On 12/13/2017 01:26 AM, Hans de Goede wrote:
Hi,
On 13-12-17 10:24, Hans de Goede wrote:
Hi All,
I would like to enable CONFIG_REGULATOR on x86_64, to fix
USB PD negotiating (and charging with more the 0.5 A in
general) and battery monitoring on Intel Cherry Trail
devices which use an Intel PMIC + FUSB302 Type-C controller
to enable USB-PD charging.
Since the USB-PD negotiation in this case is handled by
the kernel rather then by firmware in the Alpine Ridge
controller, the kernel also needs to enable/disable
the 5V boost converter feeding 5v to the Type-C port
when it is in host / power-source mode and this is
modeled as a regulator.
One of the drivers for the complex of 4 ICs which
implement the Type-C and battery charging monitoring
on these devices has a Kconfig dep on CONFIG_REGULATOR
because of this and without this driver these devices
are limited to charging (or rather slowly discharging)
at 5V 0.5A rather then charging at up to 12V 3A, also
without this battery monitoring will not work and the
kernel will be unable to make the port provide 5V
when a Type-C to USB-A-receptacle cable gets plugged in.
Downside of this is a slightly bigger kernel (the
regulator framework is tiny) and some messages like
these when some drivers load:
[ 19.955279] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply avdd not found,
using dummy regulator
[ 19.955331] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply cpvdd not found,
using dummy regulator
As these drivers now actually call into the regulator
framework which prints these messages, rather then calling
empty stubs.
These are printed at "warning" level so will not show
up on the console.
So if there are no objections I will push a commit
enabling CONFIG_REGULATOR on x86_64 one of the coming
days.
p.s.
I'm proposing this change for the 4.15 kernel only, as that finally
has all the necessary drivers to do USB PD on these devices
and enabling CONFIG_REGULATOR on x86_64 is all that is missing
to get this to work.
Regards,
Hans
This sounds okay for rawhide. The regulator framework has been
well tested and I wouldn't expect too many problems.
Thanks,
Laura
_______________________________________________
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
