Hi all,
on our embedded system we connected a HDD via FPGA driectly to the CPU.
And wrote a evry simple IDE driver for it. BAsicly the HDD internbal
registers are just memory mapped. No DMA is supported by the hardware.
But I think it would be capable of 48bit LBA mode (which just means setting
And wrote a evry simple IDE driver for it. BAsicly the HDD internbal
registers are just memory mapped. No DMA is supported by the hardware.
But I think it would be capable of 48bit LBA mode (which just means setting
the HOB bit in the device control register of the HDD correctly?)
And not
Only relevant for DMA really
So rqsize is only needed for DMA accesses?
PIO transfers are sector at a time, or multi-sector up to a usual limit
of about 16 sectors.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More
Hello.
Alan wrote:
Only relevant for DMA really
So rqsize is only needed for DMA accesses?
Not really, it affects both PIO and DMA.
PIO transfers are sector at a time, or multi-sector up to a usual limit
of about 16 sectors.
You're clearly mixing 2 things here. PIO transfers are
Alan,
Only relevant for DMA really
So rqsize is only needed for DMA accesses?
PIO transfers are sector at a time, or multi-sector up to a usual limit
of about 16 sectors.
So again: rqsize does not matter for PIO transfer?
Looking at the lines
if (hwif-no_lba48_dma lba48 dma) {
On Wed, 07 Feb 2007 14:57:27 +0100
Steven Scholz [EMAIL PROTECTED] wrote:
Alan,
Only relevant for DMA really
So rqsize is only needed for DMA accesses?
PIO transfers are sector at a time, or multi-sector up to a usual limit
of about 16 sectors.
So again: rqsize does not matter
Alan wrote:
On Wed, 07 Feb 2007 16:49:44 +0300
Sergei Shtylyov [EMAIL PROTECTED] wrote:
Hello.
Alan wrote:
Only relevant for DMA really
So rqsize is only needed for DMA accesses?
Not really, it affects both PIO and DMA.
Yes but its not relevant. The question was about
hda: status timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE_EXT
ide0: unexpected interrupt, status=0x80, count=1
ide0: reset: success
) sometimes when rqsize is set to 65536 altough I only do PIO transfer?
If
Hello.
Steven Scholz wrote:
So rqsize is only needed for DMA accesses?
PIO transfers are sector at a time, or multi-sector up to a usual limit
of about 16 sectors.
So again: rqsize does not matter for PIO transfer?
Looking at the lines
if (hwif-no_lba48_dma lba48 dma) {
Hello.
Alan wrote:
Only relevant for DMA really
So rqsize is only needed for DMA accesses?
Not really, it affects both PIO and DMA.
Yes but its not relevant. The question was about performance, and your
performance will suck equally with PIO regardless of the request size
limit.
The attached patch modifies drivers/ata/sata_vsc.c to only set the cache
line size to 0x80 if the default value is zero. Apparently zero isn't
allowed due to a bug in the chip, but I've found performance is much
better with the (non-zero) default instead of 0x80.
Signed-off-by: Nate Dailey [EMAIL
I was trying to use HDIO_DRIVE_TASK for something today,
and discovered that the libata implementation does not copy
over the upper four LBA bits from args[6].
This is serious, as any tools using this ioctl would have their
commands applied to the wrong sectors on the drive, possibly resulting
Art Haas wrote:
Also, zero out the features register before issuing PACKET_IDENTIFY,
if the code isn't already doing that.
Okay.
After the drive asserts BUSY, and later deasserts BUSY,
there might be a slight delay before the drive asserts DRQ.
So, it is possible for the status to read zeros
On Wed, Feb 07, 2007 at 11:53:17AM +0900, Tejun Heo wrote:
Art Haas wrote:
Also, zero out the features register before issuing PACKET_IDENTIFY,
if the code isn't already doing that.
Okay.
After the drive asserts BUSY, and later deasserts BUSY,
there might be a slight delay before the drive
Art Haas wrote:
On Wed, Feb 07, 2007 at 11:53:17AM +0900, Tejun Heo wrote:
Art Haas wrote:
Also, zero out the features register before issuing PACKET_IDENTIFY,
if the code isn't already doing that.
Okay.
SUCCESS!
Yay!
...
So, it succeeded without any DRQ wait. Can you please apply
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder whether
its author really thought that he could achieve that wrtiting to BMIDE status
registers? Stop fiddling with the DMA capable bits in the speedproc() -- they
do not enable DMA, and are properly dealt with by the
I boot 2.6.20 also on a pentium4 with intel 82801EB/ER (ICH5/ICH5R) IDE
Controller and the same pata disk.
On this controller the disk runs in DMA100 as it should, so I'm prone to
think it is a pata_amd.c driver trouble. Should try downgrading this
driver from version 0.2.7 to version 0.2.4?
On Wed, 7 Feb 2007 01:19:36 +0100
Luigi Genoni [EMAIL PROTECTED] wrote:
Hi,
since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is
initialized maximum in DMA33 mode (and obviously performances drop
consequently), as you can see from:
Interesting.
Willing to test any
Grzegorz Kulewski wrote:
It worked very well for half a year but with one disk (IIRC it was even
plugged into second channel but I wont bet on it). Now I have second
disk (very similar) and it is always put into PIO4 mode:
[ 17.404451] libata version 2.00 loaded.
[ 17.404916] sata_uli
Hello,
Michal Piotrowski wrote:
[--snip--]
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index a388a8d..cf70702 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1037,7 +1037,7 @@ static unsigned int ata_id_xfermask(cons
* the PIO
Hi,
Short summary:
- HPT driver rewrite (has been in -mm for months)
- driver for Toshiba TC86C001 chipset
- some fixes for piix/slc90e66/pdc202xx_new drivers
(Sergei Shtylyov [EMAIL PROTECTED])
- driver for ITE IT8213 chipset
(Jack Lee [EMAIL PROTECTED], some fixes from Alan Cox and me)
On Wed, 07 Feb 2007 19:08:14 +0100
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
- ACPI support for IDE (has been in SuSE kernels for months)
(Hannes Reinecke [EMAIL PROTECTED])
I can find no public copy of this or discussion of it, please post a
reference to the previous discussion or
reference to the previous discussion or put the ACPI patch somewhere for
review first.
http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/ide-acpi-support.patch
Thanks
Acked-by: Alan Cox [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-ide
On Wed, 07 Feb 2007 21:22:06 +0300 Alexey Starikovskiy [EMAIL PROTECTED]
wrote:
Andrew,
This bug seem to be duplicate of 7907, which in turn seem to be caused
by latest libata patches.
Oh. Surprised. Let's tell Jeff about it.
Thanks,
Alex.
Andrew Morton wrote:
This looks like
[PATCH] ide: move IDE settings handling to ide-proc.c
* move
__ide_add_setting()
ide_add_setting()
__ide_remove_setting()
auto_remove_settings()
ide_find_setting_by_name()
ide_read_setting()
ide_write_setting()
set_xfer_rate()
25 matches
Mail list logo
