headers
Linu Cherian | 1 Nov 2008 09:48
Picon

Linux Device Driver ZL50408

On Fri Oct 24, 2008 at 07:58:49AM +0530, Linu Cherian wrote:
> 

> Caleb,
> I would like to help on this. I have worked on the management
> driver of similar chip. Probably we need two seperate drivers, CMIIW.
> - management driver with a char interface for switch management
> - network driver for managing the data packets
> 
> and Iam interested to work on the management driver if you agree with
> the above. Or do we have a better way of doing it?

Caleb, iam posting the top level design to the list for feedbacks.

The processor interface provides three basic operations
1. read/write configuration register
2. send/receive Contorl command frames - for reading port statistics,
   manipulating the MAC table etc.
3. send/receive Ethernet frame
   This is the case in which the CPU management interface is used as a
   switch data port. In this case, CPU has to be assigned a MAC address.

Obviously, the driver for the ZL50408, should provide mechanisms to
carry out the above three operations.

* Operations 1 & 2 can be exported using two char dev interfaces, say
  /dev/zlreg and /dev/zlctrlfrm. User space applications can
  make use of read/write system calls to do configuration register
  access or to send/receive control frames.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Richter | 2 Nov 2008 15:58
Picon

some firedtv driver updates

Hi all,

I did a few more updates to the firedtv driver --- most of them trivial,
hence I'm not posting them on the list.  They are available at the usual
places:

== git checkout ==

git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git firedtv
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git firedtv-2.6.27
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git firedtv-2.6.28

(The former branch is the main one and based on v2.6.25.  The latter two
branches are merely merge branches which resolve merge conflicts.)

== gitweb ==

http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=shortlog;h=firedtv
http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=shortlog;h=firedtv-2.6.27
http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=shortlog;h=firedtv-2.6.28

== quilt ==

http://user.in-berlin.de/~s5r6/linux1394/firedtv/

It's still not at the level at which I would like to have reached
already some time ago for a (hopefully final) review on LKML.  There
were some other things that are keeping me distracted...

So, here is the changelog and diffstat for the series and of each of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Belisko Marek | 11 Nov 2008 14:59
Picon

Divio NW802 drivers

Hi,

I would like to use existing code for NW800 (which is infrequently
updated) chip based cameras
and create driver for kernel tree. Problem could be how to test it
because I don't have a web cam with this chip. Could you make some
proposal how to test it?

Greg could you please create a project for this driver?

Thanks

Marek

--

-- 
as simple as primitive as possible
----------------------------------------------
Marek Beli?ko - open-nandra
Rusk? Nov? Ves 219
08005 Pre?ov
Slovakia
http://open-nandra.com
Permalink | Reply | 3 comments |
headers
Greg KH | 11 Nov 2008 17:49
Gravatar

Divio NW802 drivers

On Tue, Nov 11, 2008 at 02:59:05PM +0100, Belisko Marek wrote:
> Hi,
> 
> I would like to use existing code for NW800 (which is infrequently
> updated) chip based cameras
> and create driver for kernel tree. Problem could be how to test it
> because I don't have a web cam with this chip. Could you make some
> proposal how to test it?

What code would you be modifying?  Is the code in the kernel tree
already or somewhere else?

