Thread (28 messages) 28 messages, 7 authors, 2021-10-27

Re: [PATCH v5 4/6] PCI: brcmstb: Add control of subdevice voltage regulators

From: Jim Quinlan <hidden>
Date: 2021-10-25 13:50:27
Also in: linux-pci, lkml

On Fri, Oct 22, 2021 at 3:47 PM Mark Brown [off-list ref] wrote:
On Fri, Oct 22, 2021 at 03:15:59PM -0400, Jim Quinlan wrote:
quoted
Each different SOC./board we deal with may present different ways of
making the EP device power on.  We are using
an abstraction name "brcm-ep-a"  to represent some required regulator
to make the EP  work for a specific board.  The RC
driver cannot hard code a descriptive name as it must work for all
boards designed by us, others, and third parties.
The EP driver also doesn't know  or care about the regulator name, and
this driver is often closed source and often immutable.  The EP
device itself may come from Brcm, a third party,  or sometimes a competitor.
quoted
Basically, we find using a generic name such as "brcm-ep-a-supply"
quite handy and many of our customers embrace this feature.
I know that Rob was initially against such a generic name, but I
vaguely remember him seeing some merit to this, perhaps a tiny bit :-)
Or my memory is shot, which could very well be the case.
That sounds like it just shouldn't be a regulator at all, perhaps the
board happens to need a regulator there but perhaps it needs a clock,
GPIO or some specific sequence of actions.  It sounds like you need some
sort of quirking mechanism to cope with individual boards with board
specific bindings.
The boards involved may have no PCIe sockets, or run the gamut of the different
PCIe sockets.  They all offer gpio(s) to turn off/on their power supply(s) to
make their PCIe device endpoint functional.  It is not viable to add
new Linux quirk or DT
code for each board.  First is the volume and variety of the boards
that use our SOCs.. Second, is
our lack of information/control:  often, the board is designed by one
company (not us), and
given to another company as the middleman, and then they want the
features outlined
in my aforementioned commit message.
I'd suggest as a first pass omitting this and then looking at some
actual systems later when working out how to support them, no sense in
getting the main thing held up by difficult edge cases.
These are not edge cases -- some of these are major customers.

Regards,
Jim
quoted
quoted
quoted
+     /* This is for Broadcom STB/CM chips only */
+     if (pcie->type == BCM2711)
+             return 0;
quoted
quoted
It is a relief that other chips have managed to work out how to avoid
requiring power.
quoted
I'm not sure that the other Broadcom groups have our customers, our
customers' requirements, and the amount and variation of boards that
run our PCIe driver on the SOC.
Sure, but equally they might (even if they didn't spot it yet) and in
general it's safer to err on the side of describing the hardware so we
can use that information later.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help