Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
2010/9/30 Tony Lindgren :
> * Cory Maccarrone [100930 11:34]:
>> > Looks like also board-sx1-mmc.c and board-h[23]-mmc.c have the
>> > same spotty voltage range.
>> > Cory, care to do a patch that fixes it for all of them?
>> Yeah, I can do that. I'll resubmit this patch too with the fixed up ranges.
> Turns out I already did it :) Care to test/ack this one?
[...]
> diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c
> b/arch/arm/mach-omap1/board-sx1-mmc.c
> index 5b33ae8..be5a365 100644
> --- a/arch/arm/mach-omap1/board-sx1-mmc.c
> +++ b/arch/arm/mach-omap1/board-sx1-mmc.c
> @@ -44,7 +44,8 @@ static struct omap_mmc_platform_data mmc1_data = {
> .nr_slots = 1,
> .slots[0] = {
> .set_power = mmc_set_power,
> - .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
> + MMC_VDD_30_31 | MMC_VDD_31_32 |
> MMC_VDD_32_33 | MMC_VDD_33_34,
> .name = "mmcblk",
> },
[...]
Al least this one seems wrong (haven't checked others) as the
mmc_set_power() ignores vdd parameter. This suggests that the board
supports only one particular voltage, not the whole range.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
W dniu 24 września 2010 17:38 użytkownik Cory Maccarrone
napisał:
> 2010/9/24 Michał Mirosław :
>> 2010/8/18 Cory Maccarrone :
>>> This change adds in MMC and I2C support to the HTC Herald board, as well
>>> as adding the HTCPLD driver for the PLD used on this phone. It also
>>> adds in the gpio-keys entries for the front directional keys and
>>> selector and the cursor keys on the slide-out keyboard, and gpio-leds
>>> support for the LEDs attached to the htcpld.
>>>
>>> Additionally, SPI bus support (using the spi100k driver) and
>>> touchscreen support (using the ads7846 driver) were added.
>>>
>>> Signed-off-by: Cory Maccarrone
>>> ---
>> [...]
>>> +/* MMC Card */
>>> +#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
>>> +static struct omap_mmc_platform_data htc_mmc1_data = {
>>> + .nr_slots = 1,
>>> + .switch_slot = NULL,
>>> + .slots[0] = {
>>> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
>>> + MMC_VDD_32_33 | MMC_VDD_33_34,
>>> + .name = "mmcblk",
>>> + .nomux = 1,
>>> + .wires = 4,
>>> + .switch_pin = -1,
>>> + },
>>> +};
>> [...]
>> What voltages can this MMC controller provide? That's a rather unusual OCR
>> mask.
> Not really sure, I wasn't the one who first came up with that mask.
> All I know is that it seems to work, and not just for my device, but
> lots of other HTC OMAP850 devices we've tried it on too.
>
> I'm interested though, what in particular makes it unusual?
It specifies, that device supports voltage ranges:
2.8V - 2.9V, 3.0V - 3.1V, 3.2V - 3.4V
(so: 2.9V - 3.0V and 3.1V - 3.2V are not available).
Are there really 2.8V, 3.0V, 3.3V VDDs settable?
If the host supports only VDD = 3.3V for example, then correct OCR
mask would be: MMC_VDD_32_33 | MMC_VDD_33_34 (or just one flag).
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
2010/8/18 Cory Maccarrone :
> This change adds in MMC and I2C support to the HTC Herald board, as well
> as adding the HTCPLD driver for the PLD used on this phone. It also
> adds in the gpio-keys entries for the front directional keys and
> selector and the cursor keys on the slide-out keyboard, and gpio-leds
> support for the LEDs attached to the htcpld.
>
> Additionally, SPI bus support (using the spi100k driver) and
> touchscreen support (using the ads7846 driver) were added.
>
> Signed-off-by: Cory Maccarrone
> ---
[...]
> +/* MMC Card */
> +#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
> +static struct omap_mmc_platform_data htc_mmc1_data = {
> + .nr_slots = 1,
> + .switch_slot = NULL,
> + .slots[0] = {
> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> + MMC_VDD_32_33 | MMC_VDD_33_34,
> + .name = "mmcblk",
> + .nomux = 1,
> + .wires = 4,
> + .switch_pin = -1,
> + },
> +};
[...]
What voltages can this MMC controller provide? That's a rather unusual OCR mask.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
W dniu 15 września 2010 10:25 użytkownik Russell King - ARM Linux napisał: > On Mon, Sep 06, 2010 at 09:42:41PM +0200, Michał Mirosław wrote: >> 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? > Because you may have many instances of the data (due to multiple platform > support), and only need one of them at run-time. Ah. That makes sense. Thanks, Michał Mirosław -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
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-omap" 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/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?
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
