mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hugues FRUCHET <hugues.fruchet@st.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Alexandre TORGUE <alexandre.torgue@st.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-stm32@st-md-mailman.stormreply.com" 
	<linux-stm32@st-md-mailman.stormreply.com>,
	Alain VOLMAT <alain.volmat@st.com>,
	Yannick FERTRE <yannick.fertre@st.com>,
	Philippe CORNU <philippe.cornu@st.com>
Subject: Re: [PATCH] media: stm32-dcmi: add support of BT656 bus
Date: Mon, 19 Oct 2020 10:19:58 +0000	[thread overview]
Message-ID: <254e2f2e-94ca-2421-1a1b-bcd43a75b847@st.com> (raw)
In-Reply-To: <1e1eb9d1-75af-c560-7d06-14d25bb52b3f@st.com>

Hi Sakari,

I have questions about "bus-type" handling below.

On 10/15/20 5:41 PM, Hugues FRUCHET wrote:
> Hi Sakari,
> 
> Thanks for reviewing,
> 
> On 10/13/20 11:07 AM, Sakari Ailus wrote:
>> Hi Hugues,
>>
>> On Wed, Oct 07, 2020 at 06:14:50PM +0200, Hugues Fruchet wrote:
>>> Add support of BT656 embedded synchronization bus.
>>> This mode allows to save hardware synchro lines hsync & vsync
>>> by replacing them with synchro codes embedded in data stream.
>>> This bus type is only compatible with 8 bits width data bus.
>>> Due to reserved values 0x00 & 0xff used for synchro codes,
>>> valid data only vary from 0x1 to 0xfe, this is up to sensor
>>> to clip accordingly pixel data. As a consequence of this
>>> clipping, JPEG is not supported when using this bus type.
>>> DCMI crop feature is also not available with this bus type.
>>
>> You can have more than 62 characters per line. In fact, 75 is the
>> recommended maximum.
>>
>> You should also amend the bindings to cover BT.656 mode. Also bus-type
>> should probably be made mandatory, too.
> Will do both.
> 

My understanding was that parallel BT656 bus is handled by the absence 
of hsync/vsync-active, as stated in 
Documentation/devicetree/bindings/media/video-interfaces.txt:
"  Note, that if HSYNC and VSYNC polarities are not specified, embedded
   synchronization may be required, where supported. "

Do you want to enforce usage of "bus-type" now in order to be more 
explicit on parallel or bt656 ?
If I change binding to make "bus-type" required, I have to change the 
current board devicetree files to add support of it, and I would prefer 
to not do that. Is there a way to put "bus-type" as not mandatory and 
rely on absence of hsync/vysnc to trig BT656 ? I will nevertheless amend 
bindings in order to document that.
What do you suggest ?

