This patch is a accumulation of ata-hosts-7/8/9/10/11, ata-autodma
and ata-ata66_check patches previously posted on LKML.
It is independent of IDE 94/95/96.
Wed Jul 3 00:13:31 CEST 2002 ide-clean-97
- add int 'modes_map' and flag 'no_atapi_autodma' to
struct ata_channel, initialise them in *_init_channel()
functions
- add int 'map' parameter to ch->udma_setup() functions
- add XFER_UDMA_ALL, XFER_UDMA_80W and rework misc defines
to ata-timing.h
- convert *_ratemask() functions to *_modes_map(),
mark them with __init
affected drivers: alim15x3.c, cmd64x.c, hpt366.c,
pdc202xx.c, serverworks.c, sis5513.c
- split aec62xx_udma_setup() to aec62xx_udma_setup()
and aec62xx_modes_map()
- split config_chipset_for_dma() in pdc202xx.c to
pdc202xx_udma_setup() and pdc202xx_tx_udma_setup()
- add udma_generic_setup() to pcidma.c, which
- equals functionality of driver specific udma_setup()
and config_chipset_for_dma()
- makes use of ch->modes_map, ch->no_atapi_autodma
and ch->speedproc()/tuneproc()
- auto-tunes PIO only if we failed to enable DMA
(PIO auto-tuning is already handled by ch->tuneproc()
call in probe.c, it is controlled separetly of autodma)
- convert aec62xx.c, alim15x3.c, amd74xx.c, cmd64x.c, hpt34x.c,
hpt366.c, it8172.c, pdc202xx.c, piix.c, serverworks.c,
sis5513.c and via82cxxx.c to new scheme
- this has nice side effect of teaching aec, amd, piix and via
drivers using DMA blacklist/whitelist
- clean usage of ch->autodma flag in PCI host chips drivers
- remove ATA_F_NOADMA flag from aec62xx.c, hpt34x.c,
sis5513.c and via82cxxx.c drivers, it's use was bogus
in these drivers
only two usages of ATA_F_NOADMA are left (in ide-pci.c),
probably they can alse be removed due to fact that drivers
should disable autodma not ide-pci (i.e. hpt34x)
- teach alim15x3.c, cs5530.c, cy82c693.c, hpt34x.c, hpt366.c,
it8172.c, pdc202xx.c, sis5513.c, sl82c105.c, and trm290.c
drivers about CONFIG_IDEDMA_AUTO (indirectly through ide-pci)
- make it possible to auto-tune DMA for trm290.c
- always check PIO timings in cs5530.c
- remove ata66_check entry from struct ata_pci_device,
initialise ch->udma_four directly in *_init_channel()
this abstraction wasn't needed and it was PCI specific
On Wed, Jul 03, 2002 at 12:22:11AM +0200, Bartlomiej Zolnierkiewicz wrote:
> This patch is a accumulation of ata-hosts-7/8/9/10/11, ata-autodma
> and ata-ata66_check patches previously posted on LKML.
>From a first review only, it looks like this patch prevents the chipset
drivers from disabling DMA mode on initialisation. This is Really Bad(tm)
since some revisions of some chipsets must _never_ be placed into DMA
mode due to hardware bugs. Even if the user selects CONFIG_IDEDMA_AUTO.
The code in sl82c105.c knows about the chipset revisions that this is
required for, and it looks like the code in ide-pci.c will override the
chipset if CONFIG_IDEDMA_AUTO is enabled.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, Jul 04, 2002 at 02:29:38PM +0100, Russell King wrote:
> On Wed, Jul 03, 2002 at 12:22:11AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > This patch is a accumulation of ata-hosts-7/8/9/10/11, ata-autodma
> > and ata-ata66_check patches previously posted on LKML.
>
> >From a first review only, it looks like this patch prevents the chipset
> drivers from disabling DMA mode on initialisation. This is Really Bad(tm)
> since some revisions of some chipsets must _never_ be placed into DMA
> mode due to hardware bugs. Even if the user selects CONFIG_IDEDMA_AUTO.
>
> The code in sl82c105.c knows about the chipset revisions that this is
> required for, and it looks like the code in ide-pci.c will override the
> chipset if CONFIG_IDEDMA_AUTO is enabled.
I think the best solution (for now) probably would be to supply the mode
map to the core IDE driver so that it can choose which modes (and
whether DMA) are available.
--
Vojtech Pavlik
SuSE Labs
On Thu, Jul 04, 2002 at 04:18:09PM +0200, Vojtech Pavlik wrote:
> I think the best solution (for now) probably would be to supply the mode
> map to the core IDE driver so that it can choose which modes (and
> whether DMA) are available.
I'm not really following your proposal, so I'll only say that as long as
the chipset driver can tell the core what its capabilities are _after_
running some chipset specific code, I'll be happy.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, 4 Jul 2002, Russell King wrote:
> On Wed, Jul 03, 2002 at 12:22:11AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > This patch is a accumulation of ata-hosts-7/8/9/10/11, ata-autodma
> > and ata-ata66_check patches previously posted on LKML.
>
> From a first review only, it looks like this patch prevents the chipset
> drivers from disabling DMA mode on initialisation. This is Really Bad(tm)
> since some revisions of some chipsets must _never_ be placed into DMA
> mode due to hardware bugs. Even if the user selects CONFIG_IDEDMA_AUTO.
My intention was to allow drivers decide about DMA and autodma.
> The code in sl82c105.c knows about the chipset revisions that this is
> required for, and it looks like the code in ide-pci.c will override the
> chipset if CONFIG_IDEDMA_AUTO is enabled.
I see, thanks. I will move this code before ->init_dma() call.
But I think that if you really want disable DMA and not only autodma
you should also set dma_base to 0 in your ->init_dma(), other way you
just mess DMA and autodma setups.
Greets.
--
Bartlomiej
> --
> Russell King ([email protected]) The developer of ARM Linux
> http://www.arm.linux.org.uk/personal/aboutme.html
>
On Thu, 4 Jul 2002, Russell King wrote:
> On Thu, Jul 04, 2002 at 04:18:09PM +0200, Vojtech Pavlik wrote:
> > I think the best solution (for now) probably would be to supply the mode
> > map to the core IDE driver so that it can choose which modes (and
> > whether DMA) are available.
>
> I'm not really following your proposal, so I'll only say that as long as
> the chipset driver can tell the core what its capabilities are _after_
> running some chipset specific code, I'll be happy.
My tuning scheme satisfies your both demands, by ch->dma_base,
ch->autodma and ch->modes_map host informs generic code about its
capabilities.
>
> --
> Russell King ([email protected]) The developer of ARM Linux
> http://www.arm.linux.org.uk/personal/aboutme.html
>
>My tuning scheme satisfies your both demands, by ch->dma_base,
>ch->autodma and ch->modes_map host informs generic code about its
>capabilities.
Just keep in mind that some chipsets don't use dma_base
but still can do DMA (typically ide-pmac, and some embedded
controllers). They do DMA their own way, not using the PRD
tables. Actually, I would love beeing able to use that same
dma_base (and others) fields for my own stuffs, but the common
layer, last I looked at it, still does assumptions that when
those are filled, they match a legacy controller.
Ben.
On Thu, 4 Jul 2002, Benjamin Herrenschmidt wrote:
> >My tuning scheme satisfies your both demands, by ch->dma_base,
> >ch->autodma and ch->modes_map host informs generic code about its
> >capabilities.
>
> Just keep in mind that some chipsets don't use dma_base
> but still can do DMA (typically ide-pmac, and some embedded
> controllers). They do DMA their own way, not using the PRD
> tables. Actually, I would love beeing able to use that same
> dma_base (and others) fields for my own stuffs, but the common
> layer, last I looked at it, still does assumptions that when
> those are filled, they match a legacy controller.
>
> Ben.
Yep, I'm aware of them.
--
Bartlomiej