On 5 Aug 02 at 11:33, Marcin Dalecki wrote:
> Uz.ytkownik Petr Vandrovec napisa?:
> > BTW, are there any TRM290 owners using 2.5.30? Old code set length to
> > ((length >> 2) - 1) << 16, while new code does not have special handling
> > for TRM290. Or do I miss something?
>
> The new code is overwriting those values in the host controller driver
> itself.
Really? I'm not able to locate such overwrite in trm290.c. Are they hidden
somewhere else?
Also BUG_ON() in udma_new_table is bogus. Change code:
- u32 cur_len = sg_dma_len(sg) & 0xffff;
+ u32 cur_len = sg_dma_len(sg);
/* Delete this ... */
BUG_ON(cur_len > ch->max_segment_size);
*table++ = cpu_to_le32(cur_addr);
- *table++ = cpu_to_le32(cur_len);
+ *table++ = cpu_to_le32(cur_len & 0xffff);
Without first change BUG_ON will not trigger on any transfer: values
up to 0xFE00 are legal, and values over 0x10000 get cut down to
0x0xxxx...
Second change is needed only if we have some driver setting
max_segment_size to value > 0xffff: currently we do not have such driver,
default is 0xfe00, and value set by cs5530 is 0xfe00 too.
> > And BTW#2, mine problematic Toshiba disk works fine with PDC20265 with
> > 512B request size... It breaks with i845 and i440BX, under any UDMA.
>
> Hmm... It is very well possible that the Toshiba doesn't like the
> fact that the intel chipsets cheat and do something like UDMA88 instead
> of UDMA100. Could you verify this by checking whatever forcing them to
> UDMA66 helps please? Vojtech?
It happens with UDMA0 too (and I tried slowest possible timming at
i845, and it still happens).
Petr Vandrovec
vandrove@vc.cvut.cz
P.S.: Marcin, are you Marcin or Martin? MAINTAINERS says Martin,
but your replies state Marcin...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:27 EST