Ralph Metzler wrote:
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?
Not states for every card, but states for the messages, we are in fact
blocking the message in the kernel too.. So this state machine can be
used to control these message paths. In fact need to control the
messages only. By controlling the messages we can control the operations.
> 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?
The card definitions would need to know the PCI ID's to be defined in
user space. So there needs to be something that it can lookup with.
This definition is just read from the Bridge, and passed to user space,
so there wouldn't be duplication in there. And based upon this
information the frontends can be attached, just as in kernel, not much
of a difference except that these definitions are in user space. But
some basic definitions need to be in kernel though for the rest of the
parts.
But basically the definitions which do not involve the frontend will
need to be in kernel, but the bulk of the config that we have is just a
tuner change in any aspect.
> 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?
User space alone. The back-end drivers part in the library. If we have
such an approach, even if we do anything to the back-end drivers part in
the library or the kernel parts the interface can remain the same in any
case. I think for any hardware this idea can be adapted.
If one is doing a host bridge which is again difficult to be worked
around, this need not affect this interface.
The library will have a simple frontend to interface with applications.
The backend interfaces to the backend drivers in the library (ie ,
frontends) the frontends interface to the kernel through an "extension"
into the kernel. This "extension" needs to be the same in kernel and
userspace for communication. This in kernel end interfaces to the GPIO,
I2C, subsystem etc. It can be anything in fact.
If we don't have similar interfaces at both ends then it wouldn't be
easy/possible to have the existing stuff moved as it is to userspace.
Can be thought of something like a tunnel .. ?
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.
Isn't this the same thing we are doing in kernel ? we are just extending
the kernel interface to userspace, so in any case what we do through i2c
can be done through another interface which exists in userspace ?
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.
That case would exist in kernel too.. If it needs to be switched in
kernel, in user space this will need to be switched too..
To clear up the idea i am pasting in some ideas, even though incomplete.
The state machine is not in there right now.
This is something in between the stages..
//*/
/ Copyright (C) 2006 Andrew de Quincey <adq_dvb@xxxxxxxxxxxxx>/
/ Copyright (C) 2006 Manu Abraham <manu@xxxxxxxxxxx>/
/ This program is free software; you can redistribute it and/or modify/
/ it under the terms of the GNU General Public License as published by/
/ the Free Software Foundation; either version 2 of the License, or/
/ (at your option) any later version./
/ This program is distributed in the hope that it will be useful,/
/ but WITHOUT ANY WARRANTY; without even the implied warranty of/
/ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the/
/ GNU General Public License for more details./
/ You should have received a copy of the GNU General Public License/
/ along with this program; if not, write to the Free Software/
/ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA./
/ *//
#ifndef MTI_H
#define MTI_H
/// i2c interface/
*struct* mti_i2c_msg {
/// address/
__u32 addr;
/// flags/
__u32 flags;
#define MTI_I2C_RD 0x00000001
///type/
__u32 type;
#define MTI_I2C_HW 0x00000001
#define MTI_I2C_SW 0x00000002
/// length/
__u32 length;
/// message/
__u8 *buf;
};
/// gpio interface/
*struct* mti_gpio_msg {
/// address/
__u32 addr_msb;
__u32 addr_lsb;
/// flags/
__u32 flags;
#define MTI_GPIO_RD 0x00000001
/// length/
__u32 length;
/// message/
__u32 *buf;
};
/// for device identification/
*struct* mti_dev_id {
/// vendor/
__u8 vendor;
__u8 sub_vendor;
/// device/
__u8 device;
__u8 sub_device;
/// device id/
__u32 dev_id;
};
/// wrapper/
*struct* mti_msg {
/// system type/
__u32 sub_system;
#define SYS_DVB 0x00000001
__u16 i_msg_count;
__u16 g_msg_count;
*struct* mti_dev_id *dev_id;
*struct* mti_i2c_msg *i_msg;
*struct* mti_gpio_msg *g_msg;
};
#endif
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
