RE: [EXT] Re: [v5 2/2] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-09-15 Thread Wen He


> -Original Message-
> From: Liviu Dudau 
> Sent: 2019年9月12日 22:47
> To: Wen He 
> Cc: linux-de...@linux.nxdi.nxp.com; Brian Starkey ;
> David Airlie ; Daniel Vetter ; Rob Herring
> ; Mark Rutland ;
> dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org;
> linux-ker...@vger.kernel.org; Leo Li 
> Subject: [EXT] Re: [v5 2/2] drm/arm/mali-dp: Add display QoS interface
> configuration for Mali DP500
> 
> Caution: EXT Email
> 
> On Tue, Sep 10, 2019 at 03:59:13PM +0800, Wen He wrote:
> > Configure the display Quality of service (QoS) levels priority if the
> > optional property node "arm,malidp-aqros-value" is defined in DTS file.
> >
> > QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS
> > is driven from the "RQOS" register, so needed to program the RQOS
> > register to avoid the high resolutions flicker issue on the LS1028A 
> > platform.
> >
> > Signed-off-by: Wen He 
> 
> Acked-by: Liviu Dudau 
> 
> Thanks for the patch! I will pull this into the malidp code and push it to
> drm-misc-next in the following days.

Thank you, Liviu.

Best Regards,
Wen
> 
> Best regards,
> Liviu
> 
> > ---
> >  drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
> >  drivers/gpu/drm/arm/malidp_hw.c   |  9 +
> >  drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
> >  drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> >  4 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index 333b88a5efb0..8a76315aaa0f 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -817,6 +817,12 @@ static int malidp_bind(struct device *dev)
> >
> >   malidp->core_id = version;
> >
> > + ret = of_property_read_u32(dev->of_node,
> > + "arm,malidp-arqos-value",
> > + >arqos_value);
> > + if (ret)
> > + hwdev->arqos_value = 0x0;
> > +
> >   /* set the number of lines used for output of RGB data */
> >   ret = of_property_read_u8_array(dev->of_node,
> >   "arm,malidp-output-port-lines",
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c index bd8265f02e0b..ca570b135478
> > 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -379,6 +379,15 @@ static void malidp500_modeset(struct
> malidp_hw_device *hwdev, struct videomode *
> >   malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> >   else
> >   malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > MALIDP_DE_DISPLAY_FUNC);
> > +
> > + /*
> > +  * Program the RQoS register to avoid high resolutions flicker
> > +  * issue on the LS1028A.
> > +  */
> > + if (hwdev->arqos_value) {
> > + val = hwdev->arqos_value;
> > + malidp_hw_setbits(hwdev, val,
> MALIDP500_RQOS_QUALITY);
> > + }
> >  }
> >
> >  int malidp_format_get_bpp(u32 fmt)
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.h
> > b/drivers/gpu/drm/arm/malidp_hw.h index 968a65eed371..e4c36bc90bda
> > 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.h
> > +++ b/drivers/gpu/drm/arm/malidp_hw.h
> > @@ -251,6 +251,9 @@ struct malidp_hw_device {
> >
> >   /* size of memory used for rotating layers, up to two banks available
> */
> >   u32 rotation_memory[2];
> > +
> > + /* priority level of RQOS register used for driven the ARQOS signal */
> > + u32 arqos_value;
> >  };
> >
> >  static inline u32 malidp_hw_read(struct malidp_hw_device *hwdev, u32
> > reg) diff --git a/drivers/gpu/drm/arm/malidp_regs.h
> > b/drivers/gpu/drm/arm/malidp_regs.h
> > index 993031542fa1..514c50dcb74d 100644
> > --- a/drivers/gpu/drm/arm/malidp_regs.h
> > +++ b/drivers/gpu/drm/arm/malidp_regs.h
> > @@ -210,6 +210,16 @@
> >  #define MALIDP500_CONFIG_VALID   0x00f00
> >  #define MALIDP500_CONFIG_ID  0x00fd4
> >
> > +/*
> > + * The quality of service (QoS) register on the DP500. RQOS register
> > +values
> > + * are driven by the ARQOS signal, using AXI transacations, dependent
> > +on the
> > + * FIFO input level.
> > + * The RQOS register can also set QoS levels for:
> > + *- RED_ARQOS   @ A 4-bit signal value for close to underflow
> conditions
> > + *- GREEN_ARQOS @ A 4-bit signal value for normal conditions
> > + */
> > +#define MALIDP500_RQOS_QUALITY  0x00500
> > +
> >  /* register offsets and bits specific to DP550/DP650 */
> >  #define MALIDP550_ADDR_SPACE_SIZE0x1
> >  #define MALIDP550_DE_CONTROL 0x00010
> > --
> > 2.17.1
> >
> 
> --
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯


[v5 2/2] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-09-10 Thread Wen He
Configure the display Quality of service (QoS) levels priority if the
optional property node "arm,malidp-aqros-value" is defined in DTS file.

QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
driven from the "RQOS" register, so needed to program the RQOS register
to avoid the high resolutions flicker issue on the LS1028A platform.

Signed-off-by: Wen He 
---
 drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
 drivers/gpu/drm/arm/malidp_hw.c   |  9 +
 drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
 drivers/gpu/drm/arm/malidp_regs.h | 10 ++
 4 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 333b88a5efb0..8a76315aaa0f 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -817,6 +817,12 @@ static int malidp_bind(struct device *dev)
 
malidp->core_id = version;
 
+   ret = of_property_read_u32(dev->of_node,
+   "arm,malidp-arqos-value",
+   >arqos_value);
+   if (ret)
+   hwdev->arqos_value = 0x0;
+
/* set the number of lines used for output of RGB data */
ret = of_property_read_u8_array(dev->of_node,
"arm,malidp-output-port-lines",
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index bd8265f02e0b..ca570b135478 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -379,6 +379,15 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
else
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
+
+   /*
+* Program the RQoS register to avoid high resolutions flicker
+* issue on the LS1028A.
+*/
+   if (hwdev->arqos_value) {
+   val = hwdev->arqos_value;
+   malidp_hw_setbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   }
 }
 
 int malidp_format_get_bpp(u32 fmt)
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 968a65eed371..e4c36bc90bda 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -251,6 +251,9 @@ struct malidp_hw_device {
 
/* size of memory used for rotating layers, up to two banks available */
u32 rotation_memory[2];
+
+   /* priority level of RQOS register used for driven the ARQOS signal */
+   u32 arqos_value;
 };
 
 static inline u32 malidp_hw_read(struct malidp_hw_device *hwdev, u32 reg)
diff --git a/drivers/gpu/drm/arm/malidp_regs.h 
b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..514c50dcb74d 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -210,6 +210,16 @@
 #define MALIDP500_CONFIG_VALID 0x00f00
 #define MALIDP500_CONFIG_ID0x00fd4
 
+/*
+ * The quality of service (QoS) register on the DP500. RQOS register values
+ * are driven by the ARQOS signal, using AXI transacations, dependent on the
+ * FIFO input level.
+ * The RQOS register can also set QoS levels for:
+ *- RED_ARQOS   @ A 4-bit signal value for close to underflow conditions
+ *- GREEN_ARQOS @ A 4-bit signal value for normal conditions
+ */
+#define MALIDP500_RQOS_QUALITY  0x00500
+
 /* register offsets and bits specific to DP550/DP650 */
 #define MALIDP550_ADDR_SPACE_SIZE  0x1
 #define MALIDP550_DE_CONTROL   0x00010
-- 
2.17.1



[v5 1/2] dt/bindings: display: Add optional property node define for Mali DP500

2019-09-10 Thread Wen He
Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
This property describe the ARQoS levels of DP500's QoS signaling.

Signed-off-by: Wen He 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt 
b/Documentation/devicetree/bindings/display/arm,malidp.txt
index 2f7870983ef1..7a97a2b48c2a 100644
--- a/Documentation/devicetree/bindings/display/arm,malidp.txt
+++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
@@ -37,6 +37,8 @@ Optional properties:
 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
 to be used for the framebuffer; if not present, the framebuffer may
 be located anywhere in memory.
+  - arm,malidp-arqos-high-level: integer of u32 value describing the ARQoS
+levels of DP500's QoS signaling.
 
 
 Example:
