It is out, require 2.4.19 plus -ac4
http://www.linuxdiskcert.org/ide-2.4.19-ac4.11.patch.bz2
Cheers,
Andre Hedrick
LAD Storage Consulting Group
-----------------------------------------------------
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD7441: IDE controller on PCI bus 00 dev 39
AMD7441: chipset revision 3
AMD7441: not 100% native mode: will probe irqs later
AMD7441: disabling single-word DMA support (revision < C4)
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio
hda: IBM-DTLA-307075, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: LTN242, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
SiI3112 Serial ATA: IDE controller on PCI bus 00 dev 40
SiI3112 Serial ATA: chipset revision 1
SiI3112 Serial ATA: not 100% native mode: will probe irqs later
ide2: MMIO-DMA at 0xf8800000-0xf8800007, BIOS settings: hde:pio, hdf:pio
ide3: MMIO-DMA at 0xf8800008-0xf880000f, BIOS settings: hdg:pio, hdh:pio
hde: ST*******, ATA DISK drive
ide2 at 0xf8800080-0xf8800087,0xf880008a on irq 11
hdg: ST*******, ATA DISK drive
ide3 at 0xf88000c0-0xf88000c7,0xf88000ca on irq 11
Hi Andre!
* Andre Hedrick writes:
>It is out, require 2.4.19 plus -ac4
>http://www.linuxdiskcert.org/ide-2.4.19-ac4.11.patch.bz2
How are chances that DMA will get enabled for higher blocksizes
(c2scans, DAO cd writing, audio CD ripping)?
Is there any progress on that field in 2.5.* kernels?
regards
Markus
Greetings Markus,
It is a fair question of which I do not have a nice answer.
I am working on fresh atapi-packet-generic engine but it is not a joy.
There are oddities like bus-phases or bus-states which their setup and
feeding of the DMA engine requires a more eligant hammer.
As much as I hate to concept of a DMA mempool, it looks like the direction
to follow. Games such as HOST<>DEVICE || feast<>famine of buffer streams
appear to be the norm to push vast amounts of atapi-dma. The alternative
is to have device level request queues and have the queues carry the SG or
PRD list for that portion.
I am open to suggestions for direction.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 16 Aug 2002, Markus Plail wrote:
> Hi Andre!
>
> * Andre Hedrick writes:
> >It is out, require 2.4.19 plus -ac4
> >http://www.linuxdiskcert.org/ide-2.4.19-ac4.11.patch.bz2
>
> How are chances that DMA will get enabled for higher blocksizes
> (c2scans, DAO cd writing, audio CD ripping)?
> Is there any progress on that field in 2.5.* kernels?
>
> regards
> Markus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi Andre!
* Andre Hedrick writes:
>Greetings Markus,
>It is a fair question of which I do not have a nice answer. I am
>working on fresh atapi-packet-generic engine but it is not a joy.
>There are oddities like bus-phases or bus-states which their setup and
>feeding of the DMA engine requires a more eligant hammer.
OK, I see. It's just that I stumbled across the patch for DMA audio CD
reading and thought that you perhaps have something similiar for
writing bigger block sizes.
>As much as I hate to concept of a DMA mempool, it looks like the
>direction to follow. Games such as HOST<>DEVICE || feast<>famine of
>buffer streams appear to be the norm to push vast amounts of atapi-dma.
>The alternative is to have device level request queues and have the
>queues carry the SG or PRD list for that portion.
>I am open to suggestions for direction.
I have to admit that I do not even have an idea what you are talking
about. I just think that this is a major drawback for Linux. CD writers
are as fast as 48x nowadays and DVD writers start getting more popular,
too, just as doing c2scans. So it is quite disappointing that it doesn't
work flawlessly with Linux.
regards
Markus
On Fri, 2002-08-16 at 08:01, Andre Hedrick wrote:
> As much as I hate to concept of a DMA mempool, it looks like the direction
> to follow. Games such as HOST<>DEVICE || feast<>famine of buffer streams
> appear to be the norm to push vast amounts of atapi-dma. The alternative
> is to have device level request queues and have the queues carry the SG or
> PRD list for that portion.
We have mempool in 2.5 and backported so we can preallocate pools of
memory to meet some streaming requirement and then discard the entire
pool later.
What do you actually need ?