| Message ID | 1478568298-18380-2-git-send-email-jun.nie@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
On 2016/11/8 9:24, Jun Nie wrote: > Document the device-tree binding of ZTE MMC host on > ZX296718 SoC. > > Signed-off-by: Jun Nie <jun.nie@linaro.org> > --- > .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 ++++++++++++++++++++++ > 1 file changed, 35 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt > > diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt > new file mode 100644 > index 0000000..c175c4b > --- /dev/null > +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt > @@ -0,0 +1,35 @@ > +* ZTE specific extensions to the Synopsys Designware Mobile Storage > + Host Controller > + > +The Synopsys designware mobile storage host controller is used to interface > +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents > +differences between the core Synopsys dw mshc controller properties described > +by synopsys-dw-mshc.txt and the properties used by the ZTE specific > +extensions to the Synopsys Designware Mobile Storage Host Controller. > + > +Required Properties: > + > +* compatible: should be > + - "zte,zx296718-dw-mshc": for ZX SoCs > + > +Example: > + > + mmc1: mmc@1110000 { > + compatible = "zte,zx296718-dw-mshc"; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x01110000 0x1000>; > + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; > + fifo-depth = <32>; > + data-addr = <0x200>; > + fifo-watermark-aligned; > + bus-width = <4>; > + clock-frequency = <50000000>; do you need both clock-frequency and max-frequency here? > + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>; > + clock-names = "biu", "ciu"; > + num-slots = <1>; > + max-frequency = <50000000>; > + cap-sdio-irq; > + cap-sd-highspeed; > + status = "disabled"; > + }; > -- Best Regards Shawn Lin -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>: > On 2016/11/8 9:24, Jun Nie wrote: >> >> Document the device-tree binding of ZTE MMC host on >> ZX296718 SoC. >> >> Signed-off-by: Jun Nie <jun.nie@linaro.org> >> --- >> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 >> ++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >> >> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >> new file mode 100644 >> index 0000000..c175c4b >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >> @@ -0,0 +1,35 @@ >> +* ZTE specific extensions to the Synopsys Designware Mobile Storage >> + Host Controller >> + >> +The Synopsys designware mobile storage host controller is used to >> interface >> +a SoC with storage medium such as eMMC or SD/MMC cards. This file >> documents >> +differences between the core Synopsys dw mshc controller properties >> described >> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific >> +extensions to the Synopsys Designware Mobile Storage Host Controller. >> + >> +Required Properties: >> + >> +* compatible: should be >> + - "zte,zx296718-dw-mshc": for ZX SoCs >> + >> +Example: >> + >> + mmc1: mmc@1110000 { >> + compatible = "zte,zx296718-dw-mshc"; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + reg = <0x01110000 0x1000>; >> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; >> + fifo-depth = <32>; >> + data-addr = <0x200>; >> + fifo-watermark-aligned; >> + bus-width = <4>; >> + clock-frequency = <50000000>; > > > do you need both clock-frequency and max-frequency here? According to dts document, clock-frequency is for clock configuration when dw core probe. max-frequency is for mmc core to limit max frequency for any cards at any time. Do you have any suggestion? Thank you for your time! > >> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>; >> + clock-names = "biu", "ciu"; >> + num-slots = <1>; >> + max-frequency = <50000000>; >> + cap-sdio-irq; >> + cap-sd-highspeed; >> + status = "disabled"; >> + }; >> > > > -- > Best Regards > Shawn Lin > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/14/2016 07:00 PM, Jun Nie wrote: > 2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>: >> On 2016/11/8 9:24, Jun Nie wrote: >>> >>> Document the device-tree binding of ZTE MMC host on >>> ZX296718 SoC. >>> >>> Signed-off-by: Jun Nie <jun.nie@linaro.org> >>> --- >>> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 >>> ++++++++++++++++++++++ >>> 1 file changed, 35 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>> >>> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>> new file mode 100644 >>> index 0000000..c175c4b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>> @@ -0,0 +1,35 @@ >>> +* ZTE specific extensions to the Synopsys Designware Mobile Storage >>> + Host Controller >>> + >>> +The Synopsys designware mobile storage host controller is used to >>> interface >>> +a SoC with storage medium such as eMMC or SD/MMC cards. This file >>> documents >>> +differences between the core Synopsys dw mshc controller properties >>> described >>> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific >>> +extensions to the Synopsys Designware Mobile Storage Host Controller. >>> + >>> +Required Properties: >>> + >>> +* compatible: should be >>> + - "zte,zx296718-dw-mshc": for ZX SoCs >>> + >>> +Example: >>> + >>> + mmc1: mmc@1110000 { >>> + compatible = "zte,zx296718-dw-mshc"; >>> + #address-cells = <1>; >>> + #size-cells = <0>; >>> + reg = <0x01110000 0x1000>; >>> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; >>> + fifo-depth = <32>; >>> + data-addr = <0x200>; >>> + fifo-watermark-aligned; >>> + bus-width = <4>; >>> + clock-frequency = <50000000>; >> >> >> do you need both clock-frequency and max-frequency here? > > According to dts document, clock-frequency is for clock configuration > when dw core probe. max-frequency is for mmc core to limit max > frequency for any cards at any time. Do you have any suggestion? Thank > you for your time! As i know, Jun's comment is right. :) clock-frequency should be used with clk_set_rate(). > >> >>> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>; >>> + clock-names = "biu", "ciu"; >>> + num-slots = <1>; >>> + max-frequency = <50000000>; >>> + cap-sdio-irq; >>> + cap-sd-highspeed; >>> + status = "disabled"; >>> + }; >>> >> >> >> -- >> Best Regards >> Shawn Lin >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2016/11/14 18:04, Jaehoon Chung wrote: > On 11/14/2016 07:00 PM, Jun Nie wrote: >> 2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>: >>> On 2016/11/8 9:24, Jun Nie wrote: >>>> >>>> Document the device-tree binding of ZTE MMC host on >>>> ZX296718 SoC. >>>> >>>> Signed-off-by: Jun Nie <jun.nie@linaro.org> >>>> --- >>>> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 >>>> ++++++++++++++++++++++ >>>> 1 file changed, 35 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>> new file mode 100644 >>>> index 0000000..c175c4b >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>> @@ -0,0 +1,35 @@ >>>> +* ZTE specific extensions to the Synopsys Designware Mobile Storage >>>> + Host Controller >>>> + >>>> +The Synopsys designware mobile storage host controller is used to >>>> interface >>>> +a SoC with storage medium such as eMMC or SD/MMC cards. This file >>>> documents >>>> +differences between the core Synopsys dw mshc controller properties >>>> described >>>> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific >>>> +extensions to the Synopsys Designware Mobile Storage Host Controller. >>>> + >>>> +Required Properties: >>>> + >>>> +* compatible: should be >>>> + - "zte,zx296718-dw-mshc": for ZX SoCs >>>> + >>>> +Example: >>>> + >>>> + mmc1: mmc@1110000 { >>>> + compatible = "zte,zx296718-dw-mshc"; >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + reg = <0x01110000 0x1000>; >>>> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; >>>> + fifo-depth = <32>; >>>> + data-addr = <0x200>; >>>> + fifo-watermark-aligned; >>>> + bus-width = <4>; >>>> + clock-frequency = <50000000>; >>> >>> >>> do you need both clock-frequency and max-frequency here? >> >> According to dts document, clock-frequency is for clock configuration >> when dw core probe. max-frequency is for mmc core to limit max >> frequency for any cards at any time. Do you have any suggestion? Thank >> you for your time! > > As i know, Jun's comment is right. :) > clock-frequency should be used with clk_set_rate(). yup, I was thinking that should we reuse max-frequency instead of clock-frequency in the future? I saw most of the DT(I didn't check all of them) assign clock-frequency to the same value as max of clock- freq-min-max. I think it's pointless if the clock-frequency is different from max-frequency as both of them will be setted via dw_mmc and finally we only take min(clock-frequency, max-frquency). Was I missing something? What is your opinion, Jaehoon and Jun? :) > >> >>> >>>> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>; >>>> + clock-names = "biu", "ciu"; >>>> + num-slots = <1>; >>>> + max-frequency = <50000000>; >>>> + cap-sdio-irq; >>>> + cap-sd-highspeed; >>>> + status = "disabled"; >>>> + }; >>>> >>> >>> >>> -- >>> Best Regards >>> Shawn Lin >>> >> >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Best Regards Shawn Lin -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/15/2016 09:48 AM, Shawn Lin wrote: > On 2016/11/14 18:04, Jaehoon Chung wrote: >> On 11/14/2016 07:00 PM, Jun Nie wrote: >>> 2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>: >>>> On 2016/11/8 9:24, Jun Nie wrote: >>>>> >>>>> Document the device-tree binding of ZTE MMC host on >>>>> ZX296718 SoC. >>>>> >>>>> Signed-off-by: Jun Nie <jun.nie@linaro.org> >>>>> --- >>>>> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 >>>>> ++++++++++++++++++++++ >>>>> 1 file changed, 35 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>> new file mode 100644 >>>>> index 0000000..c175c4b >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>> @@ -0,0 +1,35 @@ >>>>> +* ZTE specific extensions to the Synopsys Designware Mobile Storage >>>>> + Host Controller >>>>> + >>>>> +The Synopsys designware mobile storage host controller is used to >>>>> interface >>>>> +a SoC with storage medium such as eMMC or SD/MMC cards. This file >>>>> documents >>>>> +differences between the core Synopsys dw mshc controller properties >>>>> described >>>>> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific >>>>> +extensions to the Synopsys Designware Mobile Storage Host Controller. >>>>> + >>>>> +Required Properties: >>>>> + >>>>> +* compatible: should be >>>>> + - "zte,zx296718-dw-mshc": for ZX SoCs >>>>> + >>>>> +Example: >>>>> + >>>>> + mmc1: mmc@1110000 { >>>>> + compatible = "zte,zx296718-dw-mshc"; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <0>; >>>>> + reg = <0x01110000 0x1000>; >>>>> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; >>>>> + fifo-depth = <32>; >>>>> + data-addr = <0x200>; >>>>> + fifo-watermark-aligned; >>>>> + bus-width = <4>; >>>>> + clock-frequency = <50000000>; >>>> >>>> >>>> do you need both clock-frequency and max-frequency here? >>> >>> According to dts document, clock-frequency is for clock configuration >>> when dw core probe. max-frequency is for mmc core to limit max >>> frequency for any cards at any time. Do you have any suggestion? Thank >>> you for your time! >> >> As i know, Jun's comment is right. :) >> clock-frequency should be used with clk_set_rate(). > > yup, I was thinking that should we reuse max-frequency instead of > clock-frequency in the future? I saw most of the DT(I didn't check all > of them) assign clock-frequency to the same value as max of clock- > freq-min-max. I think it's pointless if the clock-frequency is different > from max-frequency as both of them will be setted via dw_mmc and finally > we only take min(clock-frequency, max-frquency). Was I missing > something? Well, clock-frequency is for setting CMU. but max-frequency is not really used for CMU. For example, clock-frequency is 100MHz. Max-frequency is 50MHz. It's possible to use. then dwmmc controller should divide to 2 for max-frequency. There are too many cases. Source clock can be 400MHz or 200MHz..etc.. but maximum clock is decided according to busmode. I'm not sure because i didn't have HW knowledge.. but in my experience, 1) 400MHz/2 = 200MHz, 2) 800MHz/4 = 200MHz. 1) and 2) are same value as 200MHz. but those clock phase might be a little difference. So i want to keep the clock-frequency for setting the initial CMU value. What your opinion? :) Best Regards, Jaehoon Chung > > What is your opinion, Jaehoon and Jun? :) > >> >>> >>>> >>>>> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>; >>>>> + clock-names = "biu", "ciu"; >>>>> + num-slots = <1>; >>>>> + max-frequency = <50000000>; >>>>> + cap-sdio-irq; >>>>> + cap-sd-highspeed; >>>>> + status = "disabled"; >>>>> + }; >>>>> >>>> >>>> >>>> -- >>>> Best Regards >>>> Shawn Lin >>>> >>> >>> >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2016/11/15 13:21, Jaehoon Chung wrote: > On 11/15/2016 09:48 AM, Shawn Lin wrote: >> On 2016/11/14 18:04, Jaehoon Chung wrote: >>> On 11/14/2016 07:00 PM, Jun Nie wrote: >>>> 2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>: >>>>> On 2016/11/8 9:24, Jun Nie wrote: >>>>>> >>>>>> Document the device-tree binding of ZTE MMC host on >>>>>> ZX296718 SoC. >>>>>> >>>>>> Signed-off-by: Jun Nie <jun.nie@linaro.org> >>>>>> --- >>>>>> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 >>>>>> ++++++++++++++++++++++ >>>>>> 1 file changed, 35 insertions(+) >>>>>> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>>> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>>> new file mode 100644 >>>>>> index 0000000..c175c4b >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>>> @@ -0,0 +1,35 @@ >>>>>> +* ZTE specific extensions to the Synopsys Designware Mobile Storage >>>>>> + Host Controller >>>>>> + >>>>>> +The Synopsys designware mobile storage host controller is used to >>>>>> interface >>>>>> +a SoC with storage medium such as eMMC or SD/MMC cards. This file >>>>>> documents >>>>>> +differences between the core Synopsys dw mshc controller properties >>>>>> described >>>>>> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific >>>>>> +extensions to the Synopsys Designware Mobile Storage Host Controller. >>>>>> + >>>>>> +Required Properties: >>>>>> + >>>>>> +* compatible: should be >>>>>> + - "zte,zx296718-dw-mshc": for ZX SoCs >>>>>> + >>>>>> +Example: >>>>>> + >>>>>> + mmc1: mmc@1110000 { >>>>>> + compatible = "zte,zx296718-dw-mshc"; >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <0>; >>>>>> + reg = <0x01110000 0x1000>; >>>>>> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; >>>>>> + fifo-depth = <32>; >>>>>> + data-addr = <0x200>; >>>>>> + fifo-watermark-aligned; >>>>>> + bus-width = <4>; >>>>>> + clock-frequency = <50000000>; >>>>> >>>>> >>>>> do you need both clock-frequency and max-frequency here? >>>> >>>> According to dts document, clock-frequency is for clock configuration >>>> when dw core probe. max-frequency is for mmc core to limit max >>>> frequency for any cards at any time. Do you have any suggestion? Thank >>>> you for your time! >>> >>> As i know, Jun's comment is right. :) >>> clock-frequency should be used with clk_set_rate(). >> >> yup, I was thinking that should we reuse max-frequency instead of >> clock-frequency in the future? I saw most of the DT(I didn't check all >> of them) assign clock-frequency to the same value as max of clock- >> freq-min-max. I think it's pointless if the clock-frequency is different >> from max-frequency as both of them will be setted via dw_mmc and finally >> we only take min(clock-frequency, max-frquency). Was I missing >> something? > > Well, clock-frequency is for setting CMU. but max-frequency is not really used for CMU. > For example, clock-frequency is 100MHz. Max-frequency is 50MHz. > It's possible to use. then dwmmc controller should divide to 2 for max-frequency. yes, but why shouldn't we ask clock unit to generate max-frequency, so we don't need to divide 2 here? > > There are too many cases. Source clock can be 400MHz or 200MHz..etc.. > but maximum clock is decided according to busmode. > > I'm not sure because i didn't have HW knowledge.. > but in my experience, > 1) 400MHz/2 = 200MHz, > 2) 800MHz/4 = 200MHz. > > 1) and 2) are same value as 200MHz. but those clock phase might be a little difference. clock rate shouldn't be problem but the clock phase maybe according to the different clock design. > > So i want to keep the clock-frequency for setting the initial CMU value. > What your opinion? :) it' okay and I was just think that (1) most of the host drivers direct use max-frequenct(f_max) for setting clock source rate and use internal divider to generate other different rate. Also you can look at mmc_set_clock function. That impiles they doesn't care the phase or any differences at all. (2) If clock-frequency may be a little different with max-frequency, but I now check all the DT using clock-frequency with clock-freq-min-max before your cleanup and comfirm that all of the clock-frequency(s) are the same as the max of clock-freq-min-max, namely max-frequency after your cleanup. That implies that there are no difference between setting source rate with clock-frequency and with max-frequency. Anyway, that is just some random thoughts and shouldn't block this patchset. We could disscuss this topic later. :) > > Best Regards, > Jaehoon Chung > >> >> What is your opinion, Jaehoon and Jun? :) >> >>> >>>> >>>>> >>>>>> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>; >>>>>> + clock-names = "biu", "ciu"; >>>>>> + num-slots = <1>; >>>>>> + max-frequency = <50000000>; >>>>>> + cap-sdio-irq; >>>>>> + cap-sd-highspeed; >>>>>> + status = "disabled"; >>>>>> + }; >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best Regards >>>>> Shawn Lin >>>>> >>>> >>>> >>>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Best Regards Shawn Lin -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/15/2016 04:49 PM, Shawn Lin wrote: > On 2016/11/15 13:21, Jaehoon Chung wrote: >> On 11/15/2016 09:48 AM, Shawn Lin wrote: >>> On 2016/11/14 18:04, Jaehoon Chung wrote: >>>> On 11/14/2016 07:00 PM, Jun Nie wrote: >>>>> 2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>: >>>>>> On 2016/11/8 9:24, Jun Nie wrote: >>>>>>> >>>>>>> Document the device-tree binding of ZTE MMC host on >>>>>>> ZX296718 SoC. >>>>>>> >>>>>>> Signed-off-by: Jun Nie <jun.nie@linaro.org> >>>>>>> --- >>>>>>> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 >>>>>>> ++++++++++++++++++++++ >>>>>>> 1 file changed, 35 insertions(+) >>>>>>> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>>>> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>>>> new file mode 100644 >>>>>>> index 0000000..c175c4b >>>>>>> --- /dev/null >>>>>>> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt >>>>>>> @@ -0,0 +1,35 @@ >>>>>>> +* ZTE specific extensions to the Synopsys Designware Mobile Storage >>>>>>> + Host Controller >>>>>>> + >>>>>>> +The Synopsys designware mobile storage host controller is used to >>>>>>> interface >>>>>>> +a SoC with storage medium such as eMMC or SD/MMC cards. This file >>>>>>> documents >>>>>>> +differences between the core Synopsys dw mshc controller properties >>>>>>> described >>>>>>> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific >>>>>>> +extensions to the Synopsys Designware Mobile Storage Host Controller. >>>>>>> + >>>>>>> +Required Properties: >>>>>>> + >>>>>>> +* compatible: should be >>>>>>> + - "zte,zx296718-dw-mshc": for ZX SoCs >>>>>>> + >>>>>>> +Example: >>>>>>> + >>>>>>> + mmc1: mmc@1110000 { >>>>>>> + compatible = "zte,zx296718-dw-mshc"; >>>>>>> + #address-cells = <1>; >>>>>>> + #size-cells = <0>; >>>>>>> + reg = <0x01110000 0x1000>; >>>>>>> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; >>>>>>> + fifo-depth = <32>; >>>>>>> + data-addr = <0x200>; >>>>>>> + fifo-watermark-aligned; >>>>>>> + bus-width = <4>; >>>>>>> + clock-frequency = <50000000>; >>>>>> >>>>>> >>>>>> do you need both clock-frequency and max-frequency here? >>>>> >>>>> According to dts document, clock-frequency is for clock configuration >>>>> when dw core probe. max-frequency is for mmc core to limit max >>>>> frequency for any cards at any time. Do you have any suggestion? Thank >>>>> you for your time! >>>> >>>> As i know, Jun's comment is right. :) >>>> clock-frequency should be used with clk_set_rate(). >>> >>> yup, I was thinking that should we reuse max-frequency instead of >>> clock-frequency in the future? I saw most of the DT(I didn't check all >>> of them) assign clock-frequency to the same value as max of clock- >>> freq-min-max. I think it's pointless if the clock-frequency is different >>> from max-frequency as both of them will be setted via dw_mmc and finally >>> we only take min(clock-frequency, max-frquency). Was I missing >>> something? >> >> Well, clock-frequency is for setting CMU. but max-frequency is not really used for CMU. >> For example, clock-frequency is 100MHz. Max-frequency is 50MHz. >> It's possible to use. then dwmmc controller should divide to 2 for max-frequency. > > yes, but why shouldn't we ask clock unit to generate max-frequency, so > we don't need to divide 2 here? > >> >> There are too many cases. Source clock can be 400MHz or 200MHz..etc.. >> but maximum clock is decided according to busmode. >> >> I'm not sure because i didn't have HW knowledge.. >> but in my experience, >> 1) 400MHz/2 = 200MHz, >> 2) 800MHz/4 = 200MHz. >> >> 1) and 2) are same value as 200MHz. but those clock phase might be a little difference. > > clock rate shouldn't be problem but the clock phase maybe according to > the different clock design. > >> >> So i want to keep the clock-frequency for setting the initial CMU value. >> What your opinion? :) > > it' okay and I was just think that > (1) most of the host drivers direct use max-frequenct(f_max) for > setting clock source rate and use internal divider to generate other different rate. Also you can look at mmc_set_clock function. > That impiles they doesn't care the phase or any differences at all. > (2) If clock-frequency may be a little different with max-frequency, > but I now check all the DT using clock-frequency with clock-freq-min-max > before your cleanup and comfirm that all of the clock-frequency(s) are > the same as the max of clock-freq-min-max, namely max-frequency after > your cleanup. That implies that there are no difference between > setting source rate with clock-frequency and with max-frequency. > > > Anyway, that is just some random thoughts and shouldn't block this > patchset. We could disscuss this topic later. :) Yes, we can discuss about this in future. :) Best Regards, Jaehoon Chung > >> >> Best Regards, >> Jaehoon Chung >> >>> >>> What is your opinion, Jaehoon and Jun? :) >>> >>>> >>>>> >>>>>> >>>>>>> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>; >>>>>>> + clock-names = "biu", "ciu"; >>>>>>> + num-slots = <1>; >>>>>>> + max-frequency = <50000000>; >>>>>>> + cap-sdio-irq; >>>>>>> + cap-sd-highspeed; >>>>>>> + status = "disabled"; >>>>>>> + }; >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Regards >>>>>> Shawn Lin >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt new file mode 100644 index 0000000..c175c4b --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt @@ -0,0 +1,35 @@ +* ZTE specific extensions to the Synopsys Designware Mobile Storage + Host Controller + +The Synopsys designware mobile storage host controller is used to interface +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents +differences between the core Synopsys dw mshc controller properties described +by synopsys-dw-mshc.txt and the properties used by the ZTE specific +extensions to the Synopsys Designware Mobile Storage Host Controller. + +Required Properties: + +* compatible: should be + - "zte,zx296718-dw-mshc": for ZX SoCs + +Example: + + mmc1: mmc@1110000 { + compatible = "zte,zx296718-dw-mshc"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x01110000 0x1000>; + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; + fifo-depth = <32>; + data-addr = <0x200>; + fifo-watermark-aligned; + bus-width = <4>; + clock-frequency = <50000000>; + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>; + clock-names = "biu", "ciu"; + num-slots = <1>; + max-frequency = <50000000>; + cap-sdio-irq; + cap-sd-highspeed; + status = "disabled"; + };
Document the device-tree binding of ZTE MMC host on ZX296718 SoC. Signed-off-by: Jun Nie <jun.nie@linaro.org> --- .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html