From: Frederic Chen <frederic.chen@mediatek.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: shik@chromium.org, devicetree@vger.kernel.org,
Sean.Cheng@mediatek.com,
laurent.pinchart+renesas@ideasonboard.com, Rynn.Wu@mediatek.com,
christie.yu@mediatek.com, srv_heupstream@mediatek.com,
holmes.chiou@mediatek.com, suleiman@chromium.org,
Jerry-ch.Chen@mediatek.com, jungo.lin@mediatek.com,
sj.huang@mediatek.com, yuzhao@chromium.org,
hans.verkuil@cisco.com, zwisler@chromium.org,
matthias.bgg@gmail.com, linux-mediatek@lists.infradead.org,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
Subject: Re: [RFC PATCH V1 6/6] platform: mtk-isp: Add Mediatek DIP driver
Date: Tue, 25 Jun 2019 20:16:18 +0800 [thread overview]
Message-ID: <1561464978.23799.37.camel@mtksdccf07> (raw)
In-Reply-To: <20190509094846.GA65444@google.com>
Dear Tomasz,
Would you comment on the following points in further? Thank you for the
review.
On Thu, 2019-05-09 at 18:48 +0900, Tomasz Figa wrote:
> Hi Frederic,
>
[snip]
> > +int mtk_dip_pipe_job_start(struct mtk_dip_pipe *dip_pipe,
> > + struct mtk_dip_pipe_job_info *pipe_job_info)
> > +{
> > + struct platform_device *pdev = dip_pipe->dip_dev->pdev;
> > + int ret;
> > + int out_img_buf_idx;
> > + struct img_ipi_frameparam dip_param;
> > + struct mtk_dip_dev_buffer *dev_buf_in;
> > + struct mtk_dip_dev_buffer *dev_buf_out;
> > + struct mtk_dip_dev_buffer *dev_buf_tuning;
> > +
> > + if (!pipe_job_info) {
> > + dev_err(&pdev->dev,
> > + "pipe_job_info(%p) in start can't be NULL\n",
> > + pipe_job_info);
> > + return -EINVAL;
> > + }
>
> This should be impossible to happen.
>
> > +
> > + /* We need RAW and at least MDP0 or MDP 1 buffer */
> > + if (!pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_RAW_OUT] ||
> > + (!pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_MDP0_CAPTURE] &&
> > + !pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_MDP1_CAPTURE])){
> > + struct mtk_dip_dev_buffer **map = pipe_job_info->buf_map;
> > +
> > + dev_dbg(&pdev->dev,
> > + "can't trigger job: raw(%p), mdp0(%p), mdp1(%p)\n",
> > + map[MTK_DIP_VIDEO_NODE_ID_RAW_OUT],
> > + map[MTK_DIP_VIDEO_NODE_ID_MDP0_CAPTURE],
> > + map[MTK_DIP_VIDEO_NODE_ID_MDP1_CAPTURE]);
> > + return -EINVAL;
>
> This must be validated at the time of request_validate. We can't fail at
> this stage anymore.
After the modification about checking the required buffers in
req_validate(), we got failed in the following testRequests()
of V4L2 compliance test. The V4L2 compliance test case doesn't know
which buffers of the video devices are required and expects that the
MEDIA_REQUEST_IOC_QUEUE succeed when the request has any valid buffer.
For example, when the request has MDP 0 buffer only, the DIP's
req_validate() should return an error since it also need a buffer
from RAW video device, but it make compliance test get failed.
May I still check the required buffers in req_validate() in the next
patch? I will add some note to explain that the compliance test failed
item is related to the limitation?
=======================================================
int testRequests(struct node *node, bool test_streaming)
// ......
if (i)
fail_on_test(!buf.qbuf(node));
buf.s_flags(buf.g_flags() | V4L2_BUF_FLAG_REQUEST_FD);
buf.s_request_fd(buf_req_fds[i]);
buf.s_field(V4L2_FIELD_ANY);
fail_on_test(buf.qbuf(node));
if (v4l_type_is_video(buf.g_type()) && v4l_type_is_output(buf.g_type()))
fail_on_test(buf.g_field() == V4L2_FIELD_ANY);
fail_on_test(buf.querybuf(node, i));
// ......
// LINE 1807 in v4l2-test-buffers.cpp, we will got the failed here.
// Since we need one RAW and one MDP0 buffer at least.
// v4l2-test-buffers.cpp(1807): doioctl_fd(buf_req_fds[i],
// MEDIA_REQUEST_IOC_QUEUE, 0)
// test Requests: FAIL
fail_on_test(doioctl_fd(buf_req_fds[i], MEDIA_REQUEST_IOC_QUEUE, 0));
=======================================================
> > +
> > +static int mtk_dip_vb2_queue_setup(struct vb2_queue *vq,
> > + unsigned int *num_buffers,
> > + unsigned int *num_planes,
> > + unsigned int sizes[],
> > + struct device *alloc_devs[])
> > +{
> > + struct mtk_dip_pipe *dip_pipe = vb2_get_drv_priv(vq);
> > + struct mtk_dip_video_device *node =
> > + mtk_dip_vbq_to_node(vq);
> > + struct device *dev = &dip_pipe->dip_dev->pdev->dev;
> > + struct device *buf_alloc_ctx;
> > +
[snip]
> > +
> > + if (vq->type == V4L2_BUF_TYPE_META_CAPTURE ||
> > + vq->type == V4L2_BUF_TYPE_META_OUTPUT)
> > + size = fmt->fmt.meta.buffersize;
> > + else
> > + size = fmt->fmt.pix_mp.plane_fmt[0].sizeimage;
> > +
> > + if (*num_planes) {
> > + if (sizes[0] < size) {
> > + dev_dbg(dev, "%s:%s:%s: size error(user:%d, max:%d)\n",
> > + __func__, dip_pipe->desc->name,
> > + node->desc->name, sizes[0], size);
> > + return -EINVAL;
> > + }
>
> I don't think this is an error. This is for handling VIDIOC_CREATE_BUFS,
> which can allocate for any arbitrary format.
>
> Whether the size of the buffer is big enough for current format should be
> checked in .buf_prepare callback.
When executing V4L2 compliance test, we need to check this image size to
pass the following q.create_bufs() test (LINE:709,
v4l2-test-buffers.cpp).
========================================================
node->g_fmt(fmt, q.g_type());
//....
fmt.s_height(fmt.g_height() / 2);
for (unsigned p = 0; p < fmt.g_num_planes(); p++)
fmt.s_sizeimage(fmt.g_sizeimage(p) / 2, p);
// LINE 709 in v4l2-test-buffers.cpp
// It seems that the driver needs to return EINVAL when the buffer
//size is smaller than the sizeimage required
fail_on_test(q.create_bufs(node, 1, &fmt) != EINVAL);
========================================================
The kernel document has some similar description on VIDIOC_CREATE_BUFS.
https://www.kernel.org/doc/html/latest/media/uapi/v4l/vidioc-create-bufs.html
=======================================================
Usually if the format.pix.sizeimage field is less than the minimum
required for the given format, then an error will be returned since
drivers will typically not allow this.
=======================================================
Should we check the image size of each plane here so that we can pass
the test?
>
> > + } else {
> > + *num_planes = 1;
> > + sizes[0] = size;
> > + }
> > +
> > + dev_dbg(dev, "%s:%s:%s: n_planes(%d), n_bufs(%d), size(%d)\n",
> > + __func__, dip_pipe->desc->name,
> > + node->desc->name, *num_planes, *num_buffers, sizes[0]);
> > +
> > + return 0;
> > +}
> > +
Sincerely,
Frederic Chen
WARNING: multiple messages have this Message-ID (diff)
From: Frederic Chen <frederic.chen@mediatek.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: shik@chromium.org, devicetree@vger.kernel.org,
Sean.Cheng@mediatek.com,
laurent.pinchart+renesas@ideasonboard.com, Rynn.Wu@mediatek.com,
christie.yu@mediatek.com, srv_heupstream@mediatek.com,
holmes.chiou@mediatek.com, suleiman@chromium.org,
Jerry-ch.Chen@mediatek.com, jungo.lin@mediatek.com,
sj.huang@mediatek.com, yuzhao@chromium.org,
hans.verkuil@cisco.com, zwisler@chromium.org,
matthias.bgg@gmail.com, linux-mediatek@lists.infradead.org,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
Subject: Re: [RFC PATCH V1 6/6] platform: mtk-isp: Add Mediatek DIP driver
Date: Tue, 25 Jun 2019 20:16:18 +0800 [thread overview]
Message-ID: <1561464978.23799.37.camel@mtksdccf07> (raw)
In-Reply-To: <20190509094846.GA65444@google.com>
Dear Tomasz,
Would you comment on the following points in further? Thank you for the
review.
On Thu, 2019-05-09 at 18:48 +0900, Tomasz Figa wrote:
> Hi Frederic,
>
[snip]
> > +int mtk_dip_pipe_job_start(struct mtk_dip_pipe *dip_pipe,
> > + struct mtk_dip_pipe_job_info *pipe_job_info)
> > +{
> > + struct platform_device *pdev = dip_pipe->dip_dev->pdev;
> > + int ret;
> > + int out_img_buf_idx;
> > + struct img_ipi_frameparam dip_param;
> > + struct mtk_dip_dev_buffer *dev_buf_in;
> > + struct mtk_dip_dev_buffer *dev_buf_out;
> > + struct mtk_dip_dev_buffer *dev_buf_tuning;
> > +
> > + if (!pipe_job_info) {
> > + dev_err(&pdev->dev,
> > + "pipe_job_info(%p) in start can't be NULL\n",
> > + pipe_job_info);
> > + return -EINVAL;
> > + }
>
> This should be impossible to happen.
>
> > +
> > + /* We need RAW and at least MDP0 or MDP 1 buffer */
> > + if (!pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_RAW_OUT] ||
> > + (!pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_MDP0_CAPTURE] &&
> > + !pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_MDP1_CAPTURE])){
> > + struct mtk_dip_dev_buffer **map = pipe_job_info->buf_map;
> > +
> > + dev_dbg(&pdev->dev,
> > + "can't trigger job: raw(%p), mdp0(%p), mdp1(%p)\n",
> > + map[MTK_DIP_VIDEO_NODE_ID_RAW_OUT],
> > + map[MTK_DIP_VIDEO_NODE_ID_MDP0_CAPTURE],
> > + map[MTK_DIP_VIDEO_NODE_ID_MDP1_CAPTURE]);
> > + return -EINVAL;
>
> This must be validated at the time of request_validate. We can't fail at
> this stage anymore.
After the modification about checking the required buffers in
req_validate(), we got failed in the following testRequests()
of V4L2 compliance test. The V4L2 compliance test case doesn't know
which buffers of the video devices are required and expects that the
MEDIA_REQUEST_IOC_QUEUE succeed when the request has any valid buffer.
For example, when the request has MDP 0 buffer only, the DIP's
req_validate() should return an error since it also need a buffer
from RAW video device, but it make compliance test get failed.
May I still check the required buffers in req_validate() in the next
patch? I will add some note to explain that the compliance test failed
item is related to the limitation?
=======================================================
int testRequests(struct node *node, bool test_streaming)
// ......
if (i)
fail_on_test(!buf.qbuf(node));
buf.s_flags(buf.g_flags() | V4L2_BUF_FLAG_REQUEST_FD);
buf.s_request_fd(buf_req_fds[i]);
buf.s_field(V4L2_FIELD_ANY);
fail_on_test(buf.qbuf(node));
if (v4l_type_is_video(buf.g_type()) && v4l_type_is_output(buf.g_type()))
fail_on_test(buf.g_field() == V4L2_FIELD_ANY);
fail_on_test(buf.querybuf(node, i));
// ......
// LINE 1807 in v4l2-test-buffers.cpp, we will got the failed here.
// Since we need one RAW and one MDP0 buffer at least.
// v4l2-test-buffers.cpp(1807): doioctl_fd(buf_req_fds[i],
// MEDIA_REQUEST_IOC_QUEUE, 0)
// test Requests: FAIL
fail_on_test(doioctl_fd(buf_req_fds[i], MEDIA_REQUEST_IOC_QUEUE, 0));
=======================================================
> > +
> > +static int mtk_dip_vb2_queue_setup(struct vb2_queue *vq,
> > + unsigned int *num_buffers,
> > + unsigned int *num_planes,
> > + unsigned int sizes[],
> > + struct device *alloc_devs[])
> > +{
> > + struct mtk_dip_pipe *dip_pipe = vb2_get_drv_priv(vq);
> > + struct mtk_dip_video_device *node =
> > + mtk_dip_vbq_to_node(vq);
> > + struct device *dev = &dip_pipe->dip_dev->pdev->dev;
> > + struct device *buf_alloc_ctx;
> > +
[snip]
> > +
> > + if (vq->type == V4L2_BUF_TYPE_META_CAPTURE ||
> > + vq->type == V4L2_BUF_TYPE_META_OUTPUT)
> > + size = fmt->fmt.meta.buffersize;
> > + else
> > + size = fmt->fmt.pix_mp.plane_fmt[0].sizeimage;
> > +
> > + if (*num_planes) {
> > + if (sizes[0] < size) {
> > + dev_dbg(dev, "%s:%s:%s: size error(user:%d, max:%d)\n",
> > + __func__, dip_pipe->desc->name,
> > + node->desc->name, sizes[0], size);
> > + return -EINVAL;
> > + }
>
> I don't think this is an error. This is for handling VIDIOC_CREATE_BUFS,
> which can allocate for any arbitrary format.
>
> Whether the size of the buffer is big enough for current format should be
> checked in .buf_prepare callback.
When executing V4L2 compliance test, we need to check this image size to
pass the following q.create_bufs() test (LINE:709,
v4l2-test-buffers.cpp).
========================================================
node->g_fmt(fmt, q.g_type());
//....
fmt.s_height(fmt.g_height() / 2);
for (unsigned p = 0; p < fmt.g_num_planes(); p++)
fmt.s_sizeimage(fmt.g_sizeimage(p) / 2, p);
// LINE 709 in v4l2-test-buffers.cpp
// It seems that the driver needs to return EINVAL when the buffer
//size is smaller than the sizeimage required
fail_on_test(q.create_bufs(node, 1, &fmt) != EINVAL);
========================================================
The kernel document has some similar description on VIDIOC_CREATE_BUFS.
https://www.kernel.org/doc/html/latest/media/uapi/v4l/vidioc-create-bufs.html
=======================================================
Usually if the format.pix.sizeimage field is less than the minimum
required for the given format, then an error will be returned since
drivers will typically not allow this.
=======================================================
Should we check the image size of each plane here so that we can pass
the test?
>
> > + } else {
> > + *num_planes = 1;
> > + sizes[0] = size;
> > + }
> > +
> > + dev_dbg(dev, "%s:%s:%s: n_planes(%d), n_bufs(%d), size(%d)\n",
> > + __func__, dip_pipe->desc->name,
> > + node->desc->name, *num_planes, *num_buffers, sizes[0]);
> > +
> > + return 0;
> > +}
> > +
Sincerely,
Frederic Chen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Frederic Chen <frederic.chen@mediatek.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: <hans.verkuil@cisco.com>,
<laurent.pinchart+renesas@ideasonboard.com>,
<matthias.bgg@gmail.com>, <mchehab@kernel.org>,
<yuzhao@chromium.org>, <zwisler@chromium.org>,
<linux-mediatek@lists.infradead.org>,
<linux-arm-kernel@lists.infradead.org>, <Sean.Cheng@mediatek.com>,
<sj.huang@mediatek.com>, <christie.yu@mediatek.com>,
<holmes.chiou@mediatek.com>, <Jerry-ch.Chen@mediatek.com>,
<jungo.lin@mediatek.com>, <Rynn.Wu@mediatek.com>,
<linux-media@vger.kernel.org>, <srv_heupstream@mediatek.com>,
<devicetree@vger.kernel.org>, <shik@chromium.org>,
<suleiman@chromium.org>
Subject: Re: [RFC PATCH V1 6/6] platform: mtk-isp: Add Mediatek DIP driver
Date: Tue, 25 Jun 2019 20:16:18 +0800 [thread overview]
Message-ID: <1561464978.23799.37.camel@mtksdccf07> (raw)
In-Reply-To: <20190509094846.GA65444@google.com>
Dear Tomasz,
Would you comment on the following points in further? Thank you for the
review.
On Thu, 2019-05-09 at 18:48 +0900, Tomasz Figa wrote:
> Hi Frederic,
>
[snip]
> > +int mtk_dip_pipe_job_start(struct mtk_dip_pipe *dip_pipe,
> > + struct mtk_dip_pipe_job_info *pipe_job_info)
> > +{
> > + struct platform_device *pdev = dip_pipe->dip_dev->pdev;
> > + int ret;
> > + int out_img_buf_idx;
> > + struct img_ipi_frameparam dip_param;
> > + struct mtk_dip_dev_buffer *dev_buf_in;
> > + struct mtk_dip_dev_buffer *dev_buf_out;
> > + struct mtk_dip_dev_buffer *dev_buf_tuning;
> > +
> > + if (!pipe_job_info) {
> > + dev_err(&pdev->dev,
> > + "pipe_job_info(%p) in start can't be NULL\n",
> > + pipe_job_info);
> > + return -EINVAL;
> > + }
>
> This should be impossible to happen.
>
> > +
> > + /* We need RAW and at least MDP0 or MDP 1 buffer */
> > + if (!pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_RAW_OUT] ||
> > + (!pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_MDP0_CAPTURE] &&
> > + !pipe_job_info->buf_map[MTK_DIP_VIDEO_NODE_ID_MDP1_CAPTURE])){
> > + struct mtk_dip_dev_buffer **map = pipe_job_info->buf_map;
> > +
> > + dev_dbg(&pdev->dev,
> > + "can't trigger job: raw(%p), mdp0(%p), mdp1(%p)\n",
> > + map[MTK_DIP_VIDEO_NODE_ID_RAW_OUT],
> > + map[MTK_DIP_VIDEO_NODE_ID_MDP0_CAPTURE],
> > + map[MTK_DIP_VIDEO_NODE_ID_MDP1_CAPTURE]);
> > + return -EINVAL;
>
> This must be validated at the time of request_validate. We can't fail at
> this stage anymore.
After the modification about checking the required buffers in
req_validate(), we got failed in the following testRequests()
of V4L2 compliance test. The V4L2 compliance test case doesn't know
which buffers of the video devices are required and expects that the
MEDIA_REQUEST_IOC_QUEUE succeed when the request has any valid buffer.
For example, when the request has MDP 0 buffer only, the DIP's
req_validate() should return an error since it also need a buffer
from RAW video device, but it make compliance test get failed.
May I still check the required buffers in req_validate() in the next
patch? I will add some note to explain that the compliance test failed
item is related to the limitation?
=======================================================
int testRequests(struct node *node, bool test_streaming)
// ......
if (i)
fail_on_test(!buf.qbuf(node));
buf.s_flags(buf.g_flags() | V4L2_BUF_FLAG_REQUEST_FD);
buf.s_request_fd(buf_req_fds[i]);
buf.s_field(V4L2_FIELD_ANY);
fail_on_test(buf.qbuf(node));
if (v4l_type_is_video(buf.g_type()) && v4l_type_is_output(buf.g_type()))
fail_on_test(buf.g_field() == V4L2_FIELD_ANY);
fail_on_test(buf.querybuf(node, i));
// ......
// LINE 1807 in v4l2-test-buffers.cpp, we will got the failed here.
// Since we need one RAW and one MDP0 buffer at least.
// v4l2-test-buffers.cpp(1807): doioctl_fd(buf_req_fds[i],
// MEDIA_REQUEST_IOC_QUEUE, 0)
// test Requests: FAIL
fail_on_test(doioctl_fd(buf_req_fds[i], MEDIA_REQUEST_IOC_QUEUE, 0));
=======================================================
> > +
> > +static int mtk_dip_vb2_queue_setup(struct vb2_queue *vq,
> > + unsigned int *num_buffers,
> > + unsigned int *num_planes,
> > + unsigned int sizes[],
> > + struct device *alloc_devs[])
> > +{
> > + struct mtk_dip_pipe *dip_pipe = vb2_get_drv_priv(vq);
> > + struct mtk_dip_video_device *node =
> > + mtk_dip_vbq_to_node(vq);
> > + struct device *dev = &dip_pipe->dip_dev->pdev->dev;
> > + struct device *buf_alloc_ctx;
> > +
[snip]
> > +
> > + if (vq->type == V4L2_BUF_TYPE_META_CAPTURE ||
> > + vq->type == V4L2_BUF_TYPE_META_OUTPUT)
> > + size = fmt->fmt.meta.buffersize;
> > + else
> > + size = fmt->fmt.pix_mp.plane_fmt[0].sizeimage;
> > +
> > + if (*num_planes) {
> > + if (sizes[0] < size) {
> > + dev_dbg(dev, "%s:%s:%s: size error(user:%d, max:%d)\n",
> > + __func__, dip_pipe->desc->name,
> > + node->desc->name, sizes[0], size);
> > + return -EINVAL;
> > + }
>
> I don't think this is an error. This is for handling VIDIOC_CREATE_BUFS,
> which can allocate for any arbitrary format.
>
> Whether the size of the buffer is big enough for current format should be
> checked in .buf_prepare callback.
When executing V4L2 compliance test, we need to check this image size to
pass the following q.create_bufs() test (LINE:709,
v4l2-test-buffers.cpp).
========================================================
node->g_fmt(fmt, q.g_type());
//....
fmt.s_height(fmt.g_height() / 2);
for (unsigned p = 0; p < fmt.g_num_planes(); p++)
fmt.s_sizeimage(fmt.g_sizeimage(p) / 2, p);
// LINE 709 in v4l2-test-buffers.cpp
// It seems that the driver needs to return EINVAL when the buffer
//size is smaller than the sizeimage required
fail_on_test(q.create_bufs(node, 1, &fmt) != EINVAL);
========================================================
The kernel document has some similar description on VIDIOC_CREATE_BUFS.
https://www.kernel.org/doc/html/latest/media/uapi/v4l/vidioc-create-bufs.html
=======================================================
Usually if the format.pix.sizeimage field is less than the minimum
required for the given format, then an error will be returned since
drivers will typically not allow this.
=======================================================
Should we check the image size of each plane here so that we can pass
the test?
>
> > + } else {
> > + *num_planes = 1;
> > + sizes[0] = size;
> > + }
> > +
> > + dev_dbg(dev, "%s:%s:%s: n_planes(%d), n_bufs(%d), size(%d)\n",
> > + __func__, dip_pipe->desc->name,
> > + node->desc->name, *num_planes, *num_buffers, sizes[0]);
> > +
> > + return 0;
> > +}
> > +
Sincerely,
Frederic Chen
next prev parent reply other threads:[~2019-06-25 12:16 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 10:45 [RFC PATCH V1 0/6] media: platform: Add support for Digital Image Processing (DIP) on mt8183 SoC Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` [RFC PATCH V1 1/6] dt-bindings: mt8183: Add binding for DIP shared memory Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-30 1:15 ` Rob Herring
2019-04-30 1:15 ` Rob Herring
2019-04-30 1:15 ` Rob Herring
2019-05-07 14:22 ` Frederic Chen
2019-05-07 14:22 ` Frederic Chen
2019-05-07 14:22 ` Frederic Chen
2019-05-14 16:19 ` Rob Herring
2019-05-14 16:19 ` Rob Herring
2019-05-14 16:19 ` Rob Herring
[not found] ` <CAL_JsqKGW9WqyNgqKD0MxsqxYHKZ+VNV5A2p+neGqwmKmiODOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-16 6:12 ` Tomasz Figa
2019-05-16 6:12 ` Tomasz Figa
2019-05-16 6:12 ` Tomasz Figa
2019-05-17 22:22 ` Rob Herring
2019-05-17 22:22 ` Rob Herring
2019-05-17 22:22 ` Rob Herring
2019-04-17 10:45 ` [RFC PATCH V1 3/6] dt-bindings: mt8183: Added DIP dt-bindings Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-30 1:16 ` Rob Herring
2019-04-30 1:16 ` Rob Herring
2019-04-30 1:16 ` Rob Herring
2019-05-07 14:16 ` Frederic Chen
2019-05-07 14:16 ` Frederic Chen
2019-05-14 16:14 ` Rob Herring
2019-05-14 16:14 ` Rob Herring
2019-04-17 10:45 ` [RFC PATCH V1 4/6] dts: arm64: mt8183: Add DIP nodes Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` [RFC PATCH V1 5/6] media: platform: Add Mediatek DIP driver KConfig Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` Frederic Chen
[not found] ` <20190417104511.21514-1-frederic.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-04-17 10:45 ` [RFC PATCH V1 2/6] dts: arm64: mt8183: Add DIP shared memory node Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` Frederic Chen
2019-04-17 10:45 ` [RFC PATCH V1 6/6] platform: mtk-isp: Add Mediatek DIP driver Frederic Chen
2019-04-17 10:45 ` Frederic Chen
[not found] ` <20190417104511.21514-7-frederic.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-05-09 9:48 ` Tomasz Figa
2019-05-09 9:48 ` Tomasz Figa
[not found] ` <20190509094846.GA65444-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-05-21 19:14 ` Frederic Chen
2019-05-21 19:14 ` Frederic Chen
2019-05-22 10:25 ` Tomasz Figa
2019-05-22 10:25 ` Tomasz Figa
2019-05-22 10:25 ` Tomasz Figa
2019-05-23 13:46 ` Frederic Chen
2019-05-23 13:46 ` Frederic Chen
2019-05-23 13:46 ` Frederic Chen
2019-05-29 3:38 ` Tomasz Figa
2019-05-29 3:38 ` Tomasz Figa
2019-05-29 3:38 ` Tomasz Figa
2019-06-11 8:48 ` Frederic Chen
2019-06-11 8:48 ` Frederic Chen
2019-06-11 8:48 ` Frederic Chen
2019-06-11 8:59 ` Tomasz Figa
2019-06-11 8:59 ` Tomasz Figa
2019-06-11 8:59 ` Tomasz Figa
2019-06-11 10:07 ` Frederic Chen
2019-06-11 10:07 ` Frederic Chen
2019-06-11 10:07 ` Frederic Chen
2019-06-11 10:13 ` Tomasz Figa
2019-06-11 10:13 ` Tomasz Figa
2019-06-11 10:13 ` Tomasz Figa
2019-06-25 11:35 ` Frederic Chen
2019-06-25 11:35 ` Frederic Chen
2019-06-25 11:35 ` Frederic Chen
2019-06-25 12:16 ` Frederic Chen [this message]
2019-06-25 12:16 ` Frederic Chen
2019-06-25 12:16 ` Frederic Chen
2019-06-26 4:24 ` Tomasz Figa
2019-06-26 4:24 ` Tomasz Figa
2019-06-26 4:24 ` Tomasz Figa
2019-05-22 9:51 ` Shik Chen
2019-05-22 9:51 ` Shik Chen
2019-05-22 9:51 ` Shik Chen
2019-05-23 14:24 ` Frederic Chen
2019-05-23 14:24 ` Frederic Chen
2019-05-23 14:24 ` Frederic Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1561464978.23799.37.camel@mtksdccf07 \
--to=frederic.chen@mediatek.com \
--cc=Jerry-ch.Chen@mediatek.com \
--cc=Rynn.Wu@mediatek.com \
--cc=Sean.Cheng@mediatek.com \
--cc=christie.yu@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=hans.verkuil@cisco.com \
--cc=holmes.chiou@mediatek.com \
--cc=jungo.lin@mediatek.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=shik@chromium.org \
--cc=sj.huang@mediatek.com \
--cc=srv_heupstream@mediatek.com \
--cc=suleiman@chromium.org \
--cc=tfiga@chromium.org \
--cc=yuzhao@chromium.org \
--cc=zwisler@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.