2013/1/24 Norman Feske <norman.feske@...1...>
Hi Alexander,
thanks for sharing your work.
Hi Norman,
Thank you for your response
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.
Initially I assumed that the interface would be different because
different SoCs can have a different number of multiplexable pin configurations. Moreover, stuff like enable/output enable/pullup enable is different, for, example, on TI OMAP4 and Qualcomm MSM - OMAP allows to set up separate configurations for output, input and sleep modes, while MSM has only one configuration for all modes.
But if we use string names to identify pins and integers for configuration, like it's currently implemented in linux and like I've done for Genode, we can probably have the unified interface for all SoCs. I would suggest keeping the PINMUX separate from GPIO at least until we add the support for 2-3 SoCs
- 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.
Resource arbitration is another interesting topic. Various resources such as GPIOs, regulators, clocks and even memory regions should be somehow assigned capabilities in a coarse-grained manner. For that I would like to know if there is or is planned a simpler way than writing a proxy limiting access to a subset of resources for each session type, or this could be somehow automated.
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.
For a start, I would suggest (and try doing) simply porting the drivers
from linux and having a simple interface like looking up resources by names, and then think together about adding security measures. Btw, currently my strongest concern is the lack of resource limiting for IO/RM access :)
I'm currently in the process of writing an article about my concerns about Genode, I plan to finish it by the weekend and would like you to comment on some points. It will probably be posted somewhere at the Ksys website
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
Have a nice day!
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main