omap4 gpiomux driver

[Norman Feske]

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

-- 
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