RE: [PATCH 9/9] drm/verisilicon: Add starfive hdmi driver

2023-06-22 Thread Hoegeun Kwon
Hi Keith,

There is a problem with stopping when changing modes.

Below test log

root:~> modetest -Mstarfive -c
Connectors:
id  encoder status  namesize (mm)   modes
encoders
116 115 connected   HDMI-A-1320x180 51  115
  modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
  #0 1280x800 59.91 1280 1328 1360 1440 800 803 809 823 71000 flags: phsync,
pvsync; type: preferred, driver
  #1 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags:
phsync, pvsync; type: driver
[...]

root:~> modetest -Mstarfive -s 116:#0 -v
setting mode 1280x800-59.91Hz on connectors 116, crtc 31
freq: 60.65Hz
freq: 59.91Hz
freq: 59.91Hz

root:~> modetest -Mstarfive -s 116:#1 -v
setting mode 1920x1080-60.00Hz on connectors 116, crtc 31
[   94.535626] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[   94.560985] rcu: 1-...0: (20 ticks this GP)
idle=c9bc/1/0x4000 softirq=3869/3871 fqs=1120
[   94.589532] rcu: (detected by 3, t=5264 jiffies, g=4645, q=63
ncpus=4)
[   94.615335] Task dump for CPU 1:
[   94.637723] task:modeteststate:R  running task stack:0
pid:407   ppid:397flags:0x0008
[   94.667299] Call Trace:
[   94.689297] [] __schedule+0x2a8/0xa52
[   94.714221] [] schedule+0x5a/0xdc
[   94.738626] [] schedule_timeout+0x220/0x2a6
[   94.763762] [] wait_for_completion+0xfe/0x126
[   94.789073] [] kthread_flush_worker+0x82/0xa0


> -Original Message-
> From: dri-devel  On Behalf Of
> Keith Zhao
> Sent: Friday, June 2, 2023 4:41 PM
> To: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-ri...@lists.infradead.org; linux-
> me...@vger.kernel.org; linaro-mm-...@lists.linaro.org
> Cc: Krzysztof Kozlowski ; Sumit Semwal
> ; Emil Renner Berthing ;
> Shengyang Chen ; Conor Dooley
> ; Albert Ou ; Thomas
> Zimmermann ; Jagan Teki ; Rob
> Herring ; Chris Morgan ; Paul
> Walmsley ; Keith Zhao
> ; Bjorn Andersson ;
> Changhuang Liang ; Jack Zhu
> ; Palmer Dabbelt ; Shawn
> Guo ; christian.koe...@amd.com
> Subject: [PATCH 9/9] drm/verisilicon: Add starfive hdmi driver
> 
> Add HDMI dirver for StarFive SoC JH7110.
> 
> Signed-off-by: Keith Zhao 
> ---
>  drivers/gpu/drm/verisilicon/Kconfig |  11 +
>  drivers/gpu/drm/verisilicon/Makefile|   1 +
>  drivers/gpu/drm/verisilicon/starfive_hdmi.c | 928 
> drivers/gpu/drm/verisilicon/starfive_hdmi.h | 296 +++
>  drivers/gpu/drm/verisilicon/vs_drv.c|   6 +
>  drivers/gpu/drm/verisilicon/vs_drv.h|   4 +
>  6 files changed, 1246 insertions(+)
>  create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c
>  create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h

[...]

> diff --git a/drivers/gpu/drm/verisilicon/starfive_hdmi.c
> b/drivers/gpu/drm/verisilicon/starfive_hdmi.c
> new file mode 100644
> index ..128ecca03309
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/starfive_hdmi.c
> @@ -0,0 +1,928 @@

[...]

> +static int starfive_hdmi_setup(struct starfive_hdmi *hdmi,
> +struct drm_display_mode *mode) {

[...]

> + return 0;
> +}
> +
> +static void starfive_hdmi_encoder_mode_set(struct drm_encoder *encoder,
> +struct drm_display_mode *mode,
> +struct drm_display_mode
*adj_mode) {
> + struct starfive_hdmi *hdmi = encoder_to_hdmi(encoder);
> +
> + starfive_hdmi_setup(hdmi, adj_mode);

When starfive_hdmi_setup runs here,
when changing the mode, a problem occurs because try to write a value to reg
in a state that is not resumed after suspend.

> +
> + memcpy(>previous_mode, adj_mode, sizeof(hdmi-
> >previous_mode)); }
> +
> +static void starfive_hdmi_encoder_enable(struct drm_encoder *encoder) {
> + struct starfive_hdmi *hdmi = encoder_to_hdmi(encoder);
> +
> + pm_runtime_get_sync(hdmi->dev);

So if move the call point of starfive_hdmi_setup here, it works normally.

> +}

Best regards,
Hoegeun




RE: [PATCH libdrm] vbltest: add option to use high pipe

2023-02-07 Thread Hoegeun Kwon
Could you please check this patch.

Best regards
Hoegeun

> -Original Message-
> From: dri-devel  On Behalf Of
> Hoegeun Kwon
> Sent: Monday, January 16, 2023 6:44 PM
> To: dri-devel@lists.freedesktop.org; hoegeun.k...@samsung.com
> Subject: [PATCH libdrm] vbltest: add option to use high pipe
> 
> Add option to use high pipe.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  tests/vbltest/vbltest.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c index
> 1c2b519eec4a..1be77b81c560 100644
> --- a/tests/vbltest/vbltest.c
> +++ b/tests/vbltest/vbltest.c
> @@ -45,10 +45,13 @@
> 
>  extern char *optarg;
>  extern int optind, opterr, optopt;
> -static char optstr[] = "D:M:s";
> +static char optstr[] = "D:M:p:s";
> 
>  int secondary = 0;
> 
> +#define DRM_VBLANK_HIGH_CRTC_SHIFT 1
> +static int high_pipe = 0;
> +
>  struct vbl_info {
>   unsigned int vbl_count;
>   struct timeval start;
> @@ -65,6 +68,8 @@ static void vblank_handler(int fd, unsigned int frame,
> unsigned int sec,
>   vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
>   if (secondary)
>   vbl.request.type |= DRM_VBLANK_SECONDARY;
> + if (high_pipe)
> + vbl.request.type |= high_pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
>   vbl.request.sequence = 1;
>   vbl.request.signal = (unsigned long)data;
> 
> @@ -90,6 +95,7 @@ static void usage(char *name)
>   fprintf(stderr, "  -D DEVICE  open the given device\n");
>   fprintf(stderr, "  -M MODULE  open the given module\n");
>   fprintf(stderr, "  -s use secondary pipe\n");
> + fprintf(stderr, "  -p NUM use high pipe\n");
>   exit(0);
>  }
> 
> @@ -113,12 +119,18 @@ int main(int argc, char **argv)
>   case 's':
>   secondary = 1;
>   break;
> + case 'p':
> + high_pipe = atoi(optarg);
> + break;
>   default:
>   usage(argv[0]);
>   break;
>   }
>   }
> 
> + if (secondary && high_pipe)
> + return 1;
> +
>   fd = util_open(device, module);
>   if (fd < 0)
>   return 1;
> @@ -127,6 +139,8 @@ int main(int argc, char **argv)
>   vbl.request.type = DRM_VBLANK_RELATIVE;
>   if (secondary)
>   vbl.request.type |= DRM_VBLANK_SECONDARY;
> + if (high_pipe)
> + vbl.request.type |= high_pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
>   vbl.request.sequence = 0;
>   ret = drmWaitVBlank(fd, );
>   if (ret != 0) {
> @@ -143,6 +157,8 @@ int main(int argc, char **argv)
>   vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
>   if (secondary)
>   vbl.request.type |= DRM_VBLANK_SECONDARY;
> + if (high_pipe)
> + vbl.request.type |= high_pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
>   vbl.request.sequence = 1;
>   vbl.request.signal = (unsigned long)_info;
>   ret = drmWaitVBlank(fd, );
> --
> 2.17.1




[PATCH libdrm] vbltest: add option to use high pipe

2023-01-16 Thread Hoegeun Kwon
Add option to use high pipe.

Signed-off-by: Hoegeun Kwon 
---
 tests/vbltest/vbltest.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 1c2b519eec4a..1be77b81c560 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -45,10 +45,13 @@
 
 extern char *optarg;
 extern int optind, opterr, optopt;
-static char optstr[] = "D:M:s";
+static char optstr[] = "D:M:p:s";
 
 int secondary = 0;
 
+#define DRM_VBLANK_HIGH_CRTC_SHIFT 1
+static int high_pipe = 0;
+
 struct vbl_info {
unsigned int vbl_count;
struct timeval start;
@@ -65,6 +68,8 @@ static void vblank_handler(int fd, unsigned int frame, 
unsigned int sec,
vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
if (secondary)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+   if (high_pipe)
+   vbl.request.type |= high_pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
vbl.request.sequence = 1;
vbl.request.signal = (unsigned long)data;
 
@@ -90,6 +95,7 @@ static void usage(char *name)
fprintf(stderr, "  -D DEVICE  open the given device\n");
fprintf(stderr, "  -M MODULE  open the given module\n");
fprintf(stderr, "  -s use secondary pipe\n");
+   fprintf(stderr, "  -p NUM use high pipe\n");
exit(0);
 }
 
@@ -113,12 +119,18 @@ int main(int argc, char **argv)
case 's':
secondary = 1;
break;
+   case 'p':
+   high_pipe = atoi(optarg);
+   break;
default:
usage(argv[0]);
break;
}
}
 
