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

Thanks.

--
tejun


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