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

Hi Alexander,

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

I would like not to use strings but enum values in Genode's session interfaces because this way, the compiler will safe us from spelling mistakes. The values could be defined in SoC-specific headers, which can be included by the generic interface. Do you think this is reasonable?

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.

There are two approaches. The easiest one is letting the driver enforce session-specific policies (take a look at nitpicker or ram_fs for examples of employing this scheme). In short, the parent of the driver supplies a configuration to the driver, which expresses the policy imposed to different sessions. This scheme turned out to be useful in many cases. For example, when Ivan extended the nic_bridge for static IP addresses, he used this approach.

The other way would be the "proxy" approach where the session creation is monitored by a component that imposes policy. For example, a vpci server may present virtual PCI busses to different clients and use the pci_drv as back end.

...

For a start, I would suggest (and try doing) simply porting the drivers

from linux and having a simple interface like looking up resources

If you are planning to port drivers from Linux, I would like to encourage you to follow the lines of the drivers in 'dde_linux'. This has two reasons. First, the used methodology is a clean way to port drivers without "hacking" them. So we can keep the driver up to date by upgrading the Linux version of 'dde_linux'. Second, we cannot incorporate 3rd-party GPL code into Genode's base system (which includes the 'os' repository). This would prevent Genode Labs from licensing Genode under non-GPL terms. So Linux code must stay within 'dde_linux' only.

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

Very good. I'm looking forward to your article.

Cheers Norman