Re: [PATCH v2 2/2] arm64: dts: rockchip: rk3399: fix pd_tcpc0 and pd_tcpc1 node position

[Caesar Wang]

Hi Heiko,

在 2020/5/19 上午6:29, Heiko Stübner 写道:

Hi Kever, Caesar,

could you double check where the type-c power-domains are located
in the power-tree, as Caesar did add them under pd_vio back in 2016.


Johan's patch is correct, the pd_tcpc0 and pd_tcpc1 are grouped by VDD_LOGIC.
I have a passed test for pd_vio without pd_tcpc*.



Thanks
Heiko

Am Dienstag, 28. April 2020, 22:30:03 CEST schrieb Johan Jonker:

The pd_tcpc0 and pd_tcpc1 nodes are currently a sub node of pd_vio.
In the rk3399 TRM figure of the 'Power Domain Partition' and in the
table of 'Power Domain and Voltage Domain Summary' these power domains
are positioned directly under VD_LOGIC, so fix that in 'rk3399.dtsi'.

Signed-off-by: Johan Jonker 



Reviewed-by: Caesar Wang 

Thanks,

-Caesar


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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 37279db53..a4dc1bf2e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1056,6 +1056,16 @@
clocks = < HCLK_SDIO>;
pm_qos = <_sdioaudio>;
};
+   pd_tcpc0@RK3399_PD_TCPD0 {
+   reg = ;
+   clocks = < SCLK_UPHY0_TCPDCORE>,
+< SCLK_UPHY0_TCPDPHY_REF>;
+   };
+   pd_tcpc1@RK3399_PD_TCPD1 {
+   reg = ;
+   clocks = < SCLK_UPHY1_TCPDCORE>,
+< SCLK_UPHY1_TCPDPHY_REF>;
+   };
pd_usb3@RK3399_PD_USB3 {
reg = ;
clocks = < ACLK_USB3>;
@@ -1088,16 +1098,6 @@
pm_qos = <_isp1_m0>,
 <_isp1_m1>;
};
-   pd_tcpc0@RK3399_PD_TCPD0 {
-   reg = ;
-   clocks = < SCLK_UPHY0_TCPDCORE>,
-< SCLK_UPHY0_TCPDPHY_REF>;
-   };
-   pd_tcpc1@RK3399_PD_TCPD1 {
-   reg = ;
-   clocks = < SCLK_UPHY1_TCPDCORE>,
-< SCLK_UPHY1_TCPDPHY_REF>;
-   };
pd_vo@RK3399_PD_VO {
reg = ;
#address-cells = <1>;

Re: [PATCH] phy: rockchip-dp: Avoid power leak by leaving the PHY power on

[Caesar Wang]

Hi Doug,

For now,  nobody of rockchip is responsible for this driver.
Cc: Nickey, Zain, Hjc


On 5/8/19 7:48 AM, Douglas Anderson wrote:

While testing a newer kernel on rk3288-based Chromebooks I found that
the power draw in suspend was higher on newer kernels compared to the
downstream Chrome OS 3.14 kernel.  Specifically the power of an
rk3288-veyron-jerry board that I tested (as measured by the smart
battery) was ~16 mA on Chrome OS 3.14 and ~21 mA on a newer kernel.

I tracked the regression down to the fact that the "DP PHY" driver
didn't exist in our downstream 3.14.  We relied on the eDP driver to
turn on the clock and relied on the fact that the power for the PHY
was default turned on.

Specifically the thing that caused the power regression was turning
the eDP PHY _off_.  Presumably there is some sort of power leak in the
system and when we turn the PHY off something is leaching power from
something else and causing excessive power draw.

Doing a search through device trees shows that this PHY is only ever
used on rk3288.  Presumably this power leak is present on all
rk3288-SoCs running upstream Linux so let's just whack the driver to
make sure we never turn off power.  We'll still leave the parts that
turn _on_ the power and grab the clock, though.

NOTES:
A) If someone can identify what this power leak is and fix it in some
other way we can revert this patch.
B) If someone can show that their particular board doesn't have this
power leak (maybe they have rails hooked up differently?) we can
perhaps add a device tree property indicating that for some boards
it's OK to turn this rail off.  I don't want to add this property
until I know of a board that needs it.

Fixes: fd968973de95 ("phy: Add driver for rockchip Display Port PHY")
Signed-off-by: Douglas Anderson 



Reviewed-by: Caesar Wang 


---
As far as I know Yakir (the original author) is no longer at Rockchip.
I've added a few other Rockchip people and hopefully one of them can
help direct even if they're not directly responsible.

  drivers/phy/rockchip/phy-rockchip-dp.c | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-dp.c 
b/drivers/phy/rockchip/phy-rockchip-dp.c
index 8b267a746576..10bbcd69d6f5 100644
--- a/drivers/phy/rockchip/phy-rockchip-dp.c
+++ b/drivers/phy/rockchip/phy-rockchip-dp.c
@@ -35,7 +35,7 @@ struct rockchip_dp_phy {
  static int rockchip_set_phy_state(struct phy *phy, bool enable)
  {
struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
-   int ret;
+   int ret = 0;
  
  	if (enable) {

ret = regmap_write(dp->grf, GRF_SOC_CON12,
@@ -50,9 +50,12 @@ static int rockchip_set_phy_state(struct phy *phy, bool 
enable)
} else {
clk_disable_unprepare(dp->phy_24m);
  
-		ret = regmap_write(dp->grf, GRF_SOC_CON12,

-  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
-  GRF_EDP_PHY_SIDDQ_OFF);
+   /*
+* Intentionally don't turn SIDDQ off when disabling
+* the PHY.  There is a power leak on rk3288 and
+* suspend power _increases_ by 5 mA if you turn this
+* off.
+*/



As described by TRM, The “GRF_EDP_PHY_SIDDQ_OFF” that all circuits are 
power down, all
IO are high-Z. That should make sure the PD_VIO[0] was disabled first, 
no active.

But the rk3288 can't turn pd_vio off at the moment.

[0]
PD_VIO Which clock are device clocks:
             *    clocks        devices
             *    *_IEP        IEP:Image Enhancement Processor
             *    *_ISP        ISP:Image Signal Processing
             *    *_VIP        VIP:Video Input Processor
             *    *_VOP*        VOP:Visual Output Processor
             *    *_RGA        RGA
             *    *_EDP*        EDP
             *    *_LVDS_*    LVDS
             *    *_HDMI        HDMI
             *    *_MIPI_*    MIPI


Thanks,
-Caesar



}
  
  	return ret;

Re: [PATCH v2 17/19] mailbox: rockchip: Use device-managed registration API

[Caesar Wang]

On 2018/12/17 下午11:02, Thierry Reding wrote:

From: Thierry Reding 

Get rid of some boilerplate driver removal code by using the newly added
device-managed registration API.


Reviewed-by: Caesar Wang 

Thanks,
Caesar


Cc: Caesar Wang 
Signed-off-by: Thierry Reding 
---
  drivers/mailbox/rockchip-mailbox.c | 15 +--
  1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/mailbox/rockchip-mailbox.c 
b/drivers/mailbox/rockchip-mailbox.c
index d702a204f5c1..f24a77b1a0ff 100644
--- a/drivers/mailbox/rockchip-mailbox.c
+++ b/drivers/mailbox/rockchip-mailbox.c
@@ -247,28 +247,15 @@ static int rockchip_mbox_probe(struct platform_device 
*pdev)
mb->chans[i].msg = NULL;
}
  
-	ret = mbox_controller_register(>mbox);

+   ret = devm_mbox_controller_register(>dev, >mbox);
if (ret < 0)
dev_err(>dev, "Failed to register mailbox: %d\n", ret);
  
  	return ret;

  }
  
-static int rockchip_mbox_remove(struct platform_device *pdev)

-{
-   struct rockchip_mbox *mb = platform_get_drvdata(pdev);
-
-   if (!mb)
-   return -EINVAL;
-
-   mbox_controller_unregister(>mbox);
-
-   return 0;
-}
-
  static struct platform_driver rockchip_mbox_driver = {
.probe  = rockchip_mbox_probe,
-   .remove = rockchip_mbox_remove,
.driver = {
.name = "rockchip-mailbox",
.of_match_table = of_match_ptr(rockchip_mbox_of_match),


--
王晓腾 | 系统产品三部 | 软件工程师
Caesar Wang |  Product R Dept.III | Software engineer
**
福州瑞芯微电子股份有限公司
Fuzhou Rockchip Electronics Co.Ltd
地址：福建省福州市铜盘路软件大道89号软件园A区20号楼 (福州总部)
Addr: No.20 Building, A District, Fuzhou Software Park.Gulou 
District,Fuzhou,Fujian,China(Fuzhou Headquarters)
Tel：+86-0591-83991906-8221
Mobile: +86 15059456742
E-mail: w...@rock-chips.com
*

保密提示：本邮件及其附件含有机密信息，仅发送给本邮件所指特定收件人。若非该特定收件人，请勿复制、
使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件或其他方式即刻告知发件人。
福州瑞芯微电子有限公司拥有本邮件信息的著作权及解释权，禁止任何未经授权许可的侵权行为。
IMPORTANT NOTICE: This email is from Fuzhou Rockchip Electronics Co., Ltd .The 
contents of this
email and any attachments may contain information that is privileged, 
confidential and/or exempt from disclosure under applicable law and relevant 
NDA.
If you are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution, or use of the information is STRICTLY 
PROHIBITED.
Please immediately contact the sender as soon as possible and destroy the 
material in its entirety in any format. Thank you.

Re: [PATCH v3 0/2] phy: rockchip-emmc: fixes emmc-phy power on failed with rk3399 SoCs

[Caesar Wang]

Kishon,

Can you help merge this in your  or next tree?  I'm hoping that we can 
land this somewhere.:-)



Thanks,
-Caesar
在 2018年01月11日 10:40, Caesar Wang 写道:

Hi Kishon,

Since the Shawn isn't available, I take over this series patches for now.

As the original bug had tracked on https://issuetracker.google.com/71561742.
In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[   2.375333] rockchip_emmc_phy_power: caldone timeout.
[2.377815] phy phy-ff77.syscon:phy@f780.4: phy poweron failed --> -110
...
[2.489295] mmc0: mmc_select_hs400es failed, error -110
[2.489302] mmc0: error -110 whilst initialising MMC card
..

The actual emulate, the wait 5us for calpad busy trimming, that's no enough.
We need give the enough margin for it.

Verified on url =
 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4
This series patches can apply and bring up with kernel-next on rk3399 
chromebook.

-Caesar


Changes in v3:
- As Doug commented on both upstream and gerrit.
   Change "5, 50" to "0, 50", and the message of print.
- As Doug commented on https://patchwork.kernel.org/patch/10154797,
   Change "1, 50" to "0, 50".

Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
   changed the note and added to print error value with
   regmap_read_poll_timeout API.

Shawn Lin (2):
   phy: rockchip-emmc: retry calpad busy trimming
   phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

  drivers/phy/rockchip/phy-rockchip-emmc.c | 60 +++-
  1 file changed, 28 insertions(+), 32 deletions(-)

Re: [PATCH v3 0/2] phy: rockchip-emmc: fixes emmc-phy power on failed with rk3399 SoCs

[Caesar Wang]

Kishon,

Can you help merge this in your  or next tree?  I'm hoping that we can 
land this somewhere.:-)



Thanks,
-Caesar
在 2018年01月11日 10:40, Caesar Wang 写道:

Hi Kishon,

Since the Shawn isn't available, I take over this series patches for now.

As the original bug had tracked on https://issuetracker.google.com/71561742.
In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[   2.375333] rockchip_emmc_phy_power: caldone timeout.
[2.377815] phy phy-ff77.syscon:phy@f780.4: phy poweron failed --> -110
...
[2.489295] mmc0: mmc_select_hs400es failed, error -110
[2.489302] mmc0: error -110 whilst initialising MMC card
..

The actual emulate, the wait 5us for calpad busy trimming, that's no enough.
We need give the enough margin for it.

Verified on url =
 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4
This series patches can apply and bring up with kernel-next on rk3399 
chromebook.

-Caesar


Changes in v3:
- As Doug commented on both upstream and gerrit.
   Change "5, 50" to "0, 50", and the message of print.
- As Doug commented on https://patchwork.kernel.org/patch/10154797,
   Change "1, 50" to "0, 50".

Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
   changed the note and added to print error value with
   regmap_read_poll_timeout API.

Shawn Lin (2):
   phy: rockchip-emmc: retry calpad busy trimming
   phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

  drivers/phy/rockchip/phy-rockchip-emmc.c | 60 +++-
  1 file changed, 28 insertions(+), 32 deletions(-)

[PATCH v3 0/2] phy: rockchip-emmc: fixes emmc-phy power on failed with rk3399 SoCs

[Caesar Wang]

Hi Kishon,

Since the Shawn isn't available, I take over this series patches for now.

As the original bug had tracked on https://issuetracker.google.com/71561742.
In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[   2.375333] rockchip_emmc_phy_power: caldone timeout.
[2.377815] phy phy-ff77.syscon:phy@f780.4: phy poweron failed --> -110
...
[2.489295] mmc0: mmc_select_hs400es failed, error -110
[2.489302] mmc0: error -110 whilst initialising MMC card
..

The actual emulate, the wait 5us for calpad busy trimming, that's no enough.
We need give the enough margin for it.

Verified on url =

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4
This series patches can apply and bring up with kernel-next on rk3399 
chromebook.

-Caesar


Changes in v3:
- As Doug commented on both upstream and gerrit.
  Change "5, 50" to "0, 50", and the message of print.
- As Doug commented on https://patchwork.kernel.org/patch/10154797,
  Change "1, 50" to "0, 50".

Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
  changed the note and added to print error value with
  regmap_read_poll_timeout API.

Shawn Lin (2):
  phy: rockchip-emmc: retry calpad busy trimming
  phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

 drivers/phy/rockchip/phy-rockchip-emmc.c | 60 +++-
 1 file changed, 28 insertions(+), 32 deletions(-)

-- 
2.7.4

[PATCH v3 0/2] phy: rockchip-emmc: fixes emmc-phy power on failed with rk3399 SoCs

[Caesar Wang]

Hi Kishon,

Since the Shawn isn't available, I take over this series patches for now.

As the original bug had tracked on https://issuetracker.google.com/71561742.
In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[   2.375333] rockchip_emmc_phy_power: caldone timeout.
[2.377815] phy phy-ff77.syscon:phy@f780.4: phy poweron failed --> -110
...
[2.489295] mmc0: mmc_select_hs400es failed, error -110
[2.489302] mmc0: error -110 whilst initialising MMC card
..

The actual emulate, the wait 5us for calpad busy trimming, that's no enough.
We need give the enough margin for it.

Verified on url =

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4
This series patches can apply and bring up with kernel-next on rk3399 
chromebook.

-Caesar


Changes in v3:
- As Doug commented on both upstream and gerrit.
  Change "5, 50" to "0, 50", and the message of print.
- As Doug commented on https://patchwork.kernel.org/patch/10154797,
  Change "1, 50" to "0, 50".

Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
  changed the note and added to print error value with
  regmap_read_poll_timeout API.

Shawn Lin (2):
  phy: rockchip-emmc: retry calpad busy trimming
  phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

 drivers/phy/rockchip/phy-rockchip-emmc.c | 60 +++-
 1 file changed, 28 insertions(+), 32 deletions(-)

-- 
2.7.4

[PATCH v3 1/2] phy: rockchip-emmc: retry calpad busy trimming

[Caesar Wang]

From: Shawn Lin <shawn@rock-chips.com>

It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.

Signed-off-by: Shawn Lin <shawn@rock-chips.com>
Tested-by: Ziyuan Xu <xzy...@rock-chips.com>
Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

Changes in v3:
- As Doug commented on both upstream and gerrit.
  Change "5, 50" to "0, 50", and the message of print.

Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.

 drivers/phy/rockchip/phy-rockchip-emmc.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index f1b24f1..b0d1093 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -76,6 +76,10 @@
 #define PHYCTRL_OTAPDLYSEL_MASK0xf
 #define PHYCTRL_OTAPDLYSEL_SHIFT   0x7
 
+#define PHYCTRL_IS_CALDONE(x) \
+   x) >> PHYCTRL_CALDONE_SHIFT) & \
+ PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+
 struct rockchip_emmc_phy {
unsigned intreg_offset;
struct regmap   *reg_base;
@@ -90,6 +94,7 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
unsigned long timeout;
+   int ret;
 
/*
 * Keep phyctrl_pdb and phyctrl_endll low to allow
@@ -160,17 +165,19 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
   PHYCTRL_PDB_SHIFT));
 
/*
-* According to the user manual, it asks driver to
-* wait 5us for calpad busy trimming
+* According to the user manual, it asks driver to wait 5us for
+* calpad busy trimming. However it is documented that this value is
+* PVT(A.K.A process,voltage and temperature) relevant, so some
+* failure cases are found which indicates we should be more tolerant
+* to calpad busy trimming.
 */
-   udelay(5);
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
-   if (caldone != PHYCTRL_CALDONE_DONE) {
-   pr_err("rockchip_emmc_phy_power: caldone timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  caldone, PHYCTRL_IS_CALDONE(caldone),
+  0, 50);
+   if (ret) {
+   pr_err("%s: caldone failed, ret=%d\n", __func__, ret);
+   return ret;
}
 
/* Set the frequency of the DLL operation */
-- 
2.7.4

[PATCH v3 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

[Caesar Wang]

From: Shawn Lin <shawn@rock-chips.com>

Just use the API instead of open-coding it, no functional change
intended.

Signed-off-by: Shawn Lin <shawn@rock-chips.com>
Reviewed-by: Brian Norris <briannor...@chromium.org>
Signed-off-by: Caesar Wang <w...@rock-chips.com>

---

Changes in v3:
- As Doug commented on https://patchwork.kernel.org/patch/10154797,
  Change "1, 50" to "0, 50".

Changes in v2:
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
  changed the note and added to print error value with
  regmap_read_poll_timeout API.

 drivers/phy/rockchip/phy-rockchip-emmc.c | 33 +++-
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index b0d1093..b237360 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -79,6 +79,9 @@
 #define PHYCTRL_IS_CALDONE(x) \
x) >> PHYCTRL_CALDONE_SHIFT) & \
  PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+#define PHYCTRL_IS_DLLRDY(x) \
+   x) >> PHYCTRL_DLLRDY_SHIFT) & \
+ PHYCTRL_DLLRDY_MASK) == PHYCTRL_DLLRDY_DONE)
 
 struct rockchip_emmc_phy {
unsigned intreg_offset;
@@ -93,7 +96,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int dllrdy;
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
-   unsigned long timeout;
int ret;
 
/*
@@ -217,28 +219,15 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
 * NOTE: There appear to be corner cases where the DLL seems to take
 * extra long to lock for reasons that aren't understood.  In some
 * extreme cases we've seen it take up to over 10ms (!).  We'll be
-* generous and give it 50ms.  We still busy wait here because:
-* - In most cases it should be super fast.
-* - This is not called lots during normal operation so it shouldn't
-*   be a power or performance problem to busy wait.  We expect it
-*   only at boot / resume.  In both cases, eMMC is probably on the
-*   critical path so busy waiting a little extra time should be OK.
+* generous and give it 50ms.
 */
-   timeout = jiffies + msecs_to_jiffies(50);
-   do {
-   udelay(1);
-
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
-   if (dllrdy == PHYCTRL_DLLRDY_DONE)
-   break;
-   } while (!time_after(jiffies, timeout));
-
-   if (dllrdy != PHYCTRL_DLLRDY_DONE) {
-   pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  dllrdy, PHYCTRL_IS_DLLRDY(dllrdy),
+  0, 50 * USEC_PER_MSEC);
+   if (ret) {
+   pr_err("%s: dllrdy failed. ret=%d\n", __func__, ret);
+   return ret;
}
 
return 0;
-- 
2.7.4

[PATCH v3 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

[Caesar Wang]

From: Shawn Lin 

Just use the API instead of open-coding it, no functional change
intended.

Signed-off-by: Shawn Lin 
Reviewed-by: Brian Norris 
Signed-off-by: Caesar Wang 

---

Changes in v3:
- As Doug commented on https://patchwork.kernel.org/patch/10154797,
  Change "1, 50" to "0, 50".

Changes in v2:
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
  changed the note and added to print error value with
  regmap_read_poll_timeout API.

 drivers/phy/rockchip/phy-rockchip-emmc.c | 33 +++-
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index b0d1093..b237360 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -79,6 +79,9 @@
 #define PHYCTRL_IS_CALDONE(x) \
x) >> PHYCTRL_CALDONE_SHIFT) & \
  PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+#define PHYCTRL_IS_DLLRDY(x) \
+   x) >> PHYCTRL_DLLRDY_SHIFT) & \
+ PHYCTRL_DLLRDY_MASK) == PHYCTRL_DLLRDY_DONE)
 
 struct rockchip_emmc_phy {
unsigned intreg_offset;
@@ -93,7 +96,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int dllrdy;
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
-   unsigned long timeout;
int ret;
 
/*
@@ -217,28 +219,15 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
 * NOTE: There appear to be corner cases where the DLL seems to take
 * extra long to lock for reasons that aren't understood.  In some
 * extreme cases we've seen it take up to over 10ms (!).  We'll be
-* generous and give it 50ms.  We still busy wait here because:
-* - In most cases it should be super fast.
-* - This is not called lots during normal operation so it shouldn't
-*   be a power or performance problem to busy wait.  We expect it
-*   only at boot / resume.  In both cases, eMMC is probably on the
-*   critical path so busy waiting a little extra time should be OK.
+* generous and give it 50ms.
 */
-   timeout = jiffies + msecs_to_jiffies(50);
-   do {
-   udelay(1);
-
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
-   if (dllrdy == PHYCTRL_DLLRDY_DONE)
-   break;
-   } while (!time_after(jiffies, timeout));
-
-   if (dllrdy != PHYCTRL_DLLRDY_DONE) {
-   pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  dllrdy, PHYCTRL_IS_DLLRDY(dllrdy),
+  0, 50 * USEC_PER_MSEC);
+   if (ret) {
+   pr_err("%s: dllrdy failed. ret=%d\n", __func__, ret);
+   return ret;
}
 
return 0;
-- 
2.7.4

[PATCH v3 1/2] phy: rockchip-emmc: retry calpad busy trimming

[Caesar Wang]

From: Shawn Lin 

It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.

Signed-off-by: Shawn Lin 
Tested-by: Ziyuan Xu 
Signed-off-by: Caesar Wang 
---

Changes in v3:
- As Doug commented on both upstream and gerrit.
  Change "5, 50" to "0, 50", and the message of print.

Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.

 drivers/phy/rockchip/phy-rockchip-emmc.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index f1b24f1..b0d1093 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -76,6 +76,10 @@
 #define PHYCTRL_OTAPDLYSEL_MASK0xf
 #define PHYCTRL_OTAPDLYSEL_SHIFT   0x7
 
+#define PHYCTRL_IS_CALDONE(x) \
+   x) >> PHYCTRL_CALDONE_SHIFT) & \
+ PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+
 struct rockchip_emmc_phy {
unsigned intreg_offset;
struct regmap   *reg_base;
@@ -90,6 +94,7 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
unsigned long timeout;
+   int ret;
 
/*
 * Keep phyctrl_pdb and phyctrl_endll low to allow
@@ -160,17 +165,19 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
   PHYCTRL_PDB_SHIFT));
 
/*
-* According to the user manual, it asks driver to
-* wait 5us for calpad busy trimming
+* According to the user manual, it asks driver to wait 5us for
+* calpad busy trimming. However it is documented that this value is
+* PVT(A.K.A process,voltage and temperature) relevant, so some
+* failure cases are found which indicates we should be more tolerant
+* to calpad busy trimming.
 */
-   udelay(5);
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
-   if (caldone != PHYCTRL_CALDONE_DONE) {
-   pr_err("rockchip_emmc_phy_power: caldone timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  caldone, PHYCTRL_IS_CALDONE(caldone),
+  0, 50);
+   if (ret) {
+   pr_err("%s: caldone failed, ret=%d\n", __func__, ret);
+   return ret;
}
 
/* Set the frequency of the DLL operation */
-- 
2.7.4

Re: [PATCH v2 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

[Caesar Wang]

在 2018年01月11日 03:36, Doug Anderson 写道:

Hi,

On Wed, Jan 10, 2018 at 9:46 AM, Brian Norris  wrote:

*/
- timeout = jiffies + msecs_to_jiffies(50);
- do {
- udelay(1);
-
- regmap_read(rk_phy->reg_base,
- rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
- );
- dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
- if (dllrdy == PHYCTRL_DLLRDY_DONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (dllrdy != PHYCTRL_DLLRDY_DONE) {
- pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
- return -ETIMEDOUT;
+ ret = regmap_read_poll_timeout(rk_phy->reg_base,
+rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+dllrdy, PHYCTRL_IS_DLLRDY(dllrdy),
+1, 50 * USEC_PER_MSEC);

It seems a bit schizophrenic that one of our delay loops sleeps 1 us
between loops and the other sleeps 5 us between loops.

...and, in fact, both of these numbers seem a little on the silly side
of things.  Assuming that the timer docs are up to date, usleep_range
is intended for sleeping "10us - 20ms".  Both 1 us and 5 us below that
range and "1 us" is an order of magnitude below that range.  ...your 1
and 5 actually translate to usleep_range(1, 1) and usleep_range(3, 5).

It seems like trying to do a sleep (the whole idea that some other
process will get to run for some fraction of the 1 us) is just wasting
cycles.

So I'd say either:

1. Accept that we really expect this to be a long delay and change
your delay to 10 us

2. Change the delay to 0 us and accept that you're busy waiting.

I'd vote for #2 unless you have some evidence that we often need long
delays and we've started calling this code all the time.


Agreed with #2


-Caesar




+ if (ret) {
+ pr_err("%s: dllrdy failed %d.\n", __func__, ret);
+ return ret;
   }

   return 0;
--
1.9.1



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v2 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

[Caesar Wang]

在 2018年01月11日 03:36, Doug Anderson 写道:

Hi,

On Wed, Jan 10, 2018 at 9:46 AM, Brian Norris  wrote:

*/
- timeout = jiffies + msecs_to_jiffies(50);
- do {
- udelay(1);
-
- regmap_read(rk_phy->reg_base,
- rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
- );
- dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
- if (dllrdy == PHYCTRL_DLLRDY_DONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (dllrdy != PHYCTRL_DLLRDY_DONE) {
- pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
- return -ETIMEDOUT;
+ ret = regmap_read_poll_timeout(rk_phy->reg_base,
+rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+dllrdy, PHYCTRL_IS_DLLRDY(dllrdy),
+1, 50 * USEC_PER_MSEC);

It seems a bit schizophrenic that one of our delay loops sleeps 1 us
between loops and the other sleeps 5 us between loops.

...and, in fact, both of these numbers seem a little on the silly side
of things.  Assuming that the timer docs are up to date, usleep_range
is intended for sleeping "10us - 20ms".  Both 1 us and 5 us below that
range and "1 us" is an order of magnitude below that range.  ...your 1
and 5 actually translate to usleep_range(1, 1) and usleep_range(3, 5).

It seems like trying to do a sleep (the whole idea that some other
process will get to run for some fraction of the 1 us) is just wasting
cycles.

So I'd say either:

1. Accept that we really expect this to be a long delay and change
your delay to 10 us

2. Change the delay to 0 us and accept that you're busy waiting.

I'd vote for #2 unless you have some evidence that we often need long
delays and we've started calling this code all the time.


Agreed with #2


-Caesar




+ if (ret) {
+ pr_err("%s: dllrdy failed %d.\n", __func__, ret);
+ return ret;
   }

   return 0;
--
1.9.1



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v2 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

[Caesar Wang]

As we communicate through QQ, Shawn had been on vacation util next week.

在 2018年01月11日 01:46, Brian Norris 写道:

+ Caesar

IIUC, you didn't CC him? Also, he already sent a v2 of this patchset,
withi some minor difference.

On Wed, Jan 10, 2018 at 06:49:22PM +0800, Shawn Lin wrote:

Just use the API instead of open-coding it, no functional change
intended.

Signed-off-by: Shawn Lin <shawn@rock-chips.com>
Reviewed-by: Brian Norris <briannor...@chromium.org>
Tested-by: Caesar Wang <w...@rock-chips.com>
Tested-by: Ziyuan Xu <xzy...@rock-chips.com>
---

Changes in v2:
- propagate the error and print it
- avoid using busy wait

  drivers/phy/rockchip/phy-rockchip-emmc.c | 32 +---
  1 file changed, 13 insertions(+), 19 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index 547b746..e54e78f 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -79,6 +79,9 @@
  #define PHYCTRL_IS_CALDONE(x) \
x) >> PHYCTRL_CALDONE_SHIFT) & \
  PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+#define PHYCTRL_IS_DLLRDY(x) \
+   x) >> PHYCTRL_DLLRDY_SHIFT) & \
+ PHYCTRL_DLLRDY_MASK) == PHYCTRL_DLLRDY_DONE)
  
  struct rockchip_emmc_phy {

unsigned intreg_offset;
@@ -93,7 +96,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int dllrdy;
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
-   unsigned long timeout;
int ret;
  
  	/*

@@ -217,28 +219,20 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)

I'd probably like Doug's comment on the comment rewording (and
functional change) since he wrote them in the first place, but this is
also where you and Caesar differed. Caesar just deleted most of the last
paragraph, because it really applied just to the busy wait loop, not
really to the sleep-based loop that you're putting in here.


 * NOTE: There appear to be corner cases where the DLL seems to take
 * extra long to lock for reasons that aren't understood.  In some
 * extreme cases we've seen it take up to over 10ms (!).  We'll be
-* generous and give it 50ms.  We still busy wait here because:
+* generous and give it 50ms.  We still wait here because:
 * - In most cases it should be super fast.
 * - This is not called lots during normal operation so it shouldn't
-*   be a power or performance problem to busy wait.  We expect it
+*   be a power or performance problem to wait.  We expect it

Why would it be a power problem to just "wait"? (Hint: it was only a
potential power problem to *busy* wait, where we're spinning in a tight
loop.)


 *   only at boot / resume.  In both cases, eMMC is probably on the
-*   critical path so busy waiting a little extra time should be OK.
+*   critical path so waiting a little extra time should be OK.

If we all agree that the above *performance* reasoning is not important,
then it should be fine to do the conversion to the sleep/polling macro,
and I think the best comment is just to delete all the above about power
and performance of this wait loop. It was only necessary to justify the
udelay() loop.


Just confirmed with Shawn, we can delete the above isn't important reason.



So IOW, I think Caesar's version was better :)

Otherwise, my 'Reviewed-by' for both series stands.

Doug, do you have any thoughts? Or at least Caesar and Shawn: please
choose one of your patch series, not both!

Brian


 */
-   timeout = jiffies + msecs_to_jiffies(50);
-   do {
-   udelay(1);
-
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
-   if (dllrdy == PHYCTRL_DLLRDY_DONE)
-   break;
-   } while (!time_after(jiffies, timeout));
-
-   if (dllrdy != PHYCTRL_DLLRDY_DONE) {
-   pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  dllrdy, PHYCTRL_IS_DLLRDY(dllrdy),
+  1, 50 * USEC_PER_MSEC);
+   if (ret) {
+   pr_err("%s: dllrdy failed %d.\n", __func__, ret);
+   return ret;
}
  
  	return 0;

--
1.9.1



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v2 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

[Caesar Wang]

As we communicate through QQ, Shawn had been on vacation util next week.

在 2018年01月11日 01:46, Brian Norris 写道:

+ Caesar

IIUC, you didn't CC him? Also, he already sent a v2 of this patchset,
withi some minor difference.

On Wed, Jan 10, 2018 at 06:49:22PM +0800, Shawn Lin wrote:

Just use the API instead of open-coding it, no functional change
intended.

Signed-off-by: Shawn Lin 
Reviewed-by: Brian Norris 
Tested-by: Caesar Wang 
Tested-by: Ziyuan Xu 
---

Changes in v2:
- propagate the error and print it
- avoid using busy wait

  drivers/phy/rockchip/phy-rockchip-emmc.c | 32 +---
  1 file changed, 13 insertions(+), 19 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index 547b746..e54e78f 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -79,6 +79,9 @@
  #define PHYCTRL_IS_CALDONE(x) \
x) >> PHYCTRL_CALDONE_SHIFT) & \
  PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+#define PHYCTRL_IS_DLLRDY(x) \
+   x) >> PHYCTRL_DLLRDY_SHIFT) & \
+ PHYCTRL_DLLRDY_MASK) == PHYCTRL_DLLRDY_DONE)
  
  struct rockchip_emmc_phy {

unsigned intreg_offset;
@@ -93,7 +96,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int dllrdy;
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
-   unsigned long timeout;
int ret;
  
  	/*

@@ -217,28 +219,20 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)

I'd probably like Doug's comment on the comment rewording (and
functional change) since he wrote them in the first place, but this is
also where you and Caesar differed. Caesar just deleted most of the last
paragraph, because it really applied just to the busy wait loop, not
really to the sleep-based loop that you're putting in here.


 * NOTE: There appear to be corner cases where the DLL seems to take
 * extra long to lock for reasons that aren't understood.  In some
 * extreme cases we've seen it take up to over 10ms (!).  We'll be
-* generous and give it 50ms.  We still busy wait here because:
+* generous and give it 50ms.  We still wait here because:
 * - In most cases it should be super fast.
 * - This is not called lots during normal operation so it shouldn't
-*   be a power or performance problem to busy wait.  We expect it
+*   be a power or performance problem to wait.  We expect it

Why would it be a power problem to just "wait"? (Hint: it was only a
potential power problem to *busy* wait, where we're spinning in a tight
loop.)


 *   only at boot / resume.  In both cases, eMMC is probably on the
-*   critical path so busy waiting a little extra time should be OK.
+*   critical path so waiting a little extra time should be OK.

If we all agree that the above *performance* reasoning is not important,
then it should be fine to do the conversion to the sleep/polling macro,
and I think the best comment is just to delete all the above about power
and performance of this wait loop. It was only necessary to justify the
udelay() loop.


Just confirmed with Shawn, we can delete the above isn't important reason.



So IOW, I think Caesar's version was better :)

Otherwise, my 'Reviewed-by' for both series stands.

Doug, do you have any thoughts? Or at least Caesar and Shawn: please
choose one of your patch series, not both!

Brian


 */
-   timeout = jiffies + msecs_to_jiffies(50);
-   do {
-   udelay(1);
-
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
-   if (dllrdy == PHYCTRL_DLLRDY_DONE)
-   break;
-   } while (!time_after(jiffies, timeout));
-
-   if (dllrdy != PHYCTRL_DLLRDY_DONE) {
-   pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  dllrdy, PHYCTRL_IS_DLLRDY(dllrdy),
+  1, 50 * USEC_PER_MSEC);
+   if (ret) {
+   pr_err("%s: dllrdy failed %d.\n", __func__, ret);
+   return ret;
}
  
  	return 0;

--
1.9.1



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH v2 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

[Caesar Wang]

From: Shawn Lin <shawn@rock-chips.com>

Just use the API instead of open-coding it, no functional change
intended.

Signed-off-by: Shawn Lin <shawn@rock-chips.com>
Reviewed-by: Brian Norris <briannor...@chromium.org>
Signed-off-by: Caesar Wang <w...@rock-chips.com>

---

Changes in v2:
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
  changed the note and added to print error value with
  regmap_read_poll_timeout API.

 drivers/phy/rockchip/phy-rockchip-emmc.c | 33 +++-
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index 574838f..343c623 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -79,6 +79,9 @@
 #define PHYCTRL_IS_CALDONE(x) \
x) >> PHYCTRL_CALDONE_SHIFT) & \
  PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+#define PHYCTRL_IS_DLLRDY(x) \
+   x) >> PHYCTRL_DLLRDY_SHIFT) & \
+ PHYCTRL_DLLRDY_MASK) == PHYCTRL_DLLRDY_DONE)
 
 struct rockchip_emmc_phy {
unsigned intreg_offset;
@@ -93,7 +96,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int dllrdy;
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
-   unsigned long timeout;
int ret;
 
/*
@@ -217,28 +219,15 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
 * NOTE: There appear to be corner cases where the DLL seems to take
 * extra long to lock for reasons that aren't understood.  In some
 * extreme cases we've seen it take up to over 10ms (!).  We'll be
-* generous and give it 50ms.  We still busy wait here because:
-* - In most cases it should be super fast.
-* - This is not called lots during normal operation so it shouldn't
-*   be a power or performance problem to busy wait.  We expect it
-*   only at boot / resume.  In both cases, eMMC is probably on the
-*   critical path so busy waiting a little extra time should be OK.
+* generous and give it 50ms.
 */
-   timeout = jiffies + msecs_to_jiffies(50);
-   do {
-   udelay(1);
-
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
-   if (dllrdy == PHYCTRL_DLLRDY_DONE)
-   break;
-   } while (!time_after(jiffies, timeout));
-
-   if (dllrdy != PHYCTRL_DLLRDY_DONE) {
-   pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  dllrdy, PHYCTRL_IS_DLLRDY(dllrdy),
+  1, 50 * USEC_PER_MSEC);
+   if (ret) {
+   pr_err("%s: dllrdy timeout. ret=%d\n", __func__, ret);
+   return ret;
}
 
return 0;
-- 
2.7.4

[PATCH v2 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

[Caesar Wang]

From: Shawn Lin 

Just use the API instead of open-coding it, no functional change
intended.

Signed-off-by: Shawn Lin 
Reviewed-by: Brian Norris 
Signed-off-by: Caesar Wang 

---

Changes in v2:
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
  changed the note and added to print error value with
  regmap_read_poll_timeout API.

 drivers/phy/rockchip/phy-rockchip-emmc.c | 33 +++-
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index 574838f..343c623 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -79,6 +79,9 @@
 #define PHYCTRL_IS_CALDONE(x) \
x) >> PHYCTRL_CALDONE_SHIFT) & \
  PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+#define PHYCTRL_IS_DLLRDY(x) \
+   x) >> PHYCTRL_DLLRDY_SHIFT) & \
+ PHYCTRL_DLLRDY_MASK) == PHYCTRL_DLLRDY_DONE)
 
 struct rockchip_emmc_phy {
unsigned intreg_offset;
@@ -93,7 +96,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int dllrdy;
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
-   unsigned long timeout;
int ret;
 
/*
@@ -217,28 +219,15 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
 * NOTE: There appear to be corner cases where the DLL seems to take
 * extra long to lock for reasons that aren't understood.  In some
 * extreme cases we've seen it take up to over 10ms (!).  We'll be
-* generous and give it 50ms.  We still busy wait here because:
-* - In most cases it should be super fast.
-* - This is not called lots during normal operation so it shouldn't
-*   be a power or performance problem to busy wait.  We expect it
-*   only at boot / resume.  In both cases, eMMC is probably on the
-*   critical path so busy waiting a little extra time should be OK.
+* generous and give it 50ms.
 */
-   timeout = jiffies + msecs_to_jiffies(50);
-   do {
-   udelay(1);
-
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
-   if (dllrdy == PHYCTRL_DLLRDY_DONE)
-   break;
-   } while (!time_after(jiffies, timeout));
-
-   if (dllrdy != PHYCTRL_DLLRDY_DONE) {
-   pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  dllrdy, PHYCTRL_IS_DLLRDY(dllrdy),
+  1, 50 * USEC_PER_MSEC);
+   if (ret) {
+   pr_err("%s: dllrdy timeout. ret=%d\n", __func__, ret);
+   return ret;
}
 
return 0;
-- 
2.7.4

[PATCH v2 0/2] phy: rockchip-emmc: fixes emmc-phy power on failed with rk3399 SoCs

[Caesar Wang]

Hi Kishon,

Since the Shawn isn't available, I take over this series patches for now.

As the original bug had tracked on https://issuetracker.google.com/71561742.
In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[   2.375333] rockchip_emmc_phy_power: caldone timeout.
[2.377815] phy phy-ff77.syscon:phy@f780.4: phy poweron failed --> -110
...
[2.489295] mmc0: mmc_select_hs400es failed, error -110
[2.489302] mmc0: error -110 whilst initialising MMC card
..

The actual emulate, the wait 5us for calpad busy trimming, that's no enough.
We need give the enough margin for it.

Verified on url =

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4
This series patches can apply and bring up with kernel-next on rk3399 
chromebook.

-Caesar


Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
  changed the note and added to print error value with
  regmap_read_poll_timeout API.

Shawn Lin (2):
  phy: rockchip-emmc: retry calpad busy trimming
  phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

 drivers/phy/rockchip/phy-rockchip-emmc.c | 60 +++-
 1 file changed, 28 insertions(+), 32 deletions(-)

-- 
2.7.4

[PATCH v2 0/2] phy: rockchip-emmc: fixes emmc-phy power on failed with rk3399 SoCs

[Caesar Wang]

Hi Kishon,

Since the Shawn isn't available, I take over this series patches for now.

As the original bug had tracked on https://issuetracker.google.com/71561742.
In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[   2.375333] rockchip_emmc_phy_power: caldone timeout.
[2.377815] phy phy-ff77.syscon:phy@f780.4: phy poweron failed --> -110
...
[2.489295] mmc0: mmc_select_hs400es failed, error -110
[2.489302] mmc0: error -110 whilst initialising MMC card
..

The actual emulate, the wait 5us for calpad busy trimming, that's no enough.
We need give the enough margin for it.

Verified on url =

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4
This series patches can apply and bring up with kernel-next on rk3399 
chromebook.

-Caesar


Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
  changed the note and added to print error value with
  regmap_read_poll_timeout API.

Shawn Lin (2):
  phy: rockchip-emmc: retry calpad busy trimming
  phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy

 drivers/phy/rockchip/phy-rockchip-emmc.c | 60 +++-
 1 file changed, 28 insertions(+), 32 deletions(-)

-- 
2.7.4

[PATCH v2 1/2] phy: rockchip-emmc: retry calpad busy trimming

[Caesar Wang]

From: Shawn Lin <shawn@rock-chips.com>

It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.

Signed-off-by: Shawn Lin <shawn@rock-chips.com>
Tested-by: Ziyuan Xu <xzy...@rock-chips.com>
Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.

 drivers/phy/rockchip/phy-rockchip-emmc.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index f1b24f1..574838f 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -76,6 +76,10 @@
 #define PHYCTRL_OTAPDLYSEL_MASK0xf
 #define PHYCTRL_OTAPDLYSEL_SHIFT   0x7
 
+#define PHYCTRL_IS_CALDONE(x) \
+   x) >> PHYCTRL_CALDONE_SHIFT) & \
+ PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+
 struct rockchip_emmc_phy {
unsigned intreg_offset;
struct regmap   *reg_base;
@@ -90,6 +94,7 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
unsigned long timeout;
+   int ret;
 
/*
 * Keep phyctrl_pdb and phyctrl_endll low to allow
@@ -160,17 +165,19 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
   PHYCTRL_PDB_SHIFT));
 
/*
-* According to the user manual, it asks driver to
-* wait 5us for calpad busy trimming
+* According to the user manual, it asks driver to wait 5us for
+* calpad busy trimming. However it is documented that this value is
+* PVT(A.K.A process,voltage and temperature) relevant, so some
+* failure cases are found which indicates we should be more tolerant
+* to calpad busy trimming.
 */
-   udelay(5);
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
-   if (caldone != PHYCTRL_CALDONE_DONE) {
-   pr_err("rockchip_emmc_phy_power: caldone timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  caldone, PHYCTRL_IS_CALDONE(caldone),
+  5, 50);
+   if (ret) {
+   pr_err("%s: caldone timeout, ret=%d\n", __func__, ret);
+   return ret;
}
 
/* Set the frequency of the DLL operation */
-- 
2.7.4

[PATCH v2 1/2] phy: rockchip-emmc: retry calpad busy trimming

[Caesar Wang]

From: Shawn Lin 

It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.

Signed-off-by: Shawn Lin 
Tested-by: Ziyuan Xu 
Signed-off-by: Caesar Wang 
---

Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.

 drivers/phy/rockchip/phy-rockchip-emmc.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index f1b24f1..574838f 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -76,6 +76,10 @@
 #define PHYCTRL_OTAPDLYSEL_MASK0xf
 #define PHYCTRL_OTAPDLYSEL_SHIFT   0x7
 
+#define PHYCTRL_IS_CALDONE(x) \
+   x) >> PHYCTRL_CALDONE_SHIFT) & \
+ PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+
 struct rockchip_emmc_phy {
unsigned intreg_offset;
struct regmap   *reg_base;
@@ -90,6 +94,7 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
unsigned int freqsel = PHYCTRL_FREQSEL_200M;
unsigned long rate;
unsigned long timeout;
+   int ret;
 
/*
 * Keep phyctrl_pdb and phyctrl_endll low to allow
@@ -160,17 +165,19 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
   PHYCTRL_PDB_SHIFT));
 
/*
-* According to the user manual, it asks driver to
-* wait 5us for calpad busy trimming
+* According to the user manual, it asks driver to wait 5us for
+* calpad busy trimming. However it is documented that this value is
+* PVT(A.K.A process,voltage and temperature) relevant, so some
+* failure cases are found which indicates we should be more tolerant
+* to calpad busy trimming.
 */
-   udelay(5);
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
-   if (caldone != PHYCTRL_CALDONE_DONE) {
-   pr_err("rockchip_emmc_phy_power: caldone timeout.\n");
-   return -ETIMEDOUT;
+   ret = regmap_read_poll_timeout(rk_phy->reg_base,
+  rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+  caldone, PHYCTRL_IS_CALDONE(caldone),
+  5, 50);
+   if (ret) {
+   pr_err("%s: caldone timeout, ret=%d\n", __func__, ret);
+   return ret;
}
 
/* Set the frequency of the DLL operation */
-- 
2.7.4

Re: [PATCH 1/2] phy: rockchip-emmc: retry calpad busy trimming

[Caesar Wang]

Hi Kishon & Shawn,

As the bug had tracked on https://issuetracker.google.com/71561742.

In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[   2.375333] rockchip_emmc_phy_power: caldone timeout.
[    2.377815] phy phy-ff77.syscon:phy@f780.4: phy poweron failed 
--> -110

...
[    2.489295] mmc0: mmc_select_hs400es failed, error -110
[    2.489302] mmc0: error -110 whilst initialising MMC card
..


在 2018年01月02日 10:21, Shawn Lin 写道:

It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.

Signed-off-by: Shawn Lin <shawn@rock-chips.com>


Tested-by: Caesar Wang <w...@rock-chips.com>

I had tested on rk3399 chromebook, so feel free to add my tag.

-Caesar

---

  drivers/phy/rockchip/phy-rockchip-emmc.c | 21 +
  1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index f1b24f1..512a6ef 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -76,6 +76,10 @@
  #define PHYCTRL_OTAPDLYSEL_MASK   0xf
  #define PHYCTRL_OTAPDLYSEL_SHIFT  0x7
  
+#define PHYCTRL_IS_CALDONE(x) \

+   x) >> PHYCTRL_CALDONE_SHIFT) & \
+ PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+
  struct rockchip_emmc_phy {
unsigned intreg_offset;
struct regmap   *reg_base;
@@ -160,15 +164,16 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
   PHYCTRL_PDB_SHIFT));
  
  	/*

-* According to the user manual, it asks driver to
-* wait 5us for calpad busy trimming
+* According to the user manual, it asks driver to wait 5us for
+* calpad busy trimming. However it is documented that this value is
+* PVT(A.K.A process,voltage and temperature) relevant, so some
+* failure cases are found which indicates we should be more tolerant
+* to calpad busy trimming.
 */
-   udelay(5);
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
-   if (caldone != PHYCTRL_CALDONE_DONE) {
+   if (regmap_read_poll_timeout(rk_phy->reg_base,
+rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+caldone, PHYCTRL_IS_CALDONE(caldone),
+5, 50)) {
pr_err("rockchip_emmc_phy_power: caldone timeout.\n");
return -ETIMEDOUT;
}

Re: [PATCH 1/2] phy: rockchip-emmc: retry calpad busy trimming

[Caesar Wang]

Hi Kishon & Shawn,

As the bug had tracked on https://issuetracker.google.com/71561742.

In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[   2.375333] rockchip_emmc_phy_power: caldone timeout.
[    2.377815] phy phy-ff77.syscon:phy@f780.4: phy poweron failed 
--> -110

...
[    2.489295] mmc0: mmc_select_hs400es failed, error -110
[    2.489302] mmc0: error -110 whilst initialising MMC card
..


在 2018年01月02日 10:21, Shawn Lin 写道:

It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.

Signed-off-by: Shawn Lin 


Tested-by: Caesar Wang 

I had tested on rk3399 chromebook, so feel free to add my tag.

-Caesar

---

  drivers/phy/rockchip/phy-rockchip-emmc.c | 21 +
  1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c 
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index f1b24f1..512a6ef 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -76,6 +76,10 @@
  #define PHYCTRL_OTAPDLYSEL_MASK   0xf
  #define PHYCTRL_OTAPDLYSEL_SHIFT  0x7
  
+#define PHYCTRL_IS_CALDONE(x) \

+   x) >> PHYCTRL_CALDONE_SHIFT) & \
+ PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
+
  struct rockchip_emmc_phy {
unsigned intreg_offset;
struct regmap   *reg_base;
@@ -160,15 +164,16 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool 
on_off)
   PHYCTRL_PDB_SHIFT));
  
  	/*

-* According to the user manual, it asks driver to
-* wait 5us for calpad busy trimming
+* According to the user manual, it asks driver to wait 5us for
+* calpad busy trimming. However it is documented that this value is
+* PVT(A.K.A process,voltage and temperature) relevant, so some
+* failure cases are found which indicates we should be more tolerant
+* to calpad busy trimming.
 */
