Hi Adam,
Adding Steve and Philipp in case they can help.
On Tue, Oct 15, 2019 at 1:52 AM Adam Ford wrote:
>
> I have an i.MX6Q with an ov5640 connected to the mipi-csi2 interface.
>
> I am routing ov5640 -> ipu1_csi0_mux -> ip1_csi0 -> ip1_csi0 capture.
>
> I am trying to go through the steps to
Hi Steve,
On Wed, Oct 16, 2019 at 4:11 PM Steve Longerbeam wrote:
> FIM is available on the above nodes (/dev/video0 and /dev/video3), after
> enabling links to them. So please try:
>
> # media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> # v4l2-ctl -d0 --list-ctrls
>
> # media-ctl -l "
On Wed, Oct 16, 2019 at 2:31 PM Steve Longerbeam wrote:
> If /dev/video2 is the "ipu1_ic_prpvf capture" node, it's because FIM is
> not yet available on those nodes. The FIM is only available on the
> "ipuX_csiY capture" nodes. It's on my plate to fix that.
On a 5.3.6 kernel on imx6dl-sabreauto:
Hi Steve,
On Tue, Oct 15, 2019 at 10:18 PM Steve Longerbeam wrote:
> Here's a quick example that uses the end-of-frame method to measure fi's
> (all other FIM controls are left at the default values):
>
> v4l2-ctl -d0 --set-ctrl=fim_enable=1
> # disable input capture method
> v4l2-ctl -d0 --set-
Hi Steve,
On Tue, Oct 15, 2019 at 10:18 PM Steve Longerbeam wrote:
> Here's a quick example that uses the end-of-frame method to measure fi's
> (all other FIM controls are left at the default values):
Excellent! That was what I was looking for. Will test it soon.
> v4l2-ctl -d0 --wait-for-even
Hi Steve,
On Tue, Oct 15, 2019 at 3:19 PM Steve Longerbeam wrote:
> I submitted the ICAP driver patch quite a while ago, it was ~2 yrs ago I
> think. Can't seem to find the link unfortunately.
>
> I'll work on updating the driver and retesting, and try resubmitting again.
>
> Most of the hooks a
On Tue, Oct 15, 2019 at 1:33 PM Tim Harvey wrote:
> Right, because this re-creates the initial issue. Upon any signal lock
> you would need to throw away the first few frames. I wish I knew the
> proper way to deal with this.
I thought this was handled by drivers/staging/media/imx/imx-media-fim.
Hi Tim,
On Tue, Oct 15, 2019 at 1:07 PM Tim Harvey wrote:
>
> Right, I understand there is something else going on with the i.MX53
> but what about the i.MX6 testing related to these patches?
I tested it on a imx6 sabreauto board with 5.3.x kernel plus Steve's
patch that discard the 10 initial c
0021:0 -> ipu1_csi0_mux:4
To avoid confusion, add an entry that shows how to setup the links and
configure the pads that are specific to the i.MX6DL sabrea
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Fix I2C and CSI mux numbering (Steve)
- Passed the v4l2-ctl configuration (Steve)
Documentat
In the i.MX6Q sabreauto pipeline example, it is better to provide
a real example for the output format, so do it just like in the
previous lines for consistency.
Signed-off-by: Fabio Estevam
Acked-by: Steve Longerbeam
---
Changes since v2:
- None
Documentation/media/v4l-drivers/imx.rst | 4
Pass the v4l2-ctl configuration for the imx6q-sabreauto PAL
example for completeness and consistency.
Suggested-by: Steve Longerbeam
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Newly introduced patch
Documentation/media/v4l-drivers/imx.rst | 7 ---
1 file changed, 4 insertions
Improve the documentation by specifying that the instructions
are related to the i.MX6Q sabreauto variant.
This avoids confusion if someone follows these steps on a i.MX6DL
sabreauto, which has different numbering on the I2C bus and
I2C muxes.
Signed-off-by: Fabio Estevam
Acked-by: Steve
Hi Tim,
On Tue, Oct 15, 2019 at 12:49 PM Tim Harvey wrote:
> Fabio,
>
> I assume your seeing the same rolling video issue on capture unless
> you discard the first few 'corrupt' frames? I'm still wondering how we
> can address this properly upstream.
On i.MX53 I still get the rolling video even
On Tue, Oct 15, 2019 at 11:27 AM Fabio Estevam wrote:
> Yes, I can add it.
>
> What is the video device node for "ipu1_ic_prpvf capture" on the imx6q
> sabreauto?
I managed to get access to a imx6q-sabreauto and it's /dev/video2.
Will send a new patch series soon.
Thanks
Hi Steve,
On Mon, Oct 14, 2019 at 2:20 PM Steve Longerbeam wrote:
> should be "'adv7180 4-0021:0".
Will fix it.
> should be "'ipu1_csi0_mux':5".
Will fix it.
> > + media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x576]"
> > + media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x576 field:none]"
> > +
0021:0 -> ipu1_csi0_mux:4
To avoid confusion, add an entry that shows how to setup the links and
configure the pads that are specific to the i.MX6DL sabreauto.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Add a new entry for the mx6dl sabreauto
Documentation/media/v4l-drivers/imx
Improve the documentation by specifying that the instructions
are related to the i.MX6Q sabreauto variant.
This avoids confusion if someone follows these steps on a i.MX6DL
sabreauto, which has different numbering on the I2C bus and
I2C muxes.
Signed-off-by: Fabio Estevam
---
Changes since v1
In the i.MX6Q sabreauto pipeline example, it is better to provide
a real example for the output format, so do it just like in the
previous lines for consistency.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Make this change as part of a single patch
Documentation/media/v4l-drivers
Hi Steve,
On Sat, Oct 12, 2019 at 5:24 PM Steve Longerbeam wrote:
> Ah, now I remember. You are using the imx6dl sabreauto, it's IPU-CSI
Yes, correct. I am using the imx6dl-sabreauto.
> video muxes have five input pads for each of the four MIPI CSI-2 virtual
> channels (pads 0 - 3) and one par
re certain that the adv7180 is
really present and probed.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Only print the "chip found" message on successful probe
drivers/media/i2c/adv7180.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c
ly present.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Remove an extra "found" word from commit log.
- Add "have been successfully "
drivers/media/i2c/adv7180.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/dri
t.
Signed-off-by: Fabio Estevam
---
drivers/media/i2c/adv7180.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index e780969cc2f2..15fe65a2863d 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c
3] imx-media: adv7180 4-0021:0 -> ipu1_csi0_mux:4
Update the instructions accordingly.
Also, in the last line pass the fmt field explicitly as done in the
previous lines.
Signed-off-by: Fabio Estevam
---
Documentation/media/v4l-drivers/imx.rst | 18 +-
1 file changed, 9 inserti
Hi Tim,
On Tue, Oct 8, 2019 at 6:01 PM Tim Harvey wrote:
> Ok that's strange indeed. I did recently test 5.3 on a Gateworks IMX6
> board with ADV7180 and the one patch to drop the first few frames and
> its stable. What does your testing show on an IMX6 and do you know
I will give it a try on a
Hi Tim,
On Tue, Oct 8, 2019 at 1:55 PM Tim Harvey wrote:
> I still carry around a patch from Steve for imx-csi that drops first
> few frames from BT656 sources:
> https://github.com/Gateworks/linux-imx6/commit/959fbd42ee6433f49ef4a04fb1abe8f8c78db5ad
> to deal with this.
Tried this patch and no
On Mon, Oct 7, 2019 at 10:07 PM Fabio Estevam wrote:
> So now I need to see if I can get Gstreamer to accept a pipeline like:
>
> gst-lauch-1.0 v4l2src ! kmssink
Ok, so now I decided use the hardware video deinterlacer:
media-ctl -l "'adv7180 1-0021':0 -> &#x
On Mon, Oct 7, 2019 at 10:07 PM Fabio Estevam wrote:
>
> On Mon, Oct 7, 2019 at 9:51 PM Steve Longerbeam wrote:
>
> > Ah progress. Try:
> >
> > v4l2-ctl -d0 --set-fmt-video=field=interlaced
>
> Yes, with this hint I can run:
>
> # v4l2-ctl -d0 --set-
On Mon, Oct 7, 2019 at 9:51 PM Steve Longerbeam wrote:
> Ah progress. Try:
>
> v4l2-ctl -d0 --set-fmt-video=field=interlaced
Yes, with this hint I can run:
# v4l2-ctl -d0 --set-fmt-video=field=interlaced
# v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=x.raw --stream-count=1
And it se
Hi Steve,
On Mon, Oct 7, 2019 at 9:37 PM Steve Longerbeam wrote:
> The adv7180 driver in 5.3.x doesn't support seq-bt, only alternate. So
> pad format should be "[fmt:UYVY2X8/720x240 field:alternate]".
Thanks for the suggestion. After changing to field:alternate I get:
# gst-launch-1.0 v4l2src
s to add the ADV7180 are listed here:
http://code.bulix.org/ez8yax-901750
Am I calling the correct media-ctl commands?
Any ideas, please?
Thanks,
Fabio Estevam
1[1]"
Unable to parse link: Invalid argument (22)
While at it, provide the "media-ctl -p" output from 5.2 kernel
version, so that users can see a more updated output.
Fixes: fa88fbdafb4a ("media: imx7.rst: add documentation for i.MX7 media
driver")
Signed-off-by: Fabio Esteva
On Wed, Jul 31, 2019 at 1:34 PM Sébastien Szymanski
wrote:
>
> Document "fsl,imx6ul-csi" entry.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Sébastien Szymanski
Reviewed-by: Fabio Estevam
On Wed, Jul 31, 2019 at 1:33 PM Sébastien Szymanski
wrote:
>
> i.MX7 and i.MX6UL/L have the same CSI controller. So add i.MX6UL/L support
> to imx7-media-csi driver.
>
> Signed-off-by: Sébastien Szymanski
Reviewed-by: Fabio Estevam
Hi Sakari,
On Thu, Jul 25, 2019 at 8:17 AM Sakari Ailus wrote:
> Fabio: could you address the issue?
Yes, I have sent a v2 that addresses the issue.
Regards,
Fabio Estevam
Hi Mauro,
On Thu, Jul 25, 2019 at 7:41 AM Mauro Carvalho Chehab
wrote:
> Did you check the "make htmldocs" output after this change?
>
> This code-block is broken, as it starts from column 1.
>
> Please add a tab (or at least 2 spaces) before each line, in order
> to make Sphinx process this cod
[Adding Steve and Philipp]
On Thu, Jul 18, 2019 at 10:06 AM Laura Nao wrote:
>
> Hello Loic,
>
> I'm having some issues with RAW8 mode on the OV5640 camera and I'd like
> to kindly ask for your advice, as I saw that you added support for RAW
> mode in the mainline kernel driver.
>
> I'm trying to
Hi Todor,
On Mon, Jul 1, 2019 at 6:29 PM Todor Tomov wrote:
> Thank you for the patch.
> The question about using the regulator_bulk API seems to come
> regularly from time to time.
> This has been discussed on [1] and I believe the conclusion has been
> that the regulator_bulk API doesn't guara
Hi Philipp,
On Thu, Jul 4, 2019 at 6:34 AM Philipp Zabel wrote:
> Could this just be added to the end of ov5645_global_init_setting?
Just tested your suggestion and it also works.
Thanks
in non-continuous mode.
> - At set_power(0) time power down MIPI Tx/Rx (in addition to the current
> power down of regulators and clock gating).
> - At s_stream time enable/disable the MIPI interface output.
>
> With this commit the sensor is able to enter LP-11 mode during power up,
1[1]"
Unable to parse link: Invalid argument (22)
While at it, provide the "media-ctl -p" output from 5.2 kernel
version, so that users can see a more updated output.
Fixes: fa88fbdafb4a ("media: imx7.rst: add documentation for i.MX7 media
driver")
Signed-o
-mux", so I needed to change it to:
media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi-mux':1[1]"
and then I see no errors after the media-ctl command.
I will send a patch fixing Documentation/media/v4l-drivers/imx7.rst .
Thanks,
Fabio Estevam
Hi Rui,
On Fri, Jun 28, 2019 at 7:03 PM Fabio Estevam wrote:
> The first command succeeds, but the second one fails:
>
> # media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi_mux':1[1]"
> Unable to parse link: Invalid argument (22)
I have also tested it on a
;csi':1 -> 'csi capture':0[1]"
The first command succeeds, but the second one fails:
# media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi_mux':1[1]"
Unable to parse link: Invalid argument (22)
Any ideas, please?
Thanks,
Fabio Estevam
-by: Fabio Estevam
---
drivers/media/i2c/ov5640.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index afe7920557a8..4cd246812ae2 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -158,8 +158,8
The power down and reset GPIO are optional, but the return value
from devm_gpiod_get_optional() needs to be checked and propagated
in the case of error, so that probe deferral can work.
Signed-off-by: Fabio Estevam
---
drivers/media/i2c/ov5640.c | 5 +
1 file changed, 5 insertions(+)
diff
ter explain the problem and provide
a hint that the sensor driver needs to be fixed.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Reduce the warning message (Steve)
Changes since v1:
- Changed the warning message to better explain the problem and provide
On Thu, Jun 27, 2019 at 3:45 PM Ezequiel Garcia wrote:
> I think Philipp's suggestions looks very good, both the text and keeping
> the phy state. I think both should be kept in the warning.
>
> Fabio: feel free to submit a v2, or let me know so I'll add it to my TODO.
I have just sent a v2 with
ter explain the problem and provide
a hint that the sensor driver needs to be fixed.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Changed the warning message to better explain the problem and provide
a hint that the sensor driver needs to be fixed. (Phillip)
Hi Sakari,
On Thu, Jun 27, 2019 at 1:27 PM Sakari Ailus wrote:
> This appears to change the order in which the regulators are enabled. Is
> that intentional? Does the sensor support this order as well?
Good catch! I have sent a v2 that preserves the regulator enable order.
Thanks
There is no need to call regulator_set_voltage() for each regulator
that powers the camera.
The voltage value for each regulator should be retrieved from the
device tree, so remove the unneeded regulator_set_voltage().
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None
drivers/media
The code can be simplified by using the regulator_bulk() functions,
so switch to it.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Retain the regulator enable ordering (Sakari)
drivers/media/i2c/ov5645.c | 94 +-
1 file changed, 21 insertions(+), 73
Hi Philipp,
On Thu, Jun 27, 2019 at 5:43 AM Philipp Zabel wrote:
> Are there any visual artifacts in the first frame(s) in this case?
I do not observe visual artifacts when running gst-launch-1.0 v4l2src ! kmssink
> > So in my opinion the next version of this patch should make LP-11
> > timeou
The code can be simplified by using the regulator_bulk() functions,
so switch to it.
Signed-off-by: Fabio Estevam
---
drivers/media/i2c/ov5645.c | 94 +-
1 file changed, 21 insertions(+), 73 deletions(-)
diff --git a/drivers/media/i2c/ov5645.c b/drivers
There is no need to call regulator_set_voltage() for each regulator
that powers the camera.
The voltage value for each regulator should be retrieved from the
device tree, so remove the unneeded regulator_set_voltage().
Signed-off-by: Fabio Estevam
---
drivers/media/i2c/ov5645.c | 28
Hi Steve,
On Wed, Jun 26, 2019 at 6:19 PM Steve Longerbeam wrote:
> Did you only get the LP-11 timeout warning message with this patch on
> the OV5645, or both the LP-11 timeout and clock lane timeout warnings?
With this patch applied I get only the LP-11 timeout warnings, not
clock lane timeou
s patch I could successfully test camera capture on a
imx6dl-wandboard connected to a OV5645.
Without this patch the Gsteamer pipeline fails.
Tested-by: Fabio Estevam
): undefined reference to `ipu_get_num'
All these definitions come from the imx ipu3 core driver, so make
sure that imx media depends on IMX_IPUV3_CORE.
This reverts commit 020bc7354a6ebec980e0aedf5bedf57b42f93aca.
Reported-by: Randy Dunlap
Signed-off-by: Fabio Estevam
---
drivers/staging/me
Use devm_platform_ioremap_resource() to simplify the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/media/platform/coda/coda-common.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda
In case of ioremap failure, the core code will take care of printing
the error message, so there is no need for having a local error
message in the driver.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
Currently there is a macro for reading and another macro for writing
to the CSI registers.
Functions can do parameter type checking, which leads to a safer code,
so switch from macro to function implementation.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 14
The CSI registers are 32-bit, so using u32 type is more suitable
for storing the values from register reads.
Switch from 'unsigned long' to 'u32' type.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 26 +++---
1 file changed,
Checkpatch reports an extra blank line, so remove such unneeded
line.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-mipi-csis.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c
b/drivers/staging/media/imx/imx7-mipi-csis.c
index
There is no need for initializing the 'ret' variable as it will
be assigned at:
ret = mipi_csis_parse_dt(pdev, state);
Remove the unneeded initialization.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-mipi-csis.c | 2 +-
1 file changed, 1 insertion(+),
Currently the return value from clk_bulk_prepare_enable() is checked,
but it is not propagate it in the case of failure.
Fix it and also move the error message to the caller of
mipi_csis_clk_enable().
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-mipi-csis.c | 14
Hi Sven,
[Addin Robin]
On Thu, May 30, 2019 at 6:34 PM Sven Van Asbroeck wrote:
> Unfortunately I cannot load any imx-sdma firmware on the latest mainline
> kernel. Right after the firmware is loaded, reads seem to get corrupted
> and the whole kernel crashes / hangs.
>
> I am currently bisecti
Hi Sven,
On Wed, May 29, 2019 at 5:55 PM Sven Van Asbroeck wrote:
> I am now running 5.2-rc2 with Philipp's non-plus imx6q patch.
>
> Performance is still much worse than the Freescale baseline.
>
> I am not at all worried about vpu scaler performance, after all v8 is an
> in-progress patch.
>
>
Hi Sven,
On Wed, May 29, 2019 at 12:45 PM Sven Van Asbroeck wrote:
>
> Thank you all (and especially Philipp) for this amazing work !
>
> One of the main uses for the VPU scaler is to convert from video file
> resolution to display resolution. E.g. the source video is 1080p, but the
> display vid
Hi Rob,
On Sat, May 4, 2019 at 11:40 AM Fabio Estevam wrote:
>
> As per the i.MX7D Reference Manual only the MCLK is used for
> the CSI block, so only document this single clock.
>
> Signed-off-by: Fabio Estevam
> ---
> Documentation/devicetree/bindings/media/imx7-csi.t
As per the i.MX7D Reference Manual only the MCLK is used for
the CSI block, so only document this single clock.
Signed-off-by: Fabio Estevam
---
Documentation/devicetree/bindings/media/imx7-csi.txt | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation
clk_prepare_enable() may fail, so we should better check its return value
and propagate it in the case of error.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media
imx7_csi_enable() always return 0 and its return value is never checked,
so convert it to void.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/staging/media/imx/imx7-media-csi.c
b
Use devm_platform_ioremap_resource() to simplify the code a bit.
While at it, propagate the real error value in case of
devm_platform_ioremap_resource() failure.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 8 +++-
1 file changed, 3 insertions(+), 5
As per the i.MX7D Reference Manual only the MCLK is used for
the CSI block, so only handle this single clock.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 51 --
1 file changed, 8 insertions(+), 43 deletions(-)
diff --git a/drivers/staging
Remove unneeded 'break' right after the 'return' statement as
pointed out by checkpatch.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/imx/imx7-media-csi.c
b/drivers/st
In the case of platform_get_irq() failure, let's propagate the real error
code instead of a fake one.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/imx/imx7-media-csi
In the case of devm_request_irq() failure, let's propagate the real error
code instead of a fake one.
Signed-off-by: Fabio Estevam
---
drivers/staging/media/imx/imx7-media-csi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/imx/imx7-media-csi.c
b/drivers/st
Hi Rui,
On Fri, Dec 7, 2018 at 10:44 AM Hans Verkuil wrote:
> I got a few checkpatch warnings about coding style:
>
> CHECK: Alignment should match open parenthesis
> #953: FILE: drivers/staging/media/imx/imx7-media-csi.c:911:
> +static struct v4l2_mbus_framefmt *imx7_csi_get_format(struct imx7_
imx-ipuv3 280.ipu: driver could not parse
port@0/endpoint@0 (-22)
[3.472120] imx-ipuv3-csi: probe of imx-ipuv3-csi.4 failed with error -22
Tested-by: Fabio Estevam
Hi Steve,
On Thu, Jan 17, 2019 at 6:15 PM Steve Longerbeam wrote:
>
> Disable the CSI immediately after receiving the last EOF before stream
> off (and thus before disabling the IDMA channel).
>
> This fixes a complete system hard lockup on the SabreAuto when streaming
> from the ADV7180, by repe
Hi Steve,
On Fri, Nov 23, 2018 at 8:37 PM Steve Longerbeam wrote:
> Yes, this is a regression caused by the imx subdev notifier patches.
> I've already sent a patch to the list for this, see
>
> https://www.spinics.net/lists/linux-media/msg141809.html
Thanks, this fixes it.
Hopefully it will b
Hi Sakari,
On Fri, Nov 23, 2018 at 10:35 AM Sakari Ailus
wrote:
> Makes sense. This is not necessarily a fatal error. Could you send a patch?
Yes, I have just sent it.
Thanks
debug level and make the wording a bit
less misleading.
Suggested-by: Philipp Zabel
Signed-off-by: Fabio Estevam
---
drivers/media/v4l2-core/v4l2-fwnode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
b/drivers/media/v4l2-core/v4l2-fwnode
Hi Philipp,
On Thu, Nov 22, 2018 at 2:27 PM Philipp Zabel wrote:
> There are empty endpoint nodes (without remote-endpoint property)
> labeled ipu1_csi[01]_mux_from_parallel_sensor in the i.MX6 device trees
> for board DT implementers' convenience. See commit 2539f517acbdc ("ARM:
> dts: imx6qdl:
Hi Sakari,
On Tue, Nov 20, 2018 at 10:15 AM Sakari Ailus
wrote:
> Where's the DT source for the board?
Board dts is arch/arm/boot/dts/imx6qdl-wandboard.dtsi
SoC dtsi is arch/arm/boot/dts/imx6q.dtsi
Also, since 4.20-rc the following errors are seen:
[3.449564] imx-ipuv3 240.ipu: drive
from happening?
Thanks,
Fabio Estevam
Hi Hans,
On Tue, Nov 13, 2018 at 11:37 AM Hans Verkuil wrote:
>
> On 11/13/18 13:48, Fabio Estevam wrote:
> > On Tue, Nov 13, 2018 at 6:25 AM Maxime Ripard
> > wrote:
> >
> >> --- /dev/null
> >> +++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_
On Tue, Nov 13, 2018 at 6:25 AM Maxime Ripard wrote:
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
> @@ -0,0 +1,275 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
According to Documentation/process/license-rules.rst this should be:
+// SPDX-License-Identifier: G
pxp_soft_reset() may fail with a timeout, so it is better to propagate
the error in this case.
Signed-off-by: Fabio Estevam
Reviewed-by: Philipp Zabel
---
Changes since v2:
- Jump to err_clck when pxp_soft_reset() fails. (Philipp)
drivers/media/platform/imx-pxp.c | 12 +---
1 file
clk_prepare_enable() may fail, so we should better check its return value
and propagate it in the case of error.
Signed-off-by: Fabio Estevam
Reviewed-by: Philipp Zabel
---
Changes since v2:
- None
drivers/media/platform/imx-pxp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion
Improve the pxp_soft_reset() error message by moving it to the
caller function, associating it with a proper device and also
by displaying the error code.
Signed-off-by: Fabio Estevam
Reviewed-by: Philipp Zabel
---
Changes since v2:
- None (only rebased against the change made in 2/3)
drivers
clk_prepare_enable() may fail, so we should better check its return value
and propagate it in the case of error.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Properly enumerate the series
drivers/media/platform/imx-pxp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
pxp_soft_reset() may fail with a timeout, so it is better to propagate
the error in this case.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None
drivers/media/platform/imx-pxp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/imx
Improve the pxp_soft_reset() error message by moving it to the
caller function, associating it with a proper device and also
by displaying the error code.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Newly introduced in this version
drivers/media/platform/imx-pxp.c | 8
1 file
pxp_soft_reset() may fail with a timeout, so it is better to propagate
the error in this case.
Signed-off-by: Fabio Estevam
---
drivers/media/platform/imx-pxp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/imx-pxp.c b/drivers/media
clk_prepare_enable() may fail, so we should better check its return value
and propagate it in the case of error.
Signed-off-by: Fabio Estevam
---
drivers/media/platform/imx-pxp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/imx-pxp.c b/drivers
Hi Adam,
On Sun, Oct 28, 2018 at 3:58 PM Adam Ford wrote:
> Does anyone know when the media branch get's merged into the mainline
> kernel? I assume we're in the merge window with 4.19 just having been
> released. Once these have been merged into the mainline, I'll go
> through and start reque
Hi Adam,
On Mon, Oct 22, 2018 at 9:37 AM Adam Ford wrote:
> Thank you! This tutorial web site is exactly what I need. The
> documentation page in Linux touched on the media-ctl links, but it
> didn't explain the syntax or the mapping. This graphical
> interpretation really helps it make more
Hi Philipp,
On Wed, Sep 5, 2018 at 7:00 AM, Philipp Zabel wrote:
> index ..2f90c692f3fe
> --- /dev/null
> +++ b/drivers/media/platform/imx-pxp.c
> @@ -0,0 +1,1774 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
The recommended SPDX format in this case is:
// SPDX-License-Identif
Hi Rui,
On Tue, May 8, 2018 at 10:52 AM, Rui Miguel Silva wrote:
> So, my understand is that the patches will be applied or are already
> applied to someone tree (strange patchwork does not send who or which
> tree), but since I do not want to break someone workflow I will wait for
> some mainta
Hi Rui,
On Mon, May 7, 2018 at 12:56 PM, Rui Miguel Silva wrote:
> Sorry I have Out-of-Office some part of last week, I had v6 of the original
> series ready but since I have received the notification from patchwork that
> the
> v5 was accepted, I am sending this as a follow up tha address Fabio
1 - 100 of 335 matches
Mail list logo
