Re: [PATCH 1/2] drm/exynos: depend on COMMON_CLK to fix compile tests

[Inki Dae]

HI Krzysztof,

20. 11. 17. 오전 2:53에 Krzysztof Kozlowski 이(가) 쓴 글:
> The Exynos DRM uses Common Clock Framework thus it cannot be built on
> platforms without it (e.g. compile test on MIPS with RALINK and
> SOC_RT305X):
> 
> /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in 
> function `mixer_bind':
> exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent'
> 
> Reported-by: kernel test robot 
> Signed-off-by: Krzysztof Kozlowski 

Picked it up.

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 6417f374b923..951d5f708e92 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -1,7 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config DRM_EXYNOS
>   tristate "DRM Support for Samsung SoC Exynos Series"
> - depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
> ARCH_MULTIPLATFORM || COMPILE_TEST)
> + depends on OF && DRM && COMMON_CLK
> + depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
> ARCH_MULTIPLATFORM || COMPILE_TEST
>   depends on MMU
>   select DRM_KMS_HELPER
>   select VIDEOMODE_HELPERS
> 

Re: [PATCH 14/18] drm/exynos: Consolidate IOMMU mapping code

[Inki Dae]

20. 8. 21. 오전 12:08에 Robin Murphy 이(가) 쓴 글:
> Now that arch/arm is wired up for default domains and iommu-dma, we can
> consolidate the shared mapping code onto the generic IOMMU API version,
> and retire the arch-specific implementation.
> 
> Signed-off-by: Robin Murphy 
> 
> ---
> This is a cheeky revert of 07dc3678bacc ("drm/exynos: Fix cleanup of
> IOMMU related objects"), plus removal of the remaining arm_iommu_*
> references on top.

Thanks for cleanup.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  5 +-
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_dma.c   | 61 +++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  6 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   |  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  5 +-
>  drivers/gpu/drm/exynos/exynos_drm_scaler.c|  6 +-
>  drivers/gpu/drm/exynos/exynos_mixer.c |  7 +--
>  11 files changed, 29 insertions(+), 86 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 1f79bc2a881e..8428ae12dfa5 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -55,7 +55,6 @@ static const char * const decon_clks_name[] = {
>  struct decon_context {
>   struct device   *dev;
>   struct drm_device   *drm_dev;
> - void*dma_priv;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[WINDOWS_NR];
>   struct exynos_drm_plane_config  configs[WINDOWS_NR];
> @@ -645,7 +644,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>  
>   decon_clear_channels(ctx->crtc);
>  
> - return exynos_drm_register_dma(drm_dev, dev, >dma_priv);
> + return exynos_drm_register_dma(drm_dev, dev);
>  }
>  
>  static void decon_unbind(struct device *dev, struct device *master, void 
> *data)
> @@ -655,7 +654,7 @@ static void decon_unbind(struct device *dev, struct 
> device *master, void *data)
>   decon_atomic_disable(ctx->crtc);
>  
>   /* detach this sub driver from iommu mapping if supported. */
> - exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev, >dma_priv);
> + exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev);
>  }
>  
>  static const struct component_ops decon_component_ops = {
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index f2d87a7445c7..e7b58097ccdc 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -40,7 +40,6 @@
>  struct decon_context {
>   struct device   *dev;
>   struct drm_device   *drm_dev;
> - void*dma_priv;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[WINDOWS_NR];
>   struct exynos_drm_plane_config  configs[WINDOWS_NR];
> @@ -128,13 +127,13 @@ static int decon_ctx_initialize(struct decon_context 
> *ctx,
>  
>   decon_clear_channels(ctx->crtc);
>  
> - return exynos_drm_register_dma(drm_dev, ctx->dev, >dma_priv);
> + return exynos_drm_register_dma(drm_dev, ctx->dev);
>  }
>  
>  static void decon_ctx_remove(struct decon_context *ctx)
>  {
>   /* detach this sub driver from iommu mapping if supported. */
> - exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev, >dma_priv);
> + exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev);
>  }
>  
>  static u32 decon_calc_clkdiv(struct decon_context *ctx,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dma.c
> index 58b89ec11b0e..fd5f9bcf1857 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
> @@ -14,19 +14,6 @@
>  
>  #include "exynos_drm_drv.h"
>  
> -#if defined(CONFIG_ARM_DMA_USE_IOMMU)
> -#include 
> -#else
> -#define arm_iommu_create_mapping(...)({ NULL; })
> -#define arm_iommu_attach_device(...) ({ -ENODEV; })
> -#define arm_iommu_release_mapping(...)   ({ })
> -#define arm_iommu_detach_device(...) ({ })
> -#define to_dma_iommu_mapping(dev) NULL
> -#endif
> -
> -#if !defined(CONFIG_IOMMU_DMA)
> -#define

Re: [PATCH v7 07/36] drm: exynos: use common helper for a scatterlist contiguity check

[Inki Dae]

20. 6. 19. 오후 7:36에 Marek Szyprowski 이(가) 쓴 글:
> Use common helper for checking the contiguity of the imported dma-buf.
> 
> Signed-off-by: Marek Szyprowski 

Acked-by : Inki Dae 

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +++
>  1 file changed, 3 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index efa476858db5..1716a023bca0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -431,27 +431,10 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device 
> *dev,
>  {
>   struct exynos_drm_gem *exynos_gem;
>  
> - if (sgt->nents < 1)
> + /* check if the entries in the sg_table are contiguous */
> + if (drm_prime_get_contiguous_size(sgt) < attach->dmabuf->size) {
> + DRM_ERROR("buffer chunks must be mapped contiguously");
>   return ERR_PTR(-EINVAL);
> -
> - /*
> -  * Check if the provided buffer has been mapped as contiguous
> -  * into DMA address space.
> -  */
> - if (sgt->nents > 1) {
> - dma_addr_t next_addr = sg_dma_address(sgt->sgl);
> - struct scatterlist *s;
> - unsigned int i;
> -
> - for_each_sg(sgt->sgl, s, sgt->nents, i) {
> - if (!sg_dma_len(s))
> - break;
> - if (sg_dma_address(s) != next_addr) {
> - DRM_ERROR("buffer chunks must be mapped 
> contiguously");
> - return ERR_PTR(-EINVAL);
> - }
> - next_addr = sg_dma_address(s) + sg_dma_len(s);
> - }
>   }
>  
>   exynos_gem = exynos_drm_gem_init(dev, attach->dmabuf->size);
> 

Re: [PATCH v7 08/36] drm: exynos: fix common struct sg_table related issues

[Inki Dae]

20. 6. 19. 오후 7:36에 Marek Szyprowski 이(가) 쓴 글:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
> 
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
> 
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
> 
> To avoid such issues, lets use a common dma-mapping wrappers operating
> directly on the struct sg_table objects and use scatterlist page
> iterators where possible. This, almost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
> 
> Signed-off-by: Marek Szyprowski 

Acked-by : Inki Dae 

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index fcee33a43aca..7014a8cd971a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -395,8 +395,8 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
>   return;
>  
>  out:
> - dma_unmap_sg(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt->sgl,
> - g2d_userptr->sgt->nents, DMA_BIDIRECTIONAL);
> + dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt,
> +   DMA_BIDIRECTIONAL, 0);
>  
>   pages = frame_vector_pages(g2d_userptr->vec);
>   if (!IS_ERR(pages)) {
> @@ -511,10 +511,10 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
> g2d_data *g2d,
>  
>   g2d_userptr->sgt = sgt;
>  
> - if (!dma_map_sg(to_dma_dev(g2d->drm_dev), sgt->sgl, sgt->nents,
> - DMA_BIDIRECTIONAL)) {
> + ret = dma_map_sgtable(to_dma_dev(g2d->drm_dev), sgt,
> +   DMA_BIDIRECTIONAL, 0);
> + if (ret) {
>   DRM_DEV_ERROR(g2d->dev, "failed to map sgt with dma region.\n");
> - ret = -ENOMEM;
>   goto err_sg_free_table;
>   }
>  
> 

Re: [PATCH v2] drm/exynos: fix ref count leak in mic_pre_enable

[Inki Dae]

20. 6. 15. 오후 2:49에 Navid Emamdoost 이(가) 쓴 글:
> in mic_pre_enable, pm_runtime_get_sync is called which
> increments the counter even in case of failure, leading to incorrect
> ref count. In case of failure, decrement the ref count before returning.
> 
> Signed-off-by: Navid Emamdoost 
> ---
> Changes in v2:
>   - reuse the unlock label and call pm_runtime_put_noidle

Picked it up.

Thanks,
Inki Dae

> ---
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a86abc173605..3821ea76a703 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -269,8 +269,10 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>   goto unlock;
>  
>   ret = pm_runtime_get_sync(mic->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_noidle(mic->dev);
>   goto unlock;
> + }
>  
>   mic_set_path(mic, 1);
>  
> 

Re: [PATCH] drm/exynos: fix ref count leak in mic_pre_enable

[Inki Dae]

Hi,

20. 6. 14. 오후 3:23에 Navid Emamdoost 이(가) 쓴 글:
> in mic_pre_enable, pm_runtime_get_sync is called which
> increments the counter even in case of failure, leading to incorrect
> ref count. In case of failure, decrement the ref count before returning.
> 
> Signed-off-by: Navid Emamdoost 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a86abc173605..69ff74c2ceb5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -270,7 +270,7 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>  
>   ret = pm_runtime_get_sync(mic->dev);
>   if (ret < 0)
> - goto unlock;
> + goto turn_off;

How about just calling pm_runtime_put_noidle()?

if (ret < 0) {
pm_runtime_put_noidle(mic->dev);
goto unlock;
}

Thanks,
Inki Dae

>  
>   mic_set_path(mic, 1);
>  
> 

Re: [PATCH v3] drm/exynos: Remove dev_err() on platform_get_irq() failure

[Inki Dae]

20. 5. 21. 오후 11:22에 Tamseel Shams 이(가) 쓴 글:
> platform_get_irq() will call dev_err() itself on failure,
> so there is no need for the driver to also do this.
> This is detected by coccinelle.

Picked it up.

Thanks,
Inki Dae

> 
> Signed-off-by: Tamseel Shams 
> ---
> - Changes since v2:
> * Addressed Inki Dae comments
> 
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index fcee33a43aca..03be31427181 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1498,7 +1498,6 @@ static int g2d_probe(struct platform_device *pdev)
>  
>   g2d->irq = platform_get_irq(pdev, 0);
>   if (g2d->irq < 0) {
> - dev_err(dev, "failed to get irq\n");
>   ret = g2d->irq;
>   goto err_put_clk;
>   }
> 

Re: [PATCH v2] drm/exynos: Remove dev_err() on platform_get_irq() failure

[Inki Dae]

Hi Tamseel,

Same patch[1] has been merged. So could you re-post this patch after rebasing 
it on top of exynos-drm-next branch?
After rebase, only g2d part would be valid.

Thanks,
Inki Dae

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-next=fdd79b0db1899f915f489e744a06846284fa3f1e

20. 5. 19. 오후 7:49에 Tamseel Shams 이(가) 쓴 글:
> platform_get_irq() will call dev_err() itself on failure,
> so there is no need for the driver to also do this.
> This is detected by coccinelle.
> 
> Also removing unnecessary curly braces around if () statement.
> 
> Signed-off-by: Tamseel Shams 
> ---
> Fixed review comment by j...@perches.com
> 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 -
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +---
>  drivers/gpu/drm/exynos/exynos_drm_scaler.c  | 4 +---
>  4 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 902938d2568f..958e2c6a6702 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1809,10 +1809,8 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   }
>  
>   dsi->irq = platform_get_irq(pdev, 0);
> - if (dsi->irq < 0) {
> - dev_err(dev, "failed to request dsi irq resource\n");
> + if (dsi->irq < 0)
>   return dsi->irq;
> - }
>  
>   irq_set_status_flags(dsi->irq, IRQ_NOAUTOEN);
>   ret = devm_request_threaded_irq(dev, dsi->irq, NULL,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index fcee33a43aca..03be31427181 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1498,7 +1498,6 @@ static int g2d_probe(struct platform_device *pdev)
>  
>   g2d->irq = platform_get_irq(pdev, 0);
>   if (g2d->irq < 0) {
> - dev_err(dev, "failed to get irq\n");
>   ret = g2d->irq;
>   goto err_put_clk;
>   }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index dafa87b82052..2d94afba031e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -293,10 +293,8 @@ static int rotator_probe(struct platform_device *pdev)
>   return PTR_ERR(rot->regs);
>  
>   irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> + if (irq < 0)
>   return irq;
> - }
>  
>   ret = devm_request_irq(dev, irq, rotator_irq_handler, 0, dev_name(dev),
>  rot);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c 
> b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> index 93c43c8d914e..ce1857138f89 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> @@ -502,10 +502,8 @@ static int scaler_probe(struct platform_device *pdev)
>   return PTR_ERR(scaler->regs);
>  
>   irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> + if (irq < 0)
>   return irq;
> - }
>  
>   ret = devm_request_threaded_irq(dev, irq, NULL, scaler_irq_handler,
>   IRQF_ONESHOT, "drm_scaler", scaler);
> 

Re: [PATCH v2] drm/exynos: dsi: Remove bridge node reference in error handling path in probe function

[Inki Dae]

20. 5. 16. 오후 7:57에 Christophe JAILLET 이(가) 쓴 글:
> 'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'.
> This must be released in the error handling path.

Picked it up.

Thanks,
Inki Dae

> 
> In order to do that, add an error handling path and move the
> 'exynos_dsi_parse_dt()' call from the beginning to the end of the probe
> function to ease the error handling path.
> This function only sets some variables which are used only in the
> 'transfer' function.
> 
> The call chain is:
>.transfer
> --> exynos_dsi_host_transfer
>   --> exynos_dsi_init
> --> exynos_dsi_enable_clock  (use burst_clk_rate and esc_clk_rate)
>   --> exynos_dsi_set_pll (use pll_clk_rate)
> 
> While at it, also handle cases where 'component_add()' fails.
> 
> This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge 
> node reference in removal")
> which fixed the issue in the remove function.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> A Fixes tag could be required, but I've not been able to figure out which
> one to use.
> 
> v2: move around 'exynos_dsi_parse_dt' instead of adding many gotos
> handle component_add failures
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 902938d2568f..a9d24402fabf 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1759,10 +1759,6 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   dsi->dev = dev;
>   dsi->driver_data = of_device_get_match_data(dev);
>  
> - ret = exynos_dsi_parse_dt(dsi);
> - if (ret)
> - return ret;
> -
>   dsi->supplies[0].supply = "vddcore";
>   dsi->supplies[1].supply = "vddio";
>   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
> @@ -1823,11 +1819,25 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> + ret = exynos_dsi_parse_dt(dsi);
> + if (ret)
> + return ret;
> +
>   platform_set_drvdata(pdev, >encoder);
>  
>   pm_runtime_enable(dev);
>  
> - return component_add(dev, _dsi_component_ops);
> + ret = component_add(dev, _dsi_component_ops);
> + if (ret)
> + goto err_disable_runtime;
> +
> + return 0;
> +
> +err_disable_runtime:
> + pm_runtime_disable(dev);
> + of_node_put(dsi->in_bridge_node);
> +
> + return ret;
>  }
>  
>  static int exynos_dsi_remove(struct platform_device *pdev)
> 

Re: [PATCH] drm/exynos: dsi: Remove bridge node reference in error handling path in probe function

[Inki Dae]

Hi,

20. 5. 11. 오전 12:48에 Christophe JAILLET 이(가) 쓴 글:
> 'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'.
> This must be released in the error handling path.
> 
> This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge 
> node reference in removal")
> which fixed the issue in the remove function.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> A Fixes tag could be required, but I've not been able to figure out which
> one to use.
> 
> I think that moving 'exynos_dsi_parse_dt()' in the probe could simplify
> the error handling in the probe function. However, I don't know this code
> well enough to play this game. So better safe than sorry.
> So I've kept the logic in place and added goto everywhere. :(

You could move exynos_dsi_parse_dt() call to the end of the probe function to 
handle the error simply.
dsi->in_bridge_node is accessed in bind function and the probe function is 
called before the bind call.

Could you rework and post it again?

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 28 ++---
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 902938d2568f..2aa74c3dc733 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1770,14 +1770,17 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   if (ret) {
>   if (ret != -EPROBE_DEFER)
>   dev_info(dev, "failed to get regulators: %d\n", ret);
> - return ret;
> + goto err_put_in_bridge_node;
>   }
>  
>   dsi->clks = devm_kcalloc(dev,
>   dsi->driver_data->num_clks, sizeof(*dsi->clks),
>   GFP_KERNEL);
> - if (!dsi->clks)
> - return -ENOMEM;
> + if (!dsi->clks) {
> + ret = -ENOMEM;
> + goto err_put_in_bridge_node;
> + }
> +
>  
>   for (i = 0; i < dsi->driver_data->num_clks; i++) {
>   dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
> @@ -1791,7 +1794,8 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>  
>   dev_info(dev, "failed to get the clock: %s\n",
>   clk_names[i]);
> - return PTR_ERR(dsi->clks[i]);
> + ret = PTR_ERR(dsi->clks[i]);
> + goto err_put_in_bridge_node;
>   }
>   }
>  
> @@ -1799,19 +1803,22 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   dsi->reg_base = devm_ioremap_resource(dev, res);
>   if (IS_ERR(dsi->reg_base)) {
>   dev_err(dev, "failed to remap io region\n");
> - return PTR_ERR(dsi->reg_base);
> + ret = PTR_ERR(dsi->reg_base);
> + goto err_put_in_bridge_node;
>   }
>  
>   dsi->phy = devm_phy_get(dev, "dsim");
>   if (IS_ERR(dsi->phy)) {
>   dev_info(dev, "failed to get dsim phy\n");
> - return PTR_ERR(dsi->phy);
> + ret = PTR_ERR(dsi->phy);
> + goto err_put_in_bridge_node;
>   }
>  
>   dsi->irq = platform_get_irq(pdev, 0);
>   if (dsi->irq < 0) {
>   dev_err(dev, "failed to request dsi irq resource\n");
> - return dsi->irq;
> + ret = dsi->irq;
> + goto err_put_in_bridge_node;
>   }
>  
>   irq_set_status_flags(dsi->irq, IRQ_NOAUTOEN);
> @@ -1820,7 +1827,7 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   dev_name(dev), dsi);
>   if (ret) {
>   dev_err(dev, "failed to request dsi irq\n");
> - return ret;
> + goto err_put_in_bridge_node;
>   }
>  
>   platform_set_drvdata(pdev, >encoder);
> @@ -1828,6 +1835,11 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   pm_runtime_enable(dev);
>  
>   return component_add(dev, _dsi_component_ops);
> +
> +err_put_in_bridge_node:
> + of_node_put(dsi->in_bridge_node);
> +
> + return ret;
>  }
>  
>  static int exynos_dsi_remove(struct platform_device *pdev)
> 

Re: ERROR: "vmf_insert_mixed" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!

[Inki Dae]

Hi,

19. 7. 25. 오전 7:35에 kbuild test robot 이(가) 쓴 글:
> tree:   
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   bed38c3e2dca01b358a62b5e73b46e875742fd75
> commit: 156bdac99061b4013c8e47799c6e574f7f84e9f4 drm/exynos: trigger build of 
> all modules
> date:   4 weeks ago
> config: h8300-allmodconfig (attached as .config)
> compiler: h8300-linux-gcc (GCC) 7.4.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 156bdac99061b4013c8e47799c6e574f7f84e9f4
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=h8300 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
> 
> All errors (new ones prefixed by >>):
> 
>>> ERROR: "vmf_insert_mixed" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!

With below patch I think the build error reported already will be fixed,
https://patchwork.kernel.org/patch/11035147/

Thanks,
Inki Dae

> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

Re: [PATCH 1/6] include/drm: color_mgmt: Add enum labels

[Inki Dae]

Hi,

18. 12. 14. 오후 9:10에 Christoph Manszewski 이(가) 쓴 글:
> Range setting makes sense for YCbCr and RGB buffers. Current
> drm_color_range enum labels suggest use with YCbCr buffers.
> Create enum labels without colorspace specification.
> 
> Signed-off-by: Christoph Manszewski 
> ---
>  include/drm/drm_color_mgmt.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 90ef9996d9a4..52f6d5221a0d 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -62,6 +62,8 @@ enum drm_color_range {
>   DRM_COLOR_YCBCR_LIMITED_RANGE,
>   DRM_COLOR_YCBCR_FULL_RANGE,
>   DRM_COLOR_RANGE_MAX,
> + DRM_COLOR_LIMITED_RANGE = DRM_COLOR_YCBCR_LIMITED_RANGE,
> + DRM_COLOR_FULL_RANGE = DRM_COLOR_YCBCR_FULL_RANGE,

I don't see why above two types are needed. Is there any case that the range 
checking behavior should be different according to the color space?
And even if there is that case, I think you have to put DRM_COLOR_RANG_MAX 
under DRM_COLOR_FULL_RANGE.

Thanks,
Inki Dae

>  };
>  
>  int drm_plane_create_color_properties(struct drm_plane *plane,
> 

Re: [PATCH 1/3] drm/exynos: rotator: Add support for s5pv210

[Inki Dae]

18. 12. 20. 오전 12:57에 Paweł Chmiel 이(가) 쓴 글:
> This commit adds support for s5pv210.
> Currently only NV12 and XRGB formats are supported.
> It was tested by using tool from
> https://www.spinics.net/lists/linux-samsung-soc/msg60498.html
> 
> Signed-off-by: Paweł Chmiel 
Applied.

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c | 23 +
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index a820a68429b9..a822d340ccf6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -357,6 +357,11 @@ static int rotator_runtime_resume(struct device *dev)
>  }
>  #endif
>  
> +static const struct drm_exynos_ipp_limit rotator_s5pv210_rbg888_limits[] = {
> + { IPP_SIZE_LIMIT(BUFFER, .h = { 8, SZ_16K }, .v = { 8, SZ_16K }) },
> + { IPP_SIZE_LIMIT(AREA, .h.align = 2, .v.align = 2) },
> +};
> +
>  static const struct drm_exynos_ipp_limit rotator_4210_rbg888_limits[] = {
>   { IPP_SIZE_LIMIT(BUFFER, .h = { 8, SZ_16K }, .v = { 8, SZ_16K }) },
>   { IPP_SIZE_LIMIT(AREA, .h.align = 4, .v.align = 4) },
> @@ -372,6 +377,11 @@ static const struct drm_exynos_ipp_limit 
> rotator_5250_rbg888_limits[] = {
>   { IPP_SIZE_LIMIT(AREA, .h.align = 2, .v.align = 2) },
>  };
>  
> +static const struct drm_exynos_ipp_limit rotator_s5pv210_yuv_limits[] = {
> + { IPP_SIZE_LIMIT(BUFFER, .h = { 32, SZ_64K }, .v = { 32, SZ_64K }) },
> + { IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
> +};
> +
>  static const struct drm_exynos_ipp_limit rotator_4210_yuv_limits[] = {
>   { IPP_SIZE_LIMIT(BUFFER, .h = { 32, SZ_64K }, .v = { 32, SZ_64K }) },
>   { IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
> @@ -382,6 +392,11 @@ static const struct drm_exynos_ipp_limit 
> rotator_4412_yuv_limits[] = {
>   { IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
>  };
>  
> +static const struct exynos_drm_ipp_formats rotator_s5pv210_formats[] = {
> + { IPP_SRCDST_FORMAT(XRGB, rotator_s5pv210_rbg888_limits) },
> + { IPP_SRCDST_FORMAT(NV12, rotator_s5pv210_yuv_limits) },
> +};
> +
>  static const struct exynos_drm_ipp_formats rotator_4210_formats[] = {
>   { IPP_SRCDST_FORMAT(XRGB, rotator_4210_rbg888_limits) },
>   { IPP_SRCDST_FORMAT(NV12, rotator_4210_yuv_limits) },
> @@ -397,6 +412,11 @@ static const struct exynos_drm_ipp_formats 
> rotator_5250_formats[] = {
>   { IPP_SRCDST_FORMAT(NV12, rotator_4412_yuv_limits) },
>  };
>  
> +static const struct rot_variant rotator_s5pv210_data = {
> + .formats = rotator_s5pv210_formats,
> + .num_formats = ARRAY_SIZE(rotator_s5pv210_formats),
> +};
> +
>  static const struct rot_variant rotator_4210_data = {
>   .formats = rotator_4210_formats,
>   .num_formats = ARRAY_SIZE(rotator_4210_formats),
> @@ -414,6 +434,9 @@ static const struct rot_variant rotator_5250_data = {
>  
>  static const struct of_device_id exynos_rotator_match[] = {
>   {
> + .compatible = "samsung,s5pv210-rotator",
> + .data = _s5pv210_data,
> + }, {
>   .compatible = "samsung,exynos4210-rotator",
>   .data = _4210_data,
>   }, {
> 

Re: [PATCH v3 1/9] drm/exynos: rename "bridge_node" to "mic_bridge_node"

[Inki Dae]

2018년 07월 25일 17:11에 Andrzej Hajda 이(가) 쓴 글:
> On 24.07.2018 09:49, Inki Dae wrote:
>> Hi,
>>
>> 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
>>> When adding support for peripheral out bridges, the "bridge" name
>>> becomes imprecise as it refers to a different device than the
>>> "out_bridge".
>> Could you give me more details? I'm afriad that I don't understand what you 
>> say.
> 
> The problem is that MIC is an input bridge and now we will have also
> output bridge (Toshiba DSI/LVDS converter).
> So we will have to distinguish them.
> 
>>
>> And in case of Exynos5433 SoC, SMIES(Samsung Mobile Image Enhancement 
>> System) can be located between DECON and MIPI-DSI devices also.
>> Therefore, having specific name isn't reasonable.
> 
> So probably in_bridge would be a better name. I will rephrase message
> and bridge name.

Good idea. :)

Thanks,
Inki Dae

> 
> Regars
> Andrzej
> 
> 
>>
>> Thanks,
>> Inki Dae
>>
>>> Signed-off-by: Maciej Purski 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 
>>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index eae44fd..9599e6b 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -279,7 +279,7 @@ struct exynos_dsi {
>>> struct list_head transfer_list;
>>>  
>>> const struct exynos_dsi_driver_data *driver_data;
>>> -   struct device_node *bridge_node;
>>> +   struct device_node *mic_bridge_node;
>>>  };
>>>  
>>>  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>>> @@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>>> if (ret < 0)
>>> return ret;
>>>  
>>> -   dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>>> +   dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>>>  
>>> return 0;
>>>  }
>>> @@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
>>> device *master,
>>> struct drm_encoder *encoder = dev_get_drvdata(dev);
>>> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>>> struct drm_device *drm_dev = data;
>>> -   struct drm_bridge *bridge;
>>> +   struct drm_bridge *mic_bridge;
>>> int ret;
>>>  
>>> drm_encoder_init(drm_dev, encoder, _dsi_encoder_funcs,
>>> @@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, 
>>> struct device *master,
>>> return ret;
>>> }
>>>  
>>> -   if (dsi->bridge_node) {
>>> -   bridge = of_drm_find_bridge(dsi->bridge_node);
>>> -   if (bridge)
>>> -   drm_bridge_attach(encoder, bridge, NULL);
>>> +   if (dsi->mic_bridge_node) {
>>> +   mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
>>> +   if (mic_bridge)
>>> +   drm_bridge_attach(encoder, mic_bridge, NULL);
>>> }
>>>  
>>> return mipi_dsi_host_register(>dsi_host);
>>> @@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device 
>>> *pdev)
>>>  {
>>> struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>>>  
>>> -   of_node_put(dsi->bridge_node);
>>> +   of_node_put(dsi->mic_bridge_node);
>>>  
>>> pm_runtime_disable(>dev);
>>>  
>>>
>> --
>> 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
>>
>>
> 
> --
> 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 v3 1/9] drm/exynos: rename "bridge_node" to "mic_bridge_node"

[Inki Dae]

2018년 07월 25일 17:11에 Andrzej Hajda 이(가) 쓴 글:
> On 24.07.2018 09:49, Inki Dae wrote:
>> Hi,
>>
>> 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
>>> When adding support for peripheral out bridges, the "bridge" name
>>> becomes imprecise as it refers to a different device than the
>>> "out_bridge".
>> Could you give me more details? I'm afriad that I don't understand what you 
>> say.
> 
> The problem is that MIC is an input bridge and now we will have also
> output bridge (Toshiba DSI/LVDS converter).
> So we will have to distinguish them.
> 
>>
>> And in case of Exynos5433 SoC, SMIES(Samsung Mobile Image Enhancement 
>> System) can be located between DECON and MIPI-DSI devices also.
>> Therefore, having specific name isn't reasonable.
> 
> So probably in_bridge would be a better name. I will rephrase message
> and bridge name.

Good idea. :)

Thanks,
Inki Dae

> 
> Regars
> Andrzej
> 
> 
>>
>> Thanks,
>> Inki Dae
>>
>>> Signed-off-by: Maciej Purski 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 
>>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index eae44fd..9599e6b 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -279,7 +279,7 @@ struct exynos_dsi {
>>> struct list_head transfer_list;
>>>  
>>> const struct exynos_dsi_driver_data *driver_data;
>>> -   struct device_node *bridge_node;
>>> +   struct device_node *mic_bridge_node;
>>>  };
>>>  
>>>  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>>> @@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>>> if (ret < 0)
>>> return ret;
>>>  
>>> -   dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>>> +   dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>>>  
>>> return 0;
>>>  }
>>> @@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
>>> device *master,
>>> struct drm_encoder *encoder = dev_get_drvdata(dev);
>>> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>>> struct drm_device *drm_dev = data;
>>> -   struct drm_bridge *bridge;
>>> +   struct drm_bridge *mic_bridge;
>>> int ret;
>>>  
>>> drm_encoder_init(drm_dev, encoder, _dsi_encoder_funcs,
>>> @@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, 
>>> struct device *master,
>>> return ret;
>>> }
>>>  
>>> -   if (dsi->bridge_node) {
>>> -   bridge = of_drm_find_bridge(dsi->bridge_node);
>>> -   if (bridge)
>>> -   drm_bridge_attach(encoder, bridge, NULL);
>>> +   if (dsi->mic_bridge_node) {
>>> +   mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
>>> +   if (mic_bridge)
>>> +   drm_bridge_attach(encoder, mic_bridge, NULL);
>>> }
>>>  
>>> return mipi_dsi_host_register(>dsi_host);
>>> @@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device 
>>> *pdev)
>>>  {
>>> struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>>>  
>>> -   of_node_put(dsi->bridge_node);
>>> +   of_node_put(dsi->mic_bridge_node);
>>>  
>>> pm_runtime_disable(>dev);
>>>  
>>>
>> --
>> 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
>>
>>
> 
> --
> 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 for v3.18 00/18] Backport CVE-2017-13166 fixes to Kernel 3.18

[Inki Dae]

2018년 03월 29일 16:00에 Greg KH 이(가) 쓴 글:
> On Thu, Mar 29, 2018 at 03:39:54PM +0900, Inki Dae wrote:
>> 2018년 03월 29일 13:25에 Greg KH 이(가) 쓴 글:
>>> On Thu, Mar 29, 2018 at 08:22:08AM +0900, Inki Dae wrote:
>>>> Really thanks for doing this. :) There would be many users who use
>>>> Linux-3.18 for their products yet.
>>>
>>> For new products?  They really should not be.  The kernel is officially
>>
>> Really no. Old products would still be using Linux-3.18 kernel without
>> kernel upgrade. For new product, most of SoC vendors will use
>> Linux-4.x including us.
>> Actually, we are preparing for kernel upgrade for some devices even
>> some old devices (to Linux-4.14-LTS) and almost done.
> 
> That is great to hear.
> 
>>> What is keeping you on 3.18.y and not allowing you to move to a newer
>>> kernel version?
>>
>> We also want to move to latest kernel version. However, there is a case that 
>> we cannot upgrade the kernel.
>> In case that SoC vendor never share firmwares and relevant data
>> sheets, we cannot upgrade the kernel. However, we have to resolve the
>> security issues for users of this device.
> 
> It sounds like you need to be getting those security updates from those
> SoC vendors, as they are the ones you are paying for support for that

It's true but some open source developers like me who use vendor kernel without 
vendor's support will never get the security updates from them.
So if you merge CVE patches even through this kernel is already EOL then many 
open source developers would be glad. :)

Thanks,
Inki Dae

> kernel version that they are forcing you to stay on.
> 
> good luck!
> 
> greg k-h
> 
> 
> 

Re: [PATCH for v3.18 00/18] Backport CVE-2017-13166 fixes to Kernel 3.18

[Inki Dae]

2018년 03월 29일 16:00에 Greg KH 이(가) 쓴 글:
> On Thu, Mar 29, 2018 at 03:39:54PM +0900, Inki Dae wrote:
>> 2018년 03월 29일 13:25에 Greg KH 이(가) 쓴 글:
>>> On Thu, Mar 29, 2018 at 08:22:08AM +0900, Inki Dae wrote:
>>>> Really thanks for doing this. :) There would be many users who use
>>>> Linux-3.18 for their products yet.
>>>
>>> For new products?  They really should not be.  The kernel is officially
>>
>> Really no. Old products would still be using Linux-3.18 kernel without
>> kernel upgrade. For new product, most of SoC vendors will use
>> Linux-4.x including us.
>> Actually, we are preparing for kernel upgrade for some devices even
>> some old devices (to Linux-4.14-LTS) and almost done.
> 
> That is great to hear.
> 
>>> What is keeping you on 3.18.y and not allowing you to move to a newer
>>> kernel version?
>>
>> We also want to move to latest kernel version. However, there is a case that 
>> we cannot upgrade the kernel.
>> In case that SoC vendor never share firmwares and relevant data
>> sheets, we cannot upgrade the kernel. However, we have to resolve the
>> security issues for users of this device.
> 
> It sounds like you need to be getting those security updates from those
> SoC vendors, as they are the ones you are paying for support for that

It's true but some open source developers like me who use vendor kernel without 
vendor's support will never get the security updates from them.
So if you merge CVE patches even through this kernel is already EOL then many 
open source developers would be glad. :)

Thanks,
Inki Dae

> kernel version that they are forcing you to stay on.
> 
> good luck!
> 
> greg k-h
> 
> 
> 

Re: [PATCH for v3.18 00/18] Backport CVE-2017-13166 fixes to Kernel 3.18

[Inki Dae]

2018년 03월 29일 13:25에 Greg KH 이(가) 쓴 글:
> On Thu, Mar 29, 2018 at 08:22:08AM +0900, Inki Dae wrote:
>> Really thanks for doing this. :) There would be many users who use
>> Linux-3.18 for their products yet.
> 
> For new products?  They really should not be.  The kernel is officially

Really no. Old products would still be using Linux-3.18 kernel without kernel 
upgrade. For new product, most of SoC vendors will use Linux-4.x including us.
Actually, we are preparing for kernel upgrade for some devices even some old 
devices (to Linux-4.14-LTS) and almost done.

> end-of-life, but I'm keeping it alive for a short while longer just
> because too many people seem to still be using it.  However, they are
> not actually updating the kernel in their devices, so I don't think I
> will be doing many more new 3.18.y releases.
> 
> It's a problem when people ask for support, and then don't use the
> releases given to them :(
> 
> What is keeping you on 3.18.y and not allowing you to move to a newer
> kernel version?

We also want to move to latest kernel version. However, there is a case that we 
cannot upgrade the kernel.
In case that SoC vendor never share firmwares and relevant data sheets, we 
cannot upgrade the kernel. However, we have to resolve the security issues for 
users of this device.

Thanks,
Inki Dae

> 
> thanks,
> 
> greg k-h
> 
> 
> 

Re: [PATCH for v3.18 00/18] Backport CVE-2017-13166 fixes to Kernel 3.18

[Inki Dae]

2018년 03월 29일 13:25에 Greg KH 이(가) 쓴 글:
> On Thu, Mar 29, 2018 at 08:22:08AM +0900, Inki Dae wrote:
>> Really thanks for doing this. :) There would be many users who use
>> Linux-3.18 for their products yet.
> 
> For new products?  They really should not be.  The kernel is officially

Really no. Old products would still be using Linux-3.18 kernel without kernel 
upgrade. For new product, most of SoC vendors will use Linux-4.x including us.
Actually, we are preparing for kernel upgrade for some devices even some old 
devices (to Linux-4.14-LTS) and almost done.

> end-of-life, but I'm keeping it alive for a short while longer just
> because too many people seem to still be using it.  However, they are
> not actually updating the kernel in their devices, so I don't think I
> will be doing many more new 3.18.y releases.
> 
> It's a problem when people ask for support, and then don't use the
> releases given to them :(
> 
> What is keeping you on 3.18.y and not allowing you to move to a newer
> kernel version?

We also want to move to latest kernel version. However, there is a case that we 
cannot upgrade the kernel.
In case that SoC vendor never share firmwares and relevant data sheets, we 
cannot upgrade the kernel. However, we have to resolve the security issues for 
users of this device.

Thanks,
Inki Dae

> 
> thanks,
> 
> greg k-h
> 
> 
> 

Re: [PATCH for v3.18 00/18] Backport CVE-2017-13166 fixes to Kernel 3.18

[Inki Dae]

Hi Mauro,

2018년 03월 29일 03:12에 Mauro Carvalho Chehab 이(가) 쓴 글:
> Hi Greg,
> 
> Those are the backports meant to solve CVE-2017-13166 on Kernel 3.18.
> 
> It contains two v4l2-ctrls fixes that are required to avoid crashes
> at the test application.
> 
> I wrote two patches myself for Kernel 3.18 in order to solve some
> issues specific for Kernel 3.18 with aren't needed upstream.
> one is actually a one-line change backport. The other one makes
> sure that both 32-bits and 64-bits version of some ioctl calls
> will return the same value for a reserved field.
> 
> I noticed an extra bug while testing it, but the bug also hits upstream,
> and should be backported all the way down all stable/LTS versions.
> So, I'll send it the usual way, after merging upsream.

Really thanks for doing this. :) There would be many users who use Linux-3.18 
for their products yet.

Thanks,
Inki Dae

> 
> Regards,
> Mauro
> 
> 
> Daniel Mentz (2):
>   media: v4l2-compat-ioctl32: Copy v4l2_window->global_alpha
>   media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic
> 
> Hans Verkuil (12):
>   media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
>   media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
>   media: v4l2-compat-ioctl32.c: fix the indentation
>   media: v4l2-compat-ioctl32.c: move 'helper' functions to
> __get/put_v4l2_format32
>   media: v4l2-compat-ioctl32.c: avoid sizeof(type)
>   media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
>   media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
>   media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
>   media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32
>   media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
>   media: v4l2-compat-ioctl32.c: don't copy back the result for certain
> errors
>   media: v4l2-ctrls: fix sparse warning
> 
> Mauro Carvalho Chehab (2):
>   media: v4l2-compat-ioctl32: use compat_u64 for video standard
>   media: v4l2-compat-ioctl32: initialize a reserved field
> 
> Ricardo Ribalda (2):
>   vb2: V4L2_BUF_FLAG_DONE is set after DQBUF
>   media: media/v4l2-ctrls: volatiles should not generate CH_VALUE
> 
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1020 
> +++--
>  drivers/media/v4l2-core/v4l2-ctrls.c  |   96 ++-
>  drivers/media/v4l2-core/v4l2-ioctl.c  |5 +-
>  drivers/media/v4l2-core/videobuf2-core.c  |5 +
>  4 files changed, 691 insertions(+), 435 deletions(-)
> 

Re: [PATCH for v3.18 00/18] Backport CVE-2017-13166 fixes to Kernel 3.18

[Inki Dae]

Hi Mauro,

2018년 03월 29일 03:12에 Mauro Carvalho Chehab 이(가) 쓴 글:
> Hi Greg,
> 
> Those are the backports meant to solve CVE-2017-13166 on Kernel 3.18.
> 
> It contains two v4l2-ctrls fixes that are required to avoid crashes
> at the test application.
> 
> I wrote two patches myself for Kernel 3.18 in order to solve some
> issues specific for Kernel 3.18 with aren't needed upstream.
> one is actually a one-line change backport. The other one makes
> sure that both 32-bits and 64-bits version of some ioctl calls
> will return the same value for a reserved field.
> 
> I noticed an extra bug while testing it, but the bug also hits upstream,
> and should be backported all the way down all stable/LTS versions.
> So, I'll send it the usual way, after merging upsream.

Really thanks for doing this. :) There would be many users who use Linux-3.18 
for their products yet.

Thanks,
Inki Dae

> 
> Regards,
> Mauro
> 
> 
> Daniel Mentz (2):
>   media: v4l2-compat-ioctl32: Copy v4l2_window->global_alpha
>   media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic
> 
> Hans Verkuil (12):
>   media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
>   media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
>   media: v4l2-compat-ioctl32.c: fix the indentation
>   media: v4l2-compat-ioctl32.c: move 'helper' functions to
> __get/put_v4l2_format32
>   media: v4l2-compat-ioctl32.c: avoid sizeof(type)
>   media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
>   media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
>   media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
>   media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32
>   media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
>   media: v4l2-compat-ioctl32.c: don't copy back the result for certain
> errors
>   media: v4l2-ctrls: fix sparse warning
> 
> Mauro Carvalho Chehab (2):
>   media: v4l2-compat-ioctl32: use compat_u64 for video standard
>   media: v4l2-compat-ioctl32: initialize a reserved field
> 
> Ricardo Ribalda (2):
>   vb2: V4L2_BUF_FLAG_DONE is set after DQBUF
>   media: media/v4l2-ctrls: volatiles should not generate CH_VALUE
> 
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1020 
> +++--
>  drivers/media/v4l2-core/v4l2-ctrls.c  |   96 ++-
>  drivers/media/v4l2-core/v4l2-ioctl.c  |5 +-
>  drivers/media/v4l2-core/videobuf2-core.c  |5 +
>  4 files changed, 691 insertions(+), 435 deletions(-)
> 

Re: [PATCH 1/4] ARM: dts: exynos5250: Add #sound-dai-cells property to hdmi device node

[Inki Dae]

Hi Sylwester,

2018년 03월 09일 20:52에 Sylwester Nawrocki 이(가) 쓴 글:
> Hi Inki,
> 
> On 03/09/2018 03:40 AM, Inki Dae wrote:
>> 2018년 03월 08일 02:27에 Sylwester Nawrocki 이(가) 쓴 글:
>>> This property is required for specifying link between the HDMI IP block
>>> and the SoC's audio subsystem.
>>>
>>> Signed-off-by: Sylwester Nawrocki <s.nawro...@samsung.com>
>>> ---
>>>  arch/arm/boot/dts/exynos5250.dtsi | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
>>> b/arch/arm/boot/dts/exynos5250.dtsi
>>> index 56626d1a4235..71d2ede118e3 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -700,6 +700,7 @@
>>> "sclk_hdmiphy", "mout_hdmi";
>>> samsung,syscon-phandle = <_system_controller>;
>>> phy = <>;
>>> +   #sound-dai-cells = <0>;
>>
>> This patch adds this property to hdmi device node which is bound by HDMI 
>> driver 
>> of Exynos DRM. As we talked about this at other email thread, seems this 
>> property 
>> is required mandatorily for Odroid XU3/4 board which uses Exynos5422.
>> There may be something I'm missing so could you let me know how this 
>> property 
>> is required?
> 
> It is required to properly interpret the list of DAI specified in the 
> 'sound-dai'
> property. If a device supports only one DAI it will have #sound-dai-cells = 
> <0>
> and the sound-dai property values in cpu<->codec link may look like this:
> 
>  cpu { ... }
>  codec {
>sound-dai = <>, <>;
>  };
> 
> When the CODEC support more DAIs it will have #sound-dai-cells = <1> and we 
> can
> additionally specify which DAI we exactly refer to, in this case DAI 0:
> 
>  cpu { ... }
>  codec {
>   sound-dai = < 0>, <>;
>  };
> 
> More details can be found in documentation of of_parse_phandle_with_args()
> function.
> 
> The above refers to cpu/codec mapping like I2S0 -> [max9809x, hdmi], on 
> Exynos5433
> we have I2S0 -> wm5110 and I2S1 -> hdmi.

Thanks for explanation. By the way, who binds '#sound-dai-cells' property?.
This patch adds this property to hdmi device node which will be bound by HDMI 
driver fo Exynos DRM but I don't see any place to bind '#sound-dai-cells' 
property in this driver.
So I think some driver like Odroid XU3/4 audio 
driver(sound/soc/samsung/odroid.c) or ASoC simple audio card 
driver(sound/soc/generic/simple-card.c) should exist and this property should 
be placed to such device node.

Thanks,
Inki Dae

> 
> 

Re: [PATCH 1/4] ARM: dts: exynos5250: Add #sound-dai-cells property to hdmi device node

[Inki Dae]

Hi Sylwester,

2018년 03월 09일 20:52에 Sylwester Nawrocki 이(가) 쓴 글:
> Hi Inki,
> 
> On 03/09/2018 03:40 AM, Inki Dae wrote:
>> 2018년 03월 08일 02:27에 Sylwester Nawrocki 이(가) 쓴 글:
>>> This property is required for specifying link between the HDMI IP block
>>> and the SoC's audio subsystem.
>>>
>>> Signed-off-by: Sylwester Nawrocki 
>>> ---
>>>  arch/arm/boot/dts/exynos5250.dtsi | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
>>> b/arch/arm/boot/dts/exynos5250.dtsi
>>> index 56626d1a4235..71d2ede118e3 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -700,6 +700,7 @@
>>> "sclk_hdmiphy", "mout_hdmi";
>>> samsung,syscon-phandle = <_system_controller>;
>>> phy = <>;
>>> +   #sound-dai-cells = <0>;
>>
>> This patch adds this property to hdmi device node which is bound by HDMI 
>> driver 
>> of Exynos DRM. As we talked about this at other email thread, seems this 
>> property 
>> is required mandatorily for Odroid XU3/4 board which uses Exynos5422.
>> There may be something I'm missing so could you let me know how this 
>> property 
>> is required?
> 
> It is required to properly interpret the list of DAI specified in the 
> 'sound-dai'
> property. If a device supports only one DAI it will have #sound-dai-cells = 
> <0>
> and the sound-dai property values in cpu<->codec link may look like this:
> 
>  cpu { ... }
>  codec {
>sound-dai = <>, <>;
>  };
> 
> When the CODEC support more DAIs it will have #sound-dai-cells = <1> and we 
> can
> additionally specify which DAI we exactly refer to, in this case DAI 0:
> 
>  cpu { ... }
>  codec {
>   sound-dai = < 0>, <>;
>  };
> 
> More details can be found in documentation of of_parse_phandle_with_args()
> function.
> 
> The above refers to cpu/codec mapping like I2S0 -> [max9809x, hdmi], on 
> Exynos5433
> we have I2S0 -> wm5110 and I2S1 -> hdmi.

Thanks for explanation. By the way, who binds '#sound-dai-cells' property?.
This patch adds this property to hdmi device node which will be bound by HDMI 
driver fo Exynos DRM but I don't see any place to bind '#sound-dai-cells' 
property in this driver.
So I think some driver like Odroid XU3/4 audio 
driver(sound/soc/samsung/odroid.c) or ASoC simple audio card 
driver(sound/soc/generic/simple-card.c) should exist and this property should 
be placed to such device node.

Thanks,
Inki Dae

> 
> 

Re: [PATCH 1/4] ARM: dts: exynos5250: Add #sound-dai-cells property to hdmi device node

[Inki Dae]

Hi Sylwester,

2018년 03월 08일 02:27에 Sylwester Nawrocki 이(가) 쓴 글:
> This property is required for specifying link between the HDMI IP block
> and the SoC's audio subsystem.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawro...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5250.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 56626d1a4235..71d2ede118e3 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -700,6 +700,7 @@
>   "sclk_hdmiphy", "mout_hdmi";
>   samsung,syscon-phandle = <_system_controller>;
>   phy = <>;
> + #sound-dai-cells = <0>;

This patch adds this property to hdmi device node which is bound by HDMI driver 
of Exynos DRM. As we talked about this at other email thread, seems this 
property is required mandatorily for Odroid XU3/4 board which uses Exynos5422.
There may be something I'm missing so could you let me know how this property 
is required?

Thanks,
Inki Dae

>   status = "disabled";
>   };
>  
> 

Re: [PATCH 1/4] ARM: dts: exynos5250: Add #sound-dai-cells property to hdmi device node

[Inki Dae]

Hi Sylwester,

2018년 03월 08일 02:27에 Sylwester Nawrocki 이(가) 쓴 글:
> This property is required for specifying link between the HDMI IP block
> and the SoC's audio subsystem.
> 
> Signed-off-by: Sylwester Nawrocki 
> ---
>  arch/arm/boot/dts/exynos5250.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 56626d1a4235..71d2ede118e3 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -700,6 +700,7 @@
>   "sclk_hdmiphy", "mout_hdmi";
>   samsung,syscon-phandle = <_system_controller>;
>   phy = <>;
> + #sound-dai-cells = <0>;

This patch adds this property to hdmi device node which is bound by HDMI driver 
of Exynos DRM. As we talked about this at other email thread, seems this 
property is required mandatorily for Odroid XU3/4 board which uses Exynos5422.
There may be something I'm missing so could you let me know how this property 
is required?

Thanks,
Inki Dae

>   status = "disabled";
>   };
>  
> 

Re: [PATCH 2/4] drm/exynos: fix comparison to bitshift when dealing with a mask

[Inki Dae]

2018년 02월 06일 05:09에 Wolfram Sang 이(가) 쓴 글:
> Due to a typo, the mask was destroyed by a comparison instead of a bit
> shift.
> 
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
> ---
> Only build tested. To be applied individually per subsystem.
> 
>  drivers/gpu/drm/exynos/regs-fimc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/regs-fimc.h 
> b/drivers/gpu/drm/exynos/regs-fimc.h
> index 30496134a3d072..d7cbe53c4c01f4 100644
> --- a/drivers/gpu/drm/exynos/regs-fimc.h
> +++ b/drivers/gpu/drm/exynos/regs-fimc.h
> @@ -569,7 +569,7 @@
>  #define EXYNOS_CIIMGEFF_FIN_EMBOSSING(4 << 26)
>  #define EXYNOS_CIIMGEFF_FIN_SILHOUETTE   (5 << 26)
>  #define EXYNOS_CIIMGEFF_FIN_MASK (7 << 26)
> -#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK((0xff < 13) | (0xff < 
> 0))
> +#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK((0xff << 13) | (0xff 
> << 0))
>  

Oops. Picked it up.

Thanks,
Inki Dae

>  /* Real input DMA size register */
>  #define EXYNOS_CIREAL_ISIZE_AUTOLOAD_ENABLE  (1 << 31)
> 

Re: [PATCH 2/4] drm/exynos: fix comparison to bitshift when dealing with a mask

[Inki Dae]

2018년 02월 06일 05:09에 Wolfram Sang 이(가) 쓴 글:
> Due to a typo, the mask was destroyed by a comparison instead of a bit
> shift.
> 
> Signed-off-by: Wolfram Sang 
> ---
> Only build tested. To be applied individually per subsystem.
> 
>  drivers/gpu/drm/exynos/regs-fimc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/regs-fimc.h 
> b/drivers/gpu/drm/exynos/regs-fimc.h
> index 30496134a3d072..d7cbe53c4c01f4 100644
> --- a/drivers/gpu/drm/exynos/regs-fimc.h
> +++ b/drivers/gpu/drm/exynos/regs-fimc.h
> @@ -569,7 +569,7 @@
>  #define EXYNOS_CIIMGEFF_FIN_EMBOSSING(4 << 26)
>  #define EXYNOS_CIIMGEFF_FIN_SILHOUETTE   (5 << 26)
>  #define EXYNOS_CIIMGEFF_FIN_MASK (7 << 26)
> -#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK((0xff < 13) | (0xff < 
> 0))
> +#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK((0xff << 13) | (0xff 
> << 0))
>  

Oops. Picked it up.

Thanks,
Inki Dae

>  /* Real input DMA size register */
>  #define EXYNOS_CIREAL_ISIZE_AUTOLOAD_ENABLE  (1 << 31)
> 

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

[Inki Dae]

2018년 01월 18일 02:01에 Arnd Bergmann 이(가) 쓴 글:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
> 
> 1. signed seconds overflow in y2038
> 2. the 'struct timeval' definition is deprecated in the kernel
> 3. time may jump or go backwards after a 'settimeofday()' syscall
> 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
>can't be compared
> 5. exporting microseconds requires a division by 1000, which may
>be slow on some architectures.
> 
> The code existed in two places before, but the IPP portion was
> removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM
> IPP subsystem"), so we no longer need to worry about it.
> 
> Ideally timestamps should just use 64-bit nanoseconds instead, but
> of course we can't change that now. Instead, this tries to address
> the first four points above by using monotonic 'timespec' values.
> 
> According to Tobias Jakobi, user space doesn't care about the
> timestamp at the moment, so we can change the format. Even if
> there is something looking at them, it will work just fine with
> monotonic times as long as the application only looks at the
> relative values between two events.
> 
> Link: https://patchwork.kernel.org/patch/10038593/
> Cc: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Picked it up.

Thanks,
Inki Dae

> ---
> v2: rebased to what will be in 4.15, now that ipp is gone,
> updated changelog text based on input from Tobias.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 2b8bf2dd6387..9effe40f5fa5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -926,7 +926,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   struct drm_device *drm_dev = g2d->subdrv.drm_dev;
>   struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
>   struct drm_exynos_pending_g2d_event *e;
> - struct timeval now;
> + struct timespec64 now;
>  
>   if (list_empty(_node->event_list))
>   return;
> @@ -934,9 +934,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   e = list_first_entry(_node->event_list,
>struct drm_exynos_pending_g2d_event, base.link);
>  
> - do_gettimeofday();
> + ktime_get_ts64();
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.cmdlist_no = cmdlist_no;
>  
>   drm_send_event(drm_dev, >base);
> 

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

[Inki Dae]

2018년 01월 18일 02:01에 Arnd Bergmann 이(가) 쓴 글:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
> 
> 1. signed seconds overflow in y2038
> 2. the 'struct timeval' definition is deprecated in the kernel
> 3. time may jump or go backwards after a 'settimeofday()' syscall
> 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
>can't be compared
> 5. exporting microseconds requires a division by 1000, which may
>be slow on some architectures.
> 
> The code existed in two places before, but the IPP portion was
> removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM
> IPP subsystem"), so we no longer need to worry about it.
> 
> Ideally timestamps should just use 64-bit nanoseconds instead, but
> of course we can't change that now. Instead, this tries to address
> the first four points above by using monotonic 'timespec' values.
> 
> According to Tobias Jakobi, user space doesn't care about the
> timestamp at the moment, so we can change the format. Even if
> there is something looking at them, it will work just fine with
> monotonic times as long as the application only looks at the
> relative values between two events.
> 
> Link: https://patchwork.kernel.org/patch/10038593/
> Cc: Tobias Jakobi 
> Signed-off-by: Arnd Bergmann 

Picked it up.

Thanks,
Inki Dae

> ---
> v2: rebased to what will be in 4.15, now that ipp is gone,
> updated changelog text based on input from Tobias.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 2b8bf2dd6387..9effe40f5fa5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -926,7 +926,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   struct drm_device *drm_dev = g2d->subdrv.drm_dev;
>   struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
>   struct drm_exynos_pending_g2d_event *e;
> - struct timeval now;
> + struct timespec64 now;
>  
>   if (list_empty(_node->event_list))
>   return;
> @@ -934,9 +934,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   e = list_first_entry(_node->event_list,
>struct drm_exynos_pending_g2d_event, base.link);
>  
> - do_gettimeofday();
> + ktime_get_ts64();
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.cmdlist_no = cmdlist_no;
>  
>   drm_send_event(drm_dev, >base);
> 

Re: [RFC 1/2] arm: cacheflush syscall: process only pages that are in the memory

[Inki Dae]

Hi Russell,

2018년 01월 27일 06:39에 Russell King - ARM Linux 이(가) 쓴 글:
> On Fri, Jan 26, 2018 at 02:30:47PM +0100, Marek Szyprowski wrote:
>> Hi Russell,
>>
>> On 2018-01-26 12:32, Russell King - ARM Linux wrote:
>>> On Fri, Jan 26, 2018 at 12:14:40PM +0100, Marek Szyprowski wrote:
>>>> glibc in calls cacheflush syscall on the whole textrels section of the
>>>> relocated binaries. However, relocation usually doesn't touch all pages
>>>> of that section, so not all of them are read to memory when calling this
>>>> syscall. However flush_cache_user_range() function will unconditionally
>>>> touch all pages from the provided range, resulting additional overhead
>>>> related to reading all clean pages. Optimize this by calling
>>>> flush_cache_user_range() only on the pages that are already in the
>>>> memory.
>>> What ensures that another CPU doesn't remove a page while we're
>>> flushing it?  That will trigger a data abort, which will want to
>>> take the mmap_sem, causing a deadlock.
>>
>> I thought that taking mmap_sem will prevent pages from being removed.
>> mmap_sem has been already taken in the previous implementation of that
>> syscall, until code simplification done by commit 97c72d89ce0e ("ARM:
>> cacheflush: don't bother rounding to nearest vma").
> 
> No, you're not reading the previous code state correctly.  Take a closer
> look at that commit.
> 
> find_vma() requires that mmap_sem is held across the call as the VMA
> list is not stable without that semaphore held.  However, more
> importantly, notice that it drops the semaphore _before_ calling the
> cache flushing function (__do_cache_op()).
> 
> The point is that if __do_cache_op() faults, it will enter
> do_page_fault(), which will try to take the mmap_sem again, causing
> a deadlock.

I'm not sure but seems this patch tries to do cache-flush only in-memory pages.
So I think the page fault wouldn't happen becasue flush_cache_user_range 
function returns always 0.

Thanks,
Inki Dae

> 

Re: [RFC 1/2] arm: cacheflush syscall: process only pages that are in the memory

[Inki Dae]

Hi Russell,

2018년 01월 27일 06:39에 Russell King - ARM Linux 이(가) 쓴 글:
> On Fri, Jan 26, 2018 at 02:30:47PM +0100, Marek Szyprowski wrote:
>> Hi Russell,
>>
>> On 2018-01-26 12:32, Russell King - ARM Linux wrote:
>>> On Fri, Jan 26, 2018 at 12:14:40PM +0100, Marek Szyprowski wrote:
>>>> glibc in calls cacheflush syscall on the whole textrels section of the
>>>> relocated binaries. However, relocation usually doesn't touch all pages
>>>> of that section, so not all of them are read to memory when calling this
>>>> syscall. However flush_cache_user_range() function will unconditionally
>>>> touch all pages from the provided range, resulting additional overhead
>>>> related to reading all clean pages. Optimize this by calling
>>>> flush_cache_user_range() only on the pages that are already in the
>>>> memory.
>>> What ensures that another CPU doesn't remove a page while we're
>>> flushing it?  That will trigger a data abort, which will want to
>>> take the mmap_sem, causing a deadlock.
>>
>> I thought that taking mmap_sem will prevent pages from being removed.
>> mmap_sem has been already taken in the previous implementation of that
>> syscall, until code simplification done by commit 97c72d89ce0e ("ARM:
>> cacheflush: don't bother rounding to nearest vma").
> 
> No, you're not reading the previous code state correctly.  Take a closer
> look at that commit.
> 
> find_vma() requires that mmap_sem is held across the call as the VMA
> list is not stable without that semaphore held.  However, more
> importantly, notice that it drops the semaphore _before_ calling the
> cache flushing function (__do_cache_op()).
> 
> The point is that if __do_cache_op() faults, it will enter
> do_page_fault(), which will try to take the mmap_sem again, causing
> a deadlock.

I'm not sure but seems this patch tries to do cache-flush only in-memory pages.
So I think the page fault wouldn't happen becasue flush_cache_user_range 
function returns always 0.

Thanks,
Inki Dae

> 

Re: [PATCH 03/19] drm/exynos: Use the alpha format helper

[Inki Dae]

2018년 01월 09일 19:56에 Maxime Ripard 이(가) 쓴 글:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
> 
> Cc: Inki Dae <inki@samsung.com>
> Cc: Joonyoung Shim <jy0922.s...@samsung.com>
> Cc: Kyungmin Park <kyungmin.p...@samsung.com>
> Cc: Seung-Woo Kim <sw0312@samsung.com>
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>

Acked-by: Inki Dae <inki@samsung.com>

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index dc5d79465f9b..d7339a6d072c 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -179,18 +179,6 @@ static const u8 filter_cr_horiz_tap4[] = {
>   70, 59, 48, 37, 27, 19, 11, 5,
>  };
>  
> -static inline bool is_alpha_format(unsigned int pixel_format)
> -{
> - switch (pixel_format) {
> - case DRM_FORMAT_ARGB:
> - case DRM_FORMAT_ARGB1555:
> - case DRM_FORMAT_ARGB:
> - return true;
> - default:
> - return false;
> - }
> -}
> -
>  static inline u32 vp_reg_read(struct mixer_context *ctx, u32 reg_id)
>  {
>   return readl(ctx->vp_regs + reg_id);
> @@ -625,7 +613,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
>   mixer_reg_write(ctx, MXR_GRAPHIC_BASE(win), dma_addr);
>  
>   mixer_cfg_layer(ctx, win, priority, true);
> - mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->format->format));
> + mixer_cfg_gfx_blend(ctx, win, drm_format_has_alpha(fb->format->format));
>  
>   /* layer update mandatory for mixer 16.0.33.0 */
>   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> 

Re: [PATCH 03/19] drm/exynos: Use the alpha format helper

[Inki Dae]

2018년 01월 09일 19:56에 Maxime Ripard 이(가) 쓴 글:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Kyungmin Park 
> Cc: Seung-Woo Kim 
> Signed-off-by: Maxime Ripard 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index dc5d79465f9b..d7339a6d072c 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -179,18 +179,6 @@ static const u8 filter_cr_horiz_tap4[] = {
>   70, 59, 48, 37, 27, 19, 11, 5,
>  };
>  
> -static inline bool is_alpha_format(unsigned int pixel_format)
> -{
> - switch (pixel_format) {
> - case DRM_FORMAT_ARGB:
> - case DRM_FORMAT_ARGB1555:
> - case DRM_FORMAT_ARGB:
> - return true;
> - default:
> - return false;
> - }
> -}
> -
>  static inline u32 vp_reg_read(struct mixer_context *ctx, u32 reg_id)
>  {
>   return readl(ctx->vp_regs + reg_id);
> @@ -625,7 +613,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
>   mixer_reg_write(ctx, MXR_GRAPHIC_BASE(win), dma_addr);
>  
>   mixer_cfg_layer(ctx, win, priority, true);
> - mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->format->format));
> + mixer_cfg_gfx_blend(ctx, win, drm_format_has_alpha(fb->format->format));
>  
>   /* layer update mandatory for mixer 16.0.33.0 */
>   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> 

Re: [PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

[Inki Dae]

Hi Andrzej,

2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글:
> Hi Shuah,
> 
> 
> On 24.06.2017 02:56, Shuah Khan wrote:
>> Fix to call of_node_put() right after of_drm_find_bridge() instead of
>> holding on to it until exynos_dsi_remove().
> 
> I think the current implementation is OK, node is get in probe and put
> in remove.
> There could be many bind/unbind during lifetime of the bound driver.
> For example, there is possible sequence:
> 1. probe -
> 2. bind
> 3. unbind
> 4. bind
> 
> With this patch on 2nd bind (point 4) driver will call
> of_drm_find_bridge on dsi->bridge_node which was put earlier (point 2.).
> 

Right. This is a problem.

How about moving of_drm_find_bridge function call to probe and keeping 
drm_bridge_attach call in bind for cleanup?
Seems it doesn't need to call of_drm_find_bridge function every time bind 
callback is called.

Thanks,
Inki Dae

> Regards
> Andrzej
> 
> 
>>
>> Suggested-by: Inki Dae <inki@samsung.com>
>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index e337cd2..7513b88 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1689,6 +1689,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
>> device *master,
>>  
>>  if (dsi->bridge_node) {
>>  bridge = of_drm_find_bridge(dsi->bridge_node);
>> +of_node_put(dsi->bridge_node);
>>  if (bridge)
>>  drm_bridge_attach(encoder, bridge, NULL);
>>  }
>> @@ -1807,10 +1808,6 @@ static int exynos_dsi_probe(struct platform_device 
>> *pdev)
>>  
>>  static int exynos_dsi_remove(struct platform_device *pdev)
>>  {
>> -struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>> -
>> -of_node_put(dsi->bridge_node);
>> -
>>  pm_runtime_disable(>dev);
>>  
>>  component_del(>dev, _dsi_component_ops);
> 
> 
> --
> 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] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

[Inki Dae]

Hi Andrzej,

2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글:
> Hi Shuah,
> 
> 
> On 24.06.2017 02:56, Shuah Khan wrote:
>> Fix to call of_node_put() right after of_drm_find_bridge() instead of
>> holding on to it until exynos_dsi_remove().
> 
> I think the current implementation is OK, node is get in probe and put
> in remove.
> There could be many bind/unbind during lifetime of the bound driver.
> For example, there is possible sequence:
> 1. probe -
> 2. bind
> 3. unbind
> 4. bind
> 
> With this patch on 2nd bind (point 4) driver will call
> of_drm_find_bridge on dsi->bridge_node which was put earlier (point 2.).
> 

Right. This is a problem.

How about moving of_drm_find_bridge function call to probe and keeping 
drm_bridge_attach call in bind for cleanup?
Seems it doesn't need to call of_drm_find_bridge function every time bind 
callback is called.

Thanks,
Inki Dae

> Regards
> Andrzej
> 
> 
>>
>> Suggested-by: Inki Dae 
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index e337cd2..7513b88 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1689,6 +1689,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
>> device *master,
>>  
>>  if (dsi->bridge_node) {
>>  bridge = of_drm_find_bridge(dsi->bridge_node);
>> +of_node_put(dsi->bridge_node);
>>  if (bridge)
>>  drm_bridge_attach(encoder, bridge, NULL);
>>  }
>> @@ -1807,10 +1808,6 @@ static int exynos_dsi_probe(struct platform_device 
>> *pdev)
>>  
>>  static int exynos_dsi_remove(struct platform_device *pdev)
>>  {
>> -struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>> -
>> -of_node_put(dsi->bridge_node);
>> -
>>  pm_runtime_disable(>dev);
>>  
>>  component_del(>dev, _dsi_component_ops);
> 
> 
> --
> 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] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

[Inki Dae]

2017년 06월 09일 18:23에 Hoegeun Kwon 이(가) 쓴 글:
> The bridge_node is unnecessary between FIMD and DSIM. If don't remove
> error handling, it will not work between FIMD and DSIM. So remove
> error handling.

Please make sure to describe why bridge_node is unnecessary.
For example,
In case of Exynos SoC, a bridge device such as mDNIe and MIC could be placed 
between Display Controller and MIPI DSI device but the bridge device is 
required optionally.

Thanks,
Inki Dae

> 
> Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index a11b795..6ee0dac 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>   return ret;
>  
>   dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
> - if (!dsi->bridge_node)
> - return -EINVAL;
>  
>   return 0;
>  }
> 

Re: [PATCH] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

[Inki Dae]

2017년 06월 09일 18:23에 Hoegeun Kwon 이(가) 쓴 글:
> The bridge_node is unnecessary between FIMD and DSIM. If don't remove
> error handling, it will not work between FIMD and DSIM. So remove
> error handling.

Please make sure to describe why bridge_node is unnecessary.
For example,
In case of Exynos SoC, a bridge device such as mDNIe and MIC could be placed 
between Display Controller and MIPI DSI device but the bridge device is 
required optionally.

Thanks,
Inki Dae

> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index a11b795..6ee0dac 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>   return ret;
>  
>   dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
> - if (!dsi->bridge_node)
> - return -EINVAL;
>  
>   return 0;
>  }
> 

Re: [PATCH v2] drm/exynos: dsi: Remove bridge node reference in removal

[Inki Dae]

2017년 05월 26일 10:02에 Hoegeun Kwon 이(가) 쓴 글:
> Since bridge node is referenced during in the probe, it should be
> released on removal.
> 
> Suggested-by: Andrzej Hajda <a.ha...@samsung.com>
> Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
> ---
> Hi Inki,
> 
> This patch seems to have been forgotten... :)

Yeah, forgot this. Merged.

Thanks,
Inki Dae

> 
> Changes for V2:
> 
> - Checked for rebase 4.12-rc2
> 
> Best regards,
> Hoegeun
> 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 698a824..a11b795 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1805,6 +1805,10 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>  
>  static int exynos_dsi_remove(struct platform_device *pdev)
>  {
> + struct exynos_dsi *dsi = platform_get_drvdata(pdev);
> +
> + of_node_put(dsi->bridge_node);
> +
>   pm_runtime_disable(>dev);
>  
>   component_del(>dev, _dsi_component_ops);
> 

Re: [PATCH v2] drm/exynos: dsi: Remove bridge node reference in removal

[Inki Dae]

2017년 05월 26일 10:02에 Hoegeun Kwon 이(가) 쓴 글:
> Since bridge node is referenced during in the probe, it should be
> released on removal.
> 
> Suggested-by: Andrzej Hajda 
> Signed-off-by: Hoegeun Kwon 
> ---
> Hi Inki,
> 
> This patch seems to have been forgotten... :)

Yeah, forgot this. Merged.

Thanks,
Inki Dae

> 
> Changes for V2:
> 
> - Checked for rebase 4.12-rc2
> 
> Best regards,
> Hoegeun
> 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 698a824..a11b795 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1805,6 +1805,10 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>  
>  static int exynos_dsi_remove(struct platform_device *pdev)
>  {
> + struct exynos_dsi *dsi = platform_get_drvdata(pdev);
> +
> + of_node_put(dsi->bridge_node);
> +
>   pm_runtime_disable(>dev);
>  
>   component_del(>dev, _dsi_component_ops);
> 

Re: [PATCH] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards

[Inki Dae]

2017년 04월 25일 10:54에 Hoegeun Kwon 이(가) 쓴 글:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
> 
> Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3ff9527..23191eb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -60,7 +60,6 @@
>   vci-supply = <_reg>;
>   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
> - te-gpios = < 3 GPIO_ACTIVE_HIGH>;

Reviewed-by: Inki Dae <inki@samsung.com>

Thanks,
Inki Dae

>   };
>  };
>  
> 

Re: [PATCH] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards

[Inki Dae]

2017년 04월 25일 10:54에 Hoegeun Kwon 이(가) 쓴 글:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3ff9527..23191eb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -60,7 +60,6 @@
>   vci-supply = <_reg>;
>   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
> - te-gpios = < 3 GPIO_ACTIVE_HIGH>;

Reviewed-by: Inki Dae 

Thanks,
Inki Dae

>   };
>  };
>  
> 

Re: [PATCH v2 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board

[Inki Dae]

2017년 04월 18일 14:55에 Andrzej Hajda 이(가) 쓴 글:
> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>> This patch supports TM2e panel and the panel has 1600x2560 resolution
>> in 5.65" physical.
>>
>> This identify panel type with compatibility string, also invoke
>> display mode that matches the type. So add the check code for s6e3ha2
>> compatibility and s6e3hf2 type and select the drm_display_mode of
>> default and edge type.
>>
>> Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

Reviewed-by: Inki Dae <inki@samsung.com>

Thanks,
Inki Dae

> 
>  --
> Regards
> Andrzej
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH v2 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board

[Inki Dae]

2017년 04월 18일 14:55에 Andrzej Hajda 이(가) 쓴 글:
> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>> This patch supports TM2e panel and the panel has 1600x2560 resolution
>> in 5.65" physical.
>>
>> This identify panel type with compatibility string, also invoke
>> display mode that matches the type. So add the check code for s6e3ha2
>> compatibility and s6e3hf2 type and select the drm_display_mode of
>> default and edge type.
>>
>> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 

Reviewed-by: Inki Dae 

Thanks,
Inki Dae

> 
>  --
> Regards
> Andrzej
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

[Inki Dae]

2017년 04월 05일 00:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Tue, Mar 28, 2017 at 11:38 AM, Krzysztof Kozlowski <k...@kernel.org> wrote:
>> On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae <inki@samsung.com> wrote:
>>> Merged.
>>
>> Hi,
>>
>> I do not see the tag (with DT patches) merged by you which I provided
>> to you before. These are essential for bisectability. Without them,
>> kernel bisectability is broken. Did you merged the tag somewhere?
>>
>> Best regards,
>> Krzysztof
>>
>>> Thanks,
>>> Inki Dae
> 
> Inki,
> 
> I still do not see the DTS tag [1] merged in your tree but you applied
> patches breaking the display. I looked at exynos-drm-next branch.
> 
> We talked already about bisectability and with Hoegeun we provided
> proper solution. Hoegeun split the patchset and I sent you a stable
> tag to merge. Be aware not to apply the DTS patch because you would
> effectively duplicate it. Instead, deal like with any pull request -
> merge the tag as dependency *before* applying DRM DSI patch.
> 
> I saw also a branch like this:
> https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-tm2
> but this is something obviously wrong. I do not know what are your
> plans to do with it, but please drop it as it brings only confusion.

Krzysztof,

Do not make you confusing with above branch which is used just for internal 
test so never go -next maybe you know.
Why are you suffering from this?


Thanks,
Inki Dae

> 
> Best regards,
> Krzysztof
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg567053.html
> 
>>> 2017년 03월 22일 10:36에 Hoegeun Kwon 이(가) 쓴 글:
>>>> Hi inki,
>>>>
>>>> Could you check the this patch?
>>>> For reference, patch 1/5 and 2/5 have already been applied to Krzysztof 
>>>> tree.
>>>>
>>>> Best regards,
>>>> Hoegeun
>>>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

[Inki Dae]

2017년 04월 05일 00:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Tue, Mar 28, 2017 at 11:38 AM, Krzysztof Kozlowski  wrote:
>> On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae  wrote:
>>> Merged.
>>
>> Hi,
>>
>> I do not see the tag (with DT patches) merged by you which I provided
>> to you before. These are essential for bisectability. Without them,
>> kernel bisectability is broken. Did you merged the tag somewhere?
>>
>> Best regards,
>> Krzysztof
>>
>>> Thanks,
>>> Inki Dae
> 
> Inki,
> 
> I still do not see the DTS tag [1] merged in your tree but you applied
> patches breaking the display. I looked at exynos-drm-next branch.
> 
> We talked already about bisectability and with Hoegeun we provided
> proper solution. Hoegeun split the patchset and I sent you a stable
> tag to merge. Be aware not to apply the DTS patch because you would
> effectively duplicate it. Instead, deal like with any pull request -
> merge the tag as dependency *before* applying DRM DSI patch.
> 
> I saw also a branch like this:
> https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-tm2
> but this is something obviously wrong. I do not know what are your
> plans to do with it, but please drop it as it brings only confusion.

Krzysztof,

Do not make you confusing with above branch which is used just for internal 
test so never go -next maybe you know.
Why are you suffering from this?


Thanks,
Inki Dae

> 
> Best regards,
> Krzysztof
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg567053.html
> 
>>> 2017년 03월 22일 10:36에 Hoegeun Kwon 이(가) 쓴 글:
>>>> Hi inki,
>>>>
>>>> Could you check the this patch?
>>>> For reference, patch 1/5 and 2/5 have already been applied to Krzysztof 
>>>> tree.
>>>>
>>>> Best regards,
>>>> Hoegeun
>>>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

[Inki Dae]

2017년 04월 05일 00:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Tue, Mar 28, 2017 at 11:38 AM, Krzysztof Kozlowski <k...@kernel.org> wrote:
>> On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae <inki@samsung.com> wrote:
>>> Merged.
>>
>> Hi,
>>
>> I do not see the tag (with DT patches) merged by you which I provided
>> to you before. These are essential for bisectability. Without them,
>> kernel bisectability is broken. Did you merged the tag somewhere?
>>
>> Best regards,
>> Krzysztof
>>
>>> Thanks,
>>> Inki Dae
> 
> Inki,
> 
> I still do not see the DTS tag [1] merged in your tree but you applied
> patches breaking the display. I looked at exynos-drm-next branch.
> 
> We talked already about bisectability and with Hoegeun we provided
> proper solution. Hoegeun split the patchset and I sent you a stable
> tag to merge. Be aware not to apply the DTS patch because you would
> effectively duplicate it. Instead, deal like with any pull request -
> merge the tag as dependency *before* applying DRM DSI patch.

Krzysztof,

I think merging the DTS tag is not necessary because dt and drm patches will go 
to -next separately.
Anyway, confirmed your email just now. Seems better so did what you want.


Thanks,
Inki Dae

> 
> I saw also a branch like this:
> https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-tm2
> but this is something obviously wrong. I do not know what are your
> plans to do with it, but please drop it as it brings only confusion.
> 
> Best regards,
> Krzysztof
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg567053.html
> 
>>> 2017년 03월 22일 10:36에 Hoegeun Kwon 이(가) 쓴 글:
>>>> Hi inki,
>>>>
>>>> Could you check the this patch?
>>>> For reference, patch 1/5 and 2/5 have already been applied to Krzysztof 
>>>> tree.
>>>>
>>>> Best regards,
>>>> Hoegeun
>>>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

[Inki Dae]

2017년 04월 05일 00:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Tue, Mar 28, 2017 at 11:38 AM, Krzysztof Kozlowski  wrote:
>> On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae  wrote:
>>> Merged.
>>
>> Hi,
>>
>> I do not see the tag (with DT patches) merged by you which I provided
>> to you before. These are essential for bisectability. Without them,
>> kernel bisectability is broken. Did you merged the tag somewhere?
>>
>> Best regards,
>> Krzysztof
>>
>>> Thanks,
>>> Inki Dae
> 
> Inki,
> 
> I still do not see the DTS tag [1] merged in your tree but you applied
> patches breaking the display. I looked at exynos-drm-next branch.
> 
> We talked already about bisectability and with Hoegeun we provided
> proper solution. Hoegeun split the patchset and I sent you a stable
> tag to merge. Be aware not to apply the DTS patch because you would
> effectively duplicate it. Instead, deal like with any pull request -
> merge the tag as dependency *before* applying DRM DSI patch.

Krzysztof,

I think merging the DTS tag is not necessary because dt and drm patches will go 
to -next separately.
Anyway, confirmed your email just now. Seems better so did what you want.


Thanks,
Inki Dae

> 
> I saw also a branch like this:
> https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-tm2
> but this is something obviously wrong. I do not know what are your
> plans to do with it, but please drop it as it brings only confusion.
> 
> Best regards,
> Krzysztof
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg567053.html
> 
>>> 2017년 03월 22일 10:36에 Hoegeun Kwon 이(가) 쓴 글:
>>>> Hi inki,
>>>>
>>>> Could you check the this patch?
>>>> For reference, patch 1/5 and 2/5 have already been applied to Krzysztof 
>>>> tree.
>>>>
>>>> Best regards,
>>>> Hoegeun
>>>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

[Inki Dae]

Merged.

Thanks,
Inki Dae

2017년 03월 22일 10:36에 Hoegeun Kwon 이(가) 쓴 글:
> Hi inki,
> 
> Could you check the this patch?
> For reference, patch 1/5 and 2/5 have already been applied to Krzysztof tree.
> 
> Best regards,
> Hoegeun
> 
> 
> On 03/08/2017 01:54 PM, Hoegeun Kwon wrote:
>> The dsi + panel is a parental relationship, so OF grpah is not needed.
>> Therefore, the current dsi_parse_dt function will throw an error,
>> because there is no linked OF graph for the case fimd + dsi + panel.
>>
>> Parse the Pll burst and esc clock frequency properties in dsi_parse_dt()
>> and create a bridge_node only if there is an OF graph associated with dsi.
>>
>> Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
>> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
>> Reviewed-by: Andi Shyti <andi.sh...@samsung.com>
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32 
>> 
>>   1 file changed, 8 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index f5c04d0..2d4e118 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1652,39 +1652,23 @@ static int exynos_dsi_parse_dt(struct exynos_dsi 
>> *dsi)
>>   if (ret < 0)
>>   return ret;
>>   -ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
>> -if (!ep) {
>> -dev_err(dev, "no output port with endpoint specified\n");
>> -return -EINVAL;
>> -}
>> -
>> -ret = exynos_dsi_of_read_u32(ep, "samsung,burst-clock-frequency",
>> +ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
>>>burst_clk_rate);
>>   if (ret < 0)
>> -goto end;
>> +return ret;
>>   -ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
>> +ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
>>>esc_clk_rate);
>>   if (ret < 0)
>> -goto end;
>> -
>> -of_node_put(ep);
>> +return ret;
>> ep = of_graph_get_next_endpoint(node, NULL);
>> -if (!ep) {
>> -ret = -EINVAL;
>> -goto end;
>> -}
>> -
>> -dsi->bridge_node = of_graph_get_remote_port_parent(ep);
>> -if (!dsi->bridge_node) {
>> -ret = -EINVAL;
>> -goto end;
>> +if (ep) {
>> +dsi->bridge_node = of_graph_get_remote_port_parent(ep);
>> +of_node_put(ep);
>>   }
>> -end:
>> -of_node_put(ep);
>>   -return ret;
>> +return 0;
>>   }
>> static int exynos_dsi_bind(struct device *dev, struct device *master,
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

[Inki Dae]

Merged.

Thanks,
Inki Dae

2017년 03월 22일 10:36에 Hoegeun Kwon 이(가) 쓴 글:
> Hi inki,
> 
> Could you check the this patch?
> For reference, patch 1/5 and 2/5 have already been applied to Krzysztof tree.
> 
> Best regards,
> Hoegeun
> 
> 
> On 03/08/2017 01:54 PM, Hoegeun Kwon wrote:
>> The dsi + panel is a parental relationship, so OF grpah is not needed.
>> Therefore, the current dsi_parse_dt function will throw an error,
>> because there is no linked OF graph for the case fimd + dsi + panel.
>>
>> Parse the Pll burst and esc clock frequency properties in dsi_parse_dt()
>> and create a bridge_node only if there is an OF graph associated with dsi.
>>
>> Signed-off-by: Hoegeun Kwon 
>> Reviewed-by: Andrzej Hajda 
>> Reviewed-by: Andi Shyti 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32 
>> 
>>   1 file changed, 8 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index f5c04d0..2d4e118 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1652,39 +1652,23 @@ static int exynos_dsi_parse_dt(struct exynos_dsi 
>> *dsi)
>>   if (ret < 0)
>>   return ret;
>>   -ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
>> -if (!ep) {
>> -dev_err(dev, "no output port with endpoint specified\n");
>> -return -EINVAL;
>> -}
>> -
>> -ret = exynos_dsi_of_read_u32(ep, "samsung,burst-clock-frequency",
>> +ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
>>>burst_clk_rate);
>>   if (ret < 0)
>> -goto end;
>> +return ret;
>>   -ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
>> +ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
>>>esc_clk_rate);
>>   if (ret < 0)
>> -goto end;
>> -
>> -of_node_put(ep);
>> +return ret;
>> ep = of_graph_get_next_endpoint(node, NULL);
>> -if (!ep) {
>> -ret = -EINVAL;
>> -goto end;
>> -}
>> -
>> -dsi->bridge_node = of_graph_get_remote_port_parent(ep);
>> -if (!dsi->bridge_node) {
>> -ret = -EINVAL;
>> -goto end;
>> +if (ep) {
>> +dsi->bridge_node = of_graph_get_remote_port_parent(ep);
>> +of_node_put(ep);
>>   }
>> -end:
>> -of_node_put(ep);
>>   -return ret;
>> +return 0;
>>   }
>> static int exynos_dsi_bind(struct device *dev, struct device *master,
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

[Inki Dae]

Merged.

Thanks,
Inki Dae

2017년 03월 15일 03:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> Printing raw kernel pointers might reveal information which sometimes we
> try to hide (e.g. with Kernel Address Space Layout Randomization).  Use
> the "%pK" format so these pointers will be hidden for unprivileged
> users.
> 
> Signed-off-by: Krzysztof Kozlowski <k...@kernel.org>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 22 +++---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  2 +-
>  6 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 812e2ec0761d..202526b20b64 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -979,7 +979,7 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>   bool first = !xfer->tx_done;
>   u32 reg;
>  
> - dev_dbg(dev, "< xfer %p: tx len %u, done %u, rx len %u, done %u\n",
> + dev_dbg(dev, "< xfer %pK: tx len %u, done %u, rx len %u, done %u\n",
>   xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
>  
>   if (length > DSI_TX_FIFO_SIZE)
> @@ -1177,7 +1177,7 @@ static bool exynos_dsi_transfer_finish(struct 
> exynos_dsi *dsi)
>   spin_unlock_irqrestore(>transfer_lock, flags);
>  
>   dev_dbg(dsi->dev,
> - "> xfer %p, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
> + "> xfer %pK, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
>   xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
>   xfer->rx_done);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 95871577015d..5b18b5c5fdf2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1695,7 +1695,7 @@ static int fimc_probe(struct platform_device *pdev)
>   goto err_put_clk;
>   }
>  
> - DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
> + DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
>  
>   spin_lock_init(>lock);
>   platform_set_drvdata(pdev, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c28f7ffcc4d..55a1579d11b3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -218,7 +218,7 @@ static struct exynos_drm_gem *exynos_drm_gem_init(struct 
> drm_device *dev,
>   return ERR_PTR(ret);
>   }
>  
> - DRM_DEBUG_KMS("created file object = %p\n", obj->filp);
> + DRM_DEBUG_KMS("created file object = %pK\n", obj->filp);
>  
>   return exynos_gem;
>  }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index bef57987759d..0506b2b17ac1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1723,7 +1723,7 @@ static int gsc_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
> + DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
>  
>   mutex_init(>lock);
>   platform_set_drvdata(pdev, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 9c84ee76f18a..3edda18cc2d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -208,7 +208,7 @@ static struct exynos_drm_ippdrv 
> *ipp_find_drv_by_handle(u32 prop_id)
>* e.g PAUSE state, queue buf, command control.
>*/
>   list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
> - DRM_DEBUG_KMS("count[%d]ippdrv[%p]\n", count++, ippdrv);
> + DRM_DEBUG_KMS("count[%d]ippdrv[%pK]\n", count++, ippdrv);
>  
>   mutex_lock(>cmd_lock);
>   list_for_each_entry(c_node, >cmd_list, list) {
> @@ -388,7 +388,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
> *drm_dev, void *data,
>   }
>   property->prop_id = ret;
>  
> - DRM_DEBUG_KMS("created prop_id[

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

[Inki Dae]

Merged.

Thanks,
Inki Dae

2017년 03월 15일 03:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> Printing raw kernel pointers might reveal information which sometimes we
> try to hide (e.g. with Kernel Address Space Layout Randomization).  Use
> the "%pK" format so these pointers will be hidden for unprivileged
> users.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 22 +++---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  2 +-
>  6 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 812e2ec0761d..202526b20b64 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -979,7 +979,7 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>   bool first = !xfer->tx_done;
>   u32 reg;
>  
> - dev_dbg(dev, "< xfer %p: tx len %u, done %u, rx len %u, done %u\n",
> + dev_dbg(dev, "< xfer %pK: tx len %u, done %u, rx len %u, done %u\n",
>   xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
>  
>   if (length > DSI_TX_FIFO_SIZE)
> @@ -1177,7 +1177,7 @@ static bool exynos_dsi_transfer_finish(struct 
> exynos_dsi *dsi)
>   spin_unlock_irqrestore(>transfer_lock, flags);
>  
>   dev_dbg(dsi->dev,
> - "> xfer %p, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
> + "> xfer %pK, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
>   xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
>   xfer->rx_done);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 95871577015d..5b18b5c5fdf2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1695,7 +1695,7 @@ static int fimc_probe(struct platform_device *pdev)
>   goto err_put_clk;
>   }
>  
> - DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
> + DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
>  
>   spin_lock_init(>lock);
>   platform_set_drvdata(pdev, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c28f7ffcc4d..55a1579d11b3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -218,7 +218,7 @@ static struct exynos_drm_gem *exynos_drm_gem_init(struct 
> drm_device *dev,
>   return ERR_PTR(ret);
>   }
>  
> - DRM_DEBUG_KMS("created file object = %p\n", obj->filp);
> + DRM_DEBUG_KMS("created file object = %pK\n", obj->filp);
>  
>   return exynos_gem;
>  }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index bef57987759d..0506b2b17ac1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1723,7 +1723,7 @@ static int gsc_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
> + DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
>  
>   mutex_init(>lock);
>   platform_set_drvdata(pdev, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 9c84ee76f18a..3edda18cc2d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -208,7 +208,7 @@ static struct exynos_drm_ippdrv 
> *ipp_find_drv_by_handle(u32 prop_id)
>* e.g PAUSE state, queue buf, command control.
>*/
>   list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
> - DRM_DEBUG_KMS("count[%d]ippdrv[%p]\n", count++, ippdrv);
> + DRM_DEBUG_KMS("count[%d]ippdrv[%pK]\n", count++, ippdrv);
>  
>   mutex_lock(>cmd_lock);
>   list_for_each_entry(c_node, >cmd_list, list) {
> @@ -388,7 +388,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
> *drm_dev, void *data,
>   }
>   property->prop_id = ret;
>  
> - DRM_DEBUG_KMS("created prop_id[%d]cmd[%d]ippdrv[%p]\n",

Re: [RESEND] drm/exynos: Remove support for Exynos4415 (SoC not supported anymore)

[Inki Dae]

Merged.

Thanks.

2017년 03월 12일 03:04에 Krzysztof Kozlowski 이(가) 쓴 글:
> Support for Exynos4415 is going away because there are no internal nor
> external users.
> 
> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
> the platform cannot be instantiated so remove also the drivers.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Acked-by: Kukjin Kim 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/display/exynos/exynos_dsim.txt |  1 -
>  .../bindings/display/exynos/samsung-fimd.txt   |  1 -
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 15 +--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 18 
> ++
>  4 files changed, 3 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> index a78265993665..ca5204b3bc21 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> @@ -4,7 +4,6 @@ Required properties:
>- compatible: value should be one of the following
>   "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */
>   "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
> - "samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
>   "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs 
> */
>   "samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
>   "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
> diff --git 
> a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt 
> b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> index 18645e0228b0..5837402c3ade 100644
> --- a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> @@ -11,7 +11,6 @@ Required properties:
>   "samsung,s5pv210-fimd"; /* for S5PV210 SoC */
>   "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */
>   "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
> - "samsung,exynos4415-fimd"; /* for Exynos4415 SoC */
>   "samsung,exynos5250-fimd"; /* for Exynos5250 SoCs */
>   "samsung,exynos5420-fimd"; /* for Exynos5420/5422/5800 SoCs */
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 812e2ec0761d..ef6f9c6de098 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -86,7 +86,7 @@
>  #define DSIM_SYNC_INFORM (1 << 27)
>  #define DSIM_EOT_DISABLE (1 << 28)
>  #define DSIM_MFLUSH_VS   (1 << 29)
> -/* This flag is valid only for exynos3250/3472/4415/5260/5430 */
> +/* This flag is valid only for exynos3250/3472/5260/5430 */
>  #define DSIM_CLKLANE_STOP(1 << 30)
>  
>  /* DSIM_ESCMODE */
> @@ -473,17 +473,6 @@ static const struct exynos_dsi_driver_data 
> exynos4_dsi_driver_data = {
>   .reg_values = reg_values,
>  };
>  
> -static const struct exynos_dsi_driver_data exynos4415_dsi_driver_data = {
> - .reg_ofs = exynos_reg_ofs,
> - .plltmr_reg = 0x58,
> - .has_clklane_stop = 1,
> - .num_clks = 2,
> - .max_freq = 1000,
> - .wait_for_reset = 1,
> - .num_bits_resol = 11,
> - .reg_values = reg_values,
> -};
> -
>  static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
>   .reg_ofs = exynos_reg_ofs,
>   .plltmr_reg = 0x58,
> @@ -521,8 +510,6 @@ static const struct of_device_id exynos_dsi_of_match[] = {
> .data = _dsi_driver_data },
>   { .compatible = "samsung,exynos4210-mipi-dsi",
> .data = _dsi_driver_data },
> - { .compatible = "samsung,exynos4415-mipi-dsi",
> -   .data = _dsi_driver_data },
>   { .compatible = "samsung,exynos5410-mipi-dsi",
> .data = _dsi_driver_data },
>   { .compatible = "samsung,exynos5422-mipi-dsi",
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index a9fa444c6053..661b9fe049e2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -71,10 +71,10 @@
>  #define TRIGCON  0x1A4
>  #define TRGMODE_ENABLE   (1 << 0)
>  #define SWTRGCMD_ENABLE  (1 << 1)
> -/* Exynos3250, 3472, 4415, 5260 5410, 5420 and 5422 only supported. */
> +/* Exynos3250, 3472, 5260 5410, 5420 and 5422 only supported. */
>  #define HWTRGEN_ENABLE   (1 << 3)
>  #define HWTRGMASK_ENABLE (1 << 4)
> -/* Exynos3250, 3472, 4415, 5260, 5420 and 5422 only supported. */
> +/* Exynos3250, 3472, 5260, 5420 and 5422 only supported. */
>  #define 

Re: [RESEND] drm/exynos: Remove support for Exynos4415 (SoC not supported anymore)

[Inki Dae]

Merged.

Thanks.

2017년 03월 12일 03:04에 Krzysztof Kozlowski 이(가) 쓴 글:
> Support for Exynos4415 is going away because there are no internal nor
> external users.
> 
> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
> the platform cannot be instantiated so remove also the drivers.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Acked-by: Kukjin Kim 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/display/exynos/exynos_dsim.txt |  1 -
>  .../bindings/display/exynos/samsung-fimd.txt   |  1 -
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 15 +--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 18 
> ++
>  4 files changed, 3 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> index a78265993665..ca5204b3bc21 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> @@ -4,7 +4,6 @@ Required properties:
>- compatible: value should be one of the following
>   "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */
>   "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
> - "samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
>   "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs 
> */
>   "samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
>   "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
> diff --git 
> a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt 
> b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> index 18645e0228b0..5837402c3ade 100644
> --- a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> @@ -11,7 +11,6 @@ Required properties:
>   "samsung,s5pv210-fimd"; /* for S5PV210 SoC */
>   "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */
>   "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
> - "samsung,exynos4415-fimd"; /* for Exynos4415 SoC */
>   "samsung,exynos5250-fimd"; /* for Exynos5250 SoCs */
>   "samsung,exynos5420-fimd"; /* for Exynos5420/5422/5800 SoCs */
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 812e2ec0761d..ef6f9c6de098 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -86,7 +86,7 @@
>  #define DSIM_SYNC_INFORM (1 << 27)
>  #define DSIM_EOT_DISABLE (1 << 28)
>  #define DSIM_MFLUSH_VS   (1 << 29)
> -/* This flag is valid only for exynos3250/3472/4415/5260/5430 */
> +/* This flag is valid only for exynos3250/3472/5260/5430 */
>  #define DSIM_CLKLANE_STOP(1 << 30)
>  
>  /* DSIM_ESCMODE */
> @@ -473,17 +473,6 @@ static const struct exynos_dsi_driver_data 
> exynos4_dsi_driver_data = {
>   .reg_values = reg_values,
>  };
>  
> -static const struct exynos_dsi_driver_data exynos4415_dsi_driver_data = {
> - .reg_ofs = exynos_reg_ofs,
> - .plltmr_reg = 0x58,
> - .has_clklane_stop = 1,
> - .num_clks = 2,
> - .max_freq = 1000,
> - .wait_for_reset = 1,
> - .num_bits_resol = 11,
> - .reg_values = reg_values,
> -};
> -
>  static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
>   .reg_ofs = exynos_reg_ofs,
>   .plltmr_reg = 0x58,
> @@ -521,8 +510,6 @@ static const struct of_device_id exynos_dsi_of_match[] = {
> .data = _dsi_driver_data },
>   { .compatible = "samsung,exynos4210-mipi-dsi",
> .data = _dsi_driver_data },
> - { .compatible = "samsung,exynos4415-mipi-dsi",
> -   .data = _dsi_driver_data },
>   { .compatible = "samsung,exynos5410-mipi-dsi",
> .data = _dsi_driver_data },
>   { .compatible = "samsung,exynos5422-mipi-dsi",
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index a9fa444c6053..661b9fe049e2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -71,10 +71,10 @@
>  #define TRIGCON  0x1A4
>  #define TRGMODE_ENABLE   (1 << 0)
>  #define SWTRGCMD_ENABLE  (1 << 1)
> -/* Exynos3250, 3472, 4415, 5260 5410, 5420 and 5422 only supported. */
> +/* Exynos3250, 3472, 5260 5410, 5420 and 5422 only supported. */
>  #define HWTRGEN_ENABLE   (1 << 3)
>  #define HWTRGMASK_ENABLE (1 << 4)
> -/* Exynos3250, 3472, 4415, 5260, 5420 and 5422 only supported. */
> +/* Exynos3250, 3472, 5260, 5420 and 5422 only supported. */
>  #define HWTRIGEN_PER_ENABLE  (1 << 31)
>  
>  /* display 

Re: linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681: suspicious mask ?

[Inki Dae]

Hello David,

Thanks for report.

2017년 03월 06일 19:05에 David Binderman 이(가) 쓴 글:
> Hello there,
> 
> linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681]: (warning) 
> Result of operator '|' is always true if one operand is non-zero. Did you 
> intend to use '&'?
> 

Right. this is known issue and below patch fixes this,
http://www.spinics.net/lists/dri-devel/msg132589.html

This patch will go to -fixes.

> Source code is
> 
> if (ctx->out_type | I80_HW_TRG) {
> 
> Also in the same file:
> 
> [drivers/gpu/drm/exynos/exynos5433_drm_decon.c:131]: (style) Same expression 
> on both sides of '|'.
> 
> Source code is
> 
>writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>| TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,

In this case, only problem is two flags are set in duplicate. This should be 
cleaned up. Thanks. :)

> 
> Regards
> 
> David Binderman
> 
> 

Re: linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681: suspicious mask ?

[Inki Dae]

Hello David,

Thanks for report.

2017년 03월 06일 19:05에 David Binderman 이(가) 쓴 글:
> Hello there,
> 
> linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681]: (warning) 
> Result of operator '|' is always true if one operand is non-zero. Did you 
> intend to use '&'?
> 

Right. this is known issue and below patch fixes this,
http://www.spinics.net/lists/dri-devel/msg132589.html

This patch will go to -fixes.

> Source code is
> 
> if (ctx->out_type | I80_HW_TRG) {
> 
> Also in the same file:
> 
> [drivers/gpu/drm/exynos/exynos5433_drm_decon.c:131]: (style) Same expression 
> on both sides of '|'.
> 
> Source code is
> 
>writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>| TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,

In this case, only problem is two flags are set in duplicate. This should be 
cleaned up. Thanks. :)

> 
> Regards
> 
> David Binderman
> 
> 

Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 03일 15:38에 Inki Dae 이(가) 쓴 글:
> 
> 
> 2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글:
>> On TM2/TM2e platforms HDMI output is connected to MHL bridge
>> SiI8620. To allow configure UltraHD modes on the bridge
>> and to eliminate unsupported modes this bridge should be
>> attached to drm_encoder implemented in exynos_hdmi.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
>> +---
>>  1 file changed, 46 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a73b192..41fb894 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -35,6 +35,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -133,6 +134,7 @@ struct hdmi_context {
>>  struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>  struct regulator*reg_hdmi_en;
>>  struct exynos_drm_clk   phy_clk;
>> +struct drm_bridge   *bridge;
>>  };
>>  
>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
>> *encoder)
>>  drm_connector_register(connector);
>>  drm_mode_connector_attach_encoder(connector, encoder);
>>  
>> -return 0;
>> +if (hdata->bridge) {
>> +encoder->bridge = hdata->bridge;
>> +hdata->bridge->encoder = encoder;
>> +ret = drm_bridge_attach(encoder->dev, hdata->bridge);
> 
> arguments of drm_bridge_attach function has been changed so fixed it - 
> trivial thing.
> Applied it including other patches.

The argument was changed by below patch,
drm: bridge: Link encoder and bridge in core code

Thanks.

> 
> Thanks,
> Inki Dae
> 
>> +if (ret)
>> +DRM_ERROR("Failed to attach bridge\n");
>> +}
>> +
>> +return ret;
>>  }
>>  
>>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
>> *clk, bool enable)
>>  hdmiphy_disable(hdata);
>>  }
>>  
>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>> +{
>> +struct device *dev = hdata->dev;
>> +struct device_node *ep, *np;
>> +
>> +ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>> +if (!ep)
>> +return 0;
>> +
>> +np = of_graph_get_remote_port_parent(ep);
>> +of_node_put(ep);
>> +if (!np) {
>> +DRM_ERROR("failed to get remote port parent");
>> +return -EINVAL;
>> +}
>> +
>> +hdata->bridge = of_drm_find_bridge(np);
>> +of_node_put(np);
>> +
>> +if (!hdata->bridge)
>> +return -EPROBE_DEFER;
>> +
>> +return 0;
>> +}
>> +
>>  static int hdmi_resources_init(struct hdmi_context *hdata)
>>  {
>>  struct device *dev = hdata->dev;
>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
>> *hdata)
>>  
>>  hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>  
>> -if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>> -return 0;
>> +if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>> +if (IS_ERR(hdata->reg_hdmi_en))
>> +return PTR_ERR(hdata->reg_hdmi_en);
>>  
>> -if (IS_ERR(hdata->reg_hdmi_en))
>> -return PTR_ERR(hdata->reg_hdmi_en);
>> -
>> -ret = regulator_enable(hdata->reg_hdmi_en);
>> -if (ret)
>> -DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +ret = regulator_enable(hdata->reg_hdmi_en);
>> +if (ret) {
>> +DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +return ret;
>> +}
>> +}
>>  
>> -return ret;
>> +return hdmi_bridge_init(hdata);
>>  }
>>  
>>  static struct of_device_id hdmi_match_types[] = {
>>

Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 03일 15:38에 Inki Dae 이(가) 쓴 글:
> 
> 
> 2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글:
>> On TM2/TM2e platforms HDMI output is connected to MHL bridge
>> SiI8620. To allow configure UltraHD modes on the bridge
>> and to eliminate unsupported modes this bridge should be
>> attached to drm_encoder implemented in exynos_hdmi.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
>> +---
>>  1 file changed, 46 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a73b192..41fb894 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -35,6 +35,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -133,6 +134,7 @@ struct hdmi_context {
>>  struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>  struct regulator*reg_hdmi_en;
>>  struct exynos_drm_clk   phy_clk;
>> +struct drm_bridge   *bridge;
>>  };
>>  
>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
>> *encoder)
>>  drm_connector_register(connector);
>>  drm_mode_connector_attach_encoder(connector, encoder);
>>  
>> -return 0;
>> +if (hdata->bridge) {
>> +encoder->bridge = hdata->bridge;
>> +hdata->bridge->encoder = encoder;
>> +ret = drm_bridge_attach(encoder->dev, hdata->bridge);
> 
> arguments of drm_bridge_attach function has been changed so fixed it - 
> trivial thing.
> Applied it including other patches.

The argument was changed by below patch,
drm: bridge: Link encoder and bridge in core code

Thanks.

> 
> Thanks,
> Inki Dae
> 
>> +if (ret)
>> +DRM_ERROR("Failed to attach bridge\n");
>> +}
>> +
>> +return ret;
>>  }
>>  
>>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
>> *clk, bool enable)
>>  hdmiphy_disable(hdata);
>>  }
>>  
>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>> +{
>> +struct device *dev = hdata->dev;
>> +struct device_node *ep, *np;
>> +
>> +ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>> +if (!ep)
>> +return 0;
>> +
>> +np = of_graph_get_remote_port_parent(ep);
>> +of_node_put(ep);
>> +if (!np) {
>> +DRM_ERROR("failed to get remote port parent");
>> +return -EINVAL;
>> +}
>> +
>> +hdata->bridge = of_drm_find_bridge(np);
>> +of_node_put(np);
>> +
>> +if (!hdata->bridge)
>> +return -EPROBE_DEFER;
>> +
>> +return 0;
>> +}
>> +
>>  static int hdmi_resources_init(struct hdmi_context *hdata)
>>  {
>>  struct device *dev = hdata->dev;
>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
>> *hdata)
>>  
>>  hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>  
>> -if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>> -return 0;
>> +if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>> +if (IS_ERR(hdata->reg_hdmi_en))
>> +return PTR_ERR(hdata->reg_hdmi_en);
>>  
>> -if (IS_ERR(hdata->reg_hdmi_en))
>> -return PTR_ERR(hdata->reg_hdmi_en);
>> -
>> -ret = regulator_enable(hdata->reg_hdmi_en);
>> -if (ret)
>> -DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +ret = regulator_enable(hdata->reg_hdmi_en);
>> +if (ret) {
>> +DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +return ret;
>> +}
>> +}
>>  
>> -return ret;
>> +return hdmi_bridge_init(hdata);
>>  }
>>  
>>  static struct of_device_id hdmi_match_types[] = {
>>

Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글:
> On TM2/TM2e platforms HDMI output is connected to MHL bridge
> SiI8620. To allow configure UltraHD modes on the bridge
> and to eliminate unsupported modes this bridge should be
> attached to drm_encoder implemented in exynos_hdmi.
> 
> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
> +---
>  1 file changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a73b192..41fb894 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -133,6 +134,7 @@ struct hdmi_context {
>   struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>   struct regulator*reg_hdmi_en;
>   struct exynos_drm_clk   phy_clk;
> + struct drm_bridge   *bridge;
>  };
>  
>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
> *encoder)
>   drm_connector_register(connector);
>   drm_mode_connector_attach_encoder(connector, encoder);
>  
> - return 0;
> + if (hdata->bridge) {
> + encoder->bridge = hdata->bridge;
> + hdata->bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, hdata->bridge);

arguments of drm_bridge_attach function has been changed so fixed it - trivial 
thing.
Applied it including other patches.

Thanks,
Inki Dae

> + if (ret)
> + DRM_ERROR("Failed to attach bridge\n");
> + }
> +
> + return ret;
>  }
>  
>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
> *clk, bool enable)
>   hdmiphy_disable(hdata);
>  }
>  
> +static int hdmi_bridge_init(struct hdmi_context *hdata)
> +{
> + struct device *dev = hdata->dev;
> + struct device_node *ep, *np;
> +
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!ep)
> + return 0;
> +
> + np = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!np) {
> + DRM_ERROR("failed to get remote port parent");
> + return -EINVAL;
> + }
> +
> + hdata->bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> +
> + if (!hdata->bridge)
> + return -EPROBE_DEFER;
> +
> + return 0;
> +}
> +
>  static int hdmi_resources_init(struct hdmi_context *hdata)
>  {
>   struct device *dev = hdata->dev;
> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
> *hdata)
>  
>   hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>  
> - if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
> - return 0;
> + if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
> + if (IS_ERR(hdata->reg_hdmi_en))
> + return PTR_ERR(hdata->reg_hdmi_en);
>  
> - if (IS_ERR(hdata->reg_hdmi_en))
> - return PTR_ERR(hdata->reg_hdmi_en);
> -
> - ret = regulator_enable(hdata->reg_hdmi_en);
> - if (ret)
> - DRM_ERROR("failed to enable hdmi-en regulator\n");
> + ret = regulator_enable(hdata->reg_hdmi_en);
> + if (ret) {
> + DRM_ERROR("failed to enable hdmi-en regulator\n");
> + return ret;
> + }
> + }
>  
> - return ret;
> + return hdmi_bridge_init(hdata);
>  }
>  
>  static struct of_device_id hdmi_match_types[] = {
> 

Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글:
> On TM2/TM2e platforms HDMI output is connected to MHL bridge
> SiI8620. To allow configure UltraHD modes on the bridge
> and to eliminate unsupported modes this bridge should be
> attached to drm_encoder implemented in exynos_hdmi.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
> +---
>  1 file changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a73b192..41fb894 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -133,6 +134,7 @@ struct hdmi_context {
>   struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>   struct regulator*reg_hdmi_en;
>   struct exynos_drm_clk   phy_clk;
> + struct drm_bridge   *bridge;
>  };
>  
>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
> *encoder)
>   drm_connector_register(connector);
>   drm_mode_connector_attach_encoder(connector, encoder);
>  
> - return 0;
> + if (hdata->bridge) {
> + encoder->bridge = hdata->bridge;
> + hdata->bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, hdata->bridge);

arguments of drm_bridge_attach function has been changed so fixed it - trivial 
thing.
Applied it including other patches.

Thanks,
Inki Dae

> + if (ret)
> + DRM_ERROR("Failed to attach bridge\n");
> + }
> +
> + return ret;
>  }
>  
>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
> *clk, bool enable)
>   hdmiphy_disable(hdata);
>  }
>  
> +static int hdmi_bridge_init(struct hdmi_context *hdata)
> +{
> + struct device *dev = hdata->dev;
> + struct device_node *ep, *np;
> +
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!ep)
> + return 0;
> +
> + np = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!np) {
> + DRM_ERROR("failed to get remote port parent");
> + return -EINVAL;
> + }
> +
> + hdata->bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> +
> + if (!hdata->bridge)
> + return -EPROBE_DEFER;
> +
> + return 0;
> +}
> +
>  static int hdmi_resources_init(struct hdmi_context *hdata)
>  {
>   struct device *dev = hdata->dev;
> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
> *hdata)
>  
>   hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>  
> - if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
> - return 0;
> + if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
> + if (IS_ERR(hdata->reg_hdmi_en))
> + return PTR_ERR(hdata->reg_hdmi_en);
>  
> - if (IS_ERR(hdata->reg_hdmi_en))
> - return PTR_ERR(hdata->reg_hdmi_en);
> -
> - ret = regulator_enable(hdata->reg_hdmi_en);
> - if (ret)
> - DRM_ERROR("failed to enable hdmi-en regulator\n");
> + ret = regulator_enable(hdata->reg_hdmi_en);
> + if (ret) {
> + DRM_ERROR("failed to enable hdmi-en regulator\n");
> + return ret;
> + }
> + }
>  
> - return ret;
> + return hdmi_bridge_init(hdata);
>  }
>  
>  static struct of_device_id hdmi_match_types[] = {
> 

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 02월 02일 04:03에 Sean Paul 이(가) 쓴 글:
> On Wed, Feb 01, 2017 at 03:29:40PM +, Emil Velikov wrote:
>> On 1 February 2017 at 14:52, Thierry Reding <thierry.red...@gmail.com> wrote:
>>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>>>> Thierry Reding <thierry.red...@gmail.com> writes:
>>>>
>>>>> [ Unknown signature status ]
>>>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>>>> Thierry Reding <thierry.red...@gmail.com> writes:
>>>>>>
>>>>>>> [ Unknown signature status ]
>>>>>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote:
>>>>>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote:
>>>>>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>>>>>> Dear Thierry,
>>>>>>>>>>>
>>>>>>>>>>> Could you please review this patch?
>>>>>>>>>>
>>>>>>>>>> Thierry, I think this patch has been reviewed enough but no comment
>>>>>>>>>> from you. Seems you are busy. I will pick up this.
>>>>>>>>>
>>>>>>>>> Sorry, but that's not how it works. This patch has gone through 8
>>>>>>>>> revisions within 4 weeks, and I tend to ignore patches like that until
>>>>>>>>> the dust settles.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged 
>>>>>>>> on 1/24,
>>>>>>>> and picked up on 1/31. I don't think it's unreasonable to take it 
>>>>>>>> through
>>>>>>>> another tree after that.
>>>>>>>>
>>>>>>>> I wonder if drm_panel would benefit from the -misc group 
>>>>>>>> maintainership model
>>>>>>>> as drm_bridge does. By spreading out the workload, the high-maintenance
>>>>>>>> patches would hopefully find someone to shepherd them through.
>>>>>>>
>>>>>>> Except that nobody except me really cares. If we let people take patches
>>>>>>> through separate trees or group-maintained trees they'll likely go in
>>>>>>> without too much thought. DRM panel is somewhat different from core DRM
>>>>>>> in this regard because its infrastructure is minimal and there's little
>>>>>>> outside the panel-simple driver. So we're still at a stage where we need
>>>>>>> to fine-tune what drivers should look like and how we can improve.
>>>>>>
>>>>>> I would love to care and participate in review, but with the structure
>>>>>> of your tree you're the only one whose review counts, so I don't
>>>>>> participate.
>>>>>
>>>>> Really? What exactly do you think is special about the structure of my
>>>>> tree? I require patches to be on dri-devel (I pick them up from the
>>>>> patchwork instance at freedesktop.org), the tree is publicly available
>>>>> and reviewed-by tags get picked up automatically by patchwork.
>>>>>
>>>>> The panel tree works exactly like any other maintainer tree. And my
>>>>> review is *not* the only one that counts. I appreciate every Reviewed-by
>>>>> tag I see on panel patches because it means that I don't have to look as
>>>>> closely as I have to otherwise.
>>>>>
>>>>> It is true that I am responsible for those patches, that's why I get to
>>>>> have the final word on whether or not a patch gets applied. And that's
>>>>> no different from any other maintainer tree either.
>>>>
>>>> If me reviewing a patch isn't part of unblocking that patch getting in,
>>>> then I won't bother because all I could end up doing is punishing the
>>>> developer of the patch.  Contributors have a hard enough time already.
>>>
>>> Maybe you should go and read my previous reply again more carefully.
>>> Perhaps then you'll realize that reviews are in fact helping in getting
>>&g

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 02월 02일 04:03에 Sean Paul 이(가) 쓴 글:
> On Wed, Feb 01, 2017 at 03:29:40PM +, Emil Velikov wrote:
>> On 1 February 2017 at 14:52, Thierry Reding  wrote:
>>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>>>> Thierry Reding  writes:
>>>>
>>>>> [ Unknown signature status ]
>>>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>>>> Thierry Reding  writes:
>>>>>>
>>>>>>> [ Unknown signature status ]
>>>>>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote:
>>>>>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote:
>>>>>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>>>>>> Dear Thierry,
>>>>>>>>>>>
>>>>>>>>>>> Could you please review this patch?
>>>>>>>>>>
>>>>>>>>>> Thierry, I think this patch has been reviewed enough but no comment
>>>>>>>>>> from you. Seems you are busy. I will pick up this.
>>>>>>>>>
>>>>>>>>> Sorry, but that's not how it works. This patch has gone through 8
>>>>>>>>> revisions within 4 weeks, and I tend to ignore patches like that until
>>>>>>>>> the dust settles.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged 
>>>>>>>> on 1/24,
>>>>>>>> and picked up on 1/31. I don't think it's unreasonable to take it 
>>>>>>>> through
>>>>>>>> another tree after that.
>>>>>>>>
>>>>>>>> I wonder if drm_panel would benefit from the -misc group 
>>>>>>>> maintainership model
>>>>>>>> as drm_bridge does. By spreading out the workload, the high-maintenance
>>>>>>>> patches would hopefully find someone to shepherd them through.
>>>>>>>
>>>>>>> Except that nobody except me really cares. If we let people take patches
>>>>>>> through separate trees or group-maintained trees they'll likely go in
>>>>>>> without too much thought. DRM panel is somewhat different from core DRM
>>>>>>> in this regard because its infrastructure is minimal and there's little
>>>>>>> outside the panel-simple driver. So we're still at a stage where we need
>>>>>>> to fine-tune what drivers should look like and how we can improve.
>>>>>>
>>>>>> I would love to care and participate in review, but with the structure
>>>>>> of your tree you're the only one whose review counts, so I don't
>>>>>> participate.
>>>>>
>>>>> Really? What exactly do you think is special about the structure of my
>>>>> tree? I require patches to be on dri-devel (I pick them up from the
>>>>> patchwork instance at freedesktop.org), the tree is publicly available
>>>>> and reviewed-by tags get picked up automatically by patchwork.
>>>>>
>>>>> The panel tree works exactly like any other maintainer tree. And my
>>>>> review is *not* the only one that counts. I appreciate every Reviewed-by
>>>>> tag I see on panel patches because it means that I don't have to look as
>>>>> closely as I have to otherwise.
>>>>>
>>>>> It is true that I am responsible for those patches, that's why I get to
>>>>> have the final word on whether or not a patch gets applied. And that's
>>>>> no different from any other maintainer tree either.
>>>>
>>>> If me reviewing a patch isn't part of unblocking that patch getting in,
>>>> then I won't bother because all I could end up doing is punishing the
>>>> developer of the patch.  Contributors have a hard enough time already.
>>>
>>> Maybe you should go and read my previous reply again more carefully.
>>> Perhaps then you'll realize that reviews are in fact helping in getting
>>> patches merged.
>>>
>>> Interestingly my inbox doesn't show you ever bother

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글:
> On 1 February 2017 at 14:52, Thierry Reding <thierry.red...@gmail.com> wrote:
>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>>> Thierry Reding <thierry.red...@gmail.com> writes:
>>>
>>>> [ Unknown signature status ]
>>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>>> Thierry Reding <thierry.red...@gmail.com> writes:
>>>>>
>>>>>> [ Unknown signature status ]
>>>>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote:
>>>>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote:
>>>>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>>>>> Dear Thierry,
>>>>>>>>>>
>>>>>>>>>> Could you please review this patch?
>>>>>>>>>
>>>>>>>>> Thierry, I think this patch has been reviewed enough but no comment
>>>>>>>>> from you. Seems you are busy. I will pick up this.
>>>>>>>>
>>>>>>>> Sorry, but that's not how it works. This patch has gone through 8
>>>>>>>> revisions within 4 weeks, and I tend to ignore patches like that until
>>>>>>>> the dust settles.
>>>>>>>>
>>>>>>>
>>>>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged 
>>>>>>> on 1/24,
>>>>>>> and picked up on 1/31. I don't think it's unreasonable to take it 
>>>>>>> through
>>>>>>> another tree after that.
>>>>>>>
>>>>>>> I wonder if drm_panel would benefit from the -misc group maintainership 
>>>>>>> model
>>>>>>> as drm_bridge does. By spreading out the workload, the high-maintenance
>>>>>>> patches would hopefully find someone to shepherd them through.
>>>>>>
>>>>>> Except that nobody except me really cares. If we let people take patches
>>>>>> through separate trees or group-maintained trees they'll likely go in
>>>>>> without too much thought. DRM panel is somewhat different from core DRM
>>>>>> in this regard because its infrastructure is minimal and there's little
>>>>>> outside the panel-simple driver. So we're still at a stage where we need
>>>>>> to fine-tune what drivers should look like and how we can improve.
>>>>>
>>>>> I would love to care and participate in review, but with the structure
>>>>> of your tree you're the only one whose review counts, so I don't
>>>>> participate.
>>>>
>>>> Really? What exactly do you think is special about the structure of my
>>>> tree? I require patches to be on dri-devel (I pick them up from the
>>>> patchwork instance at freedesktop.org), the tree is publicly available
>>>> and reviewed-by tags get picked up automatically by patchwork.
>>>>
>>>> The panel tree works exactly like any other maintainer tree. And my
>>>> review is *not* the only one that counts. I appreciate every Reviewed-by
>>>> tag I see on panel patches because it means that I don't have to look as
>>>> closely as I have to otherwise.
>>>>
>>>> It is true that I am responsible for those patches, that's why I get to
>>>> have the final word on whether or not a patch gets applied. And that's
>>>> no different from any other maintainer tree either.
>>>
>>> If me reviewing a patch isn't part of unblocking that patch getting in,
>>> then I won't bother because all I could end up doing is punishing the
>>> developer of the patch.  Contributors have a hard enough time already.
>>
>> Maybe you should go and read my previous reply again more carefully.
>> Perhaps then you'll realize that reviews are in fact helping in getting
>> patches merged.
>>
>> Interestingly my inbox doesn't show you ever bothering to review panel
>> patches, so maybe you should be more careful about your assumptions.
>>
> Gents, it's understandable that emotions might be running high.
> 
> What's the point in pointing fingers at each other - there is enough
> to go in each direction.
> Let us all step back for a second and consider how we can make things better.
> 
> I think it'll be nice to have some/most of the common concerns that
> Thierry/others comes across documented - in-kernel, blog post, other.
> Such that one can reference to specific points as patch falls sub-par.
> We all want to have a balance of nicely written driver and quick
> merge.
> 
> Inki, I believe myself and others have invited you before on
> #dri-devel. This is another medium where you can poke devs and from my
> experience - it tends to be more efficient, most of the time.

It's true and totally agree. I can really understand Thierry but I think we 
need to think about maintainer's role for our community.
And also I think the big and small collisions between maintainers and 
contributors are just the process of getting better.

Thanks,
Inki Dae

> 
> Thanks
> Emil
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글:
> On 1 February 2017 at 14:52, Thierry Reding  wrote:
>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>>> Thierry Reding  writes:
>>>
>>>> [ Unknown signature status ]
>>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>>> Thierry Reding  writes:
>>>>>
>>>>>> [ Unknown signature status ]
>>>>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote:
>>>>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote:
>>>>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>>>>> Dear Thierry,
>>>>>>>>>>
>>>>>>>>>> Could you please review this patch?
>>>>>>>>>
>>>>>>>>> Thierry, I think this patch has been reviewed enough but no comment
>>>>>>>>> from you. Seems you are busy. I will pick up this.
>>>>>>>>
>>>>>>>> Sorry, but that's not how it works. This patch has gone through 8
>>>>>>>> revisions within 4 weeks, and I tend to ignore patches like that until
>>>>>>>> the dust settles.
>>>>>>>>
>>>>>>>
>>>>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged 
>>>>>>> on 1/24,
>>>>>>> and picked up on 1/31. I don't think it's unreasonable to take it 
>>>>>>> through
>>>>>>> another tree after that.
>>>>>>>
>>>>>>> I wonder if drm_panel would benefit from the -misc group maintainership 
>>>>>>> model
>>>>>>> as drm_bridge does. By spreading out the workload, the high-maintenance
>>>>>>> patches would hopefully find someone to shepherd them through.
>>>>>>
>>>>>> Except that nobody except me really cares. If we let people take patches
>>>>>> through separate trees or group-maintained trees they'll likely go in
>>>>>> without too much thought. DRM panel is somewhat different from core DRM
>>>>>> in this regard because its infrastructure is minimal and there's little
>>>>>> outside the panel-simple driver. So we're still at a stage where we need
>>>>>> to fine-tune what drivers should look like and how we can improve.
>>>>>
>>>>> I would love to care and participate in review, but with the structure
>>>>> of your tree you're the only one whose review counts, so I don't
>>>>> participate.
>>>>
>>>> Really? What exactly do you think is special about the structure of my
>>>> tree? I require patches to be on dri-devel (I pick them up from the
>>>> patchwork instance at freedesktop.org), the tree is publicly available
>>>> and reviewed-by tags get picked up automatically by patchwork.
>>>>
>>>> The panel tree works exactly like any other maintainer tree. And my
>>>> review is *not* the only one that counts. I appreciate every Reviewed-by
>>>> tag I see on panel patches because it means that I don't have to look as
>>>> closely as I have to otherwise.
>>>>
>>>> It is true that I am responsible for those patches, that's why I get to
>>>> have the final word on whether or not a patch gets applied. And that's
>>>> no different from any other maintainer tree either.
>>>
>>> If me reviewing a patch isn't part of unblocking that patch getting in,
>>> then I won't bother because all I could end up doing is punishing the
>>> developer of the patch.  Contributors have a hard enough time already.
>>
>> Maybe you should go and read my previous reply again more carefully.
>> Perhaps then you'll realize that reviews are in fact helping in getting
>> patches merged.
>>
>> Interestingly my inbox doesn't show you ever bothering to review panel
>> patches, so maybe you should be more careful about your assumptions.
>>
> Gents, it's understandable that emotions might be running high.
> 
> What's the point in pointing fingers at each other - there is enough
> to go in each direction.
> Let us all step back for a second and consider how we can make things better.
> 
> I think it'll be nice to have some/most of the common concerns that
> Thierry/others comes across documented - in-kernel, blog post, other.
> Such that one can reference to specific points as patch falls sub-par.
> We all want to have a balance of nicely written driver and quick
> merge.
> 
> Inki, I believe myself and others have invited you before on
> #dri-devel. This is another medium where you can poke devs and from my
> experience - it tends to be more efficient, most of the time.

It's true and totally agree. I can really understand Thierry but I think we 
need to think about maintainer's role for our community.
And also I think the big and small collisions between maintainers and 
contributors are just the process of getting better.

Thanks,
Inki Dae

> 
> Thanks
> Emil
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

Dear Thierry,


2017년 02월 01일 23:44에 Thierry Reding 이(가) 쓴 글:
> On Wed, Feb 01, 2017 at 08:48:30AM +0900, Inki Dae wrote:
>>
>>
>> 2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>> Thierry Reding <thierry.red...@gmail.com> writes:
>>>>
>>>>> [ Unknown signature status ]
>>>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote:
>>>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote:
>>>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>>>> Dear Thierry,
>>>>>>>>>
>>>>>>>>> Could you please review this patch?
>>>>>>>>
>>>>>>>> Thierry, I think this patch has been reviewed enough but no comment
>>>>>>>> from you. Seems you are busy. I will pick up this.
>>>>>>>
>>>>>>> Sorry, but that's not how it works. This patch has gone through 8
>>>>>>> revisions within 4 weeks, and I tend to ignore patches like that until
>>>>>>> the dust settles.
>>>>>>>
>>>>>>
>>>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged on 
>>>>>> 1/24,
>>>>>> and picked up on 1/31. I don't think it's unreasonable to take it through
>>>>>> another tree after that.
>>>>>>
>>>>>> I wonder if drm_panel would benefit from the -misc group maintainership 
>>>>>> model
>>>>>> as drm_bridge does. By spreading out the workload, the high-maintenance
>>>>>> patches would hopefully find someone to shepherd them through.
>>>>>
>>>>> Except that nobody except me really cares. If we let people take patches
>>>>> through separate trees or group-maintained trees they'll likely go in
>>>>> without too much thought. DRM panel is somewhat different from core DRM
>>>>> in this regard because its infrastructure is minimal and there's little
>>>>> outside the panel-simple driver. So we're still at a stage where we need
>>>>> to fine-tune what drivers should look like and how we can improve.
>>>>
>>>> I would love to care and participate in review, but with the structure
>>>> of your tree you're the only one whose review counts, so I don't
>>>> participate.
>>>
>>> Really? What exactly do you think is special about the structure of my
>>> tree? I require patches to be on dri-devel (I pick them up from the
>>> patchwork instance at freedesktop.org), the tree is publicly available
>>> and reviewed-by tags get picked up automatically by patchwork.
>>>
>>> The panel tree works exactly like any other maintainer tree. And my
>>> review is *not* the only one that counts. I appreciate every Reviewed-by
>>> tag I see on panel patches because it means that I don't have to look as
>>> closely as I have to otherwise.
>>
>> I don't think the panel tree works exactly like other maintainer tree.
>>
>> I'd like to recommend you to read below Greg's blog. This blog says
>> about *Role of a Linux Kernel Maintainer*.
>> http://www.kroah.com/log/linux/maintainer_pledge.html
> 
> Okay, now you're being unfair. You can't compare people to Greg. He
> is beyond human.
> 
>> Especially, I'd like to emphasize below things,
>> - I will review your patch within 1-2 weeks.
>> - I will offer semi-constructive criticism of your patches.
>> - I will let you know the status of your patch if it is rejected, or
>> if it is accepted, what tree it has gone into, where you can find it,
>> and when you can expect to see it merged into Linus's tree.
> 
> First, this is a pledge by Greg, and you can hardly hold me to this if
> it isn't coming from me. I agree that the above is ideal, but I'm also
> much less efficient as a maintainer as Greg. So are many others. There
> simply isn't enough bandwidth to be able to do the above in every case
> in addition to the day job and real life.
> 
> That said, when I do get around to review patches I think I'm pretty
> good at the second and third points, though.

Agree. You did well really.

> 
> Secondly, it's very convenient how you focus on the maintainers' duties
> and c

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

Dear Thierry,


2017년 02월 01일 23:44에 Thierry Reding 이(가) 쓴 글:
> On Wed, Feb 01, 2017 at 08:48:30AM +0900, Inki Dae wrote:
>>
>>
>> 2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>> Thierry Reding  writes:
>>>>
>>>>> [ Unknown signature status ]
>>>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote:
>>>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote:
>>>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>>>> Dear Thierry,
>>>>>>>>>
>>>>>>>>> Could you please review this patch?
>>>>>>>>
>>>>>>>> Thierry, I think this patch has been reviewed enough but no comment
>>>>>>>> from you. Seems you are busy. I will pick up this.
>>>>>>>
>>>>>>> Sorry, but that's not how it works. This patch has gone through 8
>>>>>>> revisions within 4 weeks, and I tend to ignore patches like that until
>>>>>>> the dust settles.
>>>>>>>
>>>>>>
>>>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged on 
>>>>>> 1/24,
>>>>>> and picked up on 1/31. I don't think it's unreasonable to take it through
>>>>>> another tree after that.
>>>>>>
>>>>>> I wonder if drm_panel would benefit from the -misc group maintainership 
>>>>>> model
>>>>>> as drm_bridge does. By spreading out the workload, the high-maintenance
>>>>>> patches would hopefully find someone to shepherd them through.
>>>>>
>>>>> Except that nobody except me really cares. If we let people take patches
>>>>> through separate trees or group-maintained trees they'll likely go in
>>>>> without too much thought. DRM panel is somewhat different from core DRM
>>>>> in this regard because its infrastructure is minimal and there's little
>>>>> outside the panel-simple driver. So we're still at a stage where we need
>>>>> to fine-tune what drivers should look like and how we can improve.
>>>>
>>>> I would love to care and participate in review, but with the structure
>>>> of your tree you're the only one whose review counts, so I don't
>>>> participate.
>>>
>>> Really? What exactly do you think is special about the structure of my
>>> tree? I require patches to be on dri-devel (I pick them up from the
>>> patchwork instance at freedesktop.org), the tree is publicly available
>>> and reviewed-by tags get picked up automatically by patchwork.
>>>
>>> The panel tree works exactly like any other maintainer tree. And my
>>> review is *not* the only one that counts. I appreciate every Reviewed-by
>>> tag I see on panel patches because it means that I don't have to look as
>>> closely as I have to otherwise.
>>
>> I don't think the panel tree works exactly like other maintainer tree.
>>
>> I'd like to recommend you to read below Greg's blog. This blog says
>> about *Role of a Linux Kernel Maintainer*.
>> http://www.kroah.com/log/linux/maintainer_pledge.html
> 
> Okay, now you're being unfair. You can't compare people to Greg. He
> is beyond human.
> 
>> Especially, I'd like to emphasize below things,
>> - I will review your patch within 1-2 weeks.
>> - I will offer semi-constructive criticism of your patches.
>> - I will let you know the status of your patch if it is rejected, or
>> if it is accepted, what tree it has gone into, where you can find it,
>> and when you can expect to see it merged into Linus's tree.
> 
> First, this is a pledge by Greg, and you can hardly hold me to this if
> it isn't coming from me. I agree that the above is ideal, but I'm also
> much less efficient as a maintainer as Greg. So are many others. There
> simply isn't enough bandwidth to be able to do the above in every case
> in addition to the day job and real life.
> 
> That said, when I do get around to review patches I think I'm pretty
> good at the second and third points, though.

Agree. You did well really.

> 
> Secondly, it's very convenient how you focus on the maintainers' duties
> and completely leave out what maintainers expect

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 01일 17:12에 Andrzej Hajda 이(가) 쓴 글:
> On 01.02.2017 08:44, Inki Dae wrote:
>>
>> 2017년 02월 01일 16:34에 Andrzej Hajda 이(가) 쓴 글:
>>> On 01.02.2017 08:31, Inki Dae wrote:
>>>> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
>>>>> In some platforms there is attached another device to the end of HDMI.
>>>>> The patch adds support for it.
>>>> Andrzej, can you clarify what bridge device can be attached and actually 
>>>> is now attached to the end of HDMI?
>>>> And I wonder if we have the device tree file which defines the bridge 
>>>> device in mainline. Seems we have no the device tree file.
>>>>
>>>> If nothing, then this patch should be merged with real use case.
>>> SiI8620 MHL bridge in tm2/tm2e.
>> Did you post dt patch to add the properties related to SiI8620 MHL bridge 
>> device?
>>
>> I see below patch series,
>> [PATCH 00/24] drm/bridge/sii8620: add Ultra HD modes support
>>
>> but I couldn't find dt patch for it. And specifying SiI8620 MHL bridge 
>> device as description would be needed.
>>
>> Thanks.
>>
>>
> 
> Patch adding HDMI path to tm2(e) including SiI8620 node and OF bindings
> between hdmi and SiI8620 [1].

Oops, you already CCed me. I didn't check it. Sorry.

> As the bridge framework in lower modes was used only to eliminate
> unsupported modes, support for bridge in exynos_hdmi driver was not
> critical, HDMI path worked well and I forgot about it.
> But for UltraHD modes it is required as SiI8620 uses bridge framework to
> gather info about applied video mode to program registers accordingly.
> I will add requested description to this patch.

Thanks.

> 
> [1]: http://www.spinics.net/lists/devicetree/msg157892.html
> 
> Regards
> Andrzej
> 
> 

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 01일 17:12에 Andrzej Hajda 이(가) 쓴 글:
> On 01.02.2017 08:44, Inki Dae wrote:
>>
>> 2017년 02월 01일 16:34에 Andrzej Hajda 이(가) 쓴 글:
>>> On 01.02.2017 08:31, Inki Dae wrote:
>>>> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
>>>>> In some platforms there is attached another device to the end of HDMI.
>>>>> The patch adds support for it.
>>>> Andrzej, can you clarify what bridge device can be attached and actually 
>>>> is now attached to the end of HDMI?
>>>> And I wonder if we have the device tree file which defines the bridge 
>>>> device in mainline. Seems we have no the device tree file.
>>>>
>>>> If nothing, then this patch should be merged with real use case.
>>> SiI8620 MHL bridge in tm2/tm2e.
>> Did you post dt patch to add the properties related to SiI8620 MHL bridge 
>> device?
>>
>> I see below patch series,
>> [PATCH 00/24] drm/bridge/sii8620: add Ultra HD modes support
>>
>> but I couldn't find dt patch for it. And specifying SiI8620 MHL bridge 
>> device as description would be needed.
>>
>> Thanks.
>>
>>
> 
> Patch adding HDMI path to tm2(e) including SiI8620 node and OF bindings
> between hdmi and SiI8620 [1].

Oops, you already CCed me. I didn't check it. Sorry.

> As the bridge framework in lower modes was used only to eliminate
> unsupported modes, support for bridge in exynos_hdmi driver was not
> critical, HDMI path worked well and I forgot about it.
> But for UltraHD modes it is required as SiI8620 uses bridge framework to
> gather info about applied video mode to program registers accordingly.
> I will add requested description to this patch.

Thanks.

> 
> [1]: http://www.spinics.net/lists/devicetree/msg157892.html
> 
> Regards
> Andrzej
> 
> 

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 01일 16:34에 Andrzej Hajda 이(가) 쓴 글:
> On 01.02.2017 08:31, Inki Dae wrote:
>>
>> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
>>> In some platforms there is attached another device to the end of HDMI.
>>> The patch adds support for it.
>> Andrzej, can you clarify what bridge device can be attached and actually is 
>> now attached to the end of HDMI?
>> And I wonder if we have the device tree file which defines the bridge device 
>> in mainline. Seems we have no the device tree file.
>>
>> If nothing, then this patch should be merged with real use case.
> 
> SiI8620 MHL bridge in tm2/tm2e.

Did you post dt patch to add the properties related to SiI8620 MHL bridge 
device?

I see below patch series,
[PATCH 00/24] drm/bridge/sii8620: add Ultra HD modes support

but I couldn't find dt patch for it. And specifying SiI8620 MHL bridge device 
as description would be needed.

Thanks.

> 
> Regards
> Andrzej
> 
>>
>> Thanks.
>>
>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
>>> +---
>>>  1 file changed, 46 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index a73b192..41fb894 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -35,6 +35,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -133,6 +134,7 @@ struct hdmi_context {
>>> struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>> struct regulator*reg_hdmi_en;
>>> struct exynos_drm_clk   phy_clk;
>>> +   struct drm_bridge   *bridge;
>>>  };
>>>  
>>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
>>> *encoder)
>>> drm_connector_register(connector);
>>> drm_mode_connector_attach_encoder(connector, encoder);
>>>  
>>> -   return 0;
>>> +   if (hdata->bridge) {
>>> +   encoder->bridge = hdata->bridge;
>>> +   hdata->bridge->encoder = encoder;
>>> +   ret = drm_bridge_attach(encoder->dev, hdata->bridge);
>>> +   if (ret)
>>> +   DRM_ERROR("Failed to attach bridge\n");
>>> +   }
>>> +
>>> +   return ret;
>>>  }
>>>  
>>>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
>>> *clk, bool enable)
>>> hdmiphy_disable(hdata);
>>>  }
>>>  
>>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>>> +{
>>> +   struct device *dev = hdata->dev;
>>> +   struct device_node *ep, *np;
>>> +
>>> +   ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>>> +   if (!ep)
>>> +   return 0;
>>> +
>>> +   np = of_graph_get_remote_port_parent(ep);
>>> +   of_node_put(ep);
>>> +   if (!np) {
>>> +   DRM_ERROR("failed to get remote port parent");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   hdata->bridge = of_drm_find_bridge(np);
>>> +   of_node_put(np);
>>> +
>>> +   if (!hdata->bridge)
>>> +   return -EPROBE_DEFER;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  static int hdmi_resources_init(struct hdmi_context *hdata)
>>>  {
>>> struct device *dev = hdata->dev;
>>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
>>> *hdata)
>>>  
>>> hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>>  
>>> -   if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>>> -   return 0;
>>> +   if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>>> +   if (IS_ERR(hdata->reg_hdmi_en))
>>> +   return PTR_ERR(hdata->reg_hdmi_en);
>>>  
>>> -   if (IS_ERR(hdata->reg_hdmi_en))
>>> -   return PTR_ERR(hdata->reg_hdmi_en);
>>> -
>>> -   ret = regulator_enable(hdata->reg_hdmi_en);
>>> -   if (ret)
>>> -   DRM_ERROR("failed to enable hdmi-en regulator\n");
>>> +   ret = regulator_enable(hdata->reg_hdmi_en);
>>> +   if (ret) {
>>> +   DRM_ERROR("failed to enable hdmi-en regulator\n");
>>> +   return ret;
>>> +   }
>>> +   }
>>>  
>>> -   return ret;
>>> +   return hdmi_bridge_init(hdata);
>>>  }
>>>  
>>>  static struct of_device_id hdmi_match_types[] = {
>>>
>>
> 
> --
> 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 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 01일 16:34에 Andrzej Hajda 이(가) 쓴 글:
> On 01.02.2017 08:31, Inki Dae wrote:
>>
>> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
>>> In some platforms there is attached another device to the end of HDMI.
>>> The patch adds support for it.
>> Andrzej, can you clarify what bridge device can be attached and actually is 
>> now attached to the end of HDMI?
>> And I wonder if we have the device tree file which defines the bridge device 
>> in mainline. Seems we have no the device tree file.
>>
>> If nothing, then this patch should be merged with real use case.
> 
> SiI8620 MHL bridge in tm2/tm2e.

Did you post dt patch to add the properties related to SiI8620 MHL bridge 
device?

I see below patch series,
[PATCH 00/24] drm/bridge/sii8620: add Ultra HD modes support

but I couldn't find dt patch for it. And specifying SiI8620 MHL bridge device 
as description would be needed.

Thanks.

> 
> Regards
> Andrzej
> 
>>
>> Thanks.
>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
>>> +---
>>>  1 file changed, 46 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index a73b192..41fb894 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -35,6 +35,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -133,6 +134,7 @@ struct hdmi_context {
>>> struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>> struct regulator*reg_hdmi_en;
>>> struct exynos_drm_clk   phy_clk;
>>> +   struct drm_bridge   *bridge;
>>>  };
>>>  
>>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
>>> *encoder)
>>> drm_connector_register(connector);
>>> drm_mode_connector_attach_encoder(connector, encoder);
>>>  
>>> -   return 0;
>>> +   if (hdata->bridge) {
>>> +   encoder->bridge = hdata->bridge;
>>> +   hdata->bridge->encoder = encoder;
>>> +   ret = drm_bridge_attach(encoder->dev, hdata->bridge);
>>> +   if (ret)
>>> +   DRM_ERROR("Failed to attach bridge\n");
>>> +   }
>>> +
>>> +   return ret;
>>>  }
>>>  
>>>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
>>> *clk, bool enable)
>>> hdmiphy_disable(hdata);
>>>  }
>>>  
>>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>>> +{
>>> +   struct device *dev = hdata->dev;
>>> +   struct device_node *ep, *np;
>>> +
>>> +   ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>>> +   if (!ep)
>>> +   return 0;
>>> +
>>> +   np = of_graph_get_remote_port_parent(ep);
>>> +   of_node_put(ep);
>>> +   if (!np) {
>>> +   DRM_ERROR("failed to get remote port parent");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   hdata->bridge = of_drm_find_bridge(np);
>>> +   of_node_put(np);
>>> +
>>> +   if (!hdata->bridge)
>>> +   return -EPROBE_DEFER;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  static int hdmi_resources_init(struct hdmi_context *hdata)
>>>  {
>>> struct device *dev = hdata->dev;
>>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
>>> *hdata)
>>>  
>>> hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>>  
>>> -   if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>>> -   return 0;
>>> +   if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>>> +   if (IS_ERR(hdata->reg_hdmi_en))
>>> +   return PTR_ERR(hdata->reg_hdmi_en);
>>>  
>>> -   if (IS_ERR(hdata->reg_hdmi_en))
>>> -   return PTR_ERR(hdata->reg_hdmi_en);
>>> -
>>> -   ret = regulator_enable(hdata->reg_hdmi_en);
>>> -   if (ret)
>>> -   DRM_ERROR("failed to enable hdmi-en regulator\n");
>>> +   ret = regulator_enable(hdata->reg_hdmi_en);
>>> +   if (ret) {
>>> +   DRM_ERROR("failed to enable hdmi-en regulator\n");
>>> +   return ret;
>>> +   }
>>> +   }
>>>  
>>> -   return ret;
>>> +   return hdmi_bridge_init(hdata);
>>>  }
>>>  
>>>  static struct of_device_id hdmi_match_types[] = {
>>>
>>
> 
> --
> 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 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
> In some platforms there is attached another device to the end of HDMI.
> The patch adds support for it.

Andrzej, can you clarify what bridge device can be attached and actually is now 
attached to the end of HDMI?
And I wonder if we have the device tree file which defines the bridge device in 
mainline. Seems we have no the device tree file.

If nothing, then this patch should be merged with real use case.

Thanks.

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
> +---
>  1 file changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a73b192..41fb894 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -133,6 +134,7 @@ struct hdmi_context {
>   struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>   struct regulator*reg_hdmi_en;
>   struct exynos_drm_clk   phy_clk;
> + struct drm_bridge   *bridge;
>  };
>  
>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
> *encoder)
>   drm_connector_register(connector);
>   drm_mode_connector_attach_encoder(connector, encoder);
>  
> - return 0;
> + if (hdata->bridge) {
> + encoder->bridge = hdata->bridge;
> + hdata->bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, hdata->bridge);
> + if (ret)
> + DRM_ERROR("Failed to attach bridge\n");
> + }
> +
> + return ret;
>  }
>  
>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
> *clk, bool enable)
>   hdmiphy_disable(hdata);
>  }
>  
> +static int hdmi_bridge_init(struct hdmi_context *hdata)
> +{
> + struct device *dev = hdata->dev;
> + struct device_node *ep, *np;
> +
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!ep)
> + return 0;
> +
> + np = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!np) {
> + DRM_ERROR("failed to get remote port parent");
> + return -EINVAL;
> + }
> +
> + hdata->bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> +
> + if (!hdata->bridge)
> + return -EPROBE_DEFER;
> +
> + return 0;
> +}
> +
>  static int hdmi_resources_init(struct hdmi_context *hdata)
>  {
>   struct device *dev = hdata->dev;
> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
> *hdata)
>  
>   hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>  
> - if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
> - return 0;
> + if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
> + if (IS_ERR(hdata->reg_hdmi_en))
> + return PTR_ERR(hdata->reg_hdmi_en);
>  
> - if (IS_ERR(hdata->reg_hdmi_en))
> - return PTR_ERR(hdata->reg_hdmi_en);
> -
> - ret = regulator_enable(hdata->reg_hdmi_en);
> - if (ret)
> - DRM_ERROR("failed to enable hdmi-en regulator\n");
> + ret = regulator_enable(hdata->reg_hdmi_en);
> + if (ret) {
> + DRM_ERROR("failed to enable hdmi-en regulator\n");
> + return ret;
> + }
> + }
>  
> - return ret;
> + return hdmi_bridge_init(hdata);
>  }
>  
>  static struct of_device_id hdmi_match_types[] = {
> 

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
> In some platforms there is attached another device to the end of HDMI.
> The patch adds support for it.

Andrzej, can you clarify what bridge device can be attached and actually is now 
attached to the end of HDMI?
And I wonder if we have the device tree file which defines the bridge device in 
mainline. Seems we have no the device tree file.

If nothing, then this patch should be merged with real use case.

Thanks.

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
> +---
>  1 file changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a73b192..41fb894 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -133,6 +134,7 @@ struct hdmi_context {
>   struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>   struct regulator*reg_hdmi_en;
>   struct exynos_drm_clk   phy_clk;
> + struct drm_bridge   *bridge;
>  };
>  
>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
> *encoder)
>   drm_connector_register(connector);
>   drm_mode_connector_attach_encoder(connector, encoder);
>  
> - return 0;
> + if (hdata->bridge) {
> + encoder->bridge = hdata->bridge;
> + hdata->bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, hdata->bridge);
> + if (ret)
> + DRM_ERROR("Failed to attach bridge\n");
> + }
> +
> + return ret;
>  }
>  
>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
> *clk, bool enable)
>   hdmiphy_disable(hdata);
>  }
>  
> +static int hdmi_bridge_init(struct hdmi_context *hdata)
> +{
> + struct device *dev = hdata->dev;
> + struct device_node *ep, *np;
> +
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!ep)
> + return 0;
> +
> + np = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!np) {
> + DRM_ERROR("failed to get remote port parent");
> + return -EINVAL;
> + }
> +
> + hdata->bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> +
> + if (!hdata->bridge)
> + return -EPROBE_DEFER;
> +
> + return 0;
> +}
> +
>  static int hdmi_resources_init(struct hdmi_context *hdata)
>  {
>   struct device *dev = hdata->dev;
> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
> *hdata)
>  
>   hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>  
> - if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
> - return 0;
> + if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
> + if (IS_ERR(hdata->reg_hdmi_en))
> + return PTR_ERR(hdata->reg_hdmi_en);
>  
> - if (IS_ERR(hdata->reg_hdmi_en))
> - return PTR_ERR(hdata->reg_hdmi_en);
> -
> - ret = regulator_enable(hdata->reg_hdmi_en);
> - if (ret)
> - DRM_ERROR("failed to enable hdmi-en regulator\n");
> + ret = regulator_enable(hdata->reg_hdmi_en);
> + if (ret) {
> + DRM_ERROR("failed to enable hdmi-en regulator\n");
> + return ret;
> + }
> + }
>  
> - return ret;
> + return hdmi_bridge_init(hdata);
>  }
>  
>  static struct of_device_id hdmi_match_types[] = {
> 

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>> Thierry Reding <thierry.red...@gmail.com> writes:
>>
>>> [ Unknown signature status ]
>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote:
>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote:
>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>>>>>
>>>>>>
>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>> Dear Thierry,
>>>>>>>
>>>>>>> Could you please review this patch?
>>>>>>
>>>>>> Thierry, I think this patch has been reviewed enough but no comment
>>>>>> from you. Seems you are busy. I will pick up this.
>>>>>
>>>>> Sorry, but that's not how it works. This patch has gone through 8
>>>>> revisions within 4 weeks, and I tend to ignore patches like that until
>>>>> the dust settles.
>>>>>
>>>>
>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged on 
>>>> 1/24,
>>>> and picked up on 1/31. I don't think it's unreasonable to take it through
>>>> another tree after that.
>>>>
>>>> I wonder if drm_panel would benefit from the -misc group maintainership 
>>>> model
>>>> as drm_bridge does. By spreading out the workload, the high-maintenance
>>>> patches would hopefully find someone to shepherd them through.
>>>
>>> Except that nobody except me really cares. If we let people take patches
>>> through separate trees or group-maintained trees they'll likely go in
>>> without too much thought. DRM panel is somewhat different from core DRM
>>> in this regard because its infrastructure is minimal and there's little
>>> outside the panel-simple driver. So we're still at a stage where we need
>>> to fine-tune what drivers should look like and how we can improve.
>>
>> I would love to care and participate in review, but with the structure
>> of your tree you're the only one whose review counts, so I don't
>> participate.
> 
> Really? What exactly do you think is special about the structure of my
> tree? I require patches to be on dri-devel (I pick them up from the
> patchwork instance at freedesktop.org), the tree is publicly available
> and reviewed-by tags get picked up automatically by patchwork.
> 
> The panel tree works exactly like any other maintainer tree. And my
> review is *not* the only one that counts. I appreciate every Reviewed-by
> tag I see on panel patches because it means that I don't have to look as
> closely as I have to otherwise.

I don't think the panel tree works exactly like other maintainer tree.

I'd like to recommend you to read below Greg's blog. This blog says about *Role 
of a Linux Kernel Maintainer*.
http://www.kroah.com/log/linux/maintainer_pledge.html

Especially, I'd like to emphasize below things,
- I will review your patch within 1-2 weeks.
- I will offer semi-constructive criticism of your patches.
- I will let you know the status of your patch if it is rejected, or if it is 
accepted, what tree it has gone into, where you can find it, and when you can 
expect to see it merged into Linus's tree.

Why do you ignore contributor's patch? Even though the patch is ugly, I think 
you need to point it out and give your feedback to contributers as a maintainer.
There was some cases I often missed to review with busy work but I don't ignore 
contributor's patch.
That was why I tried to pick this patch up to my tree to induce your feedback.

You mentioned like below,
"This patch has gone through 8 revisions within 4 weeks, and I tend to ignore 
patches like that until the dust settles."

Yes, it's been over a month since contributor sent this patch, and even he 
requested ping~~~ but there was no comment from you.
You say "I tend to ignore patches like that until the dust settles."

I'd like to say *maintainer is really not a place for power*, and maintainer 
would implicitly have a role to encourage in contribution activity of 
contributer.

And you are continuing reply to other maintainer's comments but no comment to 
the contributor. This guy would still be ping~. :)
You said you've repeatedly complained but how new contributors know this?

And you also said,
"DRM panel is somewhat different from core DRM in this regard because its 
infrastructure is minimal and there's little outside the panel-simple driver. 
So we're still at a stage where we need to fine-tune what drivers should look 
like and how we can improve"

Please, move panel 

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>> Thierry Reding  writes:
>>
>>> [ Unknown signature status ]
>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote:
>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote:
>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>>>>>
>>>>>>
>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>> Dear Thierry,
>>>>>>>
>>>>>>> Could you please review this patch?
>>>>>>
>>>>>> Thierry, I think this patch has been reviewed enough but no comment
>>>>>> from you. Seems you are busy. I will pick up this.
>>>>>
>>>>> Sorry, but that's not how it works. This patch has gone through 8
>>>>> revisions within 4 weeks, and I tend to ignore patches like that until
>>>>> the dust settles.
>>>>>
>>>>
>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged on 
>>>> 1/24,
>>>> and picked up on 1/31. I don't think it's unreasonable to take it through
>>>> another tree after that.
>>>>
>>>> I wonder if drm_panel would benefit from the -misc group maintainership 
>>>> model
>>>> as drm_bridge does. By spreading out the workload, the high-maintenance
>>>> patches would hopefully find someone to shepherd them through.
>>>
>>> Except that nobody except me really cares. If we let people take patches
>>> through separate trees or group-maintained trees they'll likely go in
>>> without too much thought. DRM panel is somewhat different from core DRM
>>> in this regard because its infrastructure is minimal and there's little
>>> outside the panel-simple driver. So we're still at a stage where we need
>>> to fine-tune what drivers should look like and how we can improve.
>>
>> I would love to care and participate in review, but with the structure
>> of your tree you're the only one whose review counts, so I don't
>> participate.
> 
> Really? What exactly do you think is special about the structure of my
> tree? I require patches to be on dri-devel (I pick them up from the
> patchwork instance at freedesktop.org), the tree is publicly available
> and reviewed-by tags get picked up automatically by patchwork.
> 
> The panel tree works exactly like any other maintainer tree. And my
> review is *not* the only one that counts. I appreciate every Reviewed-by
> tag I see on panel patches because it means that I don't have to look as
> closely as I have to otherwise.

I don't think the panel tree works exactly like other maintainer tree.

I'd like to recommend you to read below Greg's blog. This blog says about *Role 
of a Linux Kernel Maintainer*.
http://www.kroah.com/log/linux/maintainer_pledge.html

Especially, I'd like to emphasize below things,
- I will review your patch within 1-2 weeks.
- I will offer semi-constructive criticism of your patches.
- I will let you know the status of your patch if it is rejected, or if it is 
accepted, what tree it has gone into, where you can find it, and when you can 
expect to see it merged into Linus's tree.

Why do you ignore contributor's patch? Even though the patch is ugly, I think 
you need to point it out and give your feedback to contributers as a maintainer.
There was some cases I often missed to review with busy work but I don't ignore 
contributor's patch.
That was why I tried to pick this patch up to my tree to induce your feedback.

You mentioned like below,
"This patch has gone through 8 revisions within 4 weeks, and I tend to ignore 
patches like that until the dust settles."

Yes, it's been over a month since contributor sent this patch, and even he 
requested ping~~~ but there was no comment from you.
You say "I tend to ignore patches like that until the dust settles."

I'd like to say *maintainer is really not a place for power*, and maintainer 
would implicitly have a role to encourage in contribution activity of 
contributer.

And you are continuing reply to other maintainer's comments but no comment to 
the contributor. This guy would still be ping~. :)
You said you've repeatedly complained but how new contributors know this?

And you also said,
"DRM panel is somewhat different from core DRM in this regard because its 
infrastructure is minimal and there's little outside the panel-simple driver. 
So we're still at a stage where we need to fine-tune what drivers should look 
like and how we can improve"

Please, move panel directory to drivers/stag

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017-01-31 20:30 GMT+09:00 Krzysztof Kozlowski <k...@kernel.org>:
> On Tue, Jan 31, 2017 at 12:37 PM, Inki Dae <daei...@gmail.com> wrote:
>> 2017-01-31 19:01 GMT+09:00 Krzysztof Kozlowski <k...@kernel.org>:
>>> On Tue, Jan 31, 2017 at 11:34 AM, Inki Dae <inki@samsung.com> wrote:
>>>>
>>>>
>>>> 2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
>>>>> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki@samsung.com> wrote:
>>>>>>
>>>>>>
>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>> Dear Thierry,
>>>>>>>
>>>>>>> Could you please review this patch?
>>>>>>
>>>>>> Thierry, I think this patch has been reviewed enough but no comment from 
>>>>>> you. Seems you are busy. I will pick up this.
>>>>>>
>>>>>
>>>>> Comments from v8 were not resolved and I think we are waiting for v9:
>>>>> https://lkml.org/lkml/2017/1/11/178
>>>>>
>>>>> If that is not correct then please clarify.
>>>>
>>>> Seems you pointed to change te-gpios bindings to optional. right?
>>>>
>>>> I thought Rob left ack so it's no problem.
>>>> https://lkml.org/lkml/2017/1/13/626
>>>
>>> Yes, change them to optional. I think it is a problem (regardless of
>>> Rob's ack) because you are merging a driver requiring a property which
>>> soon you want to remove. If you merge it (like this) removal of
>>> te-gpios property will be breakage of ABI. This is not a serious
>>> problem but knowing such plan of te-gpios removal upfront, it would be
>>> wrong to commit such driver.
>>
>> This is a trivial thing so it doesn't make breakage of ABI because the
>> property, te-gpios, is *optional*.
>
> So why bindings document is not changed?

Seems Hoegeun missed this.
I also think it should specify *te-gpios is optional property* like
mipi-dsi binding document did but this doesn't breakage of ABI you
mentioned. And I'd like to say we should feel ABI breakage is a
serious problem.

Sad to say, Exynos is already broken like Marek declared. This is
really a serious problem Exynos maintainers have to fix including you
and me.

Thanks,
Inki Dae

>
> +Required properties:
> (...)
> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
> +gpio pin (active high)
>
> Andrzej pointed this out and it is not fixed since then. What is the
> problem with fixing the bindings documentation?
>
>> Anyway, this wouldn't be *the things* Thierry mentioned.
>
> Probably not, I did not respond to Thierry's feedback.
>
> Best regards,
> Krzysztof

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017-01-31 20:30 GMT+09:00 Krzysztof Kozlowski :
> On Tue, Jan 31, 2017 at 12:37 PM, Inki Dae  wrote:
>> 2017-01-31 19:01 GMT+09:00 Krzysztof Kozlowski :
>>> On Tue, Jan 31, 2017 at 11:34 AM, Inki Dae  wrote:
>>>>
>>>>
>>>> 2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
>>>>> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae  wrote:
>>>>>>
>>>>>>
>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>>>> Dear Thierry,
>>>>>>>
>>>>>>> Could you please review this patch?
>>>>>>
>>>>>> Thierry, I think this patch has been reviewed enough but no comment from 
>>>>>> you. Seems you are busy. I will pick up this.
>>>>>>
>>>>>
>>>>> Comments from v8 were not resolved and I think we are waiting for v9:
>>>>> https://lkml.org/lkml/2017/1/11/178
>>>>>
>>>>> If that is not correct then please clarify.
>>>>
>>>> Seems you pointed to change te-gpios bindings to optional. right?
>>>>
>>>> I thought Rob left ack so it's no problem.
>>>> https://lkml.org/lkml/2017/1/13/626
>>>
>>> Yes, change them to optional. I think it is a problem (regardless of
>>> Rob's ack) because you are merging a driver requiring a property which
>>> soon you want to remove. If you merge it (like this) removal of
>>> te-gpios property will be breakage of ABI. This is not a serious
>>> problem but knowing such plan of te-gpios removal upfront, it would be
>>> wrong to commit such driver.
>>
>> This is a trivial thing so it doesn't make breakage of ABI because the
>> property, te-gpios, is *optional*.
>
> So why bindings document is not changed?

Seems Hoegeun missed this.
I also think it should specify *te-gpios is optional property* like
mipi-dsi binding document did but this doesn't breakage of ABI you
mentioned. And I'd like to say we should feel ABI breakage is a
serious problem.

Sad to say, Exynos is already broken like Marek declared. This is
really a serious problem Exynos maintainers have to fix including you
and me.

Thanks,
Inki Dae

>
> +Required properties:
> (...)
> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
> +gpio pin (active high)
>
> Andrzej pointed this out and it is not fixed since then. What is the
> problem with fixing the bindings documentation?
>
>> Anyway, this wouldn't be *the things* Thierry mentioned.
>
> Probably not, I did not respond to Thierry's feedback.
>
> Best regards,
> Krzysztof

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017-01-31 19:01 GMT+09:00 Krzysztof Kozlowski <k...@kernel.org>:
> On Tue, Jan 31, 2017 at 11:34 AM, Inki Dae <inki@samsung.com> wrote:
>>
>>
>> 2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
>>> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki@samsung.com> wrote:
>>>>
>>>>
>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>> Dear Thierry,
>>>>>
>>>>> Could you please review this patch?
>>>>
>>>> Thierry, I think this patch has been reviewed enough but no comment from 
>>>> you. Seems you are busy. I will pick up this.
>>>>
>>>
>>> Comments from v8 were not resolved and I think we are waiting for v9:
>>> https://lkml.org/lkml/2017/1/11/178
>>>
>>> If that is not correct then please clarify.
>>
>> Seems you pointed to change te-gpios bindings to optional. right?
>>
>> I thought Rob left ack so it's no problem.
>> https://lkml.org/lkml/2017/1/13/626
>
> Yes, change them to optional. I think it is a problem (regardless of
> Rob's ack) because you are merging a driver requiring a property which
> soon you want to remove. If you merge it (like this) removal of
> te-gpios property will be breakage of ABI. This is not a serious
> problem but knowing such plan of te-gpios removal upfront, it would be
> wrong to commit such driver.

This is a trivial thing so it doesn't make breakage of ABI because the
property, te-gpios, is *optional*.

Anyway, this wouldn't be *the things* Thierry mentioned.

Thanks,
Inki Dae

>
> 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 v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017-01-31 19:01 GMT+09:00 Krzysztof Kozlowski :
> On Tue, Jan 31, 2017 at 11:34 AM, Inki Dae  wrote:
>>
>>
>> 2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
>>> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae  wrote:
>>>>
>>>>
>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>>>> Dear Thierry,
>>>>>
>>>>> Could you please review this patch?
>>>>
>>>> Thierry, I think this patch has been reviewed enough but no comment from 
>>>> you. Seems you are busy. I will pick up this.
>>>>
>>>
>>> Comments from v8 were not resolved and I think we are waiting for v9:
>>> https://lkml.org/lkml/2017/1/11/178
>>>
>>> If that is not correct then please clarify.
>>
>> Seems you pointed to change te-gpios bindings to optional. right?
>>
>> I thought Rob left ack so it's no problem.
>> https://lkml.org/lkml/2017/1/13/626
>
> Yes, change them to optional. I think it is a problem (regardless of
> Rob's ack) because you are merging a driver requiring a property which
> soon you want to remove. If you merge it (like this) removal of
> te-gpios property will be breakage of ABI. This is not a serious
> problem but knowing such plan of te-gpios removal upfront, it would be
> wrong to commit such driver.

This is a trivial thing so it doesn't make breakage of ABI because the
property, te-gpios, is *optional*.

Anyway, this wouldn't be *the things* Thierry mentioned.

Thanks,
Inki Dae

>
> 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 v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki@samsung.com> wrote:
>>
>>
>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>> Dear Thierry,
>>>
>>> Could you please review this patch?
>>
>> Thierry, I think this patch has been reviewed enough but no comment from 
>> you. Seems you are busy. I will pick up this.
>>
> 
> Comments from v8 were not resolved and I think we are waiting for v9:
> https://lkml.org/lkml/2017/1/11/178
> 
> If that is not correct then please clarify.

Seems you pointed to change te-gpios bindings to optional. right?

I thought Rob left ack so it's no problem.
https://lkml.org/lkml/2017/1/13/626

Thanks,
Inki Dae

> 
> 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 v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae  wrote:
>>
>>
>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>> Dear Thierry,
>>>
>>> Could you please review this patch?
>>
>> Thierry, I think this patch has been reviewed enough but no comment from 
>> you. Seems you are busy. I will pick up this.
>>
> 
> Comments from v8 were not resolved and I think we are waiting for v9:
> https://lkml.org/lkml/2017/1/11/178
> 
> If that is not correct then please clarify.

Seems you pointed to change te-gpios bindings to optional. right?

I thought Rob left ack so it's no problem.
https://lkml.org/lkml/2017/1/13/626

Thanks,
Inki Dae

> 
> 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 v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 31일 17:54에 Thierry Reding 이(가) 쓴 글:
> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>
>>
>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>> Dear Thierry,
>>>
>>> Could you please review this patch?
>>
>> Thierry, I think this patch has been reviewed enough but no comment
>> from you. Seems you are busy. I will pick up this.
> 
> Sorry, but that's not how it works. This patch has gone through 8
> revisions within 4 weeks, and I tend to ignore patches like that until
> the dust settles.
> 
> Other than that, this continues the same madness that I've repeatedly
> complained about in the past. The whole mechanism of running through a
> series of writes and not caring about errors until the very end is
> something we've discussed at length in the past. It also in large parts
> duplicates a bunch of functions from other Samsung panel drivers that I
> already said should eventually be moved to something saner.
> 
> This is now the third driver and nobody's giving a damn about improving
> things.
> 
> Until somebody does, I'm going to have to NAK this.

Hoegeun had got review comments and updated his patch seriously. no feedback 
from maintainer would make him and new contributors to frustrate.
So please leave *the things* so that the contributors can understand *what they 
have to modify more* or *why maintainer ignores the patch*.

And also if you specify *the things* here than I would do what I can so *the 
things* could be cleared. 

Thanks,
Inki Dae

> 
> Thierry
> 
>>> On 01/11/2017 03:33 PM, Hoegeun Kwon wrote:
>>>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>>>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>>>> panel in the TM2 device.
>>>>
>>>> Signed-off-by: Donghwa Lee <dh09@samsung.com>
>>>> Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
>>>> Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
>>>> Tested-by: Chanwoo Choi <cw00.c...@samsung.com>
>>>> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
>>>> ---
>>>>   drivers/gpu/drm/panel/Kconfig |   6 +
>>>>   drivers/gpu/drm/panel/Makefile|   1 +
>>>>   drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 
>>>> ++
>>>>   3 files changed, 761 insertions(+)
>>>>   create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>>
>>>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>>>> index 62aba97..d913c83 100644
>>>> --- a/drivers/gpu/drm/panel/Kconfig
>>>> +++ b/drivers/gpu/drm/panel/Kconfig
>>>> @@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
>>>> WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
>>>> Xperia Z2 tablets
>>>>   +config DRM_PANEL_SAMSUNG_S6E3HA2
>>>> +tristate "Samsung S6E3HA2 DSI video mode panel"
>>>> +depends on OF
>>>> +depends on DRM_MIPI_DSI
>>>> +select VIDEOMODE_HELPERS
>>>> +
>>>>   config DRM_PANEL_SAMSUNG_S6E8AA0
>>>>   tristate "Samsung S6E8AA0 DSI video mode panel"
>>>>   depends on OF
>>>> diff --git a/drivers/gpu/drm/panel/Makefile 
>>>> b/drivers/gpu/drm/panel/Makefile
>>>> index a5c7ec0..1d483b0 100644
>>>> --- a/drivers/gpu/drm/panel/Makefile
>>>> +++ b/drivers/gpu/drm/panel/Makefile
>>>> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
>>>> panel-jdi-lt070me05000.o
>>>>   obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>>>>   obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
>>>> panel-panasonic-vvx10f034n00.o
>>>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
>>>> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
>>>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
>>>>   obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>>>>   obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>>>> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
>>>> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>> new file mode 100644
>>>> index 000..0b9c6f4
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>> 

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 31일 17:54에 Thierry Reding 이(가) 쓴 글:
> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
>>
>>
>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
>>> Dear Thierry,
>>>
>>> Could you please review this patch?
>>
>> Thierry, I think this patch has been reviewed enough but no comment
>> from you. Seems you are busy. I will pick up this.
> 
> Sorry, but that's not how it works. This patch has gone through 8
> revisions within 4 weeks, and I tend to ignore patches like that until
> the dust settles.
> 
> Other than that, this continues the same madness that I've repeatedly
> complained about in the past. The whole mechanism of running through a
> series of writes and not caring about errors until the very end is
> something we've discussed at length in the past. It also in large parts
> duplicates a bunch of functions from other Samsung panel drivers that I
> already said should eventually be moved to something saner.
> 
> This is now the third driver and nobody's giving a damn about improving
> things.
> 
> Until somebody does, I'm going to have to NAK this.

Hoegeun had got review comments and updated his patch seriously. no feedback 
from maintainer would make him and new contributors to frustrate.
So please leave *the things* so that the contributors can understand *what they 
have to modify more* or *why maintainer ignores the patch*.

And also if you specify *the things* here than I would do what I can so *the 
things* could be cleared. 

Thanks,
Inki Dae

> 
> Thierry
> 
>>> On 01/11/2017 03:33 PM, Hoegeun Kwon wrote:
>>>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>>>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>>>> panel in the TM2 device.
>>>>
>>>> Signed-off-by: Donghwa Lee 
>>>> Signed-off-by: Hyungwon Hwang 
>>>> Signed-off-by: Hoegeun Kwon 
>>>> Tested-by: Chanwoo Choi 
>>>> Reviewed-by: Andrzej Hajda 
>>>> ---
>>>>   drivers/gpu/drm/panel/Kconfig |   6 +
>>>>   drivers/gpu/drm/panel/Makefile|   1 +
>>>>   drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 
>>>> ++
>>>>   3 files changed, 761 insertions(+)
>>>>   create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>>
>>>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>>>> index 62aba97..d913c83 100644
>>>> --- a/drivers/gpu/drm/panel/Kconfig
>>>> +++ b/drivers/gpu/drm/panel/Kconfig
>>>> @@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
>>>> WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
>>>> Xperia Z2 tablets
>>>>   +config DRM_PANEL_SAMSUNG_S6E3HA2
>>>> +tristate "Samsung S6E3HA2 DSI video mode panel"
>>>> +depends on OF
>>>> +depends on DRM_MIPI_DSI
>>>> +select VIDEOMODE_HELPERS
>>>> +
>>>>   config DRM_PANEL_SAMSUNG_S6E8AA0
>>>>   tristate "Samsung S6E8AA0 DSI video mode panel"
>>>>   depends on OF
>>>> diff --git a/drivers/gpu/drm/panel/Makefile 
>>>> b/drivers/gpu/drm/panel/Makefile
>>>> index a5c7ec0..1d483b0 100644
>>>> --- a/drivers/gpu/drm/panel/Makefile
>>>> +++ b/drivers/gpu/drm/panel/Makefile
>>>> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
>>>> panel-jdi-lt070me05000.o
>>>>   obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>>>>   obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
>>>> panel-panasonic-vvx10f034n00.o
>>>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
>>>> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
>>>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
>>>>   obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>>>>   obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>>>> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
>>>> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>> new file mode 100644
>>>> index 000..0b9c6f4
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>> @@ -0,0 +1,754 @@
>>>> +/*
>>>> + * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
>>>> + *
>>>> + * Copyrigh

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
> Dear Thierry,
> 
> Could you please review this patch?

Thierry, I think this patch has been reviewed enough but no comment from you. 
Seems you are busy. I will pick up this.

Thanks.

> 
> Best Regards,
> Hoegeun Kwon
> 
> On 01/11/2017 03:33 PM, Hoegeun Kwon wrote:
>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>> panel in the TM2 device.
>>
>> Signed-off-by: Donghwa Lee 
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Hoegeun Kwon 
>> Tested-by: Chanwoo Choi 
>> Reviewed-by: Andrzej Hajda 
>> ---
>>   drivers/gpu/drm/panel/Kconfig |   6 +
>>   drivers/gpu/drm/panel/Makefile|   1 +
>>   drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 
>> ++
>>   3 files changed, 761 insertions(+)
>>   create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 62aba97..d913c83 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
>> WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
>> Xperia Z2 tablets
>>   +config DRM_PANEL_SAMSUNG_S6E3HA2
>> +tristate "Samsung S6E3HA2 DSI video mode panel"
>> +depends on OF
>> +depends on DRM_MIPI_DSI
>> +select VIDEOMODE_HELPERS
>> +
>>   config DRM_PANEL_SAMSUNG_S6E8AA0
>>   tristate "Samsung S6E8AA0 DSI video mode panel"
>>   depends on OF
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index a5c7ec0..1d483b0 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
>> panel-jdi-lt070me05000.o
>>   obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>>   obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
>> panel-panasonic-vvx10f034n00.o
>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
>> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
>>   obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>>   obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
>> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>> new file mode 100644
>> index 000..0b9c6f4
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>> @@ -0,0 +1,754 @@
>> +/*
>> + * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
>> + *
>> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
>> + * Donghwa Lee 
>> + * Hyungwon Hwang 
>> + * Hoegeun Kwon 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define S6E3HA2_MIN_BRIGHTNESS0
>> +#define S6E3HA2_MAX_BRIGHTNESS100
>> +#define S6E3HA2_DEFAULT_BRIGHTNESS80
>> +
>> +#define S6E3HA2_NUM_GAMMA_STEPS46
>> +#define S6E3HA2_GAMMA_CMD_CNT35
>> +#define S6E3HA2_VINT_STATUS_MAX10
>> +
>> +static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = 
>> {
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
>> +  0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
>> +  0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
>> +  0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
>> +  0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
>> +  0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
>> +  0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
>> +  0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
>> +  0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
>> +  0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
>> +  0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
> Dear Thierry,
> 
> Could you please review this patch?

Thierry, I think this patch has been reviewed enough but no comment from you. 
Seems you are busy. I will pick up this.

Thanks.

> 
> Best Regards,
> Hoegeun Kwon
> 
> On 01/11/2017 03:33 PM, Hoegeun Kwon wrote:
>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>> panel in the TM2 device.
>>
>> Signed-off-by: Donghwa Lee 
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Hoegeun Kwon 
>> Tested-by: Chanwoo Choi 
>> Reviewed-by: Andrzej Hajda 
>> ---
>>   drivers/gpu/drm/panel/Kconfig |   6 +
>>   drivers/gpu/drm/panel/Makefile|   1 +
>>   drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 
>> ++
>>   3 files changed, 761 insertions(+)
>>   create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 62aba97..d913c83 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
>> WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
>> Xperia Z2 tablets
>>   +config DRM_PANEL_SAMSUNG_S6E3HA2
>> +tristate "Samsung S6E3HA2 DSI video mode panel"
>> +depends on OF
>> +depends on DRM_MIPI_DSI
>> +select VIDEOMODE_HELPERS
>> +
>>   config DRM_PANEL_SAMSUNG_S6E8AA0
>>   tristate "Samsung S6E8AA0 DSI video mode panel"
>>   depends on OF
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index a5c7ec0..1d483b0 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
>> panel-jdi-lt070me05000.o
>>   obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>>   obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
>> panel-panasonic-vvx10f034n00.o
>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
>> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
>>   obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>>   obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
>> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>> new file mode 100644
>> index 000..0b9c6f4
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>> @@ -0,0 +1,754 @@
>> +/*
>> + * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
>> + *
>> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
>> + * Donghwa Lee 
>> + * Hyungwon Hwang 
>> + * Hoegeun Kwon 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define S6E3HA2_MIN_BRIGHTNESS0
>> +#define S6E3HA2_MAX_BRIGHTNESS100
>> +#define S6E3HA2_DEFAULT_BRIGHTNESS80
>> +
>> +#define S6E3HA2_NUM_GAMMA_STEPS46
>> +#define S6E3HA2_GAMMA_CMD_CNT35
>> +#define S6E3HA2_VINT_STATUS_MAX10
>> +
>> +static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = 
>> {
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
>> +  0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
>> +  0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
>> +  0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
>> +  0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
>> +  0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
>> +  0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
>> +  0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
>> +  0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
>> +  0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
>> +  0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
>> +  0x00, 0x00 },
>> +{ 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
>> +  0x85, 0x86, 0x89, 0x8a, 0x84, 0x89, 0x83, 0x83, 0x86, 0x84, 0x8b,
>> +  0x90, 0x84, 0xb0, 0xae, 

Re: [PATCH 1/3] drm/exynos/decon5433: do not disable video after reset

[Inki Dae]

Applied including other two patches.

Thanks.

2017년 01월 17일 23:15에 Andrzej Hajda 이(가) 쓴 글:
> decon_commit is called just after reset so video is disabled anyway.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 634cfd7..6fd2b11 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -158,8 +158,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   m->crtc_vsync_end = m->crtc_vsync_start + 1;
>   }
>  
> - decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
> -
>   /* enable clock gate */
>   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>   writel(val, ctx->addr + DECON_CMU);
> 

Re: [PATCH 1/3] drm/exynos/decon5433: do not disable video after reset

[Inki Dae]

Applied including other two patches.

Thanks.

2017년 01월 17일 23:15에 Andrzej Hajda 이(가) 쓴 글:
> decon_commit is called just after reset so video is disabled anyway.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 634cfd7..6fd2b11 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -158,8 +158,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   m->crtc_vsync_end = m->crtc_vsync_start + 1;
>   }
>  
> - decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
> -
>   /* enable clock gate */
>   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>   writel(val, ctx->addr + DECON_CMU);
> 

Re: [PATCH 0/3] Fix DECON_UPDATE for TV

[Inki Dae]

Hi Andrzej,

2017년 01월 17일 23:15에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
> 
> This is my final fight with DECON_UPDATE issues (I hope). My two previous 
> patches
> fixed problems on panel path, this patchset fixes also TV path.
> The root cause of all evil was in incorrect DECON_CMU programming.
> 
> Now it works correctly on:
> - panel,
> - TV,
> - both.
> I have not observed (so far) IOMMU faults, or vblank timeouts.

Really thanks for this patch set. Will review and merge it. This patch set will 
go to -fixes.

Thanks.

> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (3):
>   drm/exynos/decon5433: do not disable video after reset
>   drm/exynos/decon5433: fix CMU programming
>   drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
> 
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 

Re: [PATCH 0/3] Fix DECON_UPDATE for TV

[Inki Dae]

Hi Andrzej,

2017년 01월 17일 23:15에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
> 
> This is my final fight with DECON_UPDATE issues (I hope). My two previous 
> patches
> fixed problems on panel path, this patchset fixes also TV path.
> The root cause of all evil was in incorrect DECON_CMU programming.
> 
> Now it works correctly on:
> - panel,
> - TV,
> - both.
> I have not observed (so far) IOMMU faults, or vblank timeouts.

Really thanks for this patch set. Will review and merge it. This patch set will 
go to -fixes.

Thanks.

> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (3):
>   drm/exynos/decon5433: do not disable video after reset
>   drm/exynos/decon5433: fix CMU programming
>   drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
> 
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 

Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Inki Dae]

2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang 
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Andrzej Hajda 
>> Signed-off-by: Chanwoo Choi 
>> Signed-off-by: Hoegeun Kwon 
>> Tested-by: Chanwoo Choi 
>> ---
>>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>>  compatible = "samsung,tm2", "samsung,exynos5433";
>>  };
>>  
>> + {
>> +panel@0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <_reg>;
>> +vci-supply = <_reg>;
>> +reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = < 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.

Reasonable to remove te-gpios property but this change would make MIPI-DSI 
driver probing to be failed so MIPI-DSI driver should be fixed together.

Thanks.

> 
> Regards
> Andrzej
>> +};
>> +};
>> +
>>  _9 {
>>  status = "okay";
>>  
> 
> 
> 
> 

Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Inki Dae]

2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang 
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Andrzej Hajda 
>> Signed-off-by: Chanwoo Choi 
>> Signed-off-by: Hoegeun Kwon 
>> Tested-by: Chanwoo Choi 
>> ---
>>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>>  compatible = "samsung,tm2", "samsung,exynos5433";
>>  };
>>  
>> + {
>> +panel@0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <_reg>;
>> +vci-supply = <_reg>;
>> +reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = < 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.

Reasonable to remove te-gpios property but this change would make MIPI-DSI 
driver probing to be failed so MIPI-DSI driver should be fixed together.

Thanks.

> 
> Regards
> Andrzej
>> +};
>> +};
>> +
>>  _9 {
>>  status = "okay";
>>  
> 
> 
> 
> 

Re: [PATCH v7 1/4] drm/exynos: mic: Add mode_set callback function

[Inki Dae]

Applied.

Thanks.

2017년 01월 05일 19:20에 Hoegeun Kwon 이(가) 쓴 글:
> Before applying the patch, used the of_get_videomode function to
> parse the display-timings in the panel which is the child driver
> of dsi in the devicetree. this is wrong. So removed the
> of_get_videomode and fixed to get videomode struct through
> mode_set callback function.
> 
> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a0def0b..fed1a94 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
>   }
>   nodes[j++] = remote_node;
>  
> - ret = of_get_videomode(remote_node,
> - >vm, 0);
> - if (ret) {
> - DRM_ERROR("mic: failed to get videomode");
> - goto exit;
> - }
> -
>   break;
>   default:
>   DRM_ERROR("mic: Unknown endpoint from MIC");
> @@ -329,6 +322,17 @@ static void mic_post_disable(struct drm_bridge *bridge)
>   mutex_unlock(_mutex);
>  }
>  
> +static void mic_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct exynos_mic *mic = bridge->driver_private;
> +
> + mutex_lock(_mutex);
> + drm_display_mode_to_videomode(mode, >vm);
> + mutex_unlock(_mutex);
> +}
> +
>  static void mic_pre_enable(struct drm_bridge *bridge)
>  {
>   struct exynos_mic *mic = bridge->driver_private;
> @@ -377,6 +381,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
>  static const struct drm_bridge_funcs mic_bridge_funcs = {
>   .disable = mic_disable,
>   .post_disable = mic_post_disable,
> + .mode_set = mic_mode_set,
>   .pre_enable = mic_pre_enable,
>   .enable = mic_enable,
>  };
> 

Re: [PATCH v7 2/4] drm/exynos: mic: Fix parse_dt function

[Inki Dae]

Applied.

Thanks.

2017년 01월 05일 19:20에 Hoegeun Kwon 이(가) 쓴 글:
> The OF graph is not necessary because the panel is a child of
> dsi. therefore, the parse_dt function of dsi does not need to
> check the remote_node connected to the panel. and the whole
> parse_dt function should be refactored later.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 25 +++--
>  1 file changed, 3 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index fed1a94..cf9361a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -269,28 +269,9 @@ static int parse_dt(struct exynos_mic *mic)
>   }
>   nodes[j++] = remote_node;
>  
> - switch (i) {
> - case ENDPOINT_DECON_NODE:
> - /* decon node */
> - if (of_get_child_by_name(remote_node,
> - "i80-if-timings"))
> - mic->i80_mode = 1;
> -
> - break;
> - case ENDPOINT_DSI_NODE:
> - /* panel node */
> - remote_node = get_remote_node(remote_node, 1);
> - if (!remote_node) {
> - ret = -EPIPE;
> - goto exit;
> - }
> - nodes[j++] = remote_node;
> -
> - break;
> - default:
> - DRM_ERROR("mic: Unknown endpoint from MIC");
> - break;
> - }
> + if (i == ENDPOINT_DECON_NODE &&
> + of_get_child_by_name(remote_node, "i80-if-timings"))
> + mic->i80_mode = 1;
>   }
>  
>  exit:
> 

Re: [PATCH v7 1/4] drm/exynos: mic: Add mode_set callback function

[Inki Dae]

Applied.

Thanks.

2017년 01월 05일 19:20에 Hoegeun Kwon 이(가) 쓴 글:
> Before applying the patch, used the of_get_videomode function to
> parse the display-timings in the panel which is the child driver
> of dsi in the devicetree. this is wrong. So removed the
> of_get_videomode and fixed to get videomode struct through
> mode_set callback function.
> 
> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a0def0b..fed1a94 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
>   }
>   nodes[j++] = remote_node;
>  
> - ret = of_get_videomode(remote_node,
> - >vm, 0);
> - if (ret) {
> - DRM_ERROR("mic: failed to get videomode");
> - goto exit;
> - }
> -
>   break;
>   default:
>   DRM_ERROR("mic: Unknown endpoint from MIC");
> @@ -329,6 +322,17 @@ static void mic_post_disable(struct drm_bridge *bridge)
>   mutex_unlock(_mutex);
>  }
>  
> +static void mic_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct exynos_mic *mic = bridge->driver_private;
> +
> + mutex_lock(_mutex);
> + drm_display_mode_to_videomode(mode, >vm);
> + mutex_unlock(_mutex);
> +}
> +
>  static void mic_pre_enable(struct drm_bridge *bridge)
>  {
>   struct exynos_mic *mic = bridge->driver_private;
> @@ -377,6 +381,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
>  static const struct drm_bridge_funcs mic_bridge_funcs = {
>   .disable = mic_disable,
>   .post_disable = mic_post_disable,
> + .mode_set = mic_mode_set,
>   .pre_enable = mic_pre_enable,
>   .enable = mic_enable,
>  };
> 

Re: [PATCH v7 2/4] drm/exynos: mic: Fix parse_dt function

[Inki Dae]

Applied.

Thanks.

2017년 01월 05일 19:20에 Hoegeun Kwon 이(가) 쓴 글:
> The OF graph is not necessary because the panel is a child of
> dsi. therefore, the parse_dt function of dsi does not need to
> check the remote_node connected to the panel. and the whole
> parse_dt function should be refactored later.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 25 +++--
>  1 file changed, 3 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index fed1a94..cf9361a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -269,28 +269,9 @@ static int parse_dt(struct exynos_mic *mic)
>   }
>   nodes[j++] = remote_node;
>  
> - switch (i) {
> - case ENDPOINT_DECON_NODE:
> - /* decon node */
> - if (of_get_child_by_name(remote_node,
> - "i80-if-timings"))
> - mic->i80_mode = 1;
> -
> - break;
> - case ENDPOINT_DSI_NODE:
> - /* panel node */
> - remote_node = get_remote_node(remote_node, 1);
> - if (!remote_node) {
> - ret = -EPIPE;
> - goto exit;
> - }
> - nodes[j++] = remote_node;
> -
> - break;
> - default:
> - DRM_ERROR("mic: Unknown endpoint from MIC");
> - break;
> - }
> + if (i == ENDPOINT_DECON_NODE &&
> + of_get_child_by_name(remote_node, "i80-if-timings"))
> + mic->i80_mode = 1;
>   }
>  
>  exit:
> 

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 09일 18:53에 Andrzej Hajda 이(가) 쓴 글:
> On 09.01.2017 10:19, Inki Dae wrote:
>>
>> 2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
>>> On 06.01.2017 09:36, Inki Dae wrote:
>>>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
>>>>> Hi Inki,
>>>>>
>>>>> Thanks for the reply, but...
>>>>>
>>>>>>>> +static const struct drm_display_mode default_mode = {
>>>>>>>> +  .clock = 222372,
>>>>>>>> +  .hdisplay = 1440,
>>>>>>>> +  .hsync_start = 1440 + 1,
>>>>>>>> +  .hsync_end = 1440 + 1 + 1,
>>>>>>>> +  .htotal = 1440 + 1 + 1 + 1,
>>>>>>>> +  .vdisplay = 2560,
>>>>>>>> +  .vsync_start = 2560 + 1,
>>>>>>>> +  .vsync_end = 2560 + 1 + 1,
>>>>>>>> +  .vtotal = 2560 + 1 + 1 + 15,
>>>>>>>> +  .vrefresh = 60,
>>>>>>>> +  .flags = 0,
>>>>>>>> +};
>>>>>>> how is this working with tm2e? Are these values valid for both
>>>>>>> the boards?
>>>>>> We don't need to consider tm2e board with two reasones,
>>>>>> 1. there is no tm2e board support in mainline
>>>>>> 2. the panel on tm2 would be a little bit different from one on tm2e
>>>>> ... this display in the Tizen Kernel is supported by both:
>>>>> tm2 [1] and tm2e [2]. The only differences are:
>>>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. 
>>>> :( 
>>>>
>>>>> TM2:
>>>>>clock-frequency = <1487>;
>>>>>hactive = <1440>;
>>>>>
>>>>> TM2E:
>>>>>clock-frequency = <16523724>;
>>>>>hactive = <1600>;
>>>>>
>>>>> I don't know much about the differences you mention in point 2,
>>>>> but it's a pity to drop support only because we don't want to put
>>>>> in the dts the 'hactive', and 'clock-frequency' properties.
>>>> Anyway, tm2e board is already in mainline so Panel driver may need to 
>>>> identify what kinds of panel is probed to decide porch values. I think 
>>>> there are relevant registers in MCU of the Panel device to check version 
>>>> or similar thing.
>>> I think we can safely use different compatible string for tm2e - it uses
>>> different display IC controller - s6e3hf2, driver will provide timings
>>> based on it.
>> Using compatable string wouldn't be a good idea because Panel is a device 
>> not specific to board.
> 
> But both panels are different devices:
> TM2 has: AMS567DJ01 panel on S6E3HA2 interface (called LDI/IC)
> TM2E has AMB559DE01 panel on S6E3HF2 interface (called LDI/IC)
> 
> Why assigning different compatibles to different devices is not a good idea?

Oops, I didn't know that these two panels are different so I thought using 
different compatiable string for same panel device is not good idea.

This panel driver is no problem as-is. For tm2e board, it can be considered 
with a separated patch later.

For this, these two boards have different MCU modules but just a little bit 
different so we could do either just adding compatible string to tm2e dts file 
and panel driver - maybe not reasonable due to different hardware name - or 
creating new panel driver even though source code is duplicated.

Thanks.

> 
>>
>>> As far as I examined available specs/docs there is no reliable register
>>> which can be used to safely distinguish it on runtime, but the docs I
>>> have are far from completeness.
>> The data sheet I am seeing says a RDDIDS register describes manufacturer and 
>> module version information. With this we could identify the Panel device.
>> Of course, we may need to check the register has really different values 
>> according to board.
>>
>> Below is the version information Hoegeun checked,
>>
>> TM2
>> [4.908666] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-10-31 
>> 06:41
>> [5.035768] panel_s6e3ha2 1390.dsi.0: Id: 50 20 09
>>
>> TM2e
>> [4.929265] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-09-03 
>> 06:30
>> [5.056287] panel_s6e3ha2 1390.dsi.0: Id: 40 40 14
> 
> There is description of ID1, ID2, ID3 registers in specs of both panels,
> I see no reliable bits to distinguish panels.
> And relying on read values o

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 09일 18:53에 Andrzej Hajda 이(가) 쓴 글:
> On 09.01.2017 10:19, Inki Dae wrote:
>>
>> 2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
>>> On 06.01.2017 09:36, Inki Dae wrote:
>>>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
>>>>> Hi Inki,
>>>>>
>>>>> Thanks for the reply, but...
>>>>>
>>>>>>>> +static const struct drm_display_mode default_mode = {
>>>>>>>> +  .clock = 222372,
>>>>>>>> +  .hdisplay = 1440,
>>>>>>>> +  .hsync_start = 1440 + 1,
>>>>>>>> +  .hsync_end = 1440 + 1 + 1,
>>>>>>>> +  .htotal = 1440 + 1 + 1 + 1,
>>>>>>>> +  .vdisplay = 2560,
>>>>>>>> +  .vsync_start = 2560 + 1,
>>>>>>>> +  .vsync_end = 2560 + 1 + 1,
>>>>>>>> +  .vtotal = 2560 + 1 + 1 + 15,
>>>>>>>> +  .vrefresh = 60,
>>>>>>>> +  .flags = 0,
>>>>>>>> +};
>>>>>>> how is this working with tm2e? Are these values valid for both
>>>>>>> the boards?
>>>>>> We don't need to consider tm2e board with two reasones,
>>>>>> 1. there is no tm2e board support in mainline
>>>>>> 2. the panel on tm2 would be a little bit different from one on tm2e
>>>>> ... this display in the Tizen Kernel is supported by both:
>>>>> tm2 [1] and tm2e [2]. The only differences are:
>>>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. 
>>>> :( 
>>>>
>>>>> TM2:
>>>>>clock-frequency = <1487>;
>>>>>hactive = <1440>;
>>>>>
>>>>> TM2E:
>>>>>clock-frequency = <16523724>;
>>>>>hactive = <1600>;
>>>>>
>>>>> I don't know much about the differences you mention in point 2,
>>>>> but it's a pity to drop support only because we don't want to put
>>>>> in the dts the 'hactive', and 'clock-frequency' properties.
>>>> Anyway, tm2e board is already in mainline so Panel driver may need to 
>>>> identify what kinds of panel is probed to decide porch values. I think 
>>>> there are relevant registers in MCU of the Panel device to check version 
>>>> or similar thing.
>>> I think we can safely use different compatible string for tm2e - it uses
>>> different display IC controller - s6e3hf2, driver will provide timings
>>> based on it.
>> Using compatable string wouldn't be a good idea because Panel is a device 
>> not specific to board.
> 
> But both panels are different devices:
> TM2 has: AMS567DJ01 panel on S6E3HA2 interface (called LDI/IC)
> TM2E has AMB559DE01 panel on S6E3HF2 interface (called LDI/IC)
> 
> Why assigning different compatibles to different devices is not a good idea?

Oops, I didn't know that these two panels are different so I thought using 
different compatiable string for same panel device is not good idea.

This panel driver is no problem as-is. For tm2e board, it can be considered 
with a separated patch later.

For this, these two boards have different MCU modules but just a little bit 
different so we could do either just adding compatible string to tm2e dts file 
and panel driver - maybe not reasonable due to different hardware name - or 
creating new panel driver even though source code is duplicated.

Thanks.

> 
>>
>>> As far as I examined available specs/docs there is no reliable register
>>> which can be used to safely distinguish it on runtime, but the docs I
>>> have are far from completeness.
>> The data sheet I am seeing says a RDDIDS register describes manufacturer and 
>> module version information. With this we could identify the Panel device.
>> Of course, we may need to check the register has really different values 
>> according to board.
>>
>> Below is the version information Hoegeun checked,
>>
>> TM2
>> [4.908666] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-10-31 
>> 06:41
>> [5.035768] panel_s6e3ha2 1390.dsi.0: Id: 50 20 09
>>
>> TM2e
>> [4.929265] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-09-03 
>> 06:30
>> [5.056287] panel_s6e3ha2 1390.dsi.0: Id: 40 40 14
> 
> There is description of ID1, ID2, ID3 registers in specs of both panels,
> I see no reliable bits to distinguish panels.
> And relying on read values o

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
> On 06.01.2017 09:36, Inki Dae wrote:
>>
>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> Thanks for the reply, but...
>>>
>>>>>> +static const struct drm_display_mode default_mode = {
>>>>>> +.clock = 222372,
>>>>>> +.hdisplay = 1440,
>>>>>> +.hsync_start = 1440 + 1,
>>>>>> +.hsync_end = 1440 + 1 + 1,
>>>>>> +.htotal = 1440 + 1 + 1 + 1,
>>>>>> +.vdisplay = 2560,
>>>>>> +.vsync_start = 2560 + 1,
>>>>>> +.vsync_end = 2560 + 1 + 1,
>>>>>> +.vtotal = 2560 + 1 + 1 + 15,
>>>>>> +.vrefresh = 60,
>>>>>> +.flags = 0,
>>>>>> +};
>>>>> how is this working with tm2e? Are these values valid for both
>>>>> the boards?
>>>> We don't need to consider tm2e board with two reasones,
>>>> 1. there is no tm2e board support in mainline
>>>> 2. the panel on tm2 would be a little bit different from one on tm2e
>>> ... this display in the Tizen Kernel is supported by both:
>>> tm2 [1] and tm2e [2]. The only differences are:
>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :( 
>>
>>> TM2:
>>>clock-frequency = <1487>;
>>>hactive = <1440>;
>>>
>>> TM2E:
>>>clock-frequency = <16523724>;
>>>hactive = <1600>;
>>>
>>> I don't know much about the differences you mention in point 2,
>>> but it's a pity to drop support only because we don't want to put
>>> in the dts the 'hactive', and 'clock-frequency' properties.
>> Anyway, tm2e board is already in mainline so Panel driver may need to 
>> identify what kinds of panel is probed to decide porch values. I think there 
>> are relevant registers in MCU of the Panel device to check version or 
>> similar thing.
> 
> I think we can safely use different compatible string for tm2e - it uses
> different display IC controller - s6e3hf2, driver will provide timings
> based on it.

Using compatable string wouldn't be a good idea because Panel is a device not 
specific to board.

> As far as I examined available specs/docs there is no reliable register
> which can be used to safely distinguish it on runtime, but the docs I
> have are far from completeness.

The data sheet I am seeing says a RDDIDS register describes manufacturer and 
module version information. With this we could identify the Panel device.
Of course, we may need to check the register has really different values 
according to board.

Below is the version information Hoegeun checked,

TM2
[4.908666] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-10-31 06:41
[5.035768] panel_s6e3ha2 1390.dsi.0: Id: 50 20 09

TM2e
[4.929265] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-09-03 06:30
[5.056287] panel_s6e3ha2 1390.dsi.0: Id: 40 40 14


Thanks.

> 
> Regards
> Andrzej
> 
>>
>> Thanks.
>>
>>> Andi
>>>
>>> [1] 
>>> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
>>> [2] 
>>> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>> .
>>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
> On 06.01.2017 09:36, Inki Dae wrote:
>>
>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> Thanks for the reply, but...
>>>
>>>>>> +static const struct drm_display_mode default_mode = {
>>>>>> +.clock = 222372,
>>>>>> +.hdisplay = 1440,
>>>>>> +.hsync_start = 1440 + 1,
>>>>>> +.hsync_end = 1440 + 1 + 1,
>>>>>> +.htotal = 1440 + 1 + 1 + 1,
>>>>>> +.vdisplay = 2560,
>>>>>> +.vsync_start = 2560 + 1,
>>>>>> +.vsync_end = 2560 + 1 + 1,
>>>>>> +.vtotal = 2560 + 1 + 1 + 15,
>>>>>> +.vrefresh = 60,
>>>>>> +.flags = 0,
>>>>>> +};
>>>>> how is this working with tm2e? Are these values valid for both
>>>>> the boards?
>>>> We don't need to consider tm2e board with two reasones,
>>>> 1. there is no tm2e board support in mainline
>>>> 2. the panel on tm2 would be a little bit different from one on tm2e
>>> ... this display in the Tizen Kernel is supported by both:
>>> tm2 [1] and tm2e [2]. The only differences are:
>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :( 
>>
>>> TM2:
>>>clock-frequency = <1487>;
>>>hactive = <1440>;
>>>
>>> TM2E:
>>>clock-frequency = <16523724>;
>>>hactive = <1600>;
>>>
>>> I don't know much about the differences you mention in point 2,
>>> but it's a pity to drop support only because we don't want to put
>>> in the dts the 'hactive', and 'clock-frequency' properties.
>> Anyway, tm2e board is already in mainline so Panel driver may need to 
>> identify what kinds of panel is probed to decide porch values. I think there 
>> are relevant registers in MCU of the Panel device to check version or 
>> similar thing.
> 
> I think we can safely use different compatible string for tm2e - it uses
> different display IC controller - s6e3hf2, driver will provide timings
> based on it.

Using compatable string wouldn't be a good idea because Panel is a device not 
specific to board.

> As far as I examined available specs/docs there is no reliable register
> which can be used to safely distinguish it on runtime, but the docs I
> have are far from completeness.

The data sheet I am seeing says a RDDIDS register describes manufacturer and 
module version information. With this we could identify the Panel device.
Of course, we may need to check the register has really different values 
according to board.

Below is the version information Hoegeun checked,

TM2
[4.908666] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-10-31 06:41
[5.035768] panel_s6e3ha2 1390.dsi.0: Id: 50 20 09

TM2e
[4.929265] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-09-03 06:30
[5.056287] panel_s6e3ha2 1390.dsi.0: Id: 40 40 14


Thanks.

> 
> Regards
> Andrzej
> 
>>
>> Thanks.
>>
>>> Andi
>>>
>>> [1] 
>>> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
>>> [2] 
>>> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>> .
>>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
> Hi Inki,
> 
> Thanks for the reply, but...
> 
 +static const struct drm_display_mode default_mode = {
 +  .clock = 222372,
 +  .hdisplay = 1440,
 +  .hsync_start = 1440 + 1,
 +  .hsync_end = 1440 + 1 + 1,
 +  .htotal = 1440 + 1 + 1 + 1,
 +  .vdisplay = 2560,
 +  .vsync_start = 2560 + 1,
 +  .vsync_end = 2560 + 1 + 1,
 +  .vtotal = 2560 + 1 + 1 + 15,
 +  .vrefresh = 60,
 +  .flags = 0,
 +};
>>>
>>> how is this working with tm2e? Are these values valid for both
>>> the boards?
>>
>> We don't need to consider tm2e board with two reasones,
>> 1. there is no tm2e board support in mainline
>> 2. the panel on tm2 would be a little bit different from one on tm2e
> 
> ... this display in the Tizen Kernel is supported by both:
> tm2 [1] and tm2e [2]. The only differences are:

Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :( 

> 
> TM2:
>clock-frequency = <1487>;
>hactive = <1440>;
> 
> TM2E:
>clock-frequency = <16523724>;
>hactive = <1600>;
> 
> I don't know much about the differences you mention in point 2,
> but it's a pity to drop support only because we don't want to put
> in the dts the 'hactive', and 'clock-frequency' properties.

Anyway, tm2e board is already in mainline so Panel driver may need to identify 
what kinds of panel is probed to decide porch values. I think there are 
relevant registers in MCU of the Panel device to check version or similar thing.

Thanks.

> 
> Andi
> 
> [1] 
> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
> [2] 
> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
> Hi Inki,
> 
> Thanks for the reply, but...
> 
 +static const struct drm_display_mode default_mode = {
 +  .clock = 222372,
 +  .hdisplay = 1440,
 +  .hsync_start = 1440 + 1,
 +  .hsync_end = 1440 + 1 + 1,
 +  .htotal = 1440 + 1 + 1 + 1,
 +  .vdisplay = 2560,
 +  .vsync_start = 2560 + 1,
 +  .vsync_end = 2560 + 1 + 1,
 +  .vtotal = 2560 + 1 + 1 + 15,
 +  .vrefresh = 60,
 +  .flags = 0,
 +};
>>>
>>> how is this working with tm2e? Are these values valid for both
>>> the boards?
>>
>> We don't need to consider tm2e board with two reasones,
>> 1. there is no tm2e board support in mainline
>> 2. the panel on tm2 would be a little bit different from one on tm2e
> 
> ... this display in the Tizen Kernel is supported by both:
> tm2 [1] and tm2e [2]. The only differences are:

Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :( 

> 
> TM2:
>clock-frequency = <1487>;
>hactive = <1440>;
> 
> TM2E:
>clock-frequency = <16523724>;
>hactive = <1600>;
> 
> I don't know much about the differences you mention in point 2,
> but it's a pity to drop support only because we don't want to put
> in the dts the 'hactive', and 'clock-frequency' properties.

Anyway, tm2e board is already in mainline so Panel driver may need to identify 
what kinds of panel is probed to decide porch values. I think there are 
relevant registers in MCU of the Panel device to check version or similar thing.

Thanks.

> 
> Andi
> 
> [1] 
> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
> [2] 
> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 06일 14:22에 Andi Shyti 이(가) 쓴 글:
> Hi Hoegeun,
> 
>> +static const struct drm_display_mode default_mode = {
>> +.clock = 222372,
>> +.hdisplay = 1440,
>> +.hsync_start = 1440 + 1,
>> +.hsync_end = 1440 + 1 + 1,
>> +.htotal = 1440 + 1 + 1 + 1,
>> +.vdisplay = 2560,
>> +.vsync_start = 2560 + 1,
>> +.vsync_end = 2560 + 1 + 1,
>> +.vtotal = 2560 + 1 + 1 + 15,
>> +.vrefresh = 60,
>> +.flags = 0,
>> +};
> 
> how is this working with tm2e? Are these values valid for both
> the boards?

We don't need to consider tm2e board with two reasones,
1. there is no tm2e board support in mainline
2. the panel on tm2 would be a little bit different from one on tm2e

Thanks,
Inki Dae

> 
> Andi
> 
>