Re: [PATCH v5 2/6] phy: cdns-dphy: Add Rx support

On 08-10-21, 14:55, Paul Kocialkowski wrote:

Hi,

On Fri 08 Oct 21, 13:27, Laurent Pinchart wrote:

quoted

Hi Pratyush,

On Thu, Oct 07, 2021 at 05:44:38PM +0530, Pratyush Yadav wrote:

quoted

On 07/10/21 03:10AM, Laurent Pinchart wrote:

quoted

On Fri, Oct 01, 2021 at 11:53:16AM +0530, Vinod Koul wrote:

quoted

On 17-09-21, 22:58, Pratyush Yadav wrote:

quoted

On 16/09/21 12:22PM, Paul Kocialkowski wrote:

quoted

On Fri 03 Sep 21, 00:25, Pratyush Yadav wrote:

quoted

The Cadence DPHY can be used to receive image data over the CSI-2
protocol. Add support for Rx mode. The programming sequence differs from
the Tx mode so it is added as a separate set of hooks to isolate the two
paths. The mode in which the DPHY has to be used is selected based on
the compatible.

I just realized that I didn't follow-up on a previous revision on the debate
about using the phy sub-mode to distinguish between rx/tx.

I see that you've been using a dedicated compatible, but I'm not sure this is a
good fit either. My understanding is that the compatible should describe a group
of register-compatible revisions of a hardware component, not how the hardware
is used specifically. I guess the distinction between rx/tx falls under
the latter rather than the former.

I am not sure if that is the case. For example, we use "ti,am654-ospi" 
for Cadence Quadspi controller. The default compatible, "cdns,qspi-nor", 
only supports Quad SPI (4 lines). The "ti,am654-ospi" compatible also 
supports Octal SPI (8 lines).

Those are hardware defaults right?

quoted

In addition, I feel like the Rx DPHY is almost a different type of 
device from a Tx DPHY. The programming sequence is completely different, 

Is that due to direction or something else..?

quoted

the clocks required are different, etc. So I think using a different 
compatible for Rx mode makes sense.

Is the underlaying IP not capable of both TX and RX and in the specific
situations you are using it as TX and RX.

I am okay that default being TX but you can use Paul's approach of
direction with this to make it better proposal

Given that the RX and TX implementations are very different (it's not a
matter of selecting a mode at runtime), I'm actually tempted to
recommend having two drivers, one for the RX PHY and one for the TX PHY.
This can only be done with two different compatible strings, which I
think would be a better approach.

FWIW, I think having different drivers would certainly make things 
easier to maintain.

I'm sorry for not having recommended this in the first place.

Any objection from anyone against going in this direction ?

So apparently there is not a single register that is shared between rx and tx
and clocks are not the same either so it feels to me like a separate driver
would be legit. This looks like two distinct IPs sharing the same base address.

Sorry for delay in getting back..

Okay lets have a different compatible and driver for this

-- 
~Vinod

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy