omap4 gpiomux driver
alexander.tarasikov at ...9...
Thu Jan 24 13:45:40 CET 2013
2013/1/24 Norman Feske <norman.feske at ...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.
> 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,
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users