[Letux-kernel] is this thing upstreamable?

Andreas Kemnade andreas at kemnade.info
Mon Dec 19 21:27:18 CET 2016


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?

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20161219/21aa12ab/attachment.asc>


More information about the Letux-kernel mailing list