Re: [PATCH 07/13] libata-acpi: add ATA_FLAG_ACPI_SATA port flag
Alan Cox wrote: You can end up with _SDD methods for SFF format controllers (or what we think of as SFF format controllers) when we don't have the knowledge to drive them in their full super-whizzo method (eg Marvell) The ACPI spec says the layout is dependent on controller interface and I can see reasons why we need to follow that but not the other way around. Do you have counter-examples? The first problem is the words the spec. Agreed that STM/GTM are not safe except when expected (and not always safe when they are) but that ought to be ok as we then set all the modes properly ourselves afterwards. I agree that there are cases where we drive a controller in different way than how the BIOS configured it and as a result we can end up with unmatching ACPI nodes, but I think that it's safer to ignore unmatched ACPI nodes than to do what seems likely without really knowing what's going on. There just isn't a generic way to determine which node matches which device. The first two ports might map to the first IDE channel or port 1 and 3 (ata_piix). Or each port might map to a separate IDE channel with slave spot disabled. Even if we support 'best effort' matching, it is something that only the LLD knows how it should be done and whether it's safe or not. IMHO, we're better off just ignoring ATA ACPI hierarchy if it doesn't match the expectation of the driver. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] libata: improve ATA ACPI support
Alan Cox wrote: * after successfully executing _GTF taskfiles, IDENTIFY page is reloaded Interesting question we should sort out: What is our identify page as supplied to the user meant to be ? The old IDE one started off as the identify data at boot (which is useful) and mutated through a million kind of boot but mangled and not boot versions of the identify data, all of which are useless to userspace. Having the boot data (for some definition of boot) is important in order to know things like the BIOS view of the disk geometry and HPA (eg for partitioning), having the current data is useless as its already available via SG_IO. AFAIK, IDENTIFY using SG_IO is the way to obtain ID data. HDIO_GET_IDENTITY is only added for backward compatibility and as a sideway to obtain ATAPI IDENTIFY page while IDENTIFY_PACKET_DEVICE via SG_IO is broken. libata tries pretty hard to keep the cached IDENTIFY page up-to-date and I'm pretty sure it stays in sync with the drive most of the time. I think HDIO_GET_IDENTITY's meaning is something like give me IDENTIFY page of the device as seen by the driver and doesn't really matter as long as it can be used to get general idea about the device. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [patch 2.6.21-rc5-git 1/3] new platform_enable_wake() hook; use it in PCI
Hi! static inline int device_suspend(pm_message_t state) --- g26.orig/drivers/base/power/main.c2007-04-04 13:03:33.0 -0700 +++ g26/drivers/base/power/main.c 2007-04-04 13:03:34.0 -0700 @@ -29,6 +29,9 @@ LIST_HEAD(dpm_off_irq); DECLARE_MUTEX(dpm_sem); DECLARE_MUTEX(dpm_list_sem); +int (*platform_enable_wakeup)(struct device *dev, int is_on) = NULL; Static variables do not need zero initializers. Otherwise it looks ok. -- (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-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ACPI in Windows Vista
It is useful to see what Microsoft is doing with ACPI in Vista -- as that shapes many of the BIOS implementations that Linux will encounter: http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/CPA002_WH06.ppt - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2/3] 2.6.21-rc7: known regressions (v2)
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ACPI: Crashes + hangs during modprobe processor unless processor.nocst References : http://bugzilla.kernel.org/show_bug.cgi?id=8346 Submitter : Olaf Kirch [EMAIL PROTECTED] Status : unknown Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann [EMAIL PROTECTED] Status : unknown Subject: ali_pata: boot from CD fails References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark [EMAIL PROTECTED] Status : unknown Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark [EMAIL PROTECTED] Status : unknown Subject: qla2xxx driver no longer works References : http://lkml.org/lkml/2007/4/16/49 http://lkml.org/lkml/2007/4/20/224 Submitter : David Miller [EMAIL PROTECTED] Robert Peterson [EMAIL PROTECTED] Handled-By : David Miller [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/4/16/234 Status : patch was suggested - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] libata: improve ATA ACPI support
Alan Cox wrote: * after successfully executing _GTF taskfiles, IDENTIFY page is reloaded Interesting question we should sort out: What is our identify page as supplied to the user meant to be ? The old IDE one started off as the identify data at boot (which is useful) and mutated through a million kind of boot but mangled and not boot versions of the identify data, all of which are useless to userspace. Having the boot data (for some definition of boot) is important in order to know things like the BIOS view of the disk geometry and HPA (eg for partitioning), having the current data is useless as its already available via SG_IO. Agreed. Userspace can already fetch the real, current IDENTIFY data just by issuing the appropriate drive command (except for ATAPI, since Jeff has gone mute on the months old patch to fix it). Boot-time IDENTIFY data was extremely useful for IDE development. It showed how the BIOS had set things up (or not). Cheers - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] libata: improve ATA ACPI support
Tejun Heo wrote: of the time. I think HDIO_GET_IDENTITY's meaning is something like give me IDENTIFY page of the device as seen by the driver and doesn't really matter as long as it can be used to get general idea about the device. The correct/original meaning of that ioctl was boot time IDENTIFY data. As Alan said, it later got bastardized by various people at some point. Cheers - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] libata: improve ATA ACPI support
Hi,
On Tuesday 24 April 2007, Mark Lord wrote:
Tejun Heo wrote:
of the time. I think HDIO_GET_IDENTITY's meaning is something like
give me IDENTIFY page of the device as seen by the driver and doesn't
really matter as long as it can be used to get general idea about the
device.
The correct/original meaning of that ioctl was boot time IDENTIFY data.
As Alan said, it later got bastardized by various people at some point.
It got de-bastardized later :) and currently HDIO_GET_IDENTITY seems to be
returning boot time IDENTIFY with only two exceptions:
* if ID can't be read et all - fake geometry with user supplied values
to make things work - this is OK (was added by Alan IIRC)
* id-dma_{1word,mword,ultra} (currently selected DMA transfer modes)
are updated when the current transfer mode changes - this is of least
importance than capacity/geometry data (since nowadays all speed tuning
should be done by kernel anyway) and easy to fix once DMA rewrite patches
from my tree get merged
Thanks,
Bart
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: C2 and C3 processor states cause mouse desynchronization
On Sun, 2007-04-22 at 22:57 -0400, Lex Neva wrote: So, the questions I have: Is this a problem anyone's seen before? Is this a bug? If so, is it in linux-ACPI or psmouse (or something else)? Is there anything I can do to get my power savings and still make the mouse driver happy? Is there any chance that I can work with the linux-ACPI developers to get a fix produced? Well I am not a kernel hacker either but what give you ? cat /sys/devices/system/clocksource/clocksource0/available_clocksource cat /sys/devices/system/clocksource/clocksource0/current_clocksource and boot with parameter: report_lost_ticks and boot with parameter: notsc ( try first report_lost_ticks if you got lost ticket than boot with both notsc and report_lost_ticks ) cat /proc/interrupts At MNI got any value, different than zero ? I got all my ansync computer problems resolved at 2.6.21-rc5, but I had more problems that just a mouse desynchronization Best regards , -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
Re: ACPI in Windows Vista
On Tue, 2007-04-24 at 02:58 +0800, Len Brown wrote: It is useful to see what Microsoft is doing with ACPI in Vista -- as that shapes many of the BIOS implementations that Linux will encounter: http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/CPA002_WH06.ppt vista disable MSI per fadt.iapc_boot_arch flags, looks we should do the same. This means we don't need MSI quirk too. I'm curious why firmware shouldn't change low 1M memory between sleep, considering some ranges are reserved. Thanks, Shaohua - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
