RE: [PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547

2017-01-02 Thread Meng Yi


> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Monday, January 02, 2017 5:17 PM
> To: Meng Yi <meng...@nxp.com>
> Cc: robh...@kernel.org; Stuart Yoder <stuart.yo...@nxp.com>; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547
> 
> On Tue, Dec 20, 2016 at 02:03:07PM +0800, Meng Yi wrote:
> > pca9547 won't probed since its status property is disabled.
> > while there are devices connected to it, we need remove status
> > property to let ds3232 and adt7461 probed correctly.
> >
> > Signed-off-by: Meng Yi <meng...@nxp.com>
> 
> Changed subject prefix to 'arm64: dts: ls2080a-rdb: ', and applied the patch.
> 
> Shawn

Thanks!

Meng


RE: [PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547

2017-01-02 Thread Meng Yi


> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Monday, January 02, 2017 5:17 PM
> To: Meng Yi 
> Cc: robh...@kernel.org; Stuart Yoder ; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547
> 
> On Tue, Dec 20, 2016 at 02:03:07PM +0800, Meng Yi wrote:
> > pca9547 won't probed since its status property is disabled.
> > while there are devices connected to it, we need remove status
> > property to let ds3232 and adt7461 probed correctly.
> >
> > Signed-off-by: Meng Yi 
> 
> Changed subject prefix to 'arm64: dts: ls2080a-rdb: ', and applied the patch.
> 
> Shawn

Thanks!

Meng


[PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547

2016-12-19 Thread Meng Yi
pca9547 won't probed since its status property is disabled.
while there are devices connected to it, we need remove status
property to let ds3232 and adt7461 probed correctly.

Signed-off-by: Meng Yi <meng...@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
index 265e0a8..2ff46ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
@@ -102,7 +102,6 @@
reg = <0x75>;
#address-cells = <1>;
#size-cells = <0>;
-   status = "disabled";
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.1.0.27.g96db324



[PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547

2016-12-19 Thread Meng Yi
pca9547 won't probed since its status property is disabled.
while there are devices connected to it, we need remove status
property to let ds3232 and adt7461 probed correctly.

Signed-off-by: Meng Yi 
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
index 265e0a8..2ff46ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
@@ -102,7 +102,6 @@
reg = <0x75>;
#address-cells = <1>;
#size-cells = <0>;
-   status = "disabled";
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.1.0.27.g96db324



RE: [RFC PATCH] rtc/nxp: add FTM alarm driver as the wakeup source

2016-12-01 Thread Meng Yi
> > > +
> > > +static int nxp_ftm_rtc_read_time(struct device *dev, struct
> > > +rtc_time
> > > +*tm) {
> > > + struct timeval time;
> > > + unsigned long local_time;
> > > +
> > > + do_gettimeofday();
> > > + local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> > > + rtc_time_to_tm(local_time, tm);
> > > +
> > > + return 0;
> > > +}
> > > +
> >
> > This is not really getting time from the RTC since FTM is not a RTC
> > device, But we need to get the time to setup alarm, so we are using system
> time for now.
> > Anybody have better idea?
> >
> 
> No, that seems fine to me. I'll review the rest of the driver.

Thanks for your review, any feedback is welcomed!

> 
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Meng


RE: [RFC PATCH] rtc/nxp: add FTM alarm driver as the wakeup source

2016-12-01 Thread Meng Yi
> > > +
> > > +static int nxp_ftm_rtc_read_time(struct device *dev, struct
> > > +rtc_time
> > > +*tm) {
> > > + struct timeval time;
> > > + unsigned long local_time;
> > > +
> > > + do_gettimeofday();
> > > + local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> > > + rtc_time_to_tm(local_time, tm);
> > > +
> > > + return 0;
> > > +}
> > > +
> >
> > This is not really getting time from the RTC since FTM is not a RTC
> > device, But we need to get the time to setup alarm, so we are using system
> time for now.
> > Anybody have better idea?
> >
> 
> No, that seems fine to me. I'll review the rest of the driver.

Thanks for your review, any feedback is welcomed!

> 
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Meng


[PATCH] nxp/diu: enable diu support for t1042 platform

2016-11-25 Thread Meng Yi
From: Jason Jin <jason@nxp.com>

This patch add the DIU support for t1042 platform.
signed-off-by: Jason Jin <jason@nxp.com> [Meng Yi: Made file 
t1042rdb-specific]
Signed-off-by: Meng Yi <meng...@nxp.com>
---
 arch/powerpc/platforms/85xx/Makefile   |   1 +
 arch/powerpc/platforms/85xx/t1042rdb_diu.c | 152 +
 2 files changed, 153 insertions(+)
 create mode 100644 arch/powerpc/platforms/85xx/t1042rdb_diu.c

diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 7bc86da..fe19dad 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_P1022_RDK)   += p1022_rdk.o
 obj-$(CONFIG_P1023_RDB)   += p1023_rdb.o
 obj-$(CONFIG_TWR_P102x)   += twr_p102x.o
 obj-$(CONFIG_CORENET_GENERIC)   += corenet_generic.o
+obj-$(CONFIG_FB_FSL_DIU)   += t1042rdb_diu.o
 obj-$(CONFIG_STX_GP3)+= stx_gp3.o
 obj-$(CONFIG_TQM85xx)+= tqm85xx.o
 obj-$(CONFIG_SBC8548) += sbc8548.o
diff --git a/arch/powerpc/platforms/85xx/t1042rdb_diu.c 
b/arch/powerpc/platforms/85xx/t1042rdb_diu.c
new file mode 100644
index 000..58fa3d3
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/t1042rdb_diu.c
@@ -0,0 +1,152 @@
+/*
+ * T1042 platform DIU operation
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*DIU Pixel ClockCR offset in scfg*/
+#define CCSR_SCFG_PIXCLKCR  0x28
+
+/* DIU Pixel Clock bits of the PIXCLKCR */
+#define PIXCLKCR_PXCKEN0x8000
+#define PIXCLKCR_PXCKINV   0x4000
+#define PIXCLKCR_PXCKDLY   0xFF00
+#define PIXCLKCR_PXCLK_MASK0x00FF
+
+/* Some CPLD register definitions */
+#define CPLD_DIUCSR0x16
+#define CPLD_DIUCSR_DVIEN  0x80
+#define CPLD_DIUCSR_BACKLIGHT  0x0f
+
+struct device_node *cpld_node;
+
+/**
+ * t1042rdb_set_monitor_port: switch the output to a different monitor port
+ */
+static void t1042rdb_set_monitor_port(enum fsl_diu_monitor_port port)
+{
+   static void __iomem *cpld_base;
+
+   cpld_base = of_iomap(cpld_node, 0);
+   if (!cpld_base) {
+   pr_err("%s: Could not map cpld registers\n", __func__);
+   goto exit;
+   }
+
+   switch (port) {
+   case FSL_DIU_PORT_DVI:
+   /* Enable the DVI(HDMI) port, disable the DFP and
+* the backlight
+*/
+   clrbits8(cpld_base + CPLD_DIUCSR, CPLD_DIUCSR_DVIEN);
+   break;
+   case FSL_DIU_PORT_LVDS:
+   /*
+* LVDS also needs backlight enabled, otherwise the display
+* will be blank.
+*/
+   /* Enable the DFP port, disable the DVI*/
+   setbits8(cpld_base + CPLD_DIUCSR, 0x01 << 8);
+   setbits8(cpld_base + CPLD_DIUCSR, 0x01 << 4);
+   setbits8(cpld_base + CPLD_DIUCSR, CPLD_DIUCSR_BACKLIGHT);
+   break;
+   default:
+   pr_err("%s: Unsupported monitor port %i\n", __func__, port);
+   }
+
+   iounmap(cpld_base);
+exit:
+   of_node_put(cpld_node);
+}
+
+/**
+ * t1042rdb_set_pixel_clock: program the DIU's clock
+ * @pixclock: pixel clock in ps (pico seconds)
+ */
+static void t1042rdb_set_pixel_clock(unsigned int pixclock)
+{
+   struct device_node *scfg_np;
+   void __iomem *scfg;
+   unsigned long freq;
+   u64 temp;
+   u32 pxclk;
+
+   scfg_np = of_find_compatible_node(NULL, NULL, "fsl,t1040-scfg");
+   if (!scfg_np) {
+   pr_err("%s: Missing scfg node. Can not display video.\n",
+  __func__);
+   return;
+   }
+
+   scfg = of_iomap(scfg_np, 0);
+   of_node_put(scfg_np);
+   if (!scfg) {
+   pr_err("%s: Could not map device. Can not display video.\n",
+  __func__);
+   return;
+   }
+
+   /* Convert pixclock into frequency */
+   temp = 1ULL;
+   do_div(temp, pixclock);
+   freq = temp;
+
+   /*
+* 'pxclk' is the ratio of the platform clock to the pixel clock.
+* This number is programmed into the PIXCLKCR register, and the valid
+* range of values is 2-255.
+*/
+   pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+   pxclk = clamp_t(u32, pxclk, 2, 255);
+
+   /* Disable the pixel clock, and set it to non-inverted and no delay */
+   clrbits32(scfg + CCSR_SCFG_PIXCLKCR,
+ PIXCLKCR_PXCKEN | PIXCLKCR_PXCKDLY | PIXCLKCR_PXCLK_MASK);
+
+   /* Enable the clock a

[PATCH] nxp/diu: enable diu support for t1042 platform

2016-11-25 Thread Meng Yi
From: Jason Jin 

This patch add the DIU support for t1042 platform.
signed-off-by: Jason Jin  [Meng Yi: Made file 
t1042rdb-specific]
Signed-off-by: Meng Yi 
---
 arch/powerpc/platforms/85xx/Makefile   |   1 +
 arch/powerpc/platforms/85xx/t1042rdb_diu.c | 152 +
 2 files changed, 153 insertions(+)
 create mode 100644 arch/powerpc/platforms/85xx/t1042rdb_diu.c

diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 7bc86da..fe19dad 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_P1022_RDK)   += p1022_rdk.o
 obj-$(CONFIG_P1023_RDB)   += p1023_rdb.o
 obj-$(CONFIG_TWR_P102x)   += twr_p102x.o
 obj-$(CONFIG_CORENET_GENERIC)   += corenet_generic.o
+obj-$(CONFIG_FB_FSL_DIU)   += t1042rdb_diu.o
 obj-$(CONFIG_STX_GP3)+= stx_gp3.o
 obj-$(CONFIG_TQM85xx)+= tqm85xx.o
 obj-$(CONFIG_SBC8548) += sbc8548.o
diff --git a/arch/powerpc/platforms/85xx/t1042rdb_diu.c 
b/arch/powerpc/platforms/85xx/t1042rdb_diu.c
new file mode 100644
index 000..58fa3d3
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/t1042rdb_diu.c
@@ -0,0 +1,152 @@
+/*
+ * T1042 platform DIU operation
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*DIU Pixel ClockCR offset in scfg*/
+#define CCSR_SCFG_PIXCLKCR  0x28
+
+/* DIU Pixel Clock bits of the PIXCLKCR */
+#define PIXCLKCR_PXCKEN0x8000
+#define PIXCLKCR_PXCKINV   0x4000
+#define PIXCLKCR_PXCKDLY   0xFF00
+#define PIXCLKCR_PXCLK_MASK0x00FF
+
+/* Some CPLD register definitions */
+#define CPLD_DIUCSR0x16
+#define CPLD_DIUCSR_DVIEN  0x80
+#define CPLD_DIUCSR_BACKLIGHT  0x0f
+
+struct device_node *cpld_node;
+
+/**
+ * t1042rdb_set_monitor_port: switch the output to a different monitor port
+ */
+static void t1042rdb_set_monitor_port(enum fsl_diu_monitor_port port)
+{
+   static void __iomem *cpld_base;
+
+   cpld_base = of_iomap(cpld_node, 0);
+   if (!cpld_base) {
+   pr_err("%s: Could not map cpld registers\n", __func__);
+   goto exit;
+   }
+
+   switch (port) {
+   case FSL_DIU_PORT_DVI:
+   /* Enable the DVI(HDMI) port, disable the DFP and
+* the backlight
+*/
+   clrbits8(cpld_base + CPLD_DIUCSR, CPLD_DIUCSR_DVIEN);
+   break;
+   case FSL_DIU_PORT_LVDS:
+   /*
+* LVDS also needs backlight enabled, otherwise the display
+* will be blank.
+*/
+   /* Enable the DFP port, disable the DVI*/
+   setbits8(cpld_base + CPLD_DIUCSR, 0x01 << 8);
+   setbits8(cpld_base + CPLD_DIUCSR, 0x01 << 4);
+   setbits8(cpld_base + CPLD_DIUCSR, CPLD_DIUCSR_BACKLIGHT);
+   break;
+   default:
+   pr_err("%s: Unsupported monitor port %i\n", __func__, port);
+   }
+
+   iounmap(cpld_base);
+exit:
+   of_node_put(cpld_node);
+}
+
+/**
+ * t1042rdb_set_pixel_clock: program the DIU's clock
+ * @pixclock: pixel clock in ps (pico seconds)
+ */
+static void t1042rdb_set_pixel_clock(unsigned int pixclock)
+{
+   struct device_node *scfg_np;
+   void __iomem *scfg;
+   unsigned long freq;
+   u64 temp;
+   u32 pxclk;
+
+   scfg_np = of_find_compatible_node(NULL, NULL, "fsl,t1040-scfg");
+   if (!scfg_np) {
+   pr_err("%s: Missing scfg node. Can not display video.\n",
+  __func__);
+   return;
+   }
+
+   scfg = of_iomap(scfg_np, 0);
+   of_node_put(scfg_np);
+   if (!scfg) {
+   pr_err("%s: Could not map device. Can not display video.\n",
+  __func__);
+   return;
+   }
+
+   /* Convert pixclock into frequency */
+   temp = 1ULL;
+   do_div(temp, pixclock);
+   freq = temp;
+
+   /*
+* 'pxclk' is the ratio of the platform clock to the pixel clock.
+* This number is programmed into the PIXCLKCR register, and the valid
+* range of values is 2-255.
+*/
+   pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+   pxclk = clamp_t(u32, pxclk, 2, 255);
+
+   /* Disable the pixel clock, and set it to non-inverted and no delay */
+   clrbits32(scfg + CCSR_SCFG_PIXCLKCR,
+ PIXCLKCR_PXCKEN | PIXCLKCR_PXCKDLY | PIXCLKCR_PXCLK_MASK);
+
+   /* Enable the clock and set the pxclk */
+   setbits32(scfg + CCSR_SCFG_PIXC

RE: [RFC PATCH] rtc/nxp: add FTM alarm driver as the wakeup source

2016-11-02 Thread Meng Yi
> +
> +static int ftm_alarm_irq_enable(struct device *dev, unsigned int
> +enabled) {
> + if (enabled)
> + ftm_irq_enable(true);
> + else
> + ftm_irq_enable(false);
> +
> + return 0;
> +}
> +
> +static int nxp_ftm_rtc_read_time(struct device *dev, struct rtc_time
> +*tm) {
> + struct timeval time;
> + unsigned long local_time;
> +
> + do_gettimeofday();
> + local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> + rtc_time_to_tm(local_time, tm);
> +
> + return 0;
> +}
> +

This is not really getting time from the RTC since FTM is not a RTC device,
But we need to get the time to setup alarm, so we are using system time for now.
Anybody have better idea?

Meng


RE: [RFC PATCH] rtc/nxp: add FTM alarm driver as the wakeup source

2016-11-02 Thread Meng Yi
> +
> +static int ftm_alarm_irq_enable(struct device *dev, unsigned int
> +enabled) {
> + if (enabled)
> + ftm_irq_enable(true);
> + else
> + ftm_irq_enable(false);
> +
> + return 0;
> +}
> +
> +static int nxp_ftm_rtc_read_time(struct device *dev, struct rtc_time
> +*tm) {
> + struct timeval time;
> + unsigned long local_time;
> +
> + do_gettimeofday();
> + local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> + rtc_time_to_tm(local_time, tm);
> +
> + return 0;
> +}
> +

This is not really getting time from the RTC since FTM is not a RTC device,
But we need to get the time to setup alarm, so we are using system time for now.
Anybody have better idea?

Meng


[RFC PATCH] rtc/nxp: add FTM alarm driver as the wakeup source

2016-10-23 Thread Meng Yi
For the platforms including LS1021A, LS1043A that has the
flextimer module, implementing alarm functions within RTC
subsystem to wakeup the system when system going to sleep.
Only Ftm0 can be used to wakeup the system.

Signed-off-by: Meng Yi <meng...@nxp.com>
---
 drivers/rtc/Kconfig   |   9 ++
 drivers/rtc/Makefile  |   1 +
 drivers/rtc/rtc-nxp-ftm.c | 255 ++
 3 files changed, 265 insertions(+)
 create mode 100644 drivers/rtc/rtc-nxp-ftm.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e859d14..0ba52b3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1243,6 +1243,15 @@ config RTC_DRV_IMXDI
   This driver can also be built as a module, if so, the module
   will be called "rtc-imxdi".
 
+config RTC_DRV_NXP
+   tristate "NXP flextimer Real Time Alarm "
+   help
+   For the FlexTimer on LS1021A, LS1043A, we can use FTM0 as the wakeup
+   source.
+   Say y here to enable FTM alarm support.  The FTM alarm provides
+   alarm functions for wakeup system from deep sleep.  There is only
+   one FTM can be used in ALARM(FTM 0).
+
 config RTC_DRV_OMAP
tristate "TI OMAP Real Time Clock"
depends on ARCH_OMAP || ARCH_DAVINCI || COMPILE_TEST
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 1ac694a..abbf22c 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
 obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o
 obj-$(CONFIG_RTC_DRV_HYM8563)  += rtc-hym8563.o
 obj-$(CONFIG_RTC_DRV_IMXDI)+= rtc-imxdi.o
+obj-$(CONFIG_RTC_DRV_NXP)  += rtc-nxp-ftm.o
 obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
 obj-$(CONFIG_RTC_DRV_ISL1208)  += rtc-isl1208.o
 obj-$(CONFIG_RTC_DRV_JZ4740)   += rtc-jz4740.o
diff --git a/drivers/rtc/rtc-nxp-ftm.c b/drivers/rtc/rtc-nxp-ftm.c
new file mode 100644
index 000..74c4358
--- /dev/null
+++ b/drivers/rtc/rtc-nxp-ftm.c
@@ -0,0 +1,255 @@
+/*
+ * Copyright 2016 NXP Semiconductor, Inc.
+ *
+ * NXP FTM alarm device driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FTM_SC 0x00
+#define FTM_SC_CLK_SHIFT   3
+#define FTM_SC_CLK_MASK(0x3 << FTM_SC_CLK_SHIFT)
+#define FTM_SC_CLK(c)  ((c) << FTM_SC_CLK_SHIFT)
+#define FTM_SC_PS_MASK 0x7
+#define FTM_SC_TOIEBIT(6)
+#define FTM_SC_TOF BIT(7)
+
+#define FTM_SC_CLKS_FIXED_FREQ 0x02
+
+#define FTM_CNT0x04
+#define FTM_MOD0x08
+#define FTM_CNTIN  0x4C
+
+#define FIXED_FREQ_CLK 32000
+#define MAX_FREQ_DIV   (1 << FTM_SC_PS_MASK)
+#define MAX_COUNT_VAL  0x
+
+struct ftm_rtc {
+   struct rtc_device *rtc_dev;
+   void __iomem *base;
+   bool endian;
+   u32 alarm_freq;
+};
+
+static struct ftm_rtc rtc;
+
+static inline u32 ftm_readl(void __iomem *addr)
+{
+   return rtc.endian ? ioread32be(addr) : ioread32(addr);
+}
+
+static inline void ftm_writel(u32 val, void __iomem *addr)
+{
+   return rtc.endian ? iowrite32be(val, addr) : iowrite32(val, addr);
+}
+
+static inline void ftm_counter_enable(bool enabled)
+{
+   u32 val;
+
+   /* select and enable counter clock source */
+   val = ftm_readl(rtc.base + FTM_SC);
+   if (enabled) {
+   val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+   val |= (FTM_SC_PS_MASK | FTM_SC_CLK(FTM_SC_CLKS_FIXED_FREQ));
+   } else
+   val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+   ftm_writel(val, rtc.base + FTM_SC);
+}
+
+static int ftm_irq_enable(bool enabled)
+{
+   u32 val;
+
+   val = ftm_readl(rtc.base + FTM_SC);
+   if (enabled)
+   val |= FTM_SC_TOIE;
+   else
+   val &= ~FTM_SC_TOIE;
+   ftm_writel(val, rtc.base + FTM_SC);
+
+   return 0;
+}
+
+static inline void ftm_irq_clear(void)
+{
+   unsigned long timeout = jiffies + msecs_to_jiffies(100);
+
+   while ((FTM_SC_TOF & ftm_readl(rtc.base + FTM_SC)) &&
+   time_before(jiffies, timeout))
+   ftm_writel(ftm_readl(rtc.base + FTM_SC) & (~FTM_SC_TOF),
+  rtc.base + FTM_SC);
+}
+
+static void ftm_clean_alarm(void)
+{
+   ftm_counter_enable(false);
+
+   ftm_writel(0x00, rtc.base + FTM_CNTIN);
+   ftm_writel(~0x00, rtc.base + FTM_MOD);
+
+   /*
+* The CNT register contains the FTM counter value.
+* Reset 

[RFC PATCH] rtc/nxp: add FTM alarm driver as the wakeup source

2016-10-23 Thread Meng Yi
For the platforms including LS1021A, LS1043A that has the
flextimer module, implementing alarm functions within RTC
subsystem to wakeup the system when system going to sleep.
Only Ftm0 can be used to wakeup the system.

Signed-off-by: Meng Yi 
---
 drivers/rtc/Kconfig   |   9 ++
 drivers/rtc/Makefile  |   1 +
 drivers/rtc/rtc-nxp-ftm.c | 255 ++
 3 files changed, 265 insertions(+)
 create mode 100644 drivers/rtc/rtc-nxp-ftm.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e859d14..0ba52b3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1243,6 +1243,15 @@ config RTC_DRV_IMXDI
   This driver can also be built as a module, if so, the module
   will be called "rtc-imxdi".
 
+config RTC_DRV_NXP
+   tristate "NXP flextimer Real Time Alarm "
+   help
+   For the FlexTimer on LS1021A, LS1043A, we can use FTM0 as the wakeup
+   source.
+   Say y here to enable FTM alarm support.  The FTM alarm provides
+   alarm functions for wakeup system from deep sleep.  There is only
+   one FTM can be used in ALARM(FTM 0).
+
 config RTC_DRV_OMAP
tristate "TI OMAP Real Time Clock"
depends on ARCH_OMAP || ARCH_DAVINCI || COMPILE_TEST
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 1ac694a..abbf22c 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
 obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o
 obj-$(CONFIG_RTC_DRV_HYM8563)  += rtc-hym8563.o
 obj-$(CONFIG_RTC_DRV_IMXDI)+= rtc-imxdi.o
+obj-$(CONFIG_RTC_DRV_NXP)  += rtc-nxp-ftm.o
 obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
 obj-$(CONFIG_RTC_DRV_ISL1208)  += rtc-isl1208.o
 obj-$(CONFIG_RTC_DRV_JZ4740)   += rtc-jz4740.o
diff --git a/drivers/rtc/rtc-nxp-ftm.c b/drivers/rtc/rtc-nxp-ftm.c
new file mode 100644
index 000..74c4358
--- /dev/null
+++ b/drivers/rtc/rtc-nxp-ftm.c
@@ -0,0 +1,255 @@
+/*
+ * Copyright 2016 NXP Semiconductor, Inc.
+ *
+ * NXP FTM alarm device driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FTM_SC 0x00
+#define FTM_SC_CLK_SHIFT   3
+#define FTM_SC_CLK_MASK(0x3 << FTM_SC_CLK_SHIFT)
+#define FTM_SC_CLK(c)  ((c) << FTM_SC_CLK_SHIFT)
+#define FTM_SC_PS_MASK 0x7
+#define FTM_SC_TOIEBIT(6)
+#define FTM_SC_TOF BIT(7)
+
+#define FTM_SC_CLKS_FIXED_FREQ 0x02
+
+#define FTM_CNT0x04
+#define FTM_MOD0x08
+#define FTM_CNTIN  0x4C
+
+#define FIXED_FREQ_CLK 32000
+#define MAX_FREQ_DIV   (1 << FTM_SC_PS_MASK)
+#define MAX_COUNT_VAL  0x
+
+struct ftm_rtc {
+   struct rtc_device *rtc_dev;
+   void __iomem *base;
+   bool endian;
+   u32 alarm_freq;
+};
+
+static struct ftm_rtc rtc;
+
+static inline u32 ftm_readl(void __iomem *addr)
+{
+   return rtc.endian ? ioread32be(addr) : ioread32(addr);
+}
+
+static inline void ftm_writel(u32 val, void __iomem *addr)
+{
+   return rtc.endian ? iowrite32be(val, addr) : iowrite32(val, addr);
+}
+
+static inline void ftm_counter_enable(bool enabled)
+{
+   u32 val;
+
+   /* select and enable counter clock source */
+   val = ftm_readl(rtc.base + FTM_SC);
+   if (enabled) {
+   val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+   val |= (FTM_SC_PS_MASK | FTM_SC_CLK(FTM_SC_CLKS_FIXED_FREQ));
+   } else
+   val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+   ftm_writel(val, rtc.base + FTM_SC);
+}
+
+static int ftm_irq_enable(bool enabled)
+{
+   u32 val;
+
+   val = ftm_readl(rtc.base + FTM_SC);
+   if (enabled)
+   val |= FTM_SC_TOIE;
+   else
+   val &= ~FTM_SC_TOIE;
+   ftm_writel(val, rtc.base + FTM_SC);
+
+   return 0;
+}
+
+static inline void ftm_irq_clear(void)
+{
+   unsigned long timeout = jiffies + msecs_to_jiffies(100);
+
+   while ((FTM_SC_TOF & ftm_readl(rtc.base + FTM_SC)) &&
+   time_before(jiffies, timeout))
+   ftm_writel(ftm_readl(rtc.base + FTM_SC) & (~FTM_SC_TOF),
+  rtc.base + FTM_SC);
+}
+
+static void ftm_clean_alarm(void)
+{
+   ftm_counter_enable(false);
+
+   ftm_writel(0x00, rtc.base + FTM_CNTIN);
+   ftm_writel(~0x00, rtc.base + FTM_MOD);
+
+   /*
+* The CNT register contains the FTM counter value.
+* Reset clears the CNT register

RE: [PATCH v3 1/5] drm/fsl-dcu: enable TCON bypass mode by default

2016-10-19 Thread Meng Yi

> 
> Do not use encoder disable/enable callbacks to control bypass mode as this
> seems to mess with the signals not liked by displays. This also makes more
> sense since the encoder is already defined to be parallel RGB/LVDS at creation
> time.
> 
> Signed-off-by: Stefan Agner <ste...@agner.ch>
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |  2 ++  drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_rgb.c | 39 ---
>  2 files changed, 7 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_drv.c
> index 0884c45..3897f56 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -273,6 +273,8 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
>   goto disable_dcu_clk;
>   }
> 
> + if (fsl_dev->tcon)
> + fsl_tcon_bypass_enable(fsl_dev->tcon);
>   fsl_dcu_drm_init_planes(fsl_dev->drm);
>   drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_rgb.c
> index 26edcc8..e1dd75b 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -20,38 +20,6 @@
>  #include "fsl_dcu_drm_drv.h"
>  #include "fsl_tcon.h"
> 
> -static int
> -fsl_dcu_drm_encoder_atomic_check(struct drm_encoder *encoder,
> -  struct drm_crtc_state *crtc_state,
> -  struct drm_connector_state *conn_state)
> -{
> - return 0;
> -}
> -
> -static void fsl_dcu_drm_encoder_disable(struct drm_encoder *encoder) -{
> - struct drm_device *dev = encoder->dev;
> - struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> -
> - if (fsl_dev->tcon)
> - fsl_tcon_bypass_disable(fsl_dev->tcon);
> -}
> -
> -static void fsl_dcu_drm_encoder_enable(struct drm_encoder *encoder) -{
> - struct drm_device *dev = encoder->dev;
> - struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> -
> - if (fsl_dev->tcon)
> - fsl_tcon_bypass_enable(fsl_dev->tcon);
> -}
> -
> -static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
> - .atomic_check = fsl_dcu_drm_encoder_atomic_check,
> - .disable = fsl_dcu_drm_encoder_disable,
> - .enable = fsl_dcu_drm_encoder_enable,
> -};
> -
>  static void fsl_dcu_drm_encoder_destroy(struct drm_encoder *encoder)  {
>   drm_encoder_cleanup(encoder);
> @@ -68,13 +36,16 @@ int fsl_dcu_drm_encoder_create(struct
> fsl_dcu_drm_device *fsl_dev,
>   int ret;
> 
>   encoder->possible_crtcs = 1;
> +
> + /* Use bypass mode for parallel RGB/LVDS encoder */
> + if (fsl_dev->tcon)
> + fsl_tcon_bypass_enable(fsl_dev->tcon);
> +
>   ret = drm_encoder_init(fsl_dev->drm, encoder, _funcs,
>  DRM_MODE_ENCODER_LVDS, NULL);
>   if (ret < 0)
>   return ret;
> 
> - drm_encoder_helper_add(encoder, _helper_funcs);
> -
>   return 0;
>  }
> 
> --
> 2.10.0

Tested-By: Meng Yi <meng...@nxp.com>

Tested those 5 patches on LS1021a-twr, and everything is fine.

Meng



RE: [PATCH v3 1/5] drm/fsl-dcu: enable TCON bypass mode by default

2016-10-19 Thread Meng Yi

> 
> Do not use encoder disable/enable callbacks to control bypass mode as this
> seems to mess with the signals not liked by displays. This also makes more
> sense since the encoder is already defined to be parallel RGB/LVDS at creation
> time.
> 
> Signed-off-by: Stefan Agner 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |  2 ++  drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_rgb.c | 39 ---
>  2 files changed, 7 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_drv.c
> index 0884c45..3897f56 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -273,6 +273,8 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
>   goto disable_dcu_clk;
>   }
> 
> + if (fsl_dev->tcon)
> + fsl_tcon_bypass_enable(fsl_dev->tcon);
>   fsl_dcu_drm_init_planes(fsl_dev->drm);
>   drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_rgb.c
> index 26edcc8..e1dd75b 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -20,38 +20,6 @@
>  #include "fsl_dcu_drm_drv.h"
>  #include "fsl_tcon.h"
> 
> -static int
> -fsl_dcu_drm_encoder_atomic_check(struct drm_encoder *encoder,
> -  struct drm_crtc_state *crtc_state,
> -  struct drm_connector_state *conn_state)
> -{
> - return 0;
> -}
> -
> -static void fsl_dcu_drm_encoder_disable(struct drm_encoder *encoder) -{
> - struct drm_device *dev = encoder->dev;
> - struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> -
> - if (fsl_dev->tcon)
> - fsl_tcon_bypass_disable(fsl_dev->tcon);
> -}
> -
> -static void fsl_dcu_drm_encoder_enable(struct drm_encoder *encoder) -{
> - struct drm_device *dev = encoder->dev;
> - struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> -
> - if (fsl_dev->tcon)
> - fsl_tcon_bypass_enable(fsl_dev->tcon);
> -}
> -
> -static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
> - .atomic_check = fsl_dcu_drm_encoder_atomic_check,
> - .disable = fsl_dcu_drm_encoder_disable,
> - .enable = fsl_dcu_drm_encoder_enable,
> -};
> -
>  static void fsl_dcu_drm_encoder_destroy(struct drm_encoder *encoder)  {
>   drm_encoder_cleanup(encoder);
> @@ -68,13 +36,16 @@ int fsl_dcu_drm_encoder_create(struct
> fsl_dcu_drm_device *fsl_dev,
>   int ret;
> 
>   encoder->possible_crtcs = 1;
> +
> + /* Use bypass mode for parallel RGB/LVDS encoder */
> + if (fsl_dev->tcon)
> + fsl_tcon_bypass_enable(fsl_dev->tcon);
> +
>   ret = drm_encoder_init(fsl_dev->drm, encoder, _funcs,
>  DRM_MODE_ENCODER_LVDS, NULL);
>   if (ret < 0)
>   return ret;
> 
> - drm_encoder_helper_add(encoder, _helper_funcs);
> -
>   return 0;
>  }
> 
> --
> 2.10.0

Tested-By: Meng Yi 

Tested those 5 patches on LS1021a-twr, and everything is fine.

Meng



[PATCH v3] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-21 Thread Meng Yi
If the FTM counter reaches the FTM_MOD value between the reading of the
TOF bit and the writing of 0 to the TOF bit, the process of clearing the
TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the
current TOF count is less than FTMx_CONF[NUMTOF]. If the above condition
is met, the TOF bit remains set. If the TOF interrupt is enabled
(FTMx_SC[TOIE] = 1), the TOF interrupt also remains asserted.

Above is the errata discription

The workaround is clearing TOF bit until it is cleaned(FTM counter doesn't
always reache the FTM_MOD anyway),which may cost some cycles.

Signed-off-by: Meng Yi <meng...@nxp.com>
---
Change from V1:
-add timeout into wile loop using a counter
---
 drivers/clocksource/fsl_ftm_timer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 738515b..97bdb09 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -83,11 +83,11 @@ static inline void ftm_counter_disable(void __iomem *base)
 
 static inline void ftm_irq_acknowledge(void __iomem *base)
 {
-   u32 val;
+   u32 count = 100;
 
-   val = ftm_readl(base + FTM_SC);
-   val &= ~FTM_SC_TOF;
-   ftm_writel(val, base + FTM_SC);
+   while ((FTM_SC_TOF & ftm_readl(base + FTM_SC)) && count--)
+   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
+  base + FTM_SC);
 }
 
 static inline void ftm_irq_enable(void __iomem *base)
-- 
2.1.0.27.g96db324



[PATCH v3] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-21 Thread Meng Yi
If the FTM counter reaches the FTM_MOD value between the reading of the
TOF bit and the writing of 0 to the TOF bit, the process of clearing the
TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the
current TOF count is less than FTMx_CONF[NUMTOF]. If the above condition
is met, the TOF bit remains set. If the TOF interrupt is enabled
(FTMx_SC[TOIE] = 1), the TOF interrupt also remains asserted.

Above is the errata discription

The workaround is clearing TOF bit until it is cleaned(FTM counter doesn't
always reache the FTM_MOD anyway),which may cost some cycles.

Signed-off-by: Meng Yi 
---
Change from V1:
-add timeout into wile loop using a counter
---
 drivers/clocksource/fsl_ftm_timer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 738515b..97bdb09 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -83,11 +83,11 @@ static inline void ftm_counter_disable(void __iomem *base)
 
 static inline void ftm_irq_acknowledge(void __iomem *base)
 {
-   u32 val;
+   u32 count = 100;
 
-   val = ftm_readl(base + FTM_SC);
-   val &= ~FTM_SC_TOF;
-   ftm_writel(val, base + FTM_SC);
+   while ((FTM_SC_TOF & ftm_readl(base + FTM_SC)) && count--)
+   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
+  base + FTM_SC);
 }
 
 static inline void ftm_irq_enable(void __iomem *base)
-- 
2.1.0.27.g96db324



RE: [PATCH v2] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-21 Thread Meng Yi

> > __iomem *base)
> >
> >  static inline void ftm_irq_acknowledge(void __iomem *base)  {
> > -   u32 val;
> > +   unsigned long timeout = jiffies + msecs_to_jiffies(100);
> 
> Do you expect the jiffies to be updated when we are in the timer irq handler ?
> 

Oops, my bad. Will correct that using "for" loop.

Thanks,
Meng




RE: [PATCH v2] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-21 Thread Meng Yi

> > __iomem *base)
> >
> >  static inline void ftm_irq_acknowledge(void __iomem *base)  {
> > -   u32 val;
> > +   unsigned long timeout = jiffies + msecs_to_jiffies(100);
> 
> Do you expect the jiffies to be updated when we are in the timer irq handler ?
> 

Oops, my bad. Will correct that using "for" loop.

Thanks,
Meng




[PATCH v2] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-18 Thread Meng Yi
If the FTM counter reaches the FTM_MOD value between the reading of the
TOF bit and the writing of 0 to the TOF bit, the process of clearing the
TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the
current TOF count is less than FTMx_CONF[NUMTOF]. If the above condition
is met, the TOF bit remains set. If the TOF interrupt is enabled
(FTMx_SC[TOIE] = 1), the TOF interrupt also remains asserted.

Above is the errata discription

The workaround is clearing TOF bit until it is cleaned(FTM counter doesn't
always reache the FTM_MOD anyway),which may cost some cycles.

Signed-off-by: Meng Yi <meng...@nxp.com>
---
Change in V2:
-add timeout into IRQ context(suggested by Alexander)
---
 drivers/clocksource/fsl_ftm_timer.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 738515b..86f9186 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -83,11 +83,13 @@ static inline void ftm_counter_disable(void __iomem *base)
 
 static inline void ftm_irq_acknowledge(void __iomem *base)
 {
-   u32 val;
+   unsigned long timeout = jiffies + msecs_to_jiffies(100);
 
-   val = ftm_readl(base + FTM_SC);
-   val &= ~FTM_SC_TOF;
-   ftm_writel(val, base + FTM_SC);
+   /*read and clean the FTM_SC_TOF bit until its cleared*/
+   while ((FTM_SC_TOF & ftm_readl(base + FTM_SC)) &&
+   time_before(jiffies, timeout))
+   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
+  base + FTM_SC);
 }
 
 static inline void ftm_irq_enable(void __iomem *base)
-- 
2.1.0.27.g96db324



[PATCH v2] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-18 Thread Meng Yi
If the FTM counter reaches the FTM_MOD value between the reading of the
TOF bit and the writing of 0 to the TOF bit, the process of clearing the
TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the
current TOF count is less than FTMx_CONF[NUMTOF]. If the above condition
is met, the TOF bit remains set. If the TOF interrupt is enabled
(FTMx_SC[TOIE] = 1), the TOF interrupt also remains asserted.

Above is the errata discription

The workaround is clearing TOF bit until it is cleaned(FTM counter doesn't
always reache the FTM_MOD anyway),which may cost some cycles.

Signed-off-by: Meng Yi 
---
Change in V2:
-add timeout into IRQ context(suggested by Alexander)
---
 drivers/clocksource/fsl_ftm_timer.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 738515b..86f9186 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -83,11 +83,13 @@ static inline void ftm_counter_disable(void __iomem *base)
 
 static inline void ftm_irq_acknowledge(void __iomem *base)
 {
-   u32 val;
+   unsigned long timeout = jiffies + msecs_to_jiffies(100);
 
-   val = ftm_readl(base + FTM_SC);
-   val &= ~FTM_SC_TOF;
-   ftm_writel(val, base + FTM_SC);
+   /*read and clean the FTM_SC_TOF bit until its cleared*/
+   while ((FTM_SC_TOF & ftm_readl(base + FTM_SC)) &&
+   time_before(jiffies, timeout))
+   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
+  base + FTM_SC);
 }
 
 static inline void ftm_irq_enable(void __iomem *base)