+   if (secondary && high_pipe)
+   return 1;
+
fd = util_open(device, module);
if (fd < 0)
return 1;
@@ -127,6 +139,8 @@ int main(int argc, char **argv)
vbl.request.type = DRM_VBLANK_RELATIVE;
if (secondary)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+   if (high_pipe)
+   vbl.request.type |= high_pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
vbl.request.sequence = 0;
ret = drmWaitVBlank(fd, );
if (ret != 0) {
@@ -143,6 +157,8 @@ int main(int argc, char **argv)
vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
if (secondary)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+   if (high_pipe)
+   vbl.request.type |= high_pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
vbl.request.sequence = 1;
vbl.request.signal = (unsigned long)_info;
ret = drmWaitVBlank(fd, );
-- 
2.17.1



Re: [PATCH v2 7/7] drm/vc4: kms: Don't disable the muxing of an active CRTC

2020-11-03 Thread Hoegeun Kwon
Hi Maxime,

On 10/28/20 9:41 PM, Maxime Ripard wrote:
> The current HVS muxing code will consider the CRTCs in a given state to
> setup their muxing in the HVS, and disable the other CRTCs muxes.
>
> However, it's valid to only update a single CRTC with a state, and in this
> situation we would mux out a CRTC that was enabled but left untouched by
> the new state.
>
> Fix this by setting a flag on the CRTC state when the muxing has been
> changed, and only change the muxing configuration when that flag is there.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard 

I checked all patches well works.


All patches:

Reviewed-by: Hoegeun Kwon
Tested-by: Hoegeun Kwon

Best regards,
Hoegeun

> ---
>   drivers/gpu/drm/vc4/vc4_drv.h |  1 +-
>   drivers/gpu/drm/vc4/vc4_kms.c | 84 +---
>   2 files changed, 50 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index c6208b040f77..c074c0538e57 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -523,6 +523,7 @@ struct vc4_crtc_state {
>   struct drm_mm_node mm;
>   bool feed_txp;
>   bool txp_armed;
> + bool needs_muxing;
>   unsigned int assigned_channel;
>   
>   struct {
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 2aa726b7422c..409aeb19d210 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -224,10 +224,7 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
>   {
>   struct drm_crtc_state *crtc_state;
>   struct drm_crtc *crtc;
> - unsigned char dsp2_mux = 0;
> - unsigned char dsp3_mux = 3;
> - unsigned char dsp4_mux = 3;
> - unsigned char dsp5_mux = 3;
> + unsigned char mux;
>   unsigned int i;
>   u32 reg;
>   
> @@ -235,50 +232,59 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev 
> *vc4,
>   struct vc4_crtc_state *vc4_state = 
> to_vc4_crtc_state(crtc_state);
>   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>   
> - if (!crtc_state->active)
> + if (!vc4_state->needs_muxing)
>   continue;
>   
>   switch (vc4_crtc->data->hvs_output) {
>   case 2:
> - dsp2_mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
> + mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
> + reg = HVS_READ(SCALER_DISPECTRL);
> + HVS_WRITE(SCALER_DISPECTRL,
> +   (reg & ~SCALER_DISPECTRL_DSP2_MUX_MASK) |
> +   VC4_SET_FIELD(mux, 
> SCALER_DISPECTRL_DSP2_MUX));
>   break;
>   
>   case 3:
> - dsp3_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel == 
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPCTRL);
> + HVS_WRITE(SCALER_DISPCTRL,
> +   (reg & ~SCALER_DISPCTRL_DSP3_MUX_MASK) |
> +   VC4_SET_FIELD(mux, SCALER_DISPCTRL_DSP3_MUX));
>   break;
>   
>   case 4:
> - dsp4_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel == 
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPEOLN);
> + HVS_WRITE(SCALER_DISPEOLN,
> +   (reg & ~SCALER_DISPEOLN_DSP4_MUX_MASK) |
> +   VC4_SET_FIELD(mux, SCALER_DISPEOLN_DSP4_MUX));
> +
>   break;
>   
>   case 5:
> - dsp5_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel == 
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPDITHER);
> + HVS_WRITE(SCALER_DISPDITHER,
> +   (reg & ~SCALER_DISPDITHER_DSP5_MUX_MASK) |
> +   VC4_SET_

Re: [PATCH v2 7/7] drm/vc4: kms: Don't disable the muxing of an active CRTC

2020-11-02 Thread Hoegeun Kwon
Hi Maxime,

Thanks for V2 patch.


On 10/28/20 9:41 PM, Maxime Ripard wrote:
> The current HVS muxing code will consider the CRTCs in a given state to
> setup their muxing in the HVS, and disable the other CRTCs muxes.
>
> However, it's valid to only update a single CRTC with a state, and in this
> situation we would mux out a CRTC that was enabled but left untouched by
> the new state.
>
> Fix this by setting a flag on the CRTC state when the muxing has been
> changed, and only change the muxing configuration when that flag is there.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard 
> ---
>   drivers/gpu/drm/vc4/vc4_drv.h |  1 +-
>   drivers/gpu/drm/vc4/vc4_kms.c | 84 +---
>   2 files changed, 50 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index c6208b040f77..c074c0538e57 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -523,6 +523,7 @@ struct vc4_crtc_state {
>   struct drm_mm_node mm;
>   bool feed_txp;
>   bool txp_armed;
> + bool needs_muxing;
>   unsigned int assigned_channel;
>   
>   struct {
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 2aa726b7422c..409aeb19d210 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -224,10 +224,7 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
>   {
>   struct drm_crtc_state *crtc_state;
>   struct drm_crtc *crtc;
> - unsigned char dsp2_mux = 0;
> - unsigned char dsp3_mux = 3;
> - unsigned char dsp4_mux = 3;
> - unsigned char dsp5_mux = 3;
> + unsigned char mux;
>   unsigned int i;
>   u32 reg;
>   
> @@ -235,50 +232,59 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev 
> *vc4,
>   struct vc4_crtc_state *vc4_state = 
> to_vc4_crtc_state(crtc_state);
>   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>   
> - if (!crtc_state->active)
> + if (!vc4_state->needs_muxing)
>   continue;
>   
>   switch (vc4_crtc->data->hvs_output) {
>   case 2:
> - dsp2_mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
> + mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
> + reg = HVS_READ(SCALER_DISPECTRL);
> + HVS_WRITE(SCALER_DISPECTRL,
> +   (reg & ~SCALER_DISPECTRL_DSP2_MUX_MASK) |
> +   VC4_SET_FIELD(mux, 
> SCALER_DISPECTRL_DSP2_MUX));
>   break;
>   
>   case 3:
> - dsp3_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel == 
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPCTRL);
> + HVS_WRITE(SCALER_DISPCTRL,
> +   (reg & ~SCALER_DISPCTRL_DSP3_MUX_MASK) |
> +   VC4_SET_FIELD(mux, SCALER_DISPCTRL_DSP3_MUX));
>   break;
>   
>   case 4:
> - dsp4_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel == 
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPEOLN);
> + HVS_WRITE(SCALER_DISPEOLN,
> +   (reg & ~SCALER_DISPEOLN_DSP4_MUX_MASK) |
> +   VC4_SET_FIELD(mux, SCALER_DISPEOLN_DSP4_MUX));
> +
>   break;
>   
>   case 5:
> - dsp5_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel == 
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPDITHER);
> + HVS_WRITE(SCALER_DISPDITHER,
> +   (reg & ~SCALER_DISPDITHER_DSP5_MUX_MASK) |
> +   VC4_SET_FIELD(mux, 
> SCALER_DISPDITHER_DSP5_MUX));
>   break;
>   
>   default:
>   break;
>   }
>   }
> -
> - reg = HVS_READ(SCALER_DISPECTRL);
> - HVS_WRITE(SCALER_DISPECTRL,
> -   (reg & ~SCALER_DISPECTRL_DSP2_MUX_MASK) |
> -   VC4_SET_FIELD(dsp2_mux, SCALER_DISPECTRL_DSP2_MUX));
> -
> - reg = HVS_READ(SCALER_DISPCTRL);
> - HVS_WRITE(SCALER_DISPCTRL,
> -   (reg & 

[PATCH 0/1] drm/vc4: drv: Add error handding for bind

2020-10-26 Thread Hoegeun Kwon
Hello all,

There is a problem that if vc4_drm bind fails, a memory leak occurs on
the drm_property_create side as shown below. Add error handding for
drm_mode_config.

unreferenced object 0xff80f5a7a6c8 (size 576):
  comm "swapper/0", pid 1, jiffies 4294892559 (age 181.448s)
  hex dump (first 32 bytes):
00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00  
f8 f1 0e f5 80 ff ff ff e0 a6 a7 f5 80 ff ff ff  
  backtrace:
[<fd3656dc>] kmem_cache_alloc+0x1a4/0x328
[<9dfa1aab>] radix_tree_node_alloc.constprop.19+0x50/0x108
[<a9f1657b>] idr_get_free+0x21c/0x2b8
[<99f2eea6>] idr_alloc_u32+0x68/0xf0
[<525beb52>] idr_alloc+0x44/0x80
[<dbfbaa4b>] __drm_mode_object_add+0x64/0xc0
[<2c24dfc8>] drm_mode_object_add+0x3c/0x50
[<f45b491f>] drm_property_create+0xf0/0x1a0
[<2e1a296b>] drm_connector_create_standard_properties+0x30/0x130
[<7c53e4bd>] drm_mode_config_init+0x138/0x498
[<cc1b0767>] vc4_drm_bind+0x168/0x1f8
[<41d69f98>] try_to_bring_up_master+0x180/0x1e8
[<d1e1caae>] component_master_add_with_match+0xbc/0x108
[<85cea46d>] vc4_platform_drm_probe+0xd8/0x108
[<eacabf20>] platform_drv_probe+0x58/0xa8
[<3822d094>] really_probe+0x10c/0x350

Best regards,
Hoegeun

Hoegeun Kwon (1):
  drm/vc4: drv: Add error handding for bind

 drivers/gpu/drm/vc4/vc4_drv.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/1] drm/vc4: drv: Add error handding for bind

2020-10-26 Thread Hoegeun Kwon
There is a problem that if vc4_drm bind fails, a memory leak occurs on
the drm_property_create side. Add error handding for drm_mode_config.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index f1a5fd5dab6f..a17aa1db11b6 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -314,6 +314,7 @@ static int vc4_drm_bind(struct device *dev)
component_unbind_all(dev, drm);
 gem_destroy:
vc4_gem_destroy(drm);
+   drm_mode_config_cleanup(drm);
vc4_bo_cache_destroy(drm);
 dev_put:
drm_dev_put(drm);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/4] drm/vc4: kms: Split the HVS muxing check in a separate function

2020-10-12 Thread Hoegeun Kwon
Hi Maxime,

On 10/8/20 8:25 PM, Maxime Ripard wrote:
> The code that assigns HVS channels during atomic_check is starting to grow
> a bit big, let's move it into a separate function.
>
> Signed-off-by: Maxime Ripard 

Thanks for this patch set, I checked all patches well works.

All patches:

Reviewed-by: Hoegeun Kwon 
Tested-by: Hoegeun Kwon 

Best regards,
Hoegeun

> ---
>   drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
>   1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 149825ff5df8..846fe8b3cb7a 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -612,13 +612,13 @@ static const struct drm_private_state_funcs 
> vc4_load_tracker_state_funcs = {
>   #define NUM_OUTPUTS  6
>   #define NUM_CHANNELS 3
>   
> -static int
> -vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> +static int vc4_pv_muxing_atomic_check(struct drm_device *dev,
> +   struct drm_atomic_state *state)
>   {
>   unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
>   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>   struct drm_crtc *crtc;
> - int i, ret;
> + unsigned int i;
>   
>   /*
>* Since the HVS FIFOs are shared across all the pixelvalves and
> @@ -691,6 +691,18 @@ vc4_atomic_check(struct drm_device *dev, struct 
> drm_atomic_state *state)
>   }
>   }
>   
> + return 0;
> +}
> +
> +static int
> +vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> +{
> + int ret;
> +
> + ret = vc4_pv_muxing_atomic_check(dev, state);
> + if (ret)
> + return ret;
> +
>   ret = vc4_ctm_atomic_check(dev, state);
>   if (ret < 0)
>   return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of active

2020-09-24 Thread Hoegeun Kwon
Hi Maxime,

On 9/18/20 11:59 PM, Maxime Ripard wrote:
> The HVS has three FIFOs that can be assigned to a number of PixelValves
> through a mux.
>
> However, changing that FIFO requires that we disable and then enable the
> pixelvalve, so we want to assign FIFOs to all the enabled CRTCs, and not
> just the active ones.

Thanks for the patch.

There is a problem when doing page flip.
After connecting 2 HDMIs without hotplug and booting.(Same thing when
using hotplug.)

When executing page flip for each of HDMI 0 and 1 in modetest
operation does not work normally. (crtc irq does not occur, so timeout 
occurs.)
Sometimes both hdmi 0 or 1 work or not.

LOGs:
root:~> modetest -Mvc4 -s 32:1280x720 -v
setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
failed to set gamma: Invalid argument
freq: 60.24Hz
freq: 60.00Hz

root:~> modetest -Mvc4 -s 38:1280x720 -v
setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69
failed to set gamma: Invalid argument
select timed out or error (ret 0)
select timed out or error (ret 0)

Could you please check it?

Best regards,
Hoegeun

>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard 
> ---
>   drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index af3ee3dcdab6..01fa60844695 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -643,7 +643,7 @@ vc4_atomic_check(struct drm_device *dev, struct 
> drm_atomic_state *state)
>   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>   unsigned int matching_channels;
>   
> - if (!crtc_state->active)
> + if (!crtc_state->enable)
>   continue;
>   
>   /*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing

2020-09-18 Thread Hoegeun Kwon
Hi Maxime,

On 9/17/20 9:16 PM, Maxime Ripard wrote:
> The vc4 display engine has a first controller called the HVS that will
> perform the composition of the planes. That HVS has 3 FIFOs and can
> therefore compose planes for up to three outputs. The timings part is
> generated through a component called the Pixel Valve, and the BCM2711 has 6
> of them.
>
> Thus, the HVS has some bits to control which FIFO gets output to which
> Pixel Valve. The current code supports that muxing by looking at all the
> CRTCs in a new DRM atomic state in atomic_check, and given the set of
> contraints that we have, assigns FIFOs to CRTCs or reject the mode
> entirely. The actual muxing will occur during atomic_commit.
>
> However, that doesn't work if only a fraction of the CRTCs' state is
> updated in that state, since it will ignore the CRTCs that are kept running
> unmodified, and will thus unassign its associated FIFO, and later disable
> it.
>
> In order to make the code work as expected, let's pull the CRTC state of
> all the enabled CRTC in our atomic_check so that we can operate on all the
> running CRTCs, no matter whether they are affected by the new state or not.
>
> Cc: Hoegeun Kwon 
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard 

Thanks for the quick patch and detailed explanation.

Tested-by: Hoegeun Kwon 
Reviewed-by: Hoegeun Kwon 


Best regards,
Hoegeun

> ---
>   drivers/gpu/drm/vc4/vc4_kms.c | 17 +
>   1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 16e233e1406e..af3ee3dcdab6 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -620,6 +620,23 @@ vc4_atomic_check(struct drm_device *dev, struct 
> drm_atomic_state *state)
>   struct drm_crtc *crtc;
>   int i, ret;
>   
> + /*
> +  * Since the HVS FIFOs are shared across all the pixelvalves and
> +  * the TXP (and thus all the CRTCs), we need to pull the current
> +  * state of all the enabled CRTCs so that an update to a single
> +  * CRTC still keeps the previous FIFOs enabled and assigned to
> +  * the same CRTCs, instead of evaluating only the CRTC being
> +  * modified.
> +  */
> + list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> + if (!crtc->state->enable)
> + continue;
> +
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> + }
> +
>   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   struct vc4_crtc_state *vc4_crtc_state =
>   to_vc4_crtc_state(crtc_state);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-14 Thread Hoegeun Kwon
Hi Maxime,

On 9/8/20 9:00 PM, Maxime Ripard wrote:
> Hi Hoegeun,
>
> On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote:
>> On 9/3/20 5:00 PM, Maxime Ripard wrote:
>>> Hi everyone,
>>>
>>> Here's a (pretty long) series to introduce support in the VC4 DRM driver
>>> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>>>
>>> The main differences are that there's two HDMI controllers and that there's
>>> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
>>> have only 3 FIFOs. Both of those differences are breaking a bunch of
>>> expectations in the driver, so we first need a good bunch of cleanup and
>>> reworks to introduce support for the new controllers.
>>>
>>> Similarly, the HDMI controller has all its registers shuffled and split in
>>> multiple controllers now, so we need a bunch of changes to support this as
>>> well.
>>>
>>> Only the HDMI support is enabled for now (even though the DPI and DSI
>>> outputs have been tested too).
>>>
>>> Let me know if you have any comments
>>> Maxime
>>>
>>> Cc: bcm-kernel-feedback-l...@broadcom.com
>>> Cc: devicet...@vger.kernel.org
>>> Cc: Kamal Dasu 
>>> Cc: Philipp Zabel 
>>> Cc: Rob Herring 
>>> Cc: Stephen Boyd 
>>>
>>> Changes from v4:
>>> - Rebased on top of next-20200828
>>> - Collected the various tags
>>> - Fixed some issues with 4k support and dual output (thanks Hoegeun!)
>> Thanks for your v5 patchset.
>>
>> I tested all patches based on the next-20200812.
> Thanks again for testing all the patches
>
>> Everything else is fine, but the dual hdmi modetest doesn't work well in my
>> environment...
>>
>> In my environment, dsi is not connected, I have seen your answer[1].
> Can you share a bit more your setup? What monitors are being connected
> to each HDMI port? Do you hotplug any?
Yes, Monitors are being connected to each HDMI ports. (did not use hotplug)

When booting, both HDMI-0 and 1 are recognized and the kernel log is output.
But after run modetest on HDMI-0(works) and modetest on HDMI-1(works),
crtc timed out occurs on HDMI-0 and does not work.

When HDMI-0 is not working we do a modetest on HDMI-0, it will work agin
after about 40 sec.

Below is the log for modetest.


root:~> modetest -Mvc4 -s 32:1280x720         - HDMI-0 works
setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
failed to set gamma: Invalid argument

root:~> modetest -Mvc4 -s 32:1280x720         - HDMI-0 works
setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
failed to set gamma: Invalid argument

root:~> modetest -Mvc4 -s 38:1280x720         - HDMI-1 works
setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69
failed to set gamma: Invalid argument

                               - Crtc timed out occurs on HDMI-0 and 
does not work.

[   71.134283] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[   81.374296] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[   91.618380] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CONNECTOR:32:HDMI-A-1] flip_done timed out
[  101.854274] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:60:plane-3] flip_done timed out

[  112.094271] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[  122.590311] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out

root:~> modetest -Mvc4 -s 32:1280x720
[  132.830309] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CONNECTOR:32:HDMI-A-1] flip_done timed out
[  143.070307] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:60:plane-3] flip_done timed out
[  153.310303] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
[  163.550340] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[  173.790277] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CONNECTOR:32:HDMI-A-1] flip_done timed out
[  184.030286] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:60:plane-3] flip_done timed out
failed to set gamma: Invalid argument         - HDMI-0 works


Best regards,
Hoegeun


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:01 PM, Maxime Ripard wrote:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> The VEC and PV3 are left out for now, since it will require a more specific
> clock setup.
>
> Reviewed-by: Dave Stevenson 
> Tested-by: Chanwoo Choi 
> Tested-by: Hoegeun Kwon 
> Tested-by: Stefan Wahren 
> Signed-off-by: Maxime Ripard 

Thanks for your v5 patch


Reviewed-by: Hoegeun Kwon 


Best regards,

Hoegeun

