Hi Maxime,
Maxime Ripard <maxime.rip...@free-electrons.com> wrote on Wed [2017-Oct-11
13:55:44 +0200]:
> Hi Benoit,
>
> On Fri, Sep 29, 2017 at 06:21:25PM +0000, Benoit Parrot wrote:
> > > +struct csi2tx_priv {
> > > + struct device *dev;
> > > + atomic_t count;
> > > +
> > > + void __iomem *base;
> > > +
> > > + struct clk *esc_clk;
> > > + struct clk *p_clk;
> > > + struct clk *pixel_clk[CSI2TX_STREAMS_MAX];
> > > +
> > > + struct v4l2_subdev subdev;
> > > + struct media_pad pads[CSI2TX_PAD_MAX];
> > > + struct v4l2_mbus_framefmt pad_fmts[CSI2TX_PAD_MAX];
> > > +
> > > + bool has_internal_dphy;
> >
> > I assume dphy support is for a subsequent revision?
>
> Yes, the situation is similar to the CSI2-RX driver.
>
> > > + /*
> > > + * We use the stream ID there, but it's wrong.
> > > + *
> > > + * A stream could very well send a data type that is
> > > + * not equal to its stream ID. We need to find a
> > > + * proper way to address it.
> > > + */
> >
> > I don't quite get the above comment, from the code below it looks like
> > you are using the current fmt as a source to provide the correct DT.
> > Am I missing soemthing?
>
> Yes, so far the datatype is inferred from the format set. Is there
> anything wrong with that?
No, nothing wrong with that behavior it just doesn't not match the comment
above, where it is says that the DT is set to the stream ID...
Regards,
Benoit
