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
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 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
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
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
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
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
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
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
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
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
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
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
: 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
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
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
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
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
; (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
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
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 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 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
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
--
_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:
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
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
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:
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
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
&
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 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
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
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
I didn't get any response from you the last time I submitted this so I'm
going to nag you some more ;)
This patch is vital for one of my MMC cards. The only other way I've
found to get it working is by changing the OCR. And that would cause
problems on other controllers so it was not an option.
T
I didn't get any response for this one either ;)
This is only a performance boost so it is less critical. It is very nice
to have though since the performance gain is substancial (>100%).
It should not pose any problems with data loss, which was your primary
concern. It backs down to single block
it might help if I include the actual patch...
Index: linux-wbsd/drivers/mmc/mmc_block.c
===
--- linux-wbsd/drivers/mmc/mmc_block.c (revision 77)
+++ linux-wbsd/drivers/mmc/mmc_block.c (working copy)
@@ -166,9 +166,25 @@
struct mmc_b
ve(struct pnp_dev * dev)
+{
+ wbsd_shutdown(&dev->dev, 1);
}
+#endif /* CONFIG_PNP */
+
/*
* Power management
*/
@@ -1581,7 +1895,7 @@
#define wbsd_resume NULL
#endif
-static void wbsd_release(struct device *dev)
+static void wbsd_release_dev(struct device *dev)
{
}
@
I recently tried out adding PNP support to my driver to remove the
hassle of finding the correct parameters for it. This, however, causes
it to show up under the pnp bus, where as it previously was located
under the platform bus.
Is the idea that PNP devices should only reside on the PNP bus or
Randy.Dunlap wrote:
Pierre Ossman wrote:
I recently tried out adding PNP support to my driver to remove the
hassle of finding the correct parameters for it. This, however,
causes it to show up under the pnp bus, where as it previously was
located under the platform bus.
Is the idea that PNP
Adam Belay wrote:
Hi Pierre,
The platform bus does not show the actual physical relationship either. For
x86, ACPI is typically needed to determine this. It would be easy to bind to
spawn pnp devices off of an ISA bridge device, attached to the pci bus, but
whether it's the actual physical parent
Pierre Ossman wrote:
Geert Uytterhoeven wrote:
MMC_WBSD depends on ISA (needs isa_virt_to_bus())
Thanks. Shouldn't have missed something so obvious :)
Russell, can you fix this in your next merge?
Russell, please undo this patch. isa_virt_to_bus() is not dependent on
CONFIG_ISA. It c
Christoph Hellwig wrote:
Russell, please undo this patch. isa_virt_to_bus() is not dependent on
CONFIG_ISA. It causes problems on x86_64 platforms which cannot enable
ISA support.
Actually it is, x86_64 just refuses to set CONFIG_ISA despite having
isa-like devices.
Either way a new drive
Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 04:31:16PM +0100, Pierre Ossman wrote:
The problem was that the DMA API didn't work for x86_64 when I wrote the
driver. I see now that it has been fixed.
isa_virt_to_bus still works even though CONFIG_ISA is not configured. So
It ma
Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 05:08:32PM +0100, Pierre Ossman wrote:
For i386 and x86_64 it's defined as virt_to_phys in asm/io.h without any
#ifdef:s protecting it.
Not all the world is a PC
Then the dependency should in that case be on architectures.
How is suspend/resume handled with PNP devices? There are no
suspend/resume functions registered for the pnp bus type.
Rgds
Pierre
-
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
I'm having problem with a card reader on a laptop (Acer Aspire 1501).
The device doesn't get its resources configured properly.
The reader is connected to the LPC bus so there is no standardised way
to configure the device. On other laptops the configuration is done via
ACPI (_STA & co. in the
Adam Belay wrote:
On Sat, Feb 05, 2005 at 06:10:02PM +0100, Pierre Ossman wrote:
I'm having problem with a card reader on a laptop (Acer Aspire 1501).
The device doesn't get its resources configured properly.
The reader is connected to the LPC bus so there is no standardised way
to
krishna wrote:
Hi All,
I have a strange problem.
The Audio driver is statically compiled into the kernel.
When I am loading my MMC driver, It is getting Audio Interrupts.
I browsed thru the web and found out it is a bug in the hardware.
The hardware bug is preventing Audio driver and MMC driver wor
Here are the patches for Secure Digital support that I've been sitting
on for a while. I tried to get some feedback on inclusion of this
previously but since I didn't get any I'll just submit the thing.
It was originally diffed against 2.6.10 but it applies to 2.6.11 just
fine (only minor fuzz).
I just upgraded to Linux 2.6.11 and the soundcard on my machine went
silent. All volume controls are correct and there are no errors
reported. But no sound coming from the speakers. And here's the kicker,
the headphones work fine!
2.6.10 still works so the bug appeared in one of the patches in b
Nish Aravamudan wrote:
On Thu, 03 Mar 2005 13:51:40 +0100, Pierre Ossman <[EMAIL PROTECTED]> wrote:
I just upgraded to Linux 2.6.11 and the soundcard on my machine went
silent. All volume controls are correct and there are no errors
reported. But no sound coming from the speakers. And
Andrew Morton wrote:
Mark Canter <[EMAIL PROTECTED]> wrote:
To close this issue out of the LKML and alsa-devel, a bug report has been
written.
It appears to be an issue with the 'headphone jack sense' (as kde labels
it). The issue is in the way the 8x0 addresses the docking station/port
rep
Marcel Holtmann wrote:
Hi Pierre,
Here are the patches for Secure Digital support that I've been sitting
on for a while. I tried to get some feedback on inclusion of this
previously but since I didn't get any I'll just submit the thing.
It was originally diffed against 2.6.10 but it applies to
Pierre Ossman wrote:
Andrew Morton wrote:
Mark Canter <[EMAIL PROTECTED]> wrote:
To close this issue out of the LKML and alsa-devel, a bug report has
been written.
It appears to be an issue with the 'headphone jack sense' (as kde
labels it). The issue is in the way the 8
Russell King wrote:
On Thu, Mar 03, 2005 at 01:22:56PM +0100, Pierre Ossman wrote:
Here are the patches for Secure Digital support that I've been sitting
on for a while. I tried to get some feedback on inclusion of this
previously but since I didn't get any I'll just submit th
Russell King wrote:
On Sat, Mar 05, 2005 at 01:23:16PM +0100, Pierre Ossman wrote:
I can make a new patch or you can just undo that line once you've
applied the current one.
I'd rather not just apply this patch - there's rather a lot there to
just apply on top of what'
As promised, here is the patch broken down into smaller pieces. The
patch is now divided into six distinct parts:
* Protocol definitions.
* SD card initialisation.
* Reading read-only switch.
* Getting SCR register.
* Exposing SCR register through sysfs.
* Wide (4-bit) bus support.
Rgds
Pierre
-
Protocol definitions.
The basic commands needed for the later patches. The R1_APP_CMD seems to
be misdefined in protocol.h so this patch changes it.
Index: linux-sd/include/linux/mmc/mmc.h
===
--- linux-sd/include/linux/mmc/mmc.h (re
SD card initialisation.
This patch contains the central parts of the SD support.
The system first tries to detect MMC cards, and if none are found then
it procedes to look for an SD card. This is incorrect acording to SD
specifications but I find it odd that MMC is supposed to cope with SD
comma
Read-only support.
This patch adds a new callback for the drivers to facilitate reading the
SD card read-only switch. If the callback is not provided then a warning
will be printed and it will default to write-enable.
The read-only switch is a host enforced read-only so the MMC block layer
has
SCR download.
This patch downloads the SCR register from the card. Unlike the other
registers this one is transfered over the data bus. That required some
changes to other routines to allow a card to be selected after the host
was aquired.
This is one of the more error prone parts. The transfer
SCR sysfs access.
This provides access to the SCR register via sysfs. Since the latest bk
contains some changes to the sysfs part this probably needs updating.
The patch is trivial though so it should be easy.
Index: linux-sd/drivers/mmc/mmc_sysfs.c
==
Wide bus support.
This adds 4-bit bus support to the MMC layer. It is designed to
(hopefully) be compatible with a future 4-bit MMC implementation. This
is done by seperating the three different instances of bus width defines:
* Protocol definition: SD_BUS_WIDTH_x
* SCR contents: SD_SCR_BUS_WIDT
Takashi Iwai wrote:
>At Fri, 04 Mar 2005 22:16:03 +0100,
>Pierre Ossman wrote:
>
>
>>It seems I spoke too soon. The defaults picked by the driver are
>>actually fine. It seems to be alsactl store/restore that did something
>>strange when coming from an older ke
Takashi Iwai wrote:
Look at /etc/asound.state whether it contains the value of "Headphone
Jack Sense" control true or false.
It saves the setting once I've been in 2.6.11. From an earlier kernel
there is no such entry.
Of course, the earlier version didn't have this.
And did you take a
Lee Revell wrote:
>So is there a bug or not? Mark seems to be the only one affected.
>
>It's important to follow up, because these so-called "ALSA regressions"
>are generating bad press.
>
>Lee
>
>
>
I can generate the error using the following procedure:
1. Boot in 2.6.10. Remove /etc/asound.
Takashi Iwai wrote:
At Tue, 08 Mar 2005 02:10:06 +0100,
Pierre Ossman wrote:
Takashi Iwai wrote:
Look at /etc/asound.state whether it contains the value of "Headphone
Jack Sense" control true or false.
It saves the setting once I've been in 2.6.11. From an
Pierre Ossman, All Rights Reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
_host(mmc);
+ return wbsd_init(&pnpdev->dev, io, irq, dma, 1);
+}
- return 0;
+static void __devexit wbsd_pnp_remove(struct pnp_dev * dev)
+{
+ wbsd_shutdown(&dev->dev, 1);
}
+#endif /* CONFIG_PNP */
+
/*
* Power management
*/
@@ -1581,18 +1895,8 @@
#define wbsd_re
Ian Molton wrote:
I've been getting errors replying to you but had no alternative
address to use. perhaps you could mail me from another account ?
Afraid everything gets routed to the same account in the end anyway. I
checked the logs and the problem is that your mail server has a HELO
that dif
Ian Molton wrote:
The toshiba controller appears to want to be told when an ACMD is
issued, compared to a normal CMD.
Seems very strange since there's no change in what goes over the wire.
I think the controller (for some odd reason) keeps some extra internal
state.
Have you tried using it withou
Richard Purdie wrote:
For reference, I got the 512MB SD card working by adding an mdelay(3)
into the middle of mmc_send_op_cond(). Anything shorter and it marks
the card as bad...
I fail to see what this delay does. A few lines further down you have a
mmc_delay which you have removed. That delay
Richard Purdie wrote:
Pierre Ossman:
I, personally, would really like to see SD support included in the
main kernel. But I can also fully understand if that's not currently
possible.
I think the way forward is for someone to propose a patch. Your code
sounds the most advanced but Ian or m
- Winbond W83L51xD SD/MMC driver
*
- * Copyright (C) 2004 Pierre Ossman, All Rights Reserved.
+ * Copyright (C) 2004-2005 Pierre Ossman, All Rights Reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License
When I yank out my MP3 player, the programs trying to umount the disk
cause the following page fault:
usb 1-5: USB disconnect, address 2
scsi0 (0:0): rejecting I/O to dead device
FAT bread failed in fat_clusters_flush
Unable to handle kernel paging request at virtual address 6b6b6b6b
printing ei
Andrew Morton wrote:
Pierre Ossman <[EMAIL PROTECTED]> wrote:
When I yank out my MP3 player, the programs trying to umount the disk
cause the following page fault:
...
EIP is at scsi_device_put+0xf/0x70 [scsi_mod]
This should be fixed in 2.6.11-rc2-mm1, via bk-scsi-rc-fixes.patch.
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
ld also work for cards that mishandle the state field, and if the card
jumps to
some odd state for some reason.
>
> I am just wondering if I have set of broken cards. Any pointers
> in this regard?
>
You do. But don't be too alarmed, that is unfortunately the norm
On Wed, 24 Oct 2007 15:37:10 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 22 October 2007, Pierre Ossman wrote:
> >
> > I've been testing a bit more here, and I can't get this particular bug.
>
> It's not just a bug, it's a regressi
| 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
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
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
>
> MMC: Setting controller bus width to 1
>
All your commands are failing, oddly enough with "response index
error". I'm not familiar with the AT91 controller, so I'm adding
Nicolas Ferre, the AT91 maintainer, to this discussion.
Rgds
--
-- Pierre Ossman
L
one. But I'd still like to keep
mmc_wait_for_app_cmd().
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 f
tuff isn't seeing it.
> Was working last week.
>
This appeared because we fixed another bug. Try the included patch.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdeskto
|1 +
4 files changed, 21 insertions(+), 2 deletions(-)
Marc Pignat (1):
mmc: at91_mci: wakeup on card insertion (or removal)
Pierre Ossman (2):
mmc: add maintainer for at91
sdhci: make sure to clear the error interrupt
diff --git a/MAINTAINERS b/MAINTAINERS
index
ts since other subsystems like pcmcia also suffer
> this problem and would benefit from this but I accept that teaching
> filesystems this is more difficult.
>
Doesn't mean we shouldn't do it. And if we keep papering over the
problems, you reduce the motivation of fixing t
k. But if it is in yours, just
enable MMC_UNSAFE_RESUME and you'll have the old behaviour.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
his both to LKML and LAKML. Interested readers should
probably check both lists for replies)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://w
ed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
>
That particular piece of code seems to be a war zone in -mm right now.
I'll leave it be until we start merging this upstream.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core de
mmc/core/bus.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
Acked-by: Pierre Ossman <[EMAIL PROTECTED]>
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop,
ers/mmc/core/host.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
Acked-by: Pierre Ossman <[EMAIL PROTECTED]>
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop,
drivers/mmc/core/sdio_bus.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
Acked-by: Pierre Ossman <[EMAIL PROTECTED]>
Although this is code that only lives in my -mm tree. Should I carry
this patch instead, perhaps?
--
-- Pierre Ossman
Linux ker
; drivers/mmc/core/mmc_ops.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
Acked-by: Pierre Ossman <[EMAIL PROTECTED]>
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseau
ut we could satisfy that by stating that any transfer small enough to
fit into one block will not be split up.
(PS. You might want to add [PATCH x/3] to your subjects so that the
order of the patches is crystal clear)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer
uld you be content with replacing "func->num * 0x100" with a macro so
that the code becomes something like:
SDIO_FBR_BASE(func->num) + SDIO_FBR_STD_IF
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer ht
t blksz)
> +{
> + int ret;
> +
> + ret = mmc_io_rw_direct(func->card, 1, 0,
> SDIO_FBR_BLKSIZE(func->num),
> +blksz & 0xff, NULL);
> + if (ret)
> + return ret;
> + ret = mmc_io_rw_direct(func->card, 1, 0,
> SDIO_FBR_BLKSI
cmd.arg |= blocks;
> + } else
> + cmd.arg |= (blksz == 512) ? 0 : blksz;
> cmd.flags = MMC_RSP_R5 | MMC_CMD_ADTC;
>
Until this function is made complete, I'd like some kind of test that
blksz <= 512 when blocks == 1.
--
-- Pierre
101 - 200 of 486 matches
Mail list logo
