linux1394-devel

updated ohci driver

[Sebastien R. <Seb...@sy...>]

I have implemented a fix that was proposed a while ago by 
Robert Ficklin <rfi...@we...>. It should solve
the problem people were having with the node count staying at zero
all the time. It should also solve the bug that happen when the
card is initialized with no device connected to the bus, and then 
cannot detect any device afterward. Please try it (available
from CVS at sourceforge) and tell me if you encounter any problem.

As for the crash when loading the ohci driver on a Vaio with a CXD3222
chipset, if Sony wants to send me a laptop so I can try to fix it, I'll 
be happy to give it a shot ;-)

-- 
Sebastien Rougeaux
RSISE, The Australian National University

updated ohci driver

[Sebastien R. <Seb...@sy...>]

I have corrected a bug which was preventing the direct iso dma
to user space to work properly when using several cameras 
simultaneously on the bus (see my previous mail for the 
announcement and the explanation on how to use it).

I have now dual acquisition of 640x480 YUV422 uncompressed frames
at 30 Hz, with a CPU load so small it doesn't even appear in the
'top' command ;-)

On the down side, I have sometimes some kernel oops when trying to
stop the user app using Ctrl-C... so be warned if you want to use
this feature (it is very stable while running though).

Any comment or bug report on the ohci driver is always welcome.

Cheers,

-- 
Sebastien Rougeaux
RSISE, The Australian National University

updated ohci driver

[Sebastien R. <se...@se...>]

I have updated the ohci driver with several functionalities
(submitted by Andreas Tobler, Adam Richter, Gord Peters and
myself).

For the user side, there is now a parameter that you can set
to force the card to attempt becoming root on bus reset. It
is done at insmod time by typing 
>insmod ohci1394.o attempt_root=1
It might solve some problem when the node is not root and
the iso receive channels are not getting anything

Also, in ohci1394.h, there is now a flag USE_DEVICE that can be unset
to try the new card detection routine using 'pci_find_class'
instead of 'pci_find_device'... I am encouraging people to try
to unset to flag and see if things are working correctly. I am
also encouraging people with non-ohci cards to try it and see 
if the card is rejected properly. If everything is fine then
I will remove all the vendor/device definitions from ohci1394.h

I have also added a ohci_hw_csr_reg function to comply with the
new hook proposed by Andreas Bombe, added the (packet->type==raw)
case for the transmission of phy packets, and changed the 
proc_fs registration calls for 2.2.x kernels.

Cheers,

Sebastien Rougeaux
Seeing Machines

RE: updated ohci driver

[Gord P. <Gor...@sm...>]

> I have updated the ohci driver with several functionalities
> (submitted by Andreas Tobler, Adam Richter, Gord Peters and
> myself).

...

> new hook proposed by Andreas Bombe, added the (packet->type==raw)
> case for the transmission of phy packets, and changed the

The PHY packet transmission code you added doesn't work with the PHY packets
constructed by the hpsb_make_phypacket() routine I created.  The reason is
because you use packet->header[0] as part of the first data quadlet of the
outgoing data.  Here's the snippet of code:

        d->prg_cpu[idx]->data[0] = packet->speed_code<<16 |
		(packet->header[0] & 0xFFFF);

        if (packet->type == raw) {
		d->prg_cpu[idx]->data[1] = packet->header[1];
		d->prg_cpu[idx]->data[2] = packet->header[2];
        }

The problem with this is that you rely on the tcode already being encoded in
the packet header.  However, as Andreas pointed out, the tcode 0xE is an
OHCI specific tcode (and thus shouldn't be used in the general purpose
section of the driver).  My PHY packet construction code in
hpsb_make_phypacket() just puts the data into the packet header, and leaves
construction of the packet control information (data[0] in this case) to the
specific driver since the PCILynx driver doesn't require such information
for raw data packets.  Thus, the packet header is constructed as follows:

        packet->header[0]= data;
        packet->header[1]= ~data;

And the OHCI driver sends raw packets like this:

        if (packet->type == raw) {
            d->prg_cpu[idx]->data[0] = packet->speed_code<<16|0xE0;
            d->prg_cpu[idx]->data[1] = packet->header[0];
            d->prg_cpu[idx]->data[2] = packet->header[1];
        }

The tcode 0xE could be defined as OHCI1394_TCODE_PHY in ohci1394.h to make
it more clear what is going on there.

	Gord