>>
>>>
>>> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
>>> ---
>>>   drivers/media/platform/stm32/stm32-dcmi.c | 37 
>>> +++++++++++++++++++++++++++++--
>>>   1 file changed, 35 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c 
>>> b/drivers/media/platform/stm32/stm32-dcmi.c
>>> index fd1c41c..d7d7cdb 100644
>>> --- a/drivers/media/platform/stm32/stm32-dcmi.c
>>> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
>>> @@ -157,6 +157,7 @@ struct stm32_dcmi {
>>>       struct vb2_queue        queue;
>>>       struct v4l2_fwnode_bus_parallel    bus;
>>> +    enum v4l2_mbus_type        bus_type;
>>>       struct completion        complete;
>>>       struct clk            *mclk;
>>>       enum state            state;
>>> @@ -777,6 +778,23 @@ static int dcmi_start_streaming(struct vb2_queue 
>>> *vq, unsigned int count)
>>>       if (dcmi->bus.flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
>>>           val |= CR_PCKPOL;
>>> +    /*
>>> +     * BT656 embedded synchronisation bus mode.
>>> +     *
>>> +     * Default SAV/EAV mode is supported here with default codes
>>> +     * SAV=0xff000080 & EAV=0xff00009d.
>>> +     * With DCMI this means LSC=SAV=0x80 & LEC=EAV=0x9d.
>>> +     */
>>> +    if (dcmi->bus_type == V4L2_MBUS_BT656) {
>>> +        val |= CR_ESS;
>>> +
>>> +        /* Unmask all codes */
>>> +        reg_write(dcmi->regs, DCMI_ESUR, 0xffffffff);/* 
>>> FEC:LEC:LSC:FSC */
>>> +
>>> +        /* Trig on LSC=0x80 & LEC=0x9d codes, ignore FSC and FEC */
>>> +        reg_write(dcmi->regs, DCMI_ESCR, 0xff9d80ff);/* 
>>> FEC:LEC:LSC:FSC */
>>> +    }
>>> +
>>>       reg_write(dcmi->regs, DCMI_CR, val);
>>>       /* Set crop */
>>> @@ -1067,8 +1085,9 @@ static int dcmi_set_fmt(struct stm32_dcmi 
>>> *dcmi, struct v4l2_format *f)
>>>       if (ret)
>>>           return ret;
>>> -    /* Disable crop if JPEG is requested */
>>> -    if (pix->pixelformat == V4L2_PIX_FMT_JPEG)
>>> +    /* Disable crop if JPEG is requested or BT656 bus is selected */
>>> +    if (pix->pixelformat == V4L2_PIX_FMT_JPEG &&
>>> +        dcmi->bus_type != V4L2_MBUS_BT656)
>>>           dcmi->do_crop = false;
>>>       /* pix to mbus format */
>>> @@ -1592,6 +1611,11 @@ static int dcmi_formats_init(struct stm32_dcmi 
>>> *dcmi)
>>>               if (dcmi_formats[i].mbus_code != mbus_code.code)
>>>                   continue;
>>> +            /* Exclude JPEG if BT656 bus is selected */
>>> +            if (dcmi_formats[i].fourcc == V4L2_PIX_FMT_JPEG &&
>>> +                dcmi->bus_type == V4L2_MBUS_BT656)
>>> +                continue;
>>> +
>>>               /* Code supported, have we got this fourcc yet? */
>>>               for (j = 0; j < num_fmts; j++)
>>>                   if (sd_fmts[j]->fourcc ==
>>> @@ -1873,9 +1897,18 @@ static int dcmi_probe(struct platform_device 
>>> *pdev)
>>>           dev_err(&pdev->dev, "CSI bus not supported\n");
>>>           return -ENODEV;
>>>       }
>>> +
>>> +    if (ep.bus_type == V4L2_MBUS_BT656 &&
>>> +        ep.bus.parallel.bus_width != 8) {
>>> +        dev_err(&pdev->dev, "BT656 bus conflicts with %d bits bus 
>>> width (8 bits required)\n",
>>> +            ep.bus.parallel.bus_width);
>>
>> bus_width is unsigned here.
> I will fix it.
> 
>>
>>> +        return -ENODEV;
>>> +    }
>>> +
>>>       dcmi->bus.flags = ep.bus.parallel.flags;
>>>       dcmi->bus.bus_width = ep.bus.parallel.bus_width;
>>>       dcmi->bus.data_shift = ep.bus.parallel.data_shift;
>>> +    dcmi->bus_type = ep.bus_type;
>>>       irq = platform_get_irq(pdev, 0);
>>>       if (irq <= 0)
>>
> 
> BR,
> Hugues.

BR,
Hugues.

      reply	other threads:[~2020-10-19 10:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 16:14 Hugues Fruchet
2020-10-13  9:07 ` Sakari Ailus
2020-10-15 15:41   ` Hugues FRUCHET
2020-10-19 10:19     ` Hugues FRUCHET [this message]

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=254e2f2e-94ca-2421-1a1b-bcd43a75b847@st.com \
    --to=hugues.fruchet@st.com \
    --cc=alain.volmat@st.com \
    --cc=alexandre.torgue@st.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mchehab@kernel.org \
    --cc=philippe.cornu@st.com \
    --cc=sakari.ailus@iki.fi \
    --cc=yannick.fertre@st.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

all inboxes | Powered by JetHome®