Re: [PATCH v5 3/7] xen/arm: zynqmp: introduce zynqmp specific defines

From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: edgar.iglesias@xilinx.com,
	Stefano Stabellini <stefanos@xilinx.com>,
	saeed.nowshadi@xilinx.com, xen-devel@lists.xen.org
Subject: Re: [PATCH v5 3/7] xen/arm: zynqmp: introduce zynqmp specific defines
Date: Thu, 13 Dec 2018 15:50:23 +0000	[thread overview]
Message-ID: <40491bf4-26c6-e472-8d53-e8db08f2fc79@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1812120940430.12259@sstabellini-ThinkPad-X260>

Hi Stefano,

On 12/12/18 11:55 PM, Stefano Stabellini wrote:
> On Wed, 12 Dec 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 11/12/2018 19:22, Stefano Stabellini wrote:
>>> On Tue, 11 Dec 2018, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 03/12/2018 21:03, Stefano Stabellini wrote:
>>>> What is the plan there?
>>>
>>> The plan is to extract the node_id from a power-domain node on device
>>> tree. Each device would have a phandler to link to the right
>>> power-domain node which contains a power-domain-id attribute. The
>>> power-domain-id attribute is the node_id here.
>>>
>>> The power-domain-id changes to the Xilinx MPSoC device tree are under
>>> discussion with the device tree community.
>>
>> If I understand correctly, we will never be able to remove the hardcoded
>> values in Xen. This is because some device-tree may not have the bindings. Am
>> I correct?
> 
> If we want to support running on existing hardware and firmware releases,
> then you are correct. We won't be able to remove the hardcoded values.
> That ship has sailed, not much we can do about it.
> 
> If in the future we decide to drop support for older firmware releases
> and ask users to update their firmare/devicetrees, then we'll be able to
> remove the hardcoded values. I think it is something we can consider.
> In fact, I would rather break compatibility than not providing support
> for basic power management functionalities at all.

With your suggestion this means that Xen and the firmware are tied 
together. So you can't update Xen without updating the firmware.

We already ruled out that behavior for x-gene. See the partial revert 
you did 420596c868 to revert back the quirk.

I don't think this is very different here. We are introducing a feature, 
that we know will be broken afterwards unless you update your firmware. 
It is not like it was not planned... We should aim to support most of 
the official firmware unless there are a strong argument not to do.

Basic power management for other than Dom0 is not a valid enough reason 
for me to break compatibility.

> 
> I think it is better to introduce basic EEMI support now, even if in a
> couple of Xen releases from now we'll make the decision to drop the
> hardcoded values and require new Xilinx device trees. Xilinx users are
> used to updating firmware on these boards every 6 months, and it would
> beneficial for them to be able to take a Xen Project release rather than
> be forced to use a Xilinx Xen release to have support for power
> management. When the new bindings become available, as we introduce
> support for them in Xen, we can decide whether to keep the hardcoded
> values or whether we should take the opportunity to drop them.
This is the right moment to discuss about it. It will be too late once 
we get merged. I don't want to see 2 solutions in Xen if we know that 
bindings are work-in-progress.

I am happy to consider EEMI for Dom0. For the guests, it will have to 
wait the device-tree bindings.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel