Re: [RFC][PATCH 0/3] OF-platform PATA driver
On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote: > Anton Vorontsov wrote: > >Here is the PATA Platform driver using OF infrastructure. > > > >Mostly it's just a wrapper around a bit modified pata_platform > >driver. > > > >Patches are well split for the easier review: > > > >First one factors out platform_device specific bits and modifies > >pata_platform to be a library-alike driver (with platform_device > >default binding). > > The only issue I have here is that this library-like version has subtle semantic changes that will break existing drivers. irq_flags exists in struct pata_platform_info precisely for the IRQ resource IRQ flags (as opposed to the IORESOURCE flags, which are what the IRQ resource flags refer to instead). This change takes that for granted and just assumes we're going to be using the res->flags, which is both an invalid assumption, and will utterly break blackfin and others that depend on it. Incidentally, we already have an include/linux/pata_platform.h. If this is going to be library-like, through the prototypes in there, rather than splitting them up betewen include/linux and drivers/ata. We don't need two headers. These patches basically look fine to me otherwise, though it would be nice if the semantic-changing bits had been abstracted. So as long as the old irq_flags behaviour is maintained and that irq_res->flags stuff is ripped out, I'll add my Acked-by as well. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1: I/O error, system hangs
On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: > Le 23.11.2007 12:38, Hannes Reinecke a écrit : > > Hannes Reinecke wrote: > >> Laurent Riffard wrote: > >>> Le 21.11.2007 23:41, Andrew Morton a écrit : > On Wed, 21 Nov 2007 22:45:22 +0100 > Laurent Riffard <[EMAIL PROTECTED]> wrote: > > > Le 21.11.2007 05:45, Andrew Morton a écrit : > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ > > Hello, > > > > My system hangs shortly after I logged in Gnome desktop. SysRq-W shows > > that a bunch of task are blocked in "D" state, they seem to wait for > > some I/O completion. I can try to hand-copy some data if requested. > > > > I found these messages in dmesg: > > > > ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 > > EXT3-fs: mounted filesystem with ordered data mode. > > sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT > > driverbyte=DRIVER_OK,SUGGEST_OK > > end_request: I/O error, dev sda, sector 16460 > > ReiserFS: sda7: found reiserfs format "3.6" with standard journal > > ReiserFS: sda7: using ordered data mode > > -- > > ReiserFS: sda7: Using r5 hash to sort names > > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > > driverbyte=DRIVER_OK,SUGGEST_OK > > end_request: I/O error, dev sdb, sector 19632 > > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > > driverbyte=DRIVER_OK,SUGGEST_OK > > end_request: I/O error, dev sdb, sector 40037363 > > Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 > > extents:1 across:1048568k > > lp0: using parport0 (interrupt-driven). > > > > These errors occur *only* with 2.6.24-rc3-mm1, they are 100% > > reproducible. > > 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. > > > > Maybe something is broken in pata_via driver ? > > > Could be - > libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch > and > pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch > touch pata_via.c. > >>> None of the above... > >>> > >>> I did a bisection, it spotted git-scsi-misc.patch. > >>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. > >>> > >>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not > >>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other > >>> commits are touching documentation or drivers I don't use. I'll try > >>> to revert only this one this evening. > > I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 > does fix the problem. > > >> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an > >> error where > >> I shouldn't. Checking ... > >> > > Ok, found it. We are blocking even special commands (ie requests with > > PREEMPT not set) > > when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. > > Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O > errors. I think the problem is the way we treat BLOCKED and QUIESCED (the latter is the state that the domain validation uses and which we cannot kill fastfail on). It's definitely wrong to kill fastfail requests when the state is QUIESCE. This patch (which is applied on top of Hannes original) separates the BLOCK and QUIESCE states correctly ... does this fix the problem? James diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 13e7e09..a7cf23a 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1279,18 +1279,21 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req) "rejecting I/O to dead device\n"); ret = BLKPREP_KILL; break; - case SDEV_QUIESCE: case SDEV_BLOCK: /* -* If the devices is blocked we defer normal commands. -*/ - if (!(req->cmd_flags & REQ_PREEMPT)) - ret = BLKPREP_DEFER; - /* * Return failfast requests immediately */ if (req->cmd_flags & REQ_FAILFAST) ret = BLKPREP_KILL; + + /* fall through */ + + case SDEV_QUIESCE: + /* +* If the devices is blocked we defer normal commands. +*/ + if (!(req->cmd_flags & REQ_PREEMPT)) + ret = BLKPREP_DEFER; break; default: /* - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo
Re: [PATCH] sata_nv: don't use legacy DMA in ADMA mode (v2)
Tejun Heo wrote:
> Robert Hancock wrote:
>> We need to run any DMA command with result taskfile requested in ADMA mode
>> when the port is in ADMA mode, otherwise it may try to use the legacy DMA
>> engine
>> in ADMA mode which is not allowed. Enforce this with BUG_ON() since data
>> corruption could potentially result if this happened. Also WARN_ON() if we
>> try
>> and send result taskfile commands while NCQ commands are still active, since
>> the
>> hardware doesn't allow this.
>>
>> Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
>>
>> @@ -1425,9 +1427,17 @@
>> +/* We can't handle result taskfile with NCQ commands active, since
>> + retrieving the taskfile switches us out of ADMA mode and would abort
>> + existing commands. */
>> +WARN_ON((qc->flags & ATA_QCFLAG_RESULT_TF) &&
>> +(qc->ap->qc_allocated & ~(1 << qc->tag)));
>
> I owe an apology here. ap->qc_allocated & ~(1 << qc->tag) test isn't
> correct. Sorry. qc deferring happens after qc is allocated so the
> condition can trigger (although it should be rare) even when nothing is
> going wrong, so I guess it should be WARN_ON((qc->flags &
> ATA_QCFLAG_RESULT_TF) && link->sactive).
Or, just make the assumption clear by not allowing NCQ w/ RESULT_TF at all.
if (unlikely(qc->tf.protocol == ATA_PROT_NCQ &&
(qc->flags & ATA_QCFLAG_RESULT_TF)) {
ata_dev_printk(qc->dev, KERN_ERR,
"NCQ w/ RESULT_TF not allowed\n");
return AC_ERR_SYSTEM;
}
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv: don't use legacy DMA in ADMA mode (v2)
Robert Hancock wrote: > We need to run any DMA command with result taskfile requested in ADMA mode > when the port is in ADMA mode, otherwise it may try to use the legacy DMA > engine > in ADMA mode which is not allowed. Enforce this with BUG_ON() since data > corruption could potentially result if this happened. Also WARN_ON() if we try > and send result taskfile commands while NCQ commands are still active, since > the > hardware doesn't allow this. > > Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> > > @@ -1425,9 +1427,17 @@ > + /* We can't handle result taskfile with NCQ commands active, since > +retrieving the taskfile switches us out of ADMA mode and would abort > +existing commands. */ > + WARN_ON((qc->flags & ATA_QCFLAG_RESULT_TF) && > + (qc->ap->qc_allocated & ~(1 << qc->tag))); I owe an apology here. ap->qc_allocated & ~(1 << qc->tag) test isn't correct. Sorry. qc deferring happens after qc is allocated so the condition can trigger (although it should be rare) even when nothing is going wrong, so I guess it should be WARN_ON((qc->flags & ATA_QCFLAG_RESULT_TF) && link->sactive). Sorry. :-) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Robert Hancock wrote: > This fixes some problems with ATAPI devices on nForce4 controllers in ADMA > mode > on systems with memory located above 4GB. We need to delay setting the 64-bit > DMA mask until the PRD table and padding buffer are allocated so that they > don't > get allocated above 4GB and break legacy mode (which is needed for ATAPI > devices). > > Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Jeff Garzik wrote: Robert Hancock wrote: Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask unconditionally, but for non-ATA_PROT_DMA commands (which includes all ATAPI), it just falls back to ata_qc_issue_prot which issues via the legacy SFF interface and can only handle 32-bit addressing. So yes, it appears to have a similar bug as sata_nv had. sata_mv doesn't do ATAPI at all... .. Not yet, anyway. Stay tuned.. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3] OF-platform PATA driver
On Fri, 23 Nov 2007 20:52:29 +0300 Anton Vorontsov wrote: > Hi all, > > Here is the PATA Platform driver using OF infrastructure. > > Mostly it's just a wrapper around a bit modified pata_platform > driver. > > Patches are well split for the easier review: > > First one factors out platform_device specific bits and modifies > pata_platform to be a library-alike driver (with platform_device > default binding). > > Second patch is OF-driver itself which is using pata_platform > "library". > > Third patch is PowerPC specific, but I'm still Cc'ing linux-ide, > just to show how we're using it. > > > As an alternative approach we can use plain pata_platform > driver, but I'm not sure how Linux OF bindings' ideologists will > or will not like it. > > So, these patches are strongly Request For Comments. Feel free > to train your nitpicking skills ;-), and/or vote for the option > you most pleased about (or suggest another?). > I vote for of_platform_device, since we seem to dodge the clash with platform_device here. The code looks good, so I'm going to ack all 3 patches and if there will be no more nagging, I'm inclined to ask Kumar to queue this for the next merge window. -- Sincerely, Vitaly - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3] OF-platform PATA driver
On Fri, 2007-11-23 at 20:52 +0300, Anton Vorontsov wrote: > As an alternative approach we can use plain pata_platform > driver, but I'm not sure how Linux OF bindings' ideologists will > or will not like it. > > So, these patches are strongly Request For Comments. Feel free > to train your nitpicking skills ;-), and/or vote for the option > you most pleased about (or suggest another?). > > > Thanks. > > --- > Down here is "alternative approach". > > Probably board-neutral version may be placed somewhere in > the drivers/of/...? But who will call it: board file, or > device_initcall for all boards? .../... I'm fine with either approaches in fact. I think it's fair enough when there is existing platform devices to avoid duplicating the whole thing for an of_platform_device (unless you find a nice way to split to a library like you just did) and instead, have a "constructor" that constructs the platform device based on the OF node. Now, as you pointed out, the question is where to call it... the initcall has the problem of potentially being called for the wrong board and the thing having duplicate OF device and platform device created for it... One of the thing I've been brewing in my mind is the idea of reworking the current code that create OF platform devices when walking busses down, and have it instead call registered constructor functions. The default ones would then create OF platform devices but one could override that with constructors creating something else (such as a platform device). Now, it's not trivial, as there is a bit of a mixup on whether a "bus" should create all children and thus define their type (PCI would do such a thing) or whether the type is defined by the device object itself which typically would be the case for "generic" busses such as SoCs or PLBs when creating platform devices. I haven't quite found out a nice way to enable both possibilities... if you have ideas, please share. In the meantime, maybe it's best to merge the of_platform_device approach since Jeff agrees with it. Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ata.h: Don't do a SATA check for 40wire_relaxed
Alan Cox wrote: Without the valid bits at least one set of TSScorp drives report 0 in word 93 for PATA 40 wire, which we (and the specs) say actually means SATA. (The SATA version seems to report 80 wire...) Signed-off-by: Alan Cox <[EMAIL PROTECTED]> SATA version on what controller? Have you verified where the bridge is, if it's not reporting word93==0 ? Is this for 2.6.24-rc, considering that we are late in -rc? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ata_piix: port enable for the first SATA controller of ICH8 is 0xf not 0x3
Tejun Heo wrote: ICH8 and 9 use two SFF controllers to show 6 SATA ports. The first controllre hosts the first 4 ports while the second one hosts the last 2. The PCS register of the first controller encompasses the first four ports or all six ports depending on configuration while PCS of the second controller controls the last two ports. Using 0xf for the first controller and 0x3 for the second controller always result in the correct configuration. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- applied to #tj-upstream-fixes ACK - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ata_piix: only enable the first port on apple macbook pro
Tejun Heo wrote: From: Thomas Rohwer <[EMAIL PROTECTED]> ICH8M on apple macbook pro occasionally locks up completely during PCS initialization if ports other than the first one are enabled. Add a separate controller ID and only enable the first port. tj: commit description added and patch updated to fit with the previous controller ID update. Signed-off-by: Thomas Rohwer <[EMAIL PROTECTED]> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- applied to #tj-upstream-fixes ACK - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ata_piix: reorganize controller IDs
Tejun Heo wrote:
Move piix_pata_mwdma to top, rename ich9_2port_sata to ich8_2port_sata
for consistency and use automatically incremented values instead of
assigning fixed values to ease adding new controller IDs.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
applied to #tj-upstream-fixes.
drivers/ata/ata_piix.c | 62
1 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 80b735b..77fea05 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -119,18 +119,18 @@ enum {
PIIX_80C_SEC= (1 << 7) | (1 << 6),
/* controller IDs */
- piix_pata_33= 0,/* PIIX4 at 33Mhz */
- ich_pata_33 = 1,/* ICH up to UDMA 33 only */
- ich_pata_66 = 2,/* ICH up to 66 Mhz */
- ich_pata_100= 3,/* ICH up to UDMA 100 */
- ich5_sata = 5,
- ich6_sata = 6,
- ich6_sata_ahci = 7,
- ich6m_sata_ahci = 8,
- ich8_sata_ahci = 9,
- piix_pata_mwdma = 10, /* PIIX3 MWDMA only */
- tolapai_sata_ahci = 11,
- ich9_2port_sata = 12,
+ piix_pata_mwdma = 0,/* PIIX3 MWDMA only */
+ piix_pata_33, /* PIIX4 at 33Mhz */
+ ich_pata_33,/* ICH up to UDMA 33 only */
+ ich_pata_66,/* ICH up to 66 Mhz */
+ ich_pata_100, /* ICH up to UDMA 100 */
+ ich5_sata,
+ ich6_sata,
+ ich6_sata_ahci,
+ ich6m_sata_ahci,
+ ich8_sata_ahci,
+ ich8_2port_sata,
+ tolapai_sata_ahci,
When using automatically filled values, please move to a separate and
distinct enum...
ACK everything else
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] libata: update timing and fix pata_amd transfer mode selection
Tejun Heo wrote: Hello, This patchset cleans up and improves PATA timing related code and fix pata_amd transfer mode selection on top of the improvements. This patchset contains the following tweleve patches. 0001-ata_generic-unindent-loop-in-generic_set_mode.patch 0002-libata-export-xfermode-PATA-timing-related-functi.patch 0003-libata-clean-up-xfermode-PATA-timing-related-stuf.patch 0004-libata-kill-ata_id_to_dma_mode.patch 0005-libata-xfer_mask-is-unsigned-int-not-unsigned-long.patch 0006-libata-separate-out-ata_acpi_gtm_xfermask-from-pa.patch 0007-libata-fix-ata_acpi_gtm_xfermask.patch 0008-libata-implement-ata_timing_cycle2mode-and-use-it.patch 0009-libata-implement-ata_acpi_init_gtm.patch 0010-libata-reimplement-ata_acpi_cbl_80wire-using-ata_.patch 0011-libata-add-ATA_CBL_PATA_IGN.patch 0012-pata_amd-update-mode-selection-for-NV-PATAs.patch 0001-0005 are clean ups of timing handling code. 0006-0008 unifies timing handling code in libata-acpi.c and pata_acpi.c with the core timing code. 0009 implements initial GTM caching. I thought about moving this to LLDs but it's too much hassle. GTM is host wide and doing it from ->error_handler would require cross-port synchronization. Left alternative is adding a separate hook. Simply doing it during ACPI attach is simpler. 0010 reimplements ata_acpi_cbl_80wire() using ata_acpi_gtm_xfermask(). This new function takes @gtm argument. Both users (pata_via and pata_amd) are converted to pass initial GTM. 0011 implements ATA_CBL_PATA_IGN which tells libata to ignore cable type and supporess all related handling. 0012 updates mode selection for NV PATA controllers. We just can't tell what cable is attached on the controller either from host or drive side. So, for those controllers, pata_amd just sets cable type to ATA_CBL_PATA_IGN and use ->mode_filter to limit transfer mode according to BIOS/ACPI boot configuration. If that fails (not likely), pata_amd simply sets the highest allowed speed and let EH figure out the mess. With recent updates, EH should be able to figure it out pretty soon. overall this seems pretty sane... but I lean towards applying it in 2.6.25 rather than 2.6.24, since we are fairly deep into 2.6.24-rc at this point, with little time to test these and the speed down changes to ensure no last-minute breakage. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/12] libata: implement ata_timing_cycle2mode() and use it in libata-acpi and pata_acpi
Tejun Heo wrote:
libata-acpi is using separate timing tables for transfer modes
although libata-core has the complete ata_timing table. Implement
ata_timing_cycle2mode() to look for matching mode given transfer type
and cycle duration and use it in libata-acpi and pata_acpi to replace
private timing tables.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
drivers/ata/libata-acpi.c | 62 +++--
drivers/ata/libata-core.c | 52 +
drivers/ata/pata_acpi.c | 13 +
include/linux/libata.h|5 +---
4 files changed, 75 insertions(+), 57 deletions(-)
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 06d9961..7d982c2 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -424,22 +424,6 @@ int ata_acpi_cbl_80wire(struct ata_port *ap)
EXPORT_SYMBOL_GPL(ata_acpi_cbl_80wire);
-/* Welcome to ACPI, bring a bucket */
-const unsigned int ata_acpi_pio_cycle[7] = {
- 600, 383, 240, 180, 120, 100, 80
-};
-EXPORT_SYMBOL_GPL(ata_acpi_pio_cycle);
-
-const unsigned int ata_acpi_mwdma_cycle[5] = {
- 480, 150, 120, 100, 80
-};
-EXPORT_SYMBOL_GPL(ata_acpi_mwdma_cycle);
-
-const unsigned int ata_acpi_udma_cycle[7] = {
- 120, 80, 60, 45, 30, 20, 15
-};
-EXPORT_SYMBOL_GPL(ata_acpi_udma_cycle);
ah... they go away. nice.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] libata: fix ata_acpi_gtm_xfermask()
Tejun Heo wrote: ata_acpi_gtm_xfermask() as separated out from pacpi_discover_modes() has various bugs. Fix them. * The wrong comparison operator is used when finding for matching cycle resulting totally bogus result. * With the comparion operator fixed, boundary condtion handling is clumsy. * Setting of any DMA mask bit set all bits in PIO mask. * MWDMA and UDMA blocks are swapped. shouldn't this be combined with patch #6? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/12] libata: separate out ata_acpi_gtm_xfermask() from pacpi_discover_modes()
Tejun Heo wrote:
Finding out matching transfer mode from ACPI GTM values is useful for
other purposes too. Separate out the function and timing tables from
pata_acpi::pacpi_discover_modes().
Other than checking shared-configuration bit after doing
ata_acpi_gtm() in pacpi_discover_modes() which should be safe, this
patch doesn't introduce any behavior change.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
drivers/ata/libata-acpi.c | 78 +
drivers/ata/pata_acpi.c | 66 ++---
include/linux/libata.h| 25 ++
3 files changed, 114 insertions(+), 55 deletions(-)
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 08a52dd..5ffa542 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -424,6 +424,84 @@ int ata_acpi_cbl_80wire(struct ata_port *ap)
EXPORT_SYMBOL_GPL(ata_acpi_cbl_80wire);
+/* Welcome to ACPI, bring a bucket */
+const unsigned int ata_acpi_pio_cycle[7] = {
+ 600, 383, 240, 180, 120, 100, 80
+};
+EXPORT_SYMBOL_GPL(ata_acpi_pio_cycle);
+
+const unsigned int ata_acpi_mwdma_cycle[5] = {
+ 480, 150, 120, 100, 80
+};
+EXPORT_SYMBOL_GPL(ata_acpi_mwdma_cycle);
+
+const unsigned int ata_acpi_udma_cycle[7] = {
+ 120, 80, 60, 45, 30, 20, 15
+};
+EXPORT_SYMBOL_GPL(ata_acpi_udma_cycle);
these exports seem a bit ugly
If pressed I will apply, but...
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/12] libata: kill ata_id_to_dma_mode()
Tejun Heo wrote: ata_id_to_dma_mode() isn't quite generic. The function is basically privately implemented ata_id_xfermask() combined with hardcoded mode printing and configuration which are specific to ata_generic. Kill the function and open code it in generic_set_mode() using generic xfermode handling functions. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> ACK patches 1-4 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long
Jeff Garzik wrote: Tejun Heo wrote: xfer_mask is unsigned int not unsigned long. Change ->mode_filter to take and return unsigned int. While at it, rename @adev of ata_pci_default_filter() to @dev for consistency. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-sff.c |5 +++-- drivers/ata/pata_acpi.c|2 +- drivers/ata/pata_ali.c |2 +- drivers/ata/pata_hpt366.c |2 +- drivers/ata/pata_hpt37x.c |4 ++-- drivers/ata/pata_pdc2027x.c|4 ++-- drivers/ata/pata_scc.c |2 +- drivers/ata/pata_serverworks.c |4 ++-- include/linux/libata.h |5 +++-- 9 files changed, 16 insertions(+), 14 deletions(-) as I noted I permit unsigned long, which is a naturally aligned machine int on our platforms. er, s/permit/prefer/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long
Tejun Heo wrote: xfer_mask is unsigned int not unsigned long. Change ->mode_filter to take and return unsigned int. While at it, rename @adev of ata_pci_default_filter() to @dev for consistency. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-sff.c |5 +++-- drivers/ata/pata_acpi.c|2 +- drivers/ata/pata_ali.c |2 +- drivers/ata/pata_hpt366.c |2 +- drivers/ata/pata_hpt37x.c |4 ++-- drivers/ata/pata_pdc2027x.c|4 ++-- drivers/ata/pata_scc.c |2 +- drivers/ata/pata_serverworks.c |4 ++-- include/linux/libata.h |5 +++-- 9 files changed, 16 insertions(+), 14 deletions(-) as I noted I permit unsigned long, which is a naturally aligned machine int on our platforms. Consistency patches in the other direction (moving ATA_MASK_* to a separate enum and marking with UL suffix) are welcome. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] [SCSI/libata] libata EH conversion for ipr SAS
Brian King wrote: The following three patches convert ipr to use the new libata EH APIs. In the process of doing this, I first looked into implementing this in a similar manner to how libata SAS is done today, which is hooking into target_alloc/target_destroy to allocate/delete sata ports. While I was able to get this working after writing my own eh_strategy_handler, I was doubtful this was the best long term solution. One problem with this implementation I didn't solve was the fact that libata now invokes EH for each and every error received. For some devices, such as optical devices, each not ready response received during a media reload would result in all the attached SAS devices getting quiesced as well. My second approach is the attached patch set. In this series I have created a new libata API which can be used by SAS LLDDs. It introduces an ata_sas_rphy device object which is created/destroyed by the following API: ata_sas_rphy_alloc ata_sas_rphy_add ata_sas_rphy_delete When using this API in ipr, I made ipr's scsi_host the parent device of the SATA rphy. The SATA rphy is then the parent of the allocated scsi_hosts. This means that each SATA rphy in the SAS topology will have its own scsi_host, making SAS *much* more like all the SATA LLDDs in how it uses libata. The only issue I ran into with this implementation is that since each SATA port has its own scsi_host, the adapter cannot rely on scsi core to manage any LLDD or adapter imposed queue depth. To solve this I added some code to ipr. Longer term, block layer queue groups might be another way to do this. I'm still polishing this up, but it is up and running and seems to work with what testing I've done so far. I'm generally happy with this, though I am curious what Tejun thinks as well. Once everybody is happy, I think we should collect libata ACKs and then push this via the SCSI maintainership route. That would libsas work in parallel, with perhaps in situ tweaks and fixes as the implementation is fleshed out. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] libata: update EH speed down logic, take #2
Tejun Heo wrote: Hello, This is the second take of update-EH-speed-down-logic patchset. Changes from the last take[1] are... * Updated to apply & build against the current linus#master. Recently committed error-passthhrough-for-non-IO-command change broke build with this patchset applied. This patchset is against the current linux#master (b55d1b18). ACK patchset (I think I already did this, but just to reinforce) comments follow with next patchset response... - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH #upstream] ahci: update PCS programming
Tejun Heo wrote: For intel ones, ahci unconditionally OR'd 0xf to PCS. This isn't correct for the following cases. * ich6/7m's which only implement P0 and P2 (0xf works fine tho) * ich8/9's which have six ports and needs 0x3f to enable all ports This patch updates PCS programming such that... * port_map determined by ahci_save_initial_config() is OR'd instead of 0xf * PCS is updated only if necessary (there are turned off enable bits) port_map is determined from PORTS_IMPL PCI register which is implemented as write or write-once register. If the register isn't programmed, ahci automatically generates it from number of ports, which is good enough for PCS programming. ICH6/7M are probably the only ones where non-contiguous enable bits are necessary && PORTS_IMPL isn't programmed properly but they're proven to work reliably with 0xf anyway. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- As there hasn't been any report of brokeness due to this, I think this change can wait and get tested till the next merge cycle. The reason why this doesn't really break anything (yet) is that BIOS programs PCS correctly during boot and the value is preserved over suspend-to-ram, which is interesting considering the default value for PCS is zero. Maybe SMM code reprograms it while resuming? drivers/ata/ahci.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_ninja32: Cardbus ATA initial support
Alan Cox wrote: Lots of work needed to bring it up to scratch but it does work so you can now use the card. That makes it at least useful, especially as the other cardbus cards are usually INIC162x which aren't yet supported well. Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied #upstream - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3] OF-platform PATA driver
Anton Vorontsov wrote: Hi all, Here is the PATA Platform driver using OF infrastructure. Mostly it's just a wrapper around a bit modified pata_platform driver. Patches are well split for the easier review: First one factors out platform_device specific bits and modifies pata_platform to be a library-alike driver (with platform_device default binding). Second patch is OF-driver itself which is using pata_platform "library". Third patch is PowerPC specific, but I'm still Cc'ing linux-ide, just to show how we're using it. As an alternative approach we can use plain pata_platform driver, but I'm not sure how Linux OF bindings' ideologists will or will not like it. So, these patches are strongly Request For Comments. Feel free to train your nitpicking skills ;-), and/or vote for the option you most pleased about (or suggest another?). Seems reasonable from a libata point of view... (pata_platform maintainer CC'd) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_pcmcia: Minor cleanups and support for dual channel cards
Alan Cox wrote:
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_pcmcia.c
linux-2.6.24-rc2-mm1/drivers/ata/pata_pcmcia.c
--- linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_pcmcia.c 2007-11-16
17:55:11.0 +
+++ linux-2.6.24-rc2-mm1/drivers/ata/pata_pcmcia.c 2007-11-16
18:18:38.0 +
@@ -42,7 +42,7 @@
#define DRV_NAME "pata_pcmcia"
-#define DRV_VERSION "0.3.2"
+#define DRV_VERSION "0.3.3"
/*
* Private data structure to glue stuff together
@@ -198,7 +198,6 @@
/**
* pcmcia_init_one - attach a PCMCIA interface
* @pdev: pcmcia device
- * @ops: operations for this device
*
* Register a PCMCIA IDE interface. Such interfaces are PIO 0 and
* shared IRQ.
@@ -217,9 +216,10 @@
cistpl_cftable_entry_t dflt;
} *stk = NULL;
cistpl_cftable_entry_t *cfg;
- int pass, last_ret = 0, last_fn = 0, is_kme = 0, ret = -ENOMEM;
+ int pass, last_ret = 0, last_fn = 0, is_kme = 0, ret = -ENOMEM, p;
unsigned long io_base, ctl_base;
void __iomem *io_addr, *ctl_addr;
+ int n_ports = 1;
struct ata_port_operations *ops = &pcmcia_port_ops;
@@ -348,7 +348,7 @@
/* FIXME: Could be more ports at base + 0x10 but we only deal with
one right now */
if (pdev->io.NumPorts1 >= 0x20)
- printk(KERN_WARNING DRV_NAME ": second channel not yet
supported.\n");
+ n_ports = 2;
if (pdev->manf_id == 0x0097 && pdev->card_id == 0x1620)
ops = &pcmcia_8bit_port_ops;
@@ -357,20 +357,23 @@
* sane.
*/
ret = -ENOMEM;
- host = ata_host_alloc(&pdev->dev, 1);
+ host = ata_host_alloc(&pdev->dev, n_ports);
if (!host)
goto failed;
- ap = host->ports[0];
- ap->ops = ops;
- ap->pio_mask = 1;/* ISA so PIO 0 cycles */
- ap->flags |= ATA_FLAG_SLAVE_POSS;
- ap->ioaddr.cmd_addr = io_addr;
- ap->ioaddr.altstatus_addr = ctl_addr;
- ap->ioaddr.ctl_addr = ctl_addr;
- ata_std_ports(&ap->ioaddr);
+ for (p = 0; p < n_ports; p++) {
+ ap = host->ports[p];
- ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx", io_base, ctl_base);
+ ap->ops = ops;
+ ap->pio_mask = 1;/* ISA so PIO 0 cycles */
+ ap->flags |= ATA_FLAG_SLAVE_POSS;
+ ap->ioaddr.cmd_addr = io_addr + 0x10 * p;
+ ap->ioaddr.altstatus_addr = ctl_addr + 0x10 * p;
+ ap->ioaddr.ctl_addr = ctl_addr + 0x10 * p;
+ ata_std_ports(&ap->ioaddr);
a bit of coordination confusion here...
This patch requires
commit 33a2d9226557c298a5df13b95bd31b8b1d749918
Author: Alan Cox <[EMAIL PROTECTED]>
Date: Mon Oct 15 20:44:11 2007 +0100
pata_pcmcia: Add support for dumb 8bit IDE emulations
found in #for-testing. Should that patch be promoted to #upstream
(queued for 2.6.25), and then this patch applied on top, also in #upstream?
If you're curious, here is the current content of #for-testing
(attached). You need to poke me to move stuff from #for-testing to
#upstream, since I dropped it into #for-testing at your direction.
(for other readers, #for-testing is a branch always merged into #ALL and
thus -mm)
Jeff
Alan Cox (4):
libata: fix (hopefully) all the remaining problems with devices failing
setup/identify
pata_pcmcia: Add support for dumb 8bit IDE emulations
libata-core: Don't have screaming fits over DF/ERR combinations
libata/pata_it821x: Improve handling of poorly compatible emulations
drivers/ata/libata-core.c | 61 ---
drivers/ata/pata_it821x.c | 35 +-
drivers/ata/pata_pcmcia.c | 71 +-
3 files changed, 147 insertions(+), 20 deletions(-)
Re: [PATCH] libata-sff: tf_load
Alan Cox wrote:
Jeff said he preferred that the SFF tf_load followed the spec and we
documented that anyone who needed different overrode it, rather than it
using the ->check_status methods. No driver relies on the current behaviour.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-rc2-mm1/drivers/ata/libata-sff.c
linux-2.6.24-rc2-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.24-rc2-mm1/drivers/ata/libata-sff.c 2007-11-16
17:55:11.0 +
+++ linux-2.6.24-rc2-mm1/drivers/ata/libata-sff.c 2007-11-16
18:11:51.0 +
@@ -147,7 +147,9 @@
* @tf: ATA taskfile register set for storing input
*
* Reads ATA taskfile registers for currently-selected device
- * into @tf.
+ * into @tf. Assumes the device has a fully SFF compliant task file
+ * layout and behaviour. If you device does not (eg has a different
+ * status method) then you will need to provide a replacement tf_read
*
* LOCKING:
* Inherited from caller.
@@ -156,7 +158,7 @@
{
struct ata_ioports *ioaddr = &ap->ioaddr;
- tf->command = ata_chk_status(ap);
+ tf->command = ata_check_status(ap);
applied #upstream, thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libata: IORDY handling
Alan Cox wrote: I believe this version meets all Sergei's objections Correct the logic for when we issue a set features for transfer mode - If the device has IORDY and the controller has IORDY - set the mode - If the device has IORDY and the controller does not - turn IORDY off - If neither has IORDY do nothing Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied #upstream - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_hpt37x: Fix cable detect bug spotted by Sergei
Alan Cox wrote: Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_hpt37x.c linux-2.6.24-rc2-mm1/drivers/ata/pata_hpt37x.c --- linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_hpt37x.c 2007-11-16 17:55:11.0 + +++ linux-2.6.24-rc2-mm1/drivers/ata/pata_hpt37x.c 2007-11-16 18:14:19.0 + @@ -329,7 +329,7 @@ /* Restore state */ pci_write_config_byte(pdev, 0x5B, scr2); - if (ata66 & (1 << ap->port_no)) + if (ata66 & (2 >> ap->port_no)) ap->cbl = ATA_CBL_PATA40; applied #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_ali: Lots of problems still showing up with small ATAPI DMA
Alan Cox wrote: Hopefully there is a better long term solution but for now lets favour reliability. Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_ali: Add Mitac 8317 and derivatives
Alan Cox wrote: Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_ali.c linux-2.6.24-rc2-mm1/drivers/ata/pata_ali.c --- linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_ali.c 2007-11-16 17:55:11.0 + +++ linux-2.6.24-rc2-mm1/drivers/ata/pata_ali.c 2007-11-16 18:12:21.0 + @@ -63,6 +63,9 @@ /* Fujitsu P2000 */ if (pdev->subsystem_vendor == 0x10CF && pdev->subsystem_device == 0x10AF) return 1; + /* Mitac 8317 (Winbook-A) and relatives */ + if (pdev->subsystem_vendor == 0x1071 && pdev->subsystem_device == 0x8317) + return 1; applied #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libata-core: List more documentation sources for reference
Alan Cox wrote: And next time I'll be able to find the ata tape spec easily... Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ahci: Invalid use of writel/readl with iomap
Alan Cox wrote: Should use ioread* as discussed previously Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied to #upstream-fixes, after s/ahci/ata_piix/ in subject line - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Jeff Garzik wrote: Robert Hancock wrote: Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask unconditionally, but for non-ATA_PROT_DMA commands (which includes all ATAPI), it just falls back to ata_qc_issue_prot which issues via the legacy SFF interface and can only handle 32-bit addressing. So yes, it appears to have a similar bug as sata_nv had. sata_mv doesn't do ATAPI at all... Right.. missed that ATA_FLAG_NO_ATAPI. So these issues Tom is reporting are just with a normal SATA hard drive? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH #upstream-fixes] sata_sil24: fix sg table sizing
Tejun Heo wrote: sil24 unnecessarily used LIBATA_MAX_PRD and ATAPI sg table was short by one entry which might cause very obscure problems. This patch updates sg table sizing such that * One full page is used for PRB + sg table. On 4k page, this results in 253 sg's. * Make ATAPI sg block properly sized. * Make build fail if command block size doesn't equal PAGE_SIZE. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- Jeff, this one is for #upstream-fixes. drivers/ata/sata_sil24.c | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_jmicron: fix disabled port handling in jmicron_pre_reset()
Tejun Heo wrote: There are two bugs in disabled port handling. * test in PORT_PATA0 is reversed * ->prereset should return -ENOENT for disabled ports not 0 The first bug makes the PATA channel considered disabled but the second bug saves the day by returning 0. The net result is that cable is always left at ATA_CBL_UNKNOWN. This results in false 80c configuration and thus transfer errors. This patch fixes both bugs. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- applied to #tj-upstream-fixes. drivers/ata/pata_jmicron.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_sil680: kill bogus reset code (take 2)
Sergei Shtylyov wrote: Since writing to two reserved bits ain't much of a housekeeping, I think it's time we get rid of the custom error handler in this driver. ;-) Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> --- Oops, somehow I've managed to send a stale patch, without a version change... This code has been discussed 4 months ago, and is still in the same state. :-| The patch is against the Linus' tree... drivers/ata/pata_sil680.c | 32 ++-- 1 files changed, 2 insertions(+), 30 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Robert Hancock wrote: Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask unconditionally, but for non-ATA_PROT_DMA commands (which includes all ATAPI), it just falls back to ata_qc_issue_prot which issues via the legacy SFF interface and can only handle 32-bit addressing. So yes, it appears to have a similar bug as sata_nv had. sata_mv doesn't do ATAPI at all... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Mark Lord wrote: Morrison, Tom wrote: I am hopeful that the sata_mv has this bug (I proved that the problem I was experiencing was due to the sata_mv driver with 3.75Gig or more of memory)... I am on vacation for a week or more ...or I'd tell you today if it did have this bug! .. Yeah, I kind of had your reports in mind when I asked that. :) On a related note, I now have lots of Marvell (sata_mv) hardware here, and an Intel CPU/chipset box with physical RAM above the 4GB boundary. Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask unconditionally, but for non-ATA_PROT_DMA commands (which includes all ATAPI), it just falls back to ata_qc_issue_prot which issues via the legacy SFF interface and can only handle 32-bit addressing. So yes, it appears to have a similar bug as sata_nv had. Likely it needs a similar slave_config trick to change bounce limit depending on the connected device, unless there is really a way to issue ATAPI commands with this EDMA interface, as the TODO list in sata_mv.c suggests may be possible.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata NCQ blacklist entry
Am Freitag 23 November 2007 08:21:09 schrieb Andrew Morton:
> On Tue, 13 Nov 2007 21:55:15 +0100 Jan-Simon M__ller <[EMAIL PROTECTED]>
> wrote:
> > Hi!
>
> You removed from cc the guys who are most likely to fix this. Please
> always do reply-to-all.
Sri, will remember that.
>
> > Just using kernel 2.6.24-rc2 (325d22df7b19e0116aff3391d3a03f73d0634ded).
> >
>
> So is this problem (which in another email you attributed to smartd)
Even without smartd in my default runlevel it happens at some point.
> also
> present in 2.6.23?
I compiled and tested 2.6.23.8. Smartd enabled, nothing noticed, dmesg is
really clean:
dmesg | grep ata
ACPI: SSDT 7F6D3C3F, 02DD (r1 SataRe SataAhci 1000 INTL 20060912)
PERCPU: Allocating 46888 bytes of per cpu data
Memory: 2042960k/2087744k available (2062k kernel code, 44396k reserved, 982k
data, 324k init)
ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
libata version 2.21 loaded.
ata1: SATA max UDMA/133 cmd 0xc234e100 ctl 0x bmdma
0x irq 4347
ata2: SATA max UDMA/133 cmd 0xc234e180 ctl 0x bmdma
0x irq 4347
ata3: SATA max UDMA/133 cmd 0xc234e200 ctl 0x bmdma
0x irq 4347
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: WDC WD2500BEVS-22UST0, 01.01A01, max UDMA/133
ata1.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
ata2: SATA link down (SStatus 0 SControl 300)
ata3: SATA link down (SStatus 0 SControl 300)
ata_piix :00:1f.1: version 2.12
scsi3 : ata_piix
scsi4 : ata_piix
ata4: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma
0x00011810 irq 14
ata5: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma
0x00011818 irq 15
ata4.00: ATAPI: HL-DT-ST DVDRAM GSA-T20N, WW01, max UDMA/33
ata4.00: configured for UDMA/33
EXT3-fs: mounted filesystem with ordered data mode.
>
> And is is still present in 2.6.24-rc3?
Went back to 2.6.24-rc3 ...
Yes, but not at boot when smartd is started.
dmesg | grep ata
ACPI: SSDT 7F6D3C3F, 02DD (r1 SataRe SataAhci 1000 INTL 20060912)
PERCPU: Allocating 46968 bytes of per cpu data
Memory: 2048732k/2087744k available (2219k kernel code, 38624k reserved, 992k
data, 344k init)
ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
libata version 3.00 loaded.
ata1: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xfc404100 irq 4347
ata2: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xfc404180 irq 4347
ata3: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xfc404200 irq 4347
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: WDC WD2500BEVS-22UST0, 01.01A01, max UDMA/133
ata1.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
ata2: SATA link down (SStatus 0 SControl 300)
ata3: SATA link down (SStatus 0 SControl 300)
ata_piix :00:1f.1: version 2.12
scsi3 : ata_piix
scsi4 : ata_piix
ata4: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14
ata5: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
ata4.00: ATAPI: HL-DT-ST DVDRAM GSA-T20N, WW01, max UDMA/33
ata4.00: configured for UDMA/33
EXT3-fs: mounted filesystem with ordered data mode.
ata1.00: exception Emask 0x2 SAct 0x73 SErr 0x0 action 0x2 frozen
ata1.00: spurious completions during NCQ issue=0x0 SAct=0x73
FIS=004040a1:0008
ata1.00: cmd 60/10:00:d4:82:31/00:00:07:00:00/40 tag 0 cdb 0x0 data 8192 in
ata1.00: status: { DRDY }
ata1.00: cmd 60/08:08:9c:e5:cc/00:00:08:00:00/40 tag 1 cdb 0x0 data 4096 in
ata1.00: status: { DRDY }
ata1.00: cmd 60/10:20:24:61:25/00:00:09:00:00/40 tag 4 cdb 0x0 data 8192 in
ata1.00: status: { DRDY }
ata1.00: cmd 60/58:28:c4:65:25/00:00:09:00:00/40 tag 5 cdb 0x0 data 45056 in
ata1.00: status: { DRDY }
ata1.00: cmd 60/20:30:7c:f6:a3/00:00:05:00:00/40 tag 6 cdb 0x0 data 16384 in
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
ata1.00: exception Emask 0x2 SAct 0x187 SErr 0x0 action 0x2 frozen
ata1.00: spurious completions during NCQ issue=0x0 SAct=0x187
FIS=004040a1:0040
ata1.00: cmd 60/08:00:ec:af:10/00:00:04:00:00/40 tag 0 cdb 0x0 data 4096 in
ata1.00: status: { DRDY }
ata1.00: cmd 60/10:08:8c:e6:d8/00:00:04:00:00/40 tag 1 cdb 0x0 data 8192 in
ata1.00: status: { DRDY }
ata1.00: cmd 60/20:10:24:1a:da/00:00:04:00:00/40 tag 2 cdb 0x0 data 16384 in
ata1.00: status: { DRDY }
ata1.00: cmd 61/01:38:15:b3:30/00:00:07:00:00/40 tag 7 cdb 0x0 data 512 out
ata1.00: status: { DRDY }
ata1.00: cmd 61/10:40:1c:b3:30/00:00:07:00:00/40 tag 8 cdb 0x0 data 8192 out
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
Thanks !
Best regards,
Jan-Simon
-
To unsubscribe from this l
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Mark wrote: Yeah, I kind of had your reports in mind when I asked that. :) On a related note, I now have lots of Marvell (sata_mv) hardware here, and an Intel CPU/chipset box with physical RAM above the 4GB boundary. Morrison, Tom wrote: Yes, I believe that - otherwise, this problem would have been a crisis a LONG time ago...:-) But I do have some more questions in relationship to how things are mapped in your environment. I have a flat memory map (i.e.: the full 0x0 -- 0x1__ is passed to the 32bit Linux kernel without any 'holes' and/or reserved areas). Does your Intel memory map have this same type of flat memory model (and thus allow use of the FULL lower 4Gig) - or does it reserve areas of lower 4Gig for devices and such - if not - where are these reserved areas - and how do the relate to the I/O memory map for the device? In other words, I would be very interested in seeing the memory map & the PCI memory mapping to see if any overlap/correspond to reserve areas of lower 4 Gig (in a linux 32bit mode)... ... I believe that only 2GB or so of the 4GB RAM appears below the 4GB boundary. The rest is accessed above 4GB, using Intel's 36-bit PAE functionality. I think what you want to see is /proc/mtrr, annotated below by me: reg00: base=0x08000 (2048MB), size=2048MB: uncachable, count=1 I/O space reg01: base=0x0 ( 0MB), size=4096MB: write-back, count=1 first 2GB of RAM + I/O space reg02: base=0x1 (4096MB), size=1024MB: write-back, count=1 third GB of RAM reg03: base=0x14000 (5120MB), size= 512MB: write-back, count=1 portion of 4th GB of RAM reg04: base=0x16000 (5632MB), size= 256MB: write-back, count=1 portion of 4th GB of RAM reg05: base=0x17000 (5888MB), size= 128MB: write-back, count=1 portion of 4th GB of RAM reg06: base=0x17800 (6016MB), size= 64MB: write-back, count=1 portion of 4th GB of RAM reg07: base=0x0af80 (2808MB), size= 8MB: uncachable, count=1 (?) dunno From that, the visible RAM should be 2048 + 1024 + 512 + 256 + 128 + 64 = 3968MB. In /proc/meminfo, it reports MemTotal of 4067260kB, which divided by 1024 gives 3971MB. The BIOS reports 4024MB. But the MTRR values above do make it rather clear that nearly half the RAM requires 33-bit physical addressing for access. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Yes, I believe that - otherwise, this problem would have been a crisis a LONG time ago...:-) But I do have some more questions in relationship to how things are mapped in your environment. I have a flat memory map (i.e.: the full 0x0 -- 0x1__ is passed to the 32bit Linux kernel without any 'holes' and/or reserved areas). Does your Intel memory map have this same type of flat memory model (and thus allow use of the FULL lower 4Gig) - or does it reserve areas of lower 4Gig for devices and such - if not - where are these reserved areas - and how do the relate to the I/O memory map for the device? In other words, I would be very interested in seeing the memory map & the PCI memory mapping to see if any overlap/correspond to reserve areas of lower 4 Gig (in a linux 32bit mode)... Tom From: Mark Lord [mailto:[EMAIL PROTECTED] Sent: Fri 11/23/2007 12:46 PM To: Morrison, Tom Cc: Robert Hancock; linux-kernel; ide; Jeff Garzik; Tejun Heo Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3) Morrison, Tom wrote: > I am hopeful that the sata_mv has this bug (I proved that the > problem I was experiencing was due to the sata_mv driver > with 3.75Gig or more of memory)... > > I am on vacation for a week or more ...or I'd tell you today > if it did have this bug! .. Yeah, I kind of had your reports in mind when I asked that. :) On a related note, I now have lots of Marvell (sata_mv) hardware here, and an Intel CPU/chipset box with physical RAM above the 4GB boundary. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1: I/O error, system hangs
Le 23.11.2007 12:38, Hannes Reinecke a écrit : > Hannes Reinecke wrote: >> Laurent Riffard wrote: >>> Le 21.11.2007 23:41, Andrew Morton a écrit : On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard <[EMAIL PROTECTED]> wrote: > Le 21.11.2007 05:45, Andrew Morton a écrit : >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ > Hello, > > My system hangs shortly after I logged in Gnome desktop. SysRq-W shows > that a bunch of task are blocked in "D" state, they seem to wait for > some I/O completion. I can try to hand-copy some data if requested. > > I found these messages in dmesg: > > ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 > EXT3-fs: mounted filesystem with ordered data mode. > sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sda, sector 16460 > ReiserFS: sda7: found reiserfs format "3.6" with standard journal > ReiserFS: sda7: using ordered data mode > -- > ReiserFS: sda7: Using r5 hash to sort names > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 19632 > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 40037363 > Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 > extents:1 across:1048568k > lp0: using parport0 (interrupt-driven). > > These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. > 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. > > Maybe something is broken in pata_via driver ? > Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. >>> None of the above... >>> >>> I did a bisection, it spotted git-scsi-misc.patch. >>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. >>> >>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not >>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other >>> commits are touching documentation or drivers I don't use. I'll try >>> to revert only this one this evening. I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. >> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error >> where >> I shouldn't. Checking ... >> > Ok, found it. We are blocking even special commands (ie requests with PREEMPT > not set) > when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. -- laurent - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/ata/Kconfig| 10 +
drivers/ata/Makefile |1 +
drivers/ata/pata_of_platform.c | 88
3 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/pata_of_platform.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..5a492fa 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -614,6 +614,16 @@ config PATA_PLATFORM
If unsure, say N.
+config PATA_OF_PLATFORM
+ tristate "OpenFirmware platform device PATA support"
+ depends on PATA_PLATFORM && PPC_OF
+ help
+ This option enables support for generic directly connected ATA
+ devices commonly found on embedded systems with OpenFirmware
+ bindings.
+
+ If unsure, say N.
+
config PATA_ICSIDE
tristate "Acorn ICS PATA support"
depends on ARM && ARCH_ACORN
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b13feb2..ebcee64 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
obj-$(CONFIG_PATA_SCC) += pata_scc.o
obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o
obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o
+obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o
obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
# Should be last but two libata driver
obj-$(CONFIG_PATA_ACPI)+= pata_acpi.o
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
new file mode 100644
index 000..b4eca70
--- /dev/null
+++ b/drivers/ata/pata_of_platform.c
@@ -0,0 +1,88 @@
+/*
+ * OF-platform PATA driver
+ *
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include "pata_platform.h"
+
+static int __devinit pata_of_platform_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct device_node *dn = ofdev->node;
+ struct resource io_res;
+ struct resource ctl_res;
+ struct resource irq_res;
+ unsigned int ioport_shift = 0;
+ uint32_t *prop;
+
+ ret = of_address_to_resource(dn, 0, &io_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get IO address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_irq_to_resource(dn, 0, &irq_res);
+ if (ret == NO_IRQ)
+ irq_res.start = irq_res.end = -1;
+ else
+ irq_res.flags = 0;
+
+ prop = (uint32_t *)of_get_property(dn, "ioport-shift", NULL);
+ if (prop)
+ ioport_shift = *prop;
+
+ return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, &irq_res,
+ioport_shift);
+}
+
+static int __devexit pata_of_platform_remove(struct of_device *ofdev)
+{
+ return __pata_platform_remove(&ofdev->dev);
+}
+
+static struct of_device_id pata_of_platform_match[] = {
+ {
+ .compatible = "pata-platform",
+ },
+};
+
+static struct of_platform_driver pata_of_platform_driver = {
+ .name = "pata_of_platform",
+ .match_table= pata_of_platform_match,
+ .probe = pata_of_platform_probe,
+ .remove = __devexit_p(pata_of_platform_remove),
+};
+
+static int __init pata_of_platform_init(void)
+{
+ return of_register_platform_driver(&pata_of_platform_driver);
+}
+module_init(pata_of_platform_init);
+
+static void __exit pata_platform_exit(void)
+{
+ of_unregister_platform_driver(&pata_of_platform_driver);
+}
+module_exit(pata_platform_exit);
+
+MODULE_DESCRIPTION("OF-platform PATA driver");
+MODULE_AUTHOR("Anton Vorontsov <[EMAIL PROTECTED]>");
+MODULE_LICENSE("GPL");
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce pata node, make use pata_of_platform driver
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8349emitx.dts|9 +++--
arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5072f6d..898c294 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -249,6 +249,11 @@
device_type = "pci";
};
-
-
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8349emitx", "pata-platform";
+ reg = ;
+ ioport-shift = <1>;
+ interrupts = <17 8>;
+ interrupt-parent = <&ipic>;
+ };
};
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c
b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index aa76819..150fafb 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -37,6 +38,22 @@
#include "mpc83xx.h"
+static struct of_device_id mpc834x_ids[] = {
+ { .compatible = "pata-platform", },
+ {},
+};
+
+static int __init mpc834x_declare_of_platform_devices(void)
+{
+ if (!machine_is(mpc834x_itx))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc834x_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc834x_declare_of_platform_devices);
+
/*
*
* Setup the architecture
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/3] OF-platform PATA driver
Hi all,
Here is the PATA Platform driver using OF infrastructure.
Mostly it's just a wrapper around a bit modified pata_platform
driver.
Patches are well split for the easier review:
First one factors out platform_device specific bits and modifies
pata_platform to be a library-alike driver (with platform_device
default binding).
Second patch is OF-driver itself which is using pata_platform
"library".
Third patch is PowerPC specific, but I'm still Cc'ing linux-ide,
just to show how we're using it.
As an alternative approach we can use plain pata_platform
driver, but I'm not sure how Linux OF bindings' ideologists will
or will not like it.
So, these patches are strongly Request For Comments. Feel free
to train your nitpicking skills ;-), and/or vote for the option
you most pleased about (or suggest another?).
Thanks.
---
Down here is "alternative approach".
Probably board-neutral version may be placed somewhere in
the drivers/of/...? But who will call it: board file, or
device_initcall for all boards?
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c
b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index 150fafb..4caa90d 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -102,6 +103,78 @@ static int __init mpc834x_itx_probe(void)
return of_flat_dt_is_compatible(root, "MPC834xMITX");
}
+static int __init mpc834x_itx_pata_init(void)
+{
+ struct device_node *np;
+ unsigned int i;
+
+ if (!machine_is(mpc834x_itx))
+ return 0;
+
+ for (np = NULL, i = 0;
+(np = of_find_compatible_node(np, NULL, "pata-platform"));
+i++) {
+ int ret;
+ struct resource res[3];
+ const u32 *ioport_shift;
+ struct platform_device *pdev;
+ struct pata_platform_info pdata = {};
+
+ memset(res, 0, sizeof(res));
+
+ ret = of_address_to_resource(np, 0, &res[0]);
+ if (ret) {
+ printk(KERN_ERR "pata.%d: unable to get IO address "
+ "from the device tree\n", i);
+ goto err0;
+ }
+
+ ret = of_address_to_resource(np, 1, &res[1]);
+ if (ret) {
+ printk(KERN_ERR "pata.%d: unable to get CTL address "
+ "from the device tree\n", i);
+ goto err0;
+ }
+
+ ret = of_irq_to_resource(np, 0, &res[2]);
+ if (ret == NO_IRQ) {
+ printk(KERN_ERR "pata.%d: no IRQ\n", i);
+ goto err0;
+ }
+
+ ioport_shift = of_get_property(np, "ioport-shift", NULL);
+ if (ioport_shift)
+ pdata.ioport_shift = *ioport_shift;
+
+ pdev = platform_device_alloc("pata_platform", i);
+ if (!pdev)
+ goto err0;
+
+ ret = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (ret)
+ goto err1;
+
+ ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
+ if (ret)
+ goto err1;
+
+ ret = platform_device_register(pdev);
+ if (ret)
+ goto err1;
+
+ continue;
+err1:
+ printk(KERN_ERR "pata.%d: registration failed\n", i);
+ platform_device_del(pdev); /* will free everything */
+err0:
+ /* Even if some device failed, try others */
+ continue;
+ }
+
+ return 0;
+}
+device_initcall(mpc834x_itx_pata_init);
+
define_machine(mpc834x_itx) {
.name = "MPC834x ITX",
.probe = mpc834x_itx_probe,
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/ata/pata_platform.c | 139 +--
drivers/ata/pata_platform.h | 12
2 files changed, 94 insertions(+), 57 deletions(-)
create mode 100644 drivers/ata/pata_platform.h
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index ac03a90..6436c38 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -93,14 +93,9 @@ static struct ata_port_operations pata_platform_port_ops = {
};
static void pata_platform_setup_port(struct ata_ioports *ioaddr,
-struct pata_platform_info *info)
+unsigned int shift)
{
- unsigned int shift = 0;
-
/* Fixup the port shift for platforms that need it */
- if (info && info->ioport_shift)
- shift = info->ioport_shift;
-
ioaddr->data_addr = ioaddr->cmd_addr + (ATA_REG_DATA<< shift);
ioaddr->error_addr = ioaddr->cmd_addr + (ATA_REG_ERR << shift);
ioaddr->feature_addr= ioaddr->cmd_addr + (ATA_REG_FEATURE << shift);
@@ -114,8 +109,12 @@ static void pata_platform_setup_port(struct ata_ioports
*ioaddr,
}
/**
- * pata_platform_probe - attach a platform interface
- * @pdev: platform device
+ * __pata_platform_probe - attach a platform interface
+ * @dev: device
+ * @io_res: Resource representing I/O base
+ * @ctl_res: Resource representing CTL base
+ * @irq_res: Resource representing IRQ and its flags
+ * @ioport_shift: I/O port shift
*
* Register a platform bus IDE interface. Such interfaces are PIO and we
* assume do not support IRQ sharing.
@@ -135,42 +134,17 @@ static void pata_platform_setup_port(struct ata_ioports
*ioaddr,
*
* If no IRQ resource is present, PIO polling mode is used instead.
*/
-static int __devinit pata_platform_probe(struct platform_device *pdev)
+int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift)
{
- struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
- struct pata_platform_info *pp_info;
unsigned int mmio;
- int irq;
-
- /*
-* Simple resource validation ..
-*/
- if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
- dev_err(&pdev->dev, "invalid number of resources\n");
- return -EINVAL;
- }
-
- /*
-* Get the I/O base first
-*/
- io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (io_res == NULL) {
- io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(io_res == NULL))
- return -EINVAL;
- }
-
- /*
-* Then the CTL base
-*/
- ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
- if (ctl_res == NULL) {
- ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (unlikely(ctl_res == NULL))
- return -EINVAL;
- }
+ int irq = 0;
+ int irq_flags = 0;
/*
* Check for MMIO
@@ -181,14 +155,15 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
/*
* And the IRQ
*/
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- irq = 0;/* no irq */
+ if (irq_res && irq_res->start > 0) {
+ irq = irq_res->start;
+ irq_flags = irq_res->flags;
+ }
/*
* Now that that's out of the way, wire up the port..
*/
- host = ata_host_alloc(&pdev->dev, 1);
+ host = ata_host_alloc(dev, 1);
if (!host)
return -ENOMEM;
ap = host->ports[0];
@@ -209,25 +184,24 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
* Handle the MMIO case
*/
if (mmio) {
- ap->ioaddr.cmd_addr = devm_ioremap(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioremap(dev, io_res->start,
io_res->end - io_res->start + 1);
- ap->ioaddr.ctl_addr = devm_ioremap(&pdev->dev, ctl_res->start,
+ ap->ioaddr.ctl_addr = devm_ioremap(dev, ctl_res->start,
ctl_res->end - ctl_res->start + 1);
} else {
-
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Morrison, Tom wrote: I am hopeful that the sata_mv has this bug (I proved that the problem I was experiencing was due to the sata_mv driver with 3.75Gig or more of memory)... I am on vacation for a week or more ...or I'd tell you today if it did have this bug! .. Yeah, I kind of had your reports in mind when I asked that. :) On a related note, I now have lots of Marvell (sata_mv) hardware here, and an Intel CPU/chipset box with physical RAM above the 4GB boundary. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
I am hopeful that the sata_mv has this bug (I proved that the problem I was experiencing was due to the sata_mv driver with 3.75Gig or more of memory)... I am on vacation for a week or more ...or I'd tell you today if it did have this bug! From: [EMAIL PROTECTED] on behalf of Mark Lord Sent: Fri 11/23/2007 10:22 AM To: Robert Hancock Cc: linux-kernel; ide; Jeff Garzik; Tejun Heo Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3) Robert Hancock wrote: > This fixes some problems with ATAPI devices on nForce4 controllers in ADMA > mode > on systems with memory located above 4GB. We need to delay setting the 64-bit > DMA mask until the PRD table and padding buffer are allocated so that they > don't > get allocated above 4GB and break legacy mode (which is needed for ATAPI > devices). ... Mmm.. I wonder how many other libata drivers have this exact same bug, whether noticed yet or not ? Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Robert Hancock wrote: This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode on systems with memory located above 4GB. We need to delay setting the 64-bit DMA mask until the PRD table and padding buffer are allocated so that they don't get allocated above 4GB and break legacy mode (which is needed for ATAPI devices). ... Mmm.. I wonder how many other libata drivers have this exact same bug, whether noticed yet or not ? Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lost interrupt with cmd 64x
On Friday 23 November 2007, Sergei Shtylyov wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > > > This problem should have been already fixed by: > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6183289cd4356b790c5eaa619020fb887ec0fa44 > > > which was merged into 2.6.24-rc3. > > Put your attenction at the version against which this was reported -- > it's > eralier than when the regression was introduced. Indeed, you are correct! However it still would be worth to give 2.6.24-rc3 a try. Thanks, Bart - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide: add TORiSAN model: CD-ROM CDR_U200 fw: 1.09 to DMA blacklist
Bartlomiej Zolnierkiewicz wrote: Based on the report from [EMAIL PROTECTED] Should fix kernel bugzilla bug #9195. Cc: [EMAIL PROTECTED] Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] alim15x3: add Mitac 8317 and derivatives to ali_cable_override()
Bartlomiej Zolnierkiewicz wrote: Port of Alan's patch for pata_ali.c. Cc: Alan Cox <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] piix: add HP compaq laptop to short cable list
Bartlomiej Zolnierkiewicz wrote:
Port of Jeff's libata commit 54174db300ee1bac632d62e4ac37fe02e47d1f18
("[libata] ata_piix: add HP compaq laptop to short cable list").
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide: remove bogus ide_fix_driveid() comment
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] trm290: remove bogus init_hwif_trm290() comment
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ali14xx: constify __initdata
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lost interrupt with cmd 64x
Hello. Bartlomiej Zolnierkiewicz wrote: This problem should have been already fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6183289cd4356b790c5eaa619020fb887ec0fa44 which was merged into 2.6.24-rc3. Put your attenction at the version against which this was reported -- it's eralier than when the regression was introduced. Thanks, Bart MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1: I/O error, system hangs
Hannes Reinecke wrote:
> Laurent Riffard wrote:
>> Le 21.11.2007 23:41, Andrew Morton a écrit :
>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>> Laurent Riffard <[EMAIL PROTECTED]> wrote:
>>>
Le 21.11.2007 05:45, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
Hello,
My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
that a bunch of task are blocked in "D" state, they seem to wait for
some I/O completion. I can try to hand-copy some data if requested.
I found these messages in dmesg:
~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
EXT3-fs: mounted filesystem with ordered data mode.
sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 16460
ReiserFS: sda7: found reiserfs format "3.6" with standard journal
ReiserFS: sda7: using ordered data mode
--
ReiserFS: sda7: Using r5 hash to sort names
sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sdb, sector 19632
sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sdb, sector 40037363
Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1
extents:1 across:1048568k
lp0: using parport0 (interrupt-driven).
These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
Maybe something is broken in pata_via driver ?
>>> Could be -
>>> libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
>>> and
>>> pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
>>> touch pata_via.c.
>> None of the above...
>>
>> I did a bisection, it spotted git-scsi-misc.patch.
>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
>>
>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
>> commits are touching documentation or drivers I don't use. I'll try
>> to revert only this one this evening.
>>
> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error
> where
> I shouldn't. Checking ...
>
Ok, found it. We are blocking even special commands (ie requests with PREEMPT
not set)
when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.
James, please apply.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
Fix SPI Domain validation
This fixes a thinko of the FAILFAST handling: when we get
a request with FAILFAST set, we still have to evaluate the
PREEMPT flag to decide if this request should be passed through.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 13e7e09..9ec1566 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1284,13 +1284,15 @@ int scsi_prep_state_check(struct scsi_device *sdev,
struct request *req)
/*
* If the devices is blocked we defer normal commands.
*/
- if (!(req->cmd_flags & REQ_PREEMPT))
- ret = BLKPREP_DEFER;
- /*
-* Return failfast requests immediately
-*/
- if (req->cmd_flags & REQ_FAILFAST)
- ret = BLKPREP_KILL;
+ if (!(req->cmd_flags & REQ_PREEMPT)) {
+ /*
+* Return failfast requests immediately
+*/
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
+ else
+ ret = BLKPREP_DEFER;
+ }
break;
default:
/*
Re: 2.6.24-rc2 displays incorrect DVD description
Andrew Morton schrieb: (cc linux-ide) On Tue, 13 Nov 2007 15:48:21 -0500 (EST) [EMAIL PROTECTED] wrote: For example, 2.6.23.1: Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT Fri Oct 26 13:09:09 CDT 2007 kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) and 2.6.24-rc2: Linux version 2.6.24-rc2 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT Fri Nov 9 20:41:37 CST 2007 kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive kernel: hdd: ATAPI 126X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) The drive seems to work correctly, reading and writing just fine. I just happened to notice this and thought I'd pass it along. One other odd thing while looking through the logs, 2.6.23.1 has also reported the drive as follows: Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT Fri Oct 26 13:09:09 CDT 2007 kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive kernel: hdd: ATAPI 32X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) Any idea what is going on here? It's being reported as 48X, 126X, and 32X. If it's only the speed value in the description, perhaps you had different medias (no medium, CD-ROM, DVD-VIDEO, CD-R, CD-RW, ...) on this bootups in your drive, I have seen this changed speed value depending on insert medium in the past on some Liteon or Samsung drive. MBR Ansgar Knappheide - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2 displays incorrect DVD description
(cc linux-ide) On Tue, 13 Nov 2007 15:48:21 -0500 (EST) [EMAIL PROTECTED] wrote: > For example, 2.6.23.1: > > Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT > Fri Oct 26 13:09:09 CDT 2007 > kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive > kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, > UDMA(66) > > and > > 2.6.24-rc2: > > Linux version 2.6.24-rc2 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP > PREEMPT Fri Nov 9 20:41:37 CST 2007 > kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive > kernel: hdd: ATAPI 126X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, > UDMA(66) > > The drive seems to work correctly, reading and writing just fine. I just > happened to notice this and thought I'd pass it along. > > One other odd thing while looking through the logs, 2.6.23.1 has also > reported the drive as follows: > > Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT > Fri Oct 26 13:09:09 CDT 2007 > kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive > kernel: hdd: ATAPI 32X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, > UDMA(66) > > Any idea what is going on here? It's being reported as 48X, 126X, and 32X. > - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
