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
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 causes
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
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 may
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
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 configure
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
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
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
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
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
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 8x0 add
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.
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
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
down(>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)
{
}
@@ -1589,7 +1903,7 @@
.name = DRIVER_NAME,
.id
John W. Linville wrote:
>On Mon, Jul 04, 2005 at 12:22:53AM +0200, Pierre Ossman wrote:
>
>
>>After suspend the driver needs to retest link status in case the cable
>>has been inserted or removed during the suspend.
>>
>>Signed-off-by: Pierre Ossman <[EMAIL
Pierre Ossman wrote:
> I'm having problem with the interrupt getting killed after suspend with
> my 8139cp controller. The problem only appears if the cable is connected
> during resume (before suspend is irrelevant) and the interface is down.
>
> Both suspend-to-disk and suspend
Richard Purdie wrote:
> This fixes what looks like a bit/byte counting error in the MMC/SD code
> which was causing data corruption (in the -mm tree).
>
> Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
Ooops... Must have been late in the evening. Sorry about that blunder.
Rgds
Pierre
-
To
Russell King wrote:
>
>I still don't like the needless duplication. How about doing it this
>way (see the attached patch.)
>
>Note: I also intend to move MMC over to using an IDR for the host
>numbers, which is why we need to setup the name at registration
>time, not allocation time.
>
>
>
Pierre Ossman wrote:
> Pierre Ossman wrote:
>
>>I'm having problem with the interrupt getting killed after suspend with
>>my 8139cp controller. The problem only appears if the cable is connected
>>during resume (before suspend is irrelevant) and the interface is down.
&
with no side-effects found.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
---
Previously submitted: 2005-03-16
Previously submitted: 2004-12-03
Index: linux-wbsd/drivers/mmc/mmc_block.c
===
--- linux-wbsd/drivers/mmc/mmc_block.c (re
Jörn Engel wrote:
>Question came up before, albeit with a different phrasing. One
>possible approach to benefit from this ability would be to create a
>"forget" operation. When a filesystem already knows that some data is
>unneeded (after a truncate or erase operation), it will ask the device
Jörn Engel wrote:
>On Tue, 16 August 2005 20:13:36 +0200, Jörn Engel wrote:
>
>
>>Yes. Most filesystems expect to find either 1) old data or 2) new
>>data. Blocks full of 0xff are non-expected.
>>
>>
>
>Maybe this isn't obvious. Because of this expectation, it is
>absolutely not safe to
Andrew Morton wrote:
>The fact that this is enabled under the experimental
>CONFIG_MMC_BULKTRANSFER seems unfortunate. I mean, if the code works OK
>then we should just enable it unconditionally, no?
>
>
>
It was made this way to make Russell more open to it. I have since not
recieved any
Russell King wrote:
>
>I'd rather not. The problem is that we have a host (thanks Intel)
>which is unable to report how many bytes were transferred before an
>error occurs. My fear is that doing anything other than sector by
>sector write will lead to corruption should an error occur.
>
Russell King wrote:
>On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote:
>
>
>>We had this discussion on LKML and Alan Cox' comment on it was that a
>>solution like this would be acceptable, where we try and shove
>>everything out first and then fa
Alan Cox wrote:
>On Iau, 2005-08-18 at 09:26 +0200, Pierre Ossman wrote:
>
>
>>everything out first and then fall back on sector-by-sector to determine
>>where an error occurs. This will only break if the problematic sector
>>keeps shifting around, but at that point
Pavel Machek wrote:
>>* Transport problem. The driver will report back a CRC error, timeout or
>>whatnot and break. We might not know how many sectors survived so we try
>>again, going sector-by-sector. We might get a transfer error again,
>>possibly even before the previous one. But at this
Russell King wrote:
>
>Hmm, I think I've gone back to preferring something similar to your
>original approach actually. I've also included the IDR patch.
>
>
>
Ok. Just as long as it works. :)
My two concerns are:
* Things that assume there's a name for every kobject.
* Things that assume
Pavel Machek wrote:
>
>Maybe the card is pretty close to going to crash, but... two disk
>successive disk errors still should not be cause for journal
>corruption.
>
>[Also errors could be corelated. Imagine severe overheat. You'll
>successive failing writes, but if you let cool it down, you'll
Adrian Bunk wrote:
> [ this time with a better subject ]
>
> "extern inline" doesn't make sense.
>
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
Isn't 'extern inline' an old gcc trick to force inlining? (instead of
just hinting)
-
To unsubscribe from this list: send the line
Anderson Briglia wrote:
> Ok. I will fix the code and send another version of this patch on the V9
> series e-mail thread.
>
Have you found the time to fix this?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core
ck, and doesn't contain a fix for it.
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 &qu
end away.
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
lease add a "--" after the signed-off-by lines so that git can
parse the email.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdeskto
RSP_CRC)
> +#define MMC_RSP_R7 (MMC_RSP_PRESENT|MMC_RSP_CRC)
>
> #define mmc_resp_type(cmd) ((cmd)->flags &
> (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY|MMC_RSP_OPCODE))
>
>
Wrong. R7 is defined as MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE.
(So is R6 btw, wonder why tha
e MMC layer).
- Could you change the patch so that it covers all ENE controllers and send it
out for testing on sdhci-devel? That way we could see if there are any more ENE
controllers that will benefit from this
quirk. Just remember to ask people for a lspci.
Again, very good work.
Rgds
--
atic int mmc_mtd_probe(struct mmc_card *card)
> +{
> + struct mtd_info *mtd;
> + int ret;
> +
> + if (!(card->csd.cmdclass & CCC_ERASE))
> + return -ENODEV;
> +
You should probably check for CCC_BLOCK_READ here.
And your driver needs to check if th
my own email from the list, so a "Reply All" includes myself in the to list.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
ersion of the protocol, a version where
addressing is done on a sector (512 byte) basis instead of bytes.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer h
Russell King wrote:
>No no no no no. Repeat after me ten times. Empty or non-existant release
>functions are bad and cause oopsen. I will not create code which does
>this.
>
>
Sorry. I thought it was a generic cleanup function and since nothing was
allocated in the register function I
Russell King wrote:
>The allocation function should initialise class_dev as much as possible.
>The registration function should add the class device with the class
>model. The unregistration should remove the class device from the class
>model, but _not_ free it. The free function should drop
Russell King wrote:
>On Fri, Jul 15, 2005 at 10:21:43PM +0200, Pierre Ossman wrote:
>
>
>>Russell King wrote:
>>
>>
>>>Also note that since we have a class_dev, the mmc_host 'dev' field can
>>>be removed. However, we'll probably have to update
Sorry about reporting this error so late but the machine in question had
gone some time without upgrades.
The problem I'm seeing is that IRQs stop working for one of the IRQ
slots on the machine. It's only that slot, not the entire IRQ, since the
two slots (it's a small machine) both get routed
Pierre Ossman wrote:
> ** PCI interrupts are no longer routed automatically. If this
> ** causes a device to stop working, it is probably because the
> ** driver failed to call pci_enable_device(). As a temporary
> ** workaround, the "pci=routeirq" argument restores
Jesper Juhl wrote:
>
>Have you tried the suggestion given "... As a temporary workaround,
>the "pci=routeirq" argument..." ?
>You could also try the pci=noacpi boot option to see if that changes anything.
>
>
No, I missed that one. The machine works fine with either of those two
options. I
Adds a new ios for setting the chip select pin on MMC cards. Needed on
SD controllers which use this pin for other things and therefore cannot
have it pulled high at all times.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux/drivers/mmc
Use the chip select ios in the wbsd driver.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux/drivers/mmc/wbsd.c
===
--- linux/drivers/mmc/wbsd.c (revision 161)
+++ linux/drivers/mmc/wbsd.c (working copy)
@@ -42,7
Only show the scr file in sysfs for SD cards. Previously this was
present for all cards but had a contents of 0 for MMC cards.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
---
Meelis Roos wrote:
>
> It's OK then - I'm not using any suspend and I had a problem that my
> machine powered down instead of reboot. The patch that went into 2.6.13
> after rc7 fixed it for me. So the current tree is OK for me and if it's
> OK for you too after suspend2 changes then this case
Eric W. Biederman wrote:
>Hmm. Looking at that bug report it specifies 2.6.11. Does this
>problem really happen in 2.6.13?
>
>
>
I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc
only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch
for 2.6.13 which fixes
Eric W. Biederman wrote:
>Thanks.
>
>This is clearly a code path I missed when I was fixing things.
>
>When I made the final acpi change I checked for any other users
>of device_suspend and it seems I was blind and missed this one.
>Looking again...
>
>The patch in the bug report looks correct.
Register interrupt handler when net device is registered. Avoids missing
interrupts if the interrupt mask gets out of sync.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
---
The reason this patch is needed for me is that the resume function is
broken. It enables interrupts unconditi
Jeff Garzik wrote:
>
> Where is CONFIG_PM?
>
> Jeff
I'm not sure you're receiving my mails, but I'll give it a try anyway.
It would also seem that my MTA is choking on your MX entries. I'll look
into that once I get home.
CONFIG_PM is missing because of consistency with i8259.c, on which
It would seem that swsusp doesn't properly suspend devices, or more
precisely it wakes them up again before suspending the machine.
The problem is in swsusp_suspend(). It is designed as if
swsusp_arch_suspend() would suspend the hardware, when in fact all it
does is prepare for a suspend. The
Rafael J. Wysocki wrote:
>On Wednesday, 7 of September 2005 13:20, Pierre Ossman wrote:
>
>
>>It would seem that swsusp doesn't properly suspend devices, or more
>>precisely it wakes them up again before suspending the machine.
>>
>>
>
>Yes, it does.
e. I thought we needed it before both SD_APP_SEND_OP_COND calls but
> it's only needed before the second one so I've moved it inline into
> mmc_setup.
>
>
The spec says we need it at both (even though it might not be so in
practice). We should follow the spec first and foremost.
mmc_send_op_cond(host, host->ocr, NULL);
> + }
>
> mmc_discover_cards(host);
>
>
Nah... I think a mmc_send_if_cond() would be cleaner. The setup routine
should contain the sequence of events needed, while we abstract the
really low level grunt work
ggest trying without ndiswrapper loaded.
As this is now a tifm_sd related issue, I would recommend that Alex
Dubov takes over and the list of choice being the kernel mailing list
(both cc:d).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core d
driver works is unsafe.
>
>
Amen to that. All hw vendors that implement this particular form of
brain damage should be dragged out and shot.
I'll fix a patch for this later on.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAud
Philip Langdale wrote:
> Pierre Ossman wrote:
>
>> Amen to that. All hw vendors that implement this particular form of
>> brain damage should be dragged out and shot.
>>
>> I'll fix a patch for this later on.
>>
>
> See my updated Take 3 patch. I'v
newer cards only support a block size of 512 bytes, the most future
proof would be to use that.
>
> I tried to do multiple block access at first, but then took it out again.
> If it turns out valuable to have these, I'll implement it properly later.
> Does it make a difference per
and will be more fine grained in a final
version, but the end result should be the same. So I'd like to get as much
input as possible from anyone who has the
time to review it. There are lots of changes, so I'm bound to have made
mistakes in a few places.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC
INIT_WORK(>switch_work, mmc_omap_switch_handler);
init_timer(>switch_timer);
host->switch_timer.function = mmc_omap_switch_timer;
host->switch_timer.data = (unsigned long) host;
--
-- Pierre Ossman
Linux kernel, MM
herwise, 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://ww
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: send the
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 http:/
p 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 "unsubsc
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.org
PulseAudio
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:
lid 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])
>
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
link (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
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
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
> passwo
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://www.rdesktop.org
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
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 lin
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
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
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
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 myself
- 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
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
Linux kernel,
> 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 http://p
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: se
501 - 600 of 964 matches
Mail list logo
