From: Hans de Goede <hdegoede@redhat.com>
To: Mark Brown <broonie@kernel.org>, Adrian Hunter <adrian.hunter@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Andrey Zhizhikin <andrey.z@gmail.com>,
lgirdwood@gmail.com, lee.jones@linaro.org,
linux-kernel@vger.kernel.org,
Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
Subject: Re: [PATCH 0/2] add regulator driver and mfd cell for Intel Cherry Trail Whiskey Cove PMIC
Date: Mon, 28 Oct 2019 14:26:21 +0100 [thread overview]
Message-ID: <c5faf16d-892e-b36e-b448-9c59c2051b9e@redhat.com> (raw)
In-Reply-To: <20191028124554.GF5015@sirena.co.uk>
Hi,
On 28-10-2019 13:45, Mark Brown wrote:
> On Mon, Oct 28, 2019 at 02:41:46PM +0200, Adrian Hunter wrote:
>> On 25/10/19 10:55 AM, Andy Shevchenko wrote:
>
>>> Since it's about UHS/SD, Cc to Adrian as well.
>
>> My only concern is that the driver might conflict with ACPI methods trying
>> to do the same thing, e.g. there is one ACPI SDHC instance from GPDWin DSDT
>> with code like this:
Oh, right that is a very good point.
> That's certainly what's idiomatic for ACPI (though machine specific
> quirks are too!). The safe thing to do would be to only register the
> supply on systems where we know there's no ACPI method.
Right, so as I mentioned before Andrey told me about the evaluation
board he is using I was aware of only 3 Cherry Trail devices using
the Whiskey Cove PMIC. The GPD win, the GPD pocket and the Lenovo
Yoga book. I've checked the DSDT of all 3 and all 3 of them offer
voltage control through the Intel _DSM method for voltage control.
I've also actually tested this on the GPD win and 1.8V signalling
works fine there without needing Andrey's patch.
So it seems that Andrey's patch should only be active on his
dev-board, as actual production hardware ships with the _DSM method.
I believe that the best solution is for the Whiskey Cove MFD driver:
drivers/mfd/intel_soc_pmic_chtwc.c
To only register the new cell on Andrey's evaluation board model
(based in a DMI match I guess). Another option would be to do
the DMI check in the regulator driver, but that would mean
udev will needlessly modprobe the regulator driver on production
hardware, so doing it in the MFD driver and not registering the cell
seems best,
Regards,
Hans
next prev parent reply other threads:[~2019-10-28 13:26 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 14:29 [PATCH 0/2] add regulator driver and mfd cell for Intel Cherry Trail Whiskey Cove PMIC Andrey Zhizhikin
2019-10-24 14:29 ` [PATCH 1/2] regulator: add support for Intel Cherry Whiskey Cove regulator Andrey Zhizhikin
2019-10-25 8:01 ` Andy Shevchenko
2019-10-25 8:58 ` Andrey Zhizhikin
2019-10-25 9:14 ` Andy Shevchenko
2019-10-25 9:31 ` Andrey Zhizhikin
2019-10-25 10:47 ` Andy Shevchenko
2019-10-25 12:17 ` Mark Brown
2019-10-25 15:26 ` Andrey Zhizhikin
2019-10-25 16:02 ` Andy Shevchenko
2019-10-25 16:21 ` Andrey Zhizhikin
2019-10-24 14:29 ` [PATCH 2/2] mfd: add regulator cell to Cherry Trail Whiskey Cove PMIC Andrey Zhizhikin
2019-10-25 8:06 ` Andy Shevchenko
2019-10-25 9:16 ` Andrey Zhizhikin
2019-10-25 10:49 ` Andy Shevchenko
2019-10-25 12:00 ` Andrey Zhizhikin
2019-10-25 7:53 ` [PATCH 0/2] add regulator driver and mfd cell for Intel " Andy Shevchenko
2019-10-25 7:55 ` Andy Shevchenko
2019-10-25 8:51 ` Andrey Zhizhikin
2019-10-28 12:41 ` Adrian Hunter
2019-10-28 12:45 ` Mark Brown
2019-10-28 13:26 ` Hans de Goede [this message]
2019-10-28 15:01 ` Andrey Zhizhikin
2019-10-29 12:03 ` Hans de Goede
2019-10-29 16:57 ` Andrey Zhizhikin
2019-10-29 17:14 ` Hans de Goede
2019-10-28 16:28 ` Andy Shevchenko
2019-10-28 14:40 ` Andrey Zhizhikin
2019-10-25 9:38 ` Hans de Goede
2019-10-25 10:11 ` Andrey Zhizhikin
2019-10-25 10:45 ` Hans de Goede
2019-10-25 11:54 ` Andrey Zhizhikin
2019-10-25 12:05 ` Mark Brown
2019-10-25 12:18 ` Hans de Goede
2019-10-25 10:44 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c5faf16d-892e-b36e-b448-9c59c2051b9e@redhat.com \
--to=hdegoede@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=andrey.z@gmail.com \
--cc=andrey.zhizhikin@leica-geosystems.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).