Re: [PATCH] of/lib: Export fdt routines to modules

[Michael Bohan]

On Fri, Oct 18, 2013 at 07:38:04PM +0100, Mark Rutland wrote:

Hi Mark,

> On Fri, Oct 18, 2013 at 01:44:07AM +0100, Guenter Roeck wrote:
> > On 10/17/2013 04:51 PM, Michael Bohan wrote:
> > > On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> > >> On 10/16/2013 05:27 PM, Michael Bohan wrote:
> > >>> My motivation is actually to use the fdt format as a firmware.
> > >>> I have a requirement to express driver metadata that's loadable
> > >> >from the filesystem. This data is not reasonable to place in the
> > >>> system Device Tree, since it's application specific and does not
> > >>> actually describe hardware. The fact that the format chosen is
> > >>> 'flattened device tree' is merely just a coincidence.
> 
> Michael, could you elaborate on using the fdt format "as a firmware" and
> what driver metadata you need to be loadable from the filesystem?

We have a hardware device in which of its internal register state
is reconfigured for each application that uses it. And we may
need to quickly swap between applications many times within the
life of the system, so all of the data needs to be preloaded
ahead of the time. There's a lot of data that needs to be updated
in one-shot, and unfortunately there's really no great way to
abstract much of this information.

This metadata file is generated by a tool and lives on the
filesystem, and exists mainly so that each higher level
application driver doesn't need to change its code when such
parameters change. We also want it to be human-readable so that
people can view it, and possibly even tweak it by hand. As
mentioned, most of the data represent actual hardware
configurations, but some others describe per application software
implementation details.

> How are you intending to pass the DT to the kernel from userspace?

request_firmware()

> Given that you mention this is application-specific configuration, why
> is using sysfs attributes or some other sort of filesystem interaction
> not appropriate?

Sysfs is another option, but the major problem is that the driver
doesn't know the full list of applications until it reads the
firmware file. So if we went the sysfs route, it seems we'd need
to form some sort of 'virtual device' hierarchy so that the sysfs
files map 1:1 with each application. That is, read the metadata
file, and for each 'application node', instruct the driver to
create a virtual device for that application node, exposing sysfs
files that can hold its data. To me this seems a bit excessive
and complicated.

Another option would to have a flat sysfs representation and
have the write of one special file create an internal application
database entry for that configuration.

The point is, we can't proceed with normal operation until we
have the total list of applications and their respective
properties registered in memory.

But writing all the sysfs files could be expensive. There would
be complicated tables of different formats that would be
consuming to run through all the different possible entries.

To be honest, I mostly just thought the fdt would be a cool
implementation. It handles all of our requirements, while reusing
infrastructure within and external to the kernel.

Thanks,
Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/