From: Sakari Ailus <sakari.ailus@iki.fi>
To: "Aguirre, Sergio" <saaguirre@ti.com>
Cc: linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com,
dacohen@gmail.com, snjw23@gmail.com,
andriy.shevchenko@linux.intel.com, t.stanislaws@samsung.com,
tuukkat76@gmail.com, k.debski@samsung.com, riverful@gmail.com,
hverkuil@xs4all.nl, teturtia@gmail.com
Subject: Re: [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data
Date: Tue, 14 Feb 2012 08:21:57 +0200 [thread overview]
Message-ID: <4F39FD85.8080007@iki.fi> (raw)
In-Reply-To: <CAKnK67TGn9LWj7M5HOdz5cxG6Vu=uuU-47VAUmham3O3YTEK7A@mail.gmail.com>
Hi Sergio,
Aguirre, Sergio wrote:
> On Sat, Feb 11, 2012 at 11:17 AM, Aguirre, Sergio <saaguirre@ti.com> wrote:
>> Hi Sakari,
>>
>> On Fri, Feb 10, 2012 at 2:32 PM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
>>> Hi Sergio,
>>>
>>> Thanks for the review!
>>>
>>> Aguirre, Sergio wrote:
>>>> On Thu, Feb 2, 2012 at 5:54 PM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
>>>>> Configure CSI-2 phy based on platform data in the ISP driver. For that, the
>>>>> new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
>>>>> was configured from the board code.
>>>>>
>>>>> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
>>>>> ---
>>>>> drivers/media/video/omap3isp/ispcsi2.c | 10 +++-
>>>>> drivers/media/video/omap3isp/ispcsiphy.c | 78 ++++++++++++++++++++++++++----
>>>>> drivers/media/video/omap3isp/ispcsiphy.h | 2 +
>>>>> 3 files changed, 78 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/drivers/media/video/omap3isp/ispcsi2.c b/drivers/media/video/omap3isp/ispcsi2.c
>>>>> index 9313f7c..e2e3d63 100644
>>>>> --- a/drivers/media/video/omap3isp/ispcsi2.c
>>>>> +++ b/drivers/media/video/omap3isp/ispcsi2.c
>>>>> @@ -1068,7 +1068,13 @@ static int csi2_set_stream(struct v4l2_subdev *sd, int enable)
>>>>> struct isp_video *video_out = &csi2->video_out;
>>>>>
>>>>> switch (enable) {
>>>>> - case ISP_PIPELINE_STREAM_CONTINUOUS:
>>>>> + case ISP_PIPELINE_STREAM_CONTINUOUS: {
>>>>> + int ret;
>>>>> +
>>>>> + ret = omap3isp_csiphy_config(isp, sd);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> if (omap3isp_csiphy_acquire(csi2->phy) < 0)
>>>>> return -ENODEV;
>>>>> csi2->use_fs_irq = pipe->do_propagation;
>>>>> @@ -1092,7 +1098,7 @@ static int csi2_set_stream(struct v4l2_subdev *sd, int enable)
>>>>> csi2_if_enable(isp, csi2, 1);
>>>>> isp_video_dmaqueue_flags_clr(video_out);
>>>>> break;
>>>>> -
>>>>> + }
>>>>> case ISP_PIPELINE_STREAM_STOPPED:
>>>>> if (csi2->state == ISP_PIPELINE_STREAM_STOPPED)
>>>>> return 0;
>>>>> diff --git a/drivers/media/video/omap3isp/ispcsiphy.c b/drivers/media/video/omap3isp/ispcsiphy.c
>>>>> index 5be37ce..5d7a6ab 100644
>>>>> --- a/drivers/media/video/omap3isp/ispcsiphy.c
>>>>> +++ b/drivers/media/video/omap3isp/ispcsiphy.c
>>>>> @@ -28,6 +28,8 @@
>>>>> #include <linux/device.h>
>>>>> #include <linux/regulator/consumer.h>
>>>>>
>>>>> +#include "../../../../arch/arm/mach-omap2/control.h"
>>>>> +
>>>>> #include "isp.h"
>>>>> #include "ispreg.h"
>>>>> #include "ispcsiphy.h"
>>>>> @@ -138,15 +140,73 @@ static void csiphy_dphy_config(struct isp_csiphy *phy)
>>>>> isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG1);
>>>>> }
>>>>>
>>>>> -static int csiphy_config(struct isp_csiphy *phy,
>>>>> - struct isp_csiphy_dphy_cfg *dphy,
>>>>> - struct isp_csiphy_lanes_cfg *lanes)
>>>>> +/*
>>>>> + * TCLK values are OK at their reset values
>>>>> + */
>>>>> +#define TCLK_TERM 0
>>>>> +#define TCLK_MISS 1
>>>>> +#define TCLK_SETTLE 14
>>>>> +
>>>>> +int omap3isp_csiphy_config(struct isp_device *isp,
>>>>> + struct v4l2_subdev *csi2_subdev)
>>>>> {
>>>>> + struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
>>>>> + struct isp_pipeline *pipe = to_isp_pipeline(&csi2_subdev->entity);
>>>>> + struct isp_v4l2_subdevs_group *subdevs = pipe->external->host_priv;
>>>>> + struct isp_csiphy_dphy_cfg csi2phy;
>>>>> + int csi2_ddrclk_khz;
>>>>> + struct isp_csiphy_lanes_cfg *lanes;
>>>>> unsigned int used_lanes = 0;
>>>>> unsigned int i;
>>>>>
>>>>> + if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1
>>>>> + || subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
>>>>> + lanes = &subdevs->bus.ccp2.lanecfg;
>>>>> + else
>>>>> + lanes = &subdevs->bus.csi2.lanecfg;
>>>>> +
>>>>> + /* FIXME: Do 34xx / 35xx require something here? */
>>>>> + if (cpu_is_omap3630()) {
>>>>> + u32 cam_phy_ctrl = omap_readl(
>>>>> + OMAP343X_CTRL_BASE + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
>>>>
>>>> How about:
>>>> u32 cam_phy_ctrl = omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
>>>> ?
>>>
>>> Fine for me.
>>>
>>>>> +
>>>>> + /*
>>>>> + * SCM.CONTROL_CAMERA_PHY_CTRL
>>>>> + * - bit[4] : CSIPHY1 data sent to CSIB
>>>>> + * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
>>>>> + * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
>>>>> + */
>>>>> + if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1)
>>>>> + cam_phy_ctrl |= 1 << 2;
>>>>> + else if (subdevs->interface == ISP_INTERFACE_CSI2C_PHY1)
>>>>> + cam_phy_ctrl &= 1 << 2;
>>>>
>>>> Shouldn't this be:
>>>> cam_phy_ctrl &= ~(1 << 2);
>>>> ?
>>>
>>> Probably yes. This has come directly as it was in the original board
>>> code and might not be entirely correct. It works on the N9 at least.
>>>
>>>>> +
>>>>> + if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
>>>>> + cam_phy_ctrl |= 1;
>>>>> + else if (subdevs->interface == ISP_INTERFACE_CSI2A_PHY2)
>>>>> + cam_phy_ctrl &= 1;
>>>>
>>>> ... and:
>>>> cam_phy_ctrl &= ~1;
>>>>
>>>>> +
>>>>> + omap_writel(cam_phy_ctrl,
>>>>> + OMAP343X_CTRL_BASE
>>>>> + + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
>>>>
>>>> Again:
>>>> omap_ctrl_writel(cam_phy_ctrl, OMAP3630_CONTROL_CAMERA_PHY_CTRL);
>>>
>>> Will fix.
Actually not. omap_ctrl_writel() is defined in mach/control.c but it's
not exported, which I believe is correct. Accessing these registers in
the ISP driver is a bit of a hack, and should be eventually replaced by
a proper solution. My understanding is that such is in preparation.
>>>>> + }
>>>>> +
>>>>> + csi2_ddrclk_khz = pipe->external_rate / 1000
>>>>> + / (2 * csi2->phy->num_data_lanes)
>>>>> + * pipe->external_bpp;
>>>>
>>>> Can you please explain how did you came up with this formula?
>>>>
>>>> For example, if I keep the pixel_rate, yet I change the number of
>>>> lanes my sensor is using,
>>>> this result is unaltered, as phy->num_data_lanes is always equal to
>>>> the maximum number
>>>> of lanes available in the interface. (for OMAP4, that's 4 datalanes for CSI2-A).
>>>
>>> The number of lanes is specified in the board code (in the future, DT)
>>> and is thus specific to the board. The clock rate is per-lane whereas
>>> the pipe->external_rate is the total pixel rate on all lanes.
>>>
>>>> Meanwhile, in theory, if I keep the same pixels per second, and use
>>>> less datalanes, the
>>>> DDR frequency should at least double.
>>>>
>>>> Now, this brings me to another question, How can the sensor tell how many lanes
>>>> is using from the total?
>>>
>>> We might consider making the number of lanes used dynamic but that's
>>> currently static. I can't think of any major benefits right now in
>>> making this dynamically configurable.
>>>
>>> Does this answer to your questions? :-)
>>
>>
>> Sorry, I think I didn't made my point clear properly, so I'm proposing
>> a patch to
>> expose and fix this wrong calculation i'm telling you about:
Right; I thought this information already was there but it was the
number of lanes related to the CSI-2 interface instead.
>> <<<<<<<< PATCH START
>> From: Sergio Aguirre <saaguirre@ti.com>
>> Date: Sat, 11 Feb 2012 10:53:01 -0600
>> Subject: [PATCH] omap3isp: phy: get ddrclk based on sensor lanecount
>>
>> This will allow csi2_ddrclk_khz be calculated correctly, by
>> observing the sensor lane count, and not the interface lane count.
>>
>> An example of erratic calculation is, if you have a sensor
>> which only has 1 data lane for output, yet the interface has 2
>> lanes available, the rate still is split in half:
>>
>> pixel_rate = 96000000
>> bpp = 10
>> sensor_data_lanes = 1
>> phy_data_lanes = 2
>>
>> Current formula pretty much says:
>>
>> csi2_ddrclk_khz = pixel_rate / 1000
>> / (2 * phy_data_lanes)
>> * bpp;
>>
>> Explained is:
>>
>> bits/second(bps) = pixels/second(pixel_rate) * bits/pixel(bpp)
>> cycles/second(Hz) = bits/second / 2 bits/cycle
>> cycles/datalane = cycles/second / num
>>
>> Which is you use 2 in last line, would be wrong for a single
>> datalane sensor, so this patch attemote to collect the sensor
>> lane count, and use that instead in the formula.
>>
>> NOTE: This is tested on omap4iss driver, which is in development.
>>
>> Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
>> ---
>> drivers/media/video/omap3isp/ispcsiphy.c | 41 ++++++++++++++++--------------
>> drivers/media/video/omap3isp/ispcsiphy.h | 3 +-
>> 2 files changed, 24 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
>> b/drivers/media/video/omap3isp/ispcsiphy.c
>> index 5d7a6ab..03c5749 100644
>> --- a/drivers/media/video/omap3isp/ispcsiphy.c
>> +++ b/drivers/media/video/omap3isp/ispcsiphy.c
>> @@ -47,7 +47,7 @@ static void csiphy_lanes_config(struct isp_csiphy *phy)
>>
>> reg = isp_reg_readl(phy->isp, phy->cfg_regs, ISPCSI2_PHY_CFG);
>>
>> - for (i = 0; i < phy->num_data_lanes; i++) {
>> + for (i = 0; i < phy->max_data_lanes; i++) {
>> reg &= ~(ISPCSI2_PHY_CFG_DATA_POL_MASK(i + 1) |
>> ISPCSI2_PHY_CFG_DATA_POSITION_MASK(i + 1));
>> reg |= (phy->lanes.data[i].pol <<
>> @@ -191,22 +191,8 @@ int omap3isp_csiphy_config(struct isp_device *isp,
>> + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
>> }
>>
>> - csi2_ddrclk_khz = pipe->external_rate / 1000
>> - / (2 * csi2->phy->num_data_lanes)
>> - * pipe->external_bpp;
>> -
>> - /*
>> - * THS_TERM: Programmed value = ceil(12.5 ns/DDRClk period) - 1.
>> - * THS_SETTLE: Programmed value = ceil(90 ns/DDRClk period) + 3.
>> - */
>> - csi2phy.ths_term = DIV_ROUND_UP(25 * csi2_ddrclk_khz, 2000000) - 1;
>> - csi2phy.ths_settle = DIV_ROUND_UP(90 * csi2_ddrclk_khz, 1000000) + 3;
>> - csi2phy.tclk_term = TCLK_TERM;
>> - csi2phy.tclk_miss = TCLK_MISS;
>> - csi2phy.tclk_settle = TCLK_SETTLE;
>> -
>> /* Clock and data lanes verification */
>> - for (i = 0; i < csi2->phy->num_data_lanes; i++) {
>> + for (i = 0; i < csi2->phy->max_data_lanes; i++) {
>> if (lanes->data[i].pol > 1 || lanes->data[i].pos > 3)
>> return -EINVAL;
>>
>> @@ -214,14 +200,29 @@ int omap3isp_csiphy_config(struct isp_device *isp,
>> return -EINVAL;
>>
>> used_lanes |= 1 << lanes->data[i].pos;
>> + csi2->phy->used_data_lanes++;
>> }
>>
>> - if (lanes->clk.pol > 1 || lanes->clk.pos > 3)
>> + if (lanes->clk.pol > 1 || lanes->clk.pos > csi2->phy->max_data_lanes)
>
> Oops, above should be:
>
> if (lanes->clk.pol > 1 || lanes->clk.pos >
> (csi2->phy->max_data_lanes + 1))
>
> To correctly allow a position in between 1 and 3, as there's 3 lanes in total,
> 1 for clock and max_data_lanes for data.
>
> Apologies for the confusion
After looking at the code for CSI2 phy configuration previously, I
decided it needed a cleanup. I'll send a fixed patch later on.
Cheers,
--
Sakari Ailus
sakari.ailus@iki.fi
next prev parent reply other threads:[~2012-02-14 6:22 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 23:52 [PATCH v2 0/31] V4L2 subdev and sensor control changes, SMIA++ driver and N9 camera board code Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 01/31] v4l: Introduce integer menu controls Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 02/31] v4l: Document " Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 03/31] vivi: Add an integer menu test control Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 04/31] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs Sakari Ailus
2012-02-04 19:02 ` Sylwester Nawrocki
2012-02-04 20:30 ` Sakari Ailus
2012-02-04 22:37 ` Sylwester Nawrocki
2012-02-05 9:04 ` Sakari Ailus
2012-02-05 14:24 ` Sylwester Nawrocki
2012-02-02 23:54 ` [PATCH v2 05/31] v4l: Support s_crop and g_crop through s/g_selection Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 06/31] v4l: Add subdev selections documentation: svg and dia files Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 07/31] v4l: Add subdev selections documentation Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 08/31] v4l: Mark VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP obsolete Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 09/31] v4l: Image source control class Sakari Ailus
2012-02-04 18:42 ` Sylwester Nawrocki
2012-02-04 20:23 ` Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 10/31] v4l: Image processing " Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 11/31] v4l: Document raw bayer 4CC codes Sakari Ailus
2012-02-05 12:46 ` Prabhakar Lad
2012-02-08 18:16 ` Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 12/31] v4l: Add DPCM compressed formats Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 13/31] media: Add link_validate() op to check links to the sink pad Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 14/31] v4l: Improve sub-device documentation for pad ops Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 15/31] v4l: Implement v4l2_subdev_link_validate() Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 16/31] v4l: Allow changing control handler lock Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 17/31] omap3isp: Support additional in-memory compressed bayer formats Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 18/31] omap3isp: Move definitions required by board code under include/media Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 19/31] omap3: add definition for CONTROL_CAMERA_PHY_CTRL Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 20/31] omap3isp: Assume media_entity_pipeline_start may fail Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 21/31] omap3isp: Add lane configuration to platform data Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 22/31] omap3isp: Add information on external subdev to struct isp_pipeline Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 23/31] omap3isp: Introduce omap3isp_get_external_info() Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 24/31] omap3isp: Default link validation for ccp2, csi2, preview and resizer Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 25/31] omap3isp: Implement proper CCDC link validation, check pixel rate Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 26/31] omap3isp: Move setting constaints above media_entity_pipeline_start Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data Sakari Ailus
2012-02-10 2:05 ` Aguirre, Sergio
2012-02-10 20:32 ` Sakari Ailus
2012-02-11 17:17 ` Aguirre, Sergio
2012-02-11 17:24 ` Aguirre, Sergio
2012-02-14 6:21 ` Sakari Ailus [this message]
2012-02-16 7:40 ` [PATCH v2.1 1/1] " Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 28/31] omap3isp: Add resizer data rate configuration to resizer_set_stream Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 29/31] omap3isp: Remove isp_validate_pipeline and other old stuff Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 30/31] smiapp: Add driver Sakari Ailus
2012-02-02 23:54 ` [PATCH v2 31/31] rm680: Add camera init 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=4F39FD85.8080007@iki.fi \
--to=sakari.ailus@iki.fi \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dacohen@gmail.com \
--cc=hverkuil@xs4all.nl \
--cc=k.debski@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=riverful@gmail.com \
--cc=saaguirre@ti.com \
--cc=snjw23@gmail.com \
--cc=t.stanislaws@samsung.com \
--cc=teturtia@gmail.com \
--cc=tuukkat76@gmail.com \
/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).