[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6ed36ef-9552-3bfb-c863-0819add51850@ti.com>
Date: Fri, 9 Jun 2017 17:51:30 +0530
From: Kishon Vijay Abraham I <kishon@...com>
To: Tony Lindgren <tony@...mide.com>,
Ulf Hansson <ulf.hansson@...aro.org>
CC: Rob Herring <robh+dt@...nel.org>, Sekhar Nori <nsekhar@...com>,
Russell King <linux@...linux.org.uk>,
linux-omap <linux-omap@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH v2 0/8] omap*: Fixes/Cleanups for MMC devicetree node
Hi Tony,
On Thursday 08 June 2017 02:16 PM, Tony Lindgren wrote:
> * Ulf Hansson <ulf.hansson@...aro.org> [170608 00:24]:
>> If it helps, I can host a branch with the updates on the omap_hsmmc
>> driver, such it can be pulled in from arm soc?
>
> Great that works for me. Let's just make sure git bisect
> keeps working.
>
>> I guess you need that as, the DT changes relies on the new vqmmc
>> binding. Or you thing it doesn't matter, because for the current
>> changes that regulator is always an always on regulator?
>
> Or maybe we can just add the new regulator, then do a
> follow-up series to remove the old ones?
Since the driver has a fallback mechanism wherein if it's not able to find
vqmmc, it'll fallback to vmmc_aux, I don't think that's required.
Thanks
Kishon
Powered by blists - more mailing lists