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.
