Re: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Igor Grinberg <grinberg@xxxxxxxxxxxxxx> [141104 09:54]:
> On 11/04/14 17:42, Tony Lindgren wrote:
> > * Igor Grinberg <grinberg@xxxxxxxxxxxxxx> [141104 05:22]:
> >> Hi Tony,
> >>
> >> On 11/02/14 20:07, Tony Lindgren wrote:
> >>> Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
> >>> configuration") enabled configuring the PM features for twl4030.
> >>>
> >>> This caused poweroff command to fail on devices that have the
> >>> BCI charger on twl4030 wired, or have power wired for VBUS.
> >>> Instead of powering off, the device reboots. This is because
> >>> voltage is detected on charger or VBUS with the default bits
> >>> enabled for the power transition registers.
> >>>
> >>> To fix the issue, let's just clear VBUS and CHG bits as we want
> >>> poweroff command to keep the system powered off.
> >>
> >> What about devices that really need to start once VBUS or CHG is connected?
> > 
> > More handling can be added for some cases. With this patch the
> > poweron bits will clear to defaults if power is completely removed.
> > So start-up with VBUS and CHG works in that case.
> > 
> > However, if you have a battery connected, and you poweroff, with
> > this patch the device won't power up with VBUS or CHG connected.
> > 
> > Note that most battery operated devices are not using the charger
> > on twl4030 because it has issues charging a completely empty
> > battery AFAIK. So most battery powered devices have been using an
> > external USB charger chip that's not affected by this patch.
> > 
> > We could consider exporting a function for the charger driver to
> > configure the poweron mask. And we could also consider passing a
> > mask in ti,use_poweroff = 0xff.
> 
> Ok. That sounds better to me.
> Yet, if you say there are no such devices in practice,
> IMHO, we can merge this.
> 
> >> It seems to me that forcing these bits on power off can break that kind of
> >> devices and these settings should really be board specific.
> >> What do you think?
> > 
> > There's a patch series for "[RFC,01/16] kernel: Add support for
> > poweroff handler call chain" that should help with that. For sure
> > the poweroff handling needs to be board specific as some systems
> > may need to use a GPIO to shut off a regulator powering something
> > before powering off the SoC.
> 
> Yes, I've seen this series.
> I'm not sure though that I understand how is this supposed
> to be used with DT...
> Through the regulator bindings?
> Which will tell it to hook up on the call chain?

Yes that should be doable with regulator bindings for board specifc
configuration. For the SoC specific functions those can be registered
by the platform code.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux