Re: [PATCH 01/25] ARM: dts: exynos4: add rotator nodes
On 10.11.2015 22:23, Marek Szyprowski wrote:
> This patch adds device node for Rotator device to Exynos 4210 and 4x12
> device tree files.
>
> Signed-off-by: Marek Szyprowski
> ---
> arch/arm/boot/dts/exynos4.dtsi| 10 +-
> arch/arm/boot/dts/exynos4210.dtsi | 8
> arch/arm/boot/dts/exynos4x12.dtsi | 4
> 3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 2f31f773b096..3fa575ad7693 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -718,6 +718,15 @@
> iommus = <&sysmmu_jpeg>;
> };
>
> + rotator: rotator@1281 {
> + compatible = "samsung,exynos4210-rotator";
> + reg = <0x1281 0x1000>;
One more question after looking at second patch. You are mapping size of
0x1000 instead of 0x64. Any particular reason? (it does not really
matter... just wondering)
Best regards,
Krzysztof
> + interrupts = <0 83 0>;
> + clocks = <&clock CLK_ROTATOR>;
> + clock-names = "rotator";
> + iommus = <&sysmmu_rotator>;
> + };
> +
> hdmi: hdmi@12D0 {
> compatible = "samsung,exynos4210-hdmi";
> reg = <0x12D0 0x7>;
> @@ -945,7 +954,6 @@
> interrupts = <5 0>;
> clock-names = "sysmmu", "master";
> clocks = <&clock CLK_SMMU_ROTATOR>, <&clock CLK_ROTATOR>;
> - power-domains = <&pd_lcd0>;
> #iommu-cells = <0>;
> };
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> b/arch/arm/boot/dts/exynos4210.dtsi
> index 3e5ba665d200..b7474cf27e82 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -279,3 +279,11 @@
> <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>, <&clock CLK_XUSBXTI>;
> #clock-cells = <1>;
> };
> +
> +&rotator {
> + power-domains = <&pd_lcd0>;
> +};
> +
> +&sysmmu_rotator {
> + power-domains = <&pd_lcd0>;
> +};
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index b77dac61ffb5..148b47ad3120 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -339,6 +339,10 @@
> compatible = "samsung,exynos4212-jpeg";
> };
>
> +&rotator {
> + compatible = "samsung,exynos4212-rotator";
> +};
> +
> &mixer {
> compatible = "samsung,exynos4212-mixer";
> clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/25] ARM: dts: exynos542x: add rotator node
On 10.11.2015 22:23, Marek Szyprowski wrote: > This patch adds device node for Rotator device to Exynos 542x device > tree file. > > Signed-off-by: Marek Szyprowski > --- > arch/arm/boot/dts/exynos5420.dtsi | 19 +++ > 1 file changed, 19 insertions(+) > Looks good, thanks! Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/25] ARM: dts: exynos4: add rotator nodes
On 10.11.2015 22:23, Marek Szyprowski wrote:
> This patch adds device node for Rotator device to Exynos 4210 and 4x12
> device tree files.
>
> Signed-off-by: Marek Szyprowski
> ---
> arch/arm/boot/dts/exynos4.dtsi| 10 +-
> arch/arm/boot/dts/exynos4210.dtsi | 8
> arch/arm/boot/dts/exynos4x12.dtsi | 4
> 3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 2f31f773b096..3fa575ad7693 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -718,6 +718,15 @@
> iommus = <&sysmmu_jpeg>;
> };
>
> + rotator: rotator@1281 {
> + compatible = "samsung,exynos4210-rotator";
> + reg = <0x1281 0x1000>;
> + interrupts = <0 83 0>;
> + clocks = <&clock CLK_ROTATOR>;
> + clock-names = "rotator";
> + iommus = <&sysmmu_rotator>;
> + };
> +
> hdmi: hdmi@12D0 {
> compatible = "samsung,exynos4210-hdmi";
> reg = <0x12D0 0x7>;
> @@ -945,7 +954,6 @@
> interrupts = <5 0>;
> clock-names = "sysmmu", "master";
> clocks = <&clock CLK_SMMU_ROTATOR>, <&clock CLK_ROTATOR>;
> - power-domains = <&pd_lcd0>;
Hmm I wonder why you changed this. Sysmmu rotator and rotator are
not a part of LCD power domain on Exynos4x12 (or they should not be?)? Why?
Best regards,
Krzysztof
> #iommu-cells = <0>;
> };
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> b/arch/arm/boot/dts/exynos4210.dtsi
> index 3e5ba665d200..b7474cf27e82 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -279,3 +279,11 @@
> <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>, <&clock CLK_XUSBXTI>;
> #clock-cells = <1>;
> };
> +
> +&rotator {
> + power-domains = <&pd_lcd0>;
> +};
> +
> +&sysmmu_rotator {
> + power-domains = <&pd_lcd0>;
> +};
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index b77dac61ffb5..148b47ad3120 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -339,6 +339,10 @@
> compatible = "samsung,exynos4212-jpeg";
> };
>
> +&rotator {
> + compatible = "samsung,exynos4212-rotator";
> +};
> +
> &mixer {
> compatible = "samsung,exynos4212-mixer";
> clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Thu, Nov 12, 2015 at 09:27:21AM +0800, Yakir Yang wrote: > Hi Rob, > > On 11/12/2015 07:10 AM, Rob Herring wrote: > >On Fri, Oct 30, 2015 at 09:09:15AM +0800, Yakir Yang wrote: > >>Some edp screen do not have hpd signal, so we can't just return > >>failed when hpd plug in detect failed. > >> > >>This is an hardware property, so we need add a devicetree property > >>"analogix,need-force-hpd" to indicate this sutiation. > >> > >>Tested-by: Heiko Stuebner > >>Tested-by: Javier Martinez Canillas > >>Signed-off-by: Yakir Yang > >>--- > >I didn't find this one in v10. Did it get dropped? > > You are in my 'to' list, but I haven't send the whole v10 out, > most of them don't need update :) Okay, it's just gmail's inability to follow threading... > This series should be: > [v8 0/17 ...] > | [v8 1/17 ...] > | [v8 2/17 ...] > | [v8 3/17 ...] > | [...] > | [v8 15/17 ...] > | [v8 16/17 ...] > | [v8 17/17 ...] > | > | [v9 10/17 ...] > | [v9 15/17 ...] > | We are here > | [v9 09/17 ...] > | [v10 09/17 ...] > | Received an acked from you > >>diff --git > >>a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt > >>b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt > >>index 7659a7a..74f0e80 100644 > >>--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt > >>+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt > >>@@ -22,6 +22,9 @@ Required properties for dp-controller: > >>from general PHY binding: Should be "dp". > >> Optional properties for dp-controller: > >>+ -analogix,need-force-hpd: > >>+ Indicate driver need force hpd when hpd detect failed, this > >>+ is used for some eDP screen which don't have hpd signal. > >This should be a generic property. > > This property would only need in some no-hpd case, it would be dropped if > panel keep the hotplug signal, that's why I thought it should be optional. I agree it is optional. I just mean drop the analogix and put in a common binding doc (i.e. create a display/bridge/common.txt). Needing to ignore HPD is probably a common problem. > I thought if we put this a property to generic property, then we must need > to define it in normal device node, not sure whether it is right :) Sorry, I don't follow. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/25] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Marek, 2015-11-10 Marek Szyprowski : > DMA address is a framebuffer attribute and the right place for it is > exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces > helper function for getting dma address of the given framebuffer. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 - > drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +--- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 --- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++-- > drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 +-- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++ > drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 -- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 5 - > drivers/gpu/drm/exynos/exynos_mixer.c | 7 --- > 9 files changed, 38 insertions(+), 53 deletions(-) Reviewed-by: Gustavo Padovan Gustavo -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/25] drm/exynos: rotator: convert to common clock framework
Hi Marek, 2015-11-10 Marek Szyprowski : > This driver was not used after introduction of common clock framework. > This patch adds missing prepare/unprepare calls and allows to use it > again with current kernel code. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Gustavo Padovan Gustavo -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/25] drm/exynos: exynos7-decon: remove excessive check
Hi Marek, 2015-11-10 Marek Szyprowski : > Display area is already checked by exynos plane core, so there is no > need for such check in driver code. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 10 -- > 1 file changed, 10 deletions(-) Reviewed-by: Gustavo Padovan Gustavo -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/25] drm/exynos: fimd: fix dma burst size setting for small plane size
Hey Tobias, On 12 November 2015 at 15:17, Tobias Jakobi wrote: > This one looks a bit strange. It only changes the argument list of > fimd_win_set_pixfmt() but the commit message that it actually fixes > something. > > The corresponding upstream commit: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66367461e573321f0fbb0be0391165b5a54d5fe4 It's subtle: >> - fimd_win_set_pixfmt(ctx, win, fb); >> + fimd_win_set_pixfmt(ctx, win, fb->pixel_format, state->src.w); i.e. rather than checking the total width of the allocated fb, we check the width we are _actually_ scanning out from the fb. So I think the patch is correct. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/25] drm/exynos: fix to calculate offset of each plane for ipp fimc
Hello,
Marek Szyprowski wrote:
> From: Seung-Woo Kim
>
> NV12 and YUV420 formats are need to calculate offset of each plane
> for ipp fimc in a gem buffer. Without proper offset, only Y plane
> can be processed, so result shows green frame.
> This patch fixes to calculate offset for cbcr planes for NV12 and
> YUV420 formats.
>
> Signed-off-by: Seung-Woo Kim
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 106
> +++
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 -
> drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 +
> 3 files changed, 121 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index c747824f3c98..72a7ca188be5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -403,6 +403,97 @@ static void fimc_handle_lastend(struct fimc_context
> *ctx, bool enable)
> fimc_write(ctx, cfg, EXYNOS_CIOCTRL);
> }
>
> +static int fimc_set_planar_addr(struct drm_exynos_ipp_buf_info *buf_info,
> + u32 fmt, struct drm_exynos_sz *sz)
> +{
> + dma_addr_t *base[EXYNOS_DRM_PLANAR_MAX];
I think I've seen this at several other places already, but I never
fully understood it.
Why are we using dma_addr_t* here, instead of just dma_addr_t? I mean in
the following code the pointer is just in the dereferenced form anyway,
so why this added indirection?
With best wishes,
Tobias
> + uint64_t size[EXYNOS_DRM_PLANAR_MAX];
> + uint64_t ofs[EXYNOS_DRM_PLANAR_MAX];
> + bool bypass = false;
> + uint64_t tsize = 0;
> + int i;
> +
> + for_each_ipp_planar(i) {
> + base[i] = &buf_info->base[i];
> + size[i] = buf_info->size[i];
> + ofs[i] = 0;
> + tsize += size[i];
> + }
> +
> + if (!tsize) {
> + DRM_INFO("%s:failed to get buffer size.\n", __func__);
> + return 0;
> + }
> +
> + switch (fmt) {
> + case DRM_FORMAT_NV12:
> + case DRM_FORMAT_NV21:
> + case DRM_FORMAT_NV16:
> + case DRM_FORMAT_NV61:
> + ofs[0] = sz->hsize * sz->vsize;
> + ofs[1] = ofs[0] >> 1;
> + if (*base[0] && *base[1]) {
> + if (size[0] + size[1] < ofs[0] + ofs[1])
> + goto err_info;
> + bypass = true;
> + }
> + break;
> + case DRM_FORMAT_YUV410:
> + case DRM_FORMAT_YVU410:
> + case DRM_FORMAT_YUV411:
> + case DRM_FORMAT_YVU411:
> + case DRM_FORMAT_YUV420:
> + case DRM_FORMAT_YVU420:
> + case DRM_FORMAT_YUV422:
> + case DRM_FORMAT_YVU422:
> + case DRM_FORMAT_YUV444:
> + case DRM_FORMAT_YVU444:
> + ofs[0] = sz->hsize * sz->vsize;
> + ofs[1] = ofs[2] = ofs[0] >> 2;
> + if (*base[0] && *base[1] && *base[2]) {
> + if (size[0]+size[1]+size[2] < ofs[0]+ofs[1]+ofs[2])
> + goto err_info;
> + bypass = true;
> + }
> + break;
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + ofs[0] = sz->hsize * sz->vsize << 2;
> + if (*base[0]) {
> + if (size[0] < ofs[0])
> + goto err_info;
> + }
> + bypass = true;
> + break;
> + default:
> + bypass = true;
> + break;
> + }
> +
> + if (!bypass) {
> + *base[1] = *base[0] + ofs[0];
> + if (ofs[1] && ofs[2])
> + *base[2] = *base[1] + ofs[1];
> + }
> +
> + DRM_DEBUG_KMS("%s:y[0x%x],cb[0x%x],cr[0x%x]\n", __func__,
> + *base[0], *base[1], *base[2]);
> +
> + return 0;
> +
> +err_info:
> + DRM_ERROR("invalid size for fmt[0x%x]\n", fmt);
> +
> + for_each_ipp_planar(i) {
> + base[i] = &buf_info->base[i];
> + size[i] = buf_info->size[i];
> +
> + DRM_ERROR("buf[%d] - base[0x%x] sz[%llu] ofs[%llu]\n",
> + i, *base[i], size[i], ofs[i]);
> + }
> +
> + return -EINVAL;
> +}
>
> static int fimc_src_set_fmt_order(struct fimc_context *ctx, u32 fmt)
> {
> @@ -689,6 +780,7 @@ static int fimc_src_set_addr(struct device *dev,
> struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
> struct drm_exynos_ipp_property *property;
> struct drm_exynos_ipp_config *config;
> + int ret;
>
> if (!c_node) {
> DRM_ERROR("failed to get c_node.\n");
> @@ -709,6 +801,12 @@ static int fimc_src_set_addr(struct device *dev,
> switch (buf_type) {
> case IPP_BUF_ENQUEUE:
> config = &property->config[EXYNOS_DRM_OPS_SRC];
> + ret = fimc_set_planar_addr(buf_info, config->fmt, &config->sz);
> + if (ret) {
> +
Re: [PATCH 18/25] drm/exynos: fimd: fix dma burst size setting for small plane size
This one looks a bit strange. It only changes the argument list of
fimd_win_set_pixfmt() but the commit message that it actually fixes
something.
The corresponding upstream commit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66367461e573321f0fbb0be0391165b5a54d5fe4
With best wishes,
Tobias
Marek Szyprowski wrote:
> This patch fixes trashed display of buffers cropped to very small width.
> Even if DMA is unstable and causes tearing when changing the burst size,
> it is still better than displaying a garbage.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 44226b2b46c7..6c04ff6432d4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -487,7 +487,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>
>
> static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
> - struct drm_framebuffer *fb)
> + uint32_t pixel_format, int width)
> {
> unsigned long val;
>
> @@ -498,11 +498,11 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
>* So the request format is ARGB then change it to XRGB.
>*/
> if (ctx->driver_data->has_limited_fmt && !win) {
> - if (fb->pixel_format == DRM_FORMAT_ARGB)
> - fb->pixel_format = DRM_FORMAT_XRGB;
> + if (pixel_format == DRM_FORMAT_ARGB)
> + pixel_format = DRM_FORMAT_XRGB;
> }
>
> - switch (fb->pixel_format) {
> + switch (pixel_format) {
> case DRM_FORMAT_C8:
> val |= WINCON0_BPPMODE_8BPP_PALETTE;
> val |= WINCONx_BURSTLEN_8WORD;
> @@ -538,17 +538,15 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> break;
> }
>
> - DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
> -
> /*
> - * In case of exynos, setting dma-burst to 16Word causes permanent
> - * tearing for very small buffers, e.g. cursor buffer. Burst Mode
> - * switching which is based on plane size is not recommended as
> - * plane size varies alot towards the end of the screen and rapid
> - * movement causes unstable DMA which results into iommu crash/tear.
> + * Setting dma-burst to 16Word causes permanent tearing for very small
> + * buffers, e.g. cursor buffer. Burst Mode switching which based on
> + * plane size is not recommended as plane size varies alot towards the
> + * end of the screen and rapid movement causes unstable DMA, but it is
> + * still better to change dma-burst than displaying garbage.
>*/
>
> - if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
> + if (width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
> val &= ~WINCONx_BURSTLEN_MASK;
> val |= WINCONx_BURSTLEN_4WORD;
> }
> @@ -723,7 +721,7 @@ static void fimd_update_plane(struct exynos_drm_crtc
> *crtc,
> DRM_DEBUG_KMS("osd size = 0x%x\n", (unsigned int)val);
> }
>
> - fimd_win_set_pixfmt(ctx, win, fb);
> + fimd_win_set_pixfmt(ctx, win, fb->pixel_format, state->src.w);
>
> /* hardware window 0 doesn't support color key. */
> if (win != 0)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/25] drm/exynos: gsc: fix wrong pm_runtime state
Hi Marek, 2015-11-10 Marek Szyprowski : > From: Seung-Woo Kim > > At probe time, gsc clock is not enabled, so pm_runtime state should > be deactive. So this patch removes pm_runtime_set_active() from > gsc_probe(). > > Signed-off-by: Seung-Woo Kim > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Gustavo Padovan Gustavo -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/25] drm/exynos: gsc: prepare and unprepare gsc clock
Hi Marek, 2015-11-10 Marek Szyprowski : > From: Seung-Woo Kim > > Ths patch changes the clk_enable and clk_disable call in gsc driver > into clk_prepare_enable and clk_disable_unprepare. > > Signed-off-by: Seung-Woo Kim > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Gustavo Padovan Gustavo -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem
Hey Daniel, Daniel Stone wrote: > Hi, > > On 12 November 2015 at 12:44, Tobias Jakobi > wrote: >> Daniel Stone wrote: >>> On 10 November 2015 at 13:23, Marek Szyprowski >>> wrote: This patch series introduces a new life into Exynos IPP (Image Post Processing) subsystem by integrating it (transparently for userspace applications) with Exynos DRM core plane management. This means that all CRTC drivers transparently get support for standard features of IPP subsystem like rotation and scaling. Support for features not supported natively by CRTC drivers is implemented with a help of temporary framebuffers, where image data is processed by IPP subsystem before performing the scanout by a CRTC driver. >>> >>> Hm, interesting. The RPi has a similar setup - VC4 can work either >>> online (realtime scanout) or offline (mem2mem). Once the scene crosses >>> a certain complexity boundary, it can no longer be composed in >>> realtime and must fall back to mem2mem before it can be displayed. >>> >>> There was talk of having the fallback handled transparently in KMS for >>> VC4 - similar to this - but the conclusion seemed to be that it was an >>> inappropriate level of hidden complexity for KMS, and instead would >>> best be handled by something like HWComposer directing it. Using HWC >>> would then let you more intelligently split the scene from userspace >>> (e.g. flatten some components but retain others as active planes). >> I would be intererested in the performance implications of this >> abstraction as well. >> >> I'd like to use the Exynos FIMC for CSC and scaling, but this operation >> of course takes some time. >> >> I wonder how this interacts with page flipping. If I queue a pageflip >> event with a buffer that needs to go through the IPP for display, where >> does the delay caused by the operation factor it? If I understand this >> correctly drmModePageFlip() still is going to return immediately, but I >> might miss the next vblank period because the FIMC is still working on >> the buffer. > > Hmm, from my reading of the patches, this didn't affect page-flip > timings. In the sync case, it would block until the buffer was > actually displayed, and in the async case, the event would still be > delivered at the right time. But you're right that it does introduce > hugely variable timings, which can be a problem for userspace which > tries to be intelligent. I guess this is an issue then, since the FIMC is mainly used in the context of converting video frames. And a good video player probably wants to have tight control over the presentation of video frames, to control A/V sychronization and so on. > And even then potentially misleading from a > performance point of view: if userspace can rotate natively (e.g. as > part of a composition blit, or when rendering buffers in the first > place), then we can skip the extra work from G2D. > >> My problem here is that this abstraction would take too much control >> from the user. >> >> Correct me if I have this wrong! > > I believe that was the concern previously, yeah. :) That, and encoding > these semantics in a user-visible way could potentially be dangerous. I guess the local path transfers would still make sense though, but if I understand this correctly this would affect FIMD. With best wishes, Tobias > > Cheers, > Daniel > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem
Hi, On 12 November 2015 at 12:44, Tobias Jakobi wrote: > Daniel Stone wrote: >> On 10 November 2015 at 13:23, Marek Szyprowski >> wrote: >>> This patch series introduces a new life into Exynos IPP (Image Post >>> Processing) subsystem by integrating it (transparently for userspace >>> applications) with Exynos DRM core plane management. This means that all >>> CRTC drivers transparently get support for standard features of IPP >>> subsystem like rotation and scaling. >>> >>> Support for features not supported natively by CRTC drivers is >>> implemented with a help of temporary framebuffers, where image data is >>> processed by IPP subsystem before performing the scanout by a CRTC driver. >> >> Hm, interesting. The RPi has a similar setup - VC4 can work either >> online (realtime scanout) or offline (mem2mem). Once the scene crosses >> a certain complexity boundary, it can no longer be composed in >> realtime and must fall back to mem2mem before it can be displayed. >> >> There was talk of having the fallback handled transparently in KMS for >> VC4 - similar to this - but the conclusion seemed to be that it was an >> inappropriate level of hidden complexity for KMS, and instead would >> best be handled by something like HWComposer directing it. Using HWC >> would then let you more intelligently split the scene from userspace >> (e.g. flatten some components but retain others as active planes). > I would be intererested in the performance implications of this > abstraction as well. > > I'd like to use the Exynos FIMC for CSC and scaling, but this operation > of course takes some time. > > I wonder how this interacts with page flipping. If I queue a pageflip > event with a buffer that needs to go through the IPP for display, where > does the delay caused by the operation factor it? If I understand this > correctly drmModePageFlip() still is going to return immediately, but I > might miss the next vblank period because the FIMC is still working on > the buffer. Hmm, from my reading of the patches, this didn't affect page-flip timings. In the sync case, it would block until the buffer was actually displayed, and in the async case, the event would still be delivered at the right time. But you're right that it does introduce hugely variable timings, which can be a problem for userspace which tries to be intelligent. And even then potentially misleading from a performance point of view: if userspace can rotate natively (e.g. as part of a composition blit, or when rendering buffers in the first place), then we can skip the extra work from G2D. > My problem here is that this abstraction would take too much control > from the user. > > Correct me if I have this wrong! I believe that was the concern previously, yeah. :) That, and encoding these semantics in a user-visible way could potentially be dangerous. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PCI: designware: bail out if host_init failed
There's no reason to continue the initialization such as configure
register, scan root bus etc. if customized host_init() failed. This
patch tries to check the host_init result, bail out if failed.
Signed-off-by: Jisheng Zhang
---
drivers/pci/host/pci-dra7xx.c | 4 +++-
drivers/pci/host/pci-exynos.c | 4 +++-
drivers/pci/host/pci-imx6.c| 4 +++-
drivers/pci/host/pci-keystone.c| 4 +++-
drivers/pci/host/pci-layerscape.c | 25 -
drivers/pci/host/pcie-designware.c | 7 +--
drivers/pci/host/pcie-designware.h | 2 +-
drivers/pci/host/pcie-spear13xx.c | 4 +++-
8 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 8c36880..b3160a1 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -149,7 +149,7 @@ static void dra7xx_pcie_enable_interrupts(struct pcie_port
*pp)
LEG_EP_INTERRUPTS);
}
-static void dra7xx_pcie_host_init(struct pcie_port *pp)
+static int dra7xx_pcie_host_init(struct pcie_port *pp)
{
dw_pcie_setup_rc(pp);
@@ -162,6 +162,8 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
if (IS_ENABLED(CONFIG_PCI_MSI))
dw_pcie_msi_init(pp);
dra7xx_pcie_enable_interrupts(pp);
+
+ return 0;
}
static struct pcie_host_ops dra7xx_pcie_host_ops = {
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 01095e1..57f370b 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -481,10 +481,12 @@ static int exynos_pcie_link_up(struct pcie_port *pp)
return 0;
}
-static void exynos_pcie_host_init(struct pcie_port *pp)
+static int exynos_pcie_host_init(struct pcie_port *pp)
{
exynos_pcie_establish_link(pp);
exynos_pcie_enable_interrupts(pp);
+
+ return 0;
}
static struct pcie_host_ops exynos_pcie_host_ops = {
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 22e8224..9a46680 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -425,7 +425,7 @@ static int imx6_pcie_establish_link(struct pcie_port *pp)
return 0;
}
-static void imx6_pcie_host_init(struct pcie_port *pp)
+static int imx6_pcie_host_init(struct pcie_port *pp)
{
imx6_pcie_assert_core_reset(pp);
@@ -439,6 +439,8 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
if (IS_ENABLED(CONFIG_PCI_MSI))
dw_pcie_msi_init(pp);
+
+ return 0;
}
static void imx6_pcie_reset_phy(struct pcie_port *pp)
diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
index 0aa81bd..2604571 100644
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -250,7 +250,7 @@ static int keystone_pcie_fault(unsigned long addr, unsigned
int fsr,
return 0;
}
-static void __init ks_pcie_host_init(struct pcie_port *pp)
+static int __init ks_pcie_host_init(struct pcie_port *pp)
{
struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
u32 val;
@@ -277,6 +277,8 @@ static void __init ks_pcie_host_init(struct pcie_port *pp)
*/
hook_fault_code(17, keystone_pcie_fault, SIGBUS, 0,
"Asynchronous external abort");
+
+ return 0;
}
static struct pcie_host_ops keystone_pcie_host_ops = {
diff --git a/drivers/pci/host/pci-layerscape.c
b/drivers/pci/host/pci-layerscape.c
index 3923bed..a6e9070 100644
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -94,8 +94,9 @@ static int ls1021_pcie_link_up(struct pcie_port *pp)
return 1;
}
-static void ls1021_pcie_host_init(struct pcie_port *pp)
+static int ls1021_pcie_host_init(struct pcie_port *pp)
{
+ int ret;
struct ls_pcie *pcie = to_ls_pcie(pp);
u32 val, index[2];
@@ -103,15 +104,14 @@ static void ls1021_pcie_host_init(struct pcie_port *pp)
"fsl,pcie-scfg");
if (IS_ERR(pcie->scfg)) {
dev_err(pp->dev, "No syscfg phandle specified\n");
- pcie->scfg = NULL;
- return;
+ ret = PTR_ERR(pcie->scfg);
+ goto err;
}
- if (of_property_read_u32_array(pp->dev->of_node,
- "fsl,pcie-scfg", index, 2)) {
- pcie->scfg = NULL;
- return;
- }
+ ret = of_property_read_u32_array(pp->dev->of_node,
+"fsl,pcie-scfg", index, 2);
+ if (ret)
+ goto err;
pcie->index = index[1];
dw_pcie_setup_rc(pp);
@@ -123,6 +123,11 @@ static void ls1021_pcie_host_init(struct pcie_port *pp)
val = ioread32(pcie->dbi + PCIE_STRFMR1);
val &= 0x;
iowrite32(val, pcie->dbi + PCIE_STRFMR1);
+
+ return 0;
+err:
+ pcie->scfg = NULL;
+
Re: [PATCH] drm/exynos: only run atomic_check() if crtc is active
On Thu, Nov 12, 2015 at 11:11:20AM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Fixes an regression added by 3ae2436 (drm/exynos/mixer: replace
> direct cross-driver call with drm mode). The whole atomic update
> was failing if the hdmi display is not present/active. Add a test
> to only run atomic_check() if the CRTC is active.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index b3ba27f..1d3ca0a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -55,6 +55,9 @@ static int exynos_crtc_atomic_check(struct drm_crtc *crtc,
> {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>
> + if (!state->active)
> + return 0;
> +
> if (exynos_crtc->ops->atomic_check)
> return exynos_crtc->ops->atomic_check(exynos_crtc, state);
>
This looks like something that the core should be doing.
Thierry
signature.asc
Description: PGP signature
[PATCH v8 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
1 file changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..07c8507 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+ Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+&pinctrl_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+&sromc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", &bank))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", &width))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v7 => v8:
- More fixes to documentation
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +-
6 files changed, 184 insertions(+), 6 deletions(-)
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: only run atomic_check() if crtc is active
From: Gustavo Padovan
Fixes an regression added by 3ae2436 (drm/exynos/mixer: replace
direct cross-driver call with drm mode). The whole atomic update
was failing if the hdmi display is not present/active. Add a test
to only run atomic_check() if the CRTC is active.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b3ba27f..1d3ca0a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -55,6 +55,9 @@ static int exynos_crtc_atomic_check(struct drm_crtc *crtc,
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ if (!state->active)
+ return 0;
+
if (exynos_crtc->ops->atomic_check)
return exynos_crtc->ops->atomic_check(exynos_crtc, state);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem
Hello, Daniel Stone wrote: > Hi Marek, > > On 10 November 2015 at 13:23, Marek Szyprowski > wrote: >> This patch series introduces a new life into Exynos IPP (Image Post >> Processing) subsystem by integrating it (transparently for userspace >> applications) with Exynos DRM core plane management. This means that all >> CRTC drivers transparently get support for standard features of IPP >> subsystem like rotation and scaling. >> >> Support for features not supported natively by CRTC drivers is >> implemented with a help of temporary framebuffers, where image data is >> processed by IPP subsystem before performing the scanout by a CRTC driver. >> >> This patchset is a first version of this 'new feature' and I would like >> get some comments on the proposed approach. I plan to continue working >> on enhancing Exynos DRM drivers and especially do the cleanup the IPP >> subsystem. >> >> Most of the new features are added by the last 2 patches. All other >> patches are bugfixes in various Exynos DRM subdrivers and significant >> core rewrite - introducing a subclass of drm_plane_state was needed and >> all drivers have been converted to use it. Some initial cleanups in IPP >> subsystem were also needed to let Exynos core to call it internally from >> the driver core. This part will be cleaned even more in the future. > > Hm, interesting. The RPi has a similar setup - VC4 can work either > online (realtime scanout) or offline (mem2mem). Once the scene crosses > a certain complexity boundary, it can no longer be composed in > realtime and must fall back to mem2mem before it can be displayed. > > There was talk of having the fallback handled transparently in KMS for > VC4 - similar to this - but the conclusion seemed to be that it was an > inappropriate level of hidden complexity for KMS, and instead would > best be handled by something like HWComposer directing it. Using HWC > would then let you more intelligently split the scene from userspace > (e.g. flatten some components but retain others as active planes). I would be intererested in the performance implications of this abstraction as well. I'd like to use the Exynos FIMC for CSC and scaling, but this operation of course takes some time. I wonder how this interacts with page flipping. If I queue a pageflip event with a buffer that needs to go through the IPP for display, where does the delay caused by the operation factor it? If I understand this correctly drmModePageFlip() still is going to return immediately, but I might miss the next vblank period because the FIMC is still working on the buffer. My problem here is that this abstraction would take too much control from the user. Correct me if I have this wrong! With best wishes, Tobias > > Dan V, Eric - thoughts? > > Cheers, > Daniel > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 16/16] cobalt: add cec support
From: Hans Verkuil
Add CEC support to the cobalt driver.
Signed-off-by: Hans Verkuil
---
drivers/media/pci/cobalt/Kconfig | 1 +
drivers/media/pci/cobalt/cobalt-driver.c | 108 +-
drivers/media/pci/cobalt/cobalt-driver.h | 2 +
drivers/media/pci/cobalt/cobalt-irq.c| 3 +
drivers/media/pci/cobalt/cobalt-v4l2.c | 126 ---
drivers/media/pci/cobalt/cobalt-v4l2.h | 2 +
6 files changed, 216 insertions(+), 26 deletions(-)
diff --git a/drivers/media/pci/cobalt/Kconfig b/drivers/media/pci/cobalt/Kconfig
index a01f0cc..9125747 100644
--- a/drivers/media/pci/cobalt/Kconfig
+++ b/drivers/media/pci/cobalt/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_COBALT
depends on PCI_MSI && MTD_COMPLEX_MAPPINGS
depends on GPIOLIB || COMPILE_TEST
depends on SND
+ select MEDIA_CEC
select I2C_ALGOBIT
select VIDEO_ADV7604
select VIDEO_ADV7511
diff --git a/drivers/media/pci/cobalt/cobalt-driver.c
b/drivers/media/pci/cobalt/cobalt-driver.c
index 8fed61e..0b9e194 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.c
+++ b/drivers/media/pci/cobalt/cobalt-driver.c
@@ -76,6 +76,7 @@ static u8 edid[256] = {
0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x10,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x68,
+
0x02, 0x03, 0x1a, 0xc0, 0x48, 0xa2, 0x10, 0x04,
0x02, 0x01, 0x21, 0x14, 0x13, 0x23, 0x09, 0x07,
0x07, 0x65, 0x03, 0x0c, 0x00, 0x10, 0x00, 0xe2,
@@ -149,17 +150,44 @@ static void cobalt_notify(struct v4l2_subdev *sd,
struct cobalt *cobalt = to_cobalt(sd->v4l2_dev);
unsigned sd_nr = cobalt_get_sd_nr(sd);
struct cobalt_stream *s = &cobalt->streams[sd_nr];
- bool hotplug = arg ? *((int *)arg) : false;
- if (s->is_output)
+ switch (notification) {
+ case V4L2_SUBDEV_CEC_TX_DONE:
+ cec_transmit_done(s->cec_adap, (unsigned long)arg);
+ return;
+ case V4L2_SUBDEV_CEC_RX_MSG:
+ cec_received_msg(s->cec_adap, arg);
+ return;
+ case V4L2_SUBDEV_CEC_CONN_INPUTS:
+ cec_connected_inputs(s->cec_adap, *(u16 *)arg);
+ return;
+ default:
+ break;
+ }
+
+ if (s->is_output) {
+ switch (notification) {
+ case ADV7511_EDID_DETECT: {
+ struct adv7511_edid_detect *ed = arg;
+
+ s->cec_adap->phys_addr = ed->phys_addr;
+ break;
+ }
+ }
return;
+ }
switch (notification) {
- case ADV76XX_HOTPLUG:
+ case ADV76XX_HOTPLUG: {
+ bool hotplug = arg ? *((int *)arg) : false;
+
cobalt_s_bit_sysctrl(cobalt,
COBALT_SYS_CTRL_HPD_TO_CONNECTOR_BIT(sd_nr), hotplug);
+ if (s->cec_adap)
+ cec_connected_inputs(s->cec_adap, hotplug);
cobalt_dbg(1, "Set hotplug for adv %d to %d\n", sd_nr, hotplug);
break;
+ }
case V4L2_DEVICE_NOTIFY_EVENT:
cobalt_dbg(1, "Format changed for adv %d\n", sd_nr);
v4l2_event_queue(&s->vdev, arg);
@@ -438,12 +466,15 @@ static void cobalt_stream_struct_init(struct cobalt
*cobalt)
for (i = 0; i < COBALT_NUM_STREAMS; i++) {
struct cobalt_stream *s = &cobalt->streams[i];
+ struct video_device *vdev = &s->vdev;
s->cobalt = cobalt;
s->flags = 0;
s->is_audio = false;
s->is_output = false;
s->is_dummy = true;
+ snprintf(vdev->name, sizeof(vdev->name),
+"%s-%d", cobalt->v4l2_dev.name, i);
/* The Memory DMA channels will always get a lower channel
* number than the FIFO DMA. Video input should map to the
@@ -485,6 +516,23 @@ static void cobalt_stream_struct_init(struct cobalt
*cobalt)
}
}
+static int cobalt_create_cec_adap(struct cobalt_stream *s)
+{
+ u32 caps = CEC_CAP_IO | CEC_CAP_LOG_ADDRS |
+ CEC_CAP_PASSTHROUGH | CEC_CAP_RC |
+ CEC_CAP_ARC | CEC_CAP_VENDOR_ID;
+ u8 nsinks = 0;
+
+ if (s->is_output)
+ caps |= CEC_CAP_IS_SOURCE | CEC_CAP_CDC_HPD;
+ else
+ nsinks = 1;
+ s->cec_adap = cec_create_adapter(&cobalt_cec_adap_ops,
+s, s->vdev.name, caps, nsinks,
+THIS_MODULE, &s->cobalt->pci_dev->dev);
+ return PTR_ERR_OR_ZERO(s->cec_adap);
+}
+
static int cobalt_subdevs_init(struct cobalt *cobalt)
{
static struct adv76xx_platform_data adv7604_pdata = {
@@ -508,10 +556,10 @@ static int cobalt_subdevs_init(struct cobalt *cobalt)
.platform_data = &adv7604_pda
[PATCHv10 11/16] v4l2-subdev: add HDMI CEC ops
From: Hans Verkuil
Add CEC callbacks to the new v4l2_subdev_cec_ops struct. These are the
low-level CEC ops that subdevs that support CEC have to implement.
Signed-off-by: Hans Verkuil
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
Signed-off-by: Kamil Debski
---
include/media/v4l2-subdev.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b273cf9..e55031e 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -42,6 +42,10 @@
#defineV4L2_DEVICE_NOTIFY_EVENT_IOW('v', 2, struct
v4l2_event)
+#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 3, u32)
+#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 4, struct cec_msg)
+#define V4L2_SUBDEV_CEC_CONN_INPUTS_IOW('v', 5, u16)
+
struct v4l2_device;
struct v4l2_ctrl_handler;
struct v4l2_event;
@@ -51,6 +55,7 @@ struct v4l2_subdev;
struct v4l2_subdev_fh;
struct tuner_setup;
struct v4l2_mbus_frame_desc;
+struct cec_msg;
/* decode_vbi_line */
struct v4l2_decode_vbi_line {
@@ -642,6 +647,14 @@ struct v4l2_subdev_pad_ops {
struct v4l2_mbus_frame_desc *fd);
};
+struct v4l2_subdev_cec_ops {
+ unsigned (*available_log_addrs)(struct v4l2_subdev *sd);
+ int (*enable)(struct v4l2_subdev *sd, bool enable);
+ int (*log_addr)(struct v4l2_subdev *sd, u8 logical_addr);
+ int (*transmit)(struct v4l2_subdev *sd, u32 timeout_ms,
+ u8 retries, struct cec_msg *msg);
+};
+
struct v4l2_subdev_ops {
const struct v4l2_subdev_core_ops *core;
const struct v4l2_subdev_tuner_ops *tuner;
@@ -651,6 +664,7 @@ struct v4l2_subdev_ops {
const struct v4l2_subdev_ir_ops *ir;
const struct v4l2_subdev_sensor_ops *sensor;
const struct v4l2_subdev_pad_ops*pad;
+ const struct v4l2_subdev_cec_ops*cec;
};
/*
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 12/16] cec: adv7604: add cec support.
From: Hans Verkuil
Add CEC support to the adv7604 driver.
Signed-off-by: Hans Verkuil
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
[k.deb...@samsung.com: add missing methods cec/io_write_and_or]
[k.deb...@samsung.com: change adv7604 to adv76xx in added functions]
[hansv...@cisco.com: use _clr_set instead of _and_or]
---
drivers/media/i2c/adv7604.c | 241 +++-
1 file changed, 237 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 5631ec0..f039ae6 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -40,6 +40,7 @@
#include
#include
+#include
#include
#include
#include
@@ -80,6 +81,8 @@ MODULE_LICENSE("GPL");
#define ADV76XX_OP_SWAP_CB_CR (1 << 0)
+#define ADV76XX_MAX_ADDRS (3)
+
enum adv76xx_type {
ADV7604,
ADV7611,
@@ -184,6 +187,10 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+ u8 cec_addr[ADV76XX_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -430,7 +437,8 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg,
u8 val)
return regmap_write(state->regmap[ADV76XX_PAGE_IO], reg, val);
}
-static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8
val)
+static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
{
return io_write(sd, reg, (io_read(sd, reg) & ~mask) | val);
}
@@ -463,6 +471,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8
reg, u8 val)
return regmap_write(state->regmap[ADV76XX_PAGE_CEC], reg, val);
}
+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
+{
+ return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
+}
+
static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
{
struct adv76xx_state *state = to_state(sd);
@@ -550,8 +564,13 @@ static inline int edid_write_block(struct v4l2_subdev *sd,
static void adv76xx_set_hpd(struct adv76xx_state *state, unsigned int hpd)
{
+ u16 connected_inputs;
unsigned int i;
+ connected_inputs = hpd & state->info->read_cable_det(&state->sd);
+ v4l2_subdev_notify(&state->sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
+
for (i = 0; i < state->info->num_dv_ports; ++i)
gpiod_set_value_cansleep(state->hpd_gpio[i], hpd & BIT(i));
@@ -891,9 +910,12 @@ static int adv76xx_s_detect_tx_5v_ctrl(struct v4l2_subdev
*sd)
{
struct adv76xx_state *state = to_state(sd);
const struct adv76xx_chip_info *info = state->info;
+ u16 cable_det = info->read_cable_det(sd);
+ u16 connected_inputs = state->edid.present & cable_det;
- return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl,
- info->read_cable_det(sd));
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
+ return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det);
}
static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd,
@@ -1914,6 +1936,187 @@ static int adv76xx_set_format(struct v4l2_subdev *sd,
return 0;
}
+static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+ if ((cec_read(sd, 0x11) & 0x01) == 0) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__);
+ return;
+ }
+
+ if (tx_raw_status & 0x02) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n",
+__func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_ARB_LOST);
+ return;
+ }
+ if (tx_raw_status & 0x04) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_RETRY_TIMEOUT);
+ return;
+ }
+ if (tx_raw_status & 0x01) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: ready ok\n", __func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_OK);
+ return;
+ }
+}
+
+static void adv76xx_cec_isr(struct v4l2_subdev *sd, bool *handled)
+{
+ u8 cec_irq;
+
+ /* cec controller */
+ cec_irq = io_read(sd, 0x4d) & 0x0f;
+ if (!cec_irq)
+ return;
+
+ v4l2_dbg(1, debug, sd, "%s: cec: irq 0x%x\n", __func__, cec_
[PATCHv10 01/16] dts: exynos4*: add HDMI CEC pin definition to pinctrl
From: Kamil Debski
Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
Exynos4x12 SoCs. These are required by the HDMI CEC device.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index a7c2128..9331c62 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -820,6 +820,13 @@
samsung,pin-pud = <1>;
samsung,pin-drv = <0>;
};
+
+ hdmi_cec: hdmi-cec {
+ samsung,pins = "gpx3-6";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
pinctrl@0386 {
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index bac25c6..856b292 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -885,6 +885,13 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ hdmi_cec: hdmi-cec {
+ samsung,pins = "gpx3-6";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
pinctrl_2: pinctrl@0386 {
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 06/16] rc: Add HDMI CEC protocol handling
From: Kamil Debski
Add handling of remote control events coming from the HDMI CEC bus.
This patch includes a new keymap that maps values found in the CEC
messages to the keys pressed and released. Also, a new protocol has
been added to the core.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
drivers/media/rc/keymaps/Makefile | 1 +
drivers/media/rc/keymaps/rc-cec.c | 174 ++
drivers/media/rc/rc-main.c| 1 +
include/media/rc-core.h | 1 +
include/media/rc-map.h| 5 +-
5 files changed, 181 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/rc/keymaps/rc-cec.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index fbbd3bb..9cffcc6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+ rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..193cdca
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,174 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+
+/* CEC Spec "High-Definition Multimedia Interface Specification" can be
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+ { 0x00, KEY_OK },
+ { 0x01, KEY_UP },
+ { 0x02, KEY_DOWN },
+ { 0x03, KEY_LEFT },
+ { 0x04, KEY_RIGHT },
+ { 0x05, KEY_RIGHT_UP },
+ { 0x06, KEY_RIGHT_DOWN },
+ { 0x07, KEY_LEFT_UP },
+ { 0x08, KEY_LEFT_DOWN },
+ { 0x09, KEY_ROOT_MENU }, /* CEC Spec: Device Root Menu - see Note 2 */
+ /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu, setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device's current state. */
+ { 0x0a, KEY_SETUP },
+ { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+ { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+ { 0x0d, KEY_EXIT },
+ /* 0x0e-0x0f: Reserved */
+ { 0x10, KEY_MEDIA_TOP_MENU },
+ { 0x11, KEY_CONTEXT_MENU },
+ /* 0x12-0x1c: Reserved */
+ { 0x1d, KEY_DIGITS }, /* CEC Spec: select/toggle a Number Entry Mode */
+ { 0x1e, KEY_NUMERIC_11 },
+ { 0x1f, KEY_NUMERIC_12 },
+ /* 0x20-0x29: Keys 0 to 9 */
+ { 0x20, KEY_NUMERIC_0 },
+ { 0x21, KEY_NUMERIC_1 },
+ { 0x22, KEY_NUMERIC_2 },
+ { 0x23, KEY_NUMERIC_3 },
+ { 0x24, KEY_NUMERIC_4 },
+ { 0x25, KEY_NUMERIC_5 },
+ { 0x26, KEY_NUMERIC_6 },
+ { 0x27, KEY_NUMERIC_7 },
+ { 0x28, KEY_NUMERIC_8 },
+ { 0x29, KEY_NUMERIC_9 },
+ { 0x2a, KEY_DOT },
+ { 0x2b, KEY_ENTER },
+ { 0x2c, KEY_CLEAR },
+ /* 0x2d-0x2e: Reserved */
+ { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */
+ { 0x30, KEY_CHANNELUP },
+ { 0x31, KEY_CHANNELDOWN },
+ { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+ { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+ { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */
+ { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+ { 0x36, KEY_HELP },
+ { 0x37, KEY_PAGEUP },
+ { 0x38, KEY_PAGEDOWN },
+ /* 0x39-0x3f: Reserved */
+ { 0x40, KEY_POWER },
+ { 0x41, KEY_VOLUMEUP },
+ { 0x42, KEY_VOLUMEDOWN },
+ { 0x43, KEY_MUTE },
+ { 0x44, KEY_PLAYCD },
+ { 0x45, KEY_STOPCD },
+ { 0x46, KEY_PAUSECD },
+ { 0x47, KEY_RECORD },
+ { 0x48, KEY_REWIND },
+ { 0x49, KEY_FASTFORWARD },
+ { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+ { 0x4b, KEY_FORWARD },
+ { 0x4c, KEY_BACK },
+ { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */
+ { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */
+ /* 0x4f: Reserved */
+ { 0x50, KEY_ANGLE },
+ { 0x51, KEY_TV2 },
+ { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */
+ { 0x53, KEY_EPG },
+ { 0x54, KEY_TIME }, /* CEC Spec: Timer */
+ { 0x55, KEY_CONFIG },
+ /* The following codes are hard t
[PATCHv10 09/16] cec.txt: add CEC framework documentation
Document the new HDMI CEC framework.
Signed-off-by: Hans Verkuil
[k.deb...@samsung.com: add DocBook documentation by Hans Verkuil, with
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
Documentation/cec.txt | 326 ++
1 file changed, 326 insertions(+)
create mode 100644 Documentation/cec.txt
diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..90c2c7f
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,326 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with HDMI CEC
+hardware. It is designed to handle a multiple types of hardware (receivers,
+transmitters, USB dongles). The framework also gives the option to decide
+what to do in the kernel driver and what should be handled by userspace
+applications. In addition it integrates the remote control passthrough
+feature into the kernel's remote control framework.
+
+
+The CEC Protocol
+
+
+The CEC protocol enables consumer electronic devices to communicate with each
+other through the HDMI connection. The protocol uses logical addresses in the
+communication. The logical address is strictly connected with the functionality
+provided by the device. The TV acting as the communication hub is always
+assigned address 0. The physical address is determined by the physical
+connection between devices.
+
+The CEC framework described here is up to date with the CEC 2.0 specification.
+It is documented in the HDMI 1.4 specification with the new 2.0 bits documented
+in the HDMI 2.0 specification. But for most of the features the freely
available
+HDMI 1.3a specification is sufficient:
+
+http://www.microprocessor.org/HDMISpecification13a.pdf
+
+
+The Kernel Interface
+
+
+CEC Adapter
+---
+
+The struct cec_adapter represents the CEC adapter hardware. It is created by
+calling cec_create_adapter() and deleted by calling cec_delete_adapter():
+
+struct cec_adapter *cec_create_adapter(const struct cec_adap_ops *ops,
+ void *priv, const char *name, u32 caps,
+ u8 ninputs, struct module *owner, struct device *parent);
+void cec_delete_adapter(struct cec_adapter *adap);
+
+To create an adapter you need to pass the following information:
+
+ops: adapter operations which are called by the CEC framework and that you
+have to implement.
+
+priv: will be stored in adap->priv and can be used by the adapter ops.
+
+name: the name of the CEC adapter
+
+caps: capabilities of the CEC adapter. These capabilities determine the
+ capabilities of the hardware and which parts are to be handled
+ by userspace and which parts are handled by kernelspace. The
+ capabilities are returned by CEC_ADAP_G_CAPS.
+
+ninputs: the number of HDMI inputs of the device. This may be 0. This
+ is returned by CEC_ADAP_G_CAPS.
+
+owner: the module owner.
+
+parent: the parent device.
+
+
+After creating the adapter the driver can modify the following fields
+in struct cec_adapter:
+
+ u8 available_log_addrs;
+
+This determines the number of simultaneous logical addresses the hardware
+can program. Often this is 1, which is also the default.
+
+ u8 pwr_state;
+
+The CEC_MSG_GIVE_DEVICE_POWER_STATUS power state. By default this is
+CEC_OP_POWER_STATUS_ON (0). The driver can change this to signal power
+state transitions.
+
+ u16 phys_addr;
+
+By default this is 0x, but drivers can change this. The phys_addr field
+must be set before the CEC adapter is enabled (see the adap_enable op below).
+While the CEC adapter remains enabled it cannot be changed. Drivers never set
+this if CEC_CAP_PHYS_ADDR is set.
+
+ u32 vendor_id;
+
+By default this is CEC_VENDOR_ID_NONE (0x). It should not be changed
+once the adapter is configured. Drivers never set this if CEC_CAP_VENDOR_ID
+is set.
+
+ u8 cec_version;
+
+The CEC version that the framework should support. By default this is the
+latest version, but it can be changed to an older version, causing attempts
+to use later extensions to fail. Obviously this should be set before the
+CEC adapter is enabled.
+
+To register the /dev/cecX device node and the remote control device (if
+CEC_CAP_RC is set) you call:
+
+int cec_register_adapter(struct cec_adapter *adap);
+
+To unregister the devices call:
+
+void cec_unregister_adapter(struct cec_adapter *adap);
+
+
+Implementing the Low-Level CEC Adapter
+--
+
+The following low-level adapter operations have to be implemented in
+your driver:
+
+struct cec_adap_ops {
+ /* Low-level callbacks */
+ int (*adap_enable)(struct cec_adapter *adap, bool enable);
+ int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
+ int (*adap_transmit)(struct cec_adapter *adap, u32 timeout_ms, struct
cec_msg *msg);
+
+ /* High-level callbacks */
+ ...
+};
[PATCHv10 08/16] cec: add compat32 ioctl support
From: Hans Verkuil The CEC ioctls didn't have compat32 support, so they returned -ENOTTY when used in a 32 bit application on a 64 bit kernel. Since all the CEC ioctls are 32-bit compatible adding support for this API is trivial. Signed-off-by: Hans Verkuil --- fs/compat_ioctl.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index 48851f6..c8651aa 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -57,6 +57,7 @@ #include #include #include +#include #include #include @@ -1381,6 +1382,24 @@ COMPATIBLE_IOCTL(VIDEO_GET_NAVI) COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES) COMPATIBLE_IOCTL(VIDEO_GET_SIZE) COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE) +/* cec */ +COMPATIBLE_IOCTL(CEC_ADAP_G_CAPS) +COMPATIBLE_IOCTL(CEC_ADAP_G_LOG_ADDRS) +COMPATIBLE_IOCTL(CEC_ADAP_S_LOG_ADDRS) +COMPATIBLE_IOCTL(CEC_ADAP_G_STATE) +COMPATIBLE_IOCTL(CEC_ADAP_S_STATE) +COMPATIBLE_IOCTL(CEC_ADAP_G_PHYS_ADDR) +COMPATIBLE_IOCTL(CEC_ADAP_S_PHYS_ADDR) +COMPATIBLE_IOCTL(CEC_ADAP_G_VENDOR_ID) +COMPATIBLE_IOCTL(CEC_ADAP_S_VENDOR_ID) +COMPATIBLE_IOCTL(CEC_G_MONITOR) +COMPATIBLE_IOCTL(CEC_S_MONITOR) +COMPATIBLE_IOCTL(CEC_CLAIM) +COMPATIBLE_IOCTL(CEC_RELEASE) +COMPATIBLE_IOCTL(CEC_G_PASSTHROUGH) +COMPATIBLE_IOCTL(CEC_TRANSMIT) +COMPATIBLE_IOCTL(CEC_RECEIVE) +COMPATIBLE_IOCTL(CEC_DQEVENT) /* joystick */ COMPATIBLE_IOCTL(JSIOCGVERSION) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 03/16] dts: exynos4412-odroid*: enable the HDMI CEC device
From: Kamil Debski
Add a dts node entry and enable the HDMI CEC device present in the Exynos4
family of SoCs.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-universal_c210.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index eb37952..5c4393d 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -222,6 +222,10 @@
enable-active-high;
};
+ cec@100B {
+ status = "okay";
+ };
+
hdmi_ddc: i2c-ddc {
compatible = "i2c-gpio";
gpios = <&gpe4 2 0 &gpe4 3 0>;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 05/16] HID: add HDMI CEC specific keycodes
From: Kamil Debski
Add HDMI CEC specific keycodes to the keycodes definition.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
include/uapi/linux/input.h | 28
1 file changed, 28 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index a32bff1..5e7019a 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -752,6 +752,34 @@ struct input_keymap_entry {
#define KEY_KBDINPUTASSIST_ACCEPT 0x264
#define KEY_KBDINPUTASSIST_CANCEL 0x265
+#define KEY_RIGHT_UP 0x266
+#define KEY_RIGHT_DOWN 0x267
+#define KEY_LEFT_UP0x268
+#define KEY_LEFT_DOWN 0x269
+#define KEY_ROOT_MENU 0x26a /* Show Device's Root Menu */
+#define KEY_MEDIA_TOP_MENU 0x26b /* Show Top Menu of the Media
(e.g. DVD) */
+#define KEY_NUMERIC_11 0x26c
+#define KEY_NUMERIC_12 0x26d
+/*
+ * Toggle Audio Description: refers to an audio service that helps blind and
+ * visually impaired consumers understand the action in a program. Note: in
+ * some countries this is referred to as "Video Description".
+ */
+#define KEY_AUDIO_DESC 0x26e
+#define KEY_3D_MODE0x26f
+#define KEY_NEXT_FAVORITE 0x270
+#define KEY_STOP_RECORD0x271
+#define KEY_PAUSE_RECORD 0x272
+#define KEY_VOD0x273 /* Video on Demand */
+#define KEY_UNMUTE 0x274
+#define KEY_FASTREVERSE0x275
+#define KEY_SLOWREVERSE0x276
+/*
+ * Control a data application associated with the currently viewed channel,
+ * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.)
+ */
+#define KEY_DATA 0x275
+
#define BTN_TRIGGER_HAPPY 0x2c0
#define BTN_TRIGGER_HAPPY1 0x2c0
#define BTN_TRIGGER_HAPPY2 0x2c1
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 15/16] cec: s5p-cec: Add s5p-cec driver
From: Kamil Debski
Add CEC interface driver present in the Samsung Exynos range of
SoCs.
The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
.../devicetree/bindings/media/s5p-cec.txt | 31 +++
drivers/media/platform/Kconfig | 12 +
drivers/media/platform/Makefile| 1 +
drivers/media/platform/s5p-cec/Makefile| 2 +
drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 37 +++
.../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 +++
drivers/media/platform/s5p-cec/regs-cec.h | 96 +++
drivers/media/platform/s5p-cec/s5p_cec.c | 289 +
drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++
9 files changed, 752 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt
create mode 100644 drivers/media/platform/s5p-cec/Makefile
create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h
diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt
b/Documentation/devicetree/bindings/media/s5p-cec.txt
new file mode 100644
index 000..925ab4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -0,0 +1,31 @@
+* Samsung HDMI CEC driver
+
+The HDMI CEC module is present is Samsung SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+ - compatible : value should be following
+ "samsung,s5p-cec"
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : HDMI CEC interrupt number to the CPU.
+ - clocks : from common clock binding: handle to HDMI CEC clock.
+ - clock-names : from common clock binding: must contain "hdmicec",
+ corresponding to entry in the clocks property.
+ - samsung,syscon-phandle - phandle to the PMU system controller
+
+Example:
+
+hdmicec: cec@100B {
+ compatible = "samsung,s5p-cec";
+ reg = <0x100B 0x200>;
+ interrupts = <0 114 0>;
+ clocks = <&clock CLK_HDMI_CEC>;
+ clock-names = "hdmicec";
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ccbc974..91794a6 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -117,6 +117,18 @@ config VIDEO_S3C_CAMIF
source "drivers/media/platform/soc_camera/Kconfig"
source "drivers/media/platform/exynos4-is/Kconfig"
source "drivers/media/platform/s5p-tv/Kconfig"
+
+config VIDEO_SAMSUNG_S5P_CEC
+ tristate "Samsung S5P CEC driver"
+ depends on VIDEO_DEV && VIDEO_V4L2 && (PLAT_S5P || ARCH_EXYNOS ||
COMPILE_TEST)
+ select MEDIA_CEC
+ default n
+ ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
source "drivers/media/platform/am437x/Kconfig"
source "drivers/media/platform/xilinx/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295..957af5f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) +=
m2m-deinterlace.o
obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
diff --git a/drivers/media/platform/s5p-cec/Makefile
b/drivers/media/platform/s5p-cec/Makefile
new file mode 100644
index 000..0e2cf45
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o
+s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
new file mode 100644
index 000..d008695
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
@@ -0,0 +1,37 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
+ *
+ * Copyright (c) 2010, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * Header file for interface of Samsung Exynos hdmi cec hardware
+ *
+ * This program is free softw
[PATCHv10 04/16] input.h: add BUS_CEC type
From: Hans Verkuil
Inputs can come in over the HDMI CEC bus, so add a new type for this.
Signed-off-by: Hans Verkuil
Acked-by: Dmitry Torokhov
---
include/uapi/linux/input.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 731417c..a32bff1 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -972,6 +972,7 @@ struct input_keymap_entry {
#define BUS_GSC0x1A
#define BUS_ATARI 0x1B
#define BUS_SPI0x1C
+#define BUS_CEC0x1D
/*
* MT_TOOL types
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 02/16] dts: exynos4: add node for the HDMI CEC device
From: Kamil Debski
This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 98c0a36..7baff26 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -720,6 +720,18 @@
status = "disabled";
};
+ hdmicec: cec@100B {
+ compatible = "samsung,s5p-cec";
+ reg = <0x100B 0x200>;
+ interrupts = <0 114 0>;
+ clocks = <&clock CLK_HDMI_CEC>;
+ clock-names = "hdmicec";
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "disabled";
+ };
+
mixer: mixer@12C1 {
compatible = "samsung,exynos4210-mixer";
interrupts = <0 91 0>;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv10 00/16] HDMI CEC framework
Hi all, The tenth version of this patchset addresses comments I received from Russell King and various bug fixes and enhancements as the result of more testing. The cec.txt has been updated, but before I can make the final version there are three areas that I want to look at more closely: 1) What to do if a cable is disconnected and reconnected for a source: should the CEC adapter be disabled and re-enabled? Which means that you need to reconfigure. Or just update the physical address from the EDID (if necessary)? I think the latter, but I need to analyze this more closely. 2) I am not happy with the event mechanism. It's OK for messages, but for other events it is awkward. 3) The status field gives insufficient information and I want to reorganize that for the next version. The cec-ctl and cec-compliance utilities used to test the CEC framework can be found here: http://git.linuxtv.org/cgit.cgi/hverkuil/v4l-utils.git/log/?h=cec Best regards, Hans Changes since v9 - Updated cec.txt - Added a promiscuous capability to signal those adapters that can monitor all CEC traffic, not just directed and broadcast messages. I have one adapter that can do this. Added code in the framework to handle such messages correctly. - The status field is now value and no longer a bitmask. - Renamed the kernel config from CEC to MEDIA_CEC - The adap_transmit() callback now has a retries argument. - Use the new CEC_MAX_MSG_SIZE define instead of hardcoding it as 16 - Add support to wait for a reply after a broadcast message: this was forbidden, but it is a valid use-case. - Make sure you can't send a message to yourself. - Waiting for a transmit to succeed would never timeout (and couldn't be interrupted). Fixed. - The message status was not updated correctly if it was CEC_MSG_FEATURE_ABORTed. - Fixed a nasty kernel oops when deleting a cec adapter. - Removed the owner check: the module owner is NULL if it is compiled into the kernel instead of as a module. - Added separate register/unregister calls: this is safer and actually made it possible to drop the ugly 'cec_ready' v4l2_subdev op. Suggested by Russell, and that was a good idea. - Added missing support for 32-bit to 64-bit ioctl conversion. - Move the v4l2_subdev cec ops into a v4l2_subdev_cec_ops struct. Changes since v8 - Addressed the comments Russell King made about how the cec character devices should be allocated/freed. - Updated the DocBook documentation. Changes since v7 - I thought that the core thread could handle out-of-order messages, but that turned out to be wrong. After careful analysis I realized that I had to rewrite this part in cec.c in order to make it work. - Added new CEC-specific keys to input.h and use them in the CEC rc keymap. Replaced KEY_PLAY/PAUSE/STOP with KEY_PLAYCD/PAUSECD/STOPCD to clarify that these are media operations and not the Pause key on the keyboard. - Added CEC_PHYS_ADDR_INVALID (0x) - Added monitor support to monitor CEC traffic - Replaced CAP_TRANSMIT and CAP_RECEIVE by a single CAP_IO. - Replaced CAP_CDC by CAP_CDC_HPD since this only applies to the HPD part of the CDC messages. - Add CAP_IS_SOURCE. - Add ninputs field to cec_caps to export the number of inputs of the device. - Drop CEC_LOG_ADDRS_FL_HANDLE_MSGS and the flags field (see next change for more info). - Add CEC_CLAIM and CEC_RELEASE to explicitly start/stop processing CEC messages. This also implies ownership of the CEC interface, so other filehandles can only receive but not transmit. - Reworked event handling: report adapter state changes, input changes and if the message receive queue is full. - cec-funcs.h: added CDC HEC support. - Renamed G/S_ADAP ioctls to ADAP_G/S: this made it clearer which ioctls deal with the adapter configuration and which deal with CEC messages/events. - Clarified which CEC messages are passed on to userspace and which aren't. Specifically if CAP_ARC is set, then all ARC messages are handled by the kernel. If CAP_CDC_HPD is set, then all CDC hotplug messages are handled by the kernel. Otherwise these messages are passed on to userspace. Changes since v6 - added cec-funcs.h to provide wrapper functions that fill in the cec_msg struct. This header is needed both by the kernel and by applications. - fix a missing rc_unregister_device call. - added CEC support for the adv7842 and cobalt drivers. - added CEC operand defines. Rename CEC message defines to CEC_MSG_ and operand defines now use CEC_OP_. - the CEC_VERSION defines are dropped since we now have the CEC_OP_VERSION defines. - ditto: CEC_PRIM_DEVTYPE_ is now CEC_OP_PRIM_DEVTYPE. - ditto: CEC_FL_ALL_DEVTYPE_ is now CEC_OP_ALL_DEVTYPE. - cec-ioc-g-adap-log-addrs.xml: document cec_versions field. - cec-ioc-g-caps.xml: drop vendor_id and version fields. - add MAINTAINERS entry. - add CDC support (not yet fully functional). - ad
[PATCHv10 13/16] cec: adv7842: add cec support
From: Hans Verkuil
Add CEC support to the adv7842 driver.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7842.c | 255 +---
1 file changed, 238 insertions(+), 17 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index b7269b8..0f29b33 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -79,6 +80,8 @@ MODULE_LICENSE("GPL");
#define ADV7842_OP_SWAP_CB_CR (1 << 0)
+#define ADV7842_MAX_ADDRS (3)
+
/*
**
*
@@ -142,6 +145,10 @@ struct adv7842_state {
struct v4l2_ctrl *free_run_color_ctrl_manual;
struct v4l2_ctrl *free_run_color_ctrl;
struct v4l2_ctrl *rgb_quantization_range_ctrl;
+
+ u8 cec_addr[ADV7842_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
};
/* Unsupported timings. This device cannot support 720p30. */
@@ -418,9 +425,9 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg,
u8 val)
return adv_smbus_write_byte_data(state->i2c_cec, reg, val);
}
-static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8
val)
+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
u8 val)
{
- return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+ return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
}
static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
@@ -696,6 +703,18 @@ adv7842_get_dv_timings_cap(struct v4l2_subdev *sd)
/* --- */
+static u16 adv7842_read_cable_det(struct v4l2_subdev *sd)
+{
+ u8 reg = io_read(sd, 0x6f);
+ u16 val = 0;
+
+ if (reg & 0x02)
+ val |= 1; /* port A */
+ if (reg & 0x01)
+ val |= 2; /* port B */
+ return val;
+}
+
static void adv7842_delayed_work_enable_hotplug(struct work_struct *work)
{
struct delayed_work *dwork = to_delayed_work(work);
@@ -703,8 +722,13 @@ static void adv7842_delayed_work_enable_hotplug(struct
work_struct *work)
struct adv7842_state, delayed_work_enable_hotplug);
struct v4l2_subdev *sd = &state->sd;
int present = state->hdmi_edid.present;
+ u16 connected_inputs;
u8 mask = 0;
+ connected_inputs = present & adv7842_read_cable_det(sd);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
+
v4l2_dbg(2, debug, sd, "%s: enable hotplug on ports: 0x%x\n",
__func__, present);
@@ -983,20 +1007,16 @@ static int adv7842_s_register(struct v4l2_subdev *sd,
static int adv7842_s_detect_tx_5v_ctrl(struct v4l2_subdev *sd)
{
struct adv7842_state *state = to_state(sd);
- int prev = v4l2_ctrl_g_ctrl(state->detect_tx_5v_ctrl);
- u8 reg_io_6f = io_read(sd, 0x6f);
- int val = 0;
+ u16 cable_det = adv7842_read_cable_det(sd);
+ u16 connected_inputs;
- if (reg_io_6f & 0x02)
- val |= 1; /* port A */
- if (reg_io_6f & 0x01)
- val |= 2; /* port B */
+ v4l2_dbg(1, debug, sd, "%s: 0x%x\n", __func__, cable_det);
- v4l2_dbg(1, debug, sd, "%s: 0x%x -> 0x%x\n", __func__, prev, val);
+ connected_inputs = state->hdmi_edid.present & cable_det;
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
- if (val != prev)
- return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, val);
- return 0;
+ return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det);
}
static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd,
@@ -2157,6 +2177,183 @@ static void adv7842_irq_enable(struct v4l2_subdev *sd,
bool enable)
}
}
+static void adv7842_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+ if ((cec_read(sd, 0x11) & 0x01) == 0) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__);
+ return;
+ }
+
+ if (tx_raw_status & 0x02) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n",
+__func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_ARB_LOST);
+ return;
+ }
+ if (tx_raw_status & 0x04) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_RETRY_TIMEOUT);
+ return;
+ }
+ if (tx_raw_status & 0x01) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: ready ok\n", __func__);
[PATCHv10 14/16] cec: adv7511: add cec support.
From: Hans Verkuil
Add CEC support to the adv7511 driver.
Signed-off-by: Hans Verkuil
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7511.c | 364 +++-
include/media/adv7511.h | 6 +-
2 files changed, 358 insertions(+), 12 deletions(-)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index e4900df..dee73a6 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
static int debug;
module_param(debug, int, 0644);
@@ -59,6 +60,8 @@ MODULE_LICENSE("GPL v2");
#define ADV7511_MIN_PIXELCLOCK 2000
#define ADV7511_MAX_PIXELCLOCK 22500
+#define ADV7511_MAX_ADDRS (3)
+
/*
**
*
@@ -90,12 +93,19 @@ struct adv7511_state {
struct v4l2_ctrl_handler hdl;
int chip_revision;
u8 i2c_edid_addr;
- u8 i2c_cec_addr;
u8 i2c_pktmem_addr;
+ u8 i2c_cec_addr;
+
+ struct i2c_client *i2c_cec;
+ u8 cec_addr[ADV7511_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
+
/* Is the adv7511 powered on? */
bool power_on;
/* Did we receive hotplug and rx-sense signals? */
bool have_monitor;
+ bool enabled_irq;
/* timings from s_dv_timings */
struct v4l2_dv_timings dv_timings;
u32 fmt_code;
@@ -225,7 +235,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client
*client,
return ret;
}
-static inline void adv7511_edid_rd(struct v4l2_subdev *sd, u16 len, u8 *buf)
+static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf)
{
struct adv7511_state *state = get_adv7511_state(sd);
int i;
@@ -240,6 +250,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd,
u16 len, u8 *buf)
v4l2_err(sd, "%s: i2c read error\n", __func__);
}
+static inline int adv7511_cec_read(struct v4l2_subdev *sd, u8 reg)
+{
+ struct adv7511_state *state = get_adv7511_state(sd);
+
+ return i2c_smbus_read_byte_data(state->i2c_cec, reg);
+}
+
+static int adv7511_cec_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+ struct adv7511_state *state = get_adv7511_state(sd);
+ int ret;
+ int i;
+
+ for (i = 0; i < 3; i++) {
+ ret = i2c_smbus_write_byte_data(state->i2c_cec, reg, val);
+ if (ret == 0)
+ return 0;
+ }
+ v4l2_err(sd, "%s: I2C Write Problem\n", __func__);
+ return ret;
+}
+
+static inline int adv7511_cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8
mask,
+ u8 val)
+{
+ return adv7511_cec_write(sd, reg, (adv7511_cec_read(sd, reg) & mask) |
val);
+}
+
static int adv7511_pktmem_rd(struct v4l2_subdev *sd, u8 reg)
{
struct adv7511_state *state = get_adv7511_state(sd);
@@ -413,16 +451,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = {
#ifdef CONFIG_VIDEO_ADV_DEBUG
static void adv7511_inv_register(struct v4l2_subdev *sd)
{
+ struct adv7511_state *state = get_adv7511_state(sd);
+
v4l2_info(sd, "0x000-0x0ff: Main Map\n");
+ if (state->i2c_cec)
+ v4l2_info(sd, "0x100-0x1ff: CEC Map\n");
}
static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg)
{
+ struct adv7511_state *state = get_adv7511_state(sd);
+
reg->size = 1;
switch (reg->reg >> 8) {
case 0:
reg->val = adv7511_rd(sd, reg->reg & 0xff);
break;
+ case 1:
+ if (state->i2c_cec) {
+ reg->val = adv7511_cec_read(sd, reg->reg & 0xff);
+ break;
+ }
+ /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -433,10 +483,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd,
struct v4l2_dbg_register *
static int adv7511_s_register(struct v4l2_subdev *sd, const struct
v4l2_dbg_register *reg)
{
+ struct adv7511_state *state = get_adv7511_state(sd);
+
switch (reg->reg >> 8) {
case 0:
adv7511_wr(sd, reg->reg & 0xff, reg->val & 0xff);
break;
+ case 1:
+ if (state->i2c_cec) {
+ adv7511_cec_write(sd, reg->reg & 0xff, reg->val & 0xff);
+ break;
+ }
+ /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -524,6 +582,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
{
struct adv7511_state *state = get_adv7511_state(sd);
Re: [PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem
Hi Marek, On 10 November 2015 at 13:23, Marek Szyprowski wrote: > This patch series introduces a new life into Exynos IPP (Image Post > Processing) subsystem by integrating it (transparently for userspace > applications) with Exynos DRM core plane management. This means that all > CRTC drivers transparently get support for standard features of IPP > subsystem like rotation and scaling. > > Support for features not supported natively by CRTC drivers is > implemented with a help of temporary framebuffers, where image data is > processed by IPP subsystem before performing the scanout by a CRTC driver. > > This patchset is a first version of this 'new feature' and I would like > get some comments on the proposed approach. I plan to continue working > on enhancing Exynos DRM drivers and especially do the cleanup the IPP > subsystem. > > Most of the new features are added by the last 2 patches. All other > patches are bugfixes in various Exynos DRM subdrivers and significant > core rewrite - introducing a subclass of drm_plane_state was needed and > all drivers have been converted to use it. Some initial cleanups in IPP > subsystem were also needed to let Exynos core to call it internally from > the driver core. This part will be cleaned even more in the future. Hm, interesting. The RPi has a similar setup - VC4 can work either online (realtime scanout) or offline (mem2mem). Once the scene crosses a certain complexity boundary, it can no longer be composed in realtime and must fall back to mem2mem before it can be displayed. There was talk of having the fallback handled transparently in KMS for VC4 - similar to this - but the conclusion seemed to be that it was an inappropriate level of hidden complexity for KMS, and instead would best be handled by something like HWComposer directing it. Using HWC would then let you more intelligently split the scene from userspace (e.g. flatten some components but retain others as active planes). Dan V, Eric - thoughts? Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