If you don't have a device to test with, it's going to be very hard to
test :(

> Greg could you please create a project for this driver?

I'll need more information first...

thanks,

greg k-h
Permalink | Reply | 2 comments |
headers
Belisko Marek | 11 Nov 2008 22:03
Picon

Divio NW802 drivers

Hi Greg,

On Tue, Nov 11, 2008 at 5:49 PM, Greg KH <greg at kroah.com> wrote:
> On Tue, Nov 11, 2008 at 02:59:05PM +0100, Belisko Marek wrote:
>> Hi,
>>
>> I would like to use existing code for NW800 (which is infrequently
>> updated) chip based cameras
>> and create driver for kernel tree. Problem could be how to test it
>> because I don't have a web cam with this chip. Could you make some
>> proposal how to test it?
>
> What code would you be modifying?  Is the code in the kernel tree
> already or somewhere else?

I pick this driver from out of tree drivers and driver for 2.6 kernel
already exist but it's not in kernel tree.
Code working with 2.6 kernel can be found at
http://nw802.sourceforge.net/news.html  but very infrequently updated.
Nevertheless support many webcams with
NX800 chipset and it would be good to have it in main tree. It needs
some small modifications and code cleanup.

>
> If you don't have a device to test with, it's going to be very hard to
> test :(
Curious is that i type mail to author of driver to ask him for check
if driver will work after modifications
and he response that he stops development because he broke his camera
with NW chipset during development :)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mauro Carvalho Chehab | 11 Nov 2008 22:22
Favicon

Divio NW802 drivers

On Tue, 11 Nov 2008, Belisko Marek wrote:

>> What code would you be modifying?  Is the code in the kernel tree
>> already or somewhere else?
>
> I pick this driver from out of tree drivers and driver for 2.6 kernel
> already exist but it's not in kernel tree.
> Code working with 2.6 kernel can be found at
> http://nw802.sourceforge.net/news.html  but very infrequently updated.
> Nevertheless support many webcams with
> NX800 chipset and it would be good to have it in main tree. It needs
> some small modifications and code cleanup.

It needs also to replace from V4L1 to V4L2 API. You'll certainly need one 
sample of the device to test the newer mmap modes that are very different 
from what we had on V4L1 API.

Probably, it shouldn't be hard to transform this driver into a gspca 
sub-driver, instead of trying to change it into V4L2.

> Curious is that i type mail to author of driver to ask him for check
> if driver will work after modifications
> and he response that he stops development because he broke his camera
> with NW chipset during development :)
>
This happens ;)

> So it make sense to ask someone for help or should I stop it in this phase?

If you find some device to test, then it could be interesting. I suspect
(Continue reading)

Permalink | Reply | 0 comments |
headers
hong zhang | 13 Nov 2008 16:34
Picon
Favicon

how kernel detect device and make proble() called?

List,

Does anyone know how kernel detects a device and make probe() called for its driver?

---henry
Permalink | Reply | 6 comments |
headers
Greg KH | 13 Nov 2008 17:10
Gravatar

how kernel detect device and make proble() called?

On Thu, Nov 13, 2008 at 07:34:58AM -0800, hong zhang wrote:
> List,
> 
> Does anyone know how kernel detects a device and make probe() called for its driver?

Yes.
Permalink | Reply | 5 comments |
headers
Greg KH | 13 Nov 2008 17:30
Gravatar

how kernel detect device and make proble() called?

On Thu, Nov 13, 2008 at 08:10:11AM -0800, Greg KH wrote:
> On Thu, Nov 13, 2008 at 07:34:58AM -0800, hong zhang wrote:
> > List,
> > 
> > Does anyone know how kernel detects a device and make probe() called for its driver?
> 
> Yes.

(hint, you are going to have to be a lot more specific about your
question in order to get a good answer...)
Permalink | Reply | 4 comments |
headers
Stefan Richter | 13 Nov 2008 18:02
Picon

how kernel detect device and make proble() called?

Greg KH wrote:
> On Thu, Nov 13, 2008 at 08:10:11AM -0800, Greg KH wrote:
>> On Thu, Nov 13, 2008 at 07:34:58AM -0800, hong zhang wrote:
>> > List,
>> > 
>> > Does anyone know how kernel detects a device and make probe() called for its driver?
>> 
>> Yes.

Usually there is a subsystem which --- from the Linux driver Model's
point of view --- implements a "bus".  The subsystem has its specific
means to detect presence of hardware.  It creates one or more device
representations of detected hardware and these data structures typically
encapsulate a struct device.  The subsystem registers this struct device
instance with Linux' driver core.  The driver core calls the subsystem's
driver match method for this device and binds the first matching driver
to it.  Then the core calls this driver's probe method for the device.

> (hint, you are going to have to be a lot more specific about your
> question in order to get a good answer...)

...notably, whether you are dealing with an entirely new bus or with one
for which Linux already has support (PCI, USB...).

In the latter case, the task of the driver author is to properly
register its driver with the respective subsystem and to expose the
appropriate match flags for the subsystem's driver match routine, for
example a PCI ID table in case of a PCI device driver.

In the former case, somebody had to implement the subsystem
(Continue reading)

Permalink | Reply | 0 comments |

Gmane