On Thu, Dec 03, 2020 at 09:10:14AM +0200, Zulkifli, Muhammad Husaini wrote: > >From: Linus Walleij <linus.walleij@xxxxxxxxxx> > >Sent: Thursday, December 3, 2020 2:55 AM > >On Wed, Dec 2, 2020 at 8:04 AM <muhammad.husaini.zulkifli@xxxxxxxxx> > >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
