Hi!
I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
the DT compatible string:
mmc@0x15000 {
compatible = "altr,socfpga-dw-mshc";
reg = < 0x15000 0x400 >;
num-slots = < 1 >;
fifo-depth = < 16 >;
card-detect-delay = < 200 >;
clocks = <&apbclk>, <&mmcclk>;
clock-names = "biu", "ciu";
interrupts = < 7 >;
bus-width = < 4 >;
};
I don't think this is OK, since ARC is unrelated to Altera, which is
what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
should be extended with another compatibility string, something like
"snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
accordingly. What do you think ?
--
Best regards,
Marek Vasut
On 26.03.2016 12:14, Marek Vasut wrote:
> Hi!
>
> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
> the DT compatible string:
>
> mmc@0x15000 {
> compatible = "altr,socfpga-dw-mshc";
> reg = < 0x15000 0x400 >;
> num-slots = < 1 >;
> fifo-depth = < 16 >;
> card-detect-delay = < 200 >;
> clocks = <&apbclk>, <&mmcclk>;
> clock-names = "biu", "ciu";
> interrupts = < 7 >;
> bus-width = < 4 >;
> };
>
> I don't think this is OK, since ARC is unrelated to Altera, which is
> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
> should be extended with another compatibility string, something like
> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
> accordingly. What do you think ?
>
There is "snps,dw-mshc" described in
Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
dw_mmc host controller driver.
--
With best wishes,
Vladimir
On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
> On 26.03.2016 12:14, Marek Vasut wrote:
>> Hi!
>>
>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>> the DT compatible string:
>>
>> mmc@0x15000 {
>> compatible = "altr,socfpga-dw-mshc";
>> reg = < 0x15000 0x400 >;
>> num-slots = < 1 >;
>> fifo-depth = < 16 >;
>> card-detect-delay = < 200 >;
>> clocks = <&apbclk>, <&mmcclk>;
>> clock-names = "biu", "ciu";
>> interrupts = < 7 >;
>> bus-width = < 4 >;
>> };
>>
>> I don't think this is OK, since ARC is unrelated to Altera, which is
>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>> should be extended with another compatibility string, something like
>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>> accordingly. What do you think ?
>>
>
> There is "snps,dw-mshc" described in
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
> dw_mmc host controller driver.
Thanks, that's even better.
btw what do you think of using altr, prefix on non-altera system, that
doesn't seem ok, right ?
--
Best regards,
Marek Vasut
Hi Marek, Vladimir,
26 ????? 2016 ?. 20:30 ???????????? Marek Vasut <[email protected]> ???????:
>
> On 03/26/2016 06:26 PM, Vlad
On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
> On 26.03.2016 12:14, Marek Vasut wrote:
>> Hi!
>>
>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>> the DT compatible string:
>>
>> mmc@0x15000 {
>> compatible = "altr,socfpga-dw-mshc";
>> reg = < 0x15000 0x400 >;
>> num-slots = < 1 >;
>> fifo-depth = < 16 >;
>> card-detect-delay = < 200 >;
>> clocks = <&apbclk>, <&mmcclk>;
>> clock-names = "biu", "ciu";
>> interrupts = < 7 >;
>> bus-width = < 4 >;
>> };
>>
>> I don't think this is OK, since ARC is unrelated to Altera, which is
>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>> should be extended with another compatibility string, something like
>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>> accordingly. What do you think ?
>>
>
> There is "snps,dw-mshc" described in
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
> dw_mmc host controller driver.
Thanks, that's even better.
btw what do you think of using altr, prefix on non-altera system, that
doesn't seem ok, right ?
--
Best regards,
Marek Vasut
Hi Marek,
On 26.03.2016 19:30, Marek Vasut wrote:
> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>> On 26.03.2016 12:14, Marek Vasut wrote:
>>> Hi!
>>>
>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>> the DT compatible string:
>>>
>>> mmc@0x15000 {
>>> compatible = "altr,socfpga-dw-mshc";
>>> reg = < 0x15000 0x400 >;
>>> num-slots = < 1 >;
>>> fifo-depth = < 16 >;
>>> card-detect-delay = < 200 >;
>>> clocks = <&apbclk>, <&mmcclk>;
>>> clock-names = "biu", "ciu";
>>> interrupts = < 7 >;
>>> bus-width = < 4 >;
>>> };
>>>
>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>> should be extended with another compatibility string, something like
>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>> accordingly. What do you think ?
>>>
>>
>> There is "snps,dw-mshc" described in
>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>> dw_mmc host controller driver.
>
> Thanks, that's even better.
>
> btw what do you think of using altr, prefix on non-altera system, that
> doesn't seem ok, right ?
according to ePAPR the prefix should represent a device (IP block here
I believe) manufacturer, so it should be okay to use "altr" prefix on
non-Altera system, if Altera provides another hardware vendor with
some own IP block.
That said, I would rather prefer to see "snps,dw-mshc" prefix on description
of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
to be redundant.
--
With best wishes,
Vladimir
On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
> Hi Marek,
>
> On 26.03.2016 19:30, Marek Vasut wrote:
>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>> Hi!
>>>>
>>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>>> the DT compatible string:
>>>>
>>>> mmc@0x15000 {
>>>> compatible = "altr,socfpga-dw-mshc";
>>>> reg = < 0x15000 0x400 >;
>>>> num-slots = < 1 >;
>>>> fifo-depth = < 16 >;
>>>> card-detect-delay = < 200 >;
>>>> clocks = <&apbclk>, <&mmcclk>;
>>>> clock-names = "biu", "ciu";
>>>> interrupts = < 7 >;
>>>> bus-width = < 4 >;
>>>> };
>>>>
>>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>>> should be extended with another compatibility string, something like
>>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>>> accordingly. What do you think ?
>>>>
>>>
>>> There is "snps,dw-mshc" described in
>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>>> dw_mmc host controller driver.
>>
>> Thanks, that's even better.
>>
>> btw what do you think of using altr, prefix on non-altera system, that
>> doesn't seem ok, right ?
>
> according to ePAPR the prefix should represent a device (IP block here
> I believe) manufacturer, so it should be okay to use "altr" prefix on
> non-Altera system, if Altera provides another hardware vendor with
> some own IP block.
In this case, it's Synopsys who provides the SD/MMC/MS core to other
chip makers (Altera etc).
> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
> to be redundant.
According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
"altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
"img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
one needs it as well, but most likely yes.
I wonder if that bit is needed on some particular version of the DWMMC
core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
binding ? Or should we use DT property to discern the need for this bit ?
> --
> With best wishes,
> Vladimir
>
--
Best regards,
Marek Vasut
On 26.03.2016 20:10, Marek Vasut wrote:
> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>> Hi Marek,
>>
>> On 26.03.2016 19:30, Marek Vasut wrote:
>>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>>> Hi!
>>>>>
>>>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>>>> the DT compatible string:
>>>>>
>>>>> mmc@0x15000 {
>>>>> compatible = "altr,socfpga-dw-mshc";
>>>>> reg = < 0x15000 0x400 >;
>>>>> num-slots = < 1 >;
>>>>> fifo-depth = < 16 >;
>>>>> card-detect-delay = < 200 >;
>>>>> clocks = <&apbclk>, <&mmcclk>;
>>>>> clock-names = "biu", "ciu";
>>>>> interrupts = < 7 >;
>>>>> bus-width = < 4 >;
>>>>> };
>>>>>
>>>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>>>> should be extended with another compatibility string, something like
>>>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>>>> accordingly. What do you think ?
>>>>>
>>>>
>>>> There is "snps,dw-mshc" described in
>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>>>> dw_mmc host controller driver.
>>>
>>> Thanks, that's even better.
>>>
>>> btw what do you think of using altr, prefix on non-altera system, that
>>> doesn't seem ok, right ?
>>
>> according to ePAPR the prefix should represent a device (IP block here
>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>> non-Altera system, if Altera provides another hardware vendor with
>> some own IP block.
>
> In this case, it's Synopsys who provides the SD/MMC/MS core to other
> chip makers (Altera etc).
Correct.
>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>> to be redundant.
>
> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
> one needs it as well, but most likely yes.
>
> I wonder if that bit is needed on some particular version of the DWMMC
> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
> binding ? Or should we use DT property to discern the need for this bit ?
>
That's the most common way to take into account peculiarities, add
a property and handle it from the driver.
--
With best wishes,
Vladimir
On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
> On 26.03.2016 20:10, Marek Vasut wrote:
>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>> Hi Marek,
>>>
>>> On 26.03.2016 19:30, Marek Vasut wrote:
>>>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>>>> Hi!
>>>>>>
>>>>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>>>>> the DT compatible string:
>>>>>>
>>>>>> mmc@0x15000 {
>>>>>> compatible = "altr,socfpga-dw-mshc";
>>>>>> reg = < 0x15000 0x400 >;
>>>>>> num-slots = < 1 >;
>>>>>> fifo-depth = < 16 >;
>>>>>> card-detect-delay = < 200 >;
>>>>>> clocks = <&apbclk>, <&mmcclk>;
>>>>>> clock-names = "biu", "ciu";
>>>>>> interrupts = < 7 >;
>>>>>> bus-width = < 4 >;
>>>>>> };
>>>>>>
>>>>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>>>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>>>>> should be extended with another compatibility string, something like
>>>>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>>>>> accordingly. What do you think ?
>>>>>>
>>>>>
>>>>> There is "snps,dw-mshc" described in
>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>>>>> dw_mmc host controller driver.
>>>>
>>>> Thanks, that's even better.
>>>>
>>>> btw what do you think of using altr, prefix on non-altera system, that
>>>> doesn't seem ok, right ?
>>>
>>> according to ePAPR the prefix should represent a device (IP block here
>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>> non-Altera system, if Altera provides another hardware vendor with
>>> some own IP block.
>>
>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>> chip makers (Altera etc).
>
> Correct.
>
>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>> to be redundant.
>>
>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>> one needs it as well, but most likely yes.
>>
>> I wonder if that bit is needed on some particular version of the DWMMC
>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>> binding ? Or should we use DT property to discern the need for this bit ?
>>
>
> That's the most common way to take into account peculiarities, add
> a property and handle it from the driver.
And by "that" you mean which of those two I listed , the
"snps,dw-mshc-vN" or adding new DT prop ?
--
Best regards,
Marek Vasut
On 26.03.2016 21:52, Marek Vasut wrote:
> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>> On 26.03.2016 20:10, Marek Vasut wrote:
>>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>>> Hi Marek,
>>>>
>>>> On 26.03.2016 19:30, Marek Vasut wrote:
>>>>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>>>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>>>>>> the DT compatible string:
>>>>>>>
>>>>>>> mmc@0x15000 {
>>>>>>> compatible = "altr,socfpga-dw-mshc";
>>>>>>> reg = < 0x15000 0x400 >;
>>>>>>> num-slots = < 1 >;
>>>>>>> fifo-depth = < 16 >;
>>>>>>> card-detect-delay = < 200 >;
>>>>>>> clocks = <&apbclk>, <&mmcclk>;
>>>>>>> clock-names = "biu", "ciu";
>>>>>>> interrupts = < 7 >;
>>>>>>> bus-width = < 4 >;
>>>>>>> };
>>>>>>>
>>>>>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>>>>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>>>>>> should be extended with another compatibility string, something like
>>>>>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>>>>>> accordingly. What do you think ?
>>>>>>>
>>>>>>
>>>>>> There is "snps,dw-mshc" described in
>>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>>>>>> dw_mmc host controller driver.
>>>>>
>>>>> Thanks, that's even better.
>>>>>
>>>>> btw what do you think of using altr, prefix on non-altera system, that
>>>>> doesn't seem ok, right ?
>>>>
>>>> according to ePAPR the prefix should represent a device (IP block here
>>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>>> non-Altera system, if Altera provides another hardware vendor with
>>>> some own IP block.
>>>
>>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>>> chip makers (Altera etc).
>>
>> Correct.
>>
>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>> to be redundant.
>>>
>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>> one needs it as well, but most likely yes.
>>>
>>> I wonder if that bit is needed on some particular version of the DWMMC
>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>> binding ? Or should we use DT property to discern the need for this bit ?
>>>
>>
>> That's the most common way to take into account peculiarities, add
>> a property and handle it from the driver.
>
> And by "that" you mean which of those two I listed , the
> "snps,dw-mshc-vN" or adding new DT prop ?
>
I meant to add a new property, not a new compatible, but that's just
my experience.
Let me say it __might__ happen that a particular change you need is
specific to a particular version of the DWMMC IP (query Synopsys
by the way), but more probably it might be e.g. the same IP version with
a different reduced or extended configuration or a minor fix/improvement
to the IP block without resulting version number bump.
For example I don't remember that errata fixes in IP blocks result in
a new compatible, instead there are quite common optional "quirk"
properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
--
With best wishes,
Vladimir
On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
> On 26.03.2016 21:52, Marek Vasut wrote:
>> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>> On 26.03.2016 20:10, Marek Vasut wrote:
>>>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>>>> Hi Marek,
>>>>>
>>>>> On 26.03.2016 19:30, Marek Vasut wrote:
>>>>>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>>>>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>>>>>>> the DT compatible string:
>>>>>>>>
>>>>>>>> mmc@0x15000 {
>>>>>>>> compatible = "altr,socfpga-dw-mshc";
>>>>>>>> reg = < 0x15000 0x400 >;
>>>>>>>> num-slots = < 1 >;
>>>>>>>> fifo-depth = < 16 >;
>>>>>>>> card-detect-delay = < 200 >;
>>>>>>>> clocks = <&apbclk>, <&mmcclk>;
>>>>>>>> clock-names = "biu", "ciu";
>>>>>>>> interrupts = < 7 >;
>>>>>>>> bus-width = < 4 >;
>>>>>>>> };
>>>>>>>>
>>>>>>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>>>>>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>>>>>>> should be extended with another compatibility string, something like
>>>>>>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>>>>>>> accordingly. What do you think ?
>>>>>>>>
>>>>>>>
>>>>>>> There is "snps,dw-mshc" described in
>>>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>>>>>>> dw_mmc host controller driver.
>>>>>>
>>>>>> Thanks, that's even better.
>>>>>>
>>>>>> btw what do you think of using altr, prefix on non-altera system, that
>>>>>> doesn't seem ok, right ?
>>>>>
>>>>> according to ePAPR the prefix should represent a device (IP block here
>>>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>>>> non-Altera system, if Altera provides another hardware vendor with
>>>>> some own IP block.
>>>>
>>>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>>>> chip makers (Altera etc).
>>>
>>> Correct.
>>>
>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>> to be redundant.
>>>>
>>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>>> one needs it as well, but most likely yes.
>>>>
>>>> I wonder if that bit is needed on some particular version of the DWMMC
>>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>>> binding ? Or should we use DT property to discern the need for this bit ?
>>>>
>>>
>>> That's the most common way to take into account peculiarities, add
>>> a property and handle it from the driver.
>>
>> And by "that" you mean which of those two I listed , the
>> "snps,dw-mshc-vN" or adding new DT prop ?
>>
>
> I meant to add a new property, not a new compatible, but that's just
> my experience.
>
> Let me say it __might__ happen that a particular change you need is
> specific to a particular version of the DWMMC IP (query Synopsys
> by the way), but more probably it might be e.g. the same IP version with
> a different reduced or extended configuration or a minor fix/improvement
> to the IP block without resulting version number bump.
>
> For example I don't remember that errata fixes in IP blocks result in
> a new compatible, instead there are quite common optional "quirk"
> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
Right, this very much matches how I see it as well. Thanks for confirming.
Alexey, can you tell us if the requirement for setting
SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
disappeared with some revision OR if this is some configuration
option of the core during synthesis ?
--
Best regards,
Marek Vasut
Hi Marek, Vladimir,
On Sat, 2016-03-26 at 21:24 +-0100, Marek Vasut wrote:
+AD4- On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
+AD4- +AD4-
+AD4- +AD4- On 26.03.2016 21:52, Marek Vasut wrote:
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- On 26.03.2016 20:10, Marek Vasut wrote:
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hi Marek,
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- On 26.03.2016 19:30, Marek Vasut wrote:
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- On 26.03.2016 12:14, Marek Vasut wrote:
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hi+ACE-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- I noticed that arch/arc/boot/dts/axs10x+AF8-mb.dtsi uses +ACI-altr,+ACI- prefix in
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- the DT compatible string:
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- mmc+AEA-0x15000 +AHs-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-compatible +AD0- +ACI-altr,socfpga-dw-mshc+ACIAOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-reg +AD0- +ADw- 0x15000 0x400 +AD4AOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-num-slots +AD0- +ADw- 1 +AD4AOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-fifo-depth +AD0- +ADw- 16 +AD4AOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-card-detect-delay +AD0- +ADw- 200 +AD4AOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-clocks +AD0- +ADwAJg-apbclk+AD4-, +ADwAJg-mmcclk+AD4AOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-clock-names +AD0- +ACI-biu+ACI-, +ACI-ciu+ACIAOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-interrupts +AD0- +ADw- 7 +AD4AOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-bus-width +AD0- +ADw- 4 +AD4AOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AH0AOw-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- I don't think this is OK, since ARC is unrelated to Altera, which is
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- what the +ACI-altr,+ACI- prefix stands for. I think the socfpga-dw-mshc shim
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- should be extended with another compatibility string, something like
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +ACI-snps,arc-dw-mshc+ACI- and the axs10x+AF8-mb.dtsi should be adjusted
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- accordingly. What do you think ?
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- There is +ACI-snps,dw-mshc+ACI- described in
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- dw+AF8-mmc host controller driver.
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Thanks, that's even better.
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- btw what do you think of using altr, prefix on non-altera system, that
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- doesn't seem ok, right ?
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- according to ePAPR the prefix should represent a device (IP block here
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- I believe) manufacturer, so it should be okay to use +ACI-altr+ACI- prefix on
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- non-Altera system, if Altera provides+AKAAoA-another hardware vendor with
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- some own IP block.
+AD4- +AD4- +AD4- +AD4- +AD4- In this case, it's Synopsys who provides the SD/MMC/MS core to other
+AD4- +AD4- +AD4- +AD4- +AD4- chip makers (Altera etc).
+AD4- +AD4- +AD4- +AD4- Correct.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- That said, I would rather prefer to see +ACI-snps,dw-mshc+ACI- prefix on description
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- of an MMC controller found on SoCFPGA series, +ACI-altr,socfpga-dw-mshc+ACI- seems
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- to be redundant.
+AD4- +AD4- +AD4- +AD4- +AD4- According to drivers/mmc/host/dw+AF8-mmc-pltfm.c , the Altera SoCFPGA one
+AD4- +AD4- +AD4- +AD4- +AD4- +ACI-altr,socfpga-dw-mshc+ACI- and also Imagination Technology Pistacio one
+AD4- +AD4- +AD4- +AD4- +AD4- +ACI-img,pistachio-dw-mshc+ACI- need specialty bit (SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG),
+AD4- +AD4- +AD4- +AD4- +AD4- while the stock one +ACI-snps,dw-mshc+ACI- does not. I am not sure if the ARC
+AD4- +AD4- +AD4- +AD4- +AD4- one needs it as well, but most likely yes.
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- I wonder if that bit is needed on some particular version of the DWMMC
+AD4- +AD4- +AD4- +AD4- +AD4- core. In that case, should we have +ACI-snps,dw-mshc+ACI- and +ACI-snps,dw-mshc-vN+ACI-
+AD4- +AD4- +AD4- +AD4- +AD4- binding ? Or should we use DT property to discern the need for this bit ?
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- That's the most common way to take into account peculiarities, add
+AD4- +AD4- +AD4- +AD4- a property and handle it from the driver.
+AD4- +AD4- +AD4- And by +ACI-that+ACI- you mean which of those two I listed , the
+AD4- +AD4- +AD4- +ACI-snps,dw-mshc-vN+ACI- or adding new DT prop ?
+AD4- +AD4- +AD4-
+AD4- +AD4- I meant to add a new property, not a new compatible, but that's just
+AD4- +AD4- my experience.
+AD4- +AD4-
+AD4- +AD4- Let me say it +AF8AXw-might+AF8AXw- happen that a particular change you need is
+AD4- +AD4- specific to a particular version of the DWMMC IP (query Synopsys
+AD4- +AD4- by the way), but more probably it might be e.g. the same IP version with
+AD4- +AD4- a different reduced or extended configuration or a minor fix/improvement
+AD4- +AD4- to the IP block without resulting version number bump.
+AD4- +AD4-
+AD4- +AD4- For example I don't remember that errata fixes in IP blocks result in
+AD4- +AD4- a new compatible, instead there are quite common optional +ACI-quirk+ACI-
+AD4- +AD4- properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
+AD4- Right, this very much matches how I see it as well. Thanks for confirming.
+AD4-
+AD4- Alexey, can you tell us if the requirement for setting
+AD4- SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG came with some new revision of the core or
+AD4- disappeared with some revision OR if this is some configuration
+AD4- option of the core during synthesis ?
Sorry for not following that discussion during my weekend but I'll try
to address all questions now.
DW Mobile Storage databook says:
---------------------+AD4-8-----------------------
To meet the relatively high Input Hold Time requirement for SDR12, SDR25,
and other MMC speed modes, you should program bit+AFs-29+AF0-use+AF8-hold+AF8-Reg of the
CMD register to 1'b1.
---------------------+AD4-8-----------------------
So I'd say this specific setting has nothing to do with a particular IP block
but instead it is related to card's mode of operation. More precisely bus clock.
SDR12 stands for+AKA-12.5 MByte/s, SDR25 stands for+AKA-25 MByte/s. I.e. we probably need
so set that bit just for certain cases and regardless board that uses DW MMC.
I'm adding DW MMC maintainer as well as linux-mmc mailing list so people who
understands that stuff better may comment here as well.
-Alexey
Hi,
On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
> Hi Marek, Vladimir,
>
> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
>>>
>>> On 26.03.2016 21:52, Marek Vasut wrote:
>>>>
>>>> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>>>>
>>>>> On 26.03.2016 20:10, Marek Vasut wrote:
>>>>>>
>>>>>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>>>>>>
>>>>>>> Hi Marek,
>>>>>>>
>>>>>>> On 26.03.2016 19:30, Marek Vasut wrote:
>>>>>>>>
>>>>>>>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>>>>>>>
>>>>>>>>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>>>>>>>>> the DT compatible string:
>>>>>>>>>>
>>>>>>>>>> mmc@0x15000 {
>>>>>>>>>> compatible = "altr,socfpga-dw-mshc";
>>>>>>>>>> reg = < 0x15000 0x400 >;
>>>>>>>>>> num-slots = < 1 >;
>>>>>>>>>> fifo-depth = < 16 >;
>>>>>>>>>> card-detect-delay = < 200 >;
>>>>>>>>>> clocks = <&apbclk>, <&mmcclk>;
>>>>>>>>>> clock-names = "biu", "ciu";
>>>>>>>>>> interrupts = < 7 >;
>>>>>>>>>> bus-width = < 4 >;
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>>>>>>>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>>>>>>>>> should be extended with another compatibility string, something like
>>>>>>>>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>>>>>>>>> accordingly. What do you think ?
>>>>>>>>>>
>>>>>>>>> There is "snps,dw-mshc" described in
>>>>>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>>>>>>>>> dw_mmc host controller driver.
>>>>>>>> Thanks, that's even better.
>>>>>>>>
>>>>>>>> btw what do you think of using altr, prefix on non-altera system, that
>>>>>>>> doesn't seem ok, right ?
>>>>>>> according to ePAPR the prefix should represent a device (IP block here
>>>>>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>>>>>> non-Altera system, if Altera provides another hardware vendor with
>>>>>>> some own IP block.
>>>>>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>>>>>> chip makers (Altera etc).
>>>>> Correct.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>>>> to be redundant.
Yes..it's redundant..i should be combined to "snps,dw-mshc".
>>>>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>>>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>>>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>>>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>>>>> one needs it as well, but most likely yes.
>>>>>>
>>>>>> I wonder if that bit is needed on some particular version of the DWMMC
>>>>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>>>>> binding ? Or should we use DT property to discern the need for this bit ?
>>>>>>
>>>>> That's the most common way to take into account peculiarities, add
>>>>> a property and handle it from the driver.
>>>> And by "that" you mean which of those two I listed , the
>>>> "snps,dw-mshc-vN" or adding new DT prop ?
>>>>
>>> I meant to add a new property, not a new compatible, but that's just
>>> my experience.
>>>
>>> Let me say it __might__ happen that a particular change you need is
>>> specific to a particular version of the DWMMC IP (query Synopsys
>>> by the way), but more probably it might be e.g. the same IP version with
>>> a different reduced or extended configuration or a minor fix/improvement
>>> to the IP block without resulting version number bump.
>>>
>>> For example I don't remember that errata fixes in IP blocks result in
>>> a new compatible, instead there are quite common optional "quirk"
>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>> Right, this very much matches how I see it as well. Thanks for confirming.
>>
>> Alexey, can you tell us if the requirement for setting
>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>> disappeared with some revision OR if this is some configuration
>> option of the core during synthesis ?
>
> Sorry for not following that discussion during my weekend but I'll try
> to address all questions now.
SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
But it's difficult to use the generic feature..because it's considered the below things.
If Card is SDR50/SDR104/DDR50 mode..
1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 0,
2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 1,
If Card is SDR12/SDR25 mode, then this bit is set to 1.
We need to check phase shift scheme..but as i knew, each SoC have been implemented differently for phase shift.
(Phase shift have dependency to SoC.)
And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
(It described whether IP have hold register or not)
I didn't read this thread entirely.
I'm not sure what you have discussed..but my understanding is right..i recommend to use "snps,dw-mshc" for ARC compat string.
Otherwise it need to add "dw_mmc-<SoC>.c". dw_mmc-pltfm.c should provide the basic dw-mmc controller functionality.
After read this thread entirely, i will check more detailed what you discussed.
If i missed something, let me know, plz.
Best Regards,
Jaehoon Chung
>
> DW Mobile Storage databook says:
> --------------------->8-----------------------
> To meet the relatively high Input Hold Time requirement for SDR12, SDR25,
> and other MMC speed modes, you should program bit[29]use_hold_Reg of the
> CMD register to 1'b1.
> --------------------->8-----------------------
>
> So I'd say this specific setting has nothing to do with a particular IP block
> but instead it is related to card's mode of operation. More precisely bus clock.
> SDR12 stands for 12.5 MByte/s, SDR25 stands for 25 MByte/s. I.e. we probably need
> so set that bit just for certain cases and regardless board that uses DW MMC.
>
> I'm adding DW MMC maintainer as well as linux-mmc mailing list so people who
> understands that stuff better may comment here as well.
>
> -Alexey--
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Hi+AKA-Jaehoon,
On Mon, 2016-03-28 at 19:34 +-0900, Jaehoon Chung wrote:
+AD4- Hi,
+AFs-snip+AF0-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- That said, I would rather prefer to see +ACI-snps,dw-mshc+ACI- prefix on description
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- of an MMC controller found on SoCFPGA series, +ACI-altr,socfpga-dw-mshc+ACI- seems
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- to be redundant.
+AD4- Yes..it's redundant..i should be combined to +ACI-snps,dw-mshc+ACI-.
So for socfpga platform compat string should be something like +ACI-snps,dw-mshc-socfpga+ACI- then?
+AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- According to drivers/mmc/host/dw+AF8-mmc-pltfm.c , the Altera SoCFPGA one
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +ACI-altr,socfpga-dw-mshc+ACI- and also Imagination Technology Pistacio one
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +ACI-img,pistachio-dw-mshc+ACI- need specialty bit (SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG),
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- while the stock one +ACI-snps,dw-mshc+ACI- does not. I am not sure if the ARC
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- one needs it as well, but most likely yes.
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- I wonder if that bit is needed on some particular version of the DWMMC
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- core. In that case, should we have +ACI-snps,dw-mshc+ACI- and +ACI-snps,dw-mshc-vN+ACI-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- binding ? Or should we use DT property to discern the need for this bit ?
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- That's the most common way to take into account peculiarities, add
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- a property and handle it from the driver.
+AD4- +AD4- +AD4- +AD4- +AD4- And by +ACI-that+ACI- you mean which of those two I listed , the
+AD4- +AD4- +AD4- +AD4- +AD4- +ACI-snps,dw-mshc-vN+ACI- or adding new DT prop ?
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- I meant to add a new property, not a new compatible, but that's just
+AD4- +AD4- +AD4- +AD4- my experience.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Let me say it +AF8AXw-might+AF8AXw- happen that a particular change you need is
+AD4- +AD4- +AD4- +AD4- specific to a particular version of the DWMMC IP (query Synopsys
+AD4- +AD4- +AD4- +AD4- by the way), but more probably it might be e.g. the same IP version with
+AD4- +AD4- +AD4- +AD4- a different reduced or extended configuration or a minor fix/improvement
+AD4- +AD4- +AD4- +AD4- to the IP block without resulting version number bump.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- For example I don't remember that errata fixes in IP blocks result in
+AD4- +AD4- +AD4- +AD4- a new compatible, instead there are quite common optional +ACI-quirk+ACI-
+AD4- +AD4- +AD4- +AD4- properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
+AD4- +AD4- +AD4- Right, this very much matches how I see it as well. Thanks for confirming.
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- Alexey, can you tell us if the requirement for setting
+AD4- +AD4- +AD4- SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG came with some new revision of the core or
+AD4- +AD4- +AD4- disappeared with some revision OR if this is some configuration
+AD4- +AD4- +AD4- option of the core during synthesis ?
+AD4- +AD4- Sorry for not following that discussion during my weekend but I'll try
+AD4- +AD4- to address all questions now.
+AD4- SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG didn't come with new revision..It's using continuously.
+AD4- But it's difficult to use the generic feature..because it's considered the below things.
+AD4-
+AD4- If Card is SDR50/SDR104/DDR50 mode..
+AD4- 1) and phase shift of cclk+AF8-in+AF8-drv is 0 then SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG bit is set to 0,
+AD4- 2) and phase shift of cclk+AF8-in+AF8-drv +AD4- 0 then SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG bit is set to 1,
+AD4- If Card is SDR12/SDR25 mode, then this bit is set to 1.
So card type is also important here and for certain card type we don't need to
set+AKA-SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG, right?
+AD4- We need to check phase shift scheme..but as i knew, each SoC have been implemented differently for phase shift.
+AD4- (Phase shift have dependency to SoC.)
Given my assumption above we need to check 2 things:
+AKAAKg- Card type
+AKAAKg- SoC-specific implementation detail (phase shift scheme)
+AD4- And it have to check HCON register..there is IMPLEMENT+AF8-HOLD+AF8-REG(bit+AFs-22+AF0-).
+AD4- (It described whether IP have hold register or not)
Ah actually 3 things
+AKAAKwCg-IMPLEMENT+AF8-HOLD+AF8-REG
+AD4- I didn't read this thread entirely.
+AD4- I'm not sure what you have discussed..but my understanding is right..i recommend to use +ACI-snps,dw-mshc+ACI- for ARC compat
+AD4- string.
+AD4- Otherwise it need to add +ACI-dw+AF8-mmc-+ADw-SoC+AD4-.c+ACI-. dw+AF8-mmc-pltfm.c should provide the basic dw-mmc controller functionality.
Hm, interesting looks like you already made some changes here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id+AD0-aaaaeb7a933471f6413ca44dd36efd57f2fa9429
So now driver checks if SoC has HOLD REG then SDMMC+AF8-CMD+AF8-USE+AF8-HOLD+AF8-REG will be set
(regardless card type).
And what's interesting and connected to this discussion since mentioned commit
there's no point in having both+AKAAIg-altr,socfpga-dw-mshc+ACI- and+AKAAIg-img,pistachio-dw-mshc+ACI-
compat strings because the do nothing now. I.e. it's time to replace both mentioned
compat strings with generic+AKAAIg-snps,dw-mshc+ACI-.
Anybody volunteers for that .dts+ACo- cleanup?
-Alexey
On 03/28/2016 07:55 PM, Alexey Brodkin wrote:
> Hi Jaehoon,
>
> On Mon, 2016-03-28 at 19:34 +0900, Jaehoon Chung wrote:
>> Hi,
>
> [snip]
>
>>>>>>>>>
>>>>>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>>>>>> to be redundant.
>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
>
> So for socfpga platform compat string should be something like "snps,dw-mshc-socfpga" then?
i think yes..since there is no SoC specific feature, isn't?
>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>>>>>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>>>>>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>>>>>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>>>>>>> one needs it as well, but most likely yes.
>>>>>>>>
>>>>>>>> I wonder if that bit is needed on some particular version of the DWMMC
>>>>>>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>>>>>>> binding ? Or should we use DT property to discern the need for this bit ?
>>>>>>>>
>>>>>>> That's the most common way to take into account peculiarities, add
>>>>>>> a property and handle it from the driver.
>>>>>> And by "that" you mean which of those two I listed , the
>>>>>> "snps,dw-mshc-vN" or adding new DT prop ?
>>>>>>
>>>>> I meant to add a new property, not a new compatible, but that's just
>>>>> my experience.
>>>>>
>>>>> Let me say it __might__ happen that a particular change you need is
>>>>> specific to a particular version of the DWMMC IP (query Synopsys
>>>>> by the way), but more probably it might be e.g. the same IP version with
>>>>> a different reduced or extended configuration or a minor fix/improvement
>>>>> to the IP block without resulting version number bump.
>>>>>
>>>>> For example I don't remember that errata fixes in IP blocks result in
>>>>> a new compatible, instead there are quite common optional "quirk"
>>>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>>
>>>> Alexey, can you tell us if the requirement for setting
>>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>>> disappeared with some revision OR if this is some configuration
>>>> option of the core during synthesis ?
>>> Sorry for not following that discussion during my weekend but I'll try
>>> to address all questions now.
>> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
>> But it's difficult to use the generic feature..because it's considered the below things.
>>
>> If Card is SDR50/SDR104/DDR50 mode..
>> 1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 0,
>> 2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 1,
>> If Card is SDR12/SDR25 mode, then this bit is set to 1.
>
> So card type is also important here and for certain card type we don't need to
> set SDMMC_CMD_USE_HOLD_REG, right?
If you means card-type is card's speed mode, right..it's important.
In IP Databook, not mentioned about HS200 or HS400, but i thinks it doesn't need to set USE_HOLD_REG.
Because higher speed mode than 50MHz should be required the lowest input hold time. (~0.8ns)
>
>> We need to check phase shift scheme..but as i knew, each SoC have been implemented differently for phase shift.
>> (Phase shift have dependency to SoC.)
>
> Given my assumption above we need to check 2 things:
> * Card type
> * SoC-specific implementation detail (phase shift scheme)
In Exynos's case, there is CLKSEL register in DWMMC IP register.(as Vendor specific register.)
On other hands, rockchip is handling the phase sfiht with "clk_set_phase()"(as CMU.)
I can't know everything how they're implementing for shifting phase..
>
>> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
>> (It described whether IP have hold register or not)
>
> Ah actually 3 things
> + IMPLEMENT_HOLD_REG
Almost all have IMPLEMENT_HOLD_REG...?
If i will implement... in dw-mmc.c
switch (ios->timing) {
case SDR50/DDR50/.../
if (check cclk_in_drv > 0 for each SoC) {
SDMMC_CMD_USE_HOLD_REG is set to 1
break;
}
case SDR12/SD25
SDMMC_CMD_USE_HOLD_REG is set to 1
default:
SDMMC_CMD_USE_HOLD_REG is set to 0.
}
>
>> I didn't read this thread entirely.
>> I'm not sure what you have discussed..but my understanding is right..i recommend to use "snps,dw-mshc" for ARC compat
>> string.
>> Otherwise it need to add "dw_mmc-<SoC>.c". dw_mmc-pltfm.c should provide the basic dw-mmc controller functionality.
>
> Hm, interesting looks like you already made some changes here:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aaaaeb7a933471f6413ca44dd36efd57f2fa9429
>
> So now driver checks if SoC has HOLD REG then SDMMC_CMD_USE_HOLD_REG will be set
> (regardless card type).
Yes, it's used by default..
Except exynos, other SoCs need to set this bit until now..otherwise it will be occurred CRC error. (Rockchip, Socfpga..)
>
> And what's interesting and connected to this discussion since mentioned commit
> there's no point in having both "altr,socfpga-dw-mshc" and "img,pistachio-dw-mshc"
> compat strings because the do nothing now. I.e. it's time to replace both mentioned
> compat strings with generic "snps,dw-mshc".
>
> Anybody volunteers for that .dts* cleanup?
If have spare time to do cleanup, i will do for mshc compatible.
Best Regards,
Jaehoon Chung
>
> -Alexey--
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
On Mon, Mar 28, 2016 at 5:34 AM, Jaehoon Chung <[email protected]> wrote:
> Hi,
>
> On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
>> Hi Marek, Vladimir,
>>
>> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
>>>>
>>>> On 26.03.2016 21:52, Marek Vasut wrote:
>>>>>
>>>>> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>>>>>
>>>>>> On 26.03.2016 20:10, Marek Vasut wrote:
>>>>>>>
>>>>>>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>>>>>>>
>>>>>>>> Hi Marek,
>>>>>>>>
>>>>>>>> On 26.03.2016 19:30, Marek Vasut wrote:
>>>>>>>>>
>>>>>>>>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>>>>>>>>
>>>>>>>>>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi!
>>>>>>>>>>>
>>>>>>>>>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>>>>>>>>>> the DT compatible string:
>>>>>>>>>>>
>>>>>>>>>>> mmc@0x15000 {
>>>>>>>>>>> compatible = "altr,socfpga-dw-mshc";
>>>>>>>>>>> reg = < 0x15000 0x400 >;
>>>>>>>>>>> num-slots = < 1 >;
>>>>>>>>>>> fifo-depth = < 16 >;
>>>>>>>>>>> card-detect-delay = < 200 >;
>>>>>>>>>>> clocks = <&apbclk>, <&mmcclk>;
>>>>>>>>>>> clock-names = "biu", "ciu";
>>>>>>>>>>> interrupts = < 7 >;
>>>>>>>>>>> bus-width = < 4 >;
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>>>>>>>>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>>>>>>>>>> should be extended with another compatibility string, something like
>>>>>>>>>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>>>>>>>>>> accordingly. What do you think ?
>>>>>>>>>>>
>>>>>>>>>> There is "snps,dw-mshc" described in
>>>>>>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>>>>>>>>>> dw_mmc host controller driver.
>>>>>>>>> Thanks, that's even better.
>>>>>>>>>
>>>>>>>>> btw what do you think of using altr, prefix on non-altera system, that
>>>>>>>>> doesn't seem ok, right ?
>>>>>>>> according to ePAPR the prefix should represent a device (IP block here
>>>>>>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>>>>>>> non-Altera system, if Altera provides another hardware vendor with
>>>>>>>> some own IP block.
>>>>>>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>>>>>>> chip makers (Altera etc).
>>>>>> Correct.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>>>>> to be redundant.
>
> Yes..it's redundant..i should be combined to "snps,dw-mshc".
socfpga is done correctly, IMO.
>>>>>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>>>>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>>>>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>>>>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>>>>>> one needs it as well, but most likely yes.
>>>>>>>
>>>>>>> I wonder if that bit is needed on some particular version of the DWMMC
>>>>>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>>>>>> binding ? Or should we use DT property to discern the need for this bit ?
>>>>>>>
>>>>>> That's the most common way to take into account peculiarities, add
>>>>>> a property and handle it from the driver.
>>>>> And by "that" you mean which of those two I listed , the
>>>>> "snps,dw-mshc-vN" or adding new DT prop ?
>>>>>
>>>> I meant to add a new property, not a new compatible, but that's just
>>>> my experience.
>>>>
>>>> Let me say it __might__ happen that a particular change you need is
>>>> specific to a particular version of the DWMMC IP (query Synopsys
>>>> by the way), but more probably it might be e.g. the same IP version with
>>>> a different reduced or extended configuration or a minor fix/improvement
>>>> to the IP block without resulting version number bump.
>>>>
>>>> For example I don't remember that errata fixes in IP blocks result in
>>>> a new compatible, instead there are quite common optional "quirk"
>>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>
>>> Alexey, can you tell us if the requirement for setting
>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>> disappeared with some revision OR if this is some configuration
>>> option of the core during synthesis ?
>>
>> Sorry for not following that discussion during my weekend but I'll try
>> to address all questions now.
>
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the below things.
>
> If Card is SDR50/SDR104/DDR50 mode..
> 1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 0,
> 2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 1,
> If Card is SDR12/SDR25 mode, then this bit is set to 1.
>
> We need to check phase shift scheme..but as i knew, each SoC have been implemented differently for phase shift.
> (Phase shift have dependency to SoC.)
>
> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
> (It described whether IP have hold register or not)
>
> I didn't read this thread entirely.
> I'm not sure what you have discussed..but my understanding is right..i recommend to use "snps,dw-mshc" for ARC compat string.
> Otherwise it need to add "dw_mmc-<SoC>.c". dw_mmc-pltfm.c should provide the basic dw-mmc controller functionality.
You should use "snps,dw-mshc", but there should also be an SoC
specific compatible string. There are always integration differences
and even using just versions of IP blocks is not specific enough. This
should not require another driver file.
Rob
On 03/28/2016 02:43 PM, Rob Herring wrote:
> On Mon, Mar 28, 2016 at 5:34 AM, Jaehoon Chung <[email protected]> wrote:
>> Hi,
>>
>> On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
>>> Hi Marek, Vladimir,
>>>
>>> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>>>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
>>>>>
>>>>> On 26.03.2016 21:52, Marek Vasut wrote:
>>>>>>
>>>>>> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>>>>>>
>>>>>>> On 26.03.2016 20:10, Marek Vasut wrote:
>>>>>>>>
>>>>>>>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>>>>>>>>
>>>>>>>>> Hi Marek,
>>>>>>>>>
>>>>>>>>> On 26.03.2016 19:30, Marek Vasut wrote:
>>>>>>>>>>
>>>>>>>>>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi!
>>>>>>>>>>>>
>>>>>>>>>>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix in
>>>>>>>>>>>> the DT compatible string:
>>>>>>>>>>>>
>>>>>>>>>>>> mmc@0x15000 {
>>>>>>>>>>>> compatible = "altr,socfpga-dw-mshc";
>>>>>>>>>>>> reg = < 0x15000 0x400 >;
>>>>>>>>>>>> num-slots = < 1 >;
>>>>>>>>>>>> fifo-depth = < 16 >;
>>>>>>>>>>>> card-detect-delay = < 200 >;
>>>>>>>>>>>> clocks = <&apbclk>, <&mmcclk>;
>>>>>>>>>>>> clock-names = "biu", "ciu";
>>>>>>>>>>>> interrupts = < 7 >;
>>>>>>>>>>>> bus-width = < 4 >;
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>>>>>>>>>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>>>>>>>>>>> should be extended with another compatibility string, something like
>>>>>>>>>>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>>>>>>>>>>> accordingly. What do you think ?
>>>>>>>>>>>>
>>>>>>>>>>> There is "snps,dw-mshc" described in
>>>>>>>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and supported by
>>>>>>>>>>> dw_mmc host controller driver.
>>>>>>>>>> Thanks, that's even better.
>>>>>>>>>>
>>>>>>>>>> btw what do you think of using altr, prefix on non-altera system, that
>>>>>>>>>> doesn't seem ok, right ?
>>>>>>>>> according to ePAPR the prefix should represent a device (IP block here
>>>>>>>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>>>>>>>> non-Altera system, if Altera provides another hardware vendor with
>>>>>>>>> some own IP block.
>>>>>>>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>>>>>>>> chip makers (Altera etc).
>>>>>>> Correct.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>>>>>> to be redundant.
>>
>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
>
> socfpga is done correctly, IMO.
>
>>>>>>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>>>>>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>>>>>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>>>>>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>>>>>>> one needs it as well, but most likely yes.
>>>>>>>>
>>>>>>>> I wonder if that bit is needed on some particular version of the DWMMC
>>>>>>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>>>>>>> binding ? Or should we use DT property to discern the need for this bit ?
>>>>>>>>
>>>>>>> That's the most common way to take into account peculiarities, add
>>>>>>> a property and handle it from the driver.
>>>>>> And by "that" you mean which of those two I listed , the
>>>>>> "snps,dw-mshc-vN" or adding new DT prop ?
>>>>>>
>>>>> I meant to add a new property, not a new compatible, but that's just
>>>>> my experience.
>>>>>
>>>>> Let me say it __might__ happen that a particular change you need is
>>>>> specific to a particular version of the DWMMC IP (query Synopsys
>>>>> by the way), but more probably it might be e.g. the same IP version with
>>>>> a different reduced or extended configuration or a minor fix/improvement
>>>>> to the IP block without resulting version number bump.
>>>>>
>>>>> For example I don't remember that errata fixes in IP blocks result in
>>>>> a new compatible, instead there are quite common optional "quirk"
>>>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>>
>>>> Alexey, can you tell us if the requirement for setting
>>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>>> disappeared with some revision OR if this is some configuration
>>>> option of the core during synthesis ?
>>>
>>> Sorry for not following that discussion during my weekend but I'll try
>>> to address all questions now.
>>
>> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
>> But it's difficult to use the generic feature..because it's considered the below things.
>>
>> If Card is SDR50/SDR104/DDR50 mode..
>> 1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 0,
>> 2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 1,
>> If Card is SDR12/SDR25 mode, then this bit is set to 1.
>>
>> We need to check phase shift scheme..but as i knew, each SoC have been implemented differently for phase shift.
>> (Phase shift have dependency to SoC.)
>>
>> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
>> (It described whether IP have hold register or not)
>>
>> I didn't read this thread entirely.
>> I'm not sure what you have discussed..but my understanding is right..i recommend to use "snps,dw-mshc" for ARC compat string.
>> Otherwise it need to add "dw_mmc-<SoC>.c". dw_mmc-pltfm.c should provide the basic dw-mmc controller functionality.
>
> You should use "snps,dw-mshc", but there should also be an SoC
> specific compatible string. There are always integration differences
> and even using just versions of IP blocks is not specific enough. This
> should not require another driver file.
This is exactly what I wanted to learn in this thread, thank you!
I knew I heard this argument somewhere already, but now I have it
confirmed that adding at least one SoC-specific compat is the way
to do it.
> Rob
>
--
Best regards,
Marek Vasut
On 03/28/2016 12:34 PM, Jaehoon Chung wrote:
> Hi,
Hi,
[...]
>>>>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>>>>> to be redundant.
>
> Yes..it's redundant..i should be combined to "snps,dw-mshc".
Should the compat string be
compatible = "altr,socfpga-dw-mshc", "snps,dw-mshc";
or just
compatible = "snps,dw-mshc";
?
I am under the impression that a soc-specific identifier in addition to
a generic one (used by the driver compat table) is a good idea, because
it can help discerning the IP block from a generic one if needed at some
future point in time. It will also not break the DT for systems
which may depend on the non-generic compat, like *BSDs and such.
What do you think ? (btw this is very much my question in this thread)
>>>>>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>>>>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>>>>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>>>>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>>>>>> one needs it as well, but most likely yes.
>>>>>>>
>>>>>>> I wonder if that bit is needed on some particular version of the DWMMC
>>>>>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>>>>>> binding ? Or should we use DT property to discern the need for this bit ?
>>>>>>>
>>>>>> That's the most common way to take into account peculiarities, add
>>>>>> a property and handle it from the driver.
>>>>> And by "that" you mean which of those two I listed , the
>>>>> "snps,dw-mshc-vN" or adding new DT prop ?
>>>>>
>>>> I meant to add a new property, not a new compatible, but that's just
>>>> my experience.
>>>>
>>>> Let me say it __might__ happen that a particular change you need is
>>>> specific to a particular version of the DWMMC IP (query Synopsys
>>>> by the way), but more probably it might be e.g. the same IP version with
>>>> a different reduced or extended configuration or a minor fix/improvement
>>>> to the IP block without resulting version number bump.
>>>>
>>>> For example I don't remember that errata fixes in IP blocks result in
>>>> a new compatible, instead there are quite common optional "quirk"
>>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>
>>> Alexey, can you tell us if the requirement for setting
>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>> disappeared with some revision OR if this is some configuration
>>> option of the core during synthesis ?
>>
>> Sorry for not following that discussion during my weekend but I'll try
>> to address all questions now.
>
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the below things.
>
> If Card is SDR50/SDR104/DDR50 mode..
> 1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 0,
> 2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 1,
> If Card is SDR12/SDR25 mode, then this bit is set to 1.
>
> We need to check phase shift scheme..but as i knew, each SoC have been implemented differently for phase shift.
> (Phase shift have dependency to SoC.)
>
> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
> (It described whether IP have hold register or not)
>
> I didn't read this thread entirely.
> I'm not sure what you have discussed..but my understanding is right..i recommend to use "snps,dw-mshc" for ARC compat string.
> Otherwise it need to add "dw_mmc-<SoC>.c". dw_mmc-pltfm.c should provide the basic dw-mmc controller functionality.
>
> After read this thread entirely, i will check more detailed what you discussed.
> If i missed something, let me know, plz.
Thanks for the clarification, linux-next indeed contains changes which
make snps,dw-mshc and altr,socfpga-dw-mshc equal.
> Best Regards,
> Jaehoon Chung
>
>>
>> DW Mobile Storage databook says:
>> --------------------->8-----------------------
>> To meet the relatively high Input Hold Time requirement for SDR12, SDR25,
>> and other MMC speed modes, you should program bit[29]use_hold_Reg of the
>> CMD register to 1'b1.
>> --------------------->8-----------------------
>>
>> So I'd say this specific setting has nothing to do with a particular IP block
>> but instead it is related to card's mode of operation. More precisely bus clock.
>> SDR12 stands for 12.5 MByte/s, SDR25 stands for 25 MByte/s. I.e. we probably need
>> so set that bit just for certain cases and regardless board that uses DW MMC.
>>
>> I'm adding DW MMC maintainer as well as linux-mmc mailing list so people who
>> understands that stuff better may comment here as well.
>>
>> -Alexey--
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
--
Best regards,
Marek Vasut
Hi,
On 28.03.2016 15:50, Marek Vasut wrote:
> On 03/28/2016 12:34 PM, Jaehoon Chung wrote:
>> Hi,
>
> Hi,
>
> [...]
>
>>>>>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>>>>>> to be redundant.
>>
>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
>
> Should the compat string be
> compatible = "altr,socfpga-dw-mshc", "snps,dw-mshc";
> or just
> compatible = "snps,dw-mshc";
> ?
>
> I am under the impression that a soc-specific identifier in addition to
> a generic one (used by the driver compat table) is a good idea, because
> it can help discerning the IP block from a generic one if needed at some
> future point in time. It will also not break the DT for systems
> which may depend on the non-generic compat, like *BSDs and such.
>
> What do you think ? (btw this is very much my question in this thread)
IMO just 'compatible = "snps,dw-mshc"' is good enough, if it completely
describes the IP block on SoCFGPA --- and from what I get it is the case.
You can add a SoC-specific compatible if it is needed later on, and to my
taste only if SoC specific features can not be covered by properties.
The same sole "snps,dw-mshc" compatible is specified for NXP LPC18xx/43xx,
ZTE ZX and HiSilicon ARM SoCs.
Another similar example is ARM PrimeCell PLxxx IP blocks, as far as
I know there is no SoC-specific compatibles/aliases for PrimeCell IP blocks.
Rob, please correct me.
>>>>>>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>>>>>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>>>>>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>>>>>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>>>>>>> one needs it as well, but most likely yes.
>>>>>>>>
>>>>>>>> I wonder if that bit is needed on some particular version of the DWMMC
>>>>>>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>>>>>>> binding ? Or should we use DT property to discern the need for this bit ?
>>>>>>>>
>>>>>>> That's the most common way to take into account peculiarities, add
>>>>>>> a property and handle it from the driver.
>>>>>> And by "that" you mean which of those two I listed , the
>>>>>> "snps,dw-mshc-vN" or adding new DT prop ?
>>>>>>
>>>>> I meant to add a new property, not a new compatible, but that's just
>>>>> my experience.
>>>>>
>>>>> Let me say it __might__ happen that a particular change you need is
>>>>> specific to a particular version of the DWMMC IP (query Synopsys
>>>>> by the way), but more probably it might be e.g. the same IP version with
>>>>> a different reduced or extended configuration or a minor fix/improvement
>>>>> to the IP block without resulting version number bump.
>>>>>
>>>>> For example I don't remember that errata fixes in IP blocks result in
>>>>> a new compatible, instead there are quite common optional "quirk"
>>>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>>
>>>> Alexey, can you tell us if the requirement for setting
>>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>>> disappeared with some revision OR if this is some configuration
>>>> option of the core during synthesis ?
>>>
>>> Sorry for not following that discussion during my weekend but I'll try
>>> to address all questions now.
>>
>> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
>> But it's difficult to use the generic feature..because it's considered the below things.
>>
>> If Card is SDR50/SDR104/DDR50 mode..
>> 1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 0,
>> 2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit is set to 1,
>> If Card is SDR12/SDR25 mode, then this bit is set to 1.
>>
>> We need to check phase shift scheme..but as i knew, each SoC have been implemented differently for phase shift.
>> (Phase shift have dependency to SoC.)
>>
>> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
>> (It described whether IP have hold register or not)
>>
>> I didn't read this thread entirely.
>> I'm not sure what you have discussed..but my understanding is right..i recommend to use "snps,dw-mshc" for ARC compat string.
>> Otherwise it need to add "dw_mmc-<SoC>.c". dw_mmc-pltfm.c should provide the basic dw-mmc controller functionality.
>>
>> After read this thread entirely, i will check more detailed what you discussed.
>> If i missed something, let me know, plz.
>
> Thanks for the clarification, linux-next indeed contains changes which
> make snps,dw-mshc and altr,socfpga-dw-mshc equal.
>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> DW Mobile Storage databook says:
>>> --------------------->8-----------------------
>>> To meet the relatively high Input Hold Time requirement for SDR12, SDR25,
>>> and other MMC speed modes, you should program bit[29]use_hold_Reg of the
>>> CMD register to 1'b1.
>>> --------------------->8-----------------------
>>>
>>> So I'd say this specific setting has nothing to do with a particular IP block
>>> but instead it is related to card's mode of operation. More precisely bus clock.
>>> SDR12 stands for 12.5 MByte/s, SDR25 stands for 25 MByte/s. I.e. we probably need
>>> so set that bit just for certain cases and regardless board that uses DW MMC.
>>>
>>> I'm adding DW MMC maintainer as well as linux-mmc mailing list so people who
>>> understands that stuff better may comment here as well.
>>>
>>> -Alexey--
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>
>
--
With best wishes,
Vladimir
On Mon, Mar 28, 2016 at 11:16 AM, Vladimir Zapolskiy
<[email protected]> wrote:
> Hi,
>
> On 28.03.2016 15:50, Marek Vasut wrote:
>> On 03/28/2016 12:34 PM, Jaehoon Chung wrote:
>>> Hi,
>>
>> Hi,
>>
>> [...]
>>
>>>>>>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>>>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>>>>>>> to be redundant.
>>>
>>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
>>
>> Should the compat string be
>> compatible = "altr,socfpga-dw-mshc", "snps,dw-mshc";
>> or just
>> compatible = "snps,dw-mshc";
>> ?
>>
>> I am under the impression that a soc-specific identifier in addition to
>> a generic one (used by the driver compat table) is a good idea, because
>> it can help discerning the IP block from a generic one if needed at some
>> future point in time. It will also not break the DT for systems
>> which may depend on the non-generic compat, like *BSDs and such.
>>
>> What do you think ? (btw this is very much my question in this thread)
>
> IMO just 'compatible = "snps,dw-mshc"' is good enough, if it completely
> describes the IP block on SoCFGPA --- and from what I get it is the case.
> You can add a SoC-specific compatible if it is needed later on, and to my
> taste only if SoC specific features can not be covered by properties.
You can add the SoC-specific compatible string to the kernel later on.
You may not be able to update your DTB later on. So the specific
compatible strings need to be in the DT from the start.
There's no set rule on properties vs. implied by a compatible string,
but generally if it is fixed in the SoC, get the information based on
the compatible string. If it is a board level decision or has to be
tuned, then use a property.
> The same sole "snps,dw-mshc" compatible is specified for NXP LPC18xx/43xx,
> ZTE ZX and HiSilicon ARM SoCs.
They should be fixed.
> Another similar example is ARM PrimeCell PLxxx IP blocks, as far as
> I know there is no SoC-specific compatibles/aliases for PrimeCell IP blocks.
There are some for ST variants I think. PrimeCell blocks are a bit
different in that they generally pretty simple blocks, have not
changed much, and they
have a standard ID register that has been sufficient for determining
differences. And we have a standard way to override the ID register
when it is wrong. Look at recent patches for Denali NAND controller if
you want an example of why IP version registers (or compatible
strings) can't be trusted.
Once you get into IP blocks with lots of configuration options,
complicated clocking, power domains, and with phys on the front end,
then you hit all the integration differences.
Rob