From: Luca Ceresoli <luca@lucaceresoli.net>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Vishal Sagar <vishal.sagar@xilinx.com>,
Hyun Kwon <hyunk@xilinx.com>,
mchehab@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com,
Michal Simek <michals@xilinx.com>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
hans.verkuil@cisco.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Dinesh Kumar <dineshk@xilinx.com>,
Sandip Kothari <sandipk@xilinx.com>,
Jacopo Mondi <jacopo@jmondi.org>,
Hyun Kwon <hyun.kwon@xilinx.com>
Subject: Re: [PATCH v11 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver
Date: Tue, 21 Apr 2020 09:45:56 +0200 [thread overview]
Message-ID: <0a3ea86b-cb4c-a1db-664e-cfa555d8ccf8@lucaceresoli.net> (raw)
In-Reply-To: <20200420195714.GB8195@pendragon.ideasonboard.com>
Hi Laurent,
On 20/04/20 21:57, Laurent Pinchart wrote:
> Hi Luca,
>
> On Mon, Apr 20, 2020 at 09:24:25PM +0200, Luca Ceresoli wrote:
>> On 19/04/20 20:02, Laurent Pinchart wrote:
>> [...]
>>>> +static irqreturn_t xcsi2rxss_irq_handler(int irq, void *dev_id)
>>>> +{
>>>> + struct xcsi2rxss_state *state = (struct xcsi2rxss_state *)dev_id;
>>>> + struct xcsi2rxss_core *core = &state->core;
>>>> + u32 status;
>>>> +
>>>> + status = xcsi2rxss_read(core, XCSI_ISR_OFFSET) & XCSI_ISR_ALLINTR_MASK;
>>>> + dev_dbg_ratelimited(core->dev, "interrupt status = 0x%08x\n", status);
>>>
>>> As this is expected to occur for every frame, I would drop the message,
>>> even if rate-limited.
>>>
>>>> +
>>>> + if (!status)
>>>> + return IRQ_NONE;
>>>> +
>>>> + /* Received a short packet */
>>>> + if (status & XCSI_ISR_SPFIFONE) {
>>>> + dev_dbg_ratelimited(core->dev, "Short packet = 0x%08x\n",
>>>> + xcsi2rxss_read(core, XCSI_SPKTR_OFFSET));
>>>> + }
>>>
>>> Same here, this will occur all the time, I'd remove this message. You
>>> need to read XCSI_SPKTR_OFFSET though, and you should do so in a loop
>>> until the XCSI_CSR_SPFIFONE in XCSI_CSR_OFFSET is cleared in case
>>> multiple short packets are received before the interrupt handler
>>> executes.
>>>
>>> I also wonder if it would make sense to extract the frame number from
>>> the FS short packet, and make it available through the subdev API. I
>>> think it should be reported through a V4L2_EVENT_FRAME_SYNC event. This
>>> can be implemented later.
>>>
>>>> +
>>>> + /* Short packet FIFO overflow */
>>>> + if (status & XCSI_ISR_SPFIFOF)
>>>> + dev_dbg_ratelimited(core->dev, "Short packet FIFO overflowed\n");
>>>> +
>>>> + /*
>>>> + * Stream line buffer full
>>>> + * This means there is a backpressure from downstream IP
>>>> + */
>>>> + if (status & XCSI_ISR_SLBF) {
>>>> + dev_alert_ratelimited(core->dev, "Stream Line Buffer Full!\n");
>>>> + xcsi2rxss_stop_stream(state);
>>>> + if (core->rst_gpio) {
>>>> + gpiod_set_value(core->rst_gpio, 1);
>>>> + /* minimum 40 dphy_clk_200M cycles */
>>>> + ndelay(250);
>>>> + gpiod_set_value(core->rst_gpio, 0);
>>>> + }
>>>
>>> I don't think you should stop the core here. xcsi2rxss_stop_stream()
>>> calls the source .s_stream(0) operation, which usually involves I2C
>>> writes that will sleep.
>>>
>>> You should instead report an event to userspace (it looks like we have
>>> no error event defined in V4L2, one should be added), and rely on the
>>> normal stop procedure.
>>
>> FWIW, since a long time I've been using a modified version of this
>> routine, where after a Stream Line Buffer Full condition I just stop and
>> restart the csi2rx core and the stream continues after a minimal glitch.
>> Other subdev are unaware that anything has happened and keep on streaming.
>>
>> Not sure this is the correct thing to do, but it's working for me. Also
>> I proposed this topic in one of the previous iterations of this patch,
>> but the situation was different because the stream on/off was not
>> propagated back at that time.
>
> Thanks for the feedback. How often does this occur in practice ?
Quite often indeed in my case, as the MIPI stream comes from a remote
sensor via a video serdes chipset, and both the cable and the remote
sensor module are subject to heavy EMI. Depending on the setup I
observed SLBF happening up to 5~10 times per hour.
--
Luca
next prev parent reply other threads:[~2020-04-21 7:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 19:44 [PATCH v11 0/2] Add support for Xilinx CSI2 Receiver Subsystem Vishal Sagar
2020-04-09 19:44 ` [PATCH v11 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem Vishal Sagar
2020-04-19 15:43 ` Laurent Pinchart
2020-04-19 15:45 ` Laurent Pinchart
2020-04-20 18:02 ` Vishal Sagar
2020-04-09 19:44 ` [PATCH v11 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver Vishal Sagar
2020-04-19 18:02 ` Laurent Pinchart
2020-04-20 18:03 ` Vishal Sagar
2020-04-20 19:24 ` Luca Ceresoli
2020-04-20 19:57 ` Laurent Pinchart
2020-04-21 7:45 ` Luca Ceresoli [this message]
2020-04-21 8:38 ` Laurent Pinchart
2020-04-21 9:53 ` Luca Ceresoli
2020-04-21 8:45 ` Vishal Sagar
2020-04-21 10:29 ` Luca Ceresoli
2020-04-21 11:39 ` Vishal Sagar
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=0a3ea86b-cb4c-a1db-664e-cfa555d8ccf8@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--cc=devicetree@vger.kernel.org \
--cc=dineshk@xilinx.com \
--cc=hans.verkuil@cisco.com \
--cc=hyun.kwon@xilinx.com \
--cc=hyunk@xilinx.com \
--cc=jacopo@jmondi.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=michals@xilinx.com \
--cc=robh+dt@kernel.org \
--cc=sandipk@xilinx.com \
--cc=vishal.sagar@xilinx.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).