Hi Alexander,
thanks for sharing your work.
I would like to receive the following comments:
- does it make sense to make separate MUX drivers for each SoC given how
specific they are or do we make it part of the GPIO interface?
To be honest, I am not really knowledgeable about the problem the MUX driver solves. So I cannot really comment of whether its interface should be merged with the 'Gpio::Session interface' or not. In any case, we should try to design the driver interface to be SoC agnostic. Right now, you are placing the interface at 'os/include/platform/omap4/gpiomux_session'. I see no reason for placing it into the 'platform/omap4' subdirectory. It should be placed directly in 'os/include/gpiomux_session'. As far as I can see, the interface function signatures are not OMAP4-specific anyway.
Of course, each SoC will have a different driver implementation. But those drivers would implement the same generic interface.
- how should we go about adding PRCM and clock stuff?
This issue starts coming up more and more. Because multiple drivers need to access these resources, we need to introduce a separate component that arbitrates the access to those (critical) registers by the different drivers. This component could be called 'platform_drv'. It is similar to pci_drv on x86 in the way that it is a central point to which any device driver connects to. I suggest to introduce a new session interface called 'Platform::Session' for that.
I think that the actual interface functions will be largely SoC specific. So here, I would opt for placing the session interface to the respective 'os/include/platform/<soc>/platform_session/' directory.
Even though the interface may be defined differently for each SoC, the configuration of a system scenario (i.e., init config) would look the same. There would always be an instance of a 'platform_drv' and drivers have corresponding session routes to this service.
Cheers Norman