ieee1394 status

ieee1394 status

[Ira Weiny]

Has anything more been done on the ieee1394 since March?  Back then
there was a big discussion about some patches and fixes for endianess.
Did these make it into Ben's rsynced tree?

I am trying to do some work with 1394 on my Titanium and it seems to
self id correctly but there are problems when trying to read from the
bus.  I am assuming a problem in the OHCI driver since my G3 did not
have these problems last night with the pcilynx driver.  (And I can't
verify that until next week when I get back to it.  Sorry)

Should I dig into this further?  Is there a tree with newer 1394 code in
it?
Ira


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ieee1394 status

[Daniel Berlin]

On Fri, 4 May 2001, Ira Weiny wrote:

>
> Has anything more been done on the ieee1394 since March?

I'm about to submit a general endinaess patch tot he ieee1394 guys.

The problem is that you need different combinations of swapping for
different OHCI implementations, because the standard didn't specify a few
things it should have.

 I've been using 2 45 gig firewire drives using LVM
and XFS for months now.

I've been using a cd-rw firewire drive for about 3 days now, too.
>Back  then
> there was a big discussion about some patches and fixes for endianess.
> Did these make it into Ben's rsynced tree?
>
> I am trying to do some work with 1394 on my Titanium and it seems to
> self id correctly but there are problems when trying to read from the
> bus.  I am assuming a problem in the OHCI driver since my G3 did not
> have these problems last night with the pcilynx driver.  (And I can't
> verify that until next week when I get back to it.  Sorry)

Errr, this is pretty easy to fix.

In fact, it's what my patch fixes.

You can say whether you want the following swapped  or not (in any
combination, they are just flags)

1. selfid handling
2. reading
3. writing


Pismo needs 2 and 3 to work right.
Other OHCI on PPC (TI) need 1, 2, and 3.
Your titanium probably needs 2 and 3, since i believe it's based on the
uninorth, just a newer revision, right?

>
> Should I dig into this further?  Is there a tree with newer 1394 code in
> it?

It'll be on the 1394 list in about 10 minutes.

> Ira
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ieee1394 status

[Benjamin Herrenschmidt]

>You can say whether you want the following swapped  or not (in any
>combination, they are just flags)
>
>1. selfid handling
>2. reading
>3. writing
>
>
>Pismo needs 2 and 3 to work right.
>Other OHCI on PPC (TI) need 1, 2, and 3.
>Your titanium probably needs 2 and 3, since i believe it's based on the
>uninorth, just a newer revision, right?

The titanium is the same logic board as the Pismo (well, almost). The
last TiPb I had a chance to play with had the exact same UniNorth revision
as the Pismo.

When you say you need byteswap on read & write, is this for data packets
read/written to/from memory (DMA) or is this for datas you feed to
(read from) a FIFO ? Just curious...

>It'll be on the 1394 list in about 10 minutes.

Is it against the 1394 CVS or will the current 2.4.4 1394 code work fine
with your patch as well ? In that later case, I'll include your patch in my
kernels.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ieee1394 status

[Daniel Berlin]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> >You can say whether you want the following swapped  or not (in any
> >combination, they are just flags)
> >
> >1. selfid handling
> >2. reading
> >3. writing
> >
> >
> >Pismo needs 2 and 3 to work right.
> >Other OHCI on PPC (TI) need 1, 2, and 3.
> >Your titanium probably needs 2 and 3, since i believe it's based on the
> >uninorth, just a newer revision, right?
>
> The titanium is the same logic board as the Pismo (well, almost). The
> last TiPb I had a chance to play with had the exact same UniNorth revision
> as the Pismo.
>
> When you say you need byteswap on read & write, is this for data packets
> read/written to/from memory (DMA) or is this for datas you feed to
> (read from) a FIFO ? Just curious...

It's for the actual packet data in the third and fourth quadlets, at
least right now.  It's necessary because motherboard implementations
aren't required to support the byte swapping flag that normally takes
care of this. And the uninorth doesn't.
DMA is another issue altogether.
>
> >It'll be on the 1394 list in about 10 minutes.
>
> Is it against the 1394 CVS or will the current 2.4.4 1394 code work fine
> with your patch as well ?

It's against 1394 CVS, because that's what was easiest to diff against
(cvs diff -c3p, hand edit, done).
I always run your latest kernel, so i'm sure it works there too.

There are some 2.4 specific optimizations I made (use tasklets rather
than bottom halves, use a kmem_cache for packet allocation [
kmem_caches in 2.2 have some problems]) that i'd include if you want
to put it in the kernel.


> In that later case, I'll include your patch in my
> kernels.



>
> Ben.
>

--
"If you were going to shoot a mime, would you use a silencer?
"-Steven Wright

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/