[PATCH 3/7] mmc: dw_mmc: add device tree support

[Thomas Abraham]

On 10 May 2012 15:29, Kyungmin Park <kmpark at infradead.org> wrote:
> On 5/10/12, Thomas Abraham <thomas.abraham at linaro.org> wrote:
>> Dear Mr. Park,
>>
>> On 2 May 2012 12:25, Kyungmin Park <kmpark at infradead.org> wrote:
>>> Hi,

[...]

>>> I googled the "Synopsis Designware Mobile Storage Host Controller" and
>>> Synopsis released it as this name. but still I like the 'dw-mmc'
>>> instead of'dw-mshc'.
>>
>> Ok. Synopsis abbreviates this controller as MSHC in their datasheets
>> available online. Since device tree is more about describing the
>> hardware, using MSHC as the abbreviation will help with correlating
>> hardware specs with the dts file. So I would prefer to continue using
>> mshc as the abbreviation.
>
> Then why author of this file uses "dw-mmc" instead of "dw-mshc"? and
> it uses 'dw_mci' prefix at functions. I just worried and don't want to
> give confusion to users who uses this device.

The device tree source files are independent of any OS specific
implementations. The linux driver for this controller uses dw-mmc and
dw_mci but drivers of this controller for other operating systems
could choose use other names. Since Synopsis calls this controller as
mshc, the dts file would be closer to hardware specs if 'mshc' is used
to describe the controller.

[...]

>>>> +/* Variations in the dw_mci controller */
>>>> +#define DW_MCI_TYPE_SYNOPSIS         0
>>>> +#define DW_MCI_TYPE_EXYNOS5250               1 /* Samsung Exynos5250
>>>> Extensions */
>>> Um. it's not good idea to add specific SOC version. And as you know,
>>> exynos4 series has this controller.
>>
>> There are some differences between the Exynos4 and Exynos5 mshc
>> controllers. For instance, the DIVRATIO field in the CLKSEL register
>> is available only in Exynos5 and there are 8 phase shift values in
>> Exynos5 when compared to 4 phase shift values in Exynos4. Likewise,
>> there are some other differences. So to handle these specific
>> implementations, we need to define types (or variants) of the
>> controller. Using SoC names for the type would help in readability of
>> the different types of implementations that are defined. So I would
>> prefer to continue using SoC names for this.
>
> You mean if it supports the exynos4, then it should be add exynos4 type?
>

If the existing driver requires any Exynos4 specific extensions to
operate the controller correctly on Exynos4, then yes we should add a
Exynos4 type. The Exynos4 and Exynos5 implementations of this
controller vary in certain aspects and so we might need a Exynos4 type
as well.

Thanks,
Thomas.

[...]