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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
