ieee1394 status
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/
Quoted 2 lines · Ira Weiny
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.
Quoted 9 lines
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?
Quoted 3 lines
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.
Quoted 4 lines
Ira
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 9 lines
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
Quoted 4 lines
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...
Quoted 1 line
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/
Quoted 13 lines · Benjamin Herrenschmidt
Quoted 8 lines
You can say whether you want the following swapped or not (in any combination, they are just flags)
1. selfid handling
2. reading
3. writingQuoted 4 lines
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?
Quoted 7 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 8 lines
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/