On Mon 2019-04-15 13:12:59, Enrico Weigelt, metux IT consult wrote: > On 12.04.19 20:20, Jacek Anaszewski wrote: > > >> They now provide full support for the APU2/3 front peripherals, > >> LEDs as well as front key. The key cannot be used w/ the old led-only > >> driver. > > > > Then I propose to add missing functionalities to the LED subsystem > > driver. > > So, the led driver should also register an generic gpio, and an > input device as well - and so duplicate code that naturally belongs > into different subsystems ? No, other way around. > Maybe I should be a bit more clear on the situation here: > > * the AMD G-series SoCs have an integrated gpio controller, which is > used in various ways, depending on the actual board. > * apu2/apu3 is one of many boards using G-series SoCs. > * on apu2/apu3 the gpio's are used for different things, eg. leds, > keys, simcard slots, etc. > > According to the LDM, the gpio controller is one device, and the other > things, eg. leds or keys, are their own devices, that just happen to > be connected to the gpio controller. Yup. > That's also the usual way we do it in embedded world: we don't write > specific-purpose drivers for each single board, but instead generic > ones that are just configured for in the individual board's oftree. > Unfotunately, we don't have the luxury of oftree on x86, nor automatic > overlays on dmi-basis, yet - that's why the platform driver. Well, usualy vendor mask these details using ACPI BIOS on x86. But yes, device tree would make sense for this. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
