Re: [U-Boot] [PATCH 3/8] rockchip: video: Split out HDMI controller code

2017-03-09 Thread Nickey.Yang 

Hi Jernej,


在 2017年03月09日 07:34, Jernej Skrabec 写道:

Designware HDMI controller and phy are used in other SoCs as well. Split
out platform independent code.

DW HDMI has 8 bit registers but they can be represented as 32 bit
registers as well. Add support to select access mode.

EDID reading code use reading by blocks which is not supported by other
SoCs in general. Make it more general using byte by byte approach, which
is also used in Linux driver.

Finally, not all DW HDMI controllers are accompanied with DW HDMI phy.
Support custom phys by making controller code independent from phy code.

Signed-off-by: Jernej Skrabec 
---

I have tested this series of patches in rockchip rk3288 tinker boards.

Tested-by: Nickey Yang 

  arch/arm/include/asm/arch-rockchip/hdmi_rk3288.h | 456 --
  drivers/video/dw_hdmi.c  | 764 +++
  drivers/video/rockchip/Makefile  |   2 +-
  drivers/video/rockchip/rk_hdmi.c | 757 +-
  drivers/video/rockchip/rk_vop.c  |   1 -
  include/dw_hdmi.h| 486 ++
  6 files changed, 1275 insertions(+), 1191 deletions(-)
  delete mode 100644 arch/arm/include/asm/arch-rockchip/hdmi_rk3288.h
  create mode 100644 drivers/video/dw_hdmi.c
  create mode 100644 include/dw_hdmi.h

