Re: [RFC] ITS fails to allocate on rk3568/rk3566

[Kever Yang]

Hi Marc,

On 2021/4/15 下午4:11, Marc Zyngier wrote:

Hi Kever,

On Thu, 15 Apr 2021 08:24:33 +0100,
Kever Yang  wrote:

Hi Marc, Peter,

     RK356x GIC has two issues:

1. GIC only support 32bit address while rk356x supports 8GB DDR SDRAM,
so we use ZONE_DMA32 to fix this issue;

What transactions does this affect exactly?
The GIC on rk356x is a 32bit master, which means all the space its logic 
need to access should be in the 4GB range.

Only some ITS tables? Or
all of them, including the command queue? What about the configuration
and pending tables associated with the redistributors?


2. GIC version is r1p6-00rel0, RK356x interconnect does not support
GIC and CPU snoop to each other, hence the GIC does not support the
shareability feature.  The read of register value for shareability
feature does not return as expect in GICR and GITS, so we have to
workaround for it.

How about the cacheability attribute? Can you please provide the exact
set of attributes that this system actually supports for each of the
ITS and redistributor base registers?


The shareability attributes in GICR_PENDBASEER, GICR_PROPBASER, 
GITS_BASERn, GITS_CBASER default value is 0b00, when we set 0b01 then 
read returns 0b01.


Since there is no ACE coherency interface for this GIC controller, all 
the cacheability in the GIC is not support in hardware.




Also, please provide errata numbers for these two issues so that we
can properly document them and track the workarounds.


What kind of errata do you need, could you please share any kind of 
example close to this case?


We consider this as a SoC implement design instead of a bug, so we will 
add document in RK356X  TRM to describe the GIC design, but no idea how 
to provide the errata.


Here is the shareabily attribute from ARM GIC architecture specification:
Shareability, bits [11:10] (from GITS_CBASER)
Indicates the Shareability attributes of accesses to the command queue. 
The possible values of this field are:

0b00 Non-shareable.
0b01 Inner Shareable.
0b10 Outer Shareable.
0b11 Reserved. Treated as 0b00.
It is IMPLEMENTATION DEFINED whether this field has a fixed value or can 
be programmed by software. Implementing this field with a fixed value is 
deprecated.

On a Warm reset, this field resets to an architecturally UNKNOWN value

As you can see, "Implementing this field with a fixed value is 
deprecated", so software should program this field to '0b00 
Non-shareable' if the SoC design does not support the cache shareability.


Thanks,
- Kever


Thanks,

M.

Re: [RFC] ITS fails to allocate on rk3568/rk3566

[Kever Yang]

Hi Marc, Peter,

    RK356x GIC has two issues:

1. GIC only support 32bit address while rk356x supports 8GB DDR SDRAM, 
so we use ZONE_DMA32 to fix this issue;


2. GIC version is r1p6-00rel0, RK356x interconnect does not support GIC 
and CPU snoop to each other, hence the GIC does not support the 
shareability feature.  The read of register value for shareability  
feature does not return as expect in GICR and GITS, so we have to 
workaround for it.


Thanks,
- Kever
On 2021/4/14 下午8:42, Marc Zyngier wrote:

On Wed, 14 Apr 2021 12:41:20 +0100,
Peter Geis  wrote:

On Tue, Apr 13, 2021 at 11:51 AM Marc Zyngier  wrote:

On Tue, 13 Apr 2021 16:03:51 +0100,
Peter Geis  wrote:

On Tue, Apr 13, 2021 at 10:01 AM Marc Zyngier  wrote:

[...]


What happens if you hack all the allocations to happen in the low 4GB
of the PA space?

It seems to work correctly.
The downstream hacks used GFP_DMA32 which gets discarded by
kmalloc_fix_flags on certain allocations.
Switching to GFP_DMA seems to have satisfied it, but it feels wrong
using this code.
Need to check the corner cases to make sure I'm not missing something.

The problem is that GFP_DMA doesn't always mean the same thing.
Overall, we need to hear from Rockchip about the exact nature of the
problem, and then we *may* be able to work something out.

 From what I've read, GFP_DMA allocates as low as possible, while
GFP_DMA32 ensures it's in the 32 bit address range, am I understanding
this correctly?

ZONE_DMA{,32} aren't necessarily selected, and can vary in size (some
equally broken systems can only DMA over 30bits...).


Is there a reason GFP_DMA is permitted while GFP_DMA32 is not, aside
from backwards compatibility?  (I saw the notes about how we aren't
really supposed to rely on these flags)

They are completely independent, and they can either be selected or
not. And plenty of systems do not have any memory in the low
4GB. FWIW, one of my main machines has its first byte of RAM at 1TB.

Which means that supporting this system is going to require some very
specific handling.


I've also confirmed that their disabling shareability and caching is
necessary.

Confirmed how? For which tables? We really cannot guess this kind of
thing.


I'd also like to understand whether it is broken because you happen to
have pre-release silicon that will never make it into the wild, or if
this is the real thing that is going to ship on millions of devices.

My understanding is these chips are samples prior to the full
production run, but we are waiting on official comment from Rockchip
about this particular errata.

OK. Please let me know once you get a full description of the problem
from Rockchip. We will also need an official erratum number for this
if this is to be worked around in mainline.

M.

Re: [PATCH v3 4/4] clk: rockchip: add clock controller for rk3568

[Kever Yang]

On 2021/3/1 下午2:47, Elaine Zhang wrote:

Add the clock tree definition for the new rk3568 SoC.

Signed-off-by: Elaine Zhang 


Patch looks good to me.

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/clk/rockchip/Kconfig  |7 +
  drivers/clk/rockchip/Makefile |1 +
  drivers/clk/rockchip/clk-rk3568.c | 1726 +
  drivers/clk/rockchip/clk.h|   30 +-
  4 files changed, 1763 insertions(+), 1 deletion(-)
  create mode 100644 drivers/clk/rockchip/clk-rk3568.c

diff --git a/drivers/clk/rockchip/Kconfig b/drivers/clk/rockchip/Kconfig
index effd05032e85..2e31901f4213 100644
--- a/drivers/clk/rockchip/Kconfig
+++ b/drivers/clk/rockchip/Kconfig
@@ -85,4 +85,11 @@ config CLK_RK3399
default y
help
  Build the driver for RK3399 Clock Driver.
+
+config CLK_RK3568
+   tristate "Rockchip RK3568 clock controller support"
+   depends on (ARM64 || COMPILE_TEST)
+   default y
+   help
+ Build the driver for RK3568 Clock Driver.
  endif
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index a99e4d9bbae1..2b78f1247372 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_CLK_RK3308)+= clk-rk3308.o
  obj-$(CONFIG_CLK_RK3328)+= clk-rk3328.o
  obj-$(CONFIG_CLK_RK3368)+= clk-rk3368.o
  obj-$(CONFIG_CLK_RK3399)+= clk-rk3399.o
