Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
On 13 May 2012 01:01, Guennadi Liakhovetski wrote: > Sure. I think, my patch, that I mentioned above, shall be dropped, at > least in its present form. But if at least in principle we do want to have > a common MMC OF parser for common bindings, some code from your patch > would become redundant, I think. BTW, isn't this > > + gpio = of_get_named_gpio(np, "wp_gpios", 0); > > a typo? Shouldn't it be "wp-gpios" instead? Yes, it is a typo. Thanks for your review. This is fixed now. Regards, Thomas. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
Hi Thomas On Sat, 12 May 2012, Thomas Abraham wrote: > On 4 May 2012 04:18, Guennadi Liakhovetski wrote: > > > > What do you think about this patch > > > > http://www.spinics.net/lists/linux-sh/msg11259.html > > > > and about using mmc-generic OF properties instead of creating yet another > > copy of proprietary ones? > > Hi Guennadi, > > This patch does not intend to add any custom mmc properties. I checked > your patch (in the link mentioned above) and most of the bindings are > similar to what you have come up with except for the "ro-gpios" for > which I have used "wp-gpios". But this is following what Arnd had > proposed here: http://www.spinics.net/lists/linux-mmc/msg13564.html. Thanks for the link! I didn't know about that patch. > Regarding the MMC_CAP_4_BIT_DATA and MMC_CAP_8_BIT_DATA in your patch, > these can be derived from the bus width information that the driver > receives. Sure. I think, my patch, that I mentioned above, shall be dropped, at least in its present form. But if at least in principle we do want to have a common MMC OF parser for common bindings, some code from your patch would become redundant, I think. BTW, isn't this + gpio = of_get_named_gpio(np, "wp_gpios", 0); a typo? Shouldn't it be "wp-gpios" instead? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
On 12 May 2012 12:37, Olof Johansson wrote:
> Hi,
>
> On Thu, May 10, 2012 at 3:15 AM, Thomas Abraham
> wrote:
>> Hi Olof,
>>
>> On 2 May 2012 23:37, Olof Johansson wrote:
>>> Hi,
>>
>> [...]
>>
+# Slots: The slot specific information are contained within child-nodes
with
+ each child-node representing a supported slot. There should be atleast
one
+ child node representing a card slot. The name of the slot child node
should
+ be 'slot{n}' where n is the unique number of the slot connnected to the
+ controller. The following are optional properties which can be included
in
+ the slot child node.
>>>
>>> Since we're talking slots / cards on a bus, I think the addressing
>>> model would be useful here. So in the main controller node:
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> And then each slot would need a reg property and possibly unit address:
>>>
>>> slot {
>>> reg = <0>;
>>> ...
>>> };
>>>
>>> (unit addresses on the slots are only needed if they can't be
>>> disambiguated by name, so not needed if you only have one slot).
>>>
>>
>> Is the addressing model as described above needed in this case? The
>> address for a slot is not used by the controller driver code and is
>> just a virtual number. It would be sufficient to represent the nodes
>> representing the slots with a unique name.
>
> The driver has the concept of slot IDs (slot->id struct member), and
> the hardware definitely enumerates them.
>
> So, I think it makes sense to give a chance to enumerate the slots in
> the device tree. Otherwise, how do you know which one is which on
> hardware? It also opens up the flexibility to have the same name for
> both slots if it makes sense to describe a board that way.
Thanks Olof. Yes, I missed the usage of the id number in the driver. I
will add the slot addressing as you have suggested and repost.
Thanks,
Thomas.
>
>
> -Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
Hi,
On Thu, May 10, 2012 at 3:15 AM, Thomas Abraham
wrote:
> Hi Olof,
>
> On 2 May 2012 23:37, Olof Johansson wrote:
>> Hi,
>
> [...]
>
>>> +# Slots: The slot specific information are contained within child-nodes
>>> with
>>> + each child-node representing a supported slot. There should be atleast
>>> one
>>> + child node representing a card slot. The name of the slot child node
>>> should
>>> + be 'slot{n}' where n is the unique number of the slot connnected to the
>>> + controller. The following are optional properties which can be included
>>> in
>>> + the slot child node.
>>
>> Since we're talking slots / cards on a bus, I think the addressing
>> model would be useful here. So in the main controller node:
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> And then each slot would need a reg property and possibly unit address:
>>
>> slot {
>> reg = <0>;
>> ...
>> };
>>
>> (unit addresses on the slots are only needed if they can't be
>> disambiguated by name, so not needed if you only have one slot).
>>
>
> Is the addressing model as described above needed in this case? The
> address for a slot is not used by the controller driver code and is
> just a virtual number. It would be sufficient to represent the nodes
> representing the slots with a unique name.
The driver has the concept of slot IDs (slot->id struct member), and
the hardware definitely enumerates them.
So, I think it makes sense to give a chance to enumerate the slots in
the device tree. Otherwise, how do you know which one is which on
hardware? It also opens up the flexibility to have the same name for
both slots if it makes sense to describe a board that way.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
On 4 May 2012 04:18, Guennadi Liakhovetski wrote: > > What do you think about this patch > > http://www.spinics.net/lists/linux-sh/msg11259.html > > and about using mmc-generic OF properties instead of creating yet another > copy of proprietary ones? Hi Guennadi, This patch does not intend to add any custom mmc properties. I checked your patch (in the link mentioned above) and most of the bindings are similar to what you have come up with except for the "ro-gpios" for which I have used "wp-gpios". But this is following what Arnd had proposed here: http://www.spinics.net/lists/linux-mmc/msg13564.html. Regarding the MMC_CAP_4_BIT_DATA and MMC_CAP_8_BIT_DATA in your patch, these can be derived from the bus width information that the driver receives. Thanks, Thomas. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
On 10 May 2012 16:02, James Hogan wrote:
> Hi
>
> On 2 May 2012 06:07, Thomas Abraham wrote:
>> Add device tree based discovery support.
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
>> drivers/mmc/host/dw_mmc-pltfm.c | 24 +++
>> drivers/mmc/host/dw_mmc.c | 181
>> +++-
>> drivers/mmc/host/dw_mmc.h | 10 +
>> include/linux/mmc/dw_mmc.h | 2 +
>> 5 files changed, 296 insertions(+), 6 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>> new file mode 100644
>> index 000..c1ed70e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>> @@ -0,0 +1,85 @@
>> +* Synopsis Designware Mobile Storage Host Controller
>> +
>> +The Synopsis designware mobile storage host controller is used to interface
>> +a SoC with storage medium such as eMMC or SD/MMC cards.
>> +
>> +Required Properties:
>> +
>> +* compatible: should be one of the following
>> + - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
>
> Note that although undocumented in
> Documentation/devicetree/bindings/vendor-prefixes.txt (which it
> probably should be), the designware uart already uses a different
> prefix:
> { .compatible = "snps,dw-apb-uart" },
> http://lxr.linux.no/#linux+v3.3.5/drivers/tty/serial/8250/8250_dw.c#L165
Thanks James for pointing this out. I will change the prefix for mshc
controller bindings to be consistent with that of the uart controller.
Thanks,
Thomas.
>
> Cheers
> James
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
Hi
On 2 May 2012 06:07, Thomas Abraham wrote:
> Add device tree based discovery support.
>
> Signed-off-by: Thomas Abraham
> ---
> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
> drivers/mmc/host/dw_mmc-pltfm.c | 24 +++
> drivers/mmc/host/dw_mmc.c | 181
> +++-
> drivers/mmc/host/dw_mmc.h | 10 +
> include/linux/mmc/dw_mmc.h | 2 +
> 5 files changed, 296 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> new file mode 100644
> index 000..c1ed70e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> @@ -0,0 +1,85 @@
> +* Synopsis Designware Mobile Storage Host Controller
> +
> +The Synopsis designware mobile storage host controller is used to interface
> +a SoC with storage medium such as eMMC or SD/MMC cards.
> +
> +Required Properties:
> +
> +* compatible: should be one of the following
> + - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
Note that although undocumented in
Documentation/devicetree/bindings/vendor-prefixes.txt (which it
probably should be), the designware uart already uses a different
prefix:
{ .compatible = "snps,dw-apb-uart" },
http://lxr.linux.no/#linux+v3.3.5/drivers/tty/serial/8250/8250_dw.c#L165
Cheers
James
> +
> +* reg: physical base address of the dw-mshc controller and size of its memory
> + region.
> +
> +* interrupts: interrupt specifier for the controller. The format and value of
> + the interrupt specifier depends on the interrupt parent for the controller.
> +
> +# Slots: The slot specific information are contained within child-nodes with
> + each child-node representing a supported slot. There should be atleast one
> + child node representing a card slot. The name of the slot child node should
> + be 'slot{n}' where n is the unique number of the slot connnected to the
> + controller. The following are optional properties which can be included in
> + the slot child node.
> +
> + * bus-width: specifies the width of the data bus connected from the
> + controller to the card slot. The value should be 1, 4 or 8. In case
> + this property is not specified, a default value of 1 is assumed for
> + this property.
> +
> + * cd-gpios: specifies the card detect gpio line. The format of the
> + gpio specifier depends on the gpio controller.
> +
> + * wp-gpios: specifies the write protect gpio line. The format of the
> + gpio specifier depends on the gpio controller.
> +
> + * gpios: specifies a list of gpios used for command, clock and data
> + bus. The first gpio is the command line and the second gpio is the
> + clock line. The rest of the gpios (depending on the bus-width
> + property) are the data lines in no particular order. The format of
> + the gpio specifier depends on the gpio controller.
> +
> +Optional properties:
> +
> +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not
> + specified, the default value of the fifo size is determined from the
> + controller registers.
> +
> +* card-detect-delay: Delay in milli-seconds before detecting card after card
> + insert event. The default value is 0.
> +
> +* supports-highspeed: Enables support for high speed cards (upto 50MHz)
> +
> +* card-detection-broken: The card detection functionality is not available on
> + any of the slots.
> +
> +* no-write-protect: The write protect pad of the controller is not connected
> + to the write protect pin on the slot.
> +
> +Example:
> +
> + The MSHC controller node can be split into two portions, SoC specific and
> + board specific portions as listed below.
> +
> + dwmmc0@1220 {
> + compatible = "synopsis,dw-mshc";
> + reg = <0x1220 0x1000>;
> + interrupts = <0 75 0>;
> + };
> +
> + dwmmc0@1220 {
> + supports-highspeed;
> + card-detection-broken;
> + no-write-protect;
> + fifo-depth = <0x80>;
> + card-detect-delay = <200>;
> +
> + slot0 {
> + bus-width = <8>;
> + cd-gpios = <&gpc0 2 2 3 3>;
> + gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>,
> + <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>,
> + <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>,
> + <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>,
> + <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>;
> + };
> + };
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index 92ec3eb..2b2c9b
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
Hi Olof,
On 2 May 2012 23:37, Olof Johansson wrote:
> Hi,
[...]
>> +# Slots: The slot specific information are contained within child-nodes with
>> + each child-node representing a supported slot. There should be atleast one
>> + child node representing a card slot. The name of the slot child node
>> should
>> + be 'slot{n}' where n is the unique number of the slot connnected to the
>> + controller. The following are optional properties which can be included in
>> + the slot child node.
>
> Since we're talking slots / cards on a bus, I think the addressing
> model would be useful here. So in the main controller node:
> #address-cells = <1>;
> #size-cells = <0>;
>
> And then each slot would need a reg property and possibly unit address:
>
> slot {
> reg = <0>;
> ...
> };
>
> (unit addresses on the slots are only needed if they can't be
> disambiguated by name, so not needed if you only have one slot).
>
Is the addressing model as described above needed in this case? The
address for a slot is not used by the controller driver code and is
just a virtual number. It would be sufficient to represent the nodes
representing the slots with a unique name.
Thanks,
Thomas.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
On 10 May 2012 15:29, Kyungmin Park wrote: > On 5/10/12, Thomas Abraham wrote: >> Dear Mr. Park, >> >> On 2 May 2012 12:25, Kyungmin Park 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. [...] -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
On 5/10/12, Thomas Abraham wrote:
> Dear Mr. Park,
>
> On 2 May 2012 12:25, Kyungmin Park wrote:
>> Hi,
>>
>> On 5/2/12, Thomas Abraham wrote:
>>> Add device tree based discovery support.
>>>
>>> Signed-off-by: Thomas Abraham
>>> ---
>>> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
>>> drivers/mmc/host/dw_mmc-pltfm.c| 24 +++
>>> drivers/mmc/host/dw_mmc.c | 181
>>> +++-
>>> drivers/mmc/host/dw_mmc.h | 10 +
>>> include/linux/mmc/dw_mmc.h |2 +
>>> 5 files changed, 296 insertions(+), 6 deletions(-)
>>> create mode 100644
>>> Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>>> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>>> new file mode 100644
>>> index 000..c1ed70e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>>> @@ -0,0 +1,85 @@
>>> +* Synopsis Designware Mobile Storage Host Controller
>>> +
>>> +The Synopsis designware mobile storage host controller is used to
>>> interface
>>> +a SoC with storage medium such as eMMC or SD/MMC cards.
>>> +
>>> +Required Properties:
>>> +
>>> +* compatible: should be one of the following
>>> + - synopsis,dw-mshc: for controllers compliant with synopsis
>>> dw-mshc.
>> 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.
>
>>> +
>>> +* reg: physical base address of the dw-mshc controller and size of its
>>> memory
>>> + region.
>>> +
>>> +* interrupts: interrupt specifier for the controller. The format and
>>> value
>>> of
>>> + the interrupt specifier depends on the interrupt parent for the
>>> controller.
>>> +
>>> +# Slots: The slot specific information are contained within child-nodes
>>> with
>>> + each child-node representing a supported slot. There should be
>>> atleast
>>> one
>>> + child node representing a card slot. The name of the slot child node
>>> should
>>> + be 'slot{n}' where n is the unique number of the slot connnected to
>>> the
>>> + controller. The following are optional properties which can be
>>> included
>>> in
>>> + the slot child node.
>>> +
>>> + * bus-width: specifies the width of the data bus connected from
>>> the
>>> + controller to the card slot. The value should be 1, 4 or 8. In
>>> case
>>> + this property is not specified, a default value of 1 is assumed
>>> for
>>> + this property.
>>> +
>>> + * cd-gpios: specifies the card detect gpio line. The format of the
>>> + gpio specifier depends on the gpio controller.
>>> +
>>> + * wp-gpios: specifies the write protect gpio line. The format of
>>> the
>>> + gpio specifier depends on the gpio controller.
>>> +
>>> + * gpios: specifies a list of gpios used for command, clock and
>>> data
>>> + bus. The first gpio is the command line and the second gpio is
>>> the
>>> + clock line. The rest of the gpios (depending on the bus-width
>>> + property) are the data lines in no particular order. The format
>>> of
>>> + the gpio specifier depends on the gpio controller.
>>> +
>>> +Optional properties:
>>> +
>>> +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is
>>> not
>>> + specified, the default value of the fifo size is determined from the
>>> + controller registers.
>>> +
>>> +* card-detect-delay: Delay in milli-seconds before detecting card
>>> after
>>> card
>>> + insert event. The default value is 0.
>>> +
>>> +* supports-highspeed: Enables support for high speed cards (upto 50MHz)
>>> +
>>> +* card-detection-broken: The card detection functionality is not
>>> available
>>> on
>>> + any of the slots.
>>> +
>>> +* no-write-protect: The write protect pad of the controller is not
>>> connected
>>> + to the write protect pin on the slot.
>>> +
>>> +Example:
>>> +
>>> + The MSHC controller node can be split into two portions, SoC specific
>>> and
>>> + board specific portions as listed below.
>>> +
>>> + dwmmc0@1220 {
>>> + compatible = "synopsis,dw-mshc";
>>> + reg = <0x1220 0x1000>;
>>> + interrupts = <0 75 0>;
>>> + };
>>> +
>>> + dwmmc0@1220 {
>>> + supports-highspeed;
>>> + card-detection-broken;
>>> +
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
Dear Mr. Park,
On 2 May 2012 12:25, Kyungmin Park wrote:
> Hi,
>
> On 5/2/12, Thomas Abraham wrote:
>> Add device tree based discovery support.
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
>> drivers/mmc/host/dw_mmc-pltfm.c | 24 +++
>> drivers/mmc/host/dw_mmc.c | 181
>> +++-
>> drivers/mmc/host/dw_mmc.h | 10 +
>> include/linux/mmc/dw_mmc.h | 2 +
>> 5 files changed, 296 insertions(+), 6 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>> new file mode 100644
>> index 000..c1ed70e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>> @@ -0,0 +1,85 @@
>> +* Synopsis Designware Mobile Storage Host Controller
>> +
>> +The Synopsis designware mobile storage host controller is used to
>> interface
>> +a SoC with storage medium such as eMMC or SD/MMC cards.
>> +
>> +Required Properties:
>> +
>> +* compatible: should be one of the following
>> + - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
> 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.
>> +
>> +* reg: physical base address of the dw-mshc controller and size of its
>> memory
>> + region.
>> +
>> +* interrupts: interrupt specifier for the controller. The format and value
>> of
>> + the interrupt specifier depends on the interrupt parent for the
>> controller.
>> +
>> +# Slots: The slot specific information are contained within child-nodes
>> with
>> + each child-node representing a supported slot. There should be atleast
>> one
>> + child node representing a card slot. The name of the slot child node
>> should
>> + be 'slot{n}' where n is the unique number of the slot connnected to the
>> + controller. The following are optional properties which can be included
>> in
>> + the slot child node.
>> +
>> + * bus-width: specifies the width of the data bus connected from the
>> + controller to the card slot. The value should be 1, 4 or 8. In case
>> + this property is not specified, a default value of 1 is assumed for
>> + this property.
>> +
>> + * cd-gpios: specifies the card detect gpio line. The format of the
>> + gpio specifier depends on the gpio controller.
>> +
>> + * wp-gpios: specifies the write protect gpio line. The format of the
>> + gpio specifier depends on the gpio controller.
>> +
>> + * gpios: specifies a list of gpios used for command, clock and data
>> + bus. The first gpio is the command line and the second gpio is the
>> + clock line. The rest of the gpios (depending on the bus-width
>> + property) are the data lines in no particular order. The format of
>> + the gpio specifier depends on the gpio controller.
>> +
>> +Optional properties:
>> +
>> +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is
>> not
>> + specified, the default value of the fifo size is determined from the
>> + controller registers.
>> +
>> +* card-detect-delay: Delay in milli-seconds before detecting card after
>> card
>> + insert event. The default value is 0.
>> +
>> +* supports-highspeed: Enables support for high speed cards (upto 50MHz)
>> +
>> +* card-detection-broken: The card detection functionality is not available
>> on
>> + any of the slots.
>> +
>> +* no-write-protect: The write protect pad of the controller is not
>> connected
>> + to the write protect pin on the slot.
>> +
>> +Example:
>> +
>> + The MSHC controller node can be split into two portions, SoC specific
>> and
>> + board specific portions as listed below.
>> +
>> + dwmmc0@1220 {
>> + compatible = "synopsis,dw-mshc";
>> + reg = <0x1220 0x1000>;
>> + interrupts = <0 75 0>;
>> + };
>> +
>> + dwmmc0@1220 {
>> + supports-highspeed;
>> + card-detection-broken;
>> + no-write-protect;
>> + fifo-depth = <0x80>;
>> + card-detect-delay = <200>;
>> +
>> + slot0 {
>> + bus-width = <8>;
>> + cd-gpios = <&gpc0 2 2 3 3>;
>> + gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>,
>> + <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>,
>> + <&gpc1 2 2
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
On Tue, 1 May 2012, Thomas Abraham wrote:
> Add device tree based discovery support.
>
> Signed-off-by: Thomas Abraham
> ---
> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
> drivers/mmc/host/dw_mmc-pltfm.c| 24 +++
> drivers/mmc/host/dw_mmc.c | 181
> +++-
> drivers/mmc/host/dw_mmc.h | 10 +
> include/linux/mmc/dw_mmc.h |2 +
> 5 files changed, 296 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> new file mode 100644
> index 000..c1ed70e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> @@ -0,0 +1,85 @@
> +* Synopsis Designware Mobile Storage Host Controller
> +
> +The Synopsis designware mobile storage host controller is used to interface
> +a SoC with storage medium such as eMMC or SD/MMC cards.
> +
> +Required Properties:
> +
> +* compatible: should be one of the following
> + - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
> +
> +* reg: physical base address of the dw-mshc controller and size of its memory
> + region.
> +
> +* interrupts: interrupt specifier for the controller. The format and value of
> + the interrupt specifier depends on the interrupt parent for the controller.
> +
> +# Slots: The slot specific information are contained within child-nodes with
> + each child-node representing a supported slot. There should be atleast one
> + child node representing a card slot. The name of the slot child node should
> + be 'slot{n}' where n is the unique number of the slot connnected to the
> + controller. The following are optional properties which can be included in
> + the slot child node.
> +
> + * bus-width: specifies the width of the data bus connected from the
> + controller to the card slot. The value should be 1, 4 or 8. In case
> + this property is not specified, a default value of 1 is assumed for
> + this property.
> +
> + * cd-gpios: specifies the card detect gpio line. The format of the
> + gpio specifier depends on the gpio controller.
> +
> + * wp-gpios: specifies the write protect gpio line. The format of the
> + gpio specifier depends on the gpio controller.
> +
> + * gpios: specifies a list of gpios used for command, clock and data
> + bus. The first gpio is the command line and the second gpio is the
> + clock line. The rest of the gpios (depending on the bus-width
> + property) are the data lines in no particular order. The format of
> + the gpio specifier depends on the gpio controller.
> +
> +Optional properties:
> +
> +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not
> + specified, the default value of the fifo size is determined from the
> + controller registers.
> +
> +* card-detect-delay: Delay in milli-seconds before detecting card after card
> + insert event. The default value is 0.
> +
> +* supports-highspeed: Enables support for high speed cards (upto 50MHz)
> +
> +* card-detection-broken: The card detection functionality is not available on
> + any of the slots.
> +
> +* no-write-protect: The write protect pad of the controller is not connected
> + to the write protect pin on the slot.
What do you think about this patch
http://www.spinics.net/lists/linux-sh/msg11259.html
and about using mmc-generic OF properties instead of creating yet another
copy of proprietary ones?
Thanks
Guennadi
> +
> +Example:
> +
> + The MSHC controller node can be split into two portions, SoC specific and
> + board specific portions as listed below.
> +
> + dwmmc0@1220 {
> + compatible = "synopsis,dw-mshc";
> + reg = <0x1220 0x1000>;
> + interrupts = <0 75 0>;
> + };
> +
> + dwmmc0@1220 {
> + supports-highspeed;
> + card-detection-broken;
> + no-write-protect;
> + fifo-depth = <0x80>;
> + card-detect-delay = <200>;
> +
> + slot0 {
> + bus-width = <8>;
> + cd-gpios = <&gpc0 2 2 3 3>;
> + gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>,
> + <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>,
> + <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>,
> + <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>,
> + <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>;
> + };
> + };
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index 92ec3eb..2b2c9bd 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -19,8 +19,24 @@
> #include
> #include
> #include
> +#include
>
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
Hi,
On Tue, May 1, 2012 at 10:07 PM, Thomas Abraham
wrote:
> Add device tree based discovery support.
>
> Signed-off-by: Thomas Abraham
> ---
> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
> drivers/mmc/host/dw_mmc-pltfm.c | 24 +++
> drivers/mmc/host/dw_mmc.c | 181
> +++-
> drivers/mmc/host/dw_mmc.h | 10 +
> include/linux/mmc/dw_mmc.h | 2 +
> 5 files changed, 296 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> new file mode 100644
> index 000..c1ed70e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> @@ -0,0 +1,85 @@
> +* Synopsis Designware Mobile Storage Host Controller
> +
> +The Synopsis designware mobile storage host controller is used to interface
> +a SoC with storage medium such as eMMC or SD/MMC cards.
> +
> +Required Properties:
> +
> +* compatible: should be one of the following
> + - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
> +
> +* reg: physical base address of the dw-mshc controller and size of its memory
> + region.
> +
> +* interrupts: interrupt specifier for the controller. The format and value of
> + the interrupt specifier depends on the interrupt parent for the controller.
> +
> +# Slots: The slot specific information are contained within child-nodes with
> + each child-node representing a supported slot. There should be atleast one
> + child node representing a card slot. The name of the slot child node should
> + be 'slot{n}' where n is the unique number of the slot connnected to the
> + controller. The following are optional properties which can be included in
> + the slot child node.
Since we're talking slots / cards on a bus, I think the addressing
model would be useful here. So in the main controller node:
#address-cells = <1>;
#size-cells = <0>;
And then each slot would need a reg property and possibly unit address:
slot {
reg = <0>;
...
};
(unit addresses on the slots are only needed if they can't be
disambiguated by name, so not needed if you only have one slot).
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
Hi,
On 5/2/12, Thomas Abraham wrote:
> Add device tree based discovery support.
>
> Signed-off-by: Thomas Abraham
> ---
> .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
> drivers/mmc/host/dw_mmc-pltfm.c| 24 +++
> drivers/mmc/host/dw_mmc.c | 181
> +++-
> drivers/mmc/host/dw_mmc.h | 10 +
> include/linux/mmc/dw_mmc.h |2 +
> 5 files changed, 296 insertions(+), 6 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> new file mode 100644
> index 000..c1ed70e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
> @@ -0,0 +1,85 @@
> +* Synopsis Designware Mobile Storage Host Controller
> +
> +The Synopsis designware mobile storage host controller is used to
> interface
> +a SoC with storage medium such as eMMC or SD/MMC cards.
> +
> +Required Properties:
> +
> +* compatible: should be one of the following
> + - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
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'.
> +
> +* reg: physical base address of the dw-mshc controller and size of its
> memory
> + region.
> +
> +* interrupts: interrupt specifier for the controller. The format and value
> of
> + the interrupt specifier depends on the interrupt parent for the
> controller.
> +
> +# Slots: The slot specific information are contained within child-nodes
> with
> + each child-node representing a supported slot. There should be atleast
> one
> + child node representing a card slot. The name of the slot child node
> should
> + be 'slot{n}' where n is the unique number of the slot connnected to the
> + controller. The following are optional properties which can be included
> in
> + the slot child node.
> +
> + * bus-width: specifies the width of the data bus connected from the
> + controller to the card slot. The value should be 1, 4 or 8. In case
> + this property is not specified, a default value of 1 is assumed for
> + this property.
> +
> + * cd-gpios: specifies the card detect gpio line. The format of the
> + gpio specifier depends on the gpio controller.
> +
> + * wp-gpios: specifies the write protect gpio line. The format of the
> + gpio specifier depends on the gpio controller.
> +
> + * gpios: specifies a list of gpios used for command, clock and data
> + bus. The first gpio is the command line and the second gpio is the
> + clock line. The rest of the gpios (depending on the bus-width
> + property) are the data lines in no particular order. The format of
> + the gpio specifier depends on the gpio controller.
> +
> +Optional properties:
> +
> +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is
> not
> + specified, the default value of the fifo size is determined from the
> + controller registers.
> +
> +* card-detect-delay: Delay in milli-seconds before detecting card after
> card
> + insert event. The default value is 0.
> +
> +* supports-highspeed: Enables support for high speed cards (upto 50MHz)
> +
> +* card-detection-broken: The card detection functionality is not available
> on
> + any of the slots.
> +
> +* no-write-protect: The write protect pad of the controller is not
> connected
> + to the write protect pin on the slot.
> +
> +Example:
> +
> + The MSHC controller node can be split into two portions, SoC specific
> and
> + board specific portions as listed below.
> +
> + dwmmc0@1220 {
> + compatible = "synopsis,dw-mshc";
> + reg = <0x1220 0x1000>;
> + interrupts = <0 75 0>;
> + };
> +
> + dwmmc0@1220 {
> + supports-highspeed;
> + card-detection-broken;
> + no-write-protect;
> + fifo-depth = <0x80>;
> + card-detect-delay = <200>;
> +
> + slot0 {
> + bus-width = <8>;
> + cd-gpios = <&gpc0 2 2 3 3>;
> + gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>,
> + <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>,
> + <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>,
> + <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>,
> + <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>;
> + };
> + };
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
> b/drivers/mmc/host/dw_mmc-pltfm.c
> index 92ec3eb..2b2c9bd 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -19,8 +19,24 @@
> #include
> #include
> #include
> +#include
> #include "dw_mmc.h"
>
> +#ifd
