Re: [PATCH v5 3/7] wireless: wl12xx: add platform data passing support
W dniu 6 września 2010 14:07 użytkownik Russell King - ARM Linux napisał: > On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote: >> 2010/9/1 Ohad Ben-Cohen : >> > Add a simple mechanism to pass platform data to the >> > SDIO instances of wl12xx. [cut patch] >> Why do you need all that copying? Isn't the data constant? > > The first copy is to allow platforms to have their data marked with > __initdata. The second copy probably isn't necessary, but avoids > problems where the driver may decide to modify the platform data. Sorry for pushing at this, but why would you mark data that's meant to be used after init phase as __initdata? Best Regards, Michał Mirosław -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] generic runtime pm callbacks
On Monday, September 06, 2010, Mark Brown wrote: > On Mon, Sep 06, 2010 at 03:32:09PM +0300, Ohad Ben-Cohen wrote: > > > That may result in some drivers defining nop handlers, just to return > > 0 (in case there's nothing else they need to do). > > > Do we want that ? > > Funnily enough I was about to report this issue too - it doesn't look > great in the driver code. My use case is using runtime PM in an MFD to > communicate status to the parent devices. The subdevices are just > indicating that they are idle to the parent and have no reason to do > anything in a suspend or resume callback. > > > Alternatively, we may want to allow drivers to enable Runtime PM (by > > taking the appropriate action for their subsystem, e.g. calling > > put_noidle in probe and get_noresume in remove), but still not define > > any runtime pm handlers (implicitly always returning a success), with > > something like: > > This would be my preferred solution. OK Please submit the patch with appropriate changelog and I'll apply it. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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/3] omap3/omap4 hsmmc: Register offset handling
Hi Benoit,
On Fri, Sep 3, 2010 at 1:51 PM, kishore kadiyala
wrote:
> Hi Benoit
>
>
>
>>> + while (!(omap_readl(base + reg_off)&
>>> MMCHS_SYSSTATUS_RESETDONE))
>>> cpu_relax();
>>
>> Why does that series not seems to be based on your hwmod migration? The
>> reset is fully handle by the hwmod framework now.
>
> Agree. But Kevin has suggested to post this patch independent of hwmod.
> Does this patch has to go in hwmod series ?
>
>>
>> BTW, when do you have to apply a reset in your case? Do you have the need
>> for an API accessible by the driver?
>> I'm asking because for the moment the framework does not expose the reset
>> API and use it only at init time.
>
> Correct , I don't need reset API access in the driver.
One correction here , in case of context restore , driver does
software reset apart from
the initial reset. So reset is required and so both the tables needs
registers SYSCONFIG and
SYSSTATUS. In which case offset deviation of 0x100 can't be maintained.
Regards,
Kishore
>
>
>
>>>
>>> +enum {
>>> + OMAP_HSMMC_SYSCONFIG = 0,
>>> + OMAP_HSMMC_SYSSTATUS,
>>> + OMAP_HSMMC_CON,
>>> + OMAP_HSMMC_BLK,
>>> + OMAP_HSMMC_ARG,
>>> + OMAP_HSMMC_CMD,
>>> + OMAP_HSMMC_RSP10,
>>> + OMAP_HSMMC_RSP32,
>>> + OMAP_HSMMC_RSP54,
>>> + OMAP_HSMMC_RSP76,
>>> + OMAP_HSMMC_DATA,
>>> + OMAP_HSMMC_PSTATE,
>>> + OMAP_HSMMC_HCTL,
>>> + OMAP_HSMMC_SYSCTL,
>>> + OMAP_HSMMC_STAT,
>>> + OMAP_HSMMC_IE,
>>> + OMAP_HSMMC_ISE,
>>> + OMAP_HSMMC_CAPA,
>>> + OMAP_HSMMC_REV,
>>> + OMAP_HSMMC_CUR_CAPA,
>>> + OMAP_HSMMC_FE,
>>> + OMAP_HSMMC_ADMA_ES,
>>> + OMAP_HSMMC_ADMA_SAL,
>>> +};
>>> +
>>> +static const u16 omap3_mmc_reg_map[] = {
>>> + [OMAP_HSMMC_SYSCONFIG] = 0x0010,
>>> + [OMAP_HSMMC_SYSSTATUS] = 0x0014,
>>> + [OMAP_HSMMC_CON] = 0x002C,
>>> + [OMAP_HSMMC_BLK] = 0x0104,
>>> + [OMAP_HSMMC_ARG] = 0x0108,
>>> + [OMAP_HSMMC_CMD] = 0x010C,
>>> + [OMAP_HSMMC_RSP10] = 0x0110,
>>> + [OMAP_HSMMC_RSP32] = 0x0114,
>>> + [OMAP_HSMMC_RSP54] = 0x0118,
>>> + [OMAP_HSMMC_RSP76] = 0x011C,
>>> + [OMAP_HSMMC_DATA] = 0x0120,
>>> + [OMAP_HSMMC_PSTATE] = 0x0124,
>>> + [OMAP_HSMMC_HCTL] = 0x0128,
>>> + [OMAP_HSMMC_SYSCTL] = 0x012C,
>>> + [OMAP_HSMMC_STAT] = 0x0130,
>>> + [OMAP_HSMMC_IE] = 0x0134,
>>> + [OMAP_HSMMC_ISE] = 0x0138,
>>> + [OMAP_HSMMC_CAPA] = 0x0140,
>>> + [OMAP_HSMMC_REV] = 0x01FC,
>>> +};
>>> +
>>> +static const u16 omap4_mmc_reg_map[] = {
>>> + [OMAP_HSMMC_SYSCONFIG] = 0x0010, /* Use Highlander Version
>>> */
>>> + [OMAP_HSMMC_SYSSTATUS] = 0x0114,
>>
>> In fact that sysstatus is a legacy register that is not needed anymore in
>> the highlander version. The resetdone is in the sysconfig now.
>> So you can ignore it in OMAP4.
>
> Just verified and thanks for pointing this.
> ok will avoid checking resetdone in sysstatus for OMAP4
>
>>
>>> + [OMAP_HSMMC_CON] = 0x012C,
>>> + [OMAP_HSMMC_BLK] = 0x0204,
>>> + [OMAP_HSMMC_ARG] = 0x0208,
>>> + [OMAP_HSMMC_CMD] = 0x020C,
>>> + [OMAP_HSMMC_RSP10] = 0x0210,
>>> + [OMAP_HSMMC_RSP32] = 0x0214,
>>> + [OMAP_HSMMC_RSP54] = 0x0218,
>>> + [OMAP_HSMMC_RSP76] = 0x021C,
>>> + [OMAP_HSMMC_DATA] = 0x0220,
>>> + [OMAP_HSMMC_PSTATE] = 0x0224,
>>> + [OMAP_HSMMC_HCTL] = 0x0228,
>>> + [OMAP_HSMMC_SYSCTL] = 0x022C,
>>> + [OMAP_HSMMC_STAT] = 0x0230,
>>> + [OMAP_HSMMC_IE] = 0x0234,
>>> + [OMAP_HSMMC_ISE] = 0x0238,
>>> + [OMAP_HSMMC_CAPA] = 0x0240,
>>> + [OMAP_HSMMC_REV] = 0x, /* Use Highlander Version */
>>> + [OMAP_HSMMC_CUR_CAPA] = 0x0248,
>>> + [OMAP_HSMMC_FE] = 0x0250,
>>> + [OMAP_HSMMC_ADMA_ES] = 0x0254,
>>> + [OMAP_HSMMC_ADMA_SAL] = 0x0258,
>>
>> I didn't check all the registers, but it seems that there is a constant
>> 0x100 offset for most of these registers. Cannot you simplify this table?
>
> Sure will simplify and post.
>
>>
>> Regards,
>> Benoit
>>
>
>
>
> Regards,
> Kishore
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] generic runtime pm callbacks
On Mon, Sep 06, 2010 at 10:30:05AM -0400, Alan Stern wrote: > The real issue with USB interfaces is that they are only logical > sub-devices; they can't be power-managed separately from their parent. > Indeed, the runtime_suspend and runtime_resume callbacks for interfaces > always return 0 immediately without doing anything, and the > runtime_idle callback always calls pm_runtime_suspend. > So why not tell the PM core about this behavior? Let's put a > "no_callbacks" flag in dev_pm_info. When this flag is set the core > won't bother invoking the runtime callbacks; it can always assume > success. More importantly, an asynchronous request may never need to > use the workqueue: ... > Does that look like what you're talking about? That'd cover my use case, though it would still be nice to have the flexibility to just omit individual callbacks in the same way that it's possible to do so with regular suspend and resume (eg, if you only have to restore some state after the bus has suspended your device). -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] generic runtime pm callbacks
On Mon, 6 Sep 2010, Mark Brown wrote: > On Mon, Sep 06, 2010 at 03:32:09PM +0300, Ohad Ben-Cohen wrote: > > > That may result in some drivers defining nop handlers, just to return > > 0 (in case there's nothing else they need to do). > > > Do we want that ? > > Funnily enough I was about to report this issue too - it doesn't look > great in the driver code. My use case is using runtime PM in an MFD to > communicate status to the parent devices. The subdevices are just > indicating that they are idle to the parent and have no reason to do > anything in a suspend or resume callback. > > > Alternatively, we may want to allow drivers to enable Runtime PM (by > > taking the appropriate action for their subsystem, e.g. calling > > put_noidle in probe and get_noresume in remove), but still not define > > any runtime pm handlers (implicitly always returning a success), with > > something like: > > This would be my preferred solution. Here's an excerpt from a message I posted recently: --- The real issue with USB interfaces is that they are only logical sub-devices; they can't be power-managed separately from their parent. Indeed, the runtime_suspend and runtime_resume callbacks for interfaces always return 0 immediately without doing anything, and the runtime_idle callback always calls pm_runtime_suspend. So why not tell the PM core about this behavior? Let's put a "no_callbacks" flag in dev_pm_info. When this flag is set the core won't bother invoking the runtime callbacks; it can always assume success. More importantly, an asynchronous request may never need to use the workqueue: __pm_request_idle can directly call __pm_request_suspend. If the device's state is ACTIVE then __pm_request_suspend can switch the state directly to SUSPENDED. If the device's state is SUSPENDED and the parent's state is ACTIVE then __pm_request_resume can switch the device directly to ACTIVE. (If the parent isn't ACTIVE then we need to proceed as we do now.) With those shortcuts added there won't be any need to use delayed autosuspend for interfaces. I don't know if any other subsystems would want to use the no_callbacks flag, but it's possible. --- Does that look like what you're talking about? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: my custom SDIO card can be detected in 2.6.30 but not in 2.6.18
On Sun, 5 Sep 2010, hong zhang wrote: > Because 2.6.14 is the latest in PXA320 package. Please ask Marvell for help then. We do not support their package here. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/7] wireless: wl12xx: add platform data passing support
2010/9/6 Russell King - ARM Linux :
> We could instead make wl12xx_get_platform_data() return a const pointer
> to its own internal storage instead, or ERR pointers for the various
> failure cases.
Sounds good:
diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
new file mode 100644
index 000..973b110
--- /dev/null
+++ b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
@@ -0,0 +1,28 @@
+#include
+#include
+#include
+
+static const struct wl12xx_platform_data *platform_data;
+
+int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
+{
+ if (platform_data)
+ return -EBUSY;
+ if (!data)
+ return -EINVAL;
+
+ platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+const struct wl12xx_platform_data *wl12xx_get_platform_data(void)
+{
+ if (!platform_data)
+ return ERR_PTR(-ENODEV);
+
+ return platform_data;
+}
+EXPORT_SYMBOL(wl12xx_get_platform_data);
I'll wait a few days to see if there's any other comment, and then
post v6 with this change.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] generic runtime pm callbacks
On Mon, Sep 06, 2010 at 03:32:09PM +0300, Ohad Ben-Cohen wrote: > That may result in some drivers defining nop handlers, just to return > 0 (in case there's nothing else they need to do). > Do we want that ? Funnily enough I was about to report this issue too - it doesn't look great in the driver code. My use case is using runtime PM in an MFD to communicate status to the parent devices. The subdevices are just indicating that they are idle to the parent and have no reason to do anything in a suspend or resume callback. > Alternatively, we may want to allow drivers to enable Runtime PM (by > taking the appropriate action for their subsystem, e.g. calling > put_noidle in probe and get_noresume in remove), but still not define > any runtime pm handlers (implicitly always returning a success), with > something like: This would be my preferred solution. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
generic runtime pm callbacks
I'm adding Runtime PM support to the SDIO subsystem, and was planning to use the generic runtime pm handlers. Those handlers return -EINVAL if the driver didn't explicitly define the runtime pm handlers: That may result in some drivers defining nop handlers, just to return 0 (in case there's nothing else they need to do). Do we want that ? Alternatively, we may want to allow drivers to enable Runtime PM (by taking the appropriate action for their subsystem, e.g. calling put_noidle in probe and get_noresume in remove), but still not define any runtime pm handlers (implicitly always returning a success), with something like: diff --git a/drivers/base/power/generic_ops.c b/drivers/base/power/generic_ops. index 304c831..531762a 100644 --- a/drivers/base/power/generic_ops.c +++ b/drivers/base/power/generic_ops.c @@ -49,7 +49,7 @@ int pm_generic_runtime_suspend(struct device *dev) const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL; int ret; - ret = pm && pm->runtime_suspend ? pm->runtime_suspend(dev) : -EINVAL; + ret = pm && pm->runtime_suspend ? pm->runtime_suspend(dev) : 0; return ret; } @@ -68,7 +68,7 @@ int pm_generic_runtime_resume(struct device *dev) const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL; int ret; - ret = pm && pm->runtime_resume ? pm->runtime_resume(dev) : -EINVAL; + ret = pm && pm->runtime_resume ? pm->runtime_resume(dev) : 0; return ret; } What do you think ? Please note that the generic pm_generic_runtime_idle handler does allow drivers not to explicitly define a runtime_idle handler. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/7] wireless: wl12xx: add platform data passing support
On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
> 2010/9/1 Ohad Ben-Cohen :
> > Add a simple mechanism to pass platform data to the
> > SDIO instances of wl12xx.
> >
> > This way there is no confusion over who owns the 'embedded data',
> > typechecking is preserved, and no possibility for the wrong driver to
> > pick up the data.
> >
> > Originally proposed by Russell King.
> >
> > Signed-off-by: Ohad Ben-Cohen
> > ---
> > drivers/net/wireless/Makefile | 2 +
> > drivers/net/wireless/wl12xx/Kconfig | 5 ++-
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c | 31
> >
> > include/linux/wl12xx.h | 3 ++
> > 4 files changed, 40 insertions(+), 1 deletions(-)
> > create mode 100644 drivers/net/wireless/wl12xx/wl12xx_platform_data.c
> >
> > diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
> > index 5d4ce4d..85af697 100644
> > --- a/drivers/net/wireless/Makefile
> > +++ b/drivers/net/wireless/Makefile
> > @@ -50,5 +50,7 @@ obj-$(CONFIG_ATH_COMMON) += ath/
> > obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
> >
> > obj-$(CONFIG_WL12XX) += wl12xx/
> > +# small builtin driver bit
> > +obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
> >
> > obj-$(CONFIG_IWM) += iwmc3200wifi/
> > diff --git a/drivers/net/wireless/wl12xx/Kconfig
> > b/drivers/net/wireless/wl12xx/Kconfig
> > index 2f98058..4a8bb25 100644
> > --- a/drivers/net/wireless/wl12xx/Kconfig
> > +++ b/drivers/net/wireless/wl12xx/Kconfig
> > @@ -74,4 +74,7 @@ config WL1271_SDIO
> > If you choose to build a module, it'll be called
> > wl1271_sdio. Say N if unsure.
> >
> > -
> > +config WL12XX_PLATFORM_DATA
> > + bool
> > + depends on WL1271_SDIO != n
> > + default y
> > diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
> > b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
> > new file mode 100644
> > index 000..e00973b
> > --- /dev/null
> > +++ b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
> > @@ -0,0 +1,31 @@
> > +#include
> > +#include
> > +
> > +static struct wl12xx_platform_data *platform_data;
> > +
> > +int __init wl12xx_set_platform_data(const struct wl12xx_platform_data
> > *data)
> > +{
> > + if (platform_data)
> > + return -EBUSY;
> > + if (!data)
> > + return -EINVAL;
> > +
> > + platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
> > + if (!platform_data)
> > + return -ENOMEM;
> > +
> > + return 0;
> > +}
> > +
> > +int wl12xx_get_platform_data(struct wl12xx_platform_data *data)
> > +{
> > + if (!platform_data)
> > + return -ENODEV;
> > + if (!data)
> > + return -EINVAL;
> > +
> > + memcpy(data, platform_data, sizeof(*data));
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(wl12xx_get_platform_data);
> > diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
> > index 137ac89..3e33ae1 100644
> > --- a/include/linux/wl12xx.h
> > +++ b/include/linux/wl12xx.h
> > @@ -31,4 +31,7 @@ struct wl12xx_platform_data {
> > bool use_eeprom;
> > };
> >
> > +int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
> > +int wl12xx_get_platform_data(struct wl12xx_platform_data *data);
> > +
> > #endif
>
> Why do you need all that copying? Isn't the data constant?
The first copy is to allow platforms to have their data marked with
__initdata. The second copy probably isn't necessary, but avoids
problems where the driver may decide to modify the platform data.
We could instead make wl12xx_get_platform_data() return a const pointer
to its own internal storage instead, or ERR pointers for the various
failure cases.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] thoughts about recent Samsung related patches
> > 2) 8-Bit data transfer support > > > > The comitted version ae6d6c92212e94b12ab9365c23fb73acc2c3c2e7 (sdhci: > > 8-bit data transfer width support) looks different from another RFC > > posted in February: > > http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg01250.html > > > > As those two already differ, I think it might be wiser to move > > 8-bit-mode-handling to the platform-specific code? Even the documented > > features of a SDHC differ across implementations, I fear side-effects > > when using this kind of undocumented feature (official spec says > > "reserved" when describing this bit). > > Okay it looks different from Samsung Spec. > WIDE8[5]: Extended Data Transfer Width (It is for MMC 8-bit card). > 1: 8-bit operatoin > 0: Bit width is designated by the bit 1(Data Transfer Width) > So no need to set the BIT 1 and BIT5 simultaneously. > I also wonder other Specs how described it. esdhc occupied BIT 2 (originally HI_SPD) for this :( %10 means 8 bit transfer. %11 is reserved. > Good, I think it's possible. I'll try and send a patch. Thanks! -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH v5 3/7] wireless: wl12xx: add platform data passing support
2010/9/4 Michał Mirosław :
> 2010/9/1 Ohad Ben-Cohen :
>> Add a simple mechanism to pass platform data to the
>> SDIO instances of wl12xx.
>>
>> This way there is no confusion over who owns the 'embedded data',
>> typechecking is preserved, and no possibility for the wrong driver to
>> pick up the data.
>>
>> Originally proposed by Russell King.
>>
>> Signed-off-by: Ohad Ben-Cohen
>> ---
>> drivers/net/wireless/Makefile | 2 +
>> drivers/net/wireless/wl12xx/Kconfig | 5 ++-
>> drivers/net/wireless/wl12xx/wl12xx_platform_data.c | 31
>>
>> include/linux/wl12xx.h | 3 ++
>> 4 files changed, 40 insertions(+), 1 deletions(-)
>> create mode 100644 drivers/net/wireless/wl12xx/wl12xx_platform_data.c
>>
>> diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
>> index 5d4ce4d..85af697 100644
>> --- a/drivers/net/wireless/Makefile
>> +++ b/drivers/net/wireless/Makefile
>> @@ -50,5 +50,7 @@ obj-$(CONFIG_ATH_COMMON) += ath/
>> obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
>>
>> obj-$(CONFIG_WL12XX) += wl12xx/
>> +# small builtin driver bit
>> +obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
>>
>> obj-$(CONFIG_IWM) += iwmc3200wifi/
>> diff --git a/drivers/net/wireless/wl12xx/Kconfig
>> b/drivers/net/wireless/wl12xx/Kconfig
>> index 2f98058..4a8bb25 100644
>> --- a/drivers/net/wireless/wl12xx/Kconfig
>> +++ b/drivers/net/wireless/wl12xx/Kconfig
>> @@ -74,4 +74,7 @@ config WL1271_SDIO
>> If you choose to build a module, it'll be called
>> wl1271_sdio. Say N if unsure.
>>
>> -
>> +config WL12XX_PLATFORM_DATA
>> + bool
>> + depends on WL1271_SDIO != n
>> + default y
>> diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
>> b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
>> new file mode 100644
>> index 000..e00973b
>> --- /dev/null
>> +++ b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
>> @@ -0,0 +1,31 @@
>> +#include
>> +#include
>> +
>> +static struct wl12xx_platform_data *platform_data;
>> +
>> +int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
>> +{
>> + if (platform_data)
>> + return -EBUSY;
>> + if (!data)
>> + return -EINVAL;
>> +
>> + platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
>> + if (!platform_data)
>> + return -ENOMEM;
>> +
>> + return 0;
>> +}
>> +
>> +int wl12xx_get_platform_data(struct wl12xx_platform_data *data)
>> +{
>> + if (!platform_data)
>> + return -ENODEV;
>> + if (!data)
>> + return -EINVAL;
>> +
>> + memcpy(data, platform_data, sizeof(*data));
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(wl12xx_get_platform_data);
>> diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
>> index 137ac89..3e33ae1 100644
>> --- a/include/linux/wl12xx.h
>> +++ b/include/linux/wl12xx.h
>> @@ -31,4 +31,7 @@ struct wl12xx_platform_data {
>> bool use_eeprom;
>> };
>>
>> +int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
>> +int wl12xx_get_platform_data(struct wl12xx_platform_data *data);
>> +
>> #endif
>
> Why do you need all that copying? Isn't the data constant?
That was the original proposal from Russell;
AFAICT it's very similar to how platform device resources are handled
- it allows marking the original definition of the data as __initdata
(need to add that) thus freeing up its space after the initialization
phase completes. Later, in some scenarios, it might also allow to free
up the copied data (not done now, but the copying happen only once in
the lifetime of the driver so I'm fine with it).
>
> Best Regards,
> Michał Mirosław
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] thoughts about recent Samsung related patches
Hi On Mon, Sep 6, 2010 at 8:00 PM, Wolfram Sang wrote: > Hi, > > while working on the esdhc-controller for the imx-platform, I noticed > the recently comitted changes for Samsung controllers and have some > remarks (sorry for being late): > > 1) Checking conditions for of host->ops->get_min_clock > > The original commit e9510176ff728135383f0cdfc9c90cfe57f9e162 (sdhci: be > more strict with get_min_clock() usage) states why the additional checks > were added. Under this light, it could be argued that commit > cfd1f82f20e0c557a061189f7d8c30d623fbe313 (sdhci: remove useless > set_clock() check) could be reverted and this commit > ce5f036bbbfc6c21d7b55b8fdaa2e2bd56392d94 (sdhci-s3c: add support for the > non standard minimal clock value) could also be reverted if the samsung > platform driver just uses SDHCI_QUIRK_NONSTANDARD_CLOCK without setting > ops->set_clock? In our case we only want to use the min_clock at probe time without NONSTANDARD_CLOCK. and no need to NONSTANDARD_CLOCK at set_clock since we need other parts also at sdhci.c > > 2) 8-Bit data transfer support > > The comitted version ae6d6c92212e94b12ab9365c23fb73acc2c3c2e7 (sdhci: > 8-bit data transfer width support) looks different from another RFC > posted in February: > http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg01250.html > > As those two already differ, I think it might be wiser to move > 8-bit-mode-handling to the platform-specific code? Even the documented > features of a SDHC differ across implementations, I fear side-effects > when using this kind of undocumented feature (official spec says > "reserved" when describing this bit). Okay it looks different from Samsung Spec. WIDE8[5]: Extended Data Transfer Width (It is for MMC 8-bit card). 1: 8-bit operatoin 0: Bit width is designated by the bit 1(Data Transfer Width) So no need to set the BIT 1 and BIT5 simultaneously. I also wonder other Specs how described it. > > 3) NO_HI_SPD > > Commit 5193250168ccdf87364e35a11965336dc088578c (sdhci: add no hi-speed > bit quirk support) adds a quirk which can be avoided by using > io-accessors like in sdhci-of-esdhc.c. Maybe we can even get rid of > more, older quirks this way to save precious quirk flags. Have to check > that later. > > I hope my comments are applicable; because there is no freely available > datasheet, I can't verify all of my assumptions. Looking forward to > comments. Good, I think it's possible. I'll try and send a patch. > > Kind regards, > > Wolfram > > -- > Pengutronix e.K. | Wolfram Sang | > Industrial Linux Solutions | http://www.pengutronix.de/ | > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkyEyesACgkQD27XaX1/VRsm/QCePflpNSE0iQQWSUjf/PY723qK > ZbEAoLxAIS7jIJY/lUQpQvbkJMN6ve19 > =98xD > -END PGP SIGNATURE- > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] thoughts about recent Samsung related patches
Hi, while working on the esdhc-controller for the imx-platform, I noticed the recently comitted changes for Samsung controllers and have some remarks (sorry for being late): 1) Checking conditions for of host->ops->get_min_clock The original commit e9510176ff728135383f0cdfc9c90cfe57f9e162 (sdhci: be more strict with get_min_clock() usage) states why the additional checks were added. Under this light, it could be argued that commit cfd1f82f20e0c557a061189f7d8c30d623fbe313 (sdhci: remove useless set_clock() check) could be reverted and this commit ce5f036bbbfc6c21d7b55b8fdaa2e2bd56392d94 (sdhci-s3c: add support for the non standard minimal clock value) could also be reverted if the samsung platform driver just uses SDHCI_QUIRK_NONSTANDARD_CLOCK without setting ops->set_clock? 2) 8-Bit data transfer support The comitted version ae6d6c92212e94b12ab9365c23fb73acc2c3c2e7 (sdhci: 8-bit data transfer width support) looks different from another RFC posted in February: http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg01250.html As those two already differ, I think it might be wiser to move 8-bit-mode-handling to the platform-specific code? Even the documented features of a SDHC differ across implementations, I fear side-effects when using this kind of undocumented feature (official spec says "reserved" when describing this bit). 3) NO_HI_SPD Commit 5193250168ccdf87364e35a11965336dc088578c (sdhci: add no hi-speed bit quirk support) adds a quirk which can be avoided by using io-accessors like in sdhci-of-esdhc.c. Maybe we can even get rid of more, older quirks this way to save precious quirk flags. Have to check that later. I hope my comments are applicable; because there is no freely available datasheet, I can't verify all of my assumptions. Looking forward to comments. Kind regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 8/9] esdhc-4 esdhc: fsl esdhc driver based on platform sdhci api
On Wed, Sep 01, 2010 at 05:48:53PM +0800, Richard Zhu wrote:
> Based on SDHCI platform API, PIO and simple internal DMA
> are enabled.
>
> Signed-off-by: Richard Zhu
> ---
> drivers/mmc/host/Kconfig | 12 +
> drivers/mmc/host/Makefile|1 +
> drivers/mmc/host/sdhci-fsl.c | 481
> ++
> 3 files changed, 494 insertions(+), 0 deletions(-)
> create mode 100644 drivers/mmc/host/sdhci-fsl.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 283190b..2b67e11 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -167,6 +167,18 @@ config MMC_SDHCI_S3C_DMA
>
> YMMV.
>
> +config MMC_SDHCI_FSL
> + tristate "Freescale i.MX platform eSDHCI support"
> + depends on ARCH_MX5 && MMC_SDHCI
> + select MMC_SDHCI_IO_ACCESSORS
> + help
> + This selects the Freescale i.MX Enhanced Secure Card Host
> + Controller Interface.
> + If you have a i.MX platform with a Multimedia Card slot,
> + say Y or M here.
> +
> + If unsure, say N.
> +
> config MMC_OMAP
> tristate "TI OMAP Multimedia Card Interface support"
> depends on ARCH_OMAP
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 840bcb5..649656c 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_MMC_MXC) += mxcmmc.o
> obj-$(CONFIG_MMC_SDHCI) += sdhci.o
> obj-$(CONFIG_MMC_SDHCI_PCI) += sdhci-pci.o
> obj-$(CONFIG_MMC_SDHCI_S3C) += sdhci-s3c.o
> +obj-$(CONFIG_MMC_SDHCI_FSL) += sdhci-fsl.o
> obj-$(CONFIG_MMC_SDHCI_SPEAR)+= sdhci-spear.o
> obj-$(CONFIG_MMC_WBSD) += wbsd.o
> obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
> diff --git a/drivers/mmc/host/sdhci-fsl.c b/drivers/mmc/host/sdhci-fsl.c
> new file mode 100644
> index 000..fa57ec4
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-fsl.c
> @@ -0,0 +1,481 @@
> +/*
> + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + */
> +
> +/*
> + * sdhci-fsl.c Support for SDHCI platform devices
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +/* Supports:
> + * SDHCI fsl devices
> + *
> + * Inspired by sdhci-pci.c, by Pierre Ossman
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "sdhci.h"
> +
> +#define DRIVER_NAME "imx-sdhci"
> +
> +enum {
> + /* Vendor specified registors */
> + FSL_SDHCI_WML = 0x44,
> + FSL_SDHCI_WML_16_WORDS = 0x08100810,
> + FSL_SDHCI_WML_32_WORDS = 0x08200820,
> + FSL_SDHCI_WML_64_WORDS = 0x08400840,
> + FSL_SDHCI_WML_128_WORDS = 0x08800880,
> +
> + /* Non-standard clock control registor */
> + FSL_SDHCI_CLOCK_MASK= 0x,
> + FSL_SDHCI_CLOCK_SD_EN = 0x0008,
> + FSL_SDHCI_CLOCK_HLK_EN = 0x0002,
> +
> + /* Non-standard host control registor */
> + FSL_SDHCI_CTRL_8BITBUS = 0x0004,
> +};
> +
> +/*\
> + *
> *
> + * SDHCI core callbacks
> *
> + *
> *
> +\*/
> +
> +struct sdhci_fsl_host {
> + struct sdhci_host *host;
> + struct platform_device *pdev; /*! Platform dev */
> + struct imxmmc_platform_data *pdata; /*! private data */
> + struct clk *clk_input; /*! Clock */
> + struct regulator*regulator_mmc; /*! Regulator */
> +};
> +
> +static u32 sdhci_fsl_readl(struct sdhci_host *host, int reg)
> +{
> + return readl(host->ioaddr + reg);
> +}
> +
> +static u16 sdhci_fsl_readw(struct sdhci_host *host, int reg)
> +{
> + u32 val;
> + u16 rc;
> +
> + if (reg % 4 == 3) {
> + printk(KERN_ERR "Invalid reg address!\n");
> + return 0;
> + }
> +
> + val = readl(host->ioaddr + (reg / 4) * 4);
> + rc = (val >> (reg % 4) * 8) & 0x;
> +
> + return rc;
> +}
> +
> +static u8 sdhci_fsl_readb(struct sdh
[RFC 1/3] sdhci-pltfm: Add structure for host-specific data
We need to carry some information per host, e.g. the clock.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/sdhci-pltfm.c |7 +--
drivers/mmc/host/sdhci-pltfm.h |5 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index e045e3c..bf522a1 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -55,6 +55,7 @@ static int __devinit sdhci_pltfm_probe(struct platform_device
*pdev)
struct sdhci_pltfm_data *pdata = pdev->dev.platform_data;
const struct platform_device_id *platid = platform_get_device_id(pdev);
struct sdhci_host *host;
+ struct sdhci_pltfm_host *pltfm_host;
struct resource *iomem;
int ret;
@@ -72,15 +73,17 @@ static int __devinit sdhci_pltfm_probe(struct
platform_device *pdev)
"experience problems.\n");
if (pdev->dev.parent)
- host = sdhci_alloc_host(pdev->dev.parent, 0);
+ host = sdhci_alloc_host(pdev->dev.parent, sizeof(*pltfm_host));
else
- host = sdhci_alloc_host(&pdev->dev, 0);
+ host = sdhci_alloc_host(&pdev->dev, sizeof(*pltfm_host));
if (IS_ERR(host)) {
ret = PTR_ERR(host);
goto err;
}
+ pltfm_host = sdhci_priv(host);
+
host->hw_name = "platform";
if (pdata && pdata->ops)
host->ops = pdata->ops;
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index 900f329..c393289 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -13,6 +13,11 @@
#include
+struct sdhci_pltfm_host {
+ struct clk *clk;
+ u32 scratchpad; /* to handle quirks across io-accessor calls */
+};
+
extern struct sdhci_pltfm_data sdhci_cns3xxx_pdata;
#endif /* _DRIVERS_MMC_SDHCI_PLTFM_H */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/3] pcm043: add resources for mmc
Signed-off-by: Wolfram Sang
---
arch/arm/mach-mx3/mach-pcm043.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-pcm043.c b/arch/arm/mach-mx3/mach-pcm043.c
index 28886f0..44278d3 100644
--- a/arch/arm/mach-mx3/mach-pcm043.c
+++ b/arch/arm/mach-mx3/mach-pcm043.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -139,10 +140,31 @@ static struct i2c_board_info pcm043_i2c_devices[] = {
};
#endif
+static struct resource sdhci_resources[] = {
+ {
+ .start = 0x53fb4000,
+ .end= 0x53fb4000 + 0xff,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = MX35_INT_MMC_SDHC1,
+ .end= MX35_INT_MMC_SDHC1,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device sdhci_device = {
+ .name = "sdhci-esdhc",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(sdhci_resources),
+ .resource = sdhci_resources,
+};
+
+
static struct platform_device *devices[] __initdata = {
&pcm043_flash,
&mxc_fec_device,
&imx_wdt_device0,
+ &sdhci_device,
};
static struct pad_desc pcm043_pads[] = {
@@ -217,6 +239,13 @@ static struct pad_desc pcm043_pads[] = {
/* CAN2 */
MX35_PAD_TX5_RX0__CAN2_TXCAN,
MX35_PAD_TX4_RX1__CAN2_RXCAN,
+ /* esdhc */
+ MX35_PAD_SD1_CMD__ESDHC1_CMD,
+ MX35_PAD_SD1_CLK__ESDHC1_CLK,
+ MX35_PAD_SD1_DATA0__ESDHC1_DAT0,
+ MX35_PAD_SD1_DATA1__ESDHC1_DAT1,
+ MX35_PAD_SD1_DATA2__ESDHC1_DAT2,
+ MX35_PAD_SD1_DATA3__ESDHC1_DAT3,
};
#define AC97_GPIO_TXFS (1 * 32 + 31)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/3] mmc: add driver for imx35/51
WIP!
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/Kconfig |9 ++
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-esdhc.c | 194
drivers/mmc/host/sdhci-pltfm.c |3 +
drivers/mmc/host/sdhci-pltfm.h |1 +
5 files changed, 208 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/host/sdhci-esdhc.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 68d1279..bba3aec 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -130,6 +130,15 @@ config MMC_SDHCI_CNS3XXX
If unsure, say N.
+config MMC_SDHCI_ESDHC
+ bool "SDHCI platform support for the Freescale eSDHC controller"
+ depends on MMC_SDHCI_PLTFM
+ select MMC_SDHCI_IO_ACCESSORS
+ help
+ This selects the Freescale eSDHC controller support.
+
+ If unsure, say N.
+
config MMC_SDHCI_S3C
tristate "SDHCI support on Samsung S3C SoC"
depends on MMC_SDHCI && PLAT_SAMSUNG
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 840bcb5..7bde748 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-platform.o
sdhci-platform-y := sdhci-pltfm.o
sdhci-platform-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
+sdhci-platform-$(CONFIG_MMC_SDHCI_ESDHC) += sdhci-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
sdhci-of-y := sdhci-of-core.o
diff --git a/drivers/mmc/host/sdhci-esdhc.c b/drivers/mmc/host/sdhci-esdhc.c
new file mode 100644
index 000..dced0fd
--- /dev/null
+++ b/drivers/mmc/host/sdhci-esdhc.c
@@ -0,0 +1,194 @@
+/*
+ * Freescale eSDHC controller driver for the platform bus.
+ *
+ * derived from the OF-version. WIP!
+ *
+ * Copyright (c) 2010 Pengutronix e.K.
+ * Author: Wolfram Sang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "sdhci.h"
+#include "sdhci-pltfm.h"
+
+/*
+ * Ops and quirks for the Freescale eSDHC controller.
+ */
+
+// FIXME: Share those with the OF-version
+#define ESDHC_SYSTEM_CONTROL 0x2c
+#define ESDHC_CLOCK_MASK 0xfff0
+#define ESDHC_PREDIV_SHIFT 8
+#define ESDHC_DIVIDER_SHIFT4
+#define ESDHC_CLOCK_PEREN 0x0004
+#define ESDHC_CLOCK_HCKEN 0x0002
+#define ESDHC_CLOCK_IPGEN 0x0001
+
+#define ESDHC_HOST_CONTROL_8BITBUS 0x04
+#define ESDHC_HOST_CONTROL_LE 0x20
+
+static inline void esdhc_clrset_le(struct sdhci_host *host, u32 mask, u32 val,
int reg)
+{
+ void __iomem *base = host->ioaddr + (reg & ~0x3);
+ u32 shift = (reg & 0x3) * 8;
+
+ writel(((readl(base) & ~(mask << shift)) | (val << shift)), base);
+}
+
+static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
+{
+ if (unlikely(reg == SDHCI_HOST_VERSION))
+ reg ^= 2;
+
+ return readw(host->ioaddr + reg);
+}
+
+static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+ switch (reg) {
+ case SDHCI_TRANSFER_MODE:
+ /*
+* Postpone this write, we must do it together with a
+* command write that is down below.
+*/
+ pltfm_host->scratchpad = val;
+ return;
+ case SDHCI_COMMAND:
+ writel(val << 16 | pltfm_host->scratchpad,
+ host->ioaddr + SDHCI_TRANSFER_MODE);
+ return;
+ case SDHCI_BLOCK_SIZE:
+ val &= ~SDHCI_MAKE_BLKSZ(0x7, 0);
+ break;
+ }
+ esdhc_clrset_le(host, 0x, val, reg);
+}
+
+static void esdhc_writeb_le(struct sdhci_host *host, u8 val, int reg)
+{
+ u32 new_val;
+
+ switch (reg) {
+ case SDHCI_POWER_CONTROL:
+ /* FSL put some DMA bits here */
+ //FIXME: Convert to regulator?
+ return;
+ case SDHCI_HOST_CONTROL:
+ /* FSL messed up here, so we can just keep those two */
+ new_val = val & (SDHCI_CTRL_LED | SDHCI_CTRL_4BITBUS);
+ /* ensure the endianess */
+ new_val |= ESDHC_HOST_CONTROL_LE;
+ /* DMA mode bits are shifted */
+ new_val |= (val & SDHCI_CTRL_DMA_MASK) << 5;
+
+ esdhc_clrset_le(host, 0x, new_val, reg);
+ return;
+ }
+ esdhc_clrset_le(host, 0xff, val, reg);
+}
+
+
+//FIXME: Share the next three with OF?
+static void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+ int pre_div = 2;
+ int div = 1;
+
Support for platform-esdhc-controller
This is a patch series adding support for the esdhc-controller as a platform device which can be found on e.g. mx35/51. It was tested using a mx35-based Phytec pcm043. This is still a WIP! ADMA2 is not supported so far (mx35 just has ADMA1 which is not supported by the core?) I will see if I can grab a mx51-board later. The following changes since commit 2bfc96a127bc1cc94d26bfaa40159966064f9c8c: Linux 2.6.36-rc3 (2010-08-29 08:36:04 -0700) are available in the git repository at: git://git.pengutronix.de/git/wsa/linux-2.6.git pcm043-mmc Wolfram Sang (3): sdhci-pltfm: Add structure for host-specific data mmc: add driver for imx35/51 pcm043: add resources for mmc arch/arm/mach-mx3/mach-pcm043.c | 29 ++ drivers/mmc/host/Kconfig|9 ++ drivers/mmc/host/Makefile |1 + drivers/mmc/host/sdhci-esdhc.c | 194 +++ drivers/mmc/host/sdhci-pltfm.c | 10 ++- drivers/mmc/host/sdhci-pltfm.h |6 + 6 files changed, 247 insertions(+), 2 deletions(-) create mode 100644 drivers/mmc/host/sdhci-esdhc.c Regards, Wolfram -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A serial patchs that support FSL's eSDHC
Hi Richard, (going back to the list. A few more eyes during the process will surely help :)) On Fri, Sep 03, 2010 at 06:26:05PM +0800, Zhu Richard-R65037 wrote: > I encounter some problems when I merge my eSDHC driver into > sdhci-pltfm.c driver. > In the eSDHC solution there is a little complex in the driver > implementation refer to the HW/IC design. > One private struct such as sdhci_fsl_host in my original codes is > needed, and the board specified platform data (such > as imxmmc_platform_data struct) is mandatory required too. > > sdhci-pltfm.c driver can't provide such kinds of APIs. > Do you have any suggestions? Well, I think we can do without. In a few minutes, I will post an RFC which I just hacked. Please have a look at it, and say if you have comments or suggestions. Hopefully you'll agree that this approach is a lot less intrusive. I will mainly concentrate on the driver. For the platform part, Uwe already gave a few comments. I will also reply to some of your patches to clarify some issues. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCHv5 1/3] mmc_test: use API to check card type
There are methods to check card type. Let's use them instead of direct checking
type bits.
Signed-off-by: Andy Shevchenko
---
drivers/mmc/card/mmc_test.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index b992725..cd8edf4 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -1977,7 +1977,7 @@ static int mmc_test_probe(struct mmc_card *card)
{
int ret;
- if ((card->type != MMC_TYPE_MMC) && (card->type != MMC_TYPE_SD))
+ if (!mmc_card_mmc(card) && !mmc_card_sd(card))
return -ENODEV;
ret = device_create_file(&card->dev, &dev_attr_test);
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 3/3] mmc_test: collect data and show it via sysfs by demand
TODO:
- implement show() method based on seq_file API
Changes since v4:
- BUG_ON at exit if the list of the results isn't empty
- rebase against recent linux-next tree
Changes since v3:
- fix multi-line commentary style
- protect mmc_test_free_result() by mutex
- apply known values to newly created mmc_test_general_result structure before
attaching it to the list
- call list_del() before free mmc_test_transfer_result structure
- check truncated output in show() method, return -ENOBUFS if so
- avoid deadlock in show() method if snprintf() fails
Changes since v2:
- move card memeber to mmc_test_general_result structrure and thus throw away
mmc_test_overall_result which was overkill
- check result of kmalloc and kzalloc
- keep pointer to the actual mmc_test_general_result structure in the
mmc_test_card
Changes since v1:
- structrure members are described
- save transfer results code is split to separate function
- in mmc_test_print_rate() use count = 1 instead of 0
- mmc_test_result keeps overall results (across all tested cards), however
it's still global variable
- list_head variables inside structures have a suffix _lst now
Here is a patch which brings possibility to get test results via sysfs. It
helps to do tests non-interactively.
We have the file created under sysfs already and we could use it to out test
results.
Signed-off-by: Andy Shevchenko
---
drivers/mmc/card/mmc_test.c | 170 ++-
1 files changed, 168 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 6bffb33..bfb0e7f 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -17,6 +17,7 @@
#include
#include /* For nr_free_buffer_pages() */
+#include
#define RESULT_OK 0
#define RESULT_FAIL1
@@ -73,12 +74,45 @@ struct mmc_test_area {
};
/**
+ * struct mmc_test_transfer_result - transfer results for performance tests.
+ * @link: double-linked list
+ * @count: amount of group of sectors to check
+ * @sectors: amount of sectors to check in one group
+ * @ts: time values of transfer
+ * @rate: calculated transfer rate
+ */
+struct mmc_test_transfer_result {
+ struct list_head link;
+ unsigned int count;
+ unsigned int sectors;
+ struct timespec ts;
+ unsigned int rate;
+};
+
+/**
+ * struct mmc_test_general_result - results for tests.
+ * @link: double-linked list
+ * @card: card under test
+ * @testcase: number of test case
+ * @result: result of test run
+ * @tr_lst: transfer measurements if any as mmc_test_transfer_result
+ */
+struct mmc_test_general_result {
+ struct list_head link;
+ struct mmc_card *card;
+ int testcase;
+ int result;
+ struct list_head tr_lst;
+};
+
+/**
* struct mmc_test_card - test information.
* @card: card under test
* @scratch: transfer buffer
* @buffer: transfer buffer
* @highmem: buffer for highmem tests
* @area: information for performance tests
+ * @gr: pointer to results of current testcase
*/
struct mmc_test_card {
struct mmc_card *card;
@@ -88,7 +122,8 @@ struct mmc_test_card {
#ifdef CONFIG_HIGHMEM
struct page *highmem;
#endif
- struct mmc_test_area area;
+ struct mmc_test_areaarea;
+ struct mmc_test_general_result *gr;
};
/***/
@@ -421,6 +456,30 @@ static unsigned int mmc_test_rate(uint64_t bytes, struct
timespec *ts)
}
/*
+ * Save transfer results for future usage
+ */
+static void mmc_test_save_transfer_result(struct mmc_test_card *test,
+ unsigned int count, unsigned int sectors, struct timespec ts,
+ unsigned int rate)
+{
+ struct mmc_test_transfer_result *tr;
+
+ if (!test->gr)
+ return;
+
+ tr = kmalloc(sizeof(struct mmc_test_transfer_result), GFP_KERNEL);
+ if (!tr)
+ return;
+
+ tr->count = count;
+ tr->sectors = sectors;
+ tr->ts = ts;
+ tr->rate = rate;
+
+ list_add_tail(&tr->link, &test->gr->tr_lst);
+}
+
+/*
* Print the transfer rate.
*/
static void mmc_test_print_rate(struct mmc_test_card *test, uint64_t bytes,
@@ -438,6 +497,8 @@ static void mmc_test_print_rate(struct mmc_test_card *test,
uint64_t bytes,
mmc_hostname(test->card->host), sectors, sectors >> 1,
(sectors == 1 ? ".5" : ""), (unsigned long)ts.tv_sec,
(unsigned long)ts.tv_nsec, rate / 1000, rate / 1024);
+
+ mmc_test_save_transfer_result(test, 1, sectors, ts, rate);
}
/*
@@ -461,6 +522,8 @@ static void mmc_test_print_avg_rate(struct mmc_test_card
*test, uint64_t bytes,
sectors >> 1, (sectors == 1 ? ".5" : ""),
(unsigned long)ts.tv_sec, (unsigned long)ts.tv_nsec,
rate / 1000, rate
[PATCHv5 2/3] mmc_test: change simple_strtol() to strict_strtol()
It's better to use strict_strtol() to convert user's input and strictly check
it. At least it forbids to interpret wrong input as a 0 and prevents to run all
tests.
Signed-off-by: Andy Shevchenko
---
drivers/mmc/card/mmc_test.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index cd8edf4..6bffb33 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -1937,9 +1937,10 @@ static ssize_t mmc_test_store(struct device *dev,
{
struct mmc_card *card = mmc_dev_to_card(dev);
struct mmc_test_card *test;
- int testcase;
+ long testcase;
- testcase = simple_strtol(buf, NULL, 10);
+ if (strict_strtol(buf, 10, &testcase))
+ return -EINVAL;
test = kzalloc(sizeof(struct mmc_test_card), GFP_KERNEL);
if (!test)
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
