Re: [PATCH v2 2/2] arm64: dts: rockchip: rk3399: fix pd_tcpc0 and pd_tcpc1 node position
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 = <&cru HCLK_SDIO>; pm_qos = <&qos_sdioaudio>; }; + pd_tcpc0@RK3399_PD_TCPD0 { + reg = ; + clocks = <&cru SCLK_UPHY0_TCPDCORE>, +<&cru SCLK_UPHY0_TCPDPHY_REF>; + }; + pd_tcpc1@RK3399_PD_TCPD1 { + reg = ; + clocks = <&cru SCLK_UPHY1_TCPDCORE>, +<&cru SCLK_UPHY1_TCPDPHY_REF>; + }; pd_usb3@RK3399_PD_USB3 { reg = ; clocks = <&cru ACLK_USB3>; @@ -1088,16 +1098,6 @@ pm_qos = <&qos_isp1_m0>, <&qos_isp1_m1>; }; - pd_tcpc0@RK3399_PD_TCPD0 { - reg = ; - clocks = <&cru SCLK_UPHY0_TCPDCORE>, -<&cru SCLK_UPHY0_TCPDPHY_REF>; - }; - pd_tcpc1@RK3399_PD_TCPD1 { - reg = ; - clocks = <&cru SCLK_UPHY1_TCPDCORE>, -<&cru 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
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
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(&mb->mbox); + ret = devm_mbox_controller_register(&pdev->dev, &mb->mbox); if (ret < 0) dev_err(&pdev->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(&mb->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&D 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
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
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 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy
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 = (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
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 = (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
在 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 = (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
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 = (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
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 = (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
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
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 = (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
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 = (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
在 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 *)&rv1108_tsadc_data, +}, +{ .compatible = "rockchip,rk3228-tsadc", .data = (void *)&rk3228_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
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 *)&rv1108_tsadc_data, + }, + { .compatible = "rockchip,rk3228-tsadc", .data = (void *)&rk3228_tsadc_data, },
Re: [PATCH 3/5] arm: dts: rockchip: add tsadc node for RV1108 SoC
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 = <&cru SCLK_TSADC>; + assigned-clock-rates = <75>; + clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>; + clock-names = "tsadc", "apb_pclk"; + pinctrl-names = "init", "default", "sleep"; + pinctrl-0 = <&otp_gpio>; + pinctrl-1 = <&otp_out>; + pinctrl-2 = <&otp_gpio>; + resets = <&cru 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 &pcfg_pull_none>; + }; + + otp_gpio: otp-gpio { + rockchip,pins = <0 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + uart0 { uart0_xfer: uart0-xfer { rockchip,pins = <3 RK_PA6 RK_FUNC_1 &pcfg_pull_up>,
Re: [PATCH 1/5] dt-bindings: rockchip-thermal: Support the RV1108 SoC compatible
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
在 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 = <&cru ARMCLK>; + #cooling-cells = <2>; /* min followed by max */ + dynamic-power-coefficient = <120>; enable-method = "psci"; next-level-cache = <&l2>; }; @@ -83,6 +86,7 @@ compatible = "arm,cortex-a53", "arm,armv8"; reg = <0x0 0x1>; clocks = <&cru ARMCLK>; + dynamic-power-coefficient = <120>; enable-method = "psci"; next-level-cache = <&l2>; }; @@ -92,6 +96,7 @@ compatible = "arm,cortex-a53", "arm,armv8"; reg = <0x0 0x2>; clocks = <&cru ARMCLK>; + dynamic-power-coefficient = <120>; enable-method = "psci"; next-level-cache = <&l2>; }; @@ -101,6 +106,7 @@ compatible = "arm,cortex-a53", "arm,armv8"; reg = <0x0 0x3>; clocks = <&cru ARMCLK>; + dynamic-power-coefficient = <120>; enable-method = "psci"; next-level-cache = <&l2>; }; @@ -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 = <&tsadc 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 = <&target>; + cooling-device = <&cpu0 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
在 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 = <&grf>; + clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>; + clock-names = "tsadc", "apb_pclk"; + assigned-clocks = <&cru SCLK_TSADC>; + assigned-clock-rates = <5>; + resets = <&cru SRST_TSADC>; + reset-names = "tsadc-apb"; + pinctrl-names = "init", "default", "sleep"; + pinctrl-0 = <&otp_gpio>; + pinctrl-1 = <&otp_out>; + pinctrl-2 = <&otp_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
在 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 *)&rk3288_tsadc_data, }, { + .compatible = "rockchip,rk3328-tsadc", + .data = (void *)&rk3328_tsadc_data, + }, + { .compatible = "rockchip,rk3366-tsadc", .data = (void *)&rk3366_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
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 = <&cru ARMCLKB>; - dynamic-power-coefficient = <100>; + dynamic-power-coefficient = <436>; }; cpu_b1: cpu@101 { @@ -159,7 +159,7 @@ reg = <0x0 0x101>; enable-method = "psci"; clocks = <&cru 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
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 = <&cru ARMCLKB>; - dynamic-power-coefficient = <100>; + dynamic-power-coefficient = <436>; }; cpu_b1: cpu@101 { @@ -156,7 +156,7 @@ reg = <0x0 0x101>; enable-method = "psci"; clocks = <&cru 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 = <&tsadc 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 = <&cpu_alert0>; + trip = <&target>; still both maps use &target as trip point. Is that intentional and if so, why is the &threshold trip point never referenced? For the power allocator governor, the &threshold 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 = <&cru ACLK_GPU>; + #cooling-cells = <2>; power-domains = <&power RK3399_PD_GPU>; status = "disabled"; + + gpu_power_model: power_model { + compatible = "arm,mali-simple-power-model"; + static-coefficient = <1079403>; + dynamic-coefficient = <977>; +
Re: [PATCH v2 0/5] arm64: dts: rockchip: support mail and IPA thermal for rk3399
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
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
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
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>; + }; + }; }; &cpu_l0 { @@ -143,3 +172,7 @@ &cpu_b1 { operating-points-v2 = <&cluster1_opp>; }; + +&gpu { + operating-points-v2 = <&gpu_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>; + }; + }; }; &cpu_l0 { @@ -135,3 +164,7 @@ &cpu_b1 { operating-points-v2 = <&cluster1_opp>; }; + +&gpu { + operating-points-v2 = <&gpu_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 = <&cru ACLK_GPU>; + power-domains = <&power RK3399_PD_GPU>; + status = "disabled"; + }; + pinctrl: pinctrl { compatible = "rockchip,rk3399-pinctrl"; rockchip,grf = <&grf>; -- 2.7.4
[PATCH v2 4/5] arm64: dts: rockchip: enable the GPU for RK3399-GRU
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"; }; +&gpu { + mali-supply = <&ppvar_gpu>; + status = "okay"; +}; + ap_i2c_mic: &i2c1 { status = "okay"; -- 2.7.4
[PATCH v2 5/5] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs
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 = <&cru ARMCLKB>; - dynamic-power-coefficient = <100>; + dynamic-power-coefficient = <436>; }; cpu_b1: cpu@101 { @@ -156,7 +156,7 @@ reg = <0x0 0x101>; enable-method = "psci"; clocks = <&cru 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 = <&tsadc 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 = <&cpu_alert0>; + trip = <&target>; cooling-device = - <&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + <&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <4096>; }; map1 { - trip = <&cpu_alert1>; + trip = <&target>; cooling-device = - <&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <1024>; + }; + map2 { + trip = <&target>; + cooling-device = + <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <4096>; }; }; }; - gpu_therma
[PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI
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
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
在 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 = <&cru 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
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 4/4] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs
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 = <&cru ARMCLKB>; - dynamic-power-coefficient = <100>; + dynamic-power-coefficient = <436>; }; cpu_b1: cpu@101 { @@ -156,7 +156,7 @@ reg = <0x0 0x101>; enable-method = "psci"; clocks = <&cru 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 = <&tsadc 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 = <&cpu_alert0>; + trip = <&target>; cooling-device = - <&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + <&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <4096>; }; map1 { - trip = <&cpu_alert1>; + trip = <&target>; cooling-device = - <&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <1024>; + }; + map2 { + trip = <&target>; + cooling-device = + <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <4096>; }; }; }; - gpu_thermal: gpu { + gpu_thermal: gpu-thermal { polling-delay-passive = <100>; polling-delay = <1000>; thermal-sensors = <&tsadc 1>; - - trips { - gpu_alert0: gpu_alert0 { - temperature = <75000>; - hysteres
[PATCH 2/4] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
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>; + }; + }; }; &cpu_l0 { @@ -143,3 +172,7 @@ &cpu_b1 { operating-points-v2 = <&cluster1_opp>; }; + +&gpu { + operating-points-v2 = <&gpu_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>; + }; + }; }; &cpu_l0 { @@ -135,3 +164,7 @@ &cpu_b1 { operating-points-v2 = <&cluster1_opp>; }; + +&gpu { + operating-points-v2 = <&gpu_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 = <&cru ACLK_GPU>; + clock-names = "clk_mali"; + power-domains = <&power RK3399_PD_GPU>; + status = "disabled"; + }; + pinctrl: pinctrl { compatible = "rockchip,rk3399-pinctrl"; rockchip,grf = <&grf>; -- 2.7.4
[PATCH 1/4] dt-bindings: gpu: add the RK3399 mali for rockchip specifics
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
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"; }; +&gpu { + mali-supply = <&ppvar_gpu>; + status = "okay"; +}; + ap_i2c_mic: &i2c1 { status = "okay"; -- 2.7.4
arm64: dts: rockchip: add SdioAudio pd control for rk3399
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 = <&cru SRST_SDIO0>; reset-names = "reset"; + power-domains = <&power RK3399_PD_SDIOAUDIO>; status = "disabled"; }; @@ -678,6 +679,7 @@ pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>; #address-cells = <1>; #size-cells = <0>; + power-domains = <&power RK3399_PD_SDIOAUDIO>; status = "disabled"; }; @@ -952,6 +954,11 @@ <&cru SCLK_SDMMC>; pm_qos = <&qos_sd>; }; + pd_sdioaudio@RK3399_PD_SDIOAUDIO { + reg = ; + clocks = <&cru HCLK_SDIO>; + pm_qos = <&qos_sdioaudio>; + }; pd_vio@RK3399_PD_VIO { reg = ; #address-cells = <1>; @@ -1372,6 +1379,7 @@ clocks = <&cru SCLK_SPDIF_8CH>, <&cru HCLK_SPDIF>; pinctrl-names = "default"; pinctrl-0 = <&spdif_bus>; + power-domains = <&power RK3399_PD_SDIOAUDIO>; status = "disabled"; }; @@ -1386,6 +1394,7 @@ clocks = <&cru SCLK_I2S0_8CH>, <&cru HCLK_I2S0_8CH>; pinctrl-names = "default"; pinctrl-0 = <&i2s0_8ch_bus>; + power-domains = <&power RK3399_PD_SDIOAUDIO>; status = "disabled"; }; @@ -1399,6 +1408,7 @@ clocks = <&cru SCLK_I2S1_8CH>, <&cru HCLK_I2S1_8CH>; pinctrl-names = "default"; pinctrl-0 = <&i2s1_2ch_bus>; + power-domains = <&power RK3399_PD_SDIOAUDIO>; status = "disabled"; }; @@ -1410,6 +1420,7 @@ dma-names = "tx", "rx"; clock-names = "i2s_clk", "i2s_hclk"; clocks = <&cru SCLK_I2S2_8CH>, <&cru HCLK_I2S2_8CH>; + power-domains = <&power RK3399_PD_SDIOAUDIO>; status = "disabled"; }; -- 2.7.4
Re: [PATCH v3 1/3] spi: rockchip: add support for "cs-gpios" dts property
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(&pdev->dev); + if (ret) { + dev_err(&pdev->dev, "Failed to setup cs gpios\n"); + goto err_free_dma_rx; + } + ret = devm_spi_register_master(&pdev->dev, master); if (ret) { dev_err(&pdev->dev, "Failed to register master\n");
Re: [PATCH] mwifiex: fixes the trivial print
在 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: amit
[PATCH v2] mwifiex: fixes the unexpected be printed log by default
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
在 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
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
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
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(&private->mm_lock); - ret = drm_mm_insert_node_generic(&private->mm, &rk_obj->mm, rk_obj->base.size, PAGE_SIZE, 0, 0); - mutex_unlock(&private->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(&private->mm_lock); drm_mm_remove_node(&rk_obj->mm); + mutex_unlock(&private->mm_lock); return ret; } -- 2.7.4
Re: [PATCH] arm64: dts: rockchip: update cpu opp table for rk3399 op1
在 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
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
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
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
在 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
在 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
在 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 = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>; clock-names = "spiclk", "apb_pclk"; + pinctrl-0 = <&spi1_pins>; + pinctrl-1 = <&spi1_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
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 --- 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 = &avic_tm070ddh03, }, { + .compatible = "boe,nv101wxmn51", + .data = &boe_nv101wxmn51, + }, { .compatible = "chunghwa,claa070wp03xg", .data = &chunghwa_claa070wp03xg, }, { -- 2.7.4
[PATCH v3 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang --- Changes in v3: None Changes in v2: None .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt new file mode 100644 index 000..b258d6a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt @@ -0,0 +1,7 @@ +BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "boe,nv101wxmn51" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4
Re: [PATCH v2 2/2] drm/panel: simple: Add support BOE nv101wxmn51
在 2016年12月13日 04:22, Stéphane Marchesin 写道: On Wed, Dec 7, 2016 at 11:26 PM, Caesar Wang wrote: 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 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 Signed-off-by: Caesar Wang --- Changes in v2: - fix the vsync_start and vsync_end from the edid. - change the commit. drivers/gpu/drm/panel/panel-simple.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 06aaf79..7c90f16 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode boe_nv101wxmn51_mode = { + .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, +}; + +static const struct panel_desc boe_nv101wxmn51 = { + .modes = &boe_nv101wxmn51_mode, + .num_modes = 1, There are two modes in the EDID (there is a downclock one). Can you add both modes? Yup, I will add them for next version. Thanks. -Caesar Stéphane + .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 +1776,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, }, { + .compatible = "boe,nv101wxmn51", + .data = &boe_nv101wxmn51, + }, { .compatible = "chunghwa,claa070wp03xg", .data = &chunghwa_claa070wp03xg, }, { -- 2.7.4 ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[PATCH v4 3/5] thermal: rockchip: fixes invalid temperature case
The temp_to_code function will return 0 when we set the temperature to a invalid value (e.g. 61C, 62C, 63C), that's unpractical. This patch will prevent this case happening. That will return the max analog value to indicate the temperature is invalid or over table temperature range. Signed-off-by: Caesar Wang --- Changes in v4: None Changes in v3: - fix trivial thing for error message nd return value. Changes in v2: - As Brian commnets that restructure this to pass error codes back to the upper layers. - Improve the commit message. Changes in v1: None drivers/thermal/rockchip_thermal.c | 48 ++ 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 415e0ce..f027b86 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -120,10 +120,10 @@ struct rockchip_tsadc_chip { /* Per-sensor methods */ int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(const struct chip_tsadc_table *table, - int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(const struct chip_tsadc_table *table, - int chn, void __iomem *reg, int temp); + int (*set_alarm_temp)(const struct chip_tsadc_table *table, + int chn, void __iomem *reg, int temp); + int (*set_tshut_temp)(const struct chip_tsadc_table *table, + int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); /* Per-table methods */ @@ -401,17 +401,15 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; - u32 error = 0; + u32 error = table->data_mask; low = 0; high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table->id[low].temp || temp > table->id[high].temp) { - error = table->data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) goto exit; - } while (low <= high) { if (temp == table->id[mid].temp) @@ -650,15 +648,15 @@ static int rk_tsadcv2_get_temp(const struct chip_tsadc_table *table, return rk_tsadcv2_code_to_temp(table, val, temp); } -static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, - int chn, void __iomem *regs, int temp) +static int rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, +int chn, void __iomem *regs, int temp) { u32 alarm_value, int_en; /* Make sure the value is valid */ alarm_value = rk_tsadcv2_temp_to_code(table, temp); if (alarm_value == table->data_mask) - return; + return -ERANGE; writel_relaxed(alarm_value & table->data_mask, regs + TSADCV2_COMP_INT(chn)); @@ -666,23 +664,27 @@ static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int_en = readl_relaxed(regs + TSADCV2_INT_EN); int_en |= TSADCV2_INT_SRC_EN(chn); writel_relaxed(int_en, regs + TSADCV2_INT_EN); + + return 0; } -static void rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, - int chn, void __iomem *regs, int temp) +static int rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, +int chn, void __iomem *regs, int temp) { u32 tshut_value, val; /* Make sure the value is valid */ tshut_value = rk_tsadcv2_temp_to_code(table, temp); if (tshut_value == table->data_mask) - return; + return -ERANGE; writel_relaxed(tshut_value, regs + TSADCV2_COMP_SHUT(chn)); /* TSHUT will be valid */ val = readl_relaxed(regs + TSADCV2_AUTO_CON); writel_relaxed(val | TSADCV2_AUTO_SRC_EN(chn), regs + TSADCV2_AUTO_CON); + + return 0; } static void rk_tsadcv2_tshut_mode(int chn, void __iomem *regs, @@ -885,10 +887,8 @@ static int rockchip_thermal_set_trips(void *_sensor, int low, int high) dev_dbg(&thermal->pdev->dev, "%s: sensor %d: low: %d, high %d\n", __func__, sensor->id, low, high); - tsadc->set_alarm_temp(&tsadc->table, - sensor->id, thermal->regs, high); - - return 0; + return tsadc->set_alarm_temp(&tsadc->table, +sensor->id, thermal->regs, high); } static i
[PATCH v4 2/5] thermal: rockchip: don't pass table structs by value
From: Brian Norris This driver passes struct chip_tsadc_table by value throughout; this is inefficient, and AFAICT, there is no reason for it. Let's pass pointers instead. Signed-off-by: Brian Norris Reviewed-by: Caesar Wang Signed-off-by: Caesar Wang --- Changes in v4: None Changes in v3: None Changes in v2: None Changes in v1: - The original Brian posted on https://patchwork.kernel.org/patch/9437687 drivers/thermal/rockchip_thermal.c | 80 +++--- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 3bbc97c..415e0ce 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -118,11 +118,11 @@ struct rockchip_tsadc_chip { void (*control)(void __iomem *reg, bool on); /* Per-sensor methods */ - int (*get_temp)(struct chip_tsadc_table table, + int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(struct chip_tsadc_table table, + void (*set_alarm_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(struct chip_tsadc_table table, + void (*set_tshut_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); @@ -397,26 +397,26 @@ static const struct tsadc_table rk3399_code_table[] = { {TSADCV3_DATA_MASK, 125000}, }; -static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, +static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; u32 error = 0; low = 0; - high = table.length - 1; + high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table.id[low].temp || temp > table.id[high].temp) { - error = table.data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) { + error = table->data_mask; goto exit; } while (low <= high) { - if (temp == table.id[mid].temp) - return table.id[mid].code; - else if (temp < table.id[mid].temp) + if (temp == table->id[mid].temp) + return table->id[mid].code; + else if (temp < table->id[mid].temp) high = mid - 1; else low = mid + 1; @@ -429,28 +429,28 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, return error; } -static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, - int *temp) +static int rk_tsadcv2_code_to_temp(const struct chip_tsadc_table *table, + u32 code, int *temp) { unsigned int low = 1; - unsigned int high = table.length - 1; + unsigned int high = table->length - 1; unsigned int mid = (low + high) / 2; unsigned int num; unsigned long denom; - WARN_ON(table.length < 2); + WARN_ON(table->length < 2); - switch (table.mode) { + switch (table->mode) { case ADC_DECREMENT: - code &= table.data_mask; - if (code < table.id[high].code) + code &= table->data_mask; + if (code < table->id[high].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code >= table.id[mid].code && - code < table.id[mid - 1].code) + if (code >= table->id[mid].code && + code < table->id[mid - 1].code) break; - else if (code < table.id[mid].code) + else if (code < table->id[mid].code) low = mid + 1; else high = mid - 1; @@ -459,15 +459,15 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; case ADC_INCREMENT: - code &= table.data_mask; - if (code < table.id[low].code) + code &= table->data_mask; + if (code < table->id[low].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { -
[PATCH v4 1/5] thermal: rockchip: improve conversion error messages
From: Brian Norris These error messages don't give much information about what went wrong. It would be nice, for one, to see what invalid temperature was being requested when conversion fails. It's also good to return an error when we can't handle a conversion properly. While we're at it, fix the grammar too. Signed-off-by: Brian Norris Signed-off-by: Caesar Wang --- Changes in v4: - As Eduardo and Brian commnets on https://patchwork.kernel.org/patch/9449301 Changes in v3: None Changes in v2: None 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... drivers/thermal/rockchip_thermal.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index b811b0f..3bbc97c 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, } exit: - pr_err("Invalid the conversion, error=%d\n", error); + pr_err("%s: invalid temperature, temp=%d error=%d\n", + __func__, temp, error); return error; } @@ -475,7 +476,8 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; default: - pr_err("Invalid the conversion table\n"); + pr_err("%s: unknown table mode: %d\n", __func__, table.mode); + return -EINVAL; } /* -- 2.7.4
[PATCH v4 0/5] thermal: fixes the rockchip thermal
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(-) -- 2.7.4
[PATCH v4 5/5] thermal: rockchip: handle set_trips without the trip points
In some cases, some sensors didn't need the trip points, the set_trips will pass {-INT_MAX, INT_MAX} to trigger tsadc alarm in the end, ignore this case and disable the high temperature interrupt. Signed-off-by: Caesar Wang Reviewed-by: Brian Norris --- Changes in v4: None Changes in v3: - change the commit. - Fixes something as Brian comments on Changes in v2: - Fixes something as Brian comments on https://patchwork.kernel.org/patch/9440989. Changes in v1: None drivers/thermal/rockchip_thermal.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index cacc12b..cbbf0ce 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -674,7 +674,21 @@ static int rk_tsadcv2_get_temp(const struct chip_tsadc_table *table, static int rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { - u32 alarm_value, int_en; + u32 alarm_value; + u32 int_en, int_clr; + + /* +* In some cases, some sensors didn't need the trip points, the +* set_trips will pass {-INT_MAX, INT_MAX} to trigger tsadc alarm +* in the end, ignore this case and disable the high temperature +* interrupt. +*/ + if (temp == INT_MAX) { + int_clr = readl_relaxed(regs + TSADCV2_INT_EN); + int_clr &= ~TSADCV2_INT_SRC_EN(chn); + writel_relaxed(int_clr, regs + TSADCV2_INT_EN); + return 0; + } /* Make sure the value is valid */ alarm_value = rk_tsadcv2_temp_to_code(table, temp); -- 2.7.4
[PATCH v4 4/5] thermal: rockchip: optimize the conversion table
In order to support the valid temperature can conver to analog value. The rockchip thermal driver has not supported the all valid temperature to convert the analog value. (e.g.: 61C, 62C, 63C) For example: In some cases, we need adjust the trip point. $cd /sys/class/thermal/thermal_zone* $echo 68000 > trip_point_0_temp That will return the max analogic value indicates the invalid before posting this patch. So, this patch will optimize the conversion table to support the other cases. Signed-off-by: Caesar Wang --- Changes in v4: - 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: None Changes in v2: - improve the commit as Brian commnets on https://patchwork.kernel.org/patch/9440985 Changes in v1: None drivers/thermal/rockchip_thermal.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index f027b86..cacc12b 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -317,6 +317,7 @@ static const struct tsadc_table rk3288_code_table[] = { {3452, 115000}, {3437, 12}, {3421, 125000}, + {0, 125000}, }; static const struct tsadc_table rk3368_code_table[] = { @@ -401,10 +402,12 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; + unsigned long num; + unsigned int denom; u32 error = table->data_mask; low = 0; - high = table->length - 1; + high = (table->length - 1) - 1; /* ignore the last check for table */ mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ @@ -421,6 +424,26 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, mid = (low + high) / 2; } + /* +* The conversion code granularity provided by the table. Let's +* assume that the relationship between temperature and +* analog value between 2 table entries is linear and interpolate +* to produce less granular result. +*/ + num = abs(table->id[mid + 1].code - table->id[mid].code); + num *= temp - table->id[mid].temp; + denom = table->id[mid + 1].temp - table->id[mid].temp; + + switch (table->mode) { + case ADC_DECREMENT: + return table->id[mid].code - (num / denom); + case ADC_INCREMENT: + return table->id[mid].code + (num / denom); + default: + pr_err("%s: unknown table mode: %d\n", __func__, table->mode); + return error; + } + exit: pr_err("%s: invalid temperature, temp=%d error=%d\n", __func__, temp, error); -- 2.7.4
Re: [PATCH v3 4/5] thermal: rockchip: optimize the conversion table
在 2016年11月30日 14:29, Eduardo Valentin 写道: Hey, On Mon, Nov 28, 2016 at 07:12:03PM +0800, Caesar Wang wrote: + num = abs(table->id[mid].code - table->id[mid + 1].code); + num *= temp - table->id[mid].temp; + denom = table->id[mid + 1].temp - table->id[mid].temp; isn't the above 'mid + 1' off-by-one when mid ends being == table.length - 1? You would be accessing table->id[table.length], which is wrong memory access, no? Yup, that's indeed a real issue for me. FIxes on next version. Thanks. -Caesar ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v3 1/5] thermal: rockchip: improve conversion error messages
在 2016年11月30日 13:04, Eduardo Valentin 写道: Hey, On Mon, Nov 28, 2016 at 09:47:29PM -0800, Brian Norris wrote: Hi, + __func__, table.mode); Given that we are improving messages, would it be more informative to say that you have an invalid table mode? I considered the mode and ID listing to go hand in hand, so it was the whole table that is wrong. But it is just as well to say the "table mode" is wrong. Maybe even better: "%s: unknown table mode: %d\n". Yup, that works for me, even better. Done. Sorry for delay. And I guess same answer for patch 4, where you had the same question. yes Brian + return -EINVAL; ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v3 3/5] thermal: rockchip: fixes invalid temperature case
Hi 在 2016年11月30日 14:26, Eduardo Valentin 写道: Hello, On Tue, Nov 29, 2016 at 09:59:28PM -0800, Brian Norris wrote: On Tue, Nov 29, 2016 at 09:02:42PM -0800, Eduardo Valentin wrote: On Tue, Nov 29, 2016 at 01:57:45PM -0800, Brian Norris wrote: I was thinking while reviewing that the binary search serves more to complicate things than to help -- it's much harder to read (and validate that the loop termination logic is correct). And searching through a few dozen table entries doesn't really get much benefit from a O(n) -> O(log(n)) speed improvement. true. but if in your code path you do several walks in the table just to check if parameters are valid, given that you could simply decide if they are valid or not with simpler if condition, then, still worth, no? :-) Yes, your suggestions seems like they would have made the code both (a little) more straightforward and efficient. But... Anyway, I'm not sure if you were thinking along the same lines as me. Something like that, except I though of something even simpler: + if ((temp % table->step) != 0) + return -ERANGE; If temp passes that check, then you go to the temp -> code conversion. ...that check isn't valid as of patch 4, where Caesar adds handling for intermediate steps. We really never should have been strictly snapping to the 5C steps in the first place; intermediate values are OK. So, we still need some kind of search to find the right step -- or closest bracketing range, to compute the interpolated value. We should only reject temperatures that are too high or too low for the ADC to represent. Ok. got it. check small comment on patch 4 then. --- Side track --- BTW, when we're considering rejecting temperatures here: shouldn't this be fed back to the upper layers more nicely? We're improving the error handling for this driver in this series, but it still leaves things behaving a little odd. When I tested, I can do: ## set something obviously way too high echo 70 > trip_point_X_temp and get a 0 (success) return code from the sysfs write() syscall, even though the rockchip driver rejected it with -ERANGE. Is there really no way to feed back thermal range limits of a sensor to the of-thermal framework? well, that is a bit strange to me. Are you sure you are returning the -ERANGE? Because, my assumption is that the following of-thermal code path would return the error code back to core: 328 if (data->ops->set_trip_temp) { 329 int ret; 330 331 ret = data->ops->set_trip_temp(data->sensor_data, trip, temp); 332 if (ret) 333 return ret; 334 } And this part of thermal core would return it back to sysfs layer: 757 ret = tz->ops->set_trip_temp(tz, trip, temperature); 758 if (ret) 759 return ret; or am I missing something? that should be related to the many trips. The trips will search the next trips. So in general, trip_ponit_0_temp <= trip_ponit_1_temp <=trip_ponit_1_temp. I'm assume you set"echo 70 > trip_point_0_temp", and you keep trip1 and trip2 [ 34.449718] trip_point_temp_store, temp=70 [ 34.454568] of_thermal_set_trip_temp:336,temp=70 [ 34.459612] thermal_sys: thermal_zone_set_trips:583, temp=45000, trip_temp=70, hys=2000 [ 34.468026] thermal_sys: thermal_zone_set_trips:583, temp=45000, trip_temp=85000, hys=2000 [ 34.476336] thermal_sys: thermal_zone_set_trips:583, temp=45000, trip_temp=95000, hys=2000 [ 34.484634] thermal thermal_zone0: new temperature boundaries: -2147483647 < x < 85000 [ 34.492619] rockchip-thermal ff26.tsadc: rockchip_thermal_set_trips: sensor 0: low: -2147483647, high 85000 ===> So rockchip thermal will return 0. That should report error when you meet the needs of order. order--> trip_ponit_0_temp <= trip_ponit_1_temp <=trip_ponit_1_temp. Fox example: [ 100.898552] thermal_sys: thermal_zone_set_trips:583, temp=58333, trip_temp=70, hys=2000 [ 100.906964] thermal_sys: thermal_zone_set_trips:583, temp=58333, trip_temp=71, hys=2000 [ 100.916329] thermal_sys: thermal_zone_set_trips:583, temp=58333, trip_temp=72, hys=2000 [ 100.924685] thermal thermal_zone0: new temperature boundaries: -2147483647 < x < 70 [ 100.932965] rockchip-thermal ff26.tsadc: rockchip_thermal_set_trips: sensor 0: low: -2147483647, high 70 [ 100.943138] rk_tsadcv2_alarm_temp:682, temp=70 [ 100.948201] rk_tsadcv2_temp_to_code: invalid temperature, temp=70 error=1023 [ 100.955598] thermal thermal_zone0: Failed to set trips: -34 ===> So rockchip thermal will return error. - Caesar Brian ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[PATCH] drm/bridge: analogix_dp: set the DPCD600 during disabling the psr
Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host device, that will cause the panel hang on the startup display. The root cause we use the fast link mode during enter and exit the psr, this issue is gone if switching the fast link to main link mode. Signed-off-by: Caesar Wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 6e0447f..6a5347b 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -133,6 +133,7 @@ int analogix_dp_disable_psr(struct device *dev) { struct analogix_dp_device *dp = dev_get_drvdata(dev); struct edp_vsc_psr psr_vsc; + int ret; if (!dp->psr_support) return -EINVAL; @@ -147,6 +148,10 @@ int analogix_dp_disable_psr(struct device *dev) psr_vsc.DB0 = 0; psr_vsc.DB1 = 0; + ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0); + if (ret != 1) + dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret); + analogix_dp_send_psr_spd(dp, &psr_vsc); return 0; } -- 2.7.4
[PATCH v2 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang --- Changes in v2: None .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt new file mode 100644 index 000..b258d6a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt @@ -0,0 +1,7 @@ +BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "boe,nv101wxmn51" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4
[PATCH v2 2/2] drm/panel: simple: Add support BOE nv101wxmn51
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 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 Signed-off-by: Caesar Wang --- Changes in v2: - fix the vsync_start and vsync_end from the edid. - change the commit. drivers/gpu/drm/panel/panel-simple.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 06aaf79..7c90f16 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode boe_nv101wxmn51_mode = { + .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, +}; + +static const struct panel_desc boe_nv101wxmn51 = { + .modes = &boe_nv101wxmn51_mode, + .num_modes = 1, + .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 +1776,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, }, { + .compatible = "boe,nv101wxmn51", + .data = &boe_nv101wxmn51, + }, { .compatible = "chunghwa,claa070wp03xg", .data = &chunghwa_claa070wp03xg, }, { -- 2.7.4
[RESEND PATCH 2/2] drm/panel: simple: Add support BOE nv101wxmn51
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. Signed-off-by: Caesar Wang --- drivers/gpu/drm/panel/panel-simple.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 06aaf79..c9135dc 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode boe_nv101wxmn51_mode = { + .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 + 20, + .vtotal = 800 + 3 + 20 + 9, + .vrefresh = 60, +}; + +static const struct panel_desc boe_nv101wxmn51 = { + .modes = &boe_nv101wxmn51_mode, + .num_modes = 1, + .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 +1776,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, }, { + .compatible = "boe,nv101wxmn51", + .data = &boe_nv101wxmn51, + }, { .compatible = "chunghwa,claa070wp03xg", .data = &chunghwa_claa070wp03xg, }, { -- 2.7.4
[RESEND PATCH 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang --- .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt new file mode 100644 index 000..b258d6a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt @@ -0,0 +1,7 @@ +BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "boe,nv101wxmn51" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4
Re: [PATCH] drm/panel: simple: Add support BOE nv101wxmn51
Resend the missing document. Sorry for the noise. 在 2016年12月08日 13:26, 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. Signed-off-by: Caesar Wang --- drivers/gpu/drm/panel/panel-simple.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 06aaf79..c9135dc 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode boe_nv101wxmn51_mode = { + .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 + 20, + .vtotal = 800 + 3 + 20 + 9, + .vrefresh = 60, +}; + +static const struct panel_desc boe_nv101wxmn51 = { + .modes = &boe_nv101wxmn51_mode, + .num_modes = 1, + .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 +1776,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, }, { + .compatible = "boe,nv101wxmn51", + .data = &boe_nv101wxmn51, + }, { .compatible = "chunghwa,claa070wp03xg", .data = &chunghwa_claa070wp03xg, }, {
[PATCH] drm/panel: simple: Add support BOE nv101wxmn51
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. Signed-off-by: Caesar Wang --- drivers/gpu/drm/panel/panel-simple.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 06aaf79..c9135dc 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode boe_nv101wxmn51_mode = { + .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 + 20, + .vtotal = 800 + 3 + 20 + 9, + .vrefresh = 60, +}; + +static const struct panel_desc boe_nv101wxmn51 = { + .modes = &boe_nv101wxmn51_mode, + .num_modes = 1, + .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 +1776,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, }, { + .compatible = "boe,nv101wxmn51", + .data = &boe_nv101wxmn51, + }, { .compatible = "chunghwa,claa070wp03xg", .data = &chunghwa_claa070wp03xg, }, { -- 2.7.4
[PATCH v3 2/5] thermal: rockchip: don't pass table structs by value
From: Brian Norris This driver passes struct chip_tsadc_table by value throughout; this is inefficient, and AFAICT, there is no reason for it. Let's pass pointers instead. Signed-off-by: Brian Norris Reviewed-by: Caesar Wang --- Changes in v3: None Changes in v2: None Changes in v1: - The original Brian posted on https://patchwork.kernel.org/patch/9437687 drivers/thermal/rockchip_thermal.c | 80 +++--- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 26c247c..766486f 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -118,11 +118,11 @@ struct rockchip_tsadc_chip { void (*control)(void __iomem *reg, bool on); /* Per-sensor methods */ - int (*get_temp)(struct chip_tsadc_table table, + int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(struct chip_tsadc_table table, + void (*set_alarm_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(struct chip_tsadc_table table, + void (*set_tshut_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); @@ -397,26 +397,26 @@ static const struct tsadc_table rk3399_code_table[] = { {TSADCV3_DATA_MASK, 125000}, }; -static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, +static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; u32 error = 0; low = 0; - high = table.length - 1; + high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table.id[low].temp || temp > table.id[high].temp) { - error = table.data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) { + error = table->data_mask; goto exit; } while (low <= high) { - if (temp == table.id[mid].temp) - return table.id[mid].code; - else if (temp < table.id[mid].temp) + if (temp == table->id[mid].temp) + return table->id[mid].code; + else if (temp < table->id[mid].temp) high = mid - 1; else low = mid + 1; @@ -429,28 +429,28 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, return error; } -static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, - int *temp) +static int rk_tsadcv2_code_to_temp(const struct chip_tsadc_table *table, + u32 code, int *temp) { unsigned int low = 1; - unsigned int high = table.length - 1; + unsigned int high = table->length - 1; unsigned int mid = (low + high) / 2; unsigned int num; unsigned long denom; - WARN_ON(table.length < 2); + WARN_ON(table->length < 2); - switch (table.mode) { + switch (table->mode) { case ADC_DECREMENT: - code &= table.data_mask; - if (code < table.id[high].code) + code &= table->data_mask; + if (code < table->id[high].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code >= table.id[mid].code && - code < table.id[mid - 1].code) + if (code >= table->id[mid].code && + code < table->id[mid - 1].code) break; - else if (code < table.id[mid].code) + else if (code < table->id[mid].code) low = mid + 1; else high = mid - 1; @@ -459,15 +459,15 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; case ADC_INCREMENT: - code &= table.data_mask; - if (code < table.id[low].code) + code &= table->data_mask; + if (code < table->id[low].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code <= table.id[mid].code &&a
[PATCH v3 5/5] thermal: rockchip: handle set_trips without the trip points
In some cases, some sensors didn't need the trip points, the set_trips will pass {-INT_MAX, INT_MAX} to trigger tsadc alarm in the end, ignore this case and disable the high temperature interrupt. Signed-off-by: Caesar Wang Reviewed-by: Brian Norris --- Changes in v3: - change the commit. - Fixes something as Brian comments on Changes in v2: - Fixes something as Brian comments on https://patchwork.kernel.org/patch/9440989. Changes in v1: None drivers/thermal/rockchip_thermal.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 660ed3b..56c663c 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -675,7 +675,21 @@ static int rk_tsadcv2_get_temp(const struct chip_tsadc_table *table, static int rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { - u32 alarm_value, int_en; + u32 alarm_value; + u32 int_en, int_clr; + + /* +* In some cases, some sensors didn't need the trip points, the +* set_trips will pass {-INT_MAX, INT_MAX} to trigger tsadc alarm +* in the end, ignore this case and disable the high temperature +* interrupt. +*/ + if (temp == INT_MAX) { + int_clr = readl_relaxed(regs + TSADCV2_INT_EN); + int_clr &= ~TSADCV2_INT_SRC_EN(chn); + writel_relaxed(int_clr, regs + TSADCV2_INT_EN); + return 0; + } /* Make sure the value is valid */ alarm_value = rk_tsadcv2_temp_to_code(table, temp); -- 2.7.4
[PATCH v3 4/5] thermal: rockchip: optimize the conversion table
In order to support the valid temperature can conver to analog value. The rockchip thermal driver has not supported the all valid temperature to convert the analog value. (e.g.: 61C, 62C, 63C) For example: In some cases, we need adjust the trip point. $cd /sys/class/thermal/thermal_zone* $echo 68000 > trip_point_0_temp That will return the max analogic value indicates the invalid before posting this patch. So, this patch will optimize the conversion table to support the other cases. Signed-off-by: Caesar Wang Reviewed-by: Brian Norris --- Changes in v3: None Changes in v2: - improve the commit as Brian commnets on https://patchwork.kernel.org/patch/9440985 Changes in v1: None drivers/thermal/rockchip_thermal.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index ca1730e..660ed3b 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -401,6 +401,8 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; + unsigned long num; + unsigned int denom; u32 error = table->data_mask; low = 0; @@ -421,6 +423,27 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, mid = (low + high) / 2; } + /* +* The conversion code granularity provided by the table. Let's +* assume that the relationship between temperature and +* analog value between 2 table entries is linear and interpolate +* to produce less granular result. +*/ + num = abs(table->id[mid].code - table->id[mid + 1].code); + num *= temp - table->id[mid].temp; + denom = table->id[mid + 1].temp - table->id[mid].temp; + + switch (table->mode) { + case ADC_DECREMENT: + return table->id[mid].code - (num / denom); + case ADC_INCREMENT: + return table->id[mid].code + (num / denom); + default: + pr_err("%s: invalid conversion table, mode=%d\n", + __func__, table->mode); + return error; + } + exit: pr_err("%s: invalid temperature, temp=%d error=%d\n", __func__, temp, error); -- 2.7.4
[PATCH v3 3/5] thermal: rockchip: fixes invalid temperature case
The temp_to_code function will return 0 when we set the temperature to a invalid value (e.g. 61C, 62C, 63C), that's unpractical. This patch will prevent this case happening. That will return the max analog value to indicate the temperature is invalid or over table temperature range. Signed-off-by: Caesar Wang --- Changes in v3: - fix trivial thing for error message nd return value. Changes in v2: - As Brian commnets that restructure this to pass error codes back to the upper layers. - Improve the commit message. Changes in v1: None drivers/thermal/rockchip_thermal.c | 48 ++ 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 766486f..ca1730e 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -120,10 +120,10 @@ struct rockchip_tsadc_chip { /* Per-sensor methods */ int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(const struct chip_tsadc_table *table, - int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(const struct chip_tsadc_table *table, - int chn, void __iomem *reg, int temp); + int (*set_alarm_temp)(const struct chip_tsadc_table *table, + int chn, void __iomem *reg, int temp); + int (*set_tshut_temp)(const struct chip_tsadc_table *table, + int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); /* Per-table methods */ @@ -401,17 +401,15 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; - u32 error = 0; + u32 error = table->data_mask; low = 0; high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table->id[low].temp || temp > table->id[high].temp) { - error = table->data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) goto exit; - } while (low <= high) { if (temp == table->id[mid].temp) @@ -651,15 +649,15 @@ static int rk_tsadcv2_get_temp(const struct chip_tsadc_table *table, return rk_tsadcv2_code_to_temp(table, val, temp); } -static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, - int chn, void __iomem *regs, int temp) +static int rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, +int chn, void __iomem *regs, int temp) { u32 alarm_value, int_en; /* Make sure the value is valid */ alarm_value = rk_tsadcv2_temp_to_code(table, temp); if (alarm_value == table->data_mask) - return; + return -ERANGE; writel_relaxed(alarm_value & table->data_mask, regs + TSADCV2_COMP_INT(chn)); @@ -667,23 +665,27 @@ static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int_en = readl_relaxed(regs + TSADCV2_INT_EN); int_en |= TSADCV2_INT_SRC_EN(chn); writel_relaxed(int_en, regs + TSADCV2_INT_EN); + + return 0; } -static void rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, - int chn, void __iomem *regs, int temp) +static int rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, +int chn, void __iomem *regs, int temp) { u32 tshut_value, val; /* Make sure the value is valid */ tshut_value = rk_tsadcv2_temp_to_code(table, temp); if (tshut_value == table->data_mask) - return; + return -ERANGE; writel_relaxed(tshut_value, regs + TSADCV2_COMP_SHUT(chn)); /* TSHUT will be valid */ val = readl_relaxed(regs + TSADCV2_AUTO_CON); writel_relaxed(val | TSADCV2_AUTO_SRC_EN(chn), regs + TSADCV2_AUTO_CON); + + return 0; } static void rk_tsadcv2_tshut_mode(int chn, void __iomem *regs, @@ -886,10 +888,8 @@ static int rockchip_thermal_set_trips(void *_sensor, int low, int high) dev_dbg(&thermal->pdev->dev, "%s: sensor %d: low: %d, high %d\n", __func__, sensor->id, low, high); - tsadc->set_alarm_temp(&tsadc->table, - sensor->id, thermal->regs, high); - - return 0; + return tsadc->set_alarm_temp(&tsadc->table, +sensor->id, thermal->regs, high); } static int rock
[PATCH v3 1/5] thermal: rockchip: improve conversion error messages
From: Brian Norris These error messages don't give much information about what went wrong. It would be nice, for one, to see what invalid temperature was being requested when conversion fails. It's also good to return an error when we can't handle a conversion properly. While we're at it, fix the grammar too. Signed-off-by: Brian Norris Signed-off-by: Caesar Wang --- Changes in v3: None Changes in v2: None 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... drivers/thermal/rockchip_thermal.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index b811b0f..26c247c 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, } exit: - pr_err("Invalid the conversion, error=%d\n", error); + pr_err("%s: invalid temperature, temp=%d error=%d\n", + __func__, temp, error); return error; } @@ -475,7 +476,9 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; default: - pr_err("Invalid the conversion table\n"); + pr_err("%s: invalid conversion table, mode=%d\n", + __func__, table.mode); + return -EINVAL; } /* -- 2.7.4
[PATCH v3 0/5] thermal: fixes the rockchip thermal
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 --- 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 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 | 154 - 1 file changed, 101 insertions(+), 53 deletions(-) -- 2.7.4
Re: [PATCH v2 3/5] thermal: rockchip: fixes invalid temperature case
在 2016年11月24日 02:35, Brian Norris 写道: Hi Caesar, On Wed, Nov 23, 2016 at 10:29:32PM +0800, Caesar Wang wrote: The temp_to_code function will return 0 when we set the temperature to a invalid value (e.g. 61C, 62C, 63C), that's unpractical. This patch will prevent this case happening. That will return the max analog value to indicate the temperature is invalid or over table temperature range. Signed-off-by: Caesar Wang --- Changes in v2: - As Brian commnets that restructure this to pass error codes back to the upper layers. - Improve the commit message. Changes in v1: None drivers/thermal/rockchip_thermal.c | 41 ++ 1 file changed, 28 insertions(+), 13 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 766486f..e243e40 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -120,9 +120,9 @@ struct rockchip_tsadc_chip { /* Per-sensor methods */ int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(const struct chip_tsadc_table *table, + int (*set_alarm_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(const struct chip_tsadc_table *table, + int (*set_tshut_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); @@ -401,17 +401,15 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; - u32 error = 0; + u32 error = table->data_mask; low = 0; high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table->id[low].temp || temp > table->id[high].temp) { - error = table->data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) goto exit; - } while (low <= high) { if (temp == table->id[mid].temp) @@ -651,7 +649,7 @@ static int rk_tsadcv2_get_temp(const struct chip_tsadc_table *table, return rk_tsadcv2_code_to_temp(table, val, temp); } -static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, +static int rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { u32 alarm_value, int_en; @@ -659,7 +657,7 @@ static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, /* Make sure the value is valid */ alarm_value = rk_tsadcv2_temp_to_code(table, temp); if (alarm_value == table->data_mask) - return; + return -ERANGE; writel_relaxed(alarm_value & table->data_mask, regs + TSADCV2_COMP_INT(chn)); @@ -667,9 +665,11 @@ static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int_en = readl_relaxed(regs + TSADCV2_INT_EN); int_en |= TSADCV2_INT_SRC_EN(chn); writel_relaxed(int_en, regs + TSADCV2_INT_EN); + + return 0; } -static void rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, +static int rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { u32 tshut_value, val; @@ -677,13 +677,15 @@ static void rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, /* Make sure the value is valid */ tshut_value = rk_tsadcv2_temp_to_code(table, temp); if (tshut_value == table->data_mask) - return; + return -ERANGE; writel_relaxed(tshut_value, regs + TSADCV2_COMP_SHUT(chn)); /* TSHUT will be valid */ val = readl_relaxed(regs + TSADCV2_AUTO_CON); writel_relaxed(val | TSADCV2_AUTO_SRC_EN(chn), regs + TSADCV2_AUTO_CON); + + return 0; } static void rk_tsadcv2_tshut_mode(int chn, void __iomem *regs, @@ -882,12 +884,17 @@ static int rockchip_thermal_set_trips(void *_sensor, int low, int high) struct rockchip_thermal_sensor *sensor = _sensor; struct rockchip_thermal_data *thermal = sensor->thermal; const struct rockchip_tsadc_chip *tsadc = thermal->chip; + int ret; dev_dbg(&thermal->pdev->dev, "%s: sensor %d: low: %d, high %d\n", __func__, sensor->id, low, high); - tsadc->set_alarm_temp(&tsadc->table, + ret = tsadc->set_alarm_temp(&tsadc->table, sensor->id, thermal->regs, high); + if (ret)
[PATCH v2 0/5] thermal: fixes the rockchip thermal
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. -- 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 issue in special cases. -- Anyway, this series patches should can improve the rockchip thermal driver. 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 | 147 + 1 file changed, 101 insertions(+), 46 deletions(-) -- 2.7.4
[PATCH v2 5/5] thermal: rockchip: handle set_trips without the trip points
In some cases, some sensors didn't need the trip points, the set_trips will return {-INT_MAX, INT_MAX} to trigger thermal alarm. Signed-off-by: Caesar Wang --- Changes in v2: - Fixes something as Brian comments on https://patchwork.kernel.org/patch/9440989. Changes in v1: None drivers/thermal/rockchip_thermal.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 0d50df7..f873053 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -675,7 +675,21 @@ static int rk_tsadcv2_get_temp(const struct chip_tsadc_table *table, static int rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { - u32 alarm_value, int_en; + u32 alarm_value; + u32 int_en, int_clr; + + /* +* In some cases, some sensors didn't need the trip points, the +* set_trips will pass {-INT_MAX, INT_MAX} to trigger tsadc alarm +* in the end, ignore this case and disable the high temperature +* interrupt. +*/ + if (temp == INT_MAX) { + int_clr = readl_relaxed(regs + TSADCV2_INT_EN); + int_clr &= ~TSADCV2_INT_SRC_EN(chn); + writel_relaxed(int_clr, regs + TSADCV2_INT_EN); + return 0; + } /* Make sure the value is valid */ alarm_value = rk_tsadcv2_temp_to_code(table, temp); -- 2.7.4
[PATCH v2 2/5] thermal: rockchip: don't pass table structs by value
From: Brian Norris This driver passes struct chip_tsadc_table by value throughout; this is inefficient, and AFAICT, there is no reason for it. Let's pass pointers instead. Signed-off-by: Brian Norris Reviewed-by: Caesar Wang Signed-off-by: Caesar Wang --- Changes in v2: None Changes in v1: - The original Brian posted on https://patchwork.kernel.org/patch/9437687 drivers/thermal/rockchip_thermal.c | 80 +++--- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 26c247c..766486f 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -118,11 +118,11 @@ struct rockchip_tsadc_chip { void (*control)(void __iomem *reg, bool on); /* Per-sensor methods */ - int (*get_temp)(struct chip_tsadc_table table, + int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(struct chip_tsadc_table table, + void (*set_alarm_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(struct chip_tsadc_table table, + void (*set_tshut_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); @@ -397,26 +397,26 @@ static const struct tsadc_table rk3399_code_table[] = { {TSADCV3_DATA_MASK, 125000}, }; -static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, +static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; u32 error = 0; low = 0; - high = table.length - 1; + high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table.id[low].temp || temp > table.id[high].temp) { - error = table.data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) { + error = table->data_mask; goto exit; } while (low <= high) { - if (temp == table.id[mid].temp) - return table.id[mid].code; - else if (temp < table.id[mid].temp) + if (temp == table->id[mid].temp) + return table->id[mid].code; + else if (temp < table->id[mid].temp) high = mid - 1; else low = mid + 1; @@ -429,28 +429,28 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, return error; } -static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, - int *temp) +static int rk_tsadcv2_code_to_temp(const struct chip_tsadc_table *table, + u32 code, int *temp) { unsigned int low = 1; - unsigned int high = table.length - 1; + unsigned int high = table->length - 1; unsigned int mid = (low + high) / 2; unsigned int num; unsigned long denom; - WARN_ON(table.length < 2); + WARN_ON(table->length < 2); - switch (table.mode) { + switch (table->mode) { case ADC_DECREMENT: - code &= table.data_mask; - if (code < table.id[high].code) + code &= table->data_mask; + if (code < table->id[high].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code >= table.id[mid].code && - code < table.id[mid - 1].code) + if (code >= table->id[mid].code && + code < table->id[mid - 1].code) break; - else if (code < table.id[mid].code) + else if (code < table->id[mid].code) low = mid + 1; else high = mid - 1; @@ -459,15 +459,15 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; case ADC_INCREMENT: - code &= table.data_mask; - if (code < table.id[low].code) + code &= table->data_mask; + if (code < table->id[low].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code <= table.id[mid].code
[PATCH v2 3/5] thermal: rockchip: fixes invalid temperature case
The temp_to_code function will return 0 when we set the temperature to a invalid value (e.g. 61C, 62C, 63C), that's unpractical. This patch will prevent this case happening. That will return the max analog value to indicate the temperature is invalid or over table temperature range. Signed-off-by: Caesar Wang --- Changes in v2: - As Brian commnets that restructure this to pass error codes back to the upper layers. - Improve the commit message. Changes in v1: None drivers/thermal/rockchip_thermal.c | 41 ++ 1 file changed, 28 insertions(+), 13 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 766486f..e243e40 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -120,9 +120,9 @@ struct rockchip_tsadc_chip { /* Per-sensor methods */ int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(const struct chip_tsadc_table *table, + int (*set_alarm_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(const struct chip_tsadc_table *table, + int (*set_tshut_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); @@ -401,17 +401,15 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; - u32 error = 0; + u32 error = table->data_mask; low = 0; high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table->id[low].temp || temp > table->id[high].temp) { - error = table->data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) goto exit; - } while (low <= high) { if (temp == table->id[mid].temp) @@ -651,7 +649,7 @@ static int rk_tsadcv2_get_temp(const struct chip_tsadc_table *table, return rk_tsadcv2_code_to_temp(table, val, temp); } -static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, +static int rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { u32 alarm_value, int_en; @@ -659,7 +657,7 @@ static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, /* Make sure the value is valid */ alarm_value = rk_tsadcv2_temp_to_code(table, temp); if (alarm_value == table->data_mask) - return; + return -ERANGE; writel_relaxed(alarm_value & table->data_mask, regs + TSADCV2_COMP_INT(chn)); @@ -667,9 +665,11 @@ static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int_en = readl_relaxed(regs + TSADCV2_INT_EN); int_en |= TSADCV2_INT_SRC_EN(chn); writel_relaxed(int_en, regs + TSADCV2_INT_EN); + + return 0; } -static void rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, +static int rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { u32 tshut_value, val; @@ -677,13 +677,15 @@ static void rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, /* Make sure the value is valid */ tshut_value = rk_tsadcv2_temp_to_code(table, temp); if (tshut_value == table->data_mask) - return; + return -ERANGE; writel_relaxed(tshut_value, regs + TSADCV2_COMP_SHUT(chn)); /* TSHUT will be valid */ val = readl_relaxed(regs + TSADCV2_AUTO_CON); writel_relaxed(val | TSADCV2_AUTO_SRC_EN(chn), regs + TSADCV2_AUTO_CON); + + return 0; } static void rk_tsadcv2_tshut_mode(int chn, void __iomem *regs, @@ -882,12 +884,17 @@ static int rockchip_thermal_set_trips(void *_sensor, int low, int high) struct rockchip_thermal_sensor *sensor = _sensor; struct rockchip_thermal_data *thermal = sensor->thermal; const struct rockchip_tsadc_chip *tsadc = thermal->chip; + int ret; dev_dbg(&thermal->pdev->dev, "%s: sensor %d: low: %d, high %d\n", __func__, sensor->id, low, high); - tsadc->set_alarm_temp(&tsadc->table, + ret = tsadc->set_alarm_temp(&tsadc->table, sensor->id, thermal->regs, high); + if (ret) + dev_err(&thermal->pdev->dev, + "%s: disable sensor[%d]
[PATCH v2 4/5] thermal: rockchip: optimize the conversion table
In order to support the valid temperature can conver to analog value. The rockchip thermal driver has not supported the all valid temperature to convert the analog value. (e.g.: 61C, 62C, 63C) For example: In some cases, we need adjust the trip point. $cd /sys/class/thermal/thermal_zone* $echo 68000 > trip_point_0_temp That will return the max analogic value indicates the invalid before posting this patch. So, this patch will optimize the conversion table to support the other cases. Signed-off-by: Caesar Wang Reviewed-by: Brian Norris --- Changes in v2: - improve the commit as Brian commnets on https://patchwork.kernel.org/patch/9440985 Changes in v1: None drivers/thermal/rockchip_thermal.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index e243e40..0d50df7 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -401,6 +401,8 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; + unsigned long num; + unsigned int denom; u32 error = table->data_mask; low = 0; @@ -421,6 +423,27 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, mid = (low + high) / 2; } + /* +* The conversion code granularity provided by the table. Let's +* assume that the relationship between temperature and +* analog value between 2 table entries is linear and interpolate +* to produce less granular result. +*/ + num = abs(table->id[mid].code - table->id[mid + 1].code); + num *= temp - table->id[mid].temp; + denom = table->id[mid + 1].temp - table->id[mid].temp; + + switch (table->mode) { + case ADC_DECREMENT: + return table->id[mid].code - (num / denom); + case ADC_INCREMENT: + return table->id[mid].code + (num / denom); + default: + pr_err("%s: invalid conversion table, mode=%d\n", + __func__, table->mode); + return error; + } + exit: pr_err("%s: invalid temperature, temp=%d error=%d\n", __func__, temp, error); -- 2.7.4
[PATCH v2 1/5] thermal: rockchip: improve conversion error messages
From: Brian Norris These error messages don't give much information about what went wrong. It would be nice, for one, to see what invalid temperature was being requested when conversion fails. It's also good to return an error when we can't handle a conversion properly. While we're at it, fix the grammar too. Signed-off-by: Brian Norris Signed-off-by: Caesar Wang --- Changes in v2: None 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... drivers/thermal/rockchip_thermal.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index b811b0f..26c247c 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, } exit: - pr_err("Invalid the conversion, error=%d\n", error); + pr_err("%s: invalid temperature, temp=%d error=%d\n", + __func__, temp, error); return error; } @@ -475,7 +476,9 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; default: - pr_err("Invalid the conversion table\n"); + pr_err("%s: invalid conversion table, mode=%d\n", + __func__, table.mode); + return -EINVAL; } /* -- 2.7.4
Re: [PATCH 3/5] thermal: rockchip: fixes invalid temperature case
在 2016年11月23日 10:33, Brian Norris 写道: On Wed, Nov 23, 2016 at 10:06:15AM +0800, Caesar Wang wrote: 在 2016年11月23日 05:52, Brian Norris 写道: On Tue, Nov 22, 2016 at 12:57:37PM -0800, Brian Norris wrote: + if (temp < table->id[low].temp || temp > table->id[high].temp) goto exit; I was revisiting the logic here though, and I don't understand your error case. You're treating "too low" and "too high" the same, and in either case, you're choosing a value of ->data_mask. That doesn't make sense to me, especially for ADC_DECREMENT cases like rk3288. In that case, you're programming the trip to the lowest possible temperature. I admit that's not perfect, but that should conform to reality. Whichever is the adc value, 12it or 10bit. #define TSADCV2_DATA_MASK0xfff #define TSADCV3_DATA_MASK0x3ff The "too low" and "too high" are same, that should indicate that temperature is invalid or over table range. The currect code will return the max analog value to warn it. --- The temperature {-40C, 125C} is for rockchip SoCs, that should be similar with real world's temperature {-INT_MAX, INT_MAX}. IIUC, "too high" should not be interpreted as TSADCV2_DATA_MASK on rk3288, should it? That corresponds to -40C, which means you'll be triggering the alarm temperature at a very *low* temperature, not a very high one, no? The "too high" will correspond to -40C on rk3288, but shouldn't trigger the alarm temperature. Due to the alarm or tshut function will handle it. e.g.: static void rk_tsadcv2_alarm_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { u32 alarm_value, int_en; /* Make sure the value is valid */ alarm_value = rk_tsadcv2_temp_to_code(table, temp); if (alarm_value == table->data_mask) return; } or static void rk_tsadcv2_tshut_temp(const struct chip_tsadc_table *table, int chn, void __iomem *regs, int temp) { u32 tshut_value, val; /* Make sure the value is valid */ tshut_value = rk_tsadcv2_temp_to_code(table, temp); if (tshut_value == table->data_mask) return; ... } Brian ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH 3/5] thermal: rockchip: fixes invalid temperature case
在 2016年11月23日 05:52, Brian Norris 写道: On Tue, Nov 22, 2016 at 12:57:37PM -0800, Brian Norris wrote: On Tue, Nov 22, 2016 at 08:34:46PM +0800, Caesar Wang wrote: The temp_to_code function will return 0 when we set the trip points value or valid temperature. I'm not quite sure what you mean by "when we set the trip points value or valid temperature." Do you mean "when we set the trip point's value to an invalid temperature"? Assuming that's what you meant... Almost, I will improve the commit. This patch will prevent this case happening. This is good to change, but IMO, it's better to actually pick a close value, instead of the max. e.g., if you support temperatures at degree intervals of 80, 85, 90, ..., 125, but someone lists 82 in the device tree, we should pick either 80 or 85, not 125. I see that's what you're doing in a patch later in this series. Good. Yeah, find another issue during writing this patch, as the patch[4/5]. Signed-off-by: Caesar Wang --- drivers/thermal/rockchip_thermal.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 766486f..535f1fa 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -401,17 +401,15 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; - u32 error = 0; + u32 error = table->data_mask; low = 0; high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table->id[low].temp || temp > table->id[high].temp) { - error = table->data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) goto exit; I was revisiting the logic here though, and I don't understand your error case. You're treating "too low" and "too high" the same, and in either case, you're choosing a value of ->data_mask. That doesn't make sense to me, especially for ADC_DECREMENT cases like rk3288. In that case, you're programming the trip to the lowest possible temperature. I admit that's not perfect, but that should conform to reality. Whichever is the adc value, 12it or 10bit. #define TSADCV2_DATA_MASK0xfff #define TSADCV3_DATA_MASK0x3ff The "too low" and "too high" are same, that should indicate that temperature is invalid or over table range. The currect code will return the max analog value to warn it. --- The temperature {-40C, 125C} is for rockchip SoCs, that should be similar with real world's temperature {-INT_MAX, INT_MAX}. -Caesar It seems like either you should make this conditional, so that "too low" and "too high" make sane alternative choices (like MAX or MIN temp), or else restructure this to pass error codes back to the upper layers. Brian - } while (low <= high) { if (temp == table->id[mid].temp) -- 2.7.4 ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH 2/3] thermal: rockchip: improve conversion error messages
在 2016年11月22日 15:57, Zhang Rui 写道: On Tue, 2016-11-22 at 09:51 +0800, Caesar Wang wrote: 在 2016年11月19日 11:31, Caesar Wang 写道: Brian, 在 2016年11月19日 07:52, Brian Norris 写道: These error messages don't give much information about what went wrong. It would be nice, for one, to see what invalid temperature was being requested when conversion fails. It's also good to return an error when we can't handle a conversion properly. While we're at it, fix the grammar too. Signed-off-by: Brian Norris --- Note: it'd probably be even nicer to know which sensor this was, but we've kinda abstracted that one away by this point... drivers/thermal/rockchip_thermal.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index e227a9f0acf7..35554d146b9d 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, } exit: -pr_err("Invalid the conversion, error=%d\n", error); +pr_err("%s: invalid temperature, temp=%d error=%d\n", +__func__, temp, error); I have do some similar for rockchip inside thermal driver. Forget to send for upstream. :( exit: pr_err("%s: Invalid conversion table: code=%d, temperature=%d\n", __func__, error, temp); return error; } @@ -475,7 +476,9 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; default: -pr_err("Invalid the conversion table\n"); +pr_err("%s: invalid conversion table, mode=%d\n", +__func__, table.mode); +return -EINVAL; CHECK: Alignment should match open parenthesis #428: FILE: drivers/thermal/rockchip_thermal.c:428: +pr_err("%s: invalid temperature, temp=%d error=%d\n", +__func__, temp, error); CHECK: Alignment should match open parenthesis #480: FILE: drivers/thermal/rockchip_thermal.c:480: +pr_err("%s: invalid conversion table, mode=%d\n", +__func__, table->mode); I'm ready to resend all rockchip thermal patches. (contain them) so I will ignore patch 2/3 and 3/3 for now and wait for your new patch set. Posted the patch set on https://lkml.org/lkml/2016/11/22/250 thanks, rui } /* ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[PATCH 2/5] thermal: rockchip: don't pass table structs by value
From: Brian Norris This driver passes struct chip_tsadc_table by value throughout; this is inefficient, and AFAICT, there is no reason for it. Let's pass pointers instead. Signed-off-by: Brian Norris Reviewed-by: Caesar Wang Tested-by: Caesar Wang --- Changes: - The original Brian posted on https://patchwork.kernel.org/patch/9437687 drivers/thermal/rockchip_thermal.c | 80 +++--- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 26c247c..766486f 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -118,11 +118,11 @@ struct rockchip_tsadc_chip { void (*control)(void __iomem *reg, bool on); /* Per-sensor methods */ - int (*get_temp)(struct chip_tsadc_table table, + int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(struct chip_tsadc_table table, + void (*set_alarm_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(struct chip_tsadc_table table, + void (*set_tshut_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); @@ -397,26 +397,26 @@ static const struct tsadc_table rk3399_code_table[] = { {TSADCV3_DATA_MASK, 125000}, }; -static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, +static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; u32 error = 0; low = 0; - high = table.length - 1; + high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table.id[low].temp || temp > table.id[high].temp) { - error = table.data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) { + error = table->data_mask; goto exit; } while (low <= high) { - if (temp == table.id[mid].temp) - return table.id[mid].code; - else if (temp < table.id[mid].temp) + if (temp == table->id[mid].temp) + return table->id[mid].code; + else if (temp < table->id[mid].temp) high = mid - 1; else low = mid + 1; @@ -429,28 +429,28 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, return error; } -static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, - int *temp) +static int rk_tsadcv2_code_to_temp(const struct chip_tsadc_table *table, + u32 code, int *temp) { unsigned int low = 1; - unsigned int high = table.length - 1; + unsigned int high = table->length - 1; unsigned int mid = (low + high) / 2; unsigned int num; unsigned long denom; - WARN_ON(table.length < 2); + WARN_ON(table->length < 2); - switch (table.mode) { + switch (table->mode) { case ADC_DECREMENT: - code &= table.data_mask; - if (code < table.id[high].code) + code &= table->data_mask; + if (code < table->id[high].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code >= table.id[mid].code && - code < table.id[mid - 1].code) + if (code >= table->id[mid].code && + code < table->id[mid - 1].code) break; - else if (code < table.id[mid].code) + else if (code < table->id[mid].code) low = mid + 1; else high = mid - 1; @@ -459,15 +459,15 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; case ADC_INCREMENT: - code &= table.data_mask; - if (code < table.id[low].code) + code &= table->data_mask; + if (code < table->id[low].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code <= table.id[mid].code && -
[PATCH 0/5] thermal: rockchip: optimization to improve the driver
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. -- 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 issue in special cases. -- Anyway, this series patches should can improve the rockchip thermal driver. 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 the set_trips without the trip points. drivers/thermal/rockchip_thermal.c | 123 - 1 file changed, 80 insertions(+), 43 deletions(-) -- 2.7.4
[PATCH 3/5] thermal: rockchip: fixes invalid temperature case
The temp_to_code function will return 0 when we set the trip points value or valid temperature. This patch will prevent this case happening. Signed-off-by: Caesar Wang --- drivers/thermal/rockchip_thermal.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 766486f..535f1fa 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -401,17 +401,15 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; - u32 error = 0; + u32 error = table->data_mask; low = 0; high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table->id[low].temp || temp > table->id[high].temp) { - error = table->data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) goto exit; - } while (low <= high) { if (temp == table->id[mid].temp) -- 2.7.4
[PATCH 5/5] thermal: rockchip: handle the set_trips without the trip points.
In some cases, some sensors didn't need the trip points, the set_trips will return {-INT_MAX, INT_MAX} to trigger thermal alarm. Signed-off-by: Caesar Wang --- drivers/thermal/rockchip_thermal.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index f4d4be9..5b9c346 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -200,6 +200,7 @@ struct rockchip_thermal_data { #define TSADCV3_AUTO_Q_SEL_EN BIT(1) #define TSADCV2_INT_SRC_EN(chn)BIT(chn) +#define TSADCV2_INT_SRC_SHIFT(chn) chn #define TSADCV2_SHUT_2GPIO_SRC_EN(chn) BIT(4 + (chn)) #define TSADCV2_SHUT_2CRU_SRC_EN(chn) BIT(8 + (chn)) @@ -903,10 +904,22 @@ static int rockchip_thermal_set_trips(void *_sensor, int low, int high) struct rockchip_thermal_sensor *sensor = _sensor; struct rockchip_thermal_data *thermal = sensor->thermal; const struct rockchip_tsadc_chip *tsadc = thermal->chip; + u32 int_clr; dev_dbg(&thermal->pdev->dev, "%s: sensor %d: low: %d, high %d\n", __func__, sensor->id, low, high); + /* +* In some cases, some sensors didn't need the trip points, the +* set_trips will return {-INT_MAX, INT_MAX} to trigger thermal alarm. +*/ + if (high == INT_MAX) { + int_clr = readl_relaxed(thermal->regs + TSADCV2_INT_EN); + int_clr |= 0 << TSADCV2_INT_SRC_SHIFT(sensor->id); + writel_relaxed(int_clr, thermal->regs + TSADCV2_INT_EN); + return 0; + } + tsadc->set_alarm_temp(&tsadc->table, sensor->id, thermal->regs, high); -- 2.7.4
[PATCH 4/5] thermal: rockchip: optimize the conversion table
In order to support the valid temperature can conver to analog value. The rockchip thermal has not supported the all valid temperature. For example: In some cases, we need adjust the trip point. $cd /sys/class/thermal/thermal_zone* echo 68000 > trip_point_0_temp That will report the error message before posting this patch. Signed-off-by: Caesar Wang --- drivers/thermal/rockchip_thermal.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 535f1fa..f4d4be9 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -401,6 +401,8 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; + unsigned long num; + unsigned int denom; u32 error = table->data_mask; low = 0; @@ -421,6 +423,27 @@ static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, mid = (low + high) / 2; } + /* +* The conversion code granularity provided by the table. Let's +* assume that the relationship between temperature and +* analog value between 2 table entries is linear and interpolate +* to produce less granular result. +*/ + num = abs(table->id[mid].code - table->id[mid + 1].code); + num *= temp - table->id[mid].temp; + denom = table->id[mid + 1].temp - table->id[mid].temp; + + switch (table->mode) { + case ADC_DECREMENT: + return table->id[mid].code - (num / denom); + case ADC_INCREMENT: + return table->id[mid].code + (num / denom); + default: + pr_err("%s: invalid conversion table, mode=%d\n", + __func__, table->mode); + return error; + } + exit: pr_err("%s: invalid temperature, temp=%d error=%d\n", __func__, temp, error); -- 2.7.4
[PATCH 1/5] thermal: rockchip: improve conversion error messages
From: Brian Norris These error messages don't give much information about what went wrong. It would be nice, for one, to see what invalid temperature was being requested when conversion fails. It's also good to return an error when we can't handle a conversion properly. While we're at it, fix the grammar too. Signed-off-by: Brian Norris Signed-off-by: Caesar Wang --- Changes: - The original Brian posted on https://patchwork.kernel.org/patch/9437685 Brain said: "Note: it'd probably be even nicer to know which sensor this was, but we've kinda abstracted that one away by this point..." drivers/thermal/rockchip_thermal.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index b811b0f..26c247c 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, } exit: - pr_err("Invalid the conversion, error=%d\n", error); + pr_err("%s: invalid temperature, temp=%d error=%d\n", + __func__, temp, error); return error; } @@ -475,7 +476,9 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; default: - pr_err("Invalid the conversion table\n"); + pr_err("%s: invalid conversion table, mode=%d\n", + __func__, table.mode); + return -EINVAL; } /* -- 2.7.4
Re: [PATCH 2/3] thermal: rockchip: improve conversion error messages
在 2016年11月22日 10:15, Brian Norris 写道: On Tue, Nov 22, 2016 at 09:51:23AM +0800, Caesar Wang wrote: CHECK: Alignment should match open parenthesis #428: FILE: drivers/thermal/rockchip_thermal.c:428: +pr_err("%s: invalid temperature, temp=%d error=%d\n", +__func__, temp, error); CHECK: Alignment should match open parenthesis #480: FILE: drivers/thermal/rockchip_thermal.c:480: +pr_err("%s: invalid conversion table, mode=%d\n", +__func__, table->mode); What patch are you checking? I ran mine through checkpatch, and there are no problems. That just checkcode on Chromeos kernelv4.4, that trivial things :) $chromiumos/src/third_party/kernel/v4.4$ checkcode drivers/thermal/rockchip_thermal.c CHECK: Alignment should match open parenthesis #428: FILE: drivers/thermal/rockchip_thermal.c:428: +pr_err("%s: invalid temperature, temp=%d error=%d\n", +__func__, temp, error); ... vi drivers/thermal/rockchip_thermal.c +428 or vi drivers/thermal/rockchip_thermal.c +480, Did you perhaps mangle the tabs into spaces when you saved the patch? I'm ready to resend all rockchip thermal patches. (contain them) I see no reason to resend so far; the only criticism was on the 1st patch (a non-critical patch to the core thermal code; the others are relatively independent, as long as you don't care that I'm adding another error return without fixing up the broken CONFIG_THERMAL_EMULATION support). Brian
Re: [PATCH 2/3] thermal: rockchip: improve conversion error messages
在 2016年11月19日 11:31, Caesar Wang 写道: Brian, 在 2016年11月19日 07:52, Brian Norris 写道: These error messages don't give much information about what went wrong. It would be nice, for one, to see what invalid temperature was being requested when conversion fails. It's also good to return an error when we can't handle a conversion properly. While we're at it, fix the grammar too. Signed-off-by: Brian Norris --- Note: it'd probably be even nicer to know which sensor this was, but we've kinda abstracted that one away by this point... drivers/thermal/rockchip_thermal.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index e227a9f0acf7..35554d146b9d 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, } exit: -pr_err("Invalid the conversion, error=%d\n", error); +pr_err("%s: invalid temperature, temp=%d error=%d\n", +__func__, temp, error); I have do some similar for rockchip inside thermal driver. Forget to send for upstream. :( exit: pr_err("%s: Invalid conversion table: code=%d, temperature=%d\n", __func__, error, temp); return error; } @@ -475,7 +476,9 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; default: -pr_err("Invalid the conversion table\n"); +pr_err("%s: invalid conversion table, mode=%d\n", +__func__, table.mode); +return -EINVAL; CHECK: Alignment should match open parenthesis #428: FILE: drivers/thermal/rockchip_thermal.c:428: +pr_err("%s: invalid temperature, temp=%d error=%d\n", +__func__, temp, error); CHECK: Alignment should match open parenthesis #480: FILE: drivers/thermal/rockchip_thermal.c:480: +pr_err("%s: invalid conversion table, mode=%d\n", +__func__, table->mode); I'm ready to resend all rockchip thermal patches. (contain them) } /* ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
在 2016年11月15日 00:05, Heiko Stuebner 写道: Am Mittwoch, 9. November 2016, 21:21:55 CET schrieb Caesar Wang: From: Mark Yao Add the core display-subsystem node and the two display controllers available on the rk3399. Signed-off-by: Mark Yao Signed-off-by: Yakir Yang Signed-off-by: Caesar Wang --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58 1 file changed, 58 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index e5b5b3d..f1d289a 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -1290,6 +1290,64 @@ status = "disabled"; }; + vopl: vop@ff8f { + compatible = "rockchip,rk3399-vop-lit"; + reg = <0x0 0xff8f 0x0 0x3efc>; + interrupts = ; we're usig 4 irq elements nowadays to accomodate the pmus for separate clusters, see https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=210bbd38bb88989ce19208f98e530ff0468f38bd Same for the edp node. Ah! Sorry. Also, sadly the rockchip drm seems to need some tweaks still, as I wasn't able to get any display output yet. To make the vop at least compile I needed to forward-port https://github.com/mmind/linux-rockchip/commit/05ad856e54fc1aa1939ad1057897036cedc7fb0b https://github.com/mmind/linux-rockchip/commit/0edb1f7e1ac77437a17d7966121ee6e10ab5db67 [full branch is https://github.com/mmind/linux-rockchip/commits/tmp/testing_20161109 ] Pls allow me to have a look at it and bring up with ChromeOs, the upstream maybe miss some patches for upstream. (DRM or IOMMU or ) I will resend the other patches if I bring up and show display with upstream on https://github.com/Caesar-github/rockchip/commits/rk3399/tmp-test -Caesar but I'm not sure if I did that correctly yet and am also still seeing nothing on the display and get iommu errors when starting X11 Heiko + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>; + reset-names = "axi", "ahb", "dclk"; + iommus = <&vopl_mmu>; + status = "disabled"; + + vopl_out: port { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + vopl_mmu: iommu@ff8f3f00 { + compatible = "rockchip,iommu"; + reg = <0x0 0xff8f3f00 0x0 0x100>; + interrupts = ; + interrupt-names = "vopl_mmu"; + #iommu-cells = <0>; + status = "disabled"; + }; + + vopb: vop@ff90 { + compatible = "rockchip,rk3399-vop-big"; + reg = <0x0 0xff90 0x0 0x3efc>; + interrupts = ; + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>; + reset-names = "axi", "ahb", "dclk"; + iommus = <&vopb_mmu>; + status = "disabled"; + + vopb_out: port { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + vopb_mmu: iommu@ff903f00 { + compatible = "rockchip,iommu"; + reg = <0x0 0xff903f00 0x0 0x100>; + interrupts = ; + interrupt-names = "vopb_mmu"; + #iommu-cells = <0>; + status = "disabled"; + }; + + display_subsystem: display-subsystem { + compatible = "rockchip,display-subsystem"; + ports = <&vopl_out>, <&vopb_out>; + status = "disabled"; + }; + pinctrl: pinctrl { compatible = "rockchip,rk3399-pinctrl"; rockchip,grf = <&grf>; ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[PATCH v2.1 7/9] arm64: dts: rockchip: add pd_edp node for rk3399
From: zhangqing This patch adds the below pd_edp information for rk3399. 1. add pd_edp node for RK3399 SoC 2. add the pd support for edp Signed-off-by: Elaine Zhang Signed-off-by: Caesar Wang Reviewed-by: Doug Anderson --- Changes in v2.1: (Hope the v3 will fix the display stuff with upstream) - change the commit message as Doug comments on https://patchwork.kernel.org/patch/9419241 Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index db72033..7354c63 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -838,6 +838,10 @@ }; /* These power domains are grouped by VD_LOGIC */ + pd_edp@RK3399_PD_EDP { + reg = ; + clocks = <&cru PCLK_EDP_CTRL>; + }; pd_emmc@RK3399_PD_EMMC { reg = ; clocks = <&cru ACLK_EMMC>; @@ -1388,6 +1392,7 @@ status = "disabled"; pinctrl-names = "default"; pinctrl-0 = <&edp_hpd>; + power-domains = <&power RK3399_PD_EDP>; ports { #address-cells = <1>; -- 2.7.4
Re: [PATCH 3/3] thermal: rockchip: don't pass table structs by value
在 2016年11月19日 07:52, Brian Norris 写道: This driver passes struct chip_tsadc_table by value throughout; this is inefficient, and AFAICT, there is no reason for it. Let's pass pointers instead. Signed-off-by: Brian Norris Reviewed-by: Caesar Wang Tested-by: Caesar Wang Yup, that make sense to improve efficiency. Thanks the fixes. And tested on rk3399 evb board. --- drivers/thermal/rockchip_thermal.c | 80 +++--- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 35554d146b9d..30fb95a0dff0 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -118,11 +118,11 @@ struct rockchip_tsadc_chip { void (*control)(void __iomem *reg, bool on); /* Per-sensor methods */ - int (*get_temp)(struct chip_tsadc_table table, + int (*get_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int *temp); - void (*set_alarm_temp)(struct chip_tsadc_table table, + void (*set_alarm_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); - void (*set_tshut_temp)(struct chip_tsadc_table table, + void (*set_tshut_temp)(const struct chip_tsadc_table *table, int chn, void __iomem *reg, int temp); void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m); @@ -397,26 +397,26 @@ static const struct tsadc_table rk3399_code_table[] = { {TSADCV3_DATA_MASK, 125000}, }; -static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, +static u32 rk_tsadcv2_temp_to_code(const struct chip_tsadc_table *table, int temp) { int high, low, mid; u32 error = 0; low = 0; - high = table.length - 1; + high = table->length - 1; mid = (high + low) / 2; /* Return mask code data when the temp is over table range */ - if (temp < table.id[low].temp || temp > table.id[high].temp) { - error = table.data_mask; + if (temp < table->id[low].temp || temp > table->id[high].temp) { + error = table->data_mask; goto exit; } while (low <= high) { - if (temp == table.id[mid].temp) - return table.id[mid].code; - else if (temp < table.id[mid].temp) + if (temp == table->id[mid].temp) + return table->id[mid].code; + else if (temp < table->id[mid].temp) high = mid - 1; else low = mid + 1; @@ -429,28 +429,28 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, return error; } -static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, - int *temp) +static int rk_tsadcv2_code_to_temp(const struct chip_tsadc_table *table, + u32 code, int *temp) { unsigned int low = 1; - unsigned int high = table.length - 1; + unsigned int high = table->length - 1; unsigned int mid = (low + high) / 2; unsigned int num; unsigned long denom; - WARN_ON(table.length < 2); + WARN_ON(table->length < 2); - switch (table.mode) { + switch (table->mode) { case ADC_DECREMENT: - code &= table.data_mask; - if (code < table.id[high].code) + code &= table->data_mask; + if (code < table->id[high].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code >= table.id[mid].code && - code < table.id[mid - 1].code) + if (code >= table->id[mid].code && + code < table->id[mid - 1].code) break; - else if (code < table.id[mid].code) + else if (code < table->id[mid].code) low = mid + 1; else high = mid - 1; @@ -459,15 +459,15 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; case ADC_INCREMENT: - code &= table.data_mask; - if (code < table.id[low].code) + code &= table->data_mask; + if (code < table->id[low].code) return -EAGAIN; /* Incorrect reading */ while (low <= high) { - if (code <= table.id[mid].code && -
Re: [PATCH 2/3] thermal: rockchip: improve conversion error messages
在 2016年11月19日 11:31, Caesar Wang 写道: Brian, 在 2016年11月19日 07:52, Brian Norris 写道: These error messages don't give much information about what went wrong. It would be nice, for one, to see what invalid temperature was being requested when conversion fails. It's also good to return an error when we can't handle a conversion properly. While we're at it, fix the grammar too. Signed-off-by: Brian Norris Reviewed-by: Caesar w...@rock-chips.com Thanks the fixes. -Caesar --- Note: it'd probably be even nicer to know which sensor this was, but we've kinda abstracted that one away by this point... drivers/thermal/rockchip_thermal.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index e227a9f0acf7..35554d146b9d 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, } exit: -pr_err("Invalid the conversion, error=%d\n", error); +pr_err("%s: invalid temperature, temp=%d error=%d\n", +__func__, temp, error); I have do some similar for rockchip inside thermal driver. Forget to send for upstream. :( exit: pr_err("%s: Invalid conversion table: code=%d, temperature=%d\n", __func__, error, temp); return error; } @@ -475,7 +476,9 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; default: -pr_err("Invalid the conversion table\n"); +pr_err("%s: invalid conversion table, mode=%d\n", +__func__, table.mode); +return -EINVAL; } /*
Re: [PATCH 2/3] thermal: rockchip: improve conversion error messages
Brian, 在 2016年11月19日 07:52, Brian Norris 写道: These error messages don't give much information about what went wrong. It would be nice, for one, to see what invalid temperature was being requested when conversion fails. It's also good to return an error when we can't handle a conversion properly. While we're at it, fix the grammar too. Signed-off-by: Brian Norris --- Note: it'd probably be even nicer to know which sensor this was, but we've kinda abstracted that one away by this point... drivers/thermal/rockchip_thermal.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index e227a9f0acf7..35554d146b9d 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -424,7 +424,8 @@ static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table, } exit: - pr_err("Invalid the conversion, error=%d\n", error); + pr_err("%s: invalid temperature, temp=%d error=%d\n", + __func__, temp, error); I have do some similar for rockchip inside thermal driver. Forget to send for upstream. :( exit: pr_err("%s: Invalid conversion table: code=%d, temperature=%d\n", __func__, error, temp); return error; } @@ -475,7 +476,9 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code, } break; default: - pr_err("Invalid the conversion table\n"); + pr_err("%s: invalid conversion table, mode=%d\n", + __func__, table.mode); + return -EINVAL; } /*
Re: [PATCH 1/3] thermal: handle get_temp() errors properly
Brian, 在 2016年11月19日 07:52, Brian Norris 写道: If using CONFIG_THERMAL_EMULATION, there's a corner case where we might get an error from the zone's get_temp() callback, but we'll ignore that and keep using its value. Let's just error out properly instead. Signed-off-by: Brian Norris Tested-by: Caesar Wang [8.111296] thermal thermal_zone4: power_allocator: sustainable_power will be estimated [8.119420] thermal_zone_get_temp:537 the ret=-19, no such device, look like the A/D value had no ready yet. .. Anyway, this patch is useful for improving thermal. -Caesar --- drivers/thermal/thermal_core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index 911fd964c742..0fa497f10d25 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -494,6 +494,8 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp) mutex_lock(&tz->lock); ret = tz->ops->get_temp(tz, temp); + if (ret) + goto exit_unlock; if (IS_ENABLED(CONFIG_THERMAL_EMULATION) && tz->emul_temperature) { for (count = 0; count < tz->trips; count++) { @@ -514,6 +516,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp) *temp = tz->emul_temperature; } +exit_unlock: mutex_unlock(&tz->lock); exit: return ret;