* [RESEND PATCH 2/2] arm: dts: mt2701: Add i2c device node
From: Jun Gao @ 2017-01-18 9:41 UTC (permalink / raw)
To: Wolfram Sang, Matthias Brugger
Cc: srv_heupstream, devicetree, linux-i2c, linux-arm-kernel,
linux-kernel, linux-mediatek, Jun Gao
In-Reply-To: <1484732461-13594-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add i2c device node for MT2701.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
arch/arm/boot/dts/mt2701-evb.dts | 44 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 42 ++++++++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..a908e94 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,50 @@
};
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+};
+
+&pio {
+ i2c0_pins_a: i2c0@0 {
+ pins1 {
+ pinmux = <MT2701_PIN_75_SDA0__FUNC_SDA0>,
+ <MT2701_PIN_76_SCL0__FUNC_SCL0>;
+ bias-disable;
+ };
+ };
+
+ i2c1_pins_a: i2c1@0 {
+ pins1 {
+ pinmux = <MT2701_PIN_57_SDA1__FUNC_SDA1>,
+ <MT2701_PIN_58_SCL1__FUNC_SCL1>;
+ bias-disable;
+ };
+ };
+
+ i2c2_pins_a: i2c2@0 {
+ pins1 {
+ pinmux = <MT2701_PIN_77_SDA2__FUNC_SDA2>,
+ <MT2701_PIN_78_SCL2__FUNC_SCL2>;
+ bias-disable;
+ };
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..0d1539f 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,48 @@
status = "disabled";
};
+ i2c0: i2c@11007000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11007000 0 0x70>,
+ <0 0x11000200 0 0x80>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C0>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11008000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11008000 0 0x70>,
+ <0 0x11000280 0 0x80>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C1>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@11009000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11009000 0 0x70>,
+ <0 0x11000300 0 0x80>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C2>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/2] mmc: dt-bindings: update Mediatek MMC bindings
From: Rob Herring @ 2017-01-18 21:34 UTC (permalink / raw)
To: Yong Mao
Cc: Mark Rutland, devicetree, Ulf Hansson, Nicolas Boichat,
srv_heupstream, Javier Martinez Canillas, Catalin Marinas,
Will Deacon, Douglas Anderson, linux-kernel, Chunfeng Yun,
linux-mediatek, linux-arm-kernel, Philipp Zabel,
Greg Kroah-Hartman, Matthias Brugger, linux-mmc, Eddie Huang,
Chaotian Jing
In-Reply-To: <1484215490-7494-3-git-send-email-yong.mao@mediatek.com>
On Thu, Jan 12, 2017 at 06:04:50PM +0800, Yong Mao wrote:
> From: yong mao <yong.mao@mediatek.com>
>
> Add description for hs200-cmd-int-delay
> Add description for hs400-cmd-int-delay
> Add description for cmd-resp-sel
>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 0120c7f..2dbb3b0 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -21,6 +21,9 @@ 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
> +- hs200-cmd-int-delay: HS200 command internal delay setting
> +- hs400-cmd-int-delay: HS400 command internal delay setting
What are the units and range of values? These need vendor prefix as
well.
> +- cmd-resp-sel: command response sample selection
Looks like a boolean. State that and make the default the more common
case.
>
> Examples:
> mmc0: mmc@11230000 {
> @@ -38,4 +41,7 @@ mmc0: mmc@11230000 {
> assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
> assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
> hs400-ds-delay = <0x14015>;
> + hs200-cmd-int-delay = <26>;
> + hs400-cmd-int-delay = <14>;
> + cmd-resp-sel = <0>; /* 0: rising, 1: falling */
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v1 1/2] Documentation: mtk-quadspi: update DT bindings
From: Rob Herring @ 2017-01-18 22:08 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Guochun Mao, Richard Weinberger,
Russell King, linux-kernel, Marek Vasut, linux-mtd,
Matthias Brugger, linux-mediatek, Cyrille Pitchen, Brian Norris,
David Woodhouse, linux-arm-kernel
In-Reply-To: <20170113151326.11e9451a@bbrezillon>
On Fri, Jan 13, 2017 at 03:13:26PM +0100, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 15:13:28 +0800
> Guochun Mao <guochun.mao@mediatek.com> wrote:
>
> > Add "mediatek,mt2701-nor" for nor flash node's compatible.
> >
> > Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> > ---
> > .../devicetree/bindings/mtd/mtk-quadspi.txt | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > index fb314f0..f83d31d 100644
> > --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > @@ -1,7 +1,9 @@
> > * Serial NOR flash controller for MTK MT81xx (and similar)
> >
> > Required properties:
> > -- compatible: should be "mediatek,mt8173-nor";
> > +- compatible: should contain:
> > + "mediatek,mt2701-nor" for MT2701,
> > + "mediatek,mt8173-nor" for MT8173.
>
> Do you need to define a new compatible? If the IPs are exactly the same
> in both SoCs it shouldn't be needed.
Rather the 2701 should contain both strings in that case.
Rob
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Rob Herring @ 2017-01-18 22:20 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Boris Brezillon, Marek Vasut, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Guochun Mao,
Richard Weinberger, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Cyrille Pitchen,
Brian Norris, David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170117143650.5db87148-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote:
> Hello,
>
> (Side note: you guys should learn about stripping irrelevant parts of
> an e-mail when replying!)
>
> On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:
>
> > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > > as the oldest supported compatible and be done with it, no ? It looks a
> > > bit crappy though, I admit that ...
> >
> > Let's stop bikeshedding and wait for DT maintainers feedback
> > before taking a decision ;-).
> >
> > Rob, Mark, any opinion?
>
Sigh, is how to do compatibles really not yet understood?
> I agree that a clarification would be good. There are really two
> options:
>
> 1. Have two compatible strings in the DT, the one that matches the
> exact SoC where the IP is found (first compatible string) and the
> one that matches some other SoC where the same IP is found (second
> compatible string). Originally, Linux only supports the second
> compatible string in its device driver, but if it happens that a
> difference is found between two IPs that we thought were the same,
> we can add support for the first compatible string in the driver,
> with a slightly different behavior.
This. And no wildcards in the compatible string.
> 2. Have a single compatible string in the DT, matching the exact SoC
> where the IP is found. This involves adding immediately this
> compatible string in the corresponding driver.
I wouldn't object to this from a DT perspective as I have no clue
generally if IP blocks are "the same" or not. Subsystem maintainers will
object though.
> I've not really been able to figure out which of the two options is the
> most future-proof/appropriate.
They are both future-proof. #2 has the disadvantage of requiring a
kernel update for a new SoC.
Rob
--
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 v3 1/3] Documentation: devicetree: move shared property used by rc into a common place
From: Rob Herring @ 2017-01-18 22:22 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, sean-hENCXIMQXOg,
mchehab-JPH+aEBZ4P+UEJcrhfAQsw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1484292939-9454-2-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Fri, Jan 13, 2017 at 03:35:37PM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Most IR drivers uses the same label to identify the
> scancdoe/key table they used by multiple bindings and lack
> explanation well. So move the shared property into a common
> place and give better explanation.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/media/gpio-ir-receiver.txt | 3 +-
> .../devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
> Documentation/devicetree/bindings/media/rc.txt | 116 +++++++++++++++++++++
> .../devicetree/bindings/media/sunxi-ir.txt | 2 +-
> 4 files changed, 120 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/rc.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks for doing this.
Rob
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-18 22:23 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: mchehab-JPH+aEBZ4P+UEJcrhfAQsw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, 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
In-Reply-To: <1484292939-9454-3-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Fri, Jan 13, 2017 at 03:35:38PM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> This patch adds documentation for devicetree bindings for
> consumer Mediatek IR controller.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
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 v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-18 22:42 UTC (permalink / raw)
To: Sean Wang
Cc: Mauro Carvalho Chehab, Hans de Goede, Heiner Kallweit,
Mark Rutland, Matthias Brugger, Andi Shyti, Hans Verkuil,
Sean Young, Ivaylo Dimitrov, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-mediatek,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, sean wang
In-Reply-To: <20170118222321.ec6p7oqwwqfiofhp@rob-hp-laptop>
On Wed, Jan 18, 2017 at 4:23 PM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Jan 13, 2017 at 03:35:38PM +0800, sean.wang@mediatek.com wrote:
>> From: Sean Wang <sean.wang@mediatek.com>
>>
>> This patch adds documentation for devicetree bindings for
>> consumer Mediatek IR controller.
>>
>> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>> ---
>> .../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
>
> Acked-by: Rob Herring <robh@kernel.org>
I guess I rescind my ack if this email doesn't work:
"The response from the remote server was:
550 Relaying mail to sean.wang@mediatek.com is not allowed"
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Thomas Petazzoni @ 2017-01-18 23:38 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Boris Brezillon, Guochun Mao, devicetree,
Richard Weinberger, Russell King, linux-kernel, Marek Vasut,
linux-mtd, Matthias Brugger, linux-mediatek, Cyrille Pitchen,
Brian Norris, David Woodhouse, linux-arm-kernel
In-Reply-To: <20170118222010.ivc6jxpnrumemvdf@rob-hp-laptop>
Hello,
On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
> > > Rob, Mark, any opinion?
> >
>
> Sigh, is how to do compatibles really not yet understood?
Well, it seems like not everyone necessarily understands what is the
best strategy to adopt (me included).
> > I agree that a clarification would be good. There are really two
> > options:
> >
> > 1. Have two compatible strings in the DT, the one that matches the
> > exact SoC where the IP is found (first compatible string) and the
> > one that matches some other SoC where the same IP is found (second
> > compatible string). Originally, Linux only supports the second
> > compatible string in its device driver, but if it happens that a
> > difference is found between two IPs that we thought were the same,
> > we can add support for the first compatible string in the driver,
> > with a slightly different behavior.
>
> This. And no wildcards in the compatible string.
OK. So it means that today we do something like:
compatible = "baz,foo-12", "baz,foo-00";
and support only baz,foo-00 in the driver. If tomorrow we discover
that there is in fact a difference between the two IP blocks, we can
add support for baz,foo-12 in the driver, and handle the differences.
But then, the DT still contains:
compatible = "baz,foo-12", "baz,foo-00";
and therefore pretends that the IP block is compatible with
"baz,foo-00" which is in fact *not* the case. It was a mistake to
consider it as compatible. So we keep living with a DT that has
incorrect information.
>
> > 2. Have a single compatible string in the DT, matching the exact SoC
> > where the IP is found. This involves adding immediately this
> > compatible string in the corresponding driver.
>
> I wouldn't object to this from a DT perspective as I have no clue
> generally if IP blocks are "the same" or not. Subsystem maintainers will
> object though.
Knowing if IP blocks are "the same" is in fact not necessarily trivial.
What appears to be identical IP blocks today might be discovered later
as actually having subtle differences (sometimes not even visible in
the datasheet).
> > I've not really been able to figure out which of the two options is the
> > most future-proof/appropriate.
>
> They are both future-proof. #2 has the disadvantage of requiring a
> kernel update for a new SoC.
Which is generally anyway needed because a new SoC will almost always
require some new drivers, adjusting pin-muxing or clock drivers, etc.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v11 10/12] drm/mediatek: add non-continuous clock mode and EOT packet control
From: CK Hu @ 2017-01-19 1:42 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, shaoming chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-11-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch will update dsi clock control method.
> 1. dsi non-continue clock mode will enhance antistatic effect for panel
> 2. EOT packet control will judge whether dsi send end of packet or not
> by customize
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b3c7fd8..85f22d2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -431,6 +431,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
> break;
> }
>
> + tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6;
> + tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3;
> +
> writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
> }
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Rob Herring @ 2017-01-19 2:51 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Boris Brezillon, Marek Vasut, Mark Rutland,
devicetree@vger.kernel.org, Guochun Mao, Richard Weinberger,
Russell King, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, Matthias Brugger, linux-mediatek,
Cyrille Pitchen, Brian Norris, David Woodhouse,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170119103829.524ce715@free-electrons.com>
On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
>
>> > > Rob, Mark, any opinion?
>> >
>>
>> Sigh, is how to do compatibles really not yet understood?
>
> Well, it seems like not everyone necessarily understands what is the
> best strategy to adopt (me included).
>
>> > I agree that a clarification would be good. There are really two
>> > options:
>> >
>> > 1. Have two compatible strings in the DT, the one that matches the
>> > exact SoC where the IP is found (first compatible string) and the
>> > one that matches some other SoC where the same IP is found (second
>> > compatible string). Originally, Linux only supports the second
>> > compatible string in its device driver, but if it happens that a
>> > difference is found between two IPs that we thought were the same,
>> > we can add support for the first compatible string in the driver,
>> > with a slightly different behavior.
>>
>> This. And no wildcards in the compatible string.
>
> OK. So it means that today we do something like:
>
> compatible = "baz,foo-12", "baz,foo-00";
>
> and support only baz,foo-00 in the driver. If tomorrow we discover
> that there is in fact a difference between the two IP blocks, we can
> add support for baz,foo-12 in the driver, and handle the differences.
>
> But then, the DT still contains:
>
> compatible = "baz,foo-12", "baz,foo-00";
>
> and therefore pretends that the IP block is compatible with
> "baz,foo-00" which is in fact *not* the case. It was a mistake to
> consider it as compatible. So we keep living with a DT that has
> incorrect information.
I wouldn't say it's a mistake necessarily. The old compatible would
probably work to some extent. I'd assume it was tested to some level.
Or it could be other changes exposing a difference.
>> > 2. Have a single compatible string in the DT, matching the exact SoC
>> > where the IP is found. This involves adding immediately this
>> > compatible string in the corresponding driver.
>>
>> I wouldn't object to this from a DT perspective as I have no clue
>> generally if IP blocks are "the same" or not. Subsystem maintainers will
>> object though.
>
> Knowing if IP blocks are "the same" is in fact not necessarily trivial.
> What appears to be identical IP blocks today might be discovered later
> as actually having subtle differences (sometimes not even visible in
> the datasheet).
Yes, I know. That's exactly when you should have multiple compatibles.
Trying to guarantee things are the same is just going to get you in
trouble. You only need to figure out if blocks are obviously different
and only drop the old compatible in that case.
>> > I've not really been able to figure out which of the two options is the
>> > most future-proof/appropriate.
>>
>> They are both future-proof. #2 has the disadvantage of requiring a
>> kernel update for a new SoC.
>
> Which is generally anyway needed because a new SoC will almost always
> require some new drivers, adjusting pin-muxing or clock drivers, etc.
Yes, but you don't want to have to update every single driver.
Rob
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Sean Wang @ 2017-01-19 3:00 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Ivaylo Dimitrov,
sean wang, Sean Young, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Andi Shyti, Hans Verkuil,
Hans de Goede, linux-mediatek, Matthias Brugger,
linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Heiner Kallweit
In-Reply-To: <CAL_JsqKsxwY+v-8Q=o1ERpyfFkR7d+83kKUdfY=u21FHUX5UEw@mail.gmail.com>
On Wed, 2017-01-18 at 16:42 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 4:23 PM, Rob Herring <robh@kernel.org> wrote:
> > On Fri, Jan 13, 2017 at 03:35:38PM +0800, sean.wang@mediatek.com wrote:
> >> From: Sean Wang <sean.wang@mediatek.com>
> >>
> >> This patch adds documentation for devicetree bindings for
> >> consumer Mediatek IR controller.
> >>
> >> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> >> ---
> >> .../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
> >> 1 file changed, 24 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
> >
> > Acked-by: Rob Herring <robh@kernel.org>
>
> I guess I rescind my ack if this email doesn't work:
>
> "The response from the remote server was:
>
> 550 Relaying mail to sean.wang@mediatek.com is not allowed"
sorry for causing you inconvenience.
it should be able to work because i almost use this daily
maybe that's just a sudden problem from internal server (?)
but if the problem still continues, please let me know and
i will try to fix this.
^ permalink raw reply
* Re: [PATCH v11 11/12] drm/mediatek: update DSI sub driver flow for sending commands to panel
From: CK Hu @ 2017-01-19 3:20 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, shaoming chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-12-git-send-email-yt.shen@mediatek.com>
Hi, YT:
one comment inline.
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 89 +++++++++++++++++++++++++++++++-------
> 1 file changed, 74 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 85f22d2..21392c4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_VM_CMD_CON 0x130
> +#define VM_CMD_EN BIT(0)
> +#define TS_VFP_EN BIT(5)
> +
> #define DSI_CMDQ0 0x180
> #define CONFIG (0xff << 0)
> #define SHORT_PACKET 0
> @@ -365,16 +369,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> u32 vid_mode = CMD_MODE;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
> }
>
> writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> }
>
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
> static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> {
> struct videomode *vm = &dsi->vm;
> @@ -512,6 +523,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> writel(1, dsi->regs + DSI_START);
> }
>
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
> static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> {
> u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -570,6 +591,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
> static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> {
> if (WARN_ON(dsi->refcount == 0))
> @@ -578,6 +612,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> if (--dsi->refcount != 0)
> return;
>
> + mtk_dsi_stop(dsi);
> + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel)) {
Why drm_panel_unprepare() in mtk_dsi_poweroff() but drm_panel_prepare()
in mtk_output_dsi_enable()? This asymmetric design would easily cause
some bugs.
Regards,
CK
> + DRM_ERROR("failed to unprepare the panel\n");
> + return;
> + }
> + }
> + }
> +
> + mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
>
> @@ -596,13 +641,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> if (dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0) {
> DRM_ERROR("failed to power on dsi\n");
> @@ -610,22 +648,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> }
>
> mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>
> mtk_dsi_clk_ulp_mode_leave(dsi);
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
> - mtk_dsi_set_mode(dsi);
>
> - mtk_dsi_ps_control_vact(dsi);
> - mtk_dsi_config_vdo_timing(dsi);
> - mtk_dsi_set_interrupt_enable(dsi);
> + if (dsi->panel) {
> + if (drm_panel_prepare(dsi->panel)) {
> + DRM_ERROR("failed to prepare the panel\n");
> + goto err_dsi_power_off;
> + }
> + }
>
> mtk_dsi_set_mode(dsi);
> mtk_dsi_clk_hs_mode(dsi, 1);
>
> mtk_dsi_start(dsi);
>
> + if (dsi->panel) {
> + if (drm_panel_enable(dsi->panel)) {
> + DRM_ERROR("failed to enable the panel\n");
> + goto err_panel_disable;
> + }
> + }
> +
> dsi->enabled = true;
> +
> + return;
> +err_panel_disable:
> + mtk_dsi_stop(dsi);
> + if (dsi->panel)
> + drm_panel_unprepare(dsi->panel);
> +err_dsi_power_off:
> + mtk_dsi_poweroff(dsi);
> }
>
> static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v11 12/12] drm/mediatek: add support for Mediatek SoC MT2701
From: CK Hu @ 2017-01-19 5:30 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-13-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 ++++++++
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++++++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 17 +++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 7 +++++++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 29 +++++++++++++++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 6 ++++++
> 7 files changed, 74 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 4552178..a14d7d6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -35,6 +35,7 @@
> #define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
> #define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
> #define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
> +#define DISP_REG_OVL_ADDR_MT2701 0x0040
> #define DISP_REG_OVL_ADDR_MT8173 0x0f40
> #define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
>
> @@ -303,12 +304,19 @@ static int mtk_disp_ovl_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT2701,
> + .fmt_rgb565_is_0 = false,
> +};
> +
> static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> .addr = DISP_REG_OVL_ADDR_MT8173,
> .fmt_rgb565_is_0 = true,
> };
>
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl",
> + .data = &mt2701_ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = &mt8173_ovl_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index e5e5318..b68a513 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -236,11 +236,17 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
> + .fifo_size = SZ_4K,
> +};
> +
> static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
> .fifo_size = SZ_8K,
> };
>
> static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-rdma",
> + .data = &mt2701_rdma_driver_data},
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = &mt8173_rdma_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a9b209c..8130f3d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -60,6 +60,13 @@
> #define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
> #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>
> +#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
> +#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
> +#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
> +#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
> +#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
> +#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
> +
> #define MUTEX_SOF_SINGLE_MODE 0
> #define MUTEX_SOF_DSI0 1
> #define MUTEX_SOF_DSI1 2
> @@ -92,6 +99,15 @@ struct mtk_ddp {
> const unsigned int *mutex_mod;
> };
>
> +static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> + [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
> + [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id ddp_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> {},
> };
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index f6e853a..8b52416 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -39,6 +39,7 @@
> #define DISP_REG_UFO_START 0x0000
>
> #define DISP_COLOR_CFG_MAIN 0x0400
> +#define DISP_COLOR_START_MT2701 0x0f00
> #define DISP_COLOR_START_MT8173 0x0c00
> #define DISP_COLOR_START(comp) ((comp)->data->color_offset)
> #define DISP_COLOR_WIDTH(comp) (DISP_COLOR_START(comp) + 0x50)
> @@ -285,11 +286,17 @@ struct mtk_ddp_comp_match {
> [DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
> };
>
> +static const struct mtk_disp_color_data mt2701_color_driver_data = {
> + .color_offset = DISP_COLOR_START_MT2701,
> +};
> +
> static const struct mtk_disp_color_data mt8173_color_driver_data = {
> .color_offset = DISP_COLOR_START_MT8173,
> };
>
> static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-color",
> + .data = &mt2701_color_driver_data},
> { .compatible = "mediatek,mt8173-disp-color",
> .data = &mt8173_color_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 074fe31..7daabae 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -128,6 +128,19 @@ static int mtk_atomic_commit(struct drm_device *drm,
> .atomic_commit = mtk_atomic_commit,
> };
>
> +static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_BLS,
> + DDP_COMPONENT_DSI0,
> +};
> +
> +static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_DPI0,
> +};
> +
> static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> @@ -147,6 +160,14 @@ static int mtk_atomic_commit(struct drm_device *drm,
> DDP_COMPONENT_DPI0,
> };
>
> +static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> + .main_path = mt2701_mtk_ddp_main,
> + .main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
> + .ext_path = mt2701_mtk_ddp_ext,
> + .ext_len = ARRAY_SIZE(mt2701_mtk_ddp_ext),
> + .shadow_register = true,
> +};
> +
> static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> .main_path = mt8173_mtk_ddp_main,
> .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> @@ -340,16 +361,22 @@ static void mtk_drm_unbind(struct device *dev)
> };
>
> static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl", .data = (void *)MTK_DISP_OVL },
> { .compatible = "mediatek,mt8173-disp-ovl", .data = (void *)MTK_DISP_OVL },
> + { .compatible = "mediatek,mt2701-disp-rdma", .data = (void *)MTK_DISP_RDMA },
> { .compatible = "mediatek,mt8173-disp-rdma", .data = (void *)MTK_DISP_RDMA },
> { .compatible = "mediatek,mt8173-disp-wdma", .data = (void *)MTK_DISP_WDMA },
> + { .compatible = "mediatek,mt2701-disp-color", .data = (void *)MTK_DISP_COLOR },
> { .compatible = "mediatek,mt8173-disp-color", .data = (void *)MTK_DISP_COLOR },
> { .compatible = "mediatek,mt8173-disp-aal", .data = (void *)MTK_DISP_AAL},
> { .compatible = "mediatek,mt8173-disp-gamma", .data = (void *)MTK_DISP_GAMMA, },
> { .compatible = "mediatek,mt8173-disp-ufoe", .data = (void *)MTK_DISP_UFOE },
> + { .compatible = "mediatek,mt2701-dsi", .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
> + { .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> + { .compatible = "mediatek,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
> { .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
> { .compatible = "mediatek,mt8173-disp-od", .data = (void *)MTK_DISP_OD },
> { }
> @@ -523,6 +550,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
> mtk_drm_sys_resume);
>
> static const struct of_device_id mtk_drm_of_ids[] = {
> + { .compatible = "mediatek,mt2701-mmsys",
> + .data = &mt2701_mmsys_driver_data},
> { .compatible = "mediatek,mt8173-mmsys",
> .data = &mt8173_mmsys_driver_data},
> { }
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 21392c4..e1832ea 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1228,6 +1228,7 @@ static int mtk_dsi_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id mtk_dsi_of_match[] = {
> + { .compatible = "mediatek,mt2701-dsi" },
> { .compatible = "mediatek,mt8173-dsi" },
> { },
> };
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index fd84914..90e9131 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -465,11 +465,17 @@ static int mtk_mipi_tx_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mtk_mipitx_data mt2701_mipitx_data = {
> + .mppll_preserve = (3 << 8)
> +};
> +
> static const struct mtk_mipitx_data mt8173_mipitx_data = {
> .mppll_preserve = (0 << 8)
> };
>
> static const struct of_device_id mtk_mipi_tx_match[] = {
> + { .compatible = "mediatek,mt2701-mipi-tx",
> + .data = &mt2701_mipitx_data },
> { .compatible = "mediatek,mt8173-mipi-tx",
> .data = &mt8173_mipitx_data },
> {},
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-19 7:53 UTC (permalink / raw)
To: Rob Herring
Cc: Thomas Petazzoni, Marek Vasut, Mark Rutland, devicetree,
Guochun Mao, Richard Weinberger, Russell King, linux-kernel,
linux-mtd, Matthias Brugger, linux-mediatek, Cyrille Pitchen,
Brian Norris, David Woodhouse, linux-arm-kernel
In-Reply-To: <20170118222010.ivc6jxpnrumemvdf@rob-hp-laptop>
On Wed, 18 Jan 2017 16:20:10 -0600
Rob Herring <robh@kernel.org> wrote:
> On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote:
> > Hello,
> >
> > (Side note: you guys should learn about stripping irrelevant parts of
> > an e-mail when replying!)
> >
> > On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:
> >
> > > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > > > as the oldest supported compatible and be done with it, no ? It looks a
> > > > bit crappy though, I admit that ...
> > >
> > > Let's stop bikeshedding and wait for DT maintainers feedback
> > > before taking a decision ;-).
> > >
> > > Rob, Mark, any opinion?
> >
>
> Sigh, is how to do compatibles really not yet understood?
Apparently not, and I fear this is not the last misunderstanding on my
side ;-).
>
> > I agree that a clarification would be good. There are really two
> > options:
> >
> > 1. Have two compatible strings in the DT, the one that matches the
> > exact SoC where the IP is found (first compatible string) and the
> > one that matches some other SoC where the same IP is found (second
> > compatible string). Originally, Linux only supports the second
> > compatible string in its device driver, but if it happens that a
> > difference is found between two IPs that we thought were the same,
> > we can add support for the first compatible string in the driver,
> > with a slightly different behavior.
>
> This. And no wildcards in the compatible string.
>
> > 2. Have a single compatible string in the DT, matching the exact SoC
> > where the IP is found. This involves adding immediately this
> > compatible string in the corresponding driver.
>
> I wouldn't object to this from a DT perspective as I have no clue
> generally if IP blocks are "the same" or not. Subsystem maintainers will
> object though.
>
> > I've not really been able to figure out which of the two options is the
> > most future-proof/appropriate.
>
> They are both future-proof. #2 has the disadvantage of requiring a
> kernel update for a new SoC.
>
> Rob
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-19 8:14 UTC (permalink / raw)
To: Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Thomas Petazzoni, Marek Vasut, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Guochun Mao,
Richard Weinberger, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Matthias Brugger, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Cyrille Pitchen, Brian Norris, David Woodhouse
In-Reply-To: <CAL_Jsq+EyHtC7THLCJcwgtVtVESMOdmi3T3bBxgOqJt6BCtCHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Wed, 18 Jan 2017 20:51:08 -0600
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
> <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > Hello,
> >
> > On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
> >
> >> > > Rob, Mark, any opinion?
> >> >
> >>
> >> Sigh, is how to do compatibles really not yet understood?
> >
> > Well, it seems like not everyone necessarily understands what is the
> > best strategy to adopt (me included).
> >
> >> > I agree that a clarification would be good. There are really two
> >> > options:
> >> >
> >> > 1. Have two compatible strings in the DT, the one that matches the
> >> > exact SoC where the IP is found (first compatible string) and the
> >> > one that matches some other SoC where the same IP is found (second
> >> > compatible string). Originally, Linux only supports the second
> >> > compatible string in its device driver, but if it happens that a
> >> > difference is found between two IPs that we thought were the same,
> >> > we can add support for the first compatible string in the driver,
> >> > with a slightly different behavior.
> >>
> >> This. And no wildcards in the compatible string.
> >
> > OK. So it means that today we do something like:
> >
> > compatible = "baz,foo-12", "baz,foo-00";
> >
> > and support only baz,foo-00 in the driver. If tomorrow we discover
> > that there is in fact a difference between the two IP blocks, we can
> > add support for baz,foo-12 in the driver, and handle the differences.
> >
> > But then, the DT still contains:
> >
> > compatible = "baz,foo-12", "baz,foo-00";
> >
> > and therefore pretends that the IP block is compatible with
> > "baz,foo-00" which is in fact *not* the case. It was a mistake to
> > consider it as compatible. So we keep living with a DT that has
> > incorrect information.
>
> I wouldn't say it's a mistake necessarily. The old compatible would
> probably work to some extent. I'd assume it was tested to some level.
> Or it could be other changes exposing a difference.
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.
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.
Regards,
Boris
--
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 v2 1/2] mmc: core: Fix CMD6 timeout issue
From: Yong Mao @ 2017-01-19 8:58 UTC (permalink / raw)
To: Ulf Hansson
Cc: Shawn Lin, linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Adrian Hunter, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Chunfeng Yun, Eddie Huang, Linus Walleij, Chaotian Jing
In-Reply-To: <CAPDyKFrkehvdnYgau1zFmgcHUniMbcat_NOLkB7bSGWF+b=c9Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2017-01-12 at 16:21 +0100, Ulf Hansson wrote:
> - trimmed cc-list
>
> On 3 January 2017 at 09:49, Yong Mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> > From: yong mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >
> > When initializing EMMC, after switch to HS400,
> > it will issue CMD6 to change ext_csd,
> > if first CMD6 got CRC error,
> > the repeat CMD6 may get timeout,
> > that's because card is not back to transfer state immediately.
> >
> > For resolving this issue, it need check if card is busy
> > before sending repeat CMD6.
>
> I agree that doing retries in this path might may not be correctly
> done, but currently we do it as best effort.
>
> We should probably change this to *not* retry the CMD6 command, in
> cases when we have a MMC_RSP_R1B response, because of the reasons you
> describe.
> I get the feeling that these retry attempts for CMD6, may instead hide
> other real issues and making it harder to narrow them down. Don't you
> think?
> This leads to my following question:
> Why do you get a CRC error at the first CMD6 attempt? That shouldn't
> happen, right?
>
Host needs to ensure that there is no CRC error when sampling the
signal from device. However, in the high frequency mode, it is
inevitable that there will be CRC error.
Because of the presence of CRC error, we have the re-tune mechanism in
the mmc core layer to handle.
But in this case, it will occur CMD timeout error after re-sending the
R1B CMD. Currently, we still do not have mechanism to handle this case
in the mmc core layer.
> Perhaps you can elaborate on what of the CMD6 commands in the HS400
> enabling sequence that fails. It may help us to understand, perhaps
> there may be something in that sequence that should be changed.
>
Sorry. Maybe I didn't describe this issue clearly.
The CMD6 command issue in my commit message is only a specific example
of this type of issue we actually encounter.
I describe the issue step by step as below:
Step 1: Send a R1B command and then get command CRC error.
Step 2: According to the current logic of mmc core layer code,
it will resend this R1B command again.
Step 3: Because card may be in the busy state while resending this
R1B command, card will not response this R1B command.
And then this R1B command will fail with the reason
of timeout.
> >
> > Not only CMD6 here has this issue, but also other R1B CMD has
> > the same issue.
>
> Yes, agree!
>
> However, can you please try to point out some other commands than CM6
> that you see uses *retries*, has R1B response, and which you believe
> may not be properly managed.
>
Actually, we just met this CMD6 timeout issue in our project.
However, according to the analysis, all R1b command may have the same
issue.
> Dealing with R1B responses isn't always straight forward. Therefore I
> am wondering whether we perhaps should just not allow "automatic
> retries" in cases when R1B responses is used.
>
> The reason why I think that is easier, is because of the complexity we
> have when dealing with R1B responses.
We think "automatic retries" should still be used in this case.
With "automatic retries", it have re-tune mechanism to let host
re-select a better parameters to handle command CRC error.
>
> As for example the timeout may differ depending on the command, so
> just guessing that 500 ms might work, isn't good enough. Moreover we
> would need to deal with MMC_CAP_WAIT_WHILE_BUSY, etc. Currently I am
> not saying that we shouldn't do this, but then I first need to
> understand how big of problem this is.
>
Yes. You are right. We need to deal with MMC_CAP_WAIT_WHILE_BUSY here.
If the host has the capability of MMC_CAP_WAIT_WHILE_BUSY, it does not
need this patch. But the host, like our host, does not have this
capability, it needs this patch. I will add this logic in next version.
According to our experience, 500ms is enough here.
> >
> > Signed-off-by: Yong Mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > Signed-off-by: Chaotian Jing <chaotian.jing-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/mmc/core/core.c | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > index 1076b9d..8674dbb 100644
> > --- a/drivers/mmc/core/core.c
> > +++ b/drivers/mmc/core/core.c
> > @@ -566,6 +566,25 @@ void mmc_wait_for_req_done(struct mmc_host *host, struct mmc_request *mrq)
> >
> > mmc_retune_recheck(host);
> >
> > + /*
> > + * If a R1B CMD such as CMD6 occur CRC error,
> > + * it will retry 3 times here.
> > + * But before retrying, it must ensure card is in
> > + * transfer state.
> > + * Otherwise, the next retried CMD will got TMO error.
> > + */
> > + if (mmc_resp_type(cmd) == MMC_RSP_R1B && host->ops->card_busy) {
> > + int tries = 500; /* Wait aprox 500ms at maximum */
> > +
> > + while (host->ops->card_busy(host) && --tries)
> > + mmc_delay(1);
> > +
> > + if (tries == 0) {
> > + cmd->error = -EBUSY;
> > + break;
> > + }
> > + }
> > +
> > pr_debug("%s: req failed (CMD%u): %d, retrying...\n",
> > mmc_hostname(host), cmd->opcode, cmd->error);
> > cmd->retries--;
> > --
> > 1.7.9.5
> >
>
> Kind regards
> Uffe
^ permalink raw reply
* Re: [PATCH v2 1/2] mmc: core: Fix CMD6 timeout issue
From: Yong Mao @ 2017-01-19 9:06 UTC (permalink / raw)
To: Shawn Lin
Cc: Ulf Hansson, Chunfeng Yun, Eddie Huang, Adrian Hunter,
Linus Walleij, Chaotian Jing, linux-mmc@vger.kernel.org,
linux-mediatek
In-Reply-To: <b6efb075-226a-c7c8-2c6d-7d61d78eced1@rock-chips.com>
On Fri, 2017-01-13 at 11:35 +0800, Shawn Lin wrote:
> On 2017/1/12 23:21, Ulf Hansson wrote:
> > - trimmed cc-list
> >
> > On 3 January 2017 at 09:49, Yong Mao <yong.mao@mediatek.com> wrote:
> >> From: yong mao <yong.mao@mediatek.com>
> >>
> >> When initializing EMMC, after switch to HS400,
> >> it will issue CMD6 to change ext_csd,
> >> if first CMD6 got CRC error,
> >> the repeat CMD6 may get timeout,
> >> that's because card is not back to transfer state immediately.
> >>
> >> For resolving this issue, it need check if card is busy
> >> before sending repeat CMD6.
> >
> > I agree that doing retries in this path might may not be correctly
> > done, but currently we do it as best effort.
> >
> > We should probably change this to *not* retry the CMD6 command, in
> > cases when we have a MMC_RSP_R1B response, because of the reasons you
> > describe.
> > I get the feeling that these retry attempts for CMD6, may instead hide
> > other real issues and making it harder to narrow them down. Don't you
> > think?
> >
> > This leads to my following question:
> > Why do you get a CRC error at the first CMD6 attempt? That shouldn't
> > happen, right?
> >
> > Perhaps you can elaborate on what of the CMD6 commands in the HS400
> > enabling sequence that fails. It may help us to understand, perhaps
> > there may be something in that sequence that should be changed.
> >
> >>
> >> Not only CMD6 here has this issue, but also other R1B CMD has
> >> the same issue.
> >
> > Yes, agree!
> >
> > However, can you please try to point out some other commands than CM6
> > that you see uses *retries*, has R1B response, and which you believe
> > may not be properly managed.
> >
> > Dealing with R1B responses isn't always straight forward. Therefore I
> > am wondering whether we perhaps should just not allow "automatic
> > retries" in cases when R1B responses is used.
> >
> > The reason why I think that is easier, is because of the complexity we
> > have when dealing with R1B responses.
> >
>
> I'm just thinking a interesting question: What will happen if someone
> uses a userspace tool to switch the partition to RPMB when we are in
> command queue mode? It will fails to finish CMD6 and the emmc should be
> busy for a while. So now we shouldn't retry CMD6 but need to send a
> CMD13 to make sure it's back to transfer state OR a HPI to break it. We
> should be able to cover these cases not only from kernel context but
> also the interaction between user and kernel.
>
Specification can ensure that your question will not occur.
"NOTE if hosts need to access RPMB partition, the host should disable
the Command Queue mechanism and access RPMB partition not through the
command queue."
"General Purpose partitions may be accessed when command queuing is
enabled.The queue must be empty when CMD6 is sent(to switch partitions
or to disable command queuing). Sending CMD6 while the queue is not
empty shall be regarded as illegal command(see 6.6.39.9, Supported
Commands)."
> > As for example the timeout may differ depending on the command, so
> > just guessing that 500 ms might work, isn't good enough. Moreover we
> > would need to deal with MMC_CAP_WAIT_WHILE_BUSY, etc. Currently I am
> > not saying that we shouldn't do this, but then I first need to
> > understand how big of problem this is.
> >
> >>
> >> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> >> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
> >> ---
> >> drivers/mmc/core/core.c | 19 +++++++++++++++++++
> >> 1 file changed, 19 insertions(+)
> >>
> >> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> >> index 1076b9d..8674dbb 100644
> >> --- a/drivers/mmc/core/core.c
> >> +++ b/drivers/mmc/core/core.c
> >> @@ -566,6 +566,25 @@ void mmc_wait_for_req_done(struct mmc_host *host, struct mmc_request *mrq)
> >>
> >> mmc_retune_recheck(host);
> >>
> >> + /*
> >> + * If a R1B CMD such as CMD6 occur CRC error,
> >> + * it will retry 3 times here.
> >> + * But before retrying, it must ensure card is in
> >> + * transfer state.
> >> + * Otherwise, the next retried CMD will got TMO error.
> >> + */
> >> + if (mmc_resp_type(cmd) == MMC_RSP_R1B && host->ops->card_busy) {
> >> + int tries = 500; /* Wait aprox 500ms at maximum */
> >> +
> >> + while (host->ops->card_busy(host) && --tries)
> >> + mmc_delay(1);
> >> +
> >> + if (tries == 0) {
> >> + cmd->error = -EBUSY;
> >> + break;
> >> + }
> >> + }
> >> +
> >> pr_debug("%s: req failed (CMD%u): %d, retrying...\n",
> >> mmc_hostname(host), cmd->opcode, cmd->error);
> >> cmd->retries--;
> >> --
> >> 1.7.9.5
> >>
> >
> > Kind regards
> > Uffe
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: mt8173: add reference clock for usb
From: Greg Kroah-Hartman @ 2017-01-19 9:37 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Mathias Nyman, Felipe Balbi,
Ian Campbell, linux-usb, linux-kernel, Rob Herring,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1484719707-12107-4-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jan 18, 2017 at 02:08:25PM +0800, Chunfeng Yun wrote:
> add 26M reference clock for ssusb and xhci nodes
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
This patch doesn't apply to my tree :(
^ permalink raw reply
* [PATCH v3 0/3] mmc: mediatek: Use data tune for CMD line tune
From: Yong Mao @ 2017-01-19 10:19 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
yong mao (3):
mmc: dt-bindings: update Mediatek MMC bindings
dts: mediatek: configure some fixed mmc parameters
mmc: mediatek: Use data tune for CMD line tune
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 9 ++
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +
drivers/mmc/host/mtk-sd.c | 170 ++++++++++++++++++++---
3 files changed, 165 insertions(+), 17 deletions(-)
--
1.8.1.1.dirty
^ permalink raw reply
* [PATCH v3 1/3] mmc: dt-bindings: update Mediatek MMC bindings
From: Yong Mao @ 2017-01-19 10:19 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
In-Reply-To: <1484821156-20565-1-git-send-email-yong.mao@mediatek.com>
From: yong mao <yong.mao@mediatek.com>
Add description for mtk-hs200-cmd-int-delay
Add description for mtk-hs400-cmd-int-delay
Add description for mtk-hs400-cmd-resp-sel
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
---
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 0120c7f..149f472 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -21,6 +21,12 @@ 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
+- mtk-hs200-cmd-int-delay: HS200 command internal delay setting.
+ The value is an integer from 0 to 31
+- mtk-hs400-cmd-int-delay: HS400 command internal delay setting
+ The value is an integer from 0 to 31
+- mtk-hs400-cmd-resp-sel: HS400 command response sample selection
+ The value is an integer from 0 to 1
Examples:
mmc0: mmc@11230000 {
@@ -38,4 +44,7 @@ mmc0: mmc@11230000 {
assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
hs400-ds-delay = <0x14015>;
+ mtk-hs200-cmd-int-delay = <26>;
+ mtk-hs400-cmd-int-delay = <14>;
+ mtk-hs400-cmd-resp-sel = <0>; /* 0: rising, 1: falling */
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/3] dts: mediatek: configure some fixed mmc parameters
From: Yong Mao @ 2017-01-19 10:19 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
In-Reply-To: <1484821156-20565-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..403705e 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;
+ mtk-hs200-cmd-int-delay=<26>;
+ mtk-hs400-cmd-int-delay=<14>;
+ mtk-hs400-cmd-resp-sel=<0>; /* 0:rising, 1:falling */
vmmc-supply = <&mt6397_vemc_3v3_reg>;
vqmmc-supply = <&mt6397_vio18_reg>;
non-removable;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 3/3] mmc: mediatek: Use data tune for CMD line tune
From: Yong Mao @ 2017-01-19 10:19 UTC (permalink / raw)
To: Ulf Hansson
Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Linus Walleij,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, yong mao,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chunfeng Yun,
Eddie Huang, Chaotian Jing
In-Reply-To: <1484821156-20565-1-git-send-email-yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: yong mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
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-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Signed-off-by: Chaotian Jing <chaotian.jing-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/mmc/host/mtk-sd.c | 170 ++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 153 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 80ba034..b4e1c43 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,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 */
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 +611,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 +1319,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 +1342,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 +1414,68 @@ 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);
+ sdr_set_field(host->base + MSDC_IOCON, MSDC_IOCON_RSPL,
+ host->hs400_cmd_resp_sel);
+ 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 +1498,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 +1531,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 +1540,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 +1556,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 +1591,30 @@ 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)
+{
+ 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);
+
+ 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;
-
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
^ permalink raw reply related
* Re: [PATCH 2/6] usb: mtu3: add reference clock
From: Matthias Brugger @ 2017-01-19 12:22 UTC (permalink / raw)
To: Chunfeng Yun, Mathias Nyman, Felipe Balbi
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Ian Campbell,
linux-kernel, linux-arm-kernel, linux-usb, linux-mediatek,
devicetree
In-Reply-To: <1484719707-12107-2-git-send-email-chunfeng.yun@mediatek.com>
On 18/01/17 07:08, Chunfeng Yun wrote:
> usually, the reference clock comes from 26M oscillator directly,
> but some SoCs are not, add it for compatibility.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/usb/mtu3/mtu3.h | 1 +
> drivers/usb/mtu3/mtu3_plat.c | 21 +++++++++++++++++++--
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
> index ba9df71..aa6fd6a 100644
> --- a/drivers/usb/mtu3/mtu3.h
> +++ b/drivers/usb/mtu3/mtu3.h
> @@ -225,6 +225,7 @@ struct ssusb_mtk {
> /* common power & clock */
> struct regulator *vusb33;
> struct clk *sys_clk;
> + struct clk *ref_clk;
> /* otg */
> struct otg_switch_mtk otg_switch;
> enum usb_dr_mode dr_mode;
> diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
> index 6344859..19a345d 100644
> --- a/drivers/usb/mtu3/mtu3_plat.c
> +++ b/drivers/usb/mtu3/mtu3_plat.c
> @@ -123,7 +123,13 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> ret = clk_prepare_enable(ssusb->sys_clk);
> if (ret) {
> dev_err(ssusb->dev, "failed to enable sys_clk\n");
> - goto clk_err;
> + goto sys_clk_err;
> + }
> +
> + ret = clk_prepare_enable(ssusb->ref_clk);
> + if (ret) {
> + dev_err(ssusb->dev, "failed to enable ref_clk\n");
> + goto ref_clk_err;
> }
>
> ret = ssusb_phy_init(ssusb);
> @@ -143,8 +149,10 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> phy_err:
> ssusb_phy_exit(ssusb);
> phy_init_err:
> + clk_disable_unprepare(ssusb->ref_clk);
> +ref_clk_err:
> clk_disable_unprepare(ssusb->sys_clk);
> -clk_err:
> +sys_clk_err:
> regulator_disable(ssusb->vusb33);
> vusb33_err:
>
> @@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
> {
> clk_disable_unprepare(ssusb->sys_clk);
> + clk_disable_unprepare(ssusb->ref_clk);
> regulator_disable(ssusb->vusb33);
> ssusb_phy_power_off(ssusb);
> ssusb_phy_exit(ssusb);
> @@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
> return PTR_ERR(ssusb->sys_clk);
> }
>
> + ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
> + if (IS_ERR(ssusb->ref_clk)) {
> + dev_err(dev, "failed to get ref clock\n");
> + return PTR_ERR(ssusb->ref_clk);
> + }
> +
That would break older dts bindings, right?
ref_ck must be optional for the code.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: mt8173: add reference clock for usb
From: Matthias Brugger @ 2017-01-19 12:23 UTC (permalink / raw)
To: Greg Kroah-Hartman, Chunfeng Yun
Cc: Mathias Nyman, Felipe Balbi, Rob Herring, Mark Rutland,
Ian Campbell, linux-kernel, linux-arm-kernel, linux-usb,
linux-mediatek, devicetree
In-Reply-To: <20170119093747.GA17213@kroah.com>
On 19/01/17 10:37, Greg Kroah-Hartman wrote:
> On Wed, Jan 18, 2017 at 02:08:25PM +0800, Chunfeng Yun wrote:
>> add 26M reference clock for ssusb and xhci nodes
>>
>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> This patch doesn't apply to my tree :(
>
This patch should go through my tree, but take into account my comment
on patch 3/6. From my point of view this series is not ready to be merged.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Rob Herring @ 2017-01-19 14:18 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-arm-kernel@lists.infradead.org, Thomas Petazzoni,
Marek Vasut, Mark Rutland, devicetree@vger.kernel.org,
Guochun Mao, Richard Weinberger, Russell King,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
Matthias Brugger, linux-mediatek, Cyrille Pitchen, Brian Norris,
David Woodhouse
In-Reply-To: <20170119091428.598eb987@bbrezillon>
On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> Hi Rob,
>
> On Wed, 18 Jan 2017 20:51:08 -0600
> Rob Herring <robh@kernel.org> wrote:
>
>> On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>> > Hello,
>> >
>> > On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
>> >
>> >> > > Rob, Mark, any opinion?
>> >> >
>> >>
>> >> Sigh, is how to do compatibles really not yet understood?
>> >
>> > Well, it seems like not everyone necessarily understands what is the
>> > best strategy to adopt (me included).
>> >
>> >> > I agree that a clarification would be good. There are really two
>> >> > options:
>> >> >
>> >> > 1. Have two compatible strings in the DT, the one that matches the
>> >> > exact SoC where the IP is found (first compatible string) and the
>> >> > one that matches some other SoC where the same IP is found (second
>> >> > compatible string). Originally, Linux only supports the second
>> >> > compatible string in its device driver, but if it happens that a
>> >> > difference is found between two IPs that we thought were the same,
>> >> > we can add support for the first compatible string in the driver,
>> >> > with a slightly different behavior.
>> >>
>> >> This. And no wildcards in the compatible string.
>> >
>> > OK. So it means that today we do something like:
>> >
>> > compatible = "baz,foo-12", "baz,foo-00";
>> >
>> > and support only baz,foo-00 in the driver. If tomorrow we discover
>> > that there is in fact a difference between the two IP blocks, we can
>> > add support for baz,foo-12 in the driver, and handle the differences.
>> >
>> > But then, the DT still contains:
>> >
>> > compatible = "baz,foo-12", "baz,foo-00";
>> >
>> > and therefore pretends that the IP block is compatible with
>> > "baz,foo-00" which is in fact *not* the case. It was a mistake to
>> > consider it as compatible. So we keep living with a DT that has
>> > incorrect information.
>>
>> I wouldn't say it's a mistake necessarily. The old compatible would
>> probably work to some extent. I'd assume it was tested to some level.
>> Or it could be other changes exposing a difference.
>
> 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
^ permalink raw reply
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