Re: [PATCH] IDE udma_status = 0x76 and 2.5.30...

[Marcin Dalecki]

Uz.ytkownik Petr Vandrovec napisa?:
> 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?

This should handle it:

	hwif->seg_boundary_mask = 0xffffffff;
> 
> 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.

Well trm390 *does* set ->seg_boundary_mask.

>>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...

> P.S.: Marcin, are you Marcin or Martin? MAINTAINERS says 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.