From: Sakari Ailus <sakari.ailus@iki.fi>
To: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
linux-renesas-soc@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Kieran Bingham" <kieran.bingham@ideasonboard.com>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"Jacopo Mondi" <jacopo@jmondi.org>,
"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Hyun Kwon" <hyunk@xilinx.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Jacopo Mondi" <jacopo+renesas@jmondi.org>,
"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>
Subject: Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver
Date: Tue, 19 May 2020 12:03:57 +0300 [thread overview]
Message-ID: <20200519090357.GD3877@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <8932699a-b321-2308-8903-31268af774cb@ideasonboard.com>
Hi Kieran,
On Tue, May 19, 2020 at 09:55:24AM +0100, Kieran Bingham wrote:
> Hi Sakari,
>
> On 19/05/2020 09:10, Sakari Ailus wrote:
> > Hi Kieran,
> >
> > On Mon, May 18, 2020 at 12:45:18PM +0100, Kieran Bingham wrote:
> >> Hi Sakari,
> >>
> >> There are only fairly minor comments here, fix ups will be included in a
> >> v10.
> >>
> >> Is there anything major blocking integration?
> >
> > Not that I can see. But please see my comments below.
>
> Thanks,
>
> We might have some more work tidying up the DT validation anyway which
> has come too late, and perhaps is going to bump this to v5.9 now anyway.
>
> I can still try but ... ;-S
>
> At least hopefully now we /can/ see a path to integration though.
>
> I probably don't care if it's 5.8 or 5.9 as long as it's not 8.5 ;-)
>
> >>
> >> Regards
> >>
> >> Kieran
> >>
> >>
> >>
> >> On 16/05/2020 22:51, Sakari Ailus wrote:
> >>> Hi Kieran,
> >>>
> >>> Thanks for the update.
> >>>
> >>> On Tue, May 12, 2020 at 04:51:03PM +0100, Kieran Bingham wrote:
> >>>
> >>> ...
> >>>
> >>>> +static int max9286_enum_mbus_code(struct v4l2_subdev *sd,
> >>>> + struct v4l2_subdev_pad_config *cfg,
> >>>> + struct v4l2_subdev_mbus_code_enum *code)
> >>>> +{
> >>>> + if (code->pad || code->index > 0)
> >>>> + return -EINVAL;
> >>>> +
> >>>> + code->code = MEDIA_BUS_FMT_UYVY8_2X8;
> >>>
> >>> Why UYVY8_2X8 and not UYVY8_1X16? In general, the single sample / pixel
> >>> variant of the format is generally used on the serial busses. This choice
> >>> was made when serial busses were introduced.
> >>
> >> Ok - I presume this doesn't really have much effect anyway, they just
> >> have to match for the transmitter/receiver?
> >
> > In this case, yes. But it's harder to change later, so let's indeed do that
> > now.
>
> Yes indeed, I have to change my test scripts for the new configuration
> (or we should update the scripts to get the configuration from the
> device ;D)
>
>
> >> But it makes sense to me, so I'll update to the 1x16 variant.
> >
> > ...
>
> done anyway ;-)
>
> I see the ADV748x is using the 2x8 variants though ... (all the more
> reason for our scripts to /get/ the correct version when propagating
> formats).
>
> Perhaps I should/could add the 1x16 formats to the ADV748x too. (later)
It's a driver bug, yes.
>
>
> >>> And as you don't, you also won't know which frequencies are known to be
> >>> safe to use. That said, perhaps where this device is used having a random
> >>> frequency on that bus could not be an issue. Perhaps.
> >>
> >> Does this generate a range? or a list of static supported frequencies?
> >>
> >> We configure the pixel clock based upon the number of cameras connected,
> >> and their pixel rates etc ...
> >>
> >> Are you saying that the frequency of this clock should be validated to
> >> be a specific range? or are you talking about a different frequency?
> >
> > It depends on the system. In general, only frequencies known to be safe
> > should be used. If this one has enough shielding to guarantee there won't
> > be problems in using a random frequency in the entire range, is there a
> > guarantee that will be the case for all systems with this chip?
>
> I have no idea here... Maybe Niklas knows more having dealt more with
> the RCar-VIN/CSI parts.
>
> It seems like this is something we can add later if necessary, by
> extending the descriptions in the DT?
Works for me.
Niklas, any idea?
--
Regards,
Sakari Ailus
next prev parent reply other threads:[~2020-05-19 9:04 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 15:51 [PATCH v9 0/4] MAX9286 GMSL Support (+RDACM20) Kieran Bingham
2020-05-12 15:51 ` [PATCH v9 1/4] dt-bindings: media: i2c: Add bindings for Maxim Integrated MAX9286 Kieran Bingham
2020-05-12 22:33 ` Rob Herring
2020-05-13 12:54 ` Jacopo Mondi
2020-05-14 9:43 ` [PATCH] fixup! dt-bindings: media: i2c: Add bindings for Maxima Integrated MAX9286 Kieran Bingham
2020-05-14 10:20 ` Jacopo Mondi
2020-05-12 22:36 ` [PATCH v9 1/4] dt-bindings: media: i2c: Add bindings for Maxim " Rob Herring
2020-05-13 12:28 ` Jacopo Mondi
2020-05-12 15:51 ` [PATCH v9 2/4] media: i2c: Add MAX9286 driver Kieran Bingham
2020-05-12 17:40 ` Manivannan Sadhasivam
2020-05-14 9:53 ` Kieran Bingham
2020-05-14 9:59 ` Manivannan Sadhasivam
2020-05-14 10:05 ` Kieran Bingham
2020-05-12 18:17 ` Manivannan Sadhasivam
2020-05-14 10:02 ` Kieran Bingham
2020-05-14 10:13 ` Manivannan Sadhasivam
2020-05-14 11:47 ` Kieran Bingham
2020-05-14 11:59 ` Geert Uytterhoeven
2020-05-14 12:48 ` Manivannan Sadhasivam
2020-05-14 13:50 ` Kieran Bingham
2020-05-14 11:47 ` Kieran Bingham
2020-05-14 12:27 ` Kieran Bingham
2020-05-14 12:54 ` Manivannan Sadhasivam
2020-05-16 21:51 ` Sakari Ailus
2020-05-18 11:45 ` Kieran Bingham
2020-05-18 12:38 ` Jacopo Mondi
2020-05-18 13:09 ` Kieran Bingham
2020-05-18 16:11 ` [PATCH] fixes! [max9286]: Validate link formats Kieran Bingham
2020-05-18 18:44 ` Kieran Bingham
2020-05-19 8:13 ` Sakari Ailus
2020-05-19 7:56 ` Jacopo Mondi
2020-05-19 9:00 ` Kieran Bingham
2020-05-19 8:10 ` [PATCH v9 2/4] media: i2c: Add MAX9286 driver Sakari Ailus
2020-05-19 8:55 ` Kieran Bingham
2020-05-19 9:03 ` Sakari Ailus [this message]
2020-05-20 0:50 ` Laurent Pinchart
2020-05-26 8:54 ` Sakari Ailus
2020-05-12 15:51 ` [PATCH v9 3/4] dt-bindings: media: i2c: Add bindings for IMI RDACM2x Kieran Bingham
2020-05-12 15:51 ` [PATCH v9 4/4] media: i2c: Add RDACM20 driver Kieran Bingham
2020-05-16 22:36 ` Sakari Ailus
2020-05-18 7:35 ` Jacopo Mondi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200519090357.GD3877@valkosipuli.retiisi.org.uk \
--to=sakari.ailus@iki.fi \
--cc=devicetree@vger.kernel.org \
--cc=hverkuil@xs4all.nl \
--cc=hyunk@xilinx.com \
--cc=jacopo+renesas@jmondi.org \
--cc=jacopo@jmondi.org \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mchehab@kernel.org \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=niklas.soderlund@ragnatech.se \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).