--
Pierre Ossman
--
Pierre Ossman
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'
ey'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
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.
>
>
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&
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
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
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
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
s 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.rd
fused. 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 r
, 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 maintainer
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
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 locku
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-k
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
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
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 "[RTN
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)
> > t
t 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 htt
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
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
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
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 maintainer
(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
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
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
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
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
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.kern
() 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.
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 t
r <[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.kerne
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
>
IL 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
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
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
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
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
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
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]>
> ---
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
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-k
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
> &
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
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.
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
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
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
-
trollable. 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
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.
ur 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 "unsubscrib
ifferent 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
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
--
-- 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
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
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
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
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
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
ot 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
. 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
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
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
-
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.rdeskt
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
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
'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.k
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 pleas
st 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
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
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
>
d 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://
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
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
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.
. 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
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
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
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
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
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),
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
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
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
ake 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
Pul
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
unali
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
. 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
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
structu
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
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.kerne
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
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
orkarounds 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, c
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
--
PROTECTED]
Tested-by: Pierre Ossman [EMAIL PROTECTED]
No noticeable issues with suspend or hibernate using this patch.
Rgds
Pierre
signature.asc
Description: PGP signature
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
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
1 - 100 of 964 matches
Mail list logo
