Re: [PATCH v2] mmc: sdhci: add quirk for broken write protect detection

[Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]

Hi,

On 03/06/2014 05:42 PM, Sören Brinkmann wrote:
> On Thu, 2014-03-06 at 02:31PM +0100, Mike Looijmans wrote:
>> On 03/04/2014 10:00 PM, Sören Brinkmann wrote:
>>> On Tue, 2014-03-04 at 10:06PM +0200, Eli Billauer wrote:
>>>> Hello Sören,
>>>>
>>>> wp-inverted solves the practical problem indeed, and fools the
>>>> driver into thinking that the card has an inverted write protection
>>>> sensor, and the logic zero that it finds in the hardware register
>>>> means that the card isn't write protected.
>>>>
>>>> I'm insisting on this patch, because I think that the device tree
>>>> should describe the hardware as it is, and not fool the driver into
>>>> behaving the way we want it to. These tricks always bite back later
>>>> on.
>>> Well, why is broken-wp more accurate than wp-inverted? Strictly
>>> speaking the WP is there and working, it's just tied off to some value
>>> you want to have interpreted the other way.
>>> Anyway, seems like this is solvable with wp-inverted and whether the
>>> additional quirk is needed I leave to others do decide.
>>
>> I've begged for this patch - or a similar one - to be included too,
>> because on our boards, the "wp" value appears to be sort of random.
>> Out of 5 prototype boards, 3 would only boot with wp-inverted while
>> the other 2 wouldn't boot with wp-inverted set.
>>
>> In our case I really don't know (and I don't care either) to which
>> logic level the wp happens to think it's wired. I just want to be
>> able to tell the driver that the WP line is
>> free-floating-and-might-have-any-random-value-at-any-given-moment
>> which is a bit long, so I'd go for disable-wp instead.
> 
> Could you provide the design you use and give more details? According to
> the people I talked to, the signal should never float, unless you pin it
> out and don't drive it.
> Actually, you should open a support case for this. It is not supposed to
> happen.

we have got this from Mike (we couldn't reply because he has lost this email
thread.

Mike:
"I think I found the issue. In ps7_init.c as generated by the tools, it sets the "WP" pin not to EMIO, but to MIO 0. We use pin 0 for a status LED.

# devmem 0XF8000830
0x002E0000

Register 0XF8000830 is SD0_WP_CD_SEL, and 0x002E0000 sets CD to pin 46 and WP to pin "0", not to EMIO as I specified in the design.
"

Eli: Maybe you have the same issue as Mike. Can you please check it?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]