-- 
2.1.0.27.g96db324



RE: [PATCH] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-08 Thread Meng Yi
> >  drivers/clocksource/fsl_ftm_timer.c | 9 -
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/clocksource/fsl_ftm_timer.c
> > b/drivers/clocksource/fsl_ftm_timer.c index 738515b..ade26e5 100644
> > --- a/drivers/clocksource/fsl_ftm_timer.c
> > +++ b/drivers/clocksource/fsl_ftm_timer.c
> > @@ -83,11 +83,10 @@ static inline void ftm_counter_disable(void
> > __iomem
> > *base)
> >
> >  static inline void ftm_irq_acknowledge(void __iomem *base)  {
> > -   u32 val;
> > -
> > -   val = ftm_readl(base + FTM_SC);
> > -   val &= ~FTM_SC_TOF;
> > -   ftm_writel(val, base + FTM_SC);
> > +   /*read and clean the FTM_SC_TOF bit until its cleared*/
> > +   while (FTM_SC_TOF & ftm_readl(base + FTM_SC))
> > +   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
> > +  base + FTM_SC);
> >  }
> 
> So you are essentially polling hardware in interrupt context. Please add a
> sensible timeout to abort this loop in case of defective hardware, and maybe
> disable the interrupt in that case.
> 

Oh, right. Thank for your comments. I will correct that in next version.

 Best regards,
