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
(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://pulseaudio
;
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.rdeskto
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.
An
a nice change, it confuses things to have two changes
in one commit. Could you split them up and base it on my "for-andrew"
branch?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio
The error report is a bit thin so Pavel will need to
elaborate a bit more.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To
't have the time and energy to jump through all the hoops required to get
an official number right now. Most users use udev and those that don't can use
the "major" parameter for mmc_block.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Pul
Pavel Machek wrote:
>
> That's okay, but if one of those savages got major for you, would you
> be willing to use it? :-).
Indeed I would.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulse
spoken about MX1 SDHC maintainership.
> I am attaching my subscription.
> I am not sure about mailing list field there.
> Do you suggest this one, ALKML or other?
>
>
sdhci is outright wrong. That list is only for the sdhci driver. I
suggest LAK or LKML, preferably the one with
nt
> sets are already inconsistent with one claiming
> to describe ranges and the other specific voltages.
>
> Only the SDHCI driver uses the host->vdd defines and
> it is easily fixed to use the OCR defines.
>
> Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
>
>
t;mode == MMC_MODE_SD && (ocr & MMC_VDD_165_195)) {
>
Ooops. host->mode should have been removed by now.
Otherwise the patch looks good. Just fix these points and I'll include it.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kerne
suggested solution was to serialize all the
block subsystems so that only one was present on the stack at any given
time.
I was constantly hitting this problem a few years ago when I was running
md+xfs+nfs. The fix was in -mm back then as well. ;)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC main
uency. With tickless idle.. that's not what you
> want.
>
So with a local apic, and acpi_pm as clocksource, I shouldn't be getting timer
interrupts? Yet I do. Which I assume means that the kernel will still get woken
up very often.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintain
Arjan van de Ven wrote:
> On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
>
>>
>> So with a local apic, and acpi_pm as clocksource, I shouldn't be getting
>> timer
>> interrupts?
>>
>
> timer interrupts as in "irq0"?
>
>
o use HPET even if it is not enabled by the
> BIOS. This will still end up on IRQ#0, but will give way longer idle
> sleeps than the PIT.
>
>
So then the next two questions are; is it possible to disable C3 and is
it a net power gain to get rid of the wakeups in favor of having C3.
Rgds
contains the following patches against 2.6.21-rc1:
>>
>
> Possible build fix for
>
> drivers/built-in.o: In function `mmc_queue_thread':
> /mnt/md0/devel/linux-work5/drivers/mmc/card/queue.c:76: undefined reference
> to `blk_queue_plugged'
> make: *** [.tmp_vmlinux1]
anently screwed, or just temporarily.
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 li
Arjan van de Ven wrote:
> if it's something built in the last year or two you have the hw.
>
>
I have an ICH4-M, and from Intel's datasheets it looks like I got the
short straw..
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAu
using
> kernel 2.6.20.
>
Memory stick is completely unsupported. We haven't got any specs for neither the
the host controllers or the protocol. So I would guess it would be quite some
time before memorystick is supported directly by Linux.
Rgds
--
-- Pierre Ossman
Linux kernel
Philip Langdale wrote:
> Fix handling of low voltage MMC cards.
>
>
Sorry, my fifo filled up and you got stuck at the far end.
I've applied this and will push to andrew in a bit.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAu
re delay after you power up in case the controller needs some
time to stabilize.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsub
down when
it gets annoyed, so that might be what you're seeing here.
Other than that, I'm not sure I can help that much. The stop commands should
never wedge the card, so that isn't the issue (unless the card is buggy).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhtt
Mockern wrote:
> Hi,
>
> I have a problem with SC card. System hangs when I insert SD card. But I have
> no any problems with MMC card.
>
Bug reports should include the driver maintainer in the list of recipients.
Which SD/MMC controller do you have?
Rgds
--
-- Pierre
Mark Lord wrote:
> Another regression, for Pierre Ossman this time.
>
> My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles.
> Worked fine, without all of the noise, in all previous kernels up to
> 2.6.20+.
>
This looks like a PCI configuration issue. Ca
ce we're seeing this problem I assume the
kernel's interrupt code isn't aware of PM states?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://w
Pierre Ossman wrote:
> Mark Lord wrote:
>> But.. in the middle of all of this, we now see the SHDCI code
>> trying to talk to its as-yet-not-restored device, and being rather
>> noisy about it all:
>>
>
> Not quite. I'd say it's the kernel calling the interrupt
Mark Lord wrote:
> Pierre Ossman wrote:
>>
>> Hmm... I guess it can't be as the interrupt handler isn't associated
>> with a
>> device, just a random pointer.
>>
>> So either release the interrupt (which seems a bit unsafe as then we
>> might not
&
what you prefer. Or is moving files
around barred from the kernel?
--
-- 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
so it's only fair that I have
to clean it up.
> But whatever. What are we going to do about $SUBJECT?
>
It should go in now, along with a fix to unregister the interrupt. I
have a bunch of fixes I intend to push to Linus today and I'll include
this in that group.
Rgds
--
-- Pier
/sock.c | 151 ++--
include/linux/mmc/host.h |8 +++
include/linux/ncp_fs_sb.h |2 +
6 files changed, 184 insertions(+), 115 deletions(-)
Mark Lord (1):
sdhci: make isr tolerant of read errors
Pierre Ossman (3):
ncpfs: make sure
-by: Adrian Bunk <[EMAIL PROTECTED]>
>
Indeed, but it's probably better to just remove it rather than have old crud
lying around.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop
g these is 8 bit data bus, but as
we do not currently have a controller for that I think the point is moot.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http
ags &
(MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY|MMC_RSP_OPCODE))
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To uns
e released
control of the card. At that point there is no one else accessing the
device. If you see something else, then we have a bug somewhere.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio
a problem, please try to figure out who it is
accessing the device.
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 thi
Manuel Lauss wrote:
> Hi,
>
> here's a trivial patch which adds R6 reponse support to the au1xmmc
> driver. Fixes SD card detection / operation.
>
NAK. MMC_RSP_R1 and MMC_RSP_R6 have the same value so this will break
the switch.
Rgds
--
-- Pierre Ossman
Linux kernel,
stops with CMD7 returning error.
>
Can I see a dump with MMC_DEBUG enabled?
On a related note... Would you, or anyone else you know, be willing to
sign up as official maintainer of this driver? Otherwise I'll have to
mark it as unmaintained.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC main
t;
}
I'm not particularly proud of the second chunk though. Ideas on how to
handle when we actually get a transmission problem and not just getting
killed by a signal?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core develop
ld answer, but would gave you bogus answer.
>
This sounds promising though. In that case it wouldn't be necessary to
store the entire request, just the sequence number, right?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
also works now on the previously
> thought-to-be-broken HW.
>
So in order to detect any similar problems in the future, I'd like a
patch that adds a "default:" to that switch statement.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudi
aining it? I have source for this
> driver which also implements SDIO, also from AMD. It's a bit dated (for
> 2.6.11). But I'm willing to look into problems, as long as I have access
> to the hardware.
>
I have not heard anything from Raza, so I wouldn't even know who to
contact there.
Rgds
--
r
*server, int size,
DDPRINTK("do_ncp_rpc_call returned %d\n", result);
- if (result < 0) {
- /* There was a problem with I/O, so the connections is
-* no longer usable. */
- ncp_invalidate_conn(server);
- }
return resu
Christopher "Monty" Montgomery wrote:
> This patch was generated against 2.6.20-rc5; it fixes a bug that
> cropped up in a late 2.6.19-mm kernel.
>
> When ALSA's sysfs device creation was converted from using
> class_device_create() to device_create(), the fourth param from
>
Christopher "Monty" Montgomery wrote:
>
> My machines and the fedora rawhide machines using the 2.6.20-rcX
> releases look nothing like what you pasted. If they did, hald would
> be working... (I'll note that bugs have also been logged against
> Pulse and HAL by users having trouble, so it's
Christopher "Monty" Montgomery wrote:
>
> Interesting to know. Looking more closely, it looks like machines
> here are split between the messed up output I forwarded previously and
> the output that is expected. All of my personal boxes are messed up.
>
There is some option about deprecated
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 http://puls
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
--
-- Pierre Ossman
Linux kernel, MMC maintainer
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 maintainerh
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... depending on wh
ving. 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 http://
imer 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
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).
Rgds
--
-
s 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 maintainerhttp://w
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
Linux kernel, MMC maintainer
d 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.
Rgds
--
-- Pierre Oss
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
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
-
To
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 the line &q
rt 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.
Rgds
-
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, core dev
t=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://www.
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
PulseAudio
is it safe to try and share an
> interrupt with this chip anyway?
>
This is all perfectly valid. The wbsd hw and driver can handle sharing the
interrupt line, while the floppy cannot. If you want to avoid this, then don't
load the floppy driver or assign another irq for wbsd.
Rgds
--
s with SD?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
i 17548 0
> tifm_core 7960 2 tifm_sd,tifm_7xx1
> mmc_core 24096 3 mmc_block,tifm_sd,sdhci
>
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
r
crash if it is).
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&q
mmc
> problem.
> The problem is described here:
> http://lists.freedesktop.org/archives/hal/2007-January/006960.html
>
Odd. This might be the whole sysfs restructuring thing causing problems. Can you
check if that user has CONFIG_SYSFS_DEPRECATED on?
Rgds
--
-- Pierre Ossman
L
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
uld 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 this list: send t
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 maintainerhttp
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
ot;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, cor
lways 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.org
Pulse
Pavel Machek wrote:
> Hi!
>
> (Machine was suspended/resumed before this).
>
> mount /dev/mmc1 /mnt
>
Driver? Reproducable? Vanilla git kernel?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core devel
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 line
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 http://www.rdesktop.org
-
To unsubscribe from this
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
egwork 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&q
d ncpfs 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 thi
pletely 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 unsubscribe fr
age
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, core developer htt
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
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 believe this sh
/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://pulseaudio.or
ther 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 from this l
e 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.kernel.org
PulseAudio, core developer http://pulseaud
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
>F
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
ough. I'd
guess it is present for non-highmem so that things behave somewhat
similar for both the highmem and non-highmem cases.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop,
final
response copy if the process has gone belly up.
Now my next question in that case is, what is the purpose of
server->packet. Couldn't this buffer be provided by the caller like the
response buffer?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel
vendors who either
can provide samples or where the hardware is cheap and freely available
so I can just go out and by one.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
Salt (1):
mmc: Power quirk for ENE controllers
Manuel Lauss (2):
mmc: au1xmmc: implement proper ro switch detection
mmc: au1xmmc: return errors for unknown response types
Philip Langdale (1):
mmc: Add support for SDHC cards
Pierre Ossman (13):
mmc: replace host
(-)
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
Madhusudhan c wrote:
>
> Suppose a host controller is capable of suporting 8-bit and it tells
> the core that it can support 8-bit. Now the card that is plugged in
> might or might not support 8-bit based on the type of the card. There
> is no field in the ext_csd which will tell you what bus
arrant, or even have room for, a
rewrite. And judging from your code it looks more like reorganising the code
that's already there.
In short, this "rewrite" won't fly. Report the issues you have with the current
driver and work with the existing maintainer to get them fixed.
Rgds
--
Madhusudhan c wrote:
>
> Philip asked me about the access to the 8-bit controller. We might not
> be able to provide you direct access to the hardware platform as it
> requires involvement of business managers and so on. But can I be of
> help by testing your code on our platform and leting you
601 - 700 of 964 matches
Mail list logo