-   udelay(5);
-   regmap_read(rk_phy->reg_base,
-   rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
-   );
-   caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
-   if (caldone != PHYCTRL_CALDONE_DONE) {
+   if (regmap_read_poll_timeout(rk_phy->reg_base,
+rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
+caldone, PHYCTRL_IS_CALDONE(caldone),
+5, 50)) {
pr_err("rockchip_emmc_phy_power: caldone timeout.\n");
return -ETIMEDOUT;
}

Re: [PATCH 2/5] thermal: rockchip: Support the RV1108 SoC in thermal driver

[Caesar Wang]

在 2017年09月15日 10:10, Caesar Wang 写道:

Hi Rocky,

在 2017年08月24日 18:27, Rocky Hao 写道:

RV1108 SOC has one Temperature Sensor for CPU.

Signed-off-by: Rocky Hao <rocky@rock-chips.com>


Reviewed-by: Caesar Wang <w...@rock-chips.com>


---
  drivers/thermal/rockchip_thermal.c | 67 
++

  1 file changed, 67 insertions(+)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c

index 9da3e1819210..299a8ade71fa 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -242,6 +242,45 @@ struct tsadc_table {
  int temp;
  };
  +static const struct tsadc_table rv1108_table[] = {
+{0, -4},
+{374, -4},
+{382, -35000},
+{389, -3},
+{397, -25000},
+{405, -2},
+{413, -15000},
+{421, -1},
+{429, -5000},
+{436, 0},
+{444, 5000},
+{452, 1},
+{460, 15000},
+{468, 2},
+{476, 25000},
+{483, 3},
+{491, 35000},
+{499, 4},
+{507, 45000},
+{515, 5},
+{523, 55000},
+{531, 6},
+{539, 65000},
+{547, 7},
+{555, 75000},
+{562, 8},
+{570, 85000},
+{578, 9},
+{586, 95000},
+{594, 10},
+{602, 105000},
+{610, 11},
+{618, 115000},
+{626, 12},
+{634, 125000},
+{TSADCV2_DATA_MASK, 125000},
+};
+


From the RV1108 TRM said,  this table was used for  the negative 
temperature coefficient.

But the default table is positive temperature coefficient, why?
I think you don't need to use the negative temperature coefficient.


Sorry,  the RV1108 TRM document is old on my hand,  from the lastest 
document Rockchip RV1108 TRM V1.0 Part1-20170505.pdf said,
The RV1108 is negative temprature coefficient, so please set this bit as 
1'b1 :(





  static const struct tsadc_table rk3228_code_table[] = {
  {0, -4},
  {588, -4},
@@ -779,6 +818,30 @@ static void rk_tsadcv2_tshut_mode(int chn, void 
__iomem *regs,

  writel_relaxed(val, regs + TSADCV2_INT_EN);
  }
  +static const struct rockchip_tsadc_chip rv1108_tsadc_data = {
+.chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+.chn_num = 1, /* one channel for tsadc */
+
+.tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give 
PMIC */

+.tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
+.tshut_temp = 95000,
+
+.initialize = rk_tsadcv2_initialize,
+.irq_ack = rk_tsadcv3_irq_ack,
+.control = rk_tsadcv3_control,


If you will use the positive temperature coefficient, we need change it.

.control = rk_tsadcv2_control,




+.get_temp = rk_tsadcv2_get_temp,
+.set_alarm_temp = rk_tsadcv2_alarm_temp,
+.set_tshut_temp = rk_tsadcv2_tshut_temp,
+.set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+.table = {
+.id = rv1108_table,
+.length = ARRAY_SIZE(rv1108_table),
+.data_mask = TSADCV2_DATA_MASK,
+.mode = ADC_INCREMENT,


Ditto

-Caesar



+},
+};
+
  static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
  .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
  .chn_num = 1, /* one channel for tsadc */
@@ -928,6 +991,10 @@ static void rk_tsadcv2_tshut_mode(int chn, void 
__iomem *regs,

static const struct of_device_id of_rockchip_thermal_match[] = {
  {
+.compatible = "rockchip,rv1108-tsadc",
+.data = (void *)_tsadc_data,
+},
+{
  .compatible = "rockchip,rk3228-tsadc",
  .data = (void *)_tsadc_data,
  },




___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 2/5] thermal: rockchip: Support the RV1108 SoC in thermal driver

[Caesar Wang]

在 2017年09月15日 10:10, Caesar Wang 写道:

Hi Rocky,

在 2017年08月24日 18:27, Rocky Hao 写道:

RV1108 SOC has one Temperature Sensor for CPU.

Signed-off-by: Rocky Hao 


Reviewed-by: Caesar Wang 


---
  drivers/thermal/rockchip_thermal.c | 67 
++

  1 file changed, 67 insertions(+)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c

index 9da3e1819210..299a8ade71fa 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -242,6 +242,45 @@ struct tsadc_table {
  int temp;
  };
  +static const struct tsadc_table rv1108_table[] = {
+{0, -4},
+{374, -4},
+{382, -35000},
+{389, -3},
+{397, -25000},
+{405, -2},
+{413, -15000},
+{421, -1},
+{429, -5000},
+{436, 0},
+{444, 5000},
+{452, 1},
+{460, 15000},
+{468, 2},
+{476, 25000},
+{483, 3},
+{491, 35000},
+{499, 4},
+{507, 45000},
+{515, 5},
+{523, 55000},
+{531, 6},
+{539, 65000},
+{547, 7},
+{555, 75000},
+{562, 8},
+{570, 85000},
+{578, 9},
+{586, 95000},
+{594, 10},
+{602, 105000},
+{610, 11},
+{618, 115000},
+{626, 12},
+{634, 125000},
+{TSADCV2_DATA_MASK, 125000},
+};
+


From the RV1108 TRM said,  this table was used for  the negative 
temperature coefficient.

But the default table is positive temperature coefficient, why?
I think you don't need to use the negative temperature coefficient.


Sorry,  the RV1108 TRM document is old on my hand,  from the lastest 
document Rockchip RV1108 TRM V1.0 Part1-20170505.pdf said,
The RV1108 is negative temprature coefficient, so please set this bit as 
1'b1 :(





  static const struct tsadc_table rk3228_code_table[] = {
  {0, -4},
  {588, -4},
@@ -779,6 +818,30 @@ static void rk_tsadcv2_tshut_mode(int chn, void 
__iomem *regs,

  writel_relaxed(val, regs + TSADCV2_INT_EN);
  }
  +static const struct rockchip_tsadc_chip rv1108_tsadc_data = {
+.chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+.chn_num = 1, /* one channel for tsadc */
+
+.tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give 
PMIC */

+.tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
+.tshut_temp = 95000,
+
+.initialize = rk_tsadcv2_initialize,
+.irq_ack = rk_tsadcv3_irq_ack,
+.control = rk_tsadcv3_control,


If you will use the positive temperature coefficient, we need change it.

.control = rk_tsadcv2_control,




+.get_temp = rk_tsadcv2_get_temp,
+.set_alarm_temp = rk_tsadcv2_alarm_temp,
+.set_tshut_temp = rk_tsadcv2_tshut_temp,
+.set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+.table = {
+.id = rv1108_table,
+.length = ARRAY_SIZE(rv1108_table),
+.data_mask = TSADCV2_DATA_MASK,
+.mode = ADC_INCREMENT,


Ditto

-Caesar



+},
+};
+
  static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
  .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
  .chn_num = 1, /* one channel for tsadc */
@@ -928,6 +991,10 @@ static void rk_tsadcv2_tshut_mode(int chn, void 
__iomem *regs,

static const struct of_device_id of_rockchip_thermal_match[] = {
  {
+.compatible = "rockchip,rv1108-tsadc",
+.data = (void *)_tsadc_data,
+},
+{
  .compatible = "rockchip,rk3228-tsadc",
  .data = (void *)_tsadc_data,
  },




___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 2/5] thermal: rockchip: Support the RV1108 SoC in thermal driver

[Caesar Wang]

Hi Rocky,

在 2017年08月24日 18:27, Rocky Hao 写道:

RV1108 SOC has one Temperature Sensor for CPU.

Signed-off-by: Rocky Hao 
---
  drivers/thermal/rockchip_thermal.c | 67 ++
  1 file changed, 67 insertions(+)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 9da3e1819210..299a8ade71fa 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -242,6 +242,45 @@ struct tsadc_table {
int temp;
  };
  
+static const struct tsadc_table rv1108_table[] = {

+   {0, -4},
+   {374, -4},
+   {382, -35000},
+   {389, -3},
+   {397, -25000},
+   {405, -2},
+   {413, -15000},
+   {421, -1},
+   {429, -5000},
+   {436, 0},
+   {444, 5000},
+   {452, 1},
+   {460, 15000},
+   {468, 2},
+   {476, 25000},
+   {483, 3},
+   {491, 35000},
+   {499, 4},
+   {507, 45000},
+   {515, 5},
+   {523, 55000},
+   {531, 6},
+   {539, 65000},
+   {547, 7},
+   {555, 75000},
+   {562, 8},
+   {570, 85000},
+   {578, 9},
+   {586, 95000},
+   {594, 10},
+   {602, 105000},
+   {610, 11},
+   {618, 115000},
+   {626, 12},
+   {634, 125000},
+   {TSADCV2_DATA_MASK, 125000},
+};
+


From the RV1108 TRM said,  this table was used for  the negative 
temperature coefficient.

But the default table is positive temperature coefficient, why?
I think you don't need to use the negative temperature coefficient.


  static const struct tsadc_table rk3228_code_table[] = {
{0, -4},
{588, -4},
@@ -779,6 +818,30 @@ static void rk_tsadcv2_tshut_mode(int chn, void __iomem 
*regs,
writel_relaxed(val, regs + TSADCV2_INT_EN);
  }
  
+static const struct rockchip_tsadc_chip rv1108_tsadc_data = {

+   .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+   .chn_num = 1, /* one channel for tsadc */
+
+   .tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give PMIC */
+   .tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
+   .tshut_temp = 95000,
+
+   .initialize = rk_tsadcv2_initialize,
+   .irq_ack = rk_tsadcv3_irq_ack,
+   .control = rk_tsadcv3_control,


If you will use the positive temperature coefficient, we need change it.

.control = rk_tsadcv2_control,




+   .get_temp = rk_tsadcv2_get_temp,
+   .set_alarm_temp = rk_tsadcv2_alarm_temp,
+   .set_tshut_temp = rk_tsadcv2_tshut_temp,
+   .set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+   .table = {
+   .id = rv1108_table,
+   .length = ARRAY_SIZE(rv1108_table),
+   .data_mask = TSADCV2_DATA_MASK,
+   .mode = ADC_INCREMENT,


Ditto

-Caesar



+   },
+};
+
  static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
.chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
.chn_num = 1, /* one channel for tsadc */
@@ -928,6 +991,10 @@ static void rk_tsadcv2_tshut_mode(int chn, void __iomem 
*regs,
  
  static const struct of_device_id of_rockchip_thermal_match[] = {

{
+   .compatible = "rockchip,rv1108-tsadc",
+   .data = (void *)_tsadc_data,
+   },
+   {
.compatible = "rockchip,rk3228-tsadc",
.data = (void *)_tsadc_data,
},

Re: [PATCH 2/5] thermal: rockchip: Support the RV1108 SoC in thermal driver

[Caesar Wang]

Hi Rocky,

在 2017年08月24日 18:27, Rocky Hao 写道:

RV1108 SOC has one Temperature Sensor for CPU.

Signed-off-by: Rocky Hao 
---
  drivers/thermal/rockchip_thermal.c | 67 ++
  1 file changed, 67 insertions(+)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 9da3e1819210..299a8ade71fa 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -242,6 +242,45 @@ struct tsadc_table {
int temp;
  };
  
+static const struct tsadc_table rv1108_table[] = {

+   {0, -4},
+   {374, -4},
+   {382, -35000},
+   {389, -3},
+   {397, -25000},
+   {405, -2},
+   {413, -15000},
+   {421, -1},
+   {429, -5000},
+   {436, 0},
+   {444, 5000},
+   {452, 1},
+   {460, 15000},
+   {468, 2},
+   {476, 25000},
+   {483, 3},
+   {491, 35000},
+   {499, 4},
+   {507, 45000},
+   {515, 5},
+   {523, 55000},
+   {531, 6},
+   {539, 65000},
+   {547, 7},
+   {555, 75000},
+   {562, 8},
+   {570, 85000},
+   {578, 9},
+   {586, 95000},
+   {594, 10},
+   {602, 105000},
+   {610, 11},
+   {618, 115000},
+   {626, 12},
+   {634, 125000},
+   {TSADCV2_DATA_MASK, 125000},
+};
+


From the RV1108 TRM said,  this table was used for  the negative 
temperature coefficient.

But the default table is positive temperature coefficient, why?
I think you don't need to use the negative temperature coefficient.


  static const struct tsadc_table rk3228_code_table[] = {
{0, -4},
{588, -4},
@@ -779,6 +818,30 @@ static void rk_tsadcv2_tshut_mode(int chn, void __iomem 
*regs,
writel_relaxed(val, regs + TSADCV2_INT_EN);
  }
  
+static const struct rockchip_tsadc_chip rv1108_tsadc_data = {

+   .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+   .chn_num = 1, /* one channel for tsadc */
+
+   .tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give PMIC */
+   .tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
+   .tshut_temp = 95000,
+
+   .initialize = rk_tsadcv2_initialize,
+   .irq_ack = rk_tsadcv3_irq_ack,
+   .control = rk_tsadcv3_control,


If you will use the positive temperature coefficient, we need change it.

.control = rk_tsadcv2_control,




+   .get_temp = rk_tsadcv2_get_temp,
+   .set_alarm_temp = rk_tsadcv2_alarm_temp,
+   .set_tshut_temp = rk_tsadcv2_tshut_temp,
+   .set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+   .table = {
+   .id = rv1108_table,
+   .length = ARRAY_SIZE(rv1108_table),
+   .data_mask = TSADCV2_DATA_MASK,
+   .mode = ADC_INCREMENT,


Ditto

-Caesar



+   },
+};
+
  static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
.chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
.chn_num = 1, /* one channel for tsadc */
@@ -928,6 +991,10 @@ static void rk_tsadcv2_tshut_mode(int chn, void __iomem 
*regs,
  
  static const struct of_device_id of_rockchip_thermal_match[] = {

{
+   .compatible = "rockchip,rv1108-tsadc",
+   .data = (void *)_tsadc_data,
+   },
+   {
.compatible = "rockchip,rk3228-tsadc",
.data = (void *)_tsadc_data,
},

Re: [PATCH 3/5] arm: dts: rockchip: add tsadc node for RV1108 SoC

[Caesar Wang]

Rocky,

在 2017年08月24日 18:27, Rocky Hao 写道:

Add tsadc needed main information for RV1108 SoC.
75Hz is the max clock rate supported by tsadc module.

Signed-off-by: Rocky Hao 
---
  arch/arm/boot/dts/rv1108.dtsi | 29 +
  1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/rv1108.dtsi b/arch/arm/boot/dts/rv1108.dtsi
index 25fab0b80f53..dbdd8c2180e7 100644
--- a/arch/arm/boot/dts/rv1108.dtsi
+++ b/arch/arm/boot/dts/rv1108.dtsi
@@ -275,6 +275,25 @@
status = "disabled";
};
  
+	tsadc: tsadc@1037 {

+   compatible = "rockchip,rv1108-tsadc";
+   reg = <0x1037 0x100>;
+   interrupts = ;
+   assigned-clocks = < SCLK_TSADC>;
+   assigned-clock-rates = <75>;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   pinctrl-names = "init", "default", "sleep";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
+   pinctrl-2 = <_gpio>;
+   resets = < SRST_TSADC>;
+   reset-names = "tsadc-apb";
+   rockchip,hw-tshut-temp = <12>;


From the Patch[4/5], you set the critial temperature is 95 degree. I 
will suggest the Tshut temperature is 100 degree.
Think about the the peripherial devices,  the 120 degree will damage 
some chips.



+   #thermal-sensor-cells = <1>;
+   status = "disabled";
+   };
+
adc: adc@1038c000 {
compatible = "rockchip,rv1108-saradc", "rockchip,rk3399-saradc";
reg = <0x1038c000 0x100>;
@@ -642,6 +661,16 @@
};
};
  
+		tsadc {

+   otp_out: otp-out {
+   rockchip,pins = <0 RK_PB7 RK_FUNC_1 
_pull_none>;
+   };
+
+   otp_gpio: otp-gpio {
+   rockchip,pins = <0 RK_PB7 RK_FUNC_GPIO 
_pull_none>;
+   };
+   };
+
uart0 {
uart0_xfer: uart0-xfer {
rockchip,pins = <3 RK_PA6 RK_FUNC_1 
_pull_up>,

Re: [PATCH 3/5] arm: dts: rockchip: add tsadc node for RV1108 SoC

[Caesar Wang]

Rocky,

在 2017年08月24日 18:27, Rocky Hao 写道:

Add tsadc needed main information for RV1108 SoC.
75Hz is the max clock rate supported by tsadc module.

Signed-off-by: Rocky Hao 
---
  arch/arm/boot/dts/rv1108.dtsi | 29 +
  1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/rv1108.dtsi b/arch/arm/boot/dts/rv1108.dtsi
index 25fab0b80f53..dbdd8c2180e7 100644
--- a/arch/arm/boot/dts/rv1108.dtsi
+++ b/arch/arm/boot/dts/rv1108.dtsi
@@ -275,6 +275,25 @@
status = "disabled";
};
  
+	tsadc: tsadc@1037 {

+   compatible = "rockchip,rv1108-tsadc";
+   reg = <0x1037 0x100>;
+   interrupts = ;
+   assigned-clocks = < SCLK_TSADC>;
+   assigned-clock-rates = <75>;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   pinctrl-names = "init", "default", "sleep";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
+   pinctrl-2 = <_gpio>;
+   resets = < SRST_TSADC>;
+   reset-names = "tsadc-apb";
+   rockchip,hw-tshut-temp = <12>;


From the Patch[4/5], you set the critial temperature is 95 degree. I 
will suggest the Tshut temperature is 100 degree.
Think about the the peripherial devices,  the 120 degree will damage 
some chips.



+   #thermal-sensor-cells = <1>;
+   status = "disabled";
+   };
+
adc: adc@1038c000 {
compatible = "rockchip,rv1108-saradc", "rockchip,rk3399-saradc";
reg = <0x1038c000 0x100>;
@@ -642,6 +661,16 @@
};
};
  
+		tsadc {

+   otp_out: otp-out {
+   rockchip,pins = <0 RK_PB7 RK_FUNC_1 
_pull_none>;
+   };
+
+   otp_gpio: otp-gpio {
+   rockchip,pins = <0 RK_PB7 RK_FUNC_GPIO 
_pull_none>;
+   };
+   };
+
uart0 {
uart0_xfer: uart0-xfer {
rockchip,pins = <3 RK_PA6 RK_FUNC_1 
_pull_up>,

Re: [PATCH 1/5] dt-bindings: rockchip-thermal: Support the RV1108 SoC compatible

[Caesar Wang]

Hi Rocky,

在 2017年08月24日 18:27, Rocky Hao 写道:

Add a new compatible for thermal founding on RV1108 SoCs.

Signed-off-by: Rocky Hao 
---
  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 1 +
  1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index e3a6234fb1ac..43d744e5305e 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -2,6 +2,7 @@
  
  Required properties:

  - compatible : should be "rockchip,-tsadc"
+   "rockchip,rv1108-tsadc": found on RV1108 SoCs


According to the order,  we should put the string after the 
"rockchip,rk3399-tsadc"..., not here.

 "rockchip,rk3228-tsadc": found on RK3228 SoCs
 "rockchip,rk3288-tsadc": found on RK3288 SoCs
 "rockchip,rk3328-tsadc": found on RK3328 SoCs

Re: [PATCH 1/5] dt-bindings: rockchip-thermal: Support the RV1108 SoC compatible

[Caesar Wang]

Hi Rocky,

在 2017年08月24日 18:27, Rocky Hao 写道:

Add a new compatible for thermal founding on RV1108 SoCs.

Signed-off-by: Rocky Hao 
---
  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 1 +
  1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index e3a6234fb1ac..43d744e5305e 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -2,6 +2,7 @@
  
  Required properties:

  - compatible : should be "rockchip,-tsadc"
+   "rockchip,rv1108-tsadc": found on RV1108 SoCs


According to the order,  we should put the string after the 
"rockchip,rk3399-tsadc"..., not here.

 "rockchip,rk3228-tsadc": found on RK3228 SoCs
 "rockchip,rk3288-tsadc": found on RK3288 SoCs
 "rockchip,rk3328-tsadc": found on RK3328 SoCs

Re: [PATCH v2 4/5] arm64: dts: rockchip: add thermal nodes for rk3328 SoC

[Caesar Wang]

在 2017年08月04日 16:06, Rocky Hao 写道:

add thermal zone and dynamic CPU power coefficients for rk3328

Signed-off-by: Rocky Hao 
---
Change in v2:
- remove gerrit Change-Id

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 186fb93fdffd..68829f808320 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -47,6 +47,7 @@
  #include 
  #include 
  #include 
+#include 
  
  / {

compatible = "rockchip,rk3328";
@@ -74,6 +75,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x0>;
clocks = < ARMCLK>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
};
@@ -83,6 +86,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
clocks = < ARMCLK>;
+   dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
};
@@ -92,6 +96,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
clocks = < ARMCLK>;
+   dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
};
@@ -101,6 +106,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
clocks = < ARMCLK>;
+   dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
};
@@ -308,6 +314,43 @@
interrupts = ;
};
  
+	thermal-zones {

+   soc_thermal: soc-thermal {
+   polling-delay-passive = <20>; /* milliseconds */
+   polling-delay = <1000>; /* milliseconds */
+   sustainable-power = <1000>; /* milliwatts */
+
+   thermal-sensors = < 0>;
+
+   trips {
+   threshold: trip-point0 {
+   temperature = <7>; /* millicelsius 
*/
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   target: trip-point1 {
+   temperature = <85000>; /* millicelsius 
*/
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   soc_crit: soc-crit {
+   temperature = <95000>; /* millicelsius 
*/
+   hysteresis = <2000>; /* millicelsius */


The document had already described, maybe we should remove the 
millicelsius/milliseconds/milliwatts here.

+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
+   };
+   };
+   };
+
+   };
+
tsadc: tsadc@ff25 {
compatible = "rockchip,rk3328-tsadc";
reg = <0x0 0xff25 0x0 0x100>;

Re: [PATCH v2 4/5] arm64: dts: rockchip: add thermal nodes for rk3328 SoC

[Caesar Wang]

在 2017年08月04日 16:06, Rocky Hao 写道:

add thermal zone and dynamic CPU power coefficients for rk3328

Signed-off-by: Rocky Hao 
---
Change in v2:
- remove gerrit Change-Id

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 186fb93fdffd..68829f808320 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -47,6 +47,7 @@
  #include 
  #include 
  #include 
+#include 
  
  / {

compatible = "rockchip,rk3328";
@@ -74,6 +75,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x0>;
clocks = < ARMCLK>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
};
@@ -83,6 +86,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
clocks = < ARMCLK>;
+   dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
};
@@ -92,6 +96,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
clocks = < ARMCLK>;
+   dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
};
@@ -101,6 +106,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
clocks = < ARMCLK>;
+   dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
};
@@ -308,6 +314,43 @@
interrupts = ;
};
  
+	thermal-zones {

+   soc_thermal: soc-thermal {
+   polling-delay-passive = <20>; /* milliseconds */
+   polling-delay = <1000>; /* milliseconds */
+   sustainable-power = <1000>; /* milliwatts */
+
+   thermal-sensors = < 0>;
+
+   trips {
+   threshold: trip-point0 {
+   temperature = <7>; /* millicelsius 
*/
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   target: trip-point1 {
+   temperature = <85000>; /* millicelsius 
*/
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   soc_crit: soc-crit {
+   temperature = <95000>; /* millicelsius 
*/
+   hysteresis = <2000>; /* millicelsius */


The document had already described, maybe we should remove the 
millicelsius/milliseconds/milliwatts here.

+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
+   };
+   };
+   };
+
+   };
+
tsadc: tsadc@ff25 {
compatible = "rockchip,rk3328-tsadc";
reg = <0x0 0xff25 0x0 0x100>;

Re: [PATCH v2 3/5] arm64: dts: rockchip: add tsadc node for rk3328 SoC

[Caesar Wang]

在 2017年08月04日 16:06, Rocky Hao 写道:

add tsadc needed main information for rk3328 SoC.
5Hz is the max clock rate supported by tsadc module.

Signed-off-by: Rocky Hao 
---
Change in v2:
- remove gerrit Change-Id

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index db4b2708084d..186fb93fdffd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -308,6 +308,26 @@
interrupts = ;
};
  
+	tsadc: tsadc@ff25 {

+   compatible = "rockchip,rk3328-tsadc";
+   reg = <0x0 0xff25 0x0 0x100>;
+   interrupts = ;
+   rockchip,grf = <>;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   assigned-clocks = < SCLK_TSADC>;
+   assigned-clock-rates = <5>;
+   resets = < SRST_TSADC>;
+   reset-names = "tsadc-apb";
+   pinctrl-names = "init", "default", "sleep";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
+   pinctrl-2 = <_gpio>;
+   #thermal-sensor-cells = <1>;


Only one sensor, so maybe the value should be 0.


+   rockchip,hw-tshut-temp = <10>;
+   status = "disabled";
+   };
+
saradc: adc@ff28 {
compatible = "rockchip,rk3328-saradc", "rockchip,rk3399-saradc";
reg = <0x0 0xff28 0x0 0x100>;

Re: [PATCH v2 3/5] arm64: dts: rockchip: add tsadc node for rk3328 SoC

[Caesar Wang]

在 2017年08月04日 16:06, Rocky Hao 写道:

add tsadc needed main information for rk3328 SoC.
5Hz is the max clock rate supported by tsadc module.

Signed-off-by: Rocky Hao 
---
Change in v2:
- remove gerrit Change-Id

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index db4b2708084d..186fb93fdffd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -308,6 +308,26 @@
interrupts = ;
};
  
+	tsadc: tsadc@ff25 {

+   compatible = "rockchip,rk3328-tsadc";
+   reg = <0x0 0xff25 0x0 0x100>;
+   interrupts = ;
+   rockchip,grf = <>;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   assigned-clocks = < SCLK_TSADC>;
+   assigned-clock-rates = <5>;
+   resets = < SRST_TSADC>;
+   reset-names = "tsadc-apb";
+   pinctrl-names = "init", "default", "sleep";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
+   pinctrl-2 = <_gpio>;
+   #thermal-sensor-cells = <1>;


Only one sensor, so maybe the value should be 0.


+   rockchip,hw-tshut-temp = <10>;
+   status = "disabled";
+   };
+
saradc: adc@ff28 {
compatible = "rockchip,rk3328-saradc", "rockchip,rk3399-saradc";
reg = <0x0 0xff28 0x0 0x100>;

Re: [PATCH 2/5] thermal: rockchip: Support the RK3328 SOC in thermal driver

[Caesar Wang]

在 2017年08月11日 11:02, Zhang Rui 写道:

On Tue, 2017-07-25 at 17:09 +0800, Rocky Hao wrote:

RK3328 SOC has one Temperature Sensor for CPU.

Change-Id: I176c76bae1801d815a513986cfefcb55272c69a8
Signed-off-by: Rocky Hao <rocky@rock-chips.com>

Reviewed-by: Caesar Wang <w...@rock-chips.com>


Caesar,

what do you think of this patch?


Have a look at the rk3328's TRM,  looks good to me.


-Caesar



thanks,
rui


---
  drivers/thermal/rockchip_thermal.c | 65
++
  1 file changed, 65 insertions(+)

diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index 4c7796512453..206035139110 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -320,6 +320,44 @@ struct tsadc_table {
{0, 125000},
  };
  
+static const struct tsadc_table rk3328_code_table[] = {

+   {0, -4},
+   {296, -4},
+   {304, -35000},
+   {313, -3},
+   {331, -2},
+   {340, -15000},
+   {349, -1},
+   {359, -5000},
+   {368, 0},
+   {378, 5000},
+   {388, 1},
+   {398, 15000},
+   {408, 2},
+   {418, 25000},
+   {429, 3},
+   {440, 35000},
+   {451, 4},
+   {462, 45000},
+   {473, 5},
+   {485, 55000},
+   {496, 6},
+   {508, 65000},
+   {521, 7},
+   {533, 75000},
+   {546, 8},
+   {559, 85000},
+   {572, 9},
+   {586, 95000},
+   {600, 10},
+   {614, 105000},
+   {629, 11},
+   {644, 115000},
+   {659, 12},
+   {675, 125000},
+   {TSADCV2_DATA_MASK, 125000},
+};
+
  static const struct tsadc_table rk3368_code_table[] = {
{0, -4},
{106, -4},
@@ -790,6 +828,29 @@ static void rk_tsadcv2_tshut_mode(int chn, void
__iomem *regs,
},
  };
  
+static const struct rockchip_tsadc_chip rk3328_tsadc_data = {

+   .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+   .chn_num = 1, /* one channels for tsadc */
+
+   .tshut_mode = TSHUT_MODE_CRU, /* default TSHUT via CRU */
+   .tshut_temp = 95000,
+
+   .initialize = rk_tsadcv2_initialize,
+   .irq_ack = rk_tsadcv3_irq_ack,
+   .control = rk_tsadcv3_control,
+   .get_temp = rk_tsadcv2_get_temp,
+   .set_alarm_temp = rk_tsadcv2_alarm_temp,
+   .set_tshut_temp = rk_tsadcv2_tshut_temp,
+   .set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+   .table = {
+   .id = rk3328_code_table,
+   .length = ARRAY_SIZE(rk3328_code_table),
+   .data_mask = TSADCV2_DATA_MASK,
+   .mode = ADC_INCREMENT,
+   },
+};
+
  static const struct rockchip_tsadc_chip rk3366_tsadc_data = {
.chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
.chn_id[SENSOR_GPU] = 1, /* gpu sensor is channel 1 */
@@ -875,6 +936,10 @@ static void rk_tsadcv2_tshut_mode(int chn, void
__iomem *regs,
.data = (void *)_tsadc_data,
},
{
+   .compatible = "rockchip,rk3328-tsadc",
+   .data = (void *)_tsadc_data,
+   },
+   {
.compatible = "rockchip,rk3366-tsadc",
.data = (void *)_tsadc_data,
},

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 2/5] thermal: rockchip: Support the RK3328 SOC in thermal driver

[Caesar Wang]

在 2017年08月11日 11:02, Zhang Rui 写道:

On Tue, 2017-07-25 at 17:09 +0800, Rocky Hao wrote:

RK3328 SOC has one Temperature Sensor for CPU.

Change-Id: I176c76bae1801d815a513986cfefcb55272c69a8
Signed-off-by: Rocky Hao 

Reviewed-by: Caesar Wang 


Caesar,

what do you think of this patch?


Have a look at the rk3328's TRM,  looks good to me.


-Caesar



thanks,
rui


---
  drivers/thermal/rockchip_thermal.c | 65
++
  1 file changed, 65 insertions(+)

diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index 4c7796512453..206035139110 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -320,6 +320,44 @@ struct tsadc_table {
{0, 125000},
  };
  
+static const struct tsadc_table rk3328_code_table[] = {

+   {0, -4},
+   {296, -4},
+   {304, -35000},
+   {313, -3},
+   {331, -2},
+   {340, -15000},
+   {349, -1},
+   {359, -5000},
+   {368, 0},
+   {378, 5000},
+   {388, 1},
+   {398, 15000},
+   {408, 2},
+   {418, 25000},
+   {429, 3},
+   {440, 35000},
+   {451, 4},
+   {462, 45000},
+   {473, 5},
+   {485, 55000},
+   {496, 6},
+   {508, 65000},
+   {521, 7},
+   {533, 75000},
+   {546, 8},
+   {559, 85000},
+   {572, 9},
+   {586, 95000},
+   {600, 10},
+   {614, 105000},
+   {629, 11},
+   {644, 115000},
+   {659, 12},
+   {675, 125000},
+   {TSADCV2_DATA_MASK, 125000},
+};
+
  static const struct tsadc_table rk3368_code_table[] = {
{0, -4},
{106, -4},
@@ -790,6 +828,29 @@ static void rk_tsadcv2_tshut_mode(int chn, void
__iomem *regs,
},
  };
  
+static const struct rockchip_tsadc_chip rk3328_tsadc_data = {

+   .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+   .chn_num = 1, /* one channels for tsadc */
+
+   .tshut_mode = TSHUT_MODE_CRU, /* default TSHUT via CRU */
+   .tshut_temp = 95000,
+
+   .initialize = rk_tsadcv2_initialize,
+   .irq_ack = rk_tsadcv3_irq_ack,
+   .control = rk_tsadcv3_control,
+   .get_temp = rk_tsadcv2_get_temp,
+   .set_alarm_temp = rk_tsadcv2_alarm_temp,
+   .set_tshut_temp = rk_tsadcv2_tshut_temp,
+   .set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+   .table = {
+   .id = rk3328_code_table,
+   .length = ARRAY_SIZE(rk3328_code_table),
+   .data_mask = TSADCV2_DATA_MASK,
+   .mode = ADC_INCREMENT,
+   },
+};
+
  static const struct rockchip_tsadc_chip rk3366_tsadc_data = {
.chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
.chn_id[SENSOR_GPU] = 1, /* gpu sensor is channel 1 */
@@ -875,6 +936,10 @@ static void rk_tsadcv2_tshut_mode(int chn, void
__iomem *regs,
.data = (void *)_tsadc_data,
},
{
+   .compatible = "rockchip,rk3328-tsadc",
+   .data = (void *)_tsadc_data,
+   },
+   {
.compatible = "rockchip,rk3366-tsadc",
.data = (void *)_tsadc_data,
},

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] arm64: dts: rockchip: update dynamic-power-coefficient for rk3399

[Caesar Wang]

This patch updates the dynamic-power-coefficient for big cluster on
rk3399 SoCs.

The dynamic power consumption of the CPU is proportional to the square of
the Voltage (V) and the clock frequency (f). The coefficient is used to
calculate the dynamic power as below -
Pdyn = dynamic-power-coefficient * V^2 * f
Where Voltage is in uV, frequency is in MHz.

As the following is the tested data on rk3399's big cluster.
frequency(MHz)  Voltage(V)  Current(mA) Dynamic-power-coefficient
24  0.8 15
48  0.8 23  ~417
96  0.8 40  ~443
216 0.8 82  ~438
312 0.8 115 ~430
408 0.8 150 ~455
So the dynamic-power-coefficient average value is about 436.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 9d02006..5d54a06 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -150,7 +150,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
 
cpu_b1: cpu@101 {
@@ -159,7 +159,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
};
 
-- 
2.7.4

[PATCH] arm64: dts: rockchip: update dynamic-power-coefficient for rk3399

[Caesar Wang]

This patch updates the dynamic-power-coefficient for big cluster on
rk3399 SoCs.

The dynamic power consumption of the CPU is proportional to the square of
the Voltage (V) and the clock frequency (f). The coefficient is used to
calculate the dynamic power as below -
Pdyn = dynamic-power-coefficient * V^2 * f
Where Voltage is in uV, frequency is in MHz.

As the following is the tested data on rk3399's big cluster.
frequency(MHz)  Voltage(V)  Current(mA) Dynamic-power-coefficient
24  0.8 15
48  0.8 23  ~417
96  0.8 40  ~443
216 0.8 82  ~438
312 0.8 115 ~430
408 0.8 150 ~455
So the dynamic-power-coefficient average value is about 436.

Signed-off-by: Caesar Wang 
---

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 9d02006..5d54a06 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -150,7 +150,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
 
cpu_b1: cpu@101 {
@@ -159,7 +159,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
};
 
-- 
2.7.4

Re: [PATCH v2 5/5] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Caesar Wang]

Hi Heiko,

Thanks your comments.

在 2017年07月23日 05:48, Heiko Stuebner 写道:


Hi Caesar,

Am Montag, 17. Juli 2017, 16:14:31 CEST schrieb Caesar Wang:

As RK3399 had used the Power allocator thermal governor by default,
enabled this to manage thermals by dynamically allocating and limiting
power to devices.

Also, this patch supported the dynamic-power-coefficient/sustainable_power
and GPU's power model for needed parameters with thermal IPA.

The Thermal power allocator governor works optimatly with two passive trip
points, for the better performance we will use the trip-point0 with 70
degree above which the governor control starts operating and trip-point1
with 85 degree is the target temperature by controlling.

Signed-off-by: Caesar Wang <w...@rock-chips.com>

---

Changes in v2:
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++-
  1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 77d67cb..6d8a5eb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -147,7 +147,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
  
  		cpu_b1: cpu@101 {

@@ -156,7 +156,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;

Adjusting the coefficients should be a separate patch and the
commit message should explain how they were calculated and
why they are the exacter ones over the old values.


Okay, i don't know why the dynamic-power-coefficient is 100 for 
b-cluster before.:-)






};
};
  
@@ -690,24 +690,25 @@

};
  
  	thermal_zones: thermal-zones {

-   cpu_thermal: cpu {
+   soc_thermal: soc-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
+   sustainable-power = <1000>;
  
  			thermal-sensors = < 0>;
  
  			trips {

-   cpu_alert0: cpu_alert0 {
+   threshold: trip-point0 {
temperature = <7>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_alert1: cpu_alert1 {
-   temperature = <75000>;
+   target: trip-point1 {
+   temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_crit: cpu_crit {
+   soc_crit: soc-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -716,45 +717,31 @@
  
  			cooling-maps {

map0 {
-   trip = <_alert0>;
+   trip = <>;

still both maps use  as trip point. Is that intentional
and if so, why is the  trip point never referenced?


For the power allocator governor, the  trip point just control 
starts operating, not need for map.
For other governor (e.g: step_wise) will need the first trip point. 
Looks like we have to think about how to support them.




};
};
  
@@ -1451,8 +1438,17 @@

 ;
interrupt-names = "gpu", "job", "mmu";
clocks = < ACLK_GPU>;
+   #cooling-cells = <2>;
power-domains = < RK3399_PD_GPU>;
status = "disabled";
+
+   gpu_power_model: power_model {
+   compatible = "arm,mali-simple-power-model";
+   static-coefficient = <1079403>;
+   dynamic-coefficient = <977>;
+   ts = <32000 4700 (-80) 2>;
+   thermal-zone = &q

Re: [PATCH v2 5/5] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Caesar Wang]

Hi Heiko,

Thanks your comments.

在 2017年07月23日 05:48, Heiko Stuebner 写道:


Hi Caesar,

Am Montag, 17. Juli 2017, 16:14:31 CEST schrieb Caesar Wang:

As RK3399 had used the Power allocator thermal governor by default,
enabled this to manage thermals by dynamically allocating and limiting
power to devices.

Also, this patch supported the dynamic-power-coefficient/sustainable_power
and GPU's power model for needed parameters with thermal IPA.

The Thermal power allocator governor works optimatly with two passive trip
points, for the better performance we will use the trip-point0 with 70
degree above which the governor control starts operating and trip-point1
with 85 degree is the target temperature by controlling.

Signed-off-by: Caesar Wang 

---

Changes in v2:
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++-
  1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 77d67cb..6d8a5eb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -147,7 +147,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
  
  		cpu_b1: cpu@101 {

@@ -156,7 +156,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;

Adjusting the coefficients should be a separate patch and the
commit message should explain how they were calculated and
why they are the exacter ones over the old values.


Okay, i don't know why the dynamic-power-coefficient is 100 for 
b-cluster before.:-)






};
};
  
@@ -690,24 +690,25 @@

};
  
  	thermal_zones: thermal-zones {

-   cpu_thermal: cpu {
+   soc_thermal: soc-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
+   sustainable-power = <1000>;
  
  			thermal-sensors = < 0>;
  
  			trips {

-   cpu_alert0: cpu_alert0 {
+   threshold: trip-point0 {
temperature = <7>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_alert1: cpu_alert1 {
-   temperature = <75000>;
+   target: trip-point1 {
+   temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_crit: cpu_crit {
+   soc_crit: soc-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -716,45 +717,31 @@
  
  			cooling-maps {

map0 {
-   trip = <_alert0>;
+   trip = <>;

still both maps use  as trip point. Is that intentional
and if so, why is the  trip point never referenced?


For the power allocator governor, the  trip point just control 
starts operating, not need for map.
For other governor (e.g: step_wise) will need the first trip point. 
Looks like we have to think about how to support them.




};
};
  
@@ -1451,8 +1438,17 @@

 ;
interrupt-names = "gpu", "job", "mmu";
clocks = < ACLK_GPU>;
+   #cooling-cells = <2>;
power-domains = < RK3399_PD_GPU>;
status = "disabled";
+
+   gpu_power_model: power_model {
+   compatible = "arm,mali-simple-power-model";
+   static-coefficient = <1079403>;
+   dynamic-coefficient = <977>;
+   ts = <32000 4700 (-80) 2>;
+   thermal-zone = "gpu-thermal";
+  

Re: [PATCH v2 0/5] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[Caesar Wang]

Hi Rob & Heiko,

Do we have the chance to merge these patches?

I'm try to bring up the display and run webgl for testing with my github on
https://github.com/Caesar-github/rockchip/commits/gru/next-stable-chromeos

I believe the Rocky@RK will post patches to support the other SoCs after.

-Caesar

在 2017年07月17日 16:14, Caesar Wang 写道:

This series patches supported the mail in devicetree and used the
thermal IPA by default.

Verified with kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch. ( The Linux version 4.12.0 for now).

The most rockchip SoCs will be supported with IPA mode for thermal
in later.

---

History version:
1. The first version found on
https://www.spinics.net/lists/arm-kernel/msg593118.html

Tested on Kevin board with bringing up ChromeOS.
OS VERSION:
 CHROMEOS_RELEASE_DESCRIPTION=9693.1.0 (Official Build) dev-channel kevin 
test

BIOS VERSION:
 Google_Kevin.8785.211.2017_06_20_1043

EC VERSION:
 Build info:kevin_v1.10.217-24514961d 2017-07-03 07:46:36 wxt@nb

With the ARM's lastest mali driver TX011-SW-99002-r18p0-01rel0 on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel

 From the bootup log:
 localhost devfreq0 # dmesg |grep mali
 [0.94] mali ff9a.gpu: GPU identified as 0x0860 r2p0 status 0
 [0.940830] mali ff9a.gpu: Protected mode not available
 [0.947334] mali ff9a.gpu: Using configured power model 
mali-simple-power-model, and fallback mali-simple-power-model
 [0.960083] mali ff9a.gpu: Probed as mali0

 localhost devfreq0 # pwd
 /sys/devices/platform/ff9a.gpu/devfreq/devfreq0
 localhost devfreq0 # ls
 available_frequencies  devicemin_freq  subsystemuevent
 available_governorsgovernor  polling_interval  target_freq  userspace
 cur_freq   max_freq  power trans_stat

 localhost ff9a.gpu # ls
 core_availability_policy  gpuinfo   modalias   
soft_job_timeout
 core_mask js_scheduling_period  of_nodesubsystem
 devfreq   js_timeouts   pm_poweroffuevent
 drivermem_pool_max_size power
 driver_override   mem_pool_size power_policy
 dvfs_period   misc  reset_timeout
---

And for thermal with IPA.
Try to run 'md5sum /dev/zero &' and octane/benchmark scripts to go up the 
temperature.
 From the scripts to have a look at the actual control.
"
while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp 
/sys/devices/system/cpu/cpu[0-5]/cpufreq/scaling_cur_freq 
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0/cur_freq;date;sleep .5; done &
"

-Caesar


Changes in v2:
As Heiko comments on https://patchwork.kernel.org/patch/9835939/
- interrupt-name use the lower case.
- use the correct compatible "arm,mali-t860"
- remove the clock name, since the mali only have one input clock.
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

Caesar Wang (5):
   dt-bindings: gpu: add the RK3399 mali for rockchip specifics
   dt-bindings: gpu: add a power_model optional properties for MALI
   arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
   arm64: dts: rockchip: enable the GPU for RK3399-GRU
   arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

  .../devicetree/bindings/gpu/arm,mali-midgard.txt   | 13 
  arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |  5 ++
  arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi   | 33 ++
  arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi   | 33 ++
  arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 74 --
  5 files changed, 125 insertions(+), 33 deletions(-)

Re: [PATCH v2 0/5] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[Caesar Wang]

Hi Rob & Heiko,

Do we have the chance to merge these patches?

I'm try to bring up the display and run webgl for testing with my github on
https://github.com/Caesar-github/rockchip/commits/gru/next-stable-chromeos

I believe the Rocky@RK will post patches to support the other SoCs after.

-Caesar

在 2017年07月17日 16:14, Caesar Wang 写道:

This series patches supported the mail in devicetree and used the
thermal IPA by default.

Verified with kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch. ( The Linux version 4.12.0 for now).

The most rockchip SoCs will be supported with IPA mode for thermal
in later.

---

History version:
1. The first version found on
https://www.spinics.net/lists/arm-kernel/msg593118.html

Tested on Kevin board with bringing up ChromeOS.
OS VERSION:
 CHROMEOS_RELEASE_DESCRIPTION=9693.1.0 (Official Build) dev-channel kevin 
test

BIOS VERSION:
 Google_Kevin.8785.211.2017_06_20_1043

EC VERSION:
 Build info:kevin_v1.10.217-24514961d 2017-07-03 07:46:36 wxt@nb

With the ARM's lastest mali driver TX011-SW-99002-r18p0-01rel0 on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel

 From the bootup log:
 localhost devfreq0 # dmesg |grep mali
 [0.94] mali ff9a.gpu: GPU identified as 0x0860 r2p0 status 0
 [0.940830] mali ff9a.gpu: Protected mode not available
 [0.947334] mali ff9a.gpu: Using configured power model 
mali-simple-power-model, and fallback mali-simple-power-model
 [0.960083] mali ff9a.gpu: Probed as mali0

 localhost devfreq0 # pwd
 /sys/devices/platform/ff9a.gpu/devfreq/devfreq0
 localhost devfreq0 # ls
 available_frequencies  devicemin_freq  subsystemuevent
 available_governorsgovernor  polling_interval  target_freq  userspace
 cur_freq   max_freq  power trans_stat

 localhost ff9a.gpu # ls
 core_availability_policy  gpuinfo   modalias   
soft_job_timeout
 core_mask js_scheduling_period  of_nodesubsystem
 devfreq   js_timeouts   pm_poweroffuevent
 drivermem_pool_max_size power
 driver_override   mem_pool_size power_policy
 dvfs_period   misc  reset_timeout
---

And for thermal with IPA.
Try to run 'md5sum /dev/zero &' and octane/benchmark scripts to go up the 
temperature.
 From the scripts to have a look at the actual control.
"
while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp 
/sys/devices/system/cpu/cpu[0-5]/cpufreq/scaling_cur_freq 
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0/cur_freq;date;sleep .5; done &
"

-Caesar


Changes in v2:
As Heiko comments on https://patchwork.kernel.org/patch/9835939/
- interrupt-name use the lower case.
- use the correct compatible "arm,mali-t860"
- remove the clock name, since the mali only have one input clock.
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

Caesar Wang (5):
   dt-bindings: gpu: add the RK3399 mali for rockchip specifics
   dt-bindings: gpu: add a power_model optional properties for MALI
   arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
   arm64: dts: rockchip: enable the GPU for RK3399-GRU
   arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

  .../devicetree/bindings/gpu/arm,mali-midgard.txt   | 13 
  arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |  5 ++
  arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi   | 33 ++
  arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi   | 33 ++
  arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 74 --
  5 files changed, 125 insertions(+), 33 deletions(-)

Re: [PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

[Caesar Wang]

Rob,

在 2017年07月18日 04:07, Rob Herring 写道:

On Mon, Jul 17, 2017 at 04:14:28PM +0800, Caesar Wang wrote:

This patch adds the MALI's power-model to set the IPA model to be used
for power management.

What's IPA? India Pale Ale or Intermediate Physical Address?


IPA is intelligent Power Allocator.  (As the ARM introduced on 
https://developer.arm.com/open-source/intelligent-power-allocation)





Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

Changes in v2: None

  Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 
  1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index a461e47..b616e6b 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -37,6 +37,18 @@ Optional properties:
  - operating-points-v2 : Refer to 
Documentation/devicetree/bindings/power/opp.txt
for details.
  
+- power_model : Sets power model parameters. Note that this model was designed for the Juno

+   platform, and may not be suitable for other platforms. A 
structure containing :
+   - compatible: Should be arm,mali-simple-power-model
+   - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied
+ by v^2*f to calculate the dynamic power consumption.
+   - static-coefficient: Coefficient, in uW/V^3, which is multiplied by
+ v^3 to calculate the static power consumption.
+   - ts: An array containing coefficients for the temperature scaling
+ factor. This is used to scale the static power by a factor of
+ tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0],
+ and T = temperature in degrees.
+   - thermal-zone: A string identifying the thermal zone used for the GPU

This can all easily be implied by the compatible string. I'm not
inclined to accept something Mali specific here.


Isn't  arm,mali-midgard.txt document suit for Mali specific? :-)



This looks *very* precise, but I'd be surprised if these values are any
more than magic values (at least the dynamic coef) adjusted until the
desired power/performance requirements are achieved. To put it another
way, why don't we have similar values for CPUs?


These value was calculated by running full GPU process.

CPU had the similar value for dtsi.

Say: arch/arm64/boot/dts/rockchip/rk3399.dtsi
cpu_b0: cpu@100 {
...
dynamic-power-coefficient = <436>;
...
};

-Caesar



Rob

Re: [PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

[Caesar Wang]

Rob,

在 2017年07月18日 04:07, Rob Herring 写道:

On Mon, Jul 17, 2017 at 04:14:28PM +0800, Caesar Wang wrote:

This patch adds the MALI's power-model to set the IPA model to be used
for power management.

What's IPA? India Pale Ale or Intermediate Physical Address?


IPA is intelligent Power Allocator.  (As the ARM introduced on 
https://developer.arm.com/open-source/intelligent-power-allocation)





Signed-off-by: Caesar Wang 
---

Changes in v2: None

  Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 
  1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index a461e47..b616e6b 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -37,6 +37,18 @@ Optional properties:
  - operating-points-v2 : Refer to 
Documentation/devicetree/bindings/power/opp.txt
for details.
  
+- power_model : Sets power model parameters. Note that this model was designed for the Juno

+   platform, and may not be suitable for other platforms. A 
structure containing :
+   - compatible: Should be arm,mali-simple-power-model
+   - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied
+ by v^2*f to calculate the dynamic power consumption.
+   - static-coefficient: Coefficient, in uW/V^3, which is multiplied by
+ v^3 to calculate the static power consumption.
+   - ts: An array containing coefficients for the temperature scaling
+ factor. This is used to scale the static power by a factor of
+ tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0],
+ and T = temperature in degrees.
+   - thermal-zone: A string identifying the thermal zone used for the GPU

This can all easily be implied by the compatible string. I'm not
inclined to accept something Mali specific here.


Isn't  arm,mali-midgard.txt document suit for Mali specific? :-)



This looks *very* precise, but I'd be surprised if these values are any
more than magic values (at least the dynamic coef) adjusted until the
desired power/performance requirements are achieved. To put it another
way, why don't we have similar values for CPUs?


These value was calculated by running full GPU process.

CPU had the similar value for dtsi.

Say: arch/arm64/boot/dts/rockchip/rk3399.dtsi
cpu_b0: cpu@100 {
...
dynamic-power-coefficient = <436>;
...
};

-Caesar



Rob

[PATCH v2 1/5] dt-bindings: gpu: add the RK3399 mali for rockchip specifics

[Caesar Wang]

RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
high-end graphics processors from ARM.

This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
support IPA of gpu thermal in later.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

Changes in v2: None

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index d3b6e1a4..a461e47 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -17,6 +17,7 @@ Required properties:
   * which must be preceded by one of the following vendor specifics:
 + "amlogic,meson-gxm-mali"
 + "rockchip,rk3288-mali"
++ "rockchip,rk3399-mali"
 
 - reg : Physical base address of the device and length of the register area.
 
-- 
2.7.4

[PATCH v2 1/5] dt-bindings: gpu: add the RK3399 mali for rockchip specifics

[Caesar Wang]

RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
high-end graphics processors from ARM.

This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
support IPA of gpu thermal in later.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index d3b6e1a4..a461e47 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -17,6 +17,7 @@ Required properties:
   * which must be preceded by one of the following vendor specifics:
 + "amlogic,meson-gxm-mali"
 + "rockchip,rk3288-mali"
++ "rockchip,rk3399-mali"
 
 - reg : Physical base address of the device and length of the register area.
 
-- 
2.7.4

[PATCH v2 3/5] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Caesar Wang]

Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
opp table.

RK3399 and RK3399-OP1 SoCs have a different recommendation table with
gpu opp. Also, the ARM's mali driver found on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel.

Signed-off-by: Caesar Wang <w...@rock-chips.com>

---

Changes in v2:
As Heiko comments on https://patchwork.kernel.org/patch/9835939/
- interrupt-name use the lower case.
- use the correct compatible "arm,mali-t860"
- remove the clock name, since the mali only have one input clock.

 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 33 
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 +
 3 files changed, 78 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
index be7fe63..d8a120f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
@@ -118,6 +118,35 @@
opp-microvolt = <125>;
};
};
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <85>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <1075000>;
+   };
+   };
 };
 
 _l0 {
@@ -143,3 +172,7 @@
 _b1 {
operating-points-v2 = <_opp>;
 };
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index c83460d..81617bc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -110,6 +110,35 @@
opp-microvolt = <120>;
};
};
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <875000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <110>;
+   };
+   };
 };
 
 _l0 {
@@ -135,3 +164,7 @@
 _b1 {
operating-points-v2 = <_opp>;
 };
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 1cbd7a2..77d67cb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1443,6 +1443,18 @@
status = "disabled";
};
 
+   gpu: gpu@ff9a {
+   compatible = "arm,rk3399-mali", "arm,mali-t860";
+   reg = <0x0 0xff9a 0x0 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "gpu", "job", "mmu";
+   clocks = < ACLK_GPU>;
+   power-domains = < RK3399_PD_GPU>;
+   status = "disabled";
+   };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <>;
-- 
2.7.4

[PATCH v2 3/5] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Caesar Wang]

Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
opp table.

RK3399 and RK3399-OP1 SoCs have a different recommendation table with
gpu opp. Also, the ARM's mali driver found on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel.

Signed-off-by: Caesar Wang 

---

Changes in v2:
As Heiko comments on https://patchwork.kernel.org/patch/9835939/
- interrupt-name use the lower case.
- use the correct compatible "arm,mali-t860"
- remove the clock name, since the mali only have one input clock.

 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 33 
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 +
 3 files changed, 78 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
index be7fe63..d8a120f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
@@ -118,6 +118,35 @@
opp-microvolt = <125>;
};
};
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <85>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <1075000>;
+   };
+   };
 };
 
 _l0 {
@@ -143,3 +172,7 @@
 _b1 {
operating-points-v2 = <_opp>;
 };
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index c83460d..81617bc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -110,6 +110,35 @@
opp-microvolt = <120>;
};
};
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <875000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <110>;
+   };
+   };
 };
 
 _l0 {
@@ -135,3 +164,7 @@
 _b1 {
operating-points-v2 = <_opp>;
 };
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 1cbd7a2..77d67cb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1443,6 +1443,18 @@
status = "disabled";
};
 
+   gpu: gpu@ff9a {
+   compatible = "arm,rk3399-mali", "arm,mali-t860";
+   reg = <0x0 0xff9a 0x0 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "gpu", "job", "mmu";
+   clocks = < ACLK_GPU>;
+   power-domains = < RK3399_PD_GPU>;
+   status = "disabled";
+   };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <>;
-- 
2.7.4

[PATCH v2 4/5] arm64: dts: rockchip: enable the GPU for RK3399-GRU

[Caesar Wang]

This patch enables the gpu and adds the mali-supply power for RK3399-GRU
devices.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

Changes in v2: None

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 90259cf..d48e98b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -595,6 +595,11 @@
status = "okay";
 };
 
