On Thu, Sep 28, 2023 at 01:36:06AM +0200, Ben Hutchings wrote:
> On Wed, 2023-09-20 at 13:30 +0200, Greg Kroah-Hartman wrote:
> > 4.19-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Greg Kroah-Hartman
> >
> > commit 86495af1171e1
On Wed, 2023-09-20 at 13:30 +0200, Greg Kroah-Hartman wrote:
> 4.19-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Greg Kroah-Hartman
>
> commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
>
> In commit 9011e49d54dc ("modules: on
Hi!
> > I'm skeptical about adding now a property for a device that we don't
> > support, because we -now- think it's a good idea. I might be wrong,
> > but my assumption is that when someone will want to support an
> > 'advanced' device, it's easy to add "movable" or whatever else to the
> > list
Hi Jean,
On Wed, Oct 23, 2019 at 03:18:59PM +0200, Jean Delvare wrote:
> Hi all,
>
> When my Logitech C270 webcam is plugged in, my kernel log gets filled
> with this message:
>
> usb 3-4.1: reset high-speed USB device number 4 using xhci_hcd
>
> every 5 seconds. I have the same problem on 3 di
On Sun, Oct 20, 2019 at 2:16 PM Adam Ford wrote:
>
> On Sun, Oct 20, 2019 at 1:02 PM Laurent Pinchart
> wrote:
> >
> > Hi Adam,
> >
> > On Sun, Oct 20, 2019 at 09:45:25AM -0500, Adam Ford wrote:
> > > I am running a DM3730 connected to an mt9p031 sensor, and the ISP is
> > > running in 8-bit para
Hi Sakari,
On 19-10-23 13:57, Sakari Ailus wrote:
> Hi Marco,
>
> Apologies for the delay.
No problem.
> On Wed, Oct 02, 2019 at 10:07:35AM +0200, Marco Felsch wrote:
> > Hi Sakari,
> >
> > On 19-10-02 10:03, Sakari Ailus wrote:
> > > Hi Marco,
> > >
> > > On Fri, Aug 30, 2019 at 12:16:35PM +
Hi Marco,
Apologies for the delay.
On Wed, Oct 02, 2019 at 10:07:35AM +0200, Marco Felsch wrote:
> Hi Sakari,
>
> On 19-10-02 10:03, Sakari Ailus wrote:
> > Hi Marco,
> >
> > On Fri, Aug 30, 2019 at 12:16:35PM +0200, Marco Felsch wrote:
> > > The patch adds the initial connector parsing code, s
Hi Hans,
On 2019-10-23 09:01:40 +0200, Hans Verkuil wrote:
> Hi Niklas,
>
> For one reason or another this series was never reviewed/picked up and
> it now no longer applies.
>
> Combined with the big switch to a monolithic driver I am sure that this
> series needs to be redone. So I am marking
Hi Bingbu,
On Tue, Oct 08, 2019 at 12:21:27PM +0800, bingbu@intel.com wrote:
> From: Bingbu Cao
>
> This patch add more details for the resolution change blocks
> It can help the developer to understand the main resolution
> change blocks in ImgU.
>
> Signed-off-by: Bingbu Cao
Applied wit
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59601/
Build log: https://builder.linuxtv.org/job/patchwork/21656/
Build time: 00:11:57
Link:
https://lore.kernel.org/linux-media/a4f86608-3ad9-a57b-e399-ed3f1078a...@xs4all.nl
gpg: Signature made Wed 23 Oct 2019 07:37:5
On 10/9/19 5:53 PM, Dafna Hirschfeld wrote:
> Userspace can disable links and create pipelines that
> do not start with a source entity. Trying to stream
> from such a pipeline should fail with -EPIPE
> currently this is not handled and cause kernel crash.
>
> Reproducing the crash:
> media-ctl -d
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59600/
Build log: https://builder.linuxtv.org/job/patchwork/21648/
Build time: 00:15:41
Link:
https://lore.kernel.org/linux-media/860a9d97-7b8c-abc1-670d-57ea24312...@xs4all.nl
gpg: Signature made Wed 23 Oct 2019 06:51:2
Hi Niklas,
For one reason or another this series was never reviewed/picked up and
it now no longer applies.
Combined with the big switch to a monolithic driver I am sure that this
series needs to be redone. So I am marking it as "Changes Requested" and
it is up to you to decide whether to rebase/
On Mon, Oct 21, 2019 at 3:48 AM Philipp Zabel wrote:
>
> Hi Adam, Fabio,
>
> On Fri, 2019-10-18 at 16:00 -0300, Fabio Estevam wrote:
> > 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
On 10/8/19 10:20 AM, Jacopo Mondi wrote:
> On Tue, Oct 08, 2019 at 10:06:34AM +0200, Pavel Machek wrote:
>> On Tue 2019-10-08 09:58:28, Jacopo Mondi wrote:
>>> Pavel,
>>>
>>> On Tue, Oct 08, 2019 at 09:40:52AM +0200, Pavel Machek wrote:
On Mon 2019-10-07 18:29:03, Jacopo Mondi wrote:
> Add
On 10/7/19 6:29 PM, Jacopo Mondi wrote:
> Add documentation for the V4L2_CID_CAMERA_SENSOR_ROTATION camera
> control. The newly added read-only control reports the camera device
> mounting rotation.
>
> Signed-off-by: Jacopo Mondi
> ---
> .../media/uapi/v4l/ext-ctrls-camera.rst | 116 +
Hi Sakari,
gentle ping.
On 19-10-02 10:07, Marco Felsch wrote:
> Hi Sakari,
>
> On 19-10-02 10:03, Sakari Ailus wrote:
> > Hi Marco,
> >
> > On Fri, Aug 30, 2019 at 12:16:35PM +0200, Marco Felsch wrote:
> > > The patch adds the initial connector parsing code, so we can move from a
> > > driver
Ping!
Regards,
Hans
On 10/14/19 11:05 AM, Hans Verkuil wrote:
> Hi Florian, Nick,
>
> You both added V4L2 touch pad drivers to the kernel, but I was wondering
> about userspace support for such devices. Is there a library somewhere that
> can interpret the data?
>
> The only link I fou
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59583/
Build log: https://builder.linuxtv.org/job/patchwork/21404/
Build time: 00:10:03
Link: https://lore.kernel.org/linux-media/20191021141829.ga28...@gofer.mess.org
gpg: Signature made Mon 21 Oct 2019 02:13:15 PM UTC
g
On 10/21/19 11:48 AM, Tomasz Figa wrote:
> On Mon, Oct 21, 2019 at 6:38 PM Hans Verkuil wrote:
>>
>> On 10/21/19 11:26 AM, Tomasz Figa wrote:
>>> On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
On 10/8/19 11:11 AM, Boris Brezillon wrote:
> This is part of the multiplanar and sin
On Mon, Oct 21, 2019 at 6:38 PM Hans Verkuil wrote:
>
> On 10/21/19 11:26 AM, Tomasz Figa wrote:
> > On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
> >>
> >> On 10/8/19 11:11 AM, Boris Brezillon wrote:
> >>> This is part of the multiplanar and singleplanar unification process.
> >>> v4l2_ext
On 10/17/19 1:17 PM, Hans Verkuil wrote:
> Hi all,
>
> Since we have three separate half-day sessions for different topics I decided
> to split the announcement for this in three emails as well, so these things
> can be discussed in separate threads.
>
> All sessions are in room Terreaux VIP Loun
On 10/21/19 11:26 AM, Tomasz Figa wrote:
> On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
>>
>> On 10/8/19 11:11 AM, Boris Brezillon wrote:
>>> This is part of the multiplanar and singleplanar unification process.
>>> v4l2_ext_pix_format is supposed to work for both cases.
>>>
>>> We also add
On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
>
> On 10/8/19 11:11 AM, Boris Brezillon wrote:
> > This is part of the multiplanar and singleplanar unification process.
> > v4l2_ext_pix_format is supposed to work for both cases.
> >
> > We also add the concept of modifiers already employed in
Hi Adam, Fabio,
On Fri, 2019-10-18 at 16:00 -0300, Fabio Estevam wrote:
> 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 -> i
On 10/21/19 10:21 AM, Hans Verkuil wrote:
> On 10/20/19 7:39 PM, Laurent Pinchart wrote:
>> Hi Hans,
>>
>> On Sun, Oct 20, 2019 at 07:26:20PM +0200, Hans Verkuil wrote:
>>> On 10/20/19 7:35 AM, Laurent Pinchart wrote:
On Sat, Oct 19, 2019 at 11:14:03AM -0500, Adam Ford wrote:
> On Fri, Oct
On 10/8/19 11:11 AM, Boris Brezillon wrote:
> This is part of the multiplanar and singleplanar unification process.
> v4l2_ext_pix_format is supposed to work for both cases.
>
> We also add the concept of modifiers already employed in DRM to expose
> HW-specific formats (like tiled or compressed f
ed a better solution than this in
>>> any case. Compared to the last time I made this statement, we now have
>>> one possible solution in view in the form of libcamera ([1]). The
>>> project is still young, doesn't support the OMAP3 ISP, and isn't
>>> in
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59575/
Build log: https://builder.linuxtv.org/job/patchwork/21363/
Build time: 00:05:26
Link:
https://lore.kernel.org/linux-media/20191021072359.gc...@valkosipuli.retiisi.org.uk
gpg: Signature made Mon 21 Oct 2019 07:18:
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59574/
Build log: https://builder.linuxtv.org/job/patchwork/21362/
Build time: 00:15:34
Link:
https://lore.kernel.org/linux-media/20191021071539.gb...@valkosipuli.retiisi.org.uk
gpg: Signature made Mon 21 Oct 2019 07:04:
Hello,
On 10/20/19 5:13 PM, Ezequiel Garcia wrote:
> Hello Hans,
>
> On Thu, 17 Oct 2019 at 13:16, Hans Verkuil wrote:
>>
>> (Just updated the attendee list for this meeting, no other changes)
>>
>> Hi all,
>>
>> Since we have three separate half-day sessions for different topics I decided
>> to
Hi Biju,
Thanks for your work.
On 2019-10-15 11:57:54 +0100, Biju Das wrote:
> This patch series add VIN/CSI-2 driver support for RZ/G2N SoC.
For the whole series,
Reviewed-by: Niklas Söderlund
>
> Biju Das (4):
> media: dt-bindings: rcar-vin: Add R8A774B1 support
> media: dt-bindings: r
Hi Hans,
On Sun, Oct 20, 2019 at 07:26:20PM +0200, Hans Verkuil wrote:
> On 10/20/19 7:35 AM, Laurent Pinchart wrote:
> > Hi Adam,
> >
> > On Sat, Oct 19, 2019 at 11:14:03AM -0500, Adam Ford wrote:
> >> On Fri, Oct 18, 2019 at 4:17 PM Sakari Ailus wrote:
> >>> On Fri, Oct 18, 2019 at 04:10:23PM
Hello Hans,
On Thu, 17 Oct 2019 at 13:16, Hans Verkuil wrote:
>
> (Just updated the attendee list for this meeting, no other changes)
>
> Hi all,
>
> Since we have three separate half-day sessions for different topics I decided
> to split the announcement for this in three emails as well, so thes
On Sun, Oct 20, 2019 at 1:02 PM Laurent Pinchart
wrote:
>
> Hi Adam,
>
> On Sun, Oct 20, 2019 at 09:45:25AM -0500, Adam Ford wrote:
> > I am running a DM3730 connected to an mt9p031 sensor, and the ISP is
> > running in 8-bit parallel mode.
> >
> > I have the sensor endpoint configured as:
> >
> >
ISP, and isn't
> > > integrated with GStreamer, but fixing all that is on our roadmap.
> > >
> > > What I would like to know is whether libcamera would fit your use cases,
> > > or if you have needs that would require a different solution.
> > >
> > > [1]
Hi Adam,
On Sun, Oct 20, 2019 at 09:45:25AM -0500, Adam Ford wrote:
> I am running a DM3730 connected to an mt9p031 sensor, and the ISP is
> running in 8-bit parallel mode.
>
> I have the sensor endpoint configured as:
>
> mt9p031_out: endpoint {
> input-clock-frequency = <2400>;
>
g/
> >
> >>>>> This also means that there is no way to provide an enumeration of
> >>>>> supported
> >>>>> formats without knowing the media bus format. There have been proposals
> >>>>> to
> >>>>
ow, the format needs to be simply set using S_FMT.
>>>>>
>>>>>>
>>>>>> Setting pipeline to PAUSED ...
>>>>>> Pipeline is live and does not need PREROLL ...
>>>>>> Setting pipeline to PLAYING ...
>>>>
peline is live and does not need PREROLL ...
> > >>>> Setting pipeline to PLAYING ...
> > >>>> New clock: GstSystemClock
> > >>>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> > >>>> Internal data stream error.
>
Hi Hans,
Thank you for handling the announcement.
On Thu, Oct 17, 2019 at 01:16:20PM +0200, Hans Verkuil wrote:
> (Just updated the attendee list for this meeting, no other changes)
>
> Hi all,
>
> Since we have three separate half-day sessions for different topics I decided
> to split the anno
:
> >>>> streaming stopped, reason not-negotiated (-4)
> >>>>
> >>>> This leads me to believe that v4l2 is trying to set the format to
> >>>> something it does not think it is able to negotiate, and it's being
> >>>> re
> >
> > > > I can even explicitly set the output video format to UYVY with:
> > > >
> > > > v4l2-ctl -d /dev/video6
> > > > --set-fmt-video=width=480,height=272,pixelformat=UYVY --verbose
> > > >
> > > > VIDIOC_QUERYCAP:
> -Original Message-
> From: Steve Longerbeam
>
> On 10/9/19 8:40 AM, Tim Harvey wrote:
> > On Tue, Oct 8, 2019 at 4:48 PM Fabio Estevam
> wrote:
> >> 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 G
Pixel Format : 'UYVY'
> > > Field : None
> > > Bytes per Line: 960
> > > Size Image: 261120
> > > Colorspace: JPEG
> > > Transfer Function : Default (maps to sRGB)
>
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
> > Quantization : Default (maps to Full Range)
> > Flags :
> > #
> >
> > This shows me the UYVY format, but upon a follow-up query, it does not
> > appear to retain the pixel format of
upon a follow-up query, it does not
> appear to retain the pixel format of UYVY.
>
> v4l2-ctl -d /dev/video6 --list-formats-ext
> ioctl: VIDIOC_ENUM_FMT
> Type: Video Capture
>
> [0]: 'RGB3' (RGB3, emulated)
> [1]: 'BGR3' (BGR3, em
Hi Jacopo,
(Cc'ing the devicetree list.)
On Mon, Oct 07, 2019 at 06:29:03PM +0200, Jacopo Mondi wrote:
> Add the 'location' device property, used to specify a device mounting
> position. The property is particularly meaningful for mobile devices
> with a well defined usage orientation.
>
> Signe
Hi Jacopo,
On Mon, Oct 07, 2019 at 06:29:08PM +0200, Jacopo Mondi wrote:
> Add an helper function to parse common device properties in the same
> way as v4l2_fwnode_endpoint_parse() parses common endpoint properties.
>
> Parse the 'rotation' and 'location' properties from the firmware
> interface
Hi Jacopo,
On Mon, Oct 07, 2019 at 06:29:02PM +0200, Jacopo Mondi wrote:
> Hello, fourth iteration following:
>
> "media: v4l2-ctrls: Add camera sensor location"
> https://patchwork.kernel.org/project/linux-media/list/?series=160901
> "[v2,00/10] media: Report camera sensor properties
> https://p
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
On Fri, Oct 18, 2019 at 05:31:40PM +0200, Janusz Krzysztofik wrote:
> Commit a8fa55078a77 ("media: v4l2-subdev: Verify arguments in
> v4l2_subdev_call()") and commit 374d62e7aa50 ("media: v4l2-subdev:
> Verify v4l2_subdev_call() pad config argument") introduced a few local
> functions, unfortunatel
On 10/18/19 12:20, Seung-Woo Kim wrote:
>>From isp_video_release(), &isp->video_lock is held and subsequent
> vb2_fop_release() tries to lock vdev->lock which is same with the
> previous one. Replace vb2_fop_release() with _vb2_fop_release() to
> fix the recursive locking.
>
> Fixes: 1380f5754cb0
Hi Stanimir,
On Thu, 17 Oct 2019 at 17:47, Stanimir Varbanov
wrote:
>
> Hi Loic,
>
> On 10/17/19 6:08 PM, Loic Poulain wrote:
> > Hi Stanimir,
> >
> > On Thu, 3 Oct 2019 at 12:15, Stanimir Varbanov
> > wrote:
> >>
> >> I have tested this on db410c with following gst pipeline:
> >>
> >> gst-launc
Hi Loic,
On 10/17/19 6:08 PM, Loic Poulain wrote:
> Hi Stanimir,
>
> On Thu, 3 Oct 2019 at 12:15, Stanimir Varbanov
> wrote:
>>
>> I have tested this on db410c with following gst pipeline:
>>
>> gst-launch-1.0 -v videotestsrc !
>> video/x-raw,format=NV12,width=1280,height=960,framerate=24/1 !
>>
Hi Stanimir,
On Thu, 3 Oct 2019 at 12:15, Stanimir Varbanov
wrote:
>
> I have tested this on db410c with following gst pipeline:
>
> gst-launch-1.0 -v videotestsrc !
> video/x-raw,format=NV12,width=1280,height=960,framerate=24/1 !
> v4l2h264enc
> extra-controls="controls,h264_profile=4,h264_level
On 10/17/19 4:46 PM, JP wrote:
Hi there,
On 10/17/19 2:15 PM, Antti Palosaari wrote:
Hello,
On 10/17/19 12:08 PM, Sean Young wrote:
Hi Antti,
I have a Logilink VG0022A device which is an af9035.c type device (with
ITE 9xxx frontned). The probe of the si2146 tuner fails and returns
0xffs.
Hi there,
On 10/17/19 2:15 PM, Antti Palosaari wrote:
Hello,
On 10/17/19 12:08 PM, Sean Young wrote:
Hi Antti,
I have a Logilink VG0022A device which is an af9035.c type device (with
ITE 9xxx frontned). The probe of the si2146 tuner fails and returns
0xffs.
Now I would like to work on fixi
Hello,
On 10/17/19 12:08 PM, Sean Young wrote:
Hi Antti,
I have a Logilink VG0022A device which is an af9035.c type device (with
ITE 9xxx frontned). The probe of the si2146 tuner fails and returns 0xffs.
Now I would like to work on fixing this. Mauro suggested the firmware might
be incorrect.
> > I doubt you can handle pci memory bars like regular ram when it comes to
> > dma and iommu support. There is a reason we have p2pdma in the first
> > place ...
>
> The thing is that such bars would be actually backed by regular host
> RAM. Do we really need the complexity of real PCI bar hand
Hi,
> That could be still a guest physical address. Like on a bare metal
> system with TrustZone, there could be physical memory that is not
> accessible to the CPU.
Hmm. Yes, maybe. We could use the dma address of the (first page of
the) guest buffer. In case of a secure buffer the guest ha
Hi Niklas, Laurent,
On Tue, Oct 15, 2019 at 01:11:07AM +0300, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Mon, Oct 14, 2019 at 02:16:15AM +0200, Niklas Söderlund wrote:
> > Most Gen3 boards can output frames in NV12 format, add support for this
> > with a runtime check
On Thu, Oct 17, 2019 at 4:44 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > Also note that the guest manages the address space, so the host can't
> > > simply allocate guest page addresses.
> >
> > Is this really true? I'm not an expert in this area, but on a bare
> > metal system it's the hardware or
On Thu, Oct 17, 2019 at 4:19 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > That said, Chrome OS would use a similar model, except that we don't
> > use ION. We would likely use minigbm backed by virtio-gpu to allocate
> > appropriate secure buffers for us and then import them to the V4L2
> > driver.
>
>
On Tue, Oct 15, 2019 at 11:06 PM Dmitry Morozov
wrote:
>
> Hello Gerd,
>
> On Dienstag, 15. Oktober 2019 09:54:22 CEST Gerd Hoffmann wrote:
> > On Mon, Oct 14, 2019 at 03:05:03PM +0200, Dmitry Morozov wrote:
> > > On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> > > > Hi,
> > > >
Hi,
> > Also note that the guest manages the address space, so the host can't
> > simply allocate guest page addresses.
>
> Is this really true? I'm not an expert in this area, but on a bare
> metal system it's the hardware or firmware that sets up the various
> physical address allocations on
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59516/
Build log: https://builder.linuxtv.org/job/patchwork/20785/
Build time: 00:21:46
Link:
https://lore.kernel.org/linux-media/1074d944-de6e-7483-3337-ca9acd1b1...@xs4all.nl
gpg: Signature made Thu 17 Oct 2019 06:51:0
Hi,
> That said, Chrome OS would use a similar model, except that we don't
> use ION. We would likely use minigbm backed by virtio-gpu to allocate
> appropriate secure buffers for us and then import them to the V4L2
> driver.
What exactly is a "secure buffer"? I guess a gem object where read
a
> Hmm, the cross-device buffer sharing framework I have in mind would
> basically be a buffer registry. virtio-gpu would create buffers as
> usual, create a identifier somehow (details to be hashed out), attach
> the identifier to the dma-buf so it can be used as outlined above.
Using physical ad
ndle for the (virtio-gpu)
> buffer. Ask the host video decoder driver to import the host dma-buf.
> If it all worked fine it can ask the host hardware to decode directly to
> the host virtio-gpu resource.
>
Agreed.
> > > Referencing virtio-gpu buffers needs a better plan th
On Fri, Oct 11, 2019 at 5:54 PM Dmitry Morozov
wrote:
>
> Hi Tomasz,
>
> On Mittwoch, 9. Oktober 2019 05:55:45 CEST Tomasz Figa wrote:
> > On Tue, Oct 8, 2019 at 12:09 AM Dmitry Morozov
> >
> > wrote:
> > > Hi Tomasz,
> > >
> > > On Montag, 7. Oktober 2019 16:14:13 CEST Tomasz Figa wrote:
> > > >
e Documentation License,
>>> +.. Version 1.1 or any later version published by the Free Software
>>> +.. Foundation, with no Invariant Sections, no Front-Cover Texts
>>> +.. and no Back-Cover Texts. A copy of the license is included at
>>> +.. Documentation/media
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 "
ify this
> > +.. document under the terms of the GNU Free Documentation License,
> > +.. Version 1.1 or any later version published by the Free Software
> > +.. Foundation, with no Invariant Sections, no Front-Cover Texts
> > +.. and no Back-Cover Texts. A copy of the license
On 10/16/19 11:54 AM, Fabio Estevam wrote:
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 th
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:
On 10/16/19 6:04 AM, Fabio Estevam wrote:
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 inp
o you mean by mixing together? Hardware parsing the slices
> > always uses num_ref_idx_l[01]_default_active_minus1 from the PPS.
> > Hardware not parsing the slices always sets override to 1 and uses
> > num_ref_idx_l[01]_active_minus1 from the slice header struct.
>
> To su
On 10/15/19 4:35 PM, Niklas Söderlund wrote:
> Add a video device capability flag to indicate that its inputs and/or
> outputs are controlled by the Media Controller instead of the V4L2 API.
> When this flag is set, ioctls for get, set and enum inputs and outputs
> are automatically enabled and pro
> > > > IMHO it would only add further logic to the drivers, because they
> > > > > would need to have a conditional block that selects default or
> > > > > per-slice value based on the flag. The goal was to be able for the
> > > > > driver t
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59501/
Build log: https://builder.linuxtv.org/job/patchwork/20678/
Build time: 00:09:21
Link:
https://lore.kernel.org/linux-media/cb6f7dfe-8e7c-5fa9-e287-22daa356b...@xs4all.nl
gpg: Signature made Wed 16 Oct 2019 12:57:4
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-
On 10/16/19 12:34 AM, Jules Irenge wrote:
> Fix "alignment should mactch open parenthesis" check.
> Issue detected by checkpatch tool
>
> Signed-off-by: Jules Irenge
> ---
> drivers/staging/media/meson/vdec/codec_mpeg12.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59500/
Build log: https://builder.linuxtv.org/job/patchwork/20670/
Build time: 00:14:23
Link:
https://lore.kernel.org/linux-media/02bfac01-d6ba-1eca-efc6-1dbfcc712...@xs4all.nl
gpg: Signature made Wed 16 Oct 2019 11:31:2
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59498/
Build log: https://builder.linuxtv.org/job/patchwork/20663/
Build time: 00:13:22
Link:
https://lore.kernel.org/linux-media/5364cdbc-ccea-addd-3849-c4f9e2602...@xs4all.nl
gpg: Signature made Wed 16 Oct 2019 10:27:3
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/59497/
Build log: https://builder.linuxtv.org/job/patchwork/20659/
Build time: 00:03:57
Link:
https://lore.kernel.org/linux-media/20191016095738.gb5...@pendragon.ideasonboard.com
gpg: Signature made Wed 16 Oct 2019 09:56
On Tue, Oct 15, 2019 at 12:58 PM Biju Das wrote:
> Add the SoC specific information for RZ/G2N(R8A774B1) SoC.
> The VIN module of RZ/G2N is similar to R-Car M3-N.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoev
On Tue, Oct 15, 2019 at 12:58 PM Biju Das wrote:
> Add the compatible string for RZ/G2N (R8A774B1) to the list of supported
> SoCs.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux bey
On Tue, Oct 15, 2019 at 12:58 PM Biju Das wrote:
> Add the MIPI CSI-2 driver support for RZ/G2N(R8A774B1) SoC.
> The CSI-2 module of RZ/G2N is similar to R-Car M3-N.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterh
On Tue, Oct 15, 2019 at 12:58 PM Biju Das wrote:
> Document support for the VIN module in the Renesas RZ/G2N (R8A774B1) SoC.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia3
-ctl -d0 --wait-for-event=0x0801
>
> I plan to post an update to the imx.rst doc with these FIM usage examples.
Great, that will be helpful!
> I updated the i.MX GPT input capture driver patch and re-tested on my
> modified SabreAuto (CSI0_VSYNC signal routed to SD1_DAT0 pad),
d frame interval events can be polled with:
v4l2-ctl -d0 --wait-for-event=0x0801
I plan to post an update to the imx.rst doc with these FIM usage examples.
I updated the i.MX GPT input capture driver patch and re-tested on my
modified SabreAuto (CSI0_VSYNC signal routed to SD1_DAT0 pad),
On Mon, Oct 14, 2019 at 10:40:18AM +0200, Hans Verkuil wrote:
> This supersedes
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg150027.html
> based on feedback from Laurent:
>
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg150117.html
>
> and Sakari:
>
> https://www
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 10/15/19 9:00 AM, Fabio Estevam wrote:
Pass the v4l2-ctl configuration for the imx6q-sabreauto PAL
example for completeness and consistency.
Suggested-by: Steve Longerbeam
Signed-off-by: Fabio Estevam
Acked-by: Steve Longerbeam
---
Changes since v2:
- Newly introduced patch
Docume
On 10/15/19 9:00 AM, Fabio Estevam wrote:
The i.MX6DL sabreauto has different numbering on the I2C bus and
I2C muxes compared to the i.MX6Q as shown in the kernel log below:
[5.159423] imx-media: ipu1_csi0_mux:5 -> ipu1_csi0:0
[5.164618] imx-media: ipu1_csi1_mux:5 -> ipu1_csi1:0
[
On 10/15/19 9:42 AM, Fabio Estevam wrote:
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
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/
> I tested it on a imx6 sabreauto board with 5.3.x kernel plus Steve's
> patch that discard the 10 initial corrupted frames and I do not get
> rolling video.
>
> I do get rolling video if I remove/insert the cable though.
Right, because this re-creates the initial issue. Upon a
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
1 - 100 of 79244 matches
Mail list logo
