From: "Cousson, Benoit" <b-cousson@ti.com>
To: "Kadiyala, Kishore" <kishore.kadiyala@ti.com>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"tony@atomide.com" <tony@atomide.com>,
"cjb@laptop.org" <cjb@laptop.org>,
"Chikkature Rajashekar, Madhusudhan" <madhu.cr@ti.com>,
"khilman@deeprootsystems.com" <khilman@deeprootsystems.com>,
"paul@pwsan.com" <paul@pwsan.com>
Subject: Re: [PATCH v3 5/5] OMAP: adapt hsmmc to hwmod framework
Date: Thu, 24 Feb 2011 15:33:20 +0100 [thread overview]
Message-ID: <4D666C30.2000907@ti.com> (raw)
In-Reply-To: <AANLkTimKG_B7LxAf4Ci8mTh8-guYqBfgD2nDN0gA3EQE@mail.gmail.com>
On 2/24/2011 2:55 PM, Kadiyala, Kishore wrote:
> On Thu, Feb 24, 2011 at 5:19 PM, Cousson, Benoit<b-cousson@ti.com> wrote:
>> On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
[...]
>>> static struct hsmmc_controller {
>>> char name[HSMMC_NAME_LEN + 1];
>>> -} hsmmc[OMAP34XX_NR_MMC];
>>> +} hsmmc[OMAP44XX_NR_MMC];
>>
>> I do not know the details of that driver, so this comment might be
>> completely irrelevant, but in theory, such static table should not be
>> necessary since the driver core already maintain a list of all instances
>> bound to it.
>
> I agree, but this is used in slot data for the controller and is used
> in the driver
> to create a /sys entry.
I guess the sysfs should be able to use only the device instance.
> I will try to avoid the "OMAP44XX_NR_MMC" dependency.
[...]
>>> +static struct omap_mmc_platform_data *hsmmc_data[OMAP44XX_NR_MMC]
>>> __initdata;
>>
>> Same concern than for hsmmc, why do you need static table here?
>
> Agree, will remove static declaration.
>
>> And why do you need another structure? The omap2_hsmmc_info should already
>> be in a pdata kind of structure.
>> The board file should just populate a table of pdata that you will use
>> during init.
>
> No, omap2_hsmmc_info is intermediate structure used by the boards
> files to update
> some basic info of the controller, based on which the pdata is
> populated in hsmmc.c.
This is the point, I guess you can potentially directly fill partially a
pdata with controller information in the board file to avoid that
intermediate structure.
[...]
>>> + name = "mmci-omap-hs";
>>
>> Could you please rename the device to have something in the form: omap_XXXX?
>> In that case "omap_mmc" should be good. The "hs" is just a indication of one
>> of the mmc instance capability and does not have to be in the device name
>> since there is no none-hs instance.
>
> I understood your concern but omap1,omap2420 uses mmc driver while
> omap2430, omap3 , omap4 has hsmmc driver.
OK, it makes sense then.
> omap1, omap2420 boards have device name as "mmci-omap" currently, but
> if they undergo
> the similar change as proposed above then it looks like "omap_mmc"
>
> Therefore for hsmmc driver, I will be happy to have something like "omap_hsmmc"
>
> please let me know if this is fine.
Excellent, that's fine for me.
Thanks,
Benoit
next prev parent reply other threads:[~2011-02-24 14:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 17:47 [PATCH v3 0/5] OMAP: HSMMC: hwmod adaptation Kishore Kadiyala
2011-02-23 17:47 ` [PATCH v3 1/5] OMAP2430: hwmod data: Add HSMMC Kishore Kadiyala
2011-02-23 17:47 ` [PATCH v3 2/5] OMAP3: " Kishore Kadiyala
2011-02-23 17:47 ` [PATCH v3 3/5] OMAP4: hwmod data: enable HSMMC Kishore Kadiyala
2011-02-24 10:21 ` Cousson, Benoit
2011-02-23 17:47 ` [PATCH v3 4/5] OMAP: hwmod data: Add dev_attr and use in the host driver Kishore Kadiyala
2011-02-24 6:00 ` Varadarajan, Charulatha
2011-02-24 14:05 ` Kadiyala, Kishore
2011-02-24 10:59 ` Cousson, Benoit
2011-02-24 13:58 ` Kadiyala, Kishore
2011-02-23 17:47 ` [PATCH v3 5/5] OMAP: adapt hsmmc to hwmod framework Kishore Kadiyala
2011-02-24 6:28 ` Varadarajan, Charulatha
2011-02-24 14:02 ` Kadiyala, Kishore
2011-02-24 11:49 ` Cousson, Benoit
2011-02-24 13:55 ` Kadiyala, Kishore
2011-02-24 14:33 ` Cousson, Benoit [this message]
2011-02-24 10:19 ` [PATCH v3 0/5] OMAP: HSMMC: hwmod adaptation Cousson, Benoit
2011-02-24 18:10 ` Kadiyala, Kishore
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=4D666C30.2000907@ti.com \
--to=b-cousson@ti.com \
--cc=cjb@laptop.org \
--cc=khilman@deeprootsystems.com \
--cc=kishore.kadiyala@ti.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=madhu.cr@ti.com \
--cc=paul@pwsan.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.