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: Fri Jan 18 05:00:11 CET 2019
media-tree git hash:e8f9b16d72631870e30a3d8e4ee9f1c097bc7ba0
media_build git
Add a linear pipeline logic for the stream control. It's created by
walking backwards on the entity graph. When the stream starts it will
simply loop through the pipeline calling the respective process_frame
function of each entity.
Fixes: f2fe89061d797 ("vimc: Virtual Media Controller core, captu
Hi Helen,
Thanks for the review. Just answer the question you made.
On Tue, Jan 15, 2019 at 2:45 PM Helen Koike wrote:
>
> Hi Lucas,
>
> Thank you for this patch, please see my comments below.
>
> On 1/14/19 10:19 PM, Lucas A. M. Magalhaes wrote:
> > Add a linear pipeline logic for the stream con
Hi Steve,
On Thu, Jan 17, 2019 at 6:59 PM Steve Longerbeam wrote:
>
> Some imx platforms do not have fwnode connections to all CSI input
> ports, and should not be treated as an error. This includes the
> imx6q SabreAuto, which has no connections to ipu1_csi1 and ipu2_csi0.
> Return -ENOTCONN in
Some imx platforms do not have fwnode connections to all CSI input
ports, and should not be treated as an error. This includes the
imx6q SabreAuto, which has no connections to ipu1_csi1 and ipu2_csi0.
Return -ENOTCONN in imx_csi_parse_endpoint() so that v4l2-fwnode
endpoint parsing will not treat a
Hi Tim,
On 1/15/19 8:42 AM, Tim Harvey wrote:
On Wed, Jan 9, 2019 at 10:34 AM Steve Longerbeam wrote:
Some imx platforms do not have fwnode connections to all CSI input
ports, and should not be treated as an error. This includes the
imx6q SabreAuto, which has no connections to ipu1_csi1 and ip
The CSI must be disabled immediately after receiving the last EOF before
stream off (and thus before disabling the IDMA channel). This can be
accomplished by moving upstream stream off to just after receiving the
last EOF completion in prp_stop(). For symmetry also move upstream
stream on to end of
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 repeatedly sending a stream off immediately followed
by stream on:
while true; do
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 repeatedly sending a stream off immediately followed
by stream on:
while true; do
Hi Fabio, thanks for the review.
On 1/17/19 12:20 PM, Fabio Estevam wrote:
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 h
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
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 repeatedly sending a stream off immediately followed
by stream on:
while true; do
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 repeatedly sending a stream off immediately followed
by stream on:
while true; do
The CSI must be disabled immediately after receiving the last EOF before
stream off (and thus before disabling the IDMA channel). This can be
accomplished by moving upstream stream off to just after receiving the
last EOF completion in prp_stop(). For symmetry also move upstream
stream on to end of
On Mon, 2019-01-07 at 12:34 +0100, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil
>
> Memory-to-memory devices should copy various parts of
> struct v4l2_buffer from the output buffer to the capture buffer.
>
> Add a helper function that does that to simplify the driver code.
>
> Signed-o
---
drivers/media/rc/Kconfig | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 2c468fa0299f..4486e1940196 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -139,9 +139,7 @@ config IR_RCMM_DECODER
Hi Sean,
Your update is fine, and everything is working perfectly on my machine. We need
just now
to update the description; 'rcmm' is now the global keyword. The warning
triggered by the v5
was just: 'if' badly interpreted as a keyword by the perl script.
Best Regards,
Patric Lerda.
Patrick L
If the the queues are not streaming then the first resolution
change is handled in the buf_queue callback.
The following resolution change events are handled in job_ready.
Signed-off-by: Dafna Hirschfeld
---
drivers/media/platform/vicodec/vicodec-core.c | 355 ++
1 file changed,
Add flags indicating the pixel encoding - yuv/rgb/hsv to
fwht header and to the pixel info. Use it to enumerate
the supported pixel formats.
Signed-off-by: Dafna Hirschfeld
---
drivers/media/platform/vicodec/codec-fwht.h | 5 ++
.../media/platform/vicodec/codec-v4l2-fwht.c | 76 +
Add support for the selection api for the crop and compose targets.
The driver rounds up the coded width and height such that
all planes dimensions are multiple of 8.
Signed-off-by: Dafna Hirschfeld
---
drivers/media/platform/vicodec/codec-fwht.c | 80 +++--
drivers/media/platform/vicodec/cod
Keep the fwht header in separated field from the data.
Refactor job_ready to use a new function 'get_next_header'
Signed-off-by: Dafna Hirschfeld
---
.../media/platform/vicodec/codec-v4l2-fwht.c | 24 ++--
.../media/platform/vicodec/codec-v4l2-fwht.h | 1 +
drivers/media/platform/vicodec/vi
In the fwht_encode_frame, 'encoding = encode_plane'
should be replaced with 'encoding |= encode_plane'
so existing flags won't be overwrriten.
Signed-off-by: Dafna Hirschfeld
---
drivers/media/platform/vicodec/codec-fwht.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Add the field 'num_planes' to 'v4l2_fwht_pixfmt_info' struct.
Signed-off-by: Dafna Hirschfeld
---
.../media/platform/vicodec/codec-v4l2-fwht.c | 48 +--
.../media/platform/vicodec/codec-v4l2-fwht.h | 1 +
drivers/media/platform/vicodec/vicodec-core.c | 2 +-
3 files changed,
Main changes from v2:
1. bugfix in patch "add support for CROP" (pix instead of pix_mp)
in vidioc_try_fmt
2. using bits 18-20 for the pixel encoding so that 0 means previous version
3. some refactoring
Dafna Hirschfeld (6):
media: vicodec: bugfix - replace '=' with '|='
media: vicodec: Add nu
On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote:
> Hi Christoph,
>
> On 2019-01-11 19:17, Christoph Hellwig wrote:
> > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > resemblance of a dma address for a a physical address that does is
> > not backed by a pag
Export few HFI functions to use them from decoder to implement
more granular control needed for stateful Codec API compliance.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/hfi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/hf
Make hfi_flush function to receive an argument for the type
of flush.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/hfi.c | 4 ++--
drivers/media/platform/qcom/venus/hfi.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/
This adds three more helper functions:
* for internal buffers reallocation, applicable when we are doing
dynamic resolution change
* for initial buffer processing of capture and output queue buffer
types
All of them will be needed for stateful Codec API support.
Signed-off-by: Stanimir Varbanov
Add two more not-implemented properties for Venus v4.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/hfi_cmds.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/hfi_cmds.c
b/drivers/media/platform/qcom/venus/hfi_cmds.c
index 87a4414
Until now we returned num_output_bufs set during reqbuf but
that could be wrong when we implement stateful Codec API. So
get the minimum buffers for capture from HFI. This is supposed
to be called after stream header parsing, i.e. after dequeue
v4l2 event for change resolution.
Signed-off-by: Stan
Here we export few helper function to use them from decoder to
implement more granular control needed for stateful Codec API
compliance.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/helpers.c | 29 -
drivers/media/platform/qcom/venus/helpers.h | 7 +
In most of the cases the client will know better what could be
the maximum size for compressed data buffers. Change the driver
to permit the user to set bigger size for the compressed buffer
but make reasonable sanitation.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/vd
This refactored code for start/stop streaming vb2 operations and
adds a state machine handling similar to the one in stateful codec
API documentation. One major change is that now the HFI session is
started on STREAMON(OUTPUT) and stopped on REQBUF(OUTPUT,count=0),
during that time streamoff(cap,ou
This makes hfi_session_init to return an error when it is
already called without a call to hfi_session_deinit.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/hfi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/hfi.c
b/drivers/me
Hello,
This aims to make Venus decoder compliant with stateful Codec API [1].
The patches 1-9 are preparation for the cherry on the cake patch 10
which implements the decoder state machine similar to the one in the
stateful codec API documentation.
There few things which are still TODO:
- V4L2_D
Venus v4 doesn't send ALLOC_MODE property and thus parser doesn't
recognize it as dynamic buffer (for OUTPUT/OUTPUT2 type of buffers)
make it obvious in the helper function.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/helpers.c | 7 +++
1 file changed, 7 insertions
From: Hans Verkuil
This is a test stub driver for soc_camera. Since soc_camera is
being deprecated (and in fact, nobody is using it anymore)
there's no sense in keeping this test driver.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/soc_camera/Kconfig | 6 -
drivers/media/platfo
From: Jacopo Mondi
As the tw9910 subdevice is registered through the v4l2-async framework,
use the v4l2-async provided function to register it.
Fixes: 7b20f325a566 ("media: i2c: tw9910: Remove soc_camera dependencies")
Signed-off-by: Jacopo Mondi
Signed-off-by: Hans Verkuil
---
drivers/media/
From: Hans Verkuil
This driver got converted to not depend on soc_camera in commit
762c28121d7c ("media: i2c: ov772x: Remove soc_camera dependencies").
There's no sense in keeping the old version there.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/soc_camera/Kconfig |6 -
driver
From: Hans Verkuil
The soc_mt9t112, soc_ov772x and soc_tw9910 drivers now have
non-soc-camera replacements, so those three drivers can be
removed.
The soc_camera sh_mobile_ceu_camera platform driver also has
a non-soc-camera replacement, so remove this driver as well.
This driver was also the l
From: Hans Verkuil
With the removal of sh_mobile_ceu_camera.c this code is no
longer used and can be removed.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/soc_camera/Kconfig | 3 -
drivers/media/platform/soc_camera/Makefile| 1 -
.../platform/soc_camera/soc_scale_crop.c
From: Hans Verkuil
This driver got converted to not depend on soc_camera in commit
7b20f325a566 ("media: i2c: tw9910: Remove soc_camera dependencies").
There's no sense in keeping the old version there.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/soc_camera/Kconfig | 6 -
drivers
From: Hans Verkuil
This driver got converted to not depend on soc_camera in commit
6a26f141bf62 ("media: i2c: mt9t112: Remove soc_camera dependencies").
There's no sense in keeping the old version there.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/soc_camera/Kconfig |6 -
driv
From: Hans Verkuil
This driver got converted to not depend on soc_camera in commit
32e5a70dc8f4 ("media: platform: Add Renesas CEU driver").
There's no sense in keeping the old version there.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/soc_camera/Kconfig |9 -
drivers/media
From: Hans Verkuil
This include isn't use anymore, so drop it.
Signed-off-by: Hans Verkuil
---
include/media/i2c/tw9910.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/media/i2c/tw9910.h b/include/media/i2c/tw9910.h
index bec8f7bce745..2f93799d5a21 100644
--- a/include/media/i2c
On Thu, Jan 17, 2019 at 10:30:01AM +0100, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote:
> > The fact is there is 0 industry interest in using RDMA on platforms
> > that can't do HW DMA cache coherency - the kernel syscalls required to
> > do the cache flushin
Prepare for mbus format being smaller than the written rectangle
due to burst size.
Signed-off-by: Philipp Zabel
Reviewed-by: Steve Longerbeam
---
Changes since v3 [1]:
- Rebased onto d969291d8479 ("media: imx: Fix field negotiation")
- Comment on the horizontal padding due to DMA burst size i
Allowing to compose captured images into larger memory buffers
will let us lift alignment restrictions on CSI crop width.
For now all compose rectangles are identical to the complete
frame width / height. This will be changed in the next patches.
Signed-off-by: Philipp Zabel
Acked-by: Sakari Ail
The CSI, PRP ENC, and PRP VF subdevices shouldn't have to care about
IDMAC line start address alignment. With compose rectangle support in
the capture driver, they don't have to anymore.
If the direct CSI -> IC path is enabled, the CSI output width must
still be aligned to 8 pixels (IC burst length
Add a single imx-media mem2mem video device that uses the IPU IC PP
(image converter post processing) task for scaling and colorspace
conversion.
On i.MX6Q/DL SoCs with two IPUs currently only the first IPU is used.
The hardware only supports writing to destination buffers up to
1024x1024 pixels i
Do you need to shoot photos for your products including editing?
We are the photo studio who can help you to edit your photos or take care
of the photo shooting for you,
You ship – We shoot
White background
Retouching included
Optimized for Shopify
Revisions accepted
We also provide dedicate edi
Do you need to shoot photos for your products including editing?
We are the photo studio who can help you to edit your photos or take care
of the photo shooting for you,
You ship – We shoot
White background
Retouching included
Optimized for Shopify
Revisions accepted
We also provide dedicate edi
From: Patrick Lerda
media: add support for RCMM infrared remote controls.
Signed-off-by: Patrick Lerda
Signed-off-by: Sean Young
---
MAINTAINERS | 5 +
drivers/media/rc/Kconfig | 13 ++
drivers/media/rc/Makefile| 1 +
drivers/m
When the system lirc.h is older than v4.16, you will get errors like:
ir_loopback.c:32:16: error: field ‘proto’ has incomplete type
enum rc_proto proto;
Cc: Shuah Khan
Signed-off-by: Sean Young
---
tools/testing/selftests/ir/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tool
Hi Patrick,
I've made some very minor/cosmetic changes and added rcmm to the selftest;
I didn't want to just add them to the tree without showing to you first.
Let me know what you think.
Thanks
Sean
Patrick Lerda (1):
media: rc: rcmm decoder and encoder
Sean Young (1):
selftests: Use lirc
As the tw9910 subdevice is registered through the v4l2-async framework,
use the v4l2-async provided function to register it.
Fixes: 7b20f325a566 ("media: i2c: tw9910: Remove soc_camera dependencies")
Signed-off-by: Jacopo Mondi
---
As agreed with Hans on irc, this patch makes removing soc_camera.
Do you need to shoot photos for your products including editing?
We are the photo studio who can help you to edit your photos or take care
of the photo shooting for you,
You ship – We shoot
White background
Retouching included
Optimized for Shopify
Revisions accepted
We also provide dedicate edi
On Wed, Jan 09, 2019 at 10:33:26AM +0100, Maxime Ripard wrote:
> Now that we have everything we need in the phy framework to allow to tune
> the phy parameters, let's convert the Cadence DSI bridge to that API
> instead of creating a ad-hoc driver for its phy.
>
> Signed-off-by: Maxime Ripard
As
On 1/17/19 2:01 PM, Philipp Zabel wrote:
> On Wed, 2019-01-16 at 16:28 +0100, Hans Verkuil wrote:
>> On 1/11/19 12:10 PM, Philipp Zabel wrote:
>>> Prepare for mbus format being smaller than the written rectangle
>>> due to burst size.
>>>
>>> Signed-off-by: Philipp Zabel
>>> Reviewed-by: Steve Lon
On Wed, Jan 09, 2019 at 10:33:25AM +0100, Maxime Ripard wrote:
> Cadence has designed a D-PHY that can be used by the, currently in tree,
> DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
>
> Only the DSI driver has an ad-hoc driver for that phy at the moment, while
> the v4l2 d
Do you need to shoot photos for your products including editing?
We are the photo studio who can help you to edit your photos or take care
of the photo shooting for you,
You ship – We shoot
White background
Retouching included
Optimized for Shopify
Revisions accepted
We also provide dedicate edi
On Wed, 2019-01-16 at 17:19 +0100, Hans Verkuil wrote:
> Hi Philipp,
>
> A quick review (just a few small points):
>
> On 1/8/19 4:38 PM, Philipp Zabel wrote:
[...]
> > +/*
> > + * Video ioctls
> > + */
> > +static int ipu_csc_scaler_querycap(struct file *file, void *priv,
> > +
On Wed, Jan 09, 2019 at 10:33:23AM +0100, Maxime Ripard wrote:
> The current configuration of the DSI bridge and its associated D-PHY is
> intertwined. In order to ease the future conversion to the phy framework
> for the D-PHY part, let's split the configuration in two.
>
> Signed-off-by: Maxime
On 1/17/19 1:57 PM, Mauro Carvalho Chehab wrote:
> This driver got converted to not depend on soc_camera on commit
> 57b0ad9ebe60 ("media: soc_camera: ov9640: move ov9640 out of soc_camera").
>
> There's no sense on keeping the old version there.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-b
On Wed, 2019-01-16 at 16:28 +0100, Hans Verkuil wrote:
> On 1/11/19 12:10 PM, Philipp Zabel wrote:
> > Prepare for mbus format being smaller than the written rectangle
> > due to burst size.
> >
> > Signed-off-by: Philipp Zabel
> > Reviewed-by: Steve Longerbeam
> > ---
> > drivers/staging/media
On Thu, Jan 17, 2019 at 07:57:47AM -0500, Mauro Carvalho Chehab wrote:
> This driver got converted to not depend on soc_camera on commit
> 57b0ad9ebe60 ("media: soc_camera: ov9640: move ov9640 out of soc_camera").
>
> There's no sense on keeping the old version there.
>
> Signed-off-by: Mauro Car
This driver got converted to not depend on soc_camera on commit
57b0ad9ebe60 ("media: soc_camera: ov9640: move ov9640 out of soc_camera").
There's no sense on keeping the old version there.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/i2c/soc_camera/Kconfig | 8 -
drivers/media
On Wed, Jan 16, 2019 at 11:49 AM Thomas Hellstrom wrote:
>
> Hi,
>
> On Wed, 2019-01-16 at 09:24 -0500, Rob Clark wrote:
> > So, I guess this is to do w/ the magic of merge commits, but it looks
> > like the hunk changing the crtc_ww_class got lost:
>
> So what happened here is that this commit ch
Hi Hans,
thank you for the review.
On Wed, 2019-01-16 at 16:29 +0100, Hans Verkuil wrote:
[...]
> @@ -290,6 +294,34 @@ static int capture_s_std(struct file *file, void *fh,
> v4l2_std_id std)
> > return v4l2_subdev_call(priv->src_sd, video, s_std, std);
> > }
> >
> > +static int capture_g
On 1/16/19 4:25 PM, Dafna Hirschfeld wrote:
> If the the queues are not streaming then the first resolution
> change is handled in the buf_queue callback.
> The following resolution change events are handled in job_ready.
>
> Signed-off-by: Dafna Hirschfeld
> ---
> drivers/media/platform/vicodec
On 1/16/19 4:25 PM, Dafna Hirschfeld wrote:
> If the the queues are not streaming then the first resolution
> change is handled in the buf_queue callback.
> The following resolution change events are handled in job_ready.
>
> Signed-off-by: Dafna Hirschfeld
> ---
> drivers/media/platform/vicodec
On Fri, Jan 11, 2019 at 8:31 PM Souptick Joarder wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized b
Hi,
On Wed, Jan 09, 2019 at 01:01:22AM +0800, ayaka wrote:
> On 1/8/19 5:52 PM, Randy 'ayaka' Li wrote:
> > On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:
> > > From: Pawel Osciak
> > >
> > > Stateless video codecs will require both the H264 metadata and slices in
> > > order to
Hi,
On Thu, Jan 10, 2019 at 09:33:01PM +0800, ayaka wrote:
> I forget a important thing, for the rkvdec and rk hevc decoder, it would
> requests cabac table, scaling list, picture parameter set and reference
> picture storing in one or various of DMA buffers. I am not talking about the
> data been
Hi,
On Tue, Jan 08, 2019 at 05:52:28PM +0800, Randy 'ayaka' Li wrote:
> > +struct v4l2_ctrl_h264_scaling_matrix {
> > + __u8 scaling_list_4x4[6][16];
> > + __u8 scaling_list_8x8[6][64];
> > +};
>
> I wonder which decoder want this.
I'm not sure I follow you, scaling lists are an important pa
On 1/16/19 4:25 PM, Dafna Hirschfeld wrote:
> Add flags indicating the pixel encoding - yuv/rgb/hsv to
> fwht header and to the pixel info. Use it to enumerate
> the supported pixel formats.
>
> Signed-off-by: Dafna Hirschfeld
> ---
> drivers/media/platform/vicodec/codec-fwht.h | 5 ++
> .../
media: add support for RCMM infrared remote controls.
Signed-off-by: Patrick Lerda
---
MAINTAINERS| 5 +
drivers/media/rc/Kconfig | 13 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-rcmm-decoder.c | 257 +
driv
On Thu, 2019-01-17 at 10:30 +0100, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote:
> > The fact is there is 0 industry interest in using RDMA on platforms
> > that can't do HW DMA cache coherency - the kernel syscalls required
> > to
> > do the cache flushing o
On 1/16/19 4:25 PM, Dafna Hirschfeld wrote:
> Keep the fwht header in separated field from the data.
> Refactor job_ready to use a new function 'get_next_header'
>
> Signed-off-by: Dafna Hirschfeld
> ---
> .../media/platform/vicodec/codec-v4l2-fwht.c | 24 ++--
> .../media/platform/vicodec/cod
On Wed, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote:
> The fact is there is 0 industry interest in using RDMA on platforms
> that can't do HW DMA cache coherency - the kernel syscalls required to
> do the cache flushing on the IO path would just destroy performance to
> the point of mak
This avoids confusion with the non-soc-camera ov9640.h.
Signed-off-by: Hans Verkuil
---
Having two headers by the same name caused a daily build error. Fix this by
renaming the soc_camera ov9640.h header.
BTW, is there any reason why the soc_camera ov9640 driver can't be
removed altogether? It's
From: Patrick Lerda
media: add support for RCMM infrared remote controls.
Signed-off-by: Patrick Lerda
---
MAINTAINERS| 5 +
drivers/media/rc/Kconfig | 13 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-rcmm-decoder.c | 257 +
82 matches
Mail list logo
