[Letux-kernel] is this thing upstreamable?

[H. Nikolaus Schaller]

> Am 19.12.2016 um 21:27 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi,
> 
> On Mon, 19 Dec 2016 20:02:23 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi,
>> 
>>> Am 19.12.2016 um 16:48 schrieb Andreas Kemnade
>>> <andreas at kemnade.info>:
>>> 
>>> Hi,
>>> 
>>> I am a bit looking through old stuff, here I see:
>> 
>> good idea :)
>> 
>>> 
>>> mmc: hack pwrseq to fix gta04 bt problems
>>> 2b1976f0b095839d6e259e5f6d8febb49197198e
>>> 
>>> should that stay a hack or is it worth to be upstreamed?
>> 
>> Basically yes! We should always strive for the lowest private patch
>> count as possible because some distributions use mainline kernels.
>> 
>> Generally, I am not sure if it should be possible to control this
>> feature by some DT property.
>> 
>> Now I am a little puzzled if contradicts the bindings or not:
>> 
>> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>> 
>> "The reset GPIOs are asserted at initialization and prior we start
>> the power up procedure of the card. They will be de-asserted right
>> after the power has been provided to the card."
>> 
>> So the sequence seems to be
>> 
>> assert --- power on --- deassert ---- power off ---- assert (?)
>> 
>> "The reset pin is set to 1 (= inactive, so the 0 in the code) if mmc
>> is powered off."
>> 
>> It means the chip is simply kept in reset while powered off.
>> 
>> This might be what some eMMC chips want to see (but I am not sure).
>> 
> Hmm, I think this all depends on wiring.
> If the pin is active high on processor side and mmc power is removed on
> power off state, the reset pin will power the mmc chip through some
> esd protection circuits. That might give unpredictable results...
> So the original way of doing things does not look wrong in
> normal cases.
> 
> 
>> So we have with our hack
>> 
>> assert --- power on --- deassert ---- power off ---- deassert --
>> power on --
>> 
>> So we might break code (and have not noticed). And not fix the issue
>> after power on! We might just be lucky that the libertas driver runs
>> one power on/off sequence for firmware download and leaves BT enabled
>> with your patch.
>> 
>> This means we want be able to control the sequence to be
>> 
>> deassert --- assert + power on --- deassert ---- power off ----
>> deassert
>> 
>> because we just want a short reset impulse around power on.
>> 
> Probably this means introducing another powerseq thing.
> mmc_powerseq_short?

Well, I would simply add a new property to control the pulse
if it is short or long. Similar to the

- post-power-on-delay-ms: Delay in ms after powering the card and de-asserting the reset-gpios

for example:

- deassert-during-poweroff: Keep reset-gpios deasserted during power-off (they are asserted only shortly before power-on and deasserted after post-power-on-delay-ms)

or

- one-shot-at-power-on:

Would still be "simple" for me and not require another driver...

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20161219/5ab7ef5a/attachment.asc>