Re: [Patch v5 04/12] [media] s5p-mfc: Support MFCv10.10 buffer requirements
On Tue, 2017-06-27 at 22:30 +0200, Kamil Debski wrote:
> Hi,
>
> Please find my comments inline.
>
> On 19 June 2017 at 07:10, Smitha T Murthy wrote:
> > Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> > for MFCv10.10.
> >
> > Signed-off-by: Smitha T Murthy
> > Reviewed-by: Andrzej Hajda
> > ---
> > drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 19 +
> > drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 95
> > +++--
> > drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 2 +
> > 3 files changed, 95 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > index 1ca09d6..3f0dab3 100644
> > --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > @@ -32,5 +32,24 @@
> > #define MFC_VERSION_V100xA0
> > #define MFC_NUM_PORTS_V10 1
> >
> > +/* MFCv10 codec defines*/
> > +#define S5P_FIMV_CODEC_HEVC_ENC 26
> > +
> > +/* Encoder buffer size for MFC v10.0 */
> > +#define ENC_V100_BASE_SIZE(x, y) \
> > + (((x + 3) * (y + 3) * 8) \
> > + + ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))
> > +
> > +#define ENC_V100_H264_ME_SIZE(x, y) \
> > + (ENC_V100_BASE_SIZE(x, y) \
> > + + (DIV_ROUND_UP(x * y, 64) * 32))
> > +
> > +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> > + (ENC_V100_BASE_SIZE(x, y) \
> > + + (DIV_ROUND_UP(x * y, 128) * 16))
> > +
> > +#define ENC_V100_VP8_ME_SIZE(x, y) \
> > + ENC_V100_BASE_SIZE(x, y)
> > +
> > #endif /*_REGS_MFC_V10_H*/
> >
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > index f1a8c53..83ea733 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > @@ -64,6 +64,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> > s5p_mfc_ctx *ctx)
> > {
> > struct s5p_mfc_dev *dev = ctx->dev;
> > unsigned int mb_width, mb_height;
> > + unsigned int lcu_width = 0, lcu_height = 0;
> > int ret;
> >
> > mb_width = MB_WIDTH(ctx->img_width);
> > @@ -74,7 +75,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> > s5p_mfc_ctx *ctx)
> > ctx->luma_size, ctx->chroma_size, ctx->mv_size);
> > mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
> > } else if (ctx->type == MFCINST_ENCODER) {
> > - if (IS_MFCV8_PLUS(dev))
> > + if (IS_MFCV10(dev)) {IZE_V10 (15 * SZ_1K)
> > + ctx->tmv_buffer_size = 0;
>
> It would look much better to surround the above with braces, even
> though it's only a single line.
>
I will add the braces in the next version.
> > + } else if (IS_MFCV8_PLUS(dev))
> > ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> > ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width,
> > mb_height),
> > S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> > @@ -82,13 +85,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> > s5p_mfc_ctx *ctx)
> > ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> > ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width,
> > mb_height),
> > S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> > -
> > - ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> > - S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> > - S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> > - ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> > - S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> > - S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> > + if (IS_MFCV10(dev)) {
> > + lcu_width = enc_lcu_width(ctx->img_width);
> > + lcu_height = enc_lcu_height(ctx->img_height);
> > + if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> > + ctx->luma_dpb_size =
> > + ALIGN((mb_width * 16), 64)
> > + * ALIGN((mb_height * 16), 32)
> > + + 64;
> > + ctx->chroma_dpb_size =
> > + ALIGN((mb_width * 16), 64)
> > + * (mb_height * 8)
> > + + 64;
> > + } else {
> > + ctx->luma_dpb_size =
> > + ALIGN((lcu_width * 32), 64)
> > + * ALIGN((lcu_height * 32), 32)
> > + + 64;
> > +
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: Wed Jun 28 05:00:17 CEST 2017 media-tree git hash:2748e76ddb2967c4030171342ebdd3faa6a5e8e8 media_build git hash: bf38fb5438c3cfd90a7496e951c6902111b77587 v4l-utils git hash: 1ae9a7adea3766879935dfede90d5aefd954c786 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-arm-stm32: 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: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: ERRORS linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: WARNINGS 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: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9.26-i686: OK linux-4.10.14-i686: OK linux-4.11-i686: OK linux-4.12-rc1-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS 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: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9.26-x86_64: WARNINGS linux-4.10.14-x86_64: WARNINGS linux-4.11-x86_64: WARNINGS 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[PATCH 2/3] media: ti-vpe: cal: use of_graph_get_remote_endpoint()
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()")
drivers/media/platform/ti-vpe/cal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/cal.c
b/drivers/media/platform/ti-vpe/cal.c
index 177faa3..0c7ddf8 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1702,7 +1702,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx,
int inst)
asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
asd->match.fwnode.fwnode = of_fwnode_handle(sensor_node);
- remote_ep = of_parse_phandle(ep_node, "remote-endpoint", 0);
+ remote_ep = of_graph_get_remote_endpoint(ep_node);
if (!remote_ep) {
ctx_dbg(3, ctx, "can't get remote-endpoint\n");
goto cleanup_exit;
--
1.9.1
Re: [PATCH 1/5] [media] rockchip/rga: v4l2 m2m support
Hi,
2017-06-27 16:39 GMT+08:00 Tomasz Figa :
> Hi Jacob,
>
> Please see my comments inline.
>
> On Mon, Jun 26, 2017 at 11:51 PM, Jacob Chen wrote:
>> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
>> accelerates 2D graphics operations, such as point/line drawing, image
>> scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
> [snip]
>> +static int rga_buf_init(struct vb2_buffer *vb)
>> +{
>> + struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
>> + struct rockchip_rga *rga = ctx->rga;
>> + struct sg_table *sgt;
>> + struct scatterlist *sgl;
>> + unsigned int *pages;
>> + struct rga_buf *buf;
>> + unsigned int address, len, i, p;
>> + unsigned int mapped_size = 0;
>> +
>> + /* Create local MMU table for RGA */
>> + sgt = vb2_plane_cookie(vb, 0);
>> +
>> + /*
>> +* Alloc (2^3 * 4K) = 32K byte for storing pages, those space could
>> +* cover 32K * 4K = 128M ram address.
>
> Unless I'm missing something, there is 1024 32-bit values in one 4K
> page, which can point to 4 MB of memory. The code allocates 8 of them,
> which in total allows at most 32 MB per buffer.
>
>> +*/
>> + pages = (unsigned int *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 3);
>
> This is rather unfortunate and you should expect failures here on
> actively used systems with uptime longer than few hours. Changing this
> to dma_alloc_coherent() and enabling CMA _might_ give you a bit better
> success rate, but...
>
I decide to alloc a page pool when driver probe and get page from that poll.
> Normally, this kind of (scatter-gather capable) hardware would allow
> some kind of linking of separate pages, e.g. last entry in the page
> would point to the next page, or something like that. Doesn't this RGA
> block have something similar?
>
> Best regards,
> Tomasz
Re: [PATCH] rpmsg: Solve circular dependencies involving RPMSG_VIRTIO
Hi Bjorn, Thanks for the patch. >> >> On 06/27/2017 01:43 AM, Bjorn Andersson wrote: >>> While it's very common to use RPMSG for communicating with firmware >>> running on these remoteprocs there is no functional dependency on RPMSG. >> >> This is not entirely accurate though. RPMSG is the IPC transport on >> these remoteprocs, you seem to suggest that there are alternatives for >> these remoteprocs. Without RPMSG, you can boot, but you will not be able >> to talk to the remoteprocs, so I would call it a functional dependency. >> > > IMHO this functional dependency is not from the remoteproc driver but > your system (and firmware) design. It should be possible to write > firmware that exposes any other type of virtio device. You may want to add this clarification to your commit description then. > >>> As such RPMSG should be selected by the system integrator and not >>> automatically by the remoteproc drivers. >>> >>> This does solve problems reported with circular Kconfig dependencies for >>> Davinci and Keystone remoteproc drivers. >> >> The Keystone one issue shows up on linux-next (and not on 4.12-rcX) due >> to the differing options on RESET_CONTROLLER on VIDEO_QCOM_VENUS >> (through QCOM_SCOM). > > That's probably why I didn't see this when build testing before pushing > this. > >> This can also be resolved by changing the depends on RESET_CONTROLLER >> to a select RESET_CONTROLLER or dropping the line. >> > > Except that this would violate the general rule of "don't use 'select' > for user-selectable options". Yeah well, there seems to all sorts of usage w.r.t RESET_CONTROLLER and VIRTIO. And if the ARCHs enable the ARCH_HAS_RESET_CONTROLLER, the RESET_CONTROLLER dependencies are not even needed. A quick grep on 4.12-rc7 yielded 20 occurrences that uses depends on and 21 for selects RESET_CONTROLLER. Similar numbers on VIRTIO are 9 and 9 (with a split between different VIRTIO drivers even). > >> The davinci one is tricky though, as I did change it from using a select >> to a depends on dependency, and obviously ppc64_defconfig is something >> that I would not check. Posted a cleanup series that removes the VIRTUALIZATION dependency from REMOTEPROC and RPMSG_VIRTIO options, the latter fixes the ppc64_defconfig issue with davinci remoteproc. >> > > While I hate the process of figuring out and enable all the dependencies > to be able to enable a particular config, this change does reduce the > risk of running into more of these cyclic dependencies. > >> This patch definitely resolves both issues, but it is not obvious that >> someone would also have to enable RPMSG_VIRTIO to have these remoteprocs >> useful when looking at either of the menuconfig help. >> > > This is a common issue we have with config options and while I hate to > add another item to the list of things that you can miss in your system > configuration I would prefer that my Kconfig is maintainable. > > This also means that most remoteproc drivers should "depends on MAILBOX" > and not select either the framework or the specific drivers. But let's > try to ignore that until after the merge window. Yeah ok, as long as you follow a consistent rule across all remoteproc/rpmsg drivers, that's fine. In fact, other than RPMSG_VIRTIO, the two drivers I added for this merge window do use/switches to a depends on convention. regards Suman
Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote: >> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki : >> >> On 06/26/2017 12:35 PM, Hugues FRUCHET wrote: What I am missing to support the GTA04 camera is the control of the optional "vana-supply". So the driver does not power up the camera module when needed and therefore probing fails. - vana-supply: a regulator to power up the camera module. Driver code is not complex to add: >> >>> Yes, I saw it in your code, but as I don't have any programmable power >>> supply on my setup, I have not pushed this commit. >> >> Since you are about to add voltage supplies to the DT binding I'd suggest >> to include all three voltage supplies of the sensor chip. Looking at the >> OV9650 >> and the OV9655 datasheet there are following names used for the voltage >> supply >> pins: >> >> AVDD - Analog power supply, >> DVDD - Power supply for digital core logic, >> DOVDD - Digital power supply for I/O. > > The latter two are usually not independently switchable from the SoC power > the module is connected to. > > And sometimes DVDD and DOVDD are connected together. > > So the driver can't make much use of knowing or requesting them because the > 1.8V supply is always active, even during suspend. > >> >> I doubt the sensor can work without any of these voltage supplies, thus >> regulator_get_optional() should not be used. I would just use the regulator >> bulk API to handle all three power supplies. > > The digital part works with AVDD turned off. So the LDO supplying AVDD should > be switchable to save power (&vaux3 on the GTA04 device).> > But not all designs can switch it off. Hence the idea to define it as an > /optional/ regulator. If it is not defined by DT, the driver simply assumes > it is always powered on. I didn't say we can't define regulator supply properties as optional in the DT binding. If we define them as such and any of these *-supply properties is missing in DT with regulator_get() the regulator core will use dummy regulator for that particular voltage supply. While with regulator_get_optional() -ENODEV is returned when the regulator cannot be found. > So in summary we only need AVDD switched for the GTA04 - but it does not > matter if the others are optional properties. We would not use them. > > It does matter if they are mandatory because it adds DT complexity (size > and processing) without added function. We should not be defining DT binding only with selected use cases/board designs in mind. IMO all three voltage supplies should be listed in the binding, presumably all can be made optional, with an assumption that when the property is missing selected pin is hooked up to a fixed regulator. -- Thanks, Sylwester
Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs
Hi, According to patch work, this patch are not approved yet and its status are "Changes Requested." What changes are necessary actually? If there is no necessary change, can you approve this patch? Best, Hirokazu Honda On Thu, Jun 8, 2017 at 2:33 PM, Joe Perches wrote: > On Thu, 2017-06-08 at 14:24 +0900, Tomasz Figa wrote: >> On Thu, Jun 8, 2017 at 2:16 PM, Joe Perches wrote: > [] >> > If there automated systems that rely on specific levels, then >> > changing the levels of individual messages could also cause >> > those automated systems to fail. >> >> Well, that might be true for some of them indeed. I was thinking about >> our use case, which relies on particular numbers to get expected >> verbosity levels not caring about particular messages. I guess the >> break all or none rule is going to apply here, so we should do the >> bitmap conversion indeed. :) >> >> On the other hand, I think it would be still preferable to do the >> conversion in a separate patch. > > Right. No worries. >
Re: [PATCH] rpmsg: Solve circular dependencies involving RPMSG_VIRTIO
On Tue 27 Jun 12:08 PDT 2017, Suman Anna wrote: > Hi Bjorn, > > Thanks for the patch. > > On 06/27/2017 01:43 AM, Bjorn Andersson wrote: > > While it's very common to use RPMSG for communicating with firmware > > running on these remoteprocs there is no functional dependency on RPMSG. > > This is not entirely accurate though. RPMSG is the IPC transport on > these remoteprocs, you seem to suggest that there are alternatives for > these remoteprocs. Without RPMSG, you can boot, but you will not be able > to talk to the remoteprocs, so I would call it a functional dependency. > IMHO this functional dependency is not from the remoteproc driver but your system (and firmware) design. It should be possible to write firmware that exposes any other type of virtio device. > > As such RPMSG should be selected by the system integrator and not > > automatically by the remoteproc drivers. > > > > This does solve problems reported with circular Kconfig dependencies for > > Davinci and Keystone remoteproc drivers. > > The Keystone one issue shows up on linux-next (and not on 4.12-rcX) due > to the differing options on RESET_CONTROLLER on VIDEO_QCOM_VENUS > (through QCOM_SCOM). That's probably why I didn't see this when build testing before pushing this. > This can also be resolved by changing the depends on RESET_CONTROLLER > to a select RESET_CONTROLLER or dropping the line. > Except that this would violate the general rule of "don't use 'select' for user-selectable options". > The davinci one is tricky though, as I did change it from using a select > to a depends on dependency, and obviously ppc64_defconfig is something > that I would not check. > While I hate the process of figuring out and enable all the dependencies to be able to enable a particular config, this change does reduce the risk of running into more of these cyclic dependencies. > This patch definitely resolves both issues, but it is not obvious that > someone would also have to enable RPMSG_VIRTIO to have these remoteprocs > useful when looking at either of the menuconfig help. > This is a common issue we have with config options and while I hate to add another item to the list of things that you can miss in your system configuration I would prefer that my Kconfig is maintainable. This also means that most remoteproc drivers should "depends on MAILBOX" and not select either the framework or the specific drivers. But let's try to ignore that until after the merge window. Regards, Bjorn > regards > Suman > > > > > Signed-off-by: Bjorn Andersson > > --- > > drivers/media/platform/Kconfig | 2 +- > > drivers/remoteproc/Kconfig | 4 > > drivers/rpmsg/Kconfig | 20 +--- > > 3 files changed, 10 insertions(+), 16 deletions(-) > > > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > > index 1313cd533436..cb2f31cd0088 100644 > > --- a/drivers/media/platform/Kconfig > > +++ b/drivers/media/platform/Kconfig > > @@ -382,10 +382,10 @@ config VIDEO_STI_DELTA_DRIVER > > tristate > > depends on VIDEO_STI_DELTA > > depends on VIDEO_STI_DELTA_MJPEG > > + depends on RPMSG > > default VIDEO_STI_DELTA_MJPEG > > select VIDEOBUF2_DMA_CONTIG > > select V4L2_MEM2MEM_DEV > > - select RPMSG > > > > endif # VIDEO_STI_DELTA > > > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > > index b950e6cd4ba2..3b16f422d30c 100644 > > --- a/drivers/remoteproc/Kconfig > > +++ b/drivers/remoteproc/Kconfig > > @@ -21,7 +21,6 @@ config OMAP_REMOTEPROC > > depends on REMOTEPROC > > select MAILBOX > > select OMAP2PLUS_MBOX > > - select RPMSG_VIRTIO > > help > > Say y here to support OMAP's remote processors (dual M3 > > and DSP on OMAP4) via the remote processor framework. > > @@ -53,7 +52,6 @@ config DA8XX_REMOTEPROC > > depends on ARCH_DAVINCI_DA8XX > > depends on REMOTEPROC > > depends on DMA_CMA > > - select RPMSG_VIRTIO > > help > > Say y here to support DA8xx/OMAP-L13x remote processors via the > > remote processor framework. > > @@ -76,7 +74,6 @@ config KEYSTONE_REMOTEPROC > > depends on ARCH_KEYSTONE > > depends on RESET_CONTROLLER > > depends on REMOTEPROC > > - select RPMSG_VIRTIO > > help > > Say Y here here to support Keystone remote processors (DSP) > > via the remote processor framework. > > @@ -133,7 +130,6 @@ config ST_REMOTEPROC > > depends on REMOTEPROC > > select MAILBOX > > select STI_MBOX > > - select RPMSG_VIRTIO > > help > > Say y here to support ST's adjunct processors via the remote > > processor framework. > > diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig > > index 2a5d2b446de2..46f3f2431d68 100644 > > --- a/drivers/rpmsg/Kconfig > > +++ b/drivers/rpmsg/Kconfig > > @@ -1,8 +1,5 @@ > > -menu "Rpmsg drivers" > > - > > -# RPMSG always gets selected by whoever wants it > > -config RPMSG > > - tristat
Re: [PATCH v4 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver
Hi Jose,
On 06/27/2017 10:43 AM, Jose Abreu wrote:
> On 25-06-2017 22:13, Sylwester Nawrocki wrote:
>> On 06/20/2017 07:26 PM, 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.
>>> Signed-off-by: Jose Abreu
>>> +static int dw_hdmi_phy_init(struct dw_hdmi_dev *dw_dev)
>>> +{
>>> + struct dw_phy_pdata *phy = &dw_dev->phy_config;
>>> + const struct of_device_id *of_id;
>>> + struct of_dev_auxdata lookup;
>> struct of_dev_auxdata lookup = { };
>>
>> You could initialize to 0 here and...
>>
>>> + struct device_node *child;
>>> + const char *drvname;
>>> + int ret;
>>> +
>>> + child = dw_hdmi_get_phy_of_node(dw_dev, &of_id);
>>> + if (!child || !of_id || !of_id->data) {
>>> + dev_err(dw_dev->dev, "no supported phy found in DT\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + drvname = of_id->data;
>>> + phy->funcs = &dw_hdmi_phy_funcs;
>>> + phy->funcs_arg = dw_dev;
>>> +
>>> + lookup.compatible = (char *)of_id->compatible;
>>> + lookup.phys_addr = 0x0;
>>> + lookup.name = NULL;
>>
>> ...drop these two assignments.
>
> Ok.
>
>>> + lookup.platform_data = phy;
>>> +
>>> + request_module(drvname);
>>
>> I'd say this request_module() is not needed when you use the v4l2-async
>> subnotifiers and the modules are properly installed in the file system.
>> I might be missing something though.
>
> Hmm, well I didn't actually test without request_module but I
> think its needed, otherwise I would have to do:
>
> modprobe phy_module
> modprobe controller_module
>
> With request_module I just have to do:
>
> modprobe controller_module
If you are sure you need it I'm not against that. But assuming you have udev
in your system it should also work like this, without request_module():
1. modprobe controller_module -> phy device is created in the kernel, uevent
sent
2. udev receives uevent, finds matching module and does modprobe phy_module
Remaining part is as before: phy_module registers the driver which gets matched
with
phy device; probe() is called which registers v4l2 subdev which then is
registered
to v4l2_device through the v4l2-async mechanism.
All this assumes udev is running and modules are installed in
/lib/modules/$(uname -r).
E.g. there should be your module alias as shown by modinfo phy_module in
/lib/modules/$(uname -r)/modules.alias.
>>> + ret = of_platform_populate(dw_dev->of_node, NULL, &lookup, dw_dev->dev);
>>> + if (ret) {
>>> + dev_err(dw_dev->dev, "failed to populate phy driver\n");
>>> + return ret;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void dw_hdmi_phy_exit(struct dw_hdmi_dev *dw_dev)
>>> +{
>>> + of_platform_depopulate(dw_dev->dev);
>>> +}
>>> +static int dw_hdmi_v4l2_notify_complete(struct v4l2_async_notifier
>>> *notifier)
>>> +{
>>> + struct dw_hdmi_dev *dw_dev = notifier_to_dw_dev(notifier);
>>> + int ret;
>>> +
>>> + ret = v4l2_device_register_subdev_nodes(&dw_dev->v4l2_dev);
>>
>> There shouldn't be multiple struct v4l2_device instances, instead we should
>> have only one created by the main driver. AFAIU, in your case it would be
>> driver associated with the dw-hdmi-soc DT node. And normally such a top
>> level
>> driver creates subdev device nodes when its all required sub-devices are
>> available.
>>
>> I think this patch could be useful for you:
>> https://patchwork.linuxtv.org/patch/41834
>>
>> With that the dw-hdmi-soc driver would have it's v4l2-async notifier's
>> notify_complete() callback called only when both the hdmi-rx and the
>> hdmi-phy subdevs are registered.
>
> Yeah, I saw the patches. I just implemented this way because they
> are not merged yet, right?
I think these patches will be merged in v4.14-rc1, so together with your driver.
You could apply them locally and indicate that your series depends on them in
the cover letter.
>>> + if (ret) {
>>> + dev_err(dw_dev->dev, "failed to register subdev nodes\n");
>>> + return ret;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +static int dw_hdmi_rx_probe(struct platform_device *pdev)
>>> +{
>>> + /* V4L2 initialization */
>>> + sd = &dw_dev->sd;
>>> + v4l2_subdev_init(sd, &dw_hdmi_sd_ops);
>>> + strlcpy(sd->name, dev_name(dev), sizeof(sd->name));
>>> + sd->dev = dev;
>>> + sd->internal_ops = &dw_hdmi_internal_ops;
>>> + sd->flags |= V4L2_SUBDEV_FL_HAS_EVENTS;
>>
>> Don't you also need V4L2_SUBDEV_FL_HAS_DEVNODE flag set?
>
> Ouch. Yes I need otherwise the subdev will not be associated with
> the v4l2_device.
This flag indicates that the v4l2 subdev device node (/dev/v4l-subdev?)
should be created for this subdevice.
---
Regards,
Sylwester
Re: [Patch v5 04/12] [media] s5p-mfc: Support MFCv10.10 buffer requirements
Hi,
Please find my comments inline.
On 19 June 2017 at 07:10, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy
> Reviewed-by: Andrzej Hajda
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 19 +
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 95
> +++--
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 2 +
> 3 files changed, 95 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index 1ca09d6..3f0dab3 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,5 +32,24 @@
> #define MFC_VERSION_V100xA0
> #define MFC_NUM_PORTS_V10 1
>
> +/* MFCv10 codec defines*/
> +#define S5P_FIMV_CODEC_HEVC_ENC 26
> +
> +/* Encoder buffer size for MFC v10.0 */
> +#define ENC_V100_BASE_SIZE(x, y) \
> + (((x + 3) * (y + 3) * 8) \
> + + ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))
> +
> +#define ENC_V100_H264_ME_SIZE(x, y) \
> + (ENC_V100_BASE_SIZE(x, y) \
> + + (DIV_ROUND_UP(x * y, 64) * 32))
> +
> +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> + (ENC_V100_BASE_SIZE(x, y) \
> + + (DIV_ROUND_UP(x * y, 128) * 16))
> +
> +#define ENC_V100_VP8_ME_SIZE(x, y) \
> + ENC_V100_BASE_SIZE(x, y)
> +
> #endif /*_REGS_MFC_V10_H*/
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index f1a8c53..83ea733 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -64,6 +64,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)
> {
> struct s5p_mfc_dev *dev = ctx->dev;
> unsigned int mb_width, mb_height;
> + unsigned int lcu_width = 0, lcu_height = 0;
> int ret;
>
> mb_width = MB_WIDTH(ctx->img_width);
> @@ -74,7 +75,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)
> ctx->luma_size, ctx->chroma_size, ctx->mv_size);
> mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
> } else if (ctx->type == MFCINST_ENCODER) {
> - if (IS_MFCV8_PLUS(dev))
> + if (IS_MFCV10(dev)) {IZE_V10 (15 * SZ_1K)
> + ctx->tmv_buffer_size = 0;
It would look much better to surround the above with braces, even
though it's only a single line.
> + } else if (IS_MFCV8_PLUS(dev))
> ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width,
> mb_height),
> S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> @@ -82,13 +85,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)
> ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width,
> mb_height),
> S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> -
> - ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> - ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> + if (IS_MFCV10(dev)) {
> + lcu_width = enc_lcu_width(ctx->img_width);
> + lcu_height = enc_lcu_height(ctx->img_height);
> + if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> + ctx->luma_dpb_size =
> + ALIGN((mb_width * 16), 64)
> + * ALIGN((mb_height * 16), 32)
> + + 64;
> + ctx->chroma_dpb_size =
> + ALIGN((mb_width * 16), 64)
> + * (mb_height * 8)
> + + 64;
> + } else {
> + ctx->luma_dpb_size =
> + ALIGN((lcu_width * 32), 64)
> + * ALIGN((lcu_height * 32), 32)
> + + 64;
> + ctx->chroma_dpb_size =
> + ALIGN((lcu_width * 32), 64)
> + * (lcu_height * 16)
> + + 64;
> + }
> + } else {
>
Re: [PATCH 2/3] [media] venus: don't abuse dma_alloc for non-DMA allocations
On Tue, Jun 27, 2017 at 9:39 PM, Stanimir Varbanov wrote: > Hi Arnd, > > On 27.06.2017 18:02, Arnd Bergmann wrote: >> >> In venus_boot(), we pass a pointer to a phys_addr_t >> into dmam_alloc_coherent, which the compiler warns about: >> >> platform/qcom/venus/firmware.c: In function 'venus_boot': >> platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of >> 'dmam_alloc_coherent' from incompatible pointer type >> [-Werror=incompatible-pointer-types] >> >> The returned DMA address is later passed on to a function that >> takes a phys_addr_t, so it's clearly wrong to use the DMA >> mapping interface here: the memory may be uncached, or the >> address may be completely wrong if there is an IOMMU connected >> to the device. >> >> My interpretation is that using dmam_alloc_coherent() had two >> purposes: >> >> a) get a chunk of consecutive memory that may be larger than >> the limit for kmalloc() >> >> b) use the devres infrastructure to simplify the unwinding >> in the error case. > > > The intension here is to use per-device memory which is removed from kernel > allocator, that memory is used by remote processor (Venus) for its code > section and system memory, the memory must not be mapped to kernel to avoid > any cache issues. > > As the memory in subject is reserved per-device memory the only legal way to > allocate it is by dmam_alloc_coherent() -> dma_alloc_from_coherent(). > > For me the confusion comes from phys_addr_t which is passed to > qcom_mdt_load() and then the address passed to qcom_scm_pas_mem_setup() > which probably protects that physical memory. And the tz really expects > physical address. > > The only solution I see is by casting dma_addr_t to phys_addr_t. Yes it is > ugly but what is proper solution then? If you actually have a separate remote processor that accesses this memory, then qcom_mdt_load() is the wrong interface, as it takes a physical address, and we need to introduce another interface that can take a DMA address relative to a particular device. You cannot cast between the two types because phys_addr_t is an address as seen from the CPU, and dma_addr_t is seen by a particular device, and can only be used together with that device pointer. It looks like the pointer gets passed down to qcom_scm_call(dev, QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_MEM_SETUP_CMD, ...), which in turn takes a 32-bit address, suggesting that this is indeed a dma address for that device (possibly going through an IOMMU), so maybe it just needs to all be changed to dma_addr_t. Is there any official documentation for qcom_scm_call() that clarifies what address space the arguments are in? Arnd
Re: [PATCH 3/3] [media] venus: fix compile-test build on non-qcom ARM platform
Hi Arnd,
On 27.06.2017 18:02, Arnd Bergmann wrote:
If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:
ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko]
undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko]
undefined!
Ahh, thanks for the fix, these two will also pursuing me in my dreams.
This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built.
Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")
Signed-off-by: Arnd Bergmann
Reviewed-by: Stanimir Varbanov
---
drivers/media/platform/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index cb2f31cd0088..635c53e61f8a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -475,8 +475,8 @@ config VIDEO_QCOM_VENUS
tristate "Qualcomm Venus V4L2 encoder/decoder driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
- select QCOM_MDT_LOADER if (ARM || ARM64)
- select QCOM_SCM if (ARM || ARM64)
+ select QCOM_MDT_LOADER if ARCH_QCOM
+ select QCOM_SCM if ARCH_QCOM
select VIDEOBUF2_DMA_SG
select V4L2_MEM2MEM_DEV
---help---
regards,
Stan
Re: [PATCH 1/3] [media] venus: mark PM functions as __maybe_unused
Hi Arnd,
Thanks for the catch!
On 27.06.2017 18:02, Arnd Bergmann wrote:
Without PM support, gcc warns about two unused functions:
platform/qcom/venus/core.c:146:13: error: 'venus_clks_disable' defined but not
used [-Werror=unused-function]
platform/qcom/venus/core.c:126:12: error: 'venus_clks_enable' defined but not
used [-Werror=unused-function]
The problem as usual are incorrect #ifdefs, so the easiest fix
is to do away with the #ifdef completely and mark the suspend/resume
handlers as __maybe_unused, which they are.
Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper
functions")
Signed-off-by: Arnd Bergmann
Reviewed-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index d8cbe8549d97..47f79637938c 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -270,8 +270,7 @@ static int venus_remove(struct platform_device *pdev)
return ret;
}
-#ifdef CONFIG_PM
-static int venus_runtime_suspend(struct device *dev)
+static __maybe_unused int venus_runtime_suspend(struct device *dev)
{
struct venus_core *core = dev_get_drvdata(dev);
int ret;
@@ -283,7 +282,7 @@ static int venus_runtime_suspend(struct device *dev)
return ret;
}
-static int venus_runtime_resume(struct device *dev)
+static __maybe_unused int venus_runtime_resume(struct device *dev)
{
struct venus_core *core = dev_get_drvdata(dev);
int ret;
@@ -302,7 +301,6 @@ static int venus_runtime_resume(struct device *dev)
venus_clks_disable(core);
return ret;
}
-#endif
static const struct dev_pm_ops venus_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
Re: [PATCH 2/3] [media] venus: don't abuse dma_alloc for non-DMA allocations
Hi Arnd,
On 27.06.2017 18:02, Arnd Bergmann wrote:
In venus_boot(), we pass a pointer to a phys_addr_t
into dmam_alloc_coherent, which the compiler warns about:
platform/qcom/venus/firmware.c: In function 'venus_boot':
platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of
'dmam_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
The returned DMA address is later passed on to a function that
takes a phys_addr_t, so it's clearly wrong to use the DMA
mapping interface here: the memory may be uncached, or the
address may be completely wrong if there is an IOMMU connected
to the device.
My interpretation is that using dmam_alloc_coherent() had two
purposes:
a) get a chunk of consecutive memory that may be larger than
the limit for kmalloc()
b) use the devres infrastructure to simplify the unwinding
in the error case.
The intension here is to use per-device memory which is removed from
kernel allocator, that memory is used by remote processor (Venus) for
its code section and system memory, the memory must not be mapped to
kernel to avoid any cache issues.
As the memory in subject is reserved per-device memory the only legal
way to allocate it is by dmam_alloc_coherent() ->
dma_alloc_from_coherent().
For me the confusion comes from phys_addr_t which is passed to
qcom_mdt_load() and then the address passed to qcom_scm_pas_mem_setup()
which probably protects that physical memory. And the tz really expects
physical address.
The only solution I see is by casting dma_addr_t to phys_addr_t. Yes it
is ugly but what is proper solution then?
I think ideally we'd use a devres-based version of
alloc_pages_exact() here, but since that doesn't exist,
let's use devm_get_free_pages() instead. This wastes a little
memory as the size gets rounded up to a power of two, but
is otherwise harmless. If we want to save memory here, calling
devm_free_pages() to release the memory once it is no longer
needed is probably better anyway.
Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper
functions")
Signed-off-by: Arnd Bergmann
---
The same problem exists in the drm driver, as of commit 7c65817e6d38
("drm/msm: gpu: Enable zap shader for A5XX"), and I submitted the
same patch for that already.
---
drivers/media/platform/qcom/venus/firmware.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index 1b1a4f355918..76edb9f60311 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -60,11 +60,13 @@ int venus_boot(struct device *parent, struct device
*fw_dev, const char *fwname)
mem_size = VENUS_FW_MEM_SIZE;
- mem_va = dmam_alloc_coherent(fw_dev, mem_size, &mem_phys, GFP_KERNEL);
+ mem_va = (void *)devm_get_free_pages(parent, GFP_KERNEL,
+get_order(mem_size));
if (!mem_va) {
ret = -ENOMEM;
goto err_unreg_device;
}
+ mem_phys = virt_to_phys(mem_va);
ret = request_firmware(&mdt, fwname, fw_dev);
if (ret < 0)
regards,
Stan
Re: [PATCH] rpmsg: Solve circular dependencies involving RPMSG_VIRTIO
Hi Bjorn, Thanks for the patch. On 06/27/2017 01:43 AM, Bjorn Andersson wrote: > While it's very common to use RPMSG for communicating with firmware > running on these remoteprocs there is no functional dependency on RPMSG. This is not entirely accurate though. RPMSG is the IPC transport on these remoteprocs, you seem to suggest that there are alternatives for these remoteprocs. Without RPMSG, you can boot, but you will not be able to talk to the remoteprocs, so I would call it a functional dependency. > As such RPMSG should be selected by the system integrator and not > automatically by the remoteproc drivers. > > This does solve problems reported with circular Kconfig dependencies for > Davinci and Keystone remoteproc drivers. The Keystone one issue shows up on linux-next (and not on 4.12-rcX) due to the differing options on RESET_CONTROLLER on VIDEO_QCOM_VENUS (through QCOM_SCOM). This can also be resolved by changing the depends on RESET_CONTROLLER to a select RESET_CONTROLLER or dropping the line. The davinci one is tricky though, as I did change it from using a select to a depends on dependency, and obviously ppc64_defconfig is something that I would not check. This patch definitely resolves both issues, but it is not obvious that someone would also have to enable RPMSG_VIRTIO to have these remoteprocs useful when looking at either of the menuconfig help. regards Suman > > Signed-off-by: Bjorn Andersson > --- > drivers/media/platform/Kconfig | 2 +- > drivers/remoteproc/Kconfig | 4 > drivers/rpmsg/Kconfig | 20 +--- > 3 files changed, 10 insertions(+), 16 deletions(-) > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 1313cd533436..cb2f31cd0088 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -382,10 +382,10 @@ config VIDEO_STI_DELTA_DRIVER > tristate > depends on VIDEO_STI_DELTA > depends on VIDEO_STI_DELTA_MJPEG > + depends on RPMSG > default VIDEO_STI_DELTA_MJPEG > select VIDEOBUF2_DMA_CONTIG > select V4L2_MEM2MEM_DEV > - select RPMSG > > endif # VIDEO_STI_DELTA > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > index b950e6cd4ba2..3b16f422d30c 100644 > --- a/drivers/remoteproc/Kconfig > +++ b/drivers/remoteproc/Kconfig > @@ -21,7 +21,6 @@ config OMAP_REMOTEPROC > depends on REMOTEPROC > select MAILBOX > select OMAP2PLUS_MBOX > - select RPMSG_VIRTIO > help > Say y here to support OMAP's remote processors (dual M3 > and DSP on OMAP4) via the remote processor framework. > @@ -53,7 +52,6 @@ config DA8XX_REMOTEPROC > depends on ARCH_DAVINCI_DA8XX > depends on REMOTEPROC > depends on DMA_CMA > - select RPMSG_VIRTIO > help > Say y here to support DA8xx/OMAP-L13x remote processors via the > remote processor framework. > @@ -76,7 +74,6 @@ config KEYSTONE_REMOTEPROC > depends on ARCH_KEYSTONE > depends on RESET_CONTROLLER > depends on REMOTEPROC > - select RPMSG_VIRTIO > help > Say Y here here to support Keystone remote processors (DSP) > via the remote processor framework. > @@ -133,7 +130,6 @@ config ST_REMOTEPROC > depends on REMOTEPROC > select MAILBOX > select STI_MBOX > - select RPMSG_VIRTIO > help > Say y here to support ST's adjunct processors via the remote > processor framework. > diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig > index 2a5d2b446de2..46f3f2431d68 100644 > --- a/drivers/rpmsg/Kconfig > +++ b/drivers/rpmsg/Kconfig > @@ -1,8 +1,5 @@ > -menu "Rpmsg drivers" > - > -# RPMSG always gets selected by whoever wants it > -config RPMSG > - tristate > +menuconfig RPMSG > + tristate "Rpmsg drivers" > > config RPMSG_CHAR > tristate "RPMSG device interface" > @@ -15,7 +12,7 @@ config RPMSG_CHAR > > config RPMSG_QCOM_GLINK_RPM > tristate "Qualcomm RPM Glink driver" > - select RPMSG > + depends on RPMSG > depends on HAS_IOMEM > depends on MAILBOX > help > @@ -26,16 +23,17 @@ config RPMSG_QCOM_GLINK_RPM > config RPMSG_QCOM_SMD > tristate "Qualcomm Shared Memory Driver (SMD)" > depends on QCOM_SMEM > - select RPMSG > + depends on RPMSG > help > Say y here to enable support for the Qualcomm Shared Memory Driver > providing communication channels to remote processors in Qualcomm > platforms. > > config RPMSG_VIRTIO > - tristate > - select RPMSG > + tristate "Virtio remote processor messaging driver (RPMSG)" > + depends on RPMSG > select VIRTIO > select VIRTUALIZATION > - > -endmenu > + help > + Say y here to enable support for the Virtio remote processor > + messaging protocol (RPMSG). >
[PATCH v3 0/8] [media] s5p-jpeg: Various fixes and improvements
Hi, This series contains various fixes and improvements for the Samsung s5p-jpeg driver. Most of these patches come from the Chromium v3.8 kernel tree. In this v3: - Remove codec reset patch (Not needed based on documentation and no use case described in original patch commit message). - Check for Exynos5420 variant in stream error handling patch. - Add use case for resolution change event support in commit message. - Move subsampling value decoding in a separate function. - Check Exynos variant for 4:1:1 subsampling support. v2: - Remove IOMMU support patch (mapping now created automatically for single JPEG CODEC device). - Remove "Change sclk_jpeg to 166MHz" patch (can be set through DT properties). - Remove support for multi-planar APIs (Not needed). - Add comment regarding call to jpeg_bound_align_image() after qbuf. - Remove unrelated code from resolution change event support patch. Thierry Escande (3): [media] s5p-jpeg: Handle parsing error in s5p_jpeg_parse_hdr() [media] s5p-jpeg: Don't use temporary structure in s5p_jpeg_buf_queue [media] s5p-jpeg: Split s5p_jpeg_parse_hdr() Tony K Nadackal (3): [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf [media] s5p-jpeg: Correct WARN_ON statement for checking subsampling [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format henryhsu (2): [media] s5p-jpeg: Add support for resolution change event [media] s5p-jpeg: Add stream error handling for Exynos5420 drivers/media/platform/s5p-jpeg/jpeg-core.c | 186 +--- drivers/media/platform/s5p-jpeg/jpeg-core.h | 7 ++ 2 files changed, 148 insertions(+), 45 deletions(-) -- 2.7.4
[PATCH v3 4/8] [media] s5p-jpeg: Don't use temporary structure in s5p_jpeg_buf_queue
If s5p_jpeg_parse_hdr() fails to parse the JPEG header, the passed
s5p_jpeg_q_data structure is not modify so there is no need to use a
temporary structure and the field-by-field copy can be avoided.
Signed-off-by: Thierry Escande
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index df3e5ee..1769744 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2500,9 +2500,9 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
if (ctx->mode == S5P_JPEG_DECODE &&
vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
- struct s5p_jpeg_q_data tmp, *q_data;
+ struct s5p_jpeg_q_data *q_data;
- ctx->hdr_parsed = s5p_jpeg_parse_hdr(&tmp,
+ ctx->hdr_parsed = s5p_jpeg_parse_hdr(&ctx->out_q,
(unsigned long)vb2_plane_vaddr(vb, 0),
min((unsigned long)ctx->out_q.size,
vb2_get_plane_payload(vb, 0)), ctx);
@@ -2511,24 +2511,9 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
return;
}
- q_data = &ctx->out_q;
- q_data->w = tmp.w;
- q_data->h = tmp.h;
- q_data->sos = tmp.sos;
- memcpy(q_data->dht.marker, tmp.dht.marker,
- sizeof(tmp.dht.marker));
- memcpy(q_data->dht.len, tmp.dht.len, sizeof(tmp.dht.len));
- q_data->dht.n = tmp.dht.n;
- memcpy(q_data->dqt.marker, tmp.dqt.marker,
- sizeof(tmp.dqt.marker));
- memcpy(q_data->dqt.len, tmp.dqt.len, sizeof(tmp.dqt.len));
- q_data->dqt.n = tmp.dqt.n;
- q_data->sof = tmp.sof;
- q_data->sof_len = tmp.sof_len;
-
q_data = &ctx->cap_q;
- q_data->w = tmp.w;
- q_data->h = tmp.h;
+ q_data->w = ctx->out_q.w;
+ q_data->h = ctx->out_q.h;
/*
* This call to jpeg_bound_align_image() takes care of width and
--
2.7.4
[PATCH v3 7/8] [media] s5p-jpeg: Add support for resolution change event
From: henryhsu
This patch adds support for resolution change event to notify clients so
they can prepare correct output buffer. When resolution change happened,
G_FMT for CAPTURE should return old resolution and format before CAPTURE
queues streamoff.
This event is used in the Chromium browser project by the V4L2 JPEG
Decode Accelerator (V4L2JDA) to allocate output buffer.
Signed-off-by: Henry-Ruey Hsu
Signed-off-by: Thierry Escande
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 106 +---
drivers/media/platform/s5p-jpeg/jpeg-core.h | 7 ++
2 files changed, 89 insertions(+), 24 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index cca0fb8..5ad3d43 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1633,8 +1634,6 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct
v4l2_format *f)
FMT_TYPE_OUTPUT : FMT_TYPE_CAPTURE;
q_data->fmt = s5p_jpeg_find_format(ct, pix->pixelformat, f_type);
- q_data->w = pix->width;
- q_data->h = pix->height;
if (q_data->fmt->fourcc != V4L2_PIX_FMT_JPEG) {
/*
* During encoding Exynos4x12 SoCs access wider memory area
@@ -1642,6 +1641,8 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct
v4l2_format *f)
* the JPEG_IMAGE_SIZE register. In order to avoid sysmmu
* page fault calculate proper buffer size in such a case.
*/
+ q_data->w = pix->width;
+ q_data->h = pix->height;
if (ct->jpeg->variant->hw_ex4_compat &&
f_type == FMT_TYPE_OUTPUT && ct->mode == S5P_JPEG_ENCODE)
q_data->size = exynos4_jpeg_get_output_buffer_size(ct,
@@ -1717,6 +1718,15 @@ static int s5p_jpeg_s_fmt_vid_out(struct file *file,
void *priv,
return s5p_jpeg_s_fmt(fh_to_ctx(priv), f);
}
+static int s5p_jpeg_subscribe_event(struct v4l2_fh *fh,
+ const struct v4l2_event_subscription *sub)
+{
+ if (sub->type == V4L2_EVENT_SOURCE_CHANGE)
+ return v4l2_src_change_event_subscribe(fh, sub);
+
+ return -EINVAL;
+}
+
static int exynos3250_jpeg_try_downscale(struct s5p_jpeg_ctx *ctx,
struct v4l2_rect *r)
{
@@ -2042,6 +2052,9 @@ static const struct v4l2_ioctl_ops s5p_jpeg_ioctl_ops = {
.vidioc_g_selection = s5p_jpeg_g_selection,
.vidioc_s_selection = s5p_jpeg_s_selection,
+
+ .vidioc_subscribe_event = s5p_jpeg_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
/*
@@ -2434,8 +2447,17 @@ static int s5p_jpeg_job_ready(void *priv)
{
struct s5p_jpeg_ctx *ctx = priv;
- if (ctx->mode == S5P_JPEG_DECODE)
+ if (ctx->mode == S5P_JPEG_DECODE) {
+ /*
+* We have only one input buffer and one output buffer. If there
+* is a resolution change event, no need to continue decoding.
+*/
+ if (ctx->state == JPEGCTX_RESOLUTION_CHANGE)
+ return 0;
+
return ctx->hdr_parsed;
+ }
+
return 1;
}
@@ -2514,6 +2536,30 @@ static int s5p_jpeg_buf_prepare(struct vb2_buffer *vb)
return 0;
}
+static void s5p_jpeg_set_capture_queue_data(struct s5p_jpeg_ctx *ctx)
+{
+ struct s5p_jpeg_q_data *q_data = &ctx->cap_q;
+
+ q_data->w = ctx->out_q.w;
+ q_data->h = ctx->out_q.h;
+
+ /*
+* This call to jpeg_bound_align_image() takes care of width and
+* height values alignment when user space calls the QBUF of
+* OUTPUT buffer after the S_FMT of CAPTURE buffer.
+* Please note that on Exynos4x12 SoCs, resigning from executing
+* S_FMT on capture buffer for each JPEG image can result in a
+* hardware hangup if subsampling is lower than the one of input
+* JPEG.
+*/
+ jpeg_bound_align_image(ctx, &q_data->w, S5P_JPEG_MIN_WIDTH,
+ S5P_JPEG_MAX_WIDTH, q_data->fmt->h_align,
+ &q_data->h, S5P_JPEG_MIN_HEIGHT,
+ S5P_JPEG_MAX_HEIGHT, q_data->fmt->v_align);
+
+ q_data->size = q_data->w * q_data->h * q_data->fmt->depth >> 3;
+}
+
static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
{
struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
@@ -2521,7 +2567,18 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
if (ctx->mode == S5P_JPEG_DECODE &&
vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
- struct s5p_jpeg_q_data *q_data;
+ static const struct v4l2_event ev_src_ch = {
+
[PATCH v3 6/8] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format
From: Tony K Nadackal
This patch adds support for decoding 4:1:1 chroma subsampling in the
jpeg header parsing function.
Signed-off-by: Tony K Nadackal
Signed-off-by: Thierry Escande
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 0783809..cca0fb8 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1099,6 +1099,8 @@ static void skip(struct s5p_jpeg_buffer *buf, long len)
static bool s5p_jpeg_subsampling_decode(struct s5p_jpeg_ctx *ctx,
unsigned int subsampling)
{
+ unsigned int version;
+
switch (subsampling) {
case 0x11:
ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_444;
@@ -1112,6 +1114,19 @@ static bool s5p_jpeg_subsampling_decode(struct
s5p_jpeg_ctx *ctx,
case 0x33:
ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
break;
+ case 0x41:
+ /*
+* 4:1:1 subsampling only supported by 3250, 5420, and 5433
+* variants
+*/
+ version = ctx->jpeg->variant->version;
+ if (version != SJPEG_EXYNOS3250 &&
+ version != SJPEG_EXYNOS5420 &&
+ version != SJPEG_EXYNOS5433)
+ return false;
+
+ ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_411;
+ break;
default:
return false;
}
--
2.7.4
[PATCH v3 3/8] [media] s5p-jpeg: Handle parsing error in s5p_jpeg_parse_hdr()
This patch modifies the s5p_jpeg_parse_hdr() function so it only
modifies the passed s5p_jpeg_q_data structure if the jpeg header parsing
is successful.
Signed-off-by: Thierry Escande
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 38 -
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 0d935f5..df3e5ee 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1206,22 +1206,9 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data
*result,
break;
}
}
- result->w = width;
- result->h = height;
- result->sos = sos;
- result->dht.n = n_dht;
- while (n_dht--) {
- result->dht.marker[n_dht] = dht[n_dht];
- result->dht.len[n_dht] = dht_len[n_dht];
- }
- result->dqt.n = n_dqt;
- while (n_dqt--) {
- result->dqt.marker[n_dqt] = dqt[n_dqt];
- result->dqt.len[n_dqt] = dqt_len[n_dqt];
- }
- result->sof = sof;
- result->sof_len = sof_len;
- result->size = result->components = components;
+
+ if (notfound || !sos)
+ return false;
switch (subsampling) {
case 0x11:
@@ -1240,7 +1227,24 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data
*result,
return false;
}
- return !notfound && sos;
+ result->w = width;
+ result->h = height;
+ result->sos = sos;
+ result->dht.n = n_dht;
+ while (n_dht--) {
+ result->dht.marker[n_dht] = dht[n_dht];
+ result->dht.len[n_dht] = dht_len[n_dht];
+ }
+ result->dqt.n = n_dqt;
+ while (n_dqt--) {
+ result->dqt.marker[n_dqt] = dqt[n_dqt];
+ result->dqt.len[n_dqt] = dqt_len[n_dqt];
+ }
+ result->sof = sof;
+ result->sof_len = sof_len;
+ result->size = result->components = components;
+
+ return true;
}
static int s5p_jpeg_querycap(struct file *file, void *priv,
--
2.7.4
[PATCH v3 8/8] [media] s5p-jpeg: Add stream error handling for Exynos5420
From: henryhsu
On Exynos5420, the STREAM_STAT bit raised on the JPGINTST register means
there is a syntax error or an unrecoverable error on compressed file
when ERR_INT_EN is set to 1.
Fix this case and report BUF_STATE_ERROR to videobuf2.
Signed-off-by: Henry-Ruey Hsu
Signed-off-by: Thierry Escande
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 5ad3d43..c35d169 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2812,6 +2812,7 @@ static irqreturn_t exynos3250_jpeg_irq(int irq, void
*dev_id)
unsigned long payload_size = 0;
enum vb2_buffer_state state = VB2_BUF_STATE_DONE;
bool interrupt_timeout = false;
+ bool stream_error = false;
u32 irq_status;
spin_lock(&jpeg->slock);
@@ -2828,6 +2829,12 @@ static irqreturn_t exynos3250_jpeg_irq(int irq, void
*dev_id)
jpeg->irq_status |= irq_status;
+ if (jpeg->variant->version == SJPEG_EXYNOS5420 &&
+ irq_status & EXYNOS3250_STREAM_STAT) {
+ stream_error = true;
+ dev_err(jpeg->dev, "Syntax error or unrecoverable error
occurred.\n");
+ }
+
curr_ctx = v4l2_m2m_get_curr_priv(jpeg->m2m_dev);
if (!curr_ctx)
@@ -2844,7 +2851,7 @@ static irqreturn_t exynos3250_jpeg_irq(int irq, void
*dev_id)
EXYNOS3250_RDMA_DONE |
EXYNOS3250_RESULT_STAT))
payload_size = exynos3250_jpeg_compressed_size(jpeg->regs);
- else if (interrupt_timeout)
+ else if (interrupt_timeout || stream_error)
state = VB2_BUF_STATE_ERROR;
else
goto exit_unlock;
--
2.7.4
[PATCH v3 5/8] [media] s5p-jpeg: Split s5p_jpeg_parse_hdr()
This patch moves the subsampling value decoding read from the jpeg
header into its own function. This new function is called
s5p_jpeg_subsampling_decode() and returns true if it successfully
decodes the subsampling value, false otherwise.
Signed-off-by: Thierry Escande
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 42 -
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 1769744..0783809 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1096,6 +1096,29 @@ static void skip(struct s5p_jpeg_buffer *buf, long len)
get_byte(buf);
}
+static bool s5p_jpeg_subsampling_decode(struct s5p_jpeg_ctx *ctx,
+ unsigned int subsampling)
+{
+ switch (subsampling) {
+ case 0x11:
+ ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_444;
+ break;
+ case 0x21:
+ ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_422;
+ break;
+ case 0x22:
+ ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_420;
+ break;
+ case 0x33:
+ ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
+ break;
+ default:
+ return false;
+ }
+
+ return true;
+}
+
static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
unsigned long buffer, unsigned long size,
struct s5p_jpeg_ctx *ctx)
@@ -1207,26 +1230,9 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data
*result,
}
}
- if (notfound || !sos)
+ if (notfound || !sos || !s5p_jpeg_subsampling_decode(ctx, subsampling))
return false;
- switch (subsampling) {
- case 0x11:
- ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_444;
- break;
- case 0x21:
- ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_422;
- break;
- case 0x22:
- ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_420;
- break;
- case 0x33:
- ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
- break;
- default:
- return false;
- }
-
result->w = width;
result->h = height;
result->sos = sos;
--
2.7.4
[PATCH v3 2/8] [media] s5p-jpeg: Correct WARN_ON statement for checking subsampling
From: Tony K Nadackal
Corrects the WARN_ON statement for subsampling based on the
JPEG Hardware version.
Signed-off-by: Tony K Nadackal
Signed-off-by: Thierry Escande
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 623508d..0d935f5 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -614,24 +614,26 @@ static inline struct s5p_jpeg_ctx *fh_to_ctx(struct
v4l2_fh *fh)
static int s5p_jpeg_to_user_subsampling(struct s5p_jpeg_ctx *ctx)
{
- WARN_ON(ctx->subsampling > 3);
-
switch (ctx->jpeg->variant->version) {
case SJPEG_S5P:
+ WARN_ON(ctx->subsampling > 3);
if (ctx->subsampling > 2)
return V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
return ctx->subsampling;
case SJPEG_EXYNOS3250:
case SJPEG_EXYNOS5420:
+ WARN_ON(ctx->subsampling > 6);
if (ctx->subsampling > 3)
return V4L2_JPEG_CHROMA_SUBSAMPLING_411;
return exynos3250_decoded_subsampling[ctx->subsampling];
case SJPEG_EXYNOS4:
case SJPEG_EXYNOS5433:
+ WARN_ON(ctx->subsampling > 3);
if (ctx->subsampling > 2)
return V4L2_JPEG_CHROMA_SUBSAMPLING_420;
return exynos4x12_decoded_subsampling[ctx->subsampling];
default:
+ WARN_ON(ctx->subsampling > 3);
return V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
}
}
--
2.7.4
[PATCH v3 1/8] [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf
From: Tony K Nadackal When queuing an OUTPUT buffer for decoder, s5p_jpeg_parse_hdr() function parses the input jpeg file and takes the width and height parameters from its header. These new width/height values will be used for the calculation of stride. HX_JPEG Hardware needs the width and height values aligned on a 16 bits boundary. This width/height alignment is handled in the s5p_jpeg_s_fmt_vid_cap() function during the S_FMT ioctl call. But if user space calls the QBUF of OUTPUT buffer after the S_FMT of CAPTURE buffer, these aligned values will be replaced by the values in jpeg header. If the width/height values of jpeg are not aligned, the decoder output will be corrupted. So in this patch we call jpeg_bound_align_image() to align the width/height values of Capture buffer in s5p_jpeg_buf_queue(). Signed-off-by: Tony K Nadackal Signed-off-by: Thierry Escande --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c index 52dc794..623508d 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c @@ -2523,6 +2523,25 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb) q_data = &ctx->cap_q; q_data->w = tmp.w; q_data->h = tmp.h; + + /* +* This call to jpeg_bound_align_image() takes care of width and +* height values alignment when user space calls the QBUF of +* OUTPUT buffer after the S_FMT of CAPTURE buffer. +* Please note that on Exynos4x12 SoCs, resigning from executing +* S_FMT on capture buffer for each JPEG image can result in a +* hardware hangup if subsampling is lower than the one of input +* JPEG. +*/ + jpeg_bound_align_image(ctx, + &q_data->w, + S5P_JPEG_MIN_WIDTH, S5P_JPEG_MAX_WIDTH, + q_data->fmt->h_align, + &q_data->h, + S5P_JPEG_MIN_HEIGHT, S5P_JPEG_MAX_HEIGHT, + q_data->fmt->v_align); + + q_data->size = q_data->w * q_data->h * q_data->fmt->depth >> 3; } v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf); -- 2.7.4
Re: [PATCH 1/5] [media] rockchip/rga: v4l2 m2m support
Le mardi 27 juin 2017 à 23:11 +0800, Jacob Chen a écrit : > Hi Nicolas. > > 2017-06-26 23:49 GMT+08:00 Nicolas Dufresne : > > > > Le lundi 26 juin 2017 à 22:51 +0800, Jacob Chen a écrit : > > > Rockchip RGA is a separate 2D raster graphic acceleration unit. > > > It > > > accelerates 2D graphics operations, such as point/line drawing, > > > image > > > scaling, rotation, BitBLT, alpha blending and image > > > blur/sharpness. > > > > > > The drvier is mostly based on s5p-g2d v4l2 m2m driver. > > > And supports various operations from the rendering pipeline. > > > - copy > > > - fast solid color fill > > > - rotation > > > - flip > > > - alpha blending > > > > > > The code in rga-hw.c is used to configure regs accroding to > > > operations. > > > > > > The code in rga-buf.c is used to create private mmu table for > > > RGA. > > > The tables is stored in a list, and be removed when buffer is > > > cleanup. > > > > > > Signed-off-by: Jacob Chen > > > --- > > > drivers/media/platform/Kconfig| 11 + > > > drivers/media/platform/Makefile | 2 + > > > drivers/media/platform/rockchip-rga/Makefile | 3 + > > > drivers/media/platform/rockchip-rga/rga-buf.c | 176 + > > > drivers/media/platform/rockchip-rga/rga-hw.c | 456 > > > drivers/media/platform/rockchip-rga/rga-hw.h | 434 > > > drivers/media/platform/rockchip-rga/rga.c | 979 > > > ++ > > > drivers/media/platform/rockchip-rga/rga.h | 133 > > > 8 files changed, 2194 insertions(+) > > > create mode 100644 drivers/media/platform/rockchip-rga/Makefile > > > create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c > > > create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c > > > create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h > > > create mode 100644 drivers/media/platform/rockchip-rga/rga.c > > > create mode 100644 drivers/media/platform/rockchip-rga/rga.h > > > > > > diff --git a/drivers/media/platform/Kconfig > > > b/drivers/media/platform/Kconfig > > > index c9106e1..8199bcf 100644 > > > --- a/drivers/media/platform/Kconfig > > > +++ b/drivers/media/platform/Kconfig > > > @@ -411,6 +411,17 @@ config VIDEO_RENESAS_VSP1 > > > To compile this driver as a module, choose M here: the > > > module > > > will be called vsp1. > > > > > > +config VIDEO_ROCKCHIP_RGA > > > + tristate "Rockchip Raster 2d Grapphic Acceleration Unit" > > > + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA > > > + depends on ARCH_ROCKCHIP || COMPILE_TEST > > > + select VIDEOBUF2_DMA_SG > > > + select V4L2_MEM2MEM_DEV > > > + default n > > > + ---help--- > > > + This is a v4l2 driver for Rockchip SOC RGA2 > > > + 2d graphics accelerator. > > > + > > > config VIDEO_TI_VPE > > > tristate "TI VPE (Video Processing Engine) driver" > > > depends on VIDEO_DEV && VIDEO_V4L2 > > > diff --git a/drivers/media/platform/Makefile > > > b/drivers/media/platform/Makefile > > > index 349ddf6..3bf096f 100644 > > > --- a/drivers/media/platform/Makefile > > > +++ b/drivers/media/platform/Makefile > > > @@ -54,6 +54,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)+= > > > rcar_fdp1.o > > > obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o > > > obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/ > > > > > > +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga/ > > > + > > > obj-y+= omap/ > > > > > > obj-$(CONFIG_VIDEO_AM437X_VPFE) += am437x/ > > > diff --git a/drivers/media/platform/rockchip-rga/Makefile > > > b/drivers/media/platform/rockchip-rga/Makefile > > > new file mode 100644 > > > index 000..92fe254 > > > --- /dev/null > > > +++ b/drivers/media/platform/rockchip-rga/Makefile > > > @@ -0,0 +1,3 @@ > > > +rockchip-rga-objs := rga.o rga-hw.o rga-buf.o > > > + > > > +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o > > > diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c > > > b/drivers/media/platform/rockchip-rga/rga-buf.c > > > new file mode 100644 > > > index 000..8582092 > > > --- /dev/null > > > +++ b/drivers/media/platform/rockchip-rga/rga-buf.c > > > @@ -0,0 +1,176 @@ > > > +/* > > > + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd > > > + * Author: Jacob Chen > > > + * > > > + * This software is licensed under the terms of the GNU General > > > Public > > > + * License version 2, as published by the Free Software > > > Foundation, > > > and > > > + * may be copied, distributed, and modified under those terms. > > > + * > > > + * This program is distributed in the hope that it will be > > > useful, > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty > > > of > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > + * GNU General Public License for more details. > > > + */ > > > + > > > +#include > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > >
[ragnatech:media-tree] BUILD INCOMPLETE 2748e76ddb2967c4030171342ebdd3faa6a5e8e8
git://git.ragnatech.se/linux media-tree 2748e76ddb2967c4030171342ebdd3faa6a5e8e8 media: staging: cxd2099: Activate cxd2099 buffer mode TIMEOUT after 1687m Sorry we cannot finish the testset for your branch within a reasonable time. It's our fault -- either some build server is down or some build worker is busy doing bisects for _other_ trees. The branch will get more complete coverage and possible error reports when our build infrastructure is restored or catches up. There will be no more build success notification for this branch head, but you can expect reasonably good test coverage after waiting for 1 day. configs tested: 286 x86_64 allmodconfig sh allmodconfig shtitan_defconfig sh rsk7269_defconfig sh sh7785lcr_32bit_defconfig shallnoconfig pariscc3000_defconfig parisc b180_defconfig parisc defconfig alpha defconfig pariscallnoconfig x86_64 acpi-redef x86_64 allyesdebian x86_64nfsroot m68k sun3_defconfig m68k multi_defconfig m68k m5475evb_defconfig cris etrax-100lx_v2_defconfig blackfin TCM-BF537_defconfig blackfinBF561-EZKIT-SMP_defconfig blackfinBF533-EZKIT_defconfig blackfinBF526-EZBRD_defconfig cris dev88_defconfig parisc default_defconfig sh urquell_defconfig arm pxa_defconfig ia64 alldefconfig sh se7343_defconfig i386 randconfig-c0-06271421 i386 randconfig-c0-06271823 i386 randconfig-c0-06272017 powerpc defconfig powerpc ppc64_defconfig powerpc allnoconfig tile allnoconfig um allyesconfig x86_64randconfig-in0-06271113 mips bigsur_defconfig mips xway_defconfig powerpc tqm8541_defconfig arm iop13xx_defconfig mipsbcm63xx_defconfig xtensasmp_lx200_defconfig powerpc mpc8313_rdb_defconfig powerpc pseries_defconfig sh sh2007_defconfig x86_64randconfig-it0-06271030 x86_64randconfig-it0-06271753 microblaze allyesconfig sh r7785rp_defconfig blackfin BF518F-EZBRD_defconfig blackfin CM-BF537E_defconfig um alldefconfig s390default_defconfig x86_64 randconfig-v0-06271504 x86_64 randconfig-v0-06271832 x86_64 randconfig-v0-06272127 arm at91_dt_defconfig arm allnoconfig arm efm32_defconfig arm64 defconfig armmulti_v5_defconfig arm sunxi_defconfig arm64 allnoconfig arm exynos_defconfig armshmobile_defconfig armmulti_v7_defconfig crisetrax-100lx_defconfig mipsgpr_defconfig mips markeins_defconfig blackfinBF609-EZKIT_defconfig powerpc tqm8560_defconfig sparcalldefconfig arm corgi_defconfig armraumfeld_defconfig mips rt305x_defconfig x86_64 randconfig-g0-06271423 x86_64 randconfig-g0-06271649 x86_64 randconfig-g0-06272052 i386 allmodconfig x86_64 randconfig-x010-201726 x86_64 randconfig-x019-201726 x86_64 randconfig-x015-201726 x86_64 randconfig-x012-201726 x86_64 randconfig-x014-201726 x86_64 randconfig-x016-201726 x86_64 randconfig-x018-201726 x86_64 randconfig-x017-201726 x86_64 randconfig-x013-201726 x86_64 randconfig-x011-201726 ia64 allnoconfig ia64defconfig arm allmodconfig arm arm5 arm
Re: [PATCH 1/5] [media] rockchip/rga: v4l2 m2m support
Hi Tomasz, Yeah, the comments are wrong, i will correct it >> +*/ >> + pages = (unsigned int *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 3); > > This is rather unfortunate and you should expect failures here on > actively used systems with uptime longer than few hours. Changing this > to dma_alloc_coherent() and enabling CMA _might_ give you a bit better > success rate, but... > > Normally, this kind of (scatter-gather capable) hardware would allow > some kind of linking of separate pages, e.g. last entry in the page > would point to the next page, or something like that. Doesn't this RGA > block have something similar? > Thx for pointing it out ! : ) I looked RGA drvier used in rockchip android and i find it use kmalloc, so i think it might support separate pages. I will test it. > Best regards, > Tomasz
Re: [PATCH 1/5] [media] rockchip/rga: v4l2 m2m support
Hi Nicolas.
2017-06-26 23:49 GMT+08:00 Nicolas Dufresne :
>
> Le lundi 26 juin 2017 à 22:51 +0800, Jacob Chen a écrit :
> > Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> > accelerates 2D graphics operations, such as point/line drawing, image
> > scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
> >
> > The drvier is mostly based on s5p-g2d v4l2 m2m driver.
> > And supports various operations from the rendering pipeline.
> > - copy
> > - fast solid color fill
> > - rotation
> > - flip
> > - alpha blending
> >
> > The code in rga-hw.c is used to configure regs accroding to
> > operations.
> >
> > The code in rga-buf.c is used to create private mmu table for RGA.
> > The tables is stored in a list, and be removed when buffer is
> > cleanup.
> >
> > Signed-off-by: Jacob Chen
> > ---
> > drivers/media/platform/Kconfig| 11 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/rockchip-rga/Makefile | 3 +
> > drivers/media/platform/rockchip-rga/rga-buf.c | 176 +
> > drivers/media/platform/rockchip-rga/rga-hw.c | 456
> > drivers/media/platform/rockchip-rga/rga-hw.h | 434
> > drivers/media/platform/rockchip-rga/rga.c | 979
> > ++
> > drivers/media/platform/rockchip-rga/rga.h | 133
> > 8 files changed, 2194 insertions(+)
> > create mode 100644 drivers/media/platform/rockchip-rga/Makefile
> > create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
> > create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
> > create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
> > create mode 100644 drivers/media/platform/rockchip-rga/rga.c
> > create mode 100644 drivers/media/platform/rockchip-rga/rga.h
> >
> > diff --git a/drivers/media/platform/Kconfig
> > b/drivers/media/platform/Kconfig
> > index c9106e1..8199bcf 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -411,6 +411,17 @@ config VIDEO_RENESAS_VSP1
> > To compile this driver as a module, choose M here: the
> > module
> > will be called vsp1.
> >
> > +config VIDEO_ROCKCHIP_RGA
> > + tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
> > + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> > + depends on ARCH_ROCKCHIP || COMPILE_TEST
> > + select VIDEOBUF2_DMA_SG
> > + select V4L2_MEM2MEM_DEV
> > + default n
> > + ---help---
> > + This is a v4l2 driver for Rockchip SOC RGA2
> > + 2d graphics accelerator.
> > +
> > config VIDEO_TI_VPE
> > tristate "TI VPE (Video Processing Engine) driver"
> > depends on VIDEO_DEV && VIDEO_V4L2
> > diff --git a/drivers/media/platform/Makefile
> > b/drivers/media/platform/Makefile
> > index 349ddf6..3bf096f 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -54,6 +54,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)+=
> > rcar_fdp1.o
> > obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o
> > obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
> >
> > +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga/
> > +
> > obj-y+= omap/
> >
> > obj-$(CONFIG_VIDEO_AM437X_VPFE) += am437x/
> > diff --git a/drivers/media/platform/rockchip-rga/Makefile
> > b/drivers/media/platform/rockchip-rga/Makefile
> > new file mode 100644
> > index 000..92fe254
> > --- /dev/null
> > +++ b/drivers/media/platform/rockchip-rga/Makefile
> > @@ -0,0 +1,3 @@
> > +rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
> > +
> > +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
> > diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c
> > b/drivers/media/platform/rockchip-rga/rga-buf.c
> > new file mode 100644
> > index 000..8582092
> > --- /dev/null
> > +++ b/drivers/media/platform/rockchip-rga/rga-buf.c
> > @@ -0,0 +1,176 @@
> > +/*
> > + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> > + * Author: Jacob Chen
> > + *
> > + * This software is licensed under the terms of the GNU General
> > Public
> > + * License version 2, as published by the Free Software Foundation,
> > and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "rga-hw.h"
> > +#include "rga.h"
> > +
> > +static int
> > +rga_queue_setup(struct vb2_queue *vq,
> > +unsigned int *nbuffers, unsigned int *nplanes,
> > +unsigned int sizes[], struct device *alloc_devs[])
> > +{
> > + struct rga_ctx *ctx = vb2_get_drv_priv(vq);
> > + struct rga_frame *f = rga_get_frame(ct
[PATCH 2/3] [media] venus: don't abuse dma_alloc for non-DMA allocations
In venus_boot(), we pass a pointer to a phys_addr_t
into dmam_alloc_coherent, which the compiler warns about:
platform/qcom/venus/firmware.c: In function 'venus_boot':
platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of
'dmam_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
The returned DMA address is later passed on to a function that
takes a phys_addr_t, so it's clearly wrong to use the DMA
mapping interface here: the memory may be uncached, or the
address may be completely wrong if there is an IOMMU connected
to the device.
My interpretation is that using dmam_alloc_coherent() had two
purposes:
a) get a chunk of consecutive memory that may be larger than
the limit for kmalloc()
b) use the devres infrastructure to simplify the unwinding
in the error case.
I think ideally we'd use a devres-based version of
alloc_pages_exact() here, but since that doesn't exist,
let's use devm_get_free_pages() instead. This wastes a little
memory as the size gets rounded up to a power of two, but
is otherwise harmless. If we want to save memory here, calling
devm_free_pages() to release the memory once it is no longer
needed is probably better anyway.
Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper
functions")
Signed-off-by: Arnd Bergmann
---
The same problem exists in the drm driver, as of commit 7c65817e6d38
("drm/msm: gpu: Enable zap shader for A5XX"), and I submitted the
same patch for that already.
---
drivers/media/platform/qcom/venus/firmware.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index 1b1a4f355918..76edb9f60311 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -60,11 +60,13 @@ int venus_boot(struct device *parent, struct device
*fw_dev, const char *fwname)
mem_size = VENUS_FW_MEM_SIZE;
- mem_va = dmam_alloc_coherent(fw_dev, mem_size, &mem_phys, GFP_KERNEL);
+ mem_va = (void *)devm_get_free_pages(parent, GFP_KERNEL,
+get_order(mem_size));
if (!mem_va) {
ret = -ENOMEM;
goto err_unreg_device;
}
+ mem_phys = virt_to_phys(mem_va);
ret = request_firmware(&mdt, fwname, fw_dev);
if (ret < 0)
--
2.9.0
[PATCH v6 0/3] ADV748x HDMI/Analog video receiver
From: Kieran Bingham This is a driver for the Analog Devices ADV748x device, and follows on from a previous posting by Niklas Söderlund [0] of an earlier incarnation of this driver, and earlier versions posted by myself. ADV748x === The ADV7481 and ADV7482 support two video pipelines which can run independently of each other, with each pipeline terminating in a CSI-2 output: TXA (4-Lane) and TXB (1-Lane) The ADV7480 (Not included here), ADV7481, and ADV7482 are all derivatives, with the following features Analog HDMI MHL 4-Lane 1-Lane In In CSI CSI ADV7480 XX X ADV7481 XXX X X ADV7482 XX X X Implementation == This driver creates 4 entities. AFE (CVBS/Analog In), HDMI, TXA and TXB. At probe time, the DT is parsed to identify the endpoints for each of these nodes, and those are used for async matching of the CSI2 (TXA/TXB) entities in the master driver. The HDMI and AFE entities are then registered after a successful registration of both the CSI2 entities. HDMI is statically linked to the TXA entity, while the AFE is statically linked to the TXB entity. Routing the AFE through TXA is not supported. Support for setting the EDID on HDMI is provided (Known) Future Todo's = Further potential development areas include: - ADV7480 Support (No AFE) - MHL support (Not present on ADV7482) - CEC Support - Configurable I2C addressing - Interrupt handling for format changes and hotplug detect. However, this driver is functional without the above, and these developments can be written when required. References == [0] http://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg05196.html [1] https://git.ragnatech.se/linux rcar-vin-elinux-v9 [2] https://www.mail-archive.com/linux-media@vger.kernel.org/msg111332.html v1/RFC: - Initial posting v2: - Reworked DT parsing and entities v3: - Refreshed with lots of fixups from Sakari's review comments v4: - Many changes all round, following Laurent's review and extensive development - Now uses regmap - AFE port numbering has been changed to match the entity pads v5: - DT is now based on the latest salvator-common.dtsi - Entities are linked with immutable connections v6: - EDID support added to HDMI - AFE no longer autodetects input format by default. Kieran Bingham (3): media: adv748x: Add adv7181, adv7182 bindings media: i2c: adv748x: add adv748x driver MAINTAINERS: Add ADV748x driver Documentation/devicetree/bindings/media/i2c/adv748x.txt | 95 +- MAINTAINERS | 6 +- drivers/media/i2c/Kconfig | 11 +- drivers/media/i2c/Makefile | 1 +- drivers/media/i2c/adv748x/Makefile | 7 +- drivers/media/i2c/adv748x/adv748x-afe.c | 545 ++- drivers/media/i2c/adv748x/adv748x-core.c| 831 +- drivers/media/i2c/adv748x/adv748x-csi2.c| 327 - drivers/media/i2c/adv748x/adv748x-hdmi.c| 769 - drivers/media/i2c/adv748x/adv748x.h | 425 +- 10 files changed, 3017 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt create mode 100644 drivers/media/i2c/adv748x/Makefile create mode 100644 drivers/media/i2c/adv748x/adv748x-afe.c create mode 100644 drivers/media/i2c/adv748x/adv748x-core.c create mode 100644 drivers/media/i2c/adv748x/adv748x-csi2.c create mode 100644 drivers/media/i2c/adv748x/adv748x-hdmi.c create mode 100644 drivers/media/i2c/adv748x/adv748x.h base-commit: 2748e76ddb2967c4030171342ebdd3faa6a5e8e8 -- git-series 0.9.1
[PATCH 1/3] [media] venus: mark PM functions as __maybe_unused
Without PM support, gcc warns about two unused functions:
platform/qcom/venus/core.c:146:13: error: 'venus_clks_disable' defined but not
used [-Werror=unused-function]
platform/qcom/venus/core.c:126:12: error: 'venus_clks_enable' defined but not
used [-Werror=unused-function]
The problem as usual are incorrect #ifdefs, so the easiest fix
is to do away with the #ifdef completely and mark the suspend/resume
handlers as __maybe_unused, which they are.
Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper
functions")
Signed-off-by: Arnd Bergmann
---
drivers/media/platform/qcom/venus/core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index d8cbe8549d97..47f79637938c 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -270,8 +270,7 @@ static int venus_remove(struct platform_device *pdev)
return ret;
}
-#ifdef CONFIG_PM
-static int venus_runtime_suspend(struct device *dev)
+static __maybe_unused int venus_runtime_suspend(struct device *dev)
{
struct venus_core *core = dev_get_drvdata(dev);
int ret;
@@ -283,7 +282,7 @@ static int venus_runtime_suspend(struct device *dev)
return ret;
}
-static int venus_runtime_resume(struct device *dev)
+static __maybe_unused int venus_runtime_resume(struct device *dev)
{
struct venus_core *core = dev_get_drvdata(dev);
int ret;
@@ -302,7 +301,6 @@ static int venus_runtime_resume(struct device *dev)
venus_clks_disable(core);
return ret;
}
-#endif
static const struct dev_pm_ops venus_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
--
2.9.0
[PATCH v6 1/3] media: adv748x: Add adv7181, adv7182 bindings
From: Kieran Bingham
Create device tree bindings documentation for the ADV748x.
The ADV748x supports both the ADV7481 and ADV7482 chips which
provide analogue decoding and HDMI receiving capabilities
Signed-off-by: Kieran Bingham
---
v6:
- Clean up description and remove redundant text regarding optional
nodes
Documentation/devicetree/bindings/media/i2c/adv748x.txt | 95 ++-
1 file changed, 95 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.txt
b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
new file mode 100644
index ..21ffb5ed8183
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
@@ -0,0 +1,95 @@
+* Analog Devices ADV748X video decoder with HDMI receiver
+
+The ADV7481 and ADV7482 are multi format video decoders with an integrated
+HDMI receiver. They can output CSI-2 on two independent outputs TXA and TXB
+from three input sources HDMI, analog and TTL.
+
+Required Properties:
+
+ - compatible: Must contain one of the following
+- "adi,adv7481" for the ADV7481
+- "adi,adv7482" for the ADV7482
+
+ - reg: I2C slave address
+
+Optional Properties:
+
+ - interrupt-names: Should specify the interrupts as "intrq1", "intrq2" and/or
+"intrq3". All interrupts are optional. The "intrq3"
interrupt
+is only available on the adv7481
+ - interrupts: Specify the interrupt lines for the ADV748x
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+ Name TypePort
+ ---
+ AIN0 sink0
+ AIN1 sink1
+ AIN2 sink2
+ AIN3 sink3
+ AIN4 sink4
+ AIN5 sink5
+ AIN6 sink6
+ AIN7 sink7
+ HDMI sink8
+ TTL sink9
+ TXA source 10
+ TXB source 11
+
+The digital output port nodes must contain at least one endpoint.
+
+Ports are optional if they are not connected to anything at the hardware level.
+
+Example:
+
+ video-receiver@70 {
+ compatible = "adi,adv7482";
+ reg = <0x70>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ interrupt-parent = <&gpio6>;
+ interrupt-names = "intrq1", "intrq2";
+ interrupts = <30 IRQ_TYPE_LEVEL_LOW>,
+<31 IRQ_TYPE_LEVEL_LOW>;
+
+ port@7 {
+ reg = <7>;
+
+ adv7482_ain7: endpoint {
+ remote-endpoint = <&cvbs_in>;
+ };
+ };
+
+ port@8 {
+ reg = <8>;
+
+ adv7482_hdmi: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+
+ port@10 {
+ reg = <10>;
+
+ adv7482_txa: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csi40_in>;
+ };
+ };
+
+ port@11 {
+ reg = <11>;
+
+ adv7482_txb: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1>;
+ remote-endpoint = <&csi20_in>;
+ };
+ };
+ };
--
git-series 0.9.1
[PATCH v6 2/3] media: i2c: adv748x: add adv748x driver
From: Kieran Bingham
Provide support for the ADV7481 and ADV7482.
The driver is modelled with 4 subdevices to allow simultaneous streaming
from the AFE (Analog front end) and HDMI inputs though two CSI TX
entities.
The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
to the TXB CSI bus.
The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
and an earlier rework by Niklas Söderlund.
Signed-off-by: Kieran Bingham
---
v2:
- Implement DT parsing
- adv748x: Add CSI2 entity
- adv748x: Rework pad allocations and fmts
- Give AFE 8 input pads and move pad defines
- Use the enums to ensure pads are referenced correctly.
- adv748x: Rename AFE/HDMI entities
Now they are 'just afe' and 'just hdmi'
- Reorder the entity enum and structures
- Added pad-format for the CSI2 entities
- CSI2 s_stream pass through
- CSI2 control pass through (with link following)
v3:
- dt: Extend DT documentation to specify interrupt mappings
- simplify adv748x_parse_dt
- core: Add banner to header file describing ADV748x variants
- Use entity structure pointers rather than global state pointers where
possible
- afe: Reduce indent on afe_status
- hdmi: Add error checking to the bt->pixelclock values.
- Remove all unnecessary pad checks: handled by core
- Fix all probe cleanup paths
- adv748x_csi2_probe() now fails if it has no endpoint
- csi2: Fix small oneliners for is_txa and get_remote_sd()
- csi2: Fix checkpatch warnings
- csi2: Fix up s_stream pass-through
- csi2: Fix up Pixel Rate passthrough
- csi2: simplify adv748x_csi2_get_pad_format()
- Remove 'async notifiers' from AFE/HDMI
Using async notifiers was overkill, when we have access to the
subdevices internally and can register them directly.
- Use state lock in control handlers and clean up s_ctrls
- remove _interruptible mutex locks
v4:
- all: Convert hex 0xXX to lowercase
- all: Use defines instead of hardcoded register values
- all: Use regmap
- afe, csi2, hdmi: _probe -> _init
- afe, csi2, hdmi: _remove -> _cleanup
- afe, hdmi: Convert pattern generator to a control
- afe, hdmi: get/set-fmt refactor
- afe, hdmi, csi2: Convert to internal calls for pixelrate
- afe: Allow the AFE to configure the Input Select from DT
- afe: Reduce indent on adv748x_afe_status switch
- afe: Remove ununsed macro definitions AIN0-7
- afe: Remove extraneous control checks handled by core
- afe: Comment fixups
- afe: Rename error label
- afe: Correct control names on the SDP
- afe: Use AIN0-7 rather than AIN1-8 to match ports and MC pads
- core: adv748x_parse_dt references to nodes, and catch multiple
endpoints in a port.
- core: adv748x_dt_cleanup to simplify releasing DT nodes
- core: adv748x_print_info renamed to adv748x_identify_chip
- core: reorganise ordering of probe sequence
- core: No need for of_match_ptr
- core: Fix up i2c read/writes (regmap still on todo list)
- core: Set specific functions from the entities on subdev-init
- core: Use kzalloc for state instead of devm
- core: Improve probe error reporting
- core: Track unknown BIT(6) in tx{a,b}_power
- csi2: Improve adv748x_csi2_get_remote_sd as adv748x_csi2_get_source_sd
- csi2: -EPIPE instead of -ENODEV
- csi2: adv_dbg, instead of adv_info
- csi2: adv748x_csi2_set_format fix
- csi2: remove async notifier and sd member variables
- csi2: register links from the CSI2
- csi2: create virtual channel helper function
- dt: Remove numbering from endpoints
- dt: describe ports and interrupts as optional
- dt: Re-tab
- hdmi: adv748x_hdmi_have_signal -> adv748x_hdmi_has_signal
- hdmi: fix adv748x_hdmi_read_pixelclock return checks
- hdmi: improve adv748x_hdmi_set_video_timings
- hdmi: Fix tmp variable as polarity
- hdmi: Improve adv748x_hdmi_s_stream
- hdmi: Clean up adv748x_hdmi_s_ctrl register definitions and usage
- hdmi: Fix up adv748x_hdmi_s_dv_timings with macro names for register
- hdmi: Add locking to adv748x_hdmi_g_dv_timings
writes and locking
- hdmi: adv748x_hdmi_set_de_timings function added to clarify DE writes
- hdmi: Use CP in control register naming to match component processor
- hdmi: clean up adv748x_hdmi_query_dv_timings()
- KConfig: Fix up dependency and capitalisation
v5:
- afe,hdmi: _set_pixelrate -> _propagate_pixelrate
- hdmi: Fix arm32 compilation failure : Use DIV_ROUND_CLOSEST_ULL
- core: remove unused link functions
- csi2: Use immutable links for HDMI->TXA, AFE->TXB
v6:
- hdmi: Provide EDID support
- afe: Fix InLock inversion bug
- afe: Prevent autodetection of input format except in querystd
- afe,hdmi: Improve pattern generator control strings
- hdmi: Remove interlaced support capability (it's untested)
drivers/media/i2c/Kconfig| 11 +-
drivers/media/i2c/Makefile | 1 +-
drivers/media/i2c/adv748x/Makefile | 7 +-
drivers/media/i2c/adv748x/adv748x-afe.c | 545 -
drivers/media/i2c/adv748x/adv748x-core.c | 831 ++
[PATCH v6 3/3] MAINTAINERS: Add ADV748x driver
From: Kieran Bingham The ADV7481 is an integrated video decoder and combined HDMI/MHL receiver. Signed-off-by: Kieran Bingham --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c4be6d4af7d2..741da59b133a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -770,6 +770,12 @@ W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/media/i2c/adv7180.c +ANALOG DEVICES INC ADV748X DRIVER +M: Kieran Bingham +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/adv748x/* + ANALOG DEVICES INC ADV7511 DRIVER M: Hans Verkuil L: linux-media@vger.kernel.org -- git-series 0.9.1
[PATCH 3/3] [media] venus: fix compile-test build on non-qcom ARM platform
If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:
ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko]
undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko]
undefined!
This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built.
Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")
Signed-off-by: Arnd Bergmann
---
drivers/media/platform/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index cb2f31cd0088..635c53e61f8a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -475,8 +475,8 @@ config VIDEO_QCOM_VENUS
tristate "Qualcomm Venus V4L2 encoder/decoder driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
- select QCOM_MDT_LOADER if (ARM || ARM64)
- select QCOM_SCM if (ARM || ARM64)
+ select QCOM_MDT_LOADER if ARCH_QCOM
+ select QCOM_SCM if ARCH_QCOM
select VIDEOBUF2_DMA_SG
select V4L2_MEM2MEM_DEV
---help---
--
2.9.0
[PATCH RFC 0/2] Initial Allwinner V3s CSI Support
This patchset add initial support for Allwinner V3s CSI. Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface and CSI1 is used for parallel interface. This is not documented in datatsheet but by testing and guess. This patchset implement a v4l2 framework driver and add a binding documentation for it. Currently, the driver only support the parallel interface. And has been tested with a BT1120 signal which generating from FPGA. The following fetures are not support with this patchset: - ISP - MIPI-CSI2 - Master clock for camera sensor - Power regulator for the front end IC Yong Deng (2): media: V3s: Add support for Allwinner CSI. dt-bindings: add binding documentation for Allwinner CSI .../devicetree/bindings/media/sunxi-csi.txt| 51 ++ drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/sunxi-csi/Kconfig | 8 + drivers/media/platform/sunxi-csi/Makefile | 3 + drivers/media/platform/sunxi-csi/sunxi_csi.c | 535 + drivers/media/platform/sunxi-csi/sunxi_csi.h | 203 + drivers/media/platform/sunxi-csi/sunxi_csi_v3s.c | 827 + drivers/media/platform/sunxi-csi/sunxi_csi_v3s.h | 206 + drivers/media/platform/sunxi-csi/sunxi_video.c | 667 + drivers/media/platform/sunxi-csi/sunxi_video.h | 61 ++ 11 files changed, 2564 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/sunxi-csi.txt create mode 100644 drivers/media/platform/sunxi-csi/Kconfig create mode 100644 drivers/media/platform/sunxi-csi/Makefile create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi.c create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi.h create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi_v3s.c create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi_v3s.h create mode 100644 drivers/media/platform/sunxi-csi/sunxi_video.c create mode 100644 drivers/media/platform/sunxi-csi/sunxi_video.h -- 1.8.3.1
[PATCH RFC 1/2] media: V3s: Add support for Allwinner CSI.
Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datatsheet but by testing and guess.
This patch implement a v4l2 framework driver for it.
Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.
Signed-off-by: Yong Deng
---
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/sunxi-csi/Kconfig | 8 +
drivers/media/platform/sunxi-csi/Makefile| 3 +
drivers/media/platform/sunxi-csi/sunxi_csi.c | 535 +++
drivers/media/platform/sunxi-csi/sunxi_csi.h | 203 ++
drivers/media/platform/sunxi-csi/sunxi_csi_v3s.c | 827 +++
drivers/media/platform/sunxi-csi/sunxi_csi_v3s.h | 206 ++
drivers/media/platform/sunxi-csi/sunxi_video.c | 667 ++
drivers/media/platform/sunxi-csi/sunxi_video.h | 61 ++
10 files changed, 2513 insertions(+)
create mode 100644 drivers/media/platform/sunxi-csi/Kconfig
create mode 100644 drivers/media/platform/sunxi-csi/Makefile
create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi.c
create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi.h
create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi_v3s.c
create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi_v3s.h
create mode 100644 drivers/media/platform/sunxi-csi/sunxi_video.c
create mode 100644 drivers/media/platform/sunxi-csi/sunxi_video.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee..11c6c563 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,7 @@ source "drivers/media/platform/am437x/Kconfig"
source "drivers/media/platform/xilinx/Kconfig"
source "drivers/media/platform/rcar-vin/Kconfig"
source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sunxi-csi/Kconfig"
config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d6..3e6c20a 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-$(CONFIG_VIDEO_SUNXI_CSI) += sunxi-csi/
diff --git a/drivers/media/platform/sunxi-csi/Kconfig
b/drivers/media/platform/sunxi-csi/Kconfig
new file mode 100644
index 000..f26592a
--- /dev/null
+++ b/drivers/media/platform/sunxi-csi/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_SUNXI_CSI
+ tristate "Allwinner Camera Sensor Interface driver"
+ depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on ARCH_SUNXI
+ select VIDEOBUF2_DMA_CONTIG
+ select REGMAP_MMIO
+ ---help---
+ Support for the Allwinner Camera Sensor Interface Controller.
diff --git a/drivers/media/platform/sunxi-csi/Makefile
b/drivers/media/platform/sunxi-csi/Makefile
new file mode 100644
index 000..f27c1c5
--- /dev/null
+++ b/drivers/media/platform/sunxi-csi/Makefile
@@ -0,0 +1,3 @@
+
+sunxi-csi-objs = sunxi_csi.o sunxi_video.o sunxi_csi_v3s.o
+obj-$(CONFIG_VIDEO_SUNXI_CSI) += sunxi-csi.o
diff --git a/drivers/media/platform/sunxi-csi/sunxi_csi.c
b/drivers/media/platform/sunxi-csi/sunxi_csi.c
new file mode 100644
index 000..87277ca
--- /dev/null
+++ b/drivers/media/platform/sunxi-csi/sunxi_csi.c
@@ -0,0 +1,535 @@
+/*
+ * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing),
+ * All rights reserved.
+ * Author: Yong Deng
+ *
+ * Based on drivers/media/platform/xilinx/xilinx-vipp.c
+ * Copyright (C) 2013-2015 Ideas on Board
+ * Copyright (C) 2013-2015 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "sunxi_csi.h"
+
+/*
+ * struct sunxi_graph_entity - Entity in the video graph
+ * @list: list entry in a graph entities list
+ * @node: the entity's DT node
+ * @entity: media entity, from the corresponding V4L2 subdev
+ * @asd: subdev asynchronous registration information
+ * @subdev: V4L2 subdev
+ */
+struct sunxi_graph_entity {
+ struct list_headlist;
+ struct device_node *node;
+ struct media_entity *entity;
+
+ struct v4l2_async_subdevasd;
+ struct v4l2_subdev *s
Re: [PATCH] [media] davinci/dm644x: work around ccdc_update_raw_params trainwreck
On Tue, Jun 27, 2017 at 12:13 PM, Sekhar Nori wrote: > On Tuesday 20 June 2017 06:36 PM, Lad, Prabhakar wrote: >> Hi Arnd, >> >> Thanks for the patch. >> >> On Fri, Jun 9, 2017 at 10:36 PM, Arnd Bergmann wrote: >>> Now that the davinci drivers can be enabled in compile tests on other >>> architectures, I ran into this warning on a 64-bit build: >>> >>> drivers/media/platform/davinci/dm644x_ccdc.c: In function >>> 'ccdc_update_raw_params': >>> drivers/media/platform/davinci/dm644x_ccdc.c:279:7: error: cast to pointer >>> from integer of different size [-Werror=int-to-pointer-cast] >>> >>> While that looks fairly harmless (it would be fine on 32-bit), it was >>> just the tip of the iceberg: >>> >>> - The function constantly mixes up pointers and phys_addr_t numbers >>> - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is >>> described as an 'experimental ioctl that will change in future kernels', >>> but if we have users that probably won't happen. >>> - The code to allocate the table never gets called after we copy_from_user >>> the user input over the kernel settings, and then compare them >>> for inequality. >>> - We then go on to use an address provided by user space as both the >>> __user pointer for input and pass it through phys_to_virt to come up >>> with a kernel pointer to copy the data to. This looks like a trivially >>> exploitable root hole. >>> >>> This patch disables all the obviously broken code, by zeroing out the >>> sensitive data provided by user space. I also fix the type confusion >>> here. If we think the ioctl has no stable users, we could consider >>> just removing it instead. >>> >> I suspect there shouldn’t be possible users of this IOCTL, better of >> removing >> the IOCTL itself. >> >> Sekhar your call, as the latest PSP releases for 644x use the media >> controller framework. > > I do not have any personal experience with anyone using this support > with latest kernels. I too am okay with removing the broken support. Ok, I think that would be good. Can one of you create that patch? Note that we have two implementations of the ioctl, with different data structures, depending on the specific hardware. > Since the header file that defines the ioctl is not in include/uapi/*, I > guess it cannot be considered stable userspace ABI? Also, there are > enough warnings about instability thrown in the comments surrounding the > ioctl in include/media/davinci/vpfe_capture.h. This is not relevant really. The only thing that counts is whether there is existing user space that has active users who complain if it breaks. If you think nobody is using it, that is more important than code comments or the location of the header file, but if someone complains later anyway, we may end up reverting the removal and fix it differently. Arnd
[PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI
Add binding documentation for Allwinner CSI.
Signed-off-by: Yong Deng
---
.../devicetree/bindings/media/sunxi-csi.txt| 51 ++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sunxi-csi.txt
diff --git a/Documentation/devicetree/bindings/media/sunxi-csi.txt
b/Documentation/devicetree/bindings/media/sunxi-csi.txt
new file mode 100644
index 000..770be0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sunxi-csi.txt
@@ -0,0 +1,51 @@
+Allwinner V3s Camera Sensor Interface
+--
+
+Required properties:
+ - compatible: value must be "allwinner,sun8i-v3s-csi"
+ - reg: base address and size of the memory-mapped region.
+ - interrupts: interrupt associated to this IP
+ - clocks: phandles to the clocks feeding the CSI
+* ahb: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+ - clock-names: the clock names mentioned above
+ - resets: phandles to the reset line driving the CSI
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The
+ first port should be the input endpoints, the second one the outputs
+
+Example:
+
+ csi1: csi@01cb4000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb4000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+ clock-names = "ahb", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Parallel bus endpoint */
+ csi1_0: endpoint@0 {
+ reg = <0>;
+ remote = <&adv7611_1>;
+ bus-width = <16>;
+ data-shift = <0>;
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+ };
+
--
1.8.3.1
Re: [PATCH] [media] davinci/dm644x: work around ccdc_update_raw_params trainwreck
On Tuesday 20 June 2017 06:36 PM, Lad, Prabhakar wrote: > Hi Arnd, > > Thanks for the patch. > > On Fri, Jun 9, 2017 at 10:36 PM, Arnd Bergmann wrote: >> Now that the davinci drivers can be enabled in compile tests on other >> architectures, I ran into this warning on a 64-bit build: >> >> drivers/media/platform/davinci/dm644x_ccdc.c: In function >> 'ccdc_update_raw_params': >> drivers/media/platform/davinci/dm644x_ccdc.c:279:7: error: cast to pointer >> from integer of different size [-Werror=int-to-pointer-cast] >> >> While that looks fairly harmless (it would be fine on 32-bit), it was >> just the tip of the iceberg: >> >> - The function constantly mixes up pointers and phys_addr_t numbers >> - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is >> described as an 'experimental ioctl that will change in future kernels', >> but if we have users that probably won't happen. >> - The code to allocate the table never gets called after we copy_from_user >> the user input over the kernel settings, and then compare them >> for inequality. >> - We then go on to use an address provided by user space as both the >> __user pointer for input and pass it through phys_to_virt to come up >> with a kernel pointer to copy the data to. This looks like a trivially >> exploitable root hole. >> >> This patch disables all the obviously broken code, by zeroing out the >> sensitive data provided by user space. I also fix the type confusion >> here. If we think the ioctl has no stable users, we could consider >> just removing it instead. >> > I suspect there shouldn’t be possible users of this IOCTL, better of > removing > the IOCTL itself. > > Sekhar your call, as the latest PSP releases for 644x use the media > controller framework. I do not have any personal experience with anyone using this support with latest kernels. I too am okay with removing the broken support. Since the header file that defines the ioctl is not in include/uapi/*, I guess it cannot be considered stable userspace ABI? Also, there are enough warnings about instability thrown in the comments surrounding the ioctl in include/media/davinci/vpfe_capture.h. Thanks, Sekhar
Re: [PATCH v1 2/6] [media] ov9650: add device tree support
On 06/27/2017 07:36 AM, Sakari Ailus wrote:
> On Mon, Jun 26, 2017 at 07:46:34PM +0200, H. Nikolaus Schaller wrote:
>> Hi,
>>
>>> Am 26.06.2017 um 18:31 schrieb Sakari Ailus :
>>>
>>> Hi Hugues,
>>>
>>> On Thu, Jun 22, 2017 at 05:05:38PM +0200, Hugues Fruchet wrote:
@@ -1545,15 +1577,22 @@ static int ov965x_remove(struct i2c_client *client)
}
static const struct i2c_device_id ov965x_id[] = {
- { "OV9650", 0 },
- { "OV9652", 0 },
+ { "OV9650", 0x9650 },
+ { "OV9652", 0x9652 },
>>>
>>> This change does not appear to match with the patch description nor it the
>>> information is used. How about not changing it, unless there's a reason to?
>>> The same for the data field of the of_device_id array below.
>>
>> I think it could/should be used to check if the camera chip that is found
>> by reading the product-id and version registers does match what the device
>> tree expects and abort probing on a mismatch.
>
> Makes sense. But it should be a separate patch, shouldn't it?
>
> You could also put the id to the ops struct, and choose the ops struct that
> way. Entirely up to you.
>
I'll suggest to skip the id check between DT compatible string and real
device id read from sensor, this is not something I see in other drivers
currently.
But I would suggest to keep in a separate patch the switch of device id
names to lower case in order to align with other omnivision cameras and
not introduce upper/lower case potential bugs in DT later on (as the one
encountered by Nikolaus):
[media] ov9650: switch i2c device id to lower case
static const struct i2c_device_id ov965x_id[] = {
- { "OV9650", 0 },
- { "OV9652", 0 },
+ { "ov9650", 0 },
+ { "ov9652", 0 },
[media] ov9650: add device tree support
+static const struct of_device_id ov965x_of_match[] = {
+ { .compatible = "ovti,ov9650", },
+ { .compatible = "ovti,ov9652", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ov965x_of_match);
+
static struct i2c_driver ov965x_i2c_driver = {
.driver = {
.name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(ov965x_of_match),
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Jyri Sarha [170627 02:47]: > There is no real volume on HDMI audio output as it is a digital > interface, but it should be possible to provide some volume control > using TV's volume trough CEC. OK great! Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Hans Verkuil [170627 02:27]: > On 27/06/17 11:14, Tony Lindgren wrote: > > Adding Jyri to Cc, hopefully the CEC support allows also setting the > > HDMI audio volume level on devices implementing it? Or am I too > > optimistic? :) > > I'm not quite sure what you mean. Do you want CEC to change the volume on the > TV, or use the TV's remote to change the volume of the HDMI audio output of > the > omap4? I'm hoping to change audio volume on a USB+HDMI lapdock from omap4. > Anyway, either is supported, but it requires a userspace implementation. > > Although TV remote control messages will be mapped to an input device, and if > those are hooked up to the alsa audio volume, then this already works. OK great thanks, Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
On 06/27/17 12:27, Hans Verkuil wrote: > On 27/06/17 11:14, Tony Lindgren wrote: >> * Hans Verkuil [170627 01:39]: >>> On 26/06/17 13:07, Tony Lindgren wrote: Tomi, * Tomi Valkeinen [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil wrote: >> From: Hans Verkuil >> >> The CEC pin was always pulled up, making it impossible to use it. ... > Tony, can you queue this? It's safe to apply separately from the rest of > the HDMI CEC work. So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next? >>> >>> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the >>> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) >>> this was still pending review. >> >> OK thanks for the update. >> >> Adding Jyri to Cc, hopefully the CEC support allows also setting the >> HDMI audio volume level on devices implementing it? Or am I too >> optimistic? :) > > I'm not quite sure what you mean. Do you want CEC to change the volume on the > TV, or use the TV's remote to change the volume of the HDMI audio output of > the > omap4? > There is no real volume on HDMI audio output as it is a digital interface, but it should be possible to provide some volume control using TV's volume trough CEC. > Anyway, either is supported, but it requires a userspace implementation. > A module to pulseaudio or some extra features to alsa-lib should be generic enough (who knows, maybe there is already something). Just an idea. If someone really needs this, the pieces to put it together should be there. Best regards, Jyri > Although TV remote control messages will be mapped to an input device, and if > those are hooked up to the alsa audio volume, then this already works. >> Regards, > > Hans > >> >>> Tomi, any updates on this? It would be nice to get this in for 4.14. >> >> Yeah seems like we have real mainline kernel user needs for this one. >> >> Regards, >> >> Tony >> >
Re: [PATCH v2 3/3] [media] intel-ipu3: cio2: Add new MIPI-CSI2 driver
On Mon, Jun 26, 2017 at 11:51 PM, Sakari Ailus wrote:
> On Mon, Jun 12, 2017 at 06:59:18PM +0900, Tomasz Figa wrote:
>
>>
>> > + if (WARN_ON(freq <= 0))
>> > + return -EINVAL;
>>
>> It generally doesn't make sense for the frequency to be negative, so
>> maybe the argument should have been unsigned to start with? (And
>> 32-bit if we don't expect frequencies higher than 4 GHz anyway.)
>
> The value comes from a 64-bit integer V4L2 control so that implies the value
> range of s64 as well.
Okay, if there is no way to enforce this at control level, then I
guess we have to keep this here.
>
>>
>> > +
>> > + /* b could be 0, -2 or -8, so r < 5 */
>>
>> Definitely. Anything <= 0 is also less than 5. Let's take a
>> look at the computation below again:
>>
>> 1) accinv is multiplied by b,
>> 2) 5 is divided by 256 (=== shift right by 8 bits) = 1953125,
>> 3) accinv*b is multiplied by 1953125 to form the value of r.
>>
>> Now let's see at possible maximum absolute values for particular steps:
>> 1) 16 * -8 = -128 (signed 8 bits),
>> 2) 1953125 (unsigned 21 bits),
>> 3) -128 * 1953125 = -24872 (signed 29 bits).
>>
>> So I think the important thing to note in the comment is:
>>
>> /* b could be 0, -2 or -8, so |accinv * b| is always less than (1 <<
>> ds) and thus |r| < 5. */
>>
>> > + r = accinv * b * (5 >> ds);
>>
>> On the other hand, you lose some precision here. If you used s64
>> instead and did the divide shift at the end ((accinv * b * 5)
>> >> ds), for the example above you would get -250007629. (Depending on
>> how big freq is, it might not matter, though.)
>>
>
> The frequency is typically hundreds of mega-Hertz.
I think it still would make sense to have the calculation a bit more precise.
>
>> Also nit: What is 5? We have local constants defined above, I
>> think it could also make sense to do the same for this one. The
>> compiler should do constant propagation and simplify respective
>> calculations anyway.
>
> COUNT_ACC in the formula in the comment a few decalines above is in
> nanoseconds. Performing the calculations in integer arithmetics results in
> having 5 in the resulting formula.
>
> So this is actually a constant related to the hardware but it does not have
> a pre-determined name because it is derived from COUNT_ACC.
Which, I believe, doesn't stop us from naming it.
>> > +static int cio2_v4l2_querycap(struct file *file, void *fh,
>> > + struct v4l2_capability *cap)
>> > +{
>> > + struct cio2_device *cio2 = video_drvdata(file);
>> > +
>> > + strlcpy(cap->driver, CIO2_NAME, sizeof(cap->driver));
>> > + strlcpy(cap->card, CIO2_DEVICE_NAME, sizeof(cap->card));
>> > + snprintf(cap->bus_info, sizeof(cap->bus_info),
>> > +"PCI:%s", pci_name(cio2->pci_dev));
>> > + cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
>>
>> Hmm, I thought single plane queue type was deprecated these days and
>> _MPLANE recommended for all new drivers. I'll defer this to other
>> reviewers, though.
>
> If the device supports single plane formats only, I don't see a reason to
> use MPLANE buffer types.
On the other hand, if a further new revision of the hardware (or
amendment of supported feature set of current hardware) actually adds
support for multiple planes, changing it to MPLANE will require
keeping a non-MPLANE variant of the code, due to userspace
compatibility concerns...
Best regards,
Tomasz
Logitech B990 (UVC) slow initialization, WebRTC problems
(re-posted here because linux-uvc[10]'s list is a sourceforge list,
sourceforge recently bumped a lot of users off their lists by trying to
coerce them to agree to a "privacy" policy and the list archives appear
inactive[11])
Hi,
I have a Logitech B990 webcam, it is a UVC webcam:
ID 046d:0828 Logitech, Inc. HD Webcam B990
When I start guvcview, the webcam's blue lights flash for 5 - 7 seconds
and then a greenish picture appears.
If I go to the video tab in guvcview and change it from MJPG to YUYV or
H264 then the picture looks normal.
My WebRTC browser often tries to initialize the webcam but gives a
JavaScript error before it becomes ready. It doesn't appear to work
with cheese either.
I've attached the following details:
lsusb.log (from lsusb -v -d 046d:0828)
dmesg.out (uvcvideo traces)
guvcview.out (stdout/stderr from guvcview)
Is this a defect with the webcam or is it simply not supported? I
notice it is not in the list[1]. This was originally discussed on the
Jitsi Users list[2]
Regards,
Daniel
1. http://www.ideasonboard.org/uvc/#devices
2. http://lists.jitsi.org/pipermail/users/2017-June/013268.html
10. http://www.ideasonboard.org/uvc/
11.
https://sourceforge.net/p/linux-uvc/mailman/linux-uvc-devel/?viewmonth=201705
Bus 001 Device 010: ID 046d:0828 Logitech, Inc. HD Webcam B990
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x046d Logitech, Inc.
idProduct 0x0828 HD Webcam B990
bcdDevice0.11
iManufacturer 0
iProduct0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 2334
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 0
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 240
dwClockFrequency 48.00MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x00020a2e
Auto-Exposure Mode
Auto-Exposure Priority
Exposure Time (Absolute)
Focus (Absolute)
Zoom (Absolute)
PanTilt (Absolute)
Focus, Auto
VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 2
bSourceID 1
wMaxMultiplier 16384
bControlSize2
bmControls 0x175b
Brightness
Contrast
Saturation
Sharpness
White Balance Temperature
Backlight Compensation
Gain
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x1b
None
NTSC - 525/60
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 3
guidExtensionCode {e48e6769-0f41-db40-a850-7420d7d8240e}
bNumControl 9
bNrPins 1
baSourceID( 0) 2
bControlSize2
bmControls( 0)
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
On 27/06/17 11:14, Tony Lindgren wrote: > * Hans Verkuil [170627 01:39]: >> On 26/06/17 13:07, Tony Lindgren wrote: >>> Tomi, >>> >>> * Tomi Valkeinen [170428 04:15]: On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil > > The CEC pin was always pulled up, making it impossible to use it. >>> ... >>> Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work. >>> >>> So the dts changes are merged now but what's the status of the CEC driver >>> changes? Were there some issues as I don't see them in next? >> >> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the >> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) >> this was still pending review. > > OK thanks for the update. > > Adding Jyri to Cc, hopefully the CEC support allows also setting the > HDMI audio volume level on devices implementing it? Or am I too > optimistic? :) I'm not quite sure what you mean. Do you want CEC to change the volume on the TV, or use the TV's remote to change the volume of the HDMI audio output of the omap4? Anyway, either is supported, but it requires a userspace implementation. Although TV remote control messages will be mapped to an input device, and if those are hooked up to the alsa audio volume, then this already works. Regards, Hans > >> Tomi, any updates on this? It would be nice to get this in for 4.14. > > Yeah seems like we have real mainline kernel user needs for this one. > > Regards, > > Tony >
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
On 06/27/17 12:14, Tony Lindgren wrote: > * Hans Verkuil [170627 01:39]: >> On 26/06/17 13:07, Tony Lindgren wrote: >>> Tomi, >>> >>> * Tomi Valkeinen [170428 04:15]: On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil > > The CEC pin was always pulled up, making it impossible to use it. >>> ... >>> Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work. >>> >>> So the dts changes are merged now but what's the status of the CEC driver >>> changes? Were there some issues as I don't see them in next? >> >> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the >> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) >> this was still pending review. > > OK thanks for the update. > > Adding Jyri to Cc, hopefully the CEC support allows also setting the > HDMI audio volume level on devices implementing it? Or am I too > optimistic? :) > As long as you do not expect a regular ALSA-volume to work.. But I don't see why some CEC application would not work. However, I guess one could implement this as feature to ALSA too but AFAIK no such thing exists at the moment. Best regards, Jyri >> Tomi, any updates on this? It would be nice to get this in for 4.14. > > Yeah seems like we have real mainline kernel user needs for this one. > > Regards, > > Tony >
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Hans Verkuil [170627 01:39]: > On 26/06/17 13:07, Tony Lindgren wrote: > > Tomi, > > > > * Tomi Valkeinen [170428 04:15]: > >> On 14/04/17 13:25, Hans Verkuil wrote: > >>> From: Hans Verkuil > >>> > >>> The CEC pin was always pulled up, making it impossible to use it. > > ... > > > >> Tony, can you queue this? It's safe to apply separately from the rest of > >> the HDMI CEC work. > > > > So the dts changes are merged now but what's the status of the CEC driver > > changes? Were there some issues as I don't see them in next? > > Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the > omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) > this was still pending review. OK thanks for the update. Adding Jyri to Cc, hopefully the CEC support allows also setting the HDMI audio volume level on devices implementing it? Or am I too optimistic? :) > Tomi, any updates on this? It would be nice to get this in for 4.14. Yeah seems like we have real mainline kernel user needs for this one. Regards, Tony
Re: [PATCH v4 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver
Hi Sylwester,
On 25-06-2017 22:13, Sylwester Nawrocki wrote:
> On 06/20/2017 07:26 PM, 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.
>> Signed-off-by: Jose Abreu
>> Cc: Carlos Palminha
>> Cc: Mauro Carvalho Chehab
>> Cc: Hans Verkuil
>> Cc: Sylwester Nawrocki
>>
>> Changes from v3:
>> - Use v4l2 async API (Sylwester)
>> - Do not block waiting for phy
>> - Do not use busy waiting delays (Sylwester)
>> - Simplify dw_hdmi_power_on (Sylwester)
>> - Use clock API (Sylwester)
>> - Use compatible string (Sylwester)
>> - Minor fixes (Sylwester)
>> Changes from v2:
>> - Address review comments from Hans regarding CEC
>> - Use CEC notifier
>> - Enable SCDC
>> Changes from v1:
>> - Add support for CEC
>> - Correct typo errors
>> - Correctly detect interlaced video modes
>> - Correct VIC parsing
>> Changes from RFC:
>> - Add support for HDCP 1.4
>> - Fixup HDMI_VIC not being parsed (Hans)
>> - Send source change signal when powering off (Hans)
>> - Add a "wait stable delay"
>> - Detect interlaced video modes (Hans)
>> - Restrain g/s_register from reading/writing to HDCP regs (Hans)
>> ---
>> drivers/media/platform/dwc/Kconfig | 15 +
>> drivers/media/platform/dwc/Makefile |1 +
>> drivers/media/platform/dwc/dw-hdmi-rx.c | 1862
>> +++
>> drivers/media/platform/dwc/dw-hdmi-rx.h | 441
>> include/media/dwc/dw-hdmi-rx-pdata.h| 97 ++
>> 5 files changed, 2416 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/dw-hdmi-rx.c
>> b/drivers/media/platform/dwc/dw-hdmi-rx.c
>> new file mode 100644
>> index 000..22ee51d
>> --- /dev/null
>> +++ b/drivers/media/platform/dwc/dw-hdmi-rx.c
>> +static const struct of_device_id dw_hdmi_supported_phys[] = {
>> +{ .compatible = "snps,dw-hdmi-phy-e405", .data = DW_PHY_E405_DRVNAME, },
>> +{ },
>> +};
>> +
>> +static struct device_node *dw_hdmi_get_phy_of_node(struct dw_hdmi_dev
>> *dw_dev,
>> +const struct of_device_id **found_id)
>> +{
>> +struct device_node *child = NULL;
>> +const struct of_device_id *id;
>> +
>> +for_each_child_of_node(dw_dev->of_node, child) {
>> +id = of_match_node(dw_hdmi_supported_phys, child);
>> +if (id)
>> +break;
>> +}
>> +
>> +if (found_id)
>> +*found_id = id;
>> +
>> +return child;
>> +}
>> +
>> +static int dw_hdmi_phy_init(struct dw_hdmi_dev *dw_dev)
>> +{
>> +struct dw_phy_pdata *phy = &dw_dev->phy_config;
>> +const struct of_device_id *of_id;
>> +struct of_dev_auxdata lookup;
> struct of_dev_auxdata lookup = { };
>
> You could initialize to 0 here and...
>
>> +struct device_node *child;
>> +const char *drvname;
>> +int ret;
>> +
>> +child = dw_hdmi_get_phy_of_node(dw_dev, &of_id);
>> +if (!child || !of_id || !of_id->data) {
>> +dev_err(dw_dev->dev, "no supported phy found in DT\n");
>> +return -EINVAL;
>> +}
>> +
>> +drvname = of_id->data;
>> +phy->funcs = &dw_hdmi_phy_funcs;
>> +phy->funcs_arg = dw_dev;
>> +
>> +lookup.compatible = (char *)of_id->compatible;
>> +lookup.phys_addr = 0x0;
>> +lookup.name = NULL;
> ...drop these two assignments.
Ok.
>
>> +lookup.platform_data = phy;
>> +
>> +request_module(drvname);
> I'd say this request_module() is not needed when you use the v4l2-async
> subnotifiers and the modules are properly installed in the file system.
> I might be missing something though.
Hmm, well I didn't actually test without request_module but I
think its needed, otherwise I would have to do:
modprobe phy_module
modprobe controller_module
With request_module I just have to do:
modprobe controller_module
>
>> +ret = of_platform_populate(dw_dev->of_node, NULL, &lookup, dw_dev->dev);
>> +if (ret) {
>> +dev_err(dw_dev->dev, "failed to populate phy driver\n");
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void dw_hdmi_phy_exit(struct dw_hdmi_dev *dw_dev)
>> +{
>> +of_platform_depopulate(dw_dev->dev);
>> +}
>> +static int dw_hdmi_registered(struct v4l2_subdev *sd)
>> +{
>> +struct dw_hdmi_dev *dw_dev = to_dw_dev(sd);
>> +int ret;
>> +
>> +ret = cec_register_adapter(dw_dev->cec_adap, dw_dev->dev);
>> +if (ret) {
>> +dev_err(dw_dev->dev, "failed to register CEC adapter\n");
>> +cec_delete_adapter(dw_dev->cec_adap);
>> +return ret;
>> +}
>> +
>> +cec_register_cec_notifier(d
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
On 26/06/17 13:07, Tony Lindgren wrote: > Tomi, > > * Tomi Valkeinen [170428 04:15]: >> On 14/04/17 13:25, Hans Verkuil wrote: >>> From: Hans Verkuil >>> >>> The CEC pin was always pulled up, making it impossible to use it. > ... > >> Tony, can you queue this? It's safe to apply separately from the rest of >> the HDMI CEC work. > > So the dts changes are merged now but what's the status of the CEC driver > changes? Were there some issues as I don't see them in next? Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) this was still pending review. Tomi, any updates on this? It would be nice to get this in for 4.14. Regards, Hans
Re: [PATCH 1/5] [media] rockchip/rga: v4l2 m2m support
Hi Jacob,
Please see my comments inline.
On Mon, Jun 26, 2017 at 11:51 PM, Jacob Chen wrote:
> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> accelerates 2D graphics operations, such as point/line drawing, image
> scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
[snip]
> +static int rga_buf_init(struct vb2_buffer *vb)
> +{
> + struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> + struct rockchip_rga *rga = ctx->rga;
> + struct sg_table *sgt;
> + struct scatterlist *sgl;
> + unsigned int *pages;
> + struct rga_buf *buf;
> + unsigned int address, len, i, p;
> + unsigned int mapped_size = 0;
> +
> + /* Create local MMU table for RGA */
> + sgt = vb2_plane_cookie(vb, 0);
> +
> + /*
> +* Alloc (2^3 * 4K) = 32K byte for storing pages, those space could
> +* cover 32K * 4K = 128M ram address.
Unless I'm missing something, there is 1024 32-bit values in one 4K
page, which can point to 4 MB of memory. The code allocates 8 of them,
which in total allows at most 32 MB per buffer.
> +*/
> + pages = (unsigned int *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 3);
This is rather unfortunate and you should expect failures here on
actively used systems with uptime longer than few hours. Changing this
to dma_alloc_coherent() and enabling CMA _might_ give you a bit better
success rate, but...
Normally, this kind of (scatter-gather capable) hardware would allow
some kind of linking of separate pages, e.g. last entry in the page
would point to the next page, or something like that. Doesn't this RGA
block have something similar?
Best regards,
Tomasz
Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera
Hi Nikolaus, I would propose to work first on YUV support, so you can test a YUV VGA grabbing using your OMPA3 setup, I will add this support then in patch serie. For the co-work, let's continue on IRC (irc.freenode.net), chat #v4l, my pseudo is "hfr". BR, Hugues. On 06/26/2017 06:28 PM, H. Nikolaus Schaller wrote: > Hi Hugues, > >> Am 26.06.2017 um 15:19 schrieb Hugues FRUCHET : >> >> Nikolaus, >> some comments about pixel format/resolution below: >> >> On 06/26/2017 10:39 AM, Pavel Machek wrote: >>> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote: Hi Pavel, > Am 25.06.2017 um 11:18 schrieb Pavel Machek : > > Hi! > >> * unfortunately we still get no image :( >> >> The latter is likely a setup issue of our camera interface (OMAP3 ISP = >> Image Signal Processor) which >> we were not yet able to solve. Oscilloscoping signals on the interface >> indicated that signals and >> sync are correct. But we do not know since mplayer only shows a green >> screen. > > What mplayer command line do you use? How did you set up the pipeline > with media-ctl? > > On kernel.org, I have tree called camera-fw5-6 , where camera works > for me on n900. On gitlab, there's modifed fcam-dev, which can be used > for testing. We did have yet another (non-DT) camera driver and media-ctl working in with 3.12.37, but had no success yet to update it to work with modern kernels or drivers. It is either that the (newer) drivers missing something or the media-ctl has changed. Here is the log of our scripts with Hugues' driver and our latest setup: root@letux:~# ./camera-demo sxga DISPLAY=:0 XAUTHORITY=tcp Camera: /dev/v4l-subdev8 Setting mode sxga media-ctl -r media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]' media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]' media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]' media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]' media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]' >>> >>> Ok, so you are using capture, not preview. >>> >>> You may want to try this one: >>> >>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef >>> Author: Pavel >>> Date: Mon Feb 13 21:26:51 2017 +0100 >>> >>> omap3isp: fix VP2SDR bit so capture (not preview) works >>> >>> This is neccessary for capture (not preview) to work properly on >>> N900. Why is unknown. >>> >>> Pavel >>> ### starting mplayer in sxga mode ### mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11 >> >> => "outfmt=uyvy:width=1280:height=1024" >> >> Nikolaus, >> Be careful that only VGA/RGB565 is coded in this basic version of OV9655, >> perhaps this explain partly your troubles ? > > Ah, I see. The driver should support SXGA and UYVY2X8 (because our 3.12 > compatible driver did). > > This very old (but working) non-DT driver for 3.12 kernels > was not based on the ov9650.c code but mt9p031.c: > > > http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/media/i2c/ov9655.c;hb=refs/heads/3.12.37 > > We abandoned this independent driver because we felt (like you) that > extending the existing > ov9650 driver is a better solution for mainline. > > > At least in theory. Therefore I assumed your submission supports SXGA and > UYVY as well, > since your work is based on ours. > > Nevertheless, VGA resolution doesn't work either. > > root@letux:~# ./camera-demo vga > DISPLAY=:0 > XAUTHORITY=tcp > Camera: /dev/v4l-subdev8 > Setting mode vga > media-ctl -r > media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]' > media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]' > media-ctl -V '"ov965x":0 [UYVY2X8 640x480]' > media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 640x480]' > media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 640x480]' > ### starting mplayer in vga mode ### > mplayer tv:// -vf rotate=2 -tv > driver=v4l2:device=/dev/video2:outfmt=uyvy:width=640:height=480:fps=30 -vo x11 > > > A little later it reports a NULL pointer dereference in ccdc_link_validate() > / ccdc_is_shiftable(). > > It appears as if the input format translates into a NULL pointer by > omap3isp_video_format_info(0x1008). > > This NULL pointer is not catched by ccdc_is_shiftable(). > > And it indicates that the camera driver is doing a format that is not > supported by omap3isp... > > > So how should we proceed? > > It looks as if your driver supports your scenario (STM32F746G-DISCO) in > VGA/RGB565 > and our drivers (basically) support ours (omap3isp) in VGA/SXGA but UYVY. > > We certainly need a generic driver that supports all platforms and formats. So > we somehow need to get all this stuff into a single driver. > > Working on two different patch sets doesn't make sen
Re: [PATCH] rpmsg: Solve circular dependencies involving RPMSG_VIRTIO
On Tue, Jun 27, 2017 at 8:43 AM, Bjorn Andersson wrote: > While it's very common to use RPMSG for communicating with firmware > running on these remoteprocs there is no functional dependency on RPMSG. > As such RPMSG should be selected by the system integrator and not > automatically by the remoteproc drivers. > > This does solve problems reported with circular Kconfig dependencies for > Davinci and Keystone remoteproc drivers. > > Signed-off-by: Bjorn Andersson > --- Looks good to me, Acked-by: Arnd Bergmann
