Frank Seidel wrote:
> From: Frank Seidel <[EMAIL PROTECTED]>
>
> This patch (based on current linus git tree) adds support for
> the Ricoh RL5c476 chip: with this the mmc adapter that needs this
> disabler (R5C843) can also be handled correctly when it sits
> on a RL5c476.
Again, thanks a lot for
On Mon, 4 Feb 2008 19:25:38 +0100, Frank Seidel <[EMAIL PROTECTED]> wrote:
> From: Philip Langdale <[EMAIL PROTECTED]>
>
> As pci config space is reinitialised on suspend/resume cycle, the
> disabler needs to work its magic at resume time. For symmetry this
> change
On Mon, 4 Feb 2008 19:25:42 +0100, Frank Seidel <[EMAIL PROTECTED]> wrote:
> From: Frank Seidel <[EMAIL PROTECTED]>
>
> This patch (base on current linus git tree plus Philip Langdales
> suspend/resume patch) adds support for the Ricoh RL5c476 chip:
> with this the mmc adapter that needs this dis
Hi,
I've just upgraded to an Athlon+KT133 from a P3+pro133 setup.
For the old motherboard which had a 596b southbridge I got
perfect udma66 support form my hard drives. After I switched
over, and without changing anything except switching from
p3 to athlon optimisations, the driver reports my dr
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Vojtech,
I've tried out your new via driver and it
appears to have solved the problem with
the mis-detected ls-120 drive, but the ata66
drives are still being run at 33.
More interestingly, the pci-clk calculat
As pci config space is reinitialised on a suspend/resume cycle, the
disabler needs to work its magic at resume time. For symmetry this
change also explicitly enables the controller at suspend time but
it's not strictly necessary.
Signed-off-by: Philipl Langdale <[EMAIL PROTECTED]>
--- linux-2.6.
Sandeep K wrote:
Hi all,
Can anybody please let me know, does the current linux
tree supports MMC plus and eMMC cards.
It certainly supports MMCplus. My understanding is that eMMC
is just a form-factor and is not visibly different to the host
controller, so it should just work. I know that the
Hi Mark,
I've just upgraded to an X2 5000+ black edition. This model
doesn't have a multiple lock and I tried bumping the multiplier
up, which is perfectly stable, but which causes powernow-k8 to
fail to load. I also tried with the updated patch you posted
at the beginning of october (http://lkml.
Langsdorf, Mark wrote:
>
> The standard PowerNow! driver, by design, will stop
> working in this situation. I'm not going to support
> a driver that allows non-standard multipliers because
> it could cause a lot of hard to debug maintenance
> issues.
Just a follow-up to get this into the public
n use revoco to configure my MX Revolution mouse.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
--- linux-2.6.23/drivers/hid/usbhid/hiddev.c2007-10-09 13:31:38.0
-0700
+++ linux-phil/drivers/hid/usbhid/hiddev.c 2007-10-12 15:02:15.0
-0700
@@ -34,6 +34,7 @@
Al Viro wrote:
>>
>> +static long hiddev_compat_ioctl(struct file *file, unsigned int cmd,
>> unsigned long arg)
>> +{
>> +struct inode *inode = file->f_path.dentry->d_inode;
>> +return hiddev_ioctl(inode, file, cmd, compat_ptr(arg));
>> +}
>
> Just how many instances of that sucker do we
Currently, evdev has working 32bit compatibility and uinput does not. uinput
needs the input_event code that evdev uses, so let's refactor it so it can
be shared.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
---
drivers/input/Makefile |2
drivers/input/evdev.c
Pierre Ossman wrote:
>
> Eeeeww... This is a problem as the SD spec. clearly states the order of
> init commands. So I wouldn't be surprised if we find SD cards that choke
> on the MMC init sequence.
>
> I guess what we lose by not supporting these is 8 bit data bus, but as
> we do not currently
Hi all,
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block l
Philip Langdale wrote:
> Hi all,
>
> Thanks to the generous donation of an SDHC card by John Gilmore, and the
> surprisingly enlightened decision by the SD Card Association to publish
> useful specs, I've been able to bash out support for SDHC. The changes
> are not too pr
I will post the updated diff as a separate follow up.
Pierre Ossman wrote:
>
> When you have a commit message larger than the patch, you know there is
> something wrong. ;)
>
> Please skip the part about MMC at least.
Heh. I forget that you don't want to manually alter the email. Will do.
>
>
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level addr
Andrew Morton wrote:
> On Mon, 01 Jan 2007 07:29:55 -0800
> Philip Langdale <[EMAIL PROTECTED]> wrote:
>
>> #define MMC_RSP_R1B
>> (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY)
>> #define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
>>
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level addr
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've implemented a uniqueness fix by
adding additional RSP flags do make R6 and R7 uniq
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level addr
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level addr
are unique. Pierre and Alex both
believe that treating R6 and R7 as R1 will be sufficient. ie: The controllers do
not care about the differences between them. Due to lack of hardware, I have
done
no testing.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
Cc: Alex Dubov <[EMAIL PROTE
Pierre Ossman wrote:
> Hi everyone,
>
> As I've mentioned to some of you, I've been working on restructuring the MMC
> layer in order to make it more easily maintained and to allow extensions
> like SDIO support. A first draft of this is now ready for public review.
> I've cc:d those who have been
Pierre Ossman wrote:
>
> We could do some silly polling hack. It isn't clean, but it might get things
> somewhat working at least.
Tobias,
Pierre has asked me to take a look implementing this. My first question is
whether
all card events are getting dropped on the floor, or just insertion ones.
accordingly updated.
The polling frequency is 3 seconds because I've been running
powertop and am paranoid about wakeups now. :-) I did some
testing locally by masking out the interrupt events and 3
seconds seems usable enough to me.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
d
should never be
the same so it will cause no change in behaviour.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ff5bf73..2d5ec61 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -34,6 +34,7 @@
specs and
fixes the SDHCI driver. It also removes the explicit
defines for the host vdd and updates the SDHCI driver
to convert the bit number back to the mask value
for comparisons. Having only a single set of defines
ensures there's nothing to get out of sync.
Signed-off-by: Philip Lan
Pierre Ossman wrote:
>
> We must not have the same specs. My simplified SD 2.0 physical spec
> defines everything below bit 15 as reserved.
I was a little unclear. Both specs define bit 7 as the low-voltage
range but only the MMC spec defines the actual voltage. As such, there
is no complete defi
ibe 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]>
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 86d0957..2f34ae3 100644
--- a
.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index c87ce56..74ebd97 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -317,6 +317,24 @@ static u32 mmc_select_voltage(struct mmc
{
i
upport implemented by
> Philip Langdale .
> To support 8-bit transfers the core needs to implement "bus testing
> procedure". This requires support for CMD19 and CMD14.
>
> Why is the support for bus testing procedure msiing from the MMCv4 support?
Because we have not
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 widt
.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 21c0517..310b242 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -319,6 +319,17 @@ int mmc_attach_mmc(struct mmc_host *host
mmc_attach_bus(host, &a
drivers/mmc/host/ricoh_mmc.c 1969-12-31 16:00:00.0
-0800
+++ linux-ricoh/drivers/mmc/host/ricoh_mmc.c2007-09-15 12:29:05.0
-0700
@@ -0,0 +1,152 @@
+/*
+ * ricoh_mmc.c - Dummy driver to disable the Rioch MMC controller.
+ *
+ * Copyright (C) 2007 Philip Langdale, All Rights Reserved.
Pierre Ossman wrote:
>
> Preferably. But if you can't figure it out until it is time to merge
> things upstream, then I'll go with what we have right now.
I have not been contacted by anyone with one of those laptops so I
haven't been able to find out what's going on.
I'm updating the diff, beca
drivers/mmc/host/ricoh_mmc.c 1969-12-31 16:00:00.0
-0800
+++ linux-ricoh/drivers/mmc/host/ricoh_mmc.c2007-09-15 12:29:05.0
-0700
@@ -0,0 +1,156 @@
+/*
+ * ricoh_mmc.c - Dummy driver to disable the Rioch MMC controller.
+ *
+ * Copyright (C) 2007 Philip Langdale, All Rights Reserved.
Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-02 at 14:44 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2007-10-01 at 20:23 -0700, Philip Langdale wrote:
>>> Thanks to Matt Domsch and Rezwanul Kabir at Dell, we know how to disable the
>>> MMC controller on the multi
Pierre Ossman wrote:
>>
>
> Patch looks ok. Please try to sort out that completely disabled
> controller that was reported first though.
This remains confusing. I went and investigated and the SD disable
bit is 0x20. The one lspci dump from the IFL90 shows that 0x80 is
set by default, but setting
39 matches
Mail list logo
