changed, 17 insertions(+), 40 deletions(-)
Alex Dubov (1):
tifm_sd: treat "status error" as normal command completion
Pierre Ossman (4):
mmc: wbsd: Remove driver version
mmc: sdhci: Remove driver version
mmc: sdhci: Stop asking for mail
mmc: wbsd: Re
_DEPRECATED should make it work with any
ancient version of hal.
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 th
Brad Campbell wrote:
>
> [EMAIL PROTECTED]:/$ find sys/devices | grep mmc
> sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0
>
This is strange. You should be getting more entries below that.
> /sys/block/mmcblk0/device
Where does this point?
Rgds
--
> tifm_set_drvdata(sock, NULL);
You call that before mmc_free_host() (which flushes the work queue), and I
assume something still needs it. Put in some BUG_ON() here and there and you
should be able to catch it.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer
07-02-11 23:27 device ->
> ../../class/mmc_host/mmc0/mmc0:b368
Is this with CONFIG_SYSFS_DEPRECATED off? It should be pointing to the
../../devices tree.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://puls
("Setting ... power 0"
> message) and still
> mmc_block continues to make requests like nothing happened.
>
How did you do the "after remove" detection? Patch?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio
uld always be sent against the current version of the kernel
(i.e. git HEAD). Usually the latest packaged release will also do.
(Note that I haven't had time to review your latest version of the driver)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.o
gt;
The argument is correct, so I'm guessing that your controller might be a bit
flaky and not handle the new timing. Can you enable MMC_DEBUG and send over the
dmesg?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
et full dmesg output with i/o error and mmc debug
> info, but i'll try if it helps
I'm afraid I can't help you without a dmesg dump. This problem is most
likely crappy hardware at some point, and I need details to make any
guess about what it doesn't like.
Rgds
--
-
Eugene Ilkov wrote:
> PXAMCI: irq 0004 stat 2140
Hang on. PXAMCI is a MMC controller, right? Perhaps the MMC timings
aren't overlapping properly with the new stuff... I'm going to have to
recheck my diagrams.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintaine
Pierre Ossman wrote:
> Eugene Ilkov wrote:
>> PXAMCI: irq 0004 stat 2140
>
> Hang on. PXAMCI is a MMC controller, right? Perhaps the MMC timings
> aren't overlapping properly with the new stuff... I'm going to have to
> recheck my diagrams.
Hmm... depen
uld be forgiving. So if you can figure
out what it is up to (and more exactly how it is provoked), I'll try to fix it.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
r does not work at this stage of the resume and interrupts may
> not be delivered (if
> card was removed, for example).
Now this sounds incredibly broken. A child device should never be resumed before
its parent. Pavel, can you comment?
Rgds
--
-- Pierre Ossman
Linux kernel, MM
d out as you remove the card. I don't see any mmc debug messages
that indicate that is trying to send more mmc requests.
You could add a printk to the queue thread in mmc_queue.c. That will allow you
to see exactly when it exits (which should be before mmc_remove_host() returns).
remove routine waits for mmcqd to
exit, so there can't be any code still alive that has a request going. (I am
also completely unable to reproduce this problem here).
Add more printk:s do verify how the code in mmc_block executes.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC m
t thing in the mmc_remove_host
> (and make sure that
> nothing gets scheduled into it after this).
>
This is fixed in -mm. Making sure that nothing gets scheduled is the driver's
responsibility. I've added checks to catch broken drivers though.
Rgds
--
-- Pierre Ossman
Linu
7;s probe method had finished. So mmc_block is
> quite involved, even
> though it does not affect the problem's resolution.
I agree that mmc_block's probe method will generate a whole bunch of requests.
But I don't see how that can be called given the scenario you describe
nters are no longer valid". It
is used to determine if the global receive buffer should be copied to
the provided one upon completion.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdes
er). You need to delay the removal in
some form, e.g. using the mmc workqueue.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
> baråäö.txt
bash: baråäö.txt: File exists
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 t
convert to a stripped version.
>>
>
> Yes. utf8 support is broken, and it will fail to convert letter case
> on many case. And it's why that is not recommended.
>
>
Is there any ongoing work to fix this? UTF-8 is standard on more or less
every distribution these days
hat.
>
> Acked-by: Petr Vandrovec <[EMAIL PROTECTED]>
I'll send it on to Linus then.
>
> Looks like a typo? requres => request ?
>
Ooops. I'll fix that. :)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio
rset=xxx,utf8"
> might help a bit.
>
These tests was with the "utf8" option.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http:/
off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
Thanks. I wonder how that happened.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.
ty we know for
> sure that device_add has exited.
>
>From -mm:
http://www.kernel.org/git/?p=linux/kernel/git/drzeus/mmc.git;a=commitdiff;h=e89bac488861ebadfca3a74321af19a262dcbd08
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Pulse
actly maxing out the network.
Input welcome.
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
so little code that it just
adds complexity to abstract it up to the core. Most hw get interrupts
for insertion/removal.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
Manuel Lauss wrote:
> au1xmmc: return error when encountering unhandled/unknown response type.
>
> Signed-off-by: Manuel Lauss <[EMAIL PROTECTED]>
>
Thanks, applied.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAud
Manuel Lauss wrote:
> au1xmmc: implement proper R/O switch detection.
>
> Signed-off-by: Manuel Lauss <[EMAIL PROTECTED]>
>
Also applied.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer htt
ork on this.
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
cpfs tend to default to using udp
with this in mind. ;)
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 li
e completely useless. So you can just
remove the last bunch aswell.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscri
hey use kmap but exceed page
limits (which happens to work on non-highmem pages).
I think the right solution is to let them use page_address() instead.
Would that be correct?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, co
Andrew Morton wrote:
>
> A quick scan indicates that the following files might be buggy in this
> regard:
>
> drivers/mmc/wbsd.c
> drivers/mmc/sdhci.c
This are probably even buggier than so. They really should be using
page_address(), it seems that kmap_atomic() gives the same result when
not us
ping!
Pierre Ossman wrote:
> Ok... how about this baby instead. I've replaced the stack allocated
> request structure by one allocated with kmalloc() and reference counted
> using an atomic_t. I couldn't see anything else that was associated to
> the process, so I belie
/SD bridge, so I'm the wrong person to contact
for this. You should contact whoever is in charge of USB storage devices
(which is what you've got).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pul
sooner rather than later as the
merge window is just around the corner.
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
-off-by.
>
I'll rework that into a separate quirk to indicate it's because of
broken hardware. It's only for unreleased hw so it's no rush. I just
wanted to see if it was related to your problem.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www
Hi Alex,
I'd like you to test and comment on the following patch.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Anderson Briglia wrote:
> Hi Pierre,
>
> How about now? Is better?
>
>
Locking problem is still there. You need to unclaim the host even when
claim fails.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core develope
gs. Have you tried
with several cards? And is it repeatable?
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
Anderson Briglia wrote:
> Hi Pierre,
>
> ext Pierre Ossman wrote:
>> Patch looks ok. But I never got an answer what the difference between
>> "change" and "assign" is.
>
> You're right, the command is the same, but the difference is the
> p
ch is 2 bytes).
>
This sounds very generic and not something that is specific to the
password command.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://ww
Anderson Briglia wrote:
> ext Pierre Ossman wrote:
>>
>> This definition makes them look like bits, which is not how they are
>> used.
>
> How can I improve this? Defining using integers directly?
>
Precisely.
Rgds
--
-- Pierre Ossman
Linux kern
Linus Torvalds wrote:
> On Fri, 1 Dec 2006, Pierre Ossman wrote:
>
>> git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git
>> for-linus
>>
>
> I get
>
> Already up-to-date.
>
> did you forget to push? Or is mirroring just rea
Yoichi Yuasa wrote:
> Hi,
>
> This patch has fixed the following build error abou au1xmmc.
>
Thanks. Applied.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, co
the right bit
> when composing the command data block.
> This definition makes the code more legible and simple.
In that case you need to change the code to make sure it is clear that
it is bits and not values. Also, your definition for
MMC_LOCK_MODE_UNLOCK is wrong.
Rgds
--
-- Pierre
reg ;)
Applied, thanks.
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-
Pierre Ossman:
mmc: Change SDHCI iomem error to a warning
Vitaly Wool:
mmc: fix "prev->state: 2 != TASK_RUNNING??" problem on SD/MMC card
removal
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
Anderson Briglia wrote:
> Hi all,
>
> Someone has comments for these patches?
>
>
I haven't forgotten about you, I just haven't had the time to look at
the latest set yet. Perhaps tonight, but I cannot promise anything.
Rgds
--
-- Pierre Ossman
Lin
ata
> pointed by that pointer, it access just
> the type of the pointer.
>
>
Yes, sizeof() is compile time and completely safe in this regard.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
mc_omap_switch_handler, host);
+ INIT_WORK(&host->switch_work, mmc_omap_switch_handler);
init_timer(&host->switch_timer);
host->switch_timer.function = mmc_omap_switch_timer;
host->switch_timer.data = (unsigned long) host;
en otherwise, regard R6 and R7 as
information the hw does not need to know about. Same thing in tifm_sd.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http
t;
Looks good. I'll queue up both patches for -mm.
--
-- 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
quest you cannot use them anymore.
Do you have any pointers to how it was solved with smbfs? Relevant
patches perhaps? Provided a similar solution can be applied here.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer h
that up and commit the patch set.
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 "u
written to the sysfs node.
And third, you're a bit excessive on the goto:s. E.g. out_unlocked is
used in a single place, so it is completely unnecessary. Please do a
general cleanup of the control flow.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.o
his release, and merged during the next.
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
valid data is the right thing to do.
And the warning about mmc_key is caused by this lack of error handling.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
Ping!
Pierre Ossman wrote:
> Linus, please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
>
> to receive the following updates:
>
> drivers/mmc/at91_mci.c | 11 +--
> drivers/mmc/omap.c |6 +++---
> 2
Sascha Sommer wrote:
> Hi,
>
> Attached is a very experimental driver for a Ricoh SD Card reader that can be
> found in some notebooks like the Samsung P35.
>
Impressive. Keep up the good work. :)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp:/
(Please keep me as cc as I will almost always overlook you replies
otherwise)
pierre Tardy wrote:
> Pierre Ossman drzeus.cx> writes:
>
>> Register functions
>> ==
>>
>> I also intend to write a couple of register functions (sdio_read[bwl])
>&g
Adrian Bunk wrote:
> On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
>> ...
>> Changes since 2.6.20-rc3-mm1:
>> ...
>> git-mmc.patch
>> ...
>> git trees
>> ...
>
>
> This patch makes the needlessly global struct mmc_key_type static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECT
look at the
symlink (e.g. /sys/class/fooclass/foodev -> /sys/devices/...) and follow
that one level up? If so, then this sounds a bit complicated. Especially
from shell scripts.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
ding out a new patch set.
This just creates extra work for us.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list:
Marcin Juszkiewicz wrote:
> PXA MMC driver supports not only PXA255 but also PXA250 and newer ones
>
> Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
>
Thanks. Applied.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
ones (easy2crack).
>
This sounds like policy though, so it is something user space should
concern itself with. We should just provide the infrastructure.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulse
;
Hmm... I can't find any such requirement in HEAD, or 2.6.18. What kernel
are you running?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rd
Vitaly Wool wrote:
> On 11/26/06, Pierre Ossman <[EMAIL PROTECTED]> wrote:
>> Hmm... I can't find any such requirement in HEAD, or 2.6.18. What kernel
>> are you running?
>
> 2.6.18 + -rt patches by Ingo.
>
I guess the check is in the rt set somewhere then
mmc: Add support for mmc v4 wide-bus modes
Pierre Ossman:
mmc: Fix mmc_delay() function
mmc: Support for high speed SD cards
mmc: sdhci high speed support
mmc: Flush block queue when removing card
mmc: correct request error handling
Tony Lindgren tony:
Add
(-)
Pierre Ossman (1):
mmc: get back read-only switch function
Ragner Magalhaes (1):
mmc-omap: fix sd response type 6 vs. 1
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 41bfb5d..918477c 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -427,6 +427,21
ices are present, even though it can't probe them.
So to answer your question; no, the firmware doesn't have to tell Linux
about the devices.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaud
On Mon, 02 Jul 2007 15:32:00 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Nicolas Ferre wrote:
> > Fixes hanging using multi block operations (seen during CMD25).
> > Follows closely the datasheet flowcharts.
> >
> > This piece of code handles better big fil
On Mon, 09 Jul 2007 14:58:16 +0200
Nicolas Ferre <[EMAIL PROTECTED]> wrote:
> Fixes hanging using multi block operations (seen during CMD25).
> Follows closely the datasheet flowcharts.
>
> This piece of code handles better big file writing. I had to take
> care of the notbusy signal during write
On Tue, 10 Jul 2007 12:23:06 +0530
"Trilok Soni" <[EMAIL PROTECTED]> wrote:
>
> RTC part was reviewed and acked-by RTC maintainer. CCing to lkml and
> MMC maintainer this time.
>
There's nothing that really touches any mmc code in there. So I have no
comments a
and rework to match flowcharts
Pierre Ossman (5):
mmc: bounce requests for simple hosts
mmc: refactor bus operations
mmc: refactor host class handling
mmc: move layer init and workqueue to core file
mmc: fix silly copy-and-paste error
Rolf Eike Beer (1):
sdhci
What was the verdict here? Were you satisfied with this or do you need a change?
Pierre Ossman wrote:
> Andrew Morton wrote:
>> Whatever. I think you can work it out ;)
>>
>>
>
> Bare with me, I just woke up ;)
>
>> while (driver_probe_done() ||
Andrew Morton wrote:
> On Thu, 31 May 2007 13:20:48 +0200 Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
>> What was the verdict here? Were you satisfied with this or do you need a
>> change?
>>
>
>
> I was kinda hoing to see version #2 with that funny l
Andrew Morton wrote:
> Could we have an update for Documentation/kernel-parameters.txt, please?
>
Sorry, of course.
New patch included. "rootwait" is also just a boolean, so make sure it
is treated as such.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC mainta
dd myself as maintainer for this
> driver. Here is the entry below.
>
Wonderful. And good luck ;)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://
to
out-of-tree stuff, having these as exported symbols shows that they are
part of the API. Removing them might risk people going about doing
something silly because they don't know the functionality exists, and
we might not spot it at patch review time.
Rgds
--
-- Pierre Ossman
Lin
nfig
option that keeps the card around across the suspend.
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
Haavard Skinnemoen wrote:
>
> What exactly makes this unreliable? This is done almost exactly the
> same way for SCSI. See drivers/scsi/scsi_wait_scan.c.
>
I am not against the function of waiting for an initial scan, what I oppose is
using side effects to achieve that function. I do not want to
Hi Nicolas,
You seem to be the source of this workaround, and also the maintainer of
PXA. So I guess this falls into your lap either way. Highlights from my
discussion with Russell:
Pierre Ossman wrote:
> Russell King wrote:
>
>> > Dug out from the ARM kautobuild...
>> &g
Haavard Skinnemoen wrote:
>
> Ok, is there any better way to achieve the same this? As far as I
> can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the
> same purpose -- it ensures that scans that have already been started
> will have completed before the function continues.
>
Not
Haavard Skinnemoen wrote:
> On Thu, 10 May 2007 17:58:27 +0200
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
> Is there any way this can happen? Host controller drivers register
> themselves from module_init(), their probe() function gets called,
> which calls mmc_add_hos
han the current code even when it was compiling.
>
>
I would think that it would be better to look at just MMC_RSP_136 and
MMC_RSP_CRC in case we get future variations.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
also one of the Linux-unfriendly vendors so no hope
of getting them to cough up some info.
We could do some silly polling hack. It isn't clean, but it might get things
somewhat working at least.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Pu
Haavard Skinnemoen wrote:
>
> You're right about my assumptions. Are there any existing drivers that
> break them? Are there even any usb-based controllers around? I though
> most usb-mmc controllers used the USB Mass Storage class and thus
> don't use the mmc subsystem at all.
>
Yes, but they m
Haavard Skinnemoen wrote:
> On Sun, 13 May 2007 15:34:51 +0200
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
>> Does that sound like something that would work for you? From my point of view
>> it's a much cleaner solution that has the benefit of not being tied
Nicolas Pitre wrote:
> ... and make it depend on the response flag instead of the command type.
>
> Signed-off-by: Nicolas Pitre <[EMAIL PROTECTED]>
> ---
>
Fantastic. Applied.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.o
oping I could get some fix for at91
aswell, but that doesn't seem to be happening so I'll push in a bit.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
->quirks & SDHCI_QUIRK_NO_CARD_DETECT_INT) {
> + host->detect_timer.expires = jiffies + 3 * HZ;
> + add_timer(&host->detect_timer);
> + }
> }
>
> static void sdhci_tasklet_finish(unsigned long param)
>
I wonder if three seconds i
Testing and/or comments welcome.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 7c542a5a027caa95bb00f8a8223c7e4aef88c931
Author
Al Viro wrote:
> On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
>
> First of all, please do not put patches in attachments.
>
>
My mailer tends to fsck them up if I just paste them. And it's attached
without any base64 silliness, so most people can usua
New suggestion.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit bb8c44ee8b4d584295add58a4ea2f03b9938fc3c
Author: Pierre Ossman
++
drivers/mmc/host/sdhci.c |9 +
include/linux/major.h |2 ++
5 files changed, 35 insertions(+), 46 deletions(-)
Nicolas Pitre (1):
pxamci: fix PXA27x MMC workaround for bad CRC with 136 bit response
Pierre Ossman (2):
sdhci: handle dma
ve included everyone that has been
involved in the drivers in one way or another in case one or two maintainers can
actually be found.
Even if you don't feel like maintaining this, feel free to suggest mailing lists
that should be added to the entries.
Rgds
--
-- Pierre Ossman
tailed) and stick a MOTOROLA
in the front.
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 "
Syed Mohammed, Khasim wrote:
> Hi Pierre,
>
> Carlos Aguiar and Anderson Briglia are interested in making sure the driver
> works for existing boards as they have access to them, and I can make it work
> for new omaps (2430, 3430).
>
Great. I'll update my info.
--
301 - 400 of 486 matches
Mail list logo
