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@...12...ceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main