Meng



RE: [PATCH] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-08 Thread Meng Yi
> >  drivers/clocksource/fsl_ftm_timer.c | 9 -
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/clocksource/fsl_ftm_timer.c
> > b/drivers/clocksource/fsl_ftm_timer.c index 738515b..ade26e5 100644
> > --- a/drivers/clocksource/fsl_ftm_timer.c
> > +++ b/drivers/clocksource/fsl_ftm_timer.c
> > @@ -83,11 +83,10 @@ static inline void ftm_counter_disable(void
> > __iomem
> > *base)
> >
> >  static inline void ftm_irq_acknowledge(void __iomem *base)  {
> > -   u32 val;
> > -
> > -   val = ftm_readl(base + FTM_SC);
> > -   val &= ~FTM_SC_TOF;
> > -   ftm_writel(val, base + FTM_SC);
> > +   /*read and clean the FTM_SC_TOF bit until its cleared*/
> > +   while (FTM_SC_TOF & ftm_readl(base + FTM_SC))
> > +   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
> > +  base + FTM_SC);
> >  }
> 
> So you are essentially polling hardware in interrupt context. Please add a
> sensible timeout to abort this loop in case of defective hardware, and maybe
> disable the interrupt in that case.
> 

Oh, right. Thank for your comments. I will correct that in next version.

 Best regards,
