Re: [PATCH] mmc: logging copyrights is useless
On 15/03/17 14:11, Corentin Labbe wrote: Logging copyrights does not add any useful information in logs. This patch remove such logging Aw, come on now. That's my claim to fame. :) I would prefer if they are kept, but I'm not going to raise a stink if you insist on removing them. Regards -- Pierre Ossman
Re: [PATCH] mmc: logging copyrights is useless
On 15/03/17 14:11, Corentin Labbe wrote: Logging copyrights does not add any useful information in logs. This patch remove such logging Aw, come on now. That's my claim to fame. :) I would prefer if they are kept, but I'm not going to raise a stink if you insist on removing them. Regards -- Pierre Ossman
Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Mon, 25 Feb 2008 12:58:30 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > Thanks for the explanations. > > On Mon, 25 Feb 2008, Pierre Ossman wrote: > > > Trying to keep up with the PM changes is a full time job. For now I've > > mostly ignored it as I don't even have time for the other stuff. > > Patches welcome. > > What do you think of the patch attached to comment #40 in the Bugzilla > entry? > Looks ok. As long as those two synchronization points are guaranteed, then I'm happy. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Sun, 24 Feb 2008 10:33:34 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > Well, the patch itself isn't really adequate; it was just a first pass > intended to illustrate the nature of the problem. > > The problems in the MMC subsystem go deeper. > > The first is the way it uses flush_workqueue(). This is almost always > a bad function to call, because it introduces unnecessary dependencies. > cancel_delayed_work_sync() is much better. > > But even changing that won't solve the second issue, which is a genuine > bug. There is a race between detect events and suspend events. The > mmc_suspend_host() routine starts out by flushing the kmmcd workqueue > before calling the host's suspend routine. So what happens if another > detect event occurs in between? > The idea is that host drivers shouldn't do that. Once they've called mmc_suspend_host(), then they shouldn't be poking the MMC core in any other way. None of this is of course properly documented. :/ > This whole area of synchronization between card insertion, card > removal, suspend, and resume needs to be thought out better. > Especially keeping in mind that device registration or unregistration > during a system sleep is likely to block until the sleep is over. Trying to keep up with the PM changes is a full time job. For now I've mostly ignored it as I don't even have time for the other stuff. Patches welcome. > > Lastly, there are some other questions about confusing aspects of the > subsystem. What's the story with __mmc_claim_host()? Is it really > nothing more than an abortable mutex_lock()? Why does it ever need to > be aborted? Why is its second argument an atomic_t instead of a normal > int? > It got that way when SDIO got in. It was needed to make it abortable to solve a rather nasty deadlock situation. I don't remember the details right now, but it should be in the LKML archives. > Why are mmc_detect() and related routines described in comments as > "Card detection callback from host"? They don't handle card > _detection_ -- they handle card _removal_. They handle both. > > What's the purpose of the card-counting loop in > host/omap.c:mmc_omap_switch_handler()? It looks like dead code. > I'm not too familiar with that driver, but they've been playing around with multiplexing several cards into one controller. Might be bits and pieces of that. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMC card detection
On Thu, 21 Feb 2008 19:46:20 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > When the card is reinserted, the MMC core will try to send a > SEND_STATUS command again. This time, the card won't respond because it > is in the "idle" state, and the MMC core will think the card is gone. > > In order to fix this problem, I think I need a way to tell the MMC core > that the card really is gone and that there's no point trying to > communicate with it. Is there any way I can do that? > As you found out, you can. But the MMC core doesn't treat it differently. What is really needed is that the core should make an extra pass and see if the card has been replaced by something else (and not just check if it is gone). It's on my todo, but I haven't had time to implement it. Rgds Pierre signature.asc Description: PGP signature
Re: MMC core debugfs support (was Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers)
On Thu, 14 Feb 2008 15:00:05 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > I've started working on this, but I've run into a problem: The mmc core > structures don't seem to keep any references to the current request. So > I don't really have any information to put into the 'req' file after > moving it into the core. > > Any ideas on how to solve this? > The simple solution is just to add it. :) But is it needed though? Shouldn't a read block until there is an event, at which point you'll have access to the data structures long enough to output data. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMC core debugfs support (was Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers)
On Thu, 14 Feb 2008 15:00:05 +0100 Haavard Skinnemoen [EMAIL PROTECTED] wrote: I've started working on this, but I've run into a problem: The mmc core structures don't seem to keep any references to the current request. So I don't really have any information to put into the 'req' file after moving it into the core. Any ideas on how to solve this? The simple solution is just to add it. :) But is it needed though? Shouldn't a read block until there is an event, at which point you'll have access to the data structures long enough to output data. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMC card detection
On Thu, 21 Feb 2008 19:46:20 +0100 Haavard Skinnemoen [EMAIL PROTECTED] wrote: When the card is reinserted, the MMC core will try to send a SEND_STATUS command again. This time, the card won't respond because it is in the idle state, and the MMC core will think the card is gone. In order to fix this problem, I think I need a way to tell the MMC core that the card really is gone and that there's no point trying to communicate with it. Is there any way I can do that? As you found out, you can. But the MMC core doesn't treat it differently. What is really needed is that the core should make an extra pass and see if the card has been replaced by something else (and not just check if it is gone). It's on my todo, but I haven't had time to implement it. Rgds Pierre signature.asc Description: PGP signature
Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Sun, 24 Feb 2008 10:33:34 -0500 (EST) Alan Stern [EMAIL PROTECTED] wrote: Well, the patch itself isn't really adequate; it was just a first pass intended to illustrate the nature of the problem. The problems in the MMC subsystem go deeper. The first is the way it uses flush_workqueue(). This is almost always a bad function to call, because it introduces unnecessary dependencies. cancel_delayed_work_sync() is much better. But even changing that won't solve the second issue, which is a genuine bug. There is a race between detect events and suspend events. The mmc_suspend_host() routine starts out by flushing the kmmcd workqueue before calling the host's suspend routine. So what happens if another detect event occurs in between? The idea is that host drivers shouldn't do that. Once they've called mmc_suspend_host(), then they shouldn't be poking the MMC core in any other way. None of this is of course properly documented. :/ This whole area of synchronization between card insertion, card removal, suspend, and resume needs to be thought out better. Especially keeping in mind that device registration or unregistration during a system sleep is likely to block until the sleep is over. Trying to keep up with the PM changes is a full time job. For now I've mostly ignored it as I don't even have time for the other stuff. Patches welcome. Lastly, there are some other questions about confusing aspects of the subsystem. What's the story with __mmc_claim_host()? Is it really nothing more than an abortable mutex_lock()? Why does it ever need to be aborted? Why is its second argument an atomic_t instead of a normal int? It got that way when SDIO got in. It was needed to make it abortable to solve a rather nasty deadlock situation. I don't remember the details right now, but it should be in the LKML archives. Why are mmc_detect() and related routines described in comments as Card detection callback from host? They don't handle card _detection_ -- they handle card _removal_. They handle both. What's the purpose of the card-counting loop in host/omap.c:mmc_omap_switch_handler()? It looks like dead code. I'm not too familiar with that driver, but they've been playing around with multiplexing several cards into one controller. Might be bits and pieces of that. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Mon, 25 Feb 2008 12:58:30 -0500 (EST) Alan Stern [EMAIL PROTECTED] wrote: Thanks for the explanations. On Mon, 25 Feb 2008, Pierre Ossman wrote: Trying to keep up with the PM changes is a full time job. For now I've mostly ignored it as I don't even have time for the other stuff. Patches welcome. What do you think of the patch attached to comment #40 in the Bugzilla entry? Looks ok. As long as those two synchronization points are guaranteed, then I'm happy. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 14:26:16 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > Do I understand this correctly? You've got special handling for the > case where a bus handler doesn't have a resume routine, but no special > handling for the case where it doesn't have a suspend routine? Hmm... There should be checks for both, but the code seems to suggest otherwise. > Why bother to remove the device if neither routine exists (there won't be > any need to revive it since the bus never got suspended)? The bus always gets suspended. The checks are to determine if state is saved or not. If it isn't, then a suspend/resume is treated as a removal/insertion. > And why not simply fail the suspend if the resume routine doesn't exist > and the suspend routine does? Maybe with an error message in the > system log. For the asymmetric case, I guess that would do. But I still want to remove devices when the bus handler has no suspend handling. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 11:42:56 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > > > --- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 --- > > Thanks a lot for the debugging work! > > > > First, the patch triggers, which means that the problem discovered by Alan > > is > > troubling us. [Alan, do you have an idea how to fix that cleanly?] > > I suggest we ask the maintainer for the MMC subsystem. > > Pierre, you can find the details in the bugzilla entry. Briefly, > there's a pathway in the MMC core suspend routine (if the driver > doesn't implement a resume hook) which could lead to the host being > removed during a system suspend. This is an illegal operation and it > will deadlock. > > Do you have a suggestion for a way to fix it? > Not really. But you have some things confused. What it checks is if the mmc bus handler (not a proper driver model, just a way of separating the MMC, SD and SDIO stuff) has a resume function. And if it doesn't, it removes the card (since it cannot revive it at resume). So the only thing I can think of is to delay the removal until the resume routine, if that is safer. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 11:42:56 -0500 (EST) Alan Stern [EMAIL PROTECTED] wrote: --- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 --- Thanks a lot for the debugging work! First, the patch triggers, which means that the problem discovered by Alan is troubling us. [Alan, do you have an idea how to fix that cleanly?] I suggest we ask the maintainer for the MMC subsystem. Pierre, you can find the details in the bugzilla entry. Briefly, there's a pathway in the MMC core suspend routine (if the driver doesn't implement a resume hook) which could lead to the host being removed during a system suspend. This is an illegal operation and it will deadlock. Do you have a suggestion for a way to fix it? Not really. But you have some things confused. What it checks is if the mmc bus handler (not a proper driver model, just a way of separating the MMC, SD and SDIO stuff) has a resume function. And if it doesn't, it removes the card (since it cannot revive it at resume). So the only thing I can think of is to delay the removal until the resume routine, if that is safer. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 14:26:16 -0500 (EST) Alan Stern [EMAIL PROTECTED] wrote: Do I understand this correctly? You've got special handling for the case where a bus handler doesn't have a resume routine, but no special handling for the case where it doesn't have a suspend routine? Hmm... There should be checks for both, but the code seems to suggest otherwise. Why bother to remove the device if neither routine exists (there won't be any need to revive it since the bus never got suspended)? The bus always gets suspended. The checks are to determine if state is saved or not. If it isn't, then a suspend/resume is treated as a removal/insertion. And why not simply fail the suspend if the resume routine doesn't exist and the suspend routine does? Maybe with an error message in the system log. For the asymmetric case, I guess that would do. But I still want to remove devices when the bus handler has no suspend handling. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: random wedges with 2.6.25-rc*
On Tue, 19 Feb 2008 12:55:13 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Pierre Ossman wrote: > > > > Anyone else seeing these problems? Someone should as I've seen the problem > > on both a Lenovo and a HP laptop here. > > > I'm definitely seeing lockups here too. 2.6.24 is fine, 2.6.24-rc1 or > -rc2 locks up a minute or so after a successful boot (either to console > or to X). > > Does the following shed any light? > > http://lkml.org/lkml/2008/2/17/78 > That would explain the lockups in X as the network has been active at those times. But it would be odd if it affects the startup of udev (most likely module loading). 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
random wedges with 2.6.25-rc*
Somewhere post 2.6.24, the kernel started getting very temperamentful. I experience random hangs and wedges very often. Primarily, the udev startup locks up. If I abort it, it just locks up on more or less every action after that. Some quick debugging showed that I had a whole bunch of modprobe processes sitting around. The new CONFIG_USB_ANNOUNCE_NEW_DEVICES setting makes every startup of udev lock up consistently on at least two machines. It does not seem to be the root of the problem as disabling the option just makes the bug very unlikely. I've also seen a couple of lockups in X. Might be a different expression of the same bug, but the effect here is a complete wedge of the user interface. It seems the rest of the machine also locks up, but I haven't confirmed this. Anyone else seeing these problems? Someone should as I've seen the problem on both a Lenovo and a HP laptop here. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
random wedges with 2.6.25-rc*
Somewhere post 2.6.24, the kernel started getting very temperamentful. I experience random hangs and wedges very often. Primarily, the udev startup locks up. If I abort it, it just locks up on more or less every action after that. Some quick debugging showed that I had a whole bunch of modprobe processes sitting around. The new CONFIG_USB_ANNOUNCE_NEW_DEVICES setting makes every startup of udev lock up consistently on at least two machines. It does not seem to be the root of the problem as disabling the option just makes the bug very unlikely. I've also seen a couple of lockups in X. Might be a different expression of the same bug, but the effect here is a complete wedge of the user interface. It seems the rest of the machine also locks up, but I haven't confirmed this. Anyone else seeing these problems? Someone should as I've seen the problem on both a Lenovo and a HP laptop here. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: random wedges with 2.6.25-rc*
On Tue, 19 Feb 2008 12:55:13 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: Pierre Ossman wrote: Anyone else seeing these problems? Someone should as I've seen the problem on both a Lenovo and a HP laptop here. I'm definitely seeing lockups here too. 2.6.24 is fine, 2.6.24-rc1 or -rc2 locks up a minute or so after a successful boot (either to console or to X). Does the following shed any light? http://lkml.org/lkml/2008/2/17/78 That would explain the lockups in X as the network has been active at those times. But it would be odd if it affects the startup of udev (most likely module loading). 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard dead with 45b5035
On Mon, 18 Feb 2008 21:50:12 +0100 Pierre Ossman <[EMAIL PROTECTED]> wrote: > On Mon, 18 Feb 2008 20:50:01 +0100 > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > On Monday, 18 of February 2008, Pierre Ossman wrote: > > > The patch "[RTNETLINK]: Send a single notification on device state > > > changes." kills (at least) > > > the keyboard here. Everything seems to work fine in single user mode, but > > > when init starts > > > spawning of logins, the keyboard goes bye-bye. Even the power button is > > > ignored. :/ > > > > Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . > > > > That solved it. > Perhaps not quite. When I returned to my laptop this morning, the keyboard was gone again. Did a hard reboot, and the machine locked up a few seconds after starting X. I'll see if it can be reproduced... 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard dead with 45b5035
On Mon, 18 Feb 2008 20:50:01 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Monday, 18 of February 2008, Pierre Ossman wrote: > > The patch "[RTNETLINK]: Send a single notification on device state > > changes." kills (at least) > > the keyboard here. Everything seems to work fine in single user mode, but > > when init starts > > spawning of logins, the keyboard goes bye-bye. Even the power button is > > ignored. :/ > > Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . > That solved it. I wonder if that's also why modprobe tends to wedge up with the new USB announce thingy... Tomorrow's debugging will tell. -- -- 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
keyboard dead with 45b5035
The patch "[RTNETLINK]: Send a single notification on device state changes." kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ I've tried just creating another vt with "chvt 2", but that is insufficient to trigger the bug. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
keyboard dead with 45b5035
The patch [RTNETLINK]: Send a single notification on device state changes. kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ I've tried just creating another vt with chvt 2, but that is insufficient to trigger the bug. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard dead with 45b5035
On Mon, 18 Feb 2008 20:50:01 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 18 of February 2008, Pierre Ossman wrote: The patch [RTNETLINK]: Send a single notification on device state changes. kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . That solved it. I wonder if that's also why modprobe tends to wedge up with the new USB announce thingy... Tomorrow's debugging will tell. -- -- 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard dead with 45b5035
On Mon, 18 Feb 2008 21:50:12 +0100 Pierre Ossman [EMAIL PROTECTED] wrote: On Mon, 18 Feb 2008 20:50:01 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 18 of February 2008, Pierre Ossman wrote: The patch [RTNETLINK]: Send a single notification on device state changes. kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . That solved it. Perhaps not quite. When I returned to my laptop this morning, the keyboard was gone again. Did a hard reboot, and the machine locked up a few seconds after starting X. I'll see if it can be reproduced... 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Tue, 29 Jan 2008 19:10:13 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> +
> +/* Those printks take an awful lot of time... */
> +#ifndef DEBUG
> +static unsigned int fmax = 1500U;
> +#else
> +static unsigned int fmax = 100U;
> +#endif
> +module_param(fmax, uint, 0444);
> +MODULE_PARM_DESC(fmax, "Max frequency in Hz of the MMC bus clock");
> +
I think this was meant to go away.
> +
> +static int req_dbg_open(struct inode *inode, struct file *file)
> +{
And this should go into the core.
> +
> +static int __exit atmci_remove(struct platform_device *pdev)
> +{
> + struct atmel_mci *host = platform_get_drvdata(pdev);
> +
> + platform_set_drvdata(pdev, NULL);
> +
> + if (host) {
> + atmci_cleanup_debugfs(host);
> +
> + if (host->detect_pin >= 0) {
> + free_irq(gpio_to_irq(host->detect_pin),host->mmc);
> + cancel_delayed_work(>mmc->detect);
I also pointed this out. mmc_remove_host() will synchronize this for
you.
--
-- 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: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Tue, 29 Jan 2008 19:10:13 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
+
+/* Those printks take an awful lot of time... */
+#ifndef DEBUG
+static unsigned int fmax = 1500U;
+#else
+static unsigned int fmax = 100U;
+#endif
+module_param(fmax, uint, 0444);
+MODULE_PARM_DESC(fmax, Max frequency in Hz of the MMC bus clock);
+
I think this was meant to go away.
+
+static int req_dbg_open(struct inode *inode, struct file *file)
+{
And this should go into the core.
+
+static int __exit atmci_remove(struct platform_device *pdev)
+{
+ struct atmel_mci *host = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+
+ if (host) {
+ atmci_cleanup_debugfs(host);
+
+ if (host-detect_pin = 0) {
+ free_irq(gpio_to_irq(host-detect_pin),host-mmc);
+ cancel_delayed_work(host-mmc-detect);
I also pointed this out. mmc_remove_host() will synchronize this for
you.
--
-- 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: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: MAINTAINERS |3 - drivers/mmc/host/Kconfig |8 +- drivers/mmc/host/at91_mci.c | 114 +- drivers/mmc/host/ricoh_mmc.c | 162 ++--- drivers/mmc/host/sdhci.c | 13 +++- drivers/mmc/host/sdhci.h |1 + 6 files changed, 231 insertions(+), 70 deletions(-) David Brownell (1): at91_mci: use generic GPIO calls Feng Tang (1): sdhci: add num index for multi controllers case Frank Seidel (1): mmc: extend ricoh_mmc to support Ricoh RL5c476 Philip Langdale (1): mmc: Handle suspend/resume in Ricoh MMC disabler Pierre Ossman (2): mmc: remove sdhci and mmc_spi experimental markers MAINTAINERS: remove non-existant URLs -- -- 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: MAINTAINERS |3 - drivers/mmc/host/Kconfig |8 +- drivers/mmc/host/at91_mci.c | 114 +- drivers/mmc/host/ricoh_mmc.c | 162 ++--- drivers/mmc/host/sdhci.c | 13 +++- drivers/mmc/host/sdhci.h |1 + 6 files changed, 231 insertions(+), 70 deletions(-) David Brownell (1): at91_mci: use generic GPIO calls Feng Tang (1): sdhci: add num index for multi controllers case Frank Seidel (1): mmc: extend ricoh_mmc to support Ricoh RL5c476 Philip Langdale (1): mmc: Handle suspend/resume in Ricoh MMC disabler Pierre Ossman (2): mmc: remove sdhci and mmc_spi experimental markers MAINTAINERS: remove non-existant URLs -- -- 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Tokyo Electron SDIO controller (Ellen) support
On Mon, 3 Dec 2007 14:39:26 + Ben Dooks <[EMAIL PROTECTED]> wrote: > On Mon, Dec 03, 2007 at 08:22:07AM -0600, Matt Porter wrote: > > > > What's the status of Ben's separation patches? I haven't seen a posting of > > those > > versus a recent kernel. I've got some SDHCI driver glue for the non-pci > > Arasan core > > running in an older kernel tree with those patches. It's just waiting for > > the separation > > patches to hit the mmc or mainline tree. > > I need to go back and try and sort out the last of Pierre's last > comments, and update to the latest kernel version. I was waiting > for 2.6.24-rc4 to re-start the effort to try and ensure there are > fewer changes due to fixes. > Any progress on this little project? Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH] Tokyo Electron SDIO controller (Ellen) support
On Mon, 3 Dec 2007 14:39:26 + Ben Dooks [EMAIL PROTECTED] wrote: On Mon, Dec 03, 2007 at 08:22:07AM -0600, Matt Porter wrote: What's the status of Ben's separation patches? I haven't seen a posting of those versus a recent kernel. I've got some SDHCI driver glue for the non-pci Arasan core running in an older kernel tree with those patches. It's just waiting for the separation patches to hit the mmc or mainline tree. I need to go back and try and sort out the last of Pierre's last comments, and update to the latest kernel version. I was waiting for 2.6.24-rc4 to re-start the effort to try and ensure there are fewer changes due to fixes. Any progress on this little project? Rgds Pierre signature.asc Description: PGP signature
Re: SDIO driver not receiving responses
Don't hijack threads, it completely messes up everyone's mail box and makes your mail very difficult to find. On Thu, 31 Jan 2008 17:35:51 +1100 Farbod Nejati <[EMAIL PROTECTED]> wrote: > The mmc_send_io_op_cond() function call in core.c::mmc_rescan() is > returning with a -110 (a timeout error). I traced this deeper and > noticed that CMD5 is being sent out via sdhci.c::sdhci_send_command() (I > verified this using a logic analyser, the host *is* transmitting a CMD5 > [IO_SEND_OP_COND] packet in the correct format). However, when the > client responds with the IO_SEND_OP_COND Response R4 (SD mode), it does > not seem to be received by the host. Again, I verified using the logic > analyser that the response is as would be expected. An IRQ *is* > triggered, however it is 0x00018000 (SDHCI_INT_TIMEOUT|SDHCI_INT_ERROR). > I'm not too familiar with Linux kernel programming but I suspect that > whatever is waiting for a valid response is giving up instead and > triggering the above-mentioned interrupt instead. That would be the hardware. We don't do any software timeout handling. Have you checked the time from command to reply with the logic analyser? The chip might simply be out of spec. > > Why would the output of the above code differ from the one produced by > lspci -xxx. Could this have something to do with this issue??? > lspci shows you the PCI config space, not the device io space, which is what your code dumped. ;) > > I'm fresh out of ideas on this one and would greatly appreciate some > hints or assistance. I'm happy to provide any further information if needed. > I can only see one of two options here. Either there is some miscalculation of the timeout, or you have a hardware bug. And to determine that we need to check what is actually going over the wire. As you've checked the data contents, that isn't the problem. So the only remaining thing is checking the timing. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure version 1
On Thu, 7 Feb 2008 00:10:16 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote: > > My Toshiba SD-512-T card (Toshiba-specific specs are available as > TOSHIBA_SD_Card_Specification.pdf) shows the same "SCR structure version 1" > error message with 2.6.24 on a Motorola E680 (PXAMCI), whereas > on 2.6.21 it did _NOT_ have it (and all SCR values there are a 1:1 match > with the values listed in the spec .pdf!). > > For me at least it turned out that while on 2.6.21, raw_scr had > 0x00a5 0x10011602 > on 2.6.24 raw_scr had > 0x10011602 0x > Ouch. That would explain more or less any SCR related bug. :) > IOW, the whole thing is simply shifted by one unsigned int, rendering any > SCR interpretation fatally wrong (which, I believe, could be a > _permanent_ error in the SD stack itself which randomly - > depending on the exact bit content of a card's SCR dump - > causes the SCR version check to trigger for various cards). > Is this unsigned int shifting due to a transfer setup issue in the > highlevel SD stack or do you think it is due to a setup issue in the > lower-level pxamci driver in my case? If so, what setting could have > distorted it? I'm not seeing it on any controller here, so right now I'd guess a driver problem. No idea why though. Are you seeing this effect on other cards? > Weak voltage settings are not to blame, I believe (removed some configs to > increase a bit from minimum supported voltage). > If you don't have any specific ideas yet, any hints on how to proceed > with tracking this down? There's always bisecting the issue until you find the offending commit. Time consuming, but it gets the job done. Other than that, try adding some printk() to pxamci's data transfer routines and dump the data when it is fresh. > > I'd advise at least adding dumping the raw_scr values > in the SCR version error to be able to track such error postings better > in the future. > It's definitely something to remember in future bug reports. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/18] MMC: OMAP: Introduce new multislot structure and change driver to use it
On Mon, 28 Jan 2008 15:07:23 -0400
Carlos Aguiar <[EMAIL PROTECTED]> wrote:
> From: Juha Yrjola <[EMAIL PROTECTED]>
>
> Introduce new MMC multislot structure and change driver to use it.
>
> Note that MMC clocking is now enabled in mmc_omap_select_slot()
> and disabled in mmc_omap_release_slot().
>
> Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]>
> Signed-off-by: Jarkko Lavinen <[EMAIL PROTECTED]>
> Signed-off-by: Carlos Eduardo Aguiar <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
I still think this muxed mmc host thing is a bad idea, but it's your
nightmare...
> +
> +/* Access to the R/O switch is required for production testing
> + * purposes. */
> +static ssize_t
> +mmc_omap_show_ro(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + struct mmc_host *mmc = container_of(dev, struct mmc_host, class_dev);
> + struct mmc_omap_slot *slot = mmc_priv(mmc);
> +
> + return sprintf(buf, "%d\n", slot->pdata->get_ro(mmc_dev(mmc),
> + slot->id));
> +}
> +
> +static DEVICE_ATTR(ro, S_IRUGO, mmc_omap_show_ro, NULL);
> +
This is unrelated to the slot stuff and should be in its own patch. Also, it
should probably be in the core, not a driver.
> +
> + mmc->caps = MMC_CAP_MULTIWRITE | MMC_CAP_MMC_HIGHSPEED |
> + MMC_CAP_SD_HIGHSPEED;
This is also unrelated. From what I've seen, the OMAP is a SD controller and
does not support high speed MMC. The fact that you also conditionally set the
max frequency later also suggests that this code is entirely incorrect.
> +
> + r = mmc_add_host(mmc);
> + if (r < 0)
> + return r;
> +
> + if (slot->pdata->name != NULL) {
> + r = device_create_file(>class_dev,
> + _attr_slot_name);
> + if (r < 0)
> + goto err_remove_host;
> + }
> +
> + if (slot->pdata->get_ro != NULL) {
> + r = device_create_file(>class_dev,
> + _attr_ro);
> + }
> +
You have a bit of a race here with userspace in case you use the uevent to
trigger things.
--
-- 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: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/18] MMC: OMAP: Include missing from previous merging
On Mon, 28 Jan 2008 15:07:06 -0400 Carlos Aguiar <[EMAIL PROTECTED]> wrote: > From: Carlos Eduardo Aguiar <[EMAIL PROTECTED]> > > This patch adds an include missing from previous merging > mainline tree into linux-omap tree. > > Signed-off-by: Carlos Eduardo Aguiar <[EMAIL PROTECTED]> > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> > --- NAK. This header should not be needed in host drivers. It's a clear sign you're doing something bad. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc: extend ricoh_mmc to support Ricoh RL5c476
On Thu, 7 Feb 2008 09:20:38 +0100 Frank Seidel <[EMAIL PROTECTED]> wrote: > > > > Wouldn't it be prudent to have a check that this is indeed a R5C832, > > and a failure mode if it's none of the two known devices? > > Also thought about that, but as far as i can see this cannot happen since > we only probe for those two devices and deny to continue if anything else > /those two were not found in the beginning. > Can never be too careful though. :) I've applied the patch for now. Feel free to keep digging and finding some docs for those regs though. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH] at91_mci: use generic GPIO calls
On Mon, 04 Feb 2008 18:12:48 +0100 Nicolas Ferre <[EMAIL PROTECTED]> wrote: > From: David Brownell <[EMAIL PROTECTED]> > > Update the AT91 MMC driver to use the generic GPIO calls instead of the > AT91-specific calls; and to request (and release) those GPIO signals. > > That required updating the probe() fault cleanup codepaths. Now there > is a single sequence for freeing resources, in reverse order of their > allocation. Also that code uses use dev_*() for messaging, and has less > abuse of KERN_ERR. > > Likewise with updating remove() cleanup. This had to free the GPIOs, > and while adding that code I noticed and fixed two other problems: it > was poking at a workqueue owned by the mmc core; and in one (rare) > case would try freeing an IRQ that it didn't allocate. > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> > --- Applied thanks. -- -- 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc: extend ricoh_mmc to support Ricoh RL5c476
On Mon, 4 Feb 2008 19:25:42 +0100
Frank Seidel <[EMAIL PROTECTED]> wrote:
> From: Frank Seidel <[EMAIL PROTECTED]>
>
> This patch (base on current linus git tree plus Philip Langdales
> suspend/resume patch) adds support for the Ricoh RL5c476 chip:
> with this the mmc adapter that needs this disabler (R5C843) can
> also be handled correctly when it sits on a RL5c476.
> (+ minor style changes (removed spaces between function names
> and open parenthesis .. checkpatch warned from previos patch))
>
> Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
I see you've guys have kept yourself busy in my absence. :)
As for the patch, it looks ok although I'm not really a fan of more voodoo
constants that noone knows what they mean. Could you add some comments
explaining some of them at least?
> + if (fw_dev->device == PCI_DEVICE_ID_RICOH_RL5C476) {
*snip*
> + } else {
> + /* via R5C832 */
Wouldn't it be prudent to have a check that this is indeed a R5C832, and a
failure mode if it's none of the two known devices?
Rgds
Pierre
signature.asc
Description: PGP signature
Re: [PATCH v2] mmc: extend ricoh_mmc to support Ricoh RL5c476
On Mon, 4 Feb 2008 19:25:42 +0100
Frank Seidel [EMAIL PROTECTED] wrote:
From: Frank Seidel [EMAIL PROTECTED]
This patch (base on current linus git tree plus Philip Langdales
suspend/resume patch) adds support for the Ricoh RL5c476 chip:
with this the mmc adapter that needs this disabler (R5C843) can
also be handled correctly when it sits on a RL5c476.
(+ minor style changes (removed spaces between function names
and open parenthesis .. checkpatch warned from previos patch))
Signed-off-by: Frank Seidel [EMAIL PROTECTED]
I see you've guys have kept yourself busy in my absence. :)
As for the patch, it looks ok although I'm not really a fan of more voodoo
constants that noone knows what they mean. Could you add some comments
explaining some of them at least?
+ if (fw_dev-device == PCI_DEVICE_ID_RICOH_RL5C476) {
*snip*
+ } else {
+ /* via R5C832 */
Wouldn't it be prudent to have a check that this is indeed a R5C832, and a
failure mode if it's none of the two known devices?
Rgds
Pierre
signature.asc
Description: PGP signature
Re: [semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure version 1
On Thu, 7 Feb 2008 00:10:16 +0100 Andreas Mohr [EMAIL PROTECTED] wrote: My Toshiba SD-512-T card (Toshiba-specific specs are available as TOSHIBA_SD_Card_Specification.pdf) shows the same SCR structure version 1 error message with 2.6.24 on a Motorola E680 (PXAMCI), whereas on 2.6.21 it did _NOT_ have it (and all SCR values there are a 1:1 match with the values listed in the spec .pdf!). For me at least it turned out that while on 2.6.21, raw_scr had 0x00a5 0x10011602 on 2.6.24 raw_scr had 0x10011602 0x Ouch. That would explain more or less any SCR related bug. :) IOW, the whole thing is simply shifted by one unsigned int, rendering any SCR interpretation fatally wrong (which, I believe, could be a _permanent_ error in the SD stack itself which randomly - depending on the exact bit content of a card's SCR dump - causes the SCR version check to trigger for various cards). Is this unsigned int shifting due to a transfer setup issue in the highlevel SD stack or do you think it is due to a setup issue in the lower-level pxamci driver in my case? If so, what setting could have distorted it? I'm not seeing it on any controller here, so right now I'd guess a driver problem. No idea why though. Are you seeing this effect on other cards? Weak voltage settings are not to blame, I believe (removed some configs to increase a bit from minimum supported voltage). If you don't have any specific ideas yet, any hints on how to proceed with tracking this down? There's always bisecting the issue until you find the offending commit. Time consuming, but it gets the job done. Other than that, try adding some printk() to pxamci's data transfer routines and dump the data when it is fresh. I'd advise at least adding dumping the raw_scr values in the SCR version error to be able to track such error postings better in the future. It's definitely something to remember in future bug reports. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SDIO driver not receiving responses
Don't hijack threads, it completely messes up everyone's mail box and makes your mail very difficult to find. On Thu, 31 Jan 2008 17:35:51 +1100 Farbod Nejati [EMAIL PROTECTED] wrote: The mmc_send_io_op_cond() function call in core.c::mmc_rescan() is returning with a -110 (a timeout error). I traced this deeper and noticed that CMD5 is being sent out via sdhci.c::sdhci_send_command() (I verified this using a logic analyser, the host *is* transmitting a CMD5 [IO_SEND_OP_COND] packet in the correct format). However, when the client responds with the IO_SEND_OP_COND Response R4 (SD mode), it does not seem to be received by the host. Again, I verified using the logic analyser that the response is as would be expected. An IRQ *is* triggered, however it is 0x00018000 (SDHCI_INT_TIMEOUT|SDHCI_INT_ERROR). I'm not too familiar with Linux kernel programming but I suspect that whatever is waiting for a valid response is giving up instead and triggering the above-mentioned interrupt instead. That would be the hardware. We don't do any software timeout handling. Have you checked the time from command to reply with the logic analyser? The chip might simply be out of spec. Why would the output of the above code differ from the one produced by lspci -xxx. Could this have something to do with this issue??? lspci shows you the PCI config space, not the device io space, which is what your code dumped. ;) I'm fresh out of ideas on this one and would greatly appreciate some hints or assistance. I'm happy to provide any further information if needed. I can only see one of two options here. Either there is some miscalculation of the timeout, or you have a hardware bug. And to determine that we need to check what is actually going over the wire. As you've checked the data contents, that isn't the problem. So the only remaining thing is checking the timing. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/18] MMC: OMAP: Include missing from previous merging
On Mon, 28 Jan 2008 15:07:06 -0400 Carlos Aguiar [EMAIL PROTECTED] wrote: From: Carlos Eduardo Aguiar [EMAIL PROTECTED] This patch adds an include missing from previous merging mainline tree into linux-omap tree. Signed-off-by: Carlos Eduardo Aguiar [EMAIL PROTECTED] Signed-off-by: Tony Lindgren [EMAIL PROTECTED] --- NAK. This header should not be needed in host drivers. It's a clear sign you're doing something bad. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] at91_mci: minor cleanup
On Wed, 30 Jan 2008 17:45:48 +0100 Nicolas Ferre <[EMAIL PROTECTED]> wrote: > From: Marc Pignat <[EMAIL PROTECTED]> > > MMC_POWER_ON is a noop, no need to set the power pin again. > > Signed-off-by: Marc Pignat <[EMAIL PROTECTED]> > Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> > --- Perhaps also a WARN_ON() or something in the default case to catch bad invokations? Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH] at91_mci: minor cleanup
On Wed, 30 Jan 2008 17:45:48 +0100 Nicolas Ferre [EMAIL PROTECTED] wrote: From: Marc Pignat [EMAIL PROTECTED] MMC_POWER_ON is a noop, no need to set the power pin again. Signed-off-by: Marc Pignat [EMAIL PROTECTED] Signed-off-by: Nicolas Ferre [EMAIL PROTECTED] --- Perhaps also a WARN_ON() or something in the default case to catch bad invokations? Rgds Pierre signature.asc Description: PGP signature
Re: [patch] split MMC_CAP_4_BIT_DATA
On Sat, 12 Jan 2008 08:02:37 -0500 Robin Getz <[EMAIL PROTECTED]> wrote: > > According to the HW folks - it is exactly as Pierre indicated - in theory it > should work, 4-bit MMC requires usage of different set of commands as > compared to 4-bit SD, so it should be just software - although no one has > tested it yet. > > So I guess this is back on Bryan/Cliff to make work > > Thanks for pushing back. > It's what I do ;) If you provide some dumps of your test runs next week, I'm sure I can help with some qualified guesses as to what the problem might be. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Sat, 12 Jan 2008 14:39:47 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > On 12-01-08 12:12, Pierre Ossman wrote: > > > I'm a bit confused here. Bjorn Helgaas wanted to remove the > > pnp_start/stop_dev() calls completely, and you want them called all the > > time. :) > > Wanted where? Haven't seen a coment from Bjorn? But -- while removing them > both looks (as) sensible from a mirror-image viewpoint, this wouldn't fix > the problem. > Ah, sorry. It was a different thread. Look for a mail with the subject "PNP: do not stop/start devices in suspend/resume path" in the LKML och linux-pm archives. > > But we certainly need the pnp_start_dev() in the current flow of things. It > not being called is the problem this fixes... > I think the previous suggestion was that the drivers should call this, not the core, so that it behaved more like other parts of the kernel (e.g. PCI). Rgds Pierre signature.asc Description: PGP signature
Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Sat, 12 Jan 2008 02:23:27 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > > Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for > Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test > triggering in pnp_bus_resume() and keeping the card in a suspended state. > I'm a bit confused here. Bjorn Helgaas wanted to remove the pnp_start/stop_dev() calls completely, and you want them called all the time. :) Rgds Pierre signature.asc Description: PGP signature
Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Sat, 12 Jan 2008 02:23:27 +0100 Rene Herman [EMAIL PROTECTED] wrote: Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test triggering in pnp_bus_resume() and keeping the card in a suspended state. I'm a bit confused here. Bjorn Helgaas wanted to remove the pnp_start/stop_dev() calls completely, and you want them called all the time. :) Rgds Pierre signature.asc Description: PGP signature
Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Sat, 12 Jan 2008 14:39:47 +0100 Rene Herman [EMAIL PROTECTED] wrote: On 12-01-08 12:12, Pierre Ossman wrote: I'm a bit confused here. Bjorn Helgaas wanted to remove the pnp_start/stop_dev() calls completely, and you want them called all the time. :) Wanted where? Haven't seen a coment from Bjorn? But -- while removing them both looks (as) sensible from a mirror-image viewpoint, this wouldn't fix the problem. Ah, sorry. It was a different thread. Look for a mail with the subject PNP: do not stop/start devices in suspend/resume path in the LKML och linux-pm archives. But we certainly need the pnp_start_dev() in the current flow of things. It not being called is the problem this fixes... I think the previous suggestion was that the drivers should call this, not the core, so that it behaved more like other parts of the kernel (e.g. PCI). Rgds Pierre signature.asc Description: PGP signature
Re: [patch] split MMC_CAP_4_BIT_DATA
On Sat, 12 Jan 2008 08:02:37 -0500 Robin Getz [EMAIL PROTECTED] wrote: According to the HW folks - it is exactly as Pierre indicated - in theory it should work, 4-bit MMC requires usage of different set of commands as compared to 4-bit SD, so it should be just software - although no one has tested it yet. So I guess this is back on Bryan/Cliff to make work Thanks for pushing back. It's what I do ;) If you provide some dumps of your test runs next week, I'm sure I can help with some qualified guesses as to what the problem might be. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Fri, 11 Jan 2008 18:22:14 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote: > > I guess it is for MMC/SD card insert detection. Is it related with the > 4-bit MMC and 4-bit SD? > Actually, there are some issues about the card insert detection on > BF54x SDH. Following is some comments of our bfin-sdh driver which is > in the development. > Right. As you've noticed, that pin is not a reliable way of detecting cards. It works badly, if all, for MMC cards. And some SD cards also lack the necessary pull-up. But for the matter at hand, some cards might rely on the pull-up being there, so you'll get bit-errors without it. I don't have time to double check the specs right now, but it might explain why you're seeing problems with MMC and not SD. Btw, the MMC core sends you ios information on how you should fiddle with that bit. It was needed on a Winbond controller (the wbsd driver) as some models relied on it for card detection. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Fri, 11 Jan 2008 04:47:44 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > Cliff should be able to enumerate the cards he has tested and the > issues he's run into. i'll see if i cant get more in depth > information from the hardware guys beyond the documentation on the sdh > already available in the hardware manual (which i'm guessing has not > been enough to appease you). > Great. And you're right in that the spec did not give any indication that MMC shouldn't work. I did notice one thing though. The pull-ups and pull-downs seem to be controllable. If I remember correctly, DAT3 needs to have a controller-side pull-up for MMC cards. And the docs said the default was not to provide that (in order to use the internal pull-up that most, but not all, SD cards have for detection). Might be something to look at if you haven't already. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Fri, 11 Jan 2008 04:08:53 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote: > > So it's far more probable that you've misdiagnosed your error than this > > being the actual problem. > > the guys who design the silicon are telling us it doesnt work. our > tests show it not working. i'm not sure what else you want here. > More information. You have not provided any speculation as to why it doesn't work, or what you've done to figure it out. You haven't even described how it fails, just that it does. No information about what cards you've tested and how you've tested them to confirm that your theory on 4-bit data is accurate. You have no track record with me, and you're proposing something that goes against all known information. So you have to understand that I'm sceptical about your claims. I won't dismiss them off hand, but I need to be convinced you haven't made a mistake when coming to this conclusion. > > The fact that 4-bit MMC support has been present for some time and you're > > only now seeing a problem further supports that. > > not in the least actually. we just started developing the driver. it > has seen no real world use. we've been testing things internally to > make sure the setup is sane. 4-bit MMC is coming up as not working. Fair enough. But if it's a new driver that hasn't seen real-world testing, then there might be other bugs influencing things. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Fri, 11 Jan 2008 14:17:01 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote: > We were told this is an hardware design issue, so please help us to > workaround it in software side with Mike's patch. I'm afraid that's insufficient motivation for this change. All documentation and real world tests say that MMC and SD 4-bit data is 100% compatible. So it's far more probable that you've misdiagnosed your error than this being the actual problem. The fact that 4-bit MMC support has been present for some time and you're only now seeing a problem further supports that. In light of that, the suggested patch would not only be incorrect, it would also be worse than doing nothing. You would be papering over a symptom, making the real problem harder to find. If you want something ready for upstream, for now I suggest removing MMC_CAP_4_BIT_DATA completely from your driver's caps field. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 libertas_sdio fails to initialize Marvell SD8686
On Wed, 09 Jan 2008 14:53:58 -0500
Bill Gribble <[EMAIL PROTECTED]> wrote:
>
> Any other sage advice? I feel like the device is really close to
> working, but I just can't get it there!
>
Since you're having problems with the very first part, I'm not sure I'd agree
with your assessment. ;)
The fact is that the libertas chips are extremely moody, and Marvell has the
weird attitude that there is one driver and one firmware per
board/implementation, not per chip model. So friction is bound to appear when
we try to have a generic driver that supports all of these different revisions.
So that means there's two options for you right now; experiment wildly and hope
you get lucky and find how to avoid whatever bug your particular chip has, or
try to get information from Marvell or Raon about how to interface with the
chip.
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: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 libertas_sdio fails to initialize Marvell SD8686
On Wed, 09 Jan 2008 14:53:58 -0500 Bill Gribble [EMAIL PROTECTED] wrote: Any other sage advice? I feel like the device is really close to working, but I just can't get it there! Since you're having problems with the very first part, I'm not sure I'd agree with your assessment. ;) The fact is that the libertas chips are extremely moody, and Marvell has the weird attitude that there is one driver and one firmware per board/implementation, not per chip model. So friction is bound to appear when we try to have a generic driver that supports all of these different revisions. So that means there's two options for you right now; experiment wildly and hope you get lucky and find how to avoid whatever bug your particular chip has, or try to get information from Marvell or Raon about how to interface with the chip. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Fri, 11 Jan 2008 14:17:01 +0800 Bryan Wu [EMAIL PROTECTED] wrote: We were told this is an hardware design issue, so please help us to workaround it in software side with Mike's patch. I'm afraid that's insufficient motivation for this change. All documentation and real world tests say that MMC and SD 4-bit data is 100% compatible. So it's far more probable that you've misdiagnosed your error than this being the actual problem. The fact that 4-bit MMC support has been present for some time and you're only now seeing a problem further supports that. In light of that, the suggested patch would not only be incorrect, it would also be worse than doing nothing. You would be papering over a symptom, making the real problem harder to find. If you want something ready for upstream, for now I suggest removing MMC_CAP_4_BIT_DATA completely from your driver's caps field. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Fri, 11 Jan 2008 04:08:53 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Jan 11, 2008 3:40 AM, Pierre Ossman [EMAIL PROTECTED] wrote: So it's far more probable that you've misdiagnosed your error than this being the actual problem. the guys who design the silicon are telling us it doesnt work. our tests show it not working. i'm not sure what else you want here. More information. You have not provided any speculation as to why it doesn't work, or what you've done to figure it out. You haven't even described how it fails, just that it does. No information about what cards you've tested and how you've tested them to confirm that your theory on 4-bit data is accurate. You have no track record with me, and you're proposing something that goes against all known information. So you have to understand that I'm sceptical about your claims. I won't dismiss them off hand, but I need to be convinced you haven't made a mistake when coming to this conclusion. The fact that 4-bit MMC support has been present for some time and you're only now seeing a problem further supports that. not in the least actually. we just started developing the driver. it has seen no real world use. we've been testing things internally to make sure the setup is sane. 4-bit MMC is coming up as not working. Fair enough. But if it's a new driver that hasn't seen real-world testing, then there might be other bugs influencing things. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Fri, 11 Jan 2008 04:47:44 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: Cliff should be able to enumerate the cards he has tested and the issues he's run into. i'll see if i cant get more in depth information from the hardware guys beyond the documentation on the sdh already available in the hardware manual (which i'm guessing has not been enough to appease you). Great. And you're right in that the spec did not give any indication that MMC shouldn't work. I did notice one thing though. The pull-ups and pull-downs seem to be controllable. If I remember correctly, DAT3 needs to have a controller-side pull-up for MMC cards. And the docs said the default was not to provide that (in order to use the internal pull-up that most, but not all, SD cards have for detection). Might be something to look at if you haven't already. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Fri, 11 Jan 2008 18:22:14 +0800 Bryan Wu [EMAIL PROTECTED] wrote: I guess it is for MMC/SD card insert detection. Is it related with the 4-bit MMC and 4-bit SD? Actually, there are some issues about the card insert detection on BF54x SDH. Following is some comments of our bfin-sdh driver which is in the development. Right. As you've noticed, that pin is not a reliable way of detecting cards. It works badly, if all, for MMC cards. And some SD cards also lack the necessary pull-up. But for the matter at hand, some cards might rely on the pull-up being there, so you'll get bit-errors without it. I don't have time to double check the specs right now, but it might explain why you're seeing problems with MMC and not SD. Btw, the MMC core sends you ios information on how you should fiddle with that bit. It was needed on a Winbond controller (the wbsd driver) as some models relied on it for card detection. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Fri, 11 Jan 2008 02:19:07 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > > I see a PnP resume _consists_ of setting the resources so I can see the test > implementation wise, but yes, conceptually it seems this test shouldn't be > present. So just like the attached then? > > Pierre, what was the idea here? Added the other SOBs to the CC as well... > You assume there was an idea? ;) I don't remember why things were done the way they were. And I can't find any clues in the correspondence around the issue. So your guess is as good as mine. Rgds Pierre signature.asc Description: PGP signature
Re: [patch] split MMC_CAP_4_BIT_DATA
On Thu, 10 Jan 2008 17:22:55 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote: > > At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware > Reference, there is a table which guide us the SDH controller does not > support 4-bit mode MMC card. Please found the table picture in the > attachment or get the document at: > http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf > Ok, but this just means the controller wasn't designed with 4-bit MMC in mind. As several other "SD-only" controller have been tested with modern MMC cards without a problem, this is not sufficient to explain any problem. > > Thanks, actually we are not yet convinced by our hardware designer > why BF54x SDH does not support 4-bit MMC. > Please keep me informed on how it progresses. I'd like an at least plausible explanation, preferably also some empirical data, before I'm ready to accept Mike's patch. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Thu, 10 Jan 2008 00:45:27 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote: > > Actually, Blackfin BF54x on-chip SDIO host controller is supposed to > support 1-bit and 4-bit MMC or SD. But in the real platform, when MMC > works at 4-bit mode there will be a FIFO underrun error > (http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit_item_id=3535). > While SD works at 4-bit mode is OK. We believe this is a hardware > issue of the SDIO host controller of BF54x. Odd. As there shouldn't be a difference, I'm inclined to believe that this is card dependent. So it could as well appear with some SD cards as well. How much have you tested this issue? That tracker entry isn't very verbose. Also, how can an underrun appear? The system should have flow control. And an underrun does not sound like a bus problem, rather that you have a card with different speed characteristics than the hardware/driver can handle. > > We intend to workaround in our own BF54x SDIO host controller driver, > but there is no place for us to determine MMC or SD. One choice is to > hack common code like this: _If_ it truly cannot handle 4-bit MMC, then Mike's patch is the way to go. But I'm not yet convinced that the problem is related to MMC vs SD. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Thu, 10 Jan 2008 00:45:27 +0800 Bryan Wu [EMAIL PROTECTED] wrote: Actually, Blackfin BF54x on-chip SDIO host controller is supposed to support 1-bit and 4-bit MMC or SD. But in the real platform, when MMC works at 4-bit mode there will be a FIFO underrun error (http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdittracker_item_id=3535). While SD works at 4-bit mode is OK. We believe this is a hardware issue of the SDIO host controller of BF54x. Odd. As there shouldn't be a difference, I'm inclined to believe that this is card dependent. So it could as well appear with some SD cards as well. How much have you tested this issue? That tracker entry isn't very verbose. Also, how can an underrun appear? The system should have flow control. And an underrun does not sound like a bus problem, rather that you have a card with different speed characteristics than the hardware/driver can handle. We intend to workaround in our own BF54x SDIO host controller driver, but there is no place for us to determine MMC or SD. One choice is to hack common code like this: _If_ it truly cannot handle 4-bit MMC, then Mike's patch is the way to go. But I'm not yet convinced that the problem is related to MMC vs SD. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Thu, 10 Jan 2008 17:22:55 +0800 Bryan Wu [EMAIL PROTECTED] wrote: At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware Reference, there is a table which guide us the SDH controller does not support 4-bit mode MMC card. Please found the table picture in the attachment or get the document at: http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf Ok, but this just means the controller wasn't designed with 4-bit MMC in mind. As several other SD-only controller have been tested with modern MMC cards without a problem, this is not sufficient to explain any problem. Thanks, actually we are not yet convinced by our hardware designer why BF54x SDH does not support 4-bit MMC. Please keep me informed on how it progresses. I'd like an at least plausible explanation, preferably also some empirical data, before I'm ready to accept Mike's patch. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6: ricoh_mmc woes
On Sat, 05 Jan 2008 21:28:50 +0100 Harald Dunkel <[EMAIL PROTECTED]> wrote: > Hi folks, > > I've got a problem with a Ricoh mmc reader. As soon as I insert a > sd card I get tons of I/O errors. syslog says: > You're getting some kind of bus transfer error. Did this work with 2.6.23? Please enable CONFIG_MMC_DEBUG and include a copy of the output of dmesg. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lba 28-bit addressing mode for MMC/SD card
On Thu, 27 Dec 2007 05:51:46 -0800 (PST) Sandeep K <[EMAIL PROTECTED]> wrote: > Hi all, > > does the linux kernel MMC block layer supports lba > 28-bit > addressing mode for MMC/SD card ? > LBA is not a term used for MMC/SD, so I'm unsure what you're referring to. The MMC layer supports legacy cards, SDHC and MMC 4.2 addressing. All addresses are 32-bit. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lba 28-bit addressing mode for MMC/SD card
On Thu, 27 Dec 2007 05:51:46 -0800 (PST) Sandeep K [EMAIL PROTECTED] wrote: Hi all, does the linux kernel MMC block layer supports lba 28-bit addressing mode for MMC/SD card ? LBA is not a term used for MMC/SD, so I'm unsure what you're referring to. The MMC layer supports legacy cards, SDHC and MMC 4.2 addressing. All addresses are 32-bit. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6: ricoh_mmc woes
On Sat, 05 Jan 2008 21:28:50 +0100 Harald Dunkel [EMAIL PROTECTED] wrote: Hi folks, I've got a problem with a Ricoh mmc reader. As soon as I insert a sd card I get tons of I/O errors. syslog says: You're getting some kind of bus transfer error. Did this work with 2.6.23? Please enable CONFIG_MMC_DEBUG and include a copy of the output of dmesg. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Wed, 9 Jan 2008 11:21:40 +0800 "Cai, Cliff" <[EMAIL PROTECTED]> wrote: > > Hi,all > > I'd like to say something about this issue. > Currently,the blackfin on chip SD host ONLY support 1-bit MMC while > support 1-bit/4-bit SD/SDIO. > And we want our driver to support both 1-bit MMC and 4-bit SD/SDIO.but > the current MMC driver framework > Only allow us to set one kind of bus width,either 1-bit or 4-bit.So in > order to meet our case,we need more flexible mechanism > To inform the upper commom driver to know our situation. > That's just iterating what's already been said. My claim is that 4-bit is 4-bit, regardless if it's MMC or SD. So if you want this patch to go in you need to explain why there is a difference for the blackfin controller. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 16:44:08 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > On Jan 8, 2008 3:49 PM, Pierre Ossman <[EMAIL PROTECTED]> wrote: > > So, again, if you feel that there is a hardware difference between 4-bit > > MMC and 4-bit SD then please elaborate as it is my understanding that they > > are identical. > > you may be 100% correct, i have no idea, i'm not really familiar with > MMC/SD/SDIO at all. The patch adds complexity to the system. So until you can convince me that complexity is actually needed, I'm afraid the answer is NAK. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 14:40:49 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > i dont understand what's confusing. the Blackfin on chip host controller > only > supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it > may be a stupid decision, it is what it is, and i need the framework made > more flexible in order to get the Blackfin driver merged cleanly. we do > software for hardware, we dont do hardware. Well, since I've seen no _hardware_ differences between 4-bit MMC and 4-bit SD, "support" in this case must me "vendor will guarantee it works". And that is not the kind of "support" that needs a distinction in the code. So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Crash in Kernel 2.6.22.1 after calling mmc_register_card
On Mon, 7 Jan 2008 15:31:32 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > Hi All, > > Please CC me on responses. > > I am working on a SD/MMC Host driver . > > I am getting kerenl oops after mmc_register_card () is called. > i working on LINUX 2.6.22.1 kerenl. > > What might be the reason for this. > That's a rather central place for it to crash, so I'm doubtful it's a bug there. I'd guess some kind of memory corruption (an all to easy mistake to make when writing a new driver). Are you using DMA for the controller? If so, try using PIO and see if it stops oopsing. Rgds Pierre signature.asc Description: PGP signature
Re: Replacing drivers/mmc directory in kerenl 2.6.22.1 with drivers/mmc in kernel 2.6.23.1
On Sun, 6 Jan 2008 20:02:46 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > > Can I replace drivers/mmc directory in 2.6.22.1 with drivers/mmc > directory in 2.6.23.1. Does this cause any issues. Is there any code > in drivers/mmc in 2.6.23.1 which depends on other features in kernel > 2.6.23.1. > I'm afraid I've not kept track of such things. Try it and see if it compiles. Rgds Pierre signature.asc Description: PGP signature
Re: [patch] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 13:29:39 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do 1-bit > MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current convention of > MMC_CAP_4_BIT_DATA meaning "your host controller can do 1-bit or 4-bit for all > modes" is insufficient for our needs. The attached patch splits > MMC_CAP_4_BIT_DATA into MMC_CAP_MMC_4_BIT_DATA and MMC_CAP_SD_4_BIT_DATA and > updates all host controllers to include these in their caps and then changes > existing code to check the new defines. At the moment, SD/SDIO are lumped > into MMC_CAP_SD_4_BIT_DATA ... should I bother with splitting that into SD and > SDIO as well while I'm doing this ? > > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> I fail to see why you need to split MMC and SD. Could you elaborate why the controller won't work with MMC cards? I haven't seen any differences from SD. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 13:29:39 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do 1-bit MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current convention of MMC_CAP_4_BIT_DATA meaning your host controller can do 1-bit or 4-bit for all modes is insufficient for our needs. The attached patch splits MMC_CAP_4_BIT_DATA into MMC_CAP_MMC_4_BIT_DATA and MMC_CAP_SD_4_BIT_DATA and updates all host controllers to include these in their caps and then changes existing code to check the new defines. At the moment, SD/SDIO are lumped into MMC_CAP_SD_4_BIT_DATA ... should I bother with splitting that into SD and SDIO as well while I'm doing this ? Signed-off-by: Mike Frysinger [EMAIL PROTECTED] I fail to see why you need to split MMC and SD. Could you elaborate why the controller won't work with MMC cards? I haven't seen any differences from SD. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Replacing drivers/mmc directory in kerenl 2.6.22.1 with drivers/mmc in kernel 2.6.23.1
On Sun, 6 Jan 2008 20:02:46 -0800 raki john [EMAIL PROTECTED] wrote: Can I replace drivers/mmc directory in 2.6.22.1 with drivers/mmc directory in 2.6.23.1. Does this cause any issues. Is there any code in drivers/mmc in 2.6.23.1 which depends on other features in kernel 2.6.23.1. I'm afraid I've not kept track of such things. Try it and see if it compiles. Rgds Pierre signature.asc Description: PGP signature
Re: Crash in Kernel 2.6.22.1 after calling mmc_register_card
On Mon, 7 Jan 2008 15:31:32 -0800 raki john [EMAIL PROTECTED] wrote: Hi All, Please CC me on responses. I am working on a SD/MMC Host driver . I am getting kerenl oops after mmc_register_card () is called. i working on LINUX 2.6.22.1 kerenl. What might be the reason for this. That's a rather central place for it to crash, so I'm doubtful it's a bug there. I'd guess some kind of memory corruption (an all to easy mistake to make when writing a new driver). Are you using DMA for the controller? If so, try using PIO and see if it stops oopsing. Rgds Pierre signature.asc Description: PGP signature
Re: [patch] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 14:40:49 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: i dont understand what's confusing. the Blackfin on chip host controller only supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it may be a stupid decision, it is what it is, and i need the framework made more flexible in order to get the Blackfin driver merged cleanly. we do software for hardware, we dont do hardware. Well, since I've seen no _hardware_ differences between 4-bit MMC and 4-bit SD, support in this case must me vendor will guarantee it works. And that is not the kind of support that needs a distinction in the code. So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Wed, 9 Jan 2008 11:21:40 +0800 Cai, Cliff [EMAIL PROTECTED] wrote: Hi,all I'd like to say something about this issue. Currently,the blackfin on chip SD host ONLY support 1-bit MMC while support 1-bit/4-bit SD/SDIO. And we want our driver to support both 1-bit MMC and 4-bit SD/SDIO.but the current MMC driver framework Only allow us to set one kind of bus width,either 1-bit or 4-bit.So in order to meet our case,we need more flexible mechanism To inform the upper commom driver to know our situation. That's just iterating what's already been said. My claim is that 4-bit is 4-bit, regardless if it's MMC or SD. So if you want this patch to go in you need to explain why there is a difference for the blackfin controller. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Tue, 8 Jan 2008 16:44:08 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Jan 8, 2008 3:49 PM, Pierre Ossman [EMAIL PROTECTED] wrote: So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical. you may be 100% correct, i have no idea, i'm not really familiar with MMC/SD/SDIO at all. The patch adds complexity to the system. So until you can convince me that complexity is actually needed, I'm afraid the answer is NAK. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: Handle suspend/resume in Ricoh MMC disabler
On Sat, 29 Dec 2007 00:11:42 -0800 Philip Langdale <[EMAIL PROTECTED]> wrote: > As pci config space is reinitialised on a suspend/resume cycle, the > disabler needs to work its magic at resume time. For symmetry this > change also explicitly enables the controller at suspend time but > it's not strictly necessary. > > Signed-off-by: Philipl Langdale <[EMAIL PROTECTED]> > Thanks applied. Your patch was a bit borked though (a bunch of extra spaces). You should have a look at that for future patches. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH] mmc: Handle suspend/resume in Ricoh MMC disabler
On Sat, 29 Dec 2007 00:11:42 -0800 Philip Langdale [EMAIL PROTECTED] wrote: As pci config space is reinitialised on a suspend/resume cycle, the disabler needs to work its magic at resume time. For symmetry this change also explicitly enables the controller at suspend time but it's not strictly necessary. Signed-off-by: Philipl Langdale [EMAIL PROTECTED] Thanks applied. Your patch was a bit borked though (a bunch of extra spaces). You should have a look at that for future patches. Rgds Pierre signature.asc Description: PGP signature
Re: Order of Loading mmc driver modules.
On Wed, 26 Dec 2007 10:40:22 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > Hi All, > > I am working with pxamci driver(2.6.22.1). I have made , core and host > as separate modules. > > what is the correct order of loading the modules > > i am doing in this order first core (mmc_core.ko), then card(mmc_block.ko) > after that host driver ( pxamci.ko). Is this correct. > If you're using just insmod, then yes, this is a valid order. The only thing that is crucial is that mmc_core is loaded before any of the other. If you use modprobe that will happen automatically. > I do not know much about Linux device model. > There's lots of info on the web and in the Documentation/ directory of the kernel source if you want to indulge yourself. > i saw that pxamci.ko driver registers it self as platform_driver. When > does its probe function is called. Is it called immediately after > platform_driver_register(_driver) is called. > For pxamci, yes. More specifically, the probe function is called when there is both a driver (created by platform_driver_register()) and a device (platform_device_register()) available. But since the device is added very early in the pxamci case, the magic will happen when the driver registers. > also in card driver (mmc_block.ko) in block.c file i saw a probe > function(mmc_blk_probe). How does it is invoked . > When the corresponding device is registered. In this case it is whenever a card is detected and initialized. Rgds Pierre signature.asc Description: PGP signature
Re: Order of Loading mmc driver modules.
On Wed, 26 Dec 2007 10:40:22 -0800 raki john [EMAIL PROTECTED] wrote: Hi All, I am working with pxamci driver(2.6.22.1). I have made , core and host as separate modules. what is the correct order of loading the modules i am doing in this order first core (mmc_core.ko), then card(mmc_block.ko) after that host driver ( pxamci.ko). Is this correct. If you're using just insmod, then yes, this is a valid order. The only thing that is crucial is that mmc_core is loaded before any of the other. If you use modprobe that will happen automatically. I do not know much about Linux device model. There's lots of info on the web and in the Documentation/ directory of the kernel source if you want to indulge yourself. i saw that pxamci.ko driver registers it self as platform_driver. When does its probe function is called. Is it called immediately after platform_driver_register(pxamci_driver) is called. For pxamci, yes. More specifically, the probe function is called when there is both a driver (created by platform_driver_register()) and a device (platform_device_register()) available. But since the device is added very early in the pxamci case, the magic will happen when the driver registers. also in card driver (mmc_block.ko) in block.c file i saw a probe function(mmc_blk_probe). How does it is invoked . When the corresponding device is registered. In this case it is whenever a card is detected and initialized. Rgds Pierre signature.asc Description: PGP signature
Re: relation between mmc_request, mmc_data and mmc_command
On Sun, 23 Dec 2007 23:25:26 -0800 "raki john" <[EMAIL PROTECTED]> wrote: > > Does mmc_requeest->stop is equal to mmc_request->data->stop ? > > Does mmc_request is equal to mmc_request->data->mrq ? > > Does mmc_request->data is equal to mmc_request->cmd->data ? > > Does mmc_request is equal to mmc_request->cmd->mrq ? > Yes on all accounts. I don't know the reason for this extreme redundancy. It was there long before I got involved. > > I think Stop command which is part of mmc_request is used for sending stop > command after Multi Block write. is this correct. If stop command fails(CRC > fail, timeout), does this mean card write failed. > It is correct that it is used for multi block writes. But also other open ended transfers. If the stop command fails, then the card will be in an unknown state. The write should have been completed though. Rgds Pierre signature.asc Description: PGP signature
Re: relation between mmc_request, mmc_data and mmc_command
On Sun, 23 Dec 2007 23:25:26 -0800 raki john [EMAIL PROTECTED] wrote: Does mmc_requeest-stop is equal to mmc_request-data-stop ? Does mmc_request is equal to mmc_request-data-mrq ? Does mmc_request-data is equal to mmc_request-cmd-data ? Does mmc_request is equal to mmc_request-cmd-mrq ? Yes on all accounts. I don't know the reason for this extreme redundancy. It was there long before I got involved. I think Stop command which is part of mmc_request is used for sending stop command after Multi Block write. is this correct. If stop command fails(CRC fail, timeout), does this mean card write failed. It is correct that it is used for multi block writes. But also other open ended transfers. If the stop command fails, then the card will be in an unknown state. The write should have been completed though. Rgds Pierre signature.asc Description: PGP signature
Re: [RFC, PATCH] sdio: move temporary buffer
On Wed, 19 Dec 2007 11:55:25 +0100 Marc Pignat <[EMAIL PROTECTED]> wrote: > Move the temporary buffer used by some sdio functions from sdio_func struct to > the mmc_host struct and make it dma-safe. > > Signed-off-by: Marc Pignat <[EMAIL PROTECTED]> > --- > > There is no need to have this temporary buffer in every sdio_func, since all > access to it are serialized by sdio_[claim/release]_host. > I had some crazy idea about per function locking, but until that time this will do just fine. > I also think it should be cacheline_aligned to make sure we have no data > loss when doing dma syncing operations. This is still voodoo to me, so I'll have to take your word for it. :) > > Comments welcome! > Looks good to me. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Samsung S3C24xx SD/MMC driver
On Wed, 19 Dec 2007 15:22:13 +0100
Harald Welte <[EMAIL PROTECTED]> wrote:
> Hi!
>
> This is a MMC/SD driver for the Samsung S3C24xx SD/MMC controller, originally
> developed years ago by Thomas Kleffel <[EMAIL PROTECTED]>.
>
> Due to time constraints, he had no time to further maintain the driver
> and follow the mainline Linux changes in the SD/MMC stack.
>
> With his authorization, I have taken over the task of making it
> compliant to the current mainline SD/MMC API and take care of the
> mainline kernel merge.
>
> So please advise on whatever changes you deem neccessary and I'll try to
> do my best to incorporate them for a hopefully not-too-distant mainline
> merge.
>
> After a potential kernel inclusion, we would co-maintain the driver.
>
> Acked-by: Thomas Kleffel <[EMAIL PROTECTED]>
> Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
>
> ---
Well, my biggest beef with this driver is the excessive debug code. I did a
cleanup in an older version of the driver, but it shouldn't be to difficult to
do the same for this one. I've included my patch for reference.
> Index: linux-2.6/drivers/mmc/host/s3cmci.c
> ===
> --- /dev/null
> +++ linux-2.6/drivers/mmc/host/s3cmci.c
> +#include
This is always a warning sign. It should never be needed in a host driver.
> +
> +static inline int get_data_buffer(struct s3cmci_host *host,
> + u32 *words, u32 **pointer)
> +{
> + struct scatterlist *sg;
> +
> + if (host->pio_active == XFER_NONE)
> + return -EINVAL;
> +
> + if ((!host->mrq) || (!host->mrq->data))
> + return -EINVAL;
> +
> + if (host->pio_sgptr >= host->mrq->data->sg_len) {
> + dbg(host, dbg_debug, "no more buffers (%i/%i)\n",
> + host->pio_sgptr, host->mrq->data->sg_len);
> + return -EBUSY;
> + }
> + sg = >mrq->data->sg[host->pio_sgptr];
> +
> + *words = sg->length >> 2;
> + *pointer = page_address(sg_page(sg)) + sg->offset;
> +
The length might not be a multiple of four. And it might also be completely
unaligned. Make sure you can either handle such requests, or fail them with
-EINVAL.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 4e47c91b7ca45940af384d3c9919a0eb160a2fb9
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date: Fri Jun 1 08:19:15 2007 +0200
s3mci: remove extra debug info
Remove excessive and unmaintained debug strings. This kind of debug
info should also be in the MMC layer, not drivers.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 7c2eb45..42fa90f 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -30,6 +30,5 @@ mmc_core-y := mmc.o mmc_sysfs.o
mmc_core-$(CONFIG_BLOCK) += mmc_queue.o
ifeq ($(CONFIG_MMC_DEBUG),y)
-obj-$(CONFIG_MMC) += mmc_debug.o
EXTRA_CFLAGS += -DDEBUG
endif
diff --git a/drivers/mmc/mmc_debug.c b/drivers/mmc/mmc_debug.c
deleted file mode 100644
index f13e223..000
--- a/drivers/mmc/mmc_debug.c
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
- * linux/drivers/mmc/mmc_debug.c
- *
- * Copyright (C) 2003 maintech GmbH, Thomas Kleffel <[EMAIL PROTECTED]>
- *
- * This file contains debug helper functions for the MMC/SD stack
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include
-#include "mmc_debug.h"
-
-char *mmc_cmd2str(int cmd)
-{
- switch(cmd) {
- case 0: return "GO_IDLE_STATE";
- case 1: return "ALL_SEND_OCR";
- case 2: return "ALL_SEND_CID";
- case 3: return "ALL_SEND_RELATIVE_ADD";
- case 6: return "ACMD: SD_SET_BUSWIDTH";
- case 7: return "SEL_DESEL_CARD";
- case 9: return "SEND_CSD";
- case 10: return "SEND_CID";
- case 11: return "READ_UNTIL_STOP";
- case 12: return "STOP_TRANSMISSION";
- case 13: return "SEND_STATUS";
- case 15: return "GO_INACTIVE_STATE";
- case 16: return "SET_BLOCKLEN";
- case 17: return "READ_SINGLE_BLOCK";
- case 18: return "READ_MULTIPLE_BLOCK";
- case 24: return "WRITE_SINGLE_BLOCK";
- case 25: return "WRITE_MULTIPLE_BLOCK";
- case 41: return "ACMD: SD_APP_OP_COND";
- case 55: return "APP_CMD";
- default: return "UNKNOWN
Re: [RFC, PATCH] sdio: move temporary buffer
On Wed, 19 Dec 2007 11:55:25 +0100 Marc Pignat [EMAIL PROTECTED] wrote: Move the temporary buffer used by some sdio functions from sdio_func struct to the mmc_host struct and make it dma-safe. Signed-off-by: Marc Pignat [EMAIL PROTECTED] --- There is no need to have this temporary buffer in every sdio_func, since all access to it are serialized by sdio_[claim/release]_host. I had some crazy idea about per function locking, but until that time this will do just fine. I also think it should be cacheline_aligned to make sure we have no data loss when doing dma syncing operations. This is still voodoo to me, so I'll have to take your word for it. :) Comments welcome! Looks good to me. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Samsung S3C24xx SD/MMC driver
On Wed, 19 Dec 2007 15:22:13 +0100
Harald Welte [EMAIL PROTECTED] wrote:
Hi!
This is a MMC/SD driver for the Samsung S3C24xx SD/MMC controller, originally
developed years ago by Thomas Kleffel [EMAIL PROTECTED].
Due to time constraints, he had no time to further maintain the driver
and follow the mainline Linux changes in the SD/MMC stack.
With his authorization, I have taken over the task of making it
compliant to the current mainline SD/MMC API and take care of the
mainline kernel merge.
So please advise on whatever changes you deem neccessary and I'll try to
do my best to incorporate them for a hopefully not-too-distant mainline
merge.
After a potential kernel inclusion, we would co-maintain the driver.
Acked-by: Thomas Kleffel [EMAIL PROTECTED]
Signed-off-by: Harald Welte [EMAIL PROTECTED]
---
Well, my biggest beef with this driver is the excessive debug code. I did a
cleanup in an older version of the driver, but it shouldn't be to difficult to
do the same for this one. I've included my patch for reference.
Index: linux-2.6/drivers/mmc/host/s3cmci.c
===
--- /dev/null
+++ linux-2.6/drivers/mmc/host/s3cmci.c
+#include linux/mmc/mmc.h
This is always a warning sign. It should never be needed in a host driver.
+
+static inline int get_data_buffer(struct s3cmci_host *host,
+ u32 *words, u32 **pointer)
+{
+ struct scatterlist *sg;
+
+ if (host-pio_active == XFER_NONE)
+ return -EINVAL;
+
+ if ((!host-mrq) || (!host-mrq-data))
+ return -EINVAL;
+
+ if (host-pio_sgptr = host-mrq-data-sg_len) {
+ dbg(host, dbg_debug, no more buffers (%i/%i)\n,
+ host-pio_sgptr, host-mrq-data-sg_len);
+ return -EBUSY;
+ }
+ sg = host-mrq-data-sg[host-pio_sgptr];
+
+ *words = sg-length 2;
+ *pointer = page_address(sg_page(sg)) + sg-offset;
+
The length might not be a multiple of four. And it might also be completely
unaligned. Make sure you can either handle such requests, or fail them with
-EINVAL.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 4e47c91b7ca45940af384d3c9919a0eb160a2fb9
Author: Pierre Ossman [EMAIL PROTECTED]
Date: Fri Jun 1 08:19:15 2007 +0200
s3mci: remove extra debug info
Remove excessive and unmaintained debug strings. This kind of debug
info should also be in the MMC layer, not drivers.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 7c2eb45..42fa90f 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -30,6 +30,5 @@ mmc_core-y := mmc.o mmc_sysfs.o
mmc_core-$(CONFIG_BLOCK) += mmc_queue.o
ifeq ($(CONFIG_MMC_DEBUG),y)
-obj-$(CONFIG_MMC) += mmc_debug.o
EXTRA_CFLAGS += -DDEBUG
endif
diff --git a/drivers/mmc/mmc_debug.c b/drivers/mmc/mmc_debug.c
deleted file mode 100644
index f13e223..000
--- a/drivers/mmc/mmc_debug.c
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
- * linux/drivers/mmc/mmc_debug.c
- *
- * Copyright (C) 2003 maintech GmbH, Thomas Kleffel [EMAIL PROTECTED]
- *
- * This file contains debug helper functions for the MMC/SD stack
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include linux/mmc/mmc.h
-#include mmc_debug.h
-
-char *mmc_cmd2str(int cmd)
-{
- switch(cmd) {
- case 0: return GO_IDLE_STATE;
- case 1: return ALL_SEND_OCR;
- case 2: return ALL_SEND_CID;
- case 3: return ALL_SEND_RELATIVE_ADD;
- case 6: return ACMD: SD_SET_BUSWIDTH;
- case 7: return SEL_DESEL_CARD;
- case 9: return SEND_CSD;
- case 10: return SEND_CID;
- case 11: return READ_UNTIL_STOP;
- case 12: return STOP_TRANSMISSION;
- case 13: return SEND_STATUS;
- case 15: return GO_INACTIVE_STATE;
- case 16: return SET_BLOCKLEN;
- case 17: return READ_SINGLE_BLOCK;
- case 18: return READ_MULTIPLE_BLOCK;
- case 24: return WRITE_SINGLE_BLOCK;
- case 25: return WRITE_MULTIPLE_BLOCK;
- case 41: return ACMD: SD_APP_OP_COND;
- case 55: return APP_CMD;
- default: return UNKNOWN;
- }
-}
-EXPORT_SYMBOL(mmc_cmd2str);
-
-char *mmc_err2str(int err)
-{
- switch(err) {
- case MMC_ERR_NONE: return OK;
- case MMC_ERR_TIMEOUT: return TIMEOUT;
- case MMC_ERR_BADCRC: return BADCRC;
- case MMC_ERR_FIFO: return FIFO;
- case MMC_ERR_FAILED: return FAILED;
- case MMC_ERR_INVALID: return INVALID;
- case MMC_ERR_BUSY: return BUSY;
- case MMC_ERR_DMA: return DMA;
- case MMC_ERR_CANCELED: return CANCELED;
- default: return UNKNOWN;
- }
-}
-EXPORT_SYMBOL(mmc_err2str);
diff --git a/drivers/mmc/mmc_debug.h b/drivers/mmc/mmc_debug.h
deleted
Re: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
On Fri, 14 Dec 2007 11:01:03 +0900 "Kyungmin Park" <[EMAIL PROTECTED]> wrote: > > Yes, reserved word should or must be zero, then it should check "if > (ext_csd_struct <= 2)" instead of ">= 2". > In the Spec. 4.2, it can have three value 0, 1, or 2. There's no other > restriction. As I said, the spec doesn't say "must", and I've seen cards with bogus data in there so I'm afraid we can't rely on the fields being zero. The version field is the only decent way of determining what to expect in the rest of the structure. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
On Fri, 14 Dec 2007 11:01:03 +0900 Kyungmin Park [EMAIL PROTECTED] wrote: Yes, reserved word should or must be zero, then it should check if (ext_csd_struct = 2) instead of = 2. In the Spec. 4.2, it can have three value 0, 1, or 2. There's no other restriction. As I said, the spec doesn't say must, and I've seen cards with bogus data in there so I'm afraid we can't rely on the fields being zero. The version field is the only decent way of determining what to expect in the rest of the structure. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MMC updates
On Wed, 12 Dec 2007 20:12:47 +0100
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Linus, please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
>
*ping*
--
-- 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: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MMC updates
On Wed, 12 Dec 2007 20:12:47 +0100 Pierre Ossman [EMAIL PROTECTED] wrote: Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus *ping* -- -- 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PNP: do not stop/start devices in suspend/resume path
On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas <[EMAIL PROTECTED]> wrote: > PNP: do not stop/start devices in suspend/resume path > > Do not disable PNP devices in the suspend path. We still call > the driver's suspend method, which should prevent further use of > the device, and the protocol suspend method, which may put the > device in a low-power state. > > I'm told that Windows puts devices in a low-power state (Linux > does this in the protocol suspend method), but does not use _DIS > in the suspend path. Other relevant references: > > - In the ACPI 3.0b spec, I can't find any mention of _DIS in > connection with sleep. And Device Object Notifications, > Section 5.6.3, Table 5-43, says we should get a bus check > after awakening if hardware was removed while we slept. > > - This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx > makes a similar point about how the OS re-enumerates devices > as a result of a power state change (3rd last paragraph of > text). > > - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx > suggests that Windows only stops a device to rebalance hardware > resources. > > Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]> > Tested-by: Pierre Ossman <[EMAIL PROTECTED]> No noticeable issues with suspend or hibernate using this patch. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
On Thu, 13 Dec 2007 17:08:16 +0900 "Kyungmin Park" <[EMAIL PROTECTED]> wrote: > > In my MMC Spec. (v4.2), there's no problem to read it even though it's > revision 1.1 > Well, the spec says that those reserved fields "should be zero". Unfortunately, people seem to have read this in the IETF sense and not as "the fields MUST be zero". I.e. I've seen cards where reserved fields contain junk. > Anyway how do it handle this one? Do you have any idea? > The EXT_CSD is read after the CID, so add some table that maps certain workarounds to specific cards. Then add some bit saying "is really EXT_CSD 1.2" and check for that bit when parsing the EXT_CSD. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
On Thu, 13 Dec 2007 16:13:11 +0900 Kyungmin Park <[EMAIL PROTECTED]> wrote: > It already checked the ext_csd_struct is less than 2, > so it doesn't need to check it. > Current code only accepts the revision 1.2. > > Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]> It wasn't wrong the last time you brought this up, and it still isn't wrong. Those bits aren't defined until version 1.2 of the EXT_CSD register, hence we do not trust them. If you have some broken card that you feel you must have support for, then start working on some quirks system. 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: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PNP: do not stop/start devices in suspend/resume path
On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas [EMAIL PROTECTED] wrote: PNP: do not stop/start devices in suspend/resume path Do not disable PNP devices in the suspend path. We still call the driver's suspend method, which should prevent further use of the device, and the protocol suspend method, which may put the device in a low-power state. I'm told that Windows puts devices in a low-power state (Linux does this in the protocol suspend method), but does not use _DIS in the suspend path. Other relevant references: - In the ACPI 3.0b spec, I can't find any mention of _DIS in connection with sleep. And Device Object Notifications, Section 5.6.3, Table 5-43, says we should get a bus check after awakening if hardware was removed while we slept. - This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx makes a similar point about how the OS re-enumerates devices as a result of a power state change (3rd last paragraph of text). - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx suggests that Windows only stops a device to rebalance hardware resources. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Tested-by: Pierre Ossman [EMAIL PROTECTED] No noticeable issues with suspend or hibernate using this patch. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
On Thu, 13 Dec 2007 16:13:11 +0900 Kyungmin Park [EMAIL PROTECTED] wrote: It already checked the ext_csd_struct is less than 2, so it doesn't need to check it. Current code only accepts the revision 1.2. Signed-off-by: Kyungmin Park [EMAIL PROTECTED] It wasn't wrong the last time you brought this up, and it still isn't wrong. Those bits aren't defined until version 1.2 of the EXT_CSD register, hence we do not trust them. If you have some broken card that you feel you must have support for, then start working on some quirks system. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
On Thu, 13 Dec 2007 17:08:16 +0900 Kyungmin Park [EMAIL PROTECTED] wrote: In my MMC Spec. (v4.2), there's no problem to read it even though it's revision 1.1 Well, the spec says that those reserved fields should be zero. Unfortunately, people seem to have read this in the IETF sense and not as the fields MUST be zero. I.e. I've seen cards where reserved fields contain junk. Anyway how do it handle this one? Do you have any idea? The EXT_CSD is read after the CID, so add some table that maps certain workarounds to specific cards. Then add some bit saying is really EXT_CSD 1.2 and check for that bit when parsing the EXT_CSD. 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: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
