Re: [PATCH v6 4/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC

["Shevchenko, Andriy" <andriy.shevchenko@intel.com>]

On Thu, Dec 03, 2020 at 09:10:14AM +0200, Zulkifli, Muhammad Husaini wrote:
> >From: Linus Walleij <linus.walleij@linaro.org>
> >Sent: Thursday, December 3, 2020 2:55 AM
> >On Wed, Dec 2, 2020 at 8:04 AM <muhammad.husaini.zulkifli@intel.com>
> >wrote:

...

> >If it should use any abstraction it should be a selector regulator IMO and
> >while that may seem overengineered it adds something because regulators
> >are used in  the MMC subsystem for vdd and vqmmc because we are handling
> >the OCR mask with that and it can support any amount of present and future
> >voltages for signal levels with that as well. Any future changes to how the
> >different signal voltages are set or which voltages exist can then be done in
> >that regulator driver.
> 
> This is limitation of Keem Bay HW and I would say Keem Bay HW is somewhat
> unique in the way of handling the IO bus line voltage.
> SDcard does not have its own voltage regulator.
> I created one function sdhci_arasan_keembay_io_line_supply_operation() in sdhci-of-arasan.c
> to handle the vqmmc(io line supply operation) specific for Keem Bay SoC.
> 
> For Keem Bay, to actually modelling this as regulator ,for vqmmc, , we need to handle 2 things:
> 1) Output expander pins : using gpio regulator
> 2) voltage rail : call keembay_io_rail_supplied_voltage() to handle the SMCC Arm.
> 
> Other hardware might not need this as they might easily configure the vqmmc
> hooked up to regulator.
> 
> IMHO, we do not need to overengineered it to add custom selector
> regulator just to suit this Keem Bay HW design.

I guess Linus has a point. If it can be abstracted as selector regulator it
will suits generic approach in the MMC code.

And what is the problem to have two or more regulators? Or regulator hierarchy?


-- 
With Best Regards,
Andy Shevchenko