Hi Geert,
On Thu, Jun 20, 2024 at 4:40 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> Hi Prabhakar,
>
> Thanks for your patch!
>
> On Thu, Jun 13, 2024 at 11:17 AM Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> >
> > The SDHI/eMMC IPs found in the RZ/V2H(P) (a.k.a. r9a09g057) are very
> > similar to those found in R-Car Gen3. However, they are not identical,
> > necessitating an SoC-specific compatible string for fine-tuning driver
> > support.
> >
> > Key features of the RZ/V2H(P) SDHI/eMMC IPs include:
> > - Voltage level control via the IOVS bit.
> > - PWEN pin support via SD_STATUS register.
> > - Lack of HS400 support.
> > - Fixed address mode operation.
> >
> > regulator support is added to control the volatage levels of SD pins
> > via sd_iovs/sd_pwen bits in SD_STATUS register.
>
> Probably I am missing something obvious in the big picture, but why
> must this be modelled as a regulator? Can't the SDHI driver handle
> this register bit directly?
>
It can be handled directly. I had asked for suggestions on how to
implement this ("Subject: Modeling the register bit as a voltage
regulator for SDHI/eMMC '' also CC'd you), based on the feedback below
from Wolfram I took this approach.
> There is a similar instance of regulator driver [1] which is
> controlled via register bit write, but in our case the SD_STATUS
> register is part of the SDHI IP block itself.
... I could imagine that the SDHI driver itself exposes a regulator
driver. Just without a <reg>-property. The compatible will induce which
register and bit to use.
> Cfr. tmio_mmc_power_on(), which can use the tmio_mmc_host.set_pwr()
> callback[1] instead of/in addition to a regulator.
>
PWEN bit would have been controlled via set_pwr()
Cheers,
Prabhakar
