).
This sounds like policy though, so it is something user space should
concern itself with. We should just provide the infrastructure.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop
Marcin Juszkiewicz wrote:
> PXA MMC driver supports not only PXA255 but also PXA250 and newer ones
>
> Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
>
Thanks. Applied.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
out a new patch set.
This just creates extra work for us.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: se
of this capability. If the host can do BYTEBLOCK transfers
it can send the password commands.
This has been pointed out in the past. Anderson, please make sure you
address all the previous concerns before sending out a new patch set.
This just creates extra work for us.
Rgds
--
-- Pierre Ossman
Marcin Juszkiewicz wrote:
PXA MMC driver supports not only PXA255 but also PXA250 and newer ones
Signed-off-by: Marcin Juszkiewicz [EMAIL PROTECTED]
Thanks. Applied.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
Rafael J. Wysocki wrote:
>On Wednesday, 7 of September 2005 13:20, Pierre Ossman wrote:
>
>
>>It would seem that swsusp doesn't properly suspend devices, or more
>>precisely it wakes them up again before suspending the machine.
>>
>>
>
>Yes, it does.
It would seem that swsusp doesn't properly suspend devices, or more
precisely it wakes them up again before suspending the machine.
The problem is in swsusp_suspend(). It is designed as if
swsusp_arch_suspend() would suspend the hardware, when in fact all it
does is prepare for a suspend. The
It would seem that swsusp doesn't properly suspend devices, or more
precisely it wakes them up again before suspending the machine.
The problem is in swsusp_suspend(). It is designed as if
swsusp_arch_suspend() would suspend the hardware, when in fact all it
does is prepare for a suspend. The
Rafael J. Wysocki wrote:
On Wednesday, 7 of September 2005 13:20, Pierre Ossman wrote:
It would seem that swsusp doesn't properly suspend devices, or more
precisely it wakes them up again before suspending the machine.
Yes, it does. By design.
That seems counter-productive, so
Jeff Garzik wrote:
>
> Where is CONFIG_PM?
>
> Jeff
I'm not sure you're receiving my mails, but I'll give it a try anyway.
It would also seem that my MTA is choking on your MX entries. I'll look
into that once I get home.
CONFIG_PM is missing because of consistency with i8259.c, on which
Jeff Garzik wrote:
Where is CONFIG_PM?
Jeff
I'm not sure you're receiving my mails, but I'll give it a try anyway.
It would also seem that my MTA is choking on your MX entries. I'll look
into that once I get home.
CONFIG_PM is missing because of consistency with i8259.c, on which the
Register interrupt handler when net device is registered. Avoids missing
interrupts if the interrupt mask gets out of sync.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
---
The reason this patch is needed for me is that the resume function is
broken. It enables interrupts unconditi
Eric W. Biederman wrote:
>Thanks.
>
>This is clearly a code path I missed when I was fixing things.
>
>When I made the final acpi change I checked for any other users
>of device_suspend and it seems I was blind and missed this one.
>Looking again...
>
>The patch in the bug report looks correct.
Eric W. Biederman wrote:
>Hmm. Looking at that bug report it specifies 2.6.11. Does this
>problem really happen in 2.6.13?
>
>
>
I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc
only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch
for 2.6.13 which fixes
Meelis Roos wrote:
>
> It's OK then - I'm not using any suspend and I had a problem that my
> machine powered down instead of reboot. The patch that went into 2.6.13
> after rc7 fixed it for me. So the current tree is OK for me and if it's
> OK for you too after suspend2 changes then this case
Meelis Roos wrote:
It's OK then - I'm not using any suspend and I had a problem that my
machine powered down instead of reboot. The patch that went into 2.6.13
after rc7 fixed it for me. So the current tree is OK for me and if it's
OK for you too after suspend2 changes then this case can
Eric W. Biederman wrote:
Hmm. Looking at that bug report it specifies 2.6.11. Does this
problem really happen in 2.6.13?
I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc
only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch
for 2.6.13 which fixes the
Eric W. Biederman wrote:
Thanks.
This is clearly a code path I missed when I was fixing things.
When I made the final acpi change I checked for any other users
of device_suspend and it seems I was blind and missed this one.
Looking again...
The patch in the bug report looks correct. However
Register interrupt handler when net device is registered. Avoids missing
interrupts if the interrupt mask gets out of sync.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
---
The reason this patch is needed for me is that the resume function is
broken. It enables interrupts unconditionally
Only show the scr file in sysfs for SD cards. Previously this was
present for all cards but had a contents of 0 for MMC cards.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
---
Only show the scr file in sysfs for SD cards. Previously this was
present for all cards but had a contents of 0 for MMC cards.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
--- linux
Use the chip select ios in the wbsd driver.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux/drivers/mmc/wbsd.c
===
--- linux/drivers/mmc/wbsd.c (revision 161)
+++ linux/drivers/mmc/wbsd.c (working copy)
@@ -42,7
Adds a new ios for setting the chip select pin on MMC cards. Needed on
SD controllers which use this pin for other things and therefore cannot
have it pulled high at all times.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux/drivers/mmc
Use the chip select ios in the wbsd driver.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
Index: linux/drivers/mmc/wbsd.c
===
--- linux/drivers/mmc/wbsd.c (revision 161)
+++ linux/drivers/mmc/wbsd.c (working copy)
@@ -42,7 +42,7
Adrian Bunk wrote:
> [ this time with a better subject ]
>
> "extern inline" doesn't make sense.
>
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
Isn't 'extern inline' an old gcc trick to force inlining? (instead of
just hinting)
-
To unsubscribe from this list: send the line
Adrian Bunk wrote:
[ this time with a better subject ]
extern inline doesn't make sense.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Isn't 'extern inline' an old gcc trick to force inlining? (instead of
just hinting)
-
To unsubscribe from this list: send the line unsubscribe
Pavel Machek wrote:
>
>Maybe the card is pretty close to going to crash, but... two disk
>successive disk errors still should not be cause for journal
>corruption.
>
>[Also errors could be corelated. Imagine severe overheat. You'll
>successive failing writes, but if you let cool it down, you'll
Russell King wrote:
>
>Hmm, I think I've gone back to preferring something similar to your
>original approach actually. I've also included the IDR patch.
>
>
>
Ok. Just as long as it works. :)
My two concerns are:
* Things that assume there's a name for every kobject.
* Things that assume
Russell King wrote:
Hmm, I think I've gone back to preferring something similar to your
original approach actually. I've also included the IDR patch.
Ok. Just as long as it works. :)
My two concerns are:
* Things that assume there's a name for every kobject.
* Things that assume that a
Pavel Machek wrote:
Maybe the card is pretty close to going to crash, but... two disk
successive disk errors still should not be cause for journal
corruption.
[Also errors could be corelated. Imagine severe overheat. You'll
successive failing writes, but if you let cool it down, you'll still
Pavel Machek wrote:
>>* Transport problem. The driver will report back a CRC error, timeout or
>>whatnot and break. We might not know how many sectors survived so we try
>>again, going sector-by-sector. We might get a transfer error again,
>>possibly even before the previous one. But at this
Alan Cox wrote:
>On Iau, 2005-08-18 at 09:26 +0200, Pierre Ossman wrote:
>
>
>>everything out first and then fall back on sector-by-sector to determine
>>where an error occurs. This will only break if the problematic sector
>>keeps shifting around, but at that point
Russell King wrote:
>On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote:
>
>
>>We had this discussion on LKML and Alan Cox' comment on it was that a
>>solution like this would be acceptable, where we try and shove
>>everything out first and then fa
Russell King wrote:
>
>I'd rather not. The problem is that we have a host (thanks Intel)
>which is unable to report how many bytes were transferred before an
>error occurs. My fear is that doing anything other than sector by
>sector write will lead to corruption should an error occur.
>
Russell King wrote:
I'd rather not. The problem is that we have a host (thanks Intel)
which is unable to report how many bytes were transferred before an
error occurs. My fear is that doing anything other than sector by
sector write will lead to corruption should an error occur.
However, I've
Russell King wrote:
On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote:
We had this discussion on LKML and Alan Cox' comment on it was that a
solution like this would be acceptable, where we try and shove
everything out first and then fall back on sector-by-sector to determine
Alan Cox wrote:
On Iau, 2005-08-18 at 09:26 +0200, Pierre Ossman wrote:
everything out first and then fall back on sector-by-sector to determine
where an error occurs. This will only break if the problematic sector
keeps shifting around, but at that point the card is probably toast
anyway
Pavel Machek wrote:
* Transport problem. The driver will report back a CRC error, timeout or
whatnot and break. We might not know how many sectors survived so we try
again, going sector-by-sector. We might get a transfer error again,
possibly even before the previous one. But at this point the
Andrew Morton wrote:
>The fact that this is enabled under the experimental
>CONFIG_MMC_BULKTRANSFER seems unfortunate. I mean, if the code works OK
>then we should just enable it unconditionally, no?
>
>
>
It was made this way to make Russell more open to it. I have since not
recieved any
Jörn Engel wrote:
>On Tue, 16 August 2005 20:13:36 +0200, Jörn Engel wrote:
>
>
>>Yes. Most filesystems expect to find either 1) old data or 2) new
>>data. Blocks full of 0xff are non-expected.
>>
>>
>
>Maybe this isn't obvious. Because of this expectation, it is
>absolutely not safe to
Jörn Engel wrote:
On Tue, 16 August 2005 20:13:36 +0200, Jörn Engel wrote:
Yes. Most filesystems expect to find either 1) old data or 2) new
data. Blocks full of 0xff are non-expected.
Maybe this isn't obvious. Because of this expectation, it is
absolutely not safe to pre-erase
Andrew Morton wrote:
The fact that this is enabled under the experimental
CONFIG_MMC_BULKTRANSFER seems unfortunate. I mean, if the code works OK
then we should just enable it unconditionally, no?
It was made this way to make Russell more open to it. I have since not
recieved any more
Jörn Engel wrote:
>Question came up before, albeit with a different phrasing. One
>possible approach to benefit from this ability would be to create a
>"forget" operation. When a filesystem already knows that some data is
>unneeded (after a truncate or erase operation), it will ask the device
Jörn Engel wrote:
Question came up before, albeit with a different phrasing. One
possible approach to benefit from this ability would be to create a
forget operation. When a filesystem already knows that some data is
unneeded (after a truncate or erase operation), it will ask the device
to
with no side-effects found.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
---
Previously submitted: 2005-03-16
Previously submitted: 2004-12-03
Index: linux-wbsd/drivers/mmc/mmc_block.c
===
--- linux-wbsd/drivers/mmc/mmc_block.c (re
with no side-effects found.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
---
Previously submitted: 2005-03-16
Previously submitted: 2004-12-03
Index: linux-wbsd/drivers/mmc/mmc_block.c
===
--- linux-wbsd/drivers/mmc/mmc_block.c (revision
Pierre Ossman wrote:
> Pierre Ossman wrote:
>
>>I'm having problem with the interrupt getting killed after suspend with
>>my 8139cp controller. The problem only appears if the cable is connected
>>during resume (before suspend is irrelevant) and the interface is down.
&
Pierre Ossman wrote:
Pierre Ossman wrote:
I'm having problem with the interrupt getting killed after suspend with
my 8139cp controller. The problem only appears if the cable is connected
during resume (before suspend is irrelevant) and the interface is down.
Both suspend-to-disk and suspend
Russell King wrote:
>
>I still don't like the needless duplication. How about doing it this
>way (see the attached patch.)
>
>Note: I also intend to move MMC over to using an IDR for the host
>numbers, which is why we need to setup the name at registration
>time, not allocation time.
>
>
>
Russell King wrote:
I still don't like the needless duplication. How about doing it this
way (see the attached patch.)
Note: I also intend to move MMC over to using an IDR for the host
numbers, which is why we need to setup the name at registration
time, not allocation time.
This patch
Richard Purdie wrote:
> This fixes what looks like a bit/byte counting error in the MMC/SD code
> which was causing data corruption (in the -mm tree).
>
> Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
Ooops... Must have been late in the evening. Sorry about that blunder.
Rgds
Pierre
-
To
Richard Purdie wrote:
This fixes what looks like a bit/byte counting error in the MMC/SD code
which was causing data corruption (in the -mm tree).
Signed-off-by: Richard Purdie [EMAIL PROTECTED]
Ooops... Must have been late in the evening. Sorry about that blunder.
Rgds
Pierre
-
To
Pierre Ossman wrote:
> I'm having problem with the interrupt getting killed after suspend with
> my 8139cp controller. The problem only appears if the cable is connected
> during resume (before suspend is irrelevant) and the interface is down.
>
> Both suspend-to-disk and suspend
John W. Linville wrote:
>On Mon, Jul 04, 2005 at 12:22:53AM +0200, Pierre Ossman wrote:
>
>
>>After suspend the driver needs to retest link status in case the cable
>>has been inserted or removed during the suspend.
>>
>>Signed-off-by: Pierre Ossman <[EMAIL
John W. Linville wrote:
On Mon, Jul 04, 2005 at 12:22:53AM +0200, Pierre Ossman wrote:
After suspend the driver needs to retest link status in case the cable
has been inserted or removed during the suspend.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
Please copy netdev
Pierre Ossman wrote:
I'm having problem with the interrupt getting killed after suspend with
my 8139cp controller. The problem only appears if the cable is connected
during resume (before suspend is irrelevant) and the interface is down.
Both suspend-to-disk and suspend-to-ram exhibit
Jesper Juhl wrote:
>
>Have you tried the suggestion given "... As a temporary workaround,
>the "pci=routeirq" argument..." ?
>You could also try the pci=noacpi boot option to see if that changes anything.
>
>
No, I missed that one. The machine works fine with either of those two
options. I
Pierre Ossman wrote:
> ** PCI interrupts are no longer routed automatically. If this
> ** causes a device to stop working, it is probably because the
> ** driver failed to call pci_enable_device(). As a temporary
> ** workaround, the "pci=routeirq" argument restores
Sorry about reporting this error so late but the machine in question had
gone some time without upgrades.
The problem I'm seeing is that IRQs stop working for one of the IRQ
slots on the machine. It's only that slot, not the entire IRQ, since the
two slots (it's a small machine) both get routed
Pierre Ossman wrote:
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the pci=routeirq argument restores the old
** behavior
Jesper Juhl wrote:
Have you tried the suggestion given ... As a temporary workaround,
the pci=routeirq argument... ?
You could also try the pci=noacpi boot option to see if that changes anything.
No, I missed that one. The machine works fine with either of those two
options. I sent a
Russell King wrote:
>On Fri, Jul 15, 2005 at 10:21:43PM +0200, Pierre Ossman wrote:
>
>
>>Russell King wrote:
>>
>>
>>>Also note that since we have a class_dev, the mmc_host 'dev' field can
>>>be removed. However, we'll probably have to update
Russell King wrote:
On Fri, Jul 15, 2005 at 10:21:43PM +0200, Pierre Ossman wrote:
Russell King wrote:
Also note that since we have a class_dev, the mmc_host 'dev' field can
be removed. However, we'll probably have to update the host drivers
to do this, so it should be a separate patch
Russell King wrote:
>The allocation function should initialise class_dev as much as possible.
>The registration function should add the class device with the class
>model. The unregistration should remove the class device from the class
>model, but _not_ free it. The free function should drop
Russell King wrote:
>No no no no no. Repeat after me ten times. Empty or non-existant release
>functions are bad and cause oopsen. I will not create code which does
>this.
>
>
Sorry. I thought it was a generic cleanup function and since nothing was
allocated in the register function I
Russell King wrote:
No no no no no. Repeat after me ten times. Empty or non-existant release
functions are bad and cause oopsen. I will not create code which does
this.
Sorry. I thought it was a generic cleanup function and since nothing was
allocated in the register function I didn't
Russell King wrote:
The allocation function should initialise class_dev as much as possible.
The registration function should add the class device with the class
model. The unregistration should remove the class device from the class
model, but _not_ free it. The free function should drop the
Create a mmc_host class to allow enumeration of MMC host controllers
even though they have no card(s) inserted.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
(This will also allow cards to be enumerated by being able to find the
hosts.)
Index: linux-wbsd/drivers/mmc
Create a mmc_host class to allow enumeration of MMC host controllers
even though they have no card(s) inserted.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
(This will also allow cards to be enumerated by being able to find the
hosts.)
Index: linux-wbsd/drivers/mmc/mmc.h
Remove lots of trailing whitespace caused by not-so-great editor.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
--- linux/drivers/mmc/wbsd.c.orig 2005-07-11 14:26:40.0 +0200
+++ linux/drivers/mmc/wbsd.c 2005-07-11 14:27:02.0 +0200
@@ -93,7 +93,7 @@
static inlin
Version increase of the wbsd driver.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Even though the changes are minor for the next release an increasing
version number simplifies my support issues.
Index: linux/drivers/mmc/
Version increase of the wbsd driver.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
Even though the changes are minor for the next release an increasing
version number simplifies my support issues.
Index: linux/drivers/mmc/wbsd.c
Remove lots of trailing whitespace caused by not-so-great editor.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
--- linux/drivers/mmc/wbsd.c.orig 2005-07-11 14:26:40.0 +0200
+++ linux/drivers/mmc/wbsd.c 2005-07-11 14:27:02.0 +0200
@@ -93,7 +93,7 @@
static inline void
I upgraded a machine from 2.6.11.7 to 2.6.12.2 today and the only thanks
I got was a brand new kernel panic. From the backtrace it seems that the
dc395x driver is the culprit. From what I can tell it hasn't undergone
any changes between the two versions.
Image of kernel panic:
I upgraded a machine from 2.6.11.7 to 2.6.12.2 today and the only thanks
I got was a brand new kernel panic. From the backtrace it seems that the
dc395x driver is the culprit. From what I can tell it hasn't undergone
any changes between the two versions.
Image of kernel panic:
Documentation for how the ISA DMA controller is handled in the kernel.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
New version after feedback from Randy Dunlap.
Index: linux-wbsd/Documentation/DMA-ISA-LPC.txt
===
---
randy_dunlap wrote:
>+The DMA:able address space is the lowest 16 MB of _physical_ memory.
> The DMA-able
>+Also the transfer block may not cross page boundaries (which are 64k).
> I would write:(which are 64 KB).
>
>if I knew that was correct, but I don't.
randy_dunlap wrote:
+The DMA:able address space is the lowest 16 MB of _physical_ memory.
The DMA-able
+Also the transfer block may not cross page boundaries (which are 64k).
I would write:(which are 64 KB).
if I knew that was correct, but I don't.
Does
Documentation for how the ISA DMA controller is handled in the kernel.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
New version after feedback from Randy Dunlap.
Index: linux-wbsd/Documentation/DMA-ISA-LPC.txt
===
--- linux-wbsd
*dev)
-{
-}
+static struct platform_device *wbsd_device;
-static struct platform_device wbsd_device = {
- .name = DRIVER_NAME,
- .id = -1,
- .dev= {
- .release = wbsd_release,
- },
-};
-
static struct device_driver wbsd_driver
,
DRIVER_VERSION \n);
printk(KERN_INFO DRIVER_NAME : Copyright(c) Pierre Ossman\n);
+
+#ifdef CONFIG_PNP
+
+ if (!nopnp)
+ {
+ result = pnp_register_driver(wbsd_pnp_driver);
+ if (result 0)
+ return result
down(>dev, 1);
}
+#endif /* CONFIG_PNP */
+
/*
* Power management
*/
@@ -1581,7 +1895,7 @@
#define wbsd_resume NULL
#endif
-static void wbsd_release(struct device *dev)
+static void wbsd_release_dev(struct device *dev)
{
}
@@ -1589,7 +1903,7 @@
.name = DRIVER_NAME,
.id
it might help if I include the actual patch...
Index: linux-wbsd/drivers/mmc/mmc_block.c
===
--- linux-wbsd/drivers/mmc/mmc_block.c (revision 77)
+++ linux-wbsd/drivers/mmc/mmc_block.c (working copy)
@@ -166,9 +166,25 @@
struct
I didn't get any response for this one either ;)
This is only a performance boost so it is less critical. It is very nice
to have though since the performance gain is substancial (>100%).
It should not pose any problems with data loss, which was your primary
concern. It backs down to single
I didn't get any response from you the last time I submitted this so I'm
going to nag you some more ;)
This patch is vital for one of my MMC cards. The only other way I've
found to get it working is by changing the OCR. And that would cause
problems on other controllers so it was not an option.
I didn't get any response from you the last time I submitted this so I'm
going to nag you some more ;)
This patch is vital for one of my MMC cards. The only other way I've
found to get it working is by changing the OCR. And that would cause
problems on other controllers so it was not an option.
I didn't get any response for this one either ;)
This is only a performance boost so it is less critical. It is very nice
to have though since the performance gain is substancial (100%).
It should not pose any problems with data loss, which was your primary
concern. It backs down to single block
it might help if I include the actual patch...
Index: linux-wbsd/drivers/mmc/mmc_block.c
===
--- linux-wbsd/drivers/mmc/mmc_block.c (revision 77)
+++ linux-wbsd/drivers/mmc/mmc_block.c (working copy)
@@ -166,9 +166,25 @@
struct
Pierre Ossman, All Rights Reserved.
*
* 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
Pierre Ossman, All Rights Reserved.
*
* 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
Takashi Iwai wrote:
At Tue, 08 Mar 2005 02:10:06 +0100,
Pierre Ossman wrote:
Takashi Iwai wrote:
Look at /etc/asound.state whether it contains the value of "Headphone
Jack Sense" control true or false.
It saves the setting once I've been in 2.6.11. From an earl
Takashi Iwai wrote:
At Tue, 08 Mar 2005 02:10:06 +0100,
Pierre Ossman wrote:
Takashi Iwai wrote:
Look at /etc/asound.state whether it contains the value of Headphone
Jack Sense control true or false.
It saves the setting once I've been in 2.6.11. From an earlier kernel
Lee Revell wrote:
>So is there a bug or not? Mark seems to be the only one affected.
>
>It's important to follow up, because these so-called "ALSA regressions"
>are generating bad press.
>
>Lee
>
>
>
I can generate the error using the following procedure:
1. Boot in 2.6.10. Remove
Takashi Iwai wrote:
Look at /etc/asound.state whether it contains the value of "Headphone
Jack Sense" control true or false.
It saves the setting once I've been in 2.6.11. From an earlier kernel
there is no such entry.
Of course, the earlier version didn't have this.
And did you take a
Takashi Iwai wrote:
>At Fri, 04 Mar 2005 22:16:03 +0100,
>Pierre Ossman wrote:
>
>
>>It seems I spoke too soon. The defaults picked by the driver are
>>actually fine. It seems to be alsactl store/restore that did something
>>strange when coming from an older
Takashi Iwai wrote:
At Fri, 04 Mar 2005 22:16:03 +0100,
Pierre Ossman wrote:
It seems I spoke too soon. The defaults picked by the driver are
actually fine. It seems to be alsactl store/restore that did something
strange when coming from an older kernel.
My guess is that kmix
Takashi Iwai wrote:
Look at /etc/asound.state whether it contains the value of Headphone
Jack Sense control true or false.
It saves the setting once I've been in 2.6.11. From an earlier kernel
there is no such entry.
Of course, the earlier version didn't have this.
And did you take a
Lee Revell wrote:
So is there a bug or not? Mark seems to be the only one affected.
It's important to follow up, because these so-called ALSA regressions
are generating bad press.
Lee
I can generate the error using the following procedure:
1. Boot in 2.6.10. Remove /etc/asound.conf and
Wide bus support.
This adds 4-bit bus support to the MMC layer. It is designed to
(hopefully) be compatible with a future 4-bit MMC implementation. This
is done by seperating the three different instances of bus width defines:
* Protocol definition: SD_BUS_WIDTH_x
* SCR contents:
SCR sysfs access.
This provides access to the SCR register via sysfs. Since the latest bk
contains some changes to the sysfs part this probably needs updating.
The patch is trivial though so it should be easy.
Index: linux-sd/drivers/mmc/mmc_sysfs.c
801 - 900 of 964 matches
Mail list logo
