Hi Hans, > > Can you give examples of the sort of things that are in those registers? > Is that XML file available somewhere? Are there public datasheets? > If you mean the sensor datasheets, many of them are buried behind NDAs, but people are writing opensourced headers too...let's leave this to the lawyers. Here's an example: http://section5.ch/downloads/mt9d111.xml The XSLT sheets to generate code from it are found in the netpp distribution, see http://www.section5.ch/netpp. You might have to read some of the documentation to get to the actual clues. > BTW, you should need just a single control handler that just looks up all > the relevant information in a table. Right. It might be not too much work to write an appropriate XSLT for that. In fact, the netpp TOKENs (see it as a handle or proxy for a property) are 32 bit values, so they could be used to hold ioctl request codes. However, there are some enumeration/mapping (TOKEN -> Property) issues to be sorted out. In the standard implementation, a TOKEN is merely a mangled index, and we generate a table with elements like: { "Enable" /* id250673 */, DC_BOOL, F_RW, DC_VAR, { .varp_bool = &g_context.hist_enable }, 0 /* no children */ }, So coding efforts could again be kept at a minimum (apart from the horror of writing an XSLT), but you'd fill some bytes with the above table data. For the kernel, the property names (the string) should be probably stripped and turned into ioctl request codes (?). For some utopia, it would be darn cool (for lazy people) if device vendors provided register information in XML and the kernel would just access them via generated property tables. > If V4L2 drivers want to go into the kernel, then it is highly unlikely we > want to allow uio drivers. Such drivers cannot be reused. A typical sensor > can be used by many vendors and products. By ensuring that access to the > sensor is standardized you ensure that anyone can use that sensor and that > fixes/improvements to that sensor will benefit everyone. > > You don't have that with uio, and that's the reason we don't want it > (other reasons are possible abuse of uio allowing closed source drivers > being build on top of it). > Right. I'm aware that there's some discussion about pro/cons of uio, but I won't blame people for doing closed source drivers. Also, to bring back the above NDA topic, some vendors might be getting annoyed at source code containing their 'protected' register information. But let's keep this off topic for now. Anyhow, with the framework we use I don't see many problems in terms of reusability, because we generate most of the stuff. So you would be free to put all sensor properties into a kernel module as well (provided, that the XML files are 'free'). But for our embedded stuff (or rapid prototyping), I'd still want to see "userspace", also for the reason to quickly add a new sensor device or property without the need to recompile the kernel This is BTW a big issue for some embedded linux device vendors. So my question is still up, if there's room for userspace handlers for kernel events (ioctl requests). Our current hack is, to read events from a char device and push them through netpp. Greetings, - Martin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
