All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Tom Rini <trini@konsulko.com>,
	 Neil Armstrong <narmstrong@baylibre.com>,
	Frank Wang <frank.wang@rock-chips.com>,
	 Grant Likely <grant.likely@secretlab.ca>,
	Patrick Delaunay <patrick.delaunay@foss.st.com>,
	 Icenowy Zheng <icenowy@aosc.io>,
	Jagan Teki <jagan@amarulasolutions.com>,
	 Andre Przywara <andre.przywara@arm.com>,
	Grant Likely <grant.likely@arm.com>,
	 Peter Robinson <pbrobinson@gmail.com>,
	Joe Hershberger <joe.hershberger@ni.com>
Subject: Re: [PATCH v2] phy: Track power-on and init counts in uclass
Date: Tue, 28 Dec 2021 01:34:18 -0700	[thread overview]
Message-ID: <CAPnjgZ07oEFQVOV7_5MMx9SgJTiA1Swck9bSpLjKevqM5U5b2g@mail.gmail.com> (raw)
In-Reply-To: <20211224130549.20276-1-alpernebiyasak@gmail.com>

Hi Alper,

On Fri, 24 Dec 2021 at 06:06, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> On boards using the RK3399 SoC, the USB OHCI and EHCI controllers share
> the same PHY device instance. While these controllers are being stopped
> they both attempt to power-off and deinitialize it, but trying to
> power-off the deinitialized PHY device results in a hang. This usually
> happens just before booting an OS, and can be explicitly triggered by
> running "usb start; usb stop" in the U-Boot shell.
>
> Implement a uclass-wide counting mechanism for PHY initialization and
> power state change requests, so that we don't power-off/deinitialize a
> PHY instance until all of its users want it done. The Allwinner A10 USB
> PHY driver does this counting in-driver, remove those parts in favour of
> this in-uclass implementation.
>
> The sandbox PHY operations test needs some changes since the uclass will
> no longer call into the drivers for actions matching its tracked state
> (e.g. powering-off a powered-off PHY). Update that test, and add a new
> one which simulates multiple users of a single PHY.
>
> The major complication here is that PHY handles aren't deduplicated per
> instance, so the obvious idea of putting the counts in the PHY handles
> don't immediately work. It seems possible to bind a child udevice per
> PHY instance to the PHY provider and deduplicate the handles in each
> child's uclass-private areas, like in the CLK framework. An alternative
> approach could be to use those bound child udevices themselves as the
> PHY handles. Instead, to avoid the architectural changes those would
> require, this patch solves things by dynamically allocating a list of
> structs (one per instance) in the provider's uclass-private area.
>
> Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
> ---
>
> Changes in v2:
> - Rename {phy_,}id_priv -> {phy_,}counts
> - Split phy_get_uclass_priv -> phy_{alloc,get}_counts
> - Allocate counts (or return error) in generic_phy_get_by_*()
> - Remove now-unnecessary null checks for counts of valid phy handles
>
> v1: https://patchwork.ozlabs.org/project/uboot/patch/20211210200124.19226-1-alpernebiyasak@gmail.com/
>
>  drivers/phy/allwinner/phy-sun4i-usb.c |   9 --
>  drivers/phy/phy-uclass.c              | 120 ++++++++++++++++++++++++++
>  test/dm/phy.c                         |  83 ++++++++++++++++--
>  3 files changed, 198 insertions(+), 14 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Should add comments for the struct

Also I wonder if a simple fixed-length array might be possible instead
of the linked list?

  reply	other threads:[~2021-12-28  8:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-24 13:05 [PATCH v2] phy: Track power-on and init counts in uclass Alper Nebi Yasak
2021-12-28  8:34 ` Simon Glass [this message]
2021-12-28 12:55   ` Tom Rini
2021-12-28 13:08     ` Simon Glass
2021-12-29 22:21       ` Alper Nebi Yasak
2021-12-31  7:39     ` Peter Robinson
2021-12-29 22:01   ` Alper Nebi Yasak
2021-12-30  6:03     ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPnjgZ07oEFQVOV7_5MMx9SgJTiA1Swck9bSpLjKevqM5U5b2g@mail.gmail.com \
    --to=sjg@chromium.org \
    --cc=alpernebiyasak@gmail.com \
    --cc=andre.przywara@arm.com \
    --cc=frank.wang@rock-chips.com \
    --cc=grant.likely@arm.com \
    --cc=grant.likely@secretlab.ca \
    --cc=icenowy@aosc.io \
    --cc=jagan@amarulasolutions.com \
    --cc=joe.hershberger@ni.com \
    --cc=narmstrong@baylibre.com \
    --cc=patrick.delaunay@foss.st.com \
    --cc=pbrobinson@gmail.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.