from:"David.Wu"

Re: [U-Boot] [PATCH] rockchip: i2c: don't sent stop bit after each message

2019-11-17 Thread David.Wu


Hi Vasily,

在 2019/11/17 3:32, Vasily Khoruzhick 写道:

+   rk_i2c_send_stop_bit(i2c);
+   rk_i2c_disable(i2c);


I think it is better to also stop i2c if i2c xfer failed, how do you 
feel about it?


@@ -356,11 +356,16 @@ static int rockchip_i2c_xfer(struct udevice *bus, 
struct i2c_msg *msg,

    }
    if (ret) {
    debug("i2c_write: error sending\n");
-   return -EREMOTEIO;
+   ret = -EREMOTEIO;
+   goto exit;
    }
    }

-   return 0;
+exit:
+   rk_i2c_send_stop_bit(i2c);
+   rk_i2c_disable(i2c);
+
+   return ret;
 }



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

Re: [U-Boot] [U-Boot, v4, 7/7] net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID

2018-08-31 Thread David.Wu


Hi Janine,

This patch looks good. Thank you for adding rgmii-id/rxid/txid.
Reviewed-by: David Wu 

在 2018/8/28 14:25, Janine Hagemann 写道:

Using PHY internal delays in combination with the phy-mode
rgmii-id/rxid/txid was not possible. Only rgmii was supported.

Now we can disable rockchip's gmac delay lines and also use
rgmii-id/rxid/txid.