diff --git a/arch/arm/include/asm/arch-rockchip/hdmi_rk3288.h 
b/arch/arm/include/asm/arch-rockchip/hdmi_rk3288.h
deleted file mode 100644
index 0b51d40882..00
--- a/arch/arm/include/asm/arch-rockchip/hdmi_rk3288.h
+++ /dev/null
@@ -1,456 +0,0 @@
-/*
- * Copyright (c) 2015 Google, Inc
- * Copyright 2014 Rockchip Inc.
- * Copyright (C) 2011 Freescale Semiconductor, Inc.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef _ASM_ARCH_HDMI_H
-#define _ASM_ARCH_HDMI_H
-
-
-#define HDMI_EDID_BLOCK_SIZE128
-
-struct rk3288_hdmi {
-   u32 reserved0[0x100];
-   u32 ih_fc_stat0;
-   u32 ih_fc_stat1;
-   u32 ih_fc_stat2;
-   u32 ih_as_stat0;
-   u32 ih_phy_stat0;
-   u32 ih_i2cm_stat0;
-   u32 ih_cec_stat0;
-   u32 ih_vp_stat0;
-   u32 ih_i2cmphy_stat0;
-   u32 ih_ahbdmaaud_stat0;
-   u32 reserved1[0x17f-0x109];
-   u32 ih_mute_fc_stat0;
-   u32 ih_mute_fc_stat1;
-   u32 ih_mute_fc_stat2;
-   u32 ih_mute_as_stat0;
-   u32 ih_mute_phy_stat0;
-   u32 ih_mute_i2cm_stat0;
-   u32 ih_mute_cec_stat0;
-   u32 ih_mute_vp_stat0;
-   u32 ih_mute_i2cmphy_stat0;
-   u32 ih_mute_ahbdmaaud_stat0;
-   u32 reserved2[0x1fe - 0x189];
-   u32 ih_mute;
-   u32 tx_invid0;
-   u32 tx_instuffing;
-   u32 tx_gydata0;
-   u32 tx_gydata1;
-   u32 tx_rcrdata0;
-   u32 tx_rcrdata1;
-   u32 tx_bcbdata0;
-   u32 tx_bcbdata1;
-   u32 reserved3[0x7ff-0x207];
-   u32 vp_status;
-   u32 vp_pr_cd;
-   u32 vp_stuff;
-   u32 vp_remap;
-   u32 vp_conf;
-   u32 vp_stat;
-   u32 vp_int;
-   u32 vp_mask;
-   u32 vp_pol;
-   u32 reserved4[0xfff-0x808];
-   u32 fc_invidconf;
-   u32 fc_inhactv0;
-   u32 fc_inhactv1;
-   u32 fc_inhblank0;
-   u32 fc_inhblank1;
-   u32 fc_invactv0;
-   u32 fc_invactv1;
-   u32 fc_invblank;
-   u32 fc_hsyncindelay0;
-   u32 fc_hsyncindelay1;
-   u32 fc_hsyncinwidth0;
-   u32 fc_hsyncinwidth1;
-   u32 fc_vsyncindelay;
-   u32 fc_vsyncinwidth;
-   u32 fc_infreq0;
-   u32 fc_infreq1;
-   u32 fc_infreq2;
-   u32 fc_ctrldur;
-   u32 fc_exctrldur;
-   u32 fc_exctrlspac;
-   u32 fc_ch0pream;
-   u32 fc_ch1pream;
-   u32 fc_ch2pream;
-   u32 fc_aviconf3;
-   u32 fc_gcp;
-   u32 fc_aviconf0;
-   u32 fc_aviconf1;
-   u32 fc_aviconf2;
-   u32 fc_avivid;
-   u32 fc_avietb0;
-   u32 fc_avietb1;
-   u32 fc_avisbb0;
-   u32 fc_avisbb1;
-   u32 fc_avielb0;
-   u32 fc_avielb1;
-   u32 fc_avisrb0;
-   u32 fc_avisrb1;
-   u32 fc_audiconf0;
-   u32 fc_audiconf1;
-   u32 fc_audiconf2;
-   u32 fc_audiconf3;
-   u32 fc_vsdieeeid0;
-   u32 fc_vsdsize;
-   u32 reserved7[0x2fff-0x102a];
-   u32 phy_conf0;
-   u32 phy_tst0;
-   u32 phy_tst1;
-   u32 phy_tst2;
-   u32 phy_stat0;
-   u32 phy_int0;
-   u32 phy_mask0;
-   u32 phy_pol0;
-   u32 reserved8[0x301f-0x3007];
-   u32 phy_i2cm_slave_addr;
-   u32 phy_i2cm_address_addr;
-   u32 phy_i2cm_datao_1_addr;
-   u32 phy_i2cm_datao_0_addr;
-   u32 phy_i2cm_datai_1_addr;
-   u32 phy_i2cm_datai_0_addr;
-   u32 phy_i2cm_operation_addr;
-   u32 phy_i2cm_int_addr;
-   u32 phy_i2cm_ctlint_addr;
-   u32 phy_i2cm_div_addr;
-   u32 phy_i2cm_softrstz_addr;
-   u32 phy_i2cm_ss_scl_hcnt_1_addr;
-   u32 phy_i2cm_ss_scl_hcnt_0_addr;
-   u32

Re: [U-Boot] [PATCH] rockchip: video: fix mpixelclock in rockchip HDMI

2017-02-27 Thread Nickey.Yang 

Hi Simon,

在 2017年02月24日 00:19, Simon Glass 写道:

Hi Nickey,

On 22 February 2017 at 23:56, Nickey.Yang <nickey.y...@rock-chips.com> wrote:

Hi Simon,



在 2017年02月23日 11:52, Simon Glass 写道:

Hi,

On 11 January 2017 at 22:08, Simon Glass <s...@chromium.org> wrote:

On 28 December 2016 at 23:01, Nickey Yang <nickey.y...@rock-chips.com>
wrote:

Correct mpixelclock errors in rockchip_phy_config[] and
rockchip_mpll_cfg[].

Signed-off-by: Nickey Yang <nickey.y...@rock-chips.com>
---
   drivers/video/rockchip/rk_hdmi.c | 20 ++--
   1 file changed, 10 insertions(+), 10 deletions(-)

Applied to u-boot-rockchip, thanks!

I only just noticed, but this patch breaks HDMI output on firefly. Can
you please take a look? What does this patch actually fix?

Regards,
Simon


  You can add

 printf("---YYS  mpll.cpce = %x \n",rockchip_mpll_cfg[i].cpce);
 printf("---YYS  mpll.gmp = %x \n",rockchip_mpll_cfg[i].gmp);
 printf("---YYS  mpll.curr = %x \n",rockchip_mpll_cfg[i].curr);

in  hdmi_phy_configure(rk_hdmi.c   line 409), all of those value will be 0
without this patch.
We want to get those different value by near clock settings between
rockchip_mpll_cfg[] in fact.

Yes it makes sense


by the way,HDMI output on firefly will work well when reset this patch?

Yes it works when I revert.

Regards,
Simon





I am sorry for my mistake.
There is one "0" too many in 8350 mpixelclock in rockchip_mpll_cfg[].
I have send new patch  rockchip: video: fix 8350 clock mistake in 
rockchip HDMI to fix it.


Regards,
Nickey




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: video: fix mpixelclock in rockchip HDMI

2017-02-22 Thread Nickey.Yang 

Hi Simon,


在 2017年02月23日 11:52, Simon Glass 写道:

Hi,

On 11 January 2017 at 22:08, Simon Glass  wrote:

On 28 December 2016 at 23:01, Nickey Yang  wrote:

Correct mpixelclock errors in rockchip_phy_config[] and rockchip_mpll_cfg[].

Signed-off-by: Nickey Yang 
---
  drivers/video/rockchip/rk_hdmi.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

Applied to u-boot-rockchip, thanks!

I only just noticed, but this patch breaks HDMI output on firefly. Can
you please take a look? What does this patch actually fix?

Regards,
Simon


 You can add

printf("---YYS  mpll.cpce = %x \n",rockchip_mpll_cfg[i].cpce);
printf("---YYS  mpll.gmp = %x \n",rockchip_mpll_cfg[i].gmp);
printf("---YYS  mpll.curr = %x \n",rockchip_mpll_cfg[i].curr);

in  hdmi_phy_configure(rk_hdmi.c   line 409), all of those value will be 
0 without this patch.
We want to get those different value by near clock settings between 
rockchip_mpll_cfg[] in fact.


by the way,HDMI output on firefly will work well when reset this patch?






___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] miniarm-rk3288: set isp/vop qos priority level

2016-12-14 Thread Nickey.Yang 

Hi Kever & Simon,


在 2016年12月14日 15:07, Kever Yang 写道:

Hi Simon,

On 12/12/2016 04:27 AM, Simon Glass wrote:

Hi Nickey,

On 8 December 2016 at 21:39, Nickey Yang  
wrote:

isp-camera image will be broken when enter dual screen display mode.
We set isp qos high to solve this problem.

Signed-off-by: Nickey Yang 
---
  arch/arm/include/asm/arch-rockchip/qos_rk3288.h | 21 
+
  board/rockchip/miniarm_rk3288/miniarm-rk3288.c  | 21 
+

  2 files changed, 42 insertions(+)
  create mode 100644 arch/arm/include/asm/arch-rockchip/qos_rk3288.h

diff --git a/arch/arm/include/asm/arch-rockchip/qos_rk3288.h 
b/arch/arm/include/asm/arch-rockchip/qos_rk3288.h

new file mode 100644
index 000..d3d6c3e
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/qos_rk3288.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2016 Rockchip Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#ifndef _ASM_ARCH_QOS_RK3288_H
+#define _ASM_ARCH_QOS_RK3288_H
+
+/* cpu axi qos priority */
+#define CPU_AXI_QOS_PRIORITY_LEVEL(h, l) \
+   h) & 3) << 2) | ((l) & 3))

