IDE udma_status = 0x76 and 2.5.30...
Quoted 7 lines · Marcin Dalecki
Uz.ytkownik Petr Vandrovec napisa?:
Quoted 3 lines
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.
Quoted 7 lines
Quoted 2 lines
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 [email protected]
P.S.: Marcin, are you Marcin or Martin? MAINTAINERS says Martin, but your replies state Marcin...
Uz.ytkownik Petr Vandrovec napisa?:
Quoted 8 lines · Marcin Dalecki
Quoted 7 lines
Uz.ytkownik Petr Vandrovec napisa?:
Quoted 3 lines
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?
Quoted 6 lines
Quoted 2 lines
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?
This should handle it:
hwif->seg_boundary_mask = 0xffffffff;
Quoted 13 lines
Also
BUG_ON()inudma_new_tableis bogus. Change code:- u32
cur_len=sg_dma_len(sg)&0xffff;
+ u32cur_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);
Quoted 7 lines
Without first change
BUG_ONwill not trigger on any transfer: values up to0xFE00are legal, and values over0x10000get cut down to 0x0xxxx...Second change is needed only if we have some driver setting
max_segment_sizeto value >0xffff: currently we do not have such driver, default is0xfe00, and value set by cs5530 is0xfe00too.
Well trm390 *does* set ->seg_boundary_mask.
Quoted 8 lines
Quoted 4 lines
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).
I'm more and more amanzed, why my system works at all...
Quoted 2 lines
P.S.: Marcin, are you Marcin or Martin?MAINTAINERSsays Martin, but your replies state Marcin...
It doesn't really matter. Marcin is just the polish spelling of the name Martin. So choose whatever you want please.