Re: [PATCH resend 1/3] AM35x: Add musb support
Hi, On Wed, Jul 07, 2010 at 04:16:04AM +0530, Gadiyar, Anand wrote: Like it is done in ehci-hcd.c/ohci-hcd.c? That's different, they export the platform_driver which gets probed by ehci-hcd.c, here we would have a parent platform_driver instianting correct dma device and musb device. This looks much easier to maintain. Do you already have a patch doing this, or would you like me to spin one for RFC/RFT? I started this yesterday before leaving the office, so not much done. If you beat me to it, go for it :-) -- balbi -- 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 11/15] wireless: wl1271: introduce platform device support
On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote:
Nicolas Pitre wrote:
On Tue, 6 Jul 2010, Roger Quadros wrote:
On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
Hi Roger,
On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadrosroger.quad...@nokia.com
wrote:
My point is that shouldn't this be handled by SDIO core?
Care to explain what you mean / give a code example ?
If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
the SDIO/MMC core should tackle it, just like it deals with supply for slots
with removable cards.
Exact.
You need card detect events in order to trigger card sdio function
initialization and removals.
Why would you trigger function initialization and removal? Just to turn
off power? That's a bit like pulling off the battery from your laptop
when you want to suspend it. There is a better way to go about things.
Please share any alternative approach you may be thinking on.
OK, this is how I see it.
- Treat the non-removable card as non-removable. So no need to do card detect
emulation.
- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
framework to define this regulator supply. Even though you mention that it
is not actually a supply, it fits well in the fixed supply framework.
- When the host controller is enumerated, the mmc core will power up the slot,
find the sdio card, and probe the function driver (i.e. wl1271_sdio).
- if interface is not in use, the function driver must release the sdio host,
and this should eventually disable the vmmc supply.
- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
sdio host. this will cause the vmmc supply to be enabled, for as long as the
interface is up.
Does this address all issues?
This is mostly all good, except that claiming/releasing the SDIO host is
about access to the bus. It must be claimed right before doing any IO,
and released right after that, even when the card is expected to remain
powered. This is not the proper place to hook power control.
Another function pair would be needed instead, which would do almost
like the suspend/resume code is already doing. Something like:
/*
* Indicate to the core SDIO layer that we're not requiring that the
* function remain powered. If all functions for the card are in the
* same no power state, then the host controller can remove power from
* the card. Note: the function driver must preserve hardware states if
* necessary.
*/
int sdio_release_power(struct sdio_func *func);
/*
* Indicate to the core SDIO layer that we want power back for this
* SDIO function. The power may or may not actually have been removed
* since last call to sdio_release_power(), so the function driver must
* not assume any preserved state at the hardware level and re-perform
* all the necessary hardware config. This function returns 0 when
* power is actually restored, or some error code if this cannot be
* achieved. One error reason might be that the card is no longer
* available on the bus (was removed while powered down and card
* detection didn't trigger yet).
*/
int sdio_claim_power(struct sdio_func *func);
That's it. When the network interface is down and the hardware is not
needed, you call sdio_release_power(). When the request to activate the
network interface is received, you call sdio_claim_power() and configure
the hardware appropriately. If sdio_claim_power() returns an error,
then you just return an error to the network request, and eventually the
driver's remove method will be called if this is indeed because the card
was removed.
In the core SDIO code, this is almost identical to a suspend/resume
request, except that the request comes from the function driver instead
of the core MMC code.
For eMMC in omap_hsmmc, this is all done via claim_host / release_host
which call -enable() / -disable() methods. omap_hsmmc makes use of
mmc_power_restore_host() which calls host-bus_ops-power_restore()
which is not implemented for SDIO, but for MMC and SD it reinitializes
the card.
Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie
with the bus drivers?
Set omap2_hsmmc_info mmc[x] {.nonremovable=true, .power_saving=true} and
implement host-bus_ops-power_restore() for SDIO, then the power will
go off 9 seconds after sdio_release_host() is called. Then tweak omap_hsmmc
so that it doesn't wait 9 seconds for the SDIO case
is the wl1271 supposed to be used only with omap_hsmmc? We need to have a
solution that works neatly irrespective of which host controller is being used.
regards,
-roger
--
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
[PATCH 00/13] omap2/3/4 board updates for 2.6.36 merge window
Hi all, Here are some omap board updates for review. Regards, Tony --- Ameya Palande (1): tsl2563 ALS support for Nokia N900 David Anders (1): Add OMAP4 Panda Support Grazvydas Ignotas (2): omap3: pandora: update gpio-keys data omap3: pandora: add NAND and wifi support Hemanth V (1): OMAP4: Add GPIO LED support for SDP board Jarkko Nikula (4): omap: rx51: Set regulator V28 always on omap: rx51: Add platform_data for tlv320aic3x with reset gpionumber omap: rx51: Use REGULATOR_SUPPLY macro when initializingregulator consumers omap: rx51: Add supply and data for the tpa6130a2 headphoneamplifier Ohad Ben-Cohen (2): omap: zoom2: wlan board muxing omap: zoom3: wlan board muxing Santosh Shilimkar (1): omap4: mmc: Fix the regulator resource for MMC2 on 4430sdp Shubhrajyoti Datta (1): omap4: Board changes for 4430sdp tmp105 temperature sensor arch/arm/mach-omap2/Kconfig |5 arch/arm/mach-omap2/Makefile |2 arch/arm/mach-omap2/board-4430sdp.c | 70 ++ arch/arm/mach-omap2/board-omap3pandora.c | 148 +++-- arch/arm/mach-omap2/board-omap4panda.c | 304 ++ arch/arm/mach-omap2/board-rx51-peripherals.c | 71 +++--- arch/arm/mach-omap2/board-zoom2.c| 15 + arch/arm/mach-omap2/board-zoom3.c| 15 + 8 files changed, 574 insertions(+), 56 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap4panda.c -- Signature -- 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
[PATCH 02/13] omap: zoom3: wlan board muxing
From: Ohad Ben-Cohen oh...@ti.com
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM3.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-zoom3.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 3314704..0b62663 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -46,6 +46,21 @@ static void __init omap_zoom_init_irq(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+ /* WLAN IRQ - GPIO 162 */
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
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
[PATCH 04/13] omap3: pandora: add NAND and wifi support
From: Grazvydas Ignotas nota...@gmail.com
Add platform data for NAND and wifi, also setup all GPIOs
needed to use the wifi chip.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3pandora.c | 120 ++
1 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 7a12729..a58bdef 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -25,6 +25,9 @@
#include linux/spi/ads7846.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include linux/spi/wl12xx.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
#include linux/leds.h
#include linux/input.h
#include linux/input/matrix_keypad.h
@@ -41,13 +44,50 @@
#include plat/mcspi.h
#include plat/usb.h
#include plat/display.h
+#include plat/nand.h
#include mux.h
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
+#define PANDORA_WIFI_IRQ_GPIO 21
+#define PANDORA_WIFI_NRESET_GPIO 23
#define OMAP3_PANDORA_TS_GPIO 94
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition omap3pandora_nand_partitions[] = {
+ {
+ .name = xloader,
+ .offset = 0,
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE
+ }, {
+ .name = uboot,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 15 * NAND_BLOCK_SIZE,
+ }, {
+ .name = uboot-env,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 1 * NAND_BLOCK_SIZE,
+ }, {
+ .name = boot,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 80 * NAND_BLOCK_SIZE,
+ }, {
+ .name = rootfs,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data pandora_nand_data = {
+ .cs = 0,
+ .devsize= 1,/* '0' for 8-bit, '1' for 16-bit device */
+ .parts = omap3pandora_nand_partitions,
+ .nr_parts = ARRAY_SIZE(omap3pandora_nand_partitions),
+};
+
static struct gpio_led pandora_gpio_leds[] = {
{
.name = pandora::sd1,
@@ -246,12 +286,33 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
static int omap3pandora_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int ret, gpio_32khz;
+
/* gpio + {0,1} is mmc{0,1}_cd (input/IRQ) */
omap3pandora_mmc[0].gpio_cd = gpio + 0;
omap3pandora_mmc[1].gpio_cd = gpio + 1;
omap2_hsmmc_init(omap3pandora_mmc);
+ /* gpio + 13 drives 32kHz buffer for wifi module */
+ gpio_32khz = gpio + 13;
+ ret = gpio_request(gpio_32khz, wifi 32kHz);
+ if (ret 0) {
+ pr_err(Cannot get GPIO line %d, ret=%d\n, gpio_32khz, ret);
+ goto fail;
+ }
+
+ ret = gpio_direction_output(gpio_32khz, 1);
+ if (ret 0) {
+ pr_err(Cannot set GPIO line %d, ret=%d\n, gpio_32khz, ret);
+ goto fail_direction;
+ }
+
return 0;
+
+fail_direction:
+ gpio_free(gpio_32khz);
+fail:
+ return -ENODEV;
}
static struct twl4030_gpio_platform_data omap3pandora_gpio_data = {
@@ -530,10 +591,67 @@ static void __init omap3pandora_init_irq(void)
omap_gpio_init();
}
+static void pandora_wl1251_set_power(bool enable)
+{
+ /*
+* Keep power always on until wl1251_sdio driver learns to re-init
+* the chip after powering it down and back up.
+*/
+}
+
+static struct wl12xx_platform_data pandora_wl1251_pdata = {
+ .set_power = pandora_wl1251_set_power,
+ .use_eeprom = true,
+};
+
+static struct platform_device pandora_wl1251_data = {
+ .name = wl1251_data,
+ .id = -1,
+ .dev= {
+ .platform_data = pandora_wl1251_pdata,
+ },
+};
+
+static void pandora_wl1251_init(void)
+{
+ int ret;
+
+ ret = gpio_request(PANDORA_WIFI_IRQ_GPIO, wl1251 irq);
+ if (ret 0)
+ goto fail;
+
+ ret = gpio_direction_input(PANDORA_WIFI_IRQ_GPIO);
+ if (ret 0)
+ goto fail_irq;
+
+ pandora_wl1251_pdata.irq = gpio_to_irq(PANDORA_WIFI_IRQ_GPIO);
+ if (pandora_wl1251_pdata.irq 0)
+ goto fail_irq;
+
+ ret = gpio_request(PANDORA_WIFI_NRESET_GPIO, wl1251 nreset);
+ if (ret 0)
+ goto fail_irq;
+
+ /* start powered so that it probes with MMC subsystem */
+ ret =
[PATCH 05/13] omap: rx51: Set regulator V28 always on
From: Jarkko Nikula jhnik...@gmail.com
It seems that the battery cover sensor in Nokia N900 is powered from the
V28 domain. Now if this regulator is disabled it causes that the gpio 160
reads only zero which effectively causes uSD removal detection.
Currently the bootloader enabled V28 is kept on but this may change in the
future according to comment in
drivers/regulator/core.c: regulator_has_full_constraints.
Also if there are any consumers on the V28 domain doing regulator_enable
regulator_disable cycle the V28 will be disabled after that.
Prepare for these by defining the V28 as always_on regulator.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 5ddf156..3d95534 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -361,6 +361,7 @@ static struct regulator_init_data rx51_vaux1 = {
.name = V28,
.min_uV = 280,
.max_uV = 280,
+ .always_on = true, /* due battery cover sensor */
.valid_modes_mask = REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
.valid_ops_mask = REGULATOR_CHANGE_MODE
--
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
[PATCH 06/13] omap: rx51: Add platform_data for tlv320aic3x with reset gpionumber
From: Jarkko Nikula jhnik...@gmail.com
Proper operation of the tlv320aic3x audio codec requires that reset
sequencing is done in pair with supply voltages when using the regulator
framework. Add the codec reset gpio used in Nokia RX51 to tlv320aic3x
data.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3d95534..e350f0b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -32,6 +32,8 @@
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include sound/tlv320aic3x.h
+
#include mux.h
#include hsmmc.h
@@ -707,6 +709,10 @@ static struct twl4030_platform_data rx51_twldata
__initdata = {
.vio= rx51_vio,
};
+static struct aic3x_pdata rx51_aic3x_data __initdata = {
+ .gpio_reset = 60,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_1[] = {
{
I2C_BOARD_INFO(twl5030, 0x48),
@@ -719,6 +725,7 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
+ .platform_data = rx51_aic3x_data,
},
};
--
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
[PATCH 03/13] omap3: pandora: update gpio-keys data
From: Grazvydas Ignotas nota...@gmail.com
Update gpio-keys setup so it matches what is on default firmware.
Also make use of debounce feature in gpio-keys instead of setting it
explicitly, as gpio-keys is now capable of using hardware debounce on
OMAPs thanks to recent gpiolib changes.
Also fix a sparce warning along the way.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3pandora.c | 30 ++
1 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index db06dc9..7a12729 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -48,9 +48,6 @@
#define OMAP3_PANDORA_TS_GPIO 94
-/* hardware debounce: (value + 1) * 31us */
-#define GPIO_DEBOUNCE_TIME 127
-
static struct gpio_led pandora_gpio_leds[] = {
{
.name = pandora::sd1,
@@ -88,6 +85,7 @@ static struct platform_device pandora_leds_gpio = {
.type = ev_type, \
.code = ev_code, \
.active_low = act_low, \
+ .debounce_interval = 4, \
.desc = btn descr, \
}
@@ -99,14 +97,14 @@ static struct gpio_keys_button pandora_gpio_keys[] = {
GPIO_BUTTON_LOW(103,KEY_DOWN, down),
GPIO_BUTTON_LOW(96, KEY_LEFT, left),
GPIO_BUTTON_LOW(98, KEY_RIGHT, right),
- GPIO_BUTTON_LOW(109,KEY_KP1,game 1),
- GPIO_BUTTON_LOW(111,KEY_KP2,game 2),
- GPIO_BUTTON_LOW(106,KEY_KP3,game 3),
- GPIO_BUTTON_LOW(101,KEY_KP4,game 4),
- GPIO_BUTTON_LOW(102,BTN_TL, l),
- GPIO_BUTTON_LOW(97, BTN_TL2,l2),
- GPIO_BUTTON_LOW(105,BTN_TR, r),
- GPIO_BUTTON_LOW(107,BTN_TR2,r2),
+ GPIO_BUTTON_LOW(109,KEY_PAGEUP, game 1),
+ GPIO_BUTTON_LOW(111,KEY_END,game 2),
+ GPIO_BUTTON_LOW(106,KEY_PAGEDOWN, game 3),
+ GPIO_BUTTON_LOW(101,KEY_HOME, game 4),
+ GPIO_BUTTON_LOW(102,KEY_RIGHTSHIFT, l),
+ GPIO_BUTTON_LOW(97, KEY_KPPLUS, l2),
+ GPIO_BUTTON_LOW(105,KEY_RIGHTCTRL, r),
+ GPIO_BUTTON_LOW(107,KEY_KPMINUS,r2),
GPIO_BUTTON_LOW(104,KEY_LEFTCTRL, ctrl),
GPIO_BUTTON_LOW(99, KEY_MENU, menu),
GPIO_BUTTON_LOW(176,KEY_COFFEE, hold),
@@ -127,14 +125,7 @@ static struct platform_device pandora_keys_gpio = {
},
};
-static void __init pandora_keys_gpio_init(void)
-{
- /* set debounce time for GPIO banks 4 and 6 */
- gpio_set_debounce(32 * 3, GPIO_DEBOUNCE_TIME);
- gpio_set_debounce(32 * 5, GPIO_DEBOUNCE_TIME);
-}
-
-static int board_keymap[] = {
+static const uint32_t board_keymap[] = {
/* row, col, code */
KEY(0, 0, KEY_9),
KEY(0, 1, KEY_8),
@@ -582,7 +573,6 @@ static void __init omap3pandora_init(void)
ARRAY_SIZE(omap3pandora_spi_board_info));
omap3pandora_ads7846_init();
usb_ehci_init(ehci_pdata);
- pandora_keys_gpio_init();
usb_musb_init(musb_board_data);
/* Ensure SDRC pins are mux'd for self-refresh */
--
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
[PATCH 08/13] omap: rx51: Add supply and data for the tpa6130a2 headphoneamplifier
From: Jarkko Nikula jhnik...@gmail.com
With these and upcoming change to tpa6130a2 driver it's possible to add
support for the TPA6130A2 headphone amplifier.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index b4c3dd7..3c3f975 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -33,6 +33,7 @@
#include plat/gpmc-smc91x.h
#include sound/tlv320aic3x.h
+#include sound/tpa6130a2-plat.h
#include mux.h
#include hsmmc.h
@@ -314,6 +315,8 @@ static struct regulator_consumer_supply
rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
REGULATOR_SUPPLY(AVDD, 2-0018),
REGULATOR_SUPPLY(DRVDD, 2-0018),
+ /* tpa6130a2 */
+ REGULATOR_SUPPLY(Vdd, 2-0060),
/* Keep vmmc as last item. It is not iterated for newer boards */
REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
@@ -692,6 +695,11 @@ static struct aic3x_pdata rx51_aic3x_data __initdata = {
.gpio_reset = 60,
};
+static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = {
+ .id = TPA6130A2,
+ .power_gpio = 98,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_1[] = {
{
I2C_BOARD_INFO(twl5030, 0x48),
@@ -706,6 +714,10 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
I2C_BOARD_INFO(tlv320aic3x, 0x18),
.platform_data = rx51_aic3x_data,
},
+ {
+ I2C_BOARD_INFO(tpa6130a2, 0x60),
+ .platform_data = rx51_tpa6130a2_data,
+ }
};
static int __init rx51_i2c_init(void)
--
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
[PATCH 09/13] tsl2563 ALS support for Nokia N900
From: Ameya Palande ameya.pala...@nokia.com
This commit will enable usage of tsl2563 ambient light sensor on Nokia N900.
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3c3f975..3ae3591 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -23,6 +23,7 @@
#include linux/gpio.h
#include linux/gpio_keys.h
#include linux/mmc/host.h
+#include ../drivers/staging/iio/light/tsl2563.h
#include plat/mcspi.h
#include plat/board.h
@@ -68,6 +69,10 @@ static struct omap2_mcspi_device_config tsc2005_mcspi_config
= {
.single_channel = 1,
};
+static struct tsl2563_platform_data rx51_tsl2563_platform_data = {
+ .cover_comp_gain = 16,
+ };
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -707,6 +712,9 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
.irq = INT_34XX_SYS_NIRQ,
.platform_data = rx51_twldata,
},
+ { I2C_BOARD_INFO(tsl2563, 0x29),
+ .platform_data = rx51_tsl2563_platform_data,
+ },
};
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
--
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
[PATCH 10/13] omap4: mmc: Fix the regulator resource for MMC2 on 4430sdp
From: Santosh Shilimkar santosh.shilim...@ti.com
The MMC1 and MMC2 cards have seperate LDO supplies. Current code assumes
that they are powered by same LDO.
This patch fixes the same and has VAUX1 as supply to MMC2 card.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Tested-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index e4a5d66..216870b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -156,14 +156,16 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
+static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
{
.supply = vmmc,
- .dev_name = mmci-omap-hs.0,
+ .dev_name = mmci-omap-hs.1,
},
+};
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
{
.supply = vmmc,
- .dev_name = mmci-omap-hs.1,
+ .dev_name = mmci-omap-hs.0,
},
};
@@ -210,6 +212,8 @@ static struct regulator_init_data sdp4430_vaux1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = sdp4430_vaux_supply,
};
static struct regulator_init_data sdp4430_vaux2 = {
@@ -250,7 +254,7 @@ static struct regulator_init_data sdp4430_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 2,
+ .num_consumer_supplies = 1,
.consumer_supplies = sdp4430_vmmc_supply,
};
--
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
[PATCH 07/13] omap: rx51: Use REGULATOR_SUPPLY macro when initializingregulator consumers
From: Jarkko Nikula jhnik...@gmail.com
There is REGULATOR_SUPPLY macro available for initializing the struct
regulator_consumer_supply so use it where applicable (all other supplies
than vdds_sdi) as it improves the readability.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 43 +++---
1 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e350f0b..b4c3dd7 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -301,48 +301,27 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct regulator_consumer_supply rx51_vmmc1_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.0,
-};
+static struct regulator_consumer_supply rx51_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
-static struct regulator_consumer_supply rx51_vaux3_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vaux3_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
-static struct regulator_consumer_supply rx51_vsim_supply = {
- .supply = vmmc_aux,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vsim_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
- {
- .supply = AVDD,
- .dev_name = 2-0018,
- },
- {
- .supply = DRVDD,
- .dev_name = 2-0018,
- },
+ REGULATOR_SUPPLY(AVDD, 2-0018),
+ REGULATOR_SUPPLY(DRVDD, 2-0018),
/* Keep vmmc as last item. It is not iterated for newer boards */
- {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
- },
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
static struct regulator_consumer_supply rx51_vio_supplies[] = {
/* tlv320aic3x digital supplies */
- {
- .supply = IOVDD,
- .dev_name = 2-0018
- },
- {
- .supply = DVDD,
- .dev_name = 2-0018
- },
+ REGULATOR_SUPPLY(IOVDD, 2-0018),
+ REGULATOR_SUPPLY(DVDD, 2-0018),
};
#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
--
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
[PATCH 12/13] OMAP4: Add GPIO LED support for SDP board
From: Hemanth V heman...@ti.com
This patch adds support for GPIO LEDs present on OMAP4
SDP and Blaze boards. This basically adds platform data
required by leds-gpio driver
Signed-off-by: Hemanth V heman...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c | 50 +++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index eb1775e..f287461 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -21,6 +21,7 @@
#include linux/spi/spi.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/leds.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -40,6 +41,54 @@
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+static struct gpio_led sdp4430_gpio_leds[] = {
+ {
+ .name = omap4:green:debug0,
+ .gpio = 61,
+ },
+ {
+ .name = omap4:green:debug1,
+ .gpio = 30,
+ },
+ {
+ .name = omap4:green:debug2,
+ .gpio = 7,
+ },
+ {
+ .name = omap4:green:debug3,
+ .gpio = 8,
+ },
+ {
+ .name = omap4:green:debug4,
+ .gpio = 50,
+ },
+ {
+ .name = omap4:blue:user,
+ .gpio = 169,
+ },
+ {
+ .name = omap4:red:user,
+ .gpio = 170,
+ },
+ {
+ .name = omap4:green:user,
+ .gpio = 139,
+ },
+
+};
+
+static struct gpio_led_platform_data sdp4430_led_data = {
+ .leds = sdp4430_gpio_leds,
+ .num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
+};
+
+static struct platform_device sdp4430_leds_gpio = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_led_data,
+ },
+};
static struct spi_board_info sdp4430_spi_board_info[] __initdata = {
{
.modalias = ks8851,
@@ -112,6 +161,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_leds_gpio,
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
--
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
[PATCH 13/13] Add OMAP4 Panda Support
From: David Anders x0132...@ti.com
Add initial support for the OMAP4 based Panda Board.
Signed-off-by: David Anders x0132...@ti.com
[t...@atomide.com: selected board by default in Kconfig]
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig|5 +
arch/arm/mach-omap2/Makefile |2
arch/arm/mach-omap2/board-omap4panda.c | 304
3 files changed, 311 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap4panda.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 84fecd0..b48bacf 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -238,6 +238,11 @@ config MACH_OMAP_4430SDP
default y
depends on ARCH_OMAP4
+config MACH_OMAP4_PANDA
+ bool OMAP4 Panda Board
+ default y
+ depends on ARCH_OMAP4
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d7be082..f5b4ff4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -145,6 +145,8 @@ obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) +=
board-omap3touchbook.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o \
hsmmc.o
+obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o \
+ hsmmc.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
new file mode 100644
index 000..c03d1d5
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -0,0 +1,304 @@
+/*
+ * Board support file for OMAP4430 based PandaBoard.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Based on mach-omap2/board-4430sdp.c
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Based on mach-omap2/board-3430sdp.c
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+#include linux/i2c/twl.h
+#include linux/regulator/machine.h
+
+#include mach/hardware.h
+#include mach/omap4-common.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/control.h
+#include plat/timer-gp.h
+#include plat/usb.h
+#include plat/mmc.h
+#include hsmmc.h
+
+
+static void __init omap4_panda_init_irq(void)
+{
+ omap2_init_common_hw(NULL, NULL);
+ gic_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_UTMI,
+ .mode = MUSB_PERIPHERAL,
+ .power = 100,
+};
+
+static struct omap2_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ .wires = 8,
+ .gpio_wp= -EINVAL,
+ },
+ {} /* Terminator */
+};
+
+static struct regulator_consumer_supply omap4_panda_vmmc_supply[] = {
+ {
+ .supply = vmmc,
+ .dev_name = mmci-omap-hs.0,
+ },
+ {
+ .supply = vmmc,
+ .dev_name = mmci-omap-hs.1,
+ },
+};
+
+static int omap4_twl6030_hsmmc_late_init(struct device *dev)
+{
+ int ret = 0;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ struct omap_mmc_platform_data *pdata = dev-platform_data;
+
+ /* Setting MMC1 Card detect Irq */
+ if (pdev-id == 0)
+ pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
+ MMCDETECT_INTR_OFFSET;
+ return ret;
+}
+
+static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
+{
+ struct omap_mmc_platform_data *pdata = dev-platform_data;
+
+ pdata-init = omap4_twl6030_hsmmc_late_init;
+}
+
+static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers)
+{
+ struct omap2_hsmmc_info *c;
+
+ omap2_hsmmc_init(controllers);
+ for (c = controllers; c-mmc; c++)
+ omap4_twl6030_hsmmc_set_late_init(c-dev);
+
+ return 0;
+}
+
+static struct regulator_init_data omap4_panda_vaux1 = {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+
[PATCH 11/13] omap4: Board changes for 4430sdp tmp105 temperature sensor
From: Shubhrajyoti Datta shubhrajy...@ti.com
Adding board configuration for the tmp105
temperature sensor. The interface to the sensor
is I2C.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 216870b..eb1775e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -357,6 +357,11 @@ static struct i2c_board_info __initdata
sdp4430_i2c_boardinfo[] = {
.platform_data = sdp4430_twldata,
},
};
+static struct i2c_board_info __initdata sdp4430_i2c_3_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(tmp105, 0x48),
+ },
+};
static int __init omap4_i2c_init(void)
{
/*
@@ -366,7 +371,8 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(1, 400, sdp4430_i2c_boardinfo,
ARRAY_SIZE(sdp4430_i2c_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
- omap_register_i2c_bus(3, 400, NULL, 0);
+ omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
--
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 0/5 v2] omap2/3/4: serial fixes
Hi, * Nishanth Menon n...@ti.com [100623 07:12]: V1: http://marc.info/?l=linux-omapm=127074926903371w=2 The patch for Errata i202 went through a series of discussions ending in V3: http://marc.info/?l=linux-omapm=127109794814030w=2 This series introduces an errata variable, does a few sparse cleanups and provides fix for an new errata. I've added these to devel-serial-errata branch with some minor cosmetic edits. Left out the obvious Cc for people that we know are reading the mailing lists, then left out the link for the first patch, and moved the link in the last patch at the end of the commit message. Will repost shortly after some tests so they get reviewed also on LAKML. Regards, Tony -- 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 11/11] staging: ti dspbridge: enable driver building
On Wed, Jul 7, 2010 at 12:31 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jul 6, 2010 at 6:52 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: at that point *you* wanted your patches not to be included if the last one wasn't merged in. Not without the copyright update patch. ... So. Would you care to give a reason why my contributions don't deserve a copyright? Disclaimer: I am not a lawyer, and I speak only for myself in this post, and doesn't represent TI in anyway. AFAICT, you get copyright for every kernel change you submit and is accepted. Even if you just contribute whitespace cleanups, you get the copyright to those cleanups (not to suggest this was the sole contribution here). The copyright assignment is per the actual git commit itself, obviously, and it doesn't apply for the rest of the code in those files you edited. There are some exceptions, but they are not applicable here: - Usually when you get paid for the work, the employer keeps the copyright of the patch, not the author. - There are some projects where you have to relinquish the copyright in order for the patch to be accepted. This is how FSF (Free Software Foundation) projects work (e.g. gcc), but not the Linux kernel (which is not a FSF project). As I mentioned, I don't think these exceptions apply in this case, and AFAICT, Felipe - you inherently get the copyright for the changes that your accepted patches introduce. So it all boils down to the semantic question whether to edit the header file, adding new copyright lines, or not. Felipe, I think your contributions are important and helpful, and I would personally be happy if you continue to do them. I personally don't think that adding an explicit copyright line to the header should be important, because you get your copyright anyway. The exact change, to which you get copyright on, is kept in the git history, and will not likely to go away. I think this is pretty satisfying, and as a result, you don't see people(/companies) changing copyright headers when they submit kernel patches that edit existing files. The only thing I am not sure about, and that may be a concern to TI, is whether adding a copyright line in the header might actually give copyright ownership for the complete file. If this is true, I can understand why TI might not be so keen in adding copyright owners to the file header, without explicitly specifying what is the copyright about (not to suggest any opinion of TI on the matter, I speak only for myself). Again: I am not a lawyer, and I speak only for myself in this post, and doesn't represent TI in anyway. Thanks, Ohad. -- Felipe Contreras -- 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 1/3] omap3 gpmc: functionality enhancement
* Sukumar Ghorai s-gho...@ti.com [100604 10:34]:
few functions added in gpmc module and to be used by other drivers like NAND.
E.g.: - ioctl function
- ecc functions
Uhh, let's leave out ioctl from the description.. Otherwise people
think you're adding new ioctls in this patch.
@@ -46,8 +46,9 @@
#define GPMC_ECC_CONFIG 0x1f4
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
+#define GPMC_ECC1_RESULT0x200
-#define GPMC_CS0 0x60
+#define GPMC_CS0_BASE0x60
#define GPMC_CS_SIZE 0x30
#define GPMC_MEM_START 0x
Why changing GPMC_CS0 to GPMC_CS0_BASE? Should it rather be
GPMC_CS0_OFFSET?
@@ -419,8 +437,100 @@ void gpmc_cs_free(int cs)
EXPORT_SYMBOL(gpmc_cs_free);
/**
+ * gpmc_hwcontrol - hardware specific access (read/ write) control
+ * @cs: chip select number
+ * @cmd: command type
+ * @write: 1 for write; 0 for read
+ * @wval: value to write
+ * @rval: read pointer
+ */
+int gpmc_hwcontrol(int cs, int cmd, int write, int wval, int *rval)
+{
+ u32 regval = 0;
+
+ if (!write !rval)
+ return -EINVAL;
You pass int write, then return immediately if it's not set?
+ switch (cmd) {
+ case GPMC_STATUS_BUFFER:
+ regval = gpmc_read_reg(GPMC_STATUS);
+ /* 1 : buffer is available to write */
+ *rval = regval GPMC_STATUS_BUFF_EMPTY;
+ break;
+
+ case GPMC_GET_SET_IRQ_STATUS:
+ if (write)
+ gpmc_write_reg(GPMC_IRQSTATUS, wval);
+ else
+ *rval = gpmc_read_reg(GPMC_IRQSTATUS);
+ break;
+
+ case GPMC_PREFETCH_FIFO_CNT:
+ regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ *rval = GPMC_PREFETCH_STATUS_FIFO_CNT(regval);
+ break;
+
+ case GPMC_PREFETCH_COUNT:
+ regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ *rval = GPMC_PREFETCH_STATUS_COUNT(regval);
+ break;
+
+ case GPMC_CONFIG_WP:
+ regval = gpmc_read_reg(GPMC_CONFIG);
+ if (wval)
+ regval = ~GPMC_CONFIG_WRITEPROTECT; /* WP is ON */
+ else
+ regval |= GPMC_CONFIG_WRITEPROTECT; /* WP is OFF */
+ gpmc_write_reg(GPMC_CONFIG, regval);
+ break;
+
+ case GPMC_CONFIG_RDY_BSY:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_CONFIG_DEV_SIZE:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= GPMC_CONFIG1_DEVICESIZE(wval);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_CONFIG_DEV_TYPE:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= GPMC_CONFIG1_DEVICETYPE(wval);
+ if (wval == GPMC_DEVICETYPE_NOR)
+ regval |= GPMC_CONFIG1_MUXADDDATA;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_NAND_COMMAND:
+ gpmc_cs_write_byte(cs, GPMC_CS_NAND_COMMAND, wval);
+ break;
+
+ case GPMC_NAND_ADDRESS:
+ gpmc_cs_write_byte(cs, GPMC_CS_NAND_ADDRESS, wval);
+ break;
+
+ case GPMC_NAND_DATA:
+ if (write)
+ gpmc_cs_write_byte(cs, GPMC_CS_NAND_DATA, wval);
+ else
+ *rval = gpmc_cs_read_byte(cs, GPMC_CS_NAND_DATA);
+ break;
+
+ default:
+ printk(KERN_ERR gpmc_hwcontrol: Not supported\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(gpmc_hwcontrol);
You should just replace this function with simple functions like we already
have in gpmc.c rather than trying to pack everything into one function.
Just add various gpmc_xxx_get/set functions rather than pass int *rval.
Regards,
Tony
--
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 2/3] omap3 nand: cleanup virtual address usages
* Sukumar Ghorai s-gho...@ti.com [100604 10:34]:
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -63,7 +60,6 @@
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
-#define GPMC_CONFIG1_DEVICETYPE_NANDGPMC_CONFIG1_DEVICETYPE(2)
#define GPMC_CONFIG1_MUXADDDATA (1 9)
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 4)
#define GPMC_CONFIG1_FCLK_DIV(val) (val 3)
Is this no longer needed?
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -21,13 +21,11 @@ struct omap_nand_platform_data {
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
unsigned long phys_base;
- void __iomem*gpmc_cs_baseaddr;
- void __iomem*gpmc_baseaddr;
int devsize;
};
Glad to see these finally going away!
Regards,
Tony
--
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: [RFC][PATCH] omap3: Unify omap2_set_globals_3[43,6x]x functions
* Kevin Hilman khil...@deeprootsystems.com [100630 01:18]: Sergio Aguirre saagui...@ti.com writes: The only difference between them is the physical address of the uart4 port, which is only present in 36xx chips. We don't really need to care about keeping these 2 functions, since the decision to use uart4 is more cleanly done later when we do have access to omap_revision variable. Also, with the converion of UART to hwmod, there is no longer any need for UART base addresses in the globals struct (they've been removed in the work-in-progress conversion of UART. Signed-off-by: Sergio Aguirre saagui...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com I've applied this and added a comment for the uart4 only being on omap3630. Tony -- 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] omap3: introduce omap3_map_io
* Mike Rapoport m...@compulab.co.il [100630 11:46]: Hi Tony, Here's the patch. It applies on top of Sergio's patch Unify omap2_set_globals_3[43,6x]x functions. Thanks. I'll queue this one. However, it conflicts with the ARM: OMAP: Convert to use -reserve method to reserve boot time memory patch, so I need to get a static commit from Russell to apply this on. Regards, Tony -- 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
OK to base some patches on lmb branch?
Hi Russell, Is your lmb branch going to stay static? I'd like to base a patch unifying omap3 map_io on top of that to avoid merge conflicts: https://patchwork.kernel.org/patch/108775/ Otherwise it will conflict with your LMB related patch Convert to use -reserve method to reserve boot time memory. Regards, Tony -- 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
[APPLIED] [PATCH] omap: mux: fix multipath gpio handling
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 916c48fbec05b4718b4fd447f634725ced6cc9e7 PatchWorks http://patchwork.kernel.org/patch/110284/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=916c48fbec05b4718b4fd447f634725ced6cc9e7 -- 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
[APPLIED] [PATCH 1/1] omap: dma: Support for prefetch in destination
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 9a72a8860452681cb455ed164c2913743493b1f0 PatchWorks http://patchwork.kernel.org/patch/108773/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=9a72a8860452681cb455ed164c2913743493b1f0 -- 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
[APPLIED] [PATCHv4 1/1] OMAP3: AM3505/3517 do not have IO wakeup capability
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): b6c6aa94d0dd3dd05f42412fc39628520f72f63e PatchWorks http://patchwork.kernel.org/patch/108524/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b6c6aa94d0dd3dd05f42412fc39628520f72f63e -- 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 v3]OMAP:GPTIMER:1ms tick generation correction
* Tarun Kanti DebBarma tarun.ka...@ti.com [100622 12:35]:
+/**
+ * omap_dm_timer_ms_correction - hardware correction for millisecond timer
+ * @timer: GPTIMER on which the correction support is to be applied
+ * @load: timer load value, used here to extract the expiry count
+ */
+static void omap_dm_timer_ms_correction(struct omap_dm_timer *timer, u32
load)
+{
+ int pos_increment, neg_increment;
+ unsigned int count = (0x - load) * 1024;
+
+ pos_increment = (DIV_ROUND_UP(count, 1000) * 100) \
+ - (count * 1000);
+ neg_increment = ((DIV_ROUND_UP(count, 1000) - 1) * 100) \
+ - (count * 1000);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_TICK_POS_REG, pos_increment);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_TICK_NEG_REG, neg_increment);
+}
struct omap_dm_timer *omap_dm_timer_request(void)
{
@@ -612,6 +639,10 @@ void omap_dm_timer_set_load_start(struct omap_dm_timer
*timer, int autoreload,
{
u32 l;
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (timer-ms_correction)
+ omap_dm_timer_ms_correction(timer, load);
+#endif
l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
if (autoreload) {
l |= OMAP_TIMER_CTRL_AR;
How do you know that the timer is configured to use the 32KiHZ source?
Also, since omap2_gp_timer_set_next_event calls all the time,
we don't want to do this calculation for every tick.. So we should
make it a separate optional function.
Or can we somehow calculate this drift once during init?
Regards,
Tony
--
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 v3] serial: Add OMAP high-speed UART driver
* Govindraj govindraj...@gmail.com [100608 09:24]: On Mon, Jun 7, 2010 at 9:45 PM, Luke-Jr l...@dashjr.org wrote: On Monday 07 June 2010 08:28:51 am Govindraj wrote: Link: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summa ry Branch: pm-wip/uart This branch doesn't appear to have omap-serial.c at all... If you are trying to use with any client device connected to uart then we need to ensure the client driver speaks to omap-serial dev entries. You need apply the driver patch on top of this branch. [PATCH v3] serial: Add OMAP high-speed UART driver. Do we still have a dependency to pm-wip/uart branch? Can you please check if you can rebase all these patches on top of linux-omap for-next branch? Regards, Tony -- 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: [PATCHv2 0/3] Devkit8000: Use DIE id to initialize dm9000 MAC address
* Kan-Ru Chen ka...@0xlab.org [100706 04:09]: This patch series add the omap_get_die_id interface and use that function to construct a MAC address for use by dm9000. Thanks, I've applied these into omap for-next branch. Regards, Tony -- 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 v3] serial: Add OMAP high-speed UART driver
On Wed, Jul 7, 2010 at 5:32 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj govindraj...@gmail.com [100608 09:24]: On Mon, Jun 7, 2010 at 9:45 PM, Luke-Jr l...@dashjr.org wrote: On Monday 07 June 2010 08:28:51 am Govindraj wrote: Link: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summa ry Branch: pm-wip/uart This branch doesn't appear to have omap-serial.c at all... If you are trying to use with any client device connected to uart then we need to ensure the client driver speaks to omap-serial dev entries. You need apply the driver patch on top of this branch. [PATCH v3] serial: Add OMAP high-speed UART driver. Do we still have a dependency to pm-wip/uart branch? Can you please check if you can rebase all these patches on top of linux-omap for-next branch? pm-wip uart branch is having all the mach-omap2/serail.c changes along with hwmod data file updation and serial hwmod usage. The driver patch [serial: Add OMAP high-speed UART driver] was tested against wip/uart branch. I will re-base all these patches for-next branch, and will post driver and board support patches from pm-wip/uart as a single series. Thanks, Govindraj.R Regards, Tony -- --- Regards, Govindraj.R -- 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 2/3] omap3 nand: cleanup virtual address usages
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, July 07, 2010 3:52 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
m...@compulab.co.il
Subject: Re: [PATCH v5 2/3] omap3 nand: cleanup virtual address usages
* Sukumar Ghorai s-gho...@ti.com [100604 10:34]:
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -63,7 +60,6 @@
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
-#define GPMC_CONFIG1_DEVICETYPE_NANDGPMC_CONFIG1_DEVICETYPE(2)
#define GPMC_CONFIG1_MUXADDDATA (1 9)
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 4)
#define GPMC_CONFIG1_FCLK_DIV(val) (val 3)
Is this no longer needed?
[Ghorai] we pass GPMC_CONFIG_DEV_TYPE and GPMC_DEVICETYPE_NAND to
gpmc_hwcontrol(); And GPMC_DEVICETYPE_NAND define in previous patch of the same
series.
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -21,13 +21,11 @@ struct omap_nand_platform_data {
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
unsigned long phys_base;
- void __iomem*gpmc_cs_baseaddr;
- void __iomem*gpmc_baseaddr;
int devsize;
};
Glad to see these finally going away!
Regards,
Tony
--
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 4/9] omap: improve OMAP3_HAS_FEATURE
* Nishanth Menon n...@ti.com [100623 05:10]:
Replace OMAP3_HAS_FEATURE with OMAP_HAS_FEATURE allowing
us to support multiple chip features
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/include/plat/cpu.h | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 5f12a0b..c71dbf4 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -444,6 +444,12 @@ static inline void omap1_check_revision(void) {}
#endif
void omap_check_revision(void);
+#define OMAP_HAS_FEATURE(rev, feat, flag)\
+static inline unsigned int omap##rev##_has_ ##feat(void) \
+{\
+ return omap##rev##_features OMAP##rev##_HAS_ ##flag; \
+}\
+
/*
* Runtime detection of OMAP3 features
*/
@@ -456,17 +462,11 @@ extern u32 omap3_features;
#define OMAP3_HAS_ISPBIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-#define OMAP3_HAS_FEATURE(feat,flag) \
-static inline unsigned int omap3_has_ ##feat(void) \
-{\
- return (omap3_features OMAP3_HAS_ ##flag);\
-}\
-
-OMAP3_HAS_FEATURE(l2cache, L2CACHE)
-OMAP3_HAS_FEATURE(sgx, SGX)
-OMAP3_HAS_FEATURE(iva, IVA)
-OMAP3_HAS_FEATURE(neon, NEON)
-OMAP3_HAS_FEATURE(isp, ISP)
-OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
+OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(3, sgx, SGX)
+OMAP_HAS_FEATURE(3, iva, IVA)
+OMAP_HAS_FEATURE(3, neon, NEON)
+OMAP_HAS_FEATURE(3, isp, ISP)
+OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
Why don't you just rename u32 omap3_features to omap_features?
Then maybe move omap_features to plat-omap/common.c, and have
a generic function for getting features?
There should not be any need to have separate features variable
for each omap.
Tony
--
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 6/9] omap: move generic omap3 features to generic
* Nishanth Menon n...@ti.com [100623 05:15]: @@ -354,11 +354,11 @@ static void __init omap3_cpuinfo(void) /* Print verbose information */ pr_info(%s ES%s (, cpu_name, cpu_rev); - OMAP_SHOW_FEATURE(3, l2cache); - OMAP_SHOW_FEATURE(3, iva); - OMAP_SHOW_FEATURE(3, sgx); - OMAP_SHOW_FEATURE(3, neon); - OMAP_SHOW_FEATURE(3, isp); + OMAP_SHOW_FEATURE(, l2cache); + OMAP_SHOW_FEATURE(, iva); + OMAP_SHOW_FEATURE(, sgx); + OMAP_SHOW_FEATURE(, neon); + OMAP_SHOW_FEATURE(, isp); OMAP_SHOW_FEATURE(3, 192mhz_clk); Then you can simplify OMAP_SHOW_FEATURE too as the 3, should not be needed? Tony -- 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 v3]OMAP:GPTIMER:1ms tick generation correction
--- On Wed, 7/7/10, Tony Lindgren t...@atomide.com wrote: Or can we somehow calculate this drift once during init? If it's set up in the gentime framework, yes; very standard. AT91 is one model (they all have 32K clocks used to generate the system tick). -- 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 3/9 v3] omap: generic: introduce a single check_revision
* Nishanth Menon n...@ti.com [100625 19:19]:
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..4a0e333 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,12 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+ omap1_check_revision();
+ omap2_check_revision();
+}
+
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..5f12a0b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP1
+extern void omap1_check_revision(void);
+#else
+static inline void omap1_check_revision(void) {}
+#endif
+void omap_check_revision(void);
Hmm, to me it seems like we should have static omap_check_revision
in both mach-omap1/id.c and mach-omap2/id.c. Or do we need to call
these anywhere else outside both id.c files?
Then these can set u32 omap_revision flags in plat-omap/common.c,
and then we can have a common omap_get_revision() or something
in plat-omap/common.c?
There should not be need for cpu_is_omap tests for getting
the revision after it's initialized.
Regards,
Tony
--
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 v3]OMAP:GPTIMER:1ms tick generation correction
* David Brownell davi...@pacbell.net [100707 15:26]: --- On Wed, 7/7/10, Tony Lindgren t...@atomide.com wrote: Or can we somehow calculate this drift once during init? If it's set up in the gentime framework, yes; very standard. AT91 is one model (they all have 32K clocks used to generate the system tick). OK thats good to hear. Tony -- 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 1/3] omap3 gpmc: functionality enhancement
* Ghorai, Sukumar s-gho...@ti.com [100707 15:26]: From: Tony Lindgren [mailto:t...@atomide.com] You should just replace this function with simple functions like we already have in gpmc.c rather than trying to pack everything into one function. Just add various gpmc_xxx_get/set functions rather than pass int *rval. [Ghorai] So I was having the same query very 1st time. So we need to implement 15 separate functions to do the same as you suggested. And in my approach it's very easy to enhance the functionally in future, say to add new set/get. E.g. we need the similar cleanup for OneNAND code too. So, would you please confirm once again with one is the best and should follow? In general, we should have separate read and write functions. Maybe you can group them a little bit? Some of them need the chip select, and some of them are generic. Then some of them are NAND specific. Regards, Tony -- 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 4/9] omap: improve OMAP3_HAS_FEATURE
Tony Lindgren had written, on 07/07/2010 07:28 AM, the following:
* Nishanth Menon n...@ti.com [100623 05:10]:
Replace OMAP3_HAS_FEATURE with OMAP_HAS_FEATURE allowing
us to support multiple chip features
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/include/plat/cpu.h | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 5f12a0b..c71dbf4 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -444,6 +444,12 @@ static inline void omap1_check_revision(void) {}
#endif
void omap_check_revision(void);
+#define OMAP_HAS_FEATURE(rev, feat, flag)\
+static inline unsigned int omap##rev##_has_ ##feat(void) \
+{ \
+ return omap##rev##_features OMAP##rev##_HAS_ ##flag; \
+} \
+
/*
* Runtime detection of OMAP3 features
*/
@@ -456,17 +462,11 @@ extern u32 omap3_features;
#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-#define OMAP3_HAS_FEATURE(feat,flag) \
-static inline unsigned int omap3_has_ ##feat(void) \
-{ \
- return (omap3_features OMAP3_HAS_ ##flag);\
-} \
-
-OMAP3_HAS_FEATURE(l2cache, L2CACHE)
-OMAP3_HAS_FEATURE(sgx, SGX)
-OMAP3_HAS_FEATURE(iva, IVA)
-OMAP3_HAS_FEATURE(neon, NEON)
-OMAP3_HAS_FEATURE(isp, ISP)
-OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
+OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(3, sgx, SGX)
+OMAP_HAS_FEATURE(3, iva, IVA)
+OMAP_HAS_FEATURE(3, neon, NEON)
+OMAP_HAS_FEATURE(3, isp, ISP)
+OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
Why don't you just rename u32 omap3_features to omap_features?
Then maybe move omap_features to plat-omap/common.c, and have
a generic function for getting features?
There should not be any need to have separate features variable
for each omap.
192Mhz_clk is a OMAP3 only feature(differentiator b/w omap3430,35xx and
3630, 37xx).
overall, we will face this in the future. there are OMAP generic
features and OMAP family specific features. currently OMAP3 has 34xx,
35xx series and 3630 and 37xx series. in future we may see similar
things for OMAP4+ as well.. we need a differentiator when it comes to
omap3 specific features Vs omap generic feature.
--
Regards,
Nishanth Menon
--
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 4/9] omap: improve OMAP3_HAS_FEATURE
* Nishanth Menon n...@ti.com [100707 16:09]:
Why don't you just rename u32 omap3_features to omap_features?
Then maybe move omap_features to plat-omap/common.c, and have
a generic function for getting features?
There should not be any need to have separate features variable
for each omap.
192Mhz_clk is a OMAP3 only feature(differentiator b/w omap3430,35xx
and 3630, 37xx).
Hmm, maybe it should be defined as l3_max_clk or similar instead?
overall, we will face this in the future. there are OMAP generic
features and OMAP family specific features. currently OMAP3 has
34xx, 35xx series and 3630 and 37xx series. in future we may see
similar things for OMAP4+ as well.. we need a differentiator when it
comes to omap3 specific features Vs omap generic feature.
Sounds it will get more complex.. We should probably set it up
with something like this then:
#define FEAT_MPU_L2_OUTER BIT(1)
#define FEAT_MPU_L2 BIT(0)
...
#define FEAT_IVA2 BIT(1)
#define FEAT_IVABIT(0)
...
#define FEAT_L3_192 BIT(0)
...
struct omap_feature {
u32 mpu;/* MPU features */
u32 iva;/* IVA features */
u32 l3_max_clk;
...
};
Regards,
Tony
--
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 4/9] omap: improve OMAP3_HAS_FEATURE
Tony Lindgren had written, on 07/07/2010 08:30 AM, the following:
* Nishanth Menon n...@ti.com [100707 16:09]:
Why don't you just rename u32 omap3_features to omap_features?
Then maybe move omap_features to plat-omap/common.c, and have
a generic function for getting features?
There should not be any need to have separate features variable
for each omap.
192Mhz_clk is a OMAP3 only feature(differentiator b/w omap3430,35xx
and 3630, 37xx).
Hmm, maybe it should be defined as l3_max_clk or similar instead?
it was meant as special feature of DPLL4 as i recollect
Reference:
http://marc.info/?t=12657893665r=1w=2
overall, we will face this in the future. there are OMAP generic
features and OMAP family specific features. currently OMAP3 has
34xx, 35xx series and 3630 and 37xx series. in future we may see
similar things for OMAP4+ as well.. we need a differentiator when it
comes to omap3 specific features Vs omap generic feature.
Sounds it will get more complex.. We should probably set it up
with something like this then:
#define FEAT_MPU_L2_OUTER BIT(1)
#define FEAT_MPU_L2 BIT(0)
...
#define FEAT_IVA2 BIT(1)
#define FEAT_IVABIT(0)
...
#define FEAT_L3_192 BIT(0)
...
struct omap_feature {
u32 mpu;/* MPU features */
u32 iva;/* IVA features */
u32 l3_max_clk;
...
};
I think I understand your intent here is to introduce per IP based
feature - that is really not necessary yet (we dont really have a
usecase needing this level of complexity yet). it will be a natural
evolution when we need to have such a feature handling.
currently a need for errata handling per ip is required, and we have a
mechanism (quirks) to handle it on a IP basis. here the intent was to
identify OMAP specific features in some common way.
Regards,
Tony
--
Regards,
Nishanth Menon
--
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 11/15] wireless: wl1271: introduce platform device support
On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 08:42 PM, ext Nicolas Pitre wrote: On Tue, 6 Jul 2010, Roger Quadros wrote: OK, this is how I see it. - Treat the non-removable card as non-removable. So no need to do card detect emulation. - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator framework to define this regulator supply. Even though you mention that it is not actually a supply, it fits well in the fixed supply framework. - When the host controller is enumerated, the mmc core will power up the slot, find the sdio card, and probe the function driver (i.e. wl1271_sdio). - if interface is not in use, the function driver must release the sdio host, and this should eventually disable the vmmc supply. - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the sdio host. this will cause the vmmc supply to be enabled, for as long as the interface is up. Does this address all issues? This is mostly all good, except that claiming/releasing the SDIO host is about access to the bus. It must be claimed right before doing any IO, and released right after that, even when the card is expected to remain powered. This is not the proper place to hook power control. Agreed, but is it so that SDIO power may be removed between a host_release and claim? This appears so from omap_hsmmc host controller. No, it is not because a host is not claimed that power should be dropped. The host claim/release is meant to provide exclusive access to the card that's all. If the OMAP controller is dropping power to the card upon host-disable() then it is wrong. AFAICS only the OMAP controller is playing such games at the moment and I suspect the semantics might not be all right. Shutting down the _controller_ when it is idle might be a good thing, but not power to the _card_. Only the function driver might know when it is fine to lose power. Nicolas -- 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 11/15] wireless: wl1271: introduce platform device support
On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call -enable() / -disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host-bus_ops-power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card. This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using. I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down. Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie with the bus drivers? Absolutely! And in the SDIO case that should lie with each function drivers. Please let's stop this omap_hsmmc madness. Nicolas -- 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
[PATCH v6] OMAP4 HSMMC: Adding Card detect support for MMC1 on OMAP4
Adding card detect callback function and card detect configuration
function for MMC1 Controller.
Card detect configuration function does initial configuration of the
MMC Control PullUp-PullDown registers of Phoenix.
For MMC1 Controller, Card detect interrupt source is
twl6030 and the card detect call back function provides card present/absent
status by reading MMC Control register.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
---
V5:
https://patchwork.kernel.org/patch/106697/
https://patchwork.kernel.org/patch/106698/
V4:
http://www.mail-archive.com/linux-...@vger.kernel.org/msg01958.html
http://www.mail-archive.com/linux-...@vger.kernel.org/msg01949.html
arch/arm/mach-omap2/board-4430sdp.c |7 +++-
drivers/mfd/twl6030-irq.c | 76 +++
drivers/mmc/host/omap_hsmmc.c |4 +-
include/linux/i2c/twl.h | 16 +++
4 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index f287461..388b96d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device
*dev)
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+ if (ret)
+ pr_err(Failed configuring MMC1 card detect\n);
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+ pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+ }
return ret;
}
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..c027692 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
#include linux/irq.h
#include linux/kthread.h
#include linux/i2c/twl.h
+#include linux/platform_device.h
/*
* TWL6030 (unlike its predecessors, which had two level interrupt handling)
@@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+ if (twl_class_is_6030()) {
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_STS_B);
+ }
+
+ /*
+* Intially Configuring MMC_CTRL for receving interrupts
+* Card status on TWL6030 for MMC1
+*/
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
+ }
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
+ ret);
+ }
+ reg_val = ~(MMC_PU | MMC_PD);
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ pr_err(twl6030: Failed to write CFG_INPUT_PUPD3, error %d\n,
+ ret);
+ return ret;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
+
+int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ int ret = -EIO;
+ u8 read_reg;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+
+ switch (pdev-id) {
+ case 0:
+ /*
+* BIT0 of REG_MMC_CTRL
+* 0 - Card not present ,1 - Card present
+*/
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, read_reg,
+ TWL6030_MMCCTRL);
+ if
RE: [PATCH v3]OMAP:GPTIMER:1ms tick generation correction
Tony,
Thanks for the comments! Please see my response.
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, July 07, 2010 5:30 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; R, Sricharan
Subject: Re: [PATCH v3]OMAP:GPTIMER:1ms tick generation correction
* Tarun Kanti DebBarma tarun.ka...@ti.com [100622 12:35]:
+/**
+ * omap_dm_timer_ms_correction - hardware correction for millisecond
timer
+ * @timer: GPTIMER on which the correction support is to be applied
+ * @load: timer load value, used here to extract the expiry count
+ */
+static void omap_dm_timer_ms_correction(struct omap_dm_timer *timer,
u32 load)
+{
+ int pos_increment, neg_increment;
+ unsigned int count = (0x - load) * 1024;
+
+ pos_increment = (DIV_ROUND_UP(count, 1000) * 100) \
+ - (count * 1000);
+ neg_increment = ((DIV_ROUND_UP(count, 1000) - 1) * 100) \
+ - (count * 1000);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_TICK_POS_REG,
pos_increment);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_TICK_NEG_REG,
neg_increment);
+}
struct omap_dm_timer *omap_dm_timer_request(void)
{
@@ -612,6 +639,10 @@ void omap_dm_timer_set_load_start(struct
omap_dm_timer *timer, int autoreload,
{
u32 l;
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ if (timer-ms_correction)
+ omap_dm_timer_ms_correction(timer, load);
+#endif
l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
if (autoreload) {
l |= OMAP_TIMER_CTRL_AR;
How do you know that the timer is configured to use the 32KiHZ source?
[Tarun]
At this point we do not know. The point is we need not know.
The caller function calculates the load based upon the source clock frequency.
Viz. sys_clk or 32Khz. Please note that correction is needed both for sys_clk
and 32Khz clock.
Also, since omap2_gp_timer_set_next_event calls all the time,
we don't want to do this calculation for every tick.. So we should
make it a separate optional function.
[Tarun]
Agreed, but need some clarification here.
At first my intention was to make the call to omap_dm_timer_ms_correction()
just once since the tick period is supposed to be constant. However, during
testing it was found that the caller of omap2_gp_timer_set_next_event(unsigned
long cycles,...) passes different values for cycles and so different load
value. This gave me the impression that caller framework is programming for
counts related to different number ticks with the necessity to apply
omap_dm_timer_ms_correction() every time.
I would be glad to get feedback on my observation.
Or can we somehow calculate this drift once during init?
As described, for a constant tick we would need to compute and program just
once, during initialization.
Regards,
Tony
--
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] OMAP: Fix for bus width which improves SD card's peformance.
Tony,
Could this patch be taken ?
Thanks,
kishore
On Tue, Jun 15, 2010 at 1:37 PM, kishore kadiyala
kishorek.kadiy...@gmail.com wrote:
From: Kishore Kadiyala kishore.kadiy...@ti.com
This patch improves low speeds for SD cards.
OMAP-MMC controller's can support maximum bus width of '8'.
when bus width is mentioned as 8 in controller data,the SD
stack will check whether bus width is 4 and if not it will
set bus width to 1 and there by degrading performance.
This patch fixes the issue and improves the performance of
SD cards.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Tested-by: Jarkko Nikula jhnik...@gmail.com
---
In V5 : Rebasing on 2.6.35-rc3
In V4 : Updated with Nishanth's comments and appened his Signed-off
http://marc.info/?t=12716914936r=1w=2
In V3 : Updated with Madhu's comments and appended Tested by Nikula
In V2 : Appended Signed-off by Venkat and Ack by Madhu
Here are my experiment numbers, on a Class 6 SDHC card:
Read peformance is increased by 220%
Write Performance is increased by 52%
drivers/mmc/host/omap_hsmmc.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..a0c8515 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2096,10 +2096,23 @@ static int __init omap_hsmmc_probe(struct
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_WAIT_WHILE_BUSY;
- if (mmc_slot(host).wires = 8)
+ switch (mmc_slot(host).wires) {
+ case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
- else if (mmc_slot(host).wires = 4)
+ /* Fall through */
+ case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
+ break;
+ case 1:
+ /* Nothing to crib here */
+ case 0:
+ /* Assuming nothing was given by board, Core use's 1-Bit */
+ break;
+ default:
+ /* Completely unexpected.. Core goes with 1-Bit Width */
+ dev_crit(mmc_dev(host-mmc), Invalid width %d\n used!
+ using 1 instead\n, mmc_slot(host).wires);
+ }
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
--
1.6.3.3
--
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 11/15] wireless: wl1271: introduce platform device support
-Original Message- From: Nicolas Pitre [mailto:n...@fluxnic.net] Sent: Wednesday, July 07, 2010 9:03 AM To: Roger Quadros Cc: Hunter Adrian (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux- wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Coelho Luciano (Nokia-MS/Helsinki); a...@linux-foundation.org; San Mehat Subject: Re: [PATCH 11/15] wireless: wl1271: introduce platform device support On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call -enable() / -disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host-bus_ops-power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card. This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using. I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down. The point is that MMC/SD core files were patched to provide this kind of a support. Any controller driver can use that framework today, right?. As an example omap_hsmmc driver was patched and it works fine. Why blame the controller driver for using a support provided by core files? Regards, Madhu Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie with the bus drivers? Absolutely! And in the SDIO case that should lie with each function drivers. Please let's stop this omap_hsmmc madness. Nicolas -- 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
mtd_pagetest fails with omap2 OneNAND driver
Hello, I need some help to understand what is wrong, maybe someone can help me. I'm running an OMAP3-based board with a OneNAND from Numonyx, the problem is some mtd tests fails. An example is the mtd_pagetest, the erase test fails. [ 937.885925] mtd_pagetest: erasetest [ 937.889434] mtd_pagetest: erasing block 0 [ 937.895721] mtd_pagetest: writing 1st page of block 0 [ 937.901550] mtd_pagetest: erasing block 0 [ 937.907623] mtd_pagetest: reading 1st page of block 0 [ 937.912994] mtd_pagetest: verifying 1st page of block 0 is all 0xff [ 937.919342] mtd_pagetest: verifying all 0xff failed at 0 [ 937.924713] mtd_pagetest: finished with 1 errors If I read the mtd contents # mtd_debug read /dev/mtd4 0 1024 output.log # hexdump output.log 000 1caf ecfa 976b aa81 700a 9ce1 5427 32eb looks like the mtd partition it's not erased, but If I use the flash_eraseall tool erases the flash completely without problem # flash_eraseall /dev/mtd4 Erasing 256 Kibyte @ fa8 -- 100 % complete. # mtd_debug read /dev/mtd4 0 1024 output.log Copied 1024 bytes from address 0x in flash to file.log # hexdump output.log 000 * 400 So I don't understand why this test fails. Any idea what might be wrong ? Here the full log [ 775.590270] = [ 775.596160] mtd_pagetest: MTD device: 4 [ 775.603851] mtd_pagetest: MTD device size 262668288, eraseblock size 262144, page size 4096, count of eraseblocks 1002, pages per eraseblock 64, OOB size 64 [ 775.618408] mtd_pagetest: scanning for bad eraseblocks [ 775.624420] mtd_pagetest: scanned 1002 eraseblocks, 0 are bad [ 775.630218] mtd_pagetest: erasing whole device [ 777.486846] mtd_pagetest: erased 1002 eraseblocks [ 777.491638] mtd_pagetest: writing whole device [ 777.531585] mtd_pagetest: written up to eraseblock 0 [ 786.519378] mtd_pagetest: written up to eraseblock 256 [ 795.505706] mtd_pagetest: written up to eraseblock 512 [ 804.488769] mtd_pagetest: written up to eraseblock 768 [ 812.668182] mtd_pagetest: written 1002 eraseblocks [ 812.673126] mtd_pagetest: verifying all eraseblocks [ 812.803375] mtd_pagetest: verified up to eraseblock 0 [ 844.772460] mtd_pagetest: verified up to eraseblock 256 [ 876.734741] mtd_pagetest: verified up to eraseblock 512 [ 908.696838] mtd_pagetest: verified up to eraseblock 768 [ 937.791229] mtd_pagetest: verified 1002 eraseblocks [ 937.796234] mtd_pagetest: crosstest [ 937.800903] mtd_pagetest: reading page at 0x0 [ 937.805877] mtd_pagetest: reading page at 0xfa7f000 [ 937.811096] mtd_pagetest: reading page at 0x0 [ 937.816070] mtd_pagetest: verifying pages read at 0x0 match [ 937.821838] mtd_pagetest: crosstest ok [ 937.825622] mtd_pagetest: erasecrosstest [ 937.829589] mtd_pagetest: erasing block 0 [ 937.835906] mtd_pagetest: writing 1st page of block 0 [ 937.841552] mtd_pagetest: reading 1st page of block 0 [ 937.847198] mtd_pagetest: verifying 1st page of block 0 [ 937.852600] mtd_pagetest: erasing block 0 [ 937.858734] mtd_pagetest: writing 1st page of block 0 [ 937.864379] mtd_pagetest: erasing block 1001 [ 937.870788] mtd_pagetest: reading 1st page of block 0 [ 937.876342] mtd_pagetest: verifying 1st page of block 0 [ 937.881652] mtd_pagetest: erasecrosstest ok [ 937.885925] mtd_pagetest: erasetest [ 937.889434] mtd_pagetest: erasing block 0 [ 937.895721] mtd_pagetest: writing 1st page of block 0 [ 937.901550] mtd_pagetest: erasing block 0 [ 937.907623] mtd_pagetest: reading 1st page of block 0 [ 937.912994] mtd_pagetest: verifying 1st page of block 0 is all 0xff [ 937.919342] mtd_pagetest: verifying all 0xff failed at 0 [ 937.924713] mtd_pagetest: finished with 1 errors [ 937.929870] = Thanks in advance, Enric -- 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 11/15] wireless: wl1271: introduce platform device support
On Wed, 7 Jul 2010, Madhusudhan wrote: -Original Message- From: Nicolas Pitre [mailto:n...@fluxnic.net] Sent: Wednesday, July 07, 2010 9:03 AM To: Roger Quadros Cc: Hunter Adrian (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux- wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Coelho Luciano (Nokia-MS/Helsinki); a...@linux-foundation.org; San Mehat Subject: Re: [PATCH 11/15] wireless: wl1271: introduce platform device support On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call -enable() / -disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host-bus_ops-power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card. This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using. I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down. The point is that MMC/SD core files were patched to provide this kind of a support. Any controller driver can use that framework today, right?. As an example omap_hsmmc driver was patched and it works fine. It is not because you are twisting the layers and customizing the core stack around your own controller that it is good software design. And the presence of the mmc_power_restore_host() code doesn't mean it is sane. My point is that no one should ever use that, not even omap_hsmmc. Proof: it works so fine that now you must come up with yet another contorted hack piled on top called fake^H^H^H^Hsoftware insert/remove events to support power handling with SDIO cards. This MMC_CAP_DISABLE is ridiculous. Why would this have to be a host capability? This should be a core feature that should be _transparent_ to all hosts with no changes to any of the host drivers. When the core code knows that the card can be shut down after some idle period, it should do so with the *existing* API calls, namely the set_ios method. In the SDIO case it would be a simple matter of mapping the sdio_release_power() onto that. Instead, some contorted power management support was sneaked in, which is misdesigned to the point of breaking proper SDIO support for which more misdesigned features are now needed to work around the former ones. Now the OMAP driver is becoming a stack of its own, making decisions that clearly should be made at a higher level of abstraction. To me this denotes some laziness from the involved developers who didn't take the time to design something sensible and generic in the core code, but rather hacked a quick solution specific to omap_hmmc.c. Of course the former would require a greater understanding of common code and some additional effort to make the solution truly generic. Instead, the easy solution was taken which is to stuff magic behaviors in a host driver while other people are not paying as much attention to it than core code. Needless to say that I'm not impressed at all. Nicolas -- 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
[PATCH] omap: hwspinlock: Added hwspinlock driver
Hello, This is the patch submission for the hardware spinlock driver. I will not be available for the next 4 weeks. Please contact Hari Kanigeri (h-kanige...@ti.com) instead. Thanks, Simon == From 509bd1a2e7e5c1a6af3248742e0d53ca5f9fd066 Mon Sep 17 00:00:00 2001 From: Simon Que s...@ti.com Date: Wed, 23 Jun 2010 18:40:30 -0500 Subject: [PATCH] omap: hwspinlock: Added hwspinlock driver Created driver for OMAP hardware spinlock. This driver supports: - Reserved spinlocks for internal use - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization uses hwmod to configure the devices. One device will be created for each IP. It will pass spinlock register offset info to the driver. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c The driver takes in register offset info passed in device initialization. It uses hwmod to obtain the base address of the hardware spinlock module. Then it reads info from the registers. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address calculated from the base address and lock offsets. The device driver file is: arch/arm/plat-omap/hwspinlock.c Here's an API summary: int hwspinlock_lock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will keep trying until it succeeds. This is a blocking function. int hwspinlock_trylock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will return BUSY. If it succeeds in locking, the function will return ACQUIRED. This is a non-blocking function. int hwspinlock_unlock(struct hwspinlock *); Unlock a hardware spinlock. struct hwspinlock *hwspinlock_request(void); Provides for dynamic allocation of a hardware spinlock. It returns the handle to the next available (unallocated) spinlock. If no more locks are available, it returns NULL. struct hwspinlock *hwspinlock_request_specific(unsigned int); Provides for static allocation of a specific hardware spinlock. This allows the system to use a specific spinlock, identified by an ID. If the ID is invalid or if the desired lock is already allocated, this will return NULL. Otherwise it returns a spinlock handle. int hwspinlock_free(struct hwspinlock *); Frees an allocated hardware spinlock (either reserved or unreserved). Signed-off-by: Simon Que s...@ti.com --- arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/hwspinlocks.c| 71 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/Makefile |3 +- arch/arm/plat-omap/hwspinlock.c | 335 ++ arch/arm/plat-omap/include/plat/hwspinlock.h | 29 +++ arch/arm/plat-omap/include/plat/omap44xx.h |2 + 7 files changed, 442 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/hwspinlocks.c create mode 100644 arch/arm/plat-omap/hwspinlock.c create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6725b3a..5f5c87b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -170,3 +170,5 @@ obj-y += $(nand-m) $(nand-y) smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o obj-y += $(smc91x-m) $(smc91x-y) + +obj-$(CONFIG_ARCH_OMAP4) += hwspinlocks.o \ No newline at end of file diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach-omap2/hwspinlocks.c new file mode 100644 index 000..58a6483 --- /dev/null +++ b/arch/arm/mach-omap2/hwspinlocks.c @@ -0,0 +1,71 @@ +/* + * OMAP hardware spinlock device initialization + * + * Copyright (C) 2010 Texas Instruments. All rights reserved. + * + * Contact: Simon Que s...@ti.com + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/module.h +#include linux/interrupt.h +#include linux/device.h +#include linux/delay.h
Re: [PATCH 3/9 v3] omap: generic: introduce a single check_revision
Tony Lindgren had written, on 07/07/2010 07:36 AM, the following:
* Nishanth Menon n...@ti.com [100625 19:19]:
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index fca73cd..4a0e333 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -89,6 +89,12 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_lmb();
}
+void __init omap_check_revision(void)
+{
+ omap1_check_revision();
+ omap2_check_revision();
+}
+
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..5f12a0b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -431,7 +431,18 @@ IS_OMAP_TYPE(3517, 0x3517)
int omap_chip_is(struct omap_chip_id oci);
-void omap2_check_revision(void);
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern void omap2_check_revision(void);
+#else
+static inline void omap2_check_revision(void) {}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP1
+extern void omap1_check_revision(void);
+#else
+static inline void omap1_check_revision(void) {}
+#endif
+void omap_check_revision(void);
Hmm, to me it seems like we should have static omap_check_revision
in both mach-omap1/id.c and mach-omap2/id.c. Or do we need to call
these anywhere else outside both id.c files?
check_revision is called from mach-omap[12]/io.c - so no chance of the
check_revision to be static..
Then these can set u32 omap_revision flags in plat-omap/common.c,
and then we can have a common omap_get_revision() or something
in plat-omap/common.c?
i think I managed to get rid of it entirely.. ref: attached patch
If we are ok with this, I will repost the series (i squashed
omap1-rename-check_revision into this patch).
There should not be need for cpu_is_omap tests for getting
the revision after it's initialized.
I am not sure.. if you would like drivers to be modprobabe, there may be
quirks that you'd want to enable based on cpu_is_omapxxx checks. so it
probably does not make sense to __initdata the revision/feature variables.
--
Regards,
Nishanth Menon
From f72070e575433ad07ed018aef5c43677424003d0 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Fri, 21 May 2010 12:09:33 -0500
Subject: [PATCH 2/7] omap: generic: introduce a single check_revision
Introduce a single omap generic check_revision that routes the
request to the right revision of check_revision.
Note: OMAP1 and OMAP2+ are not built into a single kernel.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap1/io.c |1 -
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/include/plat/cpu.h |3 ++-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 0ce3fec..4f9ee73 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -20,7 +20,6 @@
#include clock.h
-extern void omap_check_revision(void);
extern void omap_sram_init(void);
/*
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index c7bf0e1..80f0950 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -371,7 +371,7 @@ static void __init omap3_cpuinfo(void)
/*
* Try to detect the exact revision of the omap we're running on
*/
-void __init omap2_check_revision(void)
+void __init omap_check_revision(void)
{
/*
* At this point we have an idea about the processor revision set
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b9ea70b..75883fe 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,7 +238,7 @@ static void __init _omap2_map_common_io(void)
local_flush_tlb_all();
flush_cache_all();
- omap2_check_revision();
+ omap_check_revision();
omap_sram_init();
}
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
Nicolas Pitre wrote: On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call -enable() / -disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host-bus_ops-power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card. This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using. The power control decision does come from the top via mmc_claim_host / mmc_release_host. I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down. The omap_hsmmc driver does not tell the core to shut down the upper layers. Instead the core tells the omap_hsmmc driver that it is disabled i.e. not currently being used so it can start taking steps to save power. That is sensible because not even the upper layers know when the next activity will be. Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie with the bus drivers? Absolutely! And in the SDIO case that should lie with each function drivers. Please let's stop this omap_hsmmc madness. You are dealing with a trivial case - turn off the power when not in use. We have 3 power saving actions: enable DPS, put the card to sleep, and finally power it off. Each increases the latency to start up again and so must be staggered. With DPS-enabled the host controller can be powered off at any time. In that case the controller registers must be restored. There are numerous entry points to the driver. Checking whether to restore registers at every entry point is error prone and messy. Instead we require that the core tells the driver when to enable and disable. 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 -- 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 11/11] staging: ti dspbridge: enable driver building
From: Felipe Contreras [mailto:felipe.contre...@gmail.com] I'm removing many people from the Cc which I think don't care about this. Is this even the right place for discussing about it? On Tue, Jul 6, 2010 at 6:52 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: On 7/4/2010 5:53 AM, Felipe Contreras wrote: On Thu, Jun 24, 2010 at 1:41 AM, Greg KHg...@kroah.com wrote: So I need some more Kconfig changes here, care to redo just this one patch? I've applied all the others and they will show up in linux-next tomorrow. I fixed all that stuff some time ago: http://article.gmane.org/gmane.linux.ports.arm.omap/36065 But the patches were ignored. Patches were not ignored, discussion was held privately (you and me), That was for the deh reorganization. Not the Kconfig ones. Yes, you are right, somehow opening this link showed the deh reorganization patches, my bad. But then again patches were not ignored, I sent you a notification that I was wrongly tracking the first patch for dspbridge branch in case you might wanted to resend again. Discussion, if any, about copyrights can be done in the patch itself. - omar -- 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 3/8] musb: fix compilation warning in host only mode
On Tue, Jul 06, 2010 at 12:13:14PM +0300, Felipe Balbi wrote: Hi, On Thu, Jun 24, 2010 at 01:17:54PM +0200, ext Gupta, Ajay Kumar wrote: Fixes below compilation warning when host only configuration is selected. drivers/usb/musb/musb_core.c: In function 'musb_stage0_irq': drivers/usb/musb/musb_core.c:711: warning: unused variable 'mbase' Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Acked-by: Felipe Balbi felipe.ba...@nokia.com You've acked a random ammount of patches recently, are you going to be resending them to me? I have a hard time going back and digging through the archives to pick out the ones that you acked vs. the ones you didn't. thanks, greg k-h -- 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: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 07, 2010 at 03:44:27PM -0700, Zach Pfeffer wrote: The DMA API handles the allocation and use of DMA channels. It can configure physical transfer settings, manage scatter-gather lists, etc. You're confused about what the DMA API is. You're talking about the DMA engine subsystem (drivers/dma) not the DMA API (see Documentation/DMA-API.txt, include/linux/dma-mapping.h, and arch/arm/include/asm/dma-mapping.h) The VCM allows all device buffers to be passed between all devices in the system without passing those buffers through each domain's API. This means that instead of writing code to interoperate between DMA engines, IOMMU mapped spaces, CPUs and physically addressed devices the user can simply target a device with a buffer using the same API regardless of how that device maps or otherwise accesses the buffer. With the DMA API, if we have a SG list which refers to the physical pages (as a struct page, offset, length tuple), the DMA API takes care of dealing with CPU caches and IOMMUs to make the data in the buffer visible to the target device. It provides you with a set of cookies referring to the SG lists, which may be coalesced if the IOMMU can do so. If you have a kernel virtual address, the DMA API has single buffer mapping/unmapping functions to do the same thing, and provide you with a cookie to pass to the device to refer to that buffer. These cookies are whatever the device needs to be able to access the buffer - for instance, if system SDRAM is located at 0xc000 virtual, 0x8000 physical and 0x4000 as far as the DMA device is concerned, then the cookie for a buffer at 0xc000 virtual will be 0x4000 and not 0x8000. -- 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
linux-next: manual merge of the omap tree with the arm tree
Hi all, Today's linux-next merge of the omap tree got conflicts in arch/arm/mach-omap2/board-3430sdp.c, arch/arm/mach-omap2/board-3630sdp.c, arch/arm/mach-omap2/board-am3517evm.c, arch/arm/mach-omap2/board-cm-t35.c, arch/arm/mach-omap2/board-devkit8000.c, arch/arm/mach-omap2/board-igep0020.c, arch/arm/mach-omap2/board-ldp.c, arch/arm/mach-omap2/board-omap3beagle.c, arch/arm/mach-omap2/board-omap3evm.c, arch/arm/mach-omap2/board-omap3pandora.c, arch/arm/mach-omap2/board-omap3touchbook.c, arch/arm/mach-omap2/board-overo.c, arch/arm/mach-omap2/board-zoom2.c and arch/arm/mach-omap2/board-zoom3.c between commit 1e6d923b4e5729b73518d241edf87a3ab2d5688c (ARM: OMAP: Convert to use -reserve method to reserve boot time memory) from the arm tree and commit c752ab9d5a5b6899f14fe1c6643c0fe0b499a4ba (omap3: introduce omap3_map_io) from the omap tree. Just context changes. I fixed it up (see below) and can carry the fix as necessary. P.S. Tony, that omap tree commit has a fairly unuseful changelog and no SOB from its purported author ... -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm/mach-omap2/board-3430sdp.c index dd9c031,e51f8e3..000 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@@ -814,8 -808,7 +808,8 @@@ MACHINE_START(OMAP_3430SDP, OMAP3430 3 .phys_io= 0x4800, .io_pg_offst= ((0xfa00) 18) 0xfffc, .boot_params= 0x8100, - .map_io = omap_3430sdp_map_io, + .map_io = omap3_map_io, + .reserve= omap_reserve, .init_irq = omap_3430sdp_init_irq, .init_machine = omap_3430sdp_init, .timer = omap_timer, diff --cc arch/arm/mach-omap2/board-3630sdp.c index 57290fb,8b7c2f9..000 --- a/arch/arm/mach-omap2/board-3630sdp.c +++ b/arch/arm/mach-omap2/board-3630sdp.c @@@ -107,8 -100,7 +100,8 @@@ MACHINE_START(OMAP_3630SDP, OMAP 3630S .phys_io= 0x4800, .io_pg_offst= ((0xfa00) 18) 0xfffc, .boot_params= 0x8100, - .map_io = omap_sdp_map_io, + .map_io = omap3_map_io, + .reserve= omap_reserve, .init_irq = omap_sdp_init_irq, .init_machine = omap_sdp_init, .timer = omap_timer, diff --cc arch/arm/mach-omap2/board-am3517evm.c index 7da92de,bbfdc6e..000 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@@ -471,8 -465,7 +465,8 @@@ MACHINE_START(OMAP3517EVM, OMAP3517/AM .phys_io= 0x4800, .io_pg_offst= ((0xd800) 18) 0xfffc, .boot_params= 0x8100, - .map_io = am3517_evm_map_io, + .map_io = omap3_map_io, + .reserve= omap_reserve, .init_irq = am3517_evm_init_irq, .init_machine = am3517_evm_init, .timer = omap_timer, diff --cc arch/arm/mach-omap2/board-cm-t35.c index bc4c3f8,79d6b15..000 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@@ -836,8 -830,7 +830,8 @@@ MACHINE_START(CM_T35, Compulab CM-T35 .phys_io= 0x4800, .io_pg_offst= ((0xd800) 18) 0xfffc, .boot_params= 0x8100, - .map_io = cm_t35_map_io, + .map_io = omap3_map_io, + .reserve= omap_reserve, .init_irq = cm_t35_init_irq, .init_machine = cm_t35_init, .timer = omap_timer, diff --cc arch/arm/mach-omap2/board-devkit8000.c index 922b746,4b7103a..000 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@@ -824,8 -826,7 +826,8 @@@ MACHINE_START(DEVKIT8000, OMAP3 Devkit .phys_io= 0x4800, .io_pg_offst= ((0xd800) 18) 0xfffc, .boot_params= 0x8100, - .map_io = devkit8000_map_io, + .map_io = omap3_map_io, + .reserve= omap_reserve, .init_irq = devkit8000_init_irq, .init_machine = devkit8000_init, .timer = omap_timer, diff --cc arch/arm/mach-omap2/board-igep0020.c index 759e39d,b26319c..000 --- a/arch/arm/mach-omap2/board-igep0020.c +++ b/arch/arm/mach-omap2/board-igep0020.c @@@ -542,8 -536,7 +536,8 @@@ MACHINE_START(IGEP0020, IGEP v2 board .phys_io= 0x4800, .io_pg_offst= ((0xfa00) 18) 0xfffc, .boot_params= 0x8100, - .map_io = igep2_map_io, + .map_io = omap3_map_io, + .reserve= omap_reserve, .init_irq = igep2_init_irq, .init_machine = igep2_init, .timer = omap_timer, diff --cc arch/arm/mach-omap2/board-ldp.c index 9cd2669,6e3930e..000 --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@@ -416,8 -410,7 +410,8 @@@ MACHINE_START(OMAP_LDP, OMAP LDP board
RE: [PATCH 3/8] musb: fix compilation warning in host only mode
Hi, On Thu, Jun 24, 2010 at 01:17:54PM +0200, ext Gupta, Ajay Kumar wrote: Fixes below compilation warning when host only configuration is selected. drivers/usb/musb/musb_core.c: In function 'musb_stage0_irq': drivers/usb/musb/musb_core.c:711: warning: unused variable 'mbase' Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Acked-by: Felipe Balbi felipe.ba...@nokia.com You've acked a random ammount of patches recently, are you going to be resending them to me? I have a hard time going back and digging through the archives to pick out the ones that you acked vs. the ones you didn't. Greg, There are 2 musb and 1 ehci-omap bug fix patches which are acked. Another related one is on ULPI and is trivial. Apart from these, 2 musb patches for v2.6.36 window are also acked. I will prepare the set and send you after sanity testing. Thanks, Ajay thanks, greg k -- 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: [RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate API
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
Sent: Friday, July 02, 2010 5:18 AM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Basak, Partha; Gopinath, Thara
Subject: [RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate API
This patch updates the cpufreq driver to use the device
set rate API to scale the mpu frequency for OMAP3.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/cpu-omap.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 9467827..cde02b5 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -29,6 +29,7 @@
#include mach/hardware.h
#include plat/clock.h
#include asm/system.h
+#include plat/omap_device.h
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
#include plat/omap-pm.h
@@ -84,7 +85,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
-#ifdef CONFIG_ARCH_OMAP1
+#ifdef CONFIG_ARiCH_OMAP1
^^
Typo I guess. Needs correction.
struct cpufreq_freqs freqs;
#endif
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
@@ -117,7 +118,7 @@ static int omap_target(struct cpufreq_policy *policy,
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
freq = target_freq * 1000;
if (opp_find_freq_ceil(mpu_dev, freq))
- omap_pm_cpu_set_freq(freq);
+ omap_device_set_rate(mpu_dev, freq);
#endif
return ret;
}
--
1.7.0.rc1.33.g07cf0f
--
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
--
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: [RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate API
-Original Message-
From: Pandita, Vikram
Sent: Thursday, July 08, 2010 8:40 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant,
Anand; Basak, Partha
Subject: RE: [RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate
API
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
Sent: Friday, July 02, 2010 5:18 AM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Basak, Partha; Gopinath, Thara
Subject: [RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate API
This patch updates the cpufreq driver to use the device
set rate API to scale the mpu frequency for OMAP3.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/cpu-omap.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 9467827..cde02b5 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -29,6 +29,7 @@
#include mach/hardware.h
#include plat/clock.h
#include asm/system.h
+#include plat/omap_device.h
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
#include plat/omap-pm.h
@@ -84,7 +85,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
-#ifdef CONFIG_ARCH_OMAP1
+#ifdef CONFIG_ARiCH_OMAP1
^^
Typo I guess. Needs correction.
Yep.. Thanks..
Regards
Thara
struct cpufreq_freqs freqs;
#endif
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
@@ -117,7 +118,7 @@ static int omap_target(struct cpufreq_policy *policy,
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
freq = target_freq * 1000;
if (opp_find_freq_ceil(mpu_dev, freq))
-omap_pm_cpu_set_freq(freq);
+omap_device_set_rate(mpu_dev, freq);
#endif
return ret;
}
--
1.7.0.rc1.33.g07cf0f
--
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
--
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 3/8] musb: fix compilation warning in host only mode
On Thu, Jul 08, 2010 at 07:23:44AM +0530, Gupta, Ajay Kumar wrote: Hi, On Thu, Jun 24, 2010 at 01:17:54PM +0200, ext Gupta, Ajay Kumar wrote: Fixes below compilation warning when host only configuration is selected. drivers/usb/musb/musb_core.c: In function 'musb_stage0_irq': drivers/usb/musb/musb_core.c:711: warning: unused variable 'mbase' Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Acked-by: Felipe Balbi felipe.ba...@nokia.com You've acked a random ammount of patches recently, are you going to be resending them to me? I have a hard time going back and digging through the archives to pick out the ones that you acked vs. the ones you didn't. Greg, There are 2 musb and 1 ehci-omap bug fix patches which are acked. Another related one is on ULPI and is trivial. Apart from these, 2 musb patches for v2.6.36 window are also acked. I will prepare the set and send you after sanity testing. That sounds great, thanks for doing this. greg k-h -- 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 06/15] omap zoom2: wlan board muxing
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 06/15] omap zoom2: wlan board muxing
From: Ohad Ben-Cohen oh...@ti.com
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM2.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-
omap2/board-zoom2.c
index 803ef14..00871be 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -71,6 +71,21 @@ static struct twl4030_platform_data zoom2_twldata = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+#ifdef CONFIG_OMAP_ZOOM_WLAN
[Ghorai] This is zoom board specific file, So why need this additional flag?
+ /* WLAN IRQ - GPIO 162 */
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.0.4
--
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
--
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 04/15] mmc: support embedded data field in mmc_host
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 04/15] mmc: support embedded data field in mmc_host
From: Ohad Ben-Cohen oh...@ti.com
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
Typically, it will be used to set the context of
a driver that is creating a new SDIO function
(and would then expect to be able to get that context
back upon creation of the new sdio func).
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/mmc/core/Kconfig |8
include/linux/mmc/host.h | 16
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index bb22ffd..ab27eb3 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
This option sets a default which can be overridden by the
module parameter removable=0 or removable=1.
+
+config MMC_EMBEDDED_SDIO
+ boolean MMC embedded SDIO device support
+ help
+ If you say Y here, support will be added for embedded SDIO
+ devices (e.g. hardwired embedded WLAN SDIO devices).
+ Such devices require software support for emulating
+ card detect events.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f65913c..9a48486 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -209,6 +209,10 @@ struct mmc_host {
struct led_trigger *led; /* activity led */
#endif
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+ void*embedded_data;
+#endif
+
struct dentry *debugfs_root;
unsigned long private[0] cacheline_aligned;
@@ -264,5 +268,17 @@ static inline void mmc_set_disable_delay(struct
mmc_host *host,
host-disable_delay = disable_delay;
}
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+static inline void *mmc_get_embedded_data(struct mmc_host *host)
+{
+ return host-embedded_data;
+}
+
+static inline void mmc_set_embedded_data(struct mmc_host *host, void
*data)
+{
+ host-embedded_data = data;
+}
+#endif
+
[Ghorai] we can avoid CONFIG_MMC_EMBEDDED_SDIO flag itself. Why we are passing
fixed data? We can enquire form card for the functions, features,.. and at
runtime itself. And we are adding many compile-time/kconfig options in this
patch series.
#endif
--
1.7.0.4
--
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
--
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 00/15] wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3
-Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen Sent: Tuesday, July 06, 2010 6:08 AM To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux- foundation.org; San Mehat; Ben-cohen, Ohad Subject: [PATCH 00/15] wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3 From: Ohad Ben-Cohen oh...@ti.com The ZOOM2/3 boards include TI's wl1271 wlan sdio device, hardwired to the 3rd mmc controller. These patches add support for WLAN on the ZOOM2/3 boards using only mainline components (most notably mac80211 and wl1271). Patches were tested on both ZOOM2 and ZOOM3. In short, these patches add software control for emulating card detect events, add board configurations to support the wl1271 device, and update the wl1271 driver to make use of these new mechanisms. Software card detect emulation is based on Android's EMBEDDED_SDIO patch by San Mehat s...@google.com (thanks, San!). These patches span over several differnt subsystems, but since they are highly dependent on each other, it is preferrable to pull them all together into a single tree (once approved). Patches are available at: git://wizery.com/pub/linux-2.6.git wl1271 And will also be sent as a follow-on to this message to the omap, mmc, arm and wireless mailing lists. Patches are based on mainline 2.6.35-rc4, but can easily be applied on wireless-testing (with two minor conflicts). If desired, I can rebase to wireless-testing and resend. Note: last missing part for full mainline community support of the wl1271 on ZOOM is the firmware, and for that there is already on-going TI work to provide it in linux-firmware. Hopefully that would be resolved soon. Thanks, Ohad Ben-Cohen (15): sdio: add TI + wl1271 ids wireless: wl1271: remove SDIO IDs from driver omap: mmc: prepare for software card detect support mmc: support embedded data field in mmc_host omap: hsmmc: add virtual card detect support omap zoom2: wlan board muxing omap zoom3: wlan board muxing wireless: wl1271: make wl12xx.h common to both spi and sdio wireless: wl12xx: support pdata SDIO handlers wireless: wl1271: support return value for the set power func wireless: wl1271: introduce platform device support wireless: wl1271: take irq info from platform data wireless: wl1271: make ref_clock configurable by board omap: zoom: add WLAN device omap: zoom: enable WLAN device arch/arm/mach-omap2/Kconfig |5 + arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-zoom-peripherals.c | 15 ++ arch/arm/mach-omap2/board-zoom-wlan.c | 129 arch/arm/mach-omap2/board-zoom2.c | 15 ++ arch/arm/mach-omap2/board-zoom3.c | 15 ++ arch/arm/mach-omap2/hsmmc.c |4 + arch/arm/mach-omap2/hsmmc.h |5 + arch/arm/mach-omap2/include/mach/board-zoom.h |5 + arch/arm/plat-omap/include/plat/mmc.h |5 + drivers/mmc/core/Kconfig |8 + drivers/mmc/host/omap_hsmmc.c | 37 +- drivers/net/wireless/wl12xx/Kconfig |1 + drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +- drivers/net/wireless/wl12xx/wl1251_spi.c |2 +- drivers/net/wireless/wl12xx/wl1271.h |8 +- drivers/net/wireless/wl12xx/wl1271_boot.c | 13 +- drivers/net/wireless/wl12xx/wl1271_boot.h |1 - drivers/net/wireless/wl12xx/wl1271_io.h |8 +- drivers/net/wireless/wl12xx/wl1271_main.c |4 +- drivers/net/wireless/wl12xx/wl1271_sdio.c | 204 +++- - drivers/net/wireless/wl12xx/wl1271_spi.c |8 +- include/linux/mmc/host.h | 16 ++ include/linux/mmc/sdio_ids.h |3 + include/linux/spi/wl12xx.h| 34 include/linux/wl12xx.h| 37 + 26 files changed, 486 insertions(+), 99 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c delete mode 100644 include/linux/spi/wl12xx.h create mode 100644 include/linux/wl12xx.h [Ghorai] This patch series having the CONFIG_MMC_EMBEDDED_SDIO as kconfig option and I feel we should void this. This could be a generic and can be get from sdio card at runtime. Quite long codes are adding in this patch series under this flag. -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to
RE: [PATCH 15/15] omap: zoom: enable WLAN device
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 15/15] omap: zoom: enable WLAN device
From: Ohad Ben-Cohen oh...@ti.com
Make it possible to build and use TI's wl1271
device on the ZOOM boards.
The device is an embedded SDIO WLAN chip
that is hardwired to the 3rd mmc controller
of the ZOOM2/3 boards.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 15 +++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b31b6f1..7fee11b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -131,6 +131,11 @@ config MACH_OMAP_ZOOM3
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBP
+config OMAP_ZOOM_WLAN
+ bool OMAP Zoom board WLAN support
+ depends on MACH_OMAP_ZOOM2 || MACH_OMAP_ZOOM3
+ select MMC_EMBEDDED_SDIO
+
config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ea52b03..ac1bad9 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -129,6 +129,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-
zoom3.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
+obj-y+= board-zoom-wlan.o
obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \
board-zoom-peripherals.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-
omap2/board-zoom-peripherals.c
index 6b39849..3128cd4 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,11 +16,13 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/mmc/host.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include mach/board-zoom.h
#include plat/common.h
#include plat/usb.h
@@ -168,6 +170,18 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable = true,
.power_saving = true,
},
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+ {
+ .mmc= 3,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .register_embedded_control =
+ omap_zoom_wlan_register_embedded_control,
+ .virtual_get_cd = omap_zoom_wlan_get_virtual_cd,
+ .ocr_mask = MMC_VDD_165_195,
+ },
+#endif
{} /* Terminator */
};
@@ -282,4 +296,5 @@ void __init zoom_peripherals_init(void)
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
+ omap_zoom_wlan_init();
}
[Ghorai] In general we can avoid OMAP_ZOOM_WLAN and MMC_EMBEDDED_SDIO as
kconfig option. 1st one is board specific and 2nd one could be generic sdio
code. As I mentioned in other patch too.
--
1.7.0.4
--
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
--
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 14/15] omap: zoom: add WLAN device
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 14/15] omap: zoom: add WLAN device
From: Ohad Ben-Cohen oh...@ti.com
Add WLAN platform device and control
functions (power and virtual card detect)
in order to allow software to control the
embedded SDIO WLAN device which resides on
the ZOOM board (TI's wl1271 device).
Based on Android's WLAN control functions by
San Mehat s...@android.com.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/board-zoom-wlan.c | 129
+
arch/arm/mach-omap2/include/mach/board-zoom.h |5 +
2 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c
diff --git a/arch/arm/mach-omap2/board-zoom-wlan.c b/arch/arm/mach-
omap2/board-zoom-wlan.c
new file mode 100644
index 000..7ed5139
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-wlan.c
@@ -0,0 +1,129 @@
+/* mach-omap2/board-zoom-wlan.c
+ *
+ * Board support for wl1271 embedded SDIO device.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
License
+ * version 2. This program is licensed as is without any warranty of
any
+ * kind, whether express or implied.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/mmc/host.h
+#include linux/mmc/sdio_ids.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/wl12xx.h
+
+#include mux.h
+
+#ifdef CONFIG_OMAP_ZOOM_WLAN
[Ghorai] Again the file itself is zoom specific, why we need the additional
flag?
+
+/* these are zoom-specific board numbers */
+#define OMAP_ZOOM_WLAN_PMENA_GPIO(101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO (162)
+
+/* wl1271 virtual 'card detect' status */
+static int omap_zoom_wlan_cd;
+static void (*wlan_set_virtual_cd)(void *dev_id, int card_present);
+static void (*wlan_set_data)(void *dev_id, void *priv);
+static void *wlan_host_devid;
+
+int omap_zoom_wlan_register_embedded_control(void *dev_id,
+ void (*set_virtual_cd)(void *dev_id, int card_present),
+ void (*set_data)(void *dev_id, void *priv))
+{
+ if (wlan_host_devid || wlan_set_virtual_cd || wlan_set_data)
+ return -EBUSY;
+
+ wlan_set_virtual_cd = set_virtual_cd;
+ wlan_set_data = set_data;
+ wlan_host_devid = dev_id;
+
+ return 0;
+}
+
+int omap_zoom_wlan_get_virtual_cd(void)
+{
+ return omap_zoom_wlan_cd;
+}
+
+static void omap_zoom_wlan_set_embedded_data(void *priv)
+{
+ if (wlan_set_data)
+ wlan_set_data(wlan_host_devid, priv);
+ else
+ pr_err(%s: host controller not registered yet\n, __func__);
+}
+
+static void omap_zoom_wlan_set_carddetect(bool card_present)
+{
+ omap_zoom_wlan_cd = card_present ? 1 : 0;
+
+ pr_info(%s: %d\n, __func__, omap_zoom_wlan_cd);
+
+ if (wlan_set_virtual_cd)
+ wlan_set_virtual_cd(wlan_host_devid, omap_zoom_wlan_cd);
+ else
+ pr_err(%s: host controller not registered yet\n, __func__);
+}
+
+static void omap_zoom_wlan_power(bool enable)
+{
+ int val = enable ? 1 : 0;
+
+ pr_info(%s: set power %d\n, __func__, val);
+
+ gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
+}
+
+struct wl12xx_platform_data omap_zoom_wlan_control = {
+ .set_power = omap_zoom_wlan_power,
+ .set_carddetect = omap_zoom_wlan_set_carddetect,
+ .set_embedded_data = omap_zoom_wlan_set_embedded_data,
+ /* ZOOM ref clock is 26 MHz */
+ .board_ref_clock = 1,
+ .irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+};
+
+static struct platform_device omap_zoom_wlan_device = {
+ .name = wl1271_sdio,
+ .id = 1,
+ .dev = {
+ .platform_data = omap_zoom_wlan_control,
+ },
+};
+
+int __init omap_zoom_wlan_init(void)
+{
+ int ret;
+
+ ret = gpio_request(OMAP_ZOOM_WLAN_PMENA_GPIO, wlan_power);
+ if (ret 0) {
+ pr_err(%s: power gpio request failed: %d\n, __func__, ret);
+ return ret;
+ }
+
+ gpio_direction_output(OMAP_ZOOM_WLAN_PMENA_GPIO, 0);
+
+ ret = gpio_request(OMAP_ZOOM_WLAN_IRQ_GPIO, wlan_irq);
+ if (ret 0) {
+ pr_err(%s: gpio request failed: %d\n, __func__, ret);
+ return ret;
+ }
+ gpio_direction_input(OMAP_ZOOM_WLAN_IRQ_GPIO);
+
+ ret = platform_device_register(omap_zoom_wlan_device);
+
+ return ret;
+}
+
+#else
RE: [PATCH v5 1/3] omap3 gpmc: functionality enhancement
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, July 07, 2010 6:32 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; m...@compulab.co.il Subject: Re: [PATCH v5 1/3] omap3 gpmc: functionality enhancement * Ghorai, Sukumar s-gho...@ti.com [100707 15:26]: From: Tony Lindgren [mailto:t...@atomide.com] You should just replace this function with simple functions like we already have in gpmc.c rather than trying to pack everything into one function. Just add various gpmc_xxx_get/set functions rather than pass int *rval. [Ghorai] So I was having the same query very 1st time. So we need to implement 15 separate functions to do the same as you suggested. And in my approach it's very easy to enhance the functionally in future, say to add new set/get. E.g. we need the similar cleanup for OneNAND code too. So, would you please confirm once again with one is the best and should follow? In general, we should have separate read and write functions. Maybe you can group them a little bit? Some of them need the chip select, and some of them are generic. Then some of them are NAND specific. [Ghorai] ok. And let me re-work this for next version. Regards, Tony -- 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 11/15] wireless: wl1271: introduce platform device support
On Wed, 7 Jul 2010, Adrian Hunter wrote: Nicolas Pitre wrote: On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call -enable() / -disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host-bus_ops-power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card. This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using. The power control decision does come from the top via mmc_claim_host / mmc_release_host. NO!!! THIS IS NOT ABOUT POWER! To the risk of repeating myself, mmc_claim_host and mmc_release_host are about getting exclusive access to the host controller. This should not have any relationship with power. If anything, you might infer some idleness of the host through that, but only to save power at the host controller level, but not at the card level. I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down. The omap_hsmmc driver does not tell the core to shut down the upper layers. What is this call to mmc_power_save_host() and mmc_power_restore_host() then? Instead the core tells the omap_hsmmc driver that it is disabled i.e. not currently being used so it can start taking steps to save power. That's not how I see things implemented right now. That is sensible because not even the upper layers know when the next activity will be. I don't agree with you. The upper layer, even if it cannot predict exactly when the next activity will occur, still has a hell of a better visibility on what is going on. In the context of an MMC/SD card, the upper layer knows about the block subsystem and it can look for dirty blocks that might be flushed in a near future. In the context of a SDIO card, it is the SDIO function driver that knows when it is important to preserve power to the card and when it is not. All the host controller driver must do is to simply and dumbly process requests from the core MMC code, including power control requests. Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie with the bus drivers? Absolutely! And in the SDIO case that should lie with each function drivers. Please let's stop this omap_hsmmc madness. You are dealing with a trivial case - turn off the power when not in use. And apparently this cannot be implemented sanely on OMAP without faking a card removal. We have 3 power saving actions: enable DPS, put the card to sleep, and finally power it off. Each increases the latency to start up again and so must be staggered. With DPS-enabled the host controller can be powered off at any time. In that case the controller registers must be restored. You could implement the first one based on some idle period. The core code probably doesn't need to know as this should be transparent to the upper layer. But the other two definitely should be handled by the core code. There are numerous entry points to the driver. Checking whether to restore registers at every entry point is error prone and messy. Please give me something else than this lame excuse. There is effectively only _one_ main entry point, namely the request method of the mmc_host_ops structure. You might need to poke at the hardware when the set_ios or the enable_sdio_irq methods are called, and if the controller is latent then you'd only have to update the register cache. This is certainly not what I would call numerous. Instead we require that the core tells the driver when to enable and disable. No you don't. You are abusing the mmc_claim_host interface with power management issues. Those power issues are then guessed in the host controller driver, and then it eventually calls back into the core to tell the upper layer to shut off. What I'm telling you is that: 1) If you want to save power after some idle period you don't need host-ops-enable and host-ops-disable at all. Simply keep a timer alive in your host driver and reset it when a new request comes in. The code for mmc_host_enable() looks rather redundant, and fishy to me with its flag to prevent recursion, so this all could be removed. 2) Putting the card to sleep and/or removing power to it must be completely managed by the core code and certainly not from the host controller driver. The fact that mmc_power_save_host() is currently called from a host
