On Tue, Jan 7, 2014 at 8:52 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tuesday 07 January 2014, Linus Walleij wrote: >> It appears that these problems appear if you explicitly >> enable the DT board support, can't we just put that into >> the defconfig then, so we don't miss such things? > > I don't understand. I didn't enable it manually and > I still get it on linux-next-20130107. Maybe you were > still on the older linux-next that had not been updated > for some time? No that's not the problem, I used the latest... but: (...) > I just tried building with "make allmodconfig KCONFIG_ALLCONFIG=allconfig", > with the allconfig file containing a CONFIG_MACH_S3C2410=y statement. > This caught a number of additionl problems, some related and some not. This was the problem, so making new build rules now to see if I can catch this. > What is actually the bigger worry here is that the contents > of the new file, while correctly moved out of mach/gpio.h also > don't belong into include/linux/platform_data, because they don't > define a pdata structure but rather the contents that are supposed > to be passed from the platform code. I would much prefer if you could > move the file back into mach-s3c24xx/ under a new name and keep it out of > platform_data. Unfortunately it cannot live right under mach-s3c24xx because there are drivers here and there referring directly to the contents of this file. The only quick-fix option would be to move it back to <mach/gpio-samsung-s3c24xx.h> but the real solution is of course to augment all drivers to use gpio descriptors and add descriptor tables to the boardfiles. I'm a bit reluctant to do that as I'd prefer to be able to test such modifications on HW ... plus time may be better invested in DT migration (as I think is the conclusion of this thread eventually). > I suspect that the only thing actually needed by the > gpio driver is the number of GPIO lines per platform, and we can > find another way to communicate that. A bit more: if you look in drivers/gpio/gpio-samsung.c you see bank base GPIO offset for each bank into the global scope *and* the number of GPIOs for each bank propagated from machine headers instead of using platform data. Again the proper solution (if the boardfiles are kept) is to switch to using a GPIO descriptor table. Or using DT. > Most of the contents should > be private to the mach-s3c code and not be visible to either the > gpio driver or any drivers using the plat/gpio-cfg.h interface. Samsungs <plat/gpio-cfg.h> is basically a custom legacy pin control implementation. The real solution to getting rid of that file is to switch over to using pinctrl-[samsung|s3c24xx] which as Heiko describes mandates also using DT, and thus blocks attempts at using this path for fixing the legacy boardfiles. It's one of these situations where we end up with an all-or-nothing conversion path: either you change everything over to device tree or everything stays in two copies ... I'm trying to refactor the existing board files here maybe that is in vain :-/ as GPIO maintainer I want to get rid of <mach/gpio.h>. >> > Note that on Exynos, the solution for the gpio driver dependencies >> > was to scrap the driver and use pinctrl-exynos instead. >> >> I think the S3C driver is a different piece of hardware unfortunately. > > But exynos was using this driver before it moved to the new pinctrl > driver. I was wrong about this, too much in my head. As Tomasz says, pinctrl-samsung can be used, but mandates that everything is moved over to device tree. Probably the best thing now that I have one problem less is to leave it to the S3C maintainers to complete their DT migration? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |