Manu Abraham writes: > > The user space library will not only have to know about things like > > specific GPIO controls (like mentioned in IRC) but things like > > necessary locking between busses of different logical frontends which > > belong to the same card. This can not only be necessary for one I2C > > transfer but around specific command sequences going to different devices. > > > > > Can't we use a state machine to handle this ? We don't use the RAW i2c > bus as it is, but we use another interface (which fits in the > requirements) that interfaces to the i2c bus. > > This part of the state machine does exist in kernel space as well as > user space. The state machine can be included in this interface in both > kernelspace and userspace. and the relevant functions does the necessary > translation depending upon the state. In any case a semaphore is in a > way a state machine. But how do you manage to have "states" for every possible kind of card? Add new ones for every new card with specific problems? > Some of the quirks, are basically from the bridge device, we can solve > some parts of the issues there. At present almost all frontends do > attach with an xx_attach function, and communicate through the i2c > interface. Some do use the GPIO also for handling things in between > alongwith i2c, and some even a pseudo i2c interface. anyhow i2c > communications are quite slow and do not exceed 400kHz, so this can be > really handled in userspace. > > I have a link to my original idea here. > http://www.thadathil.net/dvb/msg_transfer_interface/interface_desc.txt > > > So, would the library have to know those details about each card!? > > > > Yes, another one of the advantages would be that even the board > specifications, all those larger arrays can be moved out to userspace. > For this the library will even need to know PCI ID's etc. The interface > has to export information like this and more to userspace for the > library for identifying the boards etc, and even for doing a similar > attach routine also. Doesn't this requiring having a lot of the same functionality in both the kernel and user space? > Looking at the large number of card database structures, another > advantage of moving things to userspace is that even cards can easily be > forced to use a specific board type as this is easier in userspace > compared to kernel. Lesser bloat in the kernel too. But adding a new card which does not fit any of the old specs would still require adjusting both the kernel and the user space? You will also have to add some kind of access control to this library. Currently, only root can crash the system by selecting the wrong card. > The good thing would be that we can do whatever frontend operations > necessary, without any limitations. I am just afraid you will only be moving around the problem. Instead of having to find general descriptions for these extra frontend operations you will have to invent a general description of all kinds of ways the tuner has to access the bus and keep adding to those as new cards come along. And there are some strange ones, e.g. with I2C devices with the same address on the same bus which have to be switched somehow. Sometimes the complete I2C bus is multiplexed, sometimes only parts of it. Ralph _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