> ---
>   arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  48 +++-
>   arch/arm/boot/dts/bcm2711.dtsi| 122 ++-
>   2 files changed, 169 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index e94244a215af..09a1182c2936 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -70,6 +70,14 @@
>   };
>   };
>   
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>{
>   firmware_clocks: clocks {
>   compatible = "raspberrypi,firmware-clocks";
> @@ -170,6 +178,38 @@
> "RGMII_TXD3";
>   };
>   
> + {
> + clocks = <_clocks 13>, <_clocks 14>, < 0>, 
> <_27MHz>;
> + clock-names = "hdmi", "bvb", "audio", "cec";
> + status = "okay";
> +};
> +
> + {
> + clocks = <_clocks 13>, <_clocks 14>, < 1>, 
> <_27MHz>;
> + clock-names = "hdmi", "bvb", "audio", "cec";
> + status = "okay";
> +};
> +
> + {
> + clocks = <_clocks 4>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>{
>   pinctrl-names = "default";
>   pinctrl-0 = <_0_gpio40 _1_gpio41>;
> @@ -253,3 +293,11 @@
>{
>   interrupts = ;
>   };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> index 00bcaed1be32..4847dd305317 100644
> --- a/arch/arm/boot/dts/bcm2711.dtsi
> +++ b/arch/arm/boot/dts/bcm2711.dtsi
> @@ -12,6 +12,18 @@
>   
>   interrupt-parent = <>;
>   
> + vc4: gpu {
> + compatible = "brcm,bcm2711-vc5";
> + status = "disabled";
> + };
> +
> + clk_27MHz: clk-27M {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + clock-output-names = "27MHz-clock";
> + };
> +
>   clk_108MHz: clk-108M {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> @@ -238,6 +250,27 @@
>   status = "disabled";
>   };
>   
> + pixelvalve0: pixelvalve@7e206000 {
> + compatible = "brcm,bcm2711-pixelvalve0";
> + reg = <0x7e206000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve1: pixelvalve@7e207000 {
> + compatible = "brcm,bcm2711-pixelvalve1";
> + reg = <0x7e207000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve2: pixelvalve@7e20a000 {
> + compatible = "brcm,bcm2711-pixelvalve2";
> + reg = <0x7e20a000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
>   pwm1: pwm@7e20c800 {
>   compatible = "brcm,bcm2835-pwm";
>   reg = <0x7e20c800 0x28>;
> @@ -248,10 +281,25 @@
>   status = "disabled";
>   };
>   
> - hvs@7e40 {
> + pixelvalve4: pixelvalve@7e216000 {
> + compatible = "brcm,bcm2711-pixelvalve4";
> + reg = <0x7e216000 0x100>;
> + interrupts = ;

Re: [PATCH v5 77/80] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:01 PM, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Reviewed-by: Rob Herring 
> Tested-by: Chanwoo Choi 
> Tested-by: Hoegeun Kwon 
> Tested-by: Stefan Wahren 
> Signed-off-by: Maxime Ripard 

Thanks for your v5 patch


Reviewed-by: Hoegeun Kwon 


Best regards,

Hoegeun

> ---
>   Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 117 
> -
>   1 file changed, 117 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index ..03a76729d26c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: 
> https://protect2.fireeye.com/v1/url?k=0b6f5f6c-56a4d852-0b6ed423-0cc47a31309a-d9c680091736128f=1=24b01bb3-08a1-4c21-9bf9-e1d1e9ffdc3e=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbrcm%2Cbcm2711-hdmi.yaml%23
> +$schema: 
> https://protect2.fireeye.com/v1/url?k=a854ae90-f59f29ae-a85525df-0cc47a31309a-1160616098892a41=1=24b01bb3-08a1-4c21-9bf9-e1d1e9ffdc3e=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> +  - Eric Anholt 
> +
> +properties:
> +  compatible:
> +enum:
> +  - brcm,bcm2711-hdmi0
> +  - brcm,bcm2711-hdmi1
> +
> +  reg:
> +items:
> +  - description: HDMI controller register range
> +  - description: DVP register range
> +  - description: HDMI PHY register range
> +  - description: Rate Manager register range
> +  - description: Packet RAM register range
> +  - description: Metadata RAM register range
> +  - description: CSC register range
> +  - description: CEC register range
> +  - description: HD register range
> +
> +  reg-names:
> +items:
> +  - const: hdmi
> +  - const: dvp
> +  - const: phy
> +  - const: rm
> +  - const: packet
> +  - const: metadata
> +  - const: csc
> +  - const: cec
> +  - const: hd
> +
> +  clocks:
> +items:
> +  - description: The HDMI state machine clock
> +  - description: The Pixel BVB clock
> +  - description: The HDMI Audio parent clock
> +  - description: The HDMI CEC parent clock
> +
> +  clock-names:
> +items:
> +  - const: hdmi
> +  - const: bvb
> +  - const: audio
> +  - const: cec
> +
> +  ddc:
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/phandle
> +description: >
> +  Phandle of the I2C controller used for DDC EDID probing
> +
> +  hpd-gpios:
> +description: >
> +  The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> +  as an interrupt/status bit in the HDMI controller itself)
> +
> +  dmas:
> +maxItems: 1
> +description: >
> +  Should contain one entry pointing to the DMA channel used to
> +  transfer audio data.
> +
> +  dma-names:
> +const: audio-rx
> +
> +  resets:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - resets
> +  - ddc
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +hdmi0: hdmi@7ef00700 {
> +compatible = "brcm,bcm2711-hdmi0";
> +reg = <0x7ef00700 0x300>,
> +  <0x7ef00300 0x200>,
> +  <0x7ef00f00 0x80>,
> +  <0x7ef00f80 0x80>,
> +  <0x7ef01b00 0x200>,
> +  <0x7ef01f00 0x400>,
> +  <0x7ef00200 0x80>,
> +  <0x7ef04300 0x100>,
> +  <0x7ef2 0x100>;
> +reg-names = "hdmi",
> +"dvp",
> +"phy",
> +"rm",
> +"packet",
> +"metadata",
> +"csc",
> +"cec",
> +"hd";
> +clocks = <_clocks 13>, <_clocks 14>, < 1>, 
> <_27MHz>;
> +clock-names = "hdmi", "bvb", "audio", "cec";
> +resets = < 0>;
> +ddc = <>;
> +};
> +
> +...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:00 PM, Maxime Ripard wrote:
> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI and DSI
> outputs have been tested too).
>
> Let me know if you have any comments
> Maxime
>
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: devicet...@vger.kernel.org
> Cc: Kamal Dasu 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Stephen Boyd 
>
> Changes from v4:
>- Rebased on top of next-20200828
>- Collected the various tags
>- Fixed some issues with 4k support and dual output (thanks Hoegeun!)

Thanks for your v5 patchset.

I tested all patches based on the next-20200812.

Everything else is fine, but the dual hdmi modetest doesn't work well in my
environment...

In my environment, dsi is not connected, I have seen your answer[1].

Do you have any other settings? For example in config.txt.


[1] https://lkml.org/lkml/2020/9/2/566

>- Fixed typos in commit logs (thanks Dave!)
>- Split the csc setup hook into its own patch again
>- Added the CEC clock to the DT binding
>- Fixed the DT binding example
>- Reduced the number of calls to of_device_is_compatible in vc4_kms_load
>- Added back the check for the state commit in our commit hook

Best regards,

Hoegeun

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control

2020-09-01 Thread Hoegeun Kwon
Hi Chanwoo,

On 9/1/20 1:27 PM, Chanwoo Choi wrote:
> Hi Hoegeun,
>
> It looks good to me. But, just one comment.
>
> On 9/1/20 1:07 PM, Hoegeun Kwon wrote:
>> There is a problem that the output does not work at a resolution
>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>> resolution exceeding FHD.
>>
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>   drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>   drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>>   2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 95ec5eedea39..eb3192d1fd86 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -80,6 +80,7 @@
>>   # define VC4_HD_M_ENABLE   BIT(0)
>>   
>>   #define CEC_CLOCK_FREQ 4
>> +#define VC4_HSM_MID_CLOCK 149985000
>>   
>>   static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>   {
>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
>> drm_encoder *encoder)
>>  HDMI_WRITE(HDMI_VID_CTL,
>> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>   
>> +clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>  clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>  clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>   
>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
>> drm_encoder *encoder)
>>  return;
>>  }
>>   
>> +ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>> +(hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>> +if (ret) {
>> +DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>> +ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>> +if (ret) {
>> +DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
> Generally, enable the clock before using clk and then change the clock rate.
> I think that you better to change the order between clk_prepare_enable and 
> clk_set_rate.

Thank you for your comment.


As Maxime answered in another patch [1], there is no clear rule of order 
here.

[1] https://lkml.org/lkml/2020/9/1/327


Best regards,

Hoegeun


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-31 Thread Hoegeun Kwon
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
 drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 95ec5eedea39..eb3192d1fd86 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -80,6 +80,7 @@
 # define VC4_HD_M_ENABLE   BIT(0)
 
 #define CEC_CLOCK_FREQ 4
+#define VC4_HSM_MID_CLOCK 149985000
 
 static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
 {
@@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
drm_encoder *encoder)
HDMI_WRITE(HDMI_VID_CTL,
   HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
 
+   clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
 
@@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
drm_encoder *encoder)
return;
}
 
+   ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
+   (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
+   if (ret) {
+   DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
+   clk_disable_unprepare(vc4_hdmi->hsm_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
+   return;
+   }
+
+   ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+   if (ret) {
+   DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
+   clk_disable_unprepare(vc4_hdmi->hsm_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
+   return;
+   }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
 
@@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
*vc4_hdmi)
return PTR_ERR(vc4_hdmi->audio_clock);
}
 
+   vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
+   if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
+   DRM_ERROR("Failed to get pixel bvb clock\n");
+   return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+   }
+
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(vc4_hdmi->reset)) {
DRM_ERROR("Failed to get HDMI reset line\n");
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0806c6d9f24e..63c6f8bddf1d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -147,6 +147,7 @@ struct vc4_hdmi {
struct clk *pixel_clock;
struct clk *hsm_clock;
struct clk *audio_clock;
+   struct clk *pixel_bvb_clock;
 
struct reset_control *reset;
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 3/4] dt-bindings: display: vc4: hdmi: Add bvb clock-names property

2020-08-31 Thread Hoegeun Kwon
When using a resolution exceeding FHD, bvb clock is required.
Add bvb clock-names property.

Signed-off-by: Hoegeun Kwon 
---
 .../bindings/display/brcm,bcm2711-hdmi.yaml  | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index 6091fe3d315b..08cdcc579cf5 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
@@ -40,10 +40,14 @@ properties:
   - const: hd
 
   clocks:
-description: The HDMI state machine clock
+items:
+  - description: The HDMI state machine clock
+  - description: The bvb clock
 
   clock-names:
-const: hdmi
+items:
+  - const: hdmi
+  - const: bvb
 
   ddc:
 allOf:
@@ -100,8 +104,8 @@ examples:
 "csc",
 "cec",
 "hd";
-clocks = <_clocks 13>;
-clock-names = "hdmi";
+clocks = <_clocks 13>, <_clocks 14>;
+clock-names = "hdmi", "bvb";
 resets = < 0>;
 ddc = <>;
 };
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/4] drm/vc4: Support HDMI QHD or higher output

2020-08-31 Thread Hoegeun Kwon
Hi everyone,

There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.

Rebased on top of next-20200708 and [1].

[1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's 
patchset)

Changes from v1:
  - Added dt-bindings documents
  - Change patch order, first fix driver and then device tree

Hoegeun Kwon (4):
  clk: bcm: rpi: Add register to control pixel bvb clk
  drm/vc4: hdmi: Add pixel bvb clock control
  dt-bindings: display: vc4: hdmi: Add bvb clock-names property
  ARM: dts: bcm2711: Add bvb clock for hdmi-pixel

 .../bindings/display/brcm,bcm2711-hdmi.yaml   | 12 ++---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  6 +++--
 drivers/clk/bcm/clk-raspberrypi.c |  1 +
 drivers/gpu/drm/vc4/vc4_hdmi.c| 25 +++
 drivers/gpu/drm/vc4/vc4_hdmi.h|  1 +
 5 files changed, 39 insertions(+), 6 deletions(-)

-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/4] clk: bcm: rpi: Add register to control pixel bvb clk

2020-08-31 Thread Hoegeun Kwon
To use QHD or higher, we need to modify the pixel_bvb_clk value. So
add register to control this clock.

Signed-off-by: Hoegeun Kwon 
---
 drivers/clk/bcm/clk-raspberrypi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
b/drivers/clk/bcm/clk-raspberrypi.c
index 5cc82954e1ce..f89b9cfc4309 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -271,6 +271,7 @@ static int raspberrypi_discover_clocks(struct 
raspberrypi_clk *rpi,
case RPI_FIRMWARE_CORE_CLK_ID:
case RPI_FIRMWARE_M2MC_CLK_ID:
case RPI_FIRMWARE_V3D_CLK_ID:
+   case RPI_FIRMWARE_PIXEL_BVB_CLK_ID:
hw = raspberrypi_clk_register(rpi, clks->parent,
  clks->id);
if (IS_ERR(hw))
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 4/4] ARM: dts: bcm2711: Add bvb clock for hdmi-pixel

2020-08-31 Thread Hoegeun Kwon
It is necessary to control the hdmi pixel bvb clock. Add bvb clock.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index b93eb30e1ddb..90dee4cb38bc 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -172,12 +172,14 @@
 };
 
  {
-   clocks = <_clocks 13>, < 0>;
+   clocks = <_clocks 13>, < 0>, <_clocks 14>;
+   clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
 };
 
  {
-   clocks = <_clocks 13>, < 1>;
+   clocks = <_clocks 13>, < 1>, <_clocks 14>;
+   clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
 };
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-31 Thread Hoegeun Kwon
Thank you reviews by Dave, Maxime and Stefan.

On 8/29/20 12:37 AM, Dave Stevenson wrote:
> Hi Maxime, Stefan, and Hoegeun
>
> On Fri, 28 Aug 2020 at 16:25, Maxime Ripard  wrote:
>> Hi,
>>
>> On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
>>> Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
>>>> On 8/27/20 6:49 PM, Stefan Wahren wrote:
>>>>> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>>>>>> Hi Stefan,
>>>>>>
>>>>>> Thank you for your review.
>>>>>>
>>>>>>
>>>>>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>>>>>> Hi Hoeguen,
>>>>>>>
>>>>>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>>>>>>> There is a problem that the output does not work at a resolution
>>>>>>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>>>>>>> resolution exceeding FHD.
>>>>>>> this patch introduces a mandatory clock, please update
>>>>>>> brcm,bcm2835-hdmi.yaml first.
>>>>>>>
>>>>>>> Is this clock physically available on BCM283x or only on BCM2711?
>>>>>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>>>>>
>>>>>> don't supported on pi 3 and pi 3+.
>>>>>>
>>>>>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>>>>>
>>>>>> I don't think we need to modify the bvb clock.
>>>>>>
>>>>>>
>>>>>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>>>>>
>>>>>> instead of 'brcm,bcm2835-hdmi.yaml'.
>>>>> You are correct please update only brcm,bcm2711-hdmi.yaml.
>>>>>
>>>>> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
>>>>> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
>>>>> DTB. So making the BVB clock optional might be better?
>>>> You are right, if use old dtb, we have a problem with the hdmi driver.
>>>>
>>>> So how about modifying it like this?
>>>>
>>>> @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
>>>> *vc4_hdmi)
>>>>
>>>>   vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>>>>   if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>>>> -   DRM_ERROR("Failed to get pixel bvb clock\n");
>>>> -   return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>>>> +   DRM_WARN("Failed to get pixel bvb clock\n");
>>>> +   vc4_hdmi->pixel_bvb_clock = NULL;
>>>>   }
>>> i think the better solution would be devm_clk_get_optional(), which
>>> return NULL in case the clock doesn't exist.
>> It's not really optional though. BCM2711 will require it in order to run
>> properly (as Hoegeun experienced), and the previous SoCs won't.
>>
>> If we use clk_get_optional and that the DT is missing the clock on the
>> BCM2711, we will silently ignore it which doesn't sound great.
> Am I missing something here? (I know I missed this earlier)
> We're in vc5_hdmi_init_resources, which is inherently bcm2711 only.
> bcm283x will go through vc4_hdmi_init_resources.
>
> As long as vc4_hdmi_init_resources has left vc4_hdmi->pixel_bvb_clock
> at NULL, then the clock framework will be happy to do a nop.
>
> For BCM2711 an old DT would have issues, but, as Maxime has stated, no
> binding or upstream DTB has been merged yet, so it can be made
> mandatory.

If so, it seems good to set bvb_clock to mandatory without taking into

account the BCM2711 an old DTB as it hasn't been merged yet.

I will send version 2 patches.

> Making it optional drops you back on whatever the firmware might have
> set it to, which may be sufficient for some resolutions but not
> others.

As a result of checking by adding bvb_clock when I operated it with

the firmware, it was confirmed that the firmware increased the bvb_clock

from 7500 to 15000 when the FHD was exceeded.


Best regards

Hoegeun

>
>Dave
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-28 Thread Hoegeun Kwon
On 8/27/20 6:49 PM, Stefan Wahren wrote:
> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>> Hi Stefan,
>>
>> Thank you for your review.
>>
>>
>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>> Hi Hoeguen,
>>>
>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>>> There is a problem that the output does not work at a resolution
>>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>>> resolution exceeding FHD.
>>> this patch introduces a mandatory clock, please update
>>> brcm,bcm2835-hdmi.yaml first.
>>>
>>> Is this clock physically available on BCM283x or only on BCM2711?
>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>
>> don't supported on pi 3 and pi 3+.
>>
>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>
>> I don't think we need to modify the bvb clock.
>>
>>
>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>
>> instead of 'brcm,bcm2835-hdmi.yaml'.
> You are correct please update only brcm,bcm2711-hdmi.yaml.
>
> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
> DTB. So making the BVB clock optional might be better?

You are right, if use old dtb, we have a problem with the hdmi driver.

So how about modifying it like this?

@@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
*vc4_hdmi)

     vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
     if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
