From: Mickael GUENE <mickael.guene@st.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Matt Ranostay <matt.ranostay@konsulko.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ben Kao <ben.kao@intel.com>, Todor Tomov <todor.tomov@linaro.org>,
Rui Miguel Silva <rui.silva@linaro.org>,
"Akinobu Mita" <akinobu.mita@gmail.com>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
"Jason Chen" <jasonx.z.chen@intel.com>,
Jacopo Mondi <jacopo+renesas@jmondi.org>,
Tianshu Qiu <tian.shu.qiu@intel.com>,
Bingbu Cao <bingbu.cao@intel.com>
Subject: Re: [PATCH v1 2/3] media:st-mipid02: MIPID02 CSI-2 to PARALLEL bridge driver
Date: Mon, 25 Mar 2019 12:14:05 +0000 [thread overview]
Message-ID: <80f98c19-6045-9f7c-d549-f559ae8eb9d9@st.com> (raw)
In-Reply-To: <20190325111746.h26isglf4d765mtg@kekkonen.localdomain>
Hi Sakari,
On 3/25/19 12:17, Sakari Ailus wrote:
> Hi Mickael,
>
> On Mon, Mar 18, 2019 at 09:57:44AM +0000, Mickael GUENE wrote:
>> Hi Sakari,
>>
>> Thanks for your review. Find my comments below.
>>
>> On 3/16/19 23:14, Sakari Ailus wrote:
> ...
>>>> +static struct v4l2_subdev *mipid02_find_sensor(struct mipid02_dev *bridge)
>>>> +{
>>>> + struct media_device *mdev = bridge->sd.v4l2_dev->mdev;
>>>> + struct media_entity *entity;
>>>> +
>>>> + if (!mdev)
>>>> + return NULL;
>>>> +
>>>> + media_device_for_each_entity(entity, mdev)
>>>> + if (entity->function == MEDIA_ENT_F_CAM_SENSOR)
>>>> + return media_entity_to_v4l2_subdev(entity);
>>>
>>> Hmm. Could you instead use the link state to determine which of the
>>> receivers is active? You'll need one more pad, and then you'd had 1:1
>>> mapping between ports and pads.
>>>
>> Goal here is not to detect which of the receivers is active but to find
>> sensor in case there are others sub-dev in chain (for example a
>> serializer/deserializer as found in cars).
>
> You shouldn't make assumptions on the rest of the pipeline beyond the
> device that's directly connected. You might not even have a camera there.
>
I have also seen your answer to '[PATCH v2 2/2] media:st-mipid02: MIPID02 CSI-2 to PARALLEL bridge driver'
concerning support of set_fmt, get_fmt and link_validate.
My initial idea was to avoid to avoid to implement them and to avoid media ctrl configuration. According
to your remark is seems a bad idea. Right ?
In that case I have to also implement enum_mbus_code ?
I will drop this code and use connected device only to get link speed.
>> For the moment the driver doesn't support second input port usage,
>> this is why there is no such second sink pad yet in the driver.
>
> Could you add the second sink pad now, so that the uAPI remains the same
> when you add support for it? Nothing is connected to it but I don't think
> it's an issue.
>
> ...
>
>>>> +
>>>> + sensor = mipid02_find_sensor(bridge);
>>>> + if (!sensor)
>>>> + goto error;
>>>> +
>>>> + dev_dbg(&client->dev, "use sensor '%s'", sensor->name);
>>>> + memset(&bridge->r, 0, sizeof(bridge->r));
>>>> + /* build registers content */
>>>> + code = mipid02_get_source_code(bridge, sensor);
>>>> + ret |= mipid02_configure_from_rx(bridge, code, sensor);
>>>> + ret |= mipid02_configure_from_tx(bridge);
>>>> + ret |= mipid02_configure_from_code(bridge, code);
>>>> +
>>>> + /* write mipi registers */
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_CLK_LANE_REG1,
>>>> + bridge->r.clk_lane_reg1);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_CLK_LANE_REG3, CLK_MIPI_CSI);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_DATA_LANE0_REG1,
>>>> + bridge->r.data_lane0_reg1);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_DATA_LANE0_REG2,
>>>> + DATA_MIPI_CSI);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_DATA_LANE1_REG1,
>>>> + bridge->r.data_lane1_reg1);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_DATA_LANE1_REG2,
>>>> + DATA_MIPI_CSI);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_MODE_REG1,
>>>> + MODE_NO_BYPASS | bridge->r.mode_reg1);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_MODE_REG2,
>>>> + bridge->r.mode_reg2);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_DATA_ID_RREG,
>>>> + bridge->r.data_id_rreg);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_DATA_SELECTION_CTRL,
>>>> + SELECTION_MANUAL_DATA | SELECTION_MANUAL_WIDTH);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_PIX_WIDTH_CTRL,
>>>> + bridge->r.pix_width_ctrl);
>>>> + ret |= mipid02_write_reg(bridge, MIPID02_PIX_WIDTH_CTRL_EMB,
>>>> + bridge->r.pix_width_ctrl_emb);
>>>
>>> Be careful with the error codes. ret will be returned by the s_stream
>>> callback below.
>>>
>> I didn't understand your remark. Can you elaborate a little bit more ?
>
> If the functions return different error codes, then ret possibly won't be a
> valid error code, or at least it's not going to be what it was intended to
> do. You'll need to stop when you encounter an error and then return it to
> the caller.
>
> ...
>
Ok
>>>> +static int mipid02_parse_tx_ep(struct mipid02_dev *bridge)
>>>> +{
>>>> + struct i2c_client *client = bridge->i2c_client;
>>>> + struct v4l2_fwnode_endpoint ep;
>>>> + struct device_node *ep_node;
>>>> + int ret;
>>>> +
>>>> + memset(&ep, 0, sizeof(ep));
>>>> + ep.bus_type = V4L2_MBUS_PARALLEL;
>>>
>>> You can set the field in variable declaration, and omit memset. The same in
>>> the function above.
>>>
>> According to v4l2_fwnode_endpoint_parse() documentation:
>> * This function parses the V4L2 fwnode endpoint specific parameters from the
>> * firmware. The caller is responsible for assigning @vep.bus_type to a valid
>> * media bus type. The caller may also set the default configuration for the
>> * endpoint
>> It seems safer to clear ep else it may select unwanted default configuration
>> for the endpoint ?
>
> By setting one of the fields in a struct in declaration, the rest will be
> zeroed by the compiler. That's from the C standard.
>
Ok
next prev parent reply other threads:[~2019-03-25 12:14 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-12 6:44 [PATCH v1 0/3] Add support for MIPID02 CSI-2 to PARALLEL bridge I2C device Mickael Guene
2019-03-12 6:44 ` [PATCH v1 1/3] dt-bindings: Document MIPID02 bindings Mickael Guene
2019-03-16 21:46 ` Sakari Ailus
2019-03-18 8:28 ` Mickael GUENE
2019-03-18 8:48 ` Sakari Ailus
2019-03-18 9:08 ` Mickael GUENE
2019-03-12 6:44 ` [PATCH v1 2/3] media:st-mipid02: MIPID02 CSI-2 to PARALLEL bridge driver Mickael Guene
2019-03-16 22:14 ` Sakari Ailus
2019-03-18 9:57 ` Mickael GUENE
2019-03-25 11:17 ` Sakari Ailus
2019-03-25 12:14 ` Mickael GUENE [this message]
2019-03-26 11:37 ` Sakari Ailus
2019-03-26 12:07 ` Mickael GUENE
2019-03-12 6:44 ` [PATCH v1 3/3] media: MAINTAINERS: add entry for STMicroelectronics MIPID02 media driver Mickael Guene
2019-03-16 21:47 ` Sakari Ailus
2019-03-18 10:01 ` Mickael GUENE
2019-03-25 7:55 ` [PATCH v2 0/2] Add support for MIPID02 CSI-2 to PARALLEL bridge I2C device Mickael Guene
2019-03-25 7:55 ` [PATCH v2 1/2] dt-bindings: Document MIPID02 bindings Mickael Guene
2019-03-25 7:55 ` [PATCH v2 2/2] media:st-mipid02: MIPID02 CSI-2 to PARALLEL bridge driver Mickael Guene
2019-03-25 11:44 ` Sakari Ailus
2019-03-25 12:22 ` Mickael GUENE
2019-03-26 11:34 ` Sakari Ailus
2019-03-26 12:32 ` Mickael GUENE
2019-03-26 10:03 ` [PATCH v3 0/2] Add support for MIPID02 CSI-2 to PARALLEL bridge I2C device Mickael Guene
2019-03-26 10:03 ` [PATCH v3 1/2] dt-bindings: Document MIPID02 bindings Mickael Guene
2019-03-26 12:17 ` Sakari Ailus
2019-03-26 13:40 ` Mickael GUENE
2019-03-26 13:44 ` Sakari Ailus
2019-03-26 10:03 ` [PATCH v3 2/2] media:st-mipid02: MIPID02 CSI-2 to PARALLEL bridge driver Mickael Guene
2019-03-26 11:33 ` Sakari Ailus
2019-03-26 12:57 ` Mickael GUENE
2019-03-26 13:54 ` Sakari Ailus
2019-03-26 14:12 ` Mickael GUENE
2019-03-26 14:14 ` Sakari Ailus
2019-03-26 14:36 ` Mickael GUENE
2019-04-06 11:01 ` Sakari Ailus
2019-04-08 6:17 ` Mickael GUENE
2019-04-08 9:21 ` Sakari Ailus
2019-03-27 9:55 ` [PATCH v4 0/2] Add support for MIPID02 CSI-2 to PARALLEL bridge I2C device Mickael Guene
2019-03-27 9:55 ` [PATCH v4 1/2] dt-bindings: Document MIPID02 bindings Mickael Guene
2019-03-28 17:43 ` Rob Herring
2019-04-06 10:35 ` Sakari Ailus
2019-04-06 10:38 ` Sakari Ailus
2019-04-08 6:20 ` Mickael GUENE
2019-03-27 9:55 ` [PATCH v4 2/2] media:st-mipid02: MIPID02 CSI-2 to PARALLEL bridge driver Mickael Guene
[not found] ` <20190406105606.rciacao5d4hljbbu@kekkonen.localdomain>
2019-04-08 8:20 ` Mickael GUENE
2019-04-08 9:17 ` Sakari Ailus
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=80f98c19-6045-9f7c-d549-f559ae8eb9d9@st.com \
--to=mickael.guene@st.com \
--cc=akinobu.mita@gmail.com \
--cc=ben.kao@intel.com \
--cc=bingbu.cao@intel.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=jacopo+renesas@jmondi.org \
--cc=jasonx.z.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=matt.ranostay@konsulko.com \
--cc=mchehab@kernel.org \
--cc=rui.silva@linaro.org \
--cc=sakari.ailus@iki.fi \
--cc=sakari.ailus@linux.intel.com \
--cc=tian.shu.qiu@intel.com \
--cc=todor.tomov@linaro.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).