Meng



[PATCH] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-07 Thread Meng Yi
If the FTM counter reaches the FTM_MOD value between the reading of the
TOF bit and the writing of 0 to the TOF bit, the process of clearing the
TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the
current TOF count is less than FTMx_CONF[NUMTOF]. If the above condition
is met, the TOF bit remains set. If the TOF interrupt is enabled
(FTMx_SC[TOIE] = 1), the TOF interrupt also remains asserted.

Above is the errata discription

The workaround is clearing TOF bit until it is cleaned(FTM counter doesn't
always reache the FTM_MOD anyway),which may cost some cycles.

Signed-off-by: Meng Yi <meng...@nxp.com>
---
 drivers/clocksource/fsl_ftm_timer.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 738515b..ade26e5 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -83,11 +83,10 @@ static inline void ftm_counter_disable(void __iomem *base)
 
 static inline void ftm_irq_acknowledge(void __iomem *base)
 {
-   u32 val;
-
-   val = ftm_readl(base + FTM_SC);
-   val &= ~FTM_SC_TOF;
-   ftm_writel(val, base + FTM_SC);
+   /*read and clean the FTM_SC_TOF bit until its cleared*/
+   while (FTM_SC_TOF & ftm_readl(base + FTM_SC))
+   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
+  base + FTM_SC);
 }
 
 static inline void ftm_irq_enable(void __iomem *base)