-   DRM_ERROR("Failed to get pixel bvb clock\n");
-   return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+   DRM_WARN("Failed to get pixel bvb clock\n");
+   vc4_hdmi->pixel_bvb_clock = NULL;
     }

     vc4_hdmi->reset = devm_reset_control_get(dev, NULL);

If we modify like this, if there is no bvb clock in dtb, then 
pixel_bvb_clock will be null

and it will not affect the clk control function below.

   - clk_set_rate()
   - clk_prepare_enable()
   - clk_disable_unprepare()


Best regards

Hoegeun

>
>> Please comment, what do you think?
>>
>>> I'm a little bit afraid, this change could break with older firmware
>>> versions on BCM283x.
>> Tested it several times with libdrm modetest.
>>
>> I expect there will be no problem.
>>
>>
>> Best regards,
>>
>> Hoegeun
>>
>>> Best regards
>>> Stefan
>>>
>>>> Signed-off-by: Hoegeun Kwon 
>>>> ---
>>>>drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>>>drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>>>>2 files changed, 26 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c 
>>>> b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>>> index 95ec5eedea39..eb3192d1fd86 100644
>>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>>> @@ -80,6 +80,7 @@
>>>># define VC4_HD_M_ENABLEBIT(0)
>>>>
>>>>#define CEC_CLOCK_FREQ 4
>>>> +#define VC4_HSM_MID_CLOCK 149985000
>>>>
>>>>static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>>>{
>>>> @@ -380,6 +381,7 @@ static void 
>>>> vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder)
>>>>HDMI_WRITE(HDMI_VID_CTL,
>>>>   HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>>>
>>>> +  clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>>>clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>>>clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>>>
>>>> @@ -638,6 +640,23 @@ static void 
>>>> vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder)
>>>>return;
>>>>}
>>>>
>>>> +  ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>>>> +  (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>>>> +  if (ret) {
>>>> +  DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>>>> +  clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>>> +  clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>>> +  return;
>>>> +  }
>>>> +
>>>> +  ret = clk_prepare_en

Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-26 Thread Hoegeun Kwon
Hi Stefan,

Thank you for your review.


On 8/26/20 7:04 PM, Stefan Wahren wrote:
> Hi Hoeguen,
>
> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>> There is a problem that the output does not work at a resolution
>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>> resolution exceeding FHD.
> this patch introduces a mandatory clock, please update
> brcm,bcm2835-hdmi.yaml first.
>
> Is this clock physically available on BCM283x or only on BCM2711?

As far as I know, BCM2711 raspberry pi 4 supports 4k,

don't supported on pi 3 and pi 3+.

Since 4k is not supported in versions prior to Raspberry Pi 4,

I don't think we need to modify the bvb clock.


So I think it is better to update 'brcm,bcm2711-hdmi.yaml'

instead of 'brcm,bcm2835-hdmi.yaml'.

Please comment, what do you think?

>
> I'm a little bit afraid, this change could break with older firmware
> versions on BCM283x.

Tested it several times with libdrm modetest.

I expect there will be no problem.


Best regards,

Hoegeun

>
> Best regards
> Stefan
>
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>   drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>   drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>>   2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 95ec5eedea39..eb3192d1fd86 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -80,6 +80,7 @@
>>   # define VC4_HD_M_ENABLE   BIT(0)
>>   
>>   #define CEC_CLOCK_FREQ 4
>> +#define VC4_HSM_MID_CLOCK 149985000
>>   
>>   static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>   {
>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
>> drm_encoder *encoder)
>>  HDMI_WRITE(HDMI_VID_CTL,
>> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>   
>> +clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>  clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>  clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>   
>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
>> drm_encoder *encoder)
>>  return;
>>  }
>>   
>> +ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>> +(hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>> +if (ret) {
>> +DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>> +ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>> +if (ret) {
>> +DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>>  if (vc4_hdmi->variant->reset)
>>  vc4_hdmi->variant->reset(vc4_hdmi);
>>   
>> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
>> *vc4_hdmi)
>>  return PTR_ERR(vc4_hdmi->audio_clock);
>>  }
>>   
>> +vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>> +if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>> +DRM_ERROR("Failed to get pixel bvb clock\n");
>> +return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>> +}
>> +
>>  vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>>  if (IS_ERR(vc4_hdmi->reset)) {
>>  DRM_ERROR("Failed to get HDMI reset line\n");
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> index 0806c6d9f24e..63c6f8bddf1d 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> @@ -147,6 +147,7 @@ struct vc4_hdmi {
>>  struct clk *pixel_clock;
>>  struct clk *hsm_clock;
>>  struct clk *audio_clock;
>> +struct clk *pixel_bvb_clock;
>>   
>>  struct reset_control *reset;
>>   
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline

2020-08-21 Thread Hoegeun Kwon
Hi Maxime,

Thank you for your version 4 patch.
I tested all 78 patches based on the next-20200708.


Dual HDMI opearation does not work normally.
flip_done timed out occurs and doesn't work.
Could you check please it.

[  105.694541] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[  115.934994] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CONNECTOR:32:HDMI-A-1] flip_done timed out
[  126.174545] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:60:plane-3] flip_done timed out


And there is a problem with 4k UDH not outputting...
So this problem worked as I fixed it like patches[1].

[1] [PATCH 0/3] drm/vc4: Support HDMI QHD or higher output


"[PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline" all patches.

Tested-by: Hoegeun Kwon 

Best regards,
Hoegeun

> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI and DSI
> outputs have been tested too).
>
> Let me know if you have any comments
> Maxime
>
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: devicet...@vger.kernel.org
> Cc: Kamal Dasu 
> Cc: linux-...@vger.kernel.org
> Cc: Michael Turquette 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Stephen Boyd 
>
> Changes from v3:
>- Rebased on top of next-20200708
>- Added a name to the HDMI audio codec component
>- Only disable the BCM2711 HDMI pixelvalves at boot
>- Fixed an error in the HVS binding
>- Fix a framebuffer size condition that was inverted
>- Changed the channel allocation algorithm using Eric's suggestion
>- Always write the muxing values instead of updating if needed
>- Improved a bit the hvs_available_channels comment in the structure
>- Change atomic_complete_commit code to use for_each_new_crtc_in_state
>- Change the muxing code to take into account disparities between the
>  BCM2711 and previous SoCs.
>- Only change the clock rate on BCM2711 during a modeset
>- Fix a crash at atomic_disable
>- Use clk_set_min_rate for the core clock too
>- Add a few defines, and simplify the FIFO level stuff
>- Reordered the patches according to Eric's reviews
>- Fixed a regression with VID_CTL setting on RPI3
>
> Changes from v2:
>- Rebased on top of next-20200526
>- Split the firmware clock series away
>- Removed the stuck pixel (with all the subsequent pixels being shifted
>  by one
>- Fixed the writeback issue too.
>- Fix the dual output
>- Fixed the return value of phy_get_cp_current
>- Enhanced the comment on the reset delay
>- Increase the max width and height
>- Made a proper Kconfig option for the DVP clock driver
>- Fixed the alsa card name collision
>
> Changes from v1:
>- Rebased on top of 5.7-rc1
>- Run checkpatch
>- Added audio support
>- Fixed some HDMI timeouts
>- Swiched to clk_hw_register_gate_parent_data
>- Reorder Kconfig symbols in drivers/i2c/busses
>- Make the firmware clocks a child of the firmware node
>- Switch DVP clock driver to clk_hw interface
>- constify raspberrypi_clk_data in raspberrypi_clock_property
>- Don't mark firmware clocks as IGNORE_UNUSED
>- Change from reset_ms to reset_us in reset-simple, and add a bit more
>  comments
>- Remove generic clk patch to test if a NULL pointer is returned
>- Removed misleading message in the is_prepared renaming patch commit
>  message
>- Constify HDMI controller variants
>- Fix a bug in the allocation size of the clk data array
>- Added a mention in the DT binding conversion patches about the breakage
>- Merged a few fixes from kbuild
>- Fixed a few bisection and CEC build issues
>- Collected Acked-by and Reviewed-by
>- Change Dave email address to raspberrypi.com
>
> Dave Stevenson (7):
>drm/vc4: Add support for the BCM2711 HVS5
>drm/vc4: plane: Change LBM alignment constraint on LBM
>drm/vc4: plane: Optimize the LBM allocation size
>drm/vc4: hdmi: Use reg-names t

[PATCH 2/3] ARM: dts: bcm2711: Add bvb clock for hdmi-pixel

2020-08-21 Thread Hoegeun Kwon
It is necessary to control the hdmi pixel bvb clock. Add bvb clock.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index b93eb30e1ddb..90dee4cb38bc 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -172,12 +172,14 @@
 };
 
  {
-   clocks = <_clocks 13>, < 0>;
+   clocks = <_clocks 13>, < 0>, <_clocks 14>;
+   clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
 };
 
  {
-   clocks = <_clocks 13>, < 1>;
+   clocks = <_clocks 13>, < 1>, <_clocks 14>;
+   clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
 };
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/3] clk: bcm: rpi: Add register to control pixel bvb clk

2020-08-21 Thread Hoegeun Kwon
To use QHD or higher, we need to modify the pixel_bvb_clk value. So
add register to control this clock.

Signed-off-by: Hoegeun Kwon 
---
 drivers/clk/bcm/clk-raspberrypi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
b/drivers/clk/bcm/clk-raspberrypi.c
index 5cc82954e1ce..f89b9cfc4309 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -271,6 +271,7 @@ static int raspberrypi_discover_clocks(struct 
raspberrypi_clk *rpi,
case RPI_FIRMWARE_CORE_CLK_ID:
case RPI_FIRMWARE_M2MC_CLK_ID:
case RPI_FIRMWARE_V3D_CLK_ID:
+   case RPI_FIRMWARE_PIXEL_BVB_CLK_ID:
hw = raspberrypi_clk_register(rpi, clks->parent,
  clks->id);
if (IS_ERR(hw))
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-21 Thread Hoegeun Kwon
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
 drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 95ec5eedea39..eb3192d1fd86 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -80,6 +80,7 @@
 # define VC4_HD_M_ENABLE   BIT(0)
 
 #define CEC_CLOCK_FREQ 4
+#define VC4_HSM_MID_CLOCK 149985000
 
 static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
 {
@@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
drm_encoder *encoder)
HDMI_WRITE(HDMI_VID_CTL,
   HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
 
+   clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
 
@@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
drm_encoder *encoder)
return;
}
 
