On Mon, 28 Mar 2022, Oleksii Moisieiev wrote:
> On Wed, Mar 23, 2022 at 10:54:22AM +0000, Sudeep Holla wrote:
> > On Tue, Mar 22, 2022 at 07:21:47PM +0000, Oleksii Moisieiev wrote:
> > > Hi Sudeep,
> > >
> > > On Tue, Mar 22, 2022 at 11:12:21AM +0000, Sudeep Holla wrote:
> > > > On Fri, Mar 18, 2022 at 04:53:20PM -0700, Stefano Stabellini wrote:
> > > > > On Wed, 16 Mar 2022, Sudeep Holla wrote:
> > > > > > On Wed, Mar 16, 2022 at 04:46:20PM +0000, Oleksii Moisieiev wrote:
> > > > > > >
> > > > > > > > + The reason I want to keep it xen specific at the moment as we had some
> > > > > > > > plan to extended the device-id usage in the spec which hasn't progressed
> > > > > > > > a bit(I must admit that before you ask), and this addition should not be
> > > > > > > > obstruct that future development. If we align with what we define xen
> > > > > > > > specific as part of $subject work, we can always define generic binding
> > > > > > > > in the future and slowly make the other obsolete over the time.
> > > > > > >
> > > > > > > IIUC you have some plans to provide device_id support to the device-tree
> > > > > > > bindings from your side. Maybe we can discuss some of your plans here
> > > > > > > and we can come up with the generic device-id binding?
> > > > > > > So I will have something to base on in Xen.
> > > > > > >
> > > > > >
> > > > > > Sorry if I wasn't clear in earlier emails. What I mentioned was that I would
> > > > > > like to reserve the generic namespace(i.e. just device-id) for generic SCMI
> > > > > > usage. Since we haven't defined it clearly in the spec, I don't want to
> > > > > > introduce the generic definition and binding now.
> > > > > >
> > > > > > As mentioned earlier, though Xen definition and generic once may be exactly
> > > > > > same, but we won't know until then. So keep the xen usage and namespace
> > > > > > separate for now to avoid any future conflicts.
> > > > >
> > > > >
> > > > > Hi Sudeep,
> > > > >
> > > > > I thought the specification already covered this device id, it simply
> > > > > delegated the description of it to Device Tree or ACPI, which is common
> > > > > behavior in ARM specs. What is missing in the SCMI spec from your point
> > > > > of view?
> > > > >
> > > >
> > > > While you can say so, but for me it isn't to an extent that we can support
> > > > software around it. I did share my feedback with spec author but as you
> > > > know it was needed for virtualisation use-case like Xen and was rushed
> > > > into the spec. All it states is "Device identifier" identifies the device
> > > > and the enumeration is not part of the spec. It defers to DT/ACPI.
> > > >
> > > > Since I didn't have to use that in OSPM, I hadn't given much thought/review
> > > > on that.
> > > >
> > > > >
> > > > > Or would you like this scmi-devid Device Tree property (or similar) to
> > > > > be described in the SCMI specification itself?
> > > > >
> > > >
> > > > Spec doesn't cover that in general but do carry some recommendations
> > > > sometimes.
> > > >
> > > > > Typically Device Tree and ACPI descriptions are delegated to Device Tree
> > > > > and ACPI respectively. Also specification updates are typically slow
> > > > > (for good reason.) We might be waiting for a long time. It is usually
> > > > > not a matter of days.
> > > >
> > > > I agree.
> > > >
> > > > As I said, there were thoughts about adding device protocol to make
> > > > all the other protocols centered around the device. The idea is as below:
> > > >
> > > > Today a device A is associated with clock domain X, reset domain Y,
> > > > voltage domain Z, perf domain P, power domain Q, ...and so on.
> > > > Especially this would get complex with lots of devices and for virtual
> > > > machines.
> > > >
> > > > Instead let all these different operations use the device identifier A
> > > > in the above case to drive clock, reset, perf, power, voltage,...etc.
> > >
> > > So, IIUC - the idea is to provide new device based protocol
> > > which will allow agents to control different domains by using ony device
> > > id? Does it mean that scmi drivers for agents should be also changed and there will
> > > be no back compatibility with previous versions of SCMI protocol?
> >
> > The idea is it is discoverable and if the platform advertises new protocol,
> > then only it will be used. Otherwise we must continue to use the existing
> > and advertised protocols. Anyways I realised that we need not even consider
> > these new changes for the discussion here.
> >
> > > If yes - we probably can add scmi-devid property for current SCMI
> > > version, such as scmi-v3,device-id (because current DEN0056D document
> > > has version 3.1) and say that this property should be
> > > used for SCMI versions, which doesn't support device protocol.
> > > What do you think about this idea?
> >
> > The main idea we had is to re-use the generic definition of device ID
> > Linux might need for other purposes like device assignments. We would
> > like to avoid a mapping from the generic device ID Linux might need and
> > define to the one in scmi context. So as Rob mentioned, it is better to
> > define one in a generic Linux/OS context and see how we can make use of
> > that in SCMI context. We could get some recommendations added to the spec
> > if needed based on what gets added/supported in the kernel.
> >
> > So better to start addressing or responding to Rob's comments(not sure
> > if it was this version or the previous) if you want a generic device
> > ID definition. We are not adding anything SCMI specific as that might
> > end up conflicting with the one that Linux kernel might add.
> >
> Hi Rob,
>
> Based on what Sudeep have suggested, I think we may think about the approach
> of the Generic Linux device-id, which can be used for SCMI needs as the
> device id.
>
> I have some ideas, how the generic device_id can be implemented.
> >From my understanding - the Generic Device Id is the unique identifier, which
> can be set for the Device node in the Device-tree. This identifier is
> already set for each node by DTC and called phandle.
>
> I've tried setting phandle for the device-nodes, such as:
>
> &usb0 {
> /* .... */
> phandle = <0x10>;
> }
>
> DTC seems to work properly with this constant phandle. All links works
> for usb0 and all nodes, which doesn't have constant phandle receives
> calculated phandle during device-tree compilation.
>
> Also DTC will fail if I set 2 same phandle values in different
> device nodes. So we can rely on phandle as on the unique device id.
>
> What do you think about using phandle to set the device_id?
>
> The alternative way I see for now is to itroduce additional property to SCMI
> node, which includes list of the device-ids, such as:
>
> scmi {
> compatible = "arm,scmi-smc";
> /* ... */
> device-ids = <&usb0 17,
> &usb1 42,
> ....
> >;
> }
>
> Looking forward for your opinion.
> Maybe you can share some ideas about how the device-id can be
> implemented?
I don't think Sudeep and Rob meant the phandle. I think they meant
something more similar to the "xen,scmi-devid" you proposed but with a
more generic meaning.
