lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel Summit request for Discussion of future of ATA (libata) and IDE
Tejun Heo wrote:
> Robert Hancock wrote:
>> Here's my first cut at it. Compile tested only. This sets most controllers
>> to use 32-bit PIO except for those which could potentially be on a real ISA
>> or other 16-bit bus. It's a bit non-obvious what to do with some of the
>> drivers, so input is welcome.
>>
>> This implementation doesn't check the ata_id_has_dword_io at all, since it
>> would only make a difference on controllers where we don't really want to
>> use it anyway.
>>
>> It seems like regardless of whether we do 32-bit by default or not the 32-bit
>> data_xfer function should be added to libata core as we have several drivers
>> which duplicate the same code currently..
>
> Great, just some minor nitpicks as I don't have much idea about 16 bit ones.
>
>> +unsigned int ata_sff_data_xfer(struct ata_device *dev, unsigned char *buf,
>> + unsigned int buflen, int rw)
>> +{
>> + struct ata_port *ap = dev->link->ap;
>> + void __iomem *data_addr = ap->ioaddr.data_addr;
>> + unsigned int words = buflen >> 2;
>
> dwords maybe?
>
>> + unsigned int slop = buflen & 3;
>> +
>> + /* Transfer multiple of 4 bytes */
>> + if (rw == READ)
>> + ioread32_rep(data_addr, buf, words);
>> + else
>> + iowrite32_rep(data_addr, buf, words);
>> +
>> + /* Transfer trailing 1 byte, if any. */
>
> 1byte?

Yeah, those are both leftovers from the 16-bit code. I'll fix them up in
the next version, if the approach looks good..

>
> Thanks.
>


\
 
 \ /
  Last update: 2008-08-06 04:33    [W:0.247 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site