All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajendra Nayak <rnayak@ti.com>
To: "Cousson, Benoit" <b-cousson@ti.com>
Cc: Olof Johansson <olof@lixom.net>,
	cjb@laptop.org, balajitk@ti.com, tony@atomide.com,
	devicetree-discuss@lists.ozlabs.org, linux-mmc@vger.kernel.org,
	rob.herring@calxeda.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
Date: Mon, 07 Nov 2011 11:44:43 +0530	[thread overview]
Message-ID: <4EB77753.8040606@ti.com> (raw)
In-Reply-To: <4EB45844.5000603@ti.com>

On Saturday 05 November 2011 02:55 AM, Cousson, Benoit wrote:
>>> +Required properties:
>>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>>> +n is controller instance starting 0, for OMAP2/3 controllers
>>
>> No, no, no. You should not have to specify the unit-address in the
>> compatible
>> field. They are all programmed the same way, right?
>
> AFAIR, 2 instances contain a DMA engine, but that should anyway be
> detected using a "ti,had-dma-engine" extra property and not like that.
>
> Checking the code in #2, it is used to get the instance of the MMC.
>
> +static unsigned int of_get_hsmmc_instance(struct device_node *np)
> +{
> +    int i;
> +    char comp[32];
> +
> +    for (; i < OMAP_MMC_DEV_MAX; i++) {
> +        snprintf(comp, 32, "ti,omap-hsmmc%d", i);
> +        if (of_device_is_compatible(np, comp))
> +            break;
> +    }
> +    return i;
> +}
>
> Which does not seems to be a good usage of the compatible property anyway.
> For a similar issue someone on the list suggested using the "cell-index"
> property. But the definition I found in some binding documentation seems
> to reserve that to: "enumerate logical devices within an IP core."
> Ideally the driver should probably get rid of the need for an index.
> I didn't check the original driver, but that should be needed for some
> legacy reason.

yes, there are a bunch of things done inside the driver based on the
instance id which seem wrong, but I agree, encoding the instance
in the compatible property seems really bad and non-scalable.
Will look at how some of this legacy code in the driver can be
removed/cleaned up.

WARNING: multiple messages have this Message-ID (diff)
From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
Date: Mon, 07 Nov 2011 11:44:43 +0530	[thread overview]
Message-ID: <4EB77753.8040606@ti.com> (raw)
In-Reply-To: <4EB45844.5000603@ti.com>

On Saturday 05 November 2011 02:55 AM, Cousson, Benoit wrote:
>>> +Required properties:
>>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>>> +n is controller instance starting 0, for OMAP2/3 controllers
>>
>> No, no, no. You should not have to specify the unit-address in the
>> compatible
>> field. They are all programmed the same way, right?
>
> AFAIR, 2 instances contain a DMA engine, but that should anyway be
> detected using a "ti,had-dma-engine" extra property and not like that.
>
> Checking the code in #2, it is used to get the instance of the MMC.
>
> +static unsigned int of_get_hsmmc_instance(struct device_node *np)
> +{
> +    int i;
> +    char comp[32];
> +
> +    for (; i < OMAP_MMC_DEV_MAX; i++) {
> +        snprintf(comp, 32, "ti,omap-hsmmc%d", i);
> +        if (of_device_is_compatible(np, comp))
> +            break;
> +    }
> +    return i;
> +}
>
> Which does not seems to be a good usage of the compatible property anyway.
> For a similar issue someone on the list suggested using the "cell-index"
> property. But the definition I found in some binding documentation seems
> to reserve that to: "enumerate logical devices within an IP core."
> Ideally the driver should probably get rid of the need for an index.
> I didn't check the original driver, but that should be needed for some
> legacy reason.

yes, there are a bunch of things done inside the driver based on the
instance id which seem wrong, but I agree, encoding the instance
in the compatible property seems really bad and non-scalable.
Will look at how some of this legacy code in the driver can be
removed/cleaned up.

  parent reply	other threads:[~2011-11-07  6:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04 11:50 [PATCH 0/4] omap hsmmc device tree support Rajendra Nayak
2011-11-04 11:50 ` Rajendra Nayak
2011-11-04 11:50 ` [PATCH 1/4] mmc: Add additional binding for mmc host controller Rajendra Nayak
2011-11-04 11:50   ` Rajendra Nayak
2011-11-04 19:58   ` Olof Johansson
2011-11-04 19:58     ` Olof Johansson
2011-11-04 11:50 ` [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree Rajendra Nayak
2011-11-04 11:50   ` Rajendra Nayak
2011-11-04 20:04   ` Olof Johansson
2011-11-04 20:04     ` Olof Johansson
2011-11-04 21:25     ` Cousson, Benoit
2011-11-04 21:25       ` Cousson, Benoit
2011-11-04 21:28       ` Olof Johansson
2011-11-04 21:28         ` Olof Johansson
2011-11-07  6:14       ` Rajendra Nayak [this message]
2011-11-07  6:14         ` Rajendra Nayak
2011-11-04 22:15     ` Segher Boessenkool
2011-11-04 22:15       ` Segher Boessenkool
2011-11-07  6:18     ` Rajendra Nayak
2011-11-07  6:18       ` Rajendra Nayak
2011-11-14 21:30   ` Tony Lindgren
2011-11-14 21:30     ` Tony Lindgren
2011-11-15  4:15     ` Rajendra Nayak
2011-11-15  4:15       ` Rajendra Nayak
2011-11-19  0:21       ` Tony Lindgren
2011-11-19  0:21         ` Tony Lindgren
2011-11-04 11:50 ` [PATCH 3/4] omap4: mmc: Pass SoC and board data for omap4 mmc from dt Rajendra Nayak
2011-11-04 11:50   ` Rajendra Nayak
2011-11-04 11:50 ` [PATCH 4/4] omap4: mmc: use auxdata to pass platform function ptrs Rajendra Nayak
2011-11-04 11:50   ` Rajendra Nayak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EB77753.8040606@ti.com \
    --to=rnayak@ti.com \
    --cc=b-cousson@ti.com \
    --cc=balajitk@ti.com \
    --cc=cjb@laptop.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=rob.herring@calxeda.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.