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
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
> cha
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 also explicitly enables the controller
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 disabler
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
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
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
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]>
---
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]
---
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
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
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
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
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
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
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
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 need? It's
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| 118
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 @@
#include
#i
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 @@
#include linux/usb.h
#include
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
rs/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.
+ *
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,
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,
+++ 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.
+ *
+ * This program is free software; you can
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-function Ricoh R5C832. The MMC
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
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
rs/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.
+ *
+++ 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.
+ *
+ * This program is free software; you can
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 @@
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 @@ static
is 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]>
diff
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
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.
is 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]
diff --git
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
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
4 support 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:
Hi Pierre/philip,
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 transfers. The 8-bit
support seems to be missing from the MMCv4 support implemented by
Philip
.
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
.
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, mmc_ops
.
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
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
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
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
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/drivers/mmc/host
.
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
{
int bit
to the 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 Langdale
to the 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 Langdale [EMAIL
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
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 have a
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
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
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
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
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
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
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 PROTECTED]
Cc
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
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
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)
>>
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)
#define MMC_RSP_R3 (MMC_RSP_PRESENT)
-#define
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
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
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.
>
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
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
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
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
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 profound:
So I sent
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
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
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
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
76 matches
Mail list logo
