[Letux-kernel] is this thing upstreamable?

H. Nikolaus Schaller hns at goldelico.com
Mon Dec 19 20:02:23 CET 2016


> 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:


"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).

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.


-------------- 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/78960957/attachment.asc>

More information about the Letux-kernel mailing list