Re: [PATCH v2 18/25] drm/msm/dsi: Don't get DSI index from DT

[Archit Taneja <architt@codeaurora.org>]

On 06/23/2016 08:15 PM, Rob Herring wrote:
> On Thu, Jun 23, 2016 at 9:13 AM, Archit Taneja <architt@codeaurora.org> wrote:
>> The DSI host and PHY driver currently expects the DT bindings to provide
>> custom properties "qcom,dsi-host-index" and "qcom,dsi-phy-index" so that
>> the driver can identify which DSI instance it is.
>>
>> The binding isn't acceptable, but the driver still needs to figure out
>> what its instance id. This is now done by storing the mmio starting
>> addresses for each DSI instance in every SoC version in the driver. The
>> driver then identifies the index number by trying to match the stored
>> address with comparing the resource start address we get from DT.
>
> I looked a bit more at this. It seems at least one reason you need to
> know which DSI instance is which is when ganging the instances
> together and needing to define the clock master. You could define a
> property for the clock master for example.

The ganging of instances itself has two parts to it: 1) routing the
external clocks feeding to the DSI hosts. That can be managed by
assigned clocks without the need of having a clock-master property.
I've shared an example at the end showing how that can be done. 2)
Programming certain PHY register fields telling it which 'DSI index
number' it's getting its clocks from.

For (2), just having a 'clock-master' property in one of the instances
property isn't sufficient to program the register field. We need to
know that DSI0 is 0, and DSI1 is 1. That's why we need to derive it in
the driver itself if we don't have a property for it in DT.

It would have been nicer if the register interface had let us say
"I am the master" or "other instance is the master", but I guess that
wouldn't have worked if a SoC had, say, 3 DSI instances.

I guess we can derive the instance number from the driver internally
as done in this patch, use assigned clocks to set up the routing of
the external clocks, and have a "qcom,dsi-clock-master" property
only needed for Dual DSI usecases.

Does this sound good?

Thanks,
Archit

In the example bindings below, DSI0 PLL outputs are used to drive both
the DSIs, i.e, DSI0 instance is the clock master:

dsi_phy0 {
	/* DSI0 PLL clock provider */
};

dsi_phy1 {
	/* DSI1 PLL clock provider */
};

dsi0 {
	...

	assigned-clocks =
			<&mmcc BYTE0_CLK_SRC>,
			<&mmcc PCLK0_CLK_SRC>;
	assigned-clock-parents =
				<&dsi_phy0 0>,
				<&dsi_phy0 1>;
	...

};

dsi1 {
	...
	assigned-clocks =
			<&mmcc BYTE1_CLK_SRC>,
			<&mmcc PCLK1_CLK_SRC>;
	assigned-clock-parents =
				<&dsi_phy0 0>,
				<&dsi_phy0 1>;
	...
};


>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>