Re: [PATCH 2/5] arm64: dts: exynos: Move the clock-frequency property

On Wed, Feb 8, 2017 at 12:09 PM, Hoegeun Kwon [off-list ref] wrote:

On 02/08/2017 04:32 PM, Krzysztof Kozlowski wrote:

quoted

On Wed, Feb 8, 2017 at 9:24 AM, Hoegeun Kwon [off-list ref]
wrote:

quoted

quoted

"Remove the ports node abd move burst and esc clock frequency properties
to the parent (DSI node)."

The information which is missing is the answer for WHY? Why are you
doing this?

The current mipi-dsi must have at least one OF graph.
However, for example, dsi and panel are parent-child relationships,
so OF graph is not needed, and fimd and dsi are not connected to the OF
graph.
In this case, an error occurred in dsi_parse in the code before patch
(1/5).

The error occurred in case of DSI + FIMD? I do not get it whether you
are removing the something which is not needed or fixing something.

quoted

So I modified dsi_parse_dt.

quoted

Does the patch depends on 1/5?

Yes, it is.
The 2/5 to 5/5 patches depend on the 1/5 patch.

So that's a break of DT ABI for no clear (yet) reasons. Please mention
this in 1/5 patch and explain what is really fixed.

I would like to post the s6e63j0x03 panel driver for exynos3250.
However, as Rob Herring noted, dsi + panel is a parental relationship,
so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi + panel.
I think that the OF graph of dsi should be deleted even if it is not
the purpose of the s6e63j0x03 panel driver.

So the 1/5 patch parse the Pll, burst and esc clock frequency properties
in dsi_parse_dt and modified to create a bridge_node only if there is
an OF graph associated with dsi.

Thanks, now it makes sense. Such clear explanation should be part of
commit 1/5 as a proof that ABI breakage is needed.

BR,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html