Re: [RFC/Review] libata driver for Apple "macio" pata

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2008-08-01 at 12:58 -0400, Alan Cox wrote:
> > I know and I believe it should still be ok ... As I said, the chipset
> > should use the PIO field in the register for PIO transfers. And if the
> > above unknown bit is set, I suspect it's just going to increase the
> > setup time a bit or something like that, which won't hurt other than
> > perfs.
> 
> What I do with some other drivers is set the PIO mode in the pio mode function
> but defer DMA timing setup to bmdma_start/stop methods. Some chips need this
> in the PC world and that works nicely.

That would work too I suppose. I already need to tweak the DMA mode in
dbmda_start because of a need on one of the variants of the cell to add
60ns to the setup time on UDMA reads. However, the search for timing is
a bit of overhead I would have been happy to avoid there :-)

Oh well, we'll see how things go, but in this area, I think my current
code will work just fine.

> > The reason is that I can only have 64K-4K per transfer (I don't think I
> > can do 64K per DBDMA entry). So the above routine can potentially
> > breakup, in the worst case scenario, the table into twice as many
> > entries if they are all 64K precisely.
> 
> See ata_sff_dumb_qc_prep - we have PC chips with the same bug!

Yes well, this is an added bug of alignment restrictions which I don't
have (ie, you can't cross 64K boundaries, I'm pretty sure I can :-)

Anyway, setting the max segment size in the new dma params is what I
need to do here.

Cheers,
Ben.

> --
>    "Engineers are 'small children' when it comes to product warning labels"
> 					-- John Duino
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html