[U-Boot] [PATCH 074/126] pci: Add support for p2sb uclass

[Simon Glass]

Hi Bin,

On Fri, 11 Oct 2019 at 21:37, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Bin,
>
> On Wed, 9 Oct 2019 at 22:57, Bin Meng <bmeng.cn at gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Wed, Sep 25, 2019 at 10:59 PM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > The Primary-to-Sideband bus (P2SB) is used to access various peripherals
> > > through memory-mapped I/O in a large chunk of PCI space. The space is
> > > segmented into different channels and peripherals are accessed by
> > > device-specific means within those channels. Devices should be added in
> > > the device tree as subnodes of the p2sb.
> > >
> >
> > Again, I see no value of bringing P2SB to the uclass driver level,
> > given as of today it is only seen in ApolloLake. Similar mechanism was
> > seen in old x86 SoCs, and at the old time, it was called "Message
> > Port", that existed in old Atom SoCs.
>
> OK, I'll make it a SYSCON I suppose.

I dug into this a bit and I think it is better as a separate uclass.

The reason is that it has child devices which access their resources
through the uclass. Currently we have GPIO and ITSS that do this. But
from the datasheet the RTC is there alsol. The p2sb has child platdata
which supports mmio access. Take a look at p2sb-uclass.c for this.

If it is a syscon:
1. We can't really have child devices with properties known to the
uclass - syscon is for simple devices
2. The devices themselves would have to set the port ID, when really
this is a shared/uclass thing
3. We end up with an odd syscon device in the PCI bus in the device
tree, with children and no indication of why they are there

So I think a uclass is the right thing. I don't think it matters that
we end up with a few more uclasses than we would like. There is no
particular limit unless we want to have a tiny driver model with a
byte for the uclass ID.

Regards,
Simon