+obj-$(CONFIG_CLK_RK3568)   += clk-rk3568.o
diff --git a/drivers/clk/rockchip/clk-rk3568.c 
b/drivers/clk/rockchip/clk-rk3568.c
new file mode 100644
index ..60913aa91897
--- /dev/null
+++ b/drivers/clk/rockchip/clk-rk3568.c
@@ -0,0 +1,1726 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co. Ltd.
+ * Author: Elaine Zhang 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "clk.h"
+
+#define RK3568_GRF_SOC_STATUS0 0x580
+
+enum rk3568_pmu_plls {
+   ppll, hpll,
+};
+
+enum rk3568_plls {
+   apll, dpll, gpll, cpll, npll, vpll,
+};
+
+static struct rockchip_pll_rate_table rk3568_pll_rates[] = {
+   /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+   RK3036_PLL_RATE(220800, 1, 92, 1, 1, 1, 0),
+   RK3036_PLL_RATE(218400, 1, 91, 1, 1, 1, 0),
+   RK3036_PLL_RATE(216000, 1, 90, 1, 1, 1, 0),
+   RK3036_PLL_RATE(208800, 1, 87, 1, 1, 1, 0),
+   RK3036_PLL_RATE(206400, 1, 86, 1, 1, 1, 0),
+   RK3036_PLL_RATE(204000, 1, 85, 1, 1, 1, 0),
+   RK3036_PLL_RATE(201600, 1, 84, 1, 1, 1, 0),
+   RK3036_PLL_RATE(199200, 1, 83, 1, 1, 1, 0),
+   RK3036_PLL_RATE(192000, 1, 80, 1, 1, 1, 0),
+   RK3036_PLL_RATE(189600, 1, 79, 1, 1, 1, 0),
+   RK3036_PLL_RATE(18, 1, 75, 1, 1, 1, 0),
+   RK3036_PLL_RATE(170400, 1, 71, 1, 1, 1, 0),
+   RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+   RK3036_PLL_RATE(16, 3, 200, 1, 1, 1, 0),
+   RK3036_PLL_RATE(158400, 1, 132, 2, 1, 1, 0),
+   RK3036_PLL_RATE(156000, 1, 130, 2, 1, 1, 0),
+   RK3036_PLL_RATE(153600, 1, 128, 2, 1, 1, 0),
+   RK3036_PLL_RATE(151200, 1, 126, 2, 1, 1, 0),
+   RK3036_PLL_RATE(148800, 1, 124, 2, 1, 1, 0),
+   RK3036_PLL_RATE(146400, 1, 122, 2, 1, 1, 0),
+   RK3036_PLL_RATE(144000, 1, 120, 2, 1, 1, 0),
+   RK3036_PLL_RATE(141600, 1, 118, 2, 1, 1, 0),
+   RK3036_PLL_RATE(14, 3, 350, 2, 1, 1, 0),
+   RK3036_PLL_RATE(139200, 1, 116, 2, 1, 1, 0),
+   RK3036_PLL_RATE(136800, 1, 114, 2, 1, 1, 0),
+   RK3036_PLL_RATE(134400, 1, 112, 2, 1, 1, 0),
+   RK3036_PLL_RATE(132000, 1, 110, 2, 1, 1, 0),
+   RK3036_PLL_RATE(129600, 1, 108, 2, 1, 1, 0),
+   RK3036_PLL_RATE(127200, 1, 106, 2, 1, 1, 0),
+   RK3036_PLL_RATE(124800, 1, 104, 2, 1, 1, 0),
+   RK3036_PLL_RATE(12, 1, 100, 2, 1, 1, 0),
+   RK3036_PLL_RATE(118800, 1, 99, 2, 1, 1, 0),
+   RK3036_PLL_RATE(110400, 1, 92, 2, 1, 1, 0),
+   RK3036_PLL_RATE(11, 3, 275, 2, 1, 1, 0),
+   RK3036_PLL_RATE(100800, 1, 84, 2, 1, 1, 0),
+   RK3036_PLL_RATE(10, 3, 250, 2, 1, 1, 0),
+   RK3036_PLL_RATE(91200, 1, 76, 2, 1, 1, 0),
+   RK3036_PLL_RATE(81600, 1, 68, 2, 1, 1, 0),
+   RK3036_PLL_RATE(8, 3, 200, 2, 1, 1, 0),
+   RK3036_PLL_RATE(7, 3, 350, 4, 1, 1, 0),
+   RK3036_PLL_RATE(69600, 1, 116, 4, 1, 1, 0),
+   RK3036_PLL_RATE(6, 1, 100, 4, 1, 1, 0),
+   RK3036_PLL_RATE(59400, 1, 99, 4, 1, 1, 0),
+   RK3036_PLL_RATE(5, 1, 125, 6, 1, 1, 0),
+   RK3036_PLL_RATE(40800, 1, 68, 2, 2, 1, 0),
+   RK3036_PLL_RATE(31200, 1, 78, 6, 1, 1, 0),
+   RK3036_PLL_RATE(21600, 1, 72, 4, 2, 1, 0),
+   RK3036_PLL_RATE(2, 1, 100, 3, 4, 1, 0),
+   RK3036_PLL_RATE(1485

Re: [PATCH v3 2/4] clk: rockchip: add dt-binding header for rk3568

[Kever Yang]

On 2021/3/1 下午2:47, Elaine Zhang wrote:

Add the dt-bindings header for the rk3568, that gets shared between
the clock controller and the clock references in the dts.
Add softreset ID for rk3568.

Signed-off-by: Elaine Zhang 


Patch looks good to me.

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  include/dt-bindings/clock/rk3568-cru.h | 926 +
  1 file changed, 926 insertions(+)
  create mode 100644 include/dt-bindings/clock/rk3568-cru.h

diff --git a/include/dt-bindings/clock/rk3568-cru.h 
b/include/dt-bindings/clock/rk3568-cru.h
new file mode 100644
index ..d29890865150
--- /dev/null
+++ b/include/dt-bindings/clock/rk3568-cru.h
@@ -0,0 +1,926 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co. Ltd.
+ * Author: Elaine Zhang 
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3568_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3568_H
+
+/* pmucru-clocks indices */
+
+/* pmucru plls */
+#define PLL_PPLL   1
+#define PLL_HPLL   2
+
+/* pmucru clocks */
+#define XIN_OSC0_DIV   4
+#define CLK_RTC_32K5
+#define CLK_PMU6
+#define CLK_I2C0   7
+#define CLK_RTC32K_FRAC8
+#define CLK_UART0_DIV  9
+#define CLK_UART0_FRAC 10
+#define SCLK_UART0 11
+#define DBCLK_GPIO012
+#define CLK_PWM0   13
+#define CLK_CAPTURE_PWM0_NDFT  14
+#define CLK_PMUPVTM15
+#define CLK_CORE_PMUPVTM   16
+#define CLK_REF24M 17
+#define XIN_OSC0_USBPHY0_G 18
+#define CLK_USBPHY0_REF19
+#define XIN_OSC0_USBPHY1_G 20
+#define CLK_USBPHY1_REF21
+#define XIN_OSC0_MIPIDSIPHY0_G 22
+#define CLK_MIPIDSIPHY0_REF23
+#define XIN_OSC0_MIPIDSIPHY1_G 24
+#define CLK_MIPIDSIPHY1_REF25
+#define CLK_WIFI_DIV   26
+#define CLK_WIFI_OSC0  27
+#define CLK_WIFI   28
+#define CLK_PCIEPHY0_DIV   29
+#define CLK_PCIEPHY0_OSC0  30
+#define CLK_PCIEPHY0_REF   31
+#define CLK_PCIEPHY1_DIV   32
+#define CLK_PCIEPHY1_OSC0  33
+#define CLK_PCIEPHY1_REF   34
+#define CLK_PCIEPHY2_DIV   35
+#define CLK_PCIEPHY2_OSC0  36
+#define CLK_PCIEPHY2_REF   37
+#define CLK_PCIE30PHY_REF_M38
+#define CLK_PCIE30PHY_REF_N39
+#define CLK_HDMI_REF   40
+#define XIN_OSC0_EDPPHY_G  41
+#define PCLK_PDPMU 42
+#define PCLK_PMU   43
+#define PCLK_UART0 44
+#define PCLK_I2C0  45
+#define PCLK_GPIO0 46
+#define PCLK_PMUPVTM   47
+#define PCLK_PWM0  48
+#define CLK_PDPMU  49
+#define SCLK_32K_IOE   50
+
+#define CLKPMU_NR_CLKS (SCLK_32K_IOE + 1)
+
+/* cru-clocks indices */
+
+/* cru plls */
+#define PLL_APLL   1
+#define PLL_DPLL   2
+#define PLL_CPLL   3
+#define PLL_GPLL   4
+#define PLL_VPLL   5
+#define PLL_NPLL   6
+
+/* cru clocks */
+#define CPLL_333M  9
+#define ARMCLK 10
+#define USB480M11
+#define ACLK_CORE_NIU2BUS  18
+#define CLK_CORE_PVTM  19
+#define CLK_CORE_PVTM_CORE 20
+#define CLK_CORE_PVTPLL21
+#define CLK_GPU_SRC22
+#define CLK_GPU_PRE_NDFT   23
+#define CLK_GPU_PRE_MUX24
+#define ACLK_GPU_PRE   25
+#define PCLK_GPU_PRE   26
+#define CLK_GPU27
+#define CLK_GPU_NP528
+#define PCLK_GPU_PVTM  29
+#define CLK_GPU_PVTM   30
+#define CLK_GPU_PVTM_CORE  31
+#define CLK_GPU_PVTPLL 32
+#define CLK_NPU_SRC33
+#define CLK_NPU_PRE_NDFT   34
+#define CLK_NPU35
+#define CLK_NPU_NP536
+#define HCLK_NPU_PRE   37
+#define PCLK_NPU_PRE   38
+#define ACLK_NPU_PRE   39
+#define ACLK_NPU   40
+#define HCLK_NPU   41
+#define PCLK_NPU_PVTM  42
+#define CLK_NPU_PVTM   43
+#define CLK_NPU_PVTM_CORE  44
+#define CLK_NPU_PVTPLL 45
+#define CLK_DDRPHY1X_SRC   46
+#define CLK_DDRPHY1X_HWFFC_SRC 47
+#define CLK_DDR1X  48
+#define CLK_MSCH   49
+#define CLK24_DDRMON   50
+#define ACLK_GIC_AUDIO 51
+#define HCLK_GIC_AUDIO 52
+#define HCLK_SDMMC_BUFFER  53
+#define DCLK_SDMMC_BUFFER  54
+#define ACLK_GIC60055
+#define ACLK_SPINLOCK  56
+#define HCLK_I2S0_8CH  57
+#define HCLK_I2S1_8CH  58
+#define HCLK_I2S2_2CH  59
+#define HCLK_I2S3_2CH  60
+#define CLK_I2S0_8CH_TX_SRC61
+#define CLK_I2S0_8CH_TX_FRAC   62
+#define MCLK_I2S0_8CH_TX   63
+#define I2S0_MCLKOUT_TX64
+#define CLK_I2S0_8CH_RX_SRC65
+#define CLK_I2S0_8CH_RX_FRAC   66
+#define MCLK_I2S0_8CH_RX   67
+#define I2S0_MCLKOUT_RX68

Re: [PATCH v3 3/4] clk: rockchip: support more core div setting

[Kever Yang]

On 2021/3/1 下午2:47, Elaine Zhang wrote:

Use arrays to support more core independent div settings.
A55 supports each core to work at different frequencies, and each core
has an independent divider control.

Signed-off-by: Elaine Zhang 


Patch looks good to me.

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/clk/rockchip/clk-cpu.c| 53 +--
  drivers/clk/rockchip/clk-px30.c   |  7 ++--
  drivers/clk/rockchip/clk-rk3036.c |  7 ++--
  drivers/clk/rockchip/clk-rk3128.c |  7 ++--
  drivers/clk/rockchip/clk-rk3188.c |  7 ++--
  drivers/clk/rockchip/clk-rk3228.c |  7 ++--
  drivers/clk/rockchip/clk-rk3288.c |  7 ++--
  drivers/clk/rockchip/clk-rk3308.c |  7 ++--
  drivers/clk/rockchip/clk-rk3328.c |  7 ++--
  drivers/clk/rockchip/clk-rk3368.c | 14 
  drivers/clk/rockchip/clk-rk3399.c | 14 
  drivers/clk/rockchip/clk-rv1108.c |  7 ++--
  drivers/clk/rockchip/clk.h| 24 +++---
  13 files changed, 94 insertions(+), 74 deletions(-)

diff --git a/drivers/clk/rockchip/clk-cpu.c b/drivers/clk/rockchip/clk-cpu.c
index fa9027fb1920..47288197c9d7 100644
--- a/drivers/clk/rockchip/clk-cpu.c
+++ b/drivers/clk/rockchip/clk-cpu.c
@@ -84,10 +84,10 @@ static unsigned long rockchip_cpuclk_recalc_rate(struct 
clk_hw *hw,
  {
struct rockchip_cpuclk *cpuclk = to_rockchip_cpuclk_hw(hw);
const struct rockchip_cpuclk_reg_data *reg_data = cpuclk->reg_data;
-   u32 clksel0 = readl_relaxed(cpuclk->reg_base + reg_data->core_reg);
+   u32 clksel0 = readl_relaxed(cpuclk->reg_base + reg_data->core_reg[0]);
  
-	clksel0 >>= reg_data->div_core_shift;

-   clksel0 &= reg_data->div_core_mask;
+   clksel0 >>= reg_data->div_core_shift[0];
+   clksel0 &= reg_data->div_core_mask[0];
return parent_rate / (clksel0 + 1);
  }
  
@@ -120,6 +120,7 @@ static int rockchip_cpuclk_pre_rate_change(struct rockchip_cpuclk *cpuclk,

const struct rockchip_cpuclk_rate_table *rate;
unsigned long alt_prate, alt_div;
unsigned long flags;
+   int i = 0;
  
  	/* check validity of the new rate */

rate = rockchip_get_cpuclk_settings(cpuclk, ndata->new_rate);
@@ -142,10 +143,10 @@ static int rockchip_cpuclk_pre_rate_change(struct 
rockchip_cpuclk *cpuclk,
if (alt_prate > ndata->old_rate) {
/* calculate dividers */
alt_div =  DIV_ROUND_UP(alt_prate, ndata->old_rate) - 1;
-   if (alt_div > reg_data->div_core_mask) {
+   if (alt_div > reg_data->div_core_mask[0]) {
pr_warn("%s: limiting alt-divider %lu to %d\n",
-   __func__, alt_div, reg_data->div_core_mask);
-   alt_div = reg_data->div_core_mask;
+   __func__, alt_div, reg_data->div_core_mask[0]);
+   alt_div = reg_data->div_core_mask[0];
}
  
  		/*

@@ -158,19 +159,17 @@ static int rockchip_cpuclk_pre_rate_change(struct 
rockchip_cpuclk *cpuclk,
pr_debug("%s: setting div %lu as alt-rate %lu > old-rate %lu\n",
 __func__, alt_div, alt_prate, ndata->old_rate);
  
-		writel(HIWORD_UPDATE(alt_div, reg_data->div_core_mask,

- reg_data->div_core_shift) |
-  HIWORD_UPDATE(reg_data->mux_core_alt,
-reg_data->mux_core_mask,
-reg_data->mux_core_shift),
-  cpuclk->reg_base + reg_data->core_reg);
-   } else {
-   /* select alternate parent */
-   writel(HIWORD_UPDATE(reg_data->mux_core_alt,
-reg_data->mux_core_mask,
-reg_data->mux_core_shift),
-  cpuclk->reg_base + reg_data->core_reg);
+   for (i = 0; i < reg_data->num_cores; i++) {
+   writel(HIWORD_UPDATE(alt_div, 
reg_data->div_core_mask[i],
+reg_data->div_core_shift[i]),
+  cpuclk->reg_base + reg_data->core_reg[i]);
+   }
}
+   /* select alternate parent */
+   writel(HIWORD_UPDATE(reg_data->mux_core_alt,
+reg_data->mux_core_mask,
+reg_data->mux_core_shift),
+  cpuclk->reg_base + reg_data->core_reg[0]);
  
  	spin_unlock_irqrestore(cpuclk->lock, flags);

return 0;
@@ -182,6 +181,7 @@ static int rockchip_cpuclk_post_rate_change(struct 
rockchip_cpuclk *cpuclk,
const struct rockchip_cpuclk_reg_data *reg_data = cpuclk->reg_data;
const struct rockchip_cpuclk_rate_table *rate;
unsigned long flags;
+   int i = 0;
  

Re: [PATCH v3 1/4] dt-binding: clock: Document rockchip,rk3568-cru bindings

[Kever Yang]

On 2021/3/1 下午2:47, Elaine Zhang wrote:

Document the device tree bindings of the rockchip Rk3568 SoC
clock driver in 
Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml.

Signed-off-by: Elaine Zhang 


Patch looks good to me.

Reviewed-by: Kever Yang <mailto:kever.y...@rock-chips.com>>


Thanks,
- Kever

---
  .../bindings/clock/rockchip,rk3568-cru.yaml   | 60 +++
  1 file changed, 60 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml 
b/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml
new file mode 100644
index ..b2c26097827f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rk3568-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROCKCHIP rk3568 Family Clock Control Module Binding
+
+maintainers:
+  - Elaine Zhang 
+  - Heiko Stuebner 
+
+description: |
+  The RK3568 clock controller generates the clock and also implements a
+  reset controller for SoC peripherals.
+  (examples: provide SCLK_UART1\PCLK_UART1 and SRST_P_UART1\SRST_S_UART1 for 
UART module)
+  Each clock is assigned an identifier and client nodes can use this identifier
+  to specify the clock which they consume. All available clocks are defined as
+  preprocessor macros in the dt-bindings/clock/rk3568-cru.h headers and can be
+  used in device tree sources.
+
+properties:
+  compatible:
+enum:
+  - rockchip,rk3568-cru
+  - rockchip,rk3568-pmucru
+
+  reg:
+maxItems: 1
+
+  "#clock-cells":
+const: 1
+
+  "#reset-cells":
+const: 1
+
+required:
+  - compatible
+  - reg
+  - "#clock-cells"
+  - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+  # Clock Control Module node:
+  - |
+pmucru: clock-controller@fdd0 {
+  compatible = "rockchip,rk3568-pmucru";
+  reg = <0xfdd0 0x1000>;
+  #clock-cells = <1>;
+  #reset-cells = <1>;
+};
+  - |
+cru: clock-controller@fdd2 {
+  compatible = "rockchip,rk3568-cru";
+  reg = <0xfdd2 0x1000>;
+  #clock-cells = <1>;
+  #reset-cells = <1>;
+};

Re: [PATCH v2] drm/of: Consider the state in which the ep is disabled

[Kever Yang]

Hi Daniel,

On 2020/10/15 下午11:23, Daniel Vetter wrote:

On Wed, Oct 14, 2020 at 09:48:43AM +0800, Kever Yang wrote:

Hi Maintainers,

     Does this patch ready to merge?

Would maybe be good to get some acks from other drivers using this, then
Sandy can push to drm-misc-next.


Thanks for your reply, I can understand more 'acks' will be better, but 
there is no comments object to this patch


or any 'NAK' common for more then 3 months, maintainers should move to 
next step.



Thanks,

- Kever


-Daniel

On 2020/7/7 下午7:25, Sandy Huang wrote:

don't mask possible_crtcs if remote-point is disabled.

Signed-off-by: Sandy Huang 
---
   drivers/gpu/drm/drm_of.c | 3 +++
   1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index fdb05fbf72a0..565f05f5f11b 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -66,6 +66,9 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
uint32_t possible_crtcs = 0;
for_each_endpoint_of_node(port, ep) {
+   if (!of_device_is_available(ep))
+   continue;
+
remote_port = of_graph_get_remote_port(ep);
if (!remote_port) {
of_node_put(ep);

Looks good to me.


Reviewed-by: Kever Yang 

Re: [PATCH v2] drm/of: Consider the state in which the ep is disabled

[Kever Yang]

Hi Maintainers,

    Does this patch ready to merge?

On 2020/7/7 下午7:25, Sandy Huang wrote:

don't mask possible_crtcs if remote-point is disabled.

Signed-off-by: Sandy Huang 
---
  drivers/gpu/drm/drm_of.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index fdb05fbf72a0..565f05f5f11b 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -66,6 +66,9 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
uint32_t possible_crtcs = 0;
  
  	for_each_endpoint_of_node(port, ep) {

+   if (!of_device_is_available(ep))
+   continue;
+
remote_port = of_graph_get_remote_port(ep);
if (!remote_port) {
of_node_put(ep);


Looks good to me.


Reviewed-by: Kever Yang 

Thanks,
- Kever

Re: [PATCH v10 0/8] Add Rockchip NFC drivers for RK3308 and others

[Kever Yang]

Hi Miquel and maintainers,

    This patch set seems ready for upstream, could you pick and merge 
to linux-mtd?



Thanks,

- Kever

On 2020/9/30 上午10:07, Yifeng Zhao wrote:

Rockchp's NFC(Nand Flash Controller) has four versions: V600, V622, V800 and
V900.This series patch can support all four versions.


Changes in v10:
- Fix compile error on master v5.9-rc7

Changes in v9:
- The nfc->buffer will realloc while the page size of the second mtd
   is large than the first one
- Fix coding style.
- Remove struct rk_nfc_clk.
- Prepend some function with rk_nfc_.
- Replace function readl_poll_timeout_atomic with readl_relaxed_poll_timeout.
- Remove function rk_nfc_read_byte and rk_nfc_write_byte.
- Don't select the die if 'check_only == true' in function rk_nfc_exec_op.
- Modify function rk_nfc_write_page and rk_nfc_write_page_raw.

Changes in v8:
- Fix make dt_binding_check error

Changes in v7:
- Fix some wrong define
- Rebase to linux-next.
- Fix coding style.
- Reserved 4 bytes at the beginning of the oob area.
- Page raw read and write included ecc data.

Changes in v6:
- Fix some wrong define
- Modified the definition of compatible
- The mtd->name set by NAND label property.
- Add some comments.
- Fix compile error.

Changes in v5:
- Fix some wrong define.
- Add boot-medium define.
- Remove some compatible define.
- Add boot blocks support  with different ECC for bootROM.
- Rename rockchip-nand.c to rockchip-nand-controller.c.
- Unification of other variable names.
- Remove some compatible define.

Changes in v4:
- The compatible define with rkxx_nfc.
- Add assigned-clocks.
- Fix some wrong defineChanges in.
- Define platform data structure for the register offsets.
- The compatible define with rkxx_nfc.
- Use SET_SYSTEM_SLEEP_PM_OPS to define PM_OPS.
- Use exec_op instead of legacy hooks.

Changes in v3:
- Change the title for the dt-bindings.

Changes in v2:
- Fix compile error.
- Include header files sorted by file name.

Yifeng Zhao (8):
   dt-bindings: mtd: Describe Rockchip RK3xxx NAND flash controller
   mtd: rawnand: rockchip: NFC drivers for RK3308, RK2928 and others
   MAINTAINERS: add maintainers to ROCKCHIP NFC
   arm64: dts: rockchip: Add NFC node for RK3308 SoC
   arm64: dts: rockchip: Add NFC node for PX30 SoC
   arm: dts: rockchip: Add NFC node for RV1108 SoC
   arm: dts: rockchip: Add NFC node for RK2928 and other SoCs
   arm: dts: rockchip: Add NFC node for RK3036 SoC

  .../mtd/rockchip,nand-controller.yaml |  162 ++
  MAINTAINERS   |4 +-
  arch/arm/boot/dts/rk3036.dtsi |   52 +
  arch/arm/boot/dts/rk3xxx.dtsi |9 +
  arch/arm/boot/dts/rv1108.dtsi |   11 +
  arch/arm64/boot/dts/rockchip/px30.dtsi|   15 +
  arch/arm64/boot/dts/rockchip/rk3308.dtsi  |   15 +
  drivers/mtd/nand/raw/Kconfig  |   12 +
  drivers/mtd/nand/raw/Makefile |1 +
  .../mtd/nand/raw/rockchip-nand-controller.c   | 1455 +
  10 files changed, 1734 insertions(+), 2 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
  create mode 100644 drivers/mtd/nand/raw/rockchip-nand-controller.c

Re: [PATCH v10 8/8] arm: dts: rockchip: Add NFC node for RK3036 SoC

[Kever Yang]

On 2020/9/30 上午10:09, Yifeng Zhao wrote:

Add NAND FLASH Controller(NFC) node for RK3036 SoC.

Signed-off-by: Yifeng Zhao 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm/boot/dts/rk3036.dtsi | 52 +++
  1 file changed, 52 insertions(+)


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever



diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 093567022386..dda5a1f79aca 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -292,6 +292,21 @@
status = "disabled";
};
  
+	nfc: nand-controller@1050 {

+   compatible = "rockchip,rk3036-nfc",
+"rockchip,rk2928-nfc";
+   reg = <0x1050 0x4000>;
+   interrupts = ;
+   clocks = < HCLK_NANDC>, < SCLK_NANDC>;
+   clock-names = "ahb", "nfc";
+   assigned-clocks = < SCLK_NANDC>;
+   assigned-clock-rates = <15000>;
+   pinctrl-0 = <_ale _bus8 _cle _csn0
+_rdn _rdy _wrn>;
+   pinctrl-names = "default";
+   status = "disabled";
+   };
+
cru: clock-controller@2000 {
compatible = "rockchip,rk3036-cru";
reg = <0x2000 0x1000>;
@@ -643,6 +658,43 @@
};
};
  
+		nfc {

+   flash_ale: flash-ale {
+   rockchip,pins = <2 RK_PA0 1 _pull_default>;
+   };
+
+   flash_bus8: flash-bus8 {
+   rockchip,pins = <1 RK_PD0 1 _pull_default>,
+   <1 RK_PD1 1 _pull_default>,
+   <1 RK_PD2 1 _pull_default>,
+   <1 RK_PD3 1 _pull_default>,
+   <1 RK_PD4 1 _pull_default>,
+   <1 RK_PD5 1 _pull_default>,
+   <1 RK_PD6 1 _pull_default>,
+   <1 RK_PD7 1 _pull_default>;
+   };
+
+   flash_cle: flash-cle {
+   rockchip,pins = <2 RK_PA1 1 _pull_default>;
+   };
+
+   flash_csn0: flash-csn0 {
+   rockchip,pins = <2 RK_PA6 1 _pull_default>;
+   };
+
+   flash_rdn: flash-rdn {
+   rockchip,pins = <2 RK_PA3 1 _pull_default>;
+   };
+
+   flash_rdy: flash-rdy {
+   rockchip,pins = <2 RK_PA4 1 _pull_default>;
+   };
+
+   flash_wrn: flash-wrn {
+   rockchip,pins = <2 RK_PA2 1 _pull_default>;
+   };
+   };
+
emac {
emac_xfer: emac-xfer {
rockchip,pins = <2 RK_PB2 1 
_pull_default>, /* crs_dvalid */

Re: [PATCH v3 3/3] pinctrl: rockchip: create irq mapping in gpio_to_irq【请注意，邮件由linux-rockchip-bounces+kever.yang=rock-chips....@lists.infradead.org代发】

[Kever Yang]

On 2020/10/13 下午2:37, Jianqun Xu wrote:

Remove totally irq mappings create in probe, the gpio irq mapping will
be created when do
 gpio_to_irq ->
 rockchip_gpio_to_irq ->
 irq_create_mapping

This patch can speed up system boot on, also abandon many unused irq
mappings' create.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Jianqun Xu 
---
  drivers/pinctrl/pinctrl-rockchip.c | 28 
  1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index a2f361aa6d05..70dc03af5699 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -3198,7 +3198,7 @@ static void rockchip_irq_demux(struct irq_desc *desc)
  
  		irq = __ffs(pend);

pend &= ~BIT(irq);
-   virq = irq_linear_revmap(bank->domain, irq);
+   virq = irq_find_mapping(bank->domain, irq);
  
  		if (!virq) {

dev_err(bank->drvdata->dev, "unmapped irq %d\n", irq);
@@ -3377,7 +3377,7 @@ static int rockchip_interrupts_register(struct 
platform_device *pdev,
unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
struct irq_chip_generic *gc;
int ret;
-   int i, j;
+   int i;
  
  	for (i = 0; i < ctrl->nr_banks; ++i, ++bank) {

if (!bank->valid) {
@@ -3404,7 +3404,7 @@ static int rockchip_interrupts_register(struct 
platform_device *pdev,
  
  		ret = irq_alloc_domain_generic_chips(bank->domain, 32, 1,

 "rockchip_gpio_irq", handle_level_irq,
-clr, 0, IRQ_GC_INIT_MASK_CACHE);
+clr, 0, 0);
if (ret) {
dev_err(>dev, "could not alloc generic chips for bank 
%s\n",
bank->name);
@@ -3413,14 +3413,6 @@ static int rockchip_interrupts_register(struct 
platform_device *pdev,
continue;
}
  
-		/*

-* Linux assumes that all interrupts start out disabled/masked.
-* Our driver only uses the concept of masked and always keeps
-* things enabled, so for us that's all masked and all enabled.
-*/
-   writel_relaxed(0x, bank->reg_base + GPIO_INTMASK);
-   writel_relaxed(0x, bank->reg_base + GPIO_INTEN);
-
gc = irq_get_domain_generic_chip(bank->domain, 0);
gc->reg_base = bank->reg_base;
gc->private = bank;
@@ -3437,13 +3429,17 @@ static int rockchip_interrupts_register(struct 
platform_device *pdev,
gc->chip_types[0].chip.irq_set_type = rockchip_irq_set_type;
gc->wake_enabled = IRQ_MSK(bank->nr_pins);
  
+		/*

+* Linux assumes that all interrupts start out disabled/masked.
+* Our driver only uses the concept of masked and always keeps
+* things enabled, so for us that's all masked and all enabled.
+*/
+   writel_relaxed(0x, bank->reg_base + GPIO_INTMASK);
+   writel_relaxed(0x, bank->reg_base + GPIO_INTEN);
+   gc->mask_cache = 0x;
+
irq_set_chained_handler_and_data(bank->irq,
 rockchip_irq_demux, bank);
-
-   /* map the gpio irqs here, when the clock is still running */
-   for (j = 0 ; j < 32 ; j++)
-   irq_create_mapping(bank->domain, j);
-
clk_disable(bank->clk);
}
  


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever

Re: [PATCH v3 1/3] pinctrl: rockchip: make driver be tristate module【请注意，邮件由linux-rockchip-bounces+kever.yang=rock-chips....@lists.infradead.org代发】

[Kever Yang]

On 2020/10/13 下午2:37, Jianqun Xu wrote:

Make pinctrl-rockchip driver to be tristate module, support to build as
a module, this is useful for GKI.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Jianqun Xu 
---
  drivers/pinctrl/Kconfig|  2 +-
  drivers/pinctrl/pinctrl-rockchip.c | 13 +
  2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..bc9774c1ae8d 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -207,7 +207,7 @@ config PINCTRL_OXNAS
select MFD_SYSCON
  
  config PINCTRL_ROCKCHIP

-   bool
+   tristate "Rockchip gpio and pinctrl driver"
depends on OF
select PINMUX
select GENERIC_PINCONF
diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 0401c1da79dd..927d132d6716 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -16,10 +16,12 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -4258,3 +4260,14 @@ static int __init rockchip_pinctrl_drv_register(void)
return platform_driver_register(_pinctrl_driver);
  }
  postcore_initcall(rockchip_pinctrl_drv_register);
+
+static void __exit rockchip_pinctrl_drv_unregister(void)
+{
+   platform_driver_unregister(_pinctrl_driver);
+}
+module_exit(rockchip_pinctrl_drv_unregister);
+
+MODULE_DESCRIPTION("ROCKCHIP Pin Controller Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pinctrl-rockchip");
+MODULE_DEVICE_TABLE(of, rockchip_pinctrl_dt_match);


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever

Re: [PATCH v10 6/8] arm: dts: rockchip: Add NFC node for RV1108 SoC

[Kever Yang]

On 2020/9/30 上午10:09, Yifeng Zhao wrote:

Add NAND FLASH Controller(NFC) node for RV1108 SoC.

Signed-off-by: Yifeng Zhao 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm/boot/dts/rv1108.dtsi | 11 +++
  1 file changed, 11 insertions(+)


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever



diff --git a/arch/arm/boot/dts/rv1108.dtsi b/arch/arm/boot/dts/rv1108.dtsi
index a1a08cb9364e..1696ea19488b 100644
--- a/arch/arm/boot/dts/rv1108.dtsi
+++ b/arch/arm/boot/dts/rv1108.dtsi
@@ -452,6 +452,17 @@
#reset-cells = <1>;
};
  
+	nfc: nand-controller@3010 {

+   compatible = "rockchip,rv1108-nfc";
+   reg = <0x3010  0x1000>;
+   interrupts = ;
+   clocks = < HCLK_NANDC>, < SCLK_NANDC>;
+   clock-names = "ahb", "nfc";
+   assigned-clocks = < SCLK_NANDC>;
+   assigned-clock-rates = <15000>;
+   status = "disabled";
+   };
+
emmc: mmc@3011 {
compatible = "rockchip,rv1108-dw-mshc", 
"rockchip,rk3288-dw-mshc";
reg = <0x3011 0x4000>;

Re: [PATCH v10 7/8] arm: dts: rockchip: Add NFC node for RK2928 and other SoCs

[Kever Yang]

On 2020/9/30 上午10:09, Yifeng Zhao wrote:

Add NAND FLASH Controller(NFC) node for RK2928, RK3066, RK3168
and RK3188 SoCs.

Signed-off-by: Yifeng Zhao 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm/boot/dts/rk3xxx.dtsi | 9 +
  1 file changed, 9 insertions(+)


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever



diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 859a7477909f..97415180d5bb 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -276,6 +276,15 @@
status = "disabled";
};
  
+	nfc: nand-controller@1050 {

+   compatible = "rockchip,rk2928-nfc";
+   reg = <0x1050 0x4000>;
+   interrupts = ;
+   clocks = < HCLK_NANDC0>;
+   clock-names = "ahb";
+   status = "disabled";
+   };
+
pmu: pmu@20004000 {
compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
reg = <0x20004000 0x100>;

Re: [PATCH v10 2/8] mtd: rawnand: rockchip: NFC drivers for RK3308, RK2928 and others

[Kever Yang]

On 2020/9/30 上午10:07, Yifeng Zhao wrote:

This driver supports Rockchip NFC (NAND Flash Controller) found on RK3308,
RK2928, RKPX30, RV1108 and other SOCs. The driver has been tested using
8-bit NAND interface on the ARM based RK3308 platform.

Support Rockchip SoCs and NFC versions:
- PX30 and RK3326(NFCv900).
ECC: 16/40/60/70 bits/1KB.
CLOCK: ahb and nfc.
- RK3308 and RV1108(NFCv800).
ECC: 16 bits/1KB.
CLOCK: ahb and nfc.
- RK3036 and RK3128(NFCv622).
ECC: 16/24/40/60 bits/1KB.
CLOCK: ahb and nfc.
- RK3066, RK3188 and RK2928(NFCv600).
ECC: 16/24/40/60 bits/1KB.
CLOCK: ahb.

Supported features:
- Read full page data by DMA.
- Support HW ECC(one step is 1KB).
- Support 2 - 32K page size.
- Support 8 CS(depend on SoCs)

Limitations:
- No support for the ecc step size is 512.
- Untested on some SoCs.
- No support for subpages.
- No support for the builtin randomizer.
- The original bad block mask is not supported. It is recommended to use
   the BBT(bad block table).

Signed-off-by: Yifeng Zhao 


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever


---

Changes in v10:
- Fix compile error on master v5.9-rc7

Changes in v9:
- The nfc->buffer will realloc while the page size of the second mtd
   is large than the first one
- Fix coding style.
- Remove struct rk_nfc_clk.
- Prepend some function with rk_nfc_.
- Replace function readl_poll_timeout_atomic with readl_relaxed_poll_timeout.
- Remove function rk_nfc_read_byte and rk_nfc_write_byte.
- Don't select the die if 'check_only == true' in function rk_nfc_exec_op.
- Modify function rk_nfc_write_page and rk_nfc_write_page_raw.

Changes in v8: None
Changes in v7:
- Rebase to linux-next.
- Fix coding style.
- Reserved 4 bytes at the beginning of the oob area.
- Page raw read and write included ecc data.

Changes in v6:
- The mtd->name set by NAND label property.
- Add some comments.
- Fix compile error.

Changes in v5:
- Add boot blocks support  with different ECC for bootROM.
- Rename rockchip-nand.c to rockchip-nand-controller.c.
- Unification of other variable names.
- Remove some compatible define.

Changes in v4:
- Define platform data structure for the register offsets.
- The compatible define with rkxx_nfc.
- Use SET_SYSTEM_SLEEP_PM_OPS to define PM_OPS.
- Use exec_op instead of legacy hooks.

Changes in v3: None
Changes in v2:
- Fix compile error.
- Include header files sorted by file name.

  drivers/mtd/nand/raw/Kconfig  |   12 +
  drivers/mtd/nand/raw/Makefile |1 +
  .../mtd/nand/raw/rockchip-nand-controller.c   | 1455 +
  3 files changed, 1468 insertions(+)
  create mode 100644 drivers/mtd/nand/raw/rockchip-nand-controller.c

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 1203775023ad..af0ed098ca0c 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -461,6 +461,18 @@ config MTD_NAND_ARASAN
  Enables the driver for the Arasan NAND flash controller on
  Zynq Ultrascale+ MPSoC.
  
+config MTD_NAND_ROCKCHIP

+   tristate "Rockchip NAND controller"
+   depends on ARCH_ROCKCHIP && HAS_IOMEM
+   help
+ Enables support for NAND controller on Rockchip SoCs.
+ There are four different versions of NAND FLASH Controllers,
+ including:
+   NFC v600: RK2928, RK3066, RK3188
+   NFC v622: RK3036, RK3128
+   NFC v800: RK3308, RV1108
+   NFC v900: PX30, RK3326
+
  comment "Misc"
  
  config MTD_SM_COMMON

diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 2930f5b9015d..960c9be25204 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o
  obj-$(CONFIG_MTD_NAND_MESON)  += meson_nand.o
  obj-$(CONFIG_MTD_NAND_CADENCE)+= cadence-nand-controller.o
  obj-$(CONFIG_MTD_NAND_ARASAN) += arasan-nand-controller.o
+obj-$(CONFIG_MTD_NAND_ROCKCHIP)+= rockchip-nand-controller.o
  
  nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o

  nand-objs += nand_onfi.o
diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c 
b/drivers/mtd/nand/raw/rockchip-nand-controller.c
new file mode 100644
index ..fc206d1126e4
--- /dev/null
+++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c
@@ -0,0 +1,1455 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Rockchip NAND Flash controller driver.
+ * Copyright (C) 2020 Rockchip Inc.
+ * Author: Yifeng Zhao 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * NFC Page Data Layout:
+ * 1024 Bytes Data + 4Bytes sys data + 28Bytes~124Bytes ecc +
+ * 1024 Bytes Data + 4Bytes sys data + 28Bytes~124Bytes ecc +
+ *   

Re: [PATCH v10 1/8] dt-bindings: mtd: Describe Rockchip RK3xxx NAND flash controller

[Kever Yang]

On 2020/9/30 上午10:07, Yifeng Zhao wrote:

Documentation support for Rockchip RK3xxx NAND flash controllers

Signed-off-by: Yifeng Zhao 
---

Changes in v10: None
Changes in v9: None
Changes in v8:
- Fix make dt_binding_check error

Changes in v7:
- Fix some wrong define

Changes in v6:
- Fix some wrong define
- Modified the definition of compatible

Changes in v5:
- Fix some wrong define.
- Add boot-medium define.
- Remove some compatible define.

Changes in v4:
- The compatible define with rkxx_nfc.
- Add assigned-clocks.
- Fix some wrong defineChanges in.

Changes in v3:
- Change the title for the dt-bindings.

Changes in v2: None

  .../mtd/rockchip,nand-controller.yaml | 162 ++
  1 file changed, 162 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever



diff --git 
a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml 
b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
new file mode 100644
index ..b9d7a8c79402
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
@@ -0,0 +1,162 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/rockchip,nand-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoCs NAND FLASH Controller (NFC)
+
+allOf:
+  - $ref: "nand-controller.yaml#"
+
+maintainers:
+  - Heiko Stuebner 
+
+properties:
+  compatible:
+oneOf:
+  - const: rockchip,px30-nfc
+  - const: rockchip,rk2928-nfc
+  - const: rockchip,rv1108-nfc
+  - items:
+  - const: rockchip,rk3036-nfc
+  - const: rockchip,rk2928-nfc
+  - items:
+  - const: rockchip,rk3308-nfc
+  - const: rockchip,rv1108-nfc
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+minItems: 1
+items:
+  - description: Bus Clock
+  - description: Module Clock
+
+  clock-names:
+minItems: 1
+items:
+  - const: ahb
+  - const: nfc
+
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-rates:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+
+patternProperties:
+  "^nand@[0-7]$":
+type: object
+properties:
+  reg:
+minimum: 0
+maximum: 7
+
+  nand-ecc-mode:
+const: hw
+
+  nand-ecc-step-size:
+const: 1024
+
+  nand-ecc-strength:
+enum: [16, 24, 40, 60, 70]
+description:
+  The ECC configurations that can be supported are as follows.
+NFC v600 ECC 16, 24, 40, 60
+  RK2928, RK3066, RK3188
+
+NFC v622 ECC 16, 24, 40, 60
+  RK3036, RK3128
+
+NFC v800 ECC 16
+  RK3308, RV1108
+
+NFC v900 ECC 16, 40, 60, 70
+  RK3326, PX30
+
+  nand-bus-width:
+const: 8
+
+  rockchip,boot-blks:
+minimum: 2
+default: 16
+allOf:
+- $ref: /schemas/types.yaml#/definitions/uint32
+description:
+  The NFC driver need this information to select ECC
+  algorithms supported by the boot ROM.
+  Only used in combination with 'nand-is-boot-medium'.
+
+  rockchip,boot-ecc-strength:
+enum: [16, 24, 40, 60, 70]
+allOf:
+- $ref: /schemas/types.yaml#/definitions/uint32
+description:
+  If specified it indicates that a different BCH/ECC setting is
+  supported by the boot ROM.
+NFC v600 ECC 16, 24
+  RK2928, RK3066, RK3188
+
+NFC v622 ECC 16, 24, 40, 60
+  RK3036, RK3128
+
+NFC v800 ECC 16
+  RK3308, RV1108
+
+NFC v900 ECC 16, 70
+  RK3326, PX30
+
+  Only used in combination with 'nand-is-boot-medium'.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+#include 
+nfc: nand-controller@ff4b {
+  compatible = "rockchip,rk3308-nfc",
+   "rockchip,rv1108-nfc";
+  reg = <0xff4b 0x4000>;
+  interrupts = ;
+  clocks = < HCLK_NANDC>, < SCLK_NANDC>;
+  clock-names = "ahb", "nfc";
+  assigned-clocks = < SCLK_NANDC>;
+  assigned-clock-rates = <15000>;
+
+  pinctrl-0 = <_ale _bus8 _cle _csn0
+   _rdn _rdy _wrn>;
+  pinctrl-names = "default";
+
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  nand@0 {
+reg = <0>;
+label = "rk-nand";
+nand-bus-width = <8>;
+nand-ecc-mode = "hw";
+nand-ecc-step-size = <1024>;
+nand-ecc-strength = <16>;
+nand-is-boot-medium;
+rockchip,boot-blks = <8>;
+rockchip,boot-ecc-strength = <16>;
+  };
+};
+
+...

Re: [PATCH v10 4/8] arm64: dts: rockchip: Add NFC node for RK3308 SoC

[Kever Yang]

On 2020/9/30 上午10:07, Yifeng Zhao wrote:

From: Yifeng Zhao 

Add NAND FLASH Controller(NFC) node for RK3308 SoC.

Signed-off-by: Yifeng Zhao 
Signed-off-by: Yifeng Zhao 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm64/boot/dts/rockchip/rk3308.dtsi | 15 +++
  1 file changed, 15 insertions(+)


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever



diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
index 0cf954062387..f98c65c9bd13 100644
--- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -629,6 +629,21 @@
status = "disabled";
};
  
+	nfc: nand-controller@ff4b {

+   compatible = "rockchip,rk3308-nfc",
+"rockchip,rv1108-nfc";
+   reg = <0x0 0xff4b 0x0 0x4000>;
+   interrupts = ;
+   clocks = < HCLK_NANDC>, < SCLK_NANDC>;
+   clock-names = "ahb", "nfc";
+   assigned-clocks = < SCLK_NANDC>;
+   assigned-clock-rates = <15000>;
+   pinctrl-0 = <_ale _bus8 _cle _csn0
+_rdn _rdy _wrn>;
+   pinctrl-names = "default";
+   status = "disabled";
+   };
+
cru: clock-controller@ff50 {
compatible = "rockchip,rk3308-cru";
reg = <0x0 0xff50 0x0 0x1000>;

Re: [PATCH v10 5/8] arm64: dts: rockchip: Add NFC node for PX30 SoC

[Kever Yang]

On 2020/9/30 上午10:08, Yifeng Zhao wrote:

Add NAND FLASH Controller(NFC) node for PX30 SoC.

Signed-off-by: Yifeng Zhao 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm64/boot/dts/rockchip/px30.dtsi | 15 +++
  1 file changed, 15 insertions(+)


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever



diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi 
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 2695ea8cda14..6cd67e80d623 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -973,6 +973,21 @@
status = "disabled";
};
  
+	nfc: nand-controller@ff3b {

+   compatible = "rockchip,px30-nfc";
+   reg = <0x0 0xff3b 0x0 0x4000>;
+   interrupts = ;
+   clocks = < HCLK_NANDC>, < SCLK_NANDC>;
+   clock-names = "ahb", "nfc";
+   assigned-clocks = < SCLK_NANDC>;
+   assigned-clock-rates = <15000>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_ale _bus8 _cle _cs0
+_rdn _rdy _wrn _dqs>;
+   power-domains = < PX30_PD_MMC_NAND>;
+   status = "disabled";
+   };
+
gpu: gpu@ff40 {
compatible = "rockchip,px30-mali", "arm,mali-bifrost";
reg = <0x0 0xff40 0x0 0x4000>;

Re: [PATCH v3 2/3] pinctrl: rockchip: enable gpio pclk for rockchip_gpio_to_irq【请注意，邮件由linux-rockchip-bounces+kever.yang=rock-chips....@lists.infradead.org代发】

[Kever Yang]

On 2020/10/13 下午2:37, Jianqun Xu wrote:

There need to enable pclk_gpio when do irq_create_mapping, since it will
do access to gpio controller.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Jianqun Xu 
---
  drivers/pinctrl/pinctrl-rockchip.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 927d132d6716..a2f361aa6d05 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -3157,7 +3157,9 @@ static int rockchip_gpio_to_irq(struct gpio_chip *gc, 
unsigned offset)
if (!bank->domain)
return -ENXIO;
  
+	clk_enable(bank->clk);

virq = irq_create_mapping(bank->domain, offset);
+   clk_disable(bank->clk);
  
  	return (virq) ? : -ENXIO;

  }



Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever

Re: [PATCH v10 3/8] MAINTAINERS: add maintainers to ROCKCHIP NFC

[Kever Yang]

On 2020/9/30 上午10:07, Yifeng Zhao wrote:

Add maintainers to ROCKCHIP NFC.

Signed-off-by: Yifeng Zhao 
---

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  MAINTAINERS | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Looks good to me,

Reviewed-by: Kever Yang

Thanks,
- Kever



diff --git a/MAINTAINERS b/MAINTAINERS
index 190c7fa2ea01..5500df349836 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2382,12 +2382,12 @@ L:  linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
  L:linux-rockc...@lists.infradead.org
  S:Maintained
  T:git 
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
+F: Documentation/devicetree/bindings/*/*rockchip*.yaml
  F:Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
-F: Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
-F: Documentation/devicetree/bindings/spi/spi-rockchip.yaml
  F:arch/arm/boot/dts/rk3*
  F:arch/arm/boot/dts/rv1108*
  F:arch/arm/mach-rockchip/
+F: drivers/*/*/*/*rockchip*
  F:drivers/*/*/*rockchip*
  F:drivers/*/*rockchip*
  F:drivers/clk/rockchip/

Re: [PATCH v2 3/6] clk: rockchip: Export rockchip_register_softrst()

[Kever Yang]

On 2020/9/3 下午2:31, Elaine Zhang wrote:

This is used by the Rockchip clk driver, export it to allow that
driver to be compiled as a module..

Signed-off-by: Elaine Zhang 
---
  drivers/clk/rockchip/softrst.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/rockchip/softrst.c b/drivers/clk/rockchip/softrst.c
index 5f1ff5e47c4f..caba9055090b 100644
--- a/drivers/clk/rockchip/softrst.c
+++ b/drivers/clk/rockchip/softrst.c
@@ -77,9 +77,9 @@ static const struct reset_control_ops rockchip_softrst_ops = {
.deassert   = rockchip_softrst_deassert,
  };
  
-void __init rockchip_register_softrst(struct device_node *np,

- unsigned int num_regs,
- void __iomem *base, u8 flags)
+void rockchip_register_softrst(struct device_node *np,
+  unsigned int num_regs,
+  void __iomem *base, u8 flags)
  {
struct rockchip_softrst *softrst;
int ret;
@@ -107,3 +107,4 @@ void __init rockchip_register_softrst(struct device_node 
*np,
kfree(softrst);
}
  };
+EXPORT_SYMBOL(rockchip_register_softrst);


This looks good to me, so

Reviewed-by: Kever Yang 

Thanks,

- Kever

Re: [PATCH v2 2/6] clk: rockchip: Export rockchip_clk_register_ddrclk()

[Kever Yang]

On 2020/9/3 下午2:31, Elaine Zhang wrote:

This is used by the Rockchip clk driver, export it to allow that
driver to be compiled as a module..

Signed-off-by: Elaine Zhang 
---
  drivers/clk/rockchip/clk-ddr.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
index 9273bce4d7b6..282b6f22eb22 100644
--- a/drivers/clk/rockchip/clk-ddr.c
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -136,3 +136,4 @@ struct clk *rockchip_clk_register_ddrclk(const char *name, 
int flags,
  
  	return clk;

  }
+EXPORT_SYMBOL(rockchip_clk_register_ddrclk);


This looks good to me, so

Reviewed-by: Kever Yang 

Thanks,

- Kever

Re: [PATCH v2 6/6] clk: rockchip: rk3399: Support module build

[Kever Yang]

On 2020/9/3 下午2:32, Elaine Zhang wrote:

support CLK_OF_DECLARE and builtin_platform_driver_probe
double clk init method.
add module author, description and license to support building
Soc Rk3399 clock driver as module.

Signed-off-by: Elaine Zhang 
---
  drivers/clk/rockchip/clk-rk3399.c | 55 +++
  1 file changed, 55 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3399.c 
b/drivers/clk/rockchip/clk-rk3399.c
index ce1d2446f142..40ff17aee5b6 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -5,9 +5,11 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1600,3 +1602,56 @@ static void __init rk3399_pmu_clk_init(struct 
device_node *np)
rockchip_clk_of_add_provider(np, ctx);
  }
  CLK_OF_DECLARE(rk3399_cru_pmu, "rockchip,rk3399-pmucru", rk3399_pmu_clk_init);
+
+struct clk_rk3399_inits {
+   void (*inits)(struct device_node *np);
+};
+
+static const struct clk_rk3399_inits clk_rk3399_pmucru_init = {
+   .inits = rk3399_pmu_clk_init,
+};
+
+static const struct clk_rk3399_inits clk_rk3399_cru_init = {
+   .inits = rk3399_clk_init,
+};
+
+static const struct of_device_id clk_rk3399_match_table[] = {
+   {
+   .compatible = "rockchip,rk3399-cru",
+   .data = _rk3399_cru_init,
+   },  {
+   .compatible = "rockchip,rk3399-pmucru",
+   .data = _rk3399_pmucru_init,
+   },
+   { }
+};
+MODULE_DEVICE_TABLE(of, clk_rk3399_match_table);
+
+static int __init clk_rk3399_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   const struct of_device_id *match;
+   const struct clk_rk3399_inits *init_data;
+
+   match = of_match_device(clk_rk3399_match_table, >dev);
+   if (!match || !match->data)
+   return -EINVAL;
+
+   init_data = match->data;
+   if (init_data->inits)
+   init_data->inits(np);
+
+   return 0;
+}
+
+static struct platform_driver clk_rk3399_driver = {
+   .driver = {
+   .name   = "clk-rk3399",
+   .of_match_table = clk_rk3399_match_table,
+   },
+};
+builtin_platform_driver_probe(clk_rk3399_driver, clk_rk3399_probe);
+
+MODULE_DESCRIPTION("Rockchip RK3399 Clock Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:clk-rk3399");


This looks good to me, so

Reviewed-by: Kever Yang 

Thanks,

- Kever

Re: [PATCH v2 5/6] clk: rockchip: fix the clk config to support module build

[Kever Yang]

 += clk-rk3288.o
+obj-$(CONFIG_CLK_RK3308)    += clk-rk3308.o
+obj-$(CONFIG_CLK_RK3328)+= clk-rk3328.o
+obj-$(CONFIG_CLK_RK3368)+= clk-rk3368.o
+obj-$(CONFIG_CLK_RK3399)+= clk-rk3399.o


This looks good to me, so

Reviewed-by: Kever Yang 

Thanks,

- Kever

Re: [PATCH v2 1/6] clk: rockchip: Use clk_hw_register_composite instead of clk_register_composite calls

[Kever Yang]

  flags | CLK_SET_RATE_UNGATE);
+   if (IS_ERR(hw)) {
kfree(frac);
-   return clk;
+   return ERR_CAST(hw);
}
  
  	if (child) {

@@ -292,7 +289,7 @@ static struct clk *rockchip_clk_register_frac_branch(
mux_clk = clk_register(NULL, _mux->hw);
if (IS_ERR(mux_clk)) {
kfree(frac);
-   return clk;
+   return mux_clk;
}
  
  		rockchip_clk_add_lookup(ctx, mux_clk, child->id);

@@ -301,7 +298,7 @@ static struct clk *rockchip_clk_register_frac_branch(
if (frac->mux_frac_idx >= 0) {
pr_debug("%s: found fractional parent in mux at pos 
%d\n",
 __func__, frac->mux_frac_idx);
-   ret = clk_notifier_register(clk, >clk_nb);
+   ret = clk_notifier_register(hw->clk, >clk_nb);
if (ret)
pr_err("%s: failed to register clock notifier for 
%s\n",
__func__, name);
@@ -311,7 +308,7 @@ static struct clk *rockchip_clk_register_frac_branch(
}
}
  
-	return clk;

+   return hw->clk;
  }
  
  static struct clk *rockchip_clk_register_factor_branch(const char *name,

@@ -320,7 +317,7 @@ static struct clk 
*rockchip_clk_register_factor_branch(const char *name,
int gate_offset, u8 gate_shift, u8 gate_flags,
unsigned long flags, spinlock_t *lock)
  {
-   struct clk *clk;
+   struct clk_hw *hw;
struct clk_gate *gate = NULL;
struct clk_fixed_factor *fix = NULL;
  
@@ -349,16 +346,17 @@ static struct clk *rockchip_clk_register_factor_branch(const char *name,

fix->mult = mult;
fix->div = div;
  
-	clk = clk_register_composite(NULL, name, parent_names, num_parents,

-NULL, NULL,
->hw, _fixed_factor_ops,
->hw, _gate_ops, flags);
-   if (IS_ERR(clk)) {
+   hw = clk_hw_register_composite(NULL, name, parent_names, num_parents,
+  NULL, NULL,
+  >hw, _fixed_factor_ops,
+  >hw, _gate_ops, flags);
+   if (IS_ERR(hw)) {
kfree(fix);
kfree(gate);
+   return ERR_CAST(hw);
}
  
-	return clk;

+   return hw->clk;
  }
  
  struct rockchip_clk_provider * __init rockchip_clk_init(struct device_node *np,


This looks good to me, so

Reviewed-by: Kever Yang 

Thanks,

- Kever

Re: [PATCH v2 4/6] clk: rockchip: Export some clock common APIs for module drivers

[Kever Yang]

estart;
@@ -619,10 +626,10 @@ static struct notifier_block rockchip_restart_handler = {
.priority = 128,
  };
  
-void __init

+void
  rockchip_register_restart_notifier(struct rockchip_clk_provider *ctx,
-  unsigned int reg,
-  void (*cb)(void))
+  unsigned int reg,
+  void (*cb)(void))
  {
int ret;
  
@@ -634,3 +641,4 @@ rockchip_register_restart_notifier(struct rockchip_clk_provider *ctx,

pr_err("%s: cannot register restart handler, %d\n",
   __func__, ret);
  }
+EXPORT_SYMBOL(rockchip_register_restart_notifier);



This looks good to me, so

Reviewed-by: Kever Yang 

Thanks,

- Kever

[PATCH v2 2/2] dt-bindings: arm: rockchip: remove reference to fennec board

[Kever Yang]

The rk3288 fennec board has been removed, remove the binding document at
the same time.

Signed-off-by: Kever Yang 
---

Changes in v2: None

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 -
 1 file changed, 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 34865042f4e4..cc2f1c2d0cd0 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -424,11 +424,6 @@ properties:
   - rockchip,rk3288-evb-rk808
   - const: rockchip,rk3288
 
-  - description: Rockchip RK3288 Fennec
-items:
-  - const: rockchip,rk3288-fennec
-  - const: rockchip,rk3288
-
   - description: Rockchip RK3328 Evaluation board
 items:
   - const: rockchip,rk3328-evb
-- 
2.17.1

[PATCH v2 1/2] ARM: dts: rockchip: remove rk3288 fennec board support

[Kever Yang]

Since there is no one using this board, remove it.

Signed-off-by: Kever Yang 
---

Changes in v2:
- update document at the same time

 arch/arm/boot/dts/Makefile  |   1 -
 arch/arm/boot/dts/rk3288-fennec.dts | 347 
 2 files changed, 348 deletions(-)
 delete mode 100644 arch/arm/boot/dts/rk3288-fennec.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..1437ff8fe727 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -907,7 +907,6 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3229-evb.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
-   rk3288-fennec.dtb \
rk3288-firefly-beta.dtb \
rk3288-firefly.dtb \
rk3288-firefly-reload.dtb \
diff --git a/arch/arm/boot/dts/rk3288-fennec.dts 
b/arch/arm/boot/dts/rk3288-fennec.dts
deleted file mode 100644
index 4847cf902a15..
--- a/arch/arm/boot/dts/rk3288-fennec.dts
+++ /dev/null
@@ -1,347 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-
-/dts-v1/;
-
-#include "rk3288.dtsi"
-
-/ {
-   model = "Rockchip RK3288 Fennec Board";
-   compatible = "rockchip,rk3288-fennec", "rockchip,rk3288";
-
-   memory@0 {
-   reg = <0x0 0x0 0x0 0x8000>;
-   device_type = "memory";
-   };
-
-   ext_gmac: external-gmac-clock {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <12500>;
-   clock-output-names = "ext_gmac";
-   };
-
-   vcc_sys: vsys-regulator {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc_sys";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   regulator-always-on;
-   regulator-boot-on;
-   };
-};
-
- {
-   cpu0-supply = <_cpu>;
-};
-
- {
-   bus-width = <8>;
-   cap-mmc-highspeed;
-   non-removable;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk _cmd _pwr _bus8>;
-   status = "okay";
-};
-
- {
-   assigned-clocks = < SCLK_MAC>;
-   assigned-clock-parents = <_gmac>;
-   clock_in_out = "input";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>, <_rst>, <_pmeb>, <_int>;
-   phy-supply = <_lan>;
-   phy-mode = "rgmii";
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 100>;
-   snps,reset-gpio = < RK_PB0 GPIO_ACTIVE_LOW>;
-   tx_delay = <0x30>;
-   rx_delay = <0x10>;
-   status = "okay";
-};
-
- {
-   mali-supply = <_gpu>;
-   status = "okay";
-};
-
- {
-   status = "okay";
-};
-
- {
-   status = "okay";
-   clock-frequency = <40>;
-
-   rk808: pmic@1b {
-   compatible = "rockchip,rk808";
-   reg = <0x1b>;
-   interrupt-parent = <>;
-   interrupts = ;
-   #clock-cells = <1>;
-   clock-output-names = "xin32k", "rk808-clkout2";
-   pinctrl-names = "default";
-   pinctrl-0 = <_int _pwroff>;
-   rockchip,system-power-controller;
-   wakeup-source;
-
-   vcc1-supply = <_sys>;
-   vcc2-supply = <_sys>;
-   vcc3-supply = <_sys>;
-   vcc4-supply = <_sys>;
-   vcc6-supply = <_sys>;
-   vcc7-supply = <_sys>;
-   vcc8-supply = <_io>;
-   vcc9-supply = <_io>;
-   vcc10-supply = <_io>;
-   vcc11-supply = <_io>;
-   vcc12-supply = <_io>;
-   vddio-supply = <_io>;
-
-   regulators {
-   vdd_cpu: DCDC_REG1 {
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <75>;
-   regulator-max-microvolt = <135>;
-   regulator-name = "vdd_arm";
-   regulator-state-mem {
-   regulator-off-in-suspend;
-   };
-   };
-
-   vdd_gpu: DCDC_REG2 {
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <85>;
-   regulator-max-microvolt = <12500

Re: [PATCH] ARM: dts: rockchip: remove rk3288 fennec board support

[Kever Yang]

On 2019/8/20 下午9:56, Heiko Stuebner wrote:

Hi Kever,

Am Dienstag, 20. August 2019, 12:03:52 CEST schrieb Kever Yang:

Since there is no one using this board, remove it.

so just to elaborate a bit, I guess this board was internal to Rockchip,
never went to the market and therefore is obsolete without any users,
right?



Yes, even if there is someone using this board, they don't use upstream 
source code, you can see


there is only one commit relate to board itself, but never update. So I 
would like to remove it


from kernel and U-Boot upstream.



Also we should remove the binding  from
Documentation/devicetree/bindings/arm/rockchip.yaml as well


Will update.


Thanks,

- Kever




Heiko



Signed-off-by: Kever Yang 
---

  arch/arm/boot/dts/rk3288-fennec.dts | 347 
  1 file changed, 347 deletions(-)
  delete mode 100644 arch/arm/boot/dts/rk3288-fennec.dts

diff --git a/arch/arm/boot/dts/rk3288-fennec.dts 
b/arch/arm/boot/dts/rk3288-fennec.dts
deleted file mode 100644
index 4847cf902a15..
--- a/arch/arm/boot/dts/rk3288-fennec.dts
+++ /dev/null
@@ -1,347 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-
-/dts-v1/;
-
-#include "rk3288.dtsi"
-
-/ {
-   model = "Rockchip RK3288 Fennec Board";
-   compatible = "rockchip,rk3288-fennec", "rockchip,rk3288";
-
-   memory@0 {
-   reg = <0x0 0x0 0x0 0x8000>;
-   device_type = "memory";
-   };
-
-   ext_gmac: external-gmac-clock {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <12500>;
-   clock-output-names = "ext_gmac";
-   };
-
-   vcc_sys: vsys-regulator {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc_sys";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   regulator-always-on;
-   regulator-boot-on;
-   };
-};
-
- {
-   cpu0-supply = <_cpu>;
-};
-
- {
-   bus-width = <8>;
-   cap-mmc-highspeed;
-   non-removable;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk _cmd _pwr _bus8>;
-   status = "okay";
-};
-
- {
-   assigned-clocks = < SCLK_MAC>;
-   assigned-clock-parents = <_gmac>;
-   clock_in_out = "input";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>, <_rst>, <_pmeb>, <_int>;
-   phy-supply = <_lan>;
-   phy-mode = "rgmii";
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 100>;
-   snps,reset-gpio = < RK_PB0 GPIO_ACTIVE_LOW>;
-   tx_delay = <0x30>;
-   rx_delay = <0x10>;
-   status = "okay";
-};
-
- {
-   mali-supply = <_gpu>;
-   status = "okay";
-};
-
- {
-   status = "okay";
-};
-
- {
-   status = "okay";
-   clock-frequency = <40>;
-
-   rk808: pmic@1b {
-   compatible = "rockchip,rk808";
-   reg = <0x1b>;
-   interrupt-parent = <>;
-   interrupts = ;
-   #clock-cells = <1>;
-   clock-output-names = "xin32k", "rk808-clkout2";
-   pinctrl-names = "default";
-   pinctrl-0 = <_int _pwroff>;
-   rockchip,system-power-controller;
-   wakeup-source;
-
-   vcc1-supply = <_sys>;
-   vcc2-supply = <_sys>;
-   vcc3-supply = <_sys>;
-   vcc4-supply = <_sys>;
-   vcc6-supply = <_sys>;
-   vcc7-supply = <_sys>;
-   vcc8-supply = <_io>;
-   vcc9-supply = <_io>;
-   vcc10-supply = <_io>;
-   vcc11-supply = <_io>;
-   vcc12-supply = <_io>;
-   vddio-supply = <_io>;
-
-   regulators {
-   vdd_cpu: DCDC_REG1 {
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <75>;
-   regulator-max-microvolt = <135>;
-   regulator-name = "vdd_arm";
-   regulator-state-mem {
-   regulator-off-in-suspend;
-   };
-   };
-
-   vdd_gpu: DCDC_REG2 {
-   regulator-always-on;
-   regulator-boot-on;
-   

[PATCH] ARM: dts: rockchip: remove rk3288 fennec board support

[Kever Yang]

Since there is no one using this board, remove it.

Signed-off-by: Kever Yang 
---

 arch/arm/boot/dts/rk3288-fennec.dts | 347 
 1 file changed, 347 deletions(-)
 delete mode 100644 arch/arm/boot/dts/rk3288-fennec.dts

diff --git a/arch/arm/boot/dts/rk3288-fennec.dts 
b/arch/arm/boot/dts/rk3288-fennec.dts
deleted file mode 100644
index 4847cf902a15..
--- a/arch/arm/boot/dts/rk3288-fennec.dts
+++ /dev/null
@@ -1,347 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-
-/dts-v1/;
-
-#include "rk3288.dtsi"
-
-/ {
-   model = "Rockchip RK3288 Fennec Board";
-   compatible = "rockchip,rk3288-fennec", "rockchip,rk3288";
-
-   memory@0 {
-   reg = <0x0 0x0 0x0 0x8000>;
-   device_type = "memory";
-   };
-
-   ext_gmac: external-gmac-clock {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <12500>;
-   clock-output-names = "ext_gmac";
-   };
-
-   vcc_sys: vsys-regulator {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc_sys";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   regulator-always-on;
-   regulator-boot-on;
-   };
-};
-
- {
-   cpu0-supply = <_cpu>;
-};
-
- {
-   bus-width = <8>;
-   cap-mmc-highspeed;
-   non-removable;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk _cmd _pwr _bus8>;
-   status = "okay";
-};
-
- {
-   assigned-clocks = < SCLK_MAC>;
-   assigned-clock-parents = <_gmac>;
-   clock_in_out = "input";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>, <_rst>, <_pmeb>, <_int>;
-   phy-supply = <_lan>;
-   phy-mode = "rgmii";
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 100>;
-   snps,reset-gpio = < RK_PB0 GPIO_ACTIVE_LOW>;
-   tx_delay = <0x30>;
-   rx_delay = <0x10>;
-   status = "okay";
-};
-
- {
-   mali-supply = <_gpu>;
-   status = "okay";
-};
-
- {
-   status = "okay";
-};
-
- {
-   status = "okay";
-   clock-frequency = <40>;
-
-   rk808: pmic@1b {
-   compatible = "rockchip,rk808";
-   reg = <0x1b>;
-   interrupt-parent = <>;
-   interrupts = ;
-   #clock-cells = <1>;
-   clock-output-names = "xin32k", "rk808-clkout2";
-   pinctrl-names = "default";
-   pinctrl-0 = <_int _pwroff>;
-   rockchip,system-power-controller;
-   wakeup-source;
-
-   vcc1-supply = <_sys>;
-   vcc2-supply = <_sys>;
-   vcc3-supply = <_sys>;
-   vcc4-supply = <_sys>;
-   vcc6-supply = <_sys>;
-   vcc7-supply = <_sys>;
-   vcc8-supply = <_io>;
-   vcc9-supply = <_io>;
-   vcc10-supply = <_io>;
-   vcc11-supply = <_io>;
-   vcc12-supply = <_io>;
-   vddio-supply = <_io>;
-
-   regulators {
-   vdd_cpu: DCDC_REG1 {
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <75>;
-   regulator-max-microvolt = <135>;
-   regulator-name = "vdd_arm";
-   regulator-state-mem {
-   regulator-off-in-suspend;
-   };
-   };
-
-   vdd_gpu: DCDC_REG2 {
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <85>;
-   regulator-max-microvolt = <125>;
-   regulator-name = "vdd_gpu";
-   regulator-state-mem {
-   regulator-on-in-suspend;
-   regulator-suspend-microvolt = <100>;
-   };
-   };
-
-   vcc_ddr: DCDC_REG3 {
-   regulator-always-on;
-   regulator-boot-on;
-   re

Re: [PATCH v2] arm: dts: rockchip: fix vcc_host_5v regulator for usb3 host

[Kever Yang]

Hi Heiko,

On 2019/8/16 下午8:24, Heiko Stuebner wrote:

Hi Kever, TL,

[added TL Lim for clarification]

Am Donnerstag, 15. August 2019, 10:12:52 CEST schrieb Kever Yang:

According to rock64 schemetic V2 and V3, the VCC_HOST_5V output is
controlled by USB_20_HOST_DRV, which is the same as VCC_HOST1_5V.

The v1 schematics I have do reference the GPIO0_A0 as controlling this
supply, so the big question would be how to handle the different versions.

Because adding this would probably break v1 boards in this function.

@TL: where v1 boards also sold or were they only used during development?



I have check this with TL when I make this patch, the V1 hardware was 
never sold and only V2/V3


are available on the market.


Thanks,

- Kever


If this were the case, we could just apply the patch, not caring about
v1 boards, but if v1 boards were also sold to customers there would be
more of a problem.

Thanks
Heiko



Signed-off-by: Kever Yang 
---

Changes in v2:
- remove enable-active-high property

  arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 11 ++-
  1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 7cfd5ca6cc85..62936b432f9a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -34,10 +34,9 @@
  
  	vcc_host_5v: vcc-host-5v-regulator {

compatible = "regulator-fixed";
-   enable-active-high;
-   gpio = < RK_PA0 GPIO_ACTIVE_HIGH>;
+   gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
-   pinctrl-0 = <_host_drv>;
+   pinctrl-0 = <_host_drv>;
regulator-name = "vcc_host_5v";
regulator-always-on;
regulator-boot-on;
@@ -320,12 +319,6 @@
rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO _pull_none>;
};
};
-
-   usb3 {
-   usb30_host_drv: usb30-host-drv {
-   rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO _pull_none>;
-   };
-   };
  };
  
   {

[PATCH v2] arm: dts: rockchip: fix vcc_host_5v regulator for usb3 host

[Kever Yang]

According to rock64 schemetic V2 and V3, the VCC_HOST_5V output is
controlled by USB_20_HOST_DRV, which is the same as VCC_HOST1_5V.

Signed-off-by: Kever Yang 
---

Changes in v2:
- remove enable-active-high property

 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 7cfd5ca6cc85..62936b432f9a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -34,10 +34,9 @@
 
vcc_host_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
-   enable-active-high;
-   gpio = < RK_PA0 GPIO_ACTIVE_HIGH>;
+   gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
-   pinctrl-0 = <_host_drv>;
+   pinctrl-0 = <_host_drv>;
regulator-name = "vcc_host_5v";
regulator-always-on;
regulator-boot-on;
@@ -320,12 +319,6 @@
rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO _pull_none>;
};
};
-
-   usb3 {
-   usb30_host_drv: usb30-host-drv {
-   rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO _pull_none>;
-   };
-   };
 };
 
  {
-- 
2.17.1

[PATCH] arm: dts: rockchip: fix vcc_host_5v regulator for usb3 host

[Kever Yang]

According to rock64 schemetic V2 and V3, the VCC_HOST_5V output is
controlled by USB_20_HOST_DRV, which is the same as VCC_HOST1_5V.

Signed-off-by: Kever Yang 
---

 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 7cfd5ca6cc85..bd4ad1635e0b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -35,9 +35,9 @@
vcc_host_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
-   gpio = < RK_PA0 GPIO_ACTIVE_HIGH>;
+   gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
-   pinctrl-0 = <_host_drv>;
+   pinctrl-0 = <_host_drv>;
regulator-name = "vcc_host_5v";
regulator-always-on;
regulator-boot-on;
@@ -320,12 +320,6 @@
rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO _pull_none>;
};
};
-
-   usb3 {
-   usb30_host_drv: usb30-host-drv {
-   rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO _pull_none>;
-   };
-   };
 };
 
  {
-- 
2.17.1

[PATCH] arm64: dts: rk3399: init vop clock rates

[Kever Yang]

We need to init vop aclk and hclk incase the U-Boot does not do
the initialize.

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 0b3acc9..a592c24 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1480,6 +1480,8 @@
interrupts = ;
clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   assigned-clocks = < ACLK_VOP1>, < HCLK_VOP1>;
+   assigned-clock-rates = <4>, <1>;
iommus = <_mmu>;
power-domains = < RK3399_PD_VOPL>;
resets = < SRST_A_VOP1>, < SRST_H_VOP1>, < 
SRST_D_VOP1>;
@@ -1525,6 +1527,8 @@
interrupts = ;
clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   assigned-clocks = < ACLK_VOP0>, < HCLK_VOP0>;
+   assigned-clock-rates = <4>, <1>;
iommus = <_mmu>;
power-domains = < RK3399_PD_VOPB>;
resets = < SRST_A_VOP0>, < SRST_H_VOP0>, < 
SRST_D_VOP0>;
-- 
1.9.1

[PATCH] arm64: dts: rk3399: init vop clock rates

[Kever Yang]

We need to init vop aclk and hclk incase the U-Boot does not do
the initialize.

Signed-off-by: Kever Yang 
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 0b3acc9..a592c24 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1480,6 +1480,8 @@
interrupts = ;
clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   assigned-clocks = < ACLK_VOP1>, < HCLK_VOP1>;
+   assigned-clock-rates = <4>, <1>;
iommus = <_mmu>;
power-domains = < RK3399_PD_VOPL>;
resets = < SRST_A_VOP1>, < SRST_H_VOP1>, < 
SRST_D_VOP1>;
@@ -1525,6 +1527,8 @@
interrupts = ;
clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   assigned-clocks = < ACLK_VOP0>, < HCLK_VOP0>;
+   assigned-clock-rates = <4>, <1>;
iommus = <_mmu>;
power-domains = < RK3399_PD_VOPB>;
resets = < SRST_A_VOP0>, < SRST_H_VOP0>, < 
SRST_D_VOP0>;
-- 
1.9.1

Re: [PATCH] RM: dts: rockchip: rk322x: add spi node and spi pinctrl

[Kever Yang]

Hi Huibing,

Does this patch suppose to be V3?

and there is a typo in subject.


Thanks,
- Kever
On 08/07/2017 09:45 AM, Huibin Hong wrote:

Add spi node and spi pinctrl for rk322x

Signed-off-by: Huibin Hong 
---

  arch/arm/boot/dts/rk322x.dtsi | 50 +++
  1 file changed, 50 insertions(+)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index f3e4ffd..1a7afef 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -55,6 +55,7 @@
serial0 = 
serial1 = 
serial2 = 
+   spi0 = 
};
  
  	cpus {

@@ -361,6 +362,19 @@
status = "disabled";
};
  
+	spi0: spi@1109 {

+   compatible = "rockchip,rk3228-spi";
+   reg = <0x1109 0x1000>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _tx _rx _cs0 _cs1>;
+   clocks = < SCLK_SPI0>, < PCLK_SPI0>;
+   clock-names = "spiclk", "apb_pclk";
+   status = "disabled";
+   };
+
wdt: watchdog@110a {
compatible = "snps,dw-wdt";
reg = <0x110a 0x100>;
@@ -797,6 +811,42 @@
};
};
  
+		spi-0 {

+   spi0_clk: spi0-clk {
+   rockchip,pins = <0 9 RK_FUNC_2 _pull_up>;
+   };
+   spi0_cs0: spi0-cs0 {
+   rockchip,pins = <0 14 RK_FUNC_2 _pull_up>;
+   };
+   spi0_tx: spi0-tx {
+   rockchip,pins = <0 11 RK_FUNC_2 _pull_up>;
+   };
+   spi0_rx: spi0-rx {
+   rockchip,pins = <0 13 RK_FUNC_2 _pull_up>;
+   };
+   spi0_cs1: spi0-cs1 {
+   rockchip,pins = <1 12 RK_FUNC_1 _pull_up>;
+   };
+   };
+
+   spi-1 {
+   spi1_clk: spi1-clk {
+   rockchip,pins = <0 23 RK_FUNC_2 _pull_up>;
+   };
+   spi1_cs0: spi1-cs0 {
+   rockchip,pins = <2 2 RK_FUNC_2 _pull_up>;
+   };
+   spi1_rx: spi1-rx {
+   rockchip,pins = <2 0 RK_FUNC_2 _pull_up>;
+   };
+   spi1_tx: spi1-tx {
+   rockchip,pins = <2 1 RK_FUNC_2 _pull_up>;
+   };
+   spi1_cs1: spi1-cs1 {
+   rockchip,pins = <2 3 RK_FUNC_2 _pull_up>;
+   };
+   };
+
i2s1 {
i2s1_bus: i2s1-bus {
rockchip,pins = <0 8 RK_FUNC_1 _pull_none>,

Re: [PATCH] RM: dts: rockchip: rk322x: add spi node and spi pinctrl

[Kever Yang]

Hi Huibing,

Does this patch suppose to be V3?

and there is a typo in subject.


Thanks,
- Kever
On 08/07/2017 09:45 AM, Huibin Hong wrote:

Add spi node and spi pinctrl for rk322x

Signed-off-by: Huibin Hong 
---

  arch/arm/boot/dts/rk322x.dtsi | 50 +++
  1 file changed, 50 insertions(+)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index f3e4ffd..1a7afef 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -55,6 +55,7 @@
serial0 = 
serial1 = 
serial2 = 
+   spi0 = 
};
  
  	cpus {

@@ -361,6 +362,19 @@
status = "disabled";
};
  
+	spi0: spi@1109 {

+   compatible = "rockchip,rk3228-spi";
+   reg = <0x1109 0x1000>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _tx _rx _cs0 _cs1>;
+   clocks = < SCLK_SPI0>, < PCLK_SPI0>;
+   clock-names = "spiclk", "apb_pclk";
+   status = "disabled";
+   };
+
wdt: watchdog@110a {
compatible = "snps,dw-wdt";
reg = <0x110a 0x100>;
@@ -797,6 +811,42 @@
};
};
  
+		spi-0 {

+   spi0_clk: spi0-clk {
+   rockchip,pins = <0 9 RK_FUNC_2 _pull_up>;
+   };
+   spi0_cs0: spi0-cs0 {
+   rockchip,pins = <0 14 RK_FUNC_2 _pull_up>;
+   };
+   spi0_tx: spi0-tx {
+   rockchip,pins = <0 11 RK_FUNC_2 _pull_up>;
+   };
+   spi0_rx: spi0-rx {
+   rockchip,pins = <0 13 RK_FUNC_2 _pull_up>;
+   };
+   spi0_cs1: spi0-cs1 {
+   rockchip,pins = <1 12 RK_FUNC_1 _pull_up>;
+   };
+   };
+
+   spi-1 {
+   spi1_clk: spi1-clk {
+   rockchip,pins = <0 23 RK_FUNC_2 _pull_up>;
+   };
+   spi1_cs0: spi1-cs0 {
+   rockchip,pins = <2 2 RK_FUNC_2 _pull_up>;
+   };
+   spi1_rx: spi1-rx {
+   rockchip,pins = <2 0 RK_FUNC_2 _pull_up>;
+   };
+   spi1_tx: spi1-tx {
+   rockchip,pins = <2 1 RK_FUNC_2 _pull_up>;
+   };
+   spi1_cs1: spi1-cs1 {
+   rockchip,pins = <2 3 RK_FUNC_2 _pull_up>;
+   };
+   };
+
i2s1 {
i2s1_bus: i2s1-bus {
rockchip,pins = <0 8 RK_FUNC_1 _pull_none>,

Re: [PATCH 2/3] arm: dts: rk322x: correct uart2 pinctrl and add another sets

[Kever Yang]

Hi Frank,


On 05/17/2017 11:40 AM, Frank Wang wrote:

Correct UART2 PINCTRL flag and add another PINCTRL sets for UART2
in case of confict with SDMMC.

Signed-off-by: Frank Wang 
---
  arch/arm/boot/dts/rk322x.dtsi | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index cc6a27d..ea1239a 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -222,7 +222,7 @@
clocks = < SCLK_UART2>, < PCLK_UART2>;
clock-names = "baudclk", "apb_pclk";
pinctrl-names = "default";
-   pinctrl-0 = <_xfer>;
+   pinctrl-0 = <_xfer>;


There are more than one group of UART in rk322x, maybe we need to move
or add this setting in the dts file to override dtsi setting?

Thanks,
- Kever

reg-shift = <2>;
reg-io-width = <4>;
status = "disabled";
@@ -693,7 +693,7 @@
  
  		uart2 {

uart2_xfer: uart2-xfer {
-   rockchip,pins = <1 18 RK_FUNC_2 
_pull_none>,
+   rockchip,pins = <1 18 RK_FUNC_2 _pull_up>,
<1 19 RK_FUNC_2 
_pull_none>;
};
  
@@ -705,5 +705,12 @@

rockchip,pins = <0 24 RK_FUNC_1 
_pull_none>;
};
};
+
+   uart2-1 {
+   uart21_xfer: uart21-xfer {
+   rockchip,pins = <1 10 RK_FUNC_2 _pull_up>,
+   <1 9 RK_FUNC_2 _pull_none>;
+   };
+   };
};
  };

Re: [PATCH 2/3] arm: dts: rk322x: correct uart2 pinctrl and add another sets

[Kever Yang]

Hi Frank,


On 05/17/2017 11:40 AM, Frank Wang wrote:

Correct UART2 PINCTRL flag and add another PINCTRL sets for UART2
in case of confict with SDMMC.

Signed-off-by: Frank Wang 
---
  arch/arm/boot/dts/rk322x.dtsi | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index cc6a27d..ea1239a 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -222,7 +222,7 @@
clocks = < SCLK_UART2>, < PCLK_UART2>;
clock-names = "baudclk", "apb_pclk";
pinctrl-names = "default";
-   pinctrl-0 = <_xfer>;
+   pinctrl-0 = <_xfer>;


There are more than one group of UART in rk322x, maybe we need to move
or add this setting in the dts file to override dtsi setting?

Thanks,
- Kever

reg-shift = <2>;
reg-io-width = <4>;
status = "disabled";
@@ -693,7 +693,7 @@
  
  		uart2 {

uart2_xfer: uart2-xfer {
-   rockchip,pins = <1 18 RK_FUNC_2 
_pull_none>,
+   rockchip,pins = <1 18 RK_FUNC_2 _pull_up>,
<1 19 RK_FUNC_2 
_pull_none>;
};
  
@@ -705,5 +705,12 @@

rockchip,pins = <0 24 RK_FUNC_1 
_pull_none>;
};
};
+
+   uart2-1 {
+   uart21_xfer: uart21-xfer {
+   rockchip,pins = <1 10 RK_FUNC_2 _pull_up>,
+   <1 9 RK_FUNC_2 _pull_none>;
+   };
+   };
};
  };

Re: [PATCH 3/4] ARM: dts: rockchip: use pin constants to describe IO in pinctrl

[Kever Yang]

Heiko,


On 05/10/2017 05:43 AM, Heiko Stuebner wrote:

Am Mittwoch, 12. April 2017, 15:10:43 CEST schrieb Kever Yang:

Use command below to replace the IO naming in pinctrl:
sed -i -e 's/ 31 RK_FUNC_/ RK_PD7 RK_FUNC_/' arch/arm/boot/dts/rk*
sed -i -e 's/ 0 RK_FUNC_/ RK_PA0 RK_FUNC_/'
arch/arm64/boot/dts/rockchip/*

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>

I'm not sure, if we really want to mass-convert each and every pin.
All pins in use right now seem to be working and it hides other
history/blame for these entries.


Do you mean you want to leave the code already there as is, and new
code using MACRO define for IO?

This sounds reasonable, I can agree on this. I send this patch because I 
see there is

a patch from Andy using MACRO for many IOs, but not complete enough
and my patch suppose to make all Rockchip IO has update.

Thanks,
- Kever


In any case though, this needs to be split into separate arm32/arm64
patches.


Heiko

Re: [PATCH 3/4] ARM: dts: rockchip: use pin constants to describe IO in pinctrl

[Kever Yang]

Heiko,


On 05/10/2017 05:43 AM, Heiko Stuebner wrote:

Am Mittwoch, 12. April 2017, 15:10:43 CEST schrieb Kever Yang:

Use command below to replace the IO naming in pinctrl:
sed -i -e 's/ 31 RK_FUNC_/ RK_PD7 RK_FUNC_/' arch/arm/boot/dts/rk*
sed -i -e 's/ 0 RK_FUNC_/ RK_PA0 RK_FUNC_/'
arch/arm64/boot/dts/rockchip/*

Signed-off-by: Kever Yang 

I'm not sure, if we really want to mass-convert each and every pin.
All pins in use right now seem to be working and it hides other
history/blame for these entries.


Do you mean you want to leave the code already there as is, and new
code using MACRO define for IO?

This sounds reasonable, I can agree on this. I send this patch because I 
see there is

a patch from Andy using MACRO for many IOs, but not complete enough
and my patch suppose to make all Rockchip IO has update.

Thanks,
- Kever


In any case though, this needs to be split into separate arm32/arm64
patches.


Heiko

Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Hi Heiko,


On 04/12/2017 09:29 PM, Heiko Stuebner wrote:

Hi Kever,

Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang:

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>

applied for 4.13, as we're a bit late for 4.12, with the following changes:


Thanks for your help, I'm not familiar with the devices status on upstream
because not working on kernel upstream for a long time.

- commit subject
- dropped status from backlight (as there is no disabled common node
   and it's specific to the firefly itself)
- quite some reordering of properties
- reordered regulator nodes per their addresses: 0x1b < 0x40
- dropped obsolete regulator-compatible properties
- fixed gpio-irq on the mpu6500
- dropped out-of-tree orientation properties of mpu6500
   --> please provide the optional "mount-matrix" in a follow-up patch
   see bindings/iio/imu/inv_mpu6050.txt


Maybe we can drop this mpu6050 node first? I can't find binding file for it.

- dropped rockchip,i2s-broken-burst-len;
   That change never made it into the mainline kernel
- fixed pcie pinctrl indentation
- dropped wireless-bluetooth uart-gpios pinctrl
- dropped supports-emmc property

Please try to be a bit more careful when porting stuff from device kernels
with respect to properties not found in the mainline kernel and please
also double-check in [0] that I didn't break anything.


I have test this patch on my firefly-rk3399, it works fine with pwm2 
regulator

init in U-Boot.

Thanks,
- Kever



Thanks
Heiko

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=495a3c891a696b62465d71b1a125e3424352028b

Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Hi Heiko,


On 04/12/2017 09:29 PM, Heiko Stuebner wrote:

Hi Kever,

Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang:

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 

applied for 4.13, as we're a bit late for 4.12, with the following changes:


Thanks for your help, I'm not familiar with the devices status on upstream
because not working on kernel upstream for a long time.

- commit subject
- dropped status from backlight (as there is no disabled common node
   and it's specific to the firefly itself)
- quite some reordering of properties
- reordered regulator nodes per their addresses: 0x1b < 0x40
- dropped obsolete regulator-compatible properties
- fixed gpio-irq on the mpu6500
- dropped out-of-tree orientation properties of mpu6500
   --> please provide the optional "mount-matrix" in a follow-up patch
   see bindings/iio/imu/inv_mpu6050.txt


Maybe we can drop this mpu6050 node first? I can't find binding file for it.

- dropped rockchip,i2s-broken-burst-len;
   That change never made it into the mainline kernel
- fixed pcie pinctrl indentation
- dropped wireless-bluetooth uart-gpios pinctrl
- dropped supports-emmc property

Please try to be a bit more careful when porting stuff from device kernels
with respect to properties not found in the mainline kernel and please
also double-check in [0] that I didn't break anything.


I have test this patch on my firefly-rk3399, it works fine with pwm2 
regulator

init in U-Boot.

Thanks,
- Kever



Thanks
Heiko

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=495a3c891a696b62465d71b1a125e3424352028b

[PATCH 4/4] arm64: dts: rk3399: add pinctrl for some peripheral

[Kever Yang]

Add pinctrl for sdio, sdmmc, pcie, spdif, hdmi.

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 113 +++
 1 file changed, 113 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 54a5340..0096c70 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1737,6 +1737,91 @@
};
};
 
+   sdio0 {
+   sdio0_bus1: sdio0-bus1 {
+   rockchip,pins =
+   <2 RK_PC4 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_bus4: sdio0-bus4 {
+   rockchip,pins =
+   <2 RK_PC4 RK_FUNC_1 _pull_up>,
+   <2 RK_PC5 RK_FUNC_1 _pull_up>,
+   <2 RK_PC6 RK_FUNC_1 _pull_up>,
+   <2 RK_PC7 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_cmd: sdio0-cmd {
+   rockchip,pins =
+   <2 RK_PD0 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_clk: sdio0-clk {
+   rockchip,pins =
+   <2 RK_PD1 RK_FUNC_1 _pull_none>;
+   };
+
+   sdio0_cd: sdio0-cd {
+   rockchip,pins =
+   <2 RK_PD2 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_pwr: sdio0-pwr {
+   rockchip,pins =
+   <2 RK_PD3 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_bkpwr: sdio0-bkpwr {
+   rockchip,pins =
+   <2 RK_PD4 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_wp: sdio0-wp {
+   rockchip,pins =
+   <0 RK_PA3 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_int: sdio0-int {
+   rockchip,pins =
+   <0 RK_PA4 RK_FUNC_1 _pull_up>;
+   };
+   };
+
+   sdmmc {
+   sdmmc_bus1: sdmmc-bus1 {
+   rockchip,pins =
+   <4 RK_PB0 RK_FUNC_1 _pull_up>;
+   };
+
+   sdmmc_bus4: sdmmc-bus4 {
+   rockchip,pins =
+   <4 RK_PB0 RK_FUNC_1 _pull_up>,
+   <4 RK_PB1 RK_FUNC_1 _pull_up>,
+   <4 RK_PB2 RK_FUNC_1 _pull_up>,
+   <4 RK_PB3 RK_FUNC_1 _pull_up>;
+   };
+
+   sdmmc_clk: sdmmc-clk {
+   rockchip,pins =
+   <4 RK_PB4 RK_FUNC_1 _pull_none>;
+   };
+
+   sdmmc_cmd: sdmmc-cmd {
+   rockchip,pins =
+   <4 RK_PB5 RK_FUNC_1 _pull_up>;
+   };
+
+   sdmmc_cd: sdmcc-cd {
+   rockchip,pins =
+   <0 RK_PA7 RK_FUNC_1 _pull_up>;
+   };
+
+   sdmmc_wp: sdmmc-wp {
+   rockchip,pins =
+   <0 RK_PB0 RK_FUNC_1 _pull_up>;
+   };
+   };
+
sleep {
ap_pwroff: ap-pwroff {
rockchip,pins = <1 RK_PA5 RK_FUNC_1 
_pull_none>;
@@ -1752,6 +1837,11 @@
rockchip,pins =
<4 RK_PC5 RK_FUNC_1 _pull_none>;
};
+
+   spdif_bus_1: spdif-bus-1 {
+   rockchip,pins =
+   <3 RK_PC0 RK_FUNC_3 _pull_none>;
+   };
};
 
spi0 {
@@ -2011,6 +2101,19 @@
};
};
 
+   hdmi {
+   hdmi_i2c_xfer: hdmi-i2c-xfer {
+   rockchip,pins =
+   <4 RK_PC1 RK_FUNC_3 _pull_none>,
+   

[PATCH 4/4] arm64: dts: rk3399: add pinctrl for some peripheral

[Kever Yang]

Add pinctrl for sdio, sdmmc, pcie, spdif, hdmi.

Signed-off-by: Kever Yang 
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 113 +++
 1 file changed, 113 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 54a5340..0096c70 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1737,6 +1737,91 @@
};
};
 
+   sdio0 {
+   sdio0_bus1: sdio0-bus1 {
+   rockchip,pins =
+   <2 RK_PC4 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_bus4: sdio0-bus4 {
+   rockchip,pins =
+   <2 RK_PC4 RK_FUNC_1 _pull_up>,
+   <2 RK_PC5 RK_FUNC_1 _pull_up>,
+   <2 RK_PC6 RK_FUNC_1 _pull_up>,
+   <2 RK_PC7 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_cmd: sdio0-cmd {
+   rockchip,pins =
+   <2 RK_PD0 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_clk: sdio0-clk {
+   rockchip,pins =
+   <2 RK_PD1 RK_FUNC_1 _pull_none>;
+   };
+
+   sdio0_cd: sdio0-cd {
+   rockchip,pins =
+   <2 RK_PD2 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_pwr: sdio0-pwr {
+   rockchip,pins =
+   <2 RK_PD3 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_bkpwr: sdio0-bkpwr {
+   rockchip,pins =
+   <2 RK_PD4 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_wp: sdio0-wp {
+   rockchip,pins =
+   <0 RK_PA3 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_int: sdio0-int {
+   rockchip,pins =
+   <0 RK_PA4 RK_FUNC_1 _pull_up>;
+   };
+   };
+
+   sdmmc {
+   sdmmc_bus1: sdmmc-bus1 {
+   rockchip,pins =
+   <4 RK_PB0 RK_FUNC_1 _pull_up>;
+   };
+
+   sdmmc_bus4: sdmmc-bus4 {
+   rockchip,pins =
+   <4 RK_PB0 RK_FUNC_1 _pull_up>,
+   <4 RK_PB1 RK_FUNC_1 _pull_up>,
+   <4 RK_PB2 RK_FUNC_1 _pull_up>,
+   <4 RK_PB3 RK_FUNC_1 _pull_up>;
+   };
+
+   sdmmc_clk: sdmmc-clk {
+   rockchip,pins =
+   <4 RK_PB4 RK_FUNC_1 _pull_none>;
+   };
+
+   sdmmc_cmd: sdmmc-cmd {
+   rockchip,pins =
+   <4 RK_PB5 RK_FUNC_1 _pull_up>;
+   };
+
+   sdmmc_cd: sdmcc-cd {
+   rockchip,pins =
+   <0 RK_PA7 RK_FUNC_1 _pull_up>;
+   };
+
+   sdmmc_wp: sdmmc-wp {
+   rockchip,pins =
+   <0 RK_PB0 RK_FUNC_1 _pull_up>;
+   };
+   };
+
sleep {
ap_pwroff: ap-pwroff {
rockchip,pins = <1 RK_PA5 RK_FUNC_1 
_pull_none>;
@@ -1752,6 +1837,11 @@
rockchip,pins =
<4 RK_PC5 RK_FUNC_1 _pull_none>;
};
+
+   spdif_bus_1: spdif-bus-1 {
+   rockchip,pins =
+   <3 RK_PC0 RK_FUNC_3 _pull_none>;
+   };
};
 
spi0 {
@@ -2011,6 +2101,19 @@
};
};
 
+   hdmi {
+   hdmi_i2c_xfer: hdmi-i2c-xfer {
+   rockchip,pins =
+   <4 RK_PC1 RK_FUNC_3 _pull_none>,
+   &l

[PATCH 2/4] arm64: dts: rk3399: add power domain for some peripheral

[Kever Yang]

Add power domain for sd, usb, edp.

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 387ae34..9d44c19 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -947,6 +947,10 @@
};
 
/* These power domains are grouped by VD_LOGIC */
+   pd_edp@RK3399_PD_EDP {
+   reg = ;
+   clocks = < PCLK_EDP_CTRL>;
+   };
pd_emmc@RK3399_PD_EMMC {
reg = ;
clocks = < ACLK_EMMC>;
@@ -958,11 +962,33 @@
 < PCLK_GMAC>;
pm_qos = <_gmac>;
};
-   pd_sd@RK3399_PD_SD {
-   reg = ;
-   clocks = < HCLK_SDMMC>,
-< SCLK_SDMMC>;
-   pm_qos = <_sd>;
+   pd_perihp@RK3399_PD_PERIHP {
+   reg = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < ACLK_PERIHP>;
+   pm_qos = <_perihp>,
+<_pcie>,
+<_usb_host0>,
+<_usb_host1>;
+
+   pd_sd@RK3399_PD_SD {
+   reg = ;
+   clocks = < HCLK_SDMMC>,
+< SCLK_SDMMC>;
+   pm_qos = <_sd>;
+   };
+   };
+   pd_sdioaudio@RK3399_PD_SDIOAUDIO {
+   reg = ;
+   clocks = < HCLK_SDIO>;
+   pm_qos = <_sdioaudio>;
+   };
+   pd_usb3@RK3399_PD_USB3 {
+   reg = ;
+   clocks = < ACLK_USB3>;
+   pm_qos = <_usb_otg0>,
+<_usb_otg1>;
};
pd_vio@RK3399_PD_VIO {
reg = ;
-- 
1.9.1

[PATCH 2/4] arm64: dts: rk3399: add power domain for some peripheral

[Kever Yang]

Add power domain for sd, usb, edp.

Signed-off-by: Kever Yang 
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 387ae34..9d44c19 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -947,6 +947,10 @@
};
 
/* These power domains are grouped by VD_LOGIC */
+   pd_edp@RK3399_PD_EDP {
+   reg = ;
+   clocks = < PCLK_EDP_CTRL>;
+   };
pd_emmc@RK3399_PD_EMMC {
reg = ;
clocks = < ACLK_EMMC>;
@@ -958,11 +962,33 @@
 < PCLK_GMAC>;
pm_qos = <_gmac>;
};
-   pd_sd@RK3399_PD_SD {
-   reg = ;
-   clocks = < HCLK_SDMMC>,
-< SCLK_SDMMC>;
-   pm_qos = <_sd>;
+   pd_perihp@RK3399_PD_PERIHP {
+   reg = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < ACLK_PERIHP>;
+   pm_qos = <_perihp>,
+<_pcie>,
+<_usb_host0>,
+<_usb_host1>;
+
+   pd_sd@RK3399_PD_SD {
+   reg = ;
+   clocks = < HCLK_SDMMC>,
+< SCLK_SDMMC>;
+   pm_qos = <_sd>;
+   };
+   };
+   pd_sdioaudio@RK3399_PD_SDIOAUDIO {
+   reg = ;
+   clocks = < HCLK_SDIO>;
+   pm_qos = <_sdioaudio>;
+   };
+   pd_usb3@RK3399_PD_USB3 {
+   reg = ;
+   clocks = < ACLK_USB3>;
+   pm_qos = <_usb_otg0>,
+<_usb_otg1>;
};
pd_vio@RK3399_PD_VIO {
reg = ;
-- 
1.9.1

[PATCH 1/4] arm64: dts: rk3399: add missing qos node

[Kever Yang]

Add qos setting reg for some peripheral like sd, usb, pcie.

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 45 
 1 file changed, 40 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index f4f3c96..387ae34 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -769,11 +769,6 @@
status = "disabled";
};
 
-   qos_sd: qos@ffa74000 {
-   compatible = "syscon";
-   reg = <0x0 0xffa74000 0x0 0x20>;
-   };
-
qos_emmc: qos@ffa58000 {
compatible = "syscon";
reg = <0x0 0xffa58000 0x0 0x20>;
@@ -784,6 +779,41 @@
reg = <0x0 0xffa5c000 0x0 0x20>;
};
 
+   qos_pcie: qos@ffa60080 {
+   compatible = "syscon";
+   reg = <0x0 0xffa60080 0x0 0x20>;
+   };
+
+   qos_usb_host0: qos@ffa60100 {
+   compatible = "syscon";
+   reg = <0x0 0xffa60100 0x0 0x20>;
+   };
+
+   qos_usb_host1: qos@ffa60180 {
+   compatible = "syscon";
+   reg = <0x0 0xffa60180 0x0 0x20>;
+   };
+
+   qos_usb_otg0: qos@ffa7 {
+   compatible = "syscon";
+   reg = <0x0 0xffa7 0x0 0x20>;
+   };
+
+   qos_usb_otg1: qos@ffa70080 {
+   compatible = "syscon";
+   reg = <0x0 0xffa70080 0x0 0x20>;
+   };
+
+   qos_sd: qos@ffa74000 {
+   compatible = "syscon";
+   reg = <0x0 0xffa74000 0x0 0x20>;
+   };
+
+   qos_sdioaudio: qos@ffa76000 {
+   compatible = "syscon";
+   reg = <0x0 0xffa76000 0x0 0x20>;
+   };
+
qos_hdcp: qos@ffa9 {
compatible = "syscon";
reg = <0x0 0xffa9 0x0 0x20>;
@@ -854,6 +884,11 @@
reg = <0x0 0xffad 0x0 0x20>;
};
 
+   qos_perihp: qos@ffad8080 {
+   compatible = "syscon";
+   reg = <0x0 0xffad8080 0x0 0x20>;
+   };
+
qos_gpu: qos@ffae {
compatible = "syscon";
reg = <0x0 0xffae 0x0 0x20>;
-- 
1.9.1

[PATCH 1/4] arm64: dts: rk3399: add missing qos node

[Kever Yang]

Add qos setting reg for some peripheral like sd, usb, pcie.

Signed-off-by: Kever Yang 
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 45 
 1 file changed, 40 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index f4f3c96..387ae34 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -769,11 +769,6 @@
status = "disabled";
};
 
-   qos_sd: qos@ffa74000 {
-   compatible = "syscon";
-   reg = <0x0 0xffa74000 0x0 0x20>;
-   };
-
qos_emmc: qos@ffa58000 {
compatible = "syscon";
reg = <0x0 0xffa58000 0x0 0x20>;
@@ -784,6 +779,41 @@
reg = <0x0 0xffa5c000 0x0 0x20>;
};
 
+   qos_pcie: qos@ffa60080 {
+   compatible = "syscon";
+   reg = <0x0 0xffa60080 0x0 0x20>;
+   };
+
+   qos_usb_host0: qos@ffa60100 {
+   compatible = "syscon";
+   reg = <0x0 0xffa60100 0x0 0x20>;
+   };
+
+   qos_usb_host1: qos@ffa60180 {
+   compatible = "syscon";
+   reg = <0x0 0xffa60180 0x0 0x20>;
+   };
+
+   qos_usb_otg0: qos@ffa7 {
+   compatible = "syscon";
+   reg = <0x0 0xffa7 0x0 0x20>;
+   };
+
+   qos_usb_otg1: qos@ffa70080 {
+   compatible = "syscon";
+   reg = <0x0 0xffa70080 0x0 0x20>;
+   };
+
+   qos_sd: qos@ffa74000 {
+   compatible = "syscon";
+   reg = <0x0 0xffa74000 0x0 0x20>;
+   };
+
+   qos_sdioaudio: qos@ffa76000 {
+   compatible = "syscon";
+   reg = <0x0 0xffa76000 0x0 0x20>;
+   };
+
qos_hdcp: qos@ffa9 {
compatible = "syscon";
reg = <0x0 0xffa9 0x0 0x20>;
@@ -854,6 +884,11 @@
reg = <0x0 0xffad 0x0 0x20>;
};
 
+   qos_perihp: qos@ffad8080 {
+   compatible = "syscon";
+   reg = <0x0 0xffad8080 0x0 0x20>;
+   };
+
qos_gpu: qos@ffae {
compatible = "syscon";
reg = <0x0 0xffae 0x0 0x20>;
-- 
1.9.1

[PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---

Changes in v3:
- remove not upstream defined properties;
- remove fusb302 and gsl3673 node

Changes in v2:
- rebase on Heiko's for-next
- using pinctrl binding header definition instead of a number
- other fix by comments from Heiko and Andreas.

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 714 
 2 files changed, 715 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index b5636bb..bcfa53b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..2517219
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,714 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Firefly-RK3399 Board";
+   compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+
+   backlight: backlight {
+   status = "okay";
+   compatible = "pwm-backlight";
+   enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  9

[PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 
---

Changes in v3:
- remove not upstream defined properties;
- remove fusb302 and gsl3673 node

Changes in v2:
- rebase on Heiko's for-next
- using pinctrl binding header definition instead of a number
- other fix by comments from Heiko and Andreas.

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 714 
 2 files changed, 715 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index b5636bb..bcfa53b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..2517219
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,714 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Firefly-RK3399 Board";
+   compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+
+   backlight: backlight {
+   status = "okay";
+   compatible = "pwm-backlight";
+   enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+   

Re: [PATCH v2 1/2] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Hi Heiko,


On 04/08/2017 07:01 AM, Heiko Stuebner wrote:

Hi Kever,

Am Mittwoch, 5. April 2017, 17:33:19 CEST schrieb Kever Yang:

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>

[...]


+   vdd_log: vdd-log {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 1>;
+   regulator-name = "vdd_log";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+
+   /* for rockchip boot on */
+   rockchip,pwm_id= <2>;
+   rockchip,pwm_voltage = <100>;

Vendor-kernel stuff, needs to be dropped


Will drop it next version.


[...]


+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <168>;
+   i2c-scl-falling-time-ns = <4>;
+   clock-frequency = <40>;
+
+   vdd_cpu_b: pmic@40 {
+   compatible = "silergy,syr827";
+   reg = <0x40>;
+   vin-supply = <_sys>;
+   regulator-compatible = "fan53555-reg";
+   regulator-name = "vdd_cpu_b";
+   regulator-min-microvolt = <712500>;
+   regulator-max-microvolt = <150>;
+   regulator-ramp-delay = <1000>;
+   vsel-gpios = < RK_PC2 GPIO_ACTIVE_HIGH>;

non-mainline property


Will drop it next version.



+   fcs,suspend-voltage-selector = <0>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-initial-state = <3>;

non-mainline property


Will drop it next version.



+   regulator-state-mem {

indentation is wrong


+   regulator-off-in-suspend;
+   };
+   };
+
+   vdd_gpu: syr828@41 {
+   compatible = "silergy,syr828";
+   reg = <0x41>;
+   vin-supply = <_sys>;
+   regulator-compatible = "fan53555-reg";
+   regulator-name = "vdd_gpu";
+   regulator-min-microvolt = <712500>;
+   regulator-max-microvolt = <150>;
+   regulator-ramp-delay = <1000>;
+   fcs,suspend-voltage-selector = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-initial-state = <3>;

non-mainline property


Will drop it next version.



+   regulator-state-mem {

indentation is wrong


+   regulator-off-in-suspend;
+   };
+   };
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   reg = <0x1b>;
+   interrupt-parent = <>;
+   interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int_l>;
+   rockchip,system-power-controller;

system-power-controller without the "rockchip,"?


The driver at drivers/mfd/rk808.c is using "rockchip, 
system-power-controller".



+   wakeup-source;
+   #clock-cells = <1>;
+   clock-output-names = "xin32k", "rk808-clkout2";

[...]


+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <300>;
+   i2c-scl-falling-time-ns = <15>;
+
+   gsl3673: gsl3673@40 {

gsl3673: touchscreen@40


+   compatible = "GSL,GSL3673";

compatible lowercase?


This is not using upstream driver, need porting, remove it now.



+   reg = <0x40>;
+   screen_max_x = <1536>;
+   screen_max_y = <2048>;
+   irq_gpio_number = < RK_PC4 IRQ_TYPE_LEVEL_LOW>;
+   rst_gpio_number = < RK_PC6 GPIO_ACTIVE_HIGH>;
+   };
+
+   rt5640: rt5640@1c {
+   #sound-dai-cells = <0>;
+   compatible = "realtek,rt5640";
+   reg = <0x1c>;
+   clocks = < SCLK_I2S_8CH_OUT>;
+   clock-names = "mclk";
+   realtek,in1-differential;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpcon>;
+   hp-con-gpio = < RK_PC5 GPIO_ACTIVE_HI

Re: [PATCH v2 1/2] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Hi Heiko,


On 04/08/2017 07:01 AM, Heiko Stuebner wrote:

Hi Kever,

Am Mittwoch, 5. April 2017, 17:33:19 CEST schrieb Kever Yang:

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 

[...]


+   vdd_log: vdd-log {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 1>;
+   regulator-name = "vdd_log";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+
+   /* for rockchip boot on */
+   rockchip,pwm_id= <2>;
+   rockchip,pwm_voltage = <100>;

Vendor-kernel stuff, needs to be dropped


Will drop it next version.


[...]


+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <168>;
+   i2c-scl-falling-time-ns = <4>;
+   clock-frequency = <40>;
+
+   vdd_cpu_b: pmic@40 {
+   compatible = "silergy,syr827";
+   reg = <0x40>;
+   vin-supply = <_sys>;
+   regulator-compatible = "fan53555-reg";
+   regulator-name = "vdd_cpu_b";
+   regulator-min-microvolt = <712500>;
+   regulator-max-microvolt = <150>;
+   regulator-ramp-delay = <1000>;
+   vsel-gpios = < RK_PC2 GPIO_ACTIVE_HIGH>;

non-mainline property


Will drop it next version.



+   fcs,suspend-voltage-selector = <0>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-initial-state = <3>;

non-mainline property


Will drop it next version.



+   regulator-state-mem {

indentation is wrong


+   regulator-off-in-suspend;
+   };
+   };
+
+   vdd_gpu: syr828@41 {
+   compatible = "silergy,syr828";
+   reg = <0x41>;
+   vin-supply = <_sys>;
+   regulator-compatible = "fan53555-reg";
+   regulator-name = "vdd_gpu";
+   regulator-min-microvolt = <712500>;
+   regulator-max-microvolt = <150>;
+   regulator-ramp-delay = <1000>;
+   fcs,suspend-voltage-selector = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-initial-state = <3>;

non-mainline property


Will drop it next version.



+   regulator-state-mem {

indentation is wrong


+   regulator-off-in-suspend;
+   };
+   };
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   reg = <0x1b>;
+   interrupt-parent = <>;
+   interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int_l>;
+   rockchip,system-power-controller;

system-power-controller without the "rockchip,"?


The driver at drivers/mfd/rk808.c is using "rockchip, 
system-power-controller".



+   wakeup-source;
+   #clock-cells = <1>;
+   clock-output-names = "xin32k", "rk808-clkout2";

[...]


+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <300>;
+   i2c-scl-falling-time-ns = <15>;
+
+   gsl3673: gsl3673@40 {

gsl3673: touchscreen@40


+   compatible = "GSL,GSL3673";

compatible lowercase?


This is not using upstream driver, need porting, remove it now.



+   reg = <0x40>;
+   screen_max_x = <1536>;
+   screen_max_y = <2048>;
+   irq_gpio_number = < RK_PC4 IRQ_TYPE_LEVEL_LOW>;
+   rst_gpio_number = < RK_PC6 GPIO_ACTIVE_HIGH>;
+   };
+
+   rt5640: rt5640@1c {
+   #sound-dai-cells = <0>;
+   compatible = "realtek,rt5640";
+   reg = <0x1c>;
+   clocks = < SCLK_I2S_8CH_OUT>;
+   clock-names = "mclk";
+   realtek,in1-differential;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpcon>;
+   hp-con-gpio = < RK_PC5 GPIO_ACTIVE_HIGH>;
+   io-c

[PATCH v2 2/2] dt-bindings: document: add firefly-rk3399 board support

[Kever Yang]

Use "firefly,firefly-rk3399" compatible string for firefly-rk3399 board.

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---

Changes in v2: None

 Documentation/devicetree/bindings/arm/rockchip.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 250fdf0..b5201f4 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -42,6 +42,10 @@ Rockchip platforms device tree bindings
 Required root node properties:
   - compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
 
+- Firefly Firefly-RK3399 board:
+Required root node properties:
+  - compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+
 - ChipSPARK PopMetal-RK3288 board:
 Required root node properties:
   - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
-- 
1.9.1

[PATCH v2 2/2] dt-bindings: document: add firefly-rk3399 board support

[Kever Yang]

Use "firefly,firefly-rk3399" compatible string for firefly-rk3399 board.

Signed-off-by: Kever Yang 
---

Changes in v2: None

 Documentation/devicetree/bindings/arm/rockchip.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 250fdf0..b5201f4 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -42,6 +42,10 @@ Rockchip platforms device tree bindings
 Required root node properties:
   - compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
 
+- Firefly Firefly-RK3399 board:
+Required root node properties:
+  - compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+
 - ChipSPARK PopMetal-RK3288 board:
 Required root node properties:
   - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
-- 
1.9.1

[PATCH v2 1/2] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---

Changes in v2:
- rebase on Heiko's for-next
- using pinctrl binding header definition instead of a number
- other fix by comments from Heiko and Andreas.

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 750 
 2 files changed, 751 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index b5636bb..bcfa53b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..d427d40
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,750 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Firefly-RK3399 Board";
+   compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+
+   backlight: backlight {
+   status = "okay";
+   compatible = "pwm-backlight";
+   enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100 101 102 103
+ 

[PATCH v2 1/2] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 
---

Changes in v2:
- rebase on Heiko's for-next
- using pinctrl binding header definition instead of a number
- other fix by comments from Heiko and Andreas.

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 750 
 2 files changed, 751 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index b5636bb..bcfa53b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..d427d40
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,750 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Firefly-RK3399 Board";
+   compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+
+   backlight: backlight {
+   status = "okay";
+   compatible = "pwm-backlight";
+   enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100 101 102 103
+   104 105 106 107 108 109 110 

Re: [PATCH] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Hi Heiko, Andreas,


On 04/01/2017 03:41 AM, Heiko Stuebner wrote:

Hi,

Am Freitag, 31. März 2017, 18:59:49 CEST schrieb Andreas Färber:

Am 31.03.2017 um 14:56 schrieb Heiko Stuebner:

Hi Kever,

Am Freitag, 31. März 2017, 17:59:07 CEST schrieb Kever Yang:

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

This more a first glance, I didn't check every binding, but already found
some dubious ones, so in general, please make sure to only include nodes
with approved bindings.



Thanks for your review, this dts is worked with rockchip kernel 4.4 
tree, I have

remove nodes that not upstreamed, but still not clean enough.

[...]


  arch/arm64/boot/dts/rockchip/Makefile   |   1 +
  arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 772 

please provide a binding addition for the board in a separate patch as well.


OK, will do it in next patch.




  2 files changed, 773 insertions(+)
  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 3a86289..dd3d550 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb

if possible, please rebase on top of my for-next branch, as we also
have the first gru board in there now.


OK.


  
  always		:= $(dtb-y)

  subdir-y  := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..686977b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,772 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd

"Ltd."?


Yes, missing the '.'.



+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.

This should be shorter: "SPDX-License-Identifier: GPL-2.0+ OR MIT"

I'm not sure about that. There was disagreement over using SPDX in some
other dts [0]. Sadly it doesn't look like it was resolved either way.

Asking armsoc people on IRC just now, there really isn't any decision one
way or another, so please stay with real license texts until there is an
actual consensus on using spdx tags instead of license texts.


[0] https://lkml.org/lkml/2017/2/28/750


I'm not clear with this, so I just copy it from other dts, if kernel 
have a final

decision, people can move all these license to SPDX format together, right?



+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Firefly Board (Linux Opensource)";

"(Linux Opensource)" is not a hardware descripti

Re: [PATCH] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Hi Heiko, Andreas,


On 04/01/2017 03:41 AM, Heiko Stuebner wrote:

Hi,

Am Freitag, 31. März 2017, 18:59:49 CEST schrieb Andreas Färber:

Am 31.03.2017 um 14:56 schrieb Heiko Stuebner:

Hi Kever,

Am Freitag, 31. März 2017, 17:59:07 CEST schrieb Kever Yang:

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

This more a first glance, I didn't check every binding, but already found
some dubious ones, so in general, please make sure to only include nodes
with approved bindings.



Thanks for your review, this dts is worked with rockchip kernel 4.4 
tree, I have

remove nodes that not upstreamed, but still not clean enough.

[...]


  arch/arm64/boot/dts/rockchip/Makefile   |   1 +
  arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 772 

please provide a binding addition for the board in a separate patch as well.


OK, will do it in next patch.




  2 files changed, 773 insertions(+)
  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 3a86289..dd3d550 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb

if possible, please rebase on top of my for-next branch, as we also
have the first gru board in there now.


OK.


  
  always		:= $(dtb-y)

  subdir-y  := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..686977b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,772 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd

"Ltd."?


Yes, missing the '.'.



+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.

This should be shorter: "SPDX-License-Identifier: GPL-2.0+ OR MIT"

I'm not sure about that. There was disagreement over using SPDX in some
other dts [0]. Sadly it doesn't look like it was resolved either way.

Asking armsoc people on IRC just now, there really isn't any decision one
way or another, so please stay with real license texts until there is an
actual consensus on using spdx tags instead of license texts.


[0] https://lkml.org/lkml/2017/2/28/750


I'm not clear with this, so I just copy it from other dts, if kernel 
have a final

decision, people can move all these license to SPDX format together, right?



+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Firefly Board (Linux Opensource)";

"(Linux Opensource)" is not a hardware descripti

[PATCH] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 772 
 2 files changed, 773 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 3a86289..dd3d550 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..686977b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,772 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Firefly Board (Linux Opensource)";
+   compatible = "rockchip,rk3399-firefly-linux", "rockchip,rk3399";
+
+   backlight: backlight {
+   status = "okay";
+   compatible = "pwm-backlight";
+   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100 101 102 103
+   104 105 106 107 108 109 110 111
+   112 113 114 115 116 117 118 119
+   120 121 122 123 124 125 126 12

[PATCH] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 
---

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 772 
 2 files changed, 773 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 3a86289..dd3d550 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..686977b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,772 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Firefly Board (Linux Opensource)";
+   compatible = "rockchip,rk3399-firefly-linux", "rockchip,rk3399";
+
+   backlight: backlight {
+   status = "okay";
+   compatible = "pwm-backlight";
+   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100 101 102 103
+   104 105 106 107 108 109 110 111
+   112 113 114 115 116 117 118 119
+   120 121 122 123 124 125 126 127
+   

Re: [PATCH v2 1/2] pinctrl: rockchip：Add input schmitt support

[Kever Yang]

Hi David,

On 03/02/2017 03:11 PM, David Wu wrote:

From: "david.wu" 


You do not need to add this when you send mail for yourself,
it's need when you send mail for others.



To prevent external signal crosstalk, some pins need to
enable input schmitt, like i2c pins, 32k-input pin and so on.

Signed-off-by: david.wu 


Better to use "David Wu" for full name, you can correct this in your 
gitconfig file.


Thanks,
- Kever

---
changes in v2:
  - check the return value (Heiko)

  drivers/pinctrl/pinctrl-rockchip.c | 73 ++
  1 file changed, 73 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index a20ce9f..9b8d516 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -308,6 +308,9 @@ struct rockchip_pin_ctrl {
int *reg, u8 *bit);
void(*iomux_recalc)(u8 bank_num, int pin, int *reg,
u8 *bit, int *mask);
+   int (*schmitt_calc_reg)(struct rockchip_pin_bank *bank,
+   int pin_num, struct regmap **regmap,
+   int *reg, u8 *bit);
  };
  
  struct rockchip_pin_config {

@@ -1355,6 +1358,57 @@ static int rockchip_set_pull(struct rockchip_pin_bank 
*bank,
return ret;
  }
  
+static int rockchip_get_schmitt(struct rockchip_pin_bank *bank, int pin_num)

+{
+   struct rockchip_pinctrl *info = bank->drvdata;
+   struct rockchip_pin_ctrl *ctrl = info->ctrl;
+   struct regmap *regmap;
+   int reg, ret;
+   u8 bit;
+   u32 data;
+
+   ret = ctrl->schmitt_calc_reg(bank, pin_num, , , );
+   if (ret)
+   return ret;
+
+   ret = regmap_read(regmap, reg, );
+   if (ret)
+   return ret;
+
+   data >>= bit;
+   return data & 0x1;
+}
+
+static int rockchip_set_schmitt(struct rockchip_pin_bank *bank,
+   int pin_num, int enable)
+{
+   struct rockchip_pinctrl *info = bank->drvdata;
+   struct rockchip_pin_ctrl *ctrl = info->ctrl;
+   struct regmap *regmap;
+   int reg, ret;
+   unsigned long flags;
+   u8 bit;
+   u32 data, rmask;
+
+   dev_dbg(info->dev, "setting input schmitt of GPIO%d-%d to %d\n",
+   bank->bank_num, pin_num, enable);
+
+   ret = ctrl->schmitt_calc_reg(bank, pin_num, , , );
+   if (ret)
+   return ret;
+
+   spin_lock_irqsave(>slock, flags);
+
+   /* enable the write to the equivalent lower bits */
+   data = BIT(bit + 16) | (enable << bit);
+   rmask = BIT(bit + 16) | BIT(bit);
+
+   ret = regmap_update_bits(regmap, reg, rmask, data);
+   spin_unlock_irqrestore(>slock, flags);
+
+   return ret;
+}
+
  /*
   * Pinmux_ops handling
   */
@@ -1574,6 +1628,15 @@ static int rockchip_pinconf_set(struct pinctrl_dev 
*pctldev, unsigned int pin,
if (rc < 0)
return rc;
break;
+   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+   if (!info->ctrl->schmitt_calc_reg)
+   return -ENOTSUPP;
+
+   rc = rockchip_set_schmitt(bank,
+ pin - bank->pin_base, arg);
+   if (rc < 0)
+   return rc;
+   break;
default:
return -ENOTSUPP;
break;
@@ -1634,6 +1697,16 @@ static int rockchip_pinconf_get(struct pinctrl_dev 
*pctldev, unsigned int pin,
  
  		arg = rc;

break;
+   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+   if (!info->ctrl->schmitt_calc_reg)
+   return -ENOTSUPP;
+
+   rc = rockchip_get_schmitt(bank, pin - bank->pin_base);
+   if (rc < 0)
+   return rc;
+
+   arg = rc;
+   break;
default:
return -ENOTSUPP;
break;

Re: [PATCH v2 1/2] pinctrl: rockchip：Add input schmitt support

[Kever Yang]

Hi David,

On 03/02/2017 03:11 PM, David Wu wrote:

From: "david.wu" 


You do not need to add this when you send mail for yourself,
it's need when you send mail for others.



To prevent external signal crosstalk, some pins need to
enable input schmitt, like i2c pins, 32k-input pin and so on.

Signed-off-by: david.wu 


Better to use "David Wu" for full name, you can correct this in your 
gitconfig file.


Thanks,
- Kever

---
changes in v2:
  - check the return value (Heiko)

  drivers/pinctrl/pinctrl-rockchip.c | 73 ++
  1 file changed, 73 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index a20ce9f..9b8d516 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -308,6 +308,9 @@ struct rockchip_pin_ctrl {
int *reg, u8 *bit);
void(*iomux_recalc)(u8 bank_num, int pin, int *reg,
u8 *bit, int *mask);
+   int (*schmitt_calc_reg)(struct rockchip_pin_bank *bank,
+   int pin_num, struct regmap **regmap,
+   int *reg, u8 *bit);
  };
  
  struct rockchip_pin_config {

@@ -1355,6 +1358,57 @@ static int rockchip_set_pull(struct rockchip_pin_bank 
*bank,
return ret;
  }
  
+static int rockchip_get_schmitt(struct rockchip_pin_bank *bank, int pin_num)

+{
+   struct rockchip_pinctrl *info = bank->drvdata;
+   struct rockchip_pin_ctrl *ctrl = info->ctrl;
+   struct regmap *regmap;
+   int reg, ret;
+   u8 bit;
+   u32 data;
+
+   ret = ctrl->schmitt_calc_reg(bank, pin_num, , , );
+   if (ret)
+   return ret;
+
+   ret = regmap_read(regmap, reg, );
+   if (ret)
+   return ret;
+
+   data >>= bit;
+   return data & 0x1;
+}
+
+static int rockchip_set_schmitt(struct rockchip_pin_bank *bank,
+   int pin_num, int enable)
+{
+   struct rockchip_pinctrl *info = bank->drvdata;
+   struct rockchip_pin_ctrl *ctrl = info->ctrl;
+   struct regmap *regmap;
+   int reg, ret;
+   unsigned long flags;
+   u8 bit;
+   u32 data, rmask;
+
+   dev_dbg(info->dev, "setting input schmitt of GPIO%d-%d to %d\n",
+   bank->bank_num, pin_num, enable);
+
+   ret = ctrl->schmitt_calc_reg(bank, pin_num, , , );
+   if (ret)
+   return ret;
+
+   spin_lock_irqsave(>slock, flags);
+
+   /* enable the write to the equivalent lower bits */
+   data = BIT(bit + 16) | (enable << bit);
+   rmask = BIT(bit + 16) | BIT(bit);
+
+   ret = regmap_update_bits(regmap, reg, rmask, data);
+   spin_unlock_irqrestore(>slock, flags);
+
+   return ret;
+}
+
  /*
   * Pinmux_ops handling
   */
@@ -1574,6 +1628,15 @@ static int rockchip_pinconf_set(struct pinctrl_dev 
*pctldev, unsigned int pin,
if (rc < 0)
return rc;
break;
+   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+   if (!info->ctrl->schmitt_calc_reg)
+   return -ENOTSUPP;
+
+   rc = rockchip_set_schmitt(bank,
+ pin - bank->pin_base, arg);
+   if (rc < 0)
+   return rc;
+   break;
default:
return -ENOTSUPP;
break;
@@ -1634,6 +1697,16 @@ static int rockchip_pinconf_get(struct pinctrl_dev 
*pctldev, unsigned int pin,
  
  		arg = rc;

break;
+   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+   if (!info->ctrl->schmitt_calc_reg)
+   return -ENOTSUPP;
+
+   rc = rockchip_get_schmitt(bank, pin - bank->pin_base);
+   if (rc < 0)
+   return rc;
+
+   arg = rc;
+   break;
default:
return -ENOTSUPP;
break;

Re: [v2 PATCH 2/4] phy: Add USB Type-C PHY driver for rk3399

[Kever Yang]

Hi Chris,

On 06/13/2016 05:39 PM, Chris Zhong wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates.

Signed-off-by: Chris Zhong <z...@rock-chips.com>
Signed-off-by: Kever Yang <kever.y...@rock-chips.com>

---

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

  drivers/phy/Kconfig|   8 +
  drivers/phy/Makefile   |   1 +
  drivers/phy/phy-rockchip-typec.c   | 952 +
  include/linux/phy/phy-rockchip-typec.h |  20 +
  4 files changed, 981 insertions(+)
  create mode 100644 drivers/phy/phy-rockchip-typec.c
  create mode 100644 include/linux/phy/phy-rockchip-typec.h

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..ec87b3a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -351,6 +351,14 @@ config PHY_ROCKCHIP_DP
help
  Enable this to support the Rockchip Display Port PHY.
  
+config PHY_ROCKCHIP_TYPEC

+   tristate "Rockchip TYPEC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   select RESET_CONTROLLER
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
  config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 24596a9..91fa413 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += 
phy-qcom-apq8064-sata.o
  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
  obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)   += phy-qcom-ipq806x-sata.o
  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)  += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
new file mode 100644
index 000..230e074
--- /dev/null
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -0,0 +1,952 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong <z...@rock-chips.com>
+ * Kever Yang <kever.y...@rock-chips.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMN_SSM_BANDGAP(0x21 << 2)
+#define CMN_SSM_BIAS   (0x22 << 2)
+#define CMN_PLLSM0_PLLEN   (0x29 << 2)
+#define CMN_PLLSM0_PLLPRE  (0x2a << 2)
+#define CMN_PLLSM0_PLLVREF (0x2b << 2)
+#define CMN_PLLSM0_PLLLOCK (0x2c << 2)
+#define CMN_PLLSM1_PLLEN   (0x31 << 2)
+#define CMN_PLLSM1_PLLPRE  (0x32 << 2)
+#define CMN_PLLSM1_PLLVREF (0x33 << 2)
+#define CMN_PLLSM1_PLLLOCK (0x34 << 2)
+#define CMN_PLLSM1_USER_DEF_CTRL   (0x37 << 2)
+#define CMN_ICAL_OVRD  (0xc1 << 2)
+#define CMN_PLL0_VCOCAL_OVRD   (0x83 << 2)
+#define CMN_PLL0_VCOCAL_INIT   (0x84 << 2)
+#define CMN_PLL0_VCOCAL_ITER   (0x85 << 2)
+#define CMN_PLL0_LOCK_REFCNT_START (0x90 << 2)
+#define CMN_PLL0_LOCK_PLLCNT_START (0x92 << 2)
+#define CMN_PLL0_LOCK_PLLCNT_THR   (0x93 <<

Re: [v2 PATCH 2/4] phy: Add USB Type-C PHY driver for rk3399

[Kever Yang]

Hi Chris,

On 06/13/2016 05:39 PM, Chris Zhong wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 

---

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

  drivers/phy/Kconfig|   8 +
  drivers/phy/Makefile   |   1 +
  drivers/phy/phy-rockchip-typec.c   | 952 +
  include/linux/phy/phy-rockchip-typec.h |  20 +
  4 files changed, 981 insertions(+)
  create mode 100644 drivers/phy/phy-rockchip-typec.c
  create mode 100644 include/linux/phy/phy-rockchip-typec.h

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..ec87b3a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -351,6 +351,14 @@ config PHY_ROCKCHIP_DP
help
  Enable this to support the Rockchip Display Port PHY.
  
+config PHY_ROCKCHIP_TYPEC

+   tristate "Rockchip TYPEC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   select RESET_CONTROLLER
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
  config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 24596a9..91fa413 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += 
phy-qcom-apq8064-sata.o
  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
  obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)   += phy-qcom-ipq806x-sata.o
  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)  += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
new file mode 100644
index 000..230e074
--- /dev/null
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -0,0 +1,952 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ * Kever Yang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMN_SSM_BANDGAP(0x21 << 2)
+#define CMN_SSM_BIAS   (0x22 << 2)
+#define CMN_PLLSM0_PLLEN   (0x29 << 2)
+#define CMN_PLLSM0_PLLPRE  (0x2a << 2)
+#define CMN_PLLSM0_PLLVREF (0x2b << 2)
+#define CMN_PLLSM0_PLLLOCK (0x2c << 2)
+#define CMN_PLLSM1_PLLEN   (0x31 << 2)
+#define CMN_PLLSM1_PLLPRE  (0x32 << 2)
+#define CMN_PLLSM1_PLLVREF (0x33 << 2)
+#define CMN_PLLSM1_PLLLOCK (0x34 << 2)
+#define CMN_PLLSM1_USER_DEF_CTRL   (0x37 << 2)
+#define CMN_ICAL_OVRD  (0xc1 << 2)
+#define CMN_PLL0_VCOCAL_OVRD   (0x83 << 2)
+#define CMN_PLL0_VCOCAL_INIT   (0x84 << 2)
+#define CMN_PLL0_VCOCAL_ITER   (0x85 << 2)
+#define CMN_PLL0_LOCK_REFCNT_START (0x90 << 2)
+#define CMN_PLL0_LOCK_PLLCNT_START (0x92 << 2)
+#define CMN_PLL0_LOCK_PLLCNT_THR   (0x93 << 2)
+#define CMN_PLL0_INTDIV(0x94 << 2)
+#define CMN_PLL0_FRACDIV   (0x95 &l

Re: [PATCH 1/6] phy: Add USB Type-C PHY driver for rk3399

[Kever Yang]

Hi Chris,

On 05/27/2016 02:02 PM, Chris Zhong wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates.

Signed-off-by: Chris Zhong <z...@rock-chips.com>
---

  drivers/phy/Kconfig  |   7 +
  drivers/phy/Makefile |   1 +
  drivers/phy/phy-rockchip-typec.c | 823 +++
  3 files changed, 831 insertions(+)
  create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..dc388a3d 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -351,6 +351,13 @@ config PHY_ROCKCHIP_DP
help
  Enable this to support the Rockchip Display Port PHY.
  
+config PHY_ROCKCHIP_TYPEC

+   tristate "Rockchip TYPEC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
  config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 24596a9..91fa413 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += 
phy-qcom-apq8064-sata.o
  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
  obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)   += phy-qcom-ipq806x-sata.o
  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)  += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
new file mode 100644
index 000..6609cfb
--- /dev/null
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -0,0 +1,823 @@
+/*
+ * Rockchip usb3 PHY driver
+ *
+ * Copyright (C) 2016 Kever Yang <kever.y...@rock-chips.com>
+ *Chris Zhong <z...@rock-chips.com>
+ * Copyright (C) 2016 ROCKCHIP, 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADDR_ADJ   2
+#define CMN_SSM_BANDGAP(0x21 << ADDR_ADJ)
+#define CMN_SSM_BIAS   (0x22 << ADDR_ADJ)
+#define CMN_PLLSM0_PLLEN   (0x29 << ADDR_ADJ)
+#define CMN_PLLSM0_PLLPRE  (0x2a << ADDR_ADJ)
+#define CMN_PLLSM0_PLLVREF (0x2b << ADDR_ADJ)
+#define CMN_PLLSM0_PLLLOCK (0x2c << ADDR_ADJ)
+#define CMN_PLLSM1_PLLEN   (0x31 << ADDR_ADJ)
+#define CMN_PLLSM1_PLLPRE  (0x32 << ADDR_ADJ)
+#define CMN_PLLSM1_PLLVREF (0x33 << ADDR_ADJ)
+#define CMN_PLLSM1_PLLLOCK (0x34 << ADDR_ADJ)
+#define CMN_PLLSM1_USER_DEF_CTRL   (0x37 << ADDR_ADJ)
+#define CMN_ICAL_OVRD  (0xc1 << ADDR_ADJ)
+#define CMN_PLL0_VCOCAL_OVRD   (0x83 << ADDR_ADJ)
+#define CMN_PLL0_VCOCAL_INIT   (0x84 << ADDR_ADJ)
+#define CMN_PLL0_VCOCAL_ITER   (0x85 << ADDR_ADJ)
+#define CMN_PLL0_LOCK_REFCNT_START (0x90 << ADDR_ADJ)
+#define CMN_PLL0_LOCK_PLLCNT_START (0x92 << ADDR_ADJ)
+#define CMN_PLL0_LOCK_PLLCNT_THR   (0x93 << ADDR_ADJ)
+#define CMN_PLL0_INTDIV(0x94 << ADDR_ADJ)
+#define CMN_PLL0_FRACDIV   (0x95 << ADDR_ADJ)
+#define CMN_PLL0_HIGH_THR  (0x96 << ADDR_ADJ)
+#define CMN_PLL0_DSM_DIAG  (0x97 << ADDR_ADJ)
+#define CMN_PLL0_SS_CTRL1  (0x98 << ADDR_ADJ)
+#define CMN_PLL0_SS_CTRL2  (0x99 << ADDR_ADJ)
+#define CMN_PLL1_VCOCAL_START  (0xa1 << ADDR_ADJ)
+#define CMN_PLL1_VCOCAL_OVRD   (0xa3 << ADDR_ADJ)
+#define CMN_PLL1_VCOCAL_INIT   (0xa4 << ADDR_ADJ)
+#define CMN_PLL1_VCOCAL_ITER   (0xa5 << ADDR_ADJ)
+#define CMN_PLL1_LOCK_REFCNT_START (0xb0 << ADDR_ADJ)
+#define CMN_PLL1_LOCK_PLLCNT_START (0xb2 <

Re: [PATCH 1/6] phy: Add USB Type-C PHY driver for rk3399

[Kever Yang]

Hi Chris,

On 05/27/2016 02:02 PM, Chris Zhong wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates.

Signed-off-by: Chris Zhong 
---

  drivers/phy/Kconfig  |   7 +
  drivers/phy/Makefile |   1 +
  drivers/phy/phy-rockchip-typec.c | 823 +++
  3 files changed, 831 insertions(+)
  create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..dc388a3d 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -351,6 +351,13 @@ config PHY_ROCKCHIP_DP
help
  Enable this to support the Rockchip Display Port PHY.
  
+config PHY_ROCKCHIP_TYPEC

+   tristate "Rockchip TYPEC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
  config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 24596a9..91fa413 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)   += 
phy-qcom-apq8064-sata.o
  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
  obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)   += phy-qcom-ipq806x-sata.o
  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)  += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
new file mode 100644
index 000..6609cfb
--- /dev/null
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -0,0 +1,823 @@
+/*
+ * Rockchip usb3 PHY driver
+ *
+ * Copyright (C) 2016 Kever Yang 
+ *Chris Zhong 
+ * Copyright (C) 2016 ROCKCHIP, 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADDR_ADJ   2
+#define CMN_SSM_BANDGAP(0x21 << ADDR_ADJ)
+#define CMN_SSM_BIAS   (0x22 << ADDR_ADJ)
+#define CMN_PLLSM0_PLLEN   (0x29 << ADDR_ADJ)
+#define CMN_PLLSM0_PLLPRE  (0x2a << ADDR_ADJ)
+#define CMN_PLLSM0_PLLVREF (0x2b << ADDR_ADJ)
+#define CMN_PLLSM0_PLLLOCK (0x2c << ADDR_ADJ)
+#define CMN_PLLSM1_PLLEN   (0x31 << ADDR_ADJ)
+#define CMN_PLLSM1_PLLPRE  (0x32 << ADDR_ADJ)
+#define CMN_PLLSM1_PLLVREF (0x33 << ADDR_ADJ)
+#define CMN_PLLSM1_PLLLOCK (0x34 << ADDR_ADJ)
+#define CMN_PLLSM1_USER_DEF_CTRL   (0x37 << ADDR_ADJ)
+#define CMN_ICAL_OVRD  (0xc1 << ADDR_ADJ)
+#define CMN_PLL0_VCOCAL_OVRD   (0x83 << ADDR_ADJ)
+#define CMN_PLL0_VCOCAL_INIT   (0x84 << ADDR_ADJ)
+#define CMN_PLL0_VCOCAL_ITER   (0x85 << ADDR_ADJ)
+#define CMN_PLL0_LOCK_REFCNT_START (0x90 << ADDR_ADJ)
+#define CMN_PLL0_LOCK_PLLCNT_START (0x92 << ADDR_ADJ)
+#define CMN_PLL0_LOCK_PLLCNT_THR   (0x93 << ADDR_ADJ)
+#define CMN_PLL0_INTDIV(0x94 << ADDR_ADJ)
+#define CMN_PLL0_FRACDIV   (0x95 << ADDR_ADJ)
+#define CMN_PLL0_HIGH_THR  (0x96 << ADDR_ADJ)
+#define CMN_PLL0_DSM_DIAG  (0x97 << ADDR_ADJ)
+#define CMN_PLL0_SS_CTRL1  (0x98 << ADDR_ADJ)
+#define CMN_PLL0_SS_CTRL2  (0x99 << ADDR_ADJ)
+#define CMN_PLL1_VCOCAL_START  (0xa1 << ADDR_ADJ)
+#define CMN_PLL1_VCOCAL_OVRD   (0xa3 << ADDR_ADJ)
+#define CMN_PLL1_VCOCAL_INIT   (0xa4 << ADDR_ADJ)
+#define CMN_PLL1_VCOCAL_ITER   (0xa5 << ADDR_ADJ)
+#define CMN_PLL1_LOCK_REFCNT_START (0xb0 << ADDR_ADJ)
+#define CMN_PLL1_LOCK_PLLCNT_START (0xb2 << ADDR_ADJ)
+#define CMN_PLL1_LOCK_PLLCNT_THR   (0xb3 << ADDR_ADJ)
+#define CMN_PLL

Re: [PATCH 0/6] Rockchip Type-C and DispplayPort driver

[Kever Yang]

Hi Chris,

On 05/27/2016 02:02 PM, Chris Zhong wrote:

Hi all

This series patch is for rockchip Type-C phy and DisplayPort controller
driver.

The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data rates. The Type-C cable orientation detection and Power Delivery
(PD) is accomplished using a PD PHY or a exernal PD chip.

The DP controller is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work, please
put the firmware file to /lib/firmware/cdn/dptx.bin. The uCPU in charge
of aux communication and link training, the host use mailbox to
communicate with the ucpu.

The PHY driver has register a notification, to get the alt mode from PD,
the PD driver need call the tcphy_notifier_call_chain to notify PHY and
DP controller.

For the notification for the port status change from PD, I think we can
use the extcon class, pls reference the code in drivers/extcon/ for usage.

Thanks,
- Kever


This series is based on Mark Yao's branch:
https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23

I test this patches on the rk3399-evb board, with a fusb302 driver,
this branch has no rk3399.dtsi, so the patch about dts is not included
in this series.



Chris Zhong (6):
   phy: Add USB Type-C PHY driver for rk3399
   Documentation: bindings: add dt doc for Rockchip USB Type-C PHY
   drm/rockchip: vop: add cdn DP support for rk3399
   Documentation: bindings: add dt documentation for cdn DP controller
   ASoC: cdn-dp: Add cdn DP codec driver
   ASoC: rockchip: Add machine driver for cdn dp codec

  .../bindings/display/rockchip/cdn-dp-rockchip.txt  |  57 ++
  .../devicetree/bindings/phy/phy-rockchip-typec.txt |  55 ++
  .../bindings/sound/rockchip-cdn-dp-audio.txt   |  12 +
  drivers/gpu/drm/rockchip/Kconfig   |   9 +
  drivers/gpu/drm/rockchip/Makefile  |   1 +
  drivers/gpu/drm/rockchip/cdn-dp-core.c | 620 
  drivers/gpu/drm/rockchip/cdn-dp-core.h |  95 +++
  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 730 ++
  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 404 ++
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c|   9 +-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c|   2 +
  drivers/phy/Kconfig|   7 +
  drivers/phy/Makefile   |   1 +
  drivers/phy/phy-rockchip-typec.c   | 823 +
  include/sound/cdn-dp-audio.h   |  51 ++
  sound/soc/codecs/Kconfig   |   3 +
  sound/soc/codecs/Makefile  |   2 +
  sound/soc/codecs/cdn-dp-audio.c| 246 ++
  sound/soc/rockchip/Kconfig |   9 +
  sound/soc/rockchip/Makefile|   2 +
  sound/soc/rockchip/rockchip-cdn-dp-audio.c | 167 +
  22 files changed, 3306 insertions(+), 1 deletion(-)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
  create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
  create mode 100644 
Documentation/devicetree/bindings/sound/rockchip-cdn-dp-audio.txt
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h
  create mode 100644 drivers/phy/phy-rockchip-typec.c
  create mode 100644 include/sound/cdn-dp-audio.h
  create mode 100644 sound/soc/codecs/cdn-dp-audio.c
  create mode 100644 sound/soc/rockchip/rockchip-cdn-dp-audio.c

Re: [PATCH 0/6] Rockchip Type-C and DispplayPort driver

[Kever Yang]

Hi Chris,

On 05/27/2016 02:02 PM, Chris Zhong wrote:

Hi all

This series patch is for rockchip Type-C phy and DisplayPort controller
driver.

The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data rates. The Type-C cable orientation detection and Power Delivery
(PD) is accomplished using a PD PHY or a exernal PD chip.

The DP controller is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work, please
put the firmware file to /lib/firmware/cdn/dptx.bin. The uCPU in charge
of aux communication and link training, the host use mailbox to
communicate with the ucpu.

The PHY driver has register a notification, to get the alt mode from PD,
the PD driver need call the tcphy_notifier_call_chain to notify PHY and
DP controller.

For the notification for the port status change from PD, I think we can
use the extcon class, pls reference the code in drivers/extcon/ for usage.

Thanks,
- Kever


This series is based on Mark Yao's branch:
https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23

I test this patches on the rk3399-evb board, with a fusb302 driver,
this branch has no rk3399.dtsi, so the patch about dts is not included
in this series.



Chris Zhong (6):
   phy: Add USB Type-C PHY driver for rk3399
   Documentation: bindings: add dt doc for Rockchip USB Type-C PHY
   drm/rockchip: vop: add cdn DP support for rk3399
   Documentation: bindings: add dt documentation for cdn DP controller
   ASoC: cdn-dp: Add cdn DP codec driver
   ASoC: rockchip: Add machine driver for cdn dp codec

  .../bindings/display/rockchip/cdn-dp-rockchip.txt  |  57 ++
  .../devicetree/bindings/phy/phy-rockchip-typec.txt |  55 ++
  .../bindings/sound/rockchip-cdn-dp-audio.txt   |  12 +
  drivers/gpu/drm/rockchip/Kconfig   |   9 +
  drivers/gpu/drm/rockchip/Makefile  |   1 +
  drivers/gpu/drm/rockchip/cdn-dp-core.c | 620 
  drivers/gpu/drm/rockchip/cdn-dp-core.h |  95 +++
  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 730 ++
  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 404 ++
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c|   9 +-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c|   2 +
  drivers/phy/Kconfig|   7 +
  drivers/phy/Makefile   |   1 +
  drivers/phy/phy-rockchip-typec.c   | 823 +
  include/sound/cdn-dp-audio.h   |  51 ++
  sound/soc/codecs/Kconfig   |   3 +
  sound/soc/codecs/Makefile  |   2 +
  sound/soc/codecs/cdn-dp-audio.c| 246 ++
  sound/soc/rockchip/Kconfig |   9 +
  sound/soc/rockchip/Makefile|   2 +
  sound/soc/rockchip/rockchip-cdn-dp-audio.c | 167 +
  22 files changed, 3306 insertions(+), 1 deletion(-)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
  create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
  create mode 100644 
Documentation/devicetree/bindings/sound/rockchip-cdn-dp-audio.txt
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h
  create mode 100644 drivers/phy/phy-rockchip-typec.c
  create mode 100644 include/sound/cdn-dp-audio.h
  create mode 100644 sound/soc/codecs/cdn-dp-audio.c
  create mode 100644 sound/soc/rockchip/rockchip-cdn-dp-audio.c

Re: [PATCH v6 20/22] usb: dwc2: host: Properly set even/odd frame

[Kever Yang]

Doug,

Thanks for your detail debug information, pls add my Reviewed-by for 
this patch.


Thanks,
- Kever
On 02/03/2016 06:47 AM, Doug Anderson wrote:

Kever,

On Mon, Feb 1, 2016 at 11:46 PM, Kever Yang  wrote:

Doug,


On 01/29/2016 10:20 AM, Douglas Anderson wrote:

When setting up ISO and INT transfers dwc2 needs to specify whether the
transfer is for an even or an odd frame (or microframe if the controller
is running in high speed mode).

The controller appears to use this as a simple way to figure out if a
transfer should happen right away (in the current microframe) or should
happen at the start of the next microframe.  Said another way:

- If you set "odd" and the current frame number is odd it appears that
the controller will try to transfer right away.  Same thing if you set
"even" and the current frame number is even.
- If the oddness you set and the oddness of the frame number are
_different_, the transfer will be delayed until the frame number
changes.

As I understand it, the above technique allows you to plan ahead of time
where possible by always working on the next frame.  ...but it still
allows you to properly respond immediately to things that happened in
the previous frame.

The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
It always looked at the frame number and setup the transfer to happen in
the next frame.  In some cases that meant that certain transactions
would be transferred in the wrong frame.

We'll try our best to set the even / odd to do the transfer in the
scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
We'll also modify the scheduler code to handle this and not try to
schedule a second transfer for the same frame.

Note that this change relies on the work to redo the microframe
scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
in scheduler") but it works even better after ("usb: dwc2: host: Totally
redo the microframe scheduler").

With this change my stressful USB test (USB webcam + USB audio +
keyboards) has less audio crackling than before.

Seems this really help for your case?

Yes, I believe it does.  Of course my test case is pretty "black box"
for the most part in that I play music on youtube while having a
webcam open and several USB input devices connected.  I then try to
decide whether I hear more static or less static.  ...clearly a less
subjective test would be better...

* I tried with http://crosreview.com/325451 (see below) and I hear
more static with "use_old = true" than with "use_old = "false".

* I tried with this entire patch reverted and I hear about the same
static as with "use_old = true".

Note that counting reported MISS lines from my logging also shows that
the new code is better...



Do you check if the transfer can happen right in the current frame? I know
it's
quite difficult to check it, but this changes what I know for the dwc core
schedule the transaction.

Yes.  I just tried again, too.  I coded up
<https://chromium-review.googlesource.com/325451> and included it.  I
then opened up a USB webcam.

With things set to the old way:

   115.355370  QH=dc6ba8c0 next(0) fn=10cb, sch=10ca=>10cb (+1) miss=0
   115.355373  QH=dc6ba8c0 IMM ready fn=10cb, nxt=10cb
   115.355518  QH=dc6ba8c0 next(0) fn=10cc, sch=10cb=>10cc (+1) miss=0
   115.355522  QH=dc6ba8c0 IMM ready fn=10cc, nxt=10cc
   115.355637  QH=dc6ba8c0 next(0) fn=10cd, sch=10cc=>10cd (+1) miss=0
   115.355641  QH=dc6ba8c0 IMM ready fn=10cd, nxt=10cd
   115.355857  QH=dc6ba8c0 next(0) fn=10ce, sch=10cd=>10ce (+1) miss=0
   115.355859  QH=dc6ba8c0 IMM ready fn=10ce, nxt=10ce
   115.355867  QH=dc6ba8c0, wire=10cf, old_wire=10d0, EO diff (use OLD)
   115.355870  QH=dc6ba8c0 EO MISS w/ old (10ce != 10cf)
   115.356037  QH=dc6ba8c0 next(0) fn=10d0, sch=10cf=>10d0 (+1) miss=1 MISS
   115.356039  QH=dc6ba8c0 IMM ready fn=10d0, nxt=10d0
   115.356169  QH=dc6ba8c0 next(0) fn=10d1, sch=10d0=>10d1 (+1) miss=0
   115.356170  QH=dc6ba8c0 IMM ready fn=10d1, nxt=10d1
   115.356269  QH=dc6ba8c0 next(0) fn=10d2, sch=10d1=>10d2 (+1) miss=0
   115.356273  QH=dc6ba8c0 IMM ready fn=10d2, nxt=10d2
   115.356404  QH=dc6ba8c0 next(0) fn=10d3, sch=10d2=>10d3 (+1) miss=0
   115.356407  QH=dc6ba8c0 IMM ready fn=10d3, nxt=10d3

With the new way:

87.814741  QH=e2fd7880 next(0) fn=32e4, sch=32e3=>32e4 (+1) miss=0
87.814744  QH=e2fd7880 IMM ready fn=32e4, nxt=32e4
87.814858  QH=e2fd7880 next(0) fn=32e5, sch=32e4=>32e5 (+1) miss=0
87.814862  QH=e2fd7880 IMM ready fn=32e5, nxt=32e5
87.815010  QH=e2fd7880 next(0) fn=32e6, sch=32e5=>32e6 (+1) miss=0
87.815012  QH=e2fd7880 IMM ready fn=32e6, nxt=32e6
87.815220  QH=e2fd7880 next(0) fn=32e8, sch=32e6=>32e7 (+1) miss=0
87.815222  QH=e2fd7880 IMM ready fn=32e8, nxt=32e7
87.815230  QH=e2fd7880, wire=32e8, old_wire=32e9, E

Re: [PATCH v6 20/22] usb: dwc2: host: Properly set even/odd frame

[Kever Yang]

Doug,

Thanks for your detail debug information, pls add my Reviewed-by for 
this patch.


Thanks,
- Kever
On 02/03/2016 06:47 AM, Doug Anderson wrote:

Kever,

On Mon, Feb 1, 2016 at 11:46 PM, Kever Yang <kever.y...@rock-chips.com> wrote:

Doug,


On 01/29/2016 10:20 AM, Douglas Anderson wrote:

When setting up ISO and INT transfers dwc2 needs to specify whether the
transfer is for an even or an odd frame (or microframe if the controller
is running in high speed mode).

The controller appears to use this as a simple way to figure out if a
transfer should happen right away (in the current microframe) or should
happen at the start of the next microframe.  Said another way:

- If you set "odd" and the current frame number is odd it appears that
the controller will try to transfer right away.  Same thing if you set
"even" and the current frame number is even.
- If the oddness you set and the oddness of the frame number are
_different_, the transfer will be delayed until the frame number
changes.

As I understand it, the above technique allows you to plan ahead of time
where possible by always working on the next frame.  ...but it still
allows you to properly respond immediately to things that happened in
the previous frame.

The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
It always looked at the frame number and setup the transfer to happen in
the next frame.  In some cases that meant that certain transactions
would be transferred in the wrong frame.

We'll try our best to set the even / odd to do the transfer in the
scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
We'll also modify the scheduler code to handle this and not try to
schedule a second transfer for the same frame.

Note that this change relies on the work to redo the microframe
scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
in scheduler") but it works even better after ("usb: dwc2: host: Totally
redo the microframe scheduler").

With this change my stressful USB test (USB webcam + USB audio +
keyboards) has less audio crackling than before.

Seems this really help for your case?

Yes, I believe it does.  Of course my test case is pretty "black box"
for the most part in that I play music on youtube while having a
webcam open and several USB input devices connected.  I then try to
decide whether I hear more static or less static.  ...clearly a less
subjective test would be better...

* I tried with http://crosreview.com/325451 (see below) and I hear
more static with "use_old = true" than with "use_old = "false".

* I tried with this entire patch reverted and I hear about the same
static as with "use_old = true".

Note that counting reported MISS lines from my logging also shows that
the new code is better...



Do you check if the transfer can happen right in the current frame? I know
it's
quite difficult to check it, but this changes what I know for the dwc core
schedule the transaction.

Yes.  I just tried again, too.  I coded up
<https://chromium-review.googlesource.com/325451> and included it.  I
then opened up a USB webcam.

With things set to the old way:

   115.355370  QH=dc6ba8c0 next(0) fn=10cb, sch=10ca=>10cb (+1) miss=0
   115.355373  QH=dc6ba8c0 IMM ready fn=10cb, nxt=10cb
   115.355518  QH=dc6ba8c0 next(0) fn=10cc, sch=10cb=>10cc (+1) miss=0
   115.355522  QH=dc6ba8c0 IMM ready fn=10cc, nxt=10cc
   115.355637  QH=dc6ba8c0 next(0) fn=10cd, sch=10cc=>10cd (+1) miss=0
   115.355641  QH=dc6ba8c0 IMM ready fn=10cd, nxt=10cd
   115.355857  QH=dc6ba8c0 next(0) fn=10ce, sch=10cd=>10ce (+1) miss=0
   115.355859  QH=dc6ba8c0 IMM ready fn=10ce, nxt=10ce
   115.355867  QH=dc6ba8c0, wire=10cf, old_wire=10d0, EO diff (use OLD)
   115.355870  QH=dc6ba8c0 EO MISS w/ old (10ce != 10cf)
   115.356037  QH=dc6ba8c0 next(0) fn=10d0, sch=10cf=>10d0 (+1) miss=1 MISS
   115.356039  QH=dc6ba8c0 IMM ready fn=10d0, nxt=10d0
   115.356169  QH=dc6ba8c0 next(0) fn=10d1, sch=10d0=>10d1 (+1) miss=0
   115.356170  QH=dc6ba8c0 IMM ready fn=10d1, nxt=10d1
   115.356269  QH=dc6ba8c0 next(0) fn=10d2, sch=10d1=>10d2 (+1) miss=0
   115.356273  QH=dc6ba8c0 IMM ready fn=10d2, nxt=10d2
   115.356404  QH=dc6ba8c0 next(0) fn=10d3, sch=10d2=>10d3 (+1) miss=0
   115.356407  QH=dc6ba8c0 IMM ready fn=10d3, nxt=10d3

With the new way:

87.814741  QH=e2fd7880 next(0) fn=32e4, sch=32e3=>32e4 (+1) miss=0
87.814744  QH=e2fd7880 IMM ready fn=32e4, nxt=32e4
87.814858  QH=e2fd7880 next(0) fn=32e5, sch=32e4=>32e5 (+1) miss=0
87.814862  QH=e2fd7880 IMM ready fn=32e5, nxt=32e5
87.815010  QH=e2fd7880 next(0) fn=32e6, sch=32e5=>32e6 (+1) miss=0
87.815012  QH=e2fd7880 IMM ready fn=32e6, nxt=32e6
87.815220  QH=e2fd7880 next(0) fn=32e8, sch=32e6=>32e7 (+1) miss=0
87.815222  QH=e2fd7880 IMM ready fn=32e8, nxt=32e7
87.815230  QH

Re: [PATCH v6 20/22] usb: dwc2: host: Properly set even/odd frame

[Kever Yang]

Doug,

On 01/29/2016 10:20 AM, Douglas Anderson wrote:

When setting up ISO and INT transfers dwc2 needs to specify whether the
transfer is for an even or an odd frame (or microframe if the controller
is running in high speed mode).

The controller appears to use this as a simple way to figure out if a
transfer should happen right away (in the current microframe) or should
happen at the start of the next microframe.  Said another way:

- If you set "odd" and the current frame number is odd it appears that
   the controller will try to transfer right away.  Same thing if you set
   "even" and the current frame number is even.
- If the oddness you set and the oddness of the frame number are
   _different_, the transfer will be delayed until the frame number
   changes.

As I understand it, the above technique allows you to plan ahead of time
where possible by always working on the next frame.  ...but it still
allows you to properly respond immediately to things that happened in
the previous frame.

The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
It always looked at the frame number and setup the transfer to happen in
the next frame.  In some cases that meant that certain transactions
would be transferred in the wrong frame.

We'll try our best to set the even / odd to do the transfer in the
scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
We'll also modify the scheduler code to handle this and not try to
schedule a second transfer for the same frame.

Note that this change relies on the work to redo the microframe
scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
in scheduler") but it works even better after ("usb: dwc2: host: Totally
redo the microframe scheduler").

With this change my stressful USB test (USB webcam + USB audio +
keyboards) has less audio crackling than before.

Seems this really help for your case?

Do you check if the transfer can happen right in the current frame? I 
know it's

quite difficult to check it, but this changes what I know for the dwc core
schedule the transaction.

In dwc_otgbook, Interrupt OUT Transactions(also similar for Int IN, Iso 
IN/OUT)

in DMA Mode, the normal Interrupt OUT operation says:
The DWC_otg host attempts to send out the OUT token in the beginning of next
odd frame/microframe.

So I'm confuse about if the dwc core can do the transaction at the same 
frame

of host channel initialized or not.

Thanks,
- Kever


Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Properly set even/odd frame new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.c  | 92 +++-
  drivers/usb/dwc2/hcd_queue.c | 11 +-
  2 files changed, 100 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index a5db20f12ee4..c143f26bd9d9 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -1703,9 +1703,97 @@ static void dwc2_hc_set_even_odd_frame(struct dwc2_hsotg 
*hsotg,
  {
if (chan->ep_type == USB_ENDPOINT_XFER_INT ||
chan->ep_type == USB_ENDPOINT_XFER_ISOC) {
-   /* 1 if _next_ frame is odd, 0 if it's even */
-   if (!(dwc2_hcd_get_frame_number(hsotg) & 0x1))
+   int host_speed;
+   int xfer_ns;
+   int xfer_us;
+   int bytes_in_fifo;
+   u16 fifo_space;
+   u16 frame_number;
+   u16 wire_frame;
+
+   /*
+* Try to figure out if we're an even or odd frame. If we set
+* even and the current frame number is even the the transfer
+* will happen immediately.  Similar if both are odd. If one is
+* even and the other is odd then the transfer will happen when
+* the frame number ticks.
+*
+* There's a bit of a balancing act to get this right.
+* Sometimes we may want to send data in the current frame (AK
+* right away).  We might want to do this if the frame number
+* _just_ ticked, but we might also want to do this in order
+* to continue a split transaction that happened late in a
+* microframe (so we didn't know to queue the next transfer
+* until the frame number had ticked).  The problem is that we
+* need a lot of knowledge to know if there's actually still
+* time to send things or if it would be better to wait until
+* the next frame.
+*
+* We can look at how much time is left in the current frame
+* and make a guess about whether we'll have time to transfer.
+* We'll do that.
+*/
+
+ 

Re: [PATCH v6 18/22] usb: dwc2: host: Schedule periodic right away if it's time

[Kever Yang]

Doug,

On 02/02/2016 08:36 AM, Doug Anderson wrote:

Kever,

On Sun, Jan 31, 2016 at 8:36 PM, Doug Anderson  wrote:

Kever,

On Sun, Jan 31, 2016 at 7:32 PM, Kever Yang  wrote:

Doug,


On 02/01/2016 06:09 AM, Doug Anderson wrote:

Kever,

On Sun, Jan 31, 2016 at 1:36 AM, Kever Yang 
wrote:

Doug,


On 01/29/2016 10:20 AM, Douglas Anderson wrote:

In dwc2_hcd_qh_deactivate() we will put some things on the
periodic_sched_ready list.  These things won't be taken off the ready
list until the next SOF, which might be a little late.  Let's put them
on right away.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Schedule periodic right away if it's time new for v4.

Changes in v3: None
Changes in v2: None

drivers/usb/dwc2/hcd_queue.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 9b3c435339ee..3abb34a5fc5b 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -1080,12 +1080,26 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh,
   * Note: we purposely use the frame_number from the "hsotg"
structure
   * since we know SOF interrupt will handle future frames.
   */
-   if (dwc2_frame_num_le(qh->next_active_frame,
hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->next_active_frame,
hsotg->frame_number))
{
+   enum dwc2_transaction_type tr_type;
+
+   /*
+* We're bypassing the SOF handler which is normally
what
puts
+* us on the ready list because we're in a hurry and
need
to
+* try to catch up.
+*/
+   dwc2_sch_vdbg(hsotg, "QH=%p IMM ready fn=%04x,
nxt=%04x\n",
+ qh, frame_number, qh->next_active_frame);
  list_move_tail(>qh_list_entry,
 >periodic_sched_ready);
-   else
+
+   tr_type = dwc2_hcd_select_transactions(hsotg);

Do we need to add select_transactions call here? If we get into this
function in interrupt
and once we put the qh in ready queue, the qh can be handled in this
frame
again by the
later function call of dwc_hcd_select_transactions, so what we need to to
here is put
it in ready list instead of inactive queue, and wait for the schedule.

I'm not sure I understand.  Can you restate?


I'll try to explain more in the meantime...

Both before and after my change, this function would place something
on the ready queue if the next_active_frame <= the frame number as of
last SOF interrupt (aka hsotg->frame_number).  Otherwise it goes on
the inactive queue.  Assuming that the previous change ("usb: dwc2:
host: Manage frame nums better in scheduler") worked properly then
next_active_frame shouldn't be less than (hsotg->frame_number - 1).
Remember that next_active_frame is always 1 before the wire frame, so
if "next_active_frame == hsotg->frame_number - 1" it means that we
need to get the transfer on the wire _right away_.  If
"next_active_frame == hsotg->frame_number" the transfer doesn't need
to go on the wire right away, but since dwc2 can be prepped one frame
in advance it doesn't hurt to give it to the hardware right away if
there's space.

As I understand it, if we stick something on the ready queue it won't
generally get looked at until the next SOF interrupt.  That means
we'll be too late if "next_active_frame == hsotg->frame_number - 1"
and we'll possibly be too late (depending on interrupt latency) if
"next_active_frame == hsotg->frame_number"


I understand this patch and agree with your point of schedule the
periodic right away instead of at least next frame.
My point is, there are only two call to dwc2_hcd_qh_deactivate(), from
dwc2_hcd_urb_dequeue() and dwc2_release_channel(), we don't need
to do the schedule for dequeue, and there is one
dwc2_hcd_select_transactions() call at the end of dwc2_release_channel(),
maybe we don't need another dwc2_hcd_select_transactions() here.

I think the duration from this point to the function call of
dwc2_hcd_select_transactions()
in dwc2_release_channel() will be the main factor for us to decide if
we need to add a function call of  dwc2_hcd_select_transactions() here.

Oh, now I get what you're saying!

A) You've got dwc2_release_channel() -> dwc2_deactivate_qh() ->
dwc2_hcd_qh_deactivate()
...and always in that case we'll do a select / queue, so we don't need it there.

B) You've got dwc2_hcd_urb_dequeue() -> dwc2_hcd_qh_deactivate()

...but why don't we need it for dwc2_hcd_urb_dequeue()?  Yes, you're
not continuing a split so timing isn't quite as urgent, but you still
might have an INT or ISOC packet t

Re: [PATCH v6 18/22] usb: dwc2: host: Schedule periodic right away if it's time

[Kever Yang]

Doug,

On 02/02/2016 08:36 AM, Doug Anderson wrote:

Kever,

On Sun, Jan 31, 2016 at 8:36 PM, Doug Anderson <diand...@chromium.org> wrote:

Kever,

On Sun, Jan 31, 2016 at 7:32 PM, Kever Yang <kever.y...@rock-chips.com> wrote:

Doug,


On 02/01/2016 06:09 AM, Doug Anderson wrote:

Kever,

On Sun, Jan 31, 2016 at 1:36 AM, Kever Yang <kever.y...@rock-chips.com>
wrote:

Doug,


On 01/29/2016 10:20 AM, Douglas Anderson wrote:

In dwc2_hcd_qh_deactivate() we will put some things on the
periodic_sched_ready list.  These things won't be taken off the ready
list until the next SOF, which might be a little late.  Let's put them
on right away.

Signed-off-by: Douglas Anderson <diand...@chromium.org>
Tested-by: Heiko Stuebner <he...@sntech.de>
Tested-by: Stefan Wahren <stefan.wah...@i2se.com>
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Schedule periodic right away if it's time new for v4.

Changes in v3: None
Changes in v2: None

drivers/usb/dwc2/hcd_queue.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 9b3c435339ee..3abb34a5fc5b 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -1080,12 +1080,26 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh,
   * Note: we purposely use the frame_number from the "hsotg"
structure
   * since we know SOF interrupt will handle future frames.
   */
-   if (dwc2_frame_num_le(qh->next_active_frame,
hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->next_active_frame,
hsotg->frame_number))
{
+   enum dwc2_transaction_type tr_type;
+
+   /*
+* We're bypassing the SOF handler which is normally
what
puts
+* us on the ready list because we're in a hurry and
need
to
+* try to catch up.
+*/
+   dwc2_sch_vdbg(hsotg, "QH=%p IMM ready fn=%04x,
nxt=%04x\n",
+ qh, frame_number, qh->next_active_frame);
  list_move_tail(>qh_list_entry,
 >periodic_sched_ready);
-   else
+
+   tr_type = dwc2_hcd_select_transactions(hsotg);

Do we need to add select_transactions call here? If we get into this
function in interrupt
and once we put the qh in ready queue, the qh can be handled in this
frame
again by the
later function call of dwc_hcd_select_transactions, so what we need to to
here is put
it in ready list instead of inactive queue, and wait for the schedule.

I'm not sure I understand.  Can you restate?


I'll try to explain more in the meantime...

Both before and after my change, this function would place something
on the ready queue if the next_active_frame <= the frame number as of
last SOF interrupt (aka hsotg->frame_number).  Otherwise it goes on
the inactive queue.  Assuming that the previous change ("usb: dwc2:
host: Manage frame nums better in scheduler") worked properly then
next_active_frame shouldn't be less than (hsotg->frame_number - 1).
Remember that next_active_frame is always 1 before the wire frame, so
if "next_active_frame == hsotg->frame_number - 1" it means that we
need to get the transfer on the wire _right away_.  If
"next_active_frame == hsotg->frame_number" the transfer doesn't need
to go on the wire right away, but since dwc2 can be prepped one frame
in advance it doesn't hurt to give it to the hardware right away if
there's space.

As I understand it, if we stick something on the ready queue it won't
generally get looked at until the next SOF interrupt.  That means
we'll be too late if "next_active_frame == hsotg->frame_number - 1"
and we'll possibly be too late (depending on interrupt latency) if
"next_active_frame == hsotg->frame_number"


I understand this patch and agree with your point of schedule the
periodic right away instead of at least next frame.
My point is, there are only two call to dwc2_hcd_qh_deactivate(), from
dwc2_hcd_urb_dequeue() and dwc2_release_channel(), we don't need
to do the schedule for dequeue, and there is one
dwc2_hcd_select_transactions() call at the end of dwc2_release_channel(),
maybe we don't need another dwc2_hcd_select_transactions() here.

I think the duration from this point to the function call of
dwc2_hcd_select_transactions()
in dwc2_release_channel() will be the main factor for us to decide if
we need to add a function call of  dwc2_hcd_select_transactions() here.

Oh, now I get what you're saying!

A) You've got dwc2_release_channel() -> dwc2_deactivate_qh() ->
dwc2_hcd_qh_deactivate()
...and always in that case we'll do a select / queue, so we don't need it there.

B) You've got dwc2_hcd_urb_dequeue() -> dwc2_hcd_qh_deactivate()

Re: [PATCH v6 20/22] usb: dwc2: host: Properly set even/odd frame

[Kever Yang]

Doug,

On 01/29/2016 10:20 AM, Douglas Anderson wrote:

When setting up ISO and INT transfers dwc2 needs to specify whether the
transfer is for an even or an odd frame (or microframe if the controller
is running in high speed mode).

The controller appears to use this as a simple way to figure out if a
transfer should happen right away (in the current microframe) or should
happen at the start of the next microframe.  Said another way:

- If you set "odd" and the current frame number is odd it appears that
   the controller will try to transfer right away.  Same thing if you set
   "even" and the current frame number is even.
- If the oddness you set and the oddness of the frame number are
   _different_, the transfer will be delayed until the frame number
   changes.

As I understand it, the above technique allows you to plan ahead of time
where possible by always working on the next frame.  ...but it still
allows you to properly respond immediately to things that happened in
the previous frame.

The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
It always looked at the frame number and setup the transfer to happen in
the next frame.  In some cases that meant that certain transactions
would be transferred in the wrong frame.

We'll try our best to set the even / odd to do the transfer in the
scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
We'll also modify the scheduler code to handle this and not try to
schedule a second transfer for the same frame.

Note that this change relies on the work to redo the microframe
scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
in scheduler") but it works even better after ("usb: dwc2: host: Totally
redo the microframe scheduler").

With this change my stressful USB test (USB webcam + USB audio +
keyboards) has less audio crackling than before.

Seems this really help for your case?

Do you check if the transfer can happen right in the current frame? I 
know it's

quite difficult to check it, but this changes what I know for the dwc core
schedule the transaction.

In dwc_otgbook, Interrupt OUT Transactions(also similar for Int IN, Iso 
IN/OUT)

in DMA Mode, the normal Interrupt OUT operation says:
The DWC_otg host attempts to send out the OUT token in the beginning of next
odd frame/microframe.

So I'm confuse about if the dwc core can do the transaction at the same 
frame

of host channel initialized or not.

Thanks,
- Kever


Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Properly set even/odd frame new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.c  | 92 +++-
  drivers/usb/dwc2/hcd_queue.c | 11 +-
  2 files changed, 100 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index a5db20f12ee4..c143f26bd9d9 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -1703,9 +1703,97 @@ static void dwc2_hc_set_even_odd_frame(struct dwc2_hsotg 
*hsotg,
  {
if (chan->ep_type == USB_ENDPOINT_XFER_INT ||
chan->ep_type == USB_ENDPOINT_XFER_ISOC) {
-   /* 1 if _next_ frame is odd, 0 if it's even */
-   if (!(dwc2_hcd_get_frame_number(hsotg) & 0x1))
+   int host_speed;
+   int xfer_ns;
+   int xfer_us;
+   int bytes_in_fifo;
+   u16 fifo_space;
+   u16 frame_number;
+   u16 wire_frame;
+
+   /*
+* Try to figure out if we're an even or odd frame. If we set
+* even and the current frame number is even the the transfer
+* will happen immediately.  Similar if both are odd. If one is
+* even and the other is odd then the transfer will happen when
+* the frame number ticks.
+*
+* There's a bit of a balancing act to get this right.
+* Sometimes we may want to send data in the current frame (AK
+* right away).  We might want to do this if the frame number
+* _just_ ticked, but we might also want to do this in order
+* to continue a split transaction that happened late in a
+* microframe (so we didn't know to queue the next transfer
+* until the frame number had ticked).  The problem is that we
+* need a lot of knowledge to know if there's actually still
+* time to send things or if it would be better to wait until
+* the next frame.
+*
+* We can look at how much time is left in the current frame
+* and make a guess about whether we'll have time to 

Re: [PATCH v6 18/22] usb: dwc2: host: Schedule periodic right away if it's time

[Kever Yang]

Doug,

On 02/01/2016 06:09 AM, Doug Anderson wrote:

Kever,

On Sun, Jan 31, 2016 at 1:36 AM, Kever Yang  wrote:

Doug,


On 01/29/2016 10:20 AM, Douglas Anderson wrote:

In dwc2_hcd_qh_deactivate() we will put some things on the
periodic_sched_ready list.  These things won't be taken off the ready
list until the next SOF, which might be a little late.  Let's put them
on right away.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Schedule periodic right away if it's time new for v4.

Changes in v3: None
Changes in v2: None

   drivers/usb/dwc2/hcd_queue.c | 18 --
   1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 9b3c435339ee..3abb34a5fc5b 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -1080,12 +1080,26 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh,
  * Note: we purposely use the frame_number from the "hsotg"
structure
  * since we know SOF interrupt will handle future frames.
  */
-   if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number))
{
+   enum dwc2_transaction_type tr_type;
+
+   /*
+* We're bypassing the SOF handler which is normally what
puts
+* us on the ready list because we're in a hurry and need
to
+* try to catch up.
+*/
+   dwc2_sch_vdbg(hsotg, "QH=%p IMM ready fn=%04x,
nxt=%04x\n",
+ qh, frame_number, qh->next_active_frame);
 list_move_tail(>qh_list_entry,
>periodic_sched_ready);
-   else
+
+   tr_type = dwc2_hcd_select_transactions(hsotg);

Do we need to add select_transactions call here? If we get into this
function in interrupt
and once we put the qh in ready queue, the qh can be handled in this frame
again by the
later function call of dwc_hcd_select_transactions, so what we need to to
here is put
it in ready list instead of inactive queue, and wait for the schedule.

I'm not sure I understand.  Can you restate?


I'll try to explain more in the meantime...

Both before and after my change, this function would place something
on the ready queue if the next_active_frame <= the frame number as of
last SOF interrupt (aka hsotg->frame_number).  Otherwise it goes on
the inactive queue.  Assuming that the previous change ("usb: dwc2:
host: Manage frame nums better in scheduler") worked properly then
next_active_frame shouldn't be less than (hsotg->frame_number - 1).
Remember that next_active_frame is always 1 before the wire frame, so
if "next_active_frame == hsotg->frame_number - 1" it means that we
need to get the transfer on the wire _right away_.  If
"next_active_frame == hsotg->frame_number" the transfer doesn't need
to go on the wire right away, but since dwc2 can be prepped one frame
in advance it doesn't hurt to give it to the hardware right away if
there's space.

As I understand it, if we stick something on the ready queue it won't
generally get looked at until the next SOF interrupt.  That means
we'll be too late if "next_active_frame == hsotg->frame_number - 1"
and we'll possibly be too late (depending on interrupt latency) if
"next_active_frame == hsotg->frame_number"


I understand this patch and agree with your point of schedule the
periodic right away instead of at least next frame.
My point is, there are only two call to dwc2_hcd_qh_deactivate(), from
dwc2_hcd_urb_dequeue() and dwc2_release_channel(), we don't need
to do the schedule for dequeue, and there is one
dwc2_hcd_select_transactions() call at the end of dwc2_release_channel(),
maybe we don't need another dwc2_hcd_select_transactions() here.

I think the duration from this point to the function call of 
dwc2_hcd_select_transactions()

in dwc2_release_channel() will be the main factor for us to decide if
we need to add a function call of  dwc2_hcd_select_transactions() here.

Thanks,
- Kever

Note that before my series, there were more places than just the SOF
interrupt that would update hsotg->frame_number (see "usb: dwc2: host:
Manage frame nums better in scheduler" for fix).  Also before my
series (specially "usb: dwc2: host: Manage frame nums better in
scheduler") we used the actual current frame number when doing
comparisons.  Also before my series (specifically "usb: dwc2: host:
Properly set even/odd frame") we didn't really place things in the
frame that they were scheduled in anyway.


Also note that I believe that when dwc2_hcd_qh_deactivate() is called

Re: [PATCH v6 18/22] usb: dwc2: host: Schedule periodic right away if it's time

[Kever Yang]

Doug,

On 01/29/2016 10:20 AM, Douglas Anderson wrote:

In dwc2_hcd_qh_deactivate() we will put some things on the
periodic_sched_ready list.  These things won't be taken off the ready
list until the next SOF, which might be a little late.  Let's put them
on right away.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Schedule periodic right away if it's time new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/hcd_queue.c | 18 --
  1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 9b3c435339ee..3abb34a5fc5b 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -1080,12 +1080,26 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg *hsotg, 
struct dwc2_qh *qh,
 * Note: we purposely use the frame_number from the "hsotg" structure
 * since we know SOF interrupt will handle future frames.
 */
-   if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number)) {
+   enum dwc2_transaction_type tr_type;
+
+   /*
+* We're bypassing the SOF handler which is normally what puts
+* us on the ready list because we're in a hurry and need to
+* try to catch up.
+*/
+   dwc2_sch_vdbg(hsotg, "QH=%p IMM ready fn=%04x, nxt=%04x\n",
+ qh, frame_number, qh->next_active_frame);
list_move_tail(>qh_list_entry,
   >periodic_sched_ready);
-   else
+
+   tr_type = dwc2_hcd_select_transactions(hsotg);
Do we need to add select_transactions call here? If we get into this 
function in interrupt
and once we put the qh in ready queue, the qh can be handled in this 
frame again by the
later function call of dwc_hcd_select_transactions, so what we need to 
to here is put

it in ready list instead of inactive queue, and wait for the schedule.

Thanks,
- Kever


+   if (tr_type != DWC2_TRANSACTION_NONE)
+   dwc2_hcd_queue_transactions(hsotg, tr_type);
+   } else {
list_move_tail(>qh_list_entry,
   >periodic_sched_inactive);
+   }
  }
  
  /**

Re: [PATCH v6 10/22] usb: dwc2: host: Properly set the HFIR

[Kever Yang]

Doug,

On 01/29/2016 10:20 AM, Douglas Anderson wrote:

According to the most up to date version of the dwc2 databook, the FRINT
field of the HFIR register should be programmed to:
* 125 us * (PHY clock freq for HS) - 1
* 1000 us * (PHY clock freq for FS/LS) - 1

I got 3 version of dwc_otg databook, 2.74a, 2.94a and 3.10a,
all the doc describe the FrInt as:

* 125 us * (PHY clock freq for HS)
* 1000 us * (PHY clock freq for FS/LS)

Maybe John can help to check the design.

There are some feature different in new and old version, but not sure
if this is one of then.

The doc says If no value is programmed, the corecalculates the value
based on the PHY clock specified in the FS/LS PHY Clock select field of
Host configuration register(HCFG.FLSLPclkSel), does this work?

Thanks,
- Kever


This is opposed to older versions of the doc that claimed it should be:
* 125 us * (PHY clock freq for HS)
* 1000 us * (PHY clock freq for FS/LS)

In case you didn't spot it, the difference is the "- 1".

Let's add the "- 1" to match the newest user manual.  It's presumed that
the "- 1" should have always been there and that this was always a
documentation error.  If some hardware needs the "- 1" and other
hardware doesn't, we'll have to add a configuration parameter for it in
the future.

I checked things before and after this patch on rk3288 using a Total
Phase Beagle 5000 analyzer.

Before this patch, a low speed mouse shows constant Frame Timing Jitter
errors.  After this patch errors have gone away.

Before this patch SOF packets move forward about 1 us per 4 ms.  After
this patch the SOF packets move backward about 1 us per 255 ms.  Some
specific SOF timestamps from the analyzer are below.

Before:
   6.603.790
   6.603.916
   6.604.041
   6.604.166
   ...
   6.607.541
   6.607.667
   6.607.792
   6.607.917
   ...
   6.611.417
   6.611.543
   6.611.668
   6.611.793

After:
   6.215.159
   6.215.284
   6.215.408
   6.215.533
   6.215.658
   ...
   6.470.658
   6.470.783
   6.470.907
   ...
   6.726.032
   6.726.157
   6.725.281
   6.725.406

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
---
Changes in v6:
- Incorporated Properly set the HFIR patch to big series in v6
- Add Heiko's Tested-by.

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index ed73b26818c0..a5db20f12ee4 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -2245,10 +2245,10 @@ u32 dwc2_calc_frame_interval(struct dwc2_hsotg *hsotg)
  
  	if ((hprt0 & HPRT0_SPD_MASK) >> HPRT0_SPD_SHIFT == HPRT0_SPD_HIGH_SPEED)

/* High speed case */
-   return 125 * clock;
+   return 125 * clock - 1;
else
/* FS/LS case */
-   return 1000 * clock;
+   return 1000 * clock - 1;
  }
  
  /**

Re: [PATCH v6 11/22] usb: dwc2: host: There's not really a TT for the root hub

[Kever Yang]

Doug,

Reviewed-by: Kever Yang 

Thanks,
- Kever
On 01/29/2016 10:20 AM, Douglas Anderson wrote:

I find that when I plug a full speed (NOT high speed) hub into a dwc2
port and then I plug a bunch of devices into that full speed hub that
dwc2 goes bat guano crazy.  Specifically, it just spews errors like this
in the console:
   usb usb1: clear tt 1 (9043) error -22

The specific test case I used looks like this:
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
 |__ Port 1: Dev 17, If 0, Class=Hub, Driver=hub/4p, 12M
 |__ Port 2: Dev 19, If 0, ..., Driver=usbhid, 1.5M
 |__ Port 4: Dev 20, If 0, ..., Driver=usbhid, 12M
 |__ Port 4: Dev 20, If 1, ..., Driver=usbhid, 12M
 |__ Port 4: Dev 20, If 2, ..., Driver=usbhid, 12M

Showing VID/PID:
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Bus 001 Device 017: ID 03eb:3301 Atmel Corp. at43301 4-Port Hub
  Bus 001 Device 020: ID 045e:0745 Microsoft Corp. Nano Transceiver ...
  Bus 001 Device 019: ID 046d:c404 Logitech, Inc. TrackMan Wheel

I spent a bunch of time trying to figure out why there are errors to
begin with.  I believe that the issue may be a hardware issue where the
transceiver sometimes accidentally sends a PREAMBLE packet if you send a
packet to a full speed device right after one to a low speed device.
Luckily the USB driver retries and the second time things work OK.

In any case, things kinda seem work despite the errors, except for the
"clear tt" spew mucking up my console.  Chalk it up for a win for
retries and robust protocols.

So getting back to the "clear tt" problem, it appears that we get those
because there's not actually a TT here to clear.  It's my understanding
that when dwc2 operates in low speed or full speed mode that there's no
real TT out there.  That makes all these attempts to "clear the TT"
somewhat meaningless and also causes the spew in the log.

Let's just skip all the useless TT clears.  Eventually we should root
cause the errors, but even if we do this is still a proper fix and is
likely to avoid the "clear tt" error in the future.

Note that hooking up a Full Speed USB Audio Device (Jabra 510) to this
same hub with the keyboard / trackball shows that even audio works over
this janky connection.  As a point to note, this particular change (skip
bogus TT clears) compared to just commenting out the dev_err() in
hub_tt_work() actually produces better audio.

Note: don't ask me where I got a full speed USB hub or whether the
massive amount of dust that accumulated on it while it was in my junk
box affected its funtionality.  Just smile and nod.

Signed-off-by: Douglas Anderson 
---
Changes in v6:
- There's not really a TT for the root hub new for v6

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/hcd_intr.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 5d25a5ec9736..fe44870f84eb 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -87,6 +87,7 @@ static void dwc2_hc_handle_tt_clear(struct dwc2_hsotg *hsotg,
struct dwc2_host_chan *chan,
struct dwc2_qtd *qtd)
  {
+   struct usb_device *root_hub = dwc2_hsotg_to_hcd(hsotg)->self.root_hub;
struct urb *usb_urb;
  
  	if (!chan->qh)

@@ -102,6 +103,15 @@ static void dwc2_hc_handle_tt_clear(struct dwc2_hsotg 
*hsotg,
if (!usb_urb || !usb_urb->dev || !usb_urb->dev->tt)
return;
  
+	/*

+* The root hub doesn't really have a TT, but Linux thinks it
+* does because how could you have a "high speed hub" that
+* directly talks directly to low speed devices without a TT?
+* It's all lies.  Lies, I tell you.
+*/
+   if (usb_urb->dev->tt->hub == root_hub)
+   return;
+
if (qtd->urb->status != -EPIPE && qtd->urb->status != -EREMOTEIO) {
chan->qh->tt_buffer_dirty = 1;
if (usb_hub_clear_tt_buffer(usb_urb))

Re: [PATCH v6 18/22] usb: dwc2: host: Schedule periodic right away if it's time

[Kever Yang]

Doug,

On 02/01/2016 06:09 AM, Doug Anderson wrote:

Kever,

On Sun, Jan 31, 2016 at 1:36 AM, Kever Yang <kever.y...@rock-chips.com> wrote:

Doug,


On 01/29/2016 10:20 AM, Douglas Anderson wrote:

In dwc2_hcd_qh_deactivate() we will put some things on the
periodic_sched_ready list.  These things won't be taken off the ready
list until the next SOF, which might be a little late.  Let's put them
on right away.

Signed-off-by: Douglas Anderson <diand...@chromium.org>
Tested-by: Heiko Stuebner <he...@sntech.de>
Tested-by: Stefan Wahren <stefan.wah...@i2se.com>
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Schedule periodic right away if it's time new for v4.

Changes in v3: None
Changes in v2: None

   drivers/usb/dwc2/hcd_queue.c | 18 --
   1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 9b3c435339ee..3abb34a5fc5b 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -1080,12 +1080,26 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh,
  * Note: we purposely use the frame_number from the "hsotg"
structure
  * since we know SOF interrupt will handle future frames.
  */
-   if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number))
{
+   enum dwc2_transaction_type tr_type;
+
+   /*
+* We're bypassing the SOF handler which is normally what
puts
+* us on the ready list because we're in a hurry and need
to
+* try to catch up.
+*/
+   dwc2_sch_vdbg(hsotg, "QH=%p IMM ready fn=%04x,
nxt=%04x\n",
+ qh, frame_number, qh->next_active_frame);
 list_move_tail(>qh_list_entry,
>periodic_sched_ready);
-   else
+
+   tr_type = dwc2_hcd_select_transactions(hsotg);

Do we need to add select_transactions call here? If we get into this
function in interrupt
and once we put the qh in ready queue, the qh can be handled in this frame
again by the
later function call of dwc_hcd_select_transactions, so what we need to to
here is put
it in ready list instead of inactive queue, and wait for the schedule.

I'm not sure I understand.  Can you restate?


I'll try to explain more in the meantime...

Both before and after my change, this function would place something
on the ready queue if the next_active_frame <= the frame number as of
last SOF interrupt (aka hsotg->frame_number).  Otherwise it goes on
the inactive queue.  Assuming that the previous change ("usb: dwc2:
host: Manage frame nums better in scheduler") worked properly then
next_active_frame shouldn't be less than (hsotg->frame_number - 1).
Remember that next_active_frame is always 1 before the wire frame, so
if "next_active_frame == hsotg->frame_number - 1" it means that we
need to get the transfer on the wire _right away_.  If
"next_active_frame == hsotg->frame_number" the transfer doesn't need
to go on the wire right away, but since dwc2 can be prepped one frame
in advance it doesn't hurt to give it to the hardware right away if
there's space.

As I understand it, if we stick something on the ready queue it won't
generally get looked at until the next SOF interrupt.  That means
we'll be too late if "next_active_frame == hsotg->frame_number - 1"
and we'll possibly be too late (depending on interrupt latency) if
"next_active_frame == hsotg->frame_number"


I understand this patch and agree with your point of schedule the
periodic right away instead of at least next frame.
My point is, there are only two call to dwc2_hcd_qh_deactivate(), from
dwc2_hcd_urb_dequeue() and dwc2_release_channel(), we don't need
to do the schedule for dequeue, and there is one
dwc2_hcd_select_transactions() call at the end of dwc2_release_channel(),
maybe we don't need another dwc2_hcd_select_transactions() here.

I think the duration from this point to the function call of 
dwc2_hcd_select_transactions()

in dwc2_release_channel() will be the main factor for us to decide if
we need to add a function call of  dwc2_hcd_select_transactions() here.

Thanks,
- Kever

Note that before my series, there were more places than just the SOF
interrupt that would update hsotg->frame_number (see "usb: dwc2: host:
Manage frame nums better in scheduler" for fix).  Also before my
series (specially "usb: dwc2: host: Manage frame nums better in
scheduler") we used the actual current frame number when doing
comparisons.  Also before my series (specifically "usb: dwc2: host:
Properly set even/odd frame") we didn't really place things in the
frame t

Re: [PATCH v6 10/22] usb: dwc2: host: Properly set the HFIR

[Kever Yang]

Doug,

On 01/29/2016 10:20 AM, Douglas Anderson wrote:

According to the most up to date version of the dwc2 databook, the FRINT
field of the HFIR register should be programmed to:
* 125 us * (PHY clock freq for HS) - 1
* 1000 us * (PHY clock freq for FS/LS) - 1

I got 3 version of dwc_otg databook, 2.74a, 2.94a and 3.10a,
all the doc describe the FrInt as:

* 125 us * (PHY clock freq for HS)
* 1000 us * (PHY clock freq for FS/LS)

Maybe John can help to check the design.

There are some feature different in new and old version, but not sure
if this is one of then.

The doc says If no value is programmed, the corecalculates the value
based on the PHY clock specified in the FS/LS PHY Clock select field of
Host configuration register(HCFG.FLSLPclkSel), does this work?

Thanks,
- Kever


This is opposed to older versions of the doc that claimed it should be:
* 125 us * (PHY clock freq for HS)
* 1000 us * (PHY clock freq for FS/LS)

In case you didn't spot it, the difference is the "- 1".

Let's add the "- 1" to match the newest user manual.  It's presumed that
the "- 1" should have always been there and that this was always a
documentation error.  If some hardware needs the "- 1" and other
hardware doesn't, we'll have to add a configuration parameter for it in
the future.

I checked things before and after this patch on rk3288 using a Total
Phase Beagle 5000 analyzer.

Before this patch, a low speed mouse shows constant Frame Timing Jitter
errors.  After this patch errors have gone away.

Before this patch SOF packets move forward about 1 us per 4 ms.  After
this patch the SOF packets move backward about 1 us per 255 ms.  Some
specific SOF timestamps from the analyzer are below.

Before:
   6.603.790
   6.603.916
   6.604.041
   6.604.166
   ...
   6.607.541
   6.607.667
   6.607.792
   6.607.917
   ...
   6.611.417
   6.611.543
   6.611.668
   6.611.793

After:
   6.215.159
   6.215.284
   6.215.408
   6.215.533
   6.215.658
   ...
   6.470.658
   6.470.783
   6.470.907
   ...
   6.726.032
   6.726.157
   6.725.281
   6.725.406

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
---
Changes in v6:
- Incorporated Properly set the HFIR patch to big series in v6
- Add Heiko's Tested-by.

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index ed73b26818c0..a5db20f12ee4 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -2245,10 +2245,10 @@ u32 dwc2_calc_frame_interval(struct dwc2_hsotg *hsotg)
  
  	if ((hprt0 & HPRT0_SPD_MASK) >> HPRT0_SPD_SHIFT == HPRT0_SPD_HIGH_SPEED)

/* High speed case */
-   return 125 * clock;
+   return 125 * clock - 1;
else
/* FS/LS case */
-   return 1000 * clock;
+   return 1000 * clock - 1;
  }
  
  /**

Re: [PATCH v6 11/22] usb: dwc2: host: There's not really a TT for the root hub

[Kever Yang]

Doug,

Reviewed-by: Kever Yang <kever.y...@rock-chips.com>

Thanks,
- Kever
On 01/29/2016 10:20 AM, Douglas Anderson wrote:

I find that when I plug a full speed (NOT high speed) hub into a dwc2
port and then I plug a bunch of devices into that full speed hub that
dwc2 goes bat guano crazy.  Specifically, it just spews errors like this
in the console:
   usb usb1: clear tt 1 (9043) error -22

The specific test case I used looks like this:
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
 |__ Port 1: Dev 17, If 0, Class=Hub, Driver=hub/4p, 12M
 |__ Port 2: Dev 19, If 0, ..., Driver=usbhid, 1.5M
 |__ Port 4: Dev 20, If 0, ..., Driver=usbhid, 12M
 |__ Port 4: Dev 20, If 1, ..., Driver=usbhid, 12M
 |__ Port 4: Dev 20, If 2, ..., Driver=usbhid, 12M

Showing VID/PID:
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Bus 001 Device 017: ID 03eb:3301 Atmel Corp. at43301 4-Port Hub
  Bus 001 Device 020: ID 045e:0745 Microsoft Corp. Nano Transceiver ...
  Bus 001 Device 019: ID 046d:c404 Logitech, Inc. TrackMan Wheel

I spent a bunch of time trying to figure out why there are errors to
begin with.  I believe that the issue may be a hardware issue where the
transceiver sometimes accidentally sends a PREAMBLE packet if you send a
packet to a full speed device right after one to a low speed device.
Luckily the USB driver retries and the second time things work OK.

In any case, things kinda seem work despite the errors, except for the
"clear tt" spew mucking up my console.  Chalk it up for a win for
retries and robust protocols.

So getting back to the "clear tt" problem, it appears that we get those
because there's not actually a TT here to clear.  It's my understanding
that when dwc2 operates in low speed or full speed mode that there's no
real TT out there.  That makes all these attempts to "clear the TT"
somewhat meaningless and also causes the spew in the log.

Let's just skip all the useless TT clears.  Eventually we should root
cause the errors, but even if we do this is still a proper fix and is
likely to avoid the "clear tt" error in the future.

Note that hooking up a Full Speed USB Audio Device (Jabra 510) to this
same hub with the keyboard / trackball shows that even audio works over
this janky connection.  As a point to note, this particular change (skip
bogus TT clears) compared to just commenting out the dev_err() in
hub_tt_work() actually produces better audio.

Note: don't ask me where I got a full speed USB hub or whether the
massive amount of dust that accumulated on it while it was in my junk
box affected its funtionality.  Just smile and nod.

Signed-off-by: Douglas Anderson <diand...@chromium.org>
---
Changes in v6:
- There's not really a TT for the root hub new for v6

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/hcd_intr.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 5d25a5ec9736..fe44870f84eb 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -87,6 +87,7 @@ static void dwc2_hc_handle_tt_clear(struct dwc2_hsotg *hsotg,
struct dwc2_host_chan *chan,
struct dwc2_qtd *qtd)
  {
+   struct usb_device *root_hub = dwc2_hsotg_to_hcd(hsotg)->self.root_hub;
struct urb *usb_urb;
  
  	if (!chan->qh)

@@ -102,6 +103,15 @@ static void dwc2_hc_handle_tt_clear(struct dwc2_hsotg 
*hsotg,
if (!usb_urb || !usb_urb->dev || !usb_urb->dev->tt)
return;
  
+	/*

+* The root hub doesn't really have a TT, but Linux thinks it
+* does because how could you have a "high speed hub" that
+* directly talks directly to low speed devices without a TT?
+* It's all lies.  Lies, I tell you.
+*/
+   if (usb_urb->dev->tt->hub == root_hub)
+   return;
+
if (qtd->urb->status != -EPIPE && qtd->urb->status != -EREMOTEIO) {
chan->qh->tt_buffer_dirty = 1;
if (usb_hub_clear_tt_buffer(usb_urb))

Re: [PATCH v6 18/22] usb: dwc2: host: Schedule periodic right away if it's time

[Kever Yang]

Doug,

On 01/29/2016 10:20 AM, Douglas Anderson wrote:

In dwc2_hcd_qh_deactivate() we will put some things on the
periodic_sched_ready list.  These things won't be taken off the ready
list until the next SOF, which might be a little late.  Let's put them
on right away.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Schedule periodic right away if it's time new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/hcd_queue.c | 18 --
  1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 9b3c435339ee..3abb34a5fc5b 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -1080,12 +1080,26 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg *hsotg, 
struct dwc2_qh *qh,
 * Note: we purposely use the frame_number from the "hsotg" structure
 * since we know SOF interrupt will handle future frames.
 */
-   if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number)) {
+   enum dwc2_transaction_type tr_type;
+
+   /*
+* We're bypassing the SOF handler which is normally what puts
+* us on the ready list because we're in a hurry and need to
+* try to catch up.
+*/
+   dwc2_sch_vdbg(hsotg, "QH=%p IMM ready fn=%04x, nxt=%04x\n",
+ qh, frame_number, qh->next_active_frame);
list_move_tail(>qh_list_entry,
   >periodic_sched_ready);
-   else
+
+   tr_type = dwc2_hcd_select_transactions(hsotg);
Do we need to add select_transactions call here? If we get into this 
function in interrupt
and once we put the qh in ready queue, the qh can be handled in this 
frame again by the
later function call of dwc_hcd_select_transactions, so what we need to 
to here is put

it in ready list instead of inactive queue, and wait for the schedule.

Thanks,
- Kever


+   if (tr_type != DWC2_TRANSACTION_NONE)
+   dwc2_hcd_queue_transactions(hsotg, tr_type);
+   } else {
list_move_tail(>qh_list_entry,
   >periodic_sched_inactive);
+   }
  }
  
  /**

Re: [PATCH v5 03/21] usb: dwc2: host: Set host_rx_fifo_size to 528 for rk3066

[Kever Yang]

Hi Doug,

On 01/28/2016 03:44 AM, Doug Anderson wrote:

If it's all the same to you, I'll probably change it back to 525 and
then increase the periodic FIFO size by 3 DWORDS in the next patch.
12 bytes may not be much, but might as well make use of them to
improve performance / compatibility?

Presumably you're also OK with the next patch in the series: ("usb:
dwc2: host: Set host_perio_tx_fifo_size to 304 for rk3066")?

I'm OK for change in this patch, but I think we don't need next patch,
pls see the reply in another mail.

Thank,
- Kever

Re: [PATCH v5 03/21] usb: dwc2: host: Set host_rx_fifo_size to 528 for rk3066

[Kever Yang]

Hi Doug,

On 01/28/2016 03:44 AM, Doug Anderson wrote:

If it's all the same to you, I'll probably change it back to 525 and
then increase the periodic FIFO size by 3 DWORDS in the next patch.
12 bytes may not be much, but might as well make use of them to
improve performance / compatibility?

Presumably you're also OK with the next patch in the series: ("usb:
dwc2: host: Set host_perio_tx_fifo_size to 304 for rk3066")?

I'm OK for change in this patch, but I think we don't need next patch,
pls see the reply in another mail.

Thank,
- Kever

Re: [PATCH v5 04/21] usb: dwc2: host: Set host_perio_tx_fifo_size to 304 for rk3066

[Kever Yang]

Hi Doug,

We are in HOST mode, we only need to receive data from USB camera
with RX FIFO, and no need to use TX FIFO for USB webcam, right? :)

Any way, I think we need to NAK this patch after look into the design
of dwc2 controller. Because all the dwc2 controller inside the Rockchip
chips don't support the thresholding FIFO mode, in this case, there is
no more transaction before a whole packet is send out and the dwc2 only
care if the available FIFO is enough for next packet or not.

So, the addition 48 words won't help to shorten the latency for data prepare
in this case.

Thanks,
- Kever
On 01/28/2016 11:28 AM, Doug Anderson wrote:

Kever,

On Wed, Jan 27, 2016 at 7:10 PM, Kever Yang  wrote:

Hi Doug,

We are using the minimum FIFO size mode for TX now, which only
equal to one max packet size.

The addition FIFO size may help shorten the inter-packet data
prepare latency when the bus/DRAM is busy.

For the actual usage in TX, we have very little change to use the
period TX FIFO with more than one max packet size in host mode.
So far as I know, usb audio use the isochronous tx FIFO, but this
king of device won't have much data payload and won't, I haven't
see a usb audio have more data than 1024byte/ms.

So I suggest we assign this 48 words to host_nperio_tx_fifi_size instead
if we have to do this. Because we are using device base on bulk transaction
like U-disk very frequently.

Try using a USB webcam.  With that plus a USB audio device it's easy
to overwhelm the periodic TX FIFO.

If we overwhelm the periodic TX FIFO we might actually fail to
transmit ISO or INT packets at the scheduled time.  That seems more
serious of a problem to try to fix than eeking out a tiny bit
performance on a USB disk.  ...but of course, it all depends on what
you consider important.  ;)

We could split the difference, I suppose and put half on each?

-Doug

Re: [PATCH v5 08/21] usb: dwc2: host: Add scheduler tracing

[Kever Yang]

Hi Doug,

Very good idea here, I used to add some local patch and with USB
analyzer to debug this part of code, and we can use more tools with
your patch now, I can try kernelshark next time.

Do you consider to add tracing for qtd? Then we can track the whole
lift cycle of urb in dwc2 driver.

For this patch:
Reviewed-by: Kever Yang 

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

In preparation for future changes to the scheduler let's add some
tracing that makes it easy for us to see what's happening.  By default
this tracing will be off.

By changing "core.h" you can easily trace to ftrace, the console, or
nowhere.

Signed-off-by: Douglas Anderson 
---
Changes in v5: None
Changes in v4:
- Retooled scheduler tracing a bit, so left off John's Ack from v3.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.h  | 20 
  drivers/usb/dwc2/hcd.h   |  5 +
  drivers/usb/dwc2/hcd_intr.c  |  6 +-
  drivers/usb/dwc2/hcd_queue.c | 24 +++-
  4 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 538cf38af0e4..18f9e4045643 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -44,6 +44,26 @@
  #include 
  #include "hw.h"
  
+/*

+ * Suggested defines for tracers:
+ * - no_printk:Disable tracing
+ * - pr_info:  Print this info to the console
+ * - trace_printk: Print this info to trace buffer (good for verbose logging)
+ */
+
+#define DWC2_TRACE_SCHEDULER   no_printk
+#define DWC2_TRACE_SCHEDULER_VBno_printk
+
+/* Detailed scheduler tracing, but won't overwhelm console */
+#define dwc2_sch_dbg(hsotg, fmt, ...)  \
+   DWC2_TRACE_SCHEDULER(pr_fmt("%s: SCH: " fmt), \
+dev_name(hsotg->dev), ##__VA_ARGS__)
+
+/* Verbose scheduler tracing */
+#define dwc2_sch_vdbg(hsotg, fmt, ...) \
+   DWC2_TRACE_SCHEDULER_VB(pr_fmt("%s: SCH: " fmt),  \
+   dev_name(hsotg->dev), ##__VA_ARGS__)
+
  static inline u32 dwc2_readl(const void __iomem *addr)
  {
u32 value = __raw_readl(addr);
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index 1b46e2e617cc..809bc4ff9116 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -563,6 +563,11 @@ static inline u16 dwc2_frame_num_inc(u16 frame, u16 inc)
return (frame + inc) & HFNUM_MAX_FRNUM;
  }
  
+static inline u16 dwc2_frame_num_dec(u16 frame, u16 dec)

+{
+   return (frame + HFNUM_MAX_FRNUM + 1 - dec) & HFNUM_MAX_FRNUM;
+}
+
  static inline u16 dwc2_full_frame_num(u16 frame)
  {
return (frame & HFNUM_MAX_FRNUM) >> 3;
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 577c91096a51..5d25a5ec9736 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -138,13 +138,17 @@ static void dwc2_sof_intr(struct dwc2_hsotg *hsotg)
while (qh_entry != >periodic_sched_inactive) {
qh = list_entry(qh_entry, struct dwc2_qh, qh_list_entry);
qh_entry = qh_entry->next;
-   if (dwc2_frame_num_le(qh->sched_frame, hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->sched_frame, hsotg->frame_number)) {
+   dwc2_sch_vdbg(hsotg, "QH=%p ready fn=%04x, sch=%04x\n",
+ qh, hsotg->frame_number, qh->sched_frame);
+
/*
 * Move QH to the ready list to be executed next
 * (micro)frame
 */
list_move_tail(>qh_list_entry,
  >periodic_sched_ready);
+   }
}
tr_type = dwc2_hcd_select_transactions(hsotg);
if (tr_type != DWC2_TRANSACTION_NONE)
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index bc632a72f611..0e9faa75593c 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -113,6 +113,9 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg, struct 
dwc2_qh *qh,
qh->sched_frame = dwc2_frame_num_inc(hsotg->frame_number,
 SCHEDULE_SLOP);
qh->interval = urb->interval;
+   dwc2_sch_dbg(hsotg, "QH=%p init sch=%04x, fn=%04x, int=%#x\n",
+qh, qh->sched_frame, hsotg->frame_number,
+qh->interval);
  #if 0
/* Increase interrupt polling rate for debugging */
if (qh->ep_type == USB_ENDPOINT_XFER_INT)
@@ -126,6 +129,11 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg, struct 
dwc2_qh *qh,

Re: [PATCH v5 05/21] usb: dwc2: host: Avoid use of chan->qh after qh freed

[Kever Yang]

Hi Doug,

The NULL pointer bug is one of the most frequent issue we met
during hot plug stress test, thanks for this bug fix.

Reviewed-by: Kever Yang 

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

When poking around with USB devices with slub_debug enabled, I found
another obvious use after free.  Turns out that in dwc2_hc_n_intr() I
was in a state when the contents of chan->qh was filled with 0x6b,
indicating that chan->qh was freed but chan still had a reference to
it.

Let's make sure that whenever we free qh we also make sure we remove a
reference from its channel.

The bug fixed here doesn't appear to be new--I believe I just got lucky
and happened to see it while stress testing.

Signed-off-by: Douglas Anderson 
---
Changes in v5: None
Changes in v4:
- Avoid use of chan->qh after qh freed new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/hcd.c  |  8 
  drivers/usb/dwc2/hcd_intr.c | 10 ++
  2 files changed, 18 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index bc4bdbc1534e..7783c8ba0173 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -164,6 +164,9 @@ static void dwc2_qh_list_free(struct dwc2_hsotg *hsotg,
 qtd_list_entry)
dwc2_hcd_qtd_unlink_and_free(hsotg, qtd, qh);
  
+		if (qh->channel && qh->channel->qh == qh)

+   qh->channel->qh = NULL;
+
spin_unlock_irqrestore(>lock, flags);
dwc2_hcd_qh_free(hsotg, qh);
spin_lock_irqsave(>lock, flags);
@@ -554,7 +557,12 @@ static int dwc2_hcd_endpoint_disable(struct dwc2_hsotg 
*hsotg,
dwc2_hcd_qtd_unlink_and_free(hsotg, qtd, qh);
  
  	ep->hcpriv = NULL;

+
+   if (qh->channel && qh->channel->qh == qh)
+   qh->channel->qh = NULL;
+
spin_unlock_irqrestore(>lock, flags);
+
dwc2_hcd_qh_free(hsotg, qh);
  
  	return 0;

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 352c98364317..99efc2bd1617 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -1935,6 +1935,16 @@ static void dwc2_hc_n_intr(struct dwc2_hsotg *hsotg, int 
chnum)
}
  
  	dwc2_writel(hcint, hsotg->regs + HCINT(chnum));

+
+   /*
+* If we got an interrupt after someone called
+* dwc2_hcd_endpoint_disable() we don't want to crash below
+*/
+   if (!chan->qh) {
+   dev_warn(hsotg->dev, "Interrupt on disabled channel\n");
+   return;
+   }
+
chan->hcint = hcint;
hcint &= hcintmsk;
  

Re: [PATCH v5 04/21] usb: dwc2: host: Set host_perio_tx_fifo_size to 304 for rk3066

[Kever Yang]

Hi Doug,

We are using the minimum FIFO size mode for TX now, which only
equal to one max packet size.

The addition FIFO size may help shorten the inter-packet data
prepare latency when the bus/DRAM is busy.

For the actual usage in TX, we have very little change to use the
period TX FIFO with more than one max packet size in host mode.
So far as I know, usb audio use the isochronous tx FIFO, but this
king of device won't have much data payload and won't, I haven't
see a usb audio have more data than 1024byte/ms.

So I suggest we assign this 48 words to host_nperio_tx_fifi_size instead
if we have to do this. Because we are using device base on bulk transaction
like U-disk very frequently.

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

Looking at rk3288, there are two dwc2 ports.  One has 960
total_fifo_size and the other 972.

We're currently assigning 528 + 128 + 256 = 912.  That means we're
wasting 48 words on one port and 60 words on the other.  Since we have
one settings block for both ports, let's just eat the 48 words that we
know we have and assign them to what's probably the most
latency-senstive part of the system: periodic transfers.

Presumably other rk3288 parts using the rk3066 settings also have these
extra 48 words as well.

Note: ideally we'd adjust dwc2_calculate_dynamic_fifo() to handle this
more dynamically, but until that's done hardcoding things here seems OK.

NOTE: no known use cases are improved by this patch, but in my stressful
USB tests I certainly see my periodic FIFO filling up both before and
after this change.  Presumably there are some USB configurations where
the periodic FIFO would have been filled before where it no longer is.

Signed-off-by: Douglas Anderson 
---
Changes in v5: None
Changes in v4:
- Set host_perio_tx_fifo_size to 304 for rk3066 new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/platform.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index b6d7666e715c..afdcdeee266d 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -128,7 +128,7 @@ static const struct dwc2_core_params params_rk3066 = {
.en_multiple_tx_fifo= -1,
.host_rx_fifo_size  = 528,  /* 528 DWORDs */
.host_nperio_tx_fifo_size   = 128,  /* 128 DWORDs */
-   .host_perio_tx_fifo_size= 256,  /* 256 DWORDs */
+   .host_perio_tx_fifo_size= 304,  /* 304 DWORDs */
.max_transfer_size  = -1,
.max_packet_count   = -1,
.host_channels  = -1,

Re: [PATCH v5 07/21] usb: dwc2: hcd: fix split transfer schedule sequence

[Kever Yang]

Hi Doug,

I test this patch with USB 2.0 analyzer, and it make the CSPLIT in the
same order with the SSPLIT, so

Reviewed-by: Kever Yang 
Tested-by: Kever Yang 

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

We're supposed to keep outstanding splits in order.  Keep track of a
list of the order of splits and process channel interrupts in that
order.

Without this change and the following setup:
* Rockchip rk3288 Chromebook, using port ff54
   -> Pluggable 7-port Hub with Charging (powered)
  -> Microsoft Wireless Keyboard 2000 in port 1.
  -> Das Keyboard in port 2.

...I find that I get dropped keys on the Microsoft keyboard (I'm sure
there are other combinations that fail, but this documents my test).
Specifically I've been typing "hahahahahahaha" on the keyboard and often
see keys dropped or repeated.

After this change the above setup works properly.  This patch is based
on a previous patch proposed by Yunzhi Li ("usb: dwc2: hcd: fix periodic
transfer schedule sequence")

Signed-off-by: Douglas Anderson 
Signed-off-by: Yunzhi Li 
---
Changes in v5:
- Move list maintenance to hcd.c to avoid gadget-only compile error

Changes in v4:
- fix split transfer schedule sequence new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.c |  2 ++
  drivers/usb/dwc2/core.h |  2 ++
  drivers/usb/dwc2/hcd.c  |  8 
  drivers/usb/dwc2/hcd.h  |  2 ++
  drivers/usb/dwc2/hcd_intr.c | 17 +
  5 files changed, 31 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 73f2771b7740..ed73b26818c0 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -1676,6 +1676,8 @@ void dwc2_hc_cleanup(struct dwc2_hsotg *hsotg, struct 
dwc2_host_chan *chan)
  
  	chan->xfer_started = 0;
  
+	list_del_init(>split_order_list_entry);

+
/*
 * Clear channel interrupt enables and any unhandled channel interrupt
 * conditions
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 7fb6434f4639..538cf38af0e4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -657,6 +657,7 @@ struct dwc2_hregs_backup {
   *  periodic_sched_ready because it must be rescheduled 
for
   *  the next frame. Otherwise, the item moves to
   *  periodic_sched_inactive.
+ * @split_order:List keeping track of channels doing splits, in order.
   * @periodic_usecs: Total bandwidth claimed so far for periodic transfers.
   *  This value is in microseconds per (micro)frame. The
   *  assumption is that all periodic transfers may occur in
@@ -780,6 +781,7 @@ struct dwc2_hsotg {
struct list_head periodic_sched_ready;
struct list_head periodic_sched_assigned;
struct list_head periodic_sched_queued;
+   struct list_head split_order;
u16 periodic_usecs;
u16 frame_usecs[8];
u16 frame_number;
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index d2daaea88d91..87ad5bf2d166 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1045,6 +1045,11 @@ static int dwc2_queue_transaction(struct dwc2_hsotg 
*hsotg,
  {
int retval = 0;
  
+	if (chan->do_split)

+   /* Put ourselves on the list to keep order straight */
+   list_move_tail(>split_order_list_entry,
+  >split_order);
+
if (hsotg->core_params->dma_enable > 0) {
if (hsotg->core_params->dma_desc_enable > 0) {
if (!chan->xfer_started ||
@@ -3151,6 +3156,8 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
INIT_LIST_HEAD(>periodic_sched_assigned);
INIT_LIST_HEAD(>periodic_sched_queued);
  
+	INIT_LIST_HEAD(>split_order);

+
/*
 * Create a host channel descriptor for each host channel implemented
 * in the controller. Initialize the channel descriptor array.
@@ -3164,6 +3171,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
if (channel == NULL)
goto error3;
channel->hc_num = i;
+   INIT_LIST_HEAD(>split_order_list_entry);
hsotg->hc_ptr_array[i] = channel;
}
  
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h

index 42f2e4e233da..1b46e2e617cc 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -106,6 +106,7 @@ struct dwc2_qh;
   * @hc_list_entry:  For linking to list of host channels
   * @desc_list_addr: Current QH's descriptor list DMA address
   * @desc_list_sz:   Current QH's descriptor list size
+ * @split_order_list_entry: List entry for keeping track of the order of splits
   *
   * This structure represents the state of a single host channel when acting in
   * host mode. It 

Re: [PATCH v5 06/21] usb: dwc2: host: Always add to the tail of queues

[Kever Yang]

Hi Doug,

This is obviously a bug in dwc2 driver which not meet the usb 2.0
spec, and this patch can fix it.

Reviewed-by: Kever Yang 

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

The queues the the dwc2 host controller used are truly queues.  That
means FIFO or first in first out.

Unfortunately though the code was iterating through these queues
starting from the head, some places in the code was adding things to the
queue by adding at the head instead of the tail.  That means last in
first out.  Doh.

Go through and just always add to the tail.

Doing this makes things much happier when I've got:
* 7-port USB 2.0 Single-TT hub
* - Microsoft 2.4 GHz Transceiver v7.0 dongle
* - Jabra speakerphone playing music

Signed-off-by: Douglas Anderson 
---
Changes in v5: None
Changes in v4:
- Always add to the tail of queues new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/hcd.c   | 11 ++-
  drivers/usb/dwc2/hcd_ddma.c  |  4 ++--
  drivers/usb/dwc2/hcd_intr.c  |  4 ++--
  drivers/usb/dwc2/hcd_queue.c |  6 --
  4 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 7783c8ba0173..d2daaea88d91 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -969,7 +969,8 @@ enum dwc2_transaction_type dwc2_hcd_select_transactions(
 * periodic assigned schedule
 */
qh_ptr = qh_ptr->next;
-   list_move(>qh_list_entry, >periodic_sched_assigned);
+   list_move_tail(>qh_list_entry,
+  >periodic_sched_assigned);
ret_val = DWC2_TRANSACTION_PERIODIC;
}
  
@@ -1002,8 +1003,8 @@ enum dwc2_transaction_type dwc2_hcd_select_transactions(

 * non-periodic active schedule
 */
qh_ptr = qh_ptr->next;
-   list_move(>qh_list_entry,
- >non_periodic_sched_active);
+   list_move_tail(>qh_list_entry,
+  >non_periodic_sched_active);
  
  		if (ret_val == DWC2_TRANSACTION_NONE)

ret_val = DWC2_TRANSACTION_NON_PERIODIC;
@@ -1176,8 +1177,8 @@ static void dwc2_process_periodic_channels(struct 
dwc2_hsotg *hsotg)
 * Move the QH from the periodic assigned schedule to
 * the periodic queued schedule
 */
-   list_move(>qh_list_entry,
- >periodic_sched_queued);
+   list_move_tail(>qh_list_entry,
+  >periodic_sched_queued);
  
  			/* done queuing high bandwidth */

hsotg->queuing_high_bandwidth = 0;
diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
index 36606fc33c0d..16b261cfa92d 100644
--- a/drivers/usb/dwc2/hcd_ddma.c
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -1327,8 +1327,8 @@ void dwc2_hcd_complete_xfer_ddma(struct dwc2_hsotg *hsotg,
dwc2_hcd_qh_unlink(hsotg, qh);
} else {
/* Keep in assigned schedule to continue transfer */
-   list_move(>qh_list_entry,
- >periodic_sched_assigned);
+   list_move_tail(>qh_list_entry,
+  >periodic_sched_assigned);
/*
 * If channel has been halted during giveback of urb
 * then prevent any new scheduling.
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 99efc2bd1617..2c521c00e5e0 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -143,7 +143,7 @@ static void dwc2_sof_intr(struct dwc2_hsotg *hsotg)
 * Move QH to the ready list to be executed next
 * (micro)frame
 */
-   list_move(>qh_list_entry,
+   list_move_tail(>qh_list_entry,
  >periodic_sched_ready);
}
tr_type = dwc2_hcd_select_transactions(hsotg);
@@ -794,7 +794,7 @@ static void dwc2_halt_channel(struct dwc2_hsotg *hsotg,
 * halt to be queued when the periodic schedule is
 * processed.
 */
-   list_move(>qh->qh_list_entry,
+   list_move_tail(>qh->qh_list_entry,
  >periodic_sched_assigned);
  
  			/*

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index e0933a9dfad7..bc632a72f611 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -732,9 +732,11 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg *hsotg, 
struct dwc2_qh *qh,
   

Re: [PATCH v5 03/21] usb: dwc2: host: Set host_rx_fifo_size to 528 for rk3066

[Kever Yang]

Hi Doug,

On 01/23/2016 02:18 AM, Douglas Anderson wrote:

As documented in dwc2_calculate_dynamic_fifo(), host_rx_fifo_size should
really be:
  2 * ((Largest Packet size / 4) + 1 + 1) + n
  with n = number of host channel.

We have 9 host channels, so
  2 * ((1024/4) + 2) + 9 = 516 + 9 = 525

We've got 960 / 972 total_fifo_size on rk3288 (and presumably on
rk3066) and 525 + 128 + 256 = 909 so we're still under on both ports
even when we increment by 5.

Since we have space, Kever Yang suggests bumping by 8.  He says this
will meet INCR16 access and next fifo type can start with a aligned
address.

I have double check this feature, the INCR16 is actually a burst 16
on to the bus, the aligned problem only happen on the DRAM
access, and it's OK for internal RAM access via internal DMA.

Bump to 8 looks much better when we check the FIFO setting if we
have enough memory, right? :)

rk3066/rk3188/rk3288 have the same hw config for dwc2 controller,
so this patch should works on those files.

Reviewed-by: Kever Yang 


...so let's bump up by 8.  In the future, it would be nice if
dwc2_calculate_dynamic_fifo() could handle the "too small" FIFO case and
come up with something more dynamically.  When we do that we can figure
out how to allocate the extra 48 / 60 bytes of FIFO that we're currently
wasting.

NOTE: no known bugs are fixed by this patch, but it seems like a simple
fix and ought to fix someone.

Signed-off-by: Douglas Anderson 
---
Changes in v5: None
Changes in v4:
- Set host_rx_fifo_size to 528 for rk3066 new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/platform.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5008a467ce06..b6d7666e715c 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -126,7 +126,7 @@ static const struct dwc2_core_params params_rk3066 = {
.speed  = -1,
.enable_dynamic_fifo= 1,
.en_multiple_tx_fifo= -1,
-   .host_rx_fifo_size  = 520,  /* 520 DWORDs */
+   .host_rx_fifo_size  = 528,  /* 528 DWORDs */
.host_nperio_tx_fifo_size   = 128,  /* 128 DWORDs */
.host_perio_tx_fifo_size= 256,  /* 256 DWORDs */
.max_transfer_size  = -1,

Re: [PATCH v5 07/21] usb: dwc2: hcd: fix split transfer schedule sequence

[Kever Yang]

Hi Doug,

I test this patch with USB 2.0 analyzer, and it make the CSPLIT in the
same order with the SSPLIT, so

Reviewed-by: Kever Yang <kever.y...@rock-chips.com>
Tested-by: Kever Yang <kever.y...@rock-chips.com>

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

We're supposed to keep outstanding splits in order.  Keep track of a
list of the order of splits and process channel interrupts in that
order.

Without this change and the following setup:
* Rockchip rk3288 Chromebook, using port ff54
   -> Pluggable 7-port Hub with Charging (powered)
  -> Microsoft Wireless Keyboard 2000 in port 1.
  -> Das Keyboard in port 2.

...I find that I get dropped keys on the Microsoft keyboard (I'm sure
there are other combinations that fail, but this documents my test).
Specifically I've been typing "hahahahahahaha" on the keyboard and often
see keys dropped or repeated.

After this change the above setup works properly.  This patch is based
on a previous patch proposed by Yunzhi Li ("usb: dwc2: hcd: fix periodic
transfer schedule sequence")

Signed-off-by: Douglas Anderson <diand...@chromium.org>
Signed-off-by: Yunzhi Li <l...@rock-chips.com>
---
Changes in v5:
- Move list maintenance to hcd.c to avoid gadget-only compile error

Changes in v4:
- fix split transfer schedule sequence new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.c |  2 ++
  drivers/usb/dwc2/core.h |  2 ++
  drivers/usb/dwc2/hcd.c  |  8 
  drivers/usb/dwc2/hcd.h  |  2 ++
  drivers/usb/dwc2/hcd_intr.c | 17 +
  5 files changed, 31 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 73f2771b7740..ed73b26818c0 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -1676,6 +1676,8 @@ void dwc2_hc_cleanup(struct dwc2_hsotg *hsotg, struct 
dwc2_host_chan *chan)
  
  	chan->xfer_started = 0;
  
+	list_del_init(>split_order_list_entry);

+
/*
 * Clear channel interrupt enables and any unhandled channel interrupt
 * conditions
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 7fb6434f4639..538cf38af0e4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -657,6 +657,7 @@ struct dwc2_hregs_backup {
   *  periodic_sched_ready because it must be rescheduled 
for
   *  the next frame. Otherwise, the item moves to
   *  periodic_sched_inactive.
+ * @split_order:List keeping track of channels doing splits, in order.
   * @periodic_usecs: Total bandwidth claimed so far for periodic transfers.
   *  This value is in microseconds per (micro)frame. The
   *  assumption is that all periodic transfers may occur in
@@ -780,6 +781,7 @@ struct dwc2_hsotg {
struct list_head periodic_sched_ready;
struct list_head periodic_sched_assigned;
struct list_head periodic_sched_queued;
+   struct list_head split_order;
u16 periodic_usecs;
u16 frame_usecs[8];
u16 frame_number;
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index d2daaea88d91..87ad5bf2d166 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1045,6 +1045,11 @@ static int dwc2_queue_transaction(struct dwc2_hsotg 
*hsotg,
  {
int retval = 0;
  
+	if (chan->do_split)

+   /* Put ourselves on the list to keep order straight */
+   list_move_tail(>split_order_list_entry,
+  >split_order);
+
if (hsotg->core_params->dma_enable > 0) {
if (hsotg->core_params->dma_desc_enable > 0) {
if (!chan->xfer_started ||
@@ -3151,6 +3156,8 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
INIT_LIST_HEAD(>periodic_sched_assigned);
INIT_LIST_HEAD(>periodic_sched_queued);
  
+	INIT_LIST_HEAD(>split_order);

+
/*
 * Create a host channel descriptor for each host channel implemented
 * in the controller. Initialize the channel descriptor array.
@@ -3164,6 +3171,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
if (channel == NULL)
goto error3;
channel->hc_num = i;
+   INIT_LIST_HEAD(>split_order_list_entry);
hsotg->hc_ptr_array[i] = channel;
}
  
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h

index 42f2e4e233da..1b46e2e617cc 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -106,6 +106,7 @@ struct dwc2_qh;
   * @hc_list_entry:  For linking to list of host channels
   * @desc_list_addr: Current QH's descriptor list DMA address
   * @desc_list_sz:   Current QH's descriptor list size
+ * @split_order_list_entry: List entry for keeping track of the order of 

Re: [PATCH v5 08/21] usb: dwc2: host: Add scheduler tracing

[Kever Yang]

Hi Doug,

Very good idea here, I used to add some local patch and with USB
analyzer to debug this part of code, and we can use more tools with
your patch now, I can try kernelshark next time.

Do you consider to add tracing for qtd? Then we can track the whole
lift cycle of urb in dwc2 driver.

For this patch:
Reviewed-by: Kever Yang <kever.y...@rock-chips.com>

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

In preparation for future changes to the scheduler let's add some
tracing that makes it easy for us to see what's happening.  By default
this tracing will be off.

By changing "core.h" you can easily trace to ftrace, the console, or
nowhere.

Signed-off-by: Douglas Anderson <diand...@chromium.org>
---
Changes in v5: None
Changes in v4:
- Retooled scheduler tracing a bit, so left off John's Ack from v3.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.h  | 20 
  drivers/usb/dwc2/hcd.h   |  5 +
  drivers/usb/dwc2/hcd_intr.c  |  6 +-
  drivers/usb/dwc2/hcd_queue.c | 24 +++-
  4 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 538cf38af0e4..18f9e4045643 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -44,6 +44,26 @@
  #include 
  #include "hw.h"
  
+/*

+ * Suggested defines for tracers:
+ * - no_printk:Disable tracing
+ * - pr_info:  Print this info to the console
+ * - trace_printk: Print this info to trace buffer (good for verbose logging)
+ */
+
+#define DWC2_TRACE_SCHEDULER   no_printk
+#define DWC2_TRACE_SCHEDULER_VBno_printk
+
+/* Detailed scheduler tracing, but won't overwhelm console */
+#define dwc2_sch_dbg(hsotg, fmt, ...)  \
+   DWC2_TRACE_SCHEDULER(pr_fmt("%s: SCH: " fmt), \
+dev_name(hsotg->dev), ##__VA_ARGS__)
+
+/* Verbose scheduler tracing */
+#define dwc2_sch_vdbg(hsotg, fmt, ...) \
+   DWC2_TRACE_SCHEDULER_VB(pr_fmt("%s: SCH: " fmt),  \
+   dev_name(hsotg->dev), ##__VA_ARGS__)
+
  static inline u32 dwc2_readl(const void __iomem *addr)
  {
u32 value = __raw_readl(addr);
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index 1b46e2e617cc..809bc4ff9116 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -563,6 +563,11 @@ static inline u16 dwc2_frame_num_inc(u16 frame, u16 inc)
return (frame + inc) & HFNUM_MAX_FRNUM;
  }
  
+static inline u16 dwc2_frame_num_dec(u16 frame, u16 dec)

+{
+   return (frame + HFNUM_MAX_FRNUM + 1 - dec) & HFNUM_MAX_FRNUM;
+}
+
  static inline u16 dwc2_full_frame_num(u16 frame)
  {
return (frame & HFNUM_MAX_FRNUM) >> 3;
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 577c91096a51..5d25a5ec9736 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -138,13 +138,17 @@ static void dwc2_sof_intr(struct dwc2_hsotg *hsotg)
while (qh_entry != >periodic_sched_inactive) {
qh = list_entry(qh_entry, struct dwc2_qh, qh_list_entry);
qh_entry = qh_entry->next;
-   if (dwc2_frame_num_le(qh->sched_frame, hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->sched_frame, hsotg->frame_number)) {
+   dwc2_sch_vdbg(hsotg, "QH=%p ready fn=%04x, sch=%04x\n",
+ qh, hsotg->frame_number, qh->sched_frame);
+
/*
 * Move QH to the ready list to be executed next
 * (micro)frame
 */
list_move_tail(>qh_list_entry,
  >periodic_sched_ready);
+   }
}
tr_type = dwc2_hcd_select_transactions(hsotg);
if (tr_type != DWC2_TRANSACTION_NONE)
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index bc632a72f611..0e9faa75593c 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -113,6 +113,9 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg, struct 
dwc2_qh *qh,
qh->sched_frame = dwc2_frame_num_inc(hsotg->frame_number,
 SCHEDULE_SLOP);
qh->interval = urb->interval;
+   dwc2_sch_dbg(hsotg, "QH=%p init sch=%04x, fn=%04x, int=%#x\n",
+qh, qh->sched_frame, hsotg->frame_number,
+qh->interval);
  #if 0
/* Increase interrupt polling rate for debugging */
if (qh->ep_type == USB_ENDPOINT_XFER_INT)
@@ -126,6 +129,11 @@ static void

Re: [PATCH v5 04/21] usb: dwc2: host: Set host_perio_tx_fifo_size to 304 for rk3066

[Kever Yang]

Hi Doug,

We are in HOST mode, we only need to receive data from USB camera
with RX FIFO, and no need to use TX FIFO for USB webcam, right? :)

Any way, I think we need to NAK this patch after look into the design
of dwc2 controller. Because all the dwc2 controller inside the Rockchip
chips don't support the thresholding FIFO mode, in this case, there is
no more transaction before a whole packet is send out and the dwc2 only
care if the available FIFO is enough for next packet or not.

So, the addition 48 words won't help to shorten the latency for data prepare
in this case.

Thanks,
- Kever
On 01/28/2016 11:28 AM, Doug Anderson wrote:

Kever,

On Wed, Jan 27, 2016 at 7:10 PM, Kever Yang <kever.y...@rock-chips.com> wrote:

Hi Doug,

We are using the minimum FIFO size mode for TX now, which only
equal to one max packet size.

The addition FIFO size may help shorten the inter-packet data
prepare latency when the bus/DRAM is busy.

For the actual usage in TX, we have very little change to use the
period TX FIFO with more than one max packet size in host mode.
So far as I know, usb audio use the isochronous tx FIFO, but this
king of device won't have much data payload and won't, I haven't
see a usb audio have more data than 1024byte/ms.

So I suggest we assign this 48 words to host_nperio_tx_fifi_size instead
if we have to do this. Because we are using device base on bulk transaction
like U-disk very frequently.

Try using a USB webcam.  With that plus a USB audio device it's easy
to overwhelm the periodic TX FIFO.

If we overwhelm the periodic TX FIFO we might actually fail to
transmit ISO or INT packets at the scheduled time.  That seems more
serious of a problem to try to fix than eeking out a tiny bit
performance on a USB disk.  ...but of course, it all depends on what
you consider important.  ;)

We could split the difference, I suppose and put half on each?

-Doug

Re: [PATCH v5 04/21] usb: dwc2: host: Set host_perio_tx_fifo_size to 304 for rk3066

[Kever Yang]

Hi Doug,

We are using the minimum FIFO size mode for TX now, which only
equal to one max packet size.

The addition FIFO size may help shorten the inter-packet data
prepare latency when the bus/DRAM is busy.

For the actual usage in TX, we have very little change to use the
period TX FIFO with more than one max packet size in host mode.
So far as I know, usb audio use the isochronous tx FIFO, but this
king of device won't have much data payload and won't, I haven't
see a usb audio have more data than 1024byte/ms.

So I suggest we assign this 48 words to host_nperio_tx_fifi_size instead
if we have to do this. Because we are using device base on bulk transaction
like U-disk very frequently.

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

Looking at rk3288, there are two dwc2 ports.  One has 960
total_fifo_size and the other 972.

We're currently assigning 528 + 128 + 256 = 912.  That means we're
wasting 48 words on one port and 60 words on the other.  Since we have
one settings block for both ports, let's just eat the 48 words that we
know we have and assign them to what's probably the most
latency-senstive part of the system: periodic transfers.

Presumably other rk3288 parts using the rk3066 settings also have these
extra 48 words as well.

Note: ideally we'd adjust dwc2_calculate_dynamic_fifo() to handle this
more dynamically, but until that's done hardcoding things here seems OK.

NOTE: no known use cases are improved by this patch, but in my stressful
USB tests I certainly see my periodic FIFO filling up both before and
after this change.  Presumably there are some USB configurations where
the periodic FIFO would have been filled before where it no longer is.

Signed-off-by: Douglas Anderson 
---
Changes in v5: None
Changes in v4:
- Set host_perio_tx_fifo_size to 304 for rk3066 new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/platform.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index b6d7666e715c..afdcdeee266d 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -128,7 +128,7 @@ static const struct dwc2_core_params params_rk3066 = {
.en_multiple_tx_fifo= -1,
.host_rx_fifo_size  = 528,  /* 528 DWORDs */
.host_nperio_tx_fifo_size   = 128,  /* 128 DWORDs */
-   .host_perio_tx_fifo_size= 256,  /* 256 DWORDs */
+   .host_perio_tx_fifo_size= 304,  /* 304 DWORDs */
.max_transfer_size  = -1,
.max_packet_count   = -1,
.host_channels  = -1,

Re: [PATCH v5 05/21] usb: dwc2: host: Avoid use of chan->qh after qh freed

[Kever Yang]

Hi Doug,

The NULL pointer bug is one of the most frequent issue we met
during hot plug stress test, thanks for this bug fix.

Reviewed-by: Kever Yang <kever.y...@rock-chips.com>

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

When poking around with USB devices with slub_debug enabled, I found
another obvious use after free.  Turns out that in dwc2_hc_n_intr() I
was in a state when the contents of chan->qh was filled with 0x6b,
indicating that chan->qh was freed but chan still had a reference to
it.

Let's make sure that whenever we free qh we also make sure we remove a
reference from its channel.

The bug fixed here doesn't appear to be new--I believe I just got lucky
and happened to see it while stress testing.

Signed-off-by: Douglas Anderson <diand...@chromium.org>
---
Changes in v5: None
Changes in v4:
- Avoid use of chan->qh after qh freed new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/hcd.c  |  8 
  drivers/usb/dwc2/hcd_intr.c | 10 ++
  2 files changed, 18 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index bc4bdbc1534e..7783c8ba0173 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -164,6 +164,9 @@ static void dwc2_qh_list_free(struct dwc2_hsotg *hsotg,
 qtd_list_entry)
dwc2_hcd_qtd_unlink_and_free(hsotg, qtd, qh);
  
+		if (qh->channel && qh->channel->qh == qh)

+   qh->channel->qh = NULL;
+
spin_unlock_irqrestore(>lock, flags);
dwc2_hcd_qh_free(hsotg, qh);
spin_lock_irqsave(>lock, flags);
@@ -554,7 +557,12 @@ static int dwc2_hcd_endpoint_disable(struct dwc2_hsotg 
*hsotg,
dwc2_hcd_qtd_unlink_and_free(hsotg, qtd, qh);
  
  	ep->hcpriv = NULL;

+
+   if (qh->channel && qh->channel->qh == qh)
+   qh->channel->qh = NULL;
+
spin_unlock_irqrestore(>lock, flags);
+
dwc2_hcd_qh_free(hsotg, qh);
  
  	return 0;

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 352c98364317..99efc2bd1617 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -1935,6 +1935,16 @@ static void dwc2_hc_n_intr(struct dwc2_hsotg *hsotg, int 
chnum)
}
  
  	dwc2_writel(hcint, hsotg->regs + HCINT(chnum));

+
+   /*
+* If we got an interrupt after someone called
+* dwc2_hcd_endpoint_disable() we don't want to crash below
+*/
+   if (!chan->qh) {
+   dev_warn(hsotg->dev, "Interrupt on disabled channel\n");
+   return;
+   }
+
chan->hcint = hcint;
hcint &= hcintmsk;
  

Re: [PATCH v5 03/21] usb: dwc2: host: Set host_rx_fifo_size to 528 for rk3066

[Kever Yang]

Hi Doug,

On 01/23/2016 02:18 AM, Douglas Anderson wrote:

As documented in dwc2_calculate_dynamic_fifo(), host_rx_fifo_size should
really be:
  2 * ((Largest Packet size / 4) + 1 + 1) + n
  with n = number of host channel.

We have 9 host channels, so
  2 * ((1024/4) + 2) + 9 = 516 + 9 = 525

We've got 960 / 972 total_fifo_size on rk3288 (and presumably on
rk3066) and 525 + 128 + 256 = 909 so we're still under on both ports
even when we increment by 5.

Since we have space, Kever Yang suggests bumping by 8.  He says this
will meet INCR16 access and next fifo type can start with a aligned
address.

I have double check this feature, the INCR16 is actually a burst 16
on to the bus, the aligned problem only happen on the DRAM
access, and it's OK for internal RAM access via internal DMA.

Bump to 8 looks much better when we check the FIFO setting if we
have enough memory, right? :)

rk3066/rk3188/rk3288 have the same hw config for dwc2 controller,
so this patch should works on those files.

Reviewed-by: Kever Yang <kever.y...@rock-chips.com>


...so let's bump up by 8.  In the future, it would be nice if
dwc2_calculate_dynamic_fifo() could handle the "too small" FIFO case and
come up with something more dynamically.  When we do that we can figure
out how to allocate the extra 48 / 60 bytes of FIFO that we're currently
wasting.

NOTE: no known bugs are fixed by this patch, but it seems like a simple
fix and ought to fix someone.

Signed-off-by: Douglas Anderson <diand...@chromium.org>
---
Changes in v5: None
Changes in v4:
- Set host_rx_fifo_size to 528 for rk3066 new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/platform.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5008a467ce06..b6d7666e715c 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -126,7 +126,7 @@ static const struct dwc2_core_params params_rk3066 = {
.speed  = -1,
.enable_dynamic_fifo= 1,
.en_multiple_tx_fifo= -1,
-   .host_rx_fifo_size  = 520,  /* 520 DWORDs */
+   .host_rx_fifo_size  = 528,  /* 528 DWORDs */
.host_nperio_tx_fifo_size   = 128,  /* 128 DWORDs */
.host_perio_tx_fifo_size= 256,  /* 256 DWORDs */
.max_transfer_size  = -1,

Re: [PATCH v5 06/21] usb: dwc2: host: Always add to the tail of queues

[Kever Yang]

Hi Doug,

This is obviously a bug in dwc2 driver which not meet the usb 2.0
spec, and this patch can fix it.

Reviewed-by: Kever Yang <kever.y...@rock-chips.com>

Thanks,
- Kever
On 01/23/2016 02:18 AM, Douglas Anderson wrote:

The queues the the dwc2 host controller used are truly queues.  That
means FIFO or first in first out.

Unfortunately though the code was iterating through these queues
starting from the head, some places in the code was adding things to the
queue by adding at the head instead of the tail.  That means last in
first out.  Doh.

Go through and just always add to the tail.

Doing this makes things much happier when I've got:
* 7-port USB 2.0 Single-TT hub
* - Microsoft 2.4 GHz Transceiver v7.0 dongle
* - Jabra speakerphone playing music

Signed-off-by: Douglas Anderson <diand...@chromium.org>
---
Changes in v5: None
Changes in v4:
- Always add to the tail of queues new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/hcd.c   | 11 ++-
  drivers/usb/dwc2/hcd_ddma.c  |  4 ++--
  drivers/usb/dwc2/hcd_intr.c  |  4 ++--
  drivers/usb/dwc2/hcd_queue.c |  6 --
  4 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 7783c8ba0173..d2daaea88d91 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -969,7 +969,8 @@ enum dwc2_transaction_type dwc2_hcd_select_transactions(
 * periodic assigned schedule
 */
qh_ptr = qh_ptr->next;
-   list_move(>qh_list_entry, >periodic_sched_assigned);
+   list_move_tail(>qh_list_entry,
+  >periodic_sched_assigned);
ret_val = DWC2_TRANSACTION_PERIODIC;
}
  
@@ -1002,8 +1003,8 @@ enum dwc2_transaction_type dwc2_hcd_select_transactions(

 * non-periodic active schedule
 */
qh_ptr = qh_ptr->next;
-   list_move(>qh_list_entry,
- >non_periodic_sched_active);
+   list_move_tail(>qh_list_entry,
+  >non_periodic_sched_active);
  
  		if (ret_val == DWC2_TRANSACTION_NONE)

ret_val = DWC2_TRANSACTION_NON_PERIODIC;
@@ -1176,8 +1177,8 @@ static void dwc2_process_periodic_channels(struct 
dwc2_hsotg *hsotg)
 * Move the QH from the periodic assigned schedule to
 * the periodic queued schedule
 */
-   list_move(>qh_list_entry,
- >periodic_sched_queued);
+   list_move_tail(>qh_list_entry,
+  >periodic_sched_queued);
  
  			/* done queuing high bandwidth */

hsotg->queuing_high_bandwidth = 0;
diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
index 36606fc33c0d..16b261cfa92d 100644
--- a/drivers/usb/dwc2/hcd_ddma.c
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -1327,8 +1327,8 @@ void dwc2_hcd_complete_xfer_ddma(struct dwc2_hsotg *hsotg,
dwc2_hcd_qh_unlink(hsotg, qh);
} else {
/* Keep in assigned schedule to continue transfer */
-   list_move(>qh_list_entry,
- >periodic_sched_assigned);
+   list_move_tail(>qh_list_entry,
+  >periodic_sched_assigned);
/*
 * If channel has been halted during giveback of urb
 * then prevent any new scheduling.
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 99efc2bd1617..2c521c00e5e0 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -143,7 +143,7 @@ static void dwc2_sof_intr(struct dwc2_hsotg *hsotg)
 * Move QH to the ready list to be executed next
 * (micro)frame
 */
-   list_move(>qh_list_entry,
+   list_move_tail(>qh_list_entry,
  >periodic_sched_ready);
}
tr_type = dwc2_hcd_select_transactions(hsotg);
@@ -794,7 +794,7 @@ static void dwc2_halt_channel(struct dwc2_hsotg *hsotg,
 * halt to be queued when the periodic schedule is
 * processed.
 */
-   list_move(>qh->qh_list_entry,
+   list_move_tail(>qh->qh_list_entry,
  >periodic_sched_assigned);
  
  			/*

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index e0933a9dfad7..bc632a72f611 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -732,9 +732,11 @@ void dwc2_hcd_q

Re: [RESEND PATCH] rtc: rk808: rename rtc-rk808.c to rtc-rk8xx.c

[Kever Yang]

Hi Zhang Qing,

On 12/31/2015 10:14 PM, zhangqing wrote:

make rtc-rk8xx.c compatible for all pmic chips.
for pmic chips(rk808\rk807\rk816\rk818) in the future.

The commit message will be better like this:
Rename the file to rtc-rk8xx.c to compatible other Rockchip PMIC chips
like rk807/rk816/rk818 and other chips in the the future.

Also rename the variable, MACRO, function and etc. names in relate file.



Signed-off-by: zhangqing 

Prefer to use: Zhang Qing 

---
  drivers/mfd/rk808.c  |   2 +-
  drivers/rtc/Kconfig  |   8 +-
  drivers/rtc/Makefile |   2 +-
  drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} | 218 ++-
  4 files changed, 131 insertions(+), 99 deletions(-)
  rename drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} (64%)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 4b1e439..21da22b 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -77,7 +77,7 @@ static const struct mfd_cell rk808s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
{
-   .name = "rk808-rtc",
+   .name = "rk8xx-rtc",
.num_resources = ARRAY_SIZE(rtc_resources),
.resources = _resources[0],
},
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 376322f..d669473d 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -325,15 +325,15 @@ config RTC_DRV_MAX77686
  This driver can also be built as a module. If so, the module
  will be called rtc-max77686.
  
-config RTC_DRV_RK808

-   tristate "Rockchip RK808 RTC"
+config RTC_DRV_RK8XX
+   tristate "Rockchip RK8XX RTC"
depends on MFD_RK808
help
  If you say yes here you will get support for the
- RTC of RK808 PMIC.
+ RTC of RK8XX PMIC.
  
  	  This driver can also be built as a module. If so, the module

- will be called rk808-rtc.
+ will be called rk8xx-rtc.
  
  config RTC_DRV_MAX77802

tristate "Maxim 77802 RTC"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 62d61b2..5b1384a 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -120,7 +120,7 @@ obj-$(CONFIG_RTC_DRV_PUV3)  += rtc-puv3.o
  obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
  obj-$(CONFIG_RTC_DRV_R9701)   += rtc-r9701.o
  obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
-obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
+obj-$(CONFIG_RTC_DRV_RK8XX)+= rtc-rk8xx.o
  obj-$(CONFIG_RTC_DRV_RP5C01)  += rtc-rp5c01.o
  obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
  obj-$(CONFIG_RTC_DRV_RS5C348) += rtc-rs5c348.o
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk8xx.c
similarity index 64%
rename from drivers/rtc/rtc-rk808.c
rename to drivers/rtc/rtc-rk8xx.c
index 35c9aad..5d946bf 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk8xx.c
@@ -1,5 +1,5 @@
  /*
- * RTC driver for Rockchip RK808
+ * RTC driver for Rockchip RK8XX
   *
   * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
   *
@@ -20,14 +20,33 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
+#include 
+
+#define RK8XX_SECONDS_REG  0x00
+#define RK8XX_MINUTES_REG  0x01
+#define RK8XX_HOURS_REG0x02
+#define RK8XX_DAYS_REG 0x03
+#define RK8XX_MONTHS_REG   0x04
+#define RK8XX_YEARS_REG0x05
+#define RK8XX_WEEKS_REG0x06
+#define RK8XX_ALARM_SECONDS_REG0x08
+#define RK8XX_ALARM_MINUTES_REG0x09
+#define RK8XX_ALARM_HOURS_REG  0x0A
+#define RK8XX_ALARM_DAYS_REG   0x0B
+#define RK8XX_ALARM_MONTHS_REG 0x0C
+#define RK8XX_ALARM_YEARS_REG  0x0D
+#define RK8XX_RTC_CTRL_REG 0x10
+#define RK8XX_RTC_STATUS_REG   0x11
+#define RK8XX_RTC_INT_REG  0x12
+#define RK8XX_RTC_COMP_LSB_REG 0x13
+#define RK8XX_RTC_COMP_MSB_REG 0x14
  
  /* RTC_CTRL_REG bitfields */

  #define BIT_RTC_CTRL_REG_STOP_RTC_M   BIT(0)
  
-/* RK808 has a shadowed register for saving a "frozen" RTC time.

+/* RK8xx has a shadowed register for saving a "frozen" RTC time.
   * When user setting "GET_TIME" to 1, the time will save in this shadowed
   * register. If set "READSEL" to 1, user read rtc time register, actually
   * get the time of that moment. If we need the real time, clr this bit.
@@ -47,17 +66,25 @@
  
  /* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
  
-#define NUM_TIME_REGS	(RK808_WEEKS_REG - RK808_SECONDS_REG + 1)

-#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
+#define NUM_TIME_REGS  (RK8XX_WEEKS_REG - RK8XX_SECONDS_REG + 1)
+#define NUM_ALARM_REGS (RK8XX_ALARM_YEARS_REG - RK8XX_ALARM_SECONDS_REG +