* [PATCH v2, 6/6] dt-bindings: phy-mt65xx-usb: add support for new version phy
From: Chunfeng Yun @ 2017-01-20 8:18 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi,
Ian Campbell, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chunfeng Yun, Rob Herring,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484900321-26933-1-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
add a new compatible string for "mt2712", and move reference clock
into each port node;
Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 91 +++++++++++++++++---
1 file changed, 77 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..1d06604 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,21 +6,27 @@ This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
Required properties (controller (parent) node):
- compatible : should be one of
"mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
"mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain
- "u3phya_ref": for reference clock of usb3.0 analog phy.
Required nodes : a sub-node is required for each port the controller
provides. Address range information including the usual
'reg' property is used inside these nodes to describe
the controller's topology.
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
Required properties (port (child) node):
- reg : address and length of the register set for the port.
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : must contain
+ "ref_clk": 48M reference clock for HighSpeed analog phy; and
+ 26M reference clock for SuperSpeed analog phy, sometimes is
+ 24M, 25M or 27M, depended on platform.
- #phy-cells : should be 1 (See second example)
cell after port phandle is phy type from:
- PHY_TYPE_USB2
@@ -31,21 +37,31 @@ Example:
u3phy: usb-phy@11290000 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x11290000 0 0x800>;
- clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
- clock-names = "u3phya_ref";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
- phy_port0: port@11290800 {
- reg = <0 0x11290800 0 0x800>;
+ u2port0: port@11290800 {
+ reg = <0 0x11290800 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref_clk";
#phy-cells = <1>;
status = "okay";
};
- phy_port1: port@11291000 {
- reg = <0 0x11291000 0 0x800>;
+ u3port0: port@11290900 {
+ reg = <0 0x11290800 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref_clk";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: port@11291000 {
+ reg = <0 0x11291000 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref_clk";
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +80,54 @@ Example:
usb30: usb@11270000 {
...
- phys = <&phy_port0 PHY_TYPE_USB3>;
- phy-names = "usb3-0";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+ phy-names = "usb2-0", "usb3-0";
...
};
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-------------------------------------------------------------
+mt8173 and mt2701:
+port offset bank
+shared 0x0000 SPLLC
+ 0x0100 FMREG
+u2 port0 0x0800 U2PHY_COM
+u3 port0 0x0900 U3PHYD
+ 0x0a00 U3PHYD_BANK2
+ 0x0b00 U3PHYA
+ 0x0c00 U3PHYA_DA
+u2 port1 0x1000 U2PHY_COM
+u3 port1 0x1100 U3PHYD
+ 0x1200 U3PHYD_BANK2
+ 0x1300 U3PHYA
+ 0x1400 U3PHYA_DA
+u2 port2 0x1800 U2PHY_COM
+ ...
+
+mt2712:
+port offset bank
+u2 port0 0x0000 MISC
+ 0x0100 FMREG
+ 0x0300 U2PHY_COM
+u3 port0 0x0700 SPLLC
+ 0x0800 CHIP
+ 0x0900 U3PHYD
+ 0x0a00 U3PHYD_BANK2
+ 0x0b00 U3PHYA
+ 0x0c00 U3PHYA_DA
+u2 port1 0x1000 MISC
+ 0x1100 FMREG
+ 0x1300 U2PHY_COM
+u3 port1 0x1700 SPLLC
+ 0x1800 CHIP
+ 0x1900 U3PHYD
+ 0x1a00 U3PHYD_BANK2
+ 0x1b00 U3PHYA
+ 0x1c00 U3PHYA_DA
+u2 port2 0x2000 MISC
+ ...
+
+ SPLLC shared by u3 ports and FMREG shared by u2 ports on
+mt8173/mt2701 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on mt2712.
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v3 3/3] mmc: mediatek: Use data tune for CMD line tune
From: Ulf Hansson @ 2017-01-20 8:22 UTC (permalink / raw)
To: Yong Mao
Cc: Linus Walleij, Chaotian Jing, Eddie Huang, Chunfeng Yun,
linux-mmc@vger.kernel.org, srv_heupstream, linux-mediatek,
linux-kernel@vger.kernel.org
In-Reply-To: <1484821156-20565-4-git-send-email-yong.mao@mediatek.com>
[...]
> struct msdc_delay_phase {
> @@ -331,6 +339,9 @@ struct msdc_host {
> unsigned char timing;
> bool vqmmc_enabled;
> u32 hs400_ds_delay;
> + u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
> + u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
> + u32 hs400_cmd_resp_sel; /* cmd response sample selection for HS400 */
When you converted the DT binding, this should become bool instead.
> bool hs400_mode; /* current eMMC will run at hs400 mode */
> struct msdc_save_para save_para; /* used when gate HCLK */
> struct msdc_tune_para def_tune_para; /* default tune setting */
[...]
> +static void msdc_of_property_parse(struct platform_device *pdev,
> + struct msdc_host *host)
> +{
> + if (!of_property_read_u32(pdev->dev.of_node, "hs400-ds-delay",
> + &host->hs400_ds_delay))
> + dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
> + host->hs400_ds_delay);
Writing a dev_dbg for each parsed DT property, seems a bit silly. Can
you please remove that.
> +
> + if (!of_property_read_u32(pdev->dev.of_node, "mtk-hs200-cmd-int-delay",
> + &host->hs200_cmd_int_delay))
> + dev_dbg(&pdev->dev, "host->hs200-cmd-int-delay: %x\n",
> + host->hs200_cmd_int_delay);
> +
> + if (!of_property_read_u32(pdev->dev.of_node, "mtk-hs400-cmd-int-delay",
> + &host->hs400_cmd_int_delay))
> + dev_dbg(&pdev->dev, "host->hs400-cmd-int-delay: %x\n",
> + host->hs400_cmd_int_delay);
> +
> + if (!of_property_read_u32(pdev->dev.of_node, "mtk-hs400-cmd-resp-sel",
> + &host->hs400_cmd_resp_sel))
> + dev_dbg(&pdev->dev, "host->hs200_cmd-resp-sel: %x\n",
> + host->hs400_cmd_resp_sel);
> +}
> +
> static int msdc_drv_probe(struct platform_device *pdev)
> {
> struct mmc_host *mmc;
> @@ -1497,7 +1635,6 @@ static int msdc_drv_probe(struct platform_device *pdev)
> ret = mmc_of_parse(mmc);
> if (ret)
> goto host_free;
> -
Whitespace.
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> host->base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(host->base)) {
> @@ -1548,10 +1685,7 @@ static int msdc_drv_probe(struct platform_device *pdev)
> goto host_free;
> }
>
> - if (!of_property_read_u32(pdev->dev.of_node, "hs400-ds-delay",
> - &host->hs400_ds_delay))
> - dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
> - host->hs400_ds_delay);
> + msdc_of_property_parse(pdev, host);
>
> host->dev = &pdev->dev;
> host->mmc = mmc;
> @@ -1663,6 +1797,7 @@ static void msdc_save_reg(struct msdc_host *host)
> host->save_para.patch_bit0 = readl(host->base + MSDC_PATCH_BIT);
> host->save_para.patch_bit1 = readl(host->base + MSDC_PATCH_BIT1);
> host->save_para.pad_ds_tune = readl(host->base + PAD_DS_TUNE);
> + host->save_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
> host->save_para.emmc50_cfg0 = readl(host->base + EMMC50_CFG0);
> }
>
> @@ -1675,6 +1810,7 @@ static void msdc_restore_reg(struct msdc_host *host)
> writel(host->save_para.patch_bit0, host->base + MSDC_PATCH_BIT);
> writel(host->save_para.patch_bit1, host->base + MSDC_PATCH_BIT1);
> writel(host->save_para.pad_ds_tune, host->base + PAD_DS_TUNE);
> + writel(host->save_para.pad_cmd_tune, host->base + PAD_CMD_TUNE);
> writel(host->save_para.emmc50_cfg0, host->base + EMMC50_CFG0);
> }
>
> --
> 1.7.9.5
>
Please also fold in the change suggested/reported by the kbuild test robot.
Besides the minor things, this looks good to me!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] clk: mediatek: Fix MT2701 dependencies
From: Stephen Boyd @ 2017-01-20 23:22 UTC (permalink / raw)
To: Jean Delvare
Cc: James Liao, Andreas Färber, linux-clk, linux-mediatek,
Matthias Brugger, Erin Lo, Shunli Wang, Michael Turquette
In-Reply-To: <20170112094011.0e0a32e6@endymion>
On 01/12, Jean Delvare wrote:
> Hi James,
>
> On Thu, 12 Jan 2017 11:39:52 +0800, James Liao wrote:
> > On Wed, 2017-01-11 at 13:41 +0100, Jean Delvare wrote:
> > > config COMMON_CLK_MT8173
> > > bool "Clock driver for Mediatek MT8173"
> > > - depends on ARCH_MEDIATEK || COMPILE_TEST
> > > + depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
> > > select COMMON_CLK_MEDIATEK
> > > - default ARCH_MEDIATEK
> > > + default y
> > > ---help---
> > > This driver supports Mediatek MT8173 clocks.
> >
> > Although MT8173 is a 64-bit SoC, but 32-bit kernel can run on it. So I
> > think it no need to limit COMMON_CLK_MT8173 only be enabled on ARM64
> > platform.
>
> OK, I'll leave that one alone then, thanks for the information.
>
Is this patch going another round? I haven't seen anything on the
list so far.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RESEND PATCH net] macsec: fix validation failed in asynchronous operation.
From: Ryder Lee @ 2017-01-21 8:42 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Sabrina Dubroca, linux-mediatek, Ryder Lee
Add missing "macsec_skb_cb(skb)->valid = true" in callback
function macsec_decrypt_done(), this fixes packet validation
failed while decrypting asynchronously.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/net/macsec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index f83cf66..73d8d39 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -880,6 +880,9 @@ static void macsec_decrypt_done(struct crypto_async_request *base, int err)
aead_request_free(macsec_skb_cb(skb)->req);
rcu_read_lock_bh();
+ if (err == 0)
+ macsec_skb_cb(skb)->valid = true;
+
pn = ntohl(macsec_ethhdr(skb)->packet_number);
if (!macsec_post_decrypt(skb, &macsec->secy, pn)) {
rcu_read_unlock_bh();
--
1.9.1
^ permalink raw reply related
* [PATCH v4 0/3] mmc: mediatek: Use data tune for CMD line tune
From: Yong Mao @ 2017-01-21 8:55 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus Walleij, Chaotian Jing, yong mao, Eddie Huang, Chunfeng Yun,
linux-mmc, srv_heupstream, linux-mediatek, linux-kernel,
linux-arm-kernel
yong mao (3):
mmc: dt-bindings: update Mediatek MMC bindings
ARM64: dts: mediatek: configure some fixed mmc parameters
mmc: mediatek: Use data tune for CMD line tune
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 12 ++
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +
drivers/mmc/host/mtk-sd.c | 168 ++++++++++++++++++++---
3 files changed, 167 insertions(+), 16 deletions(-)
--
1.8.1.1.dirty
^ permalink raw reply
* [PATCH v4 1/3] mmc: dt-bindings: update Mediatek MMC bindings
From: Yong Mao @ 2017-01-21 8:55 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus Walleij, Chaotian Jing, yong mao, Eddie Huang, Chunfeng Yun,
linux-mmc, srv_heupstream, linux-mediatek, linux-kernel,
linux-arm-kernel
In-Reply-To: <1484988923-1543-1-git-send-email-yong.mao@mediatek.com>
From: yong mao <yong.mao@mediatek.com>
Add description for mediatek,hs200-cmd-int-delay
Add description for mediatek,hs400-cmd-int-delay
Add description for mediatek,hs400-cmd-resp-sel-rising
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
---
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 0120c7f..4182ea3 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -21,6 +21,15 @@ Optional properties:
- assigned-clocks: PLL of the source clock
- assigned-clock-parents: parent of source clock, used for HS400 mode to get 400Mhz source clock
- hs400-ds-delay: HS400 DS delay setting
+- mediatek,hs200-cmd-int-delay: HS200 command internal delay setting.
+ This field has total 32 stages.
+ The value is an integer from 0 to 31.
+- mediatek,hs400-cmd-int-delay: HS400 command internal delay setting
+ This field has total 32 stages.
+ The value is an integer from 0 to 31.
+- mediatek,hs400-cmd-resp-sel-rising: HS400 command response sample selection
+ If present,HS400 command responses are sampled on rising edges.
+ If not present,HS400 command responses are sampled on falling edges.
Examples:
mmc0: mmc@11230000 {
@@ -38,4 +47,7 @@ mmc0: mmc@11230000 {
assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
hs400-ds-delay = <0x14015>;
+ mediatek,hs200-cmd-int-delay = <26>;
+ mediatek,hs400-cmd-int-delay = <14>;
+ mediatek,hs400-cmd-resp-sel-rising;
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/3] ARM64: dts: mediatek: configure some fixed mmc parameters
From: Yong Mao @ 2017-01-21 8:55 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus Walleij, Chaotian Jing, yong mao, Eddie Huang, Chunfeng Yun,
linux-mmc, srv_heupstream, linux-mediatek, linux-kernel,
linux-arm-kernel
In-Reply-To: <1484988923-1543-1-git-send-email-yong.mao@mediatek.com>
From: yong mao <yong.mao@mediatek.com>
configure some fixed mmc parameters
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 0ecaad4..1c3634f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -134,6 +134,9 @@
bus-width = <8>;
max-frequency = <50000000>;
cap-mmc-highspeed;
+ mediatek,hs200-cmd-int-delay=<26>;
+ mediatek,hs400-cmd-int-delay=<14>;
+ mediatek,hs400-cmd-resp-sel-rising;
vmmc-supply = <&mt6397_vemc_3v3_reg>;
vqmmc-supply = <&mt6397_vio18_reg>;
non-removable;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 3/3] mmc: mediatek: Use data tune for CMD line tune
From: Yong Mao @ 2017-01-21 8:55 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus Walleij, Chaotian Jing, yong mao, Eddie Huang, Chunfeng Yun,
linux-mmc, srv_heupstream, linux-mediatek, linux-kernel,
linux-arm-kernel
In-Reply-To: <1484988923-1543-1-git-send-email-yong.mao@mediatek.com>
From: yong mao <yong.mao@mediatek.com>
If we don't select a set of better parameters for our emmc host,
It may easily occur CMD response CRC error. And also it may cause
cannot boot up issue.
Fot getting a set of better parameters, our emmc host supports
data tune mechanism.Therefore, our emmc driver also should change
to use data tune for CMD line.
Because our emmc host use the different clock source to sample the
CMD signal between HS200 and HS400 mode, the parameters are also
different between these two modes.
Separate cmd internal delay for HS200/HS400 mode.
This change can fix "System can not boot up" issue.
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
---
drivers/mmc/host/mtk-sd.c | 168 ++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 152 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 80ba034..07f3236 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -75,6 +75,7 @@
#define MSDC_PATCH_BIT1 0xb4
#define MSDC_PAD_TUNE 0xec
#define PAD_DS_TUNE 0x188
+#define PAD_CMD_TUNE 0x18c
#define EMMC50_CFG0 0x208
/*--------------------------------------------------------------------------*/
@@ -210,13 +211,18 @@
#define MSDC_PATCH_BIT_SPCPUSH (0x1 << 29) /* RW */
#define MSDC_PATCH_BIT_DECRCTMO (0x1 << 30) /* RW */
+#define MSDC_PAD_TUNE_DATWRDLY (0x1f << 0) /* RW */
#define MSDC_PAD_TUNE_DATRRDLY (0x1f << 8) /* RW */
#define MSDC_PAD_TUNE_CMDRDLY (0x1f << 16) /* RW */
+#define MSDC_PAD_TUNE_CMDRRDLY (0x1f << 22) /* RW */
+#define MSDC_PAD_TUNE_CLKTDLY (0x1f << 27) /* RW */
#define PAD_DS_TUNE_DLY1 (0x1f << 2) /* RW */
#define PAD_DS_TUNE_DLY2 (0x1f << 7) /* RW */
#define PAD_DS_TUNE_DLY3 (0x1f << 12) /* RW */
+#define PAD_CMD_TUNE_RX_DLY3 (0x1f << 1) /* RW */
+
#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0) /* RW */
#define EMMC50_CFG_CRCSTS_EDGE (0x1 << 3) /* RW */
#define EMMC50_CFG_CFCSTS_SEL (0x1 << 4) /* RW */
@@ -284,12 +290,14 @@ struct msdc_save_para {
u32 patch_bit0;
u32 patch_bit1;
u32 pad_ds_tune;
+ u32 pad_cmd_tune;
u32 emmc50_cfg0;
};
struct msdc_tune_para {
u32 iocon;
u32 pad_tune;
+ u32 pad_cmd_tune;
};
struct msdc_delay_phase {
@@ -331,6 +339,10 @@ struct msdc_host {
unsigned char timing;
bool vqmmc_enabled;
u32 hs400_ds_delay;
+ u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
+ u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
+ bool hs400_cmd_resp_sel_rising;
+ /* cmd response sample selection for HS400 */
bool hs400_mode; /* current eMMC will run at hs400 mode */
struct msdc_save_para save_para; /* used when gate HCLK */
struct msdc_tune_para def_tune_para; /* default tune setting */
@@ -600,8 +612,14 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz)
} else {
writel(host->saved_tune_para.iocon, host->base + MSDC_IOCON);
writel(host->saved_tune_para.pad_tune, host->base + MSDC_PAD_TUNE);
+ writel(host->saved_tune_para.pad_cmd_tune,
+ host->base + PAD_CMD_TUNE);
}
+ if (timing == MMC_TIMING_MMC_HS400)
+ sdr_set_field(host->base + PAD_CMD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs400_cmd_int_delay);
dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
}
@@ -1302,7 +1320,7 @@ static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u32 delay)
len_final = len;
}
start += len ? len : 1;
- if (len >= 8 && start_final < 4)
+ if (len >= 12 && start_final < 4)
break;
}
@@ -1325,36 +1343,67 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
struct msdc_host *host = mmc_priv(mmc);
u32 rise_delay = 0, fall_delay = 0;
struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
+ struct msdc_delay_phase internal_delay_phase;
u8 final_delay, final_maxlen;
+ u32 internal_delay = 0;
int cmd_err;
- int i;
+ int i, j;
+
+ if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
+ mmc->ios.timing == MMC_TIMING_UHS_SDR104)
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs200_cmd_int_delay);
sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
for (i = 0 ; i < PAD_DELAY_MAX; i++) {
sdr_set_field(host->base + MSDC_PAD_TUNE,
MSDC_PAD_TUNE_CMDRDLY, i);
- mmc_send_tuning(mmc, opcode, &cmd_err);
- if (!cmd_err)
- rise_delay |= (1 << i);
+ /*
+ * Using the same parameters, it may sometimes pass the test,
+ * but sometimes it may fail. To make sure the parameters are
+ * more stable, we test each set of parameters 3 times.
+ */
+ for (j = 0; j < 3; j++) {
+ mmc_send_tuning(mmc, opcode, &cmd_err);
+ if (!cmd_err) {
+ rise_delay |= (1 << i);
+ } else {
+ rise_delay &= ~(1 << i);
+ break;
+ }
+ }
}
final_rise_delay = get_best_delay(host, rise_delay);
/* if rising edge has enough margin, then do not scan falling edge */
- if (final_rise_delay.maxlen >= 10 ||
- (final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
+ if (final_rise_delay.maxlen >= 12 && final_rise_delay.start < 4)
goto skip_fall;
sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
for (i = 0; i < PAD_DELAY_MAX; i++) {
sdr_set_field(host->base + MSDC_PAD_TUNE,
MSDC_PAD_TUNE_CMDRDLY, i);
- mmc_send_tuning(mmc, opcode, &cmd_err);
- if (!cmd_err)
- fall_delay |= (1 << i);
+ /*
+ * Using the same parameters, it may sometimes pass the test,
+ * but sometimes it may fail. To make sure the parameters are
+ * more stable, we test each set of parameters 3 times.
+ */
+ for (j = 0; j < 3; j++) {
+ mmc_send_tuning(mmc, opcode, &cmd_err);
+ if (!cmd_err) {
+ fall_delay |= (1 << i);
+ } else {
+ fall_delay &= ~(1 << i);
+ break;
+ }
+ }
}
final_fall_delay = get_best_delay(host, fall_delay);
skip_fall:
final_maxlen = max(final_rise_delay.maxlen, final_fall_delay.maxlen);
+ if (final_fall_delay.maxlen >= 12 && final_fall_delay.start < 4)
+ final_maxlen = final_fall_delay.maxlen;
if (final_maxlen == final_rise_delay.maxlen) {
sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRDLY,
@@ -1366,7 +1415,71 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
final_fall_delay.final_phase);
final_delay = final_fall_delay.final_phase;
}
+ if (host->hs200_cmd_int_delay)
+ goto skip_internal;
+
+ for (i = 0; i < PAD_DELAY_MAX; i++) {
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY, i);
+ mmc_send_tuning(mmc, opcode, &cmd_err);
+ if (!cmd_err)
+ internal_delay |= (1 << i);
+ }
+ dev_dbg(host->dev, "Final internal delay: 0x%x\n", internal_delay);
+ internal_delay_phase = get_best_delay(host, internal_delay);
+ sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRRDLY,
+ internal_delay_phase.final_phase);
+skip_internal:
+ dev_dbg(host->dev, "Final cmd pad delay: %x\n", final_delay);
+ return final_delay == 0xff ? -EIO : 0;
+}
+
+static int hs400_tune_response(struct mmc_host *mmc, u32 opcode)
+{
+ struct msdc_host *host = mmc_priv(mmc);
+ u32 cmd_delay = 0;
+ struct msdc_delay_phase final_cmd_delay = { 0,};
+ u8 final_delay;
+ int cmd_err;
+ int i, j;
+
+ /* select EMMC50 PAD CMD tune */
+ sdr_set_bits(host->base + PAD_CMD_TUNE, BIT(0));
+
+ if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
+ mmc->ios.timing == MMC_TIMING_UHS_SDR104)
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs200_cmd_int_delay);
+
+ if (host->hs400_cmd_resp_sel_rising)
+ sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
+ else
+ sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
+ for (i = 0 ; i < PAD_DELAY_MAX; i++) {
+ sdr_set_field(host->base + PAD_CMD_TUNE,
+ PAD_CMD_TUNE_RX_DLY3, i);
+ /*
+ * Using the same parameters, it may sometimes pass the test,
+ * but sometimes it may fail. To make sure the parameters are
+ * more stable, we test each set of parameters 3 times.
+ */
+ for (j = 0; j < 3; j++) {
+ mmc_send_tuning(mmc, opcode, &cmd_err);
+ if (!cmd_err) {
+ cmd_delay |= (1 << i);
+ } else {
+ cmd_delay &= ~(1 << i);
+ break;
+ }
+ }
+ }
+ final_cmd_delay = get_best_delay(host, cmd_delay);
+ sdr_set_field(host->base + PAD_CMD_TUNE, PAD_CMD_TUNE_RX_DLY3,
+ final_cmd_delay.final_phase);
+ final_delay = final_cmd_delay.final_phase;
+ dev_dbg(host->dev, "Final cmd pad delay: %x\n", final_delay);
return final_delay == 0xff ? -EIO : 0;
}
@@ -1389,7 +1502,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
}
final_rise_delay = get_best_delay(host, rise_delay);
/* if rising edge has enough margin, then do not scan falling edge */
- if (final_rise_delay.maxlen >= 10 ||
+ if (final_rise_delay.maxlen >= 12 ||
(final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
goto skip_fall;
@@ -1422,6 +1535,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
final_delay = final_fall_delay.final_phase;
}
+ dev_dbg(host->dev, "Final data pad delay: %x\n", final_delay);
return final_delay == 0xff ? -EIO : 0;
}
@@ -1430,7 +1544,10 @@ static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
struct msdc_host *host = mmc_priv(mmc);
int ret;
- ret = msdc_tune_response(mmc, opcode);
+ if (host->hs400_mode)
+ ret = hs400_tune_response(mmc, opcode);
+ else
+ ret = msdc_tune_response(mmc, opcode);
if (ret == -EIO) {
dev_err(host->dev, "Tune response fail!\n");
return ret;
@@ -1443,6 +1560,7 @@ static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
host->saved_tune_para.iocon = readl(host->base + MSDC_IOCON);
host->saved_tune_para.pad_tune = readl(host->base + MSDC_PAD_TUNE);
+ host->saved_tune_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
return ret;
}
@@ -1477,6 +1595,25 @@ static void msdc_hw_reset(struct mmc_host *mmc)
.hw_reset = msdc_hw_reset,
};
+static void msdc_of_property_parse(struct platform_device *pdev,
+ struct msdc_host *host)
+{
+ of_property_read_u32(pdev->dev.of_node, "hs400-ds-delay",
+ &host->hs400_ds_delay);
+
+ of_property_read_u32(pdev->dev.of_node, "mediatek,hs200-cmd-int-delay",
+ &host->hs200_cmd_int_delay);
+
+ of_property_read_u32(pdev->dev.of_node, "mediatek,hs400-cmd-int-delay",
+ &host->hs400_cmd_int_delay);
+
+ if (of_property_read_bool(pdev->dev.of_node,
+ "mediatek,hs400-cmd-resp-sel-rising"))
+ host->hs400_cmd_resp_sel_rising = true;
+ else
+ host->hs400_cmd_resp_sel_rising = false;
+}
+
static int msdc_drv_probe(struct platform_device *pdev)
{
struct mmc_host *mmc;
@@ -1548,10 +1685,7 @@ static int msdc_drv_probe(struct platform_device *pdev)
goto host_free;
}
- if (!of_property_read_u32(pdev->dev.of_node, "hs400-ds-delay",
- &host->hs400_ds_delay))
- dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
- host->hs400_ds_delay);
+ msdc_of_property_parse(pdev, host);
host->dev = &pdev->dev;
host->mmc = mmc;
@@ -1663,6 +1797,7 @@ static void msdc_save_reg(struct msdc_host *host)
host->save_para.patch_bit0 = readl(host->base + MSDC_PATCH_BIT);
host->save_para.patch_bit1 = readl(host->base + MSDC_PATCH_BIT1);
host->save_para.pad_ds_tune = readl(host->base + PAD_DS_TUNE);
+ host->save_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
host->save_para.emmc50_cfg0 = readl(host->base + EMMC50_CFG0);
}
@@ -1675,6 +1810,7 @@ static void msdc_restore_reg(struct msdc_host *host)
writel(host->save_para.patch_bit0, host->base + MSDC_PATCH_BIT);
writel(host->save_para.patch_bit1, host->base + MSDC_PATCH_BIT1);
writel(host->save_para.pad_ds_tune, host->base + PAD_DS_TUNE);
+ writel(host->save_para.pad_cmd_tune, host->base + PAD_CMD_TUNE);
writel(host->save_para.emmc50_cfg0, host->base + EMMC50_CFG0);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] media: platform: constify vb2_ops structures
From: Bhumika Goyal @ 2017-01-21 9:29 UTC (permalink / raw)
To: julia.lawall, prabhakar.csengg, mchehab, minghsiu.tsai,
houlong.wei, andrew-ct.chen, matthias.bgg, linux-media,
linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Bhumika Goyal
Declare vb2_ops structures as const as they are only stored in
the ops field of a vb2_queue structure. This field is of type
const, so vb2_ops structures having same properties can be made
const too.
Done using Coccinelle:
@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct vb2_ops i@p={...};
@ok1@
identifier r1.i;
position p;
struct sta2x11_vip vip;
struct vb2_queue q;
@@
(
vip.vb_vidq.ops=&i@p
|
q.ops=&i@p
)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct vb2_ops i;
Cross compiled the media/platform/blackfin/bfin_capture.o file for
blackfin architecture.
File size before:
text data bss dec hex filename
6776 176 0 6952 1b28 platform/blackfin/bfin_capture.o
File size after:
text data bss dec hex filename
6816 136 0 6952 1b28 platform/blackfin/bfin_capture.o
File size before:
text data bss dec hex filename
12852 456 272 13580 350c platform/davinci/vpif_capture.o
File size after:
text data bss dec hex filename
12932 360 272 13564 34fc platform/davinci/vpif_capture.o
File size before:
text data bss dec hex filename
12285 360 276 12921 3279 platform/davinci/vpif_display.o
File size after:
text data bss dec hex filename
12365 296 276 12937 3289 platform/davinci/vpif_display.o
File size details before and after applying the patch remains the same for
drivers/media/platform/pxa_camera.o
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/media/platform/davinci/vpif_capture.c | 2 +-
drivers/media/platform/davinci/vpif_display.c | 2 +-
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 2 +-
drivers/media/platform/pxa_camera.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index f791f5c..54c54d9 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -309,7 +309,7 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
spin_unlock_irqrestore(&common->irqlock, flags);
}
-static struct vb2_ops video_qops = {
+static const struct vb2_ops video_qops = {
.queue_setup = vpif_buffer_queue_setup,
.buf_prepare = vpif_buffer_prepare,
.start_streaming = vpif_start_streaming,
diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c
index e5f1844..9604afd 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -289,7 +289,7 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
spin_unlock_irqrestore(&common->irqlock, flags);
}
-static struct vb2_ops video_qops = {
+static const struct vb2_ops video_qops = {
.queue_setup = vpif_buffer_queue_setup,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 13afe48..3038d62 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -621,7 +621,7 @@ static void mtk_mdp_m2m_buf_queue(struct vb2_buffer *vb)
v4l2_m2m_buf_queue(ctx->m2m_ctx, to_vb2_v4l2_buffer(vb));
}
-static struct vb2_ops mtk_mdp_m2m_qops = {
+static const struct vb2_ops mtk_mdp_m2m_qops = {
.queue_setup = mtk_mdp_m2m_queue_setup,
.buf_prepare = mtk_mdp_m2m_buf_prepare,
.buf_queue = mtk_mdp_m2m_buf_queue,
diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c
index 929006f..17167d1 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -1530,7 +1530,7 @@ static void pxac_vb2_stop_streaming(struct vb2_queue *vq)
pxa_camera_wakeup(pcdev, buf, VB2_BUF_STATE_ERROR);
}
-static struct vb2_ops pxac_vb2_ops = {
+static const struct vb2_ops pxac_vb2_ops = {
.queue_setup = pxac_vb2_queue_setup,
.buf_init = pxac_vb2_init,
.buf_prepare = pxac_vb2_prepare,
--
1.9.1
^ permalink raw reply related
* Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform
From: Rob Herring @ 2017-01-21 20:08 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Kishon Vijay Abraham I, Matthias Brugger, Felipe Balbi,
Mark Rutland, Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484719214-11989-6-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote:
> add a new compatible string for "mt2712", and a new reference clock
> for SuperSpeed analog phy;
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 81 +++++++++++++++++---
> 1 file changed, 70 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> index 33a2b1e..8f91136 100644
> --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> @@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> Required properties (controller (parent) node):
> - compatible : should be one of
> "mediatek,mt2701-u3phy"
> + "mediatek,mt2712-u3phy"
> "mediatek,mt8173-u3phy"
> - - reg : offset and length of register for phy, exclude port's
> - register.
> - clocks : a list of phandle + clock-specifier pairs, one for each
> entry in clock-names
> - clock-names : must contain
> - "u3phya_ref": for reference clock of usb3.0 analog phy.
> + "u2ref_clk": 48M reference clock of HighSpeed analog phy.
> + "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
> + sometimes is 24M, 25M or 27M, depended on platform.
_clk is redundant.
>
> Required nodes : a sub-node is required for each port the controller
> provides. Address range information including the usual
> 'reg' property is used inside these nodes to describe
> the controller's topology.
>
> +Optional properties (controller (parent) node):
> + - reg : offset and length of register shared by multiple ports,
> + exclude port's private register. It is needed on mt2701
> + and mt8173, but not on mt2712.
> +
> Required properties (port (child) node):
> - reg : address and length of the register set for the port.
> - #phy-cells : should be 1 (See second example)
> @@ -31,21 +37,27 @@ Example:
> u3phy: usb-phy@11290000 {
> compatible = "mediatek,mt8173-u3phy";
> reg = <0 0x11290000 0 0x800>;
> - clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
> - clock-names = "u3phya_ref";
> + clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>, <&clk26m>;
> + clock-names = "u2ref_clk", "u3ref_clk";
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> status = "okay";
>
> - phy_port0: port@11290800 {
> - reg = <0 0x11290800 0 0x800>;
> + u2port0: port@11290800 {
port is for OF graph. This should be usb-phy@... instead.
> + reg = <0 0x11290800 0 0x100>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + u3port0: port@11290900 {
> + reg = <0 0x11290800 0 0x700>;
> #phy-cells = <1>;
> status = "okay";
> };
>
> - phy_port1: port@11291000 {
> - reg = <0 0x11291000 0 0x800>;
> + u2port1: port@11291000 {
> + reg = <0 0x11291000 0 0x100>;
> #phy-cells = <1>;
> status = "okay";
> };
> @@ -64,7 +76,54 @@ Example:
>
> usb30: usb@11270000 {
> ...
> - phys = <&phy_port0 PHY_TYPE_USB3>;
> - phy-names = "usb3-0";
> + phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
> + phy-names = "usb2-0", "usb3-0";
> ...
> };
> +
> +
> +Layout differences of banks between mt8173/mt2701 and mt2712
> +-------------------------------------------------------------
> +mt8173 and mt2701:
> +port offset bank
> +shared 0x0000 SPLLC
> + 0x0100 FMREG
> +u2 port0 0x0800 U2PHY_COM
> +u3 port0 0x0900 U3PHYD
> + 0x0a00 U3PHYD_BANK2
> + 0x0b00 U3PHYA
> + 0x0c00 U3PHYA_DA
> +u2 port1 0x1000 U2PHY_COM
> +u3 port1 0x1100 U3PHYD
> + 0x1200 U3PHYD_BANK2
> + 0x1300 U3PHYA
> + 0x1400 U3PHYA_DA
> +u2 port2 0x1800 U2PHY_COM
> + ...
> +
> +mt2712:
> +port offset bank
> +u2 port0 0x0000 MISC
> + 0x0100 FMREG
> + 0x0300 U2PHY_COM
> +u3 port0 0x0700 SPLLC
> + 0x0800 CHIP
> + 0x0900 U3PHYD
> + 0x0a00 U3PHYD_BANK2
> + 0x0b00 U3PHYA
> + 0x0c00 U3PHYA_DA
> +u2 port1 0x1000 MISC
> + 0x1100 FMREG
> + 0x1300 U2PHY_COM
> +u3 port1 0x1700 SPLLC
> + 0x1800 CHIP
> + 0x1900 U3PHYD
> + 0x1a00 U3PHYD_BANK2
> + 0x1b00 U3PHYA
> + 0x1c00 U3PHYA_DA
> +u2 port2 0x2000 MISC
> + ...
> +
> + SPLLC shared by u3 ports and FMREG shared by u2 ports on
> +mt8173/mt2701 are put back into each port; a new bank MISC for
> +u2 ports and CHIP for u3 ports are added on mt2712.
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: mt8173-xhci: add reference clock
From: Rob Herring @ 2017-01-21 20:10 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman, Matthias Brugger,
Mark Rutland, Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484719707-12107-5-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Wed, Jan 18, 2017 at 02:08:26PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/usb/mt8173-xhci.txt | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock
From: Rob Herring @ 2017-01-21 20:11 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Mathias Nyman, Felipe Balbi,
Ian Campbell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1484719707-12107-6-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jan 18, 2017 at 02:08:27PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility
Why? This block suddenly has 2 clocks instead of 1?
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> .../devicetree/bindings/usb/mt8173-mtu3.txt | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> index e049d19..8c976cd 100644
> --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> +++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> @@ -10,7 +10,7 @@ Required properties:
> - vusb33-supply : regulator of USB avdd3.3v
> - clocks : a list of phandle + clock-specifier pairs, one for each
> entry in clock-names
> - - clock-names : must contain "sys_ck" for clock of controller;
> + - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
> "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
> depends on "mediatek,enable-wakeup"
> - phys : a list of phandle + phy specifier pairs
> @@ -56,10 +56,10 @@ ssusb: usb@11271000 {
> phys = <&phy_port0 PHY_TYPE_USB3>,
> <&phy_port1 PHY_TYPE_USB2>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> - clocks = <&topckgen CLK_TOP_USB30_SEL>,
> + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>,
> <&pericfg CLK_PERI_USB0>,
> <&pericfg CLK_PERI_USB1>;
> - clock-names = "sys_ck",
> + clock-names = "sys_ck", "ref_ck",
> "wakeup_deb_p0",
> "wakeup_deb_p1";
> vusb33-supply = <&mt6397_vusb_reg>;
> @@ -79,8 +79,8 @@ ssusb: usb@11271000 {
> reg-names = "mac";
> interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_LOW>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> - clocks = <&topckgen CLK_TOP_USB30_SEL>;
> - clock-names = "sys_ck";
> + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>;
> + clock-names = "sys_ck", "ref_ck";
> vusb33-supply = <&mt6397_vusb_reg>;
> status = "disabled";
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: mt8173-xhci: add reference clock
From: Rob Herring @ 2017-01-21 20:12 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman, Matthias Brugger,
Mark Rutland, Ian Campbell, linux-kernel, linux-arm-kernel,
linux-usb, linux-mediatek, devicetree
In-Reply-To: <1484719707-12107-5-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jan 18, 2017 at 02:08:26PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility
Same question here, too.
^ permalink raw reply
* Re: [RESEND PATCH 1/2] Documentation: devicetree: Add i2c binding for mediatek MT2701 Soc Platform
From: Rob Herring @ 2017-01-21 20:22 UTC (permalink / raw)
To: Jun Gao
Cc: devicetree, srv_heupstream, Wolfram Sang, linux-kernel,
linux-mediatek, linux-i2c, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1484732461-13594-2-git-send-email-jun.gao@mediatek.com>
On Wed, Jan 18, 2017 at 05:41:00PM +0800, Jun Gao wrote:
> From: Jun Gao <jun.gao@mediatek.com>
>
> This add i2c DT binding to i2c-mt6577.txt for MT2701.
>
> Signed-off-by: Jun Gao <jun.gao@mediatek.com>
> ---
> .../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock
From: Chunfeng Yun @ 2017-01-22 1:49 UTC (permalink / raw)
To: Rob Herring
Cc: Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman, Matthias Brugger,
Mark Rutland, Ian Campbell, linux-kernel, linux-arm-kernel,
linux-usb, linux-mediatek, devicetree
In-Reply-To: <20170121201155.cqcihopdc3kjyfi6@rob-hp-laptop>
Hi,
On Sat, 2017-01-21 at 14:11 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 02:08:27PM +0800, Chunfeng Yun wrote:
> > add a reference clock for compatibility
>
> Why? This block suddenly has 2 clocks instead of 1?
In fact, there is a reference clock which comes from 26M oscillator
directly. I ignore it because it is a fixed-clock in DTS, and always
turned on for mt8173. But later, I find that I made a mistake before
when I bring up it on a new platform whose reference clock comes from
PLL, and need control it. So here add it, no matter it is a fixed-clock
or not.
>
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > .../devicetree/bindings/usb/mt8173-mtu3.txt | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > index e049d19..8c976cd 100644
> > --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > @@ -10,7 +10,7 @@ Required properties:
> > - vusb33-supply : regulator of USB avdd3.3v
> > - clocks : a list of phandle + clock-specifier pairs, one for each
> > entry in clock-names
> > - - clock-names : must contain "sys_ck" for clock of controller;
> > + - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
> > "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
> > depends on "mediatek,enable-wakeup"
> > - phys : a list of phandle + phy specifier pairs
> > @@ -56,10 +56,10 @@ ssusb: usb@11271000 {
> > phys = <&phy_port0 PHY_TYPE_USB3>,
> > <&phy_port1 PHY_TYPE_USB2>;
> > power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> > - clocks = <&topckgen CLK_TOP_USB30_SEL>,
> > + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>,
> > <&pericfg CLK_PERI_USB0>,
> > <&pericfg CLK_PERI_USB1>;
> > - clock-names = "sys_ck",
> > + clock-names = "sys_ck", "ref_ck",
> > "wakeup_deb_p0",
> > "wakeup_deb_p1";
> > vusb33-supply = <&mt6397_vusb_reg>;
> > @@ -79,8 +79,8 @@ ssusb: usb@11271000 {
> > reg-names = "mac";
> > interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_LOW>;
> > power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> > - clocks = <&topckgen CLK_TOP_USB30_SEL>;
> > - clock-names = "sys_ck";
> > + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>;
> > + clock-names = "sys_ck", "ref_ck";
> > vusb33-supply = <&mt6397_vusb_reg>;
> > status = "disabled";
> > };
> > --
> > 1.7.9.5
> >
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: mt8173-xhci: add reference clock
From: Chunfeng Yun @ 2017-01-22 1:53 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Mathias Nyman, Felipe Balbi,
Ian Campbell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20170121201250.dpowjr3mlwuew3gx@rob-hp-laptop>
On Sat, 2017-01-21 at 14:12 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 02:08:26PM +0800, Chunfeng Yun wrote:
> > add a reference clock for compatibility
>
> Same question here, too.
The reason is the same as mt8173-mtu3
thanks a lot
>
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Guochun Mao @ 2017-01-22 2:36 UTC (permalink / raw)
To: Rob Herring, Boris Brezillon, Thomas Petazzoni, Marek Vasut,
Matthias Brugger
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Richard Weinberger, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Cyrille Pitchen,
Brian Norris, David Woodhouse
In-Reply-To: <CAL_Jsq+S-FYy4SmjJ3fWzBugw2zCj5TQkkfUA8QVL7SLJW3E1g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Thu, 2017-01-19 at 08:18 -0600, Rob Herring wrote:
> On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon
> > One last question and I'm done: is something like that acceptable?
> >
> > compatible = "<vendor>,<old-soc>","<vendor>,<new-soc>";
> >
> > This can happen when someone adds support for an unsupported feature
> > on a brand new SoC, and then someone else use the same driver for an
> > older SoC embedding the same IP but still wants to add a new compatible
> > just in case these 2 IPs appear to be slightly different.
>
> Yes, it's old and new compatible strings in this case and it's newest
> compatible string first.
>
> > Here the order of compat strings is no longer following a clear rule
> > like 'most-specific compatible first' or 'newest IP/SoC version first',
> > it's completely dependent on the order these IPs were supported in the
> > OS (Linux). I'm perfectly fine with that BTW, just want to make sure
> > this is authorized.
>
> I guess we should say "newest compatible for IP first" instead. There
> are some exceptions where we add fallbacks later on, but that falls
> under the most-specific part.
>
> It's order that the bindings are defined, not Linux support really,
> but in practice those are the same.
>
> Rob
Thanks for all your effort for code reviewing.
Our mt2701-nor's hardware is designed base on mt8713-nor,
even so, there would be some slight difference.
If I don't misunderstand your viewpoint in this discussion,
there's no need to drop mt2701-nor compatible.
And if not, is there any other suggestion?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform
From: Chunfeng Yun @ 2017-01-22 2:50 UTC (permalink / raw)
To: Rob Herring
Cc: Kishon Vijay Abraham I, Matthias Brugger, Felipe Balbi,
Mark Rutland, Ian Campbell, linux-kernel, linux-arm-kernel,
linux-usb, linux-mediatek, devicetree
In-Reply-To: <20170121200844.k5ivauhws43ac2s2@rob-hp-laptop>
On Sat, 2017-01-21 at 14:08 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote:
> > add a new compatible string for "mt2712", and a new reference clock
> > for SuperSpeed analog phy;
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 81 +++++++++++++++++---
> > 1 file changed, 70 insertions(+), 11 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > index 33a2b1e..8f91136 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > @@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> > Required properties (controller (parent) node):
> > - compatible : should be one of
> > "mediatek,mt2701-u3phy"
> > + "mediatek,mt2712-u3phy"
> > "mediatek,mt8173-u3phy"
> > - - reg : offset and length of register for phy, exclude port's
> > - register.
> > - clocks : a list of phandle + clock-specifier pairs, one for each
> > entry in clock-names
> > - clock-names : must contain
> > - "u3phya_ref": for reference clock of usb3.0 analog phy.
> > + "u2ref_clk": 48M reference clock of HighSpeed analog phy.
> > + "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
> > + sometimes is 24M, 25M or 27M, depended on platform.
>
> _clk is redundant.
remove it
>
> >
> > Required nodes : a sub-node is required for each port the controller
> > provides. Address range information including the usual
> > 'reg' property is used inside these nodes to describe
> > the controller's topology.
> >
> > +Optional properties (controller (parent) node):
> > + - reg : offset and length of register shared by multiple ports,
> > + exclude port's private register. It is needed on mt2701
> > + and mt8173, but not on mt2712.
> > +
> > Required properties (port (child) node):
> > - reg : address and length of the register set for the port.
> > - #phy-cells : should be 1 (See second example)
> > @@ -31,21 +37,27 @@ Example:
> > u3phy: usb-phy@11290000 {
> > compatible = "mediatek,mt8173-u3phy";
> > reg = <0 0x11290000 0 0x800>;
> > - clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
> > - clock-names = "u3phya_ref";
> > + clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>, <&clk26m>;
> > + clock-names = "u2ref_clk", "u3ref_clk";
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > status = "okay";
> >
> > - phy_port0: port@11290800 {
> > - reg = <0 0x11290800 0 0x800>;
> > + u2port0: port@11290800 {
>
> port is for OF graph. This should be usb-phy@... instead.
Is there any problems if u2port0's name@addr is the same as its parent's
(u3phy)? as following:
u3phy: usb-phy@11290000 {
compatible = ...;
// no reg property
clocks = ...;
u2port0: usb-phy@11290000 {
reg = ...;
}
>
> > + reg = <0 0x11290800 0 0x100>;
> > + #phy-cells = <1>;
> > + status = "okay";
> > + };
> > +
> > + u3port0: port@11290900 {
> > + reg = <0 0x11290800 0 0x700>;
> > #phy-cells = <1>;
> > status = "okay";
> > };
> >
> > + ...
Thank you!
^ permalink raw reply
* Re: [PATCH v3 3/3] media: rc: add driver for IR remote receiver on MT7623 SoC
From: kbuild test robot @ 2017-01-22 5:20 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, mchehab-JPH+aEBZ4P+UEJcrhfAQsw,
hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sean-hENCXIMQXOg,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, Sean Wang
In-Reply-To: <1484292939-9454-4-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]
Hi Sean,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.10-rc4 next-20170120]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/Documentation-devicetree-move-shared-property-used-by-rc-into-a-common-place/20170115-052257
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
>> drivers/media/rc/mtk-cir.c:220:11: error: too many arguments to function 'devm_rc_allocate_device'
ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/media/rc/mtk-cir.c:22:0:
include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
^~~~~~~~~~~~~~~~~~~~~~~
vim +/devm_rc_allocate_device +220 drivers/media/rc/mtk-cir.c
214 ir->base = devm_ioremap_resource(dev, res);
215 if (IS_ERR(ir->base)) {
216 dev_err(dev, "failed to map registers\n");
217 return PTR_ERR(ir->base);
218 }
219
> 220 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
221 if (!ir->rc) {
222 dev_err(dev, "failed to allocate device\n");
223 return -ENOMEM;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 48879 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH net] macsec: fix validation failed in asynchronous operation.
From: David Miller @ 2017-01-22 21:44 UTC (permalink / raw)
To: ryder.lee-NuS5LvNUpcJWk0Htik3J/w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sd-y1jBWg8GRStKuXlAQpz2QA
In-Reply-To: <1484988127-25860-1-git-send-email-ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Why are you resending this?
The original posting on Jan 20th made it to the mailing list and is queued
up in patchwork just fine.
Also, regardless of the reason, a "RESEND" patch should always contain an
explanation of why it needs to be resent. So that the maintainer doesn't
need to ask questions like I am right now.
^ permalink raw reply
* Re: [RESEND PATCH net] macsec: fix validation failed in asynchronous operation.
From: Ryder Lee @ 2017-01-23 1:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sd, linux-mediatek
In-Reply-To: <20170122.164450.1158725072101098502.davem@davemloft.net>
Sorry for forgetting to explain it.
The original patch was incomplete, but I sent it out by mistake...
So please ignore it.
On Sun, 2017-01-22 at 16:44 -0500, David Miller wrote:
> Why are you resending this?
>
> The original posting on Jan 20th made it to the mailing list and is queued
> up in patchwork just fine.
>
> Also, regardless of the reason, a "RESEND" patch should always contain an
> explanation of why it needs to be resent. So that the maintainer doesn't
> need to ask questions like I am right now.
^ permalink raw reply
* [PATCH 0/4] leds: add leds-mt6323 support on MT7623 SoC
From: sean.wang @ 2017-01-23 3:54 UTC (permalink / raw)
To: rpurdie, jacek.anaszewski, lee.jones, matthias.bgg, pavel,
robh+dt, mark.rutland
Cc: devicetree, linux-leds, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede, Sean Wang
From: Sean Wang <sean.wang@mediatek.com>
MT7623 SoC uses MT6323 PMIC as the default power supply
which has LED function insides. The patchset introduces
the LED support for MT6323 with on, off and hardware
dimmed and blinked and it should work on other similar
SoCs if also using MT6323.
Sean Wang (4):
Documentation: devicetree: Add document bindings for leds-mt6323
Documentation: devicetree: Add LED subnode binding for MT6323 PMIC
leds: Add LED support for MT6323 PMIC
mfd: mt6397: Add MT6323 LED support into MT6397 driver
.../devicetree/bindings/leds/leds-mt6323.txt | 60 ++++
Documentation/devicetree/bindings/mfd/mt6397.txt | 4 +
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 3 +
drivers/leds/leds-mt6323.c | 390 +++++++++++++++++++++
drivers/mfd/mt6397-core.c | 4 +
6 files changed, 469 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-mt6323.txt
create mode 100644 drivers/leds/leds-mt6323.c
--
1.9.1
^ permalink raw reply
* [PATCH 1/4] Documentation: devicetree: Add document bindings for leds-mt6323
From: sean.wang @ 2017-01-23 3:54 UTC (permalink / raw)
To: rpurdie, jacek.anaszewski, lee.jones, matthias.bgg, pavel,
robh+dt, mark.rutland
Cc: devicetree, linux-leds, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1485143685-11808-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds documentation for devicetree bindings
for LED support on MT6323 PMIC
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
.../devicetree/bindings/leds/leds-mt6323.txt | 60 ++++++++++++++++++++++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-mt6323.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-mt6323.txt b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
new file mode 100644
index 0000000..82bbf0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
@@ -0,0 +1,60 @@
+Device Tree Bindings for LED support on MT6323 PMIC
+
+MT6323 LED controller is subfunction provided by
+MT6323 PMIC, so the LED controller are defined as
+the subnode of the function node provided by MT6323
+PMIC controller that is being defined as one kind of
+Muti-Function Device (MFD) using shared bus called
+PMIC wrapper for each subfunction to access remote
+MT6323 PMIC hardware.
+
+For MT6323 MFD bindings see:
+Documentation/devicetree/bindings/mfd/mt6397.txt
+For MediaTek PMIC wrapper bindings see:
+Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+
+There's sub-node for the LED controller that describes
+the initial behavior for each LED physcially and currently
+only four LED sub-nodes could be supported.
+
+Required properties:
+- compatible : must be "mediatek,mt6323-led"
+
+Optional properties:
+- label : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- default-state: (optional) The initial state of the LED
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+&pwrap {
+ pmic: mt6323 {
+ compatible = "mediatek,mt6323";
+ interrupt-parent = <&pio>;
+ interrupts = <150 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ mt6323led: mt6323led{
+ compatible = "mediatek,mt6323-led";
+
+ led0: isink0 {
+ lebel = "LED0"
+ linux,default-trigger = "timer";
+ default-state = "on";
+ };
+ led1: isink1 {
+ label = "LED1";
+ default-state = "on";
+ };
+ led2: isink2 {
+ label = "LED2";
+ linux,default-trigger = "timer";
+ default-state = "off";
+ };
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] Documentation: devicetree: Add LED subnode binding for MT6323 PMIC
From: sean.wang @ 2017-01-23 3:54 UTC (permalink / raw)
To: rpurdie, jacek.anaszewski, lee.jones, matthias.bgg, pavel,
robh+dt, mark.rutland
Cc: devicetree, linux-leds, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1485143685-11808-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds documentation for devicetree bindings
for LED support as the subnode of MT6323 PMIC
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
Documentation/devicetree/bindings/mfd/mt6397.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
index 949c85f..c568d52 100644
--- a/Documentation/devicetree/bindings/mfd/mt6397.txt
+++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -34,6 +34,10 @@ Optional subnodes:
- clk
Required properties:
- compatible: "mediatek,mt6397-clk"
+- led
+ Required properties:
+ - compatible: "mediatek,mt6323-led"
+ see Documentation/devicetree/bindings/leds/leds-mt6323.txt
Example:
pwrap: pwrap@1000f000 {
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] leds: Add LED support for MT6323 PMIC
From: sean.wang @ 2017-01-23 3:54 UTC (permalink / raw)
To: rpurdie, jacek.anaszewski, lee.jones, matthias.bgg, pavel,
robh+dt, mark.rutland
Cc: devicetree, linux-leds, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1485143685-11808-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
MT6323 PMIC is a multi-function device that includes
LED function. It allows attaching upto 4 LEDs which can
either be on, off or dimmed and/or blinked with the the
controller.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-mt6323.c | 391 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 400 insertions(+)
create mode 100644 drivers/leds/leds-mt6323.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index c621cbb..30095fc 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -117,6 +117,14 @@ config LEDS_MIKROTIK_RB532
This option enables support for the so called "User LED" of
Mikrotik's Routerboard 532.
+config LEDS_MT6323
+ tristate "LED Support for Mediatek MT6323 PMIC"
+ depends on LEDS_CLASS
+ depends on MFD_MT6397
+ help
+ This option enables support for on-chip LED drivers found on
+ Mediatek MT6323 PMIC.
+
config LEDS_S3C24XX
tristate "LED Support for Samsung S3C24XX GPIO LEDs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 6b82737..4feb332 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_LEDS_IS31FL32XX) += leds-is31fl32xx.o
obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
obj-$(CONFIG_LEDS_MLXCPLD) += leds-mlxcpld.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
+obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-mt6323.c b/drivers/leds/leds-mt6323.c
new file mode 100644
index 0000000..de3006d
--- /dev/null
+++ b/drivers/leds/leds-mt6323.c
@@ -0,0 +1,391 @@
+/*
+ * LED driver for Mediatek MT6323 PMIC
+ *
+ * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/leds.h>
+#include <linux/regmap.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6323/registers.h>
+#include <linux/module.h>
+
+/* Register to enable 32K clock common for LED device */
+#define MTK_MT6323_TOP_CKPDN0 0x0102
+#define RG_DRV_32K_CK_PDN BIT(11)
+#define RG_DRV_32K_CK_PDN_MASK BIT(11)
+
+/* Register to enable individual clock for LED device */
+#define MTK_MT6323_TOP_CKPDN2 0x010E
+#define RG_ISINK_CK_PDN(i) BIT(i)
+#define RG_ISINK_CK_PDN_MASK(i) BIT(i)
+
+/* Register to select clock source */
+#define MTK_MT6323_TOP_CKCON1 0x0126
+#define RG_ISINK_CK_SEL_MASK(i) (BIT(10) << (i))
+
+/* Register to setup the duty cycle of the blink */
+#define MTK_MT6323_ISINK_CON0(i) (0x0330 + 0x8 * (i))
+#define ISINK_DIM_DUTY(i) (((i) << 8) & GENMASK(12, 8))
+#define ISINK_DIM_DUTY_MASK GENMASK(12, 8)
+
+/* Register to setup the period of the blink */
+#define MTK_MT6323_ISINK_CON1(i) (0x0332 + 0x8 * (i))
+#define ISINK_DIM_FSEL(i) ((i) & GENMASK(15, 0))
+#define ISINK_DIM_FSEL_MASK GENMASK(15, 0)
+
+/* Register to control the brightness */
+#define MTK_MT6323_ISINK_CON2(i) (0x0334 + 0x8 * (i))
+#define ISINK_CH_STEP(i) (((i) << 12) & GENMASK(14, 12))
+#define ISINK_CH_STEP_MASK GENMASK(14, 12)
+#define ISINK_SFSTR0_TC(i) (((i) << 1) & GENMASK(2, 1))
+#define ISINK_SFSTR0_TC_MASK GENMASK(2, 1)
+#define ISINK_SFSTR0_EN BIT(0)
+#define ISINK_SFSTR0_EN_MASK BIT(0)
+
+/* Register to LED channel enablement */
+#define MTK_MT6323_ISINK_EN_CTRL 0x0356
+#define ISINK_CH_EN(i) BIT(i)
+#define ISINK_CH_EN_MASK(i) BIT(i)
+
+#define MTK_MAX_PERIOD 10000
+#define MTK_MAX_DEVICES 4
+#define MTK_MAX_BRIGHTNESS 6
+
+struct mtk_led;
+struct mtk_leds;
+
+/**
+ * struct mtk_led - state container for the LED device
+ * @id: the identifier in MT6323 LED device
+ * @parent: the pointer to MT6323 LED controller
+ * @cdev: LED class device for this LED device
+ * @current_brightness: current state of the LED device
+ */
+struct mtk_led {
+ int id;
+ struct mtk_leds *parent;
+ struct led_classdev cdev;
+ u8 current_brightness;
+};
+
+/* struct mtk_leds - state container for holding LED controller
+ * of the driver
+ * @dev: The device pointer
+ * @hw: The underlying hardware providing shared
+ bus for the register operations
+ * @led_num: How much the LED device the controller could control
+ * @lock: The lock among process context
+ * @led: The array that contains the state of individual
+ LED device
+ */
+struct mtk_leds {
+ struct device *dev;
+ struct mt6397_chip *hw;
+ u8 led_num;
+ /* protect among process context */
+ struct mutex lock;
+ struct mtk_led led[4];
+};
+
+static void mtk_led_hw_off(struct led_classdev *cdev)
+{
+ struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
+ struct mtk_leds *leds = led->parent;
+ struct regmap *regmap = leds->hw->regmap;
+ unsigned int status;
+
+ status = ISINK_CH_EN(led->id);
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_EN_CTRL,
+ ISINK_CH_EN_MASK(led->id), ~status);
+
+ usleep_range(100, 300);
+ regmap_update_bits(regmap, MTK_MT6323_TOP_CKPDN2,
+ RG_ISINK_CK_PDN_MASK(led->id),
+ RG_ISINK_CK_PDN(led->id));
+
+ dev_dbg(leds->dev, "%s called for led%d\n",
+ __func__, led->id);
+}
+
+static u8 get_mtk_led_hw_brightness(struct led_classdev *cdev)
+{
+ struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
+ struct mtk_leds *leds = led->parent;
+ struct regmap *regmap = leds->hw->regmap;
+ unsigned int status;
+
+ regmap_read(regmap, MTK_MT6323_TOP_CKPDN2, &status);
+ if (status & RG_ISINK_CK_PDN_MASK(led->id))
+ return 0;
+
+ regmap_read(regmap, MTK_MT6323_ISINK_EN_CTRL, &status);
+ if (!(status & ISINK_CH_EN(led->id)))
+ return 0;
+
+ regmap_read(regmap, MTK_MT6323_ISINK_CON2(led->id), &status);
+ return ((status & ISINK_CH_STEP_MASK) >> 12) + 1;
+}
+
+static void mtk_led_hw_on(struct led_classdev *cdev)
+{
+ struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
+ struct mtk_leds *leds = led->parent;
+ struct regmap *regmap = leds->hw->regmap;
+ unsigned int status;
+
+ /* Setup required clock source, enable the corresponding
+ * clock and channel and let work with continuous blink as
+ * the default
+ */
+ regmap_update_bits(regmap, MTK_MT6323_TOP_CKCON1,
+ RG_ISINK_CK_SEL_MASK(led->id), 0);
+
+ status = RG_ISINK_CK_PDN(led->id);
+ regmap_update_bits(regmap, MTK_MT6323_TOP_CKPDN2,
+ RG_ISINK_CK_PDN_MASK(led->id), ~status);
+
+ usleep_range(100, 300);
+
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_EN_CTRL,
+ ISINK_CH_EN_MASK(led->id),
+ ISINK_CH_EN(led->id));
+
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_CON2(led->id),
+ ISINK_CH_STEP_MASK,
+ ISINK_CH_STEP(1));
+
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_CON0(led->id),
+ ISINK_DIM_DUTY_MASK, ISINK_DIM_DUTY(31));
+
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_CON1(led->id),
+ ISINK_DIM_FSEL_MASK, ISINK_DIM_FSEL(1000));
+
+ led->current_brightness = 1;
+
+ dev_dbg(leds->dev, "%s called for led%d\n",
+ __func__, led->id);
+}
+
+static int mtk_led_set_blink(struct led_classdev *cdev,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
+ struct mtk_leds *leds = led->parent;
+ struct regmap *regmap = leds->hw->regmap;
+ u16 period;
+ u8 duty_cycle, duty_hw;
+
+ /* Units are in ms , if over the hardware able
+ * to support, fallback into software blink
+ */
+ if (*delay_on + *delay_off > MTK_MAX_PERIOD)
+ return -EINVAL;
+
+ /* LED subsystem requires a default user
+ * friendly blink pattern for the LED so using
+ * 1Hz duty cycle 50% here if without specific
+ * value delay_on and delay off being assigned
+ */
+ if (*delay_on == 0 && *delay_off == 0) {
+ *delay_on = 500;
+ *delay_off = 500;
+ }
+
+ period = *delay_on + *delay_off;
+
+ /* duty_cycle is the percentage of period during
+ * which the led is ON
+ */
+ duty_cycle = 100 * (*delay_on) / period;
+
+ mutex_lock(&leds->lock);
+
+ if (!led->current_brightness)
+ mtk_led_hw_on(cdev);
+
+ duty_hw = DIV_ROUND_CLOSEST(duty_cycle * 1000, 3125);
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_CON0(led->id),
+ ISINK_DIM_DUTY_MASK, ISINK_DIM_DUTY(duty_hw));
+
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_CON1(led->id),
+ ISINK_DIM_FSEL_MASK, ISINK_DIM_FSEL(period - 1));
+
+ mutex_unlock(&leds->lock);
+
+ dev_dbg(leds->dev, "%s: Hardware blink! period=%dms duty=%d for led%d\n",
+ __func__, period, duty_cycle, led->id);
+
+ return 0;
+}
+
+static int mtk_led_set_brightness(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
+ struct mtk_leds *leds = led->parent;
+ struct regmap *regmap = leds->hw->regmap;
+
+ mutex_lock(&leds->lock);
+
+ if (!led->current_brightness && brightness)
+ mtk_led_hw_on(cdev);
+
+ if (brightness) {
+ /* Setup current output for the corresponding
+ * brightness level
+ */
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_CON2(led->id),
+ ISINK_CH_STEP_MASK,
+ ISINK_CH_STEP(brightness - 1));
+
+ regmap_update_bits(regmap, MTK_MT6323_ISINK_CON2(led->id),
+ ISINK_SFSTR0_TC_MASK | ISINK_SFSTR0_EN_MASK,
+ ISINK_SFSTR0_TC(2) | ISINK_SFSTR0_EN);
+
+ dev_dbg(leds->dev, "Update led brightness:%d\n",
+ brightness);
+ }
+
+ if (!brightness)
+ mtk_led_hw_off(cdev);
+ led->current_brightness = brightness;
+
+ mutex_unlock(&leds->lock);
+
+ return 0;
+}
+
+static int mt6323_led_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *child;
+ struct mt6397_chip *hw = dev_get_drvdata(pdev->dev.parent);
+ struct mtk_leds *leds;
+ int ret, i = 0, count;
+ const char *state;
+ unsigned int status;
+
+ count = of_get_child_count(np);
+ if (!count)
+ return -ENODEV;
+
+ /* The number the LEDs on MT6323 could be support is
+ * up to MTK_MAX_DEVICES
+ */
+ count = (count <= MTK_MAX_DEVICES) ? count : MTK_MAX_DEVICES;
+
+ leds = devm_kzalloc(dev, sizeof(struct mtk_leds) +
+ sizeof(struct mtk_led) * count,
+ GFP_KERNEL);
+ if (!leds)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, leds);
+ leds->dev = dev;
+
+ /* leds->hw points to the underlying bus for the register
+ * controlled
+ */
+ leds->hw = hw;
+ mutex_init(&leds->lock);
+ leds->led_num = count;
+
+ status = RG_DRV_32K_CK_PDN;
+ regmap_update_bits(leds->hw->regmap, MTK_MT6323_TOP_CKPDN0,
+ RG_DRV_32K_CK_PDN_MASK, ~status);
+
+ /* Waiting for 32K stable prior to give the default value
+ * to each LED state decided through these useful common
+ * propertys such as label, linux,default-trigger and
+ * default-state
+ */
+ usleep_range(300, 500);
+
+ for_each_available_child_of_node(np, child) {
+ leds->led[i].cdev.name =
+ of_get_property(child, "label", NULL) ? :
+ child->name;
+ leds->led[i].cdev.default_trigger = of_get_property(child,
+ "linux,default-trigger",
+ NULL);
+ leds->led[i].cdev.max_brightness = MTK_MAX_BRIGHTNESS;
+ leds->led[i].cdev.brightness_set_blocking =
+ mtk_led_set_brightness;
+ leds->led[i].cdev.blink_set = mtk_led_set_blink;
+ leds->led[i].id = i;
+ leds->led[i].parent = leds;
+ state = of_get_property(child, "default-state", NULL);
+ if (state) {
+ if (!strcmp(state, "keep")) {
+ leds->led[i].current_brightness =
+ get_mtk_led_hw_brightness(&leds->led[i].cdev);
+ } else if (!strcmp(state, "on")) {
+ mtk_led_set_brightness(&leds->led[i].cdev, 1);
+ } else {
+ mtk_led_set_brightness(&leds->led[i].cdev,
+ 0);
+ }
+ }
+ ret = devm_led_classdev_register(dev, &leds->led[i].cdev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to register LED: %d\n",
+ ret);
+ return ret;
+ }
+ leds->led[i].cdev.dev->of_node = child;
+ i++;
+ }
+
+ return 0;
+}
+
+static int mt6323_led_remove(struct platform_device *pdev)
+{
+ struct mtk_leds *leds = platform_get_drvdata(pdev);
+ int i;
+
+ /* Turned the LED to OFF state if driver removal */
+ for (i = 0 ; i < leds->led_num ; i++)
+ mtk_led_hw_off(&leds->led[i].cdev);
+
+ regmap_update_bits(leds->hw->regmap, MTK_MT6323_TOP_CKPDN0,
+ RG_DRV_32K_CK_PDN_MASK, RG_DRV_32K_CK_PDN);
+ return 0;
+}
+
+static const struct of_device_id mt6323_led_dt_match[] = {
+ { .compatible = "mediatek,mt6323-led" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mt6323_led_dt_match);
+
+static struct platform_driver mt6323_led_driver = {
+ .probe = mt6323_led_probe,
+ .remove = mt6323_led_remove,
+ .driver = {
+ .name = "mt6323-led",
+ .of_match_table = mt6323_led_dt_match,
+ },
+};
+
+module_platform_driver(mt6323_led_driver);
+
+MODULE_DESCRIPTION("LED driver for Mediatek MT6323 PMIC");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox