| Message ID | 1507627831-29323-1-git-send-email-chaotian.jing@mediatek.com |
|---|---|
| Headers | show |
| Series | mmc: mediatek: add support of mt2701/mt2712 | expand |
On 10 October 2017 at 11:30, Chaotian Jing <chaotian.jing@mediatek.com> wrote: > devicetree bindings has been updated to support multi-platforms, > so that each platform has its owns compatible name. > And, this compatible name may used in driver to distinguish with > other platform. > > Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> I assume there is no dependency to the rest or the series on this, so this can go via arm soc? Kind regards Uffe > --- > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 12 ++++-------- > 1 file changed, 4 insertions(+), 8 deletions(-) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi > index b99a273..26396ef 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi > @@ -682,8 +682,7 @@ > }; > > mmc0: mmc@11230000 { > - compatible = "mediatek,mt8173-mmc", > - "mediatek,mt8135-mmc"; > + compatible = "mediatek,mt8173-mmc"; > reg = <0 0x11230000 0 0x1000>; > interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_LOW>; > clocks = <&pericfg CLK_PERI_MSDC30_0>, > @@ -693,8 +692,7 @@ > }; > > mmc1: mmc@11240000 { > - compatible = "mediatek,mt8173-mmc", > - "mediatek,mt8135-mmc"; > + compatible = "mediatek,mt8173-mmc"; > reg = <0 0x11240000 0 0x1000>; > interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>; > clocks = <&pericfg CLK_PERI_MSDC30_1>, > @@ -704,8 +702,7 @@ > }; > > mmc2: mmc@11250000 { > - compatible = "mediatek,mt8173-mmc", > - "mediatek,mt8135-mmc"; > + compatible = "mediatek,mt8173-mmc"; > reg = <0 0x11250000 0 0x1000>; > interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_LOW>; > clocks = <&pericfg CLK_PERI_MSDC30_2>, > @@ -715,8 +712,7 @@ > }; > > mmc3: mmc@11260000 { > - compatible = "mediatek,mt8173-mmc", > - "mediatek,mt8135-mmc"; > + compatible = "mediatek,mt8173-mmc"; > reg = <0 0x11260000 0 0x1000>; > interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_LOW>; > clocks = <&pericfg CLK_PERI_MSDC30_3>, > -- > 1.8.1.1.dirty > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/10/2017 12:49 PM, Ulf Hansson wrote: > On 10 October 2017 at 11:30, Chaotian Jing <chaotian.jing@mediatek.com> wrote: >> devicetree bindings has been updated to support multi-platforms, >> so that each platform has its owns compatible name. >> And, this compatible name may used in driver to distinguish with >> other platform. >> >> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> > > I assume there is no dependency to the rest or the series on this, so > this can go via arm soc? > Not in the sense of a merge conflict or something, but mt8173-mmc won't work until patch 2/12 is merged as well. If we want to be conservative, we should wait for this patch until the next kernel release. In the end it's just a cleanup of the dtsi. Regards, Matthias > Kind regards > Uffe > >> --- >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 12 ++++-------- >> 1 file changed, 4 insertions(+), 8 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> index b99a273..26396ef 100644 >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> @@ -682,8 +682,7 @@ >> }; >> >> mmc0: mmc@11230000 { >> - compatible = "mediatek,mt8173-mmc", >> - "mediatek,mt8135-mmc"; >> + compatible = "mediatek,mt8173-mmc"; >> reg = <0 0x11230000 0 0x1000>; >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_LOW>; >> clocks = <&pericfg CLK_PERI_MSDC30_0>, >> @@ -693,8 +692,7 @@ >> }; >> >> mmc1: mmc@11240000 { >> - compatible = "mediatek,mt8173-mmc", >> - "mediatek,mt8135-mmc"; >> + compatible = "mediatek,mt8173-mmc"; >> reg = <0 0x11240000 0 0x1000>; >> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>; >> clocks = <&pericfg CLK_PERI_MSDC30_1>, >> @@ -704,8 +702,7 @@ >> }; >> >> mmc2: mmc@11250000 { >> - compatible = "mediatek,mt8173-mmc", >> - "mediatek,mt8135-mmc"; >> + compatible = "mediatek,mt8173-mmc"; >> reg = <0 0x11250000 0 0x1000>; >> interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_LOW>; >> clocks = <&pericfg CLK_PERI_MSDC30_2>, >> @@ -715,8 +712,7 @@ >> }; >> >> mmc3: mmc@11260000 { >> - compatible = "mediatek,mt8173-mmc", >> - "mediatek,mt8135-mmc"; >> + compatible = "mediatek,mt8173-mmc"; >> reg = <0 0x11260000 0 0x1000>; >> interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_LOW>; >> clocks = <&pericfg CLK_PERI_MSDC30_3>, >> -- >> 1.8.1.1.dirty >> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10 October 2017 at 13:06, Matthias Brugger <matthias.bgg@gmail.com> wrote: > > > On 10/10/2017 12:49 PM, Ulf Hansson wrote: >> >> On 10 October 2017 at 11:30, Chaotian Jing <chaotian.jing@mediatek.com> >> wrote: >>> >>> devicetree bindings has been updated to support multi-platforms, >>> so that each platform has its owns compatible name. >>> And, this compatible name may used in driver to distinguish with >>> other platform. >>> >>> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> >> >> >> I assume there is no dependency to the rest or the series on this, so >> this can go via arm soc? >> > > > Not in the sense of a merge conflict or something, but mt8173-mmc won't work > until patch 2/12 is merged as well. If we want to be conservative, we should > wait for this patch until the next kernel release. In the end it's just a > cleanup of the dtsi. In such case I can pick it part of this series, just need your ack. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/10/2017 01:10 PM, Ulf Hansson wrote: > On 10 October 2017 at 13:06, Matthias Brugger <matthias.bgg@gmail.com> wrote: >> >> >> On 10/10/2017 12:49 PM, Ulf Hansson wrote: >>> >>> On 10 October 2017 at 11:30, Chaotian Jing <chaotian.jing@mediatek.com> >>> wrote: >>>> >>>> devicetree bindings has been updated to support multi-platforms, >>>> so that each platform has its owns compatible name. >>>> And, this compatible name may used in driver to distinguish with >>>> other platform. >>>> >>>> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> >>> >>> >>> I assume there is no dependency to the rest or the series on this, so >>> this can go via arm soc? >>> >> >> >> Not in the sense of a merge conflict or something, but mt8173-mmc won't work >> until patch 2/12 is merged as well. If we want to be conservative, we should >> wait for this patch until the next kernel release. In the end it's just a >> cleanup of the dtsi. > > In such case I can pick it part of this series, just need your ack. > Acked-by: Matthias Brugger <matthias.bgg@gmail.com> Having a look on the patch, I don't expect it to create any merge conflicts. Thanks, Matthias -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 10/10/17 10:30, Chaotian Jing wrote: > from mt2701, the register of PAD_TUNE has been phased out, > while there is a new register of PAD_TUNE0 > > Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> > --- > drivers/mmc/host/mtk-sd.c | 69 ++++++++++++++++++++++++++++++++++------------- > 1 file changed, 51 insertions(+), 18 deletions(-) > > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c > index ab2fbbb..0dc45b3 100644 > --- a/drivers/mmc/host/mtk-sd.c > +++ b/drivers/mmc/host/mtk-sd.c > @@ -75,6 +75,7 @@ > #define MSDC_PATCH_BIT 0xb0 > #define MSDC_PATCH_BIT1 0xb4 > #define MSDC_PAD_TUNE 0xec > +#define MSDC_PAD_TUNE0 0xf0 > #define PAD_DS_TUNE 0x188 > #define PAD_CMD_TUNE 0x18c > #define EMMC50_CFG0 0x208 > @@ -301,6 +302,7 @@ struct msdc_save_para { > struct mtk_mmc_compatible { > u8 clk_div_bits; > bool hs400_tune; /* only used for MT8173 */ > + bool pad_tune0; You only use this to decide whether to use MDSC_PAD_TUNE or MSDC_PAD_TUNE0 as tune regs. Couldn't this field directly be a 'u32' that is either MDSC_PAD_TUNE or MDSC_PAD_TUNE0 rather than a bool? > }; > > struct msdc_tune_para { > @@ -362,21 +364,25 @@ struct msdc_host { > static const struct mtk_mmc_compatible mt8135_compat = { > .clk_div_bits = 8, > .hs400_tune = false, > + .pad_tune0 = false, and here we could have (field could be renamed accordingly of course): .pad_tune0 = MDSC_PAD_TUNE, > }; > > static const struct mtk_mmc_compatible mt8173_compat = { > .clk_div_bits = 8, > .hs400_tune = true, > + .pad_tune0 = false, > }; > > static const struct mtk_mmc_compatible mt2701_compat = { > .clk_div_bits = 12, > .hs400_tune = false, > + .pad_tune0 = true, here: .pad_tune0 = MDSC_PAD_TUNE0, > }; > > static const struct mtk_mmc_compatible mt2712_compat = { > .clk_div_bits = 12, > .hs400_tune = false, > + .pad_tune0 = true, > }; > > static const struct of_device_id msdc_of_ids[] = { > @@ -581,6 +587,10 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz) > u32 flags; > u32 div; > u32 sclk; > + u32 tune_reg = MSDC_PAD_TUNE; > + > + if (host->dev_comp->pad_tune0) > + tune_reg = MSDC_PAD_TUNE0; And this would not be needed here nor in the other functions, it could just be replaced by host->dev_comp->pad_tune0. Thanks,
On Tue, 2017-10-10 at 17:57 +0100, Julien Thierry wrote: > Hi, > > On 10/10/17 10:30, Chaotian Jing wrote: > > from mt2701, the register of PAD_TUNE has been phased out, > > while there is a new register of PAD_TUNE0 > > > > Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> > > --- > > drivers/mmc/host/mtk-sd.c | 69 ++++++++++++++++++++++++++++++++++------------- > > 1 file changed, 51 insertions(+), 18 deletions(-) > > > > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c > > index ab2fbbb..0dc45b3 100644 > > --- a/drivers/mmc/host/mtk-sd.c > > +++ b/drivers/mmc/host/mtk-sd.c > > @@ -75,6 +75,7 @@ > > #define MSDC_PATCH_BIT 0xb0 > > #define MSDC_PATCH_BIT1 0xb4 > > #define MSDC_PAD_TUNE 0xec > > +#define MSDC_PAD_TUNE0 0xf0 > > #define PAD_DS_TUNE 0x188 > > #define PAD_CMD_TUNE 0x18c > > #define EMMC50_CFG0 0x208 > > @@ -301,6 +302,7 @@ struct msdc_save_para { > > struct mtk_mmc_compatible { > > u8 clk_div_bits; > > bool hs400_tune; /* only used for MT8173 */ > > + bool pad_tune0; > > You only use this to decide whether to use MDSC_PAD_TUNE or > MSDC_PAD_TUNE0 as tune regs. > > Couldn't this field directly be a 'u32' that is either MDSC_PAD_TUNE or > MDSC_PAD_TUNE0 rather than a bool? > Thx, will change to "u32 pad_tune_reg;" at next version. > > }; > > > > struct msdc_tune_para { > > @@ -362,21 +364,25 @@ struct msdc_host { > > static const struct mtk_mmc_compatible mt8135_compat = { > > .clk_div_bits = 8, > > .hs400_tune = false, > > + .pad_tune0 = false, > > and here we could have (field could be renamed accordingly of course): > > .pad_tune0 = MDSC_PAD_TUNE, > > > }; > > > > static const struct mtk_mmc_compatible mt8173_compat = { > > .clk_div_bits = 8, > > .hs400_tune = true, > > + .pad_tune0 = false, > > }; > > > > static const struct mtk_mmc_compatible mt2701_compat = { > > .clk_div_bits = 12, > > .hs400_tune = false, > > + .pad_tune0 = true, > > here: > .pad_tune0 = MDSC_PAD_TUNE0, > > > }; > > > > static const struct mtk_mmc_compatible mt2712_compat = { > > .clk_div_bits = 12, > > .hs400_tune = false, > > + .pad_tune0 = true, > > }; > > > > static const struct of_device_id msdc_of_ids[] = { > > @@ -581,6 +587,10 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz) > > u32 flags; > > u32 div; > > u32 sclk; > > + u32 tune_reg = MSDC_PAD_TUNE; > > + > > + if (host->dev_comp->pad_tune0) > > + tune_reg = MSDC_PAD_TUNE0; > > And this would not be needed here nor in the other functions, it could > just be replaced by host->dev_comp->pad_tune0. > > Thanks, > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html