In case usb_alloc_coherent fails, the fix returns -ENOMEM to
avoid a potential NULL pointer dereference.
Signed-off-by: Kangjie Lu
---
drivers/media/usb/usbvision/usbvision-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/usb/usbvision/usbvision-core.c
b/drivers/media
devm_kcalloc may fail and return a null pointer. The fix returns
-ENOMEM upon failures to avoid null pointer dereferences.
Signed-off-by: Kangjie Lu
---
drivers/media/platform/video-mux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/video-mux.c
b/drivers/media
In case of_match_device cannot find a match, the check returns
-EINVAL to avoid a potential NULL pointer dereference
Signed-off-by: Kangjie Lu
---
drivers/media/platform/renesas-ceu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/renesas-ceu.c
b/
In case of_match_node cannot find a match, the fix returns
-EINVAL to avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu
---
drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platf
In case ioremap fails, the fix returns -ENOMEM to avoid NULL
pointer dereference.
Signed-off-by: Kangjie Lu
---
drivers/media/platform/davinci/vpss.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/davinci/vpss.c
b/drivers/media/platform/davinci/vpss.c
index 19cf68
Conservatively check return value of STV090x_WRITE_DEMOD in case
it fails.
Signed-off-by: Kangjie Lu
---
drivers/media/dvb-frontends/stv090x.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb-frontends/stv090x.c
b/drivers/media/dvb-front
In case __get_free_pages fails, return -ENOMEM to avoid NULL
pointer dereferences.
Signed-off-by: Kangjie Lu
---
drivers/media/platform/rockchip/rga/rga.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/rockchip/rga/rga.c
b/drivers/media/platform/rockchip/rga/rga
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Sat Mar 9 05:00:15 CET 2019
media-tree git hash:15d90a6ae98e6d2c68497b44a491cb9efbb98ab1
media_build git
On 3/8/19 3:57 AM, Philipp Zabel wrote:
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
Add support for the following conversions:
- YUV full-range to YUV limited-range
- YUV limited-range to YUV full-range
- YUV limited-range to RGB full-range
- RGB full-range to YUV limited-rang
On 3/8/19 3:46 AM, Philipp Zabel wrote:
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the colorspace (chromaticities), Y'CbCr encoding
On 3/8/19 2:23 AM, Philipp Zabel wrote:
Hi Steve,
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
The ycbcr2rgb and inverse rgb2ycbcr tables define the BT.601 Y'CbCr
encoding coefficients.
The rgb2ycbcr table specifically describes the BT.601 encoding from
full range RGB to full
Hi,
This series update the driver to match changes in the latest datasheet
(rev 1.50). All changes are related to register setup when starting the
stream.
This series depends on [PATCH v2] rcar-csi2: Propagate the FLD signal
for NTSC and PAL.
Niklas Söderlund (3):
rcar-csi2: Update V3M and E3
Latest information from hardware engineers reveals that H3 ES2 and ES3
behave differently when working with link speeds bellow 250 Mpbs.
Add a SoC match for H3 ES2.* and use the correct startup sequence.
Signed-off-by: Niklas Söderlund
Reviewed-by: Kieran Bingham
---
drivers/media/platform/rcar
Latest datasheet (rev 1.50) clarifies that the FLD register should be
set after LINKCNT.
Signed-off-by: Niklas Söderlund
Reviewed-by: Ulrich Hecht
Reviewed-by: Kieran Bingham
---
drivers/media/platform/rcar-vin/rcar-csi2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
The latest datasheet (rev 1.50) updates the start procedure for V3M and
E3. Update the driver to match these changes.
Signed-off-by: Niklas Söderlund
Reviewed-by: Ulrich Hecht
---
drivers/media/platform/rcar-vin/rcar-csi2.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
Depending on which video standard is used the driver needs to setup the
hardware to correctly handle fields. If stream is identified as NTSC
or PAL setup field detection and propagate the field detection signal.
Later versions of the datasheet have been updated to make it clear
that FLD register s
The resets property will become mandatory to operate the device, list it
as such. All device tree source files have always included the reset
property so making it mandatory will not introduce any regressions.
While at it improve the description for the clocks property.
Signed-off-by: Niklas Söde
Later versions of the datasheet updates the reset procedure to more
closely resemble the standby mode. Update the driver to enter and exit
the standby mode instead of resetting the hardware before and after
streaming is started and stopped.
While at it break out the full start and stop procedures
Hi,
This small series updates rcar-csi2 to use the standby mode described in
later versions of the datasheet.
* Changes since v1
- Break up enter and exit of standby mode in two separate functions.
- Add "select RESET_CONTROLLER" to Kconfig.
Niklas Söderlund (2):
dt-bindings: rcar-csi2: List
Some DVB clients are broken and only recognize the DVB-T/T2 support in
the frontend. Thus they are unable to use the frontend in DVB-C mode.
One example is the incomplete DVBv5 API support added in mythtv 0.30:
https://code.mythtv.org/trac/ticket/12638
The boolean module parameter "disable_dvb
Hi Luca,
Thanks for reviewing this. Sorry I missed out on replying to this earlier.
I had already sent v4 but have requested to be ignored. Your comments will be
addressed in the v5 patch series.
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@
Hi all,
Please ignore this patch series as I missed addressing some comments in this
patch.
I will address them in the next series.
Regards
Vishal Sagar
> -Original Message-
> From: Vishal Sagar [mailto:vishal.sa...@xilinx.com]
> Sent: Friday, March 08, 2019 11:01 PM
> To: Hyun Kwon ;
The Xilinx MIPI CSI-2 Rx Subsystem soft IP is used to capture images
from MIPI CSI-2 camera sensors and output AXI4-Stream video data ready
for image processing. Please refer to PG232 for details.
The driver is used to set the number of active lanes, if enabled
in hardware. The CSI2 Rx controller
Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
The Xilinx MIPI CSI-2 Rx Subsystem consists of a CSI-2 Rx controller, a
DPHY in Rx mode, an optional I2C controller and a Video Format Bridge.
Signed-off-by: Vishal Sagar
Reviewed-by: Hyun Kwon
---
v4
- Added reviewed by Hyun Kwon
Xilinx MIPI CSI-2 Receiver Subsystem
The Xilinx MIPI CSI-2 Receiver Subsystem Soft IP consists of a DPHY which
gets the data, an optional I2C, a CSI-2 Receiver which parses the data and
converts it into AXIS data.
This stream output maybe connected to a Xilinx
Signed-off-by: Sean Young
---
configure.ac| 1 +
utils/ir-ctl/ir-ctl.1.in| 2 +-
utils/keytable/.gitignore | 1 +
utils/keytable/Makefile.am | 4 +-
utils/keytable/ir-keytable.1.in | 1 +
utils/keytable/rc_keymap.5.in | 251 ++
Hi Hans,
Thanks for your feedback.
On 2019-03-08 15:12:15 +0100, Hans Verkuil wrote:
> On 2/16/19 11:57 PM, Niklas Söderlund wrote:
> > Allow the hardware to to do proper field detection for interlaced field
> > formats by implementing s_std() and g_std(). Depending on which video
> > standard is
On Fri, 2019-03-01 at 15:27 -0800, Steve Longerbeam wrote:
> The i.MX7 capture support forgot to change the group ID for the CSI
> to the IPU CSI in VDIC sub-device, it was left at the i.MX7 CSI
> group ID.
>
> Fixes: 67673ed55084 ("media: staging/imx: rearrange group id to take in
> account IPU"
On 3/8/19 3:09 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Fri, Mar 08, 2019 at 02:56:23PM +0100, Hans Verkuil wrote:
>> The media_device is part of a static global vimc_device struct.
>> The media framework expects this to be zeroed before it is
>> used, however, s
Hi Jacopo,
On Fri, Mar 08, 2019 at 02:31:33PM +0100, Jacopo Mondi wrote:
> Hi Sakari,
>thanks for the review
>
> On Thu, Mar 07, 2019 at 05:19:29PM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > Thanks for writing the documentation for this!
> >
> > The text is nice and informative; I have
On Fri, Mar 08, 2019 at 02:19:03PM +0100, Jacopo Mondi wrote:
> Hi Sakari and Niklas,
>
> On Thu, Mar 07, 2019 at 11:47:26AM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Tue, Mar 05, 2019 at 07:51:19PM +0100, Jacopo Mondi wrote:
> > > Hello,
> > >third version of multiplexed stream sup
On 2/16/19 11:57 PM, Niklas Söderlund wrote:
> Allow the hardware to to do proper field detection for interlaced field
> formats by implementing s_std() and g_std(). Depending on which video
> standard is selected the driver needs to setup the hardware to correctly
> identify fields.
>
> Later ver
Hi Hans,
Thank you for the patch.
On Fri, Mar 08, 2019 at 02:56:23PM +0100, Hans Verkuil wrote:
> The media_device is part of a static global vimc_device struct.
> The media framework expects this to be zeroed before it is
> used, however, since this is a global this is not the case if
> vimc is
On 3/8/19 12:26 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Thu, Mar 07, 2019 at 10:23:03AM +0100, Hans Verkuil wrote:
>> On 3/5/19 8:39 PM, Laurent Pinchart wrote:
>>> On Tue, Mar 05, 2019 at 10:58:42AM +0100, hverkuil-ci...@xs4all.nl wrote:
From: Hans Verkuil
Ensure that this p
If the subdevice created a device node, then the v4l2_subdev cannot
be freed until the last user of the device node closes it.
This means that we need a release() callback in v4l2_subdev_internal_ops
that is called from the video_device release function so the subdevice
driver can postpone freeing
Use the new v4l2_subdev_internal_ops release op to free the
subdev memory only once the last user closed the file handle.
Signed-off-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
---
drivers/media/platform/vimc/vimc-common.c | 2 ++
drivers/media/platform/vimc/vimc-common.h | 2 ++
drivers
When vivid is unloaded it used vfree to free dev->bitmap_out,
but it was actually allocated using kmalloc. Use vzalloc
instead, conform what vivid-vid-cap.c does.
Signed-off-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
---
drivers/media/platform/vivid/vivid-vid-out.c | 14 +-
1 fi
The module ownership refcounting was done in media_entity_get/put,
but that was very confusing and it did not work either in case an
application had a v4l-subdevX device open and the module was
unbound. When the v4l-subdevX device was closed the media_entity_put
was never called and the module refc
The media_device is part of a static global vimc_device struct.
The media framework expects this to be zeroed before it is
used, however, since this is a global this is not the case if
vimc is unbound and then bound again.
So call memset to ensure any left-over values are cleared.
Signed-off-by:
Don't free vimc_cap_device immediately, instead do this
in the video_device release function which is called when the
last user closes the video device. Only then is it safe to
free the memory.
Signed-off-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
---
drivers/media/platform/vimc/vimc-captur
It is not possible to use devm_kzalloc since that memory is
freed immediately when the device instance is unbound.
Various objects like the video device may still be in use
since someone has the device node open, and when that is closed
it expects the memory to be around.
So use kzalloc and relea
Various fixes for bugs that I found while working on the
regression test-media script.
The CONFIG_DEBUG_KOBJECT_RELEASE=y option in particular found
a bunch of bugs where things were not released in the right
order.
Note that the first two patches are not bug fixes, but they
help debugging kobjec
The media chardev kobject has no name, which made it hard to
debug when kobject debugging is turned on.
Signed-off-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
---
drivers/media/media-devnode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/media-devnode.c b/drivers/media/m
The cec chardev kobject has no name, which made it hard to
debug when kobject debugging is turned on.
Signed-off-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
---
drivers/media/cec/cec-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/c
Hi Helen,
On 3/6/19 11:42 PM, Helen Koike wrote:
> Media bus codes were being mapped to pixelformats, which causes a
> limitation on vimc because not all pixelformats can be mapped to media
> bus codes.
> Also, media bus codes are an internal configuration from the device.
> Userspace only assures
Hi Sakari,
thanks for the review
On Thu, Mar 07, 2019 at 05:19:29PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> Thanks for writing the documentation for this!
>
> The text is nice and informative; I have a few suggestions below.
>
> On Tue, Mar 05, 2019 at 07:51:38PM +0100, Jacopo Mondi wrote:
Hi Sakari and Niklas,
On Thu, Mar 07, 2019 at 11:47:26AM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Tue, Mar 05, 2019 at 07:51:19PM +0100, Jacopo Mondi wrote:
> > Hello,
> >third version of multiplexed stream support patch series.
> >
> > V2 sent by Niklas is available at:
> > https://patc
Hi Laurent,
On Fri, Mar 08, 2019 at 01:29:38PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Thu, Mar 07, 2019 at 11:35:11AM +0100, Jacopo Mondi wrote:
> > On Wed, Mar 06, 2019 at 09:15:21PM +0200, Laurent Pinchart wrote:
> > > On Wed, Mar 06, 2019 at 12:26:59PM +0100, Jacopo Mondi wrote:
> >
Hi Niklas,
(CC'ing Sakari)
On Thu, Mar 07, 2019 at 01:38:20AM +0100, Niklas Söderlund wrote:
> On 2019-03-07 02:26:45 +0200, Laurent Pinchart wrote:
> > On Thu, Mar 07, 2019 at 01:22:36AM +0100, Niklas Söderlund wrote:
> >> On 2019-03-07 02:13:18 +0200, Laurent Pinchart wrote:
> >>> On Sat, Feb 1
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
> Add support for the following conversions:
>
> - YUV full-range to YUV limited-range
> - YUV limited-range to YUV full-range
> - YUV limited-range to RGB full-range
> - RGB full-range to YUV limited-range
>
> The last two conversions re
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
> Only providing the input and output RGB/YUV space to the IC task init
> functions is not sufficient. To fully characterize a colorspace
> conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
> and quantization also need
Hi Jacopo,
On Thu, Mar 07, 2019 at 11:35:11AM +0100, Jacopo Mondi wrote:
> On Wed, Mar 06, 2019 at 09:15:21PM +0200, Laurent Pinchart wrote:
> > On Wed, Mar 06, 2019 at 12:26:59PM +0100, Jacopo Mondi wrote:
> >> When both the media links between AFE and HDMI and the two TX CSI-2 outputs
> >> gets
Hi Hans,
On Thu, Mar 07, 2019 at 10:23:03AM +0100, Hans Verkuil wrote:
> On 3/5/19 8:39 PM, Laurent Pinchart wrote:
> > On Tue, Mar 05, 2019 at 10:58:42AM +0100, hverkuil-ci...@xs4all.nl wrote:
> >> From: Hans Verkuil
> >>
> >> Ensure that this pointer is set to NULL after it is freed.
> >> The v
From: Colin Ian King
Don't populate the array addr_list on the stack but instead make it
static. Makes the object code smaller by 20 bytes
Before:
textdata bss dec hex filename^M
169293626 384 2093951cb ../usb/em28xx/em28xx-input.o
After:
textdata b
Hi Steve,
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
> The ycbcr2rgb and inverse rgb2ycbcr tables define the BT.601 Y'CbCr
> encoding coefficients.
>
> The rgb2ycbcr table specifically describes the BT.601 encoding from
> full range RGB to full range YUV. Add table comments to mak
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
> The saturation bit was being set at bit 9 in the second 32-bit word
> of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
> which is bit 10 of the second word.
>
> Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter u
With the default iova and dma-iommu driver, the starting
address of a new buffer would be at lower address than
the previous one.
This patch can solve this problem simply, but I want
a way to control the address direction of the IOMMU/IOVA.
The reason why we(ayaka and I) need to do this is simple
Hi, thank you Louis for the patch!
And, thank you Tomasz for adding me to CC in this thread:)
Let me add only general comments because I don't have enough knowledge
about the technical details of this device.
Please see my comments inline.
On Tue, Mar 5, 2019 at 4:51 PM Tomasz Figa wrote:
>
> +
58 matches
Mail list logo