RE: updated ohci driver

[Sebastien R. <seb...@an...>]

I fixed the tcode, and also set the speed to S100 for PHY
packets to comply with the ohci spec.

BTW, has anybody try to modify the #define USE_DEVICE
in ohci1394.h ? IF I don't get any complaints, then I
will use the pci_find_class() method in the next release.

Sebastien Rougeaux
Seeing Machines

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...]On Behalf Of Gord
Peters
Sent: Thursday, December 07, 2000 4:00 AM
To: se...@se...
Cc: Linux 1394 Developer List
Subject: RE: updated ohci driver


> I have updated the ohci driver with several functionalities
> (submitted by Andreas Tobler, Adam Richter, Gord Peters and
> myself).

...

> new hook proposed by Andreas Bombe, added the (packet->type==raw)
> case for the transmission of phy packets, and changed the

The PHY packet transmission code you added doesn't work with the PHY packets
constructed by the hpsb_make_phypacket() routine I created.  The reason is
because you use packet->header[0] as part of the first data quadlet of the
outgoing data.  Here's the snippet of code:

        d->prg_cpu[idx]->data[0] = packet->speed_code<<16 |
		(packet->header[0] & 0xFFFF);

        if (packet->type == raw) {
		d->prg_cpu[idx]->data[1] = packet->header[1];
		d->prg_cpu[idx]->data[2] = packet->header[2];
        }

The problem with this is that you rely on the tcode already being encoded in
the packet header.  However, as Andreas pointed out, the tcode 0xE is an
OHCI specific tcode (and thus shouldn't be used in the general purpose
section of the driver).  My PHY packet construction code in
hpsb_make_phypacket() just puts the data into the packet header, and leaves
construction of the packet control information (data[0] in this case) to the
specific driver since the PCILynx driver doesn't require such information
for raw data packets.  Thus, the packet header is constructed as follows:

        packet->header[0]= data;
        packet->header[1]= ~data;

And the OHCI driver sends raw packets like this:

        if (packet->type == raw) {
            d->prg_cpu[idx]->data[0] = packet->speed_code<<16|0xE0;
            d->prg_cpu[idx]->data[1] = packet->header[0];
            d->prg_cpu[idx]->data[2] = packet->header[1];
        }

The tcode 0xE could be defined as OHCI1394_TCODE_PHY in ohci1394.h to make
it more clear what is going on there.

	Gord

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

Re: updated ohci driver

[Dan D. <dde...@co...>]

Sebastien Rougeaux wrote:
> 
> BTW, has anybody try to modify the #define USE_DEVICE
> in ohci1394.h ? IF I don't get any complaints, then I
> will use the pci_find_class() method in the next release.

I changed the define to 0 and just tested it, and it works fine for me.

RE: updated ohci driver

[Gord P. <Gor...@sm...>]

> I fixed the tcode, and also set the speed to S100 for PHY
> packets to comply with the ohci spec.

Looks good.

> BTW, has anybody try to modify the #define USE_DEVICE
> in ohci1394.h ? IF I don't get any complaints, then I
> will use the pci_find_class() method in the next release.

I tried it with a TI LV23 based OHCI card (vendor id: 104c, device id: 8019)
and it worked fine (with USE_DEVICE defined and not defined).

	Gord

Re: [Linux1394-devel] updated ohci driver

[Hiromasa Y. <yos...@li...>]

  Sebastien Rougeaux <Seb...@sy...> wrote: 

> I have implemented a fix that was proposed a while ago by 
> Robert Ficklin <rfi...@we...>. It should solve
> the problem people were having with the node count staying at zero
> all the time. It should also solve the bug that happen when the
> card is initialized with no device connected to the bus, and then 
> cannot detect any device afterward. Please try it (available
> from CVS at sourceforge) and tell me if you encounter any problem.

  I try it with Sony VAIO Laptop (CXD3222,OHCI,1394.a). 

  When I connect VAIO, repeater and PC (TSB12LV23,OHCI),
  PC's node count is three, but VAIO's node count is still zero.

  I found VAIO's busReset Interrupt has assert correctly, but
  selfIDComplete Interrupt has never asserted. I wrote a few code to
  dump Port Status Register of PHY chip, it seems to be working normal.

  I'm confused. I think I need to look over 1394 OHCI specification.
-- 
 Hiromasa Yoshimoto / yos...@li...