Regards
--
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
d 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 deve
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.
>
>
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 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 de
ings 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 remo
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 se
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 "unsubscr
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)
> > the
d 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
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
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 n
ion 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 kerne
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 some
> + goto err_remove_host;
> + }
> +
> + if (slot->pdata->get_ro != NULL) {
> + r = device_create_file(&mmc->class_dev,
> + &dev_attr_ro);
> + }
> +
You have a bit of a race her
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:/
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
;[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.rde
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 disa
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
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 "unsubscri
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 s
t. 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:
ull-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 yo
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 pr
_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:
ports 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
--
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 wa
n 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://p
e 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://pu
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.rdes
erring 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://
at'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 maintainer
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 ela
e 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
identic
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 fo
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.
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
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 st
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
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
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 m
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
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
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
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.or
;
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 s
---
include/linux/pci_ids.h |1 +
4 files changed, 61 insertions(+), 10 deletions(-)
Nicolas Pitre (1):
mmc: remove unused 'mode' from the mmc_host structure
Pierre Ossman (4):
sdhci: describe quirks
sdhci: don't warn about sdhci 2.0 controllers
sdhci: use PIO
On Mon, 10 Dec 2007 19:11:12 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 09, 2007 at 06:08:18PM +0100, Pierre Ossman wrote:
> >
> > This still requires a bit of maintenance to set up a kerneltypes.h for
> > every arch.
>
> Better doing this wor
On Sat, 8 Dec 2007 22:58:11 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 03, 2007 at 09:02:19PM +1100, Rusty Russell wrote:
> > So, just insert two bits of padding in sdio_device_id and insert a comment
> > saying "/* Explicit padding: works even if we're cross-compiling */".
>
> W
On Sun, 2 Dec 2007 12:22:31 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
> I gave it a try:
> - Remove existing alignment attributes from some device_id types
> - Introduce kernel_* types with proper size and alignment for
> cross-compilation (sample for m68k included)
>
On Thu, 06 Dec 2007 23:12:46 -0500 (EST)
Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> This field and corresponding defines are simply never used anywhere
> in the code. But its mere presence is enough to confuse some host
> driver authors who attempt to rely on it. Let's eliminate the
> possibil
On Thu, 29 Nov 2007 16:40:37 -0700
Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
>
> The corresponding PCI code in pci_device_suspend() does not do
> any generic device disable or resource release. I don't know
> why PNP disables the device on suspend. I glanced through the
> ACPI spec but didn't se
On Wed, 28 Nov 2007 13:34:02 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007, Pierre Ossman wrote:
> >
> > Is there no directive we can stick in there that forces a reasonable
> > alignment (e.g. alignment == sizeof(type)) independently
On Sat, 01 Dec 2007 00:27:06 -0800
Vitaly Luban <[EMAIL PROTECTED]> wrote:
> Kernel "pci_ids.h" file has data for that card missing.
>
> Also, Ellen needs some control bits flipped before it functions properly
> as SDIO controller by the spec.
> Should apply clenly to Linus and Drzeus trees. Ple
ou get to keep a down-rev
> virtual machine to do it right :-(
>
Nah. The previous gcc package is the one shipped with Fedora 8. So I could just
grab that one (plus cpp and libgomp) and downgrade.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.o
On Sat, 1 Dec 2007 15:42:23 +0100
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> The latest GCC in Fedora rawhide contains some serious bug (or provokes a
> latent one in the kernel) that makes every kernel built unbootable. It just
> locks up halfway through the init. Kernels
isapnp: No Plug & Play device found
Any ideas on how I can work around this? I'm rather unproductive when I can't
build working kernels.. :/
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://p
, UART_IER, port->ier);
}
-static void sdio_uart_receive_chars(struct sdio_uart_port *port, int *status)
+static void sdio_uart_receive_chars(struct sdio_uart_port *port, unsigned int
*status)
{
struct tty_struct *tty = port->tty;
unsigned int ch, flag;
--
--
On Wed, 28 Nov 2007 09:28:56 +
Al Viro <[EMAIL PROTECTED]> wrote:
>
> Eh... m68k has 16bit alignment for unsigned long.
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -
On Wed, 28 Nov 2007 10:27:18 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
> So the problem is in scripts/mod/file2alias.c, which gives a different
> sizeof(struct sdio_device_id) on the cross-compile host:
> - sizeof(struct sdio_device_id) = 12 on ia32
> - sizeof(struct sdio_de
On Tue, 27 Nov 2007 22:07:23 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Current Linus tree give me this, with m68k allmodconfig:
>
> FATAL: drivers/bluetooth/btsdio: sizeof(struct sdio_device_id)=12 is not a
> modulo of the size of section __mod_sdio_device_table=30.
> Fix definition of
; (Except this particular bug looks like a post-2.6.23 regression, so I can cc
> the Rafael which never forgets, so it will then get tracked all the way into
> Linus's tree)
>
Jens said he applied it, so I figured the issue was handled. Jens, what
happened to it?
Rgds
--
-- Pi
most drivers will handle all of these things as they see
fit. Haven't seen a single bug report about it yet so...
Just change the voltage in whatever way makes sense for your controller.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Puls
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> > It most certainly does not. gcc will assume that an int* has int alignment.
> > memcpy() is a builtin, which gcc can translate to
data->bytes_xfered);
> +
The debug output here is already provided by the MMC core.
> +
> +static int __exit atmci_remove(struct platform_device *pdev)
> +{
> + struct atmel_mci *host = platform_get_drvdata(pdev);
> +
> + platform_set_drvd
cast
from char* or void* to something else, you better be damn sure the alignment is
correct because gcc will assume it is.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core deve
: Andre Haupt <[EMAIL PROTECTED]>
> Signed-off-by: Andre Haupt <[EMAIL PROTECTED]>
Nicolas, does this seem correct to you? I'm not familiar with the serial stuff.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core
ave byte
alignment, gcc can't really do anything creative.)
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 fro
I'll just readd my reply again. :)
On Fri, 23 Nov 2007 16:13:18 +0100
Nicolas Ferre <[EMAIL PROTECTED]> wrote:
> I take advantage of this thread to ask a question about the SDIO cards
> you are using to test the stack.
>
> I look at the page on the MMC wiki :
> http://mmc.drzeus.cx/wiki/SDIO
> b
ken, but I do not think
sdio_io_rw_ext_helper() is. I'll be doing a fix eventually, but it probably
won't get that high on my todo list as it will only be useful together with
some new API. Since your card was content with byte transfers, it shouldn't be
that much need for
s down.
I guess I'll have to consider adding a more low-level API. The big problem with
such a call would be that it can fail requests because the host or card cannot
satisfy them. So a function driver using such an API would have to use a much
more defensive programming (which can incur a per
deletions(-)
Alex Dubov (1):
tifm_sd: handle non-power-of-2 block sizes
David Woodhouse (1):
mmc: Avoid re-using minor numbers before the original device is closed.
Pierre Ossman (1):
mmc_block: check card state after write
--
-- Pierre Ossman
Linux kernel, MMC maintainer
ged by the core driver ?
>
There are no drivers using "increase address" yet. The ones so far have all
used a single byte FIFO port.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
eep trying to bypass every system in the
kernel. ;)
(Not to mention you'll have a lot more work on your hands.)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
elevant functions. Have a look in
drivers/core/sdio_io.c if you don't want to build the full document.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
On Mon, 19 Nov 2007 11:44:54 +
Dean Jenkins <[EMAIL PROTECTED]> wrote:
> This E-mail is for the attention of Pierre Ossman (MMC sub-system
> maintainer)
A cc helps if you want my attention. ;)
>
> Hi Pierre,
>
> I've being trying to get SDIO block-mode with i
ug string "waiting for helper to boot..." in that case.
Have you tried with the firmware that's supposed to be used with this board?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
to receive a chunk of the firmware. Odd, as the loading loop first
queries the card if it is ready for more data.
You could try adding a delay to the helper firmware loading loop
(if_sdio_prog_helper() in if_sdio.c). Add an msleep(100); in there and see if
that gets things further. Loading will
support the general sentiment)
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 "unsubsc
_QUIRK_BROKEN_DMA) &&
(host->flags & SDHCI_USE_DMA)) {
- DBG("Disabling DMA as it is marked broken");
+ DBG("Disabling DMA as it is marked broken\n");
host->flags &= ~SDHCI_USE_DMA;
}
--
-
m confused. Didn't the previous fix solve your problems?
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 t
s though. :)
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
Cc: Jens Axboe <[EMAIL PROTECTED]>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Ouch! Well that was obviously a bug. I wonder how the hell it only explodes for
Romano. I've been shuffling loads of data using -rc1 without an incident.
Rgds
--
-- Pierre Ossman
L
On Tue, 6 Nov 2007 22:15:37 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 2 Nov 2007 06:23:48 -0700 (PDT) Alex Dubov <[EMAIL PROTECTED]>
> > wrote:
> >
> > I also wonder, where do I send the patches if nobody currently maintains
> > this thing?
> >
>
> Me, Pierre, lkml?
I'm not
On Mon, 05 Nov 2007 14:46:33 +0100
Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote:
> > Did you partition and format this card in the camera or in Linux?
>
> In the camera. It happened both with a Kodak and a Panas
On Mon, 05 Nov 2007 14:51:45 +0100
Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote:
> > On Mon, 05 Nov 2007 11:51:26 +0100
> > Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> Ah, I forgot: I have a dump
280 MB).
Did you partition and format this card in the camera or in Linux?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To un
>
Since there was no error from the mmc level there, I wouldn't be so sure. Could
you try a complete fsck of the card to check that the camera is constructing a
proper FAT?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudi
s not supported by ath5k yet, and the choice is
> between ndiswrapper or Vista.). Should I enable some debugging option
> for the MMC layer?
Not at this point no. The debugging tends to be quite noise so it easily drowns
out any temporary problems.
Rgds
--
-- Pierre Ossman
Linux k
's no guarantee against bugs.
(But since my code is bug free, that shouldn't be an issue. ;))
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer htt
n invalid pointer
(the oops in the first dmesg).
Can you reproduce this? To help you I need to see the errors given by the MMC
layer. You should also try reproducing it without a tainted kernel (i.e. don't
load ndiswrapper).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maint
d. I have a whole bunch of transcend cards, and I've never gotten this
problem. Perhaps yours are rather recent?
> I have tried the fix, and it works fine. Thanks.
>
Great. I'll queue it up for -mm for some more testing, after which it will get
merged.
Rgds
--
-- Pie
d go through you, not directly through Linus...
>
Indeed. Applied.
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
| 52 +++
4 files changed, 57 insertions(+), 25 deletions(-)
David Brownell (1):
mmc_spi: Fix mmc-over-spi regression
Pierre Ossman (3):
at91_mci: Fix bad reference
mmc: fix cid and csd byte order
mmc: use common byte swap macros
1 - 100 of 486 matches
Mail list logo