+   ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
+   (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
+   if (ret) {
+   DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
+   clk_disable_unprepare(vc4_hdmi->hsm_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
+   return;
+   }
+
+   ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+   if (ret) {
+   DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
+   clk_disable_unprepare(vc4_hdmi->hsm_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
+   return;
+   }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
 
@@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
*vc4_hdmi)
return PTR_ERR(vc4_hdmi->audio_clock);
}
 
+   vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
+   if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
+   DRM_ERROR("Failed to get pixel bvb clock\n");
+   return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+   }
+
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(vc4_hdmi->reset)) {
DRM_ERROR("Failed to get HDMI reset line\n");
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0806c6d9f24e..63c6f8bddf1d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -147,6 +147,7 @@ struct vc4_hdmi {
struct clk *pixel_clock;
struct clk *hsm_clock;
struct clk *audio_clock;
+   struct clk *pixel_bvb_clock;
 
struct reset_control *reset;
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/3] drm/vc4: Support HDMI QHD or higher output

2020-08-21 Thread Hoegeun Kwon
Hi everyone,

There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.

Rebased on top of next-20200708 and [1].

[1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's 
patchset)

Hoegeun Kwon (3):
  clk: bcm: rpi: Add register to control pixel bvb clk
  ARM: dts: bcm2711: Add bvb clock for hdmi-pixel
  drm/vc4: hdmi: Add pixel bvb clock control

 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  6 --
 drivers/clk/bcm/clk-raspberrypi.c |  1 +
 drivers/gpu/drm/vc4/vc4_hdmi.c| 25 +
 drivers/gpu/drm/vc4/vc4_hdmi.h|  1 +
 4 files changed, 31 insertions(+), 2 deletions(-)

-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI

2019-05-22 Thread Hoegeun Kwon
On 4/10/19 1:24 AM, Eric Anholt wrote:
> Hoegeun Kwon  writes:
>
>> On 4/2/19 2:48 AM, Eric Anholt wrote:
>>> Hoegeun Kwon  writes:
>>>
>>>> There is a problem when often dpms goes from off to on. pm idle is not
>>>> in sync and the problem occurs. Modify pm_runtime_put from
>>>> asynchronous to synchronous.
>>> Why would we need the power domain to go to off before we try to come
>>> back?  Any idea?  Also, please specify what "the problem" is.
>> Hi Eric,
>>
>>
>> First thank you for your review.
>>
>> There is a problem failed to runtime PM enable on DSI when often dpms
> What do you mean by "failed to runtime PM enable"?  The
> pm_runtime_enable() returned an error?  Have you investigated the source
> that error, if so?

I'm sorry for the late reply.

The pm_runtime_enable() is not returned because return value is void.

The problem is that if the error log is not output
and the DPMS off on is repeated, the screen will stop.

As a result of debugging the problem, I think that synchronization
is a problem caused by dsi pm_suspend and resume.

So when we entered the pm runtime idle state, if used with sync,
the problem does not occur.

Best regards,
Hoegeun


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI

2019-04-07 Thread Hoegeun Kwon
On 4/2/19 2:48 AM, Eric Anholt wrote:
> Hoegeun Kwon  writes:
>
>> There is a problem when often dpms goes from off to on. pm idle is not
>> in sync and the problem occurs. Modify pm_runtime_put from
>> asynchronous to synchronous.
> Why would we need the power domain to go to off before we try to come
> back?  Any idea?  Also, please specify what "the problem" is.

Hi Eric,


First thank you for your review.

There is a problem failed to runtime PM enable on DSI when often dpms

goes from off to on. The cause of this problem is that when we put pm idle,

I think that there is a timing problem if I do not sync.


Best regards,

Hoegeun


>
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>   drivers/gpu/drm/vc4/vc4_dsi.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
>> index 11702e1d9011..b0264c7b8bed 100644
>> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
>> @@ -822,7 +822,7 @@ static void vc4_dsi_encoder_disable(struct drm_encoder 
>> *encoder)
>>  clk_disable_unprepare(dsi->escape_clock);
>>  clk_disable_unprepare(dsi->pixel_clock);
>>   
>> -pm_runtime_put(dev);
>> +pm_runtime_put_sync(dev);
>>   }
>>   
>>   /* Extends the mode's blank intervals to handle BCM2835's integer-only
>> -- 
>> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI

2019-03-28 Thread Hoegeun Kwon
There is a problem when often dpms goes from off to on. pm idle is not
in sync and the problem occurs. Modify pm_runtime_put from
asynchronous to synchronous.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 11702e1d9011..b0264c7b8bed 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -822,7 +822,7 @@ static void vc4_dsi_encoder_disable(struct drm_encoder 
*encoder)
clk_disable_unprepare(dsi->escape_clock);
clk_disable_unprepare(dsi->pixel_clock);
 
-   pm_runtime_put(dev);
+   pm_runtime_put_sync(dev);
 }
 
 /* Extends the mode's blank intervals to handle BCM2835's integer-only
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/crtc-helper: Add store the property value

2019-01-17 Thread Hoegeun Kwon
On 1/17/19 9:15 PM, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 10:57 AM Hoegeun Kwon  
> wrote:
>>
>> On 1/17/19 6:20 PM, Daniel Vetter wrote:
>>> On Thu, Jan 17, 2019 at 05:50:44PM +0900, Hoegeun Kwon wrote:
>>>> There is a problem in crtc_helper that property value is not updated
>>>> when dpms is turned on or off. So modify the property value when dpms
>>>> is on.
>>>>
>>>> Signed-off-by: Hoegeun Kwon 
>>> This is fixed with atomic, and exynos is atomic. Why do you care about
>>> this?
>>> -Daniel
>>
>> Thank you Daniel.
>>
>> That's right, there is no problem with exynos because it uses atomic.
>>
>> But I think it could be a problem with other connectors that do not use
>> atoms.
> Yeah, but not sure we care about those drivers all that much. If
> someone does, probably better to convert them to atomic (which is
> still happening). We did have the equivalent of your patch in the i915
> legacy modeset code, but it was quite tricky to get right. Much easier
> with atomic, where properties have the right value by design.
> -Daniel


Thank you for the detailed explanation.

Please ignore this patch.


Best regards,

Hoegeun


>
>> Best regards,
>>
>> Hoegeun
>>
>>
>>>> ---
>>>>drivers/gpu/drm/drm_crtc_helper.c | 4 
>>>>1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
>>>> b/drivers/gpu/drm/drm_crtc_helper.c
>>>> index a3c81850e755..57d359f0725c 100644
>>>> --- a/drivers/gpu/drm/drm_crtc_helper.c
>>>> +++ b/drivers/gpu/drm/drm_crtc_helper.c
>>>> @@ -735,6 +735,10 @@ int drm_crtc_helper_set_config(struct drm_mode_set 
>>>> *set,
>>>>   DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS 
>>>> on\n", set->connectors[i]->base.id,
>>>> set->connectors[i]->name);
>>>>   
>>>> set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
>>>> +
>>>> +
>>>> drm_object_property_set_value(>connectors[i]->base,
>>>> +
>>>> set->connectors[i]->dev->mode_config.dpms_property,
>>>> +DRM_MODE_DPMS_ON);
>>>>   }
>>>>   }
>>>>   __drm_helper_disable_unused_functions(dev);
>>>> --
>>>> 2.17.1
>>>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/crtc-helper: Add store the property value

2019-01-17 Thread Hoegeun Kwon

On 1/17/19 6:20 PM, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 05:50:44PM +0900, Hoegeun Kwon wrote:
>> There is a problem in crtc_helper that property value is not updated
>> when dpms is turned on or off. So modify the property value when dpms
>> is on.
>>
>> Signed-off-by: Hoegeun Kwon 
> This is fixed with atomic, and exynos is atomic. Why do you care about
> this?
> -Daniel


Thank you Daniel.

That's right, there is no problem with exynos because it uses atomic.

But I think it could be a problem with other connectors that do not use 
atoms.


Best regards,

Hoegeun


>
>> ---
>>   drivers/gpu/drm/drm_crtc_helper.c | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
>> b/drivers/gpu/drm/drm_crtc_helper.c
>> index a3c81850e755..57d359f0725c 100644
>> --- a/drivers/gpu/drm/drm_crtc_helper.c
>> +++ b/drivers/gpu/drm/drm_crtc_helper.c
>> @@ -735,6 +735,10 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>>  DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS 
>> on\n", set->connectors[i]->base.id,
>>set->connectors[i]->name);
>>  
>> set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
>> +
>> +
>> drm_object_property_set_value(>connectors[i]->base,
>> +
>> set->connectors[i]->dev->mode_config.dpms_property,
>> +DRM_MODE_DPMS_ON);
>>  }
>>  }
>>  __drm_helper_disable_unused_functions(dev);
>> -- 
>> 2.17.1
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/crtc-helper: Add store the property value

2019-01-17 Thread Hoegeun Kwon
There is a problem in crtc_helper that property value is not updated
when dpms is turned on or off. So modify the property value when dpms
is on.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/drm_crtc_helper.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index a3c81850e755..57d359f0725c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -735,6 +735,10 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS 
on\n", set->connectors[i]->base.id,
  set->connectors[i]->name);

set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
+
+   
drm_object_property_set_value(>connectors[i]->base,
+   
set->connectors[i]->dev->mode_config.dpms_property,
+   DRM_MODE_DPMS_ON);
}
}
__drm_helper_disable_unused_functions(dev);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/9] drm/exynos: ipp: Add IPP v2 framework

2017-10-10 Thread Hoegeun Kwon

Hi Marek,

Currently, IPP v2 and gsc do not seem to have any code to
check for hardware limits. How can I check the hardware limits
of device(gsc, rotator, ...) at IPP v2?

Best regards,
Hoegeun

On 09/29/2017 04:32 PM, Marek Szyprowski wrote:

This patch adds Exynos IPP v2 subsystem and userspace API.

New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging IPP operation modes (framebuffer writeback and
local-path output with image processing) can be implemented using
standard DRM features: writeback connectors and additional DRM planes with
scaling features.

V2 IPP userspace API is not compatible with old IPP ioctls. This is a
significant change, but the old IPP subsystem in mainline Linux kernel was
partially disfunctional anyway and not used in any open-source project.

V2 IPP userspace API is based on stateless approach, which much better fits
to memory-to-memory image processing model. It also provides support for
all image formats, which are both already defined in DRM API and supported
by the existing IPP hardware modules.

The API consists of the following ioctls:
- DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
   processing modules,
- DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
   formats of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
   selected image format of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
   provided structures (source and destination buffers, operation rectangle,
   transformation, etc).

The proposed userspace API is extensible. In the future more advanced image
processing operations can be defined to support for example blending.

Userspace API is fully functional also on DRM render nodes, so it is not
limited to the root/privileged client.

Internal driver API also has been completely rewritten. New IPP core
performs all possible input validation, checks and object life-time
control. The drivers can focus only on writing configuration to hardware
registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
the driver API. Minimal driver needs to provide a single callback for
starting processing and an array with supported image formats.

Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
Tested-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/exynos/Kconfig  |   3 +
  drivers/gpu/drm/exynos/Makefile |   1 +
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   9 +
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 894 
  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 191 +++
  include/uapi/drm/exynos_drm.h   | 238 +
  6 files changed, 1336 insertions(+)
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 88cff0e039b6..2e097a81df12 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,6 +94,9 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
  
+config DRM_EXYNOS_IPP

+   bool
+
  config DRM_EXYNOS_FIMC
bool "FIMC"
depends on BROKEN && MFD_SYSCON
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 09bb002c9555..f663490e949d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,6 +17,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= exynos_drm_rotator.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2fc5d3c01390..de4cce258a5b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -26,6 +26,7 @@
  #include "exynos_drm_fb.h"
  #include "exynos_drm_gem.h"
  #include "exynos_drm_plane.h"
+#include "exynos_drm_ipp.h"
  #include "exynos_drm_vidi.h"
  #include "exynos_drm_g2d.h"
  #include "exynos_drm_iommu.h"
@@ -114,6 +115,14 @@ static void exynos_drm_lastclose(struct drm_device *dev)
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES, 
exynos_drm_ipp_get_res_ioctl,
+   DRM_AU

Re: [PATCH v2 4/9] drm/exynos: gsc: Convert driver to IPP v2 core API

2017-10-10 Thread Hoegeun Kwon

Hi Marek,

On 09/29/2017 04:32 PM, Marek Szyprowski wrote:

This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.

Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
Tested-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/exynos/Kconfig  |   3 +-
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 +
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 853 
  drivers/gpu/drm/exynos/exynos_drm_gsc.h |  24 -
  4 files changed, 198 insertions(+), 683 deletions(-)
  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h



...


+static int gsc_bind(struct device *dev, struct device *master, void *data)
+{
+   struct gsc_context *ctx = dev_get_drvdata(dev);
+   struct drm_device *drm_dev = data;
+   struct exynos_drm_ipp *ipp = >ipp;
+
+   ctx->drm_dev = drm_dev;
+   drm_iommu_attach_device(drm_dev, dev);
+
+   exynos_drm_ipp_register(drm_dev, ipp, _funcs,
+  DRM_EXYNOS_IPP_CAP_CROP | DRM_EXYNOS_IPP_CAP_ROTATE |
+  DRM_EXYNOS_IPP_CAP_SCALE | 
DRM_EXYNOS_IPP_CAP_CONVERT,
+  gsc_formats, "gsc");
+
+   dev_info(dev, "The exynos gscaler is probed successfully\n");
+
+   return 0;
  }
  
+static void gsc_unbind(struct device *dev, struct device *master,

+   void *data)
+{
+   struct gsc_context *ctx = dev_get_drvdata(dev);


I think there is missing ipp_unregister() in unbind() of GSC and FIMC.

struct drm_device *drm_dev = data;
struct exynos_drm_ipp *ipp = >ipp;

exynos_drm_ipp_unregister(drm_dev, ipp);

Best regards,
Hoegeun


+
+   drm_iommu_detach_device(ctx->drm_dev, ctx->dev);
+}
+
+static const struct component_ops gsc_component_ops = {
+   .bind   = gsc_bind,
+   .unbind = gsc_unbind,
+};
+
+
  static int gsc_probe(struct platform_device *pdev)
  {
struct device *dev = >dev;
struct gsc_context *ctx;
struct resource *res;
-   struct exynos_drm_ippdrv *ippdrv;
int ret;
  
  	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);

if (!ctx)
return -ENOMEM;
  
-	if (dev->of_node) {

-   ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
-   "samsung,sysreg");
-   if (IS_ERR(ctx->sysreg)) {
-   dev_warn(dev, "failed to get system register.\n");
-   ctx->sysreg = NULL;
-   }
-   }
+   ctx->dev = dev;
  
  	/* clock control */

ctx->gsc_clk = devm_clk_get(dev, "gscl");
@@ -1699,8 +1260,8 @@ static int gsc_probe(struct platform_device *pdev)
}
  
  	ctx->irq = res->start;

-   ret = devm_request_threaded_irq(dev, ctx->irq, NULL, gsc_irq_handler,
-   IRQF_ONESHOT, "drm_gsc", ctx);
+   ret = devm_request_irq(dev, ctx->irq, gsc_irq_handler, 0,
+  dev_name(dev), ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
return ret;
@@ -1709,38 +1270,19 @@ static int gsc_probe(struct platform_device *pdev)
/* context initailization */
ctx->id = pdev->id;
  
-	ippdrv = >ippdrv;

-   ippdrv->dev = dev;
-   ippdrv->ops[EXYNOS_DRM_OPS_SRC] = _src_ops;
-   ippdrv->ops[EXYNOS_DRM_OPS_DST] = _dst_ops;
-   ippdrv->check_property = gsc_ippdrv_check_property;
-   ippdrv->reset = gsc_ippdrv_reset;
-   ippdrv->start = gsc_ippdrv_start;
-   ippdrv->stop = gsc_ippdrv_stop;
-   ret = gsc_init_prop_list(ippdrv);
-   if (ret < 0) {
-   dev_err(dev, "failed to init property list.\n");
-   return ret;
-   }
-
-   DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
-
-   mutex_init(>lock);
platform_set_drvdata(pdev, ctx);
  
  	pm_runtime_enable(dev);
  
-	ret = exynos_drm_ippdrv_register(ippdrv);

-   if (ret < 0) {
-   dev_err(dev, "failed to register drm gsc device.\n");
-   goto err_ippdrv_register;
-   }
+   ret = component_add(dev, _component_ops);
+   if (ret)
+   goto err_pm_dis;
  
  	dev_info(dev, "drm gsc registered successfully.\n");
  
  	return 0;
  
-err_ippdrv_register:

+err_pm_dis:
pm_runtime_disable(dev);
return ret;
  }