-- 
2.1.0.27.g96db324



[PATCH] clocksource/fsl: Fix errata A-007728 for flextimer

2016-09-07 Thread Meng Yi
If the FTM counter reaches the FTM_MOD value between the reading of the
TOF bit and the writing of 0 to the TOF bit, the process of clearing the
TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the
current TOF count is less than FTMx_CONF[NUMTOF]. If the above condition
is met, the TOF bit remains set. If the TOF interrupt is enabled
(FTMx_SC[TOIE] = 1), the TOF interrupt also remains asserted.

Above is the errata discription

The workaround is clearing TOF bit until it is cleaned(FTM counter doesn't
always reache the FTM_MOD anyway),which may cost some cycles.

Signed-off-by: Meng Yi 
---
 drivers/clocksource/fsl_ftm_timer.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 738515b..ade26e5 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -83,11 +83,10 @@ static inline void ftm_counter_disable(void __iomem *base)
 
 static inline void ftm_irq_acknowledge(void __iomem *base)
 {
-   u32 val;
-
-   val = ftm_readl(base + FTM_SC);
-   val &= ~FTM_SC_TOF;
-   ftm_writel(val, base + FTM_SC);
+   /*read and clean the FTM_SC_TOF bit until its cleared*/
+   while (FTM_SC_TOF & ftm_readl(base + FTM_SC))
+   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
+  base + FTM_SC);
 }
 
 static inline void ftm_irq_enable(void __iomem *base)
-- 
2.1.0.27.g96db324



RE: [PATCH 0/4] drm/fsl-dcu: add overlay and cursor plane support

2016-09-07 Thread Meng Yi
Hi Stefan,

I had tested the patches on LS1021A-TWR board using drmlib.

Like set three overlays:
root@ls1021atwr:~# ./modetest -P 39:900x100+10+10@RG24 -P 39:200x200+300+0@RG24 
-P 39:200x200+400+300@RG24

How did you test the overlays and cursor layer, I mean I see you using x-window 
like thing in the  video.

Best Regards,
Meng

> This patchset adds overlay and cursor plane support. It also fixes some issues
> uncovered during implementation of this.
> 
> However, the plane updates currently causes the display to flicker for unknown
> reasons. As far as I can tell, the CRTC atomic_flush should trigger the update
> correctly via READREG, which according to
> documentation:
> The READREG bit causes a single transfer to begin at the next frame blanking
> period. This bit is cleared when the transfer is complete.
> 
> I made a video how that looks:
> https://cloud.agner.ch/index.php/s/Yfqa2u7UBEWUT8N
> 
> Any ideas?
> 
> Stefan Agner (4):
>   drm/fsl-dcu: support overlay and cursor planes
>   drm/fsl-dcu: respect pos/size register sizes
>   drm/fsl-dcu: update all registers on flush
>   drm/fsl-dcu: do not update when modifying irq registers
> 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  | 50
> -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  4 ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h   |  8 ++---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 42 +++-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h |  3 +-
>  5 files changed, 67 insertions(+), 40 deletions(-)
> 
> --
> 2.9.3



RE: [PATCH 0/4] drm/fsl-dcu: add overlay and cursor plane support

2016-09-07 Thread Meng Yi
Hi Stefan,

I had tested the patches on LS1021A-TWR board using drmlib.

Like set three overlays:
root@ls1021atwr:~# ./modetest -P 39:900x100+10+10@RG24 -P 39:200x200+300+0@RG24 
-P 39:200x200+400+300@RG24

How did you test the overlays and cursor layer, I mean I see you using x-window 
like thing in the  video.

Best Regards,
Meng

> This patchset adds overlay and cursor plane support. It also fixes some issues
> uncovered during implementation of this.
> 
> However, the plane updates currently causes the display to flicker for unknown
> reasons. As far as I can tell, the CRTC atomic_flush should trigger the update
> correctly via READREG, which according to
> documentation:
> The READREG bit causes a single transfer to begin at the next frame blanking
> period. This bit is cleared when the transfer is complete.
> 
> I made a video how that looks:
> https://cloud.agner.ch/index.php/s/Yfqa2u7UBEWUT8N
> 
> Any ideas?
> 
> Stefan Agner (4):
>   drm/fsl-dcu: support overlay and cursor planes
>   drm/fsl-dcu: respect pos/size register sizes
>   drm/fsl-dcu: update all registers on flush
>   drm/fsl-dcu: do not update when modifying irq registers
> 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  | 50
> -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  4 ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h   |  8 ++---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 42 +++-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h |  3 +-
>  5 files changed, 67 insertions(+), 40 deletions(-)
> 
> --
> 2.9.3



RE: [PATCH 3/4] drm/fsl-dcu: update all registers on flush

2016-09-07 Thread Meng Yi
Hi Stefan,

Some comments below

> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_crtc.c
> index d30b61e..62eb284 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> @@ -27,6 +27,9 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc
> *crtc,  {
>   struct drm_pending_vblank_event *event = crtc->state->event;
> 
> + regmap_write(fsl_dev->regmap,
> +  DCU_UPDATE_MODE, DCU_UPDATE_MODE_READREG);

fsl_dev is not declared.
I had added these two lines when testing the patches.

   struct drm_device *dev = crtc->dev;
   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;

> +
>   if (event) {
>   crtc->state->event = NULL;
> 

Best Regards,
Meng


RE: [PATCH 3/4] drm/fsl-dcu: update all registers on flush

2016-09-07 Thread Meng Yi
Hi Stefan,

Some comments below

> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_crtc.c
> index d30b61e..62eb284 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> @@ -27,6 +27,9 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc
> *crtc,  {
>   struct drm_pending_vblank_event *event = crtc->state->event;
> 
> + regmap_write(fsl_dev->regmap,
> +  DCU_UPDATE_MODE, DCU_UPDATE_MODE_READREG);

fsl_dev is not declared.
I had added these two lines when testing the patches.

   struct drm_device *dev = crtc->dev;
   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;

> +
>   if (event) {
>   crtc->state->event = NULL;
> 

Best Regards,
Meng


[PATCH RESEND] ARM: dts: ls1021a: Add of_graph dt nodes to describe the panel

2016-09-06 Thread Meng Yi
add of_graph dt nodes to describe the panel, and removed
"fsl,panel" property

Signed-off-by: Meng Yi <meng...@nxp.com>
---
 arch/arm/boot/dts/ls1021a-twr.dts | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index 75ecaed..a8b148a 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -108,12 +108,23 @@
 
panel: panel {
compatible = "nec,nl4827hc19-05b";
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
};
 };
 
  {
-   fsl,panel = <>;
status = "okay";
+
+   port {
+   dcu_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
 };
 
  {
-- 
2.1.0.27.g96db324



[PATCH RESEND] ARM: dts: ls1021a: Add of_graph dt nodes to describe the panel

2016-09-06 Thread Meng Yi
add of_graph dt nodes to describe the panel, and removed
"fsl,panel" property

Signed-off-by: Meng Yi 
---
 arch/arm/boot/dts/ls1021a-twr.dts | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index 75ecaed..a8b148a 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -108,12 +108,23 @@
 
panel: panel {
compatible = "nec,nl4827hc19-05b";
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
};
 };
 
  {
-   fsl,panel = <>;
status = "okay";
+
+   port {
+   dcu_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
 };
 
  {
-- 
2.1.0.27.g96db324



RE: [PATCH] drm/fsl-dcu: fix endian issue when using clk_register_divider

2016-09-05 Thread Meng Yi

> Subject: [PATCH] drm/fsl-dcu: fix endian issue when using clk_register_divider
> 
> Since using clk_register_divider to setup the pixel clock, regmap is no longer
> used. Regmap did take care of DCU using different endianness. Check
> endianness using the device-tree property "big-endian" to determine the
> location of DIV_RATIO.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 2d701449bce1 ("drm/fsl-dcu: use common clock framework for pixel
> clock divider")
> Reported-by: Meng Yi <meng...@nxp.com>
> Signed-off-by: Stefan Agner <ste...@agner.ch>
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_drv.c
> index 7882387..8dd042e 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -330,6 +330,7 @@ static int fsl_dcu_drm_probe(struct platform_device
> *pdev)
>   const char *pix_clk_in_name;
>   const struct of_device_id *id;
>   int ret;
> + u8 div_ratio_shift = 0;
> 
>   fsl_dev = devm_kzalloc(dev, sizeof(*fsl_dev), GFP_KERNEL);
>   if (!fsl_dev)
> @@ -382,11 +383,15 @@ static int fsl_dcu_drm_probe(struct platform_device
> *pdev)
>   pix_clk_in = fsl_dev->clk;
>   }
> 
> + if (of_property_read_bool(dev->of_node, "big-endian"))
> + div_ratio_shift = 24;
> +
> +
>   pix_clk_in_name = __clk_get_name(pix_clk_in);
>   snprintf(pix_clk_name, sizeof(pix_clk_name), "%s_pix",
> pix_clk_in_name);
>   fsl_dev->pix_clk = clk_register_divider(dev, pix_clk_name,
>   pix_clk_in_name, 0, base + DCU_DIV_RATIO,
> - 0, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL);
> + div_ratio_shift, 8, CLK_DIVIDER_ROUND_CLOSEST,
> NULL);
>   if (IS_ERR(fsl_dev->pix_clk)) {
>   dev_err(dev, "failed to register pix clk\n");
>   ret = PTR_ERR(fsl_dev->pix_clk);
> --
> 2.9.0

Tested-by: Meng Yi <meng...@nxp.com>
On LS1021A-TWR board.

Meng



RE: [PATCH] drm/fsl-dcu: fix endian issue when using clk_register_divider

2016-09-05 Thread Meng Yi

> Subject: [PATCH] drm/fsl-dcu: fix endian issue when using clk_register_divider
> 
> Since using clk_register_divider to setup the pixel clock, regmap is no longer
> used. Regmap did take care of DCU using different endianness. Check
> endianness using the device-tree property "big-endian" to determine the
> location of DIV_RATIO.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 2d701449bce1 ("drm/fsl-dcu: use common clock framework for pixel
> clock divider")
> Reported-by: Meng Yi 
> Signed-off-by: Stefan Agner 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_drv.c
> index 7882387..8dd042e 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -330,6 +330,7 @@ static int fsl_dcu_drm_probe(struct platform_device
> *pdev)
>   const char *pix_clk_in_name;
>   const struct of_device_id *id;
>   int ret;
> + u8 div_ratio_shift = 0;
> 
>   fsl_dev = devm_kzalloc(dev, sizeof(*fsl_dev), GFP_KERNEL);
>   if (!fsl_dev)
> @@ -382,11 +383,15 @@ static int fsl_dcu_drm_probe(struct platform_device
> *pdev)
>   pix_clk_in = fsl_dev->clk;
>   }
> 
> + if (of_property_read_bool(dev->of_node, "big-endian"))
> + div_ratio_shift = 24;
> +
> +
>   pix_clk_in_name = __clk_get_name(pix_clk_in);
>   snprintf(pix_clk_name, sizeof(pix_clk_name), "%s_pix",
> pix_clk_in_name);
>   fsl_dev->pix_clk = clk_register_divider(dev, pix_clk_name,
>   pix_clk_in_name, 0, base + DCU_DIV_RATIO,
> - 0, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL);
> + div_ratio_shift, 8, CLK_DIVIDER_ROUND_CLOSEST,
> NULL);
>   if (IS_ERR(fsl_dev->pix_clk)) {
>   dev_err(dev, "failed to register pix clk\n");
>   ret = PTR_ERR(fsl_dev->pix_clk);
> --
> 2.9.0

Tested-by: Meng Yi 
On LS1021A-TWR board.

Meng



RE: fsl-dcu not works on latest "drm-next"

2016-06-06 Thread Meng Yi
Hi Stefan,

> >> static const struct regmap_config fsl_dcu_regmap_config = {
> >> .reg_bits = 32,
> >> .reg_stride = 4,
> >> .val_bits = 32,
> >> .cache_type = REGCACHE_RBTREE,
> >
> > This needs to be a flat cache. See
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.h
> > tml or https://lkml.org/lkml/2016/3/24/281
> > max_register also needs an appropriate value.
> 
> Ok, since the complete set which switches to the atomic helper is not stable
> material (and also won't make it into 4.7 anymore), I created a seperate 
> bugfix
> now:
> https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html
> 
> What I don't quite get yet is the REGCACHE_FLAT influencing the endianness
> behavior?
> 

I think it didn't. And endianness issue have been fixed by regmap maintainer.

> If it is, Meng, can you test again with v4.7-rc1 + the FLAT cache patch above?
> 

I have tested FLAT cache on LS1021A, it works fine. By the way do you have any 
opinion on LS1021A's
HDMI driver? 

Regards,
Meng



RE: fsl-dcu not works on latest "drm-next"

2016-06-06 Thread Meng Yi
Hi Stefan,

> >> static const struct regmap_config fsl_dcu_regmap_config = {
> >> .reg_bits = 32,
> >> .reg_stride = 4,
> >> .val_bits = 32,
> >> .cache_type = REGCACHE_RBTREE,
> >
> > This needs to be a flat cache. See
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.h
> > tml or https://lkml.org/lkml/2016/3/24/281
> > max_register also needs an appropriate value.
> 
> Ok, since the complete set which switches to the atomic helper is not stable
> material (and also won't make it into 4.7 anymore), I created a seperate 
> bugfix
> now:
> https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html
> 
> What I don't quite get yet is the REGCACHE_FLAT influencing the endianness
> behavior?
> 

I think it didn't. And endianness issue have been fixed by regmap maintainer.

> If it is, Meng, can you test again with v4.7-rc1 + the FLAT cache patch above?
> 

I have tested FLAT cache on LS1021A, it works fine. By the way do you have any 
opinion on LS1021A's
HDMI driver? 

Regards,
Meng



RE: fsl-dcu not works on latest "drm-next"

2016-06-06 Thread Meng Yi
Hi Stefan,

Sorry for reply late, I was on PTO. And another PTO on  June 9~11, 2016.UTC+8

> >> static const struct regmap_config fsl_dcu_regmap_config = {
> >> .reg_bits = 32,
> >> .reg_stride = 4,
> >> .val_bits = 32,
> >> .cache_type = REGCACHE_RBTREE,
> >
> > This needs to be a flat cache. See
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.h
> > tml or https://lkml.org/lkml/2016/3/24/281
> > max_register also needs an appropriate value.
> 
> Ok, since the complete set which switches to the atomic helper is not stable
> material (and also won't make it into 4.7 anymore), I created a seperate 
> bugfix
> now:
> https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html
> 

What is bug?

> What I don't quite get yet is the REGCACHE_FLAT influencing the endianness
> behavior?
> 
> If it is, Meng, can you test again with v4.7-rc1 + the FLAT cache patch above?
> 

I will test it, and send an e-mail to you by then.

Regards,
Meng


RE: fsl-dcu not works on latest "drm-next"

2016-06-06 Thread Meng Yi
Hi Stefan,

Sorry for reply late, I was on PTO. And another PTO on  June 9~11, 2016.UTC+8

> >> static const struct regmap_config fsl_dcu_regmap_config = {
> >> .reg_bits = 32,
> >> .reg_stride = 4,
> >> .val_bits = 32,
> >> .cache_type = REGCACHE_RBTREE,
> >
> > This needs to be a flat cache. See
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.h
> > tml or https://lkml.org/lkml/2016/3/24/281
> > max_register also needs an appropriate value.
> 
> Ok, since the complete set which switches to the atomic helper is not stable
> material (and also won't make it into 4.7 anymore), I created a seperate 
> bugfix
> now:
> https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html
> 

What is bug?

> What I don't quite get yet is the REGCACHE_FLAT influencing the endianness
> behavior?
> 
> If it is, Meng, can you test again with v4.7-rc1 + the FLAT cache patch above?
> 

I will test it, and send an e-mail to you by then.

Regards,
Meng


RE: fsl-dcu not works on latest "drm-next"

2016-05-26 Thread Meng Yi
Hi Mark,

> You've not specifically described the problem here - what are the endiannesses
> of both the CPU and the device you're talking to?  What specifically is the
> endianess problem you are seeing, what are you seeing and what do you
> expect to see?
> 

The CPU is little endian and the device DCU is big endian, specified big-endian 
in DTS, 

And here is my DTS and regmap_config,

Specified "big-endian" in DTS,

dcu: dcu@2ce {
compatible = "fsl,ls1021a-dcu";
reg = <0x0 0x2ce 0x0 0x1>;
interrupts = ;
clocks = <_clk 0>;
clock-names = "dcu";
big-endian;
status = "disabled";
};

I can't tell the difference of "reg_format_endian" and " val_format_endian ", 
so I had tried four conditions. And all failed.

static const struct regmap_config fsl_dcu_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
.cache_type = REGCACHE_RBTREE,
//  .reg_format_endian = REGMAP_ENDIAN_BIG, //  .val_format_endian = 
REGMAP_ENDIAN_BIG,

.volatile_reg = fsl_dcu_drm_is_volatile_reg, };


I expect that regmap write as big endian, and I am seeing is regmap write as 
little endian.

Thanks,
Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-26 Thread Meng Yi
Hi Mark,

> You've not specifically described the problem here - what are the endiannesses
> of both the CPU and the device you're talking to?  What specifically is the
> endianess problem you are seeing, what are you seeing and what do you
> expect to see?
> 

The CPU is little endian and the device DCU is big endian, specified big-endian 
in DTS, 

And here is my DTS and regmap_config,

Specified "big-endian" in DTS,

dcu: dcu@2ce {
compatible = "fsl,ls1021a-dcu";
reg = <0x0 0x2ce 0x0 0x1>;
interrupts = ;
clocks = <_clk 0>;
clock-names = "dcu";
big-endian;
status = "disabled";
};

I can't tell the difference of "reg_format_endian" and " val_format_endian ", 
so I had tried four conditions. And all failed.

static const struct regmap_config fsl_dcu_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
.cache_type = REGCACHE_RBTREE,
//  .reg_format_endian = REGMAP_ENDIAN_BIG, //  .val_format_endian = 
REGMAP_ENDIAN_BIG,

.volatile_reg = fsl_dcu_drm_is_volatile_reg, };


I expect that regmap write as big endian, and I am seeing is regmap write as 
little endian.

Thanks,
Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-26 Thread Meng Yi
Hi Alexander,

> From your backtrace I guess wait_event_timeout is called in some atomic
> context (might_sleep(); is called inside wait_event_timeout). This has nothing
> to do with regmap.
> 

Here is my view of point:
Since IRQ setup codes using regmap, and which is not setup properly, so 
wait_event_timeout.

> 
> The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> could successfully probe DCU.

Thanks for your information.
DCU was able to  be probed without those patches, and DCU still not works with 
those patches.

And here is my DTS and regmap_config,

Specified "big-endian" in DTS,

dcu: dcu@2ce {
compatible = "fsl,ls1021a-dcu";
reg = <0x0 0x2ce 0x0 0x1>;
interrupts = ;
clocks = <_clk 0>;
clock-names = "dcu";
big-endian;
status = "disabled";
};

I can't tell the difference of "reg_format_endian" and " val_format_endian ", 
so I had tried four conditions.

static const struct regmap_config fsl_dcu_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
.cache_type = REGCACHE_RBTREE,
//  .reg_format_endian = REGMAP_ENDIAN_BIG,
//  .val_format_endian = REGMAP_ENDIAN_BIG,

.volatile_reg = fsl_dcu_drm_is_volatile_reg,
};

Thanks,
Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-26 Thread Meng Yi
Hi Alexander,

> From your backtrace I guess wait_event_timeout is called in some atomic
> context (might_sleep(); is called inside wait_event_timeout). This has nothing
> to do with regmap.
> 

Here is my view of point:
Since IRQ setup codes using regmap, and which is not setup properly, so 
wait_event_timeout.

> 
> The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> could successfully probe DCU.

Thanks for your information.
DCU was able to  be probed without those patches, and DCU still not works with 
those patches.

And here is my DTS and regmap_config,

Specified "big-endian" in DTS,

dcu: dcu@2ce {
compatible = "fsl,ls1021a-dcu";
reg = <0x0 0x2ce 0x0 0x1>;
interrupts = ;
clocks = <_clk 0>;
clock-names = "dcu";
big-endian;
status = "disabled";
};

I can't tell the difference of "reg_format_endian" and " val_format_endian ", 
so I had tried four conditions.

static const struct regmap_config fsl_dcu_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
.cache_type = REGCACHE_RBTREE,
//  .reg_format_endian = REGMAP_ENDIAN_BIG,
//  .val_format_endian = REGMAP_ENDIAN_BIG,

.volatile_reg = fsl_dcu_drm_is_volatile_reg,
};

Thanks,
Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-25 Thread Meng Yi
Hi Alexander,
Thanks for your reply.

> Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> commit in my repo. Both touch only i915 related things. Please do a proper
> bisect and name the offending commit. On which commit you got that
> backtrace BTW?
> From your backtrace I can't see anything related to regmap.
> 

It is weird that using bisect, for the commit log is not linear.
I mean a newer date commit may be merged before an older date commit, when jump 
to that older date commit, the newer one will be lost, even though it is merged 
before older one.
So, I think it's difficult to use git bisect.
" d761701c55a99598477f3cb25c03d939a7711e74 " is just an older one, I mean 
between this commit and the next commit, maybe lots of commits are lost. So, it 
looks like this commit have nothing to do with the problem.

According to the backtrace, looks like the vblank interrupt is not happen or  
handled.
Then I found the irq is installed successfully, so the problem seems like the 
vblank irq is not properly setup. And here is the point , irq initia, irq 
handler and timing control code are using regmap.

I read out the value of relevant register using "CodeWarrior TAP", find that 
endianness is not right.

Then I changed endianness of the value to be written that using " regmap_write" 
. It works.
But "regmap_update_bits" still have the problem.

I had checked log of regmap, and didn't find which commit caused that.

Since I am not familiar with regmap, hope you can give me some advice.

Thanks,
Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-25 Thread Meng Yi
Hi Alexander,
Thanks for your reply.

> Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> commit in my repo. Both touch only i915 related things. Please do a proper
> bisect and name the offending commit. On which commit you got that
> backtrace BTW?
> From your backtrace I can't see anything related to regmap.
> 

It is weird that using bisect, for the commit log is not linear.
I mean a newer date commit may be merged before an older date commit, when jump 
to that older date commit, the newer one will be lost, even though it is merged 
before older one.
So, I think it's difficult to use git bisect.
" d761701c55a99598477f3cb25c03d939a7711e74 " is just an older one, I mean 
between this commit and the next commit, maybe lots of commits are lost. So, it 
looks like this commit have nothing to do with the problem.

According to the backtrace, looks like the vblank interrupt is not happen or  
handled.
Then I found the irq is installed successfully, so the problem seems like the 
vblank irq is not properly setup. And here is the point , irq initia, irq 
handler and timing control code are using regmap.

I read out the value of relevant register using "CodeWarrior TAP", find that 
endianness is not right.

Then I changed endianness of the value to be written that using " regmap_write" 
. It works.
But "regmap_update_bits" still have the problem.

I had checked log of regmap, and didn't find which commit caused that.

Since I am not familiar with regmap, hope you can give me some advice.

Thanks,
Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-25 Thread Meng Yi

Hi Mark,

> 
> Without any description of the problem it is difficult to comment.
> There were some drivers that were abusing the API by hacking round things
> that need fixing (the main one I've seen is reporting things as big endian
> instead of native endian to cause two layers of translation to kick in) and 
> one
> that was trying to use regmap to represent something that just fundamentally
> wasn't a regmap so *any* change in regmap internals was risky.

I was testing HDMI patches on latest "drm-next" branch, and found that it is 
not work.
And then I found the base tree was not working too. Then I debugged the base 
tree.

I read out the value of relevant register using "CodeWarrior TAP", find that 
endianness is not right.

Then I changed endianness of the value to be written that using " regmap_write" 
. It works.
But "regmap_update_bits" still have the problem.

I had checked log of regmap, and didn't find which commit caused that.

I am not familiar with regmap, can you give some advices?

Thanks,
Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-25 Thread Meng Yi

Hi Mark,

> 
> Without any description of the problem it is difficult to comment.
> There were some drivers that were abusing the API by hacking round things
> that need fixing (the main one I've seen is reporting things as big endian
> instead of native endian to cause two layers of translation to kick in) and 
> one
> that was trying to use regmap to represent something that just fundamentally
> wasn't a regmap so *any* change in regmap internals was risky.

I was testing HDMI patches on latest "drm-next" branch, and found that it is 
not work.
And then I found the base tree was not working too. Then I debugged the base 
tree.

I read out the value of relevant register using "CodeWarrior TAP", find that 
endianness is not right.

Then I changed endianness of the value to be written that using " regmap_write" 
. It works.
But "regmap_update_bits" still have the problem.

I had checked log of regmap, and didn't find which commit caused that.

I am not familiar with regmap, can you give some advices?

Thanks,
Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-25 Thread Meng Yi
Hi Alexander,

> From: Alexander Stein [mailto:alexander.st...@systec-electronic.com]
> Sent: Wednesday, May 25, 2016 4:32 PM
> To: Stefan Agner <ste...@agner.ch>
> Cc: Meng Yi <meng...@nxp.com>; dri-de...@lists.freedesktop.org; David Airlie
> <airl...@linux.ie>; airl...@redhat.com; linux-kernel@vger.kernel.org; Mark
> Brown <broo...@kernel.org>
> Subject: Re: fsl-dcu not works on latest "drm-next"
> 
> On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> > On 2016-05-24 19:14, Meng Yi wrote:
> > > I found that its regmap endianness issue, so I want to replace the
> > > "regmap".
> > Hm, replace with what? Note that we need some kind of endianness
> > convertion since the IP is big endian on LS1021a and little endian on
> > Vybrid (vf610).
> 
> Yep, regmap is required and was broken meanwhile but should be fixed now.
> See linked lkml post.
> 
> > Is it maybe just an issue with regmap/the big-endian property in the
> > device tree? Maybe this thread is interesting for you:
> > https://lkml.org/lkml/2016/3/23/233
> 
> AFAICT device tree should not been changed here. The "big-endian" property
> was there fromt he beginning.
> 
> > > I just tested the latest drm-next branch on Freescale/NXP
> > > ls1021a-twr, and got some log below. And fsl-dcu not works.
> > >
> > > Since "drm-next" merged some branch , use git bisect had some
> > > problem ,
> > >
> > > so I manually checked out that "fsl-dcu" works at
> > > d761701c55a99598477f3cb25c03d939a7711e74
> > >
> > > And not works now. some log below:
> 
> Which commit actually broke your kernel? And where to fetch it from? Is your
> problem really caused by regmap?

Since there are lots of merge commit, I had manually debugged that issue. And 
yes, it is caused by regmap.
I fetched the kernel from git://people.freedesktop.org/~airlied/linux

Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-25 Thread Meng Yi
Hi Alexander,

> From: Alexander Stein [mailto:alexander.st...@systec-electronic.com]
> Sent: Wednesday, May 25, 2016 4:32 PM
> To: Stefan Agner 
> Cc: Meng Yi ; dri-de...@lists.freedesktop.org; David Airlie
> ; airl...@redhat.com; linux-kernel@vger.kernel.org; Mark
> Brown 
> Subject: Re: fsl-dcu not works on latest "drm-next"
> 
> On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> > On 2016-05-24 19:14, Meng Yi wrote:
> > > I found that its regmap endianness issue, so I want to replace the
> > > "regmap".
> > Hm, replace with what? Note that we need some kind of endianness
> > convertion since the IP is big endian on LS1021a and little endian on
> > Vybrid (vf610).
> 
> Yep, regmap is required and was broken meanwhile but should be fixed now.
> See linked lkml post.
> 
> > Is it maybe just an issue with regmap/the big-endian property in the
> > device tree? Maybe this thread is interesting for you:
> > https://lkml.org/lkml/2016/3/23/233
> 
> AFAICT device tree should not been changed here. The "big-endian" property
> was there fromt he beginning.
> 
> > > I just tested the latest drm-next branch on Freescale/NXP
> > > ls1021a-twr, and got some log below. And fsl-dcu not works.
> > >
> > > Since "drm-next" merged some branch , use git bisect had some
> > > problem ,
> > >
> > > so I manually checked out that "fsl-dcu" works at
> > > d761701c55a99598477f3cb25c03d939a7711e74
> > >
> > > And not works now. some log below:
> 
> Which commit actually broke your kernel? And where to fetch it from? Is your
> problem really caused by regmap?

Since there are lots of merge commit, I had manually debugged that issue. And 
yes, it is caused by regmap.
I fetched the kernel from git://people.freedesktop.org/~airlied/linux

Best Regards,
Meng Yi


RE: fsl-dcu not works on latest "drm-next"

2016-05-24 Thread Meng Yi
I found that its regmap endianness issue, so I want to replace the "regmap".

Hi Stefan,
Do you have any idea about this?

Hi Mark,
Regmap endianness issue had caused some other drivers not work, like SPI etc. 
Or this is fixed and I just don't know?

Thanks,
Meng

-----
From: Meng Yi 
Sent: Tuesday, May 03, 2016 5:27 PM
To: 'dri-de...@lists.freedesktop.org' <dri-de...@lists.freedesktop.org>; David 
Airlie <airl...@linux.ie>; 'Stefan Agner' <ste...@agner.ch>; 
'airl...@redhat.com' <airl...@redhat.com>
Subject: fsl-dcu not works on latest "drm-next"

Hi,


I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and got 
some log below. And fsl-dcu not works.

Since "drm-next" merged some branch , use git bisect had some problem ,

so I manually checked out that "fsl-dcu" works at 
d761701c55a99598477f3cb25c03d939a7711e74

And not works now. some log below:



[drm] Initialized drm 1.1.0 20060810
panel supply power not found, using dummy regulator
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106 
drm_atomic_helper_wait_for_vblanks+0xff/0x124
[CRTC:24] vblank wait timed out
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
Hardware name: Freescale LS1021A
[<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
[<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
[<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
[<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
[<80211a7f>] (warn_slowpath_fmt) from [<803ca887>] 
(drm_atomic_helper_wait_for_vblanks+0xff/0x124)
[<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>] 
(drm_atomic_helper_commit+0x43/0x5c)
[<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>] 
(restore_fbdev_mode+0xad/0x16e)
[<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>] 
(drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
[<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<803ccf9d>] 
(drm_fb_helper_set_par+0x25/0x38)
[<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
[<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
[<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
[<803b6f95>] (do_bind_con_driver) from [<803b7287>] 
(do_take_over_console+0xcf/0x108)
[<803b7287>] (do_take_over_console) from [<80397549>] 
(do_fbcon_takeover+0x35/0x7c)
[<80397549>] (do_fbcon_takeover) from [<802229db>] 
(notifier_call_chain+0x23/0x38)
[<802229db>] (notifier_call_chain) from [<80222b63>] 
(__blocking_notifier_call_chain+0x27/0x36)
[<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>] 
(blocking_notifier_call_chain+0xf/0x14)
[<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>] 
(register_framebuffer+0x179/0x1d0)
[<8039bdf9>] (register_framebuffer) from [<803cd15f>] 
(drm_fb_helper_initial_config+0x1af/0x200)
[<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>] 
(drm_fbdev_cma_init+0x67/0xa8)
[<803cd593>] (drm_fbdev_cma_init) from [<803e2269>] 
(fsl_dcu_fbdev_init+0x11/0x14)
[<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
[<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
[<803d2d51>] (drm_dev_register) from [<803e1ab7>] 
(fsl_dcu_drm_probe+0x193/0x240)
[<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>] 
(platform_drv_probe+0x33/0x62)
[<803e6d2d>] (platform_drv_probe) from [<803e5e7d>] 
(driver_probe_device+0xb9/0x1a4)
[<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
[<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
[<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
[<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
[<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
[<80201517>] (do_one_initcall) from [<80800a61>] 
(kernel_init_freeable+0xd1/0x168)
[<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
[<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
---[ end trace b7946726c4e290c4 ]---
Console: switching to colour frame buffer device 60x34
fsl-dcu 2ce.dcu: fb0:  frame buffer device
[drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0


And full log in the attachment.

does anybody have any idea about this?

Best Regards,
Meng Yi



RE: fsl-dcu not works on latest "drm-next"

2016-05-24 Thread Meng Yi
I found that its regmap endianness issue, so I want to replace the "regmap".

Hi Stefan,
Do you have any idea about this?

Hi Mark,
Regmap endianness issue had caused some other drivers not work, like SPI etc. 
Or this is fixed and I just don't know?

Thanks,
Meng

-----
From: Meng Yi 
Sent: Tuesday, May 03, 2016 5:27 PM
To: 'dri-de...@lists.freedesktop.org' ; David 
Airlie ; 'Stefan Agner' ; 
'airl...@redhat.com' 
Subject: fsl-dcu not works on latest "drm-next"

Hi,


I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and got 
some log below. And fsl-dcu not works.

Since "drm-next" merged some branch , use git bisect had some problem ,

so I manually checked out that "fsl-dcu" works at 
d761701c55a99598477f3cb25c03d939a7711e74

And not works now. some log below:



[drm] Initialized drm 1.1.0 20060810
panel supply power not found, using dummy regulator
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106 
drm_atomic_helper_wait_for_vblanks+0xff/0x124
[CRTC:24] vblank wait timed out
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
Hardware name: Freescale LS1021A
[<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
[<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
[<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
[<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
[<80211a7f>] (warn_slowpath_fmt) from [<803ca887>] 
(drm_atomic_helper_wait_for_vblanks+0xff/0x124)
[<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>] 
(drm_atomic_helper_commit+0x43/0x5c)
[<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>] 
(restore_fbdev_mode+0xad/0x16e)
[<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>] 
(drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
[<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<803ccf9d>] 
(drm_fb_helper_set_par+0x25/0x38)
[<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
[<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
[<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
[<803b6f95>] (do_bind_con_driver) from [<803b7287>] 
(do_take_over_console+0xcf/0x108)
[<803b7287>] (do_take_over_console) from [<80397549>] 
(do_fbcon_takeover+0x35/0x7c)
[<80397549>] (do_fbcon_takeover) from [<802229db>] 
(notifier_call_chain+0x23/0x38)
[<802229db>] (notifier_call_chain) from [<80222b63>] 
(__blocking_notifier_call_chain+0x27/0x36)
[<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>] 
(blocking_notifier_call_chain+0xf/0x14)
[<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>] 
(register_framebuffer+0x179/0x1d0)
[<8039bdf9>] (register_framebuffer) from [<803cd15f>] 
(drm_fb_helper_initial_config+0x1af/0x200)
[<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>] 
(drm_fbdev_cma_init+0x67/0xa8)
[<803cd593>] (drm_fbdev_cma_init) from [<803e2269>] 
(fsl_dcu_fbdev_init+0x11/0x14)
[<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
[<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
[<803d2d51>] (drm_dev_register) from [<803e1ab7>] 
(fsl_dcu_drm_probe+0x193/0x240)
[<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>] 
(platform_drv_probe+0x33/0x62)
[<803e6d2d>] (platform_drv_probe) from [<803e5e7d>] 
(driver_probe_device+0xb9/0x1a4)
[<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
[<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
[<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
[<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
[<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
[<80201517>] (do_one_initcall) from [<80800a61>] 
(kernel_init_freeable+0xd1/0x168)
[<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
[<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
---[ end trace b7946726c4e290c4 ]---
Console: switching to colour frame buffer device 60x34
fsl-dcu 2ce.dcu: fb0:  frame buffer device
[drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0


And full log in the attachment.

does anybody have any idea about this?

Best Regards,
Meng Yi



[PATCH 2/2] ARM: dts: ls1021a: Add a TFT LCD panel.

2015-11-24 Thread Meng Yi
Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index fbb89d1..fad2e3b 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -105,6 +105,17 @@
bitclock-master;
};
};
+
+   panel: panel {
+   compatible = "nec,nl4827hc19-05b";
+   };
+
+};
+
+ {
+   fsl,panel = <>;
+   status = "okay";
+
 };
 
  {
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/2] ARM: dts: ls1021a: Add DCU dts node.

2015-11-24 Thread Meng Yi
Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9430a99..f01c98b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -428,6 +428,16 @@
 <_clk 1>;
};
 
+   dcu: dcu@2ce {
+   compatible = "fsl,ls1021a-dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   interrupts = ;
+   clocks = <_clk 0>;
+   clock-names = "dcu";
+   big-endian;
+   status = "disabled";
+   };
+
mdio0: mdio@2d24000 {
compatible = "gianfar";
device_type = "mdio";
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/2] ARM: dts: ls1021a: Add DCU dts node.

2015-11-24 Thread Meng Yi
Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9430a99..f01c98b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -428,6 +428,16 @@
 <_clk 1>;
};
 
+   dcu: dcu@2ce {
+   compatible = "fsl,ls1021a-dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   interrupts = ;
+   clocks = <_clk 0>;
+   clock-names = "dcu";
+   big-endian;
+   status = "disabled";
+   };
+
mdio0: mdio@2d24000 {
compatible = "gianfar";
device_type = "mdio";
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/2] ARM: dts: ls1021a: Add a TFT LCD panel.

2015-11-24 Thread Meng Yi
Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index fbb89d1..fad2e3b 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -105,6 +105,17 @@
bitclock-master;
};
};
+
+   panel: panel {
+   compatible = "nec,nl4827hc19-05b";
+   };
+
+};
+
+ {
+   fsl,panel = <>;
+   status = "okay";
+
 };
 
  {
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/