Re: [PATCH 3/3] IDE: Coding Style fixes to drivers/ide/pci/cy82c693.c
On Mon, Feb 25, 2008 at 8:31 AM, Ingo Molnar [EMAIL PROTECTED] wrote: * Paolo Ciarrocchi [EMAIL PROTECTED] wrote: Before: total: 34 errors, 14 warnings, 456 lines checked After: total: 0 errors, 8 warnings, 456 lines checked sidenote: please also indicate to maintainers that the cleanup causes no change in generated code. Find below of how one of your cleanup patches looks like in its final form in x86.git. (i auto-generated all of the commit log) info like that makes it easier for maintainers to see the intended zero impact of your changes. Sure, I'll script that. Ciao, -- Paolo http://paolo.ciarrocchi.googlepages.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
[ugly patch] Save .15W-.5W by AHCI powersaving
Hi!
This is a patch (very ugly, assumes you have just one disk) to bring
powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch
as a base.
It saves .5W compared to config with disk spinning, and even .15W
compared to hdparm -y... on my thinkpad x60 anyway.
It is also mandatory first step towards sleepy linux ;-).
Pavel
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 29e71bd..0197b1f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -259,8 +260,8 @@ static void ahci_fill_cmd_slot(struct ah
u32 opts);
#ifdef CONFIG_PM
static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg);
-static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
-static int ahci_pci_device_resume(struct pci_dev *pdev);
+int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
+int ahci_pci_device_resume(struct pci_dev *pdev);
#endif
static struct class_device_attribute *ahci_shost_attrs[] = {
@@ -268,6 +269,35 @@ static struct class_device_attribute *ah
NULL
};
+struct pci_dev *my_pdev;
+int autosuspend_enabled;
+
+/* The host and its devices are all idle so we can autosuspend */
+static int autosuspend(struct Scsi_Host *host)
+{
+ if (my_pdev autosuspend_enabled) {
+ printk(ahci: should autosuspend\n);
+ ahci_pci_device_suspend(my_pdev, PMSG_SUSPEND);
+ return 0;
+ }
+ printk(ahci: autosuspend disabled\n);
+ return -EINVAL;
+}
+
+/* The host needs to be autoresumed */
+static int autoresume(struct Scsi_Host *host)
+{
+ if (my_pdev autosuspend_enabled) {
+ printk(ahci: should autoresume\n);
+ ahci_pci_device_resume(my_pdev);
+ return 0;
+ }
+ printk(ahci: autoresume disabled\n);
+ return -EINVAL;
+}
+
+
+
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -286,6 +322,8 @@ static struct scsi_host_template ahci_sh
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
.shost_attrs= ahci_shost_attrs,
+ .autosuspend= autosuspend,
+ .autoresume = autoresume,
};
static const struct ata_port_operations ahci_ops = {
@@ -2300,8 +2356,12 @@ static int ahci_init_one(struct pci_dev
ahci_print_info(host);
pci_set_master(pdev);
- return ata_host_activate(host, pdev-irq, ahci_interrupt, IRQF_SHARED,
+
+ rc = ata_host_activate(host, pdev-irq, ahci_interrupt, IRQF_SHARED,
ahci_sht);
+ pci_save_state(pdev);
+ my_pdev = pdev;
+ return rc;
}
static int __init ahci_init(void)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 4e31071..5c40ac2 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -380,7 +381,7 @@ enum scsi_eh_timer_return ata_scsi_timed
* Inherited from SCSI layer (none, can sleep)
*
* RETURNS:
- * Zero.
+ * Nothing.
*/
void ata_scsi_error(struct Scsi_Host *host)
{
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c838e65..0edc25e 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -484,6 +484,8 @@ static int scsi_try_host_reset(struct sc
if (scsi_autoresume_host(shost) != 0)
return FAILED;
+ rtn = shost-hostt-eh_host_reset_handler(scmd);
+
if (rtn == SUCCESS) {
if (!shost-hostt-skip_settle_delay)
ssleep(HOST_RESET_SETTLE_TIME);
@@ -1577,7 +1579,11 @@ int scsi_error_handler(void *data)
* what we need to do to get it up and online again (if we can).
* If we fail, we end up taking the thing offline.
*/
+#if 0
+ /* libata uses scsi_error_handler to suspend its parts; we
deadlock
+ if we try to autoresume here */
autoresume_rc = scsi_autoresume_host(shost);
+#endif
if (shost-transportt-eh_strategy_handler)
shost-transportt-eh_strategy_handler(shost);
else
@@ -1591,8 +1597,10 @@ int scsi_error_handler(void *data)
* which are still online.
*/
scsi_restart_operations(shost);
+#if 0
if (autoresume_rc == 0)
scsi_autosuspend_host(shost);
+#endif
set_current_state(TASK_INTERRUPTIBLE);
}
__set_current_state(TASK_RUNNING);
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 233feee..3c598e0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -67,6 +67,8 @@ #undef SP
static struct kmem_cache *scsi_bidi_sdb_cache;
+void scsi_run_queue(struct
Re: IDE cdrom problem with PLEXTOR DVDR PX-608AL
On Mon, Feb 25, 2008 at 03:57:06PM +1000, Brad Rosser wrote: Hi Boris, Well, this sounds strange. Are you sure you're entering the boot options correctly on the kernel command line? Which is your boot loader? I just booted my machine with 'hdc=noprobe' (hdc is my cdrom drive) and here's what i get: ... [0.304774] Probing IDE interface ide0... [0.569359] hdb: SAMSUNG SP2014N, ATA DISK drive [0.613977] Switched to NOHz mode on CPU #1 [0.773368] Switched to NOHz mode on CPU #0 [0.874486] hda: QUANTUM FIREBALLlct10 20, ATA DISK drive [0.874506] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 [0.874506] hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33 [0.874506] hda: UDMA/33 mode selected [0.874533] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4 [0.874620] hdb: UDMA/100 mode selected [0.874744] Probing IDE interface ide1... so it seems you should check whether your kernel is receiving the 'hda=noprobe' boot option at all, or something along that path is going wrong... I'm entering the option 'hda=noprobe' (as one example) right after my boot label in LILO. The dmesg output I attached last time was a boot of straight 2.6.25-rc2 without any options; I've attached 'dmesg.noprobe.out' which is the result of a boot with 'hda=noprobe'. I must have done something stupid, but I can't see what; if you look at this line from the dmesg output: Kernel command line: BOOT_IMAGE=linux_2.6.25rc2 ro root=900 md=0,/dev/sda5,/dev/sdb5 hda=noprobe ... it would suggest the option 'hda=noprobe' was entered correctly? ok, let's try something else: change the line #if 0 to #if 1 at the beginning of kernel/params.c, it looks like: #if 0 #define DEBUGP printk #else #define DEBUGP(fmt, a...) #endif rebuild your kernel, and reboot with it. Then, please send me that boot log to see whether the kernel command line is being received from the boot loader and what exactly is getting parsed. Thanks. I tried to apply the patch but failed; I probably did something wrong. I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c' and ran 'patch --dry-run -b -p1 ../bart_patch'. This is part of my script log: are you sure you're _really_ using 2.6.25-rc2? Applying the patch against that kernel works just fine, no fuzziness or even rejects. Care to try out on a fresh kernel source tarball? After all, building a kernel with your quad core cpu won't take that long :-) when using make -j8 or something in that order. Heh. This is my first new machine in 8 years, and I couldn't wait to start using multiple cores. I was quick to discover the '-j' option ... but I only do '-j 4'. Anyway ... I'd downloaded the full baseline linux-2.6.24.tar.bz2, unpacked it, and then ran the patch patch-2.6.25-rc2.bz2 against it. That patch ran perfectly. And I was in the right directory when I ran Bart's patch, as I listed in my earlier e-mail! All indications were that I was running the 2.6.25-rc2 kernel as required, I thought. Well, I see that rc3 is out; maybe I'll give that a shot. Please see whether you can apply the patch Bart just sent and if that still gets mangled and cannot be applied, consider making those changes to ide-cd.c by hand - after all, there are only several lines that need to be changed so it won't take that long. Thanks. -- Regards/Gruß, Boris. - 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: Need help with libata error handling in libsas
James Bottomley wrote: I keep hearing that we need to convert libsas to use libata's new error handling. Unfortunately, I have very little conception of what that means. Right at the moment, libsas doesn't use any error handling functions of libata at all. I've looked through the libata-eh functions, and I find them frankly incomprehensible. Firstly, let me say what SAS error handling actually does: Let me chime in with what ipr error handling does/can do. The ipr firmware provides two basic SATA error handling methods with some modifiers to each. Cancel All - This cancels all outstanding commands to the device. When issued to an ATA device, this gets escalated by the firmware to an SRST. When issued to an ATAPI device, an ATA NOOP is issued. Reset Device - This command has modifiers to indicate either a soft reset or a hard reset. Currently, the only SATA devices that ipr officially attaches are ATAPI DVD devices. In our testing we've come to the conclusion that trying to use anything but a hard reset for ERP is generally more trouble than it is worth. All of this leads me to conclude, that all libsas needs is to plumb in the ATA equivalent of abort, junk the task query for libata devices and simply proceed, as if the task is held at the target, along the escalating reset path. The new libata-eh is used for more than just EH. It is used for device probing, device revalidation, and power management. It is also woken for all command failures and is where the request sense for ATAPI devices is issued. Device revalidation following reset is also critical for ATA and ATAPI devices. One example of this is some SATA/PATA converter chips lose their DMA xfer settings following a reset and default to PIO mode only. Any DMA transfer that is attempted simply hangs. The other issue is PMP support. The more that gets pushed into libsas, the more libsas needs to know about things such as PMP. -Brian -- Brian King Linux on Power Virtualization IBM Linux Technology Center - 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: new ata_port_operations for .pmp_{read,write} ?
Tejun Heo wrote: Mark Lord wrote: .. But no big deal. I can clone code and not bother you any more. In fact, some of the cloned code was already in sata_mv, and I removed it this past week in my local working copy. I'll just restore that, along with another big blob so that we can select pm port where needed. What a shame. The order is somewhat reversed here and I can understand why you're frustrated but I'm just trying to make things look right in long term, so feel free to bother me. :-) For temporary solution, I'm okay either way. I'll clean things up later when the necessary core changes are made. .. MMmm.. maybe the vendor unique FIS mechanism of the chipset can save the scenario here. It would seem to be a reasonable way to direct a FIS (anything up to 8KB) at a specific pmp, without changing the default pmp on the channel. I can have qc_issue use that mechanism for anything destined for pmp==15. If it works. The Marvell proprietary driver has some kludgey status polling wrapped around their own use of it. One of the chip errata apparently requires this anyway for doing the READ_LOG_EXT commands after a device error, so perhaps it will work out to be useful in more ways. Speaking of which.. I would like to sort out the freeze stuff, so that the sata_mv EH doesn't lock out the PMP commands as it does today. Can you recap what a LLD should be doing in the presence of a PM for EH purposes? Eg. media error on a PMP drive, so what core ATA functions should the sata_mv EH interrupt handler be calling, and in what sequence.. so that the libata-pmp/eh code can still succeed in it's queries to the PM? I think James is also interested in a decent explanation of how to tie into the libata-eh stuff. Like I noted before, sata_mv will need to eventually hard reset the channel regardless, but it does seem permitted to use PIO or vendor-unique-FIS PIO (with polling for either) in the interim. 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: Need help with libata error handling in libsas
On Mon, 2008-02-25 at 10:34 -0600, Brian King wrote: The new libata-eh is used for more than just EH. It is used for device probing, device revalidation, and power management. It is also woken for all command failures and is where the request sense for ATAPI devices is issued. Device revalidation following reset is also critical for ATA and ATAPI devices. One example of this is some SATA/PATA converter chips lose their DMA xfer settings following a reset and default to PIO mode only. Any DMA transfer that is attempted simply hangs. OK ... I'm grepping around in the source trying to figure out all of this. Is it documented anywhere? That would really help me out at the moment. James - 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: Need help with libata error handling in libsas
James Bottomley wrote: On Mon, 2008-02-25 at 10:34 -0600, Brian King wrote: The new libata-eh is used for more than just EH. It is used for device probing, device revalidation, and power management. It is also woken for all command failures and is where the request sense for ATAPI devices is issued. Device revalidation following reset is also critical for ATA and ATAPI devices. One example of this is some SATA/PATA converter chips lose their DMA xfer settings following a reset and default to PIO mode only. Any DMA transfer that is attempted simply hangs. Strongly seconded. Doing your own ATA EH would be foolish, as that would imply duplicating all that carefully-time-tested logic handling devices which follow the ATA specs... about 98% of the time :) Just the set-transfer-mode logic took years to get right for the majority of ATA devices. OK ... I'm grepping around in the source trying to figure out all of this. Is it documented anywhere? That would really help me out at the moment. Unfortunately, not really. The simplistic version is... freeze, set some flags, call a function to schedule EH as needed -- most notably when your HBA signals an ATA device error or some other error in the ATA domain. Regardless of all this... libsas IMO will cause some libata-EH growing pains. libsas needs libata-EH for probing, revalidation, initialization, etc. But libsas probably does NOT need libata-EH for certain duties like SATA PHY diagnosis and link handling. libsas needs libata-EH. Unfortunately for libsas, libata-EH was written from the libata controls the world point of view, and probably needs some modifications to play well in the new SATA/SAS shared worldview. Brian's recommendation is quite sane... your -error_handler() probably just needs hard reset (aka COMRESET) capability. 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
Old errata docs
Does anyone have in their posession the old errata docs for the HPT370 controller. I'm seeing two reports now where there is some kind of FIFO corruption pattern (shifted data and duplicated dwords) on the drives which are UDMA100 blacklisted, so presumably more is required for the workaround. Alan - 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 4/6] IDE: Coding Style fixes to drivers/ide/pci/it8213.c
Paolo Ciarrocchi wrote: File is now error free, only a few WARNING: line over 80 characters are left. Compile tested. Signed-off-by: Paolo Ciarrocchi [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
new regression in 2.6.25-rc3: can't resume from suspend to ram, ata1 errors
On my T61p, 2.6.25-rc2 seems to wake up fine from suspend to ram. Not so 2.6.25-rc3: it hangs on suspend to ram, with a blank screen. At one point I got lucky and got this on console (wrote down by hand, there could be typos): ata1: COMRESET failed (errno=-16) ata1: COMRESET failed (errno=-16) end_request: I/O error, dev sda sector 200554 Buffer I/O error on device dm-0, logical block 256 Buffer I/O error on device dm-0, logical block 15695875 Buffer I/O error on device dm-0, logical block 15695878 Buffer I/O error on device dm-0, logical block 15695887 Buffer I/O error on device dm-0, logical block 15695896 Buffer I/O error on device dm-0, logical block 15695914 Buffer I/O error on device dm-0, logical block 15958028 Buffer I/O error on device dm-0, logical block 22118530 Buffer I/O error on device dm-0, logical block 22315068 Buffer I/O error on device dm-0, logical block 22347824 git bisect points at this commit: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2. power_state: get rid of write-only variable in SATA After reverting 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 on top of 2.6.25-rc3 the kernel again resumes from suspend to ram. - 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: new regression in 2.6.25-rc3: can't resume from suspend to ram, ata1 errors
On Monday, 25 of February 2008, Michael S. Tsirkin wrote: On my T61p, 2.6.25-rc2 seems to wake up fine from suspend to ram. Not so 2.6.25-rc3: it hangs on suspend to ram, with a blank screen. Thanks for the report. At one point I got lucky and got this on console (wrote down by hand, there could be typos): ata1: COMRESET failed (errno=-16) ata1: COMRESET failed (errno=-16) end_request: I/O error, dev sda sector 200554 Buffer I/O error on device dm-0, logical block 256 Buffer I/O error on device dm-0, logical block 15695875 Buffer I/O error on device dm-0, logical block 15695878 Buffer I/O error on device dm-0, logical block 15695887 Buffer I/O error on device dm-0, logical block 15695896 Buffer I/O error on device dm-0, logical block 15695914 Buffer I/O error on device dm-0, logical block 15958028 Buffer I/O error on device dm-0, logical block 22118530 Buffer I/O error on device dm-0, logical block 22315068 Buffer I/O error on device dm-0, logical block 22347824 git bisect points at this commit: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2. power_state: get rid of write-only variable in SATA Jeff, could you revert it, please? Thanks, Rafael - 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: new regression in 2.6.25-rc3: can't resume from suspend to ram, ata1 errors
Michael S. Tsirkin wrote: git bisect points at this commit: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2. power_state: get rid of write-only variable in SATA Hello Pavel -- It looks like this not a write-only variable after 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: new regression in 2.6.25-rc3: can't resume from suspend to ram, ata1 errors
On Monday 25 February 2008, Rafael J. Wysocki wrote: On Monday, 25 of February 2008, Michael S. Tsirkin wrote: On my T61p, 2.6.25-rc2 seems to wake up fine from suspend to ram. Not so 2.6.25-rc3: it hangs on suspend to ram, with a blank screen. Thanks for the report. At one point I got lucky and got this on console (wrote down by hand, there could be typos): ata1: COMRESET failed (errno=-16) ata1: COMRESET failed (errno=-16) end_request: I/O error, dev sda sector 200554 Buffer I/O error on device dm-0, logical block 256 Buffer I/O error on device dm-0, logical block 15695875 Buffer I/O error on device dm-0, logical block 15695878 Buffer I/O error on device dm-0, logical block 15695887 Buffer I/O error on device dm-0, logical block 15695896 Buffer I/O error on device dm-0, logical block 15695914 Buffer I/O error on device dm-0, logical block 15958028 Buffer I/O error on device dm-0, logical block 22118530 Buffer I/O error on device dm-0, logical block 22315068 Buffer I/O error on device dm-0, logical block 22347824 git bisect points at this commit: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2. power_state: get rid of write-only variable in SATA Jeff, could you revert it, please? Jeff, this was applied between -rc2 and -rc3. 100% cleanup patches which change behavior are potentialy risky and shouldn't be considered as a -rc material. 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: Old errata docs
Alan Cox wrote: Does anyone have in their posession the old errata docs for the HPT370 controller. I'm seeing two reports now where there is some kind of FIFO corruption pattern (shifted data and duplicated dwords) on the drives which are UDMA100 blacklisted, so presumably more is required for the workaround. .. Nothing here. Highpoint was Andre's territory. :| -ml - 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: [ugly patch] Save .15W-.5W by AHCI powersaving
Pavel Machek wrote: Hi! This is a patch (very ugly, assumes you have just one disk) to bring powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch as a base. It saves .5W compared to config with disk spinning, and even .15W compared to hdparm -y... on my thinkpad x60 anyway. .. There was a discussion of this here today. It makes good use of AHCI-specific features. Has it been tested with a Port-Multiplier yet? This is cool enough that we really ought to do a hardware-independent version, so that all SATA interfaces could benefit. Especially ata_piix, but others too. 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: [ugly patch] Save .15W-.5W by AHCI powersaving
Hi! This is a patch (very ugly, assumes you have just one disk) to bring powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch as a base. It saves .5W compared to config with disk spinning, and even .15W compared to hdparm -y... on my thinkpad x60 anyway. .. There was a discussion of this here today. Real-life discussion, or something I could read? :-). It makes good use of AHCI-specific features. Has it been tested with a Port-Multiplier yet? I do not know what port-multiplier is, sorry. But it was not really tested. It is not expected to work on any other config than notebook very similar to mine. This is cool enough that we really ought to do a hardware-independent version, so that all SATA interfaces could benefit. Especially ata_piix, but others too. Well, it seems like it is 10 lines per driver once Alan's SCSI autosuspend patches are in... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: new regression in 2.6.25-rc3: can't resume from suspend to ram, ata1 errors
On Mon 2008-02-25 16:04:08, Jeff Garzik wrote: Michael S. Tsirkin wrote: git bisect points at this commit: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2. power_state: get rid of write-only variable in SATA Hello Pavel -- It looks like this not a write-only variable after all... Yep, right and sorry. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[git patches] libata updates
(additional explanation for the revert is in the full changeset
description)
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c |5 -
drivers/ata/libata.h |1 -
2 files changed, 4 insertions(+), 2 deletions(-)
Adrian Bunk (1):
make atapi_dmadir static
Jeff Garzik (1):
Revert power_state: get rid of write-only variable in SATA
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index fbc2435..4fbcce7 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -113,7 +113,7 @@ int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
MODULE_PARM_DESC(atapi_enabled, Enable discovery of ATAPI devices (0=off,
1=on));
-int atapi_dmadir = 0;
+static int atapi_dmadir = 0;
module_param(atapi_dmadir, int, 0444);
MODULE_PARM_DESC(atapi_dmadir, Enable ATAPI DMADIR bridge support (0=off,
1=on));
@@ -6567,6 +6567,8 @@ int ata_host_suspend(struct ata_host *host, pm_message_t
mesg)
ata_lpm_enable(host);
rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
+ if (rc == 0)
+ host-dev-power.power_state = mesg;
return rc;
}
@@ -6585,6 +6587,7 @@ void ata_host_resume(struct ata_host *host)
{
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
+ host-dev-power.power_state = PMSG_ON;
/* reenable link pm */
ata_lpm_disable(host);
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 6036ded..aa884f7 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -56,7 +56,6 @@ enum {
extern unsigned int ata_print_id;
extern struct workqueue_struct *ata_aux_wq;
extern int atapi_enabled;
-extern int atapi_dmadir;
extern int atapi_passthru16;
extern int libata_fua;
extern int libata_noacpi;
-
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: [ugly patch] Save .15W-.5W by AHCI powersaving
Mark Lord wrote: Pavel Machek wrote: This is a patch (very ugly, assumes you have just one disk) to bring powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch as a base. It saves .5W compared to config with disk spinning, and even .15W compared to hdparm -y... on my thinkpad x60 anyway. .. There was a discussion of this here today. It makes good use of AHCI-specific features. Has it been tested with a Port-Multiplier yet? This is cool enough that we really ought to do a hardware-independent version, so that all SATA interfaces could benefit. Especially ata_piix, but others too. BTW we can also save power by allowing the user to choose to disable hotplugging support. Then we can power down PHYs that are not in use. That requires the addition of some policy controls, because it is user-specific whether or not to waste power waiting for a plug-in event. 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: achi.c bug ?
chaoyang wang wrote: Dear Jeff, I was looking at the kernel 2.6.21 code of the achi driver and found that the sg_table_size was set to 168, while the libata set the maximum sg to be 128 somewhere else. When a requester issues a request with 128 sgs to the ahci attached device, the system would fall to a scilent error. So, I could not count on the scsi probe of scsi_device--host-sg_tablesize that was read from achi. Any advise on the better fix? Thanks you very much, Can you be more specific about somewhere else? Reducing s/g table size should be quite safe. 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: ULI 5288(SATA driver)
Saumendra Dash wrote: Hi Jeff, I'm working on ULI1575 SATA driver which I want to run in Emulated-PATA mode. I have the following understanding to run a SATA device in Emulated-PATA mode: 1. In Emulated-PATA mode the legacy IDE driver should access the SATA device directly in combined mode. 2. The class code of the device shlould be set to Emulated-PATA mode(0x0185). 3. Enable SATA in combine mode. After doing the above changes the driver does not work in Emulated-PATA mode. Is there something missing to make the driver work in Emulated-PATA mode? Use a PCI quirk to unconditionally disable emulated PATA mode, because it's not needed. 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: extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2
On Mon, 25 Feb 2008 20:05:22 +0100 Gerold Jury [EMAIL PROTECTED] wrote: Hello, I have two DVD drives, one connected to the SATA port (LG) the other to the IDE port (PHILIPS) of a via chipset. They are driven by VIA SATA support (SATA_VIA) and VIA PATA support (PATA_VIA). When I write an iso image to the drive on the SATA port /dev/sr0 it has some extra bytes on disk which make the disk unreadable. Writing to the IDE drive /dev/sr1 works well. A simple test with a DVD RAM and dd instead of growisofs dd if=/dev/zero of=/dev/srX bs=1024k count=10 and a readback afterwards dd if=/dev/srX of=imageX.bin bs=1024k count=10 gives me an all zero file from the IDE drive but a file full of probably scsi commands for the SATA drive and looks like 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0002 2a 00 00 00 00 40 00 00 40 00 00 00 00 40 00 00 |[EMAIL PROTECTED]@[EMAIL PROTECTED]| 00020010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0004 2a 00 00 00 00 80 00 00 40 00 00 00 00 80 00 00 |[EMAIL PROTECTED]| 00040010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0006 2a 00 00 00 00 c0 00 00 02 00 00 00 00 c0 00 00 |*...| 00060010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00061010 00 00 00 00 00 00 00 00 2a 00 00 00 00 c2 00 00 |*...| 00061020 40 00 00 00 00 c2 00 00 00 00 00 00 00 00 00 00 |@...| 00061030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00081010 00 00 00 00 00 00 00 00 2a 00 00 00 01 02 00 00 |*...| 00081020 40 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 |@...| 00081030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000a1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 42 00 00 |*B..| 000a1020 40 00 00 00 01 42 00 00 00 00 00 00 00 00 00 00 |@B..| 000a1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000c1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 82 00 00 |*...| 000c1020 40 00 00 00 01 82 00 00 00 00 00 00 00 00 00 00 |@...| 000c1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || I really need some hints to make the SATA drive usable, please. (added linux-ide) Did any earlier kernel work OK? 2.6.22? Thanks. uname -a Linux blaubaer 2.6.24.2 #4 Sun Feb 24 21:50:21 CET 2008 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux lspvi -v 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Subsystem: ASUSTeK Computer Inc. A7V600/K8V Deluxe/K8V-X/A8V Deluxe motherboard Flags: bus master, medium devsel, latency 64, IRQ 20 I/O ports at e800 [size=8] I/O ports at e400 [size=4] I/O ports at e000 [size=8] I/O ports at d800 [size=4] I/O ports at d400 [size=16] I/O ports at d000 [size=256] Capabilities: [c0] Power Management version 2 Kernel driver in use: sata_via 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X/A8V Deluxe motherboard Flags: bus master, medium devsel, latency 32, IRQ 20 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] I/O ports at fc00 [size=16] Capabilities: [c0] Power Management version 2 Kernel driver in use: pata_via cat /var/log/messages Feb 25 18:20:57 blaubaer sata_via :00:0f.0: version 2.3 Feb 25 18:20:57 blaubaer ACPI: PCI Interrupt :00:0f.0[B] - GSI 20 (level, low) - IRQ 20 Feb 25 18:20:57 blaubaer sata_via :00:0f.0: routed to hard irq line 10 Feb 25 18:20:57 blaubaer scsi3 : sata_via Feb 25 18:20:57 blaubaer scsi4 : sata_via Feb 25 18:20:57 blaubaer ata4: SATA max UDMA/133 cmd 0xe800 ctl 0xe400 bmdma 0xd400 irq 20 Feb 25 18:20:57 blaubaer ata5: SATA max UDMA/133 cmd 0xe000 ctl 0xd800 bmdma 0xd408 irq 20 Feb 25 18:20:57 blaubaer ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 300) Feb 25 18:20:57 blaubaer ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Feb 25 18:20:57 blaubaer ata5.00: ATAPI: HL-DT-ST DVDRAM GH20NS10, EL00, max UDMA/100 Feb 25 18:20:57 blaubaer ata5.00: configured for UDMA/100 Feb 25 18:20:57 blaubaer scsi 4:0:0:0: CD-ROMHL-DT-ST DVDRAM GH20NS10 EL00 PQ: 0 ANSI: 5 Feb 25 18:20:57 blaubaer sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Feb 25 18:20:57 blaubaer Uniform
Re: Sata-MV, Intergated Sata Device Support
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined below.
In the original mvSata.c (ver3.4) that has 0x5182 support, the config
space is as such:
case MV_SATA_DEVICE_ID_5182:
pAdapter-numberOfChannels = MV_SATA_5182_PORT_NUM;
pAdapter-numberOfUnits = 1;
pAdapter-portsPerUnit = 2;
pAdapter-sataAdapterGeneration = MV_SATA_GEN_IIE;
/*The integrated sata core chip based on 60x1 C0*/
pAdapter-chipIs60X1C0 = MV_TRUE;
pAdapter-hostInterface = MV_HOST_IF_INTEGRATED;
pAdapter-mainMaskOffset = 0x20024; /*the iobaseaddress is
0x6*/
pAdapter-mainCauseOffset = 0x20020;
break;
I have not yet figured out how all these values are defined in sata-mv.c
(ver 0.8). Specifically, where do I define numberOfChannels which
should equal 2, and numberOfUnits which obviously equals 1?
I have a current config space (not completed) for sata-mv.c which is:
{ /* chip_5182 */
.sht= mv_sht,
.flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
MV_FLAG_DUAL_HC),
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = 0x7f, /* udma0-6 */
.port_ops = mv6_ops,
},
I believe according to the new structure in sata-mv.c,
HC_MAIN_IRQ_CAUSE_OFS should equal 0x20020 and HC_MAIN_IRQ_MASK_OFS
should equal 0x20024 for the 0x5182 device.
My final question is how to implement the MV_HOST_IF_INTEGRATED flag?
Is this already implemented and renamed in sata-mv.c? Or do I need to
also add the routines?
I just wanted to point the current sata_mv hackers to this message from
April 2007...
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: new ata_port_operations for .pmp_{read,write} ?
Hello, Mark. Mark Lord wrote: MMmm.. maybe the vendor unique FIS mechanism of the chipset can save the scenario here. It would seem to be a reasonable way to direct a FIS (anything up to 8KB) at a specific pmp, without changing the default pmp on the channel. I can have qc_issue use that mechanism for anything destined for pmp==15. If it works. The Marvell proprietary driver has some kludgey status polling wrapped around their own use of it. One of the chip errata apparently requires this anyway for doing the READ_LOG_EXT commands after a device error, so perhaps it will work out to be useful in more ways. Hmmm... Speaking of which.. I would like to sort out the freeze stuff, so that the sata_mv EH doesn't lock out the PMP commands as it does today. Can you recap what a LLD should be doing in the presence of a PM for EH purposes? Eg. media error on a PMP drive, so what core ATA functions should the sata_mv EH interrupt handler be calling, and in what sequence.. so that the libata-pmp/eh code can still succeed in it's queries to the PM? libata doesn't really put much restrictions on what a LLD should do on entering EH and if the controller's behavior is predictable, there's no reason to freeze the port. If the problem is that the DMA engine isn't usable after PMP error but it's known that the controller isn't gonna cause irq storm, no need to freeze. The only command EH issues before resetting which can use DMA protocol is READ_LOG_EXT. Maybe there needs to be a way to force PIO protocol for READ_LOG_EXT. Other than that, if no-data and PIO-only commands work fine, EH autopsy should work fine. Like I noted before, sata_mv will need to eventually hard reset the channel regardless, but it does seem permitted to use PIO or vendor-unique-FIS PIO (with polling for either) in the interim. Just set ATA_EH_HARDRESET (which will soon become ATA_EH_RESET with prefer-COMRESET patchset) from the interrupt handler before requesting EH. 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
[RFC] Disk shock protection (revisited)
Hi all, at the moment I'm having another go at trying to make the disk shock protection patch fit for upstream submission. However, there are still some fundamental issues I'd like to discuss in order to make sure that I'm heading in the right direction. The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. This project is (and I personally am) mainly concerned with laptops equipped with an accelerometer and an (S)ATA hard drive that supports the unload feature of the idle immediate command. Jens Axboe, however, suggested right from the beginning that there might be more general applications for the block layer queue freezing part of the story. The question is now to what extent are the requirements for a disk shock protection facility (specific to ATA devices) and a general block layer queue freezing facility compatible and in what way should they be exposed to user space. Probably, the major problem is that I don't really know what kind of applications (apart from shock protection) I should be thinking of that might want to have a queue freezing facility at hand. Still, one thing seems obvious to me: For disk shock protection, time is of the essence, whereas in the more general case of simple block layer queue freezing, the situation is different as far as lower levels are concerned. In particular, I'm inclined to believe that in the context of such a general application it would be desirable to be able to freeze the queue of an ATA device *without* issuing an idle immediate command first. Obviously, the interface exposed to userspace would have to provide for these diverging needs. The disk-protect patch in it's current form [1] got stuck somewhere between trying to provide a general queue freezing facility and accommodating the needs of a disk shock protection setup. The sysfs attributes required to request immediate disk parking from user space are exported under /sys/block/. This is very convenient from the user's point of view because the hierarchy is intuitive and you can easily find the subdirectory associated to your hard disk. Conceptually, though, it doesn't feel right. That is, for simple queue freezing, it is perfectly alright, of course, but I don't see why and, indeed, how an ATA specific feature like immediate disk parking could be controlled from the block layer in a straight forward way. Besides, Jens, quite understandably, objects to the introduction of yet another queue hook which is the current way of telling ATA and non-ATA devices apart. Instead, he suggests to implement generic block layer notification requests like REQ_LB_OP_FREEZE of type REQ_TYPE_LINUX_BLOCK and let low level drivers act upon it as they see fit. But then we would still need a way to configure the way libata / ide actuaaly does respond to those block layer messages. As explained above, the user might want to choose whether or idle immediate is to be issued or simple queue freezing is enough for his / her purposes. Besides, some drives that actually support the unload feature of the idle immediate command don't report that capability in the IDENTIFY data, so userspace needs a way to tell the driver that the feature is available after all. So, roughly my questions are these: 1. Who is to be in charge for the shock protection application? Should userspace speak to libata / ide directly (through sysfs) and the low level drivers will notify block layer to stop the queeue or should userspace always talk to the block layer, regardless whether we want to park an ATA disk or just freeze the queue? In the latter case we'd still need the option to configure the exact behaviour for ATA devices. 2. Depending on the answer to the previous question, by what mechanism should block layer and lld interact? Special requests, queue hooks or something in some way similar to power management functions (once suggested by James Bottomley)? 3. What is the preferred way to pass device specific configuration options to libata (preferrably at runtime, i.e., after module loading)? Please let me know if you need any further information. Also, I will certainly have more questions once I try to my hand at any of your suggestions. Thanks in advance, Elias [1] http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1094 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at
libata .sg_tablesize: why always dividing by 2 ?
Jeff, We had a discussion here today about IOMMUs, and they *never* split sg list entries -- they only ever *merge*. And this happens only after the block layer has already done merging while respecting q-seg_boundary_mask. So worst case, the IOMMU may merge everything, and then in libata we unmerge them again. But the end result can never exceed the max_sg_entries limit enforced by the block layer. So.. why are we still specifying .sg_tablesize as half of what the LLD can really handle? This can cost a lot of memory, as using NCQ effectively multiplies everything by 32.. Based on this information, I should be able to do this in sata_mv, for example: - .sg_tablesize = MV_MAX_SG_CT / 2, + .sg_tablesize = MV_MAX_SG_CT, ??? - 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] Disk shock protection (revisited)
Elias Oltmanns wrote: The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. Speaking specifically to that problem, it seems to me that you either want an mlock'd daemon, or just simply to keep everything in the kernel, for this specific solution. You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. 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: Sata-MV, Intergated Sata Device Support
Jeff Garzik wrote:
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined below.
In the original mvSata.c (ver3.4) that has 0x5182 support, the config
space is as such:
case MV_SATA_DEVICE_ID_5182:
pAdapter-numberOfChannels = MV_SATA_5182_PORT_NUM;
pAdapter-numberOfUnits = 1;
pAdapter-portsPerUnit = 2;
pAdapter-sataAdapterGeneration = MV_SATA_GEN_IIE;
/*The integrated sata core chip based on 60x1 C0*/
pAdapter-chipIs60X1C0 = MV_TRUE;
pAdapter-hostInterface = MV_HOST_IF_INTEGRATED;
pAdapter-mainMaskOffset = 0x20024; /*the iobaseaddress is
0x6*/
pAdapter-mainCauseOffset = 0x20020;
break;
I have not yet figured out how all these values are defined in sata-mv.c
(ver 0.8). Specifically, where do I define numberOfChannels which
should equal 2, and numberOfUnits which obviously equals 1?
I have a current config space (not completed) for sata-mv.c which is:
{ /* chip_5182 */
.sht= mv_sht,
.flags= (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
MV_FLAG_DUAL_HC),
.pio_mask= 0x1f,/* pio0-4 */
.udma_mask= 0x7f,/* udma0-6 */
.port_ops= mv6_ops,
},
...
Saeed: isn't this what your SOC patches already implemented for us?
As near as I can tell, sata_mv now already has support for the 60x1C0.
-ml
-
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: new ata_port_operations for .pmp_{read,write} ?
Tejun Heo wrote: libata doesn't really put much restrictions on what a LLD should do on entering EH and if the controller's behavior is predictable, there's no reason to freeze the port. If the problem is that the DMA engine isn't usable after PMP error but it's known that the controller isn't gonna cause irq storm, no need to freeze. The only command EH issues before resetting which can use DMA protocol is READ_LOG_EXT. Maybe there needs to be a way to force PIO protocol for READ_LOG_EXT. Other than that, if no-data and PIO-only commands work fine, EH autopsy should work fine. .. Eh? READ LOG EXT *is* a PIO command, as opposed to READ LOG DMA EXT which uses DMA. And the EH also issues PIO READ_BUFFER commands for PM ports, if a PM is present. ??? - 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
[Bug 10086] 2.6.25-rc2 + smartd = hang
http://bugzilla.kernel.org/show_bug.cgi?id=10086 --- Comment #1 from [EMAIL PROTECTED] 2008-02-24 17:12 --- Handled-By : Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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-MV, Intergated Sata Device Support
Mark Lord wrote:
Jeff Garzik wrote:
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined below.
In the original mvSata.c (ver3.4) that has 0x5182 support, the config
space is as such:
case MV_SATA_DEVICE_ID_5182:
pAdapter-numberOfChannels = MV_SATA_5182_PORT_NUM;
pAdapter-numberOfUnits = 1;
pAdapter-portsPerUnit = 2;
pAdapter-sataAdapterGeneration = MV_SATA_GEN_IIE;
/*The integrated sata core chip based on 60x1 C0*/
pAdapter-chipIs60X1C0 = MV_TRUE;
pAdapter-hostInterface = MV_HOST_IF_INTEGRATED;
pAdapter-mainMaskOffset = 0x20024; /*the iobaseaddress is
0x6*/
pAdapter-mainCauseOffset = 0x20020;
break;
I have not yet figured out how all these values are defined in sata-mv.c
(ver 0.8). Specifically, where do I define numberOfChannels which
should equal 2, and numberOfUnits which obviously equals 1?
I have a current config space (not completed) for sata-mv.c which is:
{ /* chip_5182 */
.sht= mv_sht,
.flags= (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
MV_FLAG_DUAL_HC),
.pio_mask= 0x1f,/* pio0-4 */
.udma_mask= 0x7f,/* udma0-6 */
.port_ops= mv6_ops,
},
...
Saeed: isn't this what your SOC patches already implemented for us?
As near as I can tell, sata_mv now already has support for the 60x1C0.
Saeed's stuff didn't support PCI though, and Jon Li is definitely
talking about PCI...
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
ops-qc_defer not invoked on ata_exec_internal_sg() paths ?
The optional .qc_defer() methods don't seem to be called on the ata_exec_internal_sg() path. At present, this is probably okay. But in the future, as we add functionality for link power management and hotplug polling, this could be a problem. I think. Or is it possibly also a problem today for sata_send_pmp() and friends ? 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: libata .sg_tablesize: why always dividing by 2 ?
As an aside, ISTR tomo-san was working on eliminating the need for the /2 by tackling the details on the IOMMU side... 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: libata .sg_tablesize: why always dividing by 2 ?
Jeff Garzik wrote: Mark Lord wrote: Jeff, We had a discussion here today about IOMMUs, and they *never* split sg list entries -- they only ever *merge*. And this happens only after the block layer has already done merging while respecting q-seg_boundary_mask. So worst case, the IOMMU may merge everything, and then in libata we unmerge them again. But the end result can never exceed the max_sg_entries limit enforced by the block layer. shrug Early experience said otherwise. The split in foo_fill_sg() and resulting sg_tablesize reduction were both needed to successfully transfer data, when Ben H originally did the work. If Ben H and everyone on the arch side agrees with the above analysis, I would be quite happy to remove all those / 2. This can cost a lot of memory, as using NCQ effectively multiplies everything by 32.. I recommend dialing down the hyperbole a bit :) a lot in this case is... maybe another page or two per table, if that. Compared with everything else in the system going on, with 16-byte S/G entries, S/G table size is really the least of our worries. .. Well, today each sg table is about a page in size, and sata_mv has 32 of them per port. So cutting them in half would save 16 pages per port, or 64 pages per host controller. That's a lot for a small system, but maybe not for my 4GB test boxes. If you were truly concerned about memory usage in sata_mv, a more effective route is simply reducing MV_MAX_SG_CT to a number closer to the average s/g table size -- which is far, far lower than 256 (currently MV_MAX_SG_CT), or even 128 (MV_MAX_SG_CT/2). Or moving to a scheme where you allocate (for example) S/G tables with 32 entries... then allocate on the fly for the rare case where the S/G table must be larger... .. Oh, absolutely.. that's on my clean up list once the rest of the driver becomes stable and mostly done. But for now, safety and correctness is far more paramount in sata_mv. :) 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: libata .sg_tablesize: why always dividing by 2 ?
Jeff Garzik wrote: As an aside, ISTR tomo-san was working on eliminating the need for the /2 by tackling the details on the IOMMU side... .. Yes, tomo-san just led a nice detailed discussion of it here at LSF'08, and he agrees that even today it shouldn't affect us that way. 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: [RFC] Disk shock protection (revisited)
Jeff Garzik [EMAIL PROTECTED] wrote: Elias Oltmanns wrote: The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. Speaking specifically to that problem, it seems to me that you either want an mlock'd daemon, or just simply to keep everything in the kernel, for this specific solution. Yes, the daemon is mlock'd. You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Quite. But with mlock this particular problem can be handled in user space just fine. The only reason I can see right now for putting this logic into the kernel as well is to keep the functionality around even after task freeze during suspend / resume. On the other hand, I don't know whether this is really worth the effort even though the time when the suspend operation is in progress can arguably be one of the most accident-prone moments (think of users packing their things in a hurry). Regards, Elias - 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: libata .sg_tablesize: why always dividing by 2 ?
On Mon, 2008-02-25 at 19:15 -0500, Jeff Garzik wrote: Mark Lord wrote: Jeff, We had a discussion here today about IOMMUs, and they *never* split sg list entries -- they only ever *merge*. And this happens only after the block layer has already done merging while respecting q-seg_boundary_mask. So worst case, the IOMMU may merge everything, and then in libata we unmerge them again. But the end result can never exceed the max_sg_entries limit enforced by the block layer. shrug Early experience said otherwise. The split in foo_fill_sg() and resulting sg_tablesize reduction were both needed to successfully transfer data, when Ben H originally did the work. If Ben H and everyone on the arch side agrees with the above analysis, I would be quite happy to remove all those / 2. The split wasn't done by the iommu. The split was done by the IDE code itself to handle the stupid 64k crossing thingy. If it's done differently now, it might be possible to remove it, I haven't looked. 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: [RFC] Disk shock protection (revisited)
On Tue, 26 Feb 2008, Elias Oltmanns wrote: You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Quite. But with mlock this particular problem can be handled in user space just fine. The only reason I can see right now for putting this And, as long as there is a way to also invoke it from within the kernel, we can call it from inside the kernel as well when there is a reason to make that function available. Full flexibility is easily attainable here and nothing we should bother about too much. logic into the kernel as well is to keep the functionality around even Some hardware (Apple's?) has the entire APS logic in firmware (and AFAIK *also* export the accelerometer data for other uses). On those boxes, if you want to trust the firmware, you just ignore the accelerometer and hook to an interrupt. When you get the interrupt, you freeze the queue and unload heads. Adding that to work in-kernel would be trivial. Adding a suspend-time-only emergency HDAPS in-kernel monitor thread would also be doable, if we wanted to duplicate that for ThinkPads (I don't really think it is needed, but...). As long as queue freezing and the required unload immediate procedure can be called in at *any* time before the disk device, and its buses and controller are suspended, it would do to implement whatever we feel it is needed. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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: libata .sg_tablesize: why always dividing by 2 ?
Benjamin Herrenschmidt wrote: On Mon, 2008-02-25 at 19:15 -0500, Jeff Garzik wrote: Mark Lord wrote: Jeff, We had a discussion here today about IOMMUs, and they *never* split sg list entries -- they only ever *merge*. And this happens only after the block layer has already done merging while respecting q-seg_boundary_mask. So worst case, the IOMMU may merge everything, and then in libata we unmerge them again. But the end result can never exceed the max_sg_entries limit enforced by the block layer. shrug Early experience said otherwise. The split in foo_fill_sg() and resulting sg_tablesize reduction were both needed to successfully transfer data, when Ben H originally did the work. If Ben H and everyone on the arch side agrees with the above analysis, I would be quite happy to remove all those / 2. The split wasn't done by the iommu. The split was done by the IDE code itself to handle the stupid 64k crossing thingy. If it's done differently now, it might be possible to remove it, I haven't looked. .. The block layer uses seg_boundary_mask to ensure that we never have to split them again in the LLD. A very long time ago, when I wrote the IDE DMA code, this was not the case. 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: ops-qc_defer not invoked on ata_exec_internal_sg() paths ?
Hello, Mark. Mark Lord wrote: The optional .qc_defer() methods don't seem to be called on the ata_exec_internal_sg() path. At present, this is probably okay. But in the future, as we add functionality for link power management and hotplug polling, this could be a problem. I think. Or is it possibly also a problem today for sata_send_pmp() and friends ? That's intentional and okay. Currently, EH can only issue one non-NCQ command at a time and dynamic link PM and hotplug polling shouldn't be done via EH anyway. EH is way too big a hammer for those. 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: libata .sg_tablesize: why always dividing by 2 ?
Mark Lord wrote: Benjamin Herrenschmidt wrote: .. The split wasn't done by the iommu. The split was done by the IDE code itself to handle the stupid 64k crossing thingy. If it's done differently now, it might be possible to remove it, I haven't looked. .. The block layer uses seg_boundary_mask to ensure that we never have to split them again in the LLD. .. James B. suggests that we stick a WARN_ON() into libata to let us know if that precondition is violated. Sounds like an easy thing to do for a couple of -rc cycles someday. 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: new ata_port_operations for .pmp_{read,write} ?
Hello, Mark. Mark Lord wrote: libata doesn't really put much restrictions on what a LLD should do on entering EH and if the controller's behavior is predictable, there's no reason to freeze the port. If the problem is that the DMA engine isn't usable after PMP error but it's known that the controller isn't gonna cause irq storm, no need to freeze. The only command EH issues before resetting which can use DMA protocol is READ_LOG_EXT. Maybe there needs to be a way to force PIO protocol for READ_LOG_EXT. Other than that, if no-data and PIO-only commands work fine, EH autopsy should work fine. .. Eh? READ LOG EXT *is* a PIO command, as opposed to READ LOG DMA EXT which uses DMA. Ah.. right. My bad. And the EH also issues PIO READ_BUFFER commands for PM ports, if a PM is present. H Where? -- 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: libata .sg_tablesize: why always dividing by 2 ?
The block layer uses seg_boundary_mask to ensure that we never have to split them again in the LLD. A very long time ago, when I wrote the IDE DMA code, this was not the case. Not good enough, still, because the boundaries can change due to the iommu merging, thus the split must be re-done. 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: libata .sg_tablesize: why always dividing by 2 ?
James B. suggests that we stick a WARN_ON() into libata to let us know if that precondition is violated. Sounds like an easy thing to do for a couple of -rc cycles someday. If the block layer gives us a 32k block aligned on a 32k boundary (aligned), we have no guarantee that the iommu will not turn that into something unaligned crossing a 32k (and thus possibly a 64k) boundary. On powerpc, the iommu operates on 4k pages and only provides that level of alignment to dma_map_sg() (dma_alloc_coherent are naturally aligned, but not map_sg, that would put way too much pressure on the allocator on machines that have pinhole-sized iommu space). 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: libata .sg_tablesize: why always dividing by 2 ?
Benjamin Herrenschmidt wrote: James B. suggests that we stick a WARN_ON() into libata to let us know if that precondition is violated. Sounds like an easy thing to do for a couple of -rc cycles someday. If the block layer gives us a 32k block aligned on a 32k boundary (aligned), we have no guarantee that the iommu will not turn that into something unaligned crossing a 32k (and thus possibly a 64k) boundary. .. Certainly, but never any worse than what the block layer gave originally. The important note being: IOMMU only ever *merges*, it never *splits*. Which means that, by the time we split up any mis-merges again for 64K crossings, we can never have more SG segments than what the block layer originally fed to the IOMMU stuff. Or so the IOMMU and SCSI experts here at LSF'08 have assured me, even after my own skeptical questioning. 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: libata .sg_tablesize: why always dividing by 2 ?
On Mon, 2008-02-25 at 23:38 -0500, Mark Lord wrote: Benjamin Herrenschmidt wrote: James B. suggests that we stick a WARN_ON() into libata to let us know if that precondition is violated. Sounds like an easy thing to do for a couple of -rc cycles someday. If the block layer gives us a 32k block aligned on a 32k boundary (aligned), we have no guarantee that the iommu will not turn that into something unaligned crossing a 32k (and thus possibly a 64k) boundary. .. Certainly, but never any worse than what the block layer gave originally. The important note being: IOMMU only ever *merges*, it never *splits*. Yes, but it will also change the address and doesn't guarantee the alignment. Which means that, by the time we split up any mis-merges again for 64K crossings, we can never have more SG segments than what the block layer originally fed to the IOMMU stuff. Or so the IOMMU and SCSI experts here at LSF'08 have assured me, even after my own skeptical questioning. I suppose so. I don't remember all of the details, but iirc, it has to do with crossing 64K boundaries. Some controllers can't handle it. It's not only the _size_ of the segments, it's their alignment. The iommu will not keep alignement beyond the page size (and even then... on powerpc with a 64k base page size, you may still end up with a 4k aligned result, but let's not go there now). So that means that even if your block layer gives you nice aligned less than 64k segments that don't cross 64k boundaries, and even if your iommu isn't doing any merging at all, it may still give you back things that do not respect that 64k alignment boundary, might cross them, and thus might need to be split. Now, it would make sense (if we don't have it already) to have a flag provided by the host controller that tells us whether it suffers from that limitation, and if not, we get avoid the whole thing. 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: libata .sg_tablesize: why always dividing by 2 ?
Benjamin Herrenschmidt wrote: On Mon, 2008-02-25 at 23:38 -0500, Mark Lord wrote: Benjamin Herrenschmidt wrote: James B. suggests that we stick a WARN_ON() into libata to let us know if that precondition is violated. Sounds like an easy thing to do for a couple of -rc cycles someday. If the block layer gives us a 32k block aligned on a 32k boundary (aligned), we have no guarantee that the iommu will not turn that into something unaligned crossing a 32k (and thus possibly a 64k) boundary. .. Certainly, but never any worse than what the block layer gave originally. The important note being: IOMMU only ever *merges*, it never *splits*. Yes, but it will also change the address and doesn't guarantee the alignment. Which means that, by the time we split up any mis-merges again for 64K crossings, we can never have more SG segments than what the block layer originally fed to the IOMMU stuff. Or so the IOMMU and SCSI experts here at LSF'08 have assured me, even after my own skeptical questioning. I suppose so. I don't remember all of the details, but iirc, it has to do with crossing 64K boundaries. Some controllers can't handle it. It's not only the _size_ of the segments, it's their alignment. The iommu will not keep alignement beyond the page size (and even then... on powerpc with a 64k base page size, you may still end up with a 4k aligned result, but let's not go there now). .. That's just not possible, unless the IOMMU *splits* segments. And the IOMMU experts here say that it never does that. -ml - 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: libata .sg_tablesize: why always dividing by 2 ?
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote: I suppose so. I don't remember all of the details, but iirc, it has to do with crossing 64K boundaries. Some controllers can't handle it. It's not only the _size_ of the segments, it's their alignment. The iommu will not keep alignement beyond the page size (and even then... on powerpc with a 64k base page size, you may still end up with a 4k aligned result, but let's not go there now). .. That's just not possible, unless the IOMMU *splits* segments. And the IOMMU experts here say that it never does that. It is totally possible, and I know as wrote part of the powerpc iommu code :-) The iommu code makes no guarantee vs. preserving the alignment of a segment, at least not below PAGE_SIZE. Thus if you pass to dma_map_sg() a 64K aligned 64K segment, you may well get back a 4K aligned 64K segment. Enforcing natural alignment in the iommu code only happens for dma_alloc_coherent (it uses order-N allocations anyway), it doesn't happen for map_sg. If we were to do that, we would make it very likely for iommu allocations to fail on machine with small DMA windows. 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
ide-cd: trivial fixes
Hi Bart, here some trivial fixes that i wanted to get out the door. - 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] ide-cd: put proc-related functions together under single ifdef
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-cd.c | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 546f436..3600648 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1894,19 +1894,6 @@ int ide_cdrom_setup (ide_drive_t *drive)
return 0;
}
-#ifdef CONFIG_IDE_PROC_FS
-static
-sector_t ide_cdrom_capacity (ide_drive_t *drive)
-{
- unsigned long capacity, sectors_per_frame;
-
- if (cdrom_read_capacity(drive, capacity, sectors_per_frame, NULL))
- return 0;
-
- return capacity * sectors_per_frame;
-}
-#endif
-
static void ide_cd_remove(ide_drive_t *drive)
{
struct cdrom_info *info = drive-driver_data;
@@ -1940,14 +1927,24 @@ static void ide_cd_release(struct kref *kref)
static int ide_cd_probe(ide_drive_t *);
#ifdef CONFIG_IDE_PROC_FS
-static int proc_idecd_read_capacity
- (char *page, char **start, off_t off, int count, int *eof, void *data)
+static sector_t ide_cdrom_capacity(ide_drive_t *drive)
+{
+ unsigned long capacity, sectors_per_frame;
+
+ if (cdrom_read_capacity(drive, capacity, sectors_per_frame, NULL))
+ return 0;
+
+ return capacity * sectors_per_frame;
+}
+
+static int proc_idecd_read_capacity(char *page, char **start, off_t off,
+ int count, int *eof, void *data)
{
ide_drive_t *drive = data;
int len;
len = sprintf(page,%llu\n, (long long)ide_cdrom_capacity(drive));
- PROC_IDE_READ_RETURN(page,start,off,count,eof,len);
+ PROC_IDE_READ_RETURN(page, start, off, count, eof, len);
}
static ide_proc_entry_t idecd_proc[] = {
--
1.5.4.1
-
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] ide-cd: fix some codestyle and most of the checkpatch.pl issues
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-cd.c | 634 +
1 files changed, 323 insertions(+), 311 deletions(-)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 3600648..3853eb5 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -13,8 +13,8 @@
*
* Suggestions are welcome. Patches that work are more welcome though. ;-)
* For those wishing to work on this driver, please be sure you download
- * and comply with the latest Mt. Fuji (SFF8090 version 4) and ATAPI
- * (SFF-8020i rev 2.6) standards. These documents can be obtained by
+ * and comply with the latest Mt. Fuji (SFF8090 version 4) and ATAPI
+ * (SFF-8020i rev 2.6) standards. These documents can be obtained by
* anonymous ftp from:
*
ftp://fission.dt.wdc.com/pub/standards/SFF_atapi/spec/SFF8020-r2.6/PS/8020r26.ps
* ftp://ftp.avc-pioneer.com/Mtfuji4/Spec/Fuji4r10.pdf
@@ -41,17 +41,17 @@
#include scsi/scsi.h /* For SCSI - ATAPI command conversion */
-#include asm/irq.h
-#include asm/io.h
+#include linux/irq.h
+#include linux/io.h
#include asm/byteorder.h
-#include asm/uaccess.h
+#include linux/uaccess.h
#include asm/unaligned.h
#include ide-cd.h
static DEFINE_MUTEX(idecd_ref_mutex);
-#define to_ide_cd(obj) container_of(obj, struct cdrom_info, kref)
+#define to_ide_cd(obj) container_of(obj, struct cdrom_info, kref)
#define ide_cd_g(disk) \
container_of((disk)-private_data, struct cdrom_info, driver)
@@ -77,13 +77,12 @@ static void ide_cd_put(struct cdrom_info *cd)
mutex_unlock(idecd_ref_mutex);
}
-/
+/*
* Generic packet command support and error handling routines.
*/
-/* Mark that we've seen a media change, and invalidate our internal
- buffers. */
-static void cdrom_saw_media_change (ide_drive_t *drive)
+/* Mark that we've seen a media change, and invalidate our internal buffers. */
+static void cdrom_saw_media_change(ide_drive_t *drive)
{
struct cdrom_info *cd = drive-driver_data;
@@ -100,46 +99,45 @@ static int cdrom_log_sense(ide_drive_t *drive, struct
request *rq,
return 0;
switch (sense-sense_key) {
- case NO_SENSE: case RECOVERED_ERROR:
- break;
- case NOT_READY:
- /*
-* don't care about tray state messages for
-* e.g. capacity commands or in-progress or
-* becoming ready
-*/
- if (sense-asc == 0x3a || sense-asc == 0x04)
- break;
- log = 1;
- break;
- case ILLEGAL_REQUEST:
- /*
-* don't log START_STOP unit with LoEj set, since
-* we cannot reliably check if drive can auto-close
-*/
- if (rq-cmd[0] == GPCMD_START_STOP_UNIT sense-asc
== 0x24)
- break;
- log = 1;
- break;
- case UNIT_ATTENTION:
- /*
-* Make good and sure we've seen this potential media
-* change. Some drives (i.e. Creative) fail to present
-* the correct sense key in the error register.
-*/
- cdrom_saw_media_change(drive);
+ case NO_SENSE: case RECOVERED_ERROR:
+ break;
+ case NOT_READY:
+ /*
+* don't care about tray state messages for
+* e.g. capacity commands or in-progress or
+* becoming ready
+*/
+ if (sense-asc == 0x3a || sense-asc == 0x04)
break;
- default:
- log = 1;
+ log = 1;
+ break;
+ case ILLEGAL_REQUEST:
+ /*
+* don't log START_STOP unit with LoEj set, since
+* we cannot reliably check if drive can auto-close
+*/
+ if (rq-cmd[0] == GPCMD_START_STOP_UNIT
+ sense-asc == 0x24)
break;
+ log = 1;
+ break;
+ case UNIT_ATTENTION:
+ /*
+* Make good and sure we've seen this potential media
+* change. Some drives (i.e. Creative) fail to present
+* the correct sense key in the error register.
+*/
+ cdrom_saw_media_change(drive);
+ break;
+ default:
+ log = 1;
+ break;
}
return log;
}
-static
-void cdrom_analyze_sense_data(ide_drive_t *drive,
-
