? 2015/8/5 16:45, Heiko St?bner ??:
> Am Mittwoch, 5. August 2015, 16:43:20 schrieb Shawn Lin:
>> ? 2015/8/5 16:27, Krzysztof Kozlowski ??:
>>> On 05.08.2015 17:17, Shawn Lin wrote:
>>>> synopsys-dw-mshc supports three types of transfer mode. We add bindings
>>>> and description for how to use them at runtime. Without idmac and edmac
>>>> property, pio is the default transfer mode. Make sure that Idmac and
>>>> emdac
>>>> should not be used simultaneously.
>>>>
>>>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>>>> ---
>>>>
>>>> Changes in v3: None
>>>> Changes in v2: None
>>>>
>>>> .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 41
>>>> ++++++++++++++++++++++ 1 file changed, 41 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
>>>> b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt index
>>>> 346c609..30369cb 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
>>>> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
>>>>
>>>> @@ -75,6 +75,25 @@ Optional properties:
>>>> * vmmc-supply: The phandle to the regulator to use for vmmc. If this
>>>> is
>>>>
>>>> specified we'll defer probe until we can find this regulator.
>>>>
>>>> +* supports-idmac: Enables support for internal DMAC block within the
>>>> Synopsys + Designware Mobile Storage IP block. If supports-idmac
>>>> property is present, then + we MUST NOT add supports-edmac property
>>>> since we'd assume that dw-mshc IP is + integrated with only one type of
>>>> dma master.
>>>> +
>>>> +* supports-edmac: Enables support for external DMAC block outside the
>>>> Synopsys + Designware Mobile Storage IP block. If supports-edmac
>>>> property is present, then + we MUST NOT add supports-idmac property
>>>> since we'd assume that dw-mshc IP is + integrated with only one type of
>>>> dma master.
>>>> +
>>>> + (Without "supports-idmac" and "supports-edmac", use PIO as default
>>>> transfer mode)>
>>> Aren't you breaking here backward compatibility with existing DTB?
>>>
>>> Best regards,
>>> Krzysztof
>> Thanks, Krzysztof.
>> I guess you mean that I should keep existing DTB w/o these two
>> properties work fine using idmac?
> yep
Okay, I got it.
>
>>>> +
>>>> +* dmas: List of DMA specifiers with the controller specific format as
>>>> described + in the generic DMA client binding. This property should be
>>>> combined with + supports-edmac. Refer to dma.txt for details.
>>>> +
>>>> +* dma-names: DMA request names. Must be "rx-tx". And This property
>>>> should be + combined with supports-edmac. Refer to dma.txt for details.
>>>> +
> Similarly the use of an external dmac could simply be detected, by the
> presence of the dma-* properties. So when the machine defines dma channels use
> the external dma, otherwise the internal (or none). So you wouldn't need
> separate new properties at all.
Thanks, Heiko. I understand your point.
It will be done in v4.
>
>>>> Aliases:
>>>>
>>>> - All the MSHC controller nodes should be represented in the aliases
>>>> node using>>
>>>> @@ -95,6 +114,8 @@ board specific portions as listed below.
>>>>
>>>> #size-cells = <0>;
>>>>
>>>> };
>>>>
>>>> +[board specific internal DMA resources]
>>>> +
>>>>
>>>> dwmmc0 at 12200000 {
>>>>
>>>> clock-frequency = <400000000>;
>>>> clock-freq-min-max = <400000 200000000>;
>>>>
>>>> @@ -106,4 +127,24 @@ board specific portions as listed below.
>>>>
>>>> bus-width = <8>;
>>>> cap-mmc-highspeed;
>>>> cap-sd-highspeed;
>>>>
>>>> + supports-idmac;
>>>>
>>>> };
>>>>
>>>> +
>>>> +[board specific generic DMA request binding]
>>>> +
>>>> + dwmmc0 at 12200000 {
>>>> + clock-frequency = <400000000>;
>>>> + clock-freq-min-max = <400000 200000000>;
>>>> + num-slots = <1>;
>>>> + broken-cd;
>>>> + fifo-depth = <0x80>;
>>>> + card-detect-delay = <200>;
>>>> + vmmc-supply = <&buck8>;
>>>> + bus-width = <8>;
>>>> + cap-mmc-highspeed;
>>>> + cap-sd-highspeed;
>>>> + supports-edmac;
>>>> + dmas = <&pdma 12>;
>>>> + dma-names = "rx-tx";
>>>> + };
>>>> +
>
>
>
--
Shawn Lin