+ {
+   mali-supply = <_gpu>;
+   status = "okay";
+};
+
 ap_i2c_mic:  {
status = "okay";
 
-- 
2.7.4

[PATCH v2 4/5] arm64: dts: rockchip: enable the GPU for RK3399-GRU

[Caesar Wang]

This patch enables the gpu and adds the mali-supply power for RK3399-GRU
devices.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 90259cf..d48e98b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -595,6 +595,11 @@
status = "okay";
 };
 
+ {
+   mali-supply = <_gpu>;
+   status = "okay";
+};
+
 ap_i2c_mic:  {
status = "okay";
 
-- 
2.7.4

[PATCH v2 5/5] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Caesar Wang]

As RK3399 had used the Power allocator thermal governor by default,
enabled this to manage thermals by dynamically allocating and limiting
power to devices.

Also, this patch supported the dynamic-power-coefficient/sustainable_power
and GPU's power model for needed parameters with thermal IPA.

The Thermal power allocator governor works optimatly with two passive trip
points, for the better performance we will use the trip-point0 with 70
degree above which the governor control starts operating and trip-point1
with 85 degree is the target temperature by controlling.

Signed-off-by: Caesar Wang <w...@rock-chips.com>

---

Changes in v2:
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++-
 1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 77d67cb..6d8a5eb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -147,7 +147,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
 
cpu_b1: cpu@101 {
@@ -156,7 +156,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
};
 
@@ -690,24 +690,25 @@
};
 
thermal_zones: thermal-zones {
-   cpu_thermal: cpu {
+   soc_thermal: soc-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
+   sustainable-power = <1000>;
 
thermal-sensors = < 0>;
 
trips {
-   cpu_alert0: cpu_alert0 {
+   threshold: trip-point0 {
temperature = <7>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_alert1: cpu_alert1 {
-   temperature = <75000>;
+   target: trip-point1 {
+   temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_crit: cpu_crit {
+   soc_crit: soc-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -716,45 +717,31 @@
 
cooling-maps {
map0 {
-   trip = <_alert0>;
+   trip = <>;
cooling-device =
-   <_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
map1 {
-   trip = <_alert1>;
+   trip = <>;
cooling-device =
-   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
<_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <1024>;
+   };
+   map2 {
+   trip = <>;
+   cooling-device =
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
};
};
 
-   gpu_thermal: gpu {
+   gpu_thermal: gpu-thermal {
polling-delay-passive = <100&

[PATCH v2 5/5] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Caesar Wang]

As RK3399 had used the Power allocator thermal governor by default,
enabled this to manage thermals by dynamically allocating and limiting
power to devices.

Also, this patch supported the dynamic-power-coefficient/sustainable_power
and GPU's power model for needed parameters with thermal IPA.

The Thermal power allocator governor works optimatly with two passive trip
points, for the better performance we will use the trip-point0 with 70
degree above which the governor control starts operating and trip-point1
with 85 degree is the target temperature by controlling.

Signed-off-by: Caesar Wang 

---

Changes in v2:
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++-
 1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 77d67cb..6d8a5eb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -147,7 +147,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
 
cpu_b1: cpu@101 {
@@ -156,7 +156,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
};
 
@@ -690,24 +690,25 @@
};
 
thermal_zones: thermal-zones {
-   cpu_thermal: cpu {
+   soc_thermal: soc-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
+   sustainable-power = <1000>;
 
thermal-sensors = < 0>;
 
trips {
-   cpu_alert0: cpu_alert0 {
+   threshold: trip-point0 {
temperature = <7>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_alert1: cpu_alert1 {
-   temperature = <75000>;
+   target: trip-point1 {
+   temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_crit: cpu_crit {
+   soc_crit: soc-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -716,45 +717,31 @@
 
cooling-maps {
map0 {
-   trip = <_alert0>;
+   trip = <>;
cooling-device =
-   <_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
map1 {
-   trip = <_alert1>;
+   trip = <>;
cooling-device =
-   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
<_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <1024>;
+   };
+   map2 {
+   trip = <>;
+   cooling-device =
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
};
};
 
-   gpu_thermal: gpu {
+   gpu_thermal: gpu-thermal {
polling-delay-passive = <100>;
 

[PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

[Caesar Wang]

This patch adds the MALI's power-model to set the IPA model to be used
for power management.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

Changes in v2: None

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index a461e47..b616e6b 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -37,6 +37,18 @@ Optional properties:
 - operating-points-v2 : Refer to 
Documentation/devicetree/bindings/power/opp.txt
   for details.
 
+- power_model : Sets power model parameters. Note that this model was designed 
for the Juno
+   platform, and may not be suitable for other platforms. A 
structure containing :
+   - compatible: Should be arm,mali-simple-power-model
+   - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied
+ by v^2*f to calculate the dynamic power consumption.
+   - static-coefficient: Coefficient, in uW/V^3, which is multiplied by
+ v^3 to calculate the static power consumption.
+   - ts: An array containing coefficients for the temperature scaling
+ factor. This is used to scale the static power by a factor of
+ tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0],
+ and T = temperature in degrees.
+   - thermal-zone: A string identifying the thermal zone used for the GPU
 
 Example for a Mali-T760:
 
-- 
2.7.4

[PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

[Caesar Wang]

This patch adds the MALI's power-model to set the IPA model to be used
for power management.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index a461e47..b616e6b 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -37,6 +37,18 @@ Optional properties:
 - operating-points-v2 : Refer to 
Documentation/devicetree/bindings/power/opp.txt
   for details.
 
+- power_model : Sets power model parameters. Note that this model was designed 
for the Juno
+   platform, and may not be suitable for other platforms. A 
structure containing :
+   - compatible: Should be arm,mali-simple-power-model
+   - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied
+ by v^2*f to calculate the dynamic power consumption.
+   - static-coefficient: Coefficient, in uW/V^3, which is multiplied by
+ v^3 to calculate the static power consumption.
+   - ts: An array containing coefficients for the temperature scaling
+ factor. This is used to scale the static power by a factor of
+ tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0],
+ and T = temperature in degrees.
+   - thermal-zone: A string identifying the thermal zone used for the GPU
 
 Example for a Mali-T760:
 
-- 
2.7.4

[PATCH v2 0/5] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[Caesar Wang]

This series patches supported the mail in devicetree and used the
thermal IPA by default.

Verified with kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch. ( The Linux version 4.12.0 for now).

The most rockchip SoCs will be supported with IPA mode for thermal
in later.

---

History version:
1. The first version found on
https://www.spinics.net/lists/arm-kernel/msg593118.html

Tested on Kevin board with bringing up ChromeOS.
OS VERSION:
CHROMEOS_RELEASE_DESCRIPTION=9693.1.0 (Official Build) dev-channel kevin 
test

BIOS VERSION:
Google_Kevin.8785.211.2017_06_20_1043

EC VERSION:
Build info:kevin_v1.10.217-24514961d 2017-07-03 07:46:36 wxt@nb

With the ARM's lastest mali driver TX011-SW-99002-r18p0-01rel0 on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel

>From the bootup log:
localhost devfreq0 # dmesg |grep mali
[0.94] mali ff9a.gpu: GPU identified as 0x0860 r2p0 status 0
[0.940830] mali ff9a.gpu: Protected mode not available
[0.947334] mali ff9a.gpu: Using configured power model 
mali-simple-power-model, and fallback mali-simple-power-model
[0.960083] mali ff9a.gpu: Probed as mali0

localhost devfreq0 # pwd
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0
localhost devfreq0 # ls
available_frequencies  devicemin_freq  subsystemuevent
available_governorsgovernor  polling_interval  target_freq  userspace
cur_freq   max_freq  power trans_stat

localhost ff9a.gpu # ls
core_availability_policy  gpuinfo   modalias   
soft_job_timeout
core_mask js_scheduling_period  of_nodesubsystem
devfreq   js_timeouts   pm_poweroffuevent
drivermem_pool_max_size power
driver_override   mem_pool_size power_policy
dvfs_period   misc  reset_timeout
---

And for thermal with IPA.
Try to run 'md5sum /dev/zero &' and octane/benchmark scripts to go up the 
temperature.
>From the scripts to have a look at the actual control.
"
while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp 
/sys/devices/system/cpu/cpu[0-5]/cpufreq/scaling_cur_freq 
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0/cur_freq;date;sleep .5; 
done &
"

-Caesar


Changes in v2:
As Heiko comments on https://patchwork.kernel.org/patch/9835939/
- interrupt-name use the lower case.
- use the correct compatible "arm,mali-t860"
- remove the clock name, since the mali only have one input clock.
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

Caesar Wang (5):
  dt-bindings: gpu: add the RK3399 mali for rockchip specifics
  dt-bindings: gpu: add a power_model optional properties for MALI
  arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
  arm64: dts: rockchip: enable the GPU for RK3399-GRU
  arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

 .../devicetree/bindings/gpu/arm,mali-midgard.txt   | 13 
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |  5 ++
 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi   | 33 ++
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi   | 33 ++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 74 --
 5 files changed, 125 insertions(+), 33 deletions(-)

-- 
2.7.4

[PATCH v2 0/5] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[Caesar Wang]

This series patches supported the mail in devicetree and used the
thermal IPA by default.

Verified with kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch. ( The Linux version 4.12.0 for now).

The most rockchip SoCs will be supported with IPA mode for thermal
in later.

---

History version:
1. The first version found on
https://www.spinics.net/lists/arm-kernel/msg593118.html

Tested on Kevin board with bringing up ChromeOS.
OS VERSION:
CHROMEOS_RELEASE_DESCRIPTION=9693.1.0 (Official Build) dev-channel kevin 
test

BIOS VERSION:
Google_Kevin.8785.211.2017_06_20_1043

EC VERSION:
Build info:kevin_v1.10.217-24514961d 2017-07-03 07:46:36 wxt@nb

With the ARM's lastest mali driver TX011-SW-99002-r18p0-01rel0 on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel

>From the bootup log:
localhost devfreq0 # dmesg |grep mali
[0.94] mali ff9a.gpu: GPU identified as 0x0860 r2p0 status 0
[0.940830] mali ff9a.gpu: Protected mode not available
[0.947334] mali ff9a.gpu: Using configured power model 
mali-simple-power-model, and fallback mali-simple-power-model
[0.960083] mali ff9a.gpu: Probed as mali0

localhost devfreq0 # pwd
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0
localhost devfreq0 # ls
available_frequencies  devicemin_freq  subsystemuevent
available_governorsgovernor  polling_interval  target_freq  userspace
cur_freq   max_freq  power trans_stat

localhost ff9a.gpu # ls
core_availability_policy  gpuinfo   modalias   
soft_job_timeout
core_mask js_scheduling_period  of_nodesubsystem
devfreq   js_timeouts   pm_poweroffuevent
drivermem_pool_max_size power
driver_override   mem_pool_size power_policy
dvfs_period   misc  reset_timeout
---

And for thermal with IPA.
Try to run 'md5sum /dev/zero &' and octane/benchmark scripts to go up the 
temperature.
>From the scripts to have a look at the actual control.
"
while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp 
/sys/devices/system/cpu/cpu[0-5]/cpufreq/scaling_cur_freq 
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0/cur_freq;date;sleep .5; 
done &
"

-Caesar


Changes in v2:
As Heiko comments on https://patchwork.kernel.org/patch/9835939/
- interrupt-name use the lower case.
- use the correct compatible "arm,mali-t860"
- remove the clock name, since the mali only have one input clock.
- foo@ will produce warnings when used without reg property.
- update the commit to explain the two passive trip points changed.

Caesar Wang (5):
  dt-bindings: gpu: add the RK3399 mali for rockchip specifics
  dt-bindings: gpu: add a power_model optional properties for MALI
  arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
  arm64: dts: rockchip: enable the GPU for RK3399-GRU
  arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

 .../devicetree/bindings/gpu/arm,mali-midgard.txt   | 13 
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |  5 ++
 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi   | 33 ++
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi   | 33 ++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 74 --
 5 files changed, 125 insertions(+), 33 deletions(-)

-- 
2.7.4

Re: [PATCH 2/4] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Caesar Wang]

在 2017年07月12日 15:19, Heiko Stuebner 写道:

Hi Caesar,

Am Mittwoch, 12. Juli 2017, 14:29:28 CEST schrieb Caesar Wang:

Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
opp table.

RK3399 and RK3399-OP1 SoCs have a different recommendation table with
gpu opp. As the ARM's mali driver found on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

  arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 
  arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 33 
  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 16 
  3 files changed, 82 insertions(+)

[...]


diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 1cbd7a2..8c6438b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1443,6 +1443,22 @@
status = "disabled";
};
  
+	gpu: gpu@ff9a {

+   compatible = "arm,rk3399-mali",
+"arm,malit860",
+"arm,malit86x",
+"arm,malit8xx";

no wildcards and correct compatibles please.
The binding specifies arm,mali-t860 for your chip and the soc
specific compatible needs a rockchip vendor, so you need

compatible = "rockchip,rk3399-mali", "arm,mali-t860";



Okay,  sound resonable.


+   reg = <0x0 0xff9a 0x0 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "GPU", "JOB", "MMU";

interrupt names are job, mmu, gpu in lower case. The out-of-tree driver
will need to conform to that.


Okay, we need update the ARM's mali driver to follow up.


+   clocks = < ACLK_GPU>;
+   clock-names = "clk_mali";

no clock-names property, as midgard malis only have one clock input


Sorry, I seem to be reference for the MAILI's document, not the Linux 
document.


Update these for patches v2.

Thanks your comments.

-Caesar



Heiko


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 2/4] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Caesar Wang]

在 2017年07月12日 15:19, Heiko Stuebner 写道:

Hi Caesar,

Am Mittwoch, 12. Juli 2017, 14:29:28 CEST schrieb Caesar Wang:

Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
opp table.

RK3399 and RK3399-OP1 SoCs have a different recommendation table with
gpu opp. As the ARM's mali driver found on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel.

Signed-off-by: Caesar Wang 
---

  arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 
  arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 33 
  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 16 
  3 files changed, 82 insertions(+)

[...]


diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 1cbd7a2..8c6438b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1443,6 +1443,22 @@
status = "disabled";
};
  
+	gpu: gpu@ff9a {

+   compatible = "arm,rk3399-mali",
+"arm,malit860",
+"arm,malit86x",
+"arm,malit8xx";

no wildcards and correct compatibles please.
The binding specifies arm,mali-t860 for your chip and the soc
specific compatible needs a rockchip vendor, so you need

compatible = "rockchip,rk3399-mali", "arm,mali-t860";



Okay,  sound resonable.


+   reg = <0x0 0xff9a 0x0 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "GPU", "JOB", "MMU";

interrupt names are job, mmu, gpu in lower case. The out-of-tree driver
will need to conform to that.


Okay, we need update the ARM's mali driver to follow up.


+   clocks = < ACLK_GPU>;
+   clock-names = "clk_mali";

no clock-names property, as midgard malis only have one clock input


Sorry, I seem to be reference for the MAILI's document, not the Linux 
document.


Update these for patches v2.

Thanks your comments.

-Caesar



Heiko


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH 0/4] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[Caesar Wang]

This series patches supported the mail in devicetree and used the
thermal IPA by default.

Verified with rk3399 kevin board on my github
https://github.com/Caesar-github/rockchip/commits/gru/next-stable-chromeos
The kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch. ( The Linux version 4.12.0 for now).
---

Tested on Kevin board with bringing up ChromeOS.
OS VERSION:
CHROMEOS_RELEASE_DESCRIPTION=9693.1.0 (Official Build) dev-channel kevin 
test

BIOS VERSION:
Google_Kevin.8785.211.2017_06_20_1043

EC VERSION:
Build info:kevin_v1.10.217-24514961d 2017-07-03 07:46:36 wxt@nb

With the ARM's lastest mali driver TX011-SW-99002-r18p0-01rel0 on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel

>From the bootup log:
localhost devfreq0 # dmesg |grep mali
[0.94] mali ff9a.gpu: GPU identified as 0x0860 r2p0 status 0
[0.940830] mali ff9a.gpu: Protected mode not available
[0.947334] mali ff9a.gpu: Using configured power model 
mali-simple-power-model, and fallback mali-simple-power-model
[0.960083] mali ff9a.gpu: Probed as mali0

localhost devfreq0 # pwd
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0
localhost devfreq0 # ls
available_frequencies  devicemin_freq  subsystemuevent
available_governorsgovernor  polling_interval  target_freq  userspace
cur_freq   max_freq  power trans_stat

localhost ff9a.gpu # ls
core_availability_policy  gpuinfo   modalias   
soft_job_timeout
core_mask js_scheduling_period  of_nodesubsystem
devfreq   js_timeouts   pm_poweroffuevent
drivermem_pool_max_size power
driver_override   mem_pool_size power_policy
dvfs_period   misc  reset_timeout
---

And for thermal with IPA.
Try to run 'md5sum /dev/zero &' and octane/benchmark scripts to go up the 
temperature.
>From the scripts to have a look at the actual control.
"
while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp 
/sys/devices/system/cpu/cpu[0-5]/cpufreq/scaling_cur_freq 
/sys/devices/platform/ff9a.gpu/devfreq/ff9a.gpu/cur_freq;date;sleep .5; 
done &
"

-Caesar



Caesar Wang (4):
  dt-bindings: gpu: add the RK3399 mali for rockchip specifics
  arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
  arm64: dts: rockchip: enable the GPU for RK3399-GRU
  arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

 .../devicetree/bindings/gpu/arm,mali-midgard.txt   |  1 +
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |  5 ++
 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi   | 33 +
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi   | 33 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 78 +-
 5 files changed, 117 insertions(+), 33 deletions(-)

-- 
2.7.4

[PATCH 0/4] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[Caesar Wang]

This series patches supported the mail in devicetree and used the
thermal IPA by default.

Verified with rk3399 kevin board on my github
https://github.com/Caesar-github/rockchip/commits/gru/next-stable-chromeos
The kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch. ( The Linux version 4.12.0 for now).
---

Tested on Kevin board with bringing up ChromeOS.
OS VERSION:
CHROMEOS_RELEASE_DESCRIPTION=9693.1.0 (Official Build) dev-channel kevin 
test

BIOS VERSION:
Google_Kevin.8785.211.2017_06_20_1043

EC VERSION:
Build info:kevin_v1.10.217-24514961d 2017-07-03 07:46:36 wxt@nb

With the ARM's lastest mali driver TX011-SW-99002-r18p0-01rel0 on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel

>From the bootup log:
localhost devfreq0 # dmesg |grep mali
[0.94] mali ff9a.gpu: GPU identified as 0x0860 r2p0 status 0
[0.940830] mali ff9a.gpu: Protected mode not available
[0.947334] mali ff9a.gpu: Using configured power model 
mali-simple-power-model, and fallback mali-simple-power-model
[0.960083] mali ff9a.gpu: Probed as mali0

localhost devfreq0 # pwd
/sys/devices/platform/ff9a.gpu/devfreq/devfreq0
localhost devfreq0 # ls
available_frequencies  devicemin_freq  subsystemuevent
available_governorsgovernor  polling_interval  target_freq  userspace
cur_freq   max_freq  power trans_stat

localhost ff9a.gpu # ls
core_availability_policy  gpuinfo   modalias   
soft_job_timeout
core_mask js_scheduling_period  of_nodesubsystem
devfreq   js_timeouts   pm_poweroffuevent
drivermem_pool_max_size power
driver_override   mem_pool_size power_policy
dvfs_period   misc  reset_timeout
---

And for thermal with IPA.
Try to run 'md5sum /dev/zero &' and octane/benchmark scripts to go up the 
temperature.
>From the scripts to have a look at the actual control.
"
while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp 
/sys/devices/system/cpu/cpu[0-5]/cpufreq/scaling_cur_freq 
/sys/devices/platform/ff9a.gpu/devfreq/ff9a.gpu/cur_freq;date;sleep .5; 
done &
"

-Caesar



Caesar Wang (4):
  dt-bindings: gpu: add the RK3399 mali for rockchip specifics
  arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
  arm64: dts: rockchip: enable the GPU for RK3399-GRU
  arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

 .../devicetree/bindings/gpu/arm,mali-midgard.txt   |  1 +
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |  5 ++
 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi   | 33 +
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi   | 33 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 78 +-
 5 files changed, 117 insertions(+), 33 deletions(-)

-- 
2.7.4

[PATCH 2/4] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Caesar Wang]

Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
opp table.

RK3399 and RK3399-OP1 SoCs have a different recommendation table with
gpu opp. As the ARM's mali driver found on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 33 
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 16 
 3 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
index be7fe63..d8a120f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
@@ -118,6 +118,35 @@
opp-microvolt = <125>;
};
};
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <85>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <1075000>;
+   };
+   };
 };
 
 _l0 {
@@ -143,3 +172,7 @@
 _b1 {
operating-points-v2 = <_opp>;
 };
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index c83460d..81617bc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -110,6 +110,35 @@
opp-microvolt = <120>;
};
};
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <875000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <110>;
+   };
+   };
 };
 
 _l0 {
@@ -135,3 +164,7 @@
 _b1 {
operating-points-v2 = <_opp>;
 };
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 1cbd7a2..8c6438b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1443,6 +1443,22 @@
status = "disabled";
};
 
+   gpu: gpu@ff9a {
+   compatible = "arm,rk3399-mali",
+"arm,malit860",
+"arm,malit86x",
+"arm,malit8xx";
+   reg = <0x0 0xff9a 0x0 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "GPU", "JOB", "MMU";
+   clocks = < ACLK_GPU>;
+   clock-names = "clk_mali";
+   power-domains = < RK3399_PD_GPU>;
+   status = "disabled";
+   };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <>;
-- 
2.7.4

[PATCH 4/4] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Caesar Wang]

As RK3399 had used the Power allocator thermal governor by default,
enabled this to manage thermals by dynamically allocating and limiting
power to devices.

Also, this patch supported the dynamic-power-coefficient/sustainable_power
and GPU's power model for needed parameters with thermal IPA.

Signed-off-by: Caesar Wang <w...@rock-chips.com>

---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++-
 1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 8c6438b..139f58c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -147,7 +147,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
 
cpu_b1: cpu@101 {
@@ -156,7 +156,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
};
 
@@ -690,24 +690,25 @@
};
 
thermal_zones: thermal-zones {
-   cpu_thermal: cpu {
+   soc_thermal: soc-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
+   sustainable-power = <1000>;
 
thermal-sensors = < 0>;
 
trips {
-   cpu_alert0: cpu_alert0 {
+   threshold: trip-point@0 {
temperature = <7>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_alert1: cpu_alert1 {
-   temperature = <75000>;
+   target: trip-point@1 {
+   temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_crit: cpu_crit {
+   soc_crit: soc-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -716,45 +717,31 @@
 
cooling-maps {
map0 {
-   trip = <_alert0>;
+   trip = <>;
cooling-device =
-   <_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
map1 {
-   trip = <_alert1>;
+   trip = <>;
cooling-device =
-   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
<_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <1024>;
+   };
+   map2 {
+   trip = <>;
+   cooling-device =
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
};
};
 
-   gpu_thermal: gpu {
+   gpu_thermal: gpu-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
 
thermal-sensors = < 1>;
-
-   trips {
-   gpu_alert0: gpu_alert0 {
-   temperature = <75000>;
-   hysteresis = <2000>;
-   type = &

[PATCH 4/4] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Caesar Wang]

As RK3399 had used the Power allocator thermal governor by default,
enabled this to manage thermals by dynamically allocating and limiting
power to devices.

Also, this patch supported the dynamic-power-coefficient/sustainable_power
and GPU's power model for needed parameters with thermal IPA.

Signed-off-by: Caesar Wang 

---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++-
 1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 8c6438b..139f58c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -147,7 +147,7 @@
enable-method = "psci";
#cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
 
cpu_b1: cpu@101 {
@@ -156,7 +156,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
clocks = < ARMCLKB>;
-   dynamic-power-coefficient = <100>;
+   dynamic-power-coefficient = <436>;
};
};
 
@@ -690,24 +690,25 @@
};
 
thermal_zones: thermal-zones {
-   cpu_thermal: cpu {
+   soc_thermal: soc-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
+   sustainable-power = <1000>;
 
thermal-sensors = < 0>;
 
trips {
-   cpu_alert0: cpu_alert0 {
+   threshold: trip-point@0 {
temperature = <7>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_alert1: cpu_alert1 {
-   temperature = <75000>;
+   target: trip-point@1 {
+   temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
-   cpu_crit: cpu_crit {
+   soc_crit: soc-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -716,45 +717,31 @@
 
cooling-maps {
map0 {
-   trip = <_alert0>;
+   trip = <>;
cooling-device =
-   <_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
map1 {
-   trip = <_alert1>;
+   trip = <>;
cooling-device =
-   <_l0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
<_b0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <1024>;
+   };
+   map2 {
+   trip = <>;
+   cooling-device =
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   contribution = <4096>;
};
};
};
 
-   gpu_thermal: gpu {
+   gpu_thermal: gpu-thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
 
thermal-sensors = < 1>;
-
-   trips {
-   gpu_alert0: gpu_alert0 {
-   temperature = <75000>;
-   hysteresis = <2000>;
-   type = "p

[PATCH 2/4] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Caesar Wang]

Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
opp table.

RK3399 and RK3399-OP1 SoCs have a different recommendation table with
gpu opp. As the ARM's mali driver found on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel.

Signed-off-by: Caesar Wang 
---

 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 33 
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 16 
 3 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
index be7fe63..d8a120f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
@@ -118,6 +118,35 @@
opp-microvolt = <125>;
};
};
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <85>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <1075000>;
+   };
+   };
 };
 
 _l0 {
@@ -143,3 +172,7 @@
 _b1 {
operating-points-v2 = <_opp>;
 };
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index c83460d..81617bc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -110,6 +110,35 @@
opp-microvolt = <120>;
};
};
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <875000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <110>;
+   };
+   };
 };
 
 _l0 {
@@ -135,3 +164,7 @@
 _b1 {
operating-points-v2 = <_opp>;
 };
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 1cbd7a2..8c6438b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1443,6 +1443,22 @@
status = "disabled";
};
 
+   gpu: gpu@ff9a {
+   compatible = "arm,rk3399-mali",
+"arm,malit860",
+"arm,malit86x",
+"arm,malit8xx";
+   reg = <0x0 0xff9a 0x0 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "GPU", "JOB", "MMU";
+   clocks = < ACLK_GPU>;
+   clock-names = "clk_mali";
+   power-domains = < RK3399_PD_GPU>;
+   status = "disabled";
+   };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <>;
-- 
2.7.4

[PATCH 1/4] dt-bindings: gpu: add the RK3399 mali for rockchip specifics

[Caesar Wang]

RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
high-end graphics processors from ARM.

This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
support IPA of gpu thermal in later.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index d3b6e1a4..a461e47 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -17,6 +17,7 @@ Required properties:
   * which must be preceded by one of the following vendor specifics:
 + "amlogic,meson-gxm-mali"
 + "rockchip,rk3288-mali"
++ "rockchip,rk3399-mali"
 
 - reg : Physical base address of the device and length of the register area.
 
-- 
2.7.4

[PATCH 3/4] arm64: dts: rockchip: enable the GPU for RK3399-GRU

[Caesar Wang]

This patch enables the gpu and adds the mali-supply power for RK3399-GRU
devices.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 90259cf..d48e98b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -595,6 +595,11 @@
status = "okay";
 };
 
+ {
+   mali-supply = <_gpu>;
+   status = "okay";
+};
+
 ap_i2c_mic:  {
status = "okay";
 
-- 
2.7.4

[PATCH 1/4] dt-bindings: gpu: add the RK3399 mali for rockchip specifics

[Caesar Wang]

RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
high-end graphics processors from ARM.

This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
support IPA of gpu thermal in later.

Signed-off-by: Caesar Wang 
---

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index d3b6e1a4..a461e47 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -17,6 +17,7 @@ Required properties:
   * which must be preceded by one of the following vendor specifics:
 + "amlogic,meson-gxm-mali"
 + "rockchip,rk3288-mali"
++ "rockchip,rk3399-mali"
 
 - reg : Physical base address of the device and length of the register area.
 
-- 
2.7.4

[PATCH 3/4] arm64: dts: rockchip: enable the GPU for RK3399-GRU

[Caesar Wang]

This patch enables the gpu and adds the mali-supply power for RK3399-GRU
devices.

Signed-off-by: Caesar Wang 
---

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 90259cf..d48e98b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -595,6 +595,11 @@
status = "okay";
 };
 
+ {
+   mali-supply = <_gpu>;
+   status = "okay";
+};
+
 ap_i2c_mic:  {
status = "okay";
 
-- 
2.7.4

arm64: dts: rockchip: add SdioAudio pd control for rk3399

[Caesar Wang]

The SdioAudio power domain includes the i2s/spdif/spi5/sdio.

So this patch adds the pd control for rk3399 i2s/spdif/spi5/sdio, in order
to save more power consumption.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

Changes note:
- As the Jeffy fixes the spi'cs issue recently as follows:
aa09938 spi: rockchip: Disable Runtime PM when chip select is asserted
c863795 spi: rockchip: Set GPIO_SS flag to enable Slave Select with GPIO CS
c351587 spi: rockchip: fix error handling when probe
- Posted this CL to support the SdioAudio power domain as commnets on
  https://chromium-review.googlesource.com/#/c/378562/

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 33e17d7..a1dd0da 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -289,6 +289,7 @@
fifo-depth = <0x100>;
resets = < SRST_SDIO0>;
reset-names = "reset";
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -678,6 +679,7 @@
pinctrl-0 = <_clk _tx _rx _cs0>;
#address-cells = <1>;
#size-cells = <0>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -952,6 +954,11 @@
 < SCLK_SDMMC>;
pm_qos = <_sd>;
};
+   pd_sdioaudio@RK3399_PD_SDIOAUDIO {
+   reg = ;
+   clocks = < HCLK_SDIO>;
+   pm_qos = <_sdioaudio>;
+   };
pd_vio@RK3399_PD_VIO {
reg = ;
#address-cells = <1>;
@@ -1372,6 +1379,7 @@
clocks = < SCLK_SPDIF_8CH>, < HCLK_SPDIF>;
pinctrl-names = "default";
pinctrl-0 = <_bus>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -1386,6 +1394,7 @@
clocks = < SCLK_I2S0_8CH>, < HCLK_I2S0_8CH>;
pinctrl-names = "default";
pinctrl-0 = <_8ch_bus>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -1399,6 +1408,7 @@
clocks = < SCLK_I2S1_8CH>, < HCLK_I2S1_8CH>;
pinctrl-names = "default";
pinctrl-0 = <_2ch_bus>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -1410,6 +1420,7 @@
dma-names = "tx", "rx";
clock-names = "i2s_clk", "i2s_hclk";
clocks = < SCLK_I2S2_8CH>, < HCLK_I2S2_8CH>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
-- 
2.7.4

arm64: dts: rockchip: add SdioAudio pd control for rk3399

[Caesar Wang]

The SdioAudio power domain includes the i2s/spdif/spi5/sdio.

So this patch adds the pd control for rk3399 i2s/spdif/spi5/sdio, in order
to save more power consumption.

Signed-off-by: Caesar Wang 
---

Changes note:
- As the Jeffy fixes the spi'cs issue recently as follows:
aa09938 spi: rockchip: Disable Runtime PM when chip select is asserted
c863795 spi: rockchip: Set GPIO_SS flag to enable Slave Select with GPIO CS
c351587 spi: rockchip: fix error handling when probe
- Posted this CL to support the SdioAudio power domain as commnets on
  https://chromium-review.googlesource.com/#/c/378562/

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 33e17d7..a1dd0da 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -289,6 +289,7 @@
fifo-depth = <0x100>;
resets = < SRST_SDIO0>;
reset-names = "reset";
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -678,6 +679,7 @@
pinctrl-0 = <_clk _tx _rx _cs0>;
#address-cells = <1>;
#size-cells = <0>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -952,6 +954,11 @@
 < SCLK_SDMMC>;
pm_qos = <_sd>;
};
+   pd_sdioaudio@RK3399_PD_SDIOAUDIO {
+   reg = ;
+   clocks = < HCLK_SDIO>;
+   pm_qos = <_sdioaudio>;
+   };
pd_vio@RK3399_PD_VIO {
reg = ;
#address-cells = <1>;
@@ -1372,6 +1379,7 @@
clocks = < SCLK_SPDIF_8CH>, < HCLK_SPDIF>;
pinctrl-names = "default";
pinctrl-0 = <_bus>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -1386,6 +1394,7 @@
clocks = < SCLK_I2S0_8CH>, < HCLK_I2S0_8CH>;
pinctrl-names = "default";
pinctrl-0 = <_8ch_bus>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -1399,6 +1408,7 @@
clocks = < SCLK_I2S1_8CH>, < HCLK_I2S1_8CH>;
pinctrl-names = "default";
pinctrl-0 = <_2ch_bus>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
@@ -1410,6 +1420,7 @@
dma-names = "tx", "rx";
clock-names = "i2s_clk", "i2s_hclk";
clocks = < SCLK_I2S2_8CH>, < HCLK_I2S2_8CH>;
+   power-domains = < RK3399_PD_SDIOAUDIO>;
status = "disabled";
};
 
-- 
2.7.4

Re: [PATCH v3 1/3] spi: rockchip: add support for "cs-gpios" dts property

[Caesar Wang]

Hi,

As the previous discussed on http://crosreview.com/379681, we have hit a 
failure [0] of ec's xfer, when we support the spi's pd to turn on/off. 
(Says: support the Sdioaudio pd of rk3399 on http://crosreview.com/378562)


[0]:
..
[ 5.579694 ] cros-ec-spi spi5.0: EC failed to respond in time
[ 5.585784 ] cros-ec-spi spi5.0: Transfer error 1/3: -110
..


Feels like that a workaround way to fix it, but that should be a good 
solution.



在 2017年06月14日 11:38, Jeffy Chen 写道:

Support using "cs-gpios" property to specify cs gpios.

Signed-off-by: Jeffy Chen <jeffy.c...@rock-chips.com>


Tested-by: Caesar Wang <w...@rock-chips.com>

I have fetched these patches to test S2R with my board for chromeos4.4.

localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
...
pd_sdioaudioon
/devices/platform/ff20.spi  suspended
/devices/platform/ff88.i2s  active
/devices/platform/ff8a.i2s  suspended

-Caesar


---

Changes in v3:
include linux/gpio/consumer.h for compile errors on ARCH_X86
(reported by kbuild test robot <l...@intel.com>)

Changes in v2:
1/ request cs gpios in probe for better error handling
2/ use gpiod* function
(suggested by Heiko Stuebner)
3/ split dt-binding changes to new patch
(suggested by Shawn Lin & Heiko Stuebner)

  drivers/spi/spi-rockchip.c | 31 ++-
  1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index bab9b13..4bcf251 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -16,7 +16,8 @@
  #include 
  #include 
  #include 
-#include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -663,6 +664,27 @@ static bool rockchip_spi_can_dma(struct spi_master *master,
return (xfer->len > rs->fifo_len);
  }
  
+static int rockchip_spi_setup_cs_gpios(struct device *dev)

+{
+   struct device_node *np = dev->of_node;
+   struct gpio_desc *cs_gpio;
+   int i, nb;
+
+   if (!np)
+   return 0;
+
+   nb = of_gpio_named_count(np, "cs-gpios");
+   for (i = 0; i < nb; i++) {
+   /* We support both GPIO CS and HW CS */
+   cs_gpio = devm_gpiod_get_index_optional(dev, "cs",
+   i, GPIOD_ASIS);
+   if (IS_ERR(cs_gpio))
+   return PTR_ERR(cs_gpio);
+   }
+
+   return 0;
+}
+
  static int rockchip_spi_probe(struct platform_device *pdev)
  {
int ret = 0;
@@ -749,6 +771,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->transfer_one = rockchip_spi_transfer_one;
master->max_transfer_size = rockchip_spi_max_transfer_size;
master->handle_err = rockchip_spi_handle_err;
+   master->flags = SPI_MASTER_GPIO_SS;
  
  	rs->dma_tx.ch = dma_request_chan(rs->dev, "tx");

if (IS_ERR(rs->dma_tx.ch)) {
@@ -783,6 +806,12 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->dma_rx = rs->dma_rx.ch;
}
  
+	ret = rockchip_spi_setup_cs_gpios(>dev);

+   if (ret) {
+   dev_err(>dev, "Failed to setup cs gpios\n");
+   goto err_free_dma_rx;
+   }
+
ret = devm_spi_register_master(>dev, master);
if (ret) {
dev_err(>dev, "Failed to register master\n");

Re: [PATCH v3 1/3] spi: rockchip: add support for "cs-gpios" dts property

[Caesar Wang]

Hi,

As the previous discussed on http://crosreview.com/379681, we have hit a 
failure [0] of ec's xfer, when we support the spi's pd to turn on/off. 
(Says: support the Sdioaudio pd of rk3399 on http://crosreview.com/378562)


[0]:
..
[ 5.579694 ] cros-ec-spi spi5.0: EC failed to respond in time
[ 5.585784 ] cros-ec-spi spi5.0: Transfer error 1/3: -110
..


Feels like that a workaround way to fix it, but that should be a good 
solution.



在 2017年06月14日 11:38, Jeffy Chen 写道:

Support using "cs-gpios" property to specify cs gpios.

Signed-off-by: Jeffy Chen 


Tested-by: Caesar Wang 

I have fetched these patches to test S2R with my board for chromeos4.4.

localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
...
pd_sdioaudioon
/devices/platform/ff20.spi  suspended
/devices/platform/ff88.i2s  active
/devices/platform/ff8a.i2s  suspended

-Caesar


---

Changes in v3:
include linux/gpio/consumer.h for compile errors on ARCH_X86
(reported by kbuild test robot )

Changes in v2:
1/ request cs gpios in probe for better error handling
2/ use gpiod* function
(suggested by Heiko Stuebner)
3/ split dt-binding changes to new patch
(suggested by Shawn Lin & Heiko Stuebner)

  drivers/spi/spi-rockchip.c | 31 ++-
  1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index bab9b13..4bcf251 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -16,7 +16,8 @@
  #include 
  #include 
  #include 
-#include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -663,6 +664,27 @@ static bool rockchip_spi_can_dma(struct spi_master *master,
return (xfer->len > rs->fifo_len);
  }
  
+static int rockchip_spi_setup_cs_gpios(struct device *dev)

+{
+   struct device_node *np = dev->of_node;
+   struct gpio_desc *cs_gpio;
+   int i, nb;
+
+   if (!np)
+   return 0;
+
+   nb = of_gpio_named_count(np, "cs-gpios");
+   for (i = 0; i < nb; i++) {
+   /* We support both GPIO CS and HW CS */
+   cs_gpio = devm_gpiod_get_index_optional(dev, "cs",
+   i, GPIOD_ASIS);
+   if (IS_ERR(cs_gpio))
+   return PTR_ERR(cs_gpio);
+   }
+
+   return 0;
+}
+
  static int rockchip_spi_probe(struct platform_device *pdev)
  {
int ret = 0;
@@ -749,6 +771,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->transfer_one = rockchip_spi_transfer_one;
master->max_transfer_size = rockchip_spi_max_transfer_size;
master->handle_err = rockchip_spi_handle_err;
+   master->flags = SPI_MASTER_GPIO_SS;
  
  	rs->dma_tx.ch = dma_request_chan(rs->dev, "tx");

if (IS_ERR(rs->dma_tx.ch)) {
@@ -783,6 +806,12 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->dma_rx = rs->dma_rx.ch;
}
  
+	ret = rockchip_spi_setup_cs_gpios(>dev);

+   if (ret) {
+   dev_err(>dev, "Failed to setup cs gpios\n");
+   goto err_free_dma_rx;
+   }
+
ret = devm_spi_register_master(>dev, master);
if (ret) {
dev_err(>dev, "Failed to register master\n");

Re: [PATCH] mwifiex: fixes the trivial print

[Caesar Wang]

在 2017年06月14日 18:23, Xinming Hu 写道:

Hi Caesar,

It proved to be a feature to get better scan result from overlapping channel, 
introduced in

commit 1b499cb72f26bbf44f2fa158c2d1487730aae96a
Author: Amitkumar Karwar <akar...@marvell.com>
Date:   Sun Apr 24 23:49:51 2016 -0700

 mwifiex: disable channel filtering feature in firmware
 
 As 2.4Ghz channels are overlapping, sometimes AP responds to

 probe request even if it's operating on neighbouring channel.
 Currently firmware drops those scan entries, as current channel
 doesn't match with APs channel.
 
 This patch enables MWIFIEX_DISABLE_CHAN_FILT flag in scan

 command to disable the feature so that better scan results
 will be received in 2.4Ghz band.

As I can see, even there could be AP from overlapping channel (might be 
12/13/14 in this case),  it will be filtered depend on reg domain rules
  
if (ch->flags & IEEE80211_CHAN_DISABLED)

 continue;

so it should not been an ERROR. WARN looks fine to me.
you can add me acked-by in v2.



Okay, thanks for explanation and having a look at it.


-Caesar




Regards,
Simon
From: Caesar Wang [mailto:w...@rock-chips.com]
Sent: 2017年6月13日 18:52
To: Xinming Hu; Kalle Valo; Zhiyuan Yang; Cathy Luo
Cc: amitkar...@gmail.com; Nishant Sarmukadam; Ganapathi Bhat; 
linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
linux-kernel@vger.kernel.org; briannor...@chromium.org; 
jeffy.c...@rock-chips.com; Ganapathi Bhat
Subject: [EXT] Re: [PATCH] mwifiex: fixes the trivial print

External Email

Hi Xinming,
As issue tracked on 
https://partnerissuetracker.corp.google.com/u/2/issues/62122843


在 2017年06月13日 17:51, Xinming Hu 写道:
Hi Caesar,

The original log in google issue tracker show there exist AP in channel 13 
after periodically scan.
Per my understand, if reg domain is set to US,  channel 12/13/14 will not get 
chance to scan. (test using iw/wpa_supplicant).
I am curious about whether there are any diff from upper layer.

As a test, you can print the scan channel list, as below:

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index a7593aa..a289818 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2572,6 +2572,7 @@ static int mwifiex_set_ibss_params(struct mwifiex_private 
*priv,
   MWIFIEX_USER_SCAN_CHAN_MAX); i++) {
 chan = request->channels[i];
 user_scan_cfg->chan_list[i].chan_number = chan->hw_value;
+   pr_err("chan->hw_value = %d", chan->hw_value);
 user_scan_cfg->chan_list[i].radio_type = chan->band;
  
 if ((chan->flags & IEEE80211_CHAN_NO_IR) || !request->n_ssids)


The below as the required log:
localhost / # [   46.760997] mwifiex: chan->hw_value = 1
[   46.764878] mwifiex: chan->hw_value = 2
[   46.768765] mwifiex: chan->hw_value = 3
[   46.772625] mwifiex: chan->hw_value = 4
[   46.776608] mwifiex: chan->hw_value = 5
[   46.780485] mwifiex: chan->hw_value = 6
[   46.784384] mwifiex: chan->hw_value = 7
[   46.788252] mwifiex: chan->hw_value = 8
[   46.792185] mwifiex: chan->hw_value = 9
[   46.796036] mwifiex: chan->hw_value = 10
[   46.799978] mwifiex: chan->hw_value = 11
[   46.803908] mwifiex: chan->hw_value = 38
[   46.807847] mwifiex: chan->hw_value = 42
[   46.811786] mwifiex: chan->hw_value = 46
[   46.815722] mwifiex: chan->hw_value = 36
[   46.819646] mwifiex: chan->hw_value = 40
[   46.823577] mwifiex: chan->hw_value = 44
[   46.827503] mwifiex: chan->hw_value = 48
[   46.831440] mwifiex: chan->hw_value = 52
[   46.835363] mwifiex: chan->hw_value = 56
[   46.839287] mwifiex: chan->hw_value = 60
[   46.843205] mwifiex: chan->hw_value = 64
[   46.847129] mwifiex: chan->hw_value = 100
[   46.851134] mwifiex: chan->hw_value = 104
[   46.855150] mwifiex: chan->hw_value = 108
[   46.859155] mwifiex: chan->hw_value = 112
[   46.863168] mwifiex: chan->hw_value = 116
[   46.867175] mwifiex: chan->hw_value = 120
[   46.871186] mwifiex: chan->hw_value = 124
[   46.875196] mwifiex: chan->hw_value = 128
[   46.879208] mwifiex: chan->hw_value = 132
[   46.883214] mwifiex: chan->hw_value = 136
[   46.887224] mwifiex: chan->hw_value = 140
[   46.891230] mwifiex: chan->hw_value = 149
[   46.895241] mwifiex: chan->hw_value = 153
[   46.899246] mwifiex: chan->hw_value = 157
[   46.903256] mwifiex: chan->hw_value = 161
[   46.907262] mwifiex: chan->hw_value = 165
[   47.394176] mwifiex_pcie :01:00.0: mwifiex_get_cfp: cannot find cfp by band 
2& channel=12 freq=0

-Caesar


Regards,
Simon

-Original Message-
From: Kalle Valo [mailto:kv...@codeaurora.org]
Sent: 2017年6月13日 15:53
To: Caesar W

Re: [PATCH] mwifiex: fixes the trivial print

[Caesar Wang]

在 2017年06月14日 18:23, Xinming Hu 写道:

Hi Caesar,

It proved to be a feature to get better scan result from overlapping channel, 
introduced in

commit 1b499cb72f26bbf44f2fa158c2d1487730aae96a
Author: Amitkumar Karwar 
Date:   Sun Apr 24 23:49:51 2016 -0700

 mwifiex: disable channel filtering feature in firmware
 
 As 2.4Ghz channels are overlapping, sometimes AP responds to

 probe request even if it's operating on neighbouring channel.
 Currently firmware drops those scan entries, as current channel
 doesn't match with APs channel.
 
 This patch enables MWIFIEX_DISABLE_CHAN_FILT flag in scan

 command to disable the feature so that better scan results
 will be received in 2.4Ghz band.

As I can see, even there could be AP from overlapping channel (might be 
12/13/14 in this case),  it will be filtered depend on reg domain rules
  
if (ch->flags & IEEE80211_CHAN_DISABLED)

 continue;

so it should not been an ERROR. WARN looks fine to me.
you can add me acked-by in v2.



Okay, thanks for explanation and having a look at it.


-Caesar




Regards,
Simon
From: Caesar Wang [mailto:w...@rock-chips.com]
Sent: 2017年6月13日 18:52
To: Xinming Hu; Kalle Valo; Zhiyuan Yang; Cathy Luo
Cc: amitkar...@gmail.com; Nishant Sarmukadam; Ganapathi Bhat; 
linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
linux-kernel@vger.kernel.org; briannor...@chromium.org; 
jeffy.c...@rock-chips.com; Ganapathi Bhat
Subject: [EXT] Re: [PATCH] mwifiex: fixes the trivial print

External Email

Hi Xinming,
As issue tracked on 
https://partnerissuetracker.corp.google.com/u/2/issues/62122843


在 2017年06月13日 17:51, Xinming Hu 写道:
Hi Caesar,

The original log in google issue tracker show there exist AP in channel 13 
after periodically scan.
Per my understand, if reg domain is set to US,  channel 12/13/14 will not get 
chance to scan. (test using iw/wpa_supplicant).
I am curious about whether there are any diff from upper layer.

As a test, you can print the scan channel list, as below:

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index a7593aa..a289818 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2572,6 +2572,7 @@ static int mwifiex_set_ibss_params(struct mwifiex_private 
*priv,
   MWIFIEX_USER_SCAN_CHAN_MAX); i++) {
 chan = request->channels[i];
 user_scan_cfg->chan_list[i].chan_number = chan->hw_value;
+   pr_err("chan->hw_value = %d", chan->hw_value);
 user_scan_cfg->chan_list[i].radio_type = chan->band;
  
 if ((chan->flags & IEEE80211_CHAN_NO_IR) || !request->n_ssids)


The below as the required log:
localhost / # [   46.760997] mwifiex: chan->hw_value = 1
[   46.764878] mwifiex: chan->hw_value = 2
[   46.768765] mwifiex: chan->hw_value = 3
[   46.772625] mwifiex: chan->hw_value = 4
[   46.776608] mwifiex: chan->hw_value = 5
[   46.780485] mwifiex: chan->hw_value = 6
[   46.784384] mwifiex: chan->hw_value = 7
[   46.788252] mwifiex: chan->hw_value = 8
[   46.792185] mwifiex: chan->hw_value = 9
[   46.796036] mwifiex: chan->hw_value = 10
[   46.799978] mwifiex: chan->hw_value = 11
[   46.803908] mwifiex: chan->hw_value = 38
[   46.807847] mwifiex: chan->hw_value = 42
[   46.811786] mwifiex: chan->hw_value = 46
[   46.815722] mwifiex: chan->hw_value = 36
[   46.819646] mwifiex: chan->hw_value = 40
[   46.823577] mwifiex: chan->hw_value = 44
[   46.827503] mwifiex: chan->hw_value = 48
[   46.831440] mwifiex: chan->hw_value = 52
[   46.835363] mwifiex: chan->hw_value = 56
[   46.839287] mwifiex: chan->hw_value = 60
[   46.843205] mwifiex: chan->hw_value = 64
[   46.847129] mwifiex: chan->hw_value = 100
[   46.851134] mwifiex: chan->hw_value = 104
[   46.855150] mwifiex: chan->hw_value = 108
[   46.859155] mwifiex: chan->hw_value = 112
[   46.863168] mwifiex: chan->hw_value = 116
[   46.867175] mwifiex: chan->hw_value = 120
[   46.871186] mwifiex: chan->hw_value = 124
[   46.875196] mwifiex: chan->hw_value = 128
[   46.879208] mwifiex: chan->hw_value = 132
[   46.883214] mwifiex: chan->hw_value = 136
[   46.887224] mwifiex: chan->hw_value = 140
[   46.891230] mwifiex: chan->hw_value = 149
[   46.895241] mwifiex: chan->hw_value = 153
[   46.899246] mwifiex: chan->hw_value = 157
[   46.903256] mwifiex: chan->hw_value = 161
[   46.907262] mwifiex: chan->hw_value = 165
[   47.394176] mwifiex_pcie :01:00.0: mwifiex_get_cfp: cannot find cfp by band 
2    & channel=12 freq=0

-Caesar


Regards,
Simon

-Original Message-
From: Kalle Valo [mailto:kv...@codeaurora.org]
Sent: 2017年6月13日 15:53
To: Caesar Wang
Cc: amitkar...@gma

[PATCH v2] mwifiex: fixes the unexpected be printed log by default

[Caesar Wang]

This patch uses WARN level is not printed by default.

In some cases, some boards have always met the unused log be printed as
follows.
...
[23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0
[23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0

Due to we used the wifi default area was US and didn't support 12~14
channels. As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)

Also, as the commit 1b499cb72f26b
("mwifiex: disable channel filtering feature in firmware"), it proved to
be a feature to get better scan result from overlapping channel.

Even there could be AP from overlapping channel (might be 12/13/14
in this case), it will be filtered depend on reg domain rules.
e.g:
...
if (ch->flags & IEEE80211_CHAN_DISABLED)
continue;

So it should not been an ERROR, use the WARN level to instead it for now.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
Acked-by: Xinming Hu <h...@marvell.com>
---

Changes in v2:
- Fixes the commit and title as Kalle and Xinming comments on
  https://patchwork.kernel.org/patch/9786047/
- Add the Acked by "HU Xinming"

 drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 
channel, u32 freq)
}
}
if (i == sband->n_channels) {
-   mwifiex_dbg(priv->adapter, ERROR,
+   mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);
-- 
2.7.4

[PATCH v2] mwifiex: fixes the unexpected be printed log by default

[Caesar Wang]

This patch uses WARN level is not printed by default.

In some cases, some boards have always met the unused log be printed as
follows.
...
[23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0
[23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0

Due to we used the wifi default area was US and didn't support 12~14
channels. As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)

Also, as the commit 1b499cb72f26b
("mwifiex: disable channel filtering feature in firmware"), it proved to
be a feature to get better scan result from overlapping channel.

Even there could be AP from overlapping channel (might be 12/13/14
in this case), it will be filtered depend on reg domain rules.
e.g:
...
if (ch->flags & IEEE80211_CHAN_DISABLED)
continue;

So it should not been an ERROR, use the WARN level to instead it for now.

Signed-off-by: Caesar Wang 
Acked-by: Xinming Hu 
---

Changes in v2:
- Fixes the commit and title as Kalle and Xinming comments on
  https://patchwork.kernel.org/patch/9786047/
- Add the Acked by "HU Xinming"

 drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 
channel, u32 freq)
}
}
if (i == sband->n_channels) {
-   mwifiex_dbg(priv->adapter, ERROR,
+   mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);
-- 
2.7.4

Re: [PATCH] mwifiex: fixes the trivial print

[Caesar Wang]

在 2017年06月13日 15:04, Kalle Valo 写道:

Caesar Wang <w...@rock-chips.com> writes:


Kalle,

在 2017年06月13日 14:28, Kalle Valo 写道:

Caesar Wang <w...@rock-chips.com> writes:


We have always met the unused log be printed as following.

...
[23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0
[23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0

Maybe that's related to wifi regdom, since wifi default area
was US and didn't support 12~14 channels.

As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

   drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 
channel, u32 freq)
}
}
if (i == sband->n_channels) {
-   mwifiex_dbg(priv->adapter, ERROR,
+   mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);

I don't see how this fixes anything, care to explain? And the title is
quite vague.

Sorry for the description maybe unclear.
I'm assuming the print log is expected for marvel wifi driver. Do we
should use 'WARN' to instead of the 'ERROR' here.

But does that make any functional difference, isn't the warning still
printed?



At least, that shouldn't be printed log by default.  :)

if I read the code is correct. That only the MSG/FATAL/ERROR will output 
by default.


/**
 *enum mwifiex_debug_level  -  marvell wifi debug level
 */
enum MWIFIEX_DEBUG_LEVEL {
MWIFIEX_DBG_MSG= 0x0001,
MWIFIEX_DBG_FATAL= 0x0002,
MWIFIEX_DBG_ERROR= 0x0004,
MWIFIEX_DBG_DATA= 0x0008,
MWIFIEX_DBG_CMD= 0x0010,
MWIFIEX_DBG_EVENT= 0x0020,
MWIFIEX_DBG_INTR= 0x0040,
MWIFIEX_DBG_IOCTL= 0x0080,

MWIFIEX_DBG_MPA_D= 0x8000,
MWIFIEX_DBG_DAT_D= 0x0001,
MWIFIEX_DBG_CMD_D= 0x0002,
MWIFIEX_DBG_EVT_D= 0x0004,
MWIFIEX_DBG_FW_D= 0x0008,
MWIFIEX_DBG_IF_D= 0x0010,

MWIFIEX_DBG_ENTRY= 0x1000,
MWIFIEX_DBG_WARN= 0x2000,
MWIFIEX_DBG_INFO= 0x4000,
MWIFIEX_DBG_DUMP= 0x8000,

MWIFIEX_DBG_ANY= 0x
};

#define MWIFIEX_DEFAULT_DEBUG_MASK(MWIFIEX_DBG_MSG | \
MWIFIEX_DBG_FATAL | \
MWIFIEX_DBG_ERROR)

Re: [PATCH] mwifiex: fixes the trivial print

[Caesar Wang]

在 2017年06月13日 15:04, Kalle Valo 写道:

Caesar Wang  writes:


Kalle,

在 2017年06月13日 14:28, Kalle Valo 写道:

Caesar Wang  writes:


We have always met the unused log be printed as following.

...
[23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0
[23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0

Maybe that's related to wifi regdom, since wifi default area
was US and didn't support 12~14 channels.

As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)

Signed-off-by: Caesar Wang 
---

   drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 
channel, u32 freq)
}
}
if (i == sband->n_channels) {
-   mwifiex_dbg(priv->adapter, ERROR,
+   mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);

I don't see how this fixes anything, care to explain? And the title is
quite vague.

Sorry for the description maybe unclear.
I'm assuming the print log is expected for marvel wifi driver. Do we
should use 'WARN' to instead of the 'ERROR' here.

But does that make any functional difference, isn't the warning still
printed?



At least, that shouldn't be printed log by default.  :)

if I read the code is correct. That only the MSG/FATAL/ERROR will output 
by default.


/**
 *enum mwifiex_debug_level  -  marvell wifi debug level
 */
enum MWIFIEX_DEBUG_LEVEL {
MWIFIEX_DBG_MSG= 0x0001,
MWIFIEX_DBG_FATAL= 0x0002,
MWIFIEX_DBG_ERROR= 0x0004,
MWIFIEX_DBG_DATA= 0x0008,
MWIFIEX_DBG_CMD= 0x0010,
MWIFIEX_DBG_EVENT= 0x0020,
MWIFIEX_DBG_INTR= 0x0040,
MWIFIEX_DBG_IOCTL= 0x0080,

MWIFIEX_DBG_MPA_D= 0x8000,
MWIFIEX_DBG_DAT_D= 0x0001,
MWIFIEX_DBG_CMD_D= 0x0002,
MWIFIEX_DBG_EVT_D= 0x0004,
MWIFIEX_DBG_FW_D= 0x0008,
MWIFIEX_DBG_IF_D= 0x0010,

MWIFIEX_DBG_ENTRY= 0x1000,
MWIFIEX_DBG_WARN= 0x2000,
MWIFIEX_DBG_INFO= 0x4000,
MWIFIEX_DBG_DUMP= 0x8000,

MWIFIEX_DBG_ANY= 0x
};

#define MWIFIEX_DEFAULT_DEBUG_MASK(MWIFIEX_DBG_MSG | \
MWIFIEX_DBG_FATAL | \
MWIFIEX_DBG_ERROR)

Re: [PATCH] mwifiex: fixes the trivial print

[Caesar Wang]

Kalle,

在 2017年06月13日 14:28, Kalle Valo 写道:

Caesar Wang <w...@rock-chips.com> writes:


We have always met the unused log be printed as following.

...
[23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0
[23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0

Maybe that's related to wifi regdom, since wifi default area
was US and didn't support 12~14 channels.

As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

  drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 
channel, u32 freq)
}
}
if (i == sband->n_channels) {
-   mwifiex_dbg(priv->adapter, ERROR,
+   mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);

I don't see how this fixes anything, care to explain? And the title is
quite vague.


Sorry for the description maybe unclear.
I'm assuming the print log is expected for marvel wifi driver. Do we 
should use 'WARN' to instead of the 'ERROR' here.




And I would rather fix the root cause, mwifiex folks please comment.


Indeed, that's my expected.


-Caesar

Re: [PATCH] mwifiex: fixes the trivial print

[Caesar Wang]

Kalle,

在 2017年06月13日 14:28, Kalle Valo 写道:

Caesar Wang  writes:


We have always met the unused log be printed as following.

...
[23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0
[23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0

Maybe that's related to wifi regdom, since wifi default area
was US and didn't support 12~14 channels.

As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)

Signed-off-by: Caesar Wang 
---

  drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 
channel, u32 freq)
}
}
if (i == sband->n_channels) {
-   mwifiex_dbg(priv->adapter, ERROR,
+   mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);

I don't see how this fixes anything, care to explain? And the title is
quite vague.


Sorry for the description maybe unclear.
I'm assuming the print log is expected for marvel wifi driver. Do we 
should use 'WARN' to instead of the 'ERROR' here.




And I would rather fix the root cause, mwifiex folks please comment.


Indeed, that's my expected.


-Caesar

[PATCH] mwifiex: fixes the trivial print

[Caesar Wang]

We have always met the unused log be printed as following.

...
[23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0
[23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0

Maybe that's related to wifi regdom, since wifi default area
was US and didn't support 12~14 channels.

As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

 drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 
channel, u32 freq)
}
}
if (i == sband->n_channels) {
-   mwifiex_dbg(priv->adapter, ERROR,
+   mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);
-- 
2.7.4

[PATCH] mwifiex: fixes the trivial print

[Caesar Wang]

We have always met the unused log be printed as following.

...
[23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0
[23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2& channel=13 freq=0

Maybe that's related to wifi regdom, since wifi default area
was US and didn't support 12~14 channels.

As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)

Signed-off-by: Caesar Wang 
---

 drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 
channel, u32 freq)
}
}
if (i == sband->n_channels) {
-   mwifiex_dbg(priv->adapter, ERROR,
+   mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);
-- 
2.7.4

[PATCH] drm/rockchip: gem: add the lacks lock and trivial changes

[Caesar Wang]

As the allocation and free buffer that need to add mutex lock for drm mm,
but it lacks the locking on error path in rockchip_gem_iommu_map().
Also, the trivial changes like The comment should be  placed in the
kerneldoc and unused blank line.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 47905fa..c7e96b8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -45,13 +45,13 @@ struct rockchip_crtc_state {
  *
  * @crtc: array of enabled CRTCs, used to map from "pipe" to drm_crtc.
  * @num_pipe: number of pipes for this device.
+ * @mm_lock: protect drm_mm on multi-threads.
  */
 struct rockchip_drm_private {
struct drm_fb_helper fbdev_helper;
struct drm_gem_object *fbdev_bo;
struct drm_atomic_state *state;
struct iommu_domain *domain;
-   /* protect drm_mm on multi-threads */
struct mutex mm_lock;
struct drm_mm mm;
struct list_head psr_list;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..b74ac71 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -29,12 +29,11 @@ static int rockchip_gem_iommu_map(struct 
rockchip_gem_object *rk_obj)
ssize_t ret;
 
mutex_lock(>mm_lock);
-
ret = drm_mm_insert_node_generic(>mm, _obj->mm,
 rk_obj->base.size, PAGE_SIZE,
 0, 0);
-
mutex_unlock(>mm_lock);
+
if (ret < 0) {
DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
return ret;
@@ -56,7 +55,9 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object 
*rk_obj)
return 0;
 
 err_remove_node:
+   mutex_lock(>mm_lock);
drm_mm_remove_node(_obj->mm);
+   mutex_unlock(>mm_lock);
 
return ret;
 }
-- 
2.7.4

[PATCH] drm/rockchip: gem: add the lacks lock and trivial changes

[Caesar Wang]

As the allocation and free buffer that need to add mutex lock for drm mm,
but it lacks the locking on error path in rockchip_gem_iommu_map().
Also, the trivial changes like The comment should be  placed in the
kerneldoc and unused blank line.

Signed-off-by: Caesar Wang 
---

 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 47905fa..c7e96b8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -45,13 +45,13 @@ struct rockchip_crtc_state {
  *
  * @crtc: array of enabled CRTCs, used to map from "pipe" to drm_crtc.
  * @num_pipe: number of pipes for this device.
+ * @mm_lock: protect drm_mm on multi-threads.
  */
 struct rockchip_drm_private {
struct drm_fb_helper fbdev_helper;
struct drm_gem_object *fbdev_bo;
struct drm_atomic_state *state;
struct iommu_domain *domain;
-   /* protect drm_mm on multi-threads */
struct mutex mm_lock;
struct drm_mm mm;
struct list_head psr_list;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..b74ac71 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -29,12 +29,11 @@ static int rockchip_gem_iommu_map(struct 
rockchip_gem_object *rk_obj)
ssize_t ret;
 
mutex_lock(>mm_lock);
-
ret = drm_mm_insert_node_generic(>mm, _obj->mm,
 rk_obj->base.size, PAGE_SIZE,
 0, 0);
-
mutex_unlock(>mm_lock);
+
if (ret < 0) {
DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
return ret;
@@ -56,7 +55,9 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object 
*rk_obj)
return 0;
 
 err_remove_node:
+   mutex_lock(>mm_lock);
drm_mm_remove_node(_obj->mm);
+   mutex_unlock(>mm_lock);
 
return ret;
 }
-- 
2.7.4

Re: [PATCH] arm64: dts: rockchip: update cpu opp table for rk3399 op1

[Caesar Wang]

在 2017年04月24日 16:26, Heiko Stübner 写道:

Hi Caesar,

Am Montag, 24. April 2017, 14:18:50 CEST schrieb Caesar Wang:

Update the cpu opp table for rk3399 op1.

Ideally this should contain something about the "why".
Are these new voltage settings safer to operate under?


The before opp table is for earlier batch of rk3399 SoCs,  that's no 
enough for the current and
newer batch of rk3399 op1. In order to suit for the rk3399 op1, we need 
to little voltages changed.


-Caesar



No need to resend, please just clarify the reason.


Thanks
Heiko


Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

  arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi index dd82e16..92bd615
100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -52,27 +52,27 @@
};
opp01 {
opp-hz = /bits/ 64 <6>;
-   opp-microvolt = <80>;
+   opp-microvolt = <825000>;
};
opp02 {
opp-hz = /bits/ 64 <81600>;
-   opp-microvolt = <80>;
+   opp-microvolt = <85>;
};
opp03 {
opp-hz = /bits/ 64 <100800>;
-   opp-microvolt = <875000>;
+   opp-microvolt = <90>;
};
opp04 {
opp-hz = /bits/ 64 <12>;
-   opp-microvolt = <925000>;
+   opp-microvolt = <975000>;
};
opp05 {
opp-hz = /bits/ 64 <141600>;
-   opp-microvolt = <105>;
+   opp-microvolt = <110>;
};
opp06 {
opp-hz = /bits/ 64 <151200>;
-   opp-microvolt = <1125000>;
+   opp-microvolt = <115>;
};
};

Re: [PATCH] arm64: dts: rockchip: update cpu opp table for rk3399 op1

[Caesar Wang]

在 2017年04月24日 16:26, Heiko Stübner 写道:

Hi Caesar,

Am Montag, 24. April 2017, 14:18:50 CEST schrieb Caesar Wang:

Update the cpu opp table for rk3399 op1.

Ideally this should contain something about the "why".
Are these new voltage settings safer to operate under?


The before opp table is for earlier batch of rk3399 SoCs,  that's no 
enough for the current and
newer batch of rk3399 op1. In order to suit for the rk3399 op1, we need 
to little voltages changed.


-Caesar



No need to resend, please just clarify the reason.


Thanks
Heiko


Signed-off-by: Caesar Wang 
---

  arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi index dd82e16..92bd615
100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -52,27 +52,27 @@
};
opp01 {
opp-hz = /bits/ 64 <6>;
-   opp-microvolt = <80>;
+   opp-microvolt = <825000>;
};
opp02 {
opp-hz = /bits/ 64 <81600>;
-   opp-microvolt = <80>;
+   opp-microvolt = <85>;
};
opp03 {
opp-hz = /bits/ 64 <100800>;
-   opp-microvolt = <875000>;
+   opp-microvolt = <90>;
};
opp04 {
opp-hz = /bits/ 64 <12>;
-   opp-microvolt = <925000>;
+   opp-microvolt = <975000>;
};
opp05 {
opp-hz = /bits/ 64 <141600>;
-   opp-microvolt = <105>;
+   opp-microvolt = <110>;
};
opp06 {
opp-hz = /bits/ 64 <151200>;
-   opp-microvolt = <1125000>;
+   opp-microvolt = <115>;
};
};

[PATCH] arm64: dts: rockchip: update cpu opp table for rk3399 op1

[Caesar Wang]

Update the cpu opp table for rk3399 op1.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index dd82e16..92bd615 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -52,27 +52,27 @@
};
opp01 {
opp-hz = /bits/ 64 <6>;
-   opp-microvolt = <80>;
+   opp-microvolt = <825000>;
};
opp02 {
opp-hz = /bits/ 64 <81600>;
-   opp-microvolt = <80>;
+   opp-microvolt = <85>;
};
opp03 {
opp-hz = /bits/ 64 <100800>;
-   opp-microvolt = <875000>;
+   opp-microvolt = <90>;
};
opp04 {
opp-hz = /bits/ 64 <12>;
-   opp-microvolt = <925000>;
+   opp-microvolt = <975000>;
};
opp05 {
opp-hz = /bits/ 64 <141600>;
-   opp-microvolt = <105>;
+   opp-microvolt = <110>;
};
opp06 {
opp-hz = /bits/ 64 <151200>;
-   opp-microvolt = <1125000>;
+   opp-microvolt = <115>;
};
};
 
-- 
2.7.4

[PATCH] arm64: dts: rockchip: update cpu opp table for rk3399 op1

[Caesar Wang]

Update the cpu opp table for rk3399 op1.

Signed-off-by: Caesar Wang 
---

 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index dd82e16..92bd615 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -52,27 +52,27 @@
};
opp01 {
opp-hz = /bits/ 64 <6>;
-   opp-microvolt = <80>;
+   opp-microvolt = <825000>;
};
opp02 {
opp-hz = /bits/ 64 <81600>;
-   opp-microvolt = <80>;
+   opp-microvolt = <85>;
};
opp03 {
opp-hz = /bits/ 64 <100800>;
-   opp-microvolt = <875000>;
+   opp-microvolt = <90>;
};
opp04 {
opp-hz = /bits/ 64 <12>;
-   opp-microvolt = <925000>;
+   opp-microvolt = <975000>;
};
opp05 {
opp-hz = /bits/ 64 <141600>;
-   opp-microvolt = <105>;
+   opp-microvolt = <110>;
};
opp06 {
opp-hz = /bits/ 64 <151200>;
-   opp-microvolt = <1125000>;
+   opp-microvolt = <115>;
};
};
 
-- 
2.7.4

Re: iommu/rockchip: Fix bugs and enable on ARM64

[Caesar Wang]

Shunqian,
something is depending on these patches, can you resend these patches to 
solve the

compile errors?

-Caesar
在 2016年07月16日 00:16, Joerg Roedel 写道:

On Fri, Jul 15, 2016 at 05:32:02PM +0200, Matthias Brugger wrote:

The drm rockchip patches are dependent on iommu/rockchip patches, can
you also apply these patches together? So that can avoid compile problem.


While at it. I don't see patch 8 (iommu/Kconfig) in linux-next.
I suppose you forgot to pick that one.

I picked it up first, but it causes compile errors, so I removed it for
now.


Joerg


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: iommu/rockchip: Fix bugs and enable on ARM64

[Caesar Wang]

Shunqian,
something is depending on these patches, can you resend these patches to 
solve the

compile errors?

-Caesar
在 2016年07月16日 00:16, Joerg Roedel 写道:

On Fri, Jul 15, 2016 at 05:32:02PM +0200, Matthias Brugger wrote:

The drm rockchip patches are dependent on iommu/rockchip patches, can
you also apply these patches together? So that can avoid compile problem.


While at it. I don't see patch 8 (iommu/Kconfig) in linux-next.
I suppose you forgot to pick that one.

I picked it up first, but it causes compile errors, so I removed it for
now.


Joerg


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] thermal: rockchip: fixes the conversion table

[Caesar Wang]

As Ayaka reported the thermal was abormal on rk3288 at booting time.
thermal thermal_zone1: critical temperature reached(125 C),shutting down
thermal thermal_zone2: critical temperature reached(125 C),shutting down
thermal thermal_zone1: critical temperature reached(125 C),shutting down
thermal thermal_zone2: critical temperature reached(125 C),shutting down
...
The root caused by reading the invald analogic value, the value is zero
will convert the 125 degree to trigger the critical temperature.
Fixes it with insteading of the incorrect reading now.

Fixes commit cadf29dc2a8bcaae83
("thermal: rockchip: optimize the conversion table")

Reported-by: ayaka <ay...@soulik.info>
Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index cbbf0ce..4c77965 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -464,7 +464,7 @@ static int rk_tsadcv2_code_to_temp(const struct 
chip_tsadc_table *table,
switch (table->mode) {
case ADC_DECREMENT:
code &= table->data_mask;
-   if (code < table->id[high].code)
+   if (code <= table->id[high].code)
return -EAGAIN; /* Incorrect reading */
 
while (low <= high) {
-- 
2.7.4

[PATCH] thermal: rockchip: fixes the conversion table

[Caesar Wang]

As Ayaka reported the thermal was abormal on rk3288 at booting time.
thermal thermal_zone1: critical temperature reached(125 C),shutting down
thermal thermal_zone2: critical temperature reached(125 C),shutting down
thermal thermal_zone1: critical temperature reached(125 C),shutting down
thermal thermal_zone2: critical temperature reached(125 C),shutting down
...
The root caused by reading the invald analogic value, the value is zero
will convert the 125 degree to trigger the critical temperature.
Fixes it with insteading of the incorrect reading now.

Fixes commit cadf29dc2a8bcaae83
("thermal: rockchip: optimize the conversion table")

Reported-by: ayaka 
Signed-off-by: Caesar Wang 
---

 drivers/thermal/rockchip_thermal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index cbbf0ce..4c77965 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -464,7 +464,7 @@ static int rk_tsadcv2_code_to_temp(const struct 
chip_tsadc_table *table,
switch (table->mode) {
case ADC_DECREMENT:
code &= table->data_mask;
-   if (code < table->id[high].code)
+   if (code <= table->id[high].code)
return -EAGAIN; /* Incorrect reading */
 
while (low <= high) {
-- 
2.7.4

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[Caesar Wang]

在 2017年01月03日 07:57, Randy Li 写道:


On 01/02/2017 09:16 PM, Caesar Wang wrote:

在 2016年12月31日 00:11, ayaka 写道:


BTW, Caesar have you ever met this at RK3288 at booting time?
[8.430582] thermal thermal_zone1: critical temperature 
reached(125 C),shutting down
[8.439038] thermal thermal_zone2: critical temperature 
reached(125 C),shutting down
[8.456344] thermal thermal_zone1: critical temperature 
reached(125 C),shutting down
[8.465298] thermal thermal_zone2: critical temperature 
reached(125 C),shutting down


125C? the thermal zone isn't the upstream kernel, what's the kernel 
version?

They have been merged into the linux-next.


Really?
I saw the 90 degree is the critical temperature on rk3288 dts .
kernel$ vi arch/arm/boot/dts/rk3288.dtsi
cpu_crit: cpu_crit {
temperature = <9>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "critical";
};

Anyway, look like,  the TSHUT issue. Do you have the below patches 
for your linux kernel?
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380446.html 


No, could you resubmit those patches ?


These patches had merged for upstream.

-Caesar

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[Caesar Wang]

在 2017年01月03日 07:57, Randy Li 写道:


On 01/02/2017 09:16 PM, Caesar Wang wrote:

在 2016年12月31日 00:11, ayaka 写道:


BTW, Caesar have you ever met this at RK3288 at booting time?
[8.430582] thermal thermal_zone1: critical temperature 
reached(125 C),shutting down
[8.439038] thermal thermal_zone2: critical temperature 
reached(125 C),shutting down
[8.456344] thermal thermal_zone1: critical temperature 
reached(125 C),shutting down
[8.465298] thermal thermal_zone2: critical temperature 
reached(125 C),shutting down


125C? the thermal zone isn't the upstream kernel, what's the kernel 
version?

They have been merged into the linux-next.


Really?
I saw the 90 degree is the critical temperature on rk3288 dts .
kernel$ vi arch/arm/boot/dts/rk3288.dtsi
cpu_crit: cpu_crit {
temperature = <9>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "critical";
};

Anyway, look like,  the TSHUT issue. Do you have the below patches 
for your linux kernel?
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380446.html 


No, could you resubmit those patches ?


These patches had merged for upstream.

-Caesar

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[Caesar Wang]

在 2016年12月31日 00:11, ayaka 写道:


BTW, Caesar have you ever met this at RK3288 at booting time?
[8.430582] thermal thermal_zone1: critical temperature reached(125 
C),shutting down
[8.439038] thermal thermal_zone2: critical temperature reached(125 
C),shutting down
[8.456344] thermal thermal_zone1: critical temperature reached(125 
C),shutting down
[8.465298] thermal thermal_zone2: critical temperature reached(125 
C),shutting down


125C? the thermal zone isn't the upstream kernel, what's the kernel 
version?
Anyway, look like,  the TSHUT issue. Do you have the below patches for 
your linux kernel?

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380446.html


-Caesar



On 12/12/2016 07:05 PM, Caesar Wang wrote:

There are five patches posted for upstream.
89267b5 thermal: rockchip: improve conversion error messages
a0b5649 thermal: rockchip: don't pass table structs by value
bceed92 thermal: rockchip: fixes invalid temperature case
30be6d0 thermal: rockchip: optimize the conversion table
35636e9 thermal: rockchip: handle the set_trips without the trip points.
--

History version:
V1:
https://lkml.org/lkml/2016/11/22/250
V2:
https://lkml.org/lkml/2016/11/23/348
V3:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1281432.html
---

Brain posted the below patches for upstream.
89267b5 thermal: rockchip: improve conversion error messages
a0b5649 thermal: rockchip: don't pass table structs by value
That make sense to improve efficiency

Caesar post the below patches for upstream.
bceed92 thermal: rockchip: fixes invalid temperature case
30be6d0 thermal: rockchip: optimize the conversion table
35636e9 thermal: rockchip: handle the set_trips without the trip points.
That will fixes some issues in special cases.
--

Anyway, this series patches should can improve the rockchip thermal 
driver.



Changes in v4:
- As Eduardo and Brian commnets on
   https://patchwork.kernel.org/patch/9449301
- Print a better name.
- As Eduardo commented on https://patchwork.kernel.org/patch/9449313/
- remove the Brain's review for previous version, since the new version
   update something.

Changes in v3:
- fix trivial thing for error message nd return value.
- change the commit.
- Fixes something as Brian comments on

Changes in v2:
- As Brian commnets that restructure this to pass error codes back to 
the

   upper layers.
- Improve the commit message.
- improve the commit as Brian commnets on 
https://patchwork.kernel.org/patch/9440985

- Fixes something as Brian comments on
   https://patchwork.kernel.org/patch/9440989.

Changes in v1:
- The original Brian posted on 
https://patchwork.kernel.org/patch/9437686
   Note: it'd probably be even nicer to know which sensor this was, 
but we've

   kinda abstracted that one away by this point...
- The original Brian posted on 
https://patchwork.kernel.org/patch/9437687


Brian Norris (2):
   thermal: rockchip: improve conversion error messages
   thermal: rockchip: don't pass table structs by value

Caesar Wang (3):
   thermal: rockchip: fixes invalid temperature case
   thermal: rockchip: optimize the conversion table
   thermal: rockchip: handle set_trips without the trip points

  drivers/thermal/rockchip_thermal.c | 153 
-

  1 file changed, 100 insertions(+), 53 deletions(-)

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[Caesar Wang]

在 2016年12月31日 00:11, ayaka 写道:


BTW, Caesar have you ever met this at RK3288 at booting time?
[8.430582] thermal thermal_zone1: critical temperature reached(125 
C),shutting down
[8.439038] thermal thermal_zone2: critical temperature reached(125 
C),shutting down
[8.456344] thermal thermal_zone1: critical temperature reached(125 
C),shutting down
[8.465298] thermal thermal_zone2: critical temperature reached(125 
C),shutting down


125C? the thermal zone isn't the upstream kernel, what's the kernel 
version?
Anyway, look like,  the TSHUT issue. Do you have the below patches for 
your linux kernel?

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380446.html


-Caesar



On 12/12/2016 07:05 PM, Caesar Wang wrote:

There are five patches posted for upstream.
89267b5 thermal: rockchip: improve conversion error messages
a0b5649 thermal: rockchip: don't pass table structs by value
bceed92 thermal: rockchip: fixes invalid temperature case
30be6d0 thermal: rockchip: optimize the conversion table
35636e9 thermal: rockchip: handle the set_trips without the trip points.
--

History version:
V1:
https://lkml.org/lkml/2016/11/22/250
V2:
https://lkml.org/lkml/2016/11/23/348
V3:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1281432.html
---

Brain posted the below patches for upstream.
89267b5 thermal: rockchip: improve conversion error messages
a0b5649 thermal: rockchip: don't pass table structs by value
That make sense to improve efficiency

Caesar post the below patches for upstream.
bceed92 thermal: rockchip: fixes invalid temperature case
30be6d0 thermal: rockchip: optimize the conversion table
35636e9 thermal: rockchip: handle the set_trips without the trip points.
That will fixes some issues in special cases.
--

Anyway, this series patches should can improve the rockchip thermal 
driver.



Changes in v4:
- As Eduardo and Brian commnets on
   https://patchwork.kernel.org/patch/9449301
- Print a better name.
- As Eduardo commented on https://patchwork.kernel.org/patch/9449313/
- remove the Brain's review for previous version, since the new version
   update something.

Changes in v3:
- fix trivial thing for error message nd return value.
- change the commit.
- Fixes something as Brian comments on

Changes in v2:
- As Brian commnets that restructure this to pass error codes back to 
the

   upper layers.
- Improve the commit message.
- improve the commit as Brian commnets on 
https://patchwork.kernel.org/patch/9440985

- Fixes something as Brian comments on
   https://patchwork.kernel.org/patch/9440989.

Changes in v1:
- The original Brian posted on 
https://patchwork.kernel.org/patch/9437686
   Note: it'd probably be even nicer to know which sensor this was, 
but we've

   kinda abstracted that one away by this point...
- The original Brian posted on 
https://patchwork.kernel.org/patch/9437687


Brian Norris (2):
   thermal: rockchip: improve conversion error messages
   thermal: rockchip: don't pass table structs by value

Caesar Wang (3):
   thermal: rockchip: fixes invalid temperature case
   thermal: rockchip: optimize the conversion table
   thermal: rockchip: handle set_trips without the trip points

  drivers/thermal/rockchip_thermal.c | 153 
-

  1 file changed, 100 insertions(+), 53 deletions(-)

Re: [PATCH] spi: rockchip: support "sleep" pin configuration

[Caesar Wang]

在 2016年12月17日 08:59, Brian Norris 写道:

In the pattern of many other devices, support a system-sleep pin
configuration.

Signed-off-by: Brian Norris <briannor...@chromium.org>


Tested-by: Caesar Wang <w...@rock-chips.com>


---
  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 7 +++
  drivers/spi/spi-rockchip.c | 5 +
  2 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt 
b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index d2ca153614f9..83da4931d832 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -31,6 +31,10 @@ Optional Properties:
  - rx-sample-delay-ns: nanoseconds to delay after the SCLK edge before sampling
Rx data (may need to be fine tuned for high capacitance lines).
No delay (0) by default.
+- pinctrl-names: Names for the pin configuration(s); may be "default" or
+   "sleep", where the "sleep" configuration may describe the state
+   the pins should be in during system suspend. See also
+   pinctrl/pinctrl-bindings.txt.
  
  
  Example:

@@ -46,4 +50,7 @@ Example:
interrupts = ;
clocks = < SCLK_SPI0>, < PCLK_SPI0>;
clock-names = "spiclk", "apb_pclk";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_sleep>;
+   pinctrl-names = "default", "sleep";
};
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 0f89c2169c24..acf31f36b898 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -843,6 +844,8 @@ static int rockchip_spi_suspend(struct device *dev)
clk_disable_unprepare(rs->apb_pclk);
}
  
+	pinctrl_pm_select_sleep_state(dev);

+
return ret;
  }
  
@@ -852,6 +855,8 @@ static int rockchip_spi_resume(struct device *dev)

struct spi_master *master = dev_get_drvdata(dev);
struct rockchip_spi *rs = spi_master_get_devdata(master);
  
+	pinctrl_pm_select_default_state(dev);

+
if (!pm_runtime_suspended(dev)) {
ret = clk_prepare_enable(rs->apb_pclk);
if (ret < 0)

Re: [PATCH] spi: rockchip: support "sleep" pin configuration

[Caesar Wang]

在 2016年12月17日 08:59, Brian Norris 写道:

In the pattern of many other devices, support a system-sleep pin
configuration.

Signed-off-by: Brian Norris 


Tested-by: Caesar Wang 


---
  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 7 +++
  drivers/spi/spi-rockchip.c | 5 +
  2 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt 
b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index d2ca153614f9..83da4931d832 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -31,6 +31,10 @@ Optional Properties:
  - rx-sample-delay-ns: nanoseconds to delay after the SCLK edge before sampling
Rx data (may need to be fine tuned for high capacitance lines).
No delay (0) by default.
+- pinctrl-names: Names for the pin configuration(s); may be "default" or
+   "sleep", where the "sleep" configuration may describe the state
+   the pins should be in during system suspend. See also
+   pinctrl/pinctrl-bindings.txt.
  
  
  Example:

@@ -46,4 +50,7 @@ Example:
interrupts = ;
clocks = < SCLK_SPI0>, < PCLK_SPI0>;
clock-names = "spiclk", "apb_pclk";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_sleep>;
+   pinctrl-names = "default", "sleep";
};
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 0f89c2169c24..acf31f36b898 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -843,6 +844,8 @@ static int rockchip_spi_suspend(struct device *dev)
clk_disable_unprepare(rs->apb_pclk);
}
  
+	pinctrl_pm_select_sleep_state(dev);

+
return ret;
  }
  
@@ -852,6 +855,8 @@ static int rockchip_spi_resume(struct device *dev)

struct spi_master *master = dev_get_drvdata(dev);
struct rockchip_spi *rs = spi_master_get_devdata(master);
  
+	pinctrl_pm_select_default_state(dev);

+
if (!pm_runtime_suspended(dev)) {
ret = clk_prepare_enable(rs->apb_pclk);
if (ret < 0)

[PATCH v3 2/2] drm/panel: simple: Add support BOE nv101wxmn51

[Caesar Wang]

10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.

Read the panel default edid information:

EDID MODE DETAILS
name = 
pixel_clock = 71900
lvds_dual_channel = 0
refresh = 0
ha = 1280
hbl = 160
hso = 48
hspw = 32
hborder = 0
va = 800
vbl = 32
vso = 3
vspw = 5
vborder = 0
phsync = +
pvsync = -
x_mm = 0
y_mm = 0
drm_display_mode
.hdisplay = 1280
.hsync_start = 1328
.hsync_end = 1360
.htotal = 1440
.vdisplay = 800
.vsync_start = 803
.vsync_end = 808
.vtotal = 832

There are two modes in the edid:
Detailed mode1: Clock 71.900 MHz, 216 mm x 135 mm
   1280 1328 1360 1440 hborder 0
800  803  808  832 vborder 0
   +hsync -vsync
Detailed mode2: Clock 57.500 MHz, 216 mm x 135 mm
   1280 1328 1360 1440 hborder 0
800  803  808  832 vborder 0
   +hsync -vsync

Add the both edid to support more modes for BOE nv101wxmn51.

Signed-off-by: Caesar Wang <w...@rock-chips.com>
---

Changes in v3:
- As Stéphane commented on https://patchwork.kernel.org/patch/9465911,
  add downclock mode for edid.

Changes in v2:
- fix the vsync_start and vsync_end from the edid.
- change the commit.

 drivers/gpu/drm/panel/panel-simple.c | 45 
 1 file changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..1ce25b5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,48 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };
 
+static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
+   {
+   .clock = 71900,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 5,
+   .vtotal = 800 + 3 + 5 + 24,
+   .vrefresh = 60,
+   },
+   {
+   .clock = 57500,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 48,
+   .hsync_end = 1280 + 48 + 32,
+   .htotal = 1280 + 48 + 32 + 80,
+   .vdisplay = 800,
+   .vsync_start = 800 + 3,
+   .vsync_end = 800 + 3 + 5,
+   .vtotal = 800 + 3 + 5 + 24,
+   .vrefresh = 48,
+   },
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+   .modes = boe_nv101wxmn51_modes,
+   .num_modes = ARRAY_SIZE(boe_nv101wxmn51_modes),
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .prepare = 210,
+   .enable = 50,
+   .unprepare = 160,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1790,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "boe,nv101wxmn51",
+   .data = _nv101wxmn51,
+   }, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
}, {
-- 
2.7.4