Philip Langdale wrote:
> 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:
>
>
Looks good. I'll
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:
> In the process of developing this patch, we realised that the R6 response
> definition
> was incorrect and that it should have been identical to R1 (and so should R7).
> Correcting this mistake revealed problems in a couple of host controller
> drivers that
> relied on
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 think the trivial fix will do (after all, there's nothing that should matter
to the controller
in the R6 response; I don't know about R7). I don't have any SDHC cards so I
can't test this.
--- tifm_sd.c.orig 2006-12-11 01:39:28.0 +1100
+++ tifm_sd.c 2007-01-04
I think the trivial fix will do (after all, there's nothing that should matter
to the controller
in the R6 response; I don't know about R7). I don't have any SDHC cards so I
can't test this.
--- tifm_sd.c.orig 2006-12-11 01:39:28.0 +1100
+++ tifm_sd.c 2007-01-04
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:
In the process of developing this patch, we realised that the R6 response
definition
was incorrect and that it should have been identical to R1 (and so should R7).
Correcting this mistake revealed problems in a couple of host controller
drivers that
relied on the
Philip Langdale wrote:
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:
Looks good. I'll queue up
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've implemented a uniqueness fix by
> adding
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
Philip Langdale wrote:
> This is a bug. The MMC_RSP_R? #defines do not fully characterise the
> responses (specically, the way that the response is parsed is not
> characterised) and consequently there is no guarantee of uniqueness.
> Given this reality - the way that the tifm_sd driver works is
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
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 MMC_RSP_R6
Philip Langdale wrote:
> @@ -1386,10 +1420,37 @@
>* all get the idea that they should be ready for CMD2.
>* (My SanDisk card seems to need this.)
>*/
> - if (host->mode == MMC_MODE_SD)
> - mmc_send_app_op_cond(host, host->ocr, NULL);
> - else
> + if
Philip Langdale wrote:
> Heh. I forget that you don't want to manually alter the email. Will do.
>
>
I'm rather reluctant to change anything once someone has put a
signed-off-by line to it. Different people have different limits as to
what they regard a trivial modification.
> Done. I thought
Philip Langdale wrote:
Heh. I forget that you don't want to manually alter the email. Will do.
I'm rather reluctant to change anything once someone has put a
signed-off-by line to it. Different people have different limits as to
what they regard a trivial modification.
Done. I thought we
Philip Langdale wrote:
@@ -1386,10 +1420,37 @@
* all get the idea that they should be ready for CMD2.
* (My SanDisk card seems to need this.)
*/
- if (host-mode == MMC_MODE_SD)
- mmc_send_app_op_cond(host, host-ocr, NULL);
- else
+ if (host-mode
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 MMC_RSP_R6
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
Philip Langdale wrote:
This is a bug. The MMC_RSP_R? #defines do not fully characterise the
responses (specically, the way that the response is parsed is not
characterised) and consequently there is no guarantee of uniqueness.
Given this reality - the way that the tifm_sd driver works is
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
Pavel Machek wrote:
> Would you describe what SDHC is? I know SD flash cards, and IIRC SDIO
> cards exist, with functionality such as bluetooth...? But SDHC?
>
>
SDHC is short for "Secure Digital High Capacity". It's simply SD flash
cards than conform to a new version of the protocol, a
Hi!
> > 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 that
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
Hi!
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 that with the wrong
Pavel Machek wrote:
Would you describe what SDHC is? I know SD flash cards, and IIRC SDIO
cards exist, with functionality such as bluetooth...? But SDHC?
SDHC is short for Secure Digital High Capacity. It's simply SD flash
cards than conform to a new version of the protocol, a version
Philip Langdale wrote:
> Hi all,
>
>
>
*snip*
> Signed-off-by: Philipl Langdale <[EMAIL PROTECTED]>
>
When you have a commit message larger than the patch, you know there is
something wrong. ;)
Please skip the part about MMC at least.
> @@ -588,12 +591,15 @@
>
> if
Philip Langdale wrote:
Hi all,
*snip*
Signed-off-by: Philipl Langdale [EMAIL PROTECTED]
When you have a commit message larger than the patch, you know there is
something wrong. ;)
Please skip the part about MMC at least.
@@ -588,12 +591,15 @@
if (mmc_card_sd(card)) {
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 that
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 that with
37 matches
Mail list logo
