[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48990CA9.2060107@shaw.ca>
Date: Tue, 05 Aug 2008 20:30:01 -0600
From: Robert Hancock <hancockr@...w.ca>
To: Tejun Heo <htejun@...il.com>
CC: Alan Cox <alan@...rguk.ukuu.org.uk>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-ide <linux-ide@...r.kernel.org>,
Jeff Garzik <jeff@...zik.org>
Subject: Re: 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.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists