lkml.org 
[lkml]   [2008]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] libata: Add MMIO support to pata_sil680
Date

On 15 Feb 2008, at 21:45, Benjamin Herrenschmidt wrote:

>
> On Fri, 2008-02-15 at 15:53 +0000, Alan Cox wrote:
>>>> That's strange though. Somebody with knowledge of that HW (or
>>>> specs) who
>>>> can spot something ? Could it be an issue with timing ?
>>>>
>>>> I don't have HW access to this machine. If somebody could send
>>>> one to me
>>>> I could do more investigation.
>>>
>>> Ben, would an ssh access to such a machine and to a terminal server
>>> suffice?
>>
>> It says clearly in the code where to start. See the FIXME notes in
>> both
>> libata-sff and libata-core about MMIO. Neither the DMA transfer
>> start or
>> the probe SRST sequence are correct with MMIO posting and this hasn't
>> been fixed as I pointed out was needed when I originally NAKked the
>> change.
>>
>> Without those being fixed (especially SRST) on any device with
>> heavy PCI
>> posting of mmio your controller *wont work*.
>
> The dbdma start is mostly harmless (things don't get posted for -that-
> long), though I suppose it's worth fixing. Would reading back dmactl
> do
> in that case or do you foresee any kind of side effect ? (Maybe only
> doing it for MMIO ?)
>
> As for SRST, I'm not totally confident how safe it is to read back
> there while doing the reset sequence, so I'm tempted to really only
> do it for MMIO and use altstat rather than ctl/stat (the later tends
> to have side effects which we don't want here).
>
> What do you think ?
>
> The main problem from here is that I don't know whether we are using
> MMIO or PIO from libata-core. Maybe I can add a host flag indicate
> that such flushing is needed ?
>
> In the meantime, Guennadi, can you check if that patch helps for you
> (to see if that is indeed the problem):
>
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 004dae4..1451a52 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -3461,10 +3461,13 @@ static int ata_bus_softreset(struct ata_port
> *ap, unsigned int devmask,
>
> /* software reset. causes dev0 to be selected */
> iowrite8(ap->ctl, ioaddr->ctl_addr);
> + ioread16(ioaddr->nsect_addr);
> udelay(20); /* FIXME: flush */
> iowrite8(ap->ctl | ATA_SRST, ioaddr->ctl_addr);
> + ioread16(ioaddr->nsect_addr);
> udelay(20); /* FIXME: flush */
> iowrite8(ap->ctl, ioaddr->ctl_addr);
> + ioread16(ioaddr->nsect_addr);
>
> /* wait a while before checking status */
> ata_wait_after_reset(ap, deadline);
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index 60cd4b1..81d5828 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -273,6 +273,7 @@ void ata_bmdma_start(struct ata_queued_cmd *qc)
> * FIXME: The posting of this write means I/O starts are
> * unneccessarily delayed for MMIO
> */
> + ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
> }
>
> /**
>
> Cheers,
> Ben.


Unfortunately this patch appears to give same result as in the
original post. Guennadi and I are looking into arranging access to a
device. Thanks!

<7>pata_sil680 0000:00:0c.0: version 0.4.8
<6>sil680: 133MHz clock.
<6>scsi0 : pata_sil680
<6>scsi1 : pata_sil680
<6>ata1: PATA max UDMA/133 irq 18
<6>ata2: PATA max UDMA/133 irq 18

Tim


\
 
 \ /
  Last update: 2008-02-16 02:17    [W:0.489 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site