@@ -1748,11 +1290,6 @@ static int gsc_probe(struct platform_device *pdev)
  static int gsc_remove(struct platform_device *pdev)
  {
struct device *dev = >dev;
-   struct gsc_context *ctx = get_gsc_context(dev);
-   struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-
-   exynos_drm

Re: [PATCH 2/6] drm/exynos: ipp: Add IPP v2 framework

2017-09-20 Thread Hoegeun Kwon

Hi Marek,

Tested-by: Hoegeun Kwon <hoegeun.k...@samsung.com>

Best regards,
Hoegeun



On 09/12/2017 05:08 PM, Marek Szyprowski wrote:

This patch adds Exynos IPP v2 subsystem and userspace API.

New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging IPP operation modes (framebuffer writeback and
local-path output with image processing) can be implemented using
standard DRM features: writeback connectors and additional DRM planes with
scaling features.

V2 IPP userspace API is not compatible with old IPP ioctls. This is a
significant change, but the old IPP subsystem in mainline Linux kernel was
partially disfunctional anyway and not used in any open-source project.

V2 IPP userspace API is based on stateless approach, which much better fits
to memory-to-memory image processing model. It also provides support for
all image formats, which are both already defined in DRM API and supported
by the existing IPP hardware modules.

The API consists of the following ioctls:
- DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
   processing modules,
- DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
   formats of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
   selected image format of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
   provided structures (source and destination buffers, operation rectangle,
   transformation, etc).

The proposed userspace API is extensible. In the future more advanced image
processing operations can be defined to support for example blending.

Userspace API is fully functional also on DRM render nodes, so it is not
limited to the root/privileged client.

Internal driver API also has been completely rewritten. New IPP core
performs all possible input validation, checks and object life-time
control. The drivers can focus only on writing configuration to hardware
registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
the driver API. Minimal driver needs to provide a single callback for
starting processing and an array with supported image formats.

Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
---
  drivers/gpu/drm/exynos/Kconfig  |   3 +
  drivers/gpu/drm/exynos/Makefile |   1 +
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   9 +
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 893 
  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 188 +++
  include/uapi/drm/exynos_drm.h   | 227 
  6 files changed, 1321 insertions(+)
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 88cff0e039b6..2e097a81df12 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,6 +94,9 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
  
+config DRM_EXYNOS_IPP

+   bool
+
  config DRM_EXYNOS_FIMC
bool "FIMC"
depends on BROKEN && MFD_SYSCON
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 09bb002c9555..f663490e949d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,6 +17,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= exynos_drm_rotator.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7f19054ebce3..645046c5943a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -26,6 +26,7 @@
  #include "exynos_drm_fb.h"
  #include "exynos_drm_gem.h"
  #include "exynos_drm_plane.h"
+#include "exynos_drm_ipp.h"
  #include "exynos_drm_vidi.h"
  #include "exynos_drm_g2d.h"
  #include "exynos_drm_iommu.h"
@@ -114,6 +115,14 @@ static void exynos_drm_lastclose(struct drm_device *dev)
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES, 
exynos_drm_ipp_get_res_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_CAPS, exynos_drm_ipp_get_caps_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOC

Re: [PATCH 1/6] drm/exynos: ipp: Remove Exynos DRM IPP subsystem

2017-09-20 Thread Hoegeun Kwon

Hi Marek,

Tested-by: Hoegeun Kwon <hoegeun.k...@samsung.com>

Best regards,
Hoegeun


On 09/12/2017 05:08 PM, Marek Szyprowski wrote:

Exynos IPP will be rewritten, so remove current IPP core code and mark
existing drivers as BROKEN.

Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
---
  drivers/gpu/drm/exynos/Kconfig  |   11 +-
  drivers/gpu/drm/exynos/Makefile |1 -
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   12 -
  drivers/gpu/drm/exynos/exynos_drm_drv.h |2 -
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1806 ---
  drivers/gpu/drm/exynos/exynos_drm_ipp.h |  252 -
  include/uapi/drm/exynos_drm.h   |  192 +---
  7 files changed, 4 insertions(+), 2272 deletions(-)
  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 305dc3d4ff77..88cff0e039b6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,26 +94,21 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
  
-config DRM_EXYNOS_IPP

-   bool "Image Post Processor"
-   help
- Choose this option if you want to use IPP feature for DRM.
-
  config DRM_EXYNOS_FIMC
bool "FIMC"
-   depends on DRM_EXYNOS_IPP && MFD_SYSCON
+   depends on BROKEN && MFD_SYSCON
help
  Choose this option if you want to use Exynos FIMC for DRM.
  
  config DRM_EXYNOS_ROTATOR

bool "Rotator"
-   depends on DRM_EXYNOS_IPP
+   depends on BROKEN
help
  Choose this option if you want to use Exynos Rotator for DRM.
  
  config DRM_EXYNOS_GSC

bool "GScaler"
-   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+   depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
  Choose this option if you want to use Exynos GSC for DRM.
  
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile

index f663490e949d..09bb002c9555 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,7 +17,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= exynos_drm_rotator.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b1f7299600f0..7f19054ebce3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -28,7 +28,6 @@
  #include "exynos_drm_plane.h"
  #include "exynos_drm_vidi.h"
  #include "exynos_drm_g2d.h"
-#include "exynos_drm_ipp.h"
  #include "exynos_drm_iommu.h"
  
  #define DRIVER_NAME	"exynos"

@@ -115,14 +114,6 @@ static void exynos_drm_lastclose(struct drm_device *dev)
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY, exynos_drm_ipp_get_property,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY, exynos_drm_ipp_set_property,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF, exynos_drm_ipp_queue_buf,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL, exynos_drm_ipp_cmd_ctrl,
-   DRM_AUTH | DRM_RENDER_ALLOW),
  };
  
  static const struct file_operations exynos_drm_driver_fops = {

@@ -272,9 +263,6 @@ struct exynos_drm_driver_info {
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
}, {
-   DRV_PTR(ipp_driver, CONFIG_DRM_EXYNOS_IPP),
-   DRM_VIRTUAL_DEVICE
-   }, {
_drm_platform_driver,
DRM_VIRTUAL_DEVICE
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cf131c2aa23e..21f4271c012a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -185,7 +185,6 @@ struct exynos_drm_g2d_private {
  
  struct drm_exynos_file_private {

struct exynos_drm_g2d_private   *g2d_priv;
-   struct device   *ipp_dev;
  };
  
  /*

@@ -292,6 +291,5 @@ int exynos_atomic_commit(struc

Re: [PATCH 4/6] drm/exynos: gsc: Convert driver to IPP v2 core API

2017-09-20 Thread Hoegeun Kwon

Hi Marek,

Tested-by: Hoegeun Kwon <hoegeun.k...@samsung.com>

Best regards,
Hoegeun



On 09/12/2017 05:08 PM, Marek Szyprowski wrote:

This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.

Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
---
  drivers/gpu/drm/exynos/Kconfig  |   3 +-
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 +
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 853 
  drivers/gpu/drm/exynos/exynos_drm_gsc.h |  24 -
  4 files changed, 198 insertions(+), 683 deletions(-)
  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index c10c9ca0d8b4..4bb9edb00601 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -111,7 +111,8 @@ config DRM_EXYNOS_ROTATOR
  
  config DRM_EXYNOS_GSC

bool "GScaler"
-   depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+   depends on ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+   select DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos GSC for DRM.
  
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c

index 277e444b0be6..27242af103ea 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -272,6 +272,7 @@ struct exynos_drm_driver_info {
DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
+   DRM_COMPONENT_DRIVER
}, {
_drm_platform_driver,
DRM_VIRTUAL_DEVICE
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b17ac1..1293441a4212 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -12,6 +12,7 @@
   *
   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -22,8 +23,8 @@
  #include 
  #include "regs-gsc.h"
  #include "exynos_drm_drv.h"
+#include "exynos_drm_iommu.h"
  #include "exynos_drm_ipp.h"
-#include "exynos_drm_gsc.h"
  
  /*

   * GSC stands for General SCaler and
@@ -31,26 +32,9 @@
   * input DMA reads image data from the memory.
   * output DMA writes image data to memory.
   * GSC supports image rotation and image effect functions.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > GSC H/W > Memory.
- * Writeback operation : supports cloned screen with FIMD.
- * FIMD > GSC H/W > Memory.
- * Output operation : supports direct display using local path.
- * Memory > GSC H/W > FIMD, Mixer.
   */
  
-/*

- * TODO
- * 1. check suspend/resume api if needed.
- * 2. need to check use case platform_device_id.
- * 3. check src/dst size with, height.
- * 4. added check_prepare api for right register.
- * 5. need to add supported list in prop_list.
- * 6. check prescaler/scaler optimization.
- */
  
-#define GSC_MAX_DEVS	4

  #define GSC_MAX_SRC   4
  #define GSC_MAX_DST   16
  #define GSC_RESET_TIMEOUT 50
@@ -65,8 +49,6 @@
  #define GSC_SC_DOWN_RATIO_4_8 131072
  #define GSC_SC_DOWN_RATIO_3_8 174762
  #define GSC_SC_DOWN_RATIO_2_8 262144
-#define GSC_REFRESH_MIN12
-#define GSC_REFRESH_MAX60
  #define GSC_CROP_MAX  8192
  #define GSC_CROP_MIN  32
  #define GSC_SCALE_MAX 4224
@@ -79,8 +61,6 @@
  #define GSC_COEF_DEPTH3
  
  #define get_gsc_context(dev)	platform_get_drvdata(to_platform_device(dev))

-#define get_ctx_from_ippdrv(ippdrv)container_of(ippdrv,\
-   struct gsc_context, ippdrv);
  #define gsc_read(offset)  readl(ctx->regs + (offset))
  #define gsc_write(cfg, offset)writel(cfg, ctx->regs + (offset))
  
@@ -124,7 +104,6 @@ struct gsc_capability {

  /*
   * A structure of gsc context.
   *
- * @ippdrv: prepare initialization using ippdrv.
   * @regs_res: register resources.
   * @regs: memory mapped io registers.
   * @sysreg: handle to SYSREG block regmap.
@@ -137,11 +116,14 @@ struct gsc_capability {
   * @suspended: qos operations.
   */
  struct gsc_context {
-   struct exynos_drm_ippdrvippdrv;
+   struct exynos_drm_ipp ipp;
+   struct drm_device *drm_dev;
+   struct device   *dev;
+   struct exynos_drm_ipp_task  *task;
+
struct resource *regs_res;
void __iomem*regs;
struct regmap   *sysreg;
-   struct mutexlock;
struct clk  *gsc_clk;
struct gsc_scaler   sc;
int id;
@@ -438,25 +420,6 @@ static int gsc_sw_reset(struct gsc_context *ctx)
return 0;
  }
  
-static void gsc_

[RESEND PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-09-17 Thread Hoegeun Kwon
 The display-timing and delay are included in the panel driver. So it
 should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hi Krzysztof,

This patch was rebased to the mainline (v4.14-rc1).

Best regards,
Hoegeun

 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 0b45467..ff792ff 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
};
 };
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon

On 09/13/2017 09:13 PM, Sylwester Nawrocki wrote:

On 09/13/2017 01:41 PM, Hoegeun Kwon wrote:
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

  .num_clocks = 1,
  };
  +static struct gsc_driverdata gsc_v_5250_drvdata = {
+.variant = {
+[0] = _v_5250_variant,
+[1] = _v_5250_variant,
+[2] = _v_5250_variant,
+[3] = _v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = _v_5420_variant,
+[1] = _v_5420_variant,
+},
+.num_entities = 4,


Shouldn't num_enities be 2 here? You don't need to resend, I can
amend that when applying.




Yes, num_enities is 2.
Sorry I made a mistake.

Thanks Sylwester.

Best regards,
Hoegeun


+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+


--
Regards,
Sylwester




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 0/4] Exynos-gsc: Support the hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
Hello all,

Frist, thanks Krzysztof, Robin and Sylwester.

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Changes for V4:
- Fixed the most specific compatible come first in device tree.
- Kept compatible("samsung,exynos5-gsc") in ther driver.
- Added mark compatible("samsung,exynos5-gsc") as deprecated.
- Added print dmesg if your driver uses compatible("samsung, exynos5-gsc").
- Removed the patch 5, 6 of ver3.

Changes for V3:
- Fixed of_match_node() to of_device_get_match_data() in drm gsc driver.
- Added hardware rotation limits for gsc driver of v4l2.
- Added the remove unnecessary compatible for DT document and Exynos dts.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (4):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits
  [media] exynos-gsc: Add hardware rotation limits

 .../devicetree/bindings/media/exynos5-gsc.txt  |   9 +-
 arch/arm/boot/dts/exynos5250.dtsi  |   8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 104 -
 drivers/media/platform/exynos-gsc/gsc-core.c   | 127 -
 include/uapi/drm/exynos_drm.h  |   2 +
 6 files changed, 211 insertions(+), 43 deletions(-)

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 127 +--
 1 file changed, 122 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..173a238 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -958,6 +958,51 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_rot_en_h= 2016,
 };
 
+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2047,
+   .real_rot_en_h  = 2047,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
 static struct gsc_pix_min gsc_v_100_min = {
.org_w  = 64,
.org_h  = 32,
@@ -992,6 +1037,45 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
 };
 
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= _v_5250_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= _v_5420_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= _v_5433_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
 static struct gsc_driverdata gsc_v_100_drvdata = {
.variant = {
[0] = _v_100_variant,
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.num_clocks = 1,
 };
 
+static struct gsc_driverdata gsc_v_5250_drvdata = {
+   .variant = {
+   [0] = _v_5250_variant,
+   [1] = _v_5250_variant,
+   [2] = _v_5250_variant,
+   [3] = _v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = _v_5420_variant,
+   [1] = _v_5420_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
 static struct gsc_driverdata gsc_5433_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
+   [0] = _v_5433_variant,
+   [1] = _v_5433_v

[PATCH v4 3/4] drm/exynos/gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 104 +++-
 include/uapi/drm/exynos_drm.h   |   2 +
 2 files changed, 77 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..66a19d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -150,6 +151,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1411,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1443,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1450,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1481,17 @@ static int

[PATCH v4 1/4] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-13 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..0d4fdae 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,8 +3,11 @@
 G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
 
 Required properties:
-- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
- 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+- compatible: should be one of
+ "samsung,exynos5250-gsc"
+ "samsung,exynos5420-gsc"
+ "samsung,exynos5433-gsc"
+ "samsung,exynos5-gsc" (deprecated)
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
@@ -15,7 +18,7 @@ Optional properties:
 Example:
 
 gsc_0:  gsc@0x13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = <0 85 0>;
 };
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 2/4] ARM: dts: exynos: Add clean name of compatible.

2017-09-13 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..d0d0460 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..6166730 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5420-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5420-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon

On 09/13/2017 06:11 PM, Sylwester Nawrocki wrote:

Hi Hoegeun,

On 09/13/2017 04:33 AM, Hoegeun Kwon wrote:

@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq,
void *priv)
  static const struct of_device_id exynos_gsc_match[] = {
{
-.compatible = "samsung,exynos5-gsc",
-.data = _v_100_drvdata,

Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
data, so that it can work with "samsung,exynos5-gsc" compatible in DT
on both exynos5250 and exynos5420 SoCs?


Thank you for your question.

Exynos 5250 and 5420 have different hardware rotation limits.
Exynos 5250 is '.real_rot_en_w/h = 2016' and 5420 is '.real_rot_en_w/h =
2048'.

So my opinion they must have different compatible.

I think there is some misunderstanding, mu suggestion was to keep the
"samsung,exynos5-gsc" compatible entry in addition to the new introduced
ones: "samsung,exynos5250-gsc" and "samsung,exynos5420-gsc". That's in
order to make your changes possibly backward compatible, in theory
the updated driver should still work without changes in dts.



Thank you again for your explanation.

Yes, I understood.
I will keep "samsung,exynos5-gsc" compatible,
and add Exynos 5250/5420/5433 compatible.

Best regards,
Hoegeun

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-12 Thread Hoegeun Kwon

Hi Sylwester,

On 09/11/2017 06:35 PM, Sylwester Nawrocki wrote:

On 09/08/2017 08:02 AM, Hoegeun Kwon wrote:

The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/media/platform/exynos-gsc/gsc-core.c | 96 


  1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c

index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*priv)

  return IRQ_HANDLED;
  }
  -static struct gsc_pix_max gsc_v_100_max = {
+static struct gsc_pix_max gsc_v_5250_max = {
+.org_scaler_bypass_w= 8192,
+.org_scaler_bypass_h= 8192,
+.org_scaler_input_w= 4800,
+.org_scaler_input_h= 3344,
+.real_rot_dis_w= 4800,
+.real_rot_dis_h= 3344,
+.real_rot_en_w= 2016,
+.real_rot_en_h= 2016,
+.target_rot_dis_w= 4800,
+.target_rot_dis_h= 3344,
+.target_rot_en_w= 2016,
+.target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+.org_scaler_bypass_w= 8192,
+.org_scaler_bypass_h= 8192,
+.org_scaler_input_w= 4800,
+.org_scaler_input_h= 3344,
+.real_rot_dis_w= 4800,
+.real_rot_dis_h= 3344,
+.real_rot_en_w= 2048,
+.real_rot_en_h= 2048,
+.target_rot_dis_w= 4800,
+.target_rot_dis_h= 3344,
+.target_rot_en_w= 2016,
+.target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
  .org_scaler_bypass_w= 8192,
  .org_scaler_bypass_h= 8192,
  .org_scaler_input_w= 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*priv)

  .target_h= 2,  /* yuv420 : 2, others : 1 */
  };
  -static struct gsc_variant gsc_v_100_variant = {
-.pix_max= _v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+.pix_max= _v_5250_max,
  .pix_min= _v_100_min,
  .pix_align= _v_100_align,
  .in_buf_cnt= 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

  .local_sc_down= 2,
  };
  -static struct gsc_driverdata gsc_v_100_drvdata = {
+static struct gsc_variant gsc_v_5420_variant = {
+.pix_max= _v_5420_max,
+.pix_min= _v_100_min,
+.pix_align= _v_100_align,
+.in_buf_cnt= 32,
+.out_buf_cnt= 32,
+.sc_up_max= 8,
+.sc_down_max= 16,
+.poly_sc_down_max= 4,
+.pre_sc_down_max= 4,
+.local_sc_down= 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+.pix_max= _v_5433_max,
+.pix_min= _v_100_min,
+.pix_align= _v_100_align,
+.in_buf_cnt= 32,
+.out_buf_cnt= 32,
+.sc_up_max= 8,
+.sc_down_max= 16,
+.poly_sc_down_max= 4,
+.pre_sc_down_max= 4,
+.local_sc_down= 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
  .variant = {
-[0] = _v_100_variant,
-[1] = _v_100_variant,
-[2] = _v_100_variant,
-[3] = _v_100_variant,
+[0] = _v_5250_variant,
+[1] = _v_5250_variant,
+[2] = _v_5250_variant,
+[3] = _v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = _v_5420_variant,
+[1] = _v_5420_variant,
  },
  .num_entities = 4,
  .clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

static struct gsc_driverdata gsc_5433_drvdata = {
  .variant = {
-[0] = _v_100_variant,
-[1] = _v_100_variant,
-[2] = _v_100_variant,
+[0] = _v_5433_variant,
+[1] = _v_5433_variant,
+[2] = _v_5433_variant,
  },
  .num_entities = 3,
  .clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

static const struct of_device_id exynos_gsc_match[] = {
  {
-.compatible = "samsung,exynos5-gsc",
-.data = _v_100_drvdata,


Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
data, so that it can work with "samsung,exynos5-gsc" compatible in DT
on both exynos5250 and exynos5420 SoCs?



Thank you for your question.

Exynos 5250 and 5420 have different hardware rotation limits.
Exynos 5250 is '.real_rot_en_w/h = 2016' an

Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-12 Thread Hoegeun Kwon

On 09/10/2017 04:57 AM, kbuild test robot wrote:

Hi Hoegeun,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.13 next-20170908]
[cannot apply to drm-exynos/exynos-drm/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hoegeun-Kwon/drm-exynos-gsc-Support-the-hardware-rotation-limits/20170910-015155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 make.cross ARCH=arm

All errors (new ones prefixed by >>):


Error: arch/arm/boot/dts/exynos5250.dtsi:640.40-41 syntax error

FATAL ERROR: Unable to parse input tree


Thank you for your check.

This problem was caused by typos.
ver3 has been modified.

Best regards,
Hoegeun



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


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 6/6] ARM: dts: exynos: Remove unnecessary compatible

2017-09-08 Thread Hoegeun Kwon
Currently, the compatible('samsung,exynos5-gsc') is not used.
Remove unnecessary compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index bf08101..e632faf 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 86afe77..58392b3 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
+   compatible = "samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
+   compatible = "samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 5/6] [media] exynos-gsc: Remove unnecessary compatible

2017-09-08 Thread Hoegeun Kwon
Currently, the compatible('samsung,exynos5-gsc') is not used.
Remove unnecessary compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index daa56d5..1ea05f1 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,9 +3,9 @@
 G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
 
 Required properties:
-- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
- 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
- or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
+- compatible: should be "samsung,exynos5250-gsc", "samsung,exynos5420-gsc"
+ or "samsung,exynos5433-gsc" (for Exynos 5250, 5420, 5422,
+ and 5433 SoCs)
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
@@ -16,7 +16,7 @@ Optional properties:
 Example:
 
 gsc_0:  gsc@0x13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc;
reg = <0x13e0 0x1000>;
interrupts = <0 85 0>;
 };
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 1/6] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-08 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..daa56d5 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -5,6 +5,7 @@ G-Scaler is used for scaling and color space conversion on 
EXYNOS5 SoCs.
 Required properties:
 - compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
  5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+ or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 0/6] Exynos-gsc: Support the hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

To avoid problems with bisectability, patches 1~4 must be merged and
then merged 5 and 6.

Changes for V3:
- Fixed of_match_node() to of_device_get_match_data() in drm gsc driver.
- Added hardware rotation limits for gsc driver of v4l2.
- Added the remove unnecessary compatible for DT document and Exynos dts.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (6):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits
  [media] exynos-gsc: Add hardware rotation limits
  [media] exynos-gsc: Remove unnecessary compatible
  ARM: dts: exynos: Remove unnecessary compatible

 .../devicetree/bindings/media/exynos5-gsc.txt  |  7 +-
 arch/arm/boot/dts/exynos5250.dtsi  |  8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |  4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 93 ++---
 drivers/media/platform/exynos-gsc/gsc-core.c   | 96 +++---
 include/uapi/drm/exynos_drm.h  |  2 +
 6 files changed, 159 insertions(+), 51 deletions(-)

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 2/6] ARM: dts: exynos: Add clean name of compatible.

