On Fri, Oct 25, 2019 at 11:38 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Hi,
On 25-10-2019 09:53, Andy Shevchenko wrote:
On Thu, Oct 24, 2019 at 02:29:37PM +0000, Andrey Zhizhikin wrote:
This patchset introduces additional regulator driver for Intel Cherry
Trail Whiskey Cove PMIC. It also adds a cell in mfd driver for this
PMIC, which is used to instantiate this regulator.
Regulator support for this PMIC was present in kernel release from Intel
targeted Aero platform, but was not entirely ported upstream and has
been omitted in mainline kernel releases. Consecutively, absence of
regulator caused the SD Card interface not to be provided with Vqcc
voltage source needed to operate with UHS-I cards.
Following patches are addessing this issue and making sd card interface
to be fully operable with UHS-I cards. Regulator driver lists an ACPI id
of the SD Card interface in consumers and exposes optional "vqmmc"
voltage source, which mmc driver uses to switch signalling voltages
between 1.8V and 3.3V.
This set contains of 2 patches: one is implementing the regulator driver
(based on a non upstreamed version from Intel Aero), and another patch
registers this driver as mfd cell in exising Whiskey Cove PMIC driver.
Thank you.
Hans, Cc'ed, has quite interested in these kind of patches.
Am I right, Hans?
Yes since I do a lot of work on Bay and Cherry Trail hw enablement I'm
always interested in CHT specific patches.
Overall this series looks good (from a high level view I did not
do a detailed review) but I wonder if we really want to export all the
regulators when we just need the vsdio one?
I thought about this point, and actually came to a personal conclusion
that if I do this as a new driver - then it is better to list all
possible regulators, creating some sort of "skeleton" which people
could then work on if need be. I do agree that at the present moment
the one regulator which is exposed is the one for vsdio, but listing
all possibilities should not hurt. This was my motivation to put them
all into the driver on the first place.
If you believe additional regulator elements should be removed from
this version of the driver - I can clean them up and come up with v2
here.
Most regulators are controlled by either the P-Unit inside the CHT SoC
or through ACPI OpRegion accesses. Luckily the regulator subsys does not
expose a sysfs interface for users to directly poke regulators, but this will
still make it somewhat easier for users to poke regulators which they should
leave alone.
Agree, this is a valid point. But honestly I would really be surprised
if a user would directly touch something which can burn his silicon to
pieces. Regulators are usually not approached by users; unless they
are really HW engineers and know what they are doing.
Andrey, may I ask which device you are testing this on?
Sure, I use the original Intel Aero board. It used to have an official
image from Aero team with a heavily patched 4.4.y kernel, but when I
decided to have this updated to the latest stable branch - I've faced
the issue of missing core functionality, which led me to this patch.