* Re: [PATCH v11 02/12] drm/mediatek: add helpers for coverting from the generic components
From: CK Hu @ 2017-01-16 1:09 UTC (permalink / raw)
To: YT Shen
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Philipp Zabel,
David Airlie, Rob Herring, Mark Rutland, Matthias Brugger,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, Daniel Kurtz
In-Reply-To: <1484117473-46644-3-git-send-email-yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_ovl'
> define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_rdma'
>
> Signed-off-by: YT Shen <yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Acked-by CK Hu <ck.hu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 15 +++++++++------
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 15 +++++++++------
> 2 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index c703102..ce2759f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -57,6 +57,11 @@ struct mtk_disp_ovl {
> struct drm_crtc *crtc;
> };
>
> +static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
> +{
> + return container_of(comp, struct mtk_disp_ovl, ddp_comp);
> +}
> +
> static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
> {
> struct mtk_disp_ovl *priv = dev_id;
> @@ -76,20 +81,18 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
> static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
> struct drm_crtc *crtc)
> {
> - struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
> - ddp_comp);
> + struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
>
> - priv->crtc = crtc;
> + ovl->crtc = crtc;
> writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
> writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
> }
>
> static void mtk_ovl_disable_vblank(struct mtk_ddp_comp *comp)
> {
> - struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
> - ddp_comp);
> + struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
>
> - priv->crtc = NULL;
> + ovl->crtc = NULL;
> writel_relaxed(0x0, comp->regs + DISP_REG_OVL_INTEN);
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 0df05f9..21eff6f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -49,6 +49,11 @@ struct mtk_disp_rdma {
> struct drm_crtc *crtc;
> };
>
> +static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> +{
> + return container_of(comp, struct mtk_disp_rdma, ddp_comp);
> +}
> +
> static irqreturn_t mtk_disp_rdma_irq_handler(int irq, void *dev_id)
> {
> struct mtk_disp_rdma *priv = dev_id;
> @@ -77,20 +82,18 @@ static void rdma_update_bits(struct mtk_ddp_comp *comp, unsigned int reg,
> static void mtk_rdma_enable_vblank(struct mtk_ddp_comp *comp,
> struct drm_crtc *crtc)
> {
> - struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
> - ddp_comp);
> + struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
>
> - priv->crtc = crtc;
> + rdma->crtc = crtc;
> rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT,
> RDMA_FRAME_END_INT);
> }
>
> static void mtk_rdma_disable_vblank(struct mtk_ddp_comp *comp)
> {
> - struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
> - ddp_comp);
> + struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
>
> - priv->crtc = NULL;
> + rdma->crtc = NULL;
> rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT, 0);
> }
>
--
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 v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-15 0:23 UTC (permalink / raw)
To: Boris Brezillon
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel
In-Reply-To: <20170114092958.022f2fc8@bbrezillon>
On 01/14/2017 09:29 AM, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 18:33:40 +0100
> Marek Vasut <marek.vasut@gmail.com> wrote:
>
>> On 01/13/2017 05:56 PM, Boris Brezillon wrote:
>>> On Fri, 13 Jan 2017 17:44:12 +0100
>>> Marek Vasut <marek.vasut@gmail.com> wrote:
>>>
>>>> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
>>>>> On Fri, 13 Jan 2017 17:13:55 +0100
>>>>> Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>
>>>>>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 13/01/17 15:17, Boris Brezillon wrote:
>>>>>>>> On Fri, 13 Jan 2017 15:13:29 +0800
>>>>>>>> Guochun Mao <guochun.mao@mediatek.com> wrote:
>>>>>>>>
>>>>>>>>> Add Mediatek nor flash node.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
>>>>>>>>> ---
>>>>>>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>>>>>>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>>>>>>>>> 2 files changed, 37 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>> index 082ca88..85e5ae8 100644
>>>>>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>> @@ -24,6 +24,31 @@
>>>>>>>>> };
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> +&nor_flash {
>>>>>>>>> + pinctrl-names = "default";
>>>>>>>>> + pinctrl-0 = <&nor_pins_default>;
>>>>>>>>> + status = "okay";
>>>>>>>>> + flash@0 {
>>>>>>>>> + compatible = "jedec,spi-nor";
>>>>>>>>> + reg = <0>;
>>>>>>>>> + };
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +&pio {
>>>>>>>>> + nor_pins_default: nor {
>>>>>>>>> + pins1 {
>>>>>>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>>>>>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>>>>>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>>>>>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>>>>>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>>>>>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>>>>>>>> + drive-strength = <MTK_DRIVE_4mA>;
>>>>>>>>> + bias-pull-up;
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> &uart0 {
>>>>>>>>> status = "okay";
>>>>>>>>> };
>>>>>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>> index bdf8954..1eefce4 100644
>>>>>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>> @@ -227,6 +227,18 @@
>>>>>>>>> status = "disabled";
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> + nor_flash: spi@11014000 {
>>>>>>>>> + compatible = "mediatek,mt2701-nor",
>>>>>>>>> + "mediatek,mt8173-nor";
>>>>>>>>
>>>>>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>>>>>>>> subset of the features supported by "mediatek,mt2701-nor"?
>>>>>>>>
>>>>>>>
>>>>>>> I think even if the ip block is the same, we should provide both
>>>>>>> bindings, just in case in the future we find out that mt2701 has some
>>>>>>> hidden bug, feature or bug-feature. This way even if we update the
>>>>>>> driver, we stay compatible with older device tree blobs in the wild.
>>>>>>>
>>>>>>> We can drop the mt2701-nor in the bindings definition if you want.
>>>>>
>>>>> Oh, sorry, I misunderstood. What I meant is that if you want to
>>>>> list/support all possible compatibles, maybe you should just put one
>>>>> compatible in your DT and patch your driver (+ binding doc) to define
>>>>> all of them.
>>>>
>>>> Uh, what ? I lost you here :-)
>
> I mean adding a new entry in the mtk_nor_of_ids table (in
> mtk-quadspi.c) so that the mediatek,mt2701-nor compatible string can be
> matched directly, and you won't need to define 2 compatible strings in
> your device tree.
But then you grow the table in the driver, is that what we want if we
can avoid that ?
>>>>
>>>>>> This exactly. We should have a DT compat in the form:
>>>>>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
>>>>>> Then if we find a problem in the future, we can match on the
>>>>>> "vendor,<soc>-block" and still support the old DTs.
>>>>>
>>>>> Not sure it's only in term of whose IP appeared first. My understanding
>>>>> is that it's a way to provide inheritance. For example:
>>>>>
>>>>> "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
>>>>>
>>>>> or
>>>>>
>>>>> "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
>>>>>
>>>>> BTW, which one is the oldest between mt8173 and mt2701? :-)
>>>>
>>>> And that's another thing and I agree with you, but I don't think that's
>>>> what we're discussing in this thread. But (!), OT, I think we should
>>>> codify the rules in Documentation/ . This discussion came up multiple
>>>> times recently.
>>>>
>>>> And my question still stands, what do we put into the DT here, IMO
>>>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
>>>
>>> I'd say
>>>
>>> compatible = "mediatek,mt8173-nor";
>>>
>>> because both compatible are referring to very specific IP version. It's
>>> not the same as
>>
>> But then you don't have the ability to handle a block in this particular
>> SoC in case there's a bug found in it in the future,
>> so IMO it should be:
>>
>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
>
> Sorry again, I meant
>
> compatible = "mediatek,mt2701-nor";
>
>>
>>> compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
>>
>> This doesn't look right, since here we add two new compatibles ...
>
> That was just an example to describe how compatible inheritance works
> (at least that's my understanding of it), it does not apply to this
> particular use case.
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 ...
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v2 5/6] arm: dts: mt2701: Add ethernet device node.
From: Sean Wang @ 2017-01-14 16:10 UTC (permalink / raw)
To: John Crispin
Cc: Erin Lo, Matthias Brugger, devicetree, srv_heupstream,
linux-kernel, linux-mediatek, linux-arm-kernel
In-Reply-To: <f9f5616f-a327-be4d-3d1d-4555e67d123a@phrozen.org>
Hi John,
the watchdog driver should just be the driver that includes
reset functions called from driver and then send reset signal
to abnormal hw..
however luckily ETHDMA_RST provided from watchdog is not required
and even actually the latest driver didn't refer to the property
no longer. So i will remove it from dtsi in the next version
Sean
On Sat, 2017-01-14 at 11:32 +0100, John Crispin wrote:
> Hi Erin,
>
> small comment inline
>
> On 13/01/2017 09:42, Erin Lo wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > Add ethernet device node for MT2701.
> >
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> > ---
> > arch/arm/boot/dts/mt2701-evb.dts | 40 ++++++++++++++++++++++++++++++++++++++++
> > arch/arm/boot/dts/mt2701.dtsi | 22 ++++++++++++++++++++++
> > 2 files changed, 62 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> > index a483798..40abd3b 100644
> > --- a/arch/arm/boot/dts/mt2701-evb.dts
> > +++ b/arch/arm/boot/dts/mt2701-evb.dts
> > @@ -28,7 +28,47 @@
> > status = "okay";
> > };
> >
> > +ð {
> > + mac-address = [00 00 00 00 00 00];
> > + status = "okay";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&gmac1_pins>;
> > + gmac1: mac@1 {
> > + compatible = "mediatek,eth-mac";
> > + reg = <1>;
> > + phy-handle = <&phy5>;
> > + };
> > +
> > + mdio-bus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + phy5: ethernet-phy@5 {
> > + reg = <5>;
> > + phy-mode = "rgmii-rxid";
> > + };
> > + };
> > +};
> > +
> > &pio {
> > + gmac1_pins: eth@0 {
> > + pins_eth {
> > + pinmux = <MT2701_PIN_275_MDC__FUNC_MDC>,
> > + <MT2701_PIN_276_MDIO__FUNC_MDIO>,
> > + <MT2701_PIN_262_G2_TXEN__FUNC_G2_TXEN>,
> > + <MT2701_PIN_263_G2_TXD3__FUNC_G2_TXD3>,
> > + <MT2701_PIN_264_G2_TXD2__FUNC_G2_TXD2>,
> > + <MT2701_PIN_265_G2_TXD1__FUNC_G2_TXD1>,
> > + <MT2701_PIN_266_G2_TXD0__FUNC_G2_TXD0>,
> > + <MT2701_PIN_267_G2_TXC__FUNC_G2_TXC>,
> > + <MT2701_PIN_268_G2_RXC__FUNC_G2_RXC>,
> > + <MT2701_PIN_269_G2_RXD0__FUNC_G2_RXD0>,
> > + <MT2701_PIN_270_G2_RXD1__FUNC_G2_RXD1>,
> > + <MT2701_PIN_271_G2_RXD2__FUNC_G2_RXD2>,
> > + <MT2701_PIN_272_G2_RXD3__FUNC_G2_RXD3>,
> > + <MT2701_PIN_274_G2_RXDV__FUNC_G2_RXDV>;
> > + };
> > + };
> > +
> > spi_pins_a: spi0@0 {
> > pins_spi {
> > pinmux = <MT2701_PIN_53_SPI0_CSN__FUNC_SPI0_CS>,
> > diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> > index 4f52019..3847f70 100644
> > --- a/arch/arm/boot/dts/mt2701.dtsi
> > +++ b/arch/arm/boot/dts/mt2701.dtsi
> > @@ -381,6 +381,28 @@
> > #clock-cells = <1>;
> > };
> >
> > + eth: ethernet@1b100000 {
> > + compatible = "mediatek,mt7623-eth";
> > + reg = <0 0x1b100000 0 0x20000>;
> > + interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 199 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
> > + <&apmixedsys CLK_APMIXED_TRGPLL>,
> > + <ðsys CLK_ETHSYS_ESW>,
> > + <ðsys CLK_ETHSYS_GP2>,
> > + <ðsys CLK_ETHSYS_GP1>;
> > + clock-names = "ethif", "trgpll", "esw", "gp2", "gp1";
> > + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
> > + resets = <&watchdog MT2701_TOPRGU_ETHDMA_RST>;
>
> are you sure this is correct ? on mt7623 we point the reset at ethsys
> and not the watchdog.
>
> John
>
> > + reset-names = "eth";
> > + mediatek,ethsys = <ðsys>;
> > + mediatek,pctl = <&syscfg_pctl_a>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "disabled";
> > + };
> > +
> > bdpsys: syscon@1c000000 {
> > compatible = "mediatek,mt2701-bdpsys", "syscon";
> > reg = <0 0x1c000000 0 0x1000>;
> >
^ permalink raw reply
* Re: [PATCH v2 5/6] arm: dts: mt2701: Add ethernet device node.
From: John Crispin @ 2017-01-14 10:32 UTC (permalink / raw)
To: Erin Lo, Matthias Brugger
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Sean Wang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484296978-18572-6-git-send-email-erin.lo-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Hi Erin,
small comment inline
On 13/01/2017 09:42, Erin Lo wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Add ethernet device node for MT2701.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Erin Lo <erin.lo-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/boot/dts/mt2701-evb.dts | 40 ++++++++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/mt2701.dtsi | 22 ++++++++++++++++++++++
> 2 files changed, 62 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> index a483798..40abd3b 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -28,7 +28,47 @@
> status = "okay";
> };
>
> +ð {
> + mac-address = [00 00 00 00 00 00];
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&gmac1_pins>;
> + gmac1: mac@1 {
> + compatible = "mediatek,eth-mac";
> + reg = <1>;
> + phy-handle = <&phy5>;
> + };
> +
> + mdio-bus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy5: ethernet-phy@5 {
> + reg = <5>;
> + phy-mode = "rgmii-rxid";
> + };
> + };
> +};
> +
> &pio {
> + gmac1_pins: eth@0 {
> + pins_eth {
> + pinmux = <MT2701_PIN_275_MDC__FUNC_MDC>,
> + <MT2701_PIN_276_MDIO__FUNC_MDIO>,
> + <MT2701_PIN_262_G2_TXEN__FUNC_G2_TXEN>,
> + <MT2701_PIN_263_G2_TXD3__FUNC_G2_TXD3>,
> + <MT2701_PIN_264_G2_TXD2__FUNC_G2_TXD2>,
> + <MT2701_PIN_265_G2_TXD1__FUNC_G2_TXD1>,
> + <MT2701_PIN_266_G2_TXD0__FUNC_G2_TXD0>,
> + <MT2701_PIN_267_G2_TXC__FUNC_G2_TXC>,
> + <MT2701_PIN_268_G2_RXC__FUNC_G2_RXC>,
> + <MT2701_PIN_269_G2_RXD0__FUNC_G2_RXD0>,
> + <MT2701_PIN_270_G2_RXD1__FUNC_G2_RXD1>,
> + <MT2701_PIN_271_G2_RXD2__FUNC_G2_RXD2>,
> + <MT2701_PIN_272_G2_RXD3__FUNC_G2_RXD3>,
> + <MT2701_PIN_274_G2_RXDV__FUNC_G2_RXDV>;
> + };
> + };
> +
> spi_pins_a: spi0@0 {
> pins_spi {
> pinmux = <MT2701_PIN_53_SPI0_CSN__FUNC_SPI0_CS>,
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 4f52019..3847f70 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -381,6 +381,28 @@
> #clock-cells = <1>;
> };
>
> + eth: ethernet@1b100000 {
> + compatible = "mediatek,mt7623-eth";
> + reg = <0 0x1b100000 0 0x20000>;
> + interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 199 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
> + <&apmixedsys CLK_APMIXED_TRGPLL>,
> + <ðsys CLK_ETHSYS_ESW>,
> + <ðsys CLK_ETHSYS_GP2>,
> + <ðsys CLK_ETHSYS_GP1>;
> + clock-names = "ethif", "trgpll", "esw", "gp2", "gp1";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
> + resets = <&watchdog MT2701_TOPRGU_ETHDMA_RST>;
are you sure this is correct ? on mt7623 we point the reset at ethsys
and not the watchdog.
John
> + reset-names = "eth";
> + mediatek,ethsys = <ðsys>;
> + mediatek,pctl = <&syscfg_pctl_a>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> bdpsys: syscon@1c000000 {
> compatible = "mediatek,mt2701-bdpsys", "syscon";
> reg = <0 0x1c000000 0 0x1000>;
>
--
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 v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-14 8:29 UTC (permalink / raw)
To: Marek Vasut
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0fafcd8d-cf99-de6b-728f-5e3637810b68-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 13 Jan 2017 18:33:40 +0100
Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 01/13/2017 05:56 PM, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 17:44:12 +0100
> > Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
> >>> On Fri, 13 Jan 2017 17:13:55 +0100
> >>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>
> >>>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
> >>>>>
> >>>>>
> >>>>> On 13/01/17 15:17, Boris Brezillon wrote:
> >>>>>> On Fri, 13 Jan 2017 15:13:29 +0800
> >>>>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> >>>>>>
> >>>>>>> Add Mediatek nor flash node.
> >>>>>>>
> >>>>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>>>>>> ---
> >>>>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
> >>>>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
> >>>>>>> 2 files changed, 37 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>>>> index 082ca88..85e5ae8 100644
> >>>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>>>> @@ -24,6 +24,31 @@
> >>>>>>> };
> >>>>>>> };
> >>>>>>>
> >>>>>>> +&nor_flash {
> >>>>>>> + pinctrl-names = "default";
> >>>>>>> + pinctrl-0 = <&nor_pins_default>;
> >>>>>>> + status = "okay";
> >>>>>>> + flash@0 {
> >>>>>>> + compatible = "jedec,spi-nor";
> >>>>>>> + reg = <0>;
> >>>>>>> + };
> >>>>>>> +};
> >>>>>>> +
> >>>>>>> +&pio {
> >>>>>>> + nor_pins_default: nor {
> >>>>>>> + pins1 {
> >>>>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> >>>>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> >>>>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> >>>>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> >>>>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> >>>>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> >>>>>>> + drive-strength = <MTK_DRIVE_4mA>;
> >>>>>>> + bias-pull-up;
> >>>>>>> + };
> >>>>>>> + };
> >>>>>>> +};
> >>>>>>> +
> >>>>>>> &uart0 {
> >>>>>>> status = "okay";
> >>>>>>> };
> >>>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
> >>>>>>> b/arch/arm/boot/dts/mt2701.dtsi
> >>>>>>> index bdf8954..1eefce4 100644
> >>>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
> >>>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
> >>>>>>> @@ -227,6 +227,18 @@
> >>>>>>> status = "disabled";
> >>>>>>> };
> >>>>>>>
> >>>>>>> + nor_flash: spi@11014000 {
> >>>>>>> + compatible = "mediatek,mt2701-nor",
> >>>>>>> + "mediatek,mt8173-nor";
> >>>>>>
> >>>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
> >>>>>> subset of the features supported by "mediatek,mt2701-nor"?
> >>>>>>
> >>>>>
> >>>>> I think even if the ip block is the same, we should provide both
> >>>>> bindings, just in case in the future we find out that mt2701 has some
> >>>>> hidden bug, feature or bug-feature. This way even if we update the
> >>>>> driver, we stay compatible with older device tree blobs in the wild.
> >>>>>
> >>>>> We can drop the mt2701-nor in the bindings definition if you want.
> >>>
> >>> Oh, sorry, I misunderstood. What I meant is that if you want to
> >>> list/support all possible compatibles, maybe you should just put one
> >>> compatible in your DT and patch your driver (+ binding doc) to define
> >>> all of them.
> >>
> >> Uh, what ? I lost you here :-)
I mean adding a new entry in the mtk_nor_of_ids table (in
mtk-quadspi.c) so that the mediatek,mt2701-nor compatible string can be
matched directly, and you won't need to define 2 compatible strings in
your device tree.
> >>
> >>>> This exactly. We should have a DT compat in the form:
> >>>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
> >>>> Then if we find a problem in the future, we can match on the
> >>>> "vendor,<soc>-block" and still support the old DTs.
> >>>
> >>> Not sure it's only in term of whose IP appeared first. My understanding
> >>> is that it's a way to provide inheritance. For example:
> >>>
> >>> "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
> >>>
> >>> or
> >>>
> >>> "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
> >>>
> >>> BTW, which one is the oldest between mt8173 and mt2701? :-)
> >>
> >> And that's another thing and I agree with you, but I don't think that's
> >> what we're discussing in this thread. But (!), OT, I think we should
> >> codify the rules in Documentation/ . This discussion came up multiple
> >> times recently.
> >>
> >> And my question still stands, what do we put into the DT here, IMO
> >> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
> >
> > I'd say
> >
> > compatible = "mediatek,mt8173-nor";
> >
> > because both compatible are referring to very specific IP version. It's
> > not the same as
>
> But then you don't have the ability to handle a block in this particular
> SoC in case there's a bug found in it in the future,
> so IMO it should be:
>
> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
Sorry again, I meant
compatible = "mediatek,mt2701-nor";
>
> > compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
>
> This doesn't look right, since here we add two new compatibles ...
That was just an example to describe how compatible inheritance works
(at least that's my understanding of it), it does not apply to this
particular use case.
>
> > where you clearly have a generic compatible which is overloaded by a
> > specific one.
> >
> > But anyway, I'm not the one taking the decision here, let's wait for DT
> > maintainers reviews.
> >
> >> and what goes into the binding document ? I guess both too ?
> >
> > If both exist, they should be both documented.
> >
>
>
--
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 v11 01/12] dt-bindings: display: mediatek: update supported chips
From: Rob Herring @ 2017-01-13 17:37 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Matthias Brugger, linux-mediatek,
yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-2-git-send-email-yt.shen@mediatek.com>
On Wed, Jan 11, 2017 at 02:51:02PM +0800, YT Shen wrote:
> Add decriptions about supported chips, including MT2701 & MT8173
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 ++
> 2 files changed, 4 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
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: Marek Vasut @ 2017-01-13 17:33 UTC (permalink / raw)
To: Boris Brezillon
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170113175628.1793f433@bbrezillon>
On 01/13/2017 05:56 PM, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 17:44:12 +0100
> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
>>> On Fri, 13 Jan 2017 17:13:55 +0100
>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
>>>>>
>>>>>
>>>>> On 13/01/17 15:17, Boris Brezillon wrote:
>>>>>> On Fri, 13 Jan 2017 15:13:29 +0800
>>>>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>>>>>
>>>>>>> Add Mediatek nor flash node.
>>>>>>>
>>>>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>>>>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>>>>>>> 2 files changed, 37 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> index 082ca88..85e5ae8 100644
>>>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> @@ -24,6 +24,31 @@
>>>>>>> };
>>>>>>> };
>>>>>>>
>>>>>>> +&nor_flash {
>>>>>>> + pinctrl-names = "default";
>>>>>>> + pinctrl-0 = <&nor_pins_default>;
>>>>>>> + status = "okay";
>>>>>>> + flash@0 {
>>>>>>> + compatible = "jedec,spi-nor";
>>>>>>> + reg = <0>;
>>>>>>> + };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&pio {
>>>>>>> + nor_pins_default: nor {
>>>>>>> + pins1 {
>>>>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>>>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>>>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>>>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>>>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>>>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>>>>>> + drive-strength = <MTK_DRIVE_4mA>;
>>>>>>> + bias-pull-up;
>>>>>>> + };
>>>>>>> + };
>>>>>>> +};
>>>>>>> +
>>>>>>> &uart0 {
>>>>>>> status = "okay";
>>>>>>> };
>>>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> index bdf8954..1eefce4 100644
>>>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> @@ -227,6 +227,18 @@
>>>>>>> status = "disabled";
>>>>>>> };
>>>>>>>
>>>>>>> + nor_flash: spi@11014000 {
>>>>>>> + compatible = "mediatek,mt2701-nor",
>>>>>>> + "mediatek,mt8173-nor";
>>>>>>
>>>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>>>>>> subset of the features supported by "mediatek,mt2701-nor"?
>>>>>>
>>>>>
>>>>> I think even if the ip block is the same, we should provide both
>>>>> bindings, just in case in the future we find out that mt2701 has some
>>>>> hidden bug, feature or bug-feature. This way even if we update the
>>>>> driver, we stay compatible with older device tree blobs in the wild.
>>>>>
>>>>> We can drop the mt2701-nor in the bindings definition if you want.
>>>
>>> Oh, sorry, I misunderstood. What I meant is that if you want to
>>> list/support all possible compatibles, maybe you should just put one
>>> compatible in your DT and patch your driver (+ binding doc) to define
>>> all of them.
>>
>> Uh, what ? I lost you here :-)
>>
>>>> This exactly. We should have a DT compat in the form:
>>>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
>>>> Then if we find a problem in the future, we can match on the
>>>> "vendor,<soc>-block" and still support the old DTs.
>>>
>>> Not sure it's only in term of whose IP appeared first. My understanding
>>> is that it's a way to provide inheritance. For example:
>>>
>>> "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
>>>
>>> or
>>>
>>> "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
>>>
>>> BTW, which one is the oldest between mt8173 and mt2701? :-)
>>
>> And that's another thing and I agree with you, but I don't think that's
>> what we're discussing in this thread. But (!), OT, I think we should
>> codify the rules in Documentation/ . This discussion came up multiple
>> times recently.
>>
>> And my question still stands, what do we put into the DT here, IMO
>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
>
> I'd say
>
> compatible = "mediatek,mt8173-nor";
>
> because both compatible are referring to very specific IP version. It's
> not the same as
But then you don't have the ability to handle a block in this particular
SoC in case there's a bug found in it in the future,
so IMO it should be:
compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
> compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
This doesn't look right, since here we add two new compatibles ...
> where you clearly have a generic compatible which is overloaded by a
> specific one.
>
> But anyway, I'm not the one taking the decision here, let's wait for DT
> maintainers reviews.
>
>> and what goes into the binding document ? I guess both too ?
>
> If both exist, they should be both documented.
>
--
Best regards,
Marek Vasut
--
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 v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-13 16:56 UTC (permalink / raw)
To: Marek Vasut
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <86c997be-f500-eaa1-3ba5-d21cff6223b7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 13 Jan 2017 17:44:12 +0100
Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 17:13:55 +0100
> > Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
> >>>
> >>>
> >>> On 13/01/17 15:17, Boris Brezillon wrote:
> >>>> On Fri, 13 Jan 2017 15:13:29 +0800
> >>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> >>>>
> >>>>> Add Mediatek nor flash node.
> >>>>>
> >>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>>>> ---
> >>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
> >>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
> >>>>> 2 files changed, 37 insertions(+)
> >>>>>
> >>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> index 082ca88..85e5ae8 100644
> >>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> @@ -24,6 +24,31 @@
> >>>>> };
> >>>>> };
> >>>>>
> >>>>> +&nor_flash {
> >>>>> + pinctrl-names = "default";
> >>>>> + pinctrl-0 = <&nor_pins_default>;
> >>>>> + status = "okay";
> >>>>> + flash@0 {
> >>>>> + compatible = "jedec,spi-nor";
> >>>>> + reg = <0>;
> >>>>> + };
> >>>>> +};
> >>>>> +
> >>>>> +&pio {
> >>>>> + nor_pins_default: nor {
> >>>>> + pins1 {
> >>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> >>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> >>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> >>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> >>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> >>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> >>>>> + drive-strength = <MTK_DRIVE_4mA>;
> >>>>> + bias-pull-up;
> >>>>> + };
> >>>>> + };
> >>>>> +};
> >>>>> +
> >>>>> &uart0 {
> >>>>> status = "okay";
> >>>>> };
> >>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
> >>>>> b/arch/arm/boot/dts/mt2701.dtsi
> >>>>> index bdf8954..1eefce4 100644
> >>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
> >>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
> >>>>> @@ -227,6 +227,18 @@
> >>>>> status = "disabled";
> >>>>> };
> >>>>>
> >>>>> + nor_flash: spi@11014000 {
> >>>>> + compatible = "mediatek,mt2701-nor",
> >>>>> + "mediatek,mt8173-nor";
> >>>>
> >>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
> >>>> subset of the features supported by "mediatek,mt2701-nor"?
> >>>>
> >>>
> >>> I think even if the ip block is the same, we should provide both
> >>> bindings, just in case in the future we find out that mt2701 has some
> >>> hidden bug, feature or bug-feature. This way even if we update the
> >>> driver, we stay compatible with older device tree blobs in the wild.
> >>>
> >>> We can drop the mt2701-nor in the bindings definition if you want.
> >
> > Oh, sorry, I misunderstood. What I meant is that if you want to
> > list/support all possible compatibles, maybe you should just put one
> > compatible in your DT and patch your driver (+ binding doc) to define
> > all of them.
>
> Uh, what ? I lost you here :-)
>
> >> This exactly. We should have a DT compat in the form:
> >> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
> >> Then if we find a problem in the future, we can match on the
> >> "vendor,<soc>-block" and still support the old DTs.
> >
> > Not sure it's only in term of whose IP appeared first. My understanding
> > is that it's a way to provide inheritance. For example:
> >
> > "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
> >
> > or
> >
> > "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
> >
> > BTW, which one is the oldest between mt8173 and mt2701? :-)
>
> And that's another thing and I agree with you, but I don't think that's
> what we're discussing in this thread. But (!), OT, I think we should
> codify the rules in Documentation/ . This discussion came up multiple
> times recently.
>
> And my question still stands, what do we put into the DT here, IMO
> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
I'd say
compatible = "mediatek,mt8173-nor";
because both compatible are referring to very specific IP version. It's
not the same as
compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
where you clearly have a generic compatible which is overloaded by a
specific one.
But anyway, I'm not the one taking the decision here, let's wait for DT
maintainers reviews.
> and what goes into the binding document ? I guess both too ?
If both exist, they should be both documented.
--
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 v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-13 16:44 UTC (permalink / raw)
To: Boris Brezillon
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170113172825.75d545a3@bbrezillon>
On 01/13/2017 05:28 PM, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 17:13:55 +0100
> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
>>>
>>>
>>> On 13/01/17 15:17, Boris Brezillon wrote:
>>>> On Fri, 13 Jan 2017 15:13:29 +0800
>>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>>>
>>>>> Add Mediatek nor flash node.
>>>>>
>>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>>>>> 2 files changed, 37 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>>>> index 082ca88..85e5ae8 100644
>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>>>> @@ -24,6 +24,31 @@
>>>>> };
>>>>> };
>>>>>
>>>>> +&nor_flash {
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&nor_pins_default>;
>>>>> + status = "okay";
>>>>> + flash@0 {
>>>>> + compatible = "jedec,spi-nor";
>>>>> + reg = <0>;
>>>>> + };
>>>>> +};
>>>>> +
>>>>> +&pio {
>>>>> + nor_pins_default: nor {
>>>>> + pins1 {
>>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>>>> + drive-strength = <MTK_DRIVE_4mA>;
>>>>> + bias-pull-up;
>>>>> + };
>>>>> + };
>>>>> +};
>>>>> +
>>>>> &uart0 {
>>>>> status = "okay";
>>>>> };
>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>> index bdf8954..1eefce4 100644
>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>> @@ -227,6 +227,18 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + nor_flash: spi@11014000 {
>>>>> + compatible = "mediatek,mt2701-nor",
>>>>> + "mediatek,mt8173-nor";
>>>>
>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>>>> subset of the features supported by "mediatek,mt2701-nor"?
>>>>
>>>
>>> I think even if the ip block is the same, we should provide both
>>> bindings, just in case in the future we find out that mt2701 has some
>>> hidden bug, feature or bug-feature. This way even if we update the
>>> driver, we stay compatible with older device tree blobs in the wild.
>>>
>>> We can drop the mt2701-nor in the bindings definition if you want.
>
> Oh, sorry, I misunderstood. What I meant is that if you want to
> list/support all possible compatibles, maybe you should just put one
> compatible in your DT and patch your driver (+ binding doc) to define
> all of them.
Uh, what ? I lost you here :-)
>> This exactly. We should have a DT compat in the form:
>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
>> Then if we find a problem in the future, we can match on the
>> "vendor,<soc>-block" and still support the old DTs.
>
> Not sure it's only in term of whose IP appeared first. My understanding
> is that it's a way to provide inheritance. For example:
>
> "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
>
> or
>
> "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
>
> BTW, which one is the oldest between mt8173 and mt2701? :-)
And that's another thing and I agree with you, but I don't think that's
what we're discussing in this thread. But (!), OT, I think we should
codify the rules in Documentation/ . This discussion came up multiple
times recently.
And my question still stands, what do we put into the DT here, IMO
compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
and what goes into the binding document ? I guess both too ?
--
Best regards,
Marek Vasut
--
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 v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-13 16:28 UTC (permalink / raw)
To: Marek Vasut
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel
In-Reply-To: <b850b751-1d8d-0053-cf1f-d5314542e5c3@gmail.com>
On Fri, 13 Jan 2017 17:13:55 +0100
Marek Vasut <marek.vasut@gmail.com> wrote:
> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
> >
> >
> > On 13/01/17 15:17, Boris Brezillon wrote:
> >> On Fri, 13 Jan 2017 15:13:29 +0800
> >> Guochun Mao <guochun.mao@mediatek.com> wrote:
> >>
> >>> Add Mediatek nor flash node.
> >>>
> >>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> >>> ---
> >>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
> >>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
> >>> 2 files changed, 37 insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
> >>> b/arch/arm/boot/dts/mt2701-evb.dts
> >>> index 082ca88..85e5ae8 100644
> >>> --- a/arch/arm/boot/dts/mt2701-evb.dts
> >>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> >>> @@ -24,6 +24,31 @@
> >>> };
> >>> };
> >>>
> >>> +&nor_flash {
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&nor_pins_default>;
> >>> + status = "okay";
> >>> + flash@0 {
> >>> + compatible = "jedec,spi-nor";
> >>> + reg = <0>;
> >>> + };
> >>> +};
> >>> +
> >>> +&pio {
> >>> + nor_pins_default: nor {
> >>> + pins1 {
> >>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> >>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> >>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> >>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> >>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> >>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> >>> + drive-strength = <MTK_DRIVE_4mA>;
> >>> + bias-pull-up;
> >>> + };
> >>> + };
> >>> +};
> >>> +
> >>> &uart0 {
> >>> status = "okay";
> >>> };
> >>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
> >>> b/arch/arm/boot/dts/mt2701.dtsi
> >>> index bdf8954..1eefce4 100644
> >>> --- a/arch/arm/boot/dts/mt2701.dtsi
> >>> +++ b/arch/arm/boot/dts/mt2701.dtsi
> >>> @@ -227,6 +227,18 @@
> >>> status = "disabled";
> >>> };
> >>>
> >>> + nor_flash: spi@11014000 {
> >>> + compatible = "mediatek,mt2701-nor",
> >>> + "mediatek,mt8173-nor";
> >>
> >> Why define both here? Is "mediatek,mt8173-nor" really providing a
> >> subset of the features supported by "mediatek,mt2701-nor"?
> >>
> >
> > I think even if the ip block is the same, we should provide both
> > bindings, just in case in the future we find out that mt2701 has some
> > hidden bug, feature or bug-feature. This way even if we update the
> > driver, we stay compatible with older device tree blobs in the wild.
> >
> > We can drop the mt2701-nor in the bindings definition if you want.
Oh, sorry, I misunderstood. What I meant is that if you want to
list/support all possible compatibles, maybe you should just put one
compatible in your DT and patch your driver (+ binding doc) to define
all of them.
>
> This exactly. We should have a DT compat in the form:
> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
> Then if we find a problem in the future, we can match on the
> "vendor,<soc>-block" and still support the old DTs.
Not sure it's only in term of whose IP appeared first. My understanding
is that it's a way to provide inheritance. For example:
"<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
or
"<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
BTW, which one is the oldest between mt8173 and mt2701? :-)
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-13 16:13 UTC (permalink / raw)
To: Matthias Brugger, Boris Brezillon, Guochun Mao
Cc: David Woodhouse, Brian Norris, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Russell King,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d7b866ad-5b2f-62d3-3aa3-6fa42803d625-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 01/13/2017 04:12 PM, Matthias Brugger wrote:
>
>
> On 13/01/17 15:17, Boris Brezillon wrote:
>> On Fri, 13 Jan 2017 15:13:29 +0800
>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>
>>> Add Mediatek nor flash node.
>>>
>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>> ---
>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>>> 2 files changed, 37 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>> index 082ca88..85e5ae8 100644
>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>> @@ -24,6 +24,31 @@
>>> };
>>> };
>>>
>>> +&nor_flash {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&nor_pins_default>;
>>> + status = "okay";
>>> + flash@0 {
>>> + compatible = "jedec,spi-nor";
>>> + reg = <0>;
>>> + };
>>> +};
>>> +
>>> +&pio {
>>> + nor_pins_default: nor {
>>> + pins1 {
>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>> + drive-strength = <MTK_DRIVE_4mA>;
>>> + bias-pull-up;
>>> + };
>>> + };
>>> +};
>>> +
>>> &uart0 {
>>> status = "okay";
>>> };
>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>> b/arch/arm/boot/dts/mt2701.dtsi
>>> index bdf8954..1eefce4 100644
>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>> @@ -227,6 +227,18 @@
>>> status = "disabled";
>>> };
>>>
>>> + nor_flash: spi@11014000 {
>>> + compatible = "mediatek,mt2701-nor",
>>> + "mediatek,mt8173-nor";
>>
>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>> subset of the features supported by "mediatek,mt2701-nor"?
>>
>
> I think even if the ip block is the same, we should provide both
> bindings, just in case in the future we find out that mt2701 has some
> hidden bug, feature or bug-feature. This way even if we update the
> driver, we stay compatible with older device tree blobs in the wild.
>
> We can drop the mt2701-nor in the bindings definition if you want.
This exactly. We should have a DT compat in the form:
compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
Then if we find a problem in the future, we can match on the
"vendor,<soc>-block" and still support the old DTs.
The question is, does the "vendor,<soc>-block" go into the binding
document as well or do we only have "vendor,<oldest-compat-soc>-block"
there ?
--
Best regards,
Marek Vasut
--
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] arm64: dts: mt8173: Fix cpu_thermal cooling-maps contributions
From: Matthias Brugger @ 2017-01-13 15:36 UTC (permalink / raw)
To: Daniel Kurtz
Cc: Dawei Chien, Javi Merino, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Hans Verkuil, Mauro Carvalho Chehab,
Tiffany Lin, CK Hu, Andrew-CT Chen, Sascha Hauer, Minghsiu Tsai,
Yong Wu, Chunfeng Yun,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)
In-Reply-To: <20170113023006.150845-1-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
On 13/01/17 03:30, Daniel Kurtz wrote:
> According to [0], the contribution field for each cooling-device express
> their relative power efficiency. Higher weights express higher power
> efficiency. Weighting is relative such that if each cooling device has a
> weight of 1 they are considered equal. This is particularly useful in
> heterogeneous systems where two cooling devices may perform the same kind
> of compute, but with different efficiency.
>
> [0] Documentation/thermal/power_allocator.txt
>
> According to Mediatek IC designer, the power efficiency ratio between the
> LITTLE core cluster (cooling-device cpu0) and big core cluster
> (cooling-device cpu1) is around 3:1 (3072:1024).
>
> Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
applied, thanks.
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 12e702771f5c..9a3b0d20f7a8 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -182,12 +182,12 @@
> map@0 {
> trip = <&target>;
> cooling-device = <&cpu0 0 0>;
> - contribution = <1024>;
> + contribution = <3072>;
> };
> map@1 {
> trip = <&target>;
> cooling-device = <&cpu2 0 0>;
> - contribution = <2048>;
> + contribution = <1024>;
> };
> };
> };
>
--
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 v5] arm64: dts: mt8173: add mmsel clocks for 4K support
From: Matthias Brugger @ 2017-01-13 15:32 UTC (permalink / raw)
To: Daniel Kurtz, Bibby Hsieh
Cc: Mark Rutland, open list:OPEN FIRMWARE AND...,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
moderated list:ARM/Mediatek SoC support, Rob Herring, Pawel Moll,
Ian Campbell, Kumar Gala, Catalin Marinas, Will Deacon,
Yingjoe Chen, Sascha Hauer, James Liao, Lorenzo Pieralisi,
YH Huang
In-Reply-To: <CAGS+omAZvHmSz6bJcvisC1LZgxwbd-HzvYMDrHXzfkY3mZZEsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/01/17 05:50, Daniel Kurtz wrote:
> Hi Matthias,
>
> (Trying again to send plain text email)...
>
> On Thu, Aug 4, 2016 at 10:57 AM, Bibby Hsieh <bibby.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>> To support HDMI 4K resolution, mmsys need clcok
>> mm_sel to be 400MHz.
>>
>> The board .dts file should override the clock rate
>> property with the higher VENCPLL frequency the board
>> supports HDMI 4K resolution.
>>
>> Signed-off-by: Bibby Hsieh <bibby.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Reviewed-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
Applied to v4.10-next/dts
Thanks
>
> It looks like this patch was lost. It is actually a prerequisite for
> MTK 4k HDMI support, which already landed in v4.9.
>
> See the email thread entitled:
> [PATCH v5 0/3] MT8173 HDMI 4K support <https://lkml.org/lkml/2016/9/28/893>
>
> Or these three:
>
> 0d2200794f0a drm/mediatek: modify the factor to make the pll_rate set
> in the 1G-2G range
> 968253bd7caa drm/mediatek: enhance the HDMI driving current
> d542b7c473f0 drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
>
> -Dan
>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 78529e4..c3f32f3 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -690,6 +690,8 @@
>> compatible = "mediatek,mt8173-mmsys", "syscon";
>> reg = <0 0x14000000 0 0x1000>;
>> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
>> + assigned-clocks = <&topckgen CLK_TOP_MM_SEL>;
>> + assigned-clock-rates = <400000000>;
>> #clock-cells = <1>;
>> };
>>
>> --
>> 1.7.9.5
>>
--
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 4/6] arm: dts: mt2701: Add auxadc device node.
From: Matthias Brugger @ 2017-01-13 15:29 UTC (permalink / raw)
To: Erin Lo
Cc: srv_heupstream, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, Zhiyong Tao
In-Reply-To: <1484296978-18572-5-git-send-email-erin.lo@mediatek.com>
On 13/01/17 09:42, Erin Lo wrote:
> From: Zhiyong Tao <zhiyong.tao@mediatek.com>
>
> Add auxadc device node for MT2701.
>
> Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701-evb.dts | 4 ++++
> arch/arm/boot/dts/mt2701.dtsi | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
Applied to v4.10-next/dts32
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> index 879f1eb..a483798 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -24,6 +24,10 @@
> };
> };
>
> +&auxadc {
> + status = "okay";
> +};
> +
> &pio {
> spi_pins_a: spi0@0 {
> pins_spi {
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 1182c43..4f52019 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -208,6 +208,15 @@
> <0 0x10216000 0 0x2000>;
> };
>
> + auxadc: adc@11001000 {
> + compatible = "mediatek,mt2701-auxadc";
> + reg = <0 0x11001000 0 0x1000>;
> + clocks = <&pericfg CLK_PERI_AUXADC>;
> + clock-names = "main";
> + #io-channel-cells = <1>;
> + status = "disabled";
> + };
> +
> uart0: serial@11002000 {
> compatible = "mediatek,mt2701-uart",
> "mediatek,mt6577-uart";
>
^ permalink raw reply
* Re: [PATCH v2 3/6] arm: dts: mt2701: Add nand device node
From: Matthias Brugger @ 2017-01-13 15:29 UTC (permalink / raw)
To: Erin Lo
Cc: srv_heupstream, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, Xiaolei Li
In-Reply-To: <1484296978-18572-4-git-send-email-erin.lo@mediatek.com>
On 13/01/17 09:42, Erin Lo wrote:
> From: Xiaolei Li <xiaolei.li@mediatek.com>
>
> Add mt2701 nand device node, include nfi and bch ecc.
>
> Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
Applied to v4.10-next/dts32
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 87be52c..1182c43 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -261,6 +261,28 @@
> status = "disabled";
> };
>
> + nandc: nfi@1100d000 {
> + compatible = "mediatek,mt2701-nfc";
> + reg = <0 0x1100d000 0 0x1000>;
> + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&pericfg CLK_PERI_NFI>,
> + <&pericfg CLK_PERI_NFI_PAD>;
> + clock-names = "nfi_clk", "pad_clk";
> + status = "disabled";
> + ecc-engine = <&bch>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + bch: ecc@1100e000 {
> + compatible = "mediatek,mt2701-ecc";
> + reg = <0 0x1100e000 0 0x1000>;
> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&pericfg CLK_PERI_NFI_ECC>;
> + clock-names = "nfiecc_clk";
> + status = "disabled";
> + };
> +
> spi1: spi@11016000 {
> compatible = "mediatek,mt2701-spi";
> #address-cells = <1>;
>
^ permalink raw reply
* Re: [PATCH v2 1/6] arm: dts: mt2701: Add spi device node
From: Matthias Brugger @ 2017-01-13 15:29 UTC (permalink / raw)
To: Erin Lo
Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Leilk Liu
In-Reply-To: <1484296978-18572-2-git-send-email-erin.lo-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On 13/01/17 09:42, Erin Lo wrote:
> From: Leilk Liu <leilk.liu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Add spi device node for MT2701.
>
> Signed-off-by: Leilk Liu <leilk.liu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Erin Lo <erin.lo-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/boot/dts/mt2701-evb.dts | 50 ++++++++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/mt2701.dtsi | 39 +++++++++++++++++++++++++++++++
> 2 files changed, 89 insertions(+)
>
Applied to v4.10-next/dts32
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> index 082ca88..879f1eb 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -24,6 +24,56 @@
> };
> };
>
> +&pio {
> + spi_pins_a: spi0@0 {
> + pins_spi {
> + pinmux = <MT2701_PIN_53_SPI0_CSN__FUNC_SPI0_CS>,
> + <MT2701_PIN_54_SPI0_CK__FUNC_SPI0_CK>,
> + <MT2701_PIN_55_SPI0_MI__FUNC_SPI0_MI>,
> + <MT2701_PIN_56_SPI0_MO__FUNC_SPI0_MO>;
> + bias-disable;
> + };
> + };
> +
> + spi_pins_b: spi1@0 {
> + pins_spi {
> + pinmux = <MT2701_PIN_7_SPI1_CSN__FUNC_SPI1_CS>,
> + <MT2701_PIN_8_SPI1_MI__FUNC_SPI1_MI>,
> + <MT2701_PIN_9_SPI1_MO__FUNC_SPI1_MO>,
> + <MT2701_PIN_199_SPI1_CLK__FUNC_SPI1_CK>;
> + bias-disable;
> + };
> + };
> +
> + spi_pins_c: spi2@0 {
> + pins_spi {
> + pinmux = <MT2701_PIN_101_SPI2_CSN__FUNC_SPI2_CS>,
> + <MT2701_PIN_102_SPI2_MI__FUNC_SPI2_MI>,
> + <MT2701_PIN_103_SPI2_MO__FUNC_SPI2_MO>,
> + <MT2701_PIN_104_SPI2_CLK__FUNC_SPI2_CK>;
> + bias-disable;
> + };
> + };
> +};
> +
> +&spi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_pins_a>;
> + status = "disabled";
> +};
> +
> +&spi1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_pins_b>;
> + status = "disabled";
> +};
> +
> +&spi2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_pins_c>;
> + status = "disabled";
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index bdf8954..eb4c6fd 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -227,6 +227,45 @@
> status = "disabled";
> };
>
> + spi0: spi@1100a000 {
> + compatible = "mediatek,mt2701-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x1100a000 0 0x100>;
> + interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
> + <&topckgen CLK_TOP_SPI0_SEL>,
> + <&pericfg CLK_PERI_SPI0>;
> + clock-names = "parent-clk", "sel-clk", "spi-clk";
> + status = "disabled";
> + };
> +
> + spi1: spi@11016000 {
> + compatible = "mediatek,mt2701-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x11016000 0 0x100>;
> + interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
> + <&topckgen CLK_TOP_SPI1_SEL>,
> + <&pericfg CLK_PERI_SPI1>;
> + clock-names = "parent-clk", "sel-clk", "spi-clk";
> + status = "disabled";
> + };
> +
> + spi2: spi@11017000 {
> + compatible = "mediatek,mt2701-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x11017000 0 0x1000>;
> + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
> + <&topckgen CLK_TOP_SPI2_SEL>,
> + <&pericfg CLK_PERI_SPI2>;
> + clock-names = "parent-clk", "sel-clk", "spi-clk";
> + status = "disabled";
> + };
> +
> mmsys: syscon@14000000 {
> compatible = "mediatek,mt2701-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
>
--
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 6/6] arm: dts: mt2701: Add thermal device node.
From: Matthias Brugger @ 2017-01-13 15:27 UTC (permalink / raw)
To: Erin Lo
Cc: srv_heupstream, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, Dawei Chien
In-Reply-To: <1484296978-18572-7-git-send-email-erin.lo@mediatek.com>
On 13/01/17 09:42, Erin Lo wrote:
> From: Dawei Chien <dawei.chien@mediatek.com>
>
> Add thermal controller device nodes for MT2701.
>
> Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 3847f70..c43d5f8 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -89,6 +89,36 @@
> clock-output-names = "rtc32k";
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
> +
> + thermal-sensors = <&thermal 0>;
> + sustainable-power = <1000>;
> +
> + trips {
> + threshold: trip-point@0 {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + target: trip-point@1 {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit: cpu_crit@0 {
> + temperature = <115000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupt-parent = <&gic>;
> @@ -270,6 +300,19 @@
> status = "disabled";
> };
>
> + thermal: thermal@1100b000 {
> + #thermal-sensor-cells = <0>;
> + compatible = "mediatek,mt2701-thermal";
> + reg = <0 0x1100b000 0 0x1000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> + clock-names = "therm", "auxadc";
> + resets = <&pericfg 0x10>;
should be MT2701_PERI_AUXADC_SW_RST, right?
> + reset-names = "therm";
> + mediatek,auxadc = <&auxadc>;
> + mediatek,apmixedsys = <&apmixedsys>;
> + };
> +
> nandc: nfi@1100d000 {
> compatible = "mediatek,mt2701-nfc";
> reg = <0 0x1100d000 0 0x1000>;
>
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-13 15:21 UTC (permalink / raw)
To: Matthias Brugger
Cc: Guochun Mao, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel
In-Reply-To: <d7b866ad-5b2f-62d3-3aa3-6fa42803d625@gmail.com>
On Fri, 13 Jan 2017 16:12:20 +0100
Matthias Brugger <matthias.bgg@gmail.com> wrote:
> On 13/01/17 15:17, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 15:13:29 +0800
> > Guochun Mao <guochun.mao@mediatek.com> wrote:
> >
> >> Add Mediatek nor flash node.
> >>
> >> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> >> ---
> >> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
> >> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
> >> 2 files changed, 37 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> >> index 082ca88..85e5ae8 100644
> >> --- a/arch/arm/boot/dts/mt2701-evb.dts
> >> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> >> @@ -24,6 +24,31 @@
> >> };
> >> };
> >>
> >> +&nor_flash {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&nor_pins_default>;
> >> + status = "okay";
> >> + flash@0 {
> >> + compatible = "jedec,spi-nor";
> >> + reg = <0>;
> >> + };
> >> +};
> >> +
> >> +&pio {
> >> + nor_pins_default: nor {
> >> + pins1 {
> >> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> >> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> >> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> >> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> >> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> >> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> >> + drive-strength = <MTK_DRIVE_4mA>;
> >> + bias-pull-up;
> >> + };
> >> + };
> >> +};
> >> +
> >> &uart0 {
> >> status = "okay";
> >> };
> >> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> >> index bdf8954..1eefce4 100644
> >> --- a/arch/arm/boot/dts/mt2701.dtsi
> >> +++ b/arch/arm/boot/dts/mt2701.dtsi
> >> @@ -227,6 +227,18 @@
> >> status = "disabled";
> >> };
> >>
> >> + nor_flash: spi@11014000 {
> >> + compatible = "mediatek,mt2701-nor",
> >> + "mediatek,mt8173-nor";
> >
> > Why define both here? Is "mediatek,mt8173-nor" really providing a
> > subset of the features supported by "mediatek,mt2701-nor"?
> >
>
> I think even if the ip block is the same, we should provide both
> bindings, just in case in the future we find out that mt2701 has some
> hidden bug, feature or bug-feature. This way even if we update the
> driver, we stay compatible with older device tree blobs in the wild.
I'm fine with this approach, but in this case, defining both is wrong.
>
> We can drop the mt2701-nor in the bindings definition if you want.
Yes, please.
>
> Regards,
> Matthias
>
> >> + reg = <0 0x11014000 0 0xe0>;
> >> + clocks = <&pericfg CLK_PERI_FLASH>,
> >> + <&topckgen CLK_TOP_FLASH_SEL>;
> >> + clock-names = "spi", "sf";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + status = "disabled";
> >> + };
> >> +
> >> mmsys: syscon@14000000 {
> >> compatible = "mediatek,mt2701-mmsys", "syscon";
> >> reg = <0 0x14000000 0 0x1000>;
> >
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Matthias Brugger @ 2017-01-13 15:12 UTC (permalink / raw)
To: Boris Brezillon, Guochun Mao
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Russell King,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170113151747.6bc85245@bbrezillon>
On 13/01/17 15:17, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 15:13:29 +0800
> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>
>> Add Mediatek nor flash node.
>>
>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>> ---
>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
>> index 082ca88..85e5ae8 100644
>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>> @@ -24,6 +24,31 @@
>> };
>> };
>>
>> +&nor_flash {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&nor_pins_default>;
>> + status = "okay";
>> + flash@0 {
>> + compatible = "jedec,spi-nor";
>> + reg = <0>;
>> + };
>> +};
>> +
>> +&pio {
>> + nor_pins_default: nor {
>> + pins1 {
>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>> + drive-strength = <MTK_DRIVE_4mA>;
>> + bias-pull-up;
>> + };
>> + };
>> +};
>> +
>> &uart0 {
>> status = "okay";
>> };
>> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
>> index bdf8954..1eefce4 100644
>> --- a/arch/arm/boot/dts/mt2701.dtsi
>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>> @@ -227,6 +227,18 @@
>> status = "disabled";
>> };
>>
>> + nor_flash: spi@11014000 {
>> + compatible = "mediatek,mt2701-nor",
>> + "mediatek,mt8173-nor";
>
> Why define both here? Is "mediatek,mt8173-nor" really providing a
> subset of the features supported by "mediatek,mt2701-nor"?
>
I think even if the ip block is the same, we should provide both
bindings, just in case in the future we find out that mt2701 has some
hidden bug, feature or bug-feature. This way even if we update the
driver, we stay compatible with older device tree blobs in the wild.
We can drop the mt2701-nor in the bindings definition if you want.
Regards,
Matthias
>> + reg = <0 0x11014000 0 0xe0>;
>> + clocks = <&pericfg CLK_PERI_FLASH>,
>> + <&topckgen CLK_TOP_FLASH_SEL>;
>> + clock-names = "spi", "sf";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>> +
>> mmsys: syscon@14000000 {
>> compatible = "mediatek,mt2701-mmsys", "syscon";
>> reg = <0 0x14000000 0 0x1000>;
>
--
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 2/6] arm: dts: mt2701: Add iommu/smi device node
From: Matthias Brugger @ 2017-01-13 15:05 UTC (permalink / raw)
To: Erin Lo
Cc: srv_heupstream, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, Honghui Zhang
In-Reply-To: <1484296978-18572-3-git-send-email-erin.lo@mediatek.com>
Hi Erin,
I just took the patch from Honghui he send in june.
Please see my comment inline.
On 13/01/17 09:42, Erin Lo wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> Add the device node of iommu and smi for MT2701.
>
> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index eb4c6fd..87be52c 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -17,6 +17,7 @@
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/reset/mt2701-resets.h>
> +#include <dt-bindings/memory/mt2701-larb-port.h>
> #include "skeleton64.dtsi"
> #include "mt2701-pinfunc.h"
>
> @@ -161,6 +162,16 @@
> clock-names = "system-clk", "rtc-clk";
> };
>
> + smi_common: smi@1000c000 {
> + compatible = "mediatek,mt2701-smi-common";
> + reg = <0 0x1000c000 0 0x1000>;
> + clocks = <&infracfg CLK_INFRA_SMI>,
> + <&mmsys CLK_MM_SMI_COMMON>,
> + <&infracfg CLK_INFRA_SMI>;
> + clock-names = "apb", "smi", "async";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> + };
> +
> sysirq: interrupt-controller@10200100 {
> compatible = "mediatek,mt2701-sysirq",
> "mediatek,mt6577-sysirq";
> @@ -170,6 +181,16 @@
> reg = <0 0x10200100 0 0x1c>;
> };
>
> + iommu: mmsys_iommu@10205000 {
> + compatible = "mediatek,mt2701-m4u";
> + reg = <0 0x10205000 0 0x1000>;
> + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_M4U>;
> + clock-names = "bclk";
> + mediatek,larbs = <&larb0 &larb1 &larb2>;
> + #iommu-cells = <1>;
> + };
> +
> apmixedsys: syscon@10209000 {
> compatible = "mediatek,mt2701-apmixedsys", "syscon";
> reg = <0 0x10209000 0 0x1000>;
> @@ -272,18 +293,51 @@
> #clock-cells = <1>;
> };
>
> + larb0: larb@14010000 {
> + compatible = "mediatek,mt2701-smi-larb";
> + reg = <0 0x14010000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + mediatek,larbidx = <0>;
Did I miss something? 'mediatek,larbidx' does not sound familiar to me.
Regards,
Matthias
> + clocks = <&mmsys CLK_MM_SMI_LARB0>,
> + <&mmsys CLK_MM_SMI_LARB0>;
> + clock-names = "apb", "smi";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> + };
> +
> imgsys: syscon@15000000 {
> compatible = "mediatek,mt2701-imgsys", "syscon";
> reg = <0 0x15000000 0 0x1000>;
> #clock-cells = <1>;
> };
>
> + larb2: larb@15001000 {
> + compatible = "mediatek,mt2701-smi-larb";
> + reg = <0 0x15001000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + mediatek,larbidx = <2>;
> + clocks = <&imgsys CLK_IMG_SMI_COMM>,
> + <&imgsys CLK_IMG_SMI_COMM>;
> + clock-names = "apb", "smi";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
> + };
> +
> vdecsys: syscon@16000000 {
> compatible = "mediatek,mt2701-vdecsys", "syscon";
> reg = <0 0x16000000 0 0x1000>;
> #clock-cells = <1>;
> };
>
> + larb1: larb@16010000 {
> + compatible = "mediatek,mt2701-smi-larb";
> + reg = <0 0x16010000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + mediatek,larbidx = <1>;
> + clocks = <&vdecsys CLK_VDEC_CKGEN>,
> + <&vdecsys CLK_VDEC_LARB>;
> + clock-names = "apb", "smi";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
> + };
> +
> hifsys: syscon@1a000000 {
> compatible = "mediatek,mt2701-hifsys", "syscon";
> reg = <0 0x1a000000 0 0x1000>;
>
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-13 15:02 UTC (permalink / raw)
To: Eddie Huang
Cc: Hans Verkuil, Rick Chang, devicetree, Laurent Pinchart,
Minghsiu Tsai, srv_heupstream, James Liao, linux-kernel,
Rob Herring, Hans Verkuil, linux-mediatek, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
In-Reply-To: <1484011718.10361.7.camel@mtksdaap41>
Hi James,
On 10/01/17 02:28, Eddie Huang wrote:
> Hi Matthias,
>
> On Mon, 2017-01-09 at 19:45 +0100, Matthias Brugger wrote:
>>
>> On 09/01/17 12:29, Hans Verkuil wrote:
>>> Hi Rick,
>>>
>>> On 01/06/2017 03:34 AM, Rick Chang wrote:
>>>> Hi Hans,
>>>>
>>>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
>>>> any idea about this patch series? Should we wait for [2] or we could merge
>>>> the source code and dt-binding first?
>>>
>>> Looking at [2] I noticed that the last comment was July 4th. What is the reason
>>> it hasn't been merged yet?
>>>
>>> If I know [2] will be merged for 4.11, then I am fine with merging this media
>>> patch series. The dependency of this patch on [2] is something Mauro can handle.
>>>
>>> If [2] is not merged for 4.11, then I think it is better to wait until it is
>>> merged.
>>>
>>
>> I can't take [2] because there is no scpsys in the dts present. It seems
>> that it got never posted.
>>
>> Rick can you please follow-up with James and provide a patch which adds
>> a scpsys node to the mt2701.dtsi?
>>
>
> James sent three MT2701 dts patches [1] two weeks ago, these three
> patches include scpsys node. Please take a reference. And We will send
> new MT2701 ionmmu/smi dtsi node patch base on [1] later, thus you can
> accept and merge to 4.11.
>
Thanks for the clarification. I pulled all this patches into
v4.10-next/dts32
Hans will you take v9 of this patch set?
Then I'll take the dts patch.
Regards,
Matthias
> [1]
> https://patchwork.kernel.org/patch/9489991/
> https://patchwork.kernel.org/patch/9489985/
> https://patchwork.kernel.org/patch/9489989/
>
> Thanks,
> Eddie
>
>
^ permalink raw reply
* Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701
From: Matthias Brugger @ 2017-01-13 14:54 UTC (permalink / raw)
To: Honghui Zhang
Cc: joro-zLv9SwRftAIdnm+yROfE0A, treding-DDmLM1+adcrQT0dZR+AlfA,
mark.rutland-5wv7dgnIgG8, robh-DgEjT+Ai2ygdnm+yROfE0A,
robin.murphy-5wv7dgnIgG8, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, pebolle-IWqWACnzNjzz+pZb47iToQ,
kendrick.hsu-NuS5LvNUpcJWk0Htik3J/w, arnd-r2nGTMty4D4,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, tfiga-hpIqsD4AKlfQT0dZR+AlfA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, djkurtz-hpIqsD4AKlfQT0dZR+AlfA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
l.stach-bIcnvbaLZ9MEGnE8C9+IrQ,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w, erin.lo-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <577A1794.5040509-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/07/16 10:00, Matthias Brugger wrote:
>
>
> On 04/07/16 03:32, Honghui Zhang wrote:
>> On Sun, 2016-07-03 at 21:12 +0200, Matthias Brugger wrote:
>>>
>>> On 07/03/2016 08:24 AM, Matthias Brugger wrote:
>>>>
>>>>
>>>> On 06/08/2016 11:51 AM, honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
>>>>> From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>
>>>>> Add the dtsi node of iommu and smi for mt2701.
>>>>>
>>>>> Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>> arch/arm/boot/dts/mt2701.dtsi | 51
>>>>> +++++++++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 51 insertions(+)
>>>>>
>>>>
>>>> Applied,
>>>
>>> Please resend the patch including the infracfg and mmsys node.
>>>
>>
>> Hi, Matthias,
>>
>> Please hold this one.
>> This one is based on CCF "arm: dts: mt2701: Add clock controller device
>> nodes"[1] and power domain patch "Mediatek MT2701 SCPSYS power domain
>> support v7"[2],
>> But these two patchset are still being reviewed now.
>>
>> Do you think it's better that I send this one later after ccf and power
>> domain patch got merged? I will send this patch later if it's OK with
>> you.
>>
>
> Sounds good.
Applied now to v4.10-next/dts32
Thanks.
>
> Thanks a lot,
> Matthias
>
>> Thanks.
>> [1] https://patchwork.kernel.org/patch/9109081
>> [2]
>> http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005429.html
>>
>>> Regards,
>>> Matthias
>>>
>>>>
>>>> Thanks.
>>>>
>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>> index 42d5a37..363de0d 100644
>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>> @@ -16,6 +16,7 @@
>>>>> #include <dt-bindings/power/mt2701-power.h>
>>>>> #include <dt-bindings/interrupt-controller/irq.h>
>>>>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> +#include <dt-bindings/memory/mt2701-larb-port.h>
>>>>> #include "skeleton64.dtsi"
>>>>> #include "mt2701-pinfunc.h"
>>>>>
>>>>> @@ -160,6 +161,16 @@
>>>>> clock-names = "system-clk", "rtc-clk";
>>>>> };
>>>>>
>>>>> + smi_common: smi@1000c000 {
>>>>> + compatible = "mediatek,mt2701-smi-common";
>>>>> + reg = <0 0x1000c000 0 0x1000>;
>>>>> + clocks = <&infracfg CLK_INFRA_SMI>,
>>>>> + <&mmsys CLK_MM_SMI_COMMON>,
>>>>> + <&infracfg CLK_INFRA_SMI>;
>>>>> + clock-names = "apb", "smi", "async";
>>>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
>>>>> + };
>>>>> +
>>>>> sysirq: interrupt-controller@10200100 {
>>>>> compatible = "mediatek,mt2701-sysirq",
>>>>> "mediatek,mt6577-sysirq";
>>>>> @@ -169,6 +180,16 @@
>>>>> reg = <0 0x10200100 0 0x1c>;
>>>>> };
>>>>>
>>>>> + iommu: mmsys_iommu@10205000 {
>>>>> + compatible = "mediatek,mt2701-m4u";
>>>>> + reg = <0 0x10205000 0 0x1000>;
>>>>> + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>;
>>>>> + clocks = <&infracfg CLK_INFRA_M4U>;
>>>>> + clock-names = "bclk";
>>>>> + mediatek,larbs = <&larb0 &larb1 &larb2>;
>>>>> + #iommu-cells = <1>;
>>>>> + };
>>>>> +
>>>>> apmixedsys: syscon@10209000 {
>>>>> compatible = "mediatek,mt2701-apmixedsys", "syscon";
>>>>> reg = <0 0x10209000 0 0x1000>;
>>>>> @@ -234,6 +255,16 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + larb0: larb@14010000 {
>>>>> + compatible = "mediatek,mt2701-smi-larb";
>>>>> + reg = <0 0x14010000 0 0x1000>;
>>>>> + mediatek,smi = <&smi_common>;
>>>>> + clocks = <&mmsys CLK_MM_SMI_LARB0>,
>>>>> + <&mmsys CLK_MM_SMI_LARB0>;
>>>>> + clock-names = "apb", "smi";
>>>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
>>>>> + };
>>>>> +
>>>>> imgsys: syscon@15000000 {
>>>>> compatible = "mediatek,mt2701-imgsys", "syscon";
>>>>> reg = <0 0x15000000 0 0x1000>;
>>>>> @@ -241,6 +272,16 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + larb2: larb@15001000 {
>>>>> + compatible = "mediatek,mt2701-smi-larb";
>>>>> + reg = <0 0x15001000 0 0x1000>;
>>>>> + mediatek,smi = <&smi_common>;
>>>>> + clocks = <&imgsys CLK_IMG_SMI_COMM>,
>>>>> + <&imgsys CLK_IMG_SMI_COMM>;
>>>>> + clock-names = "apb", "smi";
>>>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
>>>>> + };
>>>>> +
>>>>> vdecsys: syscon@16000000 {
>>>>> compatible = "mediatek,mt2701-vdecsys", "syscon";
>>>>> reg = <0 0x16000000 0 0x1000>;
>>>>> @@ -248,6 +289,16 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + larb1: larb@16010000 {
>>>>> + compatible = "mediatek,mt2701-smi-larb";
>>>>> + reg = <0 0x16010000 0 0x1000>;
>>>>> + mediatek,smi = <&smi_common>;
>>>>> + clocks = <&vdecsys CLK_VDEC_CKGEN>,
>>>>> + <&vdecsys CLK_VDEC_LARB>;
>>>>> + clock-names = "apb", "smi";
>>>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
>>>>> + };
>>>>> +
>>>>> hifsys: syscon@1a000000 {
>>>>> compatible = "mediatek,mt2701-hifsys", "syscon";
>>>>> reg = <0 0x1a000000 0 0x1000>;
>>>>>
>>
>>
--
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] ARM: dts: mediatek: update my email address
From: Matthias Brugger @ 2017-01-13 14:44 UTC (permalink / raw)
To: John Crispin, Rob Herring, Mark Rutland
Cc: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1482260674-61835-1-git-send-email-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
On 20/12/16 20:04, John Crispin wrote:
> This patch updates my email address as I no longer have access to the old
> one.
>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
> ---
> arch/arm/boot/dts/mt7623-evb.dts | 2 +-
> arch/arm/boot/dts/mt7623.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks.
> diff --git a/arch/arm/boot/dts/mt7623-evb.dts b/arch/arm/boot/dts/mt7623-evb.dts
> index a9ee2d6..b60b41c 100644
> --- a/arch/arm/boot/dts/mt7623-evb.dts
> +++ b/arch/arm/boot/dts/mt7623-evb.dts
> @@ -1,6 +1,6 @@
> /*
> * Copyright (c) 2016 MediaTek Inc.
> - * Author: John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
> + * Author: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> index fd2b614..6af8e60 100644
> --- a/arch/arm/boot/dts/mt7623.dtsi
> +++ b/arch/arm/boot/dts/mt7623.dtsi
> @@ -1,6 +1,6 @@
> /*
> * Copyright (c) 2016 MediaTek Inc.
> - * Author: John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
> + * Author: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
>
^ permalink raw reply
* Re: [PATCH 1/3] arm: dts: mt2701: Sort DT nodes by register address
From: Matthias Brugger @ 2017-01-13 14:38 UTC (permalink / raw)
To: James Liao, Rob Herring, Russell King
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <1482904006-44232-2-git-send-email-jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On 28/12/16 06:46, James Liao wrote:
> This patch rearrange MT2701 DT nodes to keep them in ascending order.
>
> Signed-off-by: James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 36 ++++++++++++++++++------------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 7eab6f4..73f4b7c 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -96,24 +96,6 @@
> <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> - pio: pinctrl@10005000 {
> - compatible = "mediatek,mt2701-pinctrl";
> - reg = <0 0x1000b000 0 0x1000>;
> - mediatek,pctl-regmap = <&syscfg_pctl_a>;
> - pins-are-numbered;
> - gpio-controller;
> - #gpio-cells = <2>;
> - interrupt-controller;
> - #interrupt-cells = <2>;
> - interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> - };
Applied the whole series. I fixed the unit address of pio to 1000b000
and it's order in the file.
Please check v4.10-next/dts32
Thanks,
Mathias
> -
> - syscfg_pctl_a: syscfg@10005000 {
> - compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
> - reg = <0 0x10005000 0 0x1000>;
> - };
> -
> topckgen: syscon@10000000 {
> compatible = "mediatek,mt2701-topckgen", "syscon";
> reg = <0 0x10000000 0 0x1000>;
> @@ -134,6 +116,24 @@
> #reset-cells = <1>;
> };
>
> + pio: pinctrl@10005000 {
> + compatible = "mediatek,mt2701-pinctrl";
> + reg = <0 0x1000b000 0 0x1000>;
> + mediatek,pctl-regmap = <&syscfg_pctl_a>;
> + pins-are-numbered;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + syscfg_pctl_a: syscfg@10005000 {
> + compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
> + reg = <0 0x10005000 0 0x1000>;
> + };
> +
> watchdog: watchdog@10007000 {
> compatible = "mediatek,mt2701-wdt",
> "mediatek,mt6589-wdt";
>
--
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 -next] crypto: mediatek - make symbol of_crypto_id static
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Wei Yongjun
Cc: Matthias Brugger, Ryder Lee, Wei Yongjun, linux-crypto,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20170112150321.4187-1-weiyj.lk@gmail.com>
On Thu, Jan 12, 2017 at 03:03:21PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/crypto/mediatek/mtk-platform.c:585:27: warning:
> symbol 'of_crypto_id' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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