[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <166c9855-910d-a70c-ba86-6aebe5f2346d@intel.com>
Date: Mon, 28 Oct 2019 14:41:46 +0200
From: Adrian Hunter <adrian.hunter@...el.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Andrey Zhizhikin <andrey.z@...il.com>,
Hans de Goede <hdegoede@...hat.com>
Cc: lgirdwood@...il.com, broonie@...nel.org, lee.jones@...aro.org,
linux-kernel@...r.kernel.org,
Andrey Zhizhikin <andrey.zhizhikin@...ca-geosystems.com>
Subject: Re: [PATCH 0/2] add regulator driver and mfd cell for Intel Cherry
Trail Whiskey Cove PMIC
On 25/10/19 10:55 AM, Andy Shevchenko wrote:
> On Fri, Oct 25, 2019 at 10:53:35AM +0300, 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?
>
> 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:
If ((Arg2 == 0x03))
{
ADBG ("DSM 1p8")
If ((^^I2C7.AVBL == One))
{
If ((PMID == One))
{
DATA = 0x59
^^I2C7.DL03 = BUFF /* \_SB_.PCI0.SHC1.BUFF */
}
ElseIf ((PMID == 0x02))
{
BUFF = ^^I2C7.XD31 /* \_SB_.PCI0.I2C7.XD31 */
If ((STAT == Zero))
{
DATA |= 0x10
^^I2C7.XD31 = BUFF /* \_SB_.PCI0.SHC1.BUFF */
}
BUFF = ^^I2C7.XD32 /* \_SB_.PCI0.I2C7.XD32 */
If ((STAT == Zero))
{
DATA |= 0x0B
DATA &= 0xEB
^^I2C7.XD32 = BUFF /* \_SB_.PCI0.SHC1.BUFF */
}
Sleep (0x0A)
BUFF = ^^I2C7.XD31 /* \_SB_.PCI0.I2C7.XD31 */
If ((STAT == Zero))
{
DATA |= 0x20
^^I2C7.XD31 = BUFF /* \_SB_.PCI0.SHC1.BUFF */
}
}
ElseIf ((PMID == 0x03))
{
Local0 = ^^I2C7.PMI5.GET (One, 0x6E, 0x67)
Sleep (0x0A)
Local0 &= 0xF8
^^I2C7.PMI5.SET (One, 0x6E, 0x67, Local0)
Sleep (0x64)
Local0 = ^^I2C7.PMI5.GET (One, 0x6E, 0x67)
Sleep (0x0A)
Local0 |= One
Local0 &= 0xF9
^^I2C7.PMI5.SET (One, 0x6E, 0x67, Local0)
Sleep (0x0A)
^^I2C7.PMI5.SET (One, 0x6E, 0xC6, 0x1F)
Sleep (0x0A)
}
}
SDVL = One
Return (0x03)
}
Powered by blists - more mailing lists