Re: [PATCH 15/16] [media] solo6x10: Convert to copy_silence ops
On 05/21/2017 10:09 PM, Takashi Iwai wrote:
> Replace the copy and the silence ops with the new merged ops.
> It's a capture stream, thus no silence is needed.
>
> Signed-off-by: Takashi Iwai
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/pci/solo6x10/solo6x10-g723.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/pci/solo6x10/solo6x10-g723.c
> b/drivers/media/pci/solo6x10/solo6x10-g723.c
> index 36e93540bb49..e21db3efb748 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-g723.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-g723.c
> @@ -225,7 +225,7 @@ static snd_pcm_uframes_t snd_solo_pcm_pointer(struct
> snd_pcm_substream *ss)
>
> static int snd_solo_pcm_copy(struct snd_pcm_substream *ss, int channel,
>snd_pcm_uframes_t pos, void __user *dst,
> - snd_pcm_uframes_t count)
> + snd_pcm_uframes_t count, bool in_kernel)
> {
> struct solo_snd_pcm *solo_pcm = snd_pcm_substream_chip(ss);
> struct solo_dev *solo_dev = solo_pcm->solo_dev;
> @@ -242,10 +242,11 @@ static int snd_solo_pcm_copy(struct snd_pcm_substream
> *ss, int channel,
> if (err)
> return err;
>
> - err = copy_to_user(dst + (i * G723_PERIOD_BYTES),
> -solo_pcm->g723_buf, G723_PERIOD_BYTES);
> -
> - if (err)
> + if (in_kernel)
> + memcpy((void *)dst + (i * G723_PERIOD_BYTES),
> +solo_pcm->g723_buf, G723_PERIOD_BYTES);
> + else if (copy_to_user(dst + (i * G723_PERIOD_BYTES),
> + solo_pcm->g723_buf, G723_PERIOD_BYTES))
> return -EFAULT;
> }
>
> @@ -261,7 +262,7 @@ static const struct snd_pcm_ops snd_solo_pcm_ops = {
> .prepare = snd_solo_pcm_prepare,
> .trigger = snd_solo_pcm_trigger,
> .pointer = snd_solo_pcm_pointer,
> - .copy = snd_solo_pcm_copy,
> + .copy_silence = snd_solo_pcm_copy,
> };
>
> static int snd_solo_capture_volume_info(struct snd_kcontrol *kcontrol,
>
[GIT PULL FOR v4.13] Add qualcomm venus codec
Hi Mauro, This pull requests adds support for the Qualcomm venus codec driver. Regards, Hans The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030: [media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update() (2017-05-19 07:12:05 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git venus for you to fetch changes up to f0486d42560ae110f6e7d9b92352d7a1827cd38e: media: venus: enable building of Venus video driver (2017-05-22 09:24:20 +0200) Stanimir Varbanov (9): media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management doc: DT: venus: binding document for Qualcomm video driver MAINTAINERS: Add Qualcomm Venus video accelerator driver media: venus: adding core part and helper functions media: venus: vdec: add video decoder files media: venus: venc: add video encoder files media: venus: hfi: add Host Firmware Interface (HFI) media: venus: hfi: add Venus HFI files media: venus: enable building of Venus video driver Documentation/devicetree/bindings/media/qcom,venus.txt | 107 +++ MAINTAINERS|8 + drivers/media/platform/Kconfig | 13 + drivers/media/platform/Makefile|2 + drivers/media/platform/qcom/venus/Makefile | 11 + drivers/media/platform/qcom/venus/core.c | 388 +++ drivers/media/platform/qcom/venus/core.h | 323 + drivers/media/platform/qcom/venus/firmware.c | 109 +++ drivers/media/platform/qcom/venus/firmware.h | 22 + drivers/media/platform/qcom/venus/helpers.c| 727 drivers/media/platform/qcom/venus/helpers.h| 45 ++ drivers/media/platform/qcom/venus/hfi.c| 522 +++ drivers/media/platform/qcom/venus/hfi.h| 175 + drivers/media/platform/qcom/venus/hfi_cmds.c | 1255 +++ drivers/media/platform/qcom/venus/hfi_cmds.h | 304 + drivers/media/platform/qcom/venus/hfi_helper.h | 1050 + drivers/media/platform/qcom/venus/hfi_msgs.c | 1054 + drivers/media/platform/qcom/venus/hfi_msgs.h | 283 drivers/media/platform/qcom/venus/hfi_venus.c | 1571 drivers/media/platform/qcom/venus/hfi_venus.h | 23 + drivers/media/platform/qcom/venus/hfi_venus_io.h | 113 drivers/media/platform/qcom/venus/vdec.c | 1154 drivers/media/platform/qcom/venus/vdec.h | 23 + drivers/media/platform/qcom/venus/vdec_ctrls.c | 150 + drivers/media/platform/qcom/venus/venc.c | 1283 drivers/media/platform/qcom/venus/venc.h | 23 + drivers/media/platform/qcom/venus/venc_ctrls.c | 270 drivers/media/v4l2-core/v4l2-mem2mem.c | 37 ++ include/media/v4l2-mem2mem.h | 92 +++ 29 files changed, 11137 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt create mode 100644 drivers/media/platform/qcom/venus/Makefile create mode 100644 drivers/media/platform/qcom/venus/core.c create mode 100644 drivers/media/platform/qcom/venus/core.h create mode 100644 drivers/media/platform/qcom/venus/firmware.c create mode 100644 drivers/media/platform/qcom/venus/firmware.h create mode 100644 drivers/media/platform/qcom/venus/helpers.c create mode 100644 drivers/media/platform/qcom/venus/helpers.h create mode 100644 drivers/media/platform/qcom/venus/hfi.c create mode 100644 drivers/media/platform/qcom/venus/hfi.h create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.c create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.h create mode 100644 drivers/media/platform/qcom/venus/hfi_helper.h create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.c create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.h create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h create mode 100644 drivers/media/platform/qcom/venus/vdec.c create mode 100644 drivers/media/platform/qcom/venus/vdec.h create mode 100644 drivers/media/platform/qcom/venus/vdec_ctrls.c create mode 100644 drivers/media/platform/qcom/venus/venc.c create mode 100644 drivers/media/platform/qcom/venus/venc.h create mode 100644 drivers/media/platform/qcom/venus/venc_ctrls.c
Re: [media-pci-cx25821] question about value overwrite
On 05/19/2017 12:07 AM, Gustavo A. R. Silva wrote:
>
> Hello everybody,
>
> While looking into Coverity ID 1226903 I ran into the following piece
> of code at drivers/media/pci/cx25821/cx25821-medusa-video.c:393:
>
> 393int medusa_set_videostandard(struct cx25821_dev *dev)
> 394{
> 395int status = 0;
> 396u32 value = 0, tmp = 0;
> 397
> 398if (dev->tvnorm & V4L2_STD_PAL_BG || dev->tvnorm & V4L2_STD_PAL_DK)
> 399status = medusa_initialize_pal(dev);
> 400else
> 401status = medusa_initialize_ntsc(dev);
> 402
> 403/* Enable DENC_A output */
> 404value = cx25821_i2c_read(&dev->i2c_bus[0], DENC_A_REG_4, &tmp);
> 405value = setBitAtPos(value, 4);
> 406status = cx25821_i2c_write(&dev->i2c_bus[0], DENC_A_REG_4, value);
> 407
> 408/* Enable DENC_B output */
> 409value = cx25821_i2c_read(&dev->i2c_bus[0], DENC_B_REG_4, &tmp);
> 410value = setBitAtPos(value, 4);
> 411status = cx25821_i2c_write(&dev->i2c_bus[0], DENC_B_REG_4, value);
> 412
> 413return status;
> 414}
>
> The issue is that the value stored in variable _status_ at lines 399
> and 401 is overwritten by the one stored at line 406 and then at line
> 411, before it can be used.
>
> My question is if the original intention was to ORed the return
> values, something like in the following patch:
>
> index 0a9db05..226d14f 100644
> --- a/drivers/media/pci/cx25821/cx25821-medusa-video.c
> +++ b/drivers/media/pci/cx25821/cx25821-medusa-video.c
> @@ -403,12 +403,12 @@ int medusa_set_videostandard(struct cx25821_dev *dev)
> /* Enable DENC_A output */
> value = cx25821_i2c_read(&dev->i2c_bus[0], DENC_A_REG_4, &tmp);
> value = setBitAtPos(value, 4);
> - status = cx25821_i2c_write(&dev->i2c_bus[0], DENC_A_REG_4, value);
> + status |= cx25821_i2c_write(&dev->i2c_bus[0], DENC_A_REG_4, value);
>
> /* Enable DENC_B output */
> value = cx25821_i2c_read(&dev->i2c_bus[0], DENC_B_REG_4, &tmp);
> value = setBitAtPos(value, 4);
> - status = cx25821_i2c_write(&dev->i2c_bus[0], DENC_B_REG_4, value);
> + status |= cx25821_i2c_write(&dev->i2c_bus[0], DENC_B_REG_4, value);
>
> return status;
> }
This is a crappy driver, they just couldn't be bothered to check the error from
cx25821_i2c_read/write.
Strictly speaking the return value should be checked after every read/write and
returned in case of an error.
Not sure whether it is worth the effort fixing this.
Regards,
Hans
>
> What do you think?
>
> I'd really appreciate any comment on this.
>
> Thank you!
> --
> Gustavo A. R. Silva
>
>
>
>
Re: [PATCH v1] [media] atmel-isi: code cleanup
Hi Songjun,
It was an advice from Hans, I copy/paste the comment here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112338.html
>> + /* Enable stream on the sub device */
>> + ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 1);
>> + if (ret && ret != -ENOIOCTLCMD) {
>> + dev_err(dcmi->dev, "%s: Failed to start streaming, subdev
>> streamon error",
>> + __func__);
>> + goto err_release_buffers;
>> + }
>> +
>> + if (clk_enable(dcmi->mclk)) {
>> + dev_err(dcmi->dev, "%s: Failed to start streaming, cannot
>> enable clock",
>> + __func__);
>> + goto err_subdev_streamoff;
>> + }
>It feels more natural to me to first enable the clock, then call
>s_stream.
Please note that I have not tested code, but only reported changes done
in ST DCMI driver to reflect the same on ISI driver, would it be
possible that you check that it is still functional on your side ?
Best regards,
Hugues.
On 05/22/2017 07:02 AM, Wu, Songjun wrote:
> Hi Hugues,
>
> Thank you for your patch.
> Is it necessary to ensure ISI is clocked before starting sensor sub device?
>
> On 5/19/2017 20:08, Hugues FRUCHET wrote:
>> Adding Songjun and Ludovic as Atmel maintainers, sorry for inconvenience.
>>
>> On 05/19/2017 12:04 PM, Hugues Fruchet wrote:
>>> Ensure that ISI is clocked before starting sensor sub device.
>>> Remove un-needed type check in try_fmt().
>>> Use clamp() macro for hardware capabilities.
>>> Fix wrong tabulation to space.
>>>
>>> Signed-off-by: Hugues Fruchet
>>> ---
>>>drivers/media/platform/atmel/atmel-isi.c | 24
>>> ++--
>>>1 file changed, 10 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/atmel/atmel-isi.c
>>> b/drivers/media/platform/atmel/atmel-isi.c
>>> index e4867f8..7bf9f7d 100644
>>> --- a/drivers/media/platform/atmel/atmel-isi.c
>>> +++ b/drivers/media/platform/atmel/atmel-isi.c
>>> @@ -36,8 +36,8 @@
>>>#include "atmel-isi.h"
>>> -#define MAX_SUPPORT_WIDTH2048
>>> -#define MAX_SUPPORT_HEIGHT2048
>>> +#define MAX_SUPPORT_WIDTH2048U
>>> +#define MAX_SUPPORT_HEIGHT2048U
>>>#define MIN_FRAME_RATE15
>>>#define FRAME_INTERVAL_MILLI_SEC(1000 / MIN_FRAME_RATE)
>>> @@ -424,6 +424,8 @@ static int start_streaming(struct vb2_queue *vq,
>>> unsigned int count)
>>>struct frame_buffer *buf, *node;
>>>int ret;
>>> +pm_runtime_get_sync(isi->dev);
>>> +
>>>/* Enable stream on the sub device */
>>>ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
>>>if (ret && ret != -ENOIOCTLCMD) {
>>> @@ -431,8 +433,6 @@ static int start_streaming(struct vb2_queue *vq,
>>> unsigned int count)
>>>goto err_start_stream;
>>>}
>>> -pm_runtime_get_sync(isi->dev);
>>> -
>>>/* Reset ISI */
>>>ret = atmel_isi_wait_status(isi, WAIT_ISI_RESET);
>>>if (ret < 0) {
>>> @@ -455,10 +455,11 @@ static int start_streaming(struct vb2_queue
>>> *vq, unsigned int count)
>>>return 0;
>>>err_reset:
>>> -pm_runtime_put(isi->dev);
>>>v4l2_subdev_call(isi->entity.subdev, video, s_stream, 0);
>>>err_start_stream:
>>> +pm_runtime_put(isi->dev);
>>> +
>>>spin_lock_irq(&isi->irqlock);
>>>isi->active = NULL;
>>>/* Release all active buffers */
>>> @@ -566,20 +567,15 @@ static int isi_try_fmt(struct atmel_isi *isi,
>>> struct v4l2_format *f,
>>>};
>>>int ret;
>>> -if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>>> -return -EINVAL;
>>> -
>>>isi_fmt = find_format_by_fourcc(isi, pixfmt->pixelformat);
>>>if (!isi_fmt) {
>>>isi_fmt = isi->user_formats[isi->num_user_formats - 1];
>>>pixfmt->pixelformat = isi_fmt->fourcc;
>>>}
>>> -/* Limit to Atmel ISC hardware capabilities */
>>> -if (pixfmt->width > MAX_SUPPORT_WIDTH)
>>> -pixfmt->width = MAX_SUPPORT_WIDTH;
>>> -if (pixfmt->height > MAX_SUPPORT_HEIGHT)
>>> -pixfmt->height = MAX_SUPPORT_HEIGHT;
>>> +/* Limit to Atmel ISI hardware capabilities */
>>> +pixfmt->width = clamp(pixfmt->width, 0U, MAX_SUPPORT_WIDTH);
>>> +pixfmt->height = clamp(pixfmt->height, 0U, MAX_SUPPORT_HEIGHT);
>>>v4l2_fill_mbus_format(&format.format, pixfmt,
>>> isi_fmt->mbus_code);
>>>ret = v4l2_subdev_call(isi->entity.subdev, pad, set_fmt,
>>> @@ -1058,7 +1054,7 @@ static int isi_graph_notify_complete(struct
>>> v4l2_async_notifier *notifier)
>>>struct atmel_isi *isi = notifier_to_isi(notifier);
>>>int ret;
>>> -isi->vdev->ctrl_handler= isi->entity.subdev->ctrl_handler;
>>> +isi->vdev->ctrl_handler = isi->entity.subdev->ctrl_handler;
>>>ret = isi_formats_init(isi);
>>>if (ret) {
>>>dev_err(isi->dev, "No supported mediabus format found\n");
Re: [PATCH v1] [media] atmel-isi: code cleanup
On 5/22/2017 15:52, Hugues FRUCHET wrote:
Hi Songjun,
It was an advice from Hans, I copy/paste the comment here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112338.html
>> + /* Enable stream on the sub device */
>> + ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 1);
>> + if (ret && ret != -ENOIOCTLCMD) {
>> + dev_err(dcmi->dev, "%s: Failed to start streaming, subdev
>> streamon error",
>> + __func__);
>> + goto err_release_buffers;
>> + }
>> +
>> + if (clk_enable(dcmi->mclk)) {
>> + dev_err(dcmi->dev, "%s: Failed to start streaming, cannot
>> enable clock",
>> + __func__);
>> + goto err_subdev_streamoff;
>> + }
>It feels more natural to me to first enable the clock, then call
>s_stream.
Please note that I have not tested code, but only reported changes done
in ST DCMI driver to reflect the same on ISI driver, would it be
possible that you check that it is still functional on your side ?
Hi Hugues,
Thank you for your explanation.
It does not affect the function, but since it is more natural to first
enable the clock, then call s_stream, I think this patch has no problem.
Best regards,
Hugues.
On 05/22/2017 07:02 AM, Wu, Songjun wrote:
Hi Hugues,
Thank you for your patch.
Is it necessary to ensure ISI is clocked before starting sensor sub device?
On 5/19/2017 20:08, Hugues FRUCHET wrote:
Adding Songjun and Ludovic as Atmel maintainers, sorry for inconvenience.
On 05/19/2017 12:04 PM, Hugues Fruchet wrote:
Ensure that ISI is clocked before starting sensor sub device.
Remove un-needed type check in try_fmt().
Use clamp() macro for hardware capabilities.
Fix wrong tabulation to space.
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/atmel/atmel-isi.c | 24
++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isi.c
b/drivers/media/platform/atmel/atmel-isi.c
index e4867f8..7bf9f7d 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -36,8 +36,8 @@
#include "atmel-isi.h"
-#define MAX_SUPPORT_WIDTH2048
-#define MAX_SUPPORT_HEIGHT2048
+#define MAX_SUPPORT_WIDTH2048U
+#define MAX_SUPPORT_HEIGHT2048U
#define MIN_FRAME_RATE15
#define FRAME_INTERVAL_MILLI_SEC(1000 / MIN_FRAME_RATE)
@@ -424,6 +424,8 @@ static int start_streaming(struct vb2_queue *vq,
unsigned int count)
struct frame_buffer *buf, *node;
int ret;
+pm_runtime_get_sync(isi->dev);
+
/* Enable stream on the sub device */
ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
if (ret && ret != -ENOIOCTLCMD) {
@@ -431,8 +433,6 @@ static int start_streaming(struct vb2_queue *vq,
unsigned int count)
goto err_start_stream;
}
-pm_runtime_get_sync(isi->dev);
-
/* Reset ISI */
ret = atmel_isi_wait_status(isi, WAIT_ISI_RESET);
if (ret < 0) {
@@ -455,10 +455,11 @@ static int start_streaming(struct vb2_queue
*vq, unsigned int count)
return 0;
err_reset:
-pm_runtime_put(isi->dev);
v4l2_subdev_call(isi->entity.subdev, video, s_stream, 0);
err_start_stream:
+pm_runtime_put(isi->dev);
+
spin_lock_irq(&isi->irqlock);
isi->active = NULL;
/* Release all active buffers */
@@ -566,20 +567,15 @@ static int isi_try_fmt(struct atmel_isi *isi,
struct v4l2_format *f,
};
int ret;
-if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
-return -EINVAL;
-
isi_fmt = find_format_by_fourcc(isi, pixfmt->pixelformat);
if (!isi_fmt) {
isi_fmt = isi->user_formats[isi->num_user_formats - 1];
pixfmt->pixelformat = isi_fmt->fourcc;
}
-/* Limit to Atmel ISC hardware capabilities */
-if (pixfmt->width > MAX_SUPPORT_WIDTH)
-pixfmt->width = MAX_SUPPORT_WIDTH;
-if (pixfmt->height > MAX_SUPPORT_HEIGHT)
-pixfmt->height = MAX_SUPPORT_HEIGHT;
+/* Limit to Atmel ISI hardware capabilities */
+pixfmt->width = clamp(pixfmt->width, 0U, MAX_SUPPORT_WIDTH);
+pixfmt->height = clamp(pixfmt->height, 0U, MAX_SUPPORT_HEIGHT);
v4l2_fill_mbus_format(&format.format, pixfmt,
isi_fmt->mbus_code);
ret = v4l2_subdev_call(isi->entity.subdev, pad, set_fmt,
@@ -1058,7 +1054,7 @@ static int isi_graph_notify_complete(struct
v4l2_async_notifier *notifier)
struct atmel_isi *isi = notifier_to_isi(notifier);
int ret;
-isi->vdev->ctrl_handler= isi->entity.subdev->ctrl_handler;
+isi->vdev->ctrl_handler = isi->entity.subdev->ctrl_handler;
ret = isi_formats_init(isi);
if (ret) {
dev_err(isi->dev, "No supported mediabus format found\n");
[PATCH] [media] em28xx: fix spelling mistake: "missdetected" -> "misdetected"
From: Colin Ian King Trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King --- drivers/media/usb/em28xx/em28xx-cards.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c index a12b599a1fa2..146341aeb782 100644 --- a/drivers/media/usb/em28xx/em28xx-cards.c +++ b/drivers/media/usb/em28xx/em28xx-cards.c @@ -2855,7 +2855,7 @@ static int em28xx_hint_board(struct em28xx *dev) "Your board has no unique USB ID.\n" "A hint were successfully done, based on eeprom hash.\n" "This method is not 100%% failproof.\n" - "If the board were missdetected, please email this log to:\n" + "If the board were misdetected, please email this log to:\n" "\tV4L Mailing List \n" "Board detected as %s\n", em28xx_boards[dev->model].name); @@ -2885,7 +2885,7 @@ static int em28xx_hint_board(struct em28xx *dev) "Your board has no unique USB ID.\n" "A hint were successfully done, based on i2c devicelist hash.\n" "This method is not 100%% failproof.\n" - "If the board were missdetected, please email this log to:\n" + "If the board were misdetected, please email this log to:\n" "\tV4L Mailing List \n" "Board detected as %s\n", em28xx_boards[dev->model].name); -- 2.11.0
Re: [PATCH] media: platform: s3c-camif: fix function prototype
On 05/04/2017 11:42 PM, Gustavo A. R. Silva wrote:
> Fix function prototype so the position of arguments camif->colorfx_cb and
> camif->colorfx_cr match the order of the parameters when calling
> camif_hw_set_effect() function.
>
> Addresses-Coverity-ID: 1248800
> Addresses-Coverity-ID: 1269141
> Cc: Sylwester Nawrocki
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/media/platform/s3c-camif/camif-regs.c | 2 +-
> drivers/media/platform/s3c-camif/camif-regs.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s3c-camif/camif-regs.c
> b/drivers/media/platform/s3c-camif/camif-regs.c
> index 812fb3a..d70ffef 100644
> --- a/drivers/media/platform/s3c-camif/camif-regs.c
> +++ b/drivers/media/platform/s3c-camif/camif-regs.c
> @@ -58,7 +58,7 @@ void camif_hw_set_test_pattern(struct camif_dev *camif,
> unsigned int pattern)
> }
>
> void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
> - unsigned int cr, unsigned int cb)
> + unsigned int cb, unsigned int cr)
> {
> static const struct v4l2_control colorfx[] = {
> { V4L2_COLORFX_NONE,CIIMGEFF_FIN_BYPASS },
This will also affect this line:
cfg |= cr | (cb << 13);
cr and cb are now swapped so this will result in a different color.
Sylwester, who is wrong here: the prototype or how this function is called?
I suspect that Gustavo is right and that the prototype is wrong. But in that
case this patch should also change the cfg assignment.
Regards,
Hans
> diff --git a/drivers/media/platform/s3c-camif/camif-regs.h
> b/drivers/media/platform/s3c-camif/camif-regs.h
> index 5ad36c1..dfb49a5 100644
> --- a/drivers/media/platform/s3c-camif/camif-regs.h
> +++ b/drivers/media/platform/s3c-camif/camif-regs.h
> @@ -255,7 +255,7 @@ void camif_hw_set_output_dma(struct camif_vp *vp);
> void camif_hw_set_target_format(struct camif_vp *vp);
> void camif_hw_set_test_pattern(struct camif_dev *camif, unsigned int
> pattern);
> void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
> - unsigned int cr, unsigned int cb);
> + unsigned int cb, unsigned int cr);
> void camif_hw_set_output_addr(struct camif_vp *vp, struct camif_addr *paddr,
> int index);
> void camif_hw_dump_regs(struct camif_dev *camif, const char *label);
>
Re: [PATCH v3 0/3] Fix mdp device tree
On 05/12/2017 05:22 AM, Minghsiu Tsai wrote: Who should take care of the dtsi changes? I'm not sure who maintains the mdp dts. The driver change and the dtsi change need to be in sync, so it is probably easiest to merge this via one tree. Here is my Acked-by for these three patches: Acked-by: Hans Verkuil I can take all three, provided I have the Ack of the mdp dts maintainer. Or it can go through him with my Ack. Regards, Hans > Changes in v3: > - Upload patches again because forget to add v2 in title > > Changes in v2: > - Update commit message > > If the mdp_* nodes are under an mdp sub-node, their corresponding > platform device does not automatically get its iommu assigned properly. > > Fix this by moving the mdp component nodes up a level such that they are > siblings of mdp and all other SoC subsystems. This also simplifies the > device tree. > > Although it fixes iommu assignment issue, it also break compatibility > with old device tree. So, the patch in driver is needed to iterate over > sibling mdp device nodes, not child ones, to keep driver work properly. > > Daniel Kurtz (2): > arm64: dts: mt8173: Fix mdp device tree > media: mtk-mdp: Fix mdp device tree > > Minghsiu Tsai (1): > dt-bindings: mt8173: Fix mdp device tree > > .../devicetree/bindings/media/mediatek-mdp.txt | 12 +- > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 > ++--- > drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +- > 3 files changed, 64 insertions(+), 76 deletions(-) >
Re: [PATCH 08/12] Add USB quirk for HVR-950q to avoid intermittent device resets
Hi Devin,
On 04/20/2017 01:13 AM, Devin Heitmueller wrote:
> The USB core and sysfs will attempt to enumerate certain parameters
> which are unsupported by the au0828 - causing inconsistent behavior
> and sometimes causing the chip to reset. Avoid making these calls.
>
> This problem manifested as intermittent cases where the au8522 would
> be reset on analog video startup, in particular when starting up ALSA
> audio streaming in parallel - the sysfs entries created by
> snd-usb-audio on streaming startup would result in unsupported control
> messages being sent during tuning which would put the chip into an
> unknown state.
>
> Signed-off-by: Devin Heitmueller
I've accepted the other patches in this patch series for the media subsystem,
but this patch should go through the USB subsystem. Cc-ed linux-usb.
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/usb/core/quirks.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index 96b21b0..3116edf 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -223,6 +223,10 @@
> /* Blackmagic Design UltraStudio SDI */
> { USB_DEVICE(0x1edb, 0xbd4f), .driver_info = USB_QUIRK_NO_LPM },
>
> + /* Hauppauge HVR-950q */
> + { USB_DEVICE(0x2040, 0x7200), .driver_info =
> + USB_QUIRK_CONFIG_INTF_STRINGS },
> +
> /* INTEL VALUE SSD */
> { USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
>
>
[GIT PULL FOR v4.13] Various fixes
Various fixes for 4.13. The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030: [media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update() (2017-05-19 07:12:05 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.13a for you to fetch changes up to 196cb7e2b8becf9f4e81457d4335a1c2beee41bc: em28xx: fix spelling mistake: "missdetected" -> "misdetected" (2017-05-22 11:18:41 +0200) Benjamin Gaignard (2): cec: stih: allow to use max CEC logical addresses cec: stih: fix typos in comments Colin Ian King (2): cx18: fix spelling mistake: "demodualtor" -> "demodulator" em28xx: fix spelling mistake: "missdetected" -> "misdetected" Daniel Roschka (1): uvcvideo: Quirk for webcam in MacBook Pro 2016 Devin Heitmueller (12): cx88: Fix regression in initial video standard setting mxl111sf: Fix driver to use heap allocate buffers for USB messages au8522: don't attempt to configure unsupported VBI slicer au8522: don't touch i2c master registers on au8522 au8522: rework setup of audio routing au8522: remove note about VBI not being implemented au8522: remove leading bit for register writes au8522 Remove 0x4 bit for register reads au8522: fix lock detection to be more reliable. xc5000: Don't spin waiting for analog lock au8522: Set the initial modulation au0828: Add timer to restart TS stream if no data arrives on bulk endpoint Frank Schaefer (1): em28xx: fix+improve the register (usb control message) debugging Gustavo A. R. Silva (2): media: platform: coda: remove variable self assignment media: i2c: initialize scalar variables Hans Verkuil (1): v4l2-ioctl.c: always copy G/S_EDID result Johan Hovold (1): usbvision: add missing USB-descriptor endianness conversions Oleh Kravchenko (1): cx231xx: Initial support Astrometa T2hybrid Pan Bian (3): m5602_s5k83a: check return value of kthread_create cobalt: fix unchecked return values cx25840: fix unchecked return values Peter Boström (1): uvcvideo: Add iFunction or iInterface to device names. Petr Cvek (4): pxa_camera: Add remaining Bayer 8 formats pxa_camera: Fix incorrect test in the image size generation pxa_camera: Add (un)subscribe_event ioctl pxa_camera: Fix a call with an uninitialized device pointer Philipp Zabel (1): coda: simplify optional reset handling Rene Hickersberger (1): media: s5p-cec: Fixed spelling mistake Songjun Wu (1): atmel-isc: Set the default DMA memory burst size Thomas Hollstegge (1): em28xx: support for Sundtek MediaTV Digital Home drivers/media/dvb-frontends/au8522_common.c | 1 + drivers/media/dvb-frontends/au8522_decoder.c | 74 +-- drivers/media/dvb-frontends/au8522_dig.c | 215 +++--- drivers/media/i2c/cx25840/cx25840-core.c | 36 + drivers/media/i2c/ov2659.c| 3 +- drivers/media/pci/cobalt/cobalt-driver.c | 2 + drivers/media/pci/cx18/cx18-dvb.c | 2 +- drivers/media/pci/cx88/cx88-cards.c | 9 ++- drivers/media/pci/cx88/cx88-video.c | 2 +- drivers/media/platform/atmel/atmel-isc.c | 23 +++--- drivers/media/platform/coda/coda-common.c | 13 +--- drivers/media/platform/pxa_camera.c | 51 ++--- drivers/media/platform/s5p-cec/s5p_cec.c | 2 +- drivers/media/platform/sti/cec/stih-cec.c | 7 +- drivers/media/tuners/xc5000.c | 26 +-- drivers/media/usb/au0828/au0828-dvb.c | 30 drivers/media/usb/au0828/au0828.h | 2 + drivers/media/usb/cx231xx/Kconfig | 2 + drivers/media/usb/cx231xx/cx231xx-cards.c | 34 + drivers/media/usb/cx231xx/cx231xx-dvb.c | 49 + drivers/media/usb/cx231xx/cx231xx.h | 1 + drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c | 4 +- drivers/media/usb/dvb-usb-v2/mxl111sf.c | 32 drivers/media/usb/dvb-usb-v2/mxl111sf.h | 8 +- drivers/media/usb/em28xx/em28xx-cards.c | 19 - drivers/media/usb/em28xx/em28xx-core.c| 35 - drivers/media/usb/em28xx/em28xx-dvb.c | 1 + drivers/media/usb/em28xx/em28xx.h | 1 + drivers/media/usb/gspca/m5602/m5602_s5k83a.c | 5 ++ drivers/media/usb/usbvision/usbvision-video.c | 4 +- drivers/media/usb/uvc/uvc_driver.c| 34 - drivers/media/v4l2-core/v4l2-ioctl.c | 31 +--- 32 files changed, 462 insertions(+), 296 deletions(-)
[GIT PULL FOR v4.12] Fix stupid rainshadow bug
Let's fix this serious bug before it ends up in the 4.12 release. Regards, Hans The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030: [media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update() (2017-05-19 07:12:05 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.12j for you to fetch changes up to 71eb916453ed806ee105ef896b8f02f7eab2d4fc: rainshadow-cec: ensure exit_loop is intialized (2017-05-22 10:39:11 +0200) Colin Ian King (1): rainshadow-cec: ensure exit_loop is intialized drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH 14/16] ASoC: blackfin: Convert to copy_silence ops
On Sun, May 21, 2017 at 10:09:48PM +0200, Takashi Iwai wrote: > Replace the copy and the silence ops with the new merged ops. > The silence is performed only when CONFIG_SND_BF5XX_MMAP_SUPPORT is > set (since copy_silence ops is set only with this config), so in > bf5xx-ac97.c we have a bit tricky macro for a slight optimization. > > Note that we don't need to take in_kernel into account on this > architecture, so the conversion is easy otherwise. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [RFC 0/2] Synopsys Designware HDMI Video Capture Controller + PHY
Hi Hans, On 21-04-2017 10:53, Jose Abreu wrote: > Hi All, > > This is a RFC series that is intended to collect comments regarding the > Synopsys Designware HDMI RX controller and Synopsys Designware HDMI RX e405 > PHY > drivers. > > The Synopsys Designware HDMI RX controller is an HDMI receiver controller that > is responsible to process digital data that comes from a phy. The final result > is a stream of raw video data that can then be connected to a video DMA, for > example, and transfered into RAM so that it can be displayed. > > The controller + phy available in this series natively support all HDMI 1.4 > and > HDMI 2.0 modes, including deep color. Although, the driver is quite in its > initial stage and unfortunatelly only non deep color modes are supported. > Also, > audio is not yet supported in the driver (the controller has several audio > output interfaces). > > Feel free to take a look at this series and please leave a comment! I can > expand a little bit more about design decisions and would like to know wether > these were the best choices. > > With best regards, > Jose Miguel Abreu > > Jose Abreu (2): > [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver > [media] platform: Add Synopsys Designware HDMI RX Controller Driver > > Cc: Carlos Palminha > Cc: Mauro Carvalho Chehab > Cc: Hans Verkuil > Cc: linux-ker...@vger.kernel.org > Cc: linux-media@vger.kernel.org > > drivers/media/platform/Kconfig|2 + > drivers/media/platform/Makefile |2 + > drivers/media/platform/dwc/Kconfig| 17 + > drivers/media/platform/dwc/Makefile |2 + > drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 879 > drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 ++ > drivers/media/platform/dwc/dw-hdmi-rx.c | 1396 > + > drivers/media/platform/dwc/dw-hdmi-rx.h | 313 ++ > include/media/dwc/dw-hdmi-phy-pdata.h | 64 ++ > include/media/dwc/dw-hdmi-rx-pdata.h | 50 + > 10 files changed, 2788 insertions(+) > create mode 100644 drivers/media/platform/dwc/Kconfig > create mode 100644 drivers/media/platform/dwc/Makefile > create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c > create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h > create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c > create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h > create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h > create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h > Sorry for pinging but could you review this rfc series? This is not for the controller I mentioned a while ago, its for a different one which I had a few free time to make a driver. Though, the behavior and phy interface is similar, and the phy driver used is the same also. Best regards, Jose Miguel Abreu
Re: [RFC 1/2] [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver
On 04/21/2017 11:53 AM, Jose Abreu wrote: > This adds support for the Synopsys Designware HDMI RX PHY e405. This > phy receives and decodes HDMI video that is delivered to a controller. > > Main features included in this driver are: > - Equalizer algorithm that chooses the phy best settings > according to the detected HDMI cable characteristics. > - Support for scrambling > - Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz). > > The driver was implemented as a standalone V4L2 subdevice and the > phy interface with the controller was implemented using V4L2 ioctls. I > do not know if this is the best option but it is not possible to use the > existing API functions directly as we need specific functions that will > be called by the controller at specific configuration stages. > > There is also a bidirectional communication between controller and phy: > The phy must provide functions that the controller will call (i.e. > configuration functions) and the controller must provide read/write > callbacks, as well as other specific functions. > > Signed-off-by: Jose Abreu > Cc: Carlos Palminha > Cc: Mauro Carvalho Chehab > Cc: Hans Verkuil > Cc: linux-ker...@vger.kernel.org > Cc: linux-media@vger.kernel.org > --- > drivers/media/platform/Kconfig| 2 + > drivers/media/platform/Makefile | 2 + > drivers/media/platform/dwc/Kconfig| 8 + > drivers/media/platform/dwc/Makefile | 1 + > drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 879 > ++ > drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 ++ > include/media/dwc/dw-hdmi-phy-pdata.h | 64 ++ > 7 files changed, 1019 insertions(+) > create mode 100644 drivers/media/platform/dwc/Kconfig > create mode 100644 drivers/media/platform/dwc/Makefile > create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c > create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h > create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index ac026ee..5178229 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -33,6 +33,8 @@ source "drivers/media/platform/omap/Kconfig" > > source "drivers/media/platform/blackfin/Kconfig" > > +source "drivers/media/platform/dwc/Kconfig" > + > config VIDEO_SH_VOU > tristate "SuperH VOU video output driver" > depends on MEDIA_CAMERA_SUPPORT > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile > index 63303d6..50bc148 100644 > --- a/drivers/media/platform/Makefile > +++ b/drivers/media/platform/Makefile > @@ -77,3 +77,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec/ > obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/ > > obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)+= mtk-jpeg/ > + > +obj-y+= dwc/ > diff --git a/drivers/media/platform/dwc/Kconfig > b/drivers/media/platform/dwc/Kconfig > new file mode 100644 > index 000..361d38d > --- /dev/null > +++ b/drivers/media/platform/dwc/Kconfig > @@ -0,0 +1,8 @@ > +config VIDEO_DWC_HDMI_PHY_E405 > + tristate "Synopsys Designware HDMI RX PHY e405 driver" > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + help > + Support for Synopsys Designware HDMI RX PHY. Version is e405. > + > + To compile this driver as a module, choose M here. The module > + will be called dw-hdmi-phy-e405. > diff --git a/drivers/media/platform/dwc/Makefile > b/drivers/media/platform/dwc/Makefile > new file mode 100644 > index 000..fc3b62c > --- /dev/null > +++ b/drivers/media/platform/dwc/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o > diff --git a/drivers/media/platform/dwc/dw-hdmi-phy-e405.c > b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c > new file mode 100644 > index 000..dc00677 > --- /dev/null > +++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c > @@ -0,0 +1,879 @@ > +/* > + * Synopsys Designware HDMI PHY E405 driver > + * > + * This Synopsys dw-phy-e405 software and associated documentation > + * (hereinafter the "Software") is an unsupported proprietary work of > + * Synopsys, Inc. unless otherwise expressly agreed to in writing between > + * Synopsys and you. The Software IS NOT an item of Licensed Software or a > + * Licensed Product under any End User Software License Agreement or > + * Agreement for Licensed Products with Synopsys or any supplement thereto. > + * Synopsys is a registered trademark of Synopsys, Inc. Other names included > + * in the SOFTWARE may be the trademarks of their respective owners. > + * > + * The contents of this file are dual-licensed; you may select either > version 2 > + * of the GNU General Public License (“GPL”) or the MIT license (“MIT”). > + * > + * Copyright (c) 2017 Synopsys, Inc. and/or its affiliates. > + * > + * THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRES
Re: [RFC 1/2] [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver
Hi Hans, Thanks for the review! On 22-05-2017 11:04, Hans Verkuil wrote: > On 04/21/2017 11:53 AM, Jose Abreu wrote: >> This adds support for the Synopsys Designware HDMI RX PHY e405. This >> phy receives and decodes HDMI video that is delivered to a controller. >> >> Main features included in this driver are: >> - Equalizer algorithm that chooses the phy best settings >> according to the detected HDMI cable characteristics. >> - Support for scrambling >> - Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz). >> >> The driver was implemented as a standalone V4L2 subdevice and the >> phy interface with the controller was implemented using V4L2 ioctls. I >> do not know if this is the best option but it is not possible to use the >> existing API functions directly as we need specific functions that will >> be called by the controller at specific configuration stages. >> >> There is also a bidirectional communication between controller and phy: >> The phy must provide functions that the controller will call (i.e. >> configuration functions) and the controller must provide read/write >> callbacks, as well as other specific functions. >> >> Signed-off-by: Jose Abreu >> Cc: Carlos Palminha >> Cc: Mauro Carvalho Chehab >> Cc: Hans Verkuil >> Cc: linux-ker...@vger.kernel.org >> Cc: linux-media@vger.kernel.org >> --- >> drivers/media/platform/Kconfig| 2 + >> drivers/media/platform/Makefile | 2 + >> drivers/media/platform/dwc/Kconfig| 8 + >> drivers/media/platform/dwc/Makefile | 1 + >> drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 879 >> ++ >> drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 ++ >> include/media/dwc/dw-hdmi-phy-pdata.h | 64 ++ >> 7 files changed, 1019 insertions(+) >> create mode 100644 drivers/media/platform/dwc/Kconfig >> create mode 100644 drivers/media/platform/dwc/Makefile >> create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c >> create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h >> create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h >> >> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig >> index ac026ee..5178229 100644 >> --- a/drivers/media/platform/Kconfig >> +++ b/drivers/media/platform/Kconfig >> @@ -33,6 +33,8 @@ source "drivers/media/platform/omap/Kconfig" >> >> source "drivers/media/platform/blackfin/Kconfig" >> >> +source "drivers/media/platform/dwc/Kconfig" >> + >> config VIDEO_SH_VOU >> tristate "SuperH VOU video output driver" >> depends on MEDIA_CAMERA_SUPPORT >> diff --git a/drivers/media/platform/Makefile >> b/drivers/media/platform/Makefile >> index 63303d6..50bc148 100644 >> --- a/drivers/media/platform/Makefile >> +++ b/drivers/media/platform/Makefile >> @@ -77,3 +77,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/ >> obj-$(CONFIG_VIDEO_MEDIATEK_MDP)+= mtk-mdp/ >> >> obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk-jpeg/ >> + >> +obj-y += dwc/ >> diff --git a/drivers/media/platform/dwc/Kconfig >> b/drivers/media/platform/dwc/Kconfig >> new file mode 100644 >> index 000..361d38d >> --- /dev/null >> +++ b/drivers/media/platform/dwc/Kconfig >> @@ -0,0 +1,8 @@ >> +config VIDEO_DWC_HDMI_PHY_E405 >> +tristate "Synopsys Designware HDMI RX PHY e405 driver" >> +depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API >> +help >> + Support for Synopsys Designware HDMI RX PHY. Version is e405. >> + >> + To compile this driver as a module, choose M here. The module >> + will be called dw-hdmi-phy-e405. >> diff --git a/drivers/media/platform/dwc/Makefile >> b/drivers/media/platform/dwc/Makefile >> new file mode 100644 >> index 000..fc3b62c >> --- /dev/null >> +++ b/drivers/media/platform/dwc/Makefile >> @@ -0,0 +1 @@ >> +obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o >> diff --git a/drivers/media/platform/dwc/dw-hdmi-phy-e405.c >> b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c >> new file mode 100644 >> index 000..dc00677 >> --- /dev/null >> +++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c >> @@ -0,0 +1,879 @@ >> +/* >> + * Synopsys Designware HDMI PHY E405 driver >> + * >> + * This Synopsys dw-phy-e405 software and associated documentation >> + * (hereinafter the "Software") is an unsupported proprietary work of >> + * Synopsys, Inc. unless otherwise expressly agreed to in writing between >> + * Synopsys and you. The Software IS NOT an item of Licensed Software or a >> + * Licensed Product under any End User Software License Agreement or >> + * Agreement for Licensed Products with Synopsys or any supplement thereto. >> + * Synopsys is a registered trademark of Synopsys, Inc. Other names included >> + * in the SOFTWARE may be the trademarks of their respective owners. >> + * >> + * The contents of this file are dual-licensed; you may select either >> version 2 >> + * of the GNU General Public License (“GPL”)
Re: [RFC 2/2] [media] platform: Add Synopsys Designware HDMI RX Controller Driver
On 04/21/2017 11:53 AM, Jose Abreu wrote: > This is an initial submission for the Synopsys Designware HDMI RX > Controller Driver. This driver interacts with a phy driver so that > a communication between them is created and a video pipeline is > configured. > > The controller + phy pipeline can then be integrated into a fully > featured system that can be able to receive video up to 4k@60Hz > with deep color 48bit RGB, depending on the platform. Althoug, Typo: Although > this initial version does not yet handle deep color modes. > > This driver was implemented as a standard V4L2 subdevice and its > main features are: > - Internal state machine that reconfigures phy until the > video is not stable > - JTAG communication with phy > - Inter-module communication with phy driver > - Debug write/read ioctls > > Some notes: > - RX sense controller (cable connection/disconnection) must > be handled by the platform wrapper as this is not integrated > into the controller RTL > - The same goes for EDID ROM's > - ZCAL calibration is needed only in FPGA platforms, in ASIC > this is not needed What is ZCAL? > - The state machine is not an ideal solution as it creates a > kthread but it is needed because some sources might not be > very stable at sending the video (i.e. we must react > accordingly). I can guarantee that sources can be unstable, based on years of painful experience with HDMI receivers :-) > > Signed-off-by: Jose Abreu > Cc: Carlos Palminha > Cc: Mauro Carvalho Chehab > Cc: Hans Verkuil > Cc: linux-ker...@vger.kernel.org > Cc: linux-media@vger.kernel.org > --- > drivers/media/platform/dwc/Kconfig |9 + > drivers/media/platform/dwc/Makefile |1 + > drivers/media/platform/dwc/dw-hdmi-rx.c | 1396 > +++ > drivers/media/platform/dwc/dw-hdmi-rx.h | 313 +++ > include/media/dwc/dw-hdmi-rx-pdata.h| 50 ++ > 5 files changed, 1769 insertions(+) > create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c > create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h > create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h > > diff --git a/drivers/media/platform/dwc/Kconfig > b/drivers/media/platform/dwc/Kconfig > index 361d38d..11efa23 100644 > --- a/drivers/media/platform/dwc/Kconfig > +++ b/drivers/media/platform/dwc/Kconfig > @@ -6,3 +6,12 @@ config VIDEO_DWC_HDMI_PHY_E405 > > To compile this driver as a module, choose M here. The module > will be called dw-hdmi-phy-e405. > + > +config VIDEO_DWC_HDMI_RX > + tristate "Synopsys Designware HDMI Receiver driver" > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + help > + Support for Synopsys Designware HDMI RX controller. > + > + To compile this driver as a module, choose M here. The module > + will be called dw-hdmi-rx. > diff --git a/drivers/media/platform/dwc/Makefile > b/drivers/media/platform/dwc/Makefile > index fc3b62c..cd04ca9 100644 > --- a/drivers/media/platform/dwc/Makefile > +++ b/drivers/media/platform/dwc/Makefile > @@ -1 +1,2 @@ > obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o > +obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o > diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c > b/drivers/media/platform/dwc/dw-hdmi-rx.c > new file mode 100644 > index 000..6bfbc86 > --- /dev/null > +++ b/drivers/media/platform/dwc/dw-hdmi-rx.c > @@ -0,0 +1,1396 @@ > +/* > + * Synopsys Designware HDMI Receiver controller driver > + * > + * This Synopsys dw-hdmi-rx software and associated documentation > + * (hereinafter the "Software") is an unsupported proprietary work of > + * Synopsys, Inc. unless otherwise expressly agreed to in writing between > + * Synopsys and you. The Software IS NOT an item of Licensed Software or a > + * Licensed Product under any End User Software License Agreement or > + * Agreement for Licensed Products with Synopsys or any supplement thereto. > + * Synopsys is a registered trademark of Synopsys, Inc. Other names included > + * in the SOFTWARE may be the trademarks of their respective owners. > + * > + * The contents of this file are dual-licensed; you may select either > version 2 > + * of the GNU General Public License (“GPL”) or the MIT license (“MIT”). > + * > + * Copyright (c) 2017 Synopsys, Inc. and/or its affiliates. > + * > + * THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > + * IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL > THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE > + * ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +#include > +#include > +#include > +#include > +#incl
[PATCH] atomisp2: off by one in atomisp_s_input()
The isp->inputs[] array has isp->input_cnt elements which have been
initialized so this > should be >=.
This bug is harmless. The check against ATOM_ISP_MAX_INPUTS prevents us
from reading beyond the end of the array. The uninitialized elements
are zeroed out so we will end up returning -EINVAL a few lines later
because the .camera pointer is NULL.
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
index 6064bb823a47..aa0526ebaff1 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
@@ -683,7 +683,7 @@ static int atomisp_s_input(struct file *file, void *fh,
unsigned int input)
int ret;
rt_mutex_lock(&isp->mutex);
- if (input >= ATOM_ISP_MAX_INPUTS || input > isp->input_cnt) {
+ if (input >= ATOM_ISP_MAX_INPUTS || input >= isp->input_cnt) {
dev_dbg(isp->dev, "input_cnt: %d\n", isp->input_cnt);
ret = -EINVAL;
goto error;
Re: [PATCH v3 0/3] Fix mdp device tree
On 22/05/17 11:09, Hans Verkuil wrote: On 05/12/2017 05:22 AM, Minghsiu Tsai wrote: Who should take care of the dtsi changes? I'm not sure who maintains the mdp dts. I will take care of the dtsi patches. The driver change and the dtsi change need to be in sync, so it is probably easiest to merge this via one tree. Here is my Acked-by for these three patches: Acked-by: Hans Verkuil I can take all three, provided I have the Ack of the mdp dts maintainer. Or it can go through him with my Ack. I think we should provide backwards compability instead, as proposed here: http://lists.infradead.org/pipermail/linux-mediatek/2017-May/008811.html If this change is ok for you, please let Minghsiu know so that he can provide a v4. Regards, Matthias Regards, Hans Changes in v3: - Upload patches again because forget to add v2 in title Changes in v2: - Update commit message If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also simplifies the device tree. Although it fixes iommu assignment issue, it also break compatibility with old device tree. So, the patch in driver is needed to iterate over sibling mdp device nodes, not child ones, to keep driver work properly. Daniel Kurtz (2): arm64: dts: mt8173: Fix mdp device tree media: mtk-mdp: Fix mdp device tree Minghsiu Tsai (1): dt-bindings: mt8173: Fix mdp device tree .../devicetree/bindings/media/mediatek-mdp.txt | 12 +- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 ++--- drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +- 3 files changed, 64 insertions(+), 76 deletions(-)
Re: [PATCH v3 0/3] Fix mdp device tree
On 05/22/2017 04:14 PM, Matthias Brugger wrote: > > > On 22/05/17 11:09, Hans Verkuil wrote: >> On 05/12/2017 05:22 AM, Minghsiu Tsai wrote: >> >> Who should take care of the dtsi changes? I'm not sure who maintains the mdp >> dts. > > I will take care of the dtsi patches. > >> >> The driver change and the dtsi change need to be in sync, so it is probably >> easiest >> to merge this via one tree. >> >> Here is my Acked-by for these three patches: >> >> Acked-by: Hans Verkuil >> >> I can take all three, provided I have the Ack of the mdp dts maintainer. Or >> it can >> go through him with my Ack. >> > > I think we should provide backwards compability instead, as proposed here: > http://lists.infradead.org/pipermail/linux-mediatek/2017-May/008811.html > > If this change is ok for you, please let Minghsiu know so that he can > provide a v4. That's a lot better. In that case I can take the media patches and you the dts. I'll wait for the v4. Regards, Hans > > Regards, > Matthias > >> Regards, >> >> Hans >> >>> Changes in v3: >>> - Upload patches again because forget to add v2 in title >>> >>> Changes in v2: >>> - Update commit message >>> >>> If the mdp_* nodes are under an mdp sub-node, their corresponding >>> platform device does not automatically get its iommu assigned properly. >>> >>> Fix this by moving the mdp component nodes up a level such that they are >>> siblings of mdp and all other SoC subsystems. This also simplifies the >>> device tree. >>> >>> Although it fixes iommu assignment issue, it also break compatibility >>> with old device tree. So, the patch in driver is needed to iterate over >>> sibling mdp device nodes, not child ones, to keep driver work properly. >>> >>> Daniel Kurtz (2): >>>arm64: dts: mt8173: Fix mdp device tree >>>media: mtk-mdp: Fix mdp device tree >>> >>> Minghsiu Tsai (1): >>>dt-bindings: mt8173: Fix mdp device tree >>> >>> .../devicetree/bindings/media/mediatek-mdp.txt | 12 +- >>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 >>> ++--- >>> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +- >>> 3 files changed, 64 insertions(+), 76 deletions(-) >>> >>
[PATCH v3 5/5] drm: rcar-du: Map memory through the VSP device
From: Laurent Pinchart
For planes handled by a VSP instance, map the framebuffer memory through
the VSP to ensure proper IOMMU handling.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
[Kieran: Fix infinite loop on fail]
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 74 +---
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +-
2 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..7f8b03fc2b69 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -19,7 +19,9 @@
#include
#include
+#include
#include
+#include
#include
#include
@@ -170,12 +172,9 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
cfg.dst.width = state->state.crtc_w;
cfg.dst.height = state->state.crtc_h;
- for (i = 0; i < state->format->planes; ++i) {
- struct drm_gem_cma_object *gem;
-
- gem = drm_fb_cma_get_gem_obj(fb, i);
- cfg.mem[i] = gem->paddr + fb->offsets[i];
- }
+ for (i = 0; i < state->format->planes; ++i)
+ cfg.mem[i] = sg_dma_address(state->sg_tables[i].sgl)
+ + fb->offsets[i];
for (i = 0; i < ARRAY_SIZE(formats_kms); ++i) {
if (formats_kms[i] == state->format->fourcc) {
@@ -187,6 +186,67 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
vsp1_du_atomic_update(plane->vsp->vsp, plane->index, &cfg);
}
+static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+ struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+ struct rcar_du_device *rcdu = vsp->dev;
+ unsigned int i;
+ int ret;
+
+ if (!state->fb)
+ return 0;
+
+ for (i = 0; i < rstate->format->planes; ++i) {
+ struct drm_gem_cma_object *gem =
+ drm_fb_cma_get_gem_obj(state->fb, i);
+ struct sg_table *sgt = &rstate->sg_tables[i];
+
+ ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr, gem->paddr,
+ gem->base.size);
+ if (ret)
+ goto fail;
+
+ ret = vsp1_du_map_sg(vsp->vsp, sgt);
+ if (!ret) {
+ sg_free_table(sgt);
+ ret = -ENOMEM;
+ goto fail;
+ }
+ }
+
+ return 0;
+
+fail:
+ while (i--) {
+ struct sg_table *sgt = &rstate->sg_tables[i];
+
+ vsp1_du_unmap_sg(vsp->vsp, sgt);
+ sg_free_table(sgt);
+ }
+
+ return ret;
+}
+
+static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+ struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+ struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+ unsigned int i;
+
+ if (!state->fb)
+ return;
+
+ for (i = 0; i < rstate->format->planes; ++i) {
+ struct sg_table *sgt = &rstate->sg_tables[i];
+
+ vsp1_du_unmap_sg(vsp->vsp, sgt);
+ sg_free_table(sgt);
+ }
+}
+
static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
@@ -227,6 +287,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
drm_plane *plane,
}
static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
+ .prepare_fb = rcar_du_vsp_plane_prepare_fb,
+ .cleanup_fb = rcar_du_vsp_plane_cleanup_fb,
.atomic_check = rcar_du_vsp_plane_atomic_check,
.atomic_update = rcar_du_vsp_plane_atomic_update,
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index f1d0f1824528..8861661590ff 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -43,6 +43,7 @@ static inline struct rcar_du_vsp_plane
*to_rcar_vsp_plane(struct drm_plane *p)
* struct rcar_du_vsp_plane_state - Driver-specific plane state
* @state: base DRM plane state
* @format: information about the pixel format used by the plane
+ * @sg_tables: scatter-gather tables for the frame buffer memory
* @alpha: value of the plane alpha property
* @zpos: value of the plane zpos property
*/
@@ -50,6 +51,7 @@ struct rcar_du_vsp_plane_state {
struct drm_plane_state state;
const struct rcar_du_format_info *format;
+ struct sg_table sg_tables[3];
unsigned int alpha;
unsigned int zpos;
--
git-series 0.9.1
[PATCH v3 4/5] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP
From: Laurent Pinchart
The display buffers must be mapped for DMA through the device that
performs memory access. Expose an API to map and unmap memory through
the VSP device to be used by the DU.
As all the buffers allocated by the DU driver are coherent, we can skip
cache handling when mapping and unmapping them. This will need to be
revisited when support for non-coherent buffers will be added to the DU
driver.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
[Kieran: Remove unused header]
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 24
include/media/vsp1.h | 3 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 9d235e830f5a..7e456e482e16 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -12,6 +12,7 @@
*/
#include
+#include
#include
#include
@@ -524,6 +525,29 @@ void vsp1_du_atomic_flush(struct device *dev)
}
EXPORT_SYMBOL_GPL(vsp1_du_atomic_flush);
+int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt)
+{
+ struct vsp1_device *vsp1 = dev_get_drvdata(dev);
+
+ /*
+* As all the buffers allocated by the DU driver are coherent, we can
+* skip cache sync. This will need to be revisited when support for
+* non-coherent buffers will be added to the DU driver.
+*/
+ return dma_map_sg_attrs(vsp1->bus_master, sgt->sgl, sgt->nents,
+ DMA_TO_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
+}
+EXPORT_SYMBOL_GPL(vsp1_du_map_sg);
+
+void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt)
+{
+ struct vsp1_device *vsp1 = dev_get_drvdata(dev);
+
+ dma_unmap_sg_attrs(vsp1->bus_master, sgt->sgl, sgt->nents,
+ DMA_TO_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
+}
+EXPORT_SYMBOL_GPL(vsp1_du_unmap_sg);
+
/*
-
* Initialization
*/
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 38aac554dbba..6aa630c9f7af 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -13,6 +13,7 @@
#ifndef __MEDIA_VSP1_H__
#define __MEDIA_VSP1_H__
+#include
#include
#include
@@ -46,5 +47,7 @@ void vsp1_du_atomic_begin(struct device *dev);
int vsp1_du_atomic_update(struct device *dev, unsigned int rpf,
const struct vsp1_du_atomic_config *cfg);
void vsp1_du_atomic_flush(struct device *dev);
+int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt);
+void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt);
#endif /* __MEDIA_VSP1_H__ */
--
git-series 0.9.1
[PATCH v3 0/5] R-Car DU: Fix IOMMU operation when connected to VSP
Hello, This patch series fixes the rcar-du-drm driver to support VSP plane sources with an IOMMU. It is available for convenience at git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git vsp-du/iommu-fcp On R-Car Gen3 the DU has no direct memory access but sources planes through VSP instances. When an IOMMU is inserted between the VSP and memory, the DU framebuffers need to be DMA mapped using the VSP device, not the DU device as currently done. The same situation can also be reproduced on Gen2 hardware by linking the VSP to the DU in DT [1], effectively disabling direct memory access by the DU. The situation is made quite complex by the fact that different planes can be connected to different DU instances, and thus served by different IOMMUs (or, in practice on existing hardware, by the same IOMMU but through different micro-TLBs). We thus can't allocate and map buffers to the right device in a single dma_alloc_wc() operation as done in the DRM CMA GEM helpers. However, on such setups, the DU DT node doesn't reference IOMMUs as the DU does not perform any direct memory access. We can thus keep the GEM object allocation unchanged, and the DMA addresses that we receive in the DU driver will be physical addresses. Those buffers then need to be mapped to the VSP device when they are associated with planes. Fortunately the atomic framework provides two plane helper operations, .prepare_fb() and .cleanup_fb() that we can use for this purpose. The reality is slightly more complex than this on Gen3, as an FCP device instance sits between VSP instances and memory. It is the FCP devices that are connected to the IOMMUs, and buffer mapping thus need to be performed using the FCP devices. This isn't required on Gen2 as the platforms don't have any FCPs. Patches 1/5 and 2/5 extend the rcar-fcp driver API to expose the FCP struct device. Patch 3/5 then updates the vsp1 driver to map the display lists and video buffers through the FCP when it exists. This alone fixes VSP operation with an IOMMU on R-Car Gen3 systems. Moving on to addressing the DU issue, patch 4/5 extends the vsp1 driver API to allow mapping a scatter-gather list to the VSP, with the implementation using the FCP devices instead when available. Patch 5/5 finally uses the vsp1 mapping API in the rcar-du-drm driver to map and unmap buffers when needed. The series has been tested on the H2 Lager board and M3-W Salvator-X boards. The IOMMU is known not to work properly on the H3 ES1.1, so the H3 Salvator-X board hasn't been tested. In all cases both the DU and VSP operation has been tested, and tests were run with and without linking the DU and VSP devices to the IOMMU in DT. For H2, the patches were tested on top of v4.12-rc1 with a set of out-of-tree patches to link the VSP and DU to the IOMMUs and to enable VSP+DU combined similar to R-Car Gen3, and an additional DMA mapping API patch [2] that fixes IOMMU operation on ARM32, currently broken in v4.12-rc1. For M3-W, they were were tested on top of renesas-drivers-2017-05-16-v4.12-rc1 with a set of out-of-tree patches to add FCP, VSP, DU and IPMMU instances to the M3-W DT, as well as a hack for the IPMMU driver to whitelist all bus master devices. All tests passed successfully. The issue previously noticed on H3 with synchronization between page flip and VSP operation that was caused by buffers getting unmapped (and possibly freed) before the VSP was done reading them is now gone thanks to the VSP+DU flicker fix that should be merged in v4.13 and is available in renesas-drivers-2017-05-16-v4.12-rc1. A possible improvement is to modify the GEM object allocation mechanism to use non-contiguous memory when the DU driver detects that all the VSP instances it is connected to use an IOMMU (possibly through FCP devices). [1] https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg06589.html [2] https://www.spinics.net/lists/arm-kernel/msg581410.html Laurent Pinchart (4): v4l: rcar-fcp: Don't get/put module reference v4l: rcar-fcp: Add an API to retrieve the FCP device v4l: vsp1: Add API to map and unmap DRM buffers through the VSP drm: rcar-du: Map memory through the VSP device Magnus Damm (1): v4l: vsp1: Map the DL and video buffers through the proper bus master drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 74 ++--- drivers/gpu/drm/rcar-du/rcar_du_vsp.h| 2 +- drivers/media/platform/rcar-fcp.c| 17 ++ drivers/media/platform/vsp1/vsp1.h | 1 +- drivers/media/platform/vsp1/vsp1_dl.c| 4 +- drivers/media/platform/vsp1/vsp1_drm.c | 24 - drivers/media/platform/vsp1/vsp1_drv.c | 9 +++- drivers/media/platform/vsp1/vsp1_video.c | 2 +- include/media/rcar-fcp.h | 5 ++- include/media/vsp1.h | 3 +- 10 files changed, 123 insertions(+), 18 deletions(-) base-commit: f2c61f98e0b5f8b53b8fb860e5dcdd661bde7d0b -- git-series 0.9.1
[PATCH v3 3/5] v4l: vsp1: Map the DL and video buffers through the proper bus master
From: Magnus Damm
On Gen2 hardware the VSP1 is a bus master and accesses the display list
and video buffers through DMA directly. On Gen3 hardware, however,
memory accesses go through a separate IP core called FCP.
The VSP1 driver unconditionally maps DMA buffers through the VSP device.
While this doesn't cause any practical issue so far, DMA mappings will
be incorrect as soon as we will enable IOMMU support for the FCP on Gen3
platforms, resulting in IOMMU faults.
Fix this by mapping all buffers through the FCP device if present, and
through the VSP1 device as usual otherwise.
Suggested-by: Magnus Damm
[Cache the bus master device]
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1.h | 1 +
drivers/media/platform/vsp1/vsp1_dl.c| 4 ++--
drivers/media/platform/vsp1/vsp1_drv.c | 9 +
drivers/media/platform/vsp1/vsp1_video.c | 2 +-
4 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1.h
b/drivers/media/platform/vsp1/vsp1.h
index 85387a64179a..847963b6e9eb 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -74,6 +74,7 @@ struct vsp1_device {
void __iomem *mmio;
struct rcar_fcp_device *fcp;
+ struct device *bus_master;
struct vsp1_bru *bru;
struct vsp1_clu *clu;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 7d8f37772b56..445d1c31fff3 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -137,7 +137,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
dlb->vsp1 = vsp1;
dlb->size = size;
- dlb->entries = dma_alloc_wc(vsp1->dev, dlb->size, &dlb->dma,
+ dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, &dlb->dma,
GFP_KERNEL);
if (!dlb->entries)
return -ENOMEM;
@@ -150,7 +150,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
*/
static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
{
- dma_free_wc(dlb->vsp1->dev, dlb->size, dlb->entries, dlb->dma);
+ dma_free_wc(dlb->vsp1->bus_master, dlb->size, dlb->entries, dlb->dma);
}
/**
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 048446af5ae7..95c26edead85 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -764,6 +764,15 @@ static int vsp1_probe(struct platform_device *pdev)
PTR_ERR(vsp1->fcp));
return PTR_ERR(vsp1->fcp);
}
+
+ /*
+* When the FCP is present, it handles all bus master accesses
+* for the VSP and must thus be used in place of the VSP device
+* to map DMA buffers.
+*/
+ vsp1->bus_master = rcar_fcp_get_device(vsp1->fcp);
+ } else {
+ vsp1->bus_master = vsp1->dev;
}
/* Configure device parameters based on the version register. */
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index eab3c3ea85d7..5af3486afe07 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -1197,7 +1197,7 @@ struct vsp1_video *vsp1_video_create(struct vsp1_device
*vsp1,
video->queue.ops = &vsp1_video_queue_qops;
video->queue.mem_ops = &vb2_dma_contig_memops;
video->queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
- video->queue.dev = video->vsp1->dev;
+ video->queue.dev = video->vsp1->bus_master;
ret = vb2_queue_init(&video->queue);
if (ret < 0) {
dev_err(video->vsp1->dev, "failed to initialize vb2 queue\n");
--
git-series 0.9.1
[PATCH v3 1/5] v4l: rcar-fcp: Don't get/put module reference
From: Laurent Pinchart
Direct callers of the FCP API hold a reference to the FCP module due to
module linkage, there's no need to take another one manually. Take a
reference to the device instead to ensure that it won't disappear behind
the caller's back.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Kieran Bingham
---
drivers/media/platform/rcar-fcp.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/rcar-fcp.c
b/drivers/media/platform/rcar-fcp.c
index 7146fc5ef168..e9f609edf513 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -53,14 +53,7 @@ struct rcar_fcp_device *rcar_fcp_get(const struct
device_node *np)
if (fcp->dev->of_node != np)
continue;
- /*
-* Make sure the module won't be unloaded behind our back. This
-* is a poor man's safety net, the module should really not be
-* unloaded while FCP users can be active.
-*/
- if (!try_module_get(fcp->dev->driver->owner))
- fcp = NULL;
-
+ get_device(fcp->dev);
goto done;
}
@@ -81,7 +74,7 @@ EXPORT_SYMBOL_GPL(rcar_fcp_get);
void rcar_fcp_put(struct rcar_fcp_device *fcp)
{
if (fcp)
- module_put(fcp->dev->driver->owner);
+ put_device(fcp->dev);
}
EXPORT_SYMBOL_GPL(rcar_fcp_put);
--
git-series 0.9.1
[PATCH v3 2/5] v4l: rcar-fcp: Add an API to retrieve the FCP device
From: Laurent Pinchart
The new rcar_fcp_get_device() function retrieves the struct device
related to the FCP device. This is useful to handle DMA mapping through
the right device.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Kieran Bingham
---
drivers/media/platform/rcar-fcp.c | 6 ++
include/media/rcar-fcp.h | 5 +
2 files changed, 11 insertions(+)
diff --git a/drivers/media/platform/rcar-fcp.c
b/drivers/media/platform/rcar-fcp.c
index e9f609edf513..2988031d285d 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -78,6 +78,12 @@ void rcar_fcp_put(struct rcar_fcp_device *fcp)
}
EXPORT_SYMBOL_GPL(rcar_fcp_put);
+struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
+{
+ return fcp->dev;
+}
+EXPORT_SYMBOL_GPL(rcar_fcp_get_device);
+
/**
* rcar_fcp_enable - Enable an FCP
* @fcp: The FCP instance
diff --git a/include/media/rcar-fcp.h b/include/media/rcar-fcp.h
index 8723f05c6321..b60a7b176c37 100644
--- a/include/media/rcar-fcp.h
+++ b/include/media/rcar-fcp.h
@@ -19,6 +19,7 @@ struct rcar_fcp_device;
#if IS_ENABLED(CONFIG_VIDEO_RENESAS_FCP)
struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np);
void rcar_fcp_put(struct rcar_fcp_device *fcp);
+struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp);
int rcar_fcp_enable(struct rcar_fcp_device *fcp);
void rcar_fcp_disable(struct rcar_fcp_device *fcp);
#else
@@ -27,6 +28,10 @@ static inline struct rcar_fcp_device *rcar_fcp_get(const
struct device_node *np)
return ERR_PTR(-ENOENT);
}
static inline void rcar_fcp_put(struct rcar_fcp_device *fcp) { }
+static inline struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
+{
+ return NULL;
+}
static inline int rcar_fcp_enable(struct rcar_fcp_device *fcp)
{
return 0;
--
git-series 0.9.1
Re: [PATCH v3 0/5] R-Car DU: Fix IOMMU operation when connected to VSP
Hi Mauro, I would like this series to go in the same pull-request to the DRM tree as the previous series you acked. Again, the series touches both V4L2, and DRM, to provide another fix up the Rcar-DU driver. I have reviewed and tested the whole series Would it be possible to get your Acked-by: again please? -- Regards Kieran Bingham On 22/05/17 15:19, Kieran Bingham wrote: > Hello, > > This patch series fixes the rcar-du-drm driver to support VSP plane sources > with an IOMMU. It is available for convenience at > > git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git vsp-du/iommu-fcp > > On R-Car Gen3 the DU has no direct memory access but sources planes through > VSP instances. When an IOMMU is inserted between the VSP and memory, the DU > framebuffers need to be DMA mapped using the VSP device, not the DU device as > currently done. The same situation can also be reproduced on Gen2 hardware by > linking the VSP to the DU in DT [1], effectively disabling direct memory > access by the DU. > > The situation is made quite complex by the fact that different planes can be > connected to different DU instances, and thus served by different IOMMUs (or, > in practice on existing hardware, by the same IOMMU but through different > micro-TLBs). We thus can't allocate and map buffers to the right device in a > single dma_alloc_wc() operation as done in the DRM CMA GEM helpers. > > However, on such setups, the DU DT node doesn't reference IOMMUs as the DU > does not perform any direct memory access. We can thus keep the GEM object > allocation unchanged, and the DMA addresses that we receive in the DU driver > will be physical addresses. Those buffers then need to be mapped to the VSP > device when they are associated with planes. Fortunately the atomic framework > provides two plane helper operations, .prepare_fb() and .cleanup_fb() that we > can use for this purpose. > > The reality is slightly more complex than this on Gen3, as an FCP device > instance sits between VSP instances and memory. It is the FCP devices that are > connected to the IOMMUs, and buffer mapping thus need to be performed using > the FCP devices. This isn't required on Gen2 as the platforms don't have any > FCPs. > > Patches 1/5 and 2/5 extend the rcar-fcp driver API to expose the FCP struct > device. Patch 3/5 then updates the vsp1 driver to map the display lists and > video buffers through the FCP when it exists. This alone fixes VSP operation > with an IOMMU on R-Car Gen3 systems. > > Moving on to addressing the DU issue, patch 4/5 extends the vsp1 driver API to > allow mapping a scatter-gather list to the VSP, with the implementation using > the FCP devices instead when available. Patch 5/5 finally uses the vsp1 > mapping API in the rcar-du-drm driver to map and unmap buffers when needed. > > The series has been tested on the H2 Lager board and M3-W Salvator-X boards. > The IOMMU is known not to work properly on the H3 ES1.1, so the H3 Salvator-X > board hasn't been tested. In all cases both the DU and VSP operation has been > tested, and tests were run with and without linking the DU and VSP devices to > the IOMMU in DT. > > For H2, the patches were tested on top of v4.12-rc1 with a set of out-of-tree > patches to link the VSP and DU to the IOMMUs and to enable VSP+DU combined > similar to R-Car Gen3, and an additional DMA mapping API patch [2] that fixes > IOMMU operation on ARM32, currently broken in v4.12-rc1. For M3-W, they were > were tested on top of renesas-drivers-2017-05-16-v4.12-rc1 with a set of > out-of-tree patches to add FCP, VSP, DU and IPMMU instances to the M3-W DT, as > well as a hack for the IPMMU driver to whitelist all bus master devices. > > All tests passed successfully. The issue previously noticed on H3 with > synchronization between page flip and VSP operation that was caused by buffers > getting unmapped (and possibly freed) before the VSP was done reading them is > now gone thanks to the VSP+DU flicker fix that should be merged in v4.13 and > is available in renesas-drivers-2017-05-16-v4.12-rc1. > > A possible improvement is to modify the GEM object allocation mechanism to use > non-contiguous memory when the DU driver detects that all the VSP instances it > is connected to use an IOMMU (possibly through FCP devices). > > [1] > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg06589.html > [2] https://www.spinics.net/lists/arm-kernel/msg581410.html > > Laurent Pinchart (4): > v4l: rcar-fcp: Don't get/put module reference > v4l: rcar-fcp: Add an API to retrieve the FCP device > v4l: vsp1: Add API to map and unmap DRM buffers through the VSP > drm: rcar-du: Map memory through the VSP device > > Magnus Damm (1): > v4l: vsp1: Map the DL and video buffers through the proper bus master > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 74 ++--- > drivers/gpu/drm/rcar-du/rcar_du_vsp.h| 2 +- > drivers/media/platform/rcar-fcp.c| 17
Re: [PATCH v1 3/3] v4l: async: Match parent devices
Hi Laurent,
On 18/05/17 15:01, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Wednesday 17 May 2017 16:03:39 Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> Devices supporting multiple endpoints on a single device node must set
>> their subdevice fwnode to the endpoint to allow distinct comparisons.
>>
>> Adapt the match_fwnode call to compare against the provided fwnodes
>> first, but also to search for a comparison against the parent fwnode.
>>
>> This allows notifiers to pass the endpoint for comparison and still
>> support existing subdevices which store their default parent device
>> node.
>>
>> Signed-off-by: Kieran Bingham
>> ---
>> drivers/media/v4l2-core/v4l2-async.c | 20
>> 1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-async.c
>> b/drivers/media/v4l2-core/v4l2-async.c index e1e181db90f7..65735a5c4350
>> 100644
>> --- a/drivers/media/v4l2-core/v4l2-async.c
>> +++ b/drivers/media/v4l2-core/v4l2-async.c
>> @@ -41,14 +41,26 @@ static bool match_devname(struct v4l2_subdev *sd,
>> return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
>> }
>>
> /*
> * Check whether the two device_node pointers refer to the same OF node. We
> * can't compare pointers directly as they can differ if overlays have been
> * applied.
> */
Thanks - that's a good addition - I've put it in.
>
>> +static bool match_of(struct device_node *a, struct device_node *b)
>> +{
>> +return !of_node_cmp(of_node_full_name(a), of_node_full_name(b));
>> +}
>> +
>> static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev
>> *asd)
>> {
>> +struct device_node *sdnode;
>> +struct fwnode_handle *async_device;
>
> I would name this asd_fwnode, and to be consistent rename sdnode to sd_ofnode.
Actually, now that I agree with Sakari, and the parent of both the SD and the
ASD should be cross-referenced, I have used:
sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
>
>> +
>> +async_device = fwnode_graph_get_port_parent(asd->match.fwnode.fwnode);
>> +
>> if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
>> -return sd->fwnode == asd->match.fwnode.fwnode;
>> +return sd->fwnode == asd->match.fwnode.fwnode ||
>> + sd->fwnode == async_device;
>
> I wonder whether we could simplify this by changing the
> fwnode_graph_get_port_parent() API. At the moment the function walks two or
> three levels up depending on whether there's a ports name or not. If we
> turned
> in into a function that accepts an endpoint, port or device node, and returns
> the device node unconditionally (basically, returning the argument if its
> name
> is not "port(@[0-9]+)?" or "endpoint(@[0-9]+)?", and walking up until it
> reaches the device node otherwise), you could write the above
>
> asd_fwnode = fwnode_graph_get_port_parent(asd->match.fwnode.fwnode);
>
> if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
> sd->fwnode == asd_fwnode;
>
> sdnode = to_of_node(sd->fwnode);
>
> return match_of(sdnode, to_of_node(asd_node));
I don't think that would help here. I want the function to do comparisons on the
endpoint when provided - I don't want helpers to suddenly bring the comparison
up to the device level.
>
>> +
>> +sdnode = to_of_node(sd->fwnode);
>>
>> -return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
>> -of_node_full_name(
>> -to_of_node(asd->match.fwnode.fwnode)));
>> +return match_of(sdnode, to_of_node(asd->match.fwnode.fwnode)) ||
>> + match_of(sdnode, to_of_node(async_device));
>
> This is getting a bit complex, could you document the function ?
I've added comments, and improved helpers - I think it's looking a lot better
now :)
>
>> }
>>
>> static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev
>> *asd)
>
--
Kieran
[PATCH] [media] coda: improve colorimetry handling
The hardware codec is not colorspace aware. We should trust userspace to
set the correct colorimetry information on the OUTPUT queue and mirror
the exact same setting on the CAPTURE queue.
There is no reason to restrict colorspace to JPEG or REC709 only. Also,
set the default colorspace, as returned by calling VIDIOC_TRY/S_FMT with
V4L2_COLORSPACE_DEFAULT, initially.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 51 ++-
drivers/media/platform/coda/coda.h| 3 ++
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index d523e990d5093..506003eb9a01c 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -430,10 +430,10 @@ static int coda_g_fmt(struct file *file, void *priv,
f->fmt.pix.bytesperline = q_data->bytesperline;
f->fmt.pix.sizeimage= q_data->sizeimage;
- if (f->fmt.pix.pixelformat == V4L2_PIX_FMT_JPEG)
- f->fmt.pix.colorspace = V4L2_COLORSPACE_JPEG;
- else
- f->fmt.pix.colorspace = ctx->colorspace;
+ f->fmt.pix.colorspace = ctx->colorspace;
+ f->fmt.pix.xfer_func= ctx->xfer_func;
+ f->fmt.pix.ycbcr_enc= ctx->ycbcr_enc;
+ f->fmt.pix.quantization = ctx->quantization;
return 0;
}
@@ -599,6 +599,9 @@ static int coda_try_fmt_vid_cap(struct file *file, void
*priv,
}
f->fmt.pix.colorspace = ctx->colorspace;
+ f->fmt.pix.xfer_func = ctx->xfer_func;
+ f->fmt.pix.ycbcr_enc = ctx->ycbcr_enc;
+ f->fmt.pix.quantization = ctx->quantization;
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
codec = coda_find_codec(ctx->dev, q_data_src->fourcc,
@@ -635,6 +638,23 @@ static int coda_try_fmt_vid_cap(struct file *file, void
*priv,
return 0;
}
+static void coda_set_default_colorspace(struct v4l2_pix_format *fmt)
+{
+ enum v4l2_colorspace colorspace;
+
+ if (fmt->pixelformat == V4L2_PIX_FMT_JPEG)
+ colorspace = V4L2_COLORSPACE_JPEG;
+ else if (fmt->width <= 720 && fmt->height <= 576)
+ colorspace = V4L2_COLORSPACE_SMPTE170M;
+ else
+ colorspace = V4L2_COLORSPACE_REC709;
+
+ fmt->colorspace = colorspace;
+ fmt->xfer_func = V4L2_XFER_FUNC_DEFAULT;
+ fmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
+ fmt->quantization = V4L2_QUANTIZATION_DEFAULT;
+}
+
static int coda_try_fmt_vid_out(struct file *file, void *priv,
struct v4l2_format *f)
{
@@ -648,16 +668,8 @@ static int coda_try_fmt_vid_out(struct file *file, void
*priv,
if (ret < 0)
return ret;
- switch (f->fmt.pix.colorspace) {
- case V4L2_COLORSPACE_REC709:
- case V4L2_COLORSPACE_JPEG:
- break;
- default:
- if (f->fmt.pix.pixelformat == V4L2_PIX_FMT_JPEG)
- f->fmt.pix.colorspace = V4L2_COLORSPACE_JPEG;
- else
- f->fmt.pix.colorspace = V4L2_COLORSPACE_REC709;
- }
+ if (f->fmt.pix.colorspace == V4L2_COLORSPACE_DEFAULT)
+ coda_set_default_colorspace(&f->fmt.pix);
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
codec = coda_find_codec(dev, f->fmt.pix.pixelformat,
q_data_dst->fourcc);
@@ -772,6 +784,9 @@ static int coda_s_fmt_vid_out(struct file *file, void *priv,
return ret;
ctx->colorspace = f->fmt.pix.colorspace;
+ ctx->xfer_func = f->fmt.pix.xfer_func;
+ ctx->ycbcr_enc = f->fmt.pix.ycbcr_enc;
+ ctx->quantization = f->fmt.pix.quantization;
memset(&f_cap, 0, sizeof(f_cap));
f_cap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
@@ -1282,7 +1297,13 @@ static void set_default_params(struct coda_ctx *ctx)
csize = coda_estimate_sizeimage(ctx, usize, max_w, max_h);
ctx->params.codec_mode = ctx->codec->mode;
- ctx->colorspace = V4L2_COLORSPACE_REC709;
+ if (ctx->cvd->src_formats[0] == V4L2_PIX_FMT_JPEG)
+ ctx->colorspace = V4L2_COLORSPACE_JPEG;
+ else
+ ctx->colorspace = V4L2_COLORSPACE_REC709;
+ ctx->xfer_func = V4L2_XFER_FUNC_DEFAULT;
+ ctx->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
+ ctx->quantization = V4L2_QUANTIZATION_DEFAULT;
ctx->params.framerate = 30;
/* Default formats for output and input queues */
diff --git a/drivers/media/platform/coda/coda.h
b/drivers/media/platform/coda/coda.h
index 20222befb9b2f..308116d855e6f 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -206,6 +206,9 @@ struct coda_ctx {
enum coda_inst_type inst_type;
const struct coda_codec *codec;
enum v4l2_colorspacecolorspace;
+ enum v4l2_xfer_func x
Re: [PATCH v2 1/2] device property: Add fwnode_graph_get_port_parent
Hi Sakari,
On 19/05/17 22:51, Sakari Ailus wrote:
> Hi Kieran,
>
> On Fri, May 19, 2017 at 05:16:02PM +0100, Kieran Bingham wrote:
>> +struct fwnode_handle *
>> +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
>> +{
>> +return fwnode_call_ptr_op(endpoint, graph_get_port_parent);
>
> graph_get_port_parent op will actually get the parent of the port. But it
> expects a port node, not an endpoint node. This is implemented so in order
> to center the ops around primitives rather than end user APIs that may
> change over time.
>
> I think you'll need:
>
> return fwnode_call_ptr_op(fwnode_graph_get_next_parent(endpoint),
> graph_get_port_parent);
>
> Or something like that.
Aha - that explains why I remember thinking to ask you if the implementation of
graph_get_port_parent checked enough levels up :)
I've added the fwnode_graph_get_next_parent() call, but separated it out so that
the code fits cleanly:
struct fwnode_handle *
fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
{
struct fwnode_handle *port = fwnode_get_next_parent(endpoint);
return fwnode_call_ptr_op(port, graph_get_port_parent);
}
EXPORT_SYMBOL_GPL(fwnode_graph_get_port_parent);
I will include this in my testing and rebasing before I repost.
--
Regards
Kieran
Re: [PATCH v2 2/2] v4l: async: Match parent devices
Reviewing my own post:
On 19/05/17 17:16, Kieran Bingham wrote:
> From: Kieran Bingham
>
> Devices supporting multiple endpoints on a single device node must set
> their subdevice fwnode to the endpoint to allow distinct comparisons.
>
> Adapt the match_fwnode call to compare against the provided fwnodes
> first, but also to search for a comparison against the parent fwnode.
>
> This allows notifiers to pass the endpoint for comparison and still
> support existing subdevices which store their default parent device
> node.
>
> Signed-off-by: Kieran Bingham
>
> ---
> v2:
> - Added documentation comments
> - simplified the OF match by adding match_fwnode_of()
>
> drivers/media/v4l2-core/v4l2-async.c | 33 -
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-async.c
> b/drivers/media/v4l2-core/v4l2-async.c
> index cbd919d4edd2..2473c0a1f7a8 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -41,14 +41,37 @@ static bool match_devname(struct v4l2_subdev *sd,
> return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
> }
>
> +static bool match_fwnode_of(struct fwnode_handle *a, struct fwnode_handle *b)
> +{
> + return !of_node_cmp(of_node_full_name(to_of_node(a)),
> + of_node_full_name(to_of_node(b)));
> +}
> +
> +/*
> + * Compare the sd with the notifier.
> + *
> + * As a measure to support drivers which have not been converted to use
> + * endpoint matching, we also find the parent device of the node in the
> + * notifier, and compare the sd against that device.
> + */
> static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev
> *asd)
> {
> - if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
> - return sd->fwnode == asd->match.fwnode.fwnode;
> + struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
> + struct fwnode_handle *sd_parent, *asd_parent;
> +
The keen eyed will notice that sd_parent is not initialised here before use:
Fixed in the next version, pending testing and repost.
> + asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
> +
> + if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
> + return sd->fwnode == asd_fwnode ||
> +sd_parent == asd_fwnode ||
> +sd->fwnode == asd_parent;
>
> - return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
> - of_node_full_name(
> - to_of_node(asd->match.fwnode.fwnode)));
> + /*
> + * Compare OF nodes with a full match to support removable dt snippets.
> + */
> + return match_fwnode_of(sd->fwnode, asd_fwnode) ||
> +match_fwnode_of(sd_parent, asd_fwnode) ||
> +match_fwnode_of(sd->fwnode, asd_parent);
> }
>
> static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev
> *asd)
>
[PATCH v3 1/2] device property: Add fwnode_graph_get_port_parent
From: Kieran Bingham
Provide a helper to obtain the parent device fwnode without first
parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
Signed-off-by: Kieran Bingham
---
v2:
- Rebase on top of Sakari's acpi-graph-clean branch and simplify
v3:
- Fix up kerneldoc
- Get the 'port' of the endpoint to find the parent of the port
drivers/base/property.c | 15 +++
include/linux/property.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index b311a6fa7d0c..fdbc644fd743 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1169,6 +1169,21 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle
*fwnode,
EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
/**
+ * fwnode_graph_get_port_parent - Return the device fwnode of a port endpoint
+ * @endpoint: Endpoint firmware node of the port
+ *
+ * Return: the firmware node of the device the @endpoint belongs to.
+ */
+struct fwnode_handle *
+fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
+{
+ struct fwnode_handle *port = fwnode_get_next_parent(endpoint);
+
+ return fwnode_call_ptr_op(port, graph_get_port_parent);
+}
+EXPORT_SYMBOL_GPL(fwnode_graph_get_port_parent);
+
+/**
* fwnode_graph_get_remote_port_parent - Return fwnode of a remote device
* @fwnode: Endpoint firmware node pointing to the remote endpoint
*
diff --git a/include/linux/property.h b/include/linux/property.h
index b9f4838d9882..af95d5d84192 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -275,6 +275,8 @@ void *device_get_mac_address(struct device *dev, char
*addr, int alen);
struct fwnode_handle *fwnode_graph_get_next_endpoint(
struct fwnode_handle *fwnode, struct fwnode_handle *prev);
+struct fwnode_handle *fwnode_graph_get_port_parent(
+ struct fwnode_handle *fwnode);
struct fwnode_handle *fwnode_graph_get_remote_port_parent(
struct fwnode_handle *fwnode);
struct fwnode_handle *fwnode_graph_get_remote_port(
--
git-series 0.9.1
[PATCH v3 0/2] v4l: async: Match parent devices
From: Kieran Bingham As devices become more complicated, it becomes necessary (and more accurate) to match devices based on their endpoint, as devices may have multiple subdevices. To support using endpoints in the V4L2 async subdev framework, while some devices still use their device fwnode, we need to be able to parse a fwnode for the device from the endpoint. By providing a helper fwnode_graph_get_port_parent(), we can use it in the match_fwnode to support matches during the transition to endpoint matching. This series is dependant upon Sakari's v4l2-acpi and acpi-graph-cleaned branch v2: - Rebased on top of git.linuxtv.org/sailus/media_tree.git #acpi-graph-cleaned v3: - Fixed uninitialised asd_parent - Improved kerneldocs - Get the 'port' of the endpoint in fwnode_graph_get_port_parent Kieran Bingham (2): device property: Add fwnode_graph_get_port_parent v4l: async: Match parent devices drivers/base/property.c | 15 - drivers/media/v4l2-core/v4l2-async.c | 36 - include/linux/property.h | 2 ++- 3 files changed, 48 insertions(+), 5 deletions(-) base-commit: d043978c7c919c727fb76b6593c71d0e697a5d66 -- git-series 0.9.1
[PATCH v3 2/2] v4l: async: Match parent devices
From: Kieran Bingham
Devices supporting multiple endpoints on a single device node must set
their subdevice fwnode to the endpoint to allow distinct comparisons.
Adapt the match_fwnode call to compare against the provided fwnodes
first, but also to search for a comparison against the parent fwnode.
This allows notifiers to pass the endpoint for comparison and still
support existing subdevices which store their default parent device
node.
Signed-off-by: Kieran Bingham
---
v2:
- Added documentation comments
- simplified the OF match by adding match_fwnode_of()
v3:
- Fix comments
- Fix sd_parent, and asd_parent usage
drivers/media/v4l2-core/v4l2-async.c | 36 -
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index cbd919d4edd2..12c0707851fd 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -41,14 +41,40 @@ static bool match_devname(struct v4l2_subdev *sd,
return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
}
+/*
+ * Check whether the two device_node pointers refer to the same OF node. We
+ * can't compare pointers directly as they can differ if overlays have been
+ * applied.
+ */
+static bool match_fwnode_of(struct fwnode_handle *a, struct fwnode_handle *b)
+{
+ return !of_node_cmp(of_node_full_name(to_of_node(a)),
+ of_node_full_name(to_of_node(b)));
+}
+
+/*
+ * As a measure to support drivers which have not been converted to use
+ * endpoint matching, we also find the parent devices for cross-matching.
+ *
+ * When all devices use endpoint matching, this code can be simplified, and the
+ * parent comparisons can be removed.
+ */
static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
- return sd->fwnode == asd->match.fwnode.fwnode;
+ struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
+ struct fwnode_handle *sd_parent, *asd_parent;
+
+ sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
+ asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
+
+ if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
+ return sd->fwnode == asd_fwnode ||
+ sd_parent == asd_fwnode ||
+ sd->fwnode == asd_parent;
- return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
- of_node_full_name(
- to_of_node(asd->match.fwnode.fwnode)));
+ return match_fwnode_of(sd->fwnode, asd_fwnode) ||
+ match_fwnode_of(sd_parent, asd_fwnode) ||
+ match_fwnode_of(sd->fwnode, asd_parent);
}
static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
--
git-series 0.9.1
[PATCH] [media] uvcvideo: Prevent heap overflow in uvc driver
From: Robb Glasser The size of uvc_control_mapping is user controlled leading to a potential heap overflow in the uvc driver. This adds a check to verify the user provided size fits within the bounds of the defined buffer size. Signed-off-by: Robb Glasser [groeck: cherry picked from https://source.codeaurora.org/quic/la/kernel/msm-3.10 commit b7b99e55bc7770187913ed092990852ea52d7892; updated subject] Signed-off-by: Guenter Roeck --- Fixes CVE-2017-0627. drivers/media/usb/uvc/uvc_ctrl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index c2ee6e39fd0c..252ab991396f 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -1992,6 +1992,9 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain *chain, if (!found) return -ENOENT; + if (ctrl->info.size < mapping->size) + return -EINVAL; + if (mutex_lock_interruptible(&chain->ctrl_mutex)) return -ERESTARTSYS; -- 2.7.4
Re: [PATCH 13/16] lirc_dev: use an ida instead of a hand-rolled array to keep track of minors
On Mon, May 01, 2017 at 06:04:42PM +0200, David Härdeman wrote:
> Using the kernel ida facilities, we can avoid a lot of unnecessary code and
> at the same
> time get rid of lirc_dev_lock in favour of per-device locks (the irctls array
> was used
> throughout lirc_dev so this patch necessarily touches a lot of code).
>
> Signed-off-by: David Härdeman
> ---
> drivers/media/rc/ir-lirc-codec.c|9 -
> drivers/media/rc/lirc_dev.c | 258
> ---
> drivers/staging/media/lirc/lirc_zilog.c | 16 +-
> include/media/lirc_dev.h| 14 --
> 4 files changed, 115 insertions(+), 182 deletions(-)
>
> diff --git a/drivers/media/rc/ir-lirc-codec.c
> b/drivers/media/rc/ir-lirc-codec.c
> index a30af91710fe..2c1221a61ea1 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -382,7 +382,6 @@ static int ir_lirc_register(struct rc_dev *dev)
>
> snprintf(drv->name, sizeof(drv->name), "ir-lirc-codec (%s)",
>dev->driver_name);
> - drv->minor = -1;
> drv->features = features;
> drv->data = &dev->raw->lirc;
> drv->rbuf = NULL;
> @@ -394,11 +393,9 @@ static int ir_lirc_register(struct rc_dev *dev)
> drv->rdev = dev;
> drv->owner = THIS_MODULE;
>
> - drv->minor = lirc_register_driver(drv);
> - if (drv->minor < 0) {
> - rc = -ENODEV;
> + rc = lirc_register_driver(drv);
> + if (rc < 0)
> goto out;
> - }
>
> dev->raw->lirc.drv = drv;
> dev->raw->lirc.dev = dev;
> @@ -413,7 +410,7 @@ static int ir_lirc_unregister(struct rc_dev *dev)
> {
> struct lirc_codec *lirc = &dev->raw->lirc;
>
> - lirc_unregister_driver(lirc->drv->minor);
> + lirc_unregister_driver(lirc->drv);
> kfree(lirc->drv);
> lirc->drv = NULL;
>
> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
> index e44e0b23b883..7db7d4c57991 100644
> --- a/drivers/media/rc/lirc_dev.c
> +++ b/drivers/media/rc/lirc_dev.c
> @@ -31,23 +31,35 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> #include
>
> #define IRCTL_DEV_NAME "BaseRemoteCtl"
> -#define NOPLUG -1
> #define LOGHEAD "lirc_dev (%s[%d]): "
>
> static dev_t lirc_base_dev;
>
> +/**
> + * struct irctl - lirc per-device structure
> + * @d: internal copy of the &struct lirc_driver for
> the device
> + * @dead:if the device has gone away
> + * @users: the number of users of the lirc chardev (currently
> limited to 1)
> + * @mutex: synchronizes open()/close()/ioctl()/etc calls
> + * @buf: used to store lirc RX data
> + * @buf_internal:whether @buf was allocated internally or not
> + * @chunk_size: @buf stores and read() returns data chunks of
> this size
> + * @dev: the &struct device for the lirc device
> + * @cdev:the &struct device for the lirc chardev
> + */
> struct irctl {
> struct lirc_driver d;
> - int attached;
> - int open;
> + bool dead;
> + unsigned users;
>
> - struct mutex irctl_lock;
> + struct mutex mutex;
> struct lirc_buffer *buf;
> bool buf_internal;
> unsigned int chunk_size;
> @@ -56,9 +68,9 @@ struct irctl {
> struct cdev cdev;
> };
>
> -static DEFINE_MUTEX(lirc_dev_lock);
> -
> -static struct irctl *irctls[MAX_IRCTL_DEVICES];
> +/* Used to keep track of allocated lirc devices */
> +#define LIRC_MAX_DEVICES 256
> +static DEFINE_IDA(lirc_ida);
>
> /* Only used for sysfs but defined to void otherwise */
> static struct class *lirc_class;
> @@ -72,9 +84,6 @@ static void lirc_release(struct device *ld)
> kfree(ir->buf);
> }
>
> - mutex_lock(&lirc_dev_lock);
> - irctls[ir->d.minor] = NULL;
> - mutex_unlock(&lirc_dev_lock);
> kfree(ir);
> }
>
> @@ -117,7 +126,18 @@ static int lirc_allocate_buffer(struct irctl *ir)
> return err;
> }
>
> -int lirc_register_driver(struct lirc_driver *d)
> +/**
> + * lirc_register_driver() - create a new lirc device by registering a driver
> + * @d: the &struct lirc_driver to register
> + *
> + * This function allocates and registers a lirc device for a given
> + * &lirc_driver. The &lirc_driver structure is updated to contain
> + * information about the allocated device (minor, buffer, etc).
> + *
> + * Return: zero on success or a negative error value.
> + */
> +int
> +lirc_register_driver(struct lirc_driver *d)
> {
> struct irctl *ir;
> int minor;
> @@ -138,12 +158,6 @@ int lirc_register_driver(struct lirc_driver *d)
> return -EINVAL;
> }
>
> - if (d->minor >= MAX_IRCTL_DEVICES) {
> - dev_err(d->dev, "minor must be between 0 and %d!\n",
> - MAX_IRCTL_DEVICES - 1);
> - return -EBADRQC;
> - }
> -
>
Re: [PATCH 3/7] rc-core: img-nec-decoder - leave the internals of rc_dev alone
On Mon, May 01, 2017 at 06:10:06PM +0200, David Härdeman wrote:
> Obvious fix, leave repeat handling to rc-core
>
> Signed-off-by: David Härdeman
> ---
> drivers/media/rc/ir-nec-decoder.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/rc/ir-nec-decoder.c
> b/drivers/media/rc/ir-nec-decoder.c
> index 3ce850314dca..75b9137f6faf 100644
> --- a/drivers/media/rc/ir-nec-decoder.c
> +++ b/drivers/media/rc/ir-nec-decoder.c
> @@ -88,13 +88,9 @@ static int ir_nec_decode(struct rc_dev *dev, struct
> ir_raw_event ev)
> data->state = STATE_BIT_PULSE;
> return 0;
> } else if (eq_margin(ev.duration, NEC_REPEAT_SPACE, NEC_UNIT /
> 2)) {
> - if (!dev->keypressed) {
> - IR_dprintk(1, "Discarding last key repeat:
> event after key up\n");
> - } else {
> - rc_repeat(dev);
> - IR_dprintk(1, "Repeat last key\n");
> - data->state = STATE_TRAILER_PULSE;
> - }
> + rc_repeat(dev);
> + IR_dprintk(1, "Repeat last key\n");
> + data->state = STATE_TRAILER_PULSE;
This is not correct. This means that whenever a nec repeat is received,
the last scancode is sent to the input device, irrespective of whether
there has been no IR for hours. The original code is stricter.
> return 0;
> }
>
Re: [PATCH 4/7] rc-core: sanyo - leave the internals of rc_dev alone
On Mon, May 01, 2017 at 06:10:12PM +0200, David Härdeman wrote:
> Leave repeat handling to rc-core.
>
> Signed-off-by: David Härdeman
> ---
> drivers/media/rc/ir-sanyo-decoder.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/rc/ir-sanyo-decoder.c
> b/drivers/media/rc/ir-sanyo-decoder.c
> index 520bb77dcb62..e6a906a34f90 100644
> --- a/drivers/media/rc/ir-sanyo-decoder.c
> +++ b/drivers/media/rc/ir-sanyo-decoder.c
> @@ -110,13 +110,9 @@ static int ir_sanyo_decode(struct rc_dev *dev, struct
> ir_raw_event ev)
> break;
>
> if (!data->count && geq_margin(ev.duration, SANYO_REPEAT_SPACE,
> SANYO_UNIT / 2)) {
> - if (!dev->keypressed) {
> - IR_dprintk(1, "SANYO discarding last key
> repeat: event after key up\n");
> - } else {
> - rc_repeat(dev);
> - IR_dprintk(1, "SANYO repeat last key\n");
> - data->state = STATE_INACTIVE;
> - }
> + rc_repeat(dev);
> + IR_dprintk(1, "SANYO repeat last key\n");
> + data->state = STATE_INACTIVE;
Same as the nec decoder: the original code checks whether there has been
a key up event already, so you don't get old scancodes repeated for no
reason.
> return 0;
> }
>
[PATCH] [media] atomisp: use NULL instead of 0 for pointers
Fix warning issued by sparse: Using plain integer as NULL pointer
Signed-off-by: Paolo Cretaro
---
drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 2 +-
.../media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c| 2 +-
.../media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c| 2 +-
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 2 +-
drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c | 4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
index 5e9dafe7cc32..d6447398f5ef 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
@@ -706,7 +706,7 @@ static int ov5693_read_otp_reg_array(struct i2c_client
*client, u16 size,
{
u16 index;
int ret;
- u16 *pVal = 0;
+ u16 *pVal = NULL;
for (index = 0; index <= size; index++) {
pVal = (u16 *) (buf + index);
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c
index ed33d4c4c84a..5d40afd482f5 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c
@@ -239,7 +239,7 @@ static ia_css_queue_t *bufq_get_qhandle(
enum sh_css_queue_id id,
int thread)
{
- ia_css_queue_t *q = 0;
+ ia_css_queue_t *q = NULL;
switch (type) {
case sh_css_host2sp_buffer_queue:
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c
index b36d7b00ebe8..18966d89602a 100644
---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/spctrl/src/spctrl.c
@@ -57,7 +57,7 @@ enum ia_css_err ia_css_spctrl_load_fw(sp_ID_t sp_id,
hrt_vaddress code_addr = mmgr_NULL;
struct ia_css_sp_init_dmem_cfg *init_dmem_cfg;
- if ((sp_id >= N_SP_ID) || (spctrl_cfg == 0))
+ if ((sp_id >= N_SP_ID) || (spctrl_cfg == NULL))
return IA_CSS_ERR_INVALID_ARGUMENTS;
spctrl_cofig_info[sp_id].code_addr = mmgr_NULL;
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index 57295397da3e..5e63073f3581 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -193,7 +193,7 @@ int hmm_init(void)
* at the beginning, to avoid hmm_alloc return 0 in the
* further allocation.
*/
- dummy_ptr = hmm_alloc(1, HMM_BO_PRIVATE, 0, 0, HMM_UNCACHED);
+ dummy_ptr = hmm_alloc(1, HMM_BO_PRIVATE, 0, NULL, HMM_UNCACHED);
if (!ret) {
ret = sysfs_create_group(&atomisp_dev->kobj,
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
b/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
index 7dff22f59e29..2e78976bb2ac 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
@@ -55,7 +55,7 @@ static ia_css_ptr __hrt_isp_css_mm_alloc(size_t bytes, void
*userptr,
if (type == HRT_USR_PTR) {
if (userptr == NULL)
return hmm_alloc(bytes, HMM_BO_PRIVATE, 0,
-0, cached);
+NULL, cached);
else {
if (num_pages < ((__page_align(bytes)) >> PAGE_SHIFT))
dev_err(atomisp_dev,
@@ -94,7 +94,7 @@ ia_css_ptr hrt_isp_css_mm_alloc_user_ptr(size_t bytes, void
*userptr,
ia_css_ptr hrt_isp_css_mm_alloc_cached(size_t bytes)
{
if (my_userptr == NULL)
- return hmm_alloc(bytes, HMM_BO_PRIVATE, 0, 0,
+ return hmm_alloc(bytes, HMM_BO_PRIVATE, 0, NULL,
HMM_CACHED);
else {
if (my_num_pages < ((__page_align(bytes)) >> PAGE_SHIFT))
--
2.13.0
Re: [PATCH v2 1/2] binding for stm32 cec driver
On Tue, May 16, 2017 at 02:56:22PM +0200, Benjamin Gaignard wrote:
Commit message?
Preferred subject prefix is "dt-bindings: media: ..."
> Signed-off-by: Benjamin Gaignard
> ---
> .../devicetree/bindings/media/st,stm32-cec.txt| 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/st,stm32-cec.txt
>
> diff --git a/Documentation/devicetree/bindings/media/st,stm32-cec.txt
> b/Documentation/devicetree/bindings/media/st,stm32-cec.txt
> new file mode 100644
> index 000..6be2381
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/st,stm32-cec.txt
> @@ -0,0 +1,19 @@
> +STMicroelectronics STM32 CEC driver
> +
> +Required properties:
> + - compatible : value should be "st,stm32-cec"
All stm32 chips have same CEC block?
> + - reg : Physical base address of the IP registers and length of memory
> + mapped region.
> + - clocks : from common clock binding: handle to CEC clocks
> + - clock-names : from common clock binding: must be "cec" and "hdmi-cec".
> + - interrupts : CEC interrupt number to the CPU.
> +
> +Example for stm32f746:
> +
> +cec: cec@40006c00 {
> + compatible = "st,stm32-cec";
> + reg = <0x40006C00 0x400>;
> + interrupts = <94>;
> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(CEC)>, <&rcc 1 CLK_HDMI_CEC>;
> + clock-names = "cec", "hdmi-cec";
> +};
> --
> 1.9.1
>
[PATCH v4 1/3] dt-bindings: mt8173: Fix mdp device tree
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
Signed-off-by: Minghsiu Tsai
Acked-by: Rob Herring
Acked-by: Hans Verkuil
---
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index 4182063..0d03e3a 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -2,7 +2,7 @@
Media Data Path is used for scaling and color space conversion.
-Required properties (controller (parent) node):
+Required properties (controller node):
- compatible: "mediatek,mt8173-mdp"
- mediatek,vpu: the node of video processor unit, see
Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
@@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
for details.
Example:
-mdp {
- compatible = "mediatek,mt8173-mdp";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- mediatek,vpu = <&vpu>;
-
mdp_rdma0: rdma@14001000 {
compatible = "mediatek,mt8173-mdp-rdma";
+"mediatek,mt8173-mdp";
reg = <0 0x14001000 0 0x1000>;
clocks = <&mmsys CLK_MM_MDP_RDMA0>,
<&mmsys CLK_MM_MUTEX_32K>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
iommus = <&iommu M4U_PORT_MDP_RDMA0>;
mediatek,larb = <&larb0>;
+ mediatek,vpu = <&vpu>;
};
mdp_rdma1: rdma@14002000 {
@@ -106,4 +101,3 @@ mdp {
iommus = <&iommu M4U_PORT_MDP_WROT1>;
mediatek,larb = <&larb4>;
};
-};
--
1.9.1
[PATCH v4 2/3] arm64: dts: mt8173: Fix mdp device tree
From: Daniel Kurtz
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
Signed-off-by: Daniel Kurtz
Signed-off-by: Minghsiu Tsai
Acked-by: Hans Verkuil
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 +++
1 file changed, 60 insertions(+), 66 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 6922252..d28a363 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -792,80 +792,74 @@
#clock-cells = <1>;
};
- mdp {
- compatible = "mediatek,mt8173-mdp";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
+ mdp_rdma0: rdma@14001000 {
+ compatible = "mediatek,mt8173-mdp-rdma",
+"mediatek,mt8173-mdp";
+ reg = <0 0x14001000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+<&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA0>;
+ mediatek,larb = <&larb0>;
mediatek,vpu = <&vpu>;
+ };
- mdp_rdma0: rdma@14001000 {
- compatible = "mediatek,mt8173-mdp-rdma";
- reg = <0 0x14001000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RDMA0>,
-<&mmsys CLK_MM_MUTEX_32K>;
- power-domains = <&scpsys
MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_RDMA0>;
- mediatek,larb = <&larb0>;
- };
-
- mdp_rdma1: rdma@14002000 {
- compatible = "mediatek,mt8173-mdp-rdma";
- reg = <0 0x14002000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RDMA1>,
-<&mmsys CLK_MM_MUTEX_32K>;
- power-domains = <&scpsys
MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_RDMA1>;
- mediatek,larb = <&larb4>;
- };
+ mdp_rdma1: rdma@14002000 {
+ compatible = "mediatek,mt8173-mdp-rdma";
+ reg = <0 0x14002000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA1>,
+<&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA1>;
+ mediatek,larb = <&larb4>;
+ };
- mdp_rsz0: rsz@14003000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14003000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ0>;
- power-domains = <&scpsys
MT8173_POWER_DOMAIN_MM>;
- };
+ mdp_rsz0: rsz@14003000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14003000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
- mdp_rsz1: rsz@14004000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14004000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ1>;
- power-domains = <&scpsys
MT8173_POWER_DOMAIN_MM>;
- };
+ mdp_rsz1: rsz@14004000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14004000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
- mdp_rsz2: rsz@14005000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14005000
[PATCH v4 0/3] Fix mdp device tree
Changes in v4: - Add backwards compability if dts is out-of-date Changes in v3: - Upload patches again because forget to add v2 in title Changes in v2: - Update commit message If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also simplifies the device tree. Although it fixes iommu assignment issue, it also break compatibility with old device tree. So, the patch in driver is needed to iterate over sibling mdp device nodes, not child ones, to keep driver work properly. Daniel Kurtz (2): arm64: dts: mt8173: Fix mdp device tree media: mtk-mdp: Fix mdp device tree Minghsiu Tsai (1): dt-bindings: mt8173: Fix mdp device tree .../devicetree/bindings/media/mediatek-mdp.txt | 12 +- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 ++--- drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 12 +- 3 files changed, 73 insertions(+), 77 deletions(-) -- 1.9.1
[PATCH v4 3/3] media: mtk-mdp: Fix mdp device tree
From: Daniel Kurtz
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
Signed-off-by: Daniel Kurtz
Signed-off-by: Minghsiu Tsai
Signed-off-by: Matthias Brugger
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7d..8134755 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
{
struct mtk_mdp_dev *mdp;
struct device *dev = &pdev->dev;
- struct device_node *node;
+ struct device_node *node, *parent;
int i, ret = 0;
mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
@@ -117,8 +117,16 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(&mdp->lock);
mutex_init(&mdp->vpulock);
+ /* Old dts had the components as child nodes */
+ if (of_get_next_child(dev->of_node, NULL)) {
+ parent = dev->of_node;
+ dev_warn(dev, "device tree is out of date\n");
+ } else {
+ parent = dev->of_node->parent;
+ }
+
/* Iterate over sibling MDP function blocks */
- for_each_child_of_node(dev->of_node, node) {
+ for_each_child_of_node(parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;
--
1.9.1
Re: [PATCH v3 0/3] Fix mdp device tree
On Mon, 2017-05-22 at 16:16 +0200, Hans Verkuil wrote: > On 05/22/2017 04:14 PM, Matthias Brugger wrote: > > > > > > On 22/05/17 11:09, Hans Verkuil wrote: > >> On 05/12/2017 05:22 AM, Minghsiu Tsai wrote: > >> > >> Who should take care of the dtsi changes? I'm not sure who maintains the > >> mdp dts. > > > > I will take care of the dtsi patches. > > > >> > >> The driver change and the dtsi change need to be in sync, so it is > >> probably easiest > >> to merge this via one tree. > >> > >> Here is my Acked-by for these three patches: > >> > >> Acked-by: Hans Verkuil > >> > >> I can take all three, provided I have the Ack of the mdp dts maintainer. > >> Or it can > >> go through him with my Ack. > >> > > > > I think we should provide backwards compability instead, as proposed here: > > http://lists.infradead.org/pipermail/linux-mediatek/2017-May/008811.html > > > > If this change is ok for you, please let Minghsiu know so that he can > > provide a v4. > > That's a lot better. In that case I can take the media patches and you the > dts. > > I'll wait for the v4. > Hi Hans, Matthias, I have uploaded v4, thanks. > Regards, > > Hans > > > > > Regards, > > Matthias > > > >> Regards, > >> > >>Hans > >> > >>> Changes in v3: > >>> - Upload patches again because forget to add v2 in title > >>> > >>> Changes in v2: > >>> - Update commit message > >>> > >>> If the mdp_* nodes are under an mdp sub-node, their corresponding > >>> platform device does not automatically get its iommu assigned properly. > >>> > >>> Fix this by moving the mdp component nodes up a level such that they are > >>> siblings of mdp and all other SoC subsystems. This also simplifies the > >>> device tree. > >>> > >>> Although it fixes iommu assignment issue, it also break compatibility > >>> with old device tree. So, the patch in driver is needed to iterate over > >>> sibling mdp device nodes, not child ones, to keep driver work properly. > >>> > >>> Daniel Kurtz (2): > >>>arm64: dts: mt8173: Fix mdp device tree > >>>media: mtk-mdp: Fix mdp device tree > >>> > >>> Minghsiu Tsai (1): > >>>dt-bindings: mt8173: Fix mdp device tree > >>> > >>> .../devicetree/bindings/media/mediatek-mdp.txt | 12 +- > >>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 > >>> ++--- > >>> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +- > >>> 3 files changed, 64 insertions(+), 76 deletions(-) > >>> > >> >
cron job: media_tree daily build: ERRORS
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: Tue May 23 05:00:28 CEST 2017 media-tree git hash:36bcba973ad478042d1ffc6e89afd92e8bd17030 media_build git hash: c8dfc17d6d049d79497c78737625f6ea3b08c456 v4l-utils git hash: d16a17abd1d8d7885ca2f44fb295035278baa89c gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: ERRORS linux-4.9.26-i686: ERRORS linux-4.10.14-i686: ERRORS linux-4.11-i686: ERRORS linux-4.12-rc1-i686: OK linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: ERRORS linux-4.9.26-x86_64: ERRORS linux-4.10.14-x86_64: ERRORS linux-4.11-x86_64: ERRORS linux-4.12-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
