This machine has a known good Samsung SATA DVD on ICH8 [8086:2820].
With kernel 2.6.23-rc1 I now get the following:
ata_piix :00:1f.2: version 2.11
ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 19
PCI: Setting latency timer of
Hello.
Benjamin Herrenschmidt wrote:
Note that with all your patches applied, it doesn't seem to auto-tune
the speed at boot anymore and doesn't enable DMA. I can make it do so
with hdparm -d1, in which case, for example, on this wallstreet, I get
MDMA2 which is correct, however, it seems to
Hello.
Bartlomiej Zolnierkiewicz wrote:
* Split off checking of the status register from ide_wait_stat() to
__ide_wait_stat() helper.
* Use the new helper in ide_config_drive_speed(). The only change in the
functionality is that the function now fails if after 20 sec (WAIT_CMD)
On Mon, 23 Jul 2007 12:36:44 -0400
Chuck Ebbert [EMAIL PROTECTED] wrote:
People with IDE tape drives are complaining there's no ide-scsi
driver available anymore with the new PATA layer. Is anyone
working on one?
It would make no sense. The libata layer is already using the SCSI
midlayer so
On Mon, 2007-07-23 at 12:36 -0400, Chuck Ebbert wrote:
People with IDE tape drives are complaining there's no ide-scsi
driver available anymore with the new PATA layer. Is anyone
working on one?
You mean libata-pata? The SCSI tape driver, st (or the onstream osst
driver), should just attach
On 07/23/2007 12:52 PM, Alan Cox wrote:
People with IDE tape drives are complaining there's no ide-scsi
driver available anymore with the new PATA layer. Is anyone
working on one?
It would make no sense. The libata layer is already using the SCSI
midlayer so compliant devices should already
On Mon, 2007-07-23 at 13:01 -0400, Chuck Ebbert wrote:
On 07/23/2007 12:52 PM, Alan Cox wrote:
People with IDE tape drives are complaining there's no ide-scsi
driver available anymore with the new PATA layer. Is anyone
working on one?
It would make no sense. The libata layer is already
Hello.
Alan Cox wrote:
/* Only use IORDY/NWAIT for PIO mode 3 and 4 */
if (pio_mode 3)
info-smc.nwait_mode = 0;
else
info-smc.nwait_mode = 3;
That is wrong.
Yeah.
Any mode for PIO2+ will use IORDY. Modes below may require
it
Any mode for PIO2+ will use IORDY. Modes below may require
it sometimes (and its a good signal check). See ata_pio_need_iordy(atadev)
For PIO3+ you wanted to say? PIO2 doesn't require IORDY (and the majority
of drives report 240 ns lowest cycle time w/o IORDY which is PIO2).
I did
On Sunday 22 July 2007, Benjamin Herrenschmidt wrote:
On Sun, 2007-07-22 at 20:19 +0200, Bartlomiej Zolnierkiewicz wrote:
pmac_ide_tune_chipset() don't set drive-init_speed.
Fix it by setting drive-{current,init}_speed in pmac_ide_do_setfeature()
and clean up
On Sunday 22 July 2007, Benjamin Herrenschmidt wrote:
On Sun, 2007-07-22 at 20:20 +0200, Bartlomiej Zolnierkiewicz wrote:
kauai_lookup_timing() should always return non-zero return value:
* BUG() in kauai_lookup_timing() if the timing info cannot be found.
* Remove code checking for
On Sunday 22 July 2007, Benjamin Herrenschmidt wrote:
On Sun, 2007-07-22 at 20:21 +0200, Bartlomiej Zolnierkiewicz wrote:
* Don't check check for pmif == NULL (it should never be NULL if we got
here).
* Make a local copy of the timings and set the pmif-timings[] only after
setting
On Sunday 22 July 2007, Benjamin Herrenschmidt wrote:
On Sun, 2007-07-22 at 20:22 +0200, Bartlomiej Zolnierkiewicz wrote:
* Move adjusting of cycle time for devices providing explicit DMA cycle time
from pmac_ide_mdma_enable() to set_timings_mdma().
* Remove no longer needed
* Fix pmac_ide_dma_check() to use pmac_ide_tune_chipset() and remove no longer
necessary pmac_ide_{m,u}dma_enable().
* While at it remove some dead code from pmac_ide_dma_check() (leftovers from
conversion to use ide_max_dma_mode()).
There should be no functionality changes caused by this
On Monday 23 July 2007, Benjamin Herrenschmidt wrote:
On Sun, 2007-07-22 at 20:33 +0200, Bartlomiej Zolnierkiewicz wrote:
* Use __ide_wait_stat() instead of wait_for_ready() in
pmac_ide_do_setfeature().
While at it do following changes to match __ide_wait_stat() call in
On Sunday 22 July 2007, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
* Use -OUTBSYNC instead of -OUTB when writing command register
(needed for scc_pata and pmac host drivers).
* Don't check DRDY bit of the status register on ATAPI devices
(ATAPI devices are
Hi,
Thanks for reviewing and testing this patch series.
On Monday 23 July 2007, Benjamin Herrenschmidt wrote:
Ok, there's a combination of things here:
- First, doing a set_pio from userland (hdparm -p XX) causes the kernel
to disable DMA, which I think is incorrect. It's not the
On Monday 23 July 2007, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
* Split off checking of the status register from ide_wait_stat() to
__ide_wait_stat() helper.
* Use the new helper in ide_config_drive_speed(). The only change in the
functionality is that
On Sunday 22 July 2007, Sergei Shtylyov wrote:
Bartlomiej Zolnierkiewicz wrote:
Upper layers are responsible for controlling nIEN so don't clear nIEN after
command execution in pmac_ide_do_setfeature().
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej
Gah! Why the debug messages might be using KERN_ERR?
Blah, other debug messages where like that and I copy/pasted stupidly. I
suppose at one point, somebody (maybe me) decided that it was a PITA to
have to add debug on the kernel command line :-)
I will change all of these to pr_debug
Hi,
On Sunday 22 July 2007, Sergei Shtylyov wrote:
Bartlomiej Zolnierkiewicz wrote:
Use -set_pio_mode method to program PIO modes in ide_set_xfer_rate()
(the only place which used -speedproc to program PIO modes) and remove
handling of PIO modes from all -speedproc implementations.
On Mon, 2007-07-23 at 23:22 +0200, Bartlomiej Zolnierkiewicz wrote:
Hi,
Thanks for reviewing and testing this patch series.
On Monday 23 July 2007, Benjamin Herrenschmidt wrote:
Ok, there's a combination of things here:
- First, doing a set_pio from userland (hdparm -p XX)
Hello.
Benjamin Herrenschmidt wrote:
Ok, there's a combination of things here:
- First, doing a set_pio from userland (hdparm -p XX) causes the kernel
to disable DMA, which I think is incorrect.
That's the way ide_config_drive_speed() works.
And I still think that's bad.
Bart
On Tue, 2007-07-24 at 02:06 +0400, Sergei Shtylyov wrote:
Ugh ? It re-enables DMA in the sense that if called to configure a
DMA
speed, it re-enables dma on the host, thus effectively leaving with
DMA
enabled.
No. DMA is still diabled for the IDE core at this point. You need
a real
Use ide_config_drive_speed() instead of pmac_ide_do_setfeature() and remove
the latter, also ide-iops.c::__ide_wait_stat() could be static again.
Since for IDE PMAC host driver IDE_CONTROL_REG is always true, device's
-quirk_list is always zero and -ide_dma_host_{on,off} are nops than
the only
* Add missing initialization of hwif-autodma and drive-autodma to
pmac_ide_setup_dma().
* Use ide_tune_dma() in pmac_ide_dma_check().
While at it:
* Fix pmac_ide_dma_check() return value if DMA mode is not programmed
(should be -1 otherwise ide_set_dma() will try to enable DMA).
* Remove
This patch adds NCQ support to the sata_mv driver. Currently it does
not work: FPDMA commands time out, and eventually EH falls back to
non-NCQ, which works.
My attention has turned to other things for moment. Anybody interested
in sata_mv NCQ is encouraged to pick up where this left off, as
This is just a refresh of the existing libata-dev.git#new-eh patches
that convert all remaining old-EH drivers to new EH, against 2.6.23-rc1.
All three conversions are completely untested. pdc_adma and sata_qstor
need reviewing by someone with docs, in addition to testing.
Even it still works
28 matches
Mail list logo