@@ -54,6 +56,7 @@ Example:
clocks = <>, <>, <>, <>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
+   arm,malidp-arqos-high-level = <0xd000d000>;
port {
dp0_output: endpoint {
remote-endpoint = <_2_input>;
-- 
2.17.1



RE: [EXT] Re: [v4 2/2] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-09-10 Thread Wen He


> -Original Message-
> From: Liviu Dudau 
> Sent: 2019年9月6日 22:18
> To: Wen He 
> Cc: linux-de...@linux.nxdi.nxp.com; Brian Starkey ;
> David Airlie ; Daniel Vetter ; Rob Herring
> ; Mark Rutland ;
> dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org;
> linux-ker...@vger.kernel.org; Leo Li 
> Subject: [EXT] Re: [v4 2/2] drm/arm/mali-dp: Add display QoS interface
> configuration for Mali DP500
> 
> Caution: EXT Email
> 
> Hi Wen,
> 
> On Thu, Aug 22, 2019 at 10:11:35AM +0800, Wen He wrote:
> > Configure the display Quality of service (QoS) levels priority if the
> > optional property node "arm,malidp-aqros-value" is defined in DTS file.
> >
> > QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS
> > is driven from the "RQOS" register, so needed to program the RQOS
> > register to avoid the high resolutions flicker issue on the LS1028A 
> > platform.
> >
> > Signed-off-by: Wen He 
> > ---
> >  drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
> >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> >  drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
> >  drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> >  4 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index c27ff456eddc..80e8d15760ac 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -815,6 +815,12 @@ static int malidp_bind(struct device *dev)
> >
> >   malidp->core_id = version;
> >
> > + ret = of_property_read_u32(dev->of_node,
> > + "arm,malidp-arqos-value",
> > + >arqos_value);
> > + if (ret)
> > + hwdev->arqos_value = 0x0;
> > +
> >   /* set the number of lines used for output of RGB data */
> >   ret = of_property_read_u8_array(dev->of_node,
> >   "arm,malidp-output-port-lines",
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c index 380be66d4c6e..f90a367a5bc9
> > 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -374,6 +374,19 @@ static void malidp500_modeset(struct
> malidp_hw_device *hwdev, struct videomode *
> >   malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> >   else
> >   malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > MALIDP_DE_DISPLAY_FUNC);
> > +
> > + /*
> > +  * Program the RQoS register to avoid high resolutions flicker
> > +  * issue on the LS1028A.
> > +  */
> > + if (hwdev->arqos_value) {
> > + val = hwdev->arqos_value;
> > +
> > + if (mode->pixelclock > 14850)
> > + malidp_hw_setbits(hwdev, val,
> MALIDP500_RQOS_QUALITY);
> > + else
> > + malidp_hw_clearbits(hwdev, val,
> MALIDP500_RQOS_QUALITY);
> > + }
> 
> This application of the arqos_value based on a pixel clock value bothers me,
> because it has two problems:
> 
> 1. Some other user of the Mali DP driver can't apply a system QoS value that
> they can now specify in the DT, unless the requested pixel clock is bigger 
> than
> 145MHz. :(
> 
> 2. (A guess) The flickering issue shows up on a combination of pixelclock and
> resolution (i.e. it is a bandwidth problem), but you only address one of the
> variables. Haven't tested on the LS1028A yet, but do you know if 
> (theoretically)
> it would have a flicker problem doing 640x480@200MHz without the QoS
> value?
> 
> How about this instead?
> 
> --8<-
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> b/drivers/gpu/drm/arm/malidp_hw.c index 380be66d4c6eb..e2f96dce13850
> 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -374,6 +374,22 @@ static void malidp500_modeset(struct
> malidp_hw_device *hwdev, struct videomode *
> malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> else
> malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> +
> +   /*
> +* Program the RQoS register. LS1028A has an issue where screen
> will
> +* flicker on pixelclocks higher than 148.5MHz but otherwise doesn't
> + 

RE: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-09-05 Thread Wen He


> -Original Message-
> From: Liviu Dudau 
> Sent: 2019年9月5日 0:13
> To: Wen He 
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> 
> Subject: Re: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface
> configuration for Mali DP500
> 
> Caution: EXT Email
> 
> On Thu, Aug 15, 2019 at 11:14:17AM +, Wen He wrote:
> >
> >
> > > -Original Message-
> > > From: Liviu Dudau 
> > > Sent: 2019年7月22日 17:33
> > > To: Wen He 
> > > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> > > 
> > > Subject: Re: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS
> > > interface configuration for Mali DP500
> > >
> > > Caution: EXT Email
> > >
> > > On Mon, Jul 22, 2019 at 02:12:08AM +, Wen He wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Liviu Dudau 
> > > > > Sent: 2019年7月19日 19:46
> > > > > To: Wen He 
> > > > > Cc: dri-devel@lists.freedesktop.org;
> > > > > linux-ker...@vger.kernel.org; brian.star...@arm.com;
> > > > > airl...@linux.ie; dan...@ffwll.ch; Leo Li 
> > > > > Subject: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS
> > > > > interface configuration for Mali DP500
> > > > >
> > > > > Caution: EXT Email
> > > > >
> > > > > On Fri, Jul 19, 2019 at 05:54:45PM +0800, Wen He wrote:
> > > > > > Configure the display Quality of service (QoS) levels priority
> > > > > > if the optional property node "arm,malidp-aqros-value" is
> > > > > > defined in DTS
> > > file.
> > > > > >
> > > > > > QoS signaling using AQROS and AWQOS AXI interface signals, the
> > > > > > AQROS is driven from the "RQOS" register, so needed to program
> > > > > > the RQOS register to avoid the 4k resolution flicker issue on
> > > > > > the LS1028A
> > > platform.
> > > > > >
> > > > > > Signed-off-by: Wen He 
> > > > > > ---
> > > > > > change in v2:
> > > > > > - modify some content based on feedback from
> > > > > > maintainers
> > > > > >
> > > > > >  drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
> > > > > >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> > > > > >  drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
> > > > > >  drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> > > > > >  4 files changed, 32 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > > > > > b/drivers/gpu/drm/arm/malidp_drv.c
> > > > > > index f25ec4382277..61c49a0668a7 100644
> > > > > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > > > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > > > > @@ -818,6 +818,12 @@ static int malidp_bind(struct device
> > > > > > *dev)
> > > > > >
> > > > > >   malidp->core_id = version;
> > > > > >
> > > > > > + ret = of_property_read_u32(dev->of_node,
> > > > > > +
> "arm,malidp-arqos-value",
> > > > > > + >arqos_value);
> > > > > > + if (ret)
> > > > > > + hwdev->arqos_value = 0x0;
> > > > >
> > > > > Is zero the default value that you want? I thought it was 0x00010001.
> > > >
> > > > Actually, the register default value always is 0x00010001(can be
> > > > found in RM
> > > document).
> > >
> > > Exactly, but with your code you are overwriting it to 0 if the DT
> > > doesn't have the arm,malidp-arqos-value property.
> > >
> > > >
> > > > >
> > > > > > +
> > > > > >   /* set the number of lines used for output of RGB data */
> > > > > >   ret = of_property_read_u8_array(dev->of_node,
> > > > > >
> > > > > > "arm,malidp-output-port-lines", diff --git
> > > > >

[v4 2/2] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-08-21 Thread Wen He
Configure the display Quality of service (QoS) levels priority if the
optional property node "arm,malidp-aqros-value" is defined in DTS file.

QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
driven from the "RQOS" register, so needed to program the RQOS register
to avoid the high resolutions flicker issue on the LS1028A platform.

Signed-off-by: Wen He 
---
 drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
 drivers/gpu/drm/arm/malidp_hw.c   | 13 +
 drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
 drivers/gpu/drm/arm/malidp_regs.h | 10 ++
 4 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c27ff456eddc..80e8d15760ac 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -815,6 +815,12 @@ static int malidp_bind(struct device *dev)
 
malidp->core_id = version;
 
+   ret = of_property_read_u32(dev->of_node,
+   "arm,malidp-arqos-value",
+   >arqos_value);
+   if (ret)
+   hwdev->arqos_value = 0x0;
+
/* set the number of lines used for output of RGB data */
ret = of_property_read_u8_array(dev->of_node,
"arm,malidp-output-port-lines",
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 380be66d4c6e..f90a367a5bc9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -374,6 +374,19 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
else
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
+
+   /*
+* Program the RQoS register to avoid high resolutions flicker
+* issue on the LS1028A.
+*/
+   if (hwdev->arqos_value) {
+   val = hwdev->arqos_value;
+
+   if (mode->pixelclock > 14850)
+   malidp_hw_setbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   else
+   malidp_hw_clearbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   }
 }
 
 int malidp_format_get_bpp(u32 fmt)
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 968a65eed371..e4c36bc90bda 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -251,6 +251,9 @@ struct malidp_hw_device {
 
/* size of memory used for rotating layers, up to two banks available */
u32 rotation_memory[2];
+
+   /* priority level of RQOS register used for driven the ARQOS signal */
+   u32 arqos_value;
 };
 
 static inline u32 malidp_hw_read(struct malidp_hw_device *hwdev, u32 reg)
diff --git a/drivers/gpu/drm/arm/malidp_regs.h 
b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..514c50dcb74d 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -210,6 +210,16 @@
 #define MALIDP500_CONFIG_VALID 0x00f00
 #define MALIDP500_CONFIG_ID0x00fd4
 
+/*
+ * The quality of service (QoS) register on the DP500. RQOS register values
+ * are driven by the ARQOS signal, using AXI transacations, dependent on the
+ * FIFO input level.
+ * The RQOS register can also set QoS levels for:
+ *- RED_ARQOS   @ A 4-bit signal value for close to underflow conditions
+ *- GREEN_ARQOS @ A 4-bit signal value for normal conditions
+ */
+#define MALIDP500_RQOS_QUALITY  0x00500
+
 /* register offsets and bits specific to DP550/DP650 */
 #define MALIDP550_ADDR_SPACE_SIZE  0x1
 #define MALIDP550_DE_CONTROL   0x00010
-- 
2.17.1



[v4 1/2] dt/bindings: display: Add optional property node define for Mali DP500

2019-08-21 Thread Wen He
Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
This property describe the ARQoS levels of DP500's QoS signaling.

Signed-off-by: Wen He 
---
 Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt 
b/Documentation/devicetree/bindings/display/arm,malidp.txt
index 2f7870983ef1..7a97a2b48c2a 100644
--- a/Documentation/devicetree/bindings/display/arm,malidp.txt
+++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
@@ -37,6 +37,8 @@ Optional properties:
 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
 to be used for the framebuffer; if not present, the framebuffer may
 be located anywhere in memory.
+  - arm,malidp-arqos-high-level: integer of u32 value describing the ARQoS
+levels of DP500's QoS signaling.
 
 
 Example:
@@ -54,6 +56,7 @@ Example:
clocks = <>, <>, <>, <>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
+   arm,malidp-arqos-high-level = <0xd000d000>;
port {
dp0_output: endpoint {
remote-endpoint = <_2_input>;
-- 
2.17.1



RE: [EXT] Re: [v3 1/2] dt/bindings: display: Add optional property node for Mali DP500

2019-08-18 Thread Wen He


> -Original Message-
> From: Rob Herring 
> Sent: 2019年8月17日 4:09
> To: Wen He 
> Cc: linux-de...@linux.nxdi.nxp.com; Liviu Dudau ;
> Brian Starkey ; David Airlie ; Daniel
> Vetter ; Mark Rutland ; dri-devel
> ; devicet...@vger.kernel.org;
> linux-ker...@vger.kernel.org; Leo Li 
> Subject: [EXT] Re: [v3 1/2] dt/bindings: display: Add optional property node 
> for
> Mali DP500
> 
> Caution: EXT Email
> 
> On Fri, Aug 16, 2019 at 4:14 AM Wen He  wrote:
> >
> > Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
> > This property describe the ARQoS levels of DP500's QoS signaling.
> >
> > Signed-off-by: Wen He 
> > ---
> > change in v3:
> > - correction the describe of the node
> >
> >  Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt
> b/Documentation/devicetree/bindings/display/arm,malidp.txt
> > index 2f7870983ef1..1f711d32f235 100644
> > --- a/Documentation/devicetree/bindings/display/arm,malidp.txt
> > +++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
> > @@ -37,6 +37,8 @@ Optional properties:
> >
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
> >  to be used for the framebuffer; if not present, the framebuffer may
> >  be located anywhere in memory.
> > +  - arm,malidp-arqos-high-level: phandle to describing the ARQoS levels of
> DP500's
> > +QoS signaling.
> 
> The driver is reading a u32... Did you test this?

Sure, actually, here should be use a u32 value

The older description was correct, sorry, I should be
Correction the example node define...

'integer of u32 value describing the ARQoS levels of DP500's QoS signaling', 

> 
> 
> >
> >
> >  Example:
> > @@ -54,6 +56,7 @@ Example:
> > clocks = <>, <>, <>,
> <>;
> > clock-names = "pxlclk", "mclk", "aclk", "pclk";
> > arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
> > +   arm,malidp-arqos-high-level = <>;
arm,malidp-arqos-high-level = < 
0xd000d000>;

Best Regards,
Wen

> > port {
> > dp0_output: endpoint {
> > remote-endpoint =
> <_2_input>;
> > --
> > 2.17.1
> >


[v3 1/2] dt/bindings: display: Add optional property node for Mali DP500

2019-08-17 Thread Wen He
Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
This property describe the ARQoS levels of DP500's QoS signaling.

Signed-off-by: Wen He 
---
change in v3:
- correction the describe of the node

 Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt 
b/Documentation/devicetree/bindings/display/arm,malidp.txt
index 2f7870983ef1..1f711d32f235 100644
--- a/Documentation/devicetree/bindings/display/arm,malidp.txt
+++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
@@ -37,6 +37,8 @@ Optional properties:
 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
 to be used for the framebuffer; if not present, the framebuffer may
 be located anywhere in memory.
+  - arm,malidp-arqos-high-level: phandle to describing the ARQoS levels of 
DP500's
+QoS signaling.
 
 
 Example:
@@ -54,6 +56,7 @@ Example:
clocks = <>, <>, <>, <>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
+   arm,malidp-arqos-high-level = <>;
port {
dp0_output: endpoint {
remote-endpoint = <_2_input>;
-- 
2.17.1

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

[v3 2/2] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-08-16 Thread Wen He
Configure the display Quality of service (QoS) levels priority if the
optional property node "arm,malidp-aqros-value" is defined in DTS file.

QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
driven from the "RQOS" register, so needed to program the RQOS register
to avoid the high resolutions flicker issue on the LS1028A platform.

Signed-off-by: Wen He 
---
change in v3:
- after testing more resolutions, if pixelclock > 148.5MHz will
get the flickering

 drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
 drivers/gpu/drm/arm/malidp_hw.c   | 13 +
 drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
 drivers/gpu/drm/arm/malidp_regs.h | 10 ++
 4 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c27ff456eddc..80e8d15760ac 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -815,6 +815,12 @@ static int malidp_bind(struct device *dev)
 
malidp->core_id = version;
 
+   ret = of_property_read_u32(dev->of_node,
+   "arm,malidp-arqos-value",
+   >arqos_value);
+   if (ret)
+   hwdev->arqos_value = 0x0;
+
/* set the number of lines used for output of RGB data */
ret = of_property_read_u8_array(dev->of_node,
"arm,malidp-output-port-lines",
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 380be66d4c6e..f90a367a5bc9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -374,6 +374,19 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
else
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
+
+   /*
+* Program the RQoS register to avoid high resolutions flicker
+* issue on the LS1028A.
+*/
+   if (hwdev->arqos_value) {
+   val = hwdev->arqos_value;
+
+   if (mode->pixelclock > 14850)
+   malidp_hw_setbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   else
+   malidp_hw_clearbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   }
 }
 
 int malidp_format_get_bpp(u32 fmt)
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 968a65eed371..e4c36bc90bda 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -251,6 +251,9 @@ struct malidp_hw_device {
 
/* size of memory used for rotating layers, up to two banks available */
u32 rotation_memory[2];
+
+   /* priority level of RQOS register used for driven the ARQOS signal */
+   u32 arqos_value;
 };
 
 static inline u32 malidp_hw_read(struct malidp_hw_device *hwdev, u32 reg)
diff --git a/drivers/gpu/drm/arm/malidp_regs.h 
b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..514c50dcb74d 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -210,6 +210,16 @@
 #define MALIDP500_CONFIG_VALID 0x00f00
 #define MALIDP500_CONFIG_ID0x00fd4
 
+/*
+ * The quality of service (QoS) register on the DP500. RQOS register values
+ * are driven by the ARQOS signal, using AXI transacations, dependent on the
+ * FIFO input level.
+ * The RQOS register can also set QoS levels for:
+ *- RED_ARQOS   @ A 4-bit signal value for close to underflow conditions
+ *- GREEN_ARQOS @ A 4-bit signal value for normal conditions
+ */
+#define MALIDP500_RQOS_QUALITY  0x00500
+
 /* register offsets and bits specific to DP550/DP650 */
 #define MALIDP550_ADDR_SPACE_SIZE  0x1
 #define MALIDP550_DE_CONTROL   0x00010
-- 
2.17.1



RE: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-08-15 Thread Wen He


> -Original Message-
> From: Liviu Dudau 
> Sent: 2019年7月22日 17:33
> To: Wen He 
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> 
> Subject: Re: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface
> configuration for Mali DP500
> 
> Caution: EXT Email
> 
> On Mon, Jul 22, 2019 at 02:12:08AM +, Wen He wrote:
> >
> >
> > > -Original Message-
> > > From: Liviu Dudau 
> > > Sent: 2019年7月19日 19:46
> > > To: Wen He 
> > > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> > > 
> > > Subject: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS
> > > interface configuration for Mali DP500
> > >
> > > Caution: EXT Email
> > >
> > > On Fri, Jul 19, 2019 at 05:54:45PM +0800, Wen He wrote:
> > > > Configure the display Quality of service (QoS) levels priority if
> > > > the optional property node "arm,malidp-aqros-value" is defined in DTS
> file.
> > > >
> > > > QoS signaling using AQROS and AWQOS AXI interface signals, the
> > > > AQROS is driven from the "RQOS" register, so needed to program the
> > > > RQOS register to avoid the 4k resolution flicker issue on the LS1028A
> platform.
> > > >
> > > > Signed-off-by: Wen He 
> > > > ---
> > > > change in v2:
> > > > - modify some content based on feedback from maintainers
> > > >
> > > >  drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
> > > >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> > > >  drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
> > > >  drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> > > >  4 files changed, 32 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > > > b/drivers/gpu/drm/arm/malidp_drv.c
> > > > index f25ec4382277..61c49a0668a7 100644
> > > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > > @@ -818,6 +818,12 @@ static int malidp_bind(struct device *dev)
> > > >
> > > >   malidp->core_id = version;
> > > >
> > > > + ret = of_property_read_u32(dev->of_node,
> > > > + "arm,malidp-arqos-value",
> > > > + >arqos_value);
> > > > + if (ret)
> > > > + hwdev->arqos_value = 0x0;
> > >
> > > Is zero the default value that you want? I thought it was 0x00010001.
> >
> > Actually, the register default value always is 0x00010001(can be found in RM
> document).
> 
> Exactly, but with your code you are overwriting it to 0 if the DT doesn't have
> the arm,malidp-arqos-value property.
> 
> >
> > >
> > > > +
> > > >   /* set the number of lines used for output of RGB data */
> > > >   ret = of_property_read_u8_array(dev->of_node,
> > > >
> > > > "arm,malidp-output-port-lines", diff --git
> > > > a/drivers/gpu/drm/arm/malidp_hw.c
> > > > b/drivers/gpu/drm/arm/malidp_hw.c index 50af399d7f6f..323683b1e9f7
> > > > 100644
> > > > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > > > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > > > @@ -374,6 +374,19 @@ static void malidp500_modeset(struct
> > > malidp_hw_device *hwdev, struct videomode *
> > > >   malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > > MALIDP_DE_DISPLAY_FUNC);
> > > >   else
> > > >   malidp_hw_clearbits(hwdev,
> MALIDP_DISP_FUNC_ILACED,
> > > > MALIDP_DE_DISPLAY_FUNC);
> > > > +
> > > > + /*
> > > > +  * Program the RQoS register to avoid 4k resolution flicker
> > > > +  * on the LS1028A.
> > > > +  */
> > > > + if (hwdev->arqos_value) {
> > > > + val = hwdev->arqos_value;
> > > > +
> > > > + if (mode->pixelclock == 59400)
> > >
> > > If I remember correctly, you declare the pixelclocks in the device
> > > tree, so I wonder if this is needed here. We should just set what
> > > value was in the DT regardless of the pixelclock, and 

RE: [EXT] Re: [v2 2/3] dt/bindings: display: Add optional property node defined for Mali DP500

2019-08-14 Thread Wen He


> -Original Message-
> From: Rob Herring 
> Sent: 2019年8月13日 7:20
> To: Wen He 
> Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; mark.rutl...@arm.com; liviu.du...@arm.com;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> 
> Subject: [EXT] Re: [v2 2/3] dt/bindings: display: Add optional property node
> defined for Mali DP500
> 
> 
> On Fri, Jul 19, 2019 at 05:58:42PM +0800, Wen He wrote:
> > Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
> > This property describe the ARQoS levels of DP500's QoS signaling.
> >
> > Signed-off-by: Wen He 
> > ---
> >  Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt
> b/Documentation/devicetree/bindings/display/arm,malidp.txt
> > index 2f7870983ef1..76a0e7251251 100644
> > --- a/Documentation/devicetree/bindings/display/arm,malidp.txt
> > +++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
> > @@ -37,6 +37,8 @@ Optional properties:
> >
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
> >  to be used for the framebuffer; if not present, the framebuffer may
> >  be located anywhere in memory.
> > +  - arm,malidp-arqos-high-level: integer of u32 value describing the ARQoS
> > +levels of DP500's QoS signaling.
> 
> u32 here, and...

Hi Rob,

Sorry, should be written as" phandle to a node describing the AQRoS levels of 
DP500's QoS signaling"..
Is that ok?

Best Regards,
Wen

> 
> >
> >
> >  Example:
> > @@ -54,6 +56,7 @@ Example:
> >   clocks = <>, <>, <>,
> <>;
> >   clock-names = "pxlclk", "mclk", "aclk", "pclk";
> >   arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
> > + arm,malidp-arqos-high-level = <>;
> 
> phandle here?
> 
> >   port {
> >   dp0_output: endpoint {
> >   remote-endpoint = <_2_input>;
> > --
> > 2.17.1
> >


RE: [EXT] Re: [v2 1/4] dt-bindings: display: Add DT bindings for LS1028A HDP-TX PHY.

2019-08-12 Thread Wen He


> -Original Message-
> From: Rob Herring 
> Sent: 2019年8月13日 7:30
> To: Wen He 
> Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> Leo Li 
> Subject: [EXT] Re: [v2 1/4] dt-bindings: display: Add DT bindings for LS1028A
> HDP-TX PHY.
> 
> Caution: EXT Email
> 
> On Fri, Jul 19, 2019 at 06:09:39PM +0800, Wen He wrote:
> > Add DT bindings documentmation for the HDP-TX PHY controller. The
> > describes which could be found on NXP Layerscape ls1028a platform.
> 
> Not required, but please consider converting to DT schema (YAML) format.

Understand,

> 
> >
> > Signed-off-by: Wen He 
> > ---
> > change in v2:
> > - correction the node name.
> >
> >  .../devicetree/bindings/display/fsl,hdp.txt   | 56 +++
> >  1 file changed, 56 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/fsl,hdp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/fsl,hdp.txt
> > b/Documentation/devicetree/bindings/display/fsl,hdp.txt
> > new file mode 100644
> > index ..53ca08337587
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/fsl,hdp.txt
> > @@ -0,0 +1,56 @@
> > +NXP Layerscpae ls1028a HDP-TX PHY Controller
> 
> typo
> 
> > +
> > +
> > +The following bindings describe the Cadence HDP TX PHY on ls1028a
> > +that offer multi-protocol support of standars such as eDP and
> > +Displayport,
> 
> s/offer/offers/
> 
> and another typo.
> 
> > +supports for 25-600MHz pixel clock and up to 4k2k at 60MHz resolution.
> > +The HDP transmitter is a Cadence HDP TX controller IP with a
> > +companion PHY IP.
> > +
> > +Required properties:
> > +  - compatible:   Should be "fsl,ls1028a-dp" for ls1028a.
> > +  - reg:  Physical base address and size of the block of registers
> used
> > +  by the processor.
> 
> The example shows 2 regions, what are they?

One is HDP transmitter controller address region, another is multimedia PLL 
address region.
Sorry, here should be use the HDP transmitter controller region. 

I've already send clock patches included the multimedia PLL implementation.

> 
> > +  - interrupts:   HDP hotplug in/out detect interrupt number
> > +  - clocks:   A list of phandle + clock-specifier pairs, one for each
> entry
> > +  in 'clock-names'
> > +  - clock-names:  A list of clock names. It should contain:
> > +  - "clk_ipg": inter-Integrated circuit clock
> > +  - "clk_core": for the Main Display TX controller clock
> > +  - "clk_pxl": for the pixel clock feeding the output PLL of the 
> > processor
> > +  - "clk_pxl_mux": for the high PerfPLL bypass clock
> > +  - "clk_pxl_link": for the link rate pixel clock
> > +  - "clk_apb": for the APB interface clock
> > +  - "clk_vif": for the Video pixel clock
> 
> 'clk_' is redundant.
> 

OK

> > +
> > +Required sub-nodes:
> > +  - port: The HDP connection to an encoder output port. The connection
> > +is modelled using the OF graph bindings specified in
> > +Documentation/devicetree/bindings/graph.txt
> 
> I'm still confused as to what this block does? The 'encoder output' is
> DisplayPort? If this is just a phy, then use the phy binding.
> 
> Normally, a DisplayPort encoder/bridge OF graph output would be connected
> to a DP connector node or a panel.

Yes, you are right, but 
For LS1028A, HDP(Cadence HD Display Transmitter) are included eDP/Display port 
controller and Display PHY controller.
In other word, they are 1 IP block on LS1028A.

A full graphics connection relationship of the LS1028A:

DP500 --> eDP/DP controller ---> DPHY ---> DP/eDP interface.

Best Regards,
Wen

> 
> Rob


RE: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-07-23 Thread Wen He


> -Original Message-
> From: Liviu Dudau 
> Sent: 2019年7月22日 17:33
> To: Wen He 
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> 
> Subject: Re: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface
> configuration for Mali DP500
> 
> Caution: EXT Email
> 
> On Mon, Jul 22, 2019 at 02:12:08AM +, Wen He wrote:
> >
> >
> > > -Original Message-
> > > From: Liviu Dudau 
> > > Sent: 2019年7月19日 19:46
> > > To: Wen He 
> > > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> > > 
> > > Subject: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS
> > > interface configuration for Mali DP500
> > >
> > > Caution: EXT Email
> > >
> > > On Fri, Jul 19, 2019 at 05:54:45PM +0800, Wen He wrote:
> > > > Configure the display Quality of service (QoS) levels priority if
> > > > the optional property node "arm,malidp-aqros-value" is defined in DTS
> file.
> > > >
> > > > QoS signaling using AQROS and AWQOS AXI interface signals, the
> > > > AQROS is driven from the "RQOS" register, so needed to program the
> > > > RQOS register to avoid the 4k resolution flicker issue on the LS1028A
> platform.
> > > >
> > > > Signed-off-by: Wen He 
> > > > ---
> > > > change in v2:
> > > > - modify some content based on feedback from maintainers
> > > >
> > > >  drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
> > > >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> > > >  drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
> > > >  drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> > > >  4 files changed, 32 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > > > b/drivers/gpu/drm/arm/malidp_drv.c
> > > > index f25ec4382277..61c49a0668a7 100644
> > > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > > @@ -818,6 +818,12 @@ static int malidp_bind(struct device *dev)
> > > >
> > > >   malidp->core_id = version;
> > > >
> > > > + ret = of_property_read_u32(dev->of_node,
> > > > + "arm,malidp-arqos-value",
> > > > + >arqos_value);
> > > > + if (ret)
> > > > + hwdev->arqos_value = 0x0;
> > >
> > > Is zero the default value that you want? I thought it was 0x00010001.
> >
> > Actually, the register default value always is 0x00010001(can be found in RM
> document).
> 
> Exactly, but with your code you are overwriting it to 0 if the DT doesn't have
> the arm,malidp-arqos-value property.

Impossible, I've always block the overwrite action with following condition in 
code.

if (hwdev->arqos_value) {

}

> 
> >
> > >
> > > > +
> > > >   /* set the number of lines used for output of RGB data */
> > > >   ret = of_property_read_u8_array(dev->of_node,
> > > >
> > > > "arm,malidp-output-port-lines", diff --git
> > > > a/drivers/gpu/drm/arm/malidp_hw.c
> > > > b/drivers/gpu/drm/arm/malidp_hw.c index 50af399d7f6f..323683b1e9f7
> > > > 100644
> > > > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > > > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > > > @@ -374,6 +374,19 @@ static void malidp500_modeset(struct
> > > malidp_hw_device *hwdev, struct videomode *
> > > >   malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > > MALIDP_DE_DISPLAY_FUNC);
> > > >   else
> > > >   malidp_hw_clearbits(hwdev,
> MALIDP_DISP_FUNC_ILACED,
> > > > MALIDP_DE_DISPLAY_FUNC);
> > > > +
> > > > + /*
> > > > +  * Program the RQoS register to avoid 4k resolution flicker
> > > > +  * on the LS1028A.
> > > > +  */
> > > > + if (hwdev->arqos_value) {
> > > > + val = hwdev->arqos_value;
> > > > +
> > > > + if (mode->pixelclock == 59400)
> > >
> > > If I remember correctly, you declare the pixelclocks in the device
> > > tree, so I wonder

RE: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-07-21 Thread Wen He


> -Original Message-
> From: Liviu Dudau 
> Sent: 2019年7月19日 19:46
> To: Wen He 
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> 
> Subject: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface
> configuration for Mali DP500
> 
> Caution: EXT Email
> 
> On Fri, Jul 19, 2019 at 05:54:45PM +0800, Wen He wrote:
> > Configure the display Quality of service (QoS) levels priority if the
> > optional property node "arm,malidp-aqros-value" is defined in DTS file.
> >
> > QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS
> > is driven from the "RQOS" register, so needed to program the RQOS
> > register to avoid the 4k resolution flicker issue on the LS1028A platform.
> >
> > Signed-off-by: Wen He 
> > ---
> > change in v2:
> > - modify some content based on feedback from maintainers
> >
> >  drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
> >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> >  drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
> >  drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> >  4 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index f25ec4382277..61c49a0668a7 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -818,6 +818,12 @@ static int malidp_bind(struct device *dev)
> >
> >   malidp->core_id = version;
> >
> > + ret = of_property_read_u32(dev->of_node,
> > + "arm,malidp-arqos-value",
> > + >arqos_value);
> > + if (ret)
> > + hwdev->arqos_value = 0x0;
> 
> Is zero the default value that you want? I thought it was 0x00010001.

Actually, the register default value always is 0x00010001(can be found in RM 
document).

> 
> > +
> >   /* set the number of lines used for output of RGB data */
> >   ret = of_property_read_u8_array(dev->of_node,
> >   "arm,malidp-output-port-lines",
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c index 50af399d7f6f..323683b1e9f7
> > 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -374,6 +374,19 @@ static void malidp500_modeset(struct
> malidp_hw_device *hwdev, struct videomode *
> >   malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> >   else
> >   malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > MALIDP_DE_DISPLAY_FUNC);
> > +
> > + /*
> > +  * Program the RQoS register to avoid 4k resolution flicker
> > +  * on the LS1028A.
> > +  */
> > + if (hwdev->arqos_value) {
> > + val = hwdev->arqos_value;
> > +
> > + if (mode->pixelclock == 59400)
> 
> If I remember correctly, you declare the pixelclocks in the device tree, so I
> wonder if this is needed here. We should just set what value was in the DT
> regardless of the pixelclock, and then you manipulate the DT to choose one of
> your fixed resolutions and also set the QoS value.

Yes, you remember correctly, but
1. declare the pixelclocks in the device tree.
About this, I was hoping to discuss it with you. I want to implement another 
patch
that just declare 27MHz reference clock in the device tree and add a fake clock 
subsystem
to enable/display prepare to set PLL. I am thinking what to do next.
As I remember, I sent out a patch that "Disable checking for required pixel 
clock",
I think should be cancel it.

2. declare the fixed resolutions list in DTS.
Yes, Although I put four resolutions for supported list in DTS file, but this 
just a
workaround that If not enable EDID OR EDID is not available. Once EDID is 
enabled,
these resolutions list declare will be remove in DTS. so we can't use it as a 
condition
to set the QoS value. 

Best Regards,
Wen

> 
> Best regards,
> Liviu
> 
> > + malidp_hw_setbits(hwdev, val,
> MALIDP500_RQOS_QUALITY);
> > + else
> > + malidp_hw_clearbits(hwdev, val,
> MALIDP500_RQOS_QUALITY);
> > + }
> >  }
> >
> >  int malidp_format_get_bpp(u32 fmt)
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.h
> > b/drivers/gpu/drm/arm/malidp_hw.h index 968a65eed371..e4c36bc90bda
> > 100644
> > --- a/drivers/

[v2] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE

2019-07-19 Thread Wen He
The new LS1028A DP driver code causes a link failure when DRM_IMX built-in,
but platform is ARCH_LAYERSCAPE:

drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to `ipu_prg_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to `ipu_dc_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:53: undefined reference to 
`ipu_dc_enable_channel'
drivers/gpu/drm/imx/ipuv3-crtc.c:54: undefined reference to `ipu_di_enable'
drivers/gpu/drm/imx/ipuv3-crtc.o: In function `ipu_crtc_mode_set_nofb

Adding a Kconfig dependency allow to build if ARCH_LAYERSCAPE is enable.

Signed-off-by: Wen He 
---
change in v2:
- fix Kconfig conflit issue after rebased to kernel 5.2

 drivers/gpu/ipu-v3/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index 061fb990c120..be515dd95c2c 100644
--- a/drivers/gpu/ipu-v3/Kconfig
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config IMX_IPUV3_CORE
tristate "IPUv3 core support"
-   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || COMPILE_TEST
+   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || COMPILE_TEST 
|| ARCH_LAYERSCAPE
depends on DRM || !DRM # if DRM=m, this can't be 'y'
select BITREVERSE
select GENERIC_ALLOCATOR if DRM
-- 
2.17.1



[v2 2/4] arm64: dts: ls1028a: Add properties for HDP Controller.

2019-07-19 Thread Wen He
This patch enables the HDP controller driver on the LS1028A.

Signed-off-by: Alison Wang 
Signed-off-by: Wen He 
---
 .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 25 +++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index aef5b06a98d5..19612ad9a4a1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -91,6 +91,13 @@
clock-output-names= "pclk";
};
 
+   hdpclk: clock-hdpcore {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <16250>;
+   clock-output-names= "hdpclk";
+   };
+
reboot {
compatible ="syscon-reboot";
regmap = <>;
@@ -558,7 +565,25 @@
 
port {
dp0_out: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 
+   hdptx0: display@f20 {
+   compatible = "fsl,ls1028a-dp";
+   reg = <0x0 0xf1f 0x0 0x>,
+   <0x0 0xf20 0x0 0xf>;
+   interrupts = <0 221 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <>, <>, <>,
+<>, <>, <>, <>;
+   clock-names = "clk_ipg", "clk_core", "clk_pxl",
+ "clk_pxl_mux", "clk_pxl_link", "clk_apb",
+ "clk_vif";
+
+   port {
+   dp1_out: endpoint {
+   remote-endpoint = <_out>;
};
};
};
-- 
2.17.1



[v2 3/4] arm64: ls1028ardb: Add support DP nodes for LS1028ARDB

2019-07-19 Thread Wen He
This patch add HDP PHY Controller related nodes on the LS1028ARDB.

Signed-off-by: Alison Wang 
Signed-off-by: Wen He 
---
 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 9fb911317ecd..a907eb2c000b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -171,3 +171,15 @@
  {
status = "okay";
 };
+
+ {
+   fsl,no_edid;
+   resolution = "3840x2160@60",
+  "1920x1080@60",
+  "1280x720@60",
+  "720x480@60";
+   lane_mapping = <0x4e>;
+   edp_link_rate = <0x6>;
+   edp_num_lanes = <0x4>;
+   status = "okay";
+};
-- 
2.17.1



[v2 4/4] arm64: ls1028aqds: Add support DP nodes for LS1028AQDS

2019-07-19 Thread Wen He
This patch add HDP PHY Controller related nodes on the LS1028AQDS.

Signed-off-by: Alison Wang 
Signed-off-by: Wen He 
---
 arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index de6ef39f3118..a9af6e8a6517 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -173,3 +173,15 @@
  {
status = "okay";
 };
+
+ {
+   fsl,no_edid;
+   resolution = "3840x2160@60",
+  "1920x1080@60",
+  "1280x720@60",
+  "720x480@60";
+   lane_mapping = <0x4e>;
+   edp_link_rate = <0x6>;
+   edp_num_lanes = <0x4>;
+   status = "okay";
+};
-- 
2.17.1



[v2 1/4] dt-bindings: display: Add DT bindings for LS1028A HDP-TX PHY.

2019-07-19 Thread Wen He
Add DT bindings documentmation for the HDP-TX PHY controller. The describes
which could be found on NXP Layerscape ls1028a platform.

Signed-off-by: Wen He 
---
change in v2:
- correction the node name.

 .../devicetree/bindings/display/fsl,hdp.txt   | 56 +++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/fsl,hdp.txt

diff --git a/Documentation/devicetree/bindings/display/fsl,hdp.txt 
b/Documentation/devicetree/bindings/display/fsl,hdp.txt
new file mode 100644
index ..53ca08337587
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/fsl,hdp.txt
@@ -0,0 +1,56 @@
+NXP Layerscpae ls1028a HDP-TX PHY Controller
+
+
+The following bindings describe the Cadence HDP TX PHY on ls1028a that
+offer multi-protocol support of standars such as eDP and Displayport,
+supports for 25-600MHz pixel clock and up to 4k2k at 60MHz resolution.
+The HDP transmitter is a Cadence HDP TX controller IP with a companion
+PHY IP.
+
+Required properties:
+  - compatible:   Should be "fsl,ls1028a-dp" for ls1028a.
+  - reg:  Physical base address and size of the block of registers used
+  by the processor.
+  - interrupts:   HDP hotplug in/out detect interrupt number
+  - clocks:   A list of phandle + clock-specifier pairs, one for each entry
+  in 'clock-names'
+  - clock-names:  A list of clock names. It should contain:
+  - "clk_ipg": inter-Integrated circuit clock
+  - "clk_core": for the Main Display TX controller clock
+  - "clk_pxl": for the pixel clock feeding the output PLL of the processor
+  - "clk_pxl_mux": for the high PerfPLL bypass clock
+  - "clk_pxl_link": for the link rate pixel clock
+  - "clk_apb": for the APB interface clock
+  - "clk_vif": for the Video pixel clock
+
+Required sub-nodes:
+  - port: The HDP connection to an encoder output port. The connection
+is modelled using the OF graph bindings specified in
+Documentation/devicetree/bindings/graph.txt
+
+
+Example:
+
+/ {
+...
+
+hdptx0: display@f20 {
+compatible = "fsl,ls1028a-dp";
+   reg = <0x0 0xf1f 0x0 0x>,
+   <0x0 0xf20 0x0 0xf>;
+interrupts = <0 221 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <>, <>, <>,
+ <>, <>, <>, <>;
+   clock-names = "clk_ipg", "clk_core", "clk_pxl",
+  "clk_pxl_mux", "clk_pxl_link", "clk_apb",
+  "clk_vif";
+
+   port {
+   dp1_output: endpoint {
+   remote-endpoint = <_input>;
+   };
+   };
+};
+
+...
+};
-- 
2.17.1



[v2 2/3] dt/bindings: display: Add optional property node defined for Mali DP500

2019-07-19 Thread Wen He
Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
This property describe the ARQoS levels of DP500's QoS signaling.

Signed-off-by: Wen He 
---
 Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt 
b/Documentation/devicetree/bindings/display/arm,malidp.txt
index 2f7870983ef1..76a0e7251251 100644
--- a/Documentation/devicetree/bindings/display/arm,malidp.txt
+++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
@@ -37,6 +37,8 @@ Optional properties:
 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
 to be used for the framebuffer; if not present, the framebuffer may
 be located anywhere in memory.
+  - arm,malidp-arqos-high-level: integer of u32 value describing the ARQoS
+levels of DP500's QoS signaling.
 
 
 Example:
@@ -54,6 +56,7 @@ Example:
clocks = <>, <>, <>, <>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
+   arm,malidp-arqos-high-level = <>;
port {
dp0_output: endpoint {
remote-endpoint = <_2_input>;
-- 
2.17.1



[v2 1/3] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500

2019-07-19 Thread Wen He
Configure the display Quality of service (QoS) levels priority if the
optional property node "arm,malidp-aqros-value" is defined in DTS file.

QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
driven from the "RQOS" register, so needed to program the RQOS register
to avoid the 4k resolution flicker issue on the LS1028A platform.

Signed-off-by: Wen He 
---
change in v2:
- modify some content based on feedback from maintainers

 drivers/gpu/drm/arm/malidp_drv.c  |  6 ++
 drivers/gpu/drm/arm/malidp_hw.c   | 13 +
 drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
 drivers/gpu/drm/arm/malidp_regs.h | 10 ++
 4 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index f25ec4382277..61c49a0668a7 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -818,6 +818,12 @@ static int malidp_bind(struct device *dev)
 
malidp->core_id = version;
 
+   ret = of_property_read_u32(dev->of_node,
+   "arm,malidp-arqos-value",
+   >arqos_value);
+   if (ret)
+   hwdev->arqos_value = 0x0;
+
/* set the number of lines used for output of RGB data */
ret = of_property_read_u8_array(dev->of_node,
"arm,malidp-output-port-lines",
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 50af399d7f6f..323683b1e9f7 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -374,6 +374,19 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
else
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
+
+   /*
+* Program the RQoS register to avoid 4k resolution flicker
+* on the LS1028A.
+*/
+   if (hwdev->arqos_value) {
+   val = hwdev->arqos_value;
+
+   if (mode->pixelclock == 59400)
+   malidp_hw_setbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   else
+   malidp_hw_clearbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   }
 }
 
 int malidp_format_get_bpp(u32 fmt)
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 968a65eed371..e4c36bc90bda 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -251,6 +251,9 @@ struct malidp_hw_device {
 
/* size of memory used for rotating layers, up to two banks available */
u32 rotation_memory[2];
+
+   /* priority level of RQOS register used for driven the ARQOS signal */
+   u32 arqos_value;
 };
 
 static inline u32 malidp_hw_read(struct malidp_hw_device *hwdev, u32 reg)
diff --git a/drivers/gpu/drm/arm/malidp_regs.h 
b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..514c50dcb74d 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -210,6 +210,16 @@
 #define MALIDP500_CONFIG_VALID 0x00f00
 #define MALIDP500_CONFIG_ID0x00fd4
 
+/*
+ * The quality of service (QoS) register on the DP500. RQOS register values
+ * are driven by the ARQOS signal, using AXI transacations, dependent on the
+ * FIFO input level.
+ * The RQOS register can also set QoS levels for:
+ *- RED_ARQOS   @ A 4-bit signal value for close to underflow conditions
+ *- GREEN_ARQOS @ A 4-bit signal value for normal conditions
+ */
+#define MALIDP500_RQOS_QUALITY  0x00500
+
 /* register offsets and bits specific to DP550/DP650 */
 #define MALIDP550_ADDR_SPACE_SIZE  0x1
 #define MALIDP550_DE_CONTROL   0x00010
-- 
2.17.1



RE: [EXT] Re: [PATCH] drm/arm/mali-dp: Add display QoS interface configuration

2019-07-18 Thread Wen He


> -Original Message-
> From: Liviu Dudau 
> Sent: 2019年7月18日 17:37
> To: Wen He 
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> 
> Subject: Re: [EXT] Re: [PATCH] drm/arm/mali-dp: Add display QoS interface
> configuration
> 
> Caution: EXT Email
> 
> On Thu, Jul 18, 2019 at 03:29:48AM +, Wen He wrote:
> >
> >
> > > -Original Message-
> > > From: Liviu Dudau 
> > > Sent: 2019年7月17日 19:22
> > > To: Wen He 
> > > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> > > 
> > > Subject: [EXT] Re: [PATCH] drm/arm/mali-dp: Add display QoS
> > > interface configuration
> > >
> > >
> > > Hi Wen,
> > >
> >
> > Hi Liviu,
> 
> Hi Wen,
> 
> >
> > > On Wed, Jul 17, 2019 at 05:23:53PM +0800, Wen He wrote:
> > > > Configure the display Quality of service (QoS) levels to high
> > > > priority if the level is defined as high as in DTS. The ARQOS for
> > > > DP500 is driven from the "RQOS" register, needed to program the
> > > > RQOS register value < 7 for the 4k resolution flicker to disappear on 
> > > > the
> LS1028A platform.
> > >
> > > Thanks for taking time to come up with a more generic patch for your
> issue!
> > >
> >
> > Thanks for the review and comments,
> >
> > > I have a question: what happens if you program the
> > > MALIDP500_RQOS_QUALITY register to 0xd000d000 for all pixelclocks?
> > >
> >
> > We can't do that, because:
> > 1. The flicker issue only reproduced in 4k@60.
> 
> Can you clarify? Does this mean that with the RQOS setting of 0xd000d000
> you don't see flicker at lower resolutions, or that you haven't tested at 
> other
> resolution than 4k@60?

I mean that I didn't see flicker issue at lower resolutions without the RQOS 
setting
of 0xd000d000.

The ROQS register default value's 0x00010001, in this case, only found the 
flicker
issue can be reproduced in 4k@60, other lower resolutions not found this issue.
So If setting the RQOS register value's to 0xd001d001, 4k flicker issue will be 
resolve.

> 
> > 2. This configuration will be reduced DDR benchmark performance data,
> > because the LCDC and DDR are both to connect CCI-400. we have to make
> > sure that DDR performance at first when work together with other
> resolutions.
> 
> Hmm, I'm not sure I'm sharing the same view of the problem. You are writing
> into DP500's QoS registers, which don't control how CCI-400 or DDR are going
> to behave. Now I agree that a more aggressive QoS from DP500 is going to
> lead to more contention to the DDR, but maybe you can look into CCI-400's
> QoS settings and tweak the bandwidth allocation there as well.

Yes, I agree with you, but after discussed with our design team, I chose them 
advice
that only change the DP500's QoS.
Here're comments from our design team:
---
There are multiple registers that impact QOS values in the system, particularly 
as it
relates to transactions from the LCD Controller.
"The “best” approach (which in theory should result in the LCD Controller having
the bandwidth it needs to avoid buffer underrun, while also having the minimal 
impact
on the system) is to use the dynamic QoS information (ARQOS) coming from the LCD
Controller. To do this, you need to program the LCD Controller’s “RQOS” 
register. 
See the attached DP-500 TRM, Section 2.4.6, “Display Quality of Service 
Interface”
and Section 4.2.9, “Display engine quality of service registers”.
---

> 
> >
> > > Also, some suggestions further down:
> > >
> > > >
> > > > Signed-off-by: Wen He 
> > > > ---
> > > > change in v2:
> > > > - add new implementation for 4k flicker issue on the
> > > > LS1028A
> > > >
> > > >  drivers/gpu/drm/arm/malidp_drv.c  |  5 +
> > > >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> > > >  drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
> > > >  drivers/gpu/drm/arm/malidp_regs.h | 12 
> > > >  4 files changed, 33 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > > > b/drivers/gpu/drm/arm/malidp_drv.c
> > > > index f25ec4382277..d2b2cf52ac87 100644
> > > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> &g

RE: [EXT] Re: [PATCH] drm/arm/mali-dp: Add display QoS interface configuration

2019-07-17 Thread Wen He


> -Original Message-
> From: Liviu Dudau 
> Sent: 2019年7月17日 19:22
> To: Wen He 
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> 
> Subject: [EXT] Re: [PATCH] drm/arm/mali-dp: Add display QoS interface
> configuration
> 
> 
> Hi Wen,
> 

Hi Liviu,

> On Wed, Jul 17, 2019 at 05:23:53PM +0800, Wen He wrote:
> > Configure the display Quality of service (QoS) levels to high priority
> > if the level is defined as high as in DTS. The ARQOS for DP500 is
> > driven from the "RQOS" register, needed to program the RQOS register
> > value < 7 for the 4k resolution flicker to disappear on the LS1028A 
> > platform.
> 
> Thanks for taking time to come up with a more generic patch for your issue!
> 

Thanks for the review and comments,

> I have a question: what happens if you program the
> MALIDP500_RQOS_QUALITY register to 0xd000d000 for all pixelclocks?
> 

We can't do that, because:
1. The flicker issue only reproduced in 4k@60.
2. This configuration will be reduced DDR benchmark performance data, because 
the
LCDC and DDR are both to connect CCI-400. we have to make sure that DDR 
performance
at first when work together with other resolutions.

> Also, some suggestions further down:
> 
> >
> > Signed-off-by: Wen He 
> > ---
> > change in v2:
> > - add new implementation for 4k flicker issue on the LS1028A
> >
> >  drivers/gpu/drm/arm/malidp_drv.c  |  5 +
> >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> >  drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
> >  drivers/gpu/drm/arm/malidp_regs.h | 12 
> >  4 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index f25ec4382277..d2b2cf52ac87 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -818,6 +818,11 @@ static int malidp_bind(struct device *dev)
> >
> >   malidp->core_id = version;
> >
> > + hwdev->arqos_high_level = false;
> 
> This is not needed.
> 
> > +
> > + hwdev->arqos_high_level = of_property_read_bool(dev->of_node,
> > + "arm,malidp-arqos-high-level");
> 
> I think it would be better to have this property as a u32 value, rather than a
> boolean, and put the value that we want to program MALIDP_RQOS_QUALITY
> with in there.

I really thought that, but I've tested DDR performance for 4k resolution with
different RQOS setting, the best test performance data is when set the RQOS
register value's 0xd000d000. So the value is fixed, I think the Boolean type is
better used here, that's why I did it.

> 
> Also, you need to add the documentation for this optional property in
> Documentation/devicetree/bindings/display/arm,malidp.txt.

Understand, I will generate another patch to add this change for the DT 
bindings.

> 

> > +
> >   /* set the number of lines used for output of RGB data */
> >   ret = of_property_read_u8_array(dev->of_node,
> >   "arm,malidp-output-port-lines",
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c index 50af399d7f6f..eaa1658cd86b
> > 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -374,6 +374,19 @@ static void malidp500_modeset(struct
> malidp_hw_device *hwdev, struct videomode *
> >   malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> >   else
> >   malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > MALIDP_DE_DISPLAY_FUNC);
> > +
> > + /*
> > +  *  Program the RQoS register to increasing QoS levels for
> > +  *  the 4k resolution flicker to disappear on the LS1028A.
> 
> Looks like two sentences got smashed into one, the result is a bit hard to 
> read.
> 

Ha, maybe should be described like this:
"Program the RQoS register to avoid 4k resolution flicker on the LS1028A."

Best Regards,
Wen

> Best regards,
> Liviu
> 
> > +  */
> > + if (hwdev->arqos_high_level) {
> > + val = RED_ARQOS_VALUE | GREEN_ARQOS_VALUE;
> > +
> > + if (mode->pixelclock == 59400)
> > + malidp_hw_setbits(hwdev, val,
> MALIDP500_RQOS_QUALITY);
> > + else
> > + malidp_hw_clearbits(hwdev, val,
> MALIDP500_RQOS_QUALITY);
> > + }
&g

[PATCH] drm/arm/mali-dp: Add display QoS interface configuration

2019-07-17 Thread Wen He
Configure the display Quality of service (QoS) levels to high priority
if the level is defined as high as in DTS. The ARQOS for DP500 is driven
from the "RQOS" register, needed to program the RQOS register value < 7
for the 4k resolution flicker to disappear on the LS1028A platform.

Signed-off-by: Wen He 
---
change in v2:
- add new implementation for 4k flicker issue on the LS1028A

 drivers/gpu/drm/arm/malidp_drv.c  |  5 +
 drivers/gpu/drm/arm/malidp_hw.c   | 13 +
 drivers/gpu/drm/arm/malidp_hw.h   |  3 +++
 drivers/gpu/drm/arm/malidp_regs.h | 12 
 4 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index f25ec4382277..d2b2cf52ac87 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -818,6 +818,11 @@ static int malidp_bind(struct device *dev)
 
malidp->core_id = version;
 
+   hwdev->arqos_high_level = false;
+
+   hwdev->arqos_high_level = of_property_read_bool(dev->of_node,
+   "arm,malidp-arqos-high-level");
+
/* set the number of lines used for output of RGB data */
ret = of_property_read_u8_array(dev->of_node,
"arm,malidp-output-port-lines",
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 50af399d7f6f..eaa1658cd86b 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -374,6 +374,19 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
else
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
+
+   /*
+*  Program the RQoS register to increasing QoS levels for
+*  the 4k resolution flicker to disappear on the LS1028A.
+*/
+   if (hwdev->arqos_high_level) {
+   val = RED_ARQOS_VALUE | GREEN_ARQOS_VALUE;
+
+   if (mode->pixelclock == 59400)
+   malidp_hw_setbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   else
+   malidp_hw_clearbits(hwdev, val, MALIDP500_RQOS_QUALITY);
+   }
 }
 
 int malidp_format_get_bpp(u32 fmt)
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 968a65eed371..b8baba60508a 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -251,6 +251,9 @@ struct malidp_hw_device {
 
/* size of memory used for rotating layers, up to two banks available */
u32 rotation_memory[2];
+
+   /* priority level of RQOS register used for driven the ARQOS signal */
+   bool arqos_high_level;
 };
 
 static inline u32 malidp_hw_read(struct malidp_hw_device *hwdev, u32 reg)
diff --git a/drivers/gpu/drm/arm/malidp_regs.h 
b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..08842142b3b2 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -210,6 +210,18 @@
 #define MALIDP500_CONFIG_VALID 0x00f00
 #define MALIDP500_CONFIG_ID0x00fd4
 
+/*
+ * The quality of service (QoS) register on the DP500. RQOS register values
+ * are driven by the ARQOS signal, using AXI transacations, dependent on the
+ * FIFO input level.
+ * The RQOS register can also set QoS levels for:
+ *- RED_ARQOS   @ A 4-bit signal value for close to underflow conditions
+ *- GREEN_ARQOS @ A 4-bit signal value for normal conditions
+ */
+#define MALIDP500_RQOS_QUALITY  0x00500
+#define RED_ARQOS_VALUE (0xd << 12)
+#define GREEN_ARQOS_VALUE   (0xd << 28)
+
 /* register offsets and bits specific to DP550/DP650 */
 #define MALIDP550_ADDR_SPACE_SIZE  0x1
 #define MALIDP550_DE_CONTROL   0x00010
-- 
2.17.1



RE: [PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k to avoid flicker issue

2019-07-17 Thread Wen He


> -Original Message-
> From: liviu.du...@arm.com 
> Sent: 2019年3月30日 0:11
> To: Wen He 
> Cc: brian.star...@arm.com; mal...@foss.arm.com;
> dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k to avoid
> flicker issue
> 
> On Fri, Mar 29, 2019 at 08:20:00AM +, Wen He wrote:
> >
> >
> > > -Original Message-
> > > From: liviu.du...@arm.com [mailto:liviu.du...@arm.com]
> > > Sent: 2019年3月29日 0:39
> > > To: Wen He 
> > > Cc: brian.star...@arm.com; mal...@foss.arm.com;
> > > dri-devel@lists.freedesktop.org
> > > Subject: Re: [PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k
> > > to avoid flicker issue
> > >
> > > Hi Wen,
> > >
> > > On Thu, Mar 28, 2019 at 03:56:58AM +, Wen He wrote:
> > > > When we running DDR benchmark test will able to observed flicker
> > > > issue in 4k@60 resolution on monitor. In LS1028A SoC, need
> > > > increasing DP500 priority to avoid that issue.
> > > >
> > > > Signed-off-by: Wen He 
> > > > ---
> > > >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> > > >  drivers/gpu/drm/arm/malidp_regs.h |  8 
> > > >  2 files changed, 21 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > > > b/drivers/gpu/drm/arm/malidp_hw.c index
> 8df12e9a33bb..a5263488eb02
> > > > 100644
> > > > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > > > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > > > @@ -378,6 +378,19 @@ static void malidp500_modeset(struct
> > > malidp_hw_device *hwdev, struct videomode *
> > > > malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > > MALIDP_DE_DISPLAY_FUNC);
> > > > else
> > > > malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > > > MALIDP_DE_DISPLAY_FUNC);
> > > > +
> > > > +#ifdef CONFIG_ARCH_LAYERSCAPE
> > > > +   /* Setting QoS for 4k resolution to avoid flicker issue */
> > > > +   if (mode->hactive == 3840
> > > > +   && mode->vactive == 2160)
> > >
> > > I'm not keen on this check, it only enables this for one 3840x2160.
> > > What if the output is 2160x3840? Does it matter what pixel clock you use?
> > > Can the same issue be seen if (for example) you use 120Hz refresh
> > > rate but on a smaller output resolution?
> > >
> >
> > Hi liviu,
> 
> Hi Wen,
> 
> >
> > Let me clearly it.
> > Currently, we only supported four resolutions (480p@60, 720p@60,
> 1080@60, 4k@60) for LS1028A Display port.
> > All of the refresh rate is 60MHz. so that impossible will be there 
> > resolution
> output's 2160x3840 and refresh rate is 120MHz.
> 
> Yes, but you are asking to merge this into the mainline driver which supports
> more resolutions than that.
> 
> >
> > > I think it's worth thinking this in terms of bandwidth and not
> > > hardcode for one resolution.
> > >
> >
> > Yes, you are right.
> > But only 4k resolution have the flicker issue, so this is a special problem.
> > I think that hardcode is better than dynamically adjusting bandwidth.
> 
> If you want to do that for your BSP, then it's fine. For mainline, I think we 
> can
> do better and think in more generic terms.
> 
> >
> > > Also, I think setting the QoS bits should be a bit more generic, i.e
> > > if the modeset requires a certain bandwidth you should write a value
> > > read from a device tree, for example?
> > >
> > > > +   malidp_hw_setbits(hwdev, GREEN_ARQOS_CONFIG
> > > > +   | RED_ARQOS_CONFIG, 
> > > > MALIDP500_RQOS_QUALITY);
> > > > +   else
> > > > +   malidp_hw_clearbits(hwdev, GREEN_ARQOS_CONFIG
> > > > +   | RED_ARQOS_CONFIG, 
> > > > MALIDP500_RQOS_QUALITY);
> > > > +
> > > > +   malidp_hw_setbits(hwdev, CONFIG_VALID,
> MALIDP500_CONFIG_VALID);
> > >
> > > malidp500_modeset() will be called with MALIDP_CFG_VALID set anyway,
> > > so you should not need this. I don't know what bit 1 in
> > > MALIDP500_CONFIG_VALID does for LS1028A, I don't have that spec.
> > >
> >
> > About this, I got this step from our design team, So just to make sure
> > the confi

RE: [EXT] Re: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE

2019-07-08 Thread Wen He


> -Original Message-
> From: Philipp Zabel 
> Sent: 2019年7月5日 18:32
> To: Wen He ; linux-ker...@vger.kernel.org;
> dri-devel@lists.freedesktop.org
> Cc: Leo Li 
> Subject: [EXT] Re: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE
> 
> Caution: EXT Email
> 
> Hi Wen,
> 
> On Wed, 2019-05-08 at 10:56 +, Wen He wrote:
> > The new LS1028A DP driver code causes a link failure when DRM_IMX
> > built-in, but platform is ARCH_LAYERSCAPE:
> >
> > drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to
> `ipu_prg_enable'
> > drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to
> `ipu_dc_enable'
> > drivers/gpu/drm/imx/ipuv3-crtc.c:53: undefined reference to
> `ipu_dc_enable_channel'
> > drivers/gpu/drm/imx/ipuv3-crtc.c:54: undefined reference to `ipu_di_enable'
> > drivers/gpu/drm/imx/ipuv3-crtc.o: In function `ipu_crtc_mode_set_nofb
> >
> > Adding a Kconfig dependency allow to build if ARCH_LAYERSCAPE is enable.
> >
> > Signed-off-by: Wen He 
> > ---
> >  drivers/gpu/ipu-v3/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
> > index fe6f8c5b4445..51ea88c440df 100644
> > --- a/drivers/gpu/ipu-v3/Kconfig
> > +++ b/drivers/gpu/ipu-v3/Kconfig
> > @@ -1,6 +1,6 @@
> >  config IMX_IPUV3_CORE
> >   tristate "IPUv3 core support"
> > - depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM ||
> COMPILE_TEST
> > + depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM ||
> > + COMPILE_TEST || ARCH_LAYERSCAPE
> >   depends on DRM || !DRM # if DRM=m, this can't be 'y'
> >   select BITREVERSE
> >   select GENERIC_ALLOCATOR if DRM
> > --
> > 2.17.1
> 
> Thank you for the patch, but this does not seem right.
> ipuv3-crtc.c is part of DRM_IMX, which already depends on IMX_IPUV3_CORE.
> How did you manage to make it try to compile imxdrm?
> 

Thanks for the review, Philipp,

NXP LS1028A platform use same Display IP with IMX8, so they have use same 
display
transmit controller drivers, config 'DRM_IMX' is used to support drm common 
drivers
on the NXP I.MX and LS1028A, display transmit controller is coming to plan 
upstream.  

Actually, we have done compile of the imxdrm on LS1028A BSP release.

> Since LS1028A does not have the IPUv3, keeping this under COMPILE_TEST
> should be correct.

Although LS1028A does not have the IPVv3, but DRM_IMX depends on it, LS1028A 
display
Transmit controller drivers also depends on DRM_IMX, so we need add this 
dependency to
solve the compile issue.

Best Regards,
Wen

> 
> regards
> Philipp


RE: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required pixel clock rate

2019-05-17 Thread Wen He


> -Original Message-
> From: liviu.du...@arm.com [mailto:liviu.du...@arm.com]
> Sent: 2019年5月16日 16:24
> To: Wen He 
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Leo Li
> 
> Subject: Re: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required
> pixel clock rate
> 
> Caution: EXT Email
> 
> On Thu, May 16, 2019 at 08:10:21AM +, Wen He wrote:
> >
> >
> > > -Original Message-
> > > From: liviu.du...@arm.com [mailto:liviu.du...@arm.com]
> > > Sent: 2019年5月15日 23:46
> > > To: Wen He 
> > > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > > Leo Li 
> > > Subject: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for
> > > required pixel clock rate
> > >
> > >
> > > Hi Wen,
> >
> > Hi Liviu,
> >

Hi Liviu,

> > >
> > > On Wed, May 15, 2019 at 02:42:08AM +0000, Wen He wrote:
> > > > Disable checking for required pixel clock rate if ARCH_LAYERSCPAE
> > > > is enable.
> > > >
> > > > Signed-off-by: Alison Wang 
> > > > Signed-off-by: Wen He 
> > > > ---
> > > > change in description:
> > > >   - This check that only supported one pixel clock required clock
> rate
> > > >   compare with dts node value. but we have supports 4 pixel clock
> > > >   for ls1028a board.
> > >
> > > So, your DT says your pixel clock provider is a fixed clock? If you
> > > support more than one rate, you should instead use a real provider
> > > for it. How do you support the 4 pixel clocks?
> > >
> >
> > Yes , the DT node only can provided one pixel clock by using a fixed clock.
> > But we Display Port controller support 4 or more resolutions, each of
> > which requires a set of pixel clocks to drive, and we hope they can
> > switch any resolution we want by some program every times.
> 
> That program can't be some userspace application, because it will have to
> make changes to the hardware and the kernel will not know that things have
> changed under its feet. That leaves the option of the bootloader or some other
> kernel module doing the changes.
> 
> If you have another kernel module that knows how to change clocks, that
> should be implemented using the common clocks infrastructure, at which time
> you can put it in the DT as the clock provider for the pixelclock.
> 

Hi Liviu,

Yes, I think you are right, and even though we didn't implement clocks prepare
/enable/disable interface, but we can notification hardware to change pixel 
clock
by determining the required pixel clock in each mode once had modeset event
in DP driver.

But the point is how do we meet the conditions for the clock rate check in 
here? 

As you know, we LS1028A supports 4 modes, every resolution change will to
determine whether the hardware supports the pixel clock required for the 
resolution
by calling this function malidp_crtc_mode_valid() . assume if we put 
fixed-clock in DT
node that will can't meet this checking.

Best Regards,
Wen

> If the bootloader does the changes, then the bootloader should edit the DT
> and set the correct value for the pixel clock. Regardless, with your change 
> and
> on your platform the user can request any resolution and the driver will
> silently fail to set that resolution.
> 
> One other problem is the one Robin raised, where the kernel is compiled for
> multiple platforms, like what various Linux distributions do. That kernel will
> either work on other SoC or not, depending on what
> CONFIG_ARCH_LAYERSCAPE is set to.
> 
> In summary, for this patch, it's a NAK. There are proper ways of achieving 
> what
> you need, but this patch is not.
> 
> Best regards,
> Liviu
> 
> >
> > For example, if we set that fixed pixel clock is 2700 (27Mhz), but
> > user hope can see a group 1080p resolution penguins during startup ,
> > and hope playing a 4k video once system boot up done.
> > Btw, In our board, the 1080p resolution is driven by a 148.5Mhz pixel
> > clock, 4k is driven by a 594Mhz. 27Mhz only can drive 480p resolution.
> >
> > To meet the above user requirements, I was to setup following steps,
> > 1. Add the "video=1920x1080-32@60" to bootargs command line [specify
> > penguins size] 2. Play a 4K video with 4k resolution when system boot up
> done.
> >
> > > Also, not sure what the paragraph above is meant to be. Should it be
> > > part of the commit message?
> > >
> >
> > These comments just want to let you know.
> >
> > > Best regards,
> &g

RE: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required pixel clock rate

2019-05-17 Thread Wen He


> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 2019年5月16日 18:45
> To: Wen He ; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org; liviu.du...@arm.com
> Cc: Leo Li 
> Subject: Re: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required
> pixel clock rate
> 
> 
> On 16/05/2019 10:42, Wen He wrote:
> >
> >
> >> -Original Message-
> >> From: Robin Murphy [mailto:robin.mur...@arm.com]
> >> Sent: 2019年5月16日 1:14
> >> To: Wen He ; dri-devel@lists.freedesktop.org;
> >> linux-ker...@vger.kernel.org; liviu.du...@arm.com
> >> Cc: Leo Li 
> >> Subject: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for
> >> required pixel clock rate
> >>
> >> Caution: EXT Email
> >>
> >> On 15/05/2019 03:42, Wen He wrote:
> >>> Disable checking for required pixel clock rate if ARCH_LAYERSCPAE is
> >>> enable.
> >>>
> >>> Signed-off-by: Alison Wang 
> >>> Signed-off-by: Wen He 
> >>> ---
> >>> change in description:
> >>>- This check that only supported one pixel clock required clock
> rate
> >>>compare with dts node value. but we have supports 4 pixel clock
> >>>for ls1028a board.
> >>>drivers/gpu/drm/arm/malidp_crtc.c | 2 ++
> >>>1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> >>> b/drivers/gpu/drm/arm/malidp_crtc.c
> >>> index 56aad288666e..bb79223d9981 100644
> >>> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> >>> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> >>> @@ -36,11 +36,13 @@ static enum drm_mode_status
> >>> malidp_crtc_mode_valid(struct drm_crtc *crtc,
> >>>
> >>>if (req_rate) {
> >>>rate = clk_round_rate(hwdev->pxlclk, req_rate);
> >>> +#ifndef CONFIG_ARCH_LAYERSCAPE
> >>
> >> What about multiplatform builds? The kernel config doesn't tell you
> >> what hardware you're actually running on.
> >>
> >
> > Hi Robin,
> >
> > Thanks for your reply.
> >
> > In fact, Only one platform integrates this IP when
> CONFIG_ARCH_LAYERSCAPE is set.
> > Although this are not good ways, but I think it won't be a problem under
> multiplatform builds.
> 
> My point is that ARCH_LAYERSCAPE is going to be enabled in distribution
> kernels along with everything else, so you're effectively removing this check 
> for
> all other vendors' Mali-DP implementations as well, which is probably not OK.
> 
> Furthermore, if LS1028A really only supports 4 specific modes as the BSP
> documentation I found claims, then surely you'd want a *more* specific check
> here, rather than no check at all?

Hi Robin,

Thanks for your comments.

Yes, As you said, now LS1028A only supports 4 modes, and we use three clocks to 
support
all four modes. In fact, this was really the point.

However, we can only enable one mode to meet the check statement in this place.

For example, If user has a 1080p monitor, we must be set the pixel fixed-clock 
to 148.5MHz. 
if user want to choice 4k monitor, we also to be change the pixel fixed-clock 
to 594MHz in
DT node. In reality, We have no way of knowing what kind of monitor the user 
wants. Right?

Moreover, user cannot to change screen resolution in this case, I don't think 
this place is
reasonable. we need to supporting Ubuntu , Wayland and other embedded GU, so we 
need
to switch the resolutions.

Maybe it's that most android device used, and android system always only need 
one
resolution.

Best Regards,
Wen

> 
> Robin.


RE: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required pixel clock rate

2019-05-17 Thread Wen He


> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 2019年5月16日 1:14
> To: Wen He ; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org; liviu.du...@arm.com
> Cc: Leo Li 
> Subject: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required pixel
> clock rate
> 
> Caution: EXT Email
> 
> On 15/05/2019 03:42, Wen He wrote:
> > Disable checking for required pixel clock rate if ARCH_LAYERSCPAE is
> > enable.
> >
> > Signed-off-by: Alison Wang 
> > Signed-off-by: Wen He 
> > ---
> > change in description:
> >   - This check that only supported one pixel clock required clock rate
> >   compare with dts node value. but we have supports 4 pixel clock
> >   for ls1028a board.
> >   drivers/gpu/drm/arm/malidp_crtc.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> > b/drivers/gpu/drm/arm/malidp_crtc.c
> > index 56aad288666e..bb79223d9981 100644
> > --- a/drivers/gpu/drm/arm/malidp_crtc.c
> > +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> > @@ -36,11 +36,13 @@ static enum drm_mode_status
> > malidp_crtc_mode_valid(struct drm_crtc *crtc,
> >
> >   if (req_rate) {
> >   rate = clk_round_rate(hwdev->pxlclk, req_rate);
> > +#ifndef CONFIG_ARCH_LAYERSCAPE
> 
> What about multiplatform builds? The kernel config doesn't tell you what
> hardware you're actually running on.
> 

Hi Robin,

Thanks for your reply.

In fact, Only one platform integrates this IP when CONFIG_ARCH_LAYERSCAPE is 
set.
Although this are not good ways, but I think it won't be a problem under 
multiplatform builds.

Best Regards,
Wen

> Robin.
> 
> >   if (rate != req_rate) {
> >   DRM_DEBUG_DRIVER("pxlclk doesn't support %ld
> Hz\n",
> >req_rate);
> >   return MODE_NOCLOCK;
> >   }
> > +#endif
> >   }
> >
> >   return MODE_OK;
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required pixel clock rate

2019-05-16 Thread Wen He


> -Original Message-
> From: liviu.du...@arm.com [mailto:liviu.du...@arm.com]
> Sent: 2019年5月15日 23:46
> To: Wen He 
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Leo Li
> 
> Subject: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required pixel
> clock rate
> 
> 
> Hi Wen,

Hi Liviu,

> 
> On Wed, May 15, 2019 at 02:42:08AM +, Wen He wrote:
> > Disable checking for required pixel clock rate if ARCH_LAYERSCPAE is
> > enable.
> >
> > Signed-off-by: Alison Wang 
> > Signed-off-by: Wen He 
> > ---
> > change in description:
> >   - This check that only supported one pixel clock required clock rate
> >   compare with dts node value. but we have supports 4 pixel clock
> >   for ls1028a board.
> 
> So, your DT says your pixel clock provider is a fixed clock? If you support 
> more
> than one rate, you should instead use a real provider for it. How do you
> support the 4 pixel clocks?
> 
 
Yes , the DT node only can provided one pixel clock by using a fixed clock.
But we Display Port controller support 4 or more resolutions, each of which
requires a set of pixel clocks to drive, and we hope they can switch any 
resolution
we want by some program every times.

For example, if we set that fixed pixel clock is 2700 (27Mhz), but user 
hope can see
a group 1080p resolution penguins during startup , and hope playing a 4k video 
once
system boot up done. 
Btw, In our board, the 1080p resolution is driven by a 148.5Mhz pixel clock, 4k 
is driven
by a 594Mhz. 27Mhz only can drive 480p resolution.

To meet the above user requirements, I was to setup following steps,
1. Add the "video=1920x1080-32@60" to bootargs command line [specify penguins 
size]
2. Play a 4K video with 4k resolution when system boot up done.

> Also, not sure what the paragraph above is meant to be. Should it be part of
> the commit message?
> 

These comments just want to let you know.

> Best regards,
> Liviu
> 
> 
> >  drivers/gpu/drm/arm/malidp_crtc.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> > b/drivers/gpu/drm/arm/malidp_crtc.c
> > index 56aad288666e..bb79223d9981 100644
> > --- a/drivers/gpu/drm/arm/malidp_crtc.c
> > +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> > @@ -36,11 +36,13 @@ static enum drm_mode_status
> > malidp_crtc_mode_valid(struct drm_crtc *crtc,
> >

According to our pixel configuration above,
Now the variable req_rate value is 14850 or 5940, another variable rate 
value is
2700, so we will get a warning and display will cannot works well. 

We're not sure which resolution are user want, and we also can't just offered 
one resolution
to user. so I remove this check on our board, maybe it's not good change.

I want to know do you have other good suggestion? Thanks.

Best Regards,
Wen

> >   if (req_rate) {
> >   rate = clk_round_rate(hwdev->pxlclk, req_rate);
> > +#ifndef CONFIG_ARCH_LAYERSCAPE
> >   if (rate != req_rate) {
> >   DRM_DEBUG_DRIVER("pxlclk doesn't support %ld
> Hz\n",
> >req_rate);
> >   return MODE_NOCLOCK;
> >   }
> > +#endif
> >   }
> >
> >   return MODE_OK;
> > --
> > 2.17.1
> >
> 
> --
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯


[v1] drm/arm/mali-dp: Disable checking for required pixel clock rate

2019-05-14 Thread Wen He
Disable checking for required pixel clock rate if ARCH_LAYERSCPAE
is enable.

Signed-off-by: Alison Wang 
Signed-off-by: Wen He 
---
change in description:
- This check that only supported one pixel clock required clock rate
compare with dts node value. but we have supports 4 pixel clock
for ls1028a board.
 drivers/gpu/drm/arm/malidp_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 56aad288666e..bb79223d9981 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -36,11 +36,13 @@ static enum drm_mode_status malidp_crtc_mode_valid(struct 
drm_crtc *crtc,
 
if (req_rate) {
rate = clk_round_rate(hwdev->pxlclk, req_rate);
+#ifndef CONFIG_ARCH_LAYERSCAPE
if (rate != req_rate) {
DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
 req_rate);
return MODE_NOCLOCK;
}
+#endif
}
 
return MODE_OK;
-- 
2.17.1



RE: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE

2019-05-09 Thread Wen He


> -Original Message-
> From: Wen He
> Sent: 2019年5月8日 17:42
> To: dri-devel@lists.freedesktop.org; p.za...@pengutronix.de
> Cc: Leo Li ; Wen He 
> Subject: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE
> 
> The new LS1028A DP driver code causes a link failure when DRM_IMX built-in,
> but platform is ARCH_LAYERSCAPE:
> 
> drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to `ipu_prg_enable'
> drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to `ipu_dc_enable'
> drivers/gpu/drm/imx/ipuv3-crtc.c:53: undefined reference to
> `ipu_dc_enable_channel'
> drivers/gpu/drm/imx/ipuv3-crtc.c:54: undefined reference to `ipu_di_enable'
> drivers/gpu/drm/imx/ipuv3-crtc.o: In function `ipu_crtc_mode_set_nofb
> 
> Adding a Kconfig dependency allow to build if ARCH_LAYERSCAPE is enable.
> 
> Signed-off-by: Wen He 
> ---
>  drivers/gpu/ipu-v3/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig index
> fe6f8c5b4445..51ea88c440df 100644
> --- a/drivers/gpu/ipu-v3/Kconfig
> +++ b/drivers/gpu/ipu-v3/Kconfig
> @@ -1,6 +1,6 @@
>  config IMX_IPUV3_CORE
>   tristate "IPUv3 core support"
> - depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM ||
> COMPILE_TEST
> + depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM ||
> COMPILE_TEST
> +|| ARCH_LAYERSCAPE
>   depends on DRM || !DRM # if DRM=m, this can't be 'y'
>   select BITREVERSE
>   select GENERIC_ALLOCATOR if DRM
> --
> 2.17.1

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

[v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE

2019-05-09 Thread Wen He
The new LS1028A DP driver code causes a link failure when DRM_IMX built-in,
but platform is ARCH_LAYERSCAPE:

drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to `ipu_prg_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to `ipu_dc_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:53: undefined reference to 
`ipu_dc_enable_channel'
drivers/gpu/drm/imx/ipuv3-crtc.c:54: undefined reference to `ipu_di_enable'
drivers/gpu/drm/imx/ipuv3-crtc.o: In function `ipu_crtc_mode_set_nofb

Adding a Kconfig dependency allow to build if ARCH_LAYERSCAPE is enable.

Signed-off-by: Wen He 
---
 drivers/gpu/ipu-v3/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index fe6f8c5b4445..51ea88c440df 100644
--- a/drivers/gpu/ipu-v3/Kconfig
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -1,6 +1,6 @@
 config IMX_IPUV3_CORE
tristate "IPUv3 core support"
-   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || COMPILE_TEST
+   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || COMPILE_TEST 
|| ARCH_LAYERSCAPE
depends on DRM || !DRM # if DRM=m, this can't be 'y'
select BITREVERSE
select GENERIC_ALLOCATOR if DRM
-- 
2.17.1

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

[v1] drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times

2019-05-09 Thread Wen He
This patch trying to fix monitor freeze issue caused by drm error
'flip_done timed out' on LS1028A platform. this set try is make a loop
around the second setting CVAL and try like 5 times before giveing up.

Signed-off-by: Liviu 
Signed-off-by: Wen He 
---
 drivers/gpu/drm/arm/malidp_drv.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 21725c9b9f5e..18cb7f134f4e 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -192,6 +192,7 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
 {
struct drm_device *drm = state->dev;
struct malidp_drm *malidp = drm->dev_private;
+   int loop = 5;
 
malidp->event = malidp->crtc.state->event;
malidp->crtc.state->event = NULL;
@@ -206,8 +207,18 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
drm_crtc_vblank_get(>crtc);
 
/* only set config_valid if the CRTC is enabled */
-   if (malidp_set_and_wait_config_valid(drm) < 0)
+   if (malidp_set_and_wait_config_valid(drm) < 0) {
+   /*
+* make a loop around the second CVAL setting and
+* try 5 times before giving up.
+*/
+   while (loop--) {
+   if (!malidp_set_and_wait_config_valid(drm))
+   break;
+   }
DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
+   }
+
} else if (malidp->event) {
/* CRTC inactive means vblank IRQ is disabled, send event 
directly */
spin_lock_irq(>event_lock);
-- 
2.17.1

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

[v1] drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times

2019-05-09 Thread Wen He
This patch trying to fix monitor freeze issue caused by drm error
'flip_done timed out' on LS1028A platform. this set try is make a loop
around the second setting CVAL and try like 5 times before giveing up.

Signed-off-by: Liviu 
Signed-off-by: Wen He 
---
 drivers/gpu/drm/arm/malidp_drv.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 21725c9b9f5e..18cb7f134f4e 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -192,6 +192,7 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
 {
struct drm_device *drm = state->dev;
struct malidp_drm *malidp = drm->dev_private;
+   int loop = 5;
 
malidp->event = malidp->crtc.state->event;
malidp->crtc.state->event = NULL;
@@ -206,8 +207,18 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
drm_crtc_vblank_get(>crtc);
 
/* only set config_valid if the CRTC is enabled */
-   if (malidp_set_and_wait_config_valid(drm) < 0)
+   if (malidp_set_and_wait_config_valid(drm) < 0) {
+   /*
+* make a loop around the second CVAL setting and
+* try 5 times before giving up.
+*/
+   while (loop--) {
+   if (!malidp_set_and_wait_config_valid(drm))
+   break;
+   }
DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
+   }
+
} else if (malidp->event) {
/* CRTC inactive means vblank IRQ is disabled, send event 
directly */
spin_lock_irq(>event_lock);
-- 
2.17.1

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

RE: [v1] drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times

2019-05-09 Thread Wen He


> -Original Message-
> From: Wen He
> Sent: 2019年5月8日 17:39
> To: dri-devel@lists.freedesktop.org; liviu.du...@arm.com;
> brian.star...@arm.com
> Cc: Leo Li ; Wen He 
> Subject: [v1] drm/arm/mali-dp: Add a loop around the second set CVAL and try
> 5 times
> 
> This patch trying to fix monitor freeze issue caused by drm error 'flip_done
> timed out' on LS1028A platform. this set try is make a loop around the second
> setting CVAL and try like 5 times before giveing up.
> 
> Signed-off-by: Liviu 
> Signed-off-by: Wen He 
> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 21725c9b9f5e..18cb7f134f4e 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -192,6 +192,7 @@ static void malidp_atomic_commit_hw_done(struct
> drm_atomic_state *state)  {
>   struct drm_device *drm = state->dev;
>   struct malidp_drm *malidp = drm->dev_private;
> + int loop = 5;
> 
>   malidp->event = malidp->crtc.state->event;
>   malidp->crtc.state->event = NULL;
> @@ -206,8 +207,18 @@ static void malidp_atomic_commit_hw_done(struct
> drm_atomic_state *state)
>   drm_crtc_vblank_get(>crtc);
> 
>   /* only set config_valid if the CRTC is enabled */
> - if (malidp_set_and_wait_config_valid(drm) < 0)
> + if (malidp_set_and_wait_config_valid(drm) < 0) {
> + /*
> +  * make a loop around the second CVAL setting and
> +  * try 5 times before giving up.
> +  */
> + while (loop--) {
> + if (!malidp_set_and_wait_config_valid(drm))
> + break;
> + }
>   DRM_DEBUG_DRIVER("timed out waiting for updated
> configuration\n");
> + }
> +
>   } else if (malidp->event) {
>   /* CRTC inactive means vblank IRQ is disabled, send event 
> directly */
>   spin_lock_irq(>event_lock);
> --
> 2.17.1

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

[v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE

2019-05-09 Thread Wen He
The new LS1028A DP driver code causes a link failure when DRM_IMX built-in,
but platform is ARCH_LAYERSCAPE:

drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to `ipu_prg_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to `ipu_dc_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:53: undefined reference to 
`ipu_dc_enable_channel'
drivers/gpu/drm/imx/ipuv3-crtc.c:54: undefined reference to `ipu_di_enable'
drivers/gpu/drm/imx/ipuv3-crtc.o: In function `ipu_crtc_mode_set_nofb

Adding a Kconfig dependency allow to build if ARCH_LAYERSCAPE is enable.

Signed-off-by: Wen He 
---
 drivers/gpu/ipu-v3/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index fe6f8c5b4445..51ea88c440df 100644
--- a/drivers/gpu/ipu-v3/Kconfig
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -1,6 +1,6 @@
 config IMX_IPUV3_CORE
tristate "IPUv3 core support"
-   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || COMPILE_TEST
+   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || COMPILE_TEST 
|| ARCH_LAYERSCAPE
depends on DRM || !DRM # if DRM=m, this can't be 'y'
select BITREVERSE
select GENERIC_ALLOCATOR if DRM
-- 
2.17.1

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

RE: [PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k to avoid flicker issue

2019-03-29 Thread Wen He


> -Original Message-
> From: liviu.du...@arm.com [mailto:liviu.du...@arm.com]
> Sent: 2019年3月29日 0:39
> To: Wen He 
> Cc: brian.star...@arm.com; mal...@foss.arm.com;
> dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k to avoid
> flicker issue
> 
> Hi Wen,
> 
> On Thu, Mar 28, 2019 at 03:56:58AM +, Wen He wrote:
> > When we running DDR benchmark test will able to observed flicker issue
> > in 4k@60 resolution on monitor. In LS1028A SoC, need increasing DP500
> > priority to avoid that issue.
> >
> > Signed-off-by: Wen He 
> > ---
> >  drivers/gpu/drm/arm/malidp_hw.c   | 13 +
> >  drivers/gpu/drm/arm/malidp_regs.h |  8 
> >  2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c index 8df12e9a33bb..a5263488eb02
> > 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -378,6 +378,19 @@ static void malidp500_modeset(struct
> malidp_hw_device *hwdev, struct videomode *
> > malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> > else
> > malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > MALIDP_DE_DISPLAY_FUNC);
> > +
> > +#ifdef CONFIG_ARCH_LAYERSCAPE
> > +   /* Setting QoS for 4k resolution to avoid flicker issue */
> > +   if (mode->hactive == 3840
> > +   && mode->vactive == 2160)
> 
> I'm not keen on this check, it only enables this for one 3840x2160.
> What if the output is 2160x3840? Does it matter what pixel clock you use?
> Can the same issue be seen if (for example) you use 120Hz refresh rate but on
> a smaller output resolution?
> 

Hi liviu,

Let me clearly it.
Currently, we only supported four resolutions (480p@60, 720p@60, 1080@60, 
4k@60) for LS1028A Display port.
All of the refresh rate is 60MHz. so that impossible will be there resolution 
output's 2160x3840 and refresh rate is 120MHz.

> I think it's worth thinking this in terms of bandwidth and not hardcode for 
> one
> resolution.
> 

Yes, you are right. 
But only 4k resolution have the flicker issue, so this is a special problem. 
I think that hardcode is better than dynamically adjusting bandwidth.

> Also, I think setting the QoS bits should be a bit more generic, i.e if the
> modeset requires a certain bandwidth you should write a value read from a
> device tree, for example?
> 
> > +   malidp_hw_setbits(hwdev, GREEN_ARQOS_CONFIG
> > +   | RED_ARQOS_CONFIG, MALIDP500_RQOS_QUALITY);
> > +   else
> > +   malidp_hw_clearbits(hwdev, GREEN_ARQOS_CONFIG
> > +   | RED_ARQOS_CONFIG, MALIDP500_RQOS_QUALITY);
> > +
> > +   malidp_hw_setbits(hwdev, CONFIG_VALID, MALIDP500_CONFIG_VALID);
> 
> malidp500_modeset() will be called with MALIDP_CFG_VALID set anyway, so
> you should not need this. I don't know what bit 1 in
> MALIDP500_CONFIG_VALID does for LS1028A, I don't have that spec.
> 

About this, I got this step from our design team, So just to make sure the 
configuration works that 
writing value 0x3 to MALIDP500_CONFIG_VALID.

Is there can always to valid configuration? If yes, I can remove this line.

> 
> > +#endif
> >  }
> >
> >  int malidp_format_get_bpp(u32 fmt)
> > diff --git a/drivers/gpu/drm/arm/malidp_regs.h
> > b/drivers/gpu/drm/arm/malidp_regs.h
> > index a0dd6e1676a8..8dcf7e9f46ce 100644
> > --- a/drivers/gpu/drm/arm/malidp_regs.h
> > +++ b/drivers/gpu/drm/arm/malidp_regs.h
> > @@ -213,6 +213,14 @@
> >  #define MALIDP500_DC_IRQ_BASE  0x00f00
> >  #define MALIDP500_CONFIG_VALID 0x00f00
> >  #define MALIDP500_CONFIG_ID0x00fd4
> > +#ifdef CONFIG_ARCH_LAYERSCAPE
> > +#define MALIDP500_RQOS_QUALITY  0x00500
> > +/* Increasing QoS level signal */
> > +#define GREEN_ARQOS_CONFIG  (0xd << 28)
> > +/* Close to underflow QoS level signal */
> > +#define RED_ARQOS_CONFIG(0xd << 12)
> > +#define CONFIG_VALID0x3
> 
> What are these values? Is it something NXP has added to the DP500? If so, I
> think these should have some LAYERSCAPE (or LS) in their name. Also, rather
> than hardcoding the values, would it not be better to read them form device
> tree, to allow for fine tuning or variability between IP deployments?
> 
> Best regards,
> Liviu
> 

These values are QoS registers of DP500.
I have already put CONFIG_ARCH_LAYERSCAPE definition to specify architectu

[PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k to avoid flicker issue

2019-03-28 Thread Wen He
When we running DDR benchmark test will able to observed flicker issue
in 4k@60 resolution on monitor. In LS1028A SoC, need increasing DP500
priority to avoid that issue.

Signed-off-by: Wen He 
---
 drivers/gpu/drm/arm/malidp_hw.c   | 13 +
 drivers/gpu/drm/arm/malidp_regs.h |  8 
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 8df12e9a33bb..a5263488eb02 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -378,6 +378,19 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
else
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, 
MALIDP_DE_DISPLAY_FUNC);
+
+#ifdef CONFIG_ARCH_LAYERSCAPE
+   /* Setting QoS for 4k resolution to avoid flicker issue */
+   if (mode->hactive == 3840
+   && mode->vactive == 2160)
+   malidp_hw_setbits(hwdev, GREEN_ARQOS_CONFIG
+   | RED_ARQOS_CONFIG, MALIDP500_RQOS_QUALITY);
+   else
+   malidp_hw_clearbits(hwdev, GREEN_ARQOS_CONFIG
+   | RED_ARQOS_CONFIG, MALIDP500_RQOS_QUALITY);
+
+   malidp_hw_setbits(hwdev, CONFIG_VALID, MALIDP500_CONFIG_VALID);
+#endif
 }
 
 int malidp_format_get_bpp(u32 fmt)
diff --git a/drivers/gpu/drm/arm/malidp_regs.h 
b/drivers/gpu/drm/arm/malidp_regs.h
index a0dd6e1676a8..8dcf7e9f46ce 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -213,6 +213,14 @@
 #define MALIDP500_DC_IRQ_BASE  0x00f00
 #define MALIDP500_CONFIG_VALID 0x00f00
 #define MALIDP500_CONFIG_ID0x00fd4
+#ifdef CONFIG_ARCH_LAYERSCAPE
+#define MALIDP500_RQOS_QUALITY  0x00500
+/* Increasing QoS level signal */
+#define GREEN_ARQOS_CONFIG  (0xd << 28)
+/* Close to underflow QoS level signal */
+#define RED_ARQOS_CONFIG(0xd << 12)
+#define CONFIG_VALID0x3
+#endif
 
 /* register offsets and bits specific to DP550/DP650 */
 #define MALIDP550_ADDR_SPACE_SIZE  0x1
-- 
2.17.1

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