Based on commit eaf70ad14cbb ("net: stmmac: dwmac-rk: Add
handling for RGMII_ID/RXID/TXID") for mainline linux kernel.

Signed-off-by: Janine Hagemann 
Acked-by: Joe Hershberger 
---
v4: No changes
---
  drivers/net/gmac_rockchip.c | 80 +++--
  1 file changed, 63 insertions(+), 17 deletions(-)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 0f91731..c01ae75 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -24,6 +24,11 @@
  #include 
  #include "designware.h"
  
+DECLARE_GLOBAL_DATA_PTR;

+#define DELAY_ENABLE(soc, tx, rx) \
+   (((tx) ? soc##_TXCLK_DLY_ENA_GMAC_ENABLE : 
soc##_TXCLK_DLY_ENA_GMAC_DISABLE) | \
+   ((rx) ? soc##_RXCLK_DLY_ENA_GMAC_ENABLE : 
soc##_RXCLK_DLY_ENA_GMAC_DISABLE))
+
  /*
   * Platform data for the gmac
   *
@@ -286,8 +291,7 @@ static void rk3228_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3228_RXCLK_DLY_ENA_GMAC_MASK |
 RK3228_TXCLK_DLY_ENA_GMAC_MASK,
 RK3228_GMAC_PHY_INTF_SEL_RGMII |
-RK3228_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3228_TXCLK_DLY_ENA_GMAC_ENABLE);
+DELAY_ENABLE(RK3228, pdata->tx_delay, pdata->rx_delay));
  
  	rk_clrsetreg(&grf->mac_con[0],

 RK3228_CLK_RX_DL_CFG_GMAC_MASK |
@@ -310,8 +314,7 @@ static void rk3288_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3288_TXCLK_DLY_ENA_GMAC_MASK |
 RK3288_CLK_RX_DL_CFG_GMAC_MASK |
 RK3288_CLK_TX_DL_CFG_GMAC_MASK,
-RK3288_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3288_TXCLK_DLY_ENA_GMAC_ENABLE |
+DELAY_ENABLE(RK3288, pdata->rx_delay, pdata->tx_delay) |
 pdata->rx_delay << RK3288_CLK_RX_DL_CFG_GMAC_SHIFT |
 pdata->tx_delay << RK3288_CLK_TX_DL_CFG_GMAC_SHIFT);
  }
@@ -350,8 +353,7 @@ static void rk3328_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3328_RXCLK_DLY_ENA_GMAC_MASK |
 RK3328_TXCLK_DLY_ENA_GMAC_MASK,
 RK3328_GMAC_PHY_INTF_SEL_RGMII |
-RK3328_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3328_TXCLK_DLY_ENA_GMAC_ENABLE);
+DELAY_ENABLE(RK3328, pdata->tx_delay, pdata->rx_delay));
  
  	rk_clrsetreg(&grf->mac_con[0],

 RK3328_CLK_RX_DL_CFG_GMAC_MASK |
@@ -392,8 +394,7 @@ static void rk3368_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3368_TXCLK_DLY_ENA_GMAC_MASK |
 RK3368_CLK_RX_DL_CFG_GMAC_MASK |
 RK3368_CLK_TX_DL_CFG_GMAC_MASK,
-RK3368_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3368_TXCLK_DLY_ENA_GMAC_ENABLE |
+DELAY_ENABLE(RK3368, pdata->tx_delay, pdata->rx_delay) |
 pdata->rx_delay << RK3368_CLK_RX_DL_CFG_GMAC_SHIFT |
 pdata->tx_delay << RK3368_CLK_TX_DL_CFG_GMAC_SHIFT);
  }
@@ -413,8 +414,7 @@ static void rk3399_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3399_TXCLK_DLY_ENA_GMAC_MASK |
 RK3399_CLK_RX_DL_CFG_GMAC_MASK |
 RK3399_CLK_TX_DL_CFG_GMAC_MASK,
-RK3399_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3399_TXCLK_DLY_ENA_GMAC_ENABLE |
+DELAY_ENABLE(RK3399, pdata->tx_delay, pdata->rx_delay) |
 pdata->rx_delay << RK3399_CLK_RX_DL_CFG_GMAC_SHIFT |
 pdata->tx_delay << RK3399_CLK_TX_DL_CFG_GMAC_SHIFT);
  }
@@ -451,40 +451,86 @@ static int gmac_rockchip_probe(struct udevice *dev)
  
  	switch (eth_pdata->phy_interface) {

case PHY_INTERFACE_MODE_RGMII:
+   /* Set to RGMII mode */
+   if (ops->set_to_rgmii)
+   ops->set_to_rgmii(pdata);
+   else
+   return -EPERM;
+
/*
 * If the gmac clock is from internal pll, need to set and
 * check the return value for gmac clock at RGMII mode. If
 * the gmac clock is from external source, the clock rate
 * is not set, because of it is bypassed.
 */
+
if (!pdata->clock_input) {
rate = clk_set_rate(&clk, 12500);
if (rate != 12500)
return -EINVAL;
}
+   break;
  
+	case PHY_INTER

Re: [U-Boot] [U-Boot, v4, 6/7] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii

2018-08-31 Thread David.Wu


Hi Janine,

Thank you for the fix.

在 2018/8/28 14:25, Janine Hagemann 写道:

We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of
RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii()
to enable the RX delay.
The MASK was used in a wrong way.

Signed-off-by: Janine Hagemann
Reviewed-by: Philipp Tomisch
Acked-by: Joe Hershberger


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

Re: [U-Boot] [Resend] [U-Boot, v4, 7/7] net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID

2018-08-31 Thread David.Wu


Resend it for Undelivered Mail.

在 2018/8/31 19:54, David.Wu 写道:

Hi Janine,

This patch looks good. Thank you for adding rgmii-id/rxid/txid.
Reviewed-by: David Wu 

在 2018/8/28 14:25, Janine Hagemann 写道:

Using PHY internal delays in combination with the phy-mode
rgmii-id/rxid/txid was not possible. Only rgmii was supported.

Now we can disable rockchip's gmac delay lines and also use
rgmii-id/rxid/txid.

Based on commit eaf70ad14cbb ("net: stmmac: dwmac-rk: Add
handling for RGMII_ID/RXID/TXID") for mainline linux kernel.

Signed-off-by: Janine Hagemann 
Acked-by: Joe Hershberger 
---
v4: No changes
---
  drivers/net/gmac_rockchip.c | 80 
+++--

  1 file changed, 63 insertions(+), 17 deletions(-)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 0f91731..c01ae75 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -24,6 +24,11 @@
  #include 
  #include "designware.h"
+DECLARE_GLOBAL_DATA_PTR;
+#define DELAY_ENABLE(soc, tx, rx) \
+    (((tx) ? soc##_TXCLK_DLY_ENA_GMAC_ENABLE : 
soc##_TXCLK_DLY_ENA_GMAC_DISABLE) | \
+    ((rx) ? soc##_RXCLK_DLY_ENA_GMAC_ENABLE : 
soc##_RXCLK_DLY_ENA_GMAC_DISABLE))

+
  /*
   * Platform data for the gmac
   *
@@ -286,8 +291,7 @@ static void rk3228_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)

   RK3228_RXCLK_DLY_ENA_GMAC_MASK |
   RK3228_TXCLK_DLY_ENA_GMAC_MASK,
   RK3228_GMAC_PHY_INTF_SEL_RGMII |
- RK3228_RXCLK_DLY_ENA_GMAC_ENABLE |
- RK3228_TXCLK_DLY_ENA_GMAC_ENABLE);
+ DELAY_ENABLE(RK3228, pdata->tx_delay, pdata->rx_delay));
  rk_clrsetreg(&grf->mac_con[0],
   RK3228_CLK_RX_DL_CFG_GMAC_MASK |
@@ -310,8 +314,7 @@ static void rk3288_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)

   RK3288_TXCLK_DLY_ENA_GMAC_MASK |
   RK3288_CLK_RX_DL_CFG_GMAC_MASK |
   RK3288_CLK_TX_DL_CFG_GMAC_MASK,
- RK3288_RXCLK_DLY_ENA_GMAC_ENABLE |
- RK3288_TXCLK_DLY_ENA_GMAC_ENABLE |
+ DELAY_ENABLE(RK3288, pdata->rx_delay, pdata->tx_delay) |
   pdata->rx_delay << RK3288_CLK_RX_DL_CFG_GMAC_SHIFT |
   pdata->tx_delay << RK3288_CLK_TX_DL_CFG_GMAC_SHIFT);
  }
@@ -350,8 +353,7 @@ static void rk3328_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)

   RK3328_RXCLK_DLY_ENA_GMAC_MASK |
   RK3328_TXCLK_DLY_ENA_GMAC_MASK,
   RK3328_GMAC_PHY_INTF_SEL_RGMII |
- RK3328_RXCLK_DLY_ENA_GMAC_ENABLE |
- RK3328_TXCLK_DLY_ENA_GMAC_ENABLE);
+ DELAY_ENABLE(RK3328, pdata->tx_delay, pdata->rx_delay));
  rk_clrsetreg(&grf->mac_con[0],
   RK3328_CLK_RX_DL_CFG_GMAC_MASK |
@@ -392,8 +394,7 @@ static void rk3368_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)

   RK3368_TXCLK_DLY_ENA_GMAC_MASK |
   RK3368_CLK_RX_DL_CFG_GMAC_MASK |
   RK3368_CLK_TX_DL_CFG_GMAC_MASK,
- RK3368_RXCLK_DLY_ENA_GMAC_ENABLE |
- RK3368_TXCLK_DLY_ENA_GMAC_ENABLE |
+ DELAY_ENABLE(RK3368, pdata->tx_delay, pdata->rx_delay) |
   pdata->rx_delay << RK3368_CLK_RX_DL_CFG_GMAC_SHIFT |
   pdata->tx_delay << RK3368_CLK_TX_DL_CFG_GMAC_SHIFT);
  }
@@ -413,8 +414,7 @@ static void rk3399_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)

   RK3399_TXCLK_DLY_ENA_GMAC_MASK |
   RK3399_CLK_RX_DL_CFG_GMAC_MASK |
   RK3399_CLK_TX_DL_CFG_GMAC_MASK,
- RK3399_RXCLK_DLY_ENA_GMAC_ENABLE |
- RK3399_TXCLK_DLY_ENA_GMAC_ENABLE |
+ DELAY_ENABLE(RK3399, pdata->tx_delay, pdata->rx_delay) |
   pdata->rx_delay << RK3399_CLK_RX_DL_CFG_GMAC_SHIFT |
   pdata->tx_delay << RK3399_CLK_TX_DL_CFG_GMAC_SHIFT);
  }
@@ -451,40 +451,86 @@ static int gmac_rockchip_probe(struct udevice *dev)
  switch (eth_pdata->phy_interface) {
  case PHY_INTERFACE_MODE_RGMII:
+    /* Set to RGMII mode */
+    if (ops->set_to_rgmii)
+    ops->set_to_rgmii(pdata);
+    else
+    return -EPERM;
+
  /*
   * If the gmac clock is from internal pll, need to set and
   * check the return value for gmac clock at RGMII mode. If
   * the gmac clock is from external source, the clock rate
   * is not set, because of it is bypassed.
   */
+
  if (!pdata->clock_input) {
  rate = clk_set_rate(&clk, 12500);
  if (rate != 12500)
  return -EINVAL;
  }
+    break;
+    case PHY_INTERFACE_MODE_RGMII_ID:
  /* Set to RGMII mode */
-    if (ops->set_to_rgmii)
+    if (ops->set_to_rgmii) {
+    pdata->tx_delay = 0;
+

Re: [U-Boot] [U-Boot, v4, 5/9] net: gmac_rk3288: Add RK3288 GMAC driver

2016-12-24 Thread David.Wu


Hi Simon,

Could you rename this driver file from rk3288 to rockchip,
and the name of some common function?
The other rockchip socs would use this driver as rk1108, etc.

在 2016/12/3 13:06, Simon Glass 写道:

From: Sjoerd Simons 

Add a new driver for the GMAC ethernet interface present in Rockchip
RK3288 SOCs. This driver subclasses the generic design-ware driver to
add the glue needed specifically for Rockchip.

Signed-off-by: Sjoerd Simons 
Signed-off-by: Simon Glass 
Acked-by: Joe Hershberger 
---

Changes in v4: None
Changes in v3:
- Add comments for struct gmac_rk3288_platdata
- Adjust binding to use r/tx-delay instead of r/tx_delay
- Sort includes
- Use debug() instead of printf() for error
- Use function calls instead of fix_mac_speed() hook
- Use new clk interface

Changes in v2:
- Adjust to new hook name
- Fix various coding style nits

  drivers/net/Kconfig   |   7 +++
  drivers/net/Makefile  |   1 +
  drivers/net/gmac_rk3288.c | 154 ++
  3 files changed, 162 insertions(+)
  create mode 100644 drivers/net/gmac_rk3288.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f25d3ff..0027a2e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -215,4 +215,11 @@ config PIC32_ETH
  This driver implements 10/100 Mbps Ethernet and MAC layer for
  Microchip PIC32 microcontrollers.
  
+config GMAC_RK3288

+   bool "Rockchip RK3288 Synopsys Designware Ethernet MAC"
+   depends on DM_ETH && ETH_DESIGNWARE
+   help
+ This driver provides Rockchip RK3288 network support based on the
+ Synopsys Designware driver.
+
  endif # NETDEVICES
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 9a7bfc6..348e98b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_FTGMAC100) += ftgmac100.o
  obj-$(CONFIG_FTMAC110) += ftmac110.o
  obj-$(CONFIG_FTMAC100) += ftmac100.o
  obj-$(CONFIG_GRETH) += greth.o
+obj-$(CONFIG_GMAC_RK3288) += gmac_rk3288.o
  obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o
  obj-$(CONFIG_KS8851_MLL) += ks8851_mll.o
  obj-$(CONFIG_LAN91C96) += lan91c96.o
diff --git a/drivers/net/gmac_rk3288.c b/drivers/net/gmac_rk3288.c
new file mode 100644
index 000..0c22756
--- /dev/null
+++ b/drivers/net/gmac_rk3288.c
@@ -0,0 +1,154 @@
+/*
+ * (C) Copyright 2015 Sjoerd Simons 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Rockchip GMAC ethernet IP driver for U-Boot
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "designware.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Platform data for the gmac
+ *
+ * dw_eth_pdata: Required platform data for designware driver (must be first)
+ */
+struct gmac_rk3288_platdata {
+   struct dw_eth_pdata dw_eth_pdata;
+   int tx_delay;
+   int rx_delay;
+};
+
+static int gmac_rk3288_ofdata_to_platdata(struct udevice *dev)
+{
+   struct gmac_rk3288_platdata *pdata = dev_get_platdata(dev);
+
+   pdata->tx_delay = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"tx-delay", 0x30);
+   pdata->rx_delay = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"rx-delay", 0x10);
+
+   return designware_eth_ofdata_to_platdata(dev);
+}
+
+static int gmac_rk3288_fix_mac_speed(struct dw_eth_dev *priv)
+{
+   struct rk3288_grf *grf;
+   int clk;
+
+   switch (priv->phydev->speed) {
+   case 10:
+   clk = GMAC_CLK_SEL_2_5M;
+   break;
+   case 100:
+   clk = GMAC_CLK_SEL_25M;
+   break;
+   case 1000:
+   clk = GMAC_CLK_SEL_125M;
+   break;
+   default:
+   debug("Unknown phy speed: %d\n", priv->phydev->speed);
+   return -EINVAL;
+   }
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(&grf->soc_con1,
+GMAC_CLK_SEL_MASK << GMAC_CLK_SEL_SHIFT,
+clk << GMAC_CLK_SEL_SHIFT);
+
+   return 0;
+}
+
+static int gmac_rk3288_probe(struct udevice *dev)
+{
+   struct gmac_rk3288_platdata *pdata = dev_get_platdata(dev);
+   struct rk3288_grf *grf;
+   struct clk clk;
+   int ret;
+
+   ret = clk_get_by_index(dev, 0, &clk);
+   if (ret)
+   return ret;
+
+   /* Since mac_clk is fed by an external clock we can use 0 here */
+   ret = clk_set_rate(&clk, 0);
+   if (ret)
+   return ret;
+
+   /* Set to RGMII mode */
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(&grf->soc_con1,
+RMII_MODE_MASK << RMII_MODE_SHIFT |
+GMAC_PHY_INTF_SEL_MASK << GMAC_PHY_INTF_SEL_SHIFT,
+GMAC_PHY_INTF_SEL_RGMII << GMAC_PHY_INTF_SEL_SHIFT);
+
+   rk_clrsetreg(&grf->soc_con3,
+RXCLK_DLY_ENA_GMAC_MASK <<

Re: [U-Boot] [PATCH 4/8] clk: rockchip: Add Saradc clock support for rk3288

2017-09-13 Thread David.Wu

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Hi Dr.Philipp å¨ 2017/9/13 18:24, Dr. Philipp Tomsich åé:
   > >> On 13 Sep 2017, at 12:09, David Wu  wrote:
  >> > > Please add a commit message. > >> Signed-off-by: David Wu 

   > > Reviewed-by: Philipp Tomsich 
  > > See above and below for requested changes. > >> --- >> 
drivers/clk/rockchip/clk_rk3288.c
   | 45 +++ >> 1 file changed, 45 
insertions(+)
   >> >> diff --git a/drivers/clk/rockchip/clk_rk3288.c 
b/drivers/clk/rockchip/clk_rk3288.c
   >> index 478195b..29652b0 100644 >> --- a/drivers/clk/rockchip/clk_rk3288.c
   >> +++ b/drivers/clk/rockchip/clk_rk3288.c >> @@ -111,6 +111,15 @@ enum {
   >> PERI_ACLK_DIV_SHIFT = 0, >> PERI_ACLK_DIV_MASK = 0x1f << 
PERI_ACLK_DIV_SHIFT,
   >> >> + /* >> + * CLKSEL24 >> + * saradc_div_con: >> + * 
clk_saradc=24MHz/(saradc_div_con+1)
   >> + */ >> + CLK_SARADC_DIV_CON_SHIFT = 8, >> + CLK_SARADC_DIV_CON_MASK =
   0xff << CLK_SARADC_DIV_CON_SHIFT, >> + CLK_SARADC_DIV_CON_WIDTH = 8, >> +
   >> SOCSTS_DPLL_LOCK = 1 << 5, >> SOCSTS_APLL_LOCK = 1 << 6, >> 
SOCSTS_CPLL_LOCK
   = 1 << 7, >> @@ -131,6 +140,11 @@ static const struct pll_div apll_init_cfg
   = PLL_DIVISORS(APLL_HZ, 1, 1); >> static const struct pll_div gpll_init_cfg
   = PLL_DIVISORS(GPLL_HZ, 2, 2); >> static const struct pll_div cpll_init_cfg
   = PLL_DIVISORS(CPLL_HZ, 1, 2); >> >> +static inline u32 extract_bits(u32
  val, unsigned width, unsigned shift) >> +{ >> + return (val >> shift) & ((1
   << width) - 1); >> +} > > Please reuse whatâs already available in 
include/bitfield.h.
   > This also applies to all call-sites for extract_bits below: they should
   directly use the already existing function. [...] 

Content analysis details:   (5.6 points, 5.0 required)

 pts rule name  description
 -- --
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 0.0 KHOP_BIG_TO_CC Sent to 10+ recipients instaed of Bcc or a list
 2.6 RCVD_IN_SBLRBL: Received via a relay in Spamhaus SBL
[211.157.147.132 listed in zen.spamhaus.org]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.132 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---

Hi Dr.Philipp

在 2017/9/13 18:24, Dr. Philipp Tomsich 写道:



On 13 Sep 2017, at 12:09, David Wu  wrote:



Please add a commit message.


Signed-off-by: David Wu 


Reviewed-by: Philipp Tomsich 

See above and below for requested changes.


---
drivers/clk/rockchip/clk_rk3288.c | 45 +++
1 file changed, 45 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3288.c 
b/drivers/clk/rockchip/clk_rk3288.c
index 478195b..29652b0 100644
--- a/drivers/clk/rockchip/clk_rk3288.c
+++ b/drivers/clk/rockchip/clk_rk3288.c
@@ -111,6 +111,15 @@ enum {
PERI_ACLK_DIV_SHIFT = 0,
PERI_ACLK_DIV_MASK  = 0x1f << PERI_ACLK_DIV_SHIFT,

+   /*
+* CLKSEL24
+* saradc_div_con:
+* clk_saradc=24MHz/(saradc_div_con+1)
+*/
+   CLK_SARADC_DIV_CON_SHIFT= 8,
+   CLK_SARADC_DIV_CON_MASK = 0xff << CLK_SARADC_DIV_CON_SHIFT,
+   CLK_SARADC_DIV_CON_WIDTH= 8,
+
SOCSTS_DPLL_LOCK= 1 << 5,
SOCSTS_APLL_LOCK= 1 << 6,
SOCSTS_CPLL_LOCK= 1 << 7,
@@ -131,6 +140,11 @@ static const struct pll_div apll_init_cfg = 
PLL_DIVISORS(APLL_HZ, 1, 1);
static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 2, 2);
static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 2);

+static inline u32 extract_bits(u32 val, unsigned width, unsigned shift)
+{
+   return (val >> shift) & ((1 << width) - 1);
+}


Please reuse what’s already available in include/bitfield.h.
This also applies to all call-sites for extract_bits below: they should 
directly use the already existing function.


Okay, i will use the bitfield_extract（) instead of it.




+
static int rkclk_set_pll(struct rk3288_cru *cru, enum rk_clk_id clk_id,
 const struct pll_div *div)
{
@@ -634,6 +648,31 @@ static ulong rockchip_spi_set_clk(struct rk3288_cru *cru, 
uint gclk_rate,
return rockchip_spi_get_clk(cru, gclk_rate, periph);
}

+static ulong rockchip_saradc_get_clk(struct rk3288_cru *cru)
+{
+   u32 div, val;
+
+   val = readl(&cru->cru_clksel_con[24]);
+   div = extract_bits(val, CLK_SARADC_DIV_CON_WIDTH,
+  CLK_SARADC_DIV_CON_SHIFT);
+
+   return DIV_TO_RATE(OS

Re: [U-Boot] [PATCH 2/8] configs: rockchip: Enable the ROCKCHIP_SARADC config

2017-09-13 Thread David.Wu

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Hi Dr.Philipp, å¨ 2017/9/13 18:20, Dr. Philipp Tomsich 
åé:
   > Please use an âimplyâ in the Kconfig for the various SoCs (or possibly
   > even the entire sub-architecture) or a "default y if â¦â. > > Given
  that this is a DM-enabled driver, there is no harm in compiling > it in, even
   if a given board does not use it. This should make defconfig > changes 
unnecessary
   (unless someone really needs to override the > implied setting). [...] 

Content analysis details:   (5.6 points, 5.0 required)

 pts rule name  description
 -- --
 2.6 RCVD_IN_SBLRBL: Received via a relay in Spamhaus SBL
[211.157.147.132 listed in zen.spamhaus.org]
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.132 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---

Hi Dr.Philipp,

在 2017/9/13 18:20, Dr. Philipp Tomsich 写道:

Please use an ‘imply’ in the Kconfig for the various SoCs (or possibly
even the entire sub-architecture) or a "default y if …”.

Given that this is a DM-enabled driver, there is no harm in compiling
it in, even if a given board does not use it.  This should make defconfig
changes unnecessary (unless someone really needs to override the
implied setting).


Yeap, it is no harm to compile it in, so config the CONFIG_ADC and 
CONFIG_SARADC_ROCKCHIP with a default y in Kconfig?


--- End Message ---
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,1/8] adc: Add driver for Rockchip Saradc

2017-09-14 Thread David.Wu

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Hi Philipp, å¨ 2017/9/14 4:40, Philipp Tomsich åé: >
  > > On Wed, 13 Sep 2017, David Wu wrote: > >> The ADC can support some 
channels
   signal-ended some bits Successive >> Approximation >> Register (SAR) A/D
  Converter, like 6-channel and 10-bit. It converts >> the analog >> input 
signal
   into some bits binary digital codes. >> >> Signed-off-by: David Wu 

   > > Reviewed-by: Philipp Tomsich 
  > > Please see below for requested changes. > >> --- >> drivers/adc/KconfigÂ
   Â Â Â Â Â Â Â Â Â |Â Â 9 ++ >> drivers/adc/MakefileÂ Â Â Â Â Â Â Â Â |Â Â
   1 + >> drivers/adc/rockchip-saradc.c | 188 >> 
++
   >> 3 files changed, 198 insertions(+) >> create mode 100644 
drivers/adc/rockchip-saradc.c
   >> >> diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig >> index 
e5335f7..830fe0f
   100644 >> --- a/drivers/adc/Kconfig >> +++ b/drivers/adc/Kconfig >> @@ -20,6
   +20,15 @@ config ADC_EXYNOS >> Â Â Â Â Â - 12-bit resolution >> Â Â Â Â Â
   - 600 KSPS of sample rate >> >> +config SARADC_ROCKCHIP >> +Â Â Â bool 
"Enable
   Rockchip SARADC driver" >> +Â Â Â help >> +Â Â Â Â Â This enables driver
  for Rockchip SARADC. >> +Â Â Â Â Â It provides: >> +Â Â Â Â Â - 2~6 analog
   input channels >> +Â Â Â Â Â - 1O-bit resolution >> +Â Â Â Â Â - 1MSPS of
   sample rate >> + >> config ADC_SANDBOX >> Â Â Â Â bool "Enable Sandbox ADC
   test driver" >> Â Â Â Â help >> diff --git a/drivers/adc/Makefile 
b/drivers/adc/Makefile
   >> index cebf26d..4b5aa69 100644 >> --- a/drivers/adc/Makefile >> +++ 
b/drivers/adc/Makefile
   >> @@ -8,3 +8,4 @@ >> obj-$(CONFIG_ADC) += adc-uclass.o >> 
obj-$(CONFIG_ADC_EXYNOS)
   += exynos-adc.o >> obj-$(CONFIG_ADC_SANDBOX) += sandbox.o >> 
+obj-$(CONFIG_SARADC_ROCKCHIP)
   += rockchip-saradc.o > > Do you feel strongly about the "SARADC_ROCKCHIP"
   or would "ADC_ROCKCHIP" > be correct as well?Â I don't care either way, but
   this is the first > entry here that does not start with CONFIG_ADC_, so I
   am wondering... [...] 

Content analysis details:   (6.8 points, 5.0 required)

 pts rule name  description
 -- --
 2.6 RCVD_IN_SBLRBL: Received via a relay in Spamhaus SBL
[211.157.147.132 listed in zen.spamhaus.org]
 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 [Blocked - see ]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.132 listed in bl.mailspike.net]
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---

Hi Philipp,

在 2017/9/14 4:40, Philipp Tomsich 写道:



On Wed, 13 Sep 2017, David Wu wrote:

The ADC can support some channels signal-ended some bits Successive 
Approximation
Register (SAR) A/D Converter, like 6-channel and 10-bit. It converts 
the analog

input signal into some bits binary digital codes.

Signed-off-by: David Wu 


Reviewed-by: Philipp Tomsich 

Please see below for requested changes.


---
drivers/adc/Kconfig   |   9 ++
drivers/adc/Makefile  |   1 +
drivers/adc/rockchip-saradc.c | 188 
++

3 files changed, 198 insertions(+)
create mode 100644 drivers/adc/rockchip-saradc.c

diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index e5335f7..830fe0f 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -20,6 +20,15 @@ config ADC_EXYNOS
  - 12-bit resolution
  - 600 KSPS of sample rate

+config SARADC_ROCKCHIP
+    bool "Enable Rockchip SARADC driver"
+    help
+  This enables driver for Rockchip SARADC.
+  It provides:
+  - 2~6 analog input channels
+  - 1O-bit resolution
+  - 1MSPS of sample rate
+
config ADC_SANDBOX
bool "Enable Sandbox ADC test driver"
help
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index cebf26d..4b5aa69 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -8,3 +8,4 @@
obj-$(CONFIG_ADC) += adc-uclass.o
obj-$(CONFIG_ADC_EXYNOS) += exynos-adc.o
obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
+obj-$(CONFIG_SARADC_ROCKCHIP) += rockchip-saradc.o


Do you feel strongly about the "SARADC_ROCKCHIP" or would "ADC_ROCKCHIP" 
be correct as well?  I don't care either way, but this is the first 
entry here that does not start with CONFIG_ADC_, so I am wondering...


Yes, we have other adc IPs, like tsadc,vsadc...
So i think SARADC_ROCKCHIP is better.



diff --git a/drivers/adc/rockchip-

Re: [U-Boot] [PATCH] rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs

2017-09-20 Thread David.Wu


Hi Philipp,

在 2017/9/20 19:54, Philipp Tomsich 写道:

Enable the Rockchip SARADC driver on all supported SoCs (i.e. all
except the RK3036 and RK3228, which don't have this peripheral):
RK3188, RK3288, RK3328, RK3368, RK3399 and RV1108.

Signed-off-by: Philipp Tomsich
---


Reviewed-by: David Wu 

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

Re: [U-Boot] [PATCH] rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs

2017-09-21 Thread David.Wu


Hi Philipp,

在 2017/9/20 21:00, Dr. Philipp Tomsich 写道:

Should we just imply these two configuration-values for all Rockchip
devices (i.e. even for the RK3036 and RK3228) to further simplify the
Kconfig?


I think it is okay to imply all rockchip devices, it is no harm. If 
after all Rockchip chips'defconfig is the same one, only one is 
rockchip_defconfig, we don't have this problem. now of defconfig indeed 
too much.


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

Re: [U-Boot] [U-Boot, 4/6] net: gmac_rockchip: Define the gmac grf register struct at gmac_rockchip.c

2017-10-17 Thread David.Wu


Hi Philipp,

在 2017/10/6 18:06, Philipp Tomsich 写道:



On Thu, 21 Sep 2017, David Wu wrote:


If we include both the rk3288_grf.h and rv1108_grf.h, there is a
number of compiling error for redefinition. So we define the reg
structs of mac_grf at gmac_rockchip.c. Remove the rk**_grf.h files,
give them own grf offset for their use.


The reg offset should not be open-coded in gmac_rockchip.c.

The issue of GRF-header having conflicting definitions was already
discussed on the list, when I initially submitted the RK3368 support.
The decision back then was as follows:
1/ The GRF files should not contain definitions that are private to
    the IOMUX (e.g. these should go into the pinctrl-driver), etc.


I'll try to move all the iomux definitions at GRF-header into 
pinctrl-driver, use pinctrl_request* interface to set iomux in some 
board.c file.



2/ As an intermediate step, we move some of this (i.e. the GMAC_CLK_SEL
    definitions into gmac_rockchip.c.


I still think the 'GMAC_CLK_SEL' bit set should be implemented at clk 
driver.



3/ The long-term solution will be to either create misc-devices that
    handle the 'set-to-rgmii' functionality and the 'GMAC_CLK_SEL'
    bits (although on those, modelling it via the clk-framework might
    be more appropriate).


Could you give me a example code for misc-devices?



Please clean up the affected GRF files that cause the conflicts (e.g.
the RV1108) and extend the current implementation w/o open-coding a
grf-offet.

Additional requested changes below.



Signed-off-by: David Wu 
Acked-by: Philipp Tomsich 
---

drivers/net/gmac_rockchip.c | 144 
+++-

1 file changed, 116 insertions(+), 28 deletions(-)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 586ccbf..5f8f0cd 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -15,9 +15,6 @@
#include 
#include 
#include 
-#include 
-#include 
-#include 
#include 
#include 
#include "designware.h"
@@ -31,15 +28,37 @@ DECLARE_GLOBAL_DATA_PTR;
 */
struct gmac_rockchip_platdata {
struct dw_eth_pdata dw_eth_pdata;
+    void *grf;
int tx_delay;
int rx_delay;
};

struct rk_gmac_ops {
-    int (*fix_mac_speed)(struct dw_eth_dev *priv);
+    int (*fix_mac_speed)(struct gmac_rockchip_platdata *pdata,
+ struct dw_eth_dev *priv);
void (*set_to_rgmii)(struct gmac_rockchip_platdata *pdata);
};

+struct gmac_rockchip_driver_data {
+    const struct rk_gmac_ops *ops;
+    unsigned int grf_offset;
+};
+
+struct rk3288_mac_grf {
+    u32 soc_con1;
+    u32 reserved;
+    u32 soc_con3;
+};
+
+struct rk3368_mac_grf {
+    u32 soc_con15;
+    u32 soc_con16;
+};
+
+struct rk3399_mac_grf {
+    u32 soc_con5;
+    u32 soc_con6;
+};


We really can't pollute the GMAC driver with these definitions.
The actual values need to come out of the central GRF structure definition.



static int gmac_rockchip_ofdata_to_platdata(struct udevice *dev)
{
@@ -58,10 +77,18 @@ static int gmac_rockchip_ofdata_to_platdata(struct 
udevice *dev)

return designware_eth_ofdata_to_platdata(dev);
}

-static int rk3288_gmac_fix_mac_speed(struct dw_eth_dev *priv)
+static int rk3288_gmac_fix_mac_speed(struct gmac_rockchip_platdata 
*pdata,

+ struct dw_eth_dev *priv)
{
-    struct rk3288_grf *grf;
+    struct rk3288_mac_grf *grf = (struct rk3288_mac_grf *)pdata->grf;
int clk;
+    enum {
+    RK3288_GMAC_CLK_SEL_SHIFT = 12,
+    RK3288_GMAC_CLK_SEL_MASK  = GENMASK(13, 12),
+    RK3288_GMAC_CLK_SEL_125M  = 0 << 12,
+    RK3288_GMAC_CLK_SEL_25M   = 3 << 12,
+    RK3288_GMAC_CLK_SEL_2_5M  = 2 << 12,
+    };

switch (priv->phydev->speed) {
case 10:
@@ -78,15 +105,15 @@ static int rk3288_gmac_fix_mac_speed(struct 
dw_eth_dev *priv)

    return -EINVAL;
}

-    grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
rk_clrsetreg(&grf->soc_con1, RK3288_GMAC_CLK_SEL_MASK, clk);

return 0;
}

-static int rk3368_gmac_fix_mac_speed(struct dw_eth_dev *priv)
+static int rk3368_gmac_fix_mac_speed(struct gmac_rockchip_platdata 
*pdata,

+ struct dw_eth_dev *priv)
{
-    struct rk3368_grf *grf;
+    struct rk3368_mac_grf *grf = (struct rk3368_mac_grf *)pdata->grf;
int clk;
enum {
    RK3368_GMAC_CLK_SEL_2_5M = 2 << 4,
@@ -110,16 +137,22 @@ static int rk3368_gmac_fix_mac_speed(struct 
dw_eth_dev *priv)

    return -EINVAL;
}

-    grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
rk_clrsetreg(&grf->soc_con15, RK3368_GMAC_CLK_SEL_MASK, clk);

return 0;
}

-static int rk3399_gmac_fix_mac_speed(struct dw_eth_dev *priv)
+static int rk3399_gmac_fix_mac_speed(struct gmac_rockchip_platdata 
*pdata,

+ struct dw_eth_dev *priv)
{
-    struct rk3399_grf_regs *grf;
+    struct rk3399_mac_grf *grf = (struct rk3399_mac_grf *)pdata->grf;
int clk;
+    enum {
+    RK3399_GMAC_CLK_SEL_MASK  = GENMASK(6, 4),
+    RK3399_GMAC_CLK_SEL_

Re: [U-Boot] [U-Boot, 4/6] net: gmac_rockchip: Define the gmac grf register struct at gmac_rockchip.c

2017-10-18 Thread David.Wu

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Hi Philipp, å¨ 2017/10/6 18:06, Philipp Tomsich åé: >
   > > On Thu, 21 Sep 2017, David Wu wrote: > >> If we include both the 
rk3288_grf.h
   and rv1108_grf.h, there is a >> number of compiling error for redefinition.
   So we define the reg >> structs of mac_grf at gmac_rockchip.c. Remove the
   rk**_grf.h files, >> give them own grf offset for their use. > > The reg
  offset should not be open-coded in gmac_rockchip.c. > > The issue of 
GRF-header
   having conflicting definitions was already > discussed on the list, when
  I initially submitted the RK3368 support. > The decision back then was as
  follows: > 1/ The GRF files should not contain definitions that are private
   to > Â Â the IOMUX (e.g. these should go into the pinctrl-driver), etc. [...]
   

Content analysis details:   (5.1 points, 5.0 required)

 pts rule name  description
 -- --
 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
[211.157.147.133 listed in psbl.surriel.com]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.133 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---

Hi Philipp,

在 2017/10/6 18:06, Philipp Tomsich 写道:



On Thu, 21 Sep 2017, David Wu wrote:


If we include both the rk3288_grf.h and rv1108_grf.h, there is a
number of compiling error for redefinition. So we define the reg
structs of mac_grf at gmac_rockchip.c. Remove the rk**_grf.h files,
give them own grf offset for their use.


The reg offset should not be open-coded in gmac_rockchip.c.

The issue of GRF-header having conflicting definitions was already
discussed on the list, when I initially submitted the RK3368 support.
The decision back then was as follows:
1/ The GRF files should not contain definitions that are private to
    the IOMUX (e.g. these should go into the pinctrl-driver), etc.


Here are some problems, we call Pinctrl-driver interface to set iomux 
like uart console in some Soc board_init_f or board_init, but the DM 
peripheral driver is not ready for us to use, so if the iomux 
definitions are moved to the pinctrl drive, and using the pinctrl 
interface has limitations.



2/ As an intermediate step, we move some of this (i.e. the GMAC_CLK_SEL
    definitions into gmac_rockchip.c.
3/ The long-term solution will be to either create misc-devices that
    handle the 'set-to-rgmii' functionality and the 'GMAC_CLK_SEL'
    bits (although on those, modelling it via the clk-framework might
    be more appropriate).

Please clean up the affected GRF files that cause the conflicts (e.g.
the RV1108) and extend the current implementation w/o open-coding a
grf-offet.

Additional requested changes below.



Signed-off-by: David Wu 
Acked-by: Philipp Tomsich 
---

drivers/net/gmac_rockchip.c | 144 
+++-

1 file changed, 116 insertions(+), 28 deletions(-)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 586ccbf..5f8f0cd 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -15,9 +15,6 @@
#include 
#include 
#include 
-#include 
-#include 
-#include 
#include 
#include 
#include "designware.h"
@@ -31,15 +28,37 @@ DECLARE_GLOBAL_DATA_PTR;
 */
struct gmac_rockchip_platdata {
struct dw_eth_pdata dw_eth_pdata;
+    void *grf;
int tx_delay;
int rx_delay;
};

struct rk_gmac_ops {
-    int (*fix_mac_speed)(struct dw_eth_dev *priv);
+    int (*fix_mac_speed)(struct gmac_rockchip_platdata *pdata,
+ struct dw_eth_dev *priv);
void (*set_to_rgmii)(struct gmac_rockchip_platdata *pdata);
};

+struct gmac_rockchip_driver_data {
+    const struct rk_gmac_ops *ops;
+    unsigned int grf_offset;
+};
+
+struct rk3288_mac_grf {
+    u32 soc_con1;
+    u32 reserved;
+    u32 soc_con3;
+};
+
+struct rk3368_mac_grf {
+    u32 soc_con15;
+    u32 soc_con16;
+};
+
+struct rk3399_mac_grf {
+    u32 soc_con5;
+    u32 soc_con6;
+};


We really can't pollute the GMAC driver with these definitions.
The actual values need to come out of the central GRF structure definition.



static int gmac_rockchip_ofdata_to_platdata(struct udevice *dev)
{
@@ -58,10 +77,18 @@ static int gmac_rockchip_ofdata_to_platdata(struct 
udevice *dev)

return designware_eth_ofdata_to_platdata(dev);
}

-static int rk3288_gmac_fix_mac_speed(struct dw_eth_dev *priv)
+static int rk3288_gmac_fix_mac_speed(struct gmac_rockchip_platdata 
*pdata,

+ struct dw_eth_dev *priv)
{
-    struct rk3288_grf *grf;
+    struct rk3288_mac_grf *grf = (struct rk3288_mac_

Re: [U-Boot] [U-Boot, 5/6] net: gmac_rockchip: Use the proerty of "clock_in_out" to set mac clock

2017-10-18 Thread David.Wu

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Hi Philipp, å¨ 2017/10/6 18:17, Philipp Tomsich åé: >>
   +Â Â Â if (pdata->clk_in) { >> +Â Â Â Â Â Â Â /* >> +Â Â Â Â Â Â Â Â * Since
   mac_clk is fed by an external clock >> +Â Â Â Â Â Â Â Â * we can use 0 here.
   >> +Â Â Â Â Â Â Â Â */ >> +Â Â Â Â Â Â Â ret = clk_set_rate(&clk, 0); > >
   In hindsight using '0' was a bad decision. > We should always request the
   expected external clock rate here (so the > clock driver could do some sanity
   checking). [...] 

Content analysis details:   (6.9 points, 5.0 required)

 pts rule name  description
 -- --
 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
[211.157.147.133 listed in psbl.surriel.com]
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 [Blocked - see ]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.133 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---

Hi Philipp,

在 2017/10/6 18:17, Philipp Tomsich 写道:

+    if (pdata->clk_in) {
+    /*
+ * Since mac_clk is fed by an external clock
+ * we can use 0 here.
+ */
+    ret = clk_set_rate(&clk, 0);


In hindsight using '0' was a bad decision.
We should always request the expected external clock rate here (so the 
clock driver could do some sanity checking).


We need to tell CLK driver to configure internal or external register, 
so do you think we're going to set this cru register directly in the 
GAMC drive, or is it similar to kernel, introducing parent, CLK driver 
through the parent to judge external or internal?


--- End Message ---
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 16/18] clk: rockchip: Add rk322x gamc clock support

2017-12-21 Thread David.Wu


Hi Philipp,

在 2017/11/26 22:50, Philipp Tomsich 写道:


On Thu, 9 Nov 2017, David Wu wrote:


Assuming mac_clk is fed by an external clock, set clk_rmii_src
clock select control register from IO for rgmii interface.

Signed-off-by: David Wu 
Acked-by: Philipp Tomsich 


Reviewed-by: Philipp Tomsich 

See below for requested changes.


---

Changes in v2:
- New patch

drivers/clk/rockchip/clk_rk322x.c | 13 +
1 file changed, 13 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk322x.c 
b/drivers/clk/rockchip/clk_rk322x.c

index e87267d..5fd27cd 100644
--- a/drivers/clk/rockchip/clk_rk322x.c
+++ b/drivers/clk/rockchip/clk_rk322x.c
@@ -239,6 +239,16 @@ static ulong rockchip_mmc_get_clk(struct 
rk322x_cru *cru, uint clk_general_rate,

return DIV_TO_RATE(src_rate, div) / 2;
}

+static int rk322x_mac_set_clk(struct rk322x_cru *cru,
+  int periph, uint freq)
+{
+    /* Assuming mac_clk is fed by an external clock */
+    rk_clrsetreg(&cru->cru_clksel_con[5], BIT(5),
+ BIT(5));


Please use a symbolic constant for BIT(5).

If this is the input/output selection for the MAC clk and covered by 
'clock_in_out = "input";' in the DTS, then the DTS should be consulted 
before assuming a specific setting here.




Yes, I think so, but not do it now;
If it is "input", then actually do not need to set clk rate, as long as 
the direction of setting clk, clk rate rely on external clock input may 
originate from PHY.

If it is "output", then also need to set clk rate.

There has been the interface of setting clock rate currently, but not 
set the direction. Can we in the GMAC driver directly set cru registers 
of mac_clk direction through the dts property of "clk_in_out", otherwise 
need clk framework to provide a set of directional interface like 
setting the parent of mac_clk.



+
+    return 0;
+}
+
static ulong rockchip_mmc_set_clk(struct rk322x_cru *cru, uint 
clk_general_rate,

  int periph, uint freq)
{
@@ -352,6 +362,9 @@ static ulong rk322x_clk_set_rate(struct clk *clk, 
ulong rate)

case CLK_DDR:
    new_rate = rk322x_ddr_set_clk(priv->cru, rate);
    break;
+    case SCLK_MAC:
+    new_rate = rk322x_mac_set_clk(priv->cru, clk->id, rate);
+    break;
default:
    return -ENOENT;
}







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

Re: [U-Boot] [PATCH v2 17/18] net: gmac_rockchip: Add support for the RK3228 GMAC

2017-12-25 Thread David.Wu


Hi Heiko,

Yes, Next plan I want to implement the integrated-phy, because some 
customers are also consulting this feature, but the current RMII/RGMII 
of internal/external mac_clk compatible configuration still has a 
problem, I want to solve this first.


在 2017/12/26 4:45, Heiko Stuebner 写道:

Hi David,

Am Donnerstag, 9. November 2017, 17:28:19 CET schrieb David Wu:
[stuff that somehow got caught by the spam filter]

Shouldn't that code also handle the integrated-phy of the rk3228/rk3229?
Right now it looks like this only handles rgmii connected external phys
but I guess most tv-boxes based on the rk3229 might use the internal
phy to save on components.


Heiko





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

Re: [U-Boot] [PATCH v2 14/18] rockchip: pinctrl: rk322x: Move the iomux definitions into pinctrl-driver

2017-12-25 Thread David.Wu


Hi Heiko

在 2017/12/26 2:59, Heiko Stuebner 写道:

Hi David,

Am Donnerstag, 9. November 2017, 17:24:58 CET schrieb David Wu:

diff --git a/arch/arm/mach-rockchip/rk322x-board-spl.c 
b/arch/arm/mach-rockchip/rk322x-board-spl.c
index 35f4f97..f7c6045 100644
--- a/arch/arm/mach-rockchip/rk322x-board-spl.c
+++ b/arch/arm/mach-rockchip/rk322x-board-spl.c
@@ -30,7 +30,25 @@ DECLARE_GLOBAL_DATA_PTR;
  
  void board_debug_uart_init(void)

  {
-static struct rk322x_grf * const grf = (void *)GRF_BASE;
+   static struct rk322x_grf * const grf = (void *)GRF_BASE;
+   enum {
+   GPIO1B2_SHIFT   = 4,
+   GPIO1B2_MASK= 3 << GPIO1B2_SHIFT,
+   GPIO1B2_UART1_SIN,
+   GPIO1B2_UART21_SIN,
+
+   GPIO1B1_SHIFT   = 2,
+   GPIO1B1_MASK= 3 << GPIO1B1_SHIFT,
+   GPIO1B1_UART1_SOUT,
+   GPIO1B1_UART21_SOUT,


You seem to drop the GPIO1B1_GPIO = 0, line, so the enum counting
wil get jumbled, because GPIO1B1_UART1_SOUT for example will get to
be 4 instead of the 1 it needs to be.

This may be true for the other patches for the other socs as well,
so you may want to double check?



Yes, they are needed to check again.



Heiko





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

Re: [U-Boot] [U-Boot, v2, 16/18] clk: rockchip: Add rk322x gamc clock support

2018-01-12 Thread David.Wu


Hi Philipp,

For the 'assigned-clocks' patches, i tested them well, and have 
implemented them at rk3328, rk3229, rk3288 and rk3368. The patches has 
been send for your review. Except for one thing, just like you said, we 
need to move "clk_set_defaults" further down and do it just before:

if (drv->probe) {
   ret = drv->probe(dev);
after ofdata_to_platdata called, or we might have a cru uninitialized 
problem.


在 2018/1/8 23:12, Dr. Philipp Tomsich 写道:

David,

As discussed last week (off-list), I implemented infrastructure-support for the
'assigned-clocks', 'assigned-clock-parents' and 'assigned-clock-rates’ 
properties
in the DTS … and validated on the RK3399.

For my work-in-progress tree, see the ‘assigned-clocks-wip’ branch at:
https://github.com/ptomsich/u-boot-rockchip/tree/assigned-clocks-wip

If this is sufficient to solve our clocking-issue on GMAC let me know. I plan to
have some additional time to finish this up for submission around the end of
the week.

@Jakob: This is the change I mentioned this morning that provides infrastructure
to allow setting PLLs via the DTS.  These changes are also on our internal GIT
in the ‘assigned-clocks-wip’ branch (which I manually mirror onto GitHub, so I
can test via Travis-CI).

Comments are welcome,
Phil.


On 4 Jan 2018, at 14:22, David.Wu  wrote:

Hi Philipp,

Could i just make the clock-driver respond to the requested frequency? I.e. 
50MHz will most likely always come from the internal sources
so when 50Mhz for rmii gets requested you just assume that we will use the 
internal source. And the 125MHz, we assume that we will use the externalsource.

在 2017/12/21 19:21, David.Wu 写道:

Hi Philipp,
在 2017/11/26 22:50, Philipp Tomsich 写道:


On Thu, 9 Nov 2017, David Wu wrote:


Assuming mac_clk is fed by an external clock, set clk_rmii_src
clock select control register from IO for rgmii interface.

Signed-off-by: David Wu 
Acked-by: Philipp Tomsich 


Reviewed-by: Philipp Tomsich 

See below for requested changes.


---

Changes in v2:
- New patch

drivers/clk/rockchip/clk_rk322x.c | 13 +
1 file changed, 13 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk322x.c 
b/drivers/clk/rockchip/clk_rk322x.c
index e87267d..5fd27cd 100644
--- a/drivers/clk/rockchip/clk_rk322x.c
+++ b/drivers/clk/rockchip/clk_rk322x.c
@@ -239,6 +239,16 @@ static ulong rockchip_mmc_get_clk(struct rk322x_cru *cru, 
uint clk_general_rate,
 return DIV_TO_RATE(src_rate, div) / 2;
}

+static int rk322x_mac_set_clk(struct rk322x_cru *cru,
+  int periph, uint freq)
+{
+/* Assuming mac_clk is fed by an external clock */
+rk_clrsetreg(&cru->cru_clksel_con[5], BIT(5),
+ BIT(5));


Please use a symbolic constant for BIT(5).

If this is the input/output selection for the MAC clk and covered by 'clock_in_out = 
"input";' in the DTS, then the DTS should be consulted before assuming a 
specific setting here.


Yes, I think so, but not do it now;
If it is "input", then actually do not need to set clk rate, as long as the 
direction of setting clk, clk rate rely on external clock input may originate from PHY.
If it is "output", then also need to set clk rate.
There has been the interface of setting clock rate currently, but not set the direction. 
Can we in the GMAC driver directly set cru registers of mac_clk direction through the dts 
property of "clk_in_out", otherwise need clk framework to provide a set of 
directional interface like setting the parent of mac_clk.

+
+return 0;
+}
+
static ulong rockchip_mmc_set_clk(struct rk322x_cru *cru, uint clk_general_rate,
   int periph, uint freq)
{
@@ -352,6 +362,9 @@ static ulong rk322x_clk_set_rate(struct clk *clk, ulong 
rate)
 case CLK_DDR:
 new_rate = rk322x_ddr_set_clk(priv->cru, rate);
 break;
+case SCLK_MAC:
+new_rate = rk322x_mac_set_clk(priv->cru, clk->id, rate);
+break;
 default:
 return -ENOENT;
 }














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

Re: [U-Boot] [PATCH] rockchip: i2c: don't sent stop bit after each message

Re: [U-Boot] [U-Boot, v4, 7/7] net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID

Re: [U-Boot] [U-Boot, v4, 6/7] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii

Re: [U-Boot] [Resend] [U-Boot, v4, 7/7] net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID

Re: [U-Boot] [U-Boot, v4, 5/9] net: gmac_rk3288: Add RK3288 GMAC driver

Re: [U-Boot] [PATCH 4/8] clk: rockchip: Add Saradc clock support for rk3288

Re: [U-Boot] [PATCH 2/8] configs: rockchip: Enable the ROCKCHIP_SARADC config

Re: [U-Boot] [U-Boot,1/8] adc: Add driver for Rockchip Saradc

Re: [U-Boot] [PATCH] rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs

Re: [U-Boot] [PATCH] rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs

Re: [U-Boot] [U-Boot, 4/6] net: gmac_rockchip: Define the gmac grf register struct at gmac_rockchip.c

Re: [U-Boot] [U-Boot, 4/6] net: gmac_rockchip: Define the gmac grf register struct at gmac_rockchip.c

Re: [U-Boot] [U-Boot, 5/6] net: gmac_rockchip: Use the proerty of "clock_in_out" to set mac clock

Re: [U-Boot] [U-Boot, v2, 16/18] clk: rockchip: Add rk322x gamc clock support

Re: [U-Boot] [PATCH v2 17/18] net: gmac_rockchip: Add support for the RK3228 GMAC

Re: [U-Boot] [PATCH v2 14/18] rockchip: pinctrl: rk322x: Move the iomux definitions into pinctrl-driver

Re: [U-Boot] [U-Boot, v2, 16/18] clk: rockchip: Add rk322x gamc clock support

17 matches

Site Navigation

Mail list logo

Footer information