Can you instead define

XXX_SHIFT   2
XXX_MASK  (3 << XXX_SHIFT)

and then use these in the .c code?


+
+#define CPU_AXI_QOS_PRIORITY0x08
+
+#define VIO0_VOP_QOS0xffad0400
+#define VIO1_VOP_QOS0xffad
+#define VIO1_ISP_R_QOS  0xffad0900
+#define VIO1_ISP_W0_QOS 0xffad0100
+#define VIO1_ISP_W1_QOS 0xffad0180
+
+#endif
diff --git a/board/rockchip/miniarm_rk3288/miniarm-rk3288.c 
b/board/rockchip/miniarm_rk3288/miniarm-rk3288.c

index 79541a3..ba0f3a3 100644
--- a/board/rockchip/miniarm_rk3288/miniarm-rk3288.c
+++ b/board/rockchip/miniarm_rk3288/miniarm-rk3288.c
@@ -5,3 +5,24 @@
   */

  #include 
+#include 
+#include 
+
+int rk_board_late_init(void)
+{
+   /* set isp qos to higher priority */
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_R_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_W0_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_W1_QOS + CPU_AXI_QOS_PRIORITY);
+
+   /* set vop qos to higher priority */
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO0_VOP_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_VOP_QOS + CPU_AXI_QOS_PRIORITY);
Can you add a register struct for this in 
arch/arm/include/asm/arch-rockchip/ ?


Also I think it would be best to put this code somewhere in
arch/arm/mach-rockchip and call it from your late init routine.


I understand people don't like source cod in hardcode(or nearly) and 
out of

any framwork, but there do have some different one time init program for
different SoC or board, I think it's OK to add then in soc_init() or 
board_init()

with appropriate comment.

Back to the case here, setting the ISP NOC niu to higher priority is 
only needed
for the miniarm board for the use case in that board. It might have 
other requirement
for other board for different use cases, so it's OK to add the code in 
board file.
I think you would like to have some API function for this setting then 
different board can use it

instead of do SoC setting in board file, right?
Before other board need this blob of code, would it be more clear to 
put the code in board file?



or in arch/arm/mach-rockchip/rk3288-board.c
+__weak int rk_qos_init(void)
+{
+/* do  set  vop  qos level  */
+   }

int board_late_init(void)
 {
setup_boot_mode();
+   rk_qos_init();

}

in board/rockchip/miniarm_rk3288/miniarm-rk3288.c
+int rk_qos_init(void)
+{
+/* do  set vop  qos level  */
+/* do  set isp qos level  */
+}

Whether this is  a better way?

@Nickey, I'm sure the patch V3 is not what we need. Simon's suggestion 
could be detail in this:

- add a rk3288_qos_init() in arch/arm/mach-rockchip/rk3288-board.c
- call the rk3288_qos_init() in rk_board_late_init() of 
board/rockchip/miniarm_rk3288/miniarm-rk3288.c


Thanks,
- Kever



+
+   return 0;
+}
--
1.9.1



Regards,
Simon











___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot