Madhusudhan c wrote:
Hi Pierre/philip,
Hi Madhusudhan,
Feel free to add me as cc in the future if you want me to notice your mail ;)
This is regarding the MMCv4 support that came in as part of the MMC
core of 2.6.20 linux kernel version.
The high speed MMC cards can support 4-bit/8-bit
Madhusudhan c wrote:
Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support
long back, which had the bus testing procedure implemented and it
works fine. I am able to write and read the data pattern back
successfuly with his patch. I am not sure why his patch was not
Madhusudhan c wrote:
The bus test procedure from this patch can be adopted to the MMCv4
support in the MMC core with small changes to do bus testing procedure
only if the host sets the capability to support 8-bit. That way we
dont break the legacy code. What do you think?
Until 8-bit SD
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 width
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.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from
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 unsubscribe from this list: send the line
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
PulseAudio, core developer http://pulseaudio.org
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://pulseaudio.org
rdesktop
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 the most MX1 users and/or
developers.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC
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]
Looks good. I'll queue it up.
Rgds
--
-- Pierre Ossman
Linux kernel
. 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.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
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: Remove stray
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 the line unsubscribe linux-kernel in
the body
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
--
-- Pierre Ossman
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://www.kernel.org
PulseAudio, core developer http
-
../../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://pulseaudio.org
rdesktop, core developer
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, core developer http://pulseaudio.org
rdesktop, core developer http
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
PulseAudio, core developer
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://pulseaudio.org
rdesktop, core developer
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 maintainerhttp://www.kernel.org
PulseAudio, core developer
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 maintainerhttp
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 where you look, you get different
block layer problem.
The block layer can get a bit fuzzy when you start yanking device out from under
it. That said, the mmc block driver should 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
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, MMC maintainerhttp
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
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio
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://www.kernel.org
PulseAudio, core developer http
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 maintainerhttp://www.kernel.org
PulseAudio, core developer
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 Ossman
Linux kernel, MMC maintainer
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
rdesktop, core
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 unsubscribe from this list: send the line unsubscribe linux
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
. 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
--
-- Pierre Ossman
Linux kernel, MMC maintainer
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 developer http://pulseaudio.org
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
PulseAudio, core
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 unsubscribe from this list: send the line
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 maintainerhttp://www.kernel.org
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 Ossman
Linux
[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 developer http://pulseaudio.org
rdesktop, core developer
.
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.rdesktop.org
-
To unsubscribe from this list: send
.
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 in
the body
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, core developer http://pulseaudio.org
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 maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop
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 maintainerhttp://www.kernel.org
PulseAudio
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?
Yes:
0:9786349XT-PIC-XTtimer
you shouldn't if you
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
--
-- Pierre Ossman
Linux
:
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] Error 1
Huh? Is blk_queue_plugged() deprecated?
--
-- Pierre Ossman
Linux kernel, MMC
, 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 line unsubscribe linux
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
PulseAudio, core developer
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, MMC maintainerhttp://www.kernel.org
PulseAudio, core
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. Can you bisect which
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://www.rdesktop.org
-
To unsubscribe
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 handler of a
currently sleeping device. Since
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
get it back), or handle states at the start of the isr.
From
. 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 this list: send the line
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
--
-- Pierre Ossman
Linux kernel, MMC maintainer
/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
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, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send
seen any differences from SD.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe from this list: send the line
On Sun, 6 Jan 2008 20:02:46 -0800
raki john [EMAIL PROTECTED] wrote:
Can I replace drivers/mmc directory in 2.6.22.1 with drivers/mmc
directory in 2.6.23.1. Does this cause any issues. Is there any code
in drivers/mmc in 2.6.23.1 which depends on other features in kernel
2.6.23.1.
I'm
On Mon, 7 Jan 2008 15:31:32 -0800
raki john [EMAIL PROTECTED] wrote:
Hi All,
Please CC me on responses.
I am working on a SD/MMC Host driver .
I am getting kerenl oops after mmc_register_card () is called.
i working on LINUX 2.6.22.1 kerenl.
What might be the reason for this.
. And that is
not the kind of support that needs a distinction in the code.
So, again, if you feel that there is a hardware difference between 4-bit MMC
and 4-bit SD then please elaborate as it is my understanding that they are
identical.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
is
4-bit, regardless if it's MMC or SD. So if you want this patch to go in you
need to explain why there is a difference for the blackfin controller.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
On Tue, 8 Jan 2008 16:44:08 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
On Jan 8, 2008 3:49 PM, Pierre Ossman [EMAIL PROTECTED] wrote:
So, again, if you feel that there is a hardware difference between 4-bit
MMC and 4-bit SD then please elaborate as it is my understanding
cards, SDHC and MMC 4.2 addressing. All addresses are
32-bit.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe from
CONFIG_MMC_DEBUG and include a copy of the output of dmesg.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe from
. But
I'm not yet convinced that the problem is related to MMC vs SD.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe
some empirical data, before I'm ready to accept
Mike's patch.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe from
that means there's two options for you right now; experiment wildly and hope
you get lucky and find how to avoid whatever bug your particular chip has, or
try to get information from Marvell or Raon about how to interface with the
chip.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Fri, 11 Jan 2008 04:08:53 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
On Jan 11, 2008 3:40 AM, Pierre Ossman [EMAIL PROTECTED] wrote:
So it's far more probable that you've misdiagnosed your error than this
being the actual problem.
the guys who design the silicon are telling us
to have a controller-side
pull-up for MMC cards. And the docs said the default was not to provide that
(in order to use the internal pull-up that most, but not all, SD cards have for
detection). Might be something to look at if you haven't already.
Rgds
--
-- Pierre Ossman
Linux kernel
models
relied on it for card detection.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe from this list: send the line
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman [EMAIL PROTECTED] wrote:
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume() and keeping the card in a suspended state.
On Sat, 12 Jan 2008 14:39:47 +0100
Rene Herman [EMAIL PROTECTED] wrote:
On 12-01-08 12:12, Pierre Ossman wrote:
I'm a bit confused here. Bjorn Helgaas wanted to remove the
pnp_start/stop_dev() calls completely, and you want them called all the
time. :)
Wanted where? Haven't seen
has
tested it yet.
So I guess this is back on Bryan/Cliff to make work
Thanks for pushing back.
It's what I do ;)
If you provide some dumps of your test runs next week, I'm sure I can help with
some qualified guesses as to what the problem might be.
Rgds
--
-- Pierre Ossman
On Sat, 15 Sep 2007 12:54:08 -0700
Philip Langdale [EMAIL PROTECTED] wrote:
Thanks to Matt Domsch and Rezwanul Kabir at Dell, we know how to
disable the MMC controller on the multi-function Ricoh R5C832. The
MMC controller needs to be disabled or it will steal MMC cards from
the SD controller
: Cornelia Huck [EMAIL PROTECTED]
mmc: Avoid double sdio_unregister_bus() on module unload.
Signed-off-by: Cornelia Huck [EMAIL PROTECTED]
ps. :)
This has been pushed to kernel.org. Andrew, update at will.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
, and the immediately issued subsequent
commands also fail since the card state was never checked before
sending these commands.
(There was a discussion about these cards at the thread: MMC:
CRC Errors with 2GB cards)
I'm confused. Didn't the previous fix solve your problems?
Rgds
--
-- Pierre
)
(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;
}
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
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 unsubscribe linux-kernel
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 be slow as hell though.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
with this board?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wed, 12 Dec 2007 20:12:47 +0100
Pierre Ossman [EMAIL PROTECTED] wrote:
Linus, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
*ping*
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core
say must, and I've seen cards with bogus data in
there so I'm afraid we can't rely on the fields being zero. The version field
is the only decent way of determining what to expect in the rest of the
structure.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
operations.
This is still voodoo to me, so I'll have to take your word for it. :)
Comments welcome!
Looks good to me.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core
. Make sure you can either handle such requests, or fail them with
-EINVAL.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit
, 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;
--
-- Pierre Ossman
: 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://pulseaudio.org
rdesktop, core
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 that previously worked
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.org
PulseAudio, core developer http
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. Please
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 of arch?
We could use something
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 see a
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 incrementing address to
work
to put that pain and what compromises to make.
BTW. Is the API for the exported SDIO core functions documented
anywhere ?
Yes, as kerneldoc tags for the relevant functions. Have a look in
drivers/core/sdio_io.c if you don't want to build the full document.
Rgds
--
-- Pierre Ossman
. ;)
(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 http://www.rdesktop.org
-
To unsubscribe from
you have any evidence that any card drivers will use
sdio_io_rw_ext_helper() in a manner that needs the START ADDRESS to be
changed 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
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
(which can incur a performance hit).
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
1 - 100 of 964 matches
Mail list logo
