[RFC linus/master 0/4] rpi: support regulator and usbphy

[Alexander Aring]

Hi Stephen,

On Sat, Oct 24, 2015 at 09:40:52PM -0600, Stephen Warren wrote:
> On 10/24/2015 06:20 AM, Alexander Aring wrote:
> > Hi,
> > 
> > this patch series supports regulator and a "dummy?" usb phy for the raspberry
> > pi. My use-case is to have a mainline solution for power the usb without
> > booting via u-boot at first. This patch series should support this use-case.
> 
> You should make sure to run ./scripts/get_maintainer.pl on all these
> patches and send the emails to the correct lists and maintainers. None
> of the relevant maintainers or lists were CC'd on any of these emails,
> so if any of them notice that you sent these emails, it will be by chance.
> 

ok, sure.

> > I tested it with the bootloader "barebox" [0].
> > 
> > There was already some solution for doing this via PM domains directly inside
> > the firmware driver of raspberrypi. This patches are still not mainline and
> > there was some issues why not.
> >
> > I hope this patch series by doing it via a regulator driver (which can also
> > used for other driver to power them) and adding a usb phy (which is used by
> > the dwc2 driver to power the usb) is a more acceptable solution or I did it
> > even more complex than it is.
> 
> Nevertheless, I believe the HW feature you're trying to enable is power
> domains. Regulators are generally for off-chip power sources or control.
> I don't think using regulators instead of power domains is appropriate.

mh, yes. Power domains sounds better.

The current handling with regulators would be e.g. that messages like
this:

[    2.020288] sdhci-bcm2835 20300000.sdhci: No vmmc regulator found
[    2.026388] sdhci-bcm2835 20300000.sdhci: No vqmmc regulator found

we could simple use for vmmc the SDHC "firmware set power command" which
is triggered then by rpi the regulator driver then.

The benefit would "maybe" that drivers are connected somehow with the
"power domain". So if you remove the module then the regulator driver
will also turn off the power state. By doing this over regulator, we
need a less/maybe nothing additional "runtime decision" inside the
driver. This depends also to what the firmware is really do by the
command.

The previous implementation of using power domains, simple enables at
boot time the power of some "domains" (probing at firmware). The drivers
which will use the "domain" doesn't know about that.

This will also ends in some races between "power on domains" (was done
at firmware probing) and "probing the driver", except we are sure that
the "power domains" will be "set on" before we probe any other drivers.

The possible solution would be to add "runtime decision" where others
driver has the "regulator_enable" call, we do the calls for set the
"power domain" on. Then return "-EPROBE_DEFER" if the firmware is not
loaded before.

> I don't recall the issue that prevented the previous power domains
> patches from being accepted, but your best bet is to pick up those
> patches, fix the issue, and resend them. I'd suggest co-ordinating with
> their author in case he/she happens to be working on them.
> 

The previous domain power patches also has issues which wasn't noticed
before, especially the race between "dwc2 porbing" <-> "firmware probing"
and the dwc2 driver doesn't know anything about the power domain.

Nevertheless for me is currently "USB" important, everything else is
working fine at the moment.

I will here try to provide a list what I could do as next for a possible
mainline solution for this issue:

* First of all, I will split the dwc2 "-EPROBE_DEFER" off by this patch
  series and send them to the right lists. This is something which should
  be fixed, also in stable.

Possible next steps:

- Remove the regulator driver and leave the usbphy driver there. Yes,
  there exists no "real" usbphy, that's why I would rename more stuff
  and call it a "dummy" driver which reacts on "phy_power_on/off" from
  the "dwc2" driver. The dummy driver will generate "rpi firmware"
  messages directly to the firmware which turns the USB off/on.

  This all assumes on that the firmware will do the correct handling
  there. I don't know what the firmware exactly does and if the "dwc2"
  driver can deal with that. The firmware is so far I know closed source.

- Remove the regulator driver and add Power Domain driver (where should
  this driver placed then? Still inside the firmware?).

  Then I have two possible suboptions:
  
  - Add a "dummy" ubsphy driver which will use the "power domain" driver
    then.
  - Add runtime decision inside the "dwc2" driver which will use "power
    domain" calls, when it's "brcm,bcm2835-usb" compatible string. This
    requires that the "dwc2" maintainers will accept such solution.

- Still working on the regulator idea?

- Use the previous patches, but then be ensure somehow about the probing
  dependencies. I don't know how I can deal that without that the driver
  doesn't know the power domain. Okay I could maybe do that sowmehow in an
  earlier initcall, but this sounds wrong. The driver should also notice
  about to turn off the power domain when it's not used anymore (e.g.
  rmmod).

These are currently my ideas what I can do. What do you think is the
best direction we should go? (Or maybe somebody has more ideas than me,
please let me know).

> Note that the email subject should start with "[RFC PATCH]"; it's
> assumed that your patches should be based on Linus's kernel (or some
> maintainer branch thereof).

Ok. On which branch should I base my patches? I don't get it, there is
some linux-rpi git repository at kernel.org [0] but it seems nobody used
it anymore. I am confused, which is the maintainer branch for doing rpi
stuff?

I can understand when I doing regulator or phy stuff then I can send it
to the MAINTAINERS repository. Is there no rpi-repository which we can
simple apply all patches if they get an acked from the corresponding
maintainers?

Thanks.

- Alex

[0] https://git.kernel.org/cgit/linux/kernel/git/rpi/linux-rpi.git/