2017-09-08 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..bf08101 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 3/6] drm/exynos/gsc: Add hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 93 +++--
 include/uapi/drm/exynos_drm.h   |  2 +
 2 files changed, 66 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..a4fb347 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -150,6 +151,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1411,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1443,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1450,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1481,17 @@ static int

[PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 96 
 1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
return IRQ_HANDLED;
 }
 
-static struct gsc_pix_max gsc_v_100_max = {
+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
.org_scaler_bypass_w= 8192,
.org_scaler_bypass_h= 8192,
.org_scaler_input_w = 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_h   = 2,  /* yuv420 : 2, others : 1 */
 };
 
-static struct gsc_variant gsc_v_100_variant = {
-   .pix_max= _v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= _v_5250_max,
.pix_min= _v_100_min,
.pix_align  = _v_100_align,
.in_buf_cnt = 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
 };
 
-static struct gsc_driverdata gsc_v_100_drvdata = {
+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= _v_5420_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= _v_5433_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
-   [3] = _v_100_variant,
+   [0] = _v_5250_variant,
+   [1] = _v_5250_variant,
+   [2] = _v_5250_variant,
+   [3] = _v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = _v_5420_variant,
+   [1] = _v_5420_variant,
},
.num_entities = 4,
.clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
 
 static struct gsc_driverdata gsc_5433_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
+   [0] = _v_5433_variant,
+   [1] = _v_5433_variant,
+   [2] = _v_5433_variant,
},
.num_entities = 3,
.clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
 
 static const struct of_device_id exynos_gsc_match[] = {
{
-   .compatible = "samsung,exynos5-gsc",
-

Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-07 Thread Hoegeun Kwon

On 09/07/2017 08:27 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-07 11:39, Hoegeun Kwon wrote:

Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>


The new values (5250/5420 specific) should replace old exynos5-gsc, 
there is no

point providing both in dts.



Hi Marek,

Thanks for your review.

I used both compatibles to not modify v4l2.
But v4l2 will also be fixed, so 'exynos5-gsc' will be removed.

And also, Thanks for your comment for of_device_get_match_data() of 
patch(3/3).


Best regards,
Hoegeun


---
  arch/arm/boot/dts/exynos5250.dtsi | 8 
  arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi

index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
  };
gsc_0:  gsc@13e0 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e0 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -647,7 +647,7 @@
  };
gsc_1:  gsc@13e1 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e1 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -657,7 +657,7 @@
  };
gsc_2:  gsc@13e2 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e2 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -667,7 +667,7 @@
  };
gsc_3:  gsc@13e3 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e3 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi

index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
  };
gsc_0: video-scaler@13e0 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";

  reg = <0x13e0 0x1000>;
  interrupts = ;
  clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
  };
gsc_1: video-scaler@13e1 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";

  reg = <0x13e1 0x1000>;
  interrupts = ;
  clocks = < CLK_GSCL1>;


Best regards


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-07 Thread Hoegeun Kwon

On 09/07/2017 08:25 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-07 07:16, Hoegeun Kwon wrote:

On 09/04/2017 03:19 PM, Hoegeun Kwon wrote:

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:
The gscaler has hardware rotation limits that need to be imported 
from

dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int 
gsc_ippdrv_check_property(struct device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related 
to pos

+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int 
gsc_ippdrv_check_property(struct device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scal

[PATCH v2 1/3] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-07 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..daa56d5 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -5,6 +5,7 @@ G-Scaler is used for scaling and color space conversion on 
EXYNOS5 SoCs.
 Required properties:
 - compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
  5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+ or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/3] drm/exynos/gsc: Support the hardware rotation limits

2017-09-07 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits

 .../devicetree/bindings/media/exynos5-gsc.txt  |   1 +
 arch/arm/boot/dts/exynos5250.dtsi  |   8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 100 +++--
 include/uapi/drm/exynos_drm.h  |   2 +
 5 files changed, 80 insertions(+), 35 deletions(-)

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-07 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 3/3] drm/exynos/gsc: Add hardware rotation limits

2017-09-07 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 100 +++-
 include/uapi/drm/exynos_drm.h   |   2 +
 2 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..590a645 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -150,6 +150,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1410,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1442,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1449,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1480,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYN

Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-06 Thread Hoegeun Kwon

On 09/04/2017 03:19 PM, Hoegeun Kwon wrote:

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:

The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related to 
pos

+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+

Re: [PATCH] drm/vblank: Fix delta_ns to an absolute value

2017-09-05 Thread Hoegeun Kwon

On 09/04/2017 04:36 PM, Daniel Vetter wrote:

On Fri, Sep 01, 2017 at 04:36:25PM +0300, Ville Syrjälä wrote:

On Fri, Sep 01, 2017 at 04:07:16PM +0900, Hoegeun Kwon wrote:

If scanout started, we should reduce etime by delta_ns. But delta_ns
is negative if scanout has not started. If delta_ns is negative,
subtraction of delta_ns from etime increases etime. This is wrong, the
etime should not be increased, so you have to make delta_ns an
absolute value.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hello all,

I think that the etime should not be increased.
In cases where delta_ns is negative, if you get time again after an
interrupt call, there is a problem that the time obtained from the
interrupt becomes the future time instead of the past time.

Please let me know if this patch is wrong.

It is wrong. The timestamp corresponds to the first active pixel of the
frame/field. So while between vblank start and active start we expect
to get a timestamp that is in the future.

A bit more strict, it's up to drivers when exactly the vblank interrupt
fires. Some fire at vblank start, some at the end, some somewhen around
that. The only rule is that the vblank must not fire before the point of
no return for another page_flip call, i.e. after the vblank event goes
out, the next page_flip (or atomic ioctl) must go to the next vblank.

So yeah both positive and negative deltas make perfect sense.
-Daniel


Thanks Ville and Daniel,

Your response has been really helpful.
Thanks so much.

Best regards,
Hoegeun


Best regards,
Hoegeun

  drivers/gpu/drm/drm_vblank.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..a3e0176 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   etime = ktime_sub_ns(etime, delta_ns);
+   etime = ktime_sub_ns(etime, abs(delta_ns));
*vblank_time = ktime_to_timeval(etime);
  
  	DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d rep]\n",

--
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-04 Thread Hoegeun Kwon

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:

The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related to pos
+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+(pos->h > pp->scale_max.vsize)) {

[PATCH] drm/vblank: Fix delta_ns to an absolute value

2017-09-01 Thread Hoegeun Kwon
If scanout started, we should reduce etime by delta_ns. But delta_ns
is negative if scanout has not started. If delta_ns is negative,
subtraction of delta_ns from etime increases etime. This is wrong, the
etime should not be increased, so you have to make delta_ns an
absolute value.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hello all,

I think that the etime should not be increased.
In cases where delta_ns is negative, if you get time again after an
interrupt call, there is a problem that the time obtained from the
interrupt becomes the future time instead of the past time.

Please let me know if this patch is wrong.

Best regards,
Hoegeun

 drivers/gpu/drm/drm_vblank.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..a3e0176 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   etime = ktime_sub_ns(etime, delta_ns);
+   etime = ktime_sub_ns(etime, abs(delta_ns));
*vblank_time = ktime_to_timeval(etime);
 
DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d 
rep]\n",
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/3] drm/exynos/gsc: Support the rotate hardware limits of gsc

2017-08-31 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  ARM: dts: exynos: Add the hardware rotation limits for gsc
  arm64: dts: exynos: Add the hardware rotation limits for gsc
  drm/exynos/gsc: Add rotation hardware limits of gscaler

 arch/arm/boot/dts/exynos5250.dtsi  |  8 
 arch/arm/boot/dts/exynos5420.dtsi  |  4 ++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  6 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 63 +++---
 include/uapi/drm/exynos_drm.h  |  2 +
 5 files changed, 60 insertions(+), 23 deletions(-)

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-08-31 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 +
 include/uapi/drm/exynos_drm.h   |  2 ++
 2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-   (sz->vsize > pp->scale_max.hsize) ||
+   (pos->h > pp->scale_max.hsize) ||
(pos->w < pp->scale_min.vsize) ||
-  

[PATCH 1/3] ARM: dts: exynos: Add the hardware rotation limits for gsc

2017-08-31 Thread Hoegeun Kwon
The gscaler has maximum size of input or output rotation. Add the
hardware limits property for the gscaler rotation in the exynos5250
and exynos5420 dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..d9434e0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -643,6 +643,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL0>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc0>;
};
 
@@ -653,6 +655,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL1>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc1>;
};
 
@@ -663,6 +667,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL2>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc2>;
};
 
@@ -673,6 +679,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL3>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc3>;
};
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..0fd6be9 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -664,6 +664,8 @@
clocks = < CLK_GSCL0>;
clock-names = "gscl";
power-domains = <_pd>;
+   rot-max-hsize = <2016>;
+   rot-max-vsize = <2016>;
iommus = <_gscl0>;
};
 
@@ -674,6 +676,8 @@
clocks = < CLK_GSCL1>;
clock-names = "gscl";
power-domains = <_pd>;
+   rot-max-hsize = <2016>;
+   rot-max-vsize = <2016>;
iommus = <_gscl1>;
};
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] arm64: dts: exynos: Add the hardware rotation limits for gsc

2017-08-31 Thread Hoegeun Kwon
The gscaler has maximum size of input or output rotation. Add the
hardware limits property for the gscaler rotation in the exynos5433
dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 7fe994b..57c9997 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -891,6 +891,8 @@
 <_gscl CLK_ACLK_GSCL0>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl0>;
};
 
@@ -904,6 +906,8 @@
 <_gscl CLK_ACLK_GSCL1>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl1>;
};
 
@@ -917,6 +921,8 @@
 <_gscl CLK_ACLK_GSCL2>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl2>;
};
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-08-28 Thread Hoegeun Kwon

Hi Krzysztof,

The driver has been merged into exynos-drm-misc.
Could you please check this patch(3/3).

Best regards,
Hoegeun

On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:

The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
  1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 443e0c9..6b70c8d 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -242,28 +242,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
  
  		port {

dsi_in: endpoint {


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-07-31 Thread Hoegeun Kwon

Dear Thierry,

Could you please check these patches.

Best regards,
Hoegeun


On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:

Hi Andrzej,

Thank you for your review.

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V4:
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (2/3 patch).
- Fixed the style of macro function.

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (1/3 patch).
- Added Acked-by: Rob Herring <r...@kernel.org> (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
   dt-bindings: Add support for samsung s6e63j0x03 panel binding
   drm/panel: Add support for s6e63j0x03 panel driver
   ARM: dts: exynos: Remove the display-timing and delay from rinato dts

  .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
  arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
  drivers/gpu/drm/panel/Kconfig  |   7 +
  drivers/gpu/drm/panel/Makefile |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 532 +
  5 files changed, 564 insertions(+), 22 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-07-12 Thread Hoegeun Kwon
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae <inki@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 532 +++
 3 files changed, 540 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d84a031..bc69bca 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -80,6 +80,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on BACKLIGHT_CLASS_DEVICE
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   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 9f6610d..42d2e29 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -6,6 +6,7 @@ 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_S6E63J0X03) += panel-samsung-s6e63j0x03.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-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..aeb32aa
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,532 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae <inki@samsung.com>
+ * Hoegeun Kwon <hoegeun.k...@samsung.com>
+ *
+ * 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 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+#define FIRST_COLUMN 20
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct drm_display_mode default_mode = {
+   .clock = 4649,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0

[PATCH v4 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

2017-07-12 Thread Hoegeun Kwon
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Rob Herring <r...@kernel.org>
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..3f1a839
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel (interface: MIPI-DSI command 
mode)
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-07-12 Thread Hoegeun Kwon
Hi Andrzej,

Thank you for your review.

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V4:
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (2/3 patch).
- Fixed the style of macro function.

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (1/3 patch).
- Added Acked-by: Rob Herring <r...@kernel.org> (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e63j0x03 panel binding
  drm/panel: Add support for s6e63j0x03 panel driver
  ARM: dts: exynos: Remove the display-timing and delay from rinato dts

 .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
 arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 532 +
 5 files changed, 564 insertions(+), 22 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-07-12 Thread Hoegeun Kwon
The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 443e0c9..6b70c8d 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -242,28 +242,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
 
port {
dsi_in: endpoint {
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-07-12 Thread Hoegeun Kwon

Hi Andrzej,

Could you please check this patch?

Best regards,
Hoegeun


On 06/27/2017 11:11 AM, Hoegeun Kwon wrote:

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae <inki@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/panel/Kconfig|   7 +
  drivers/gpu/drm/panel/Makefile   |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 540 +++
  3 files changed, 548 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..3f4afde 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
  
+config DRM_PANEL_SAMSUNG_S6E63J0X03

+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   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 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ 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_S6E63J0X03) += panel-samsung-s6e63j0x03.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-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..c3d1b5d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,540 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae <inki@samsung.com>
+ * Hoegeun Kwon <hoegeun.k...@samsung.com>
+ *
+ * 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 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+#define FIRST_COLUMN 20
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct drm_display_mode default_mode = {
+   .clock = 4649,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0

Re: [PATCH v2] drm/exynos: mic: add a bridge at probe

2017-07-05 Thread Hoegeun Kwon

On 07/05/2017 05:18 PM, Inki Dae wrote:

This patch moves drm_bridge_add call into probe.

It doesn't need to call drm_bridge_add call every time
bind callback is called.

Changelog v2
- moved drm_bridge_remove call into remove callback.
- corrected description.

Suggested-by: Andrzej Hajda <a.ha...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Inki Dae <inki@samsung.com>


Reviewed-by: Hoegeun Kwon <hoegeun.k...@samsung.com>

Best regards,
Hoegeun

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-07-05 Thread Hoegeun Kwon

Hi Inki,

Could you check this patch? :D

Best regards,
Hoegeun

On 06/21/2017 07:51 PM, Hoegeun Kwon wrote:

Remove the error handling of bridge_node because the bridge_node is
optional.

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 optional.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hi all,

Thanks for Krzysztof's advice.

Changes for V4:
- Fixed the word('optional') from commit message.

Changes for V3:
- Removed the word('required') from commit message.

Changes for V2:
- Modified the commit message in more detail than before.

Best regards,
Hoegeun

  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;

  }


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] drm/exynos: mic: add a bridge at probe

2017-07-05 Thread Hoegeun Kwon

On 07/03/2017 04:27 PM, Inki Dae wrote:

This patch moves drm_bridge_add call into probe.

This change is required by DSI driver so that
the brige can be bound at DSI driver's probe.

Suggested-by: Andrzej Hajda <a.ha...@samsung.com>
Signed-off-by: Inki Dae <inki@samsung.com>


Reviewed-by: Hoegeun Kwon <hoegeun.k...@samsung.com>

Best regards,
Hoegeun

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

2017-06-26 Thread Hoegeun Kwon
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Rob Herring <r...@kernel.org>
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..3f1a839
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel (interface: MIPI-DSI command 
mode)
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-06-26 Thread Hoegeun Kwon
The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index de2702e..3df88383 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
};
 };
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-06-26 Thread Hoegeun Kwon
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae <inki@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 540 +++
 3 files changed, 548 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..3f4afde 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   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 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ 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_S6E63J0X03) += panel-samsung-s6e63j0x03.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-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..c3d1b5d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,540 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae <inki@samsung.com>
+ * Hoegeun Kwon <hoegeun.k...@samsung.com>
+ *
+ * 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 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+#define FIRST_COLUMN 20
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct drm_display_mode default_mode = {
+   .clock = 4649,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+   },
+   {   /* gamma 120 */
+

[PATCH v3 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-06-26 Thread Hoegeun Kwon
Hi all,

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (1/3 patch).
- Added Acked-by: Rob Herring <r...@kernel.org> (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e63j0x03 panel binding
  drm/panel: Add support for s6e63j0x03 panel driver
  ARM: dts: exynos: Remove the display-timing and delay from rinato dts

 .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
 arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 540 +
 5 files changed, 572 insertions(+), 22 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-06-21 Thread Hoegeun Kwon
Remove the error handling of bridge_node because the bridge_node is
optional.

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 optional.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hi all,

Thanks for Krzysztof's advice.

Changes for V4:
- Fixed the word('optional') from commit message.

Changes for V3:
- Removed the word('required') from commit message.

Changes for V2:
- Modified the commit message in more detail than before.

Best regards,
Hoegeun

 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;
 }
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-06-21 Thread Hoegeun Kwon
Remove the error handling of bridge_node because the bridge_node is
optionally.

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 optionally.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hi all,

Changes for V3:
- Removed the word('required') from commit message.

Changes for V2:
- Modified the commit message in more detail than before.

Best regards,
Hoegeun

 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;
 }
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-06-19 Thread Hoegeun Kwon

Hello Tobias,

Sorry for late reply.

On 06/14/2017 09:30 PM, Tobias Jakobi wrote:

Hello Hoegeun,

my last question (does this regress the case "node required, but
absent") still stands.


Hoegeun Kwon wrote:

Remove the error handling of bridge_node because the bridge_node is
required optionally.

I don't think a construction like that exists. Either it's required, or
it's optional. "required optionally" makes no sense to me (but I'm not a
native speaker).

- Tobias


The bridge_node is optional.
I will change commit message and send ver3 patch.

Best regards,
Hoegeun





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.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hi Inki and Tobias,

Thanks for your review.

Changes for V2:
- Modified the commit message in more detail than before.

Best Regards,
Hoegeun

  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;

  }







___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/4] drm/panel: Add support for s6e63j0x03 panel driver

2017-06-19 Thread Hoegeun Kwon

On 06/19/2017 06:14 PM, Andrzej Hajda wrote:


On 15.06.2017 12:03, Hoegeun Kwon wrote:

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae <inki@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/panel/Kconfig|   7 +
  drivers/gpu/drm/panel/Makefile   |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 476 +++
  3 files changed, 484 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..3f4afde 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
  
+config DRM_PANEL_SAMSUNG_S6E63J0X03

+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   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 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ 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_S6E63J0X03) += panel-samsung-s6e63j0x03.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-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..dd038bc
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,476 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae <inki@samsung.com>
+ * Hoegeun Kwon <hoegeun.k...@samsung.com>
+ *
+ * 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 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MIN_BRIGHTNESS 0

This macro is not used at all and according to API it must be 0, so it
can be removed.


+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+   },
+   {   /* gamma 120 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x3d, 0x66, 0x68, 0x69, 0x69, 0x69, 0x28,
+   0x28, 0x27, 0x28, 0x28, 0x27, 0x30, 0x2e, 0x2f, 0x31, 0x31,
+

[PATCH v2 1/4] dt-bindings: Add support for samsung s6e63j0x03 panel binding

2017-06-15 Thread Hoegeun Kwon
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Rob Herring <r...@kernel.org>
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..3f1a839
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel (interface: MIPI-DSI command 
mode)
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/4] drm/panel: Add support for s6e63j0x03 panel driver

2017-06-15 Thread Hoegeun Kwon
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae <inki@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 476 +++
 3 files changed, 484 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..3f4afde 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   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 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ 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_S6E63J0X03) += panel-samsung-s6e63j0x03.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-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..dd038bc
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,476 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae <inki@samsung.com>
+ * Hoegeun Kwon <hoegeun.k...@samsung.com>
+ *
+ * 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 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+   },
+   {   /* gamma 120 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x3d, 0x66, 0x68, 0x69, 0x69, 0x69, 0x28,
+   0x28, 0x27, 0x28, 0x28, 0x27, 0x30, 0x2e, 0x2f, 0x31, 0x31,
+   0x30, 0x00, 0xf9, 0x01, 0x05, 0x01, 0x1b
+   },
+   {   /* gamma 150 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x31, 0x51, 0x53, 0x66, 0x66, 0

[PATCH v2 4/4] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-06-15 Thread Hoegeun Kwon
The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index de2702e..3df88383 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
};
 };
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/4] Add support for the s6e63j0x03 panel on Rinato board

2017-06-15 Thread Hoegeun Kwon
Hi all,

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (1/3 patch).
- Added Acked-by: Rob Herring <r...@kernel.org> (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (4):
  dt-bindings: Add support for samsung s6e63j0x03 panel binding
  drm/panel: Add support for s6e63j0x03 panel driver
  ARM: dts: exynos: Fix the active of reset gpios from rinato dts
  ARM: dts: exynos: Remove the display-timing and delay from rinato dts

 .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 ++
 arch/arm/boot/dts/exynos3250-rinato.dts|  24 +-
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 476 +
 5 files changed, 509 insertions(+), 23 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 3/4] ARM: dts: exynos: Fix the active of reset gpios from rinato dts

2017-06-15 Thread Hoegeun Kwon
This reset gpios is active low, therefore fix from active high to low.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 82e676a..de2702e 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -225,7 +225,7 @@
reg = <0>;
vdd3-supply = <_reg>;
vci-supply = <_reg>;
-   reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
power-on-delay= <30>;
power-off-delay= <120>;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-06-14 Thread Hoegeun Kwon

Hi Andrzej,

Thanks for your review.

On 06/12/2017 10:16 PM, Andrzej Hajda wrote:

Hi Hoegeun,

Nice to see patches completing support for mainlined platforms.

On 09.06.2017 06:59, Hoegeun Kwon wrote:

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae <inki@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/panel/Kconfig|   7 +
  drivers/gpu/drm/panel/Makefile   |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 491 +++
  3 files changed, 499 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c




...


+
+static int s6e63j0x03_enable(struct drm_panel *panel)
+{
+   struct s6e63j0x03 *ctx = panel_to_s6e63j0x03(panel);
+   struct backlight_device *bl_dev = ctx->bl_dev;
+   u8 seq[] = { MIPI_DCS_SET_DISPLAY_ON };
+   int ret;
+
+   ret = s6e63j0x03_dcs_write_seq(ctx, seq, ARRAY_SIZE(seq));
+   if (ret > 0)
+   bl_dev->props.power = FB_BLANK_UNBLANK;
+
+   return 0;
+}

For many (maybe most) panels power on sequence is as follows:
0. Enable power supplies and gpios.
1. Initialization, including MIPI_DCS_EXIT_SLEEP_MODE
2. Wait for 120ms, to avoid display glitches.
3. Unblanking and adjusting display, including MIPI_DCS_SET_DISPLAY_ON.

And power-off:
4. MIPI_DCS_SET_DISPLAY_OFF
5. MIPI_DCS_ENTER_SLEEP_MODE
6. Wait for 120ms
7. Disable power supplies and gpios.

I suppose waiting for 120ms is a good indicator what should be put into
prepare/enable/disable/unprepare phase.
In my opinion it should be as follows:
Prepare: 0, 1
Enable: 2, 3
Disable: 4,5,6
Unprepare: 7

What do you think about it?
Could you arrange the code this way and test if it works correctly?
Maybe you/other developers have some opinions about it?


I agree with you.
I will send ver2 patch with the above style.
And modify it to use as mipi_dsi_dcs_*.


+
+static const struct drm_display_mode default_mode = {
+   .clock = 4644,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};

clock should be equal vtotal*htotal*vrefresh, it is little higher? what
is the reason?
What is actual refresh rate?


The actual refresh rate is 30.43Hz
So I will modfiy the clock Hz to 4649.

((323 * 473 )* 30.43) / 1000 = 4649

Best regards,
Hoegeun


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-06-14 Thread Hoegeun Kwon
Remove the error handling of bridge_node because the bridge_node is
required optionally.

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.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hi Inki and Tobias,

Thanks for your review.

Changes for V2:
- Modified the commit message in more detail than before.

Best Regards,
Hoegeun

 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;
 }
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-06-13 Thread Hoegeun Kwon

On 06/13/2017 06:25 PM, Inki Dae wrote:


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


Remove the error handling for bridge_node because the bridge_node is
required optionally. It has already been described in commit message.

For example,
In case of Exynos 3250 SoC, no bridge_node is required between FIMD
and MIPI DSI.

Best regards,
Hoegeun




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;

  }





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-06-09 Thread 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.

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;
 }
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-06-09 Thread Hoegeun Kwon

On 06/09/2017 04:45 PM, Krzysztof Kozlowski wrote:

On Fri, Jun 09, 2017 at 01:59:14PM +0900, Hoegeun Kwon wrote:

The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
  1 file changed, 22 deletions(-)

I understand this depends on merging in the panel driver so this will
have to wait till then. I'll take it when panel hits mainline (arm-soc
folks discourage recently cross-tree merges for DT).

Best regards,
Krzysztof


Thanks for your reply.
I agree with your opinion,
I will wait for the panel driver to merge.

Best regards,
Hoegeun


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] ARM: dts: exynos: Add the OF graph between fimd and dsi

2017-06-09 Thread Hoegeun Kwon

On 06/09/2017 04:27 PM, Krzysztof Kozlowski wrote:

On Fri, Jun 09, 2017 at 11:59:33AM +0900, Hoegeun Kwon wrote:

It should be connected to OF graph between fimd and dsi.
Add the OF graph between fimd and dsi.

I need more explanation why this is needed. What happens without this?
What issue is fixed here?

What about Exynos5250 and Exynos5420? I think we do not have a board in
mainline using FIMD but maybe this should be added just for correct
hardware description?


Thank you for your review.

I'm sorry, this patch is wrong.
Please ignore this patch. :)

Best regards,
Hoegeun




Best regards,
Krzysztof


Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  arch/arm/boot/dts/exynos3250.dtsi | 26 ++
  arch/arm/boot/dts/exynos4.dtsi| 26 ++
  2 files changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 590ee44..22d523f 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -311,6 +311,19 @@
iommus = <_fimd0>;
samsung,sysreg = <_reg>;
status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   fimd_to_dsi: endpoint {
+   remote-endpoint =
+   <_to_fimd>;
+   };
+   };
+   };
};
  
  		dsi_0: dsi@11C8 {

@@ -326,6 +339,19 @@
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi_to_fimd: endpoint {
+   remote-endpoint =
+   <_to_dsi>;
+   };
+   };
+   };
};
  
  		sysmmu_fimd0: sysmmu@11E2 {

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 497a947..773d392 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -193,6 +193,19 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi_to_fimd: endpoint {
+   remote-endpoint =
+   <_to_dsi>;
+   };
+   };
+   };
};
  
  	camera {

@@ -715,6 +728,19 @@
iommus = <_fimd0>;
samsung,sysreg = <_reg>;
status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   fimd_to_dsi: endpoint {
+   remote-endpoint =
+   <_to_fimd>;
+   };
+   };
+   };
};
  
  	tmu: tmu@100C {

--
1.9.1






___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

2017-06-08 Thread Hoegeun Kwon
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..34b6e2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active high)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   3   >