omap4 gpiomux driver

Norman Feske norman.feske at ...1...
Thu Jan 24 10:35:53 CET 2013

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.


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list