Hi Bin,
On Fri, 11 Oct 2019 at 21:37, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Wed, 9 Oct 2019 at 22:57, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, Sep 25, 2019 at 10:59 PM Simon Glass sjg@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