Re: [PATCH 7/8] OMAP4: clock: Add CPU local timer clock node.
On Fri, Dec 9, 2011 at 4:32 AM, Turquette, Mike mturque...@ti.com wrote:
On Fri, Sep 30, 2011 at 2:15 AM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Fri, Sep 30, 2011 at 3:00 AM, Linus Walleij linus.wall...@linaro.org
wrote:
2011/9/8 Santosh Shilimkar santosh.shilim...@ti.com:
Local timer clock is sourced from the CPU clock and hence changes
along with CPU clock. These per CPU local timers are used as
clock-events, so they need to be reconfigured on CPU frequency
change as part of CPUfreq governor.
This requires patch 6956/2 right?
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6956/2
Can I add your Tested-by: to the patch as well?
Sure.
Santosh,
I've taken in Linus' patch as well as this patch while testing clk
notifiers (part of common clk framework code).
Linus' patch matches the clk based on dev_id, but the clkdev entry in
your patch populated dev_id with NULL and con_id with smp_twd so
things never worked correctly. Below changed fixed it for me:
You are right.
When I picked up the patch while changing the
OMAP44XX stuff to OMAP4430, looks like I miss-placed it.
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index ae8c292..0f8cf68 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -4114,7 +4114,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, l4_div_ck,
l4_div_ck_hw.clk, CK_443X),
CLK(NULL, lp_clk_div_ck,
lp_clk_div_ck_hw.clk, CK_443X),
CLK(NULL, l4_wkup_clk_mux_ck,
l4_wkup_clk_mux_ck_hw.clk, CK_443X),
- CLK(NULL, smp_twd,
mpu_periphclk_hw.clk, CK_443X),
+ CLK(smp_twd, NULL, mpu_periphclk_hw.clk,
CK_443X),
CLK(NULL, ocp_abe_iclk,
ocp_abe_iclk_hw.clk, CK_443X),
CLK(NULL, per_abe_24m_fclk,
per_abe_24m_fclk_hw.clk, CK_443X),
CLK(NULL, per_abe_nc_fclk,
per_abe_nc_fclk_hw.clk, CK_443X),
A better change might be for the code in smp_twd.c to match on con_id
but I'll let you guys sort that out.
I guess we can stick to what Linus and others have followed.
Will post an updated patch. Thanks for catch.
Regards
Santosh
--
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: Commit 09d28d2c19 introduces set-after-free in arch/arm/mach-omap2/mcbsp.c
On 12/11/2011 08:08 AM, NeilBrown wrote: Should these settings just be moved up before the call to omap_device_build_ss?? Doing that removes [0.196014] Slab corruption: size-32 start=ded3edc0, len=32 warning. Good catch! Yes, they must be set before omap_device_build_ss and definitely before kfree. I just wonder how did I managed to put them after both. Perhaps my own rebasing error or just plain stupidity... I'll send a patch soon. -- Jarkko -- 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 09/10] input: serio: ams-delta: Toggle keyboard power over GPIO
On Sun, Dec 11, 2011 at 09:12:07PM +0100, Janusz Krzysztofik wrote:
Don't use Amstrad Delta custom I/O functions once GPIO interface is
available for the underlying hardware.
Depends on patch 8/10 omapfb: lcd_ams_delta: Drive control lines over
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Dmitry Torokhov d...@mail.ru
---
arch/arm/mach-omap1/board-ams-delta.c |5 --
arch/arm/plat-omap/include/plat/board-ams-delta.h |2 -
drivers/input/serio/ams_delta_serio.c | 45 +++-
3 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index b7422e3..587118c 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -232,11 +232,6 @@ static struct gpio _latch_gpios[] __initconst = {
.label = dockit2,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = keybrd_pwr,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
.flags = GPIOF_OUT_INIT_LOW,
.label = keybrd_dataout,
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 1d0706e..004c827 100644
--- a/arch/arm/plat-omap/include/plat/board-ams-delta.h
+++ b/arch/arm/plat-omap/include/plat/board-ams-delta.h
@@ -28,8 +28,6 @@
#if defined (CONFIG_MACH_AMS_DELTA)
-#define AMD_DELTA_LATCH2_KEYBRD_PWR 0x0100
-#define AMD_DELTA_LATCH2_KEYBRD_DATA 0x0200
#define AMD_DELTA_LATCH2_SCARD_RSTIN 0x0400
#define AMD_DELTA_LATCH2_SCARD_CMDVCC0x0800
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index d4d08bd..1499c7d 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -92,8 +92,7 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, void
*dev_id)
static int ams_delta_serio_open(struct serio *serio)
{
/* enable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
- AMD_DELTA_LATCH2_KEYBRD_PWR);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
return 0;
}
@@ -101,9 +100,26 @@ static int ams_delta_serio_open(struct serio *serio)
static void ams_delta_serio_close(struct serio *serio)
{
/* disable keyboard */
- ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
+ gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
}
+static struct gpio _gpios[] __initconst_or_module = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-data,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
+ .flags = GPIOF_DIR_IN,
+ .label = serio-clock,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = serio-power,
+ },
+};
static int __init ams_delta_serio_init(void)
{
int err;
@@ -123,19 +139,11 @@ static int __init ams_delta_serio_init(void)
strlcpy(ams_delta_serio-phys, GPIO/serio0,
sizeof(ams_delta_serio-phys));
- err = gpio_request(AMS_DELTA_GPIO_PIN_KEYBRD_DATA, serio-data);
+ err = gpio_request_array(_gpios, ARRAY_SIZE(_gpios));
if (err) {
- pr_err(ams_delta_serio: Couldn't request gpio pin for data\n);
+ pr_err(ams_delta_serio: Couldn't request gpio pins\n);
goto serio;
}
- gpio_direction_input(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
-
- err = gpio_request(AMS_DELTA_GPIO_PIN_KEYBRD_CLK, serio-clock);
- if (err) {
- pr_err(ams_delta_serio: couldn't request gpio pin for
clock\n);
- goto gpio_data;
- }
- gpio_direction_input(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
err = request_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
ams_delta_serio_interrupt, IRQ_TYPE_EDGE_RISING,
@@ -143,7 +151,7 @@ static int __init ams_delta_serio_init(void)
if (err 0) {
pr_err(ams_delta_serio: couldn't request gpio interrupt %d\n,
gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK));
- goto gpio_clk;
+ goto gpio;
}
/*
* Since GPIO register handling for keyboard clock pin is performed
@@ -157,10 +165,8 @@ static int __init ams_delta_serio_init(void)
dev_info(ams_delta_serio-dev, %s\n, ams_delta_serio-name);
return 0;
-gpio_clk:
- gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
-gpio_data:
- gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
+gpio:
+ gpio_free_array(_gpios, ARRAY_SIZE(_gpios));
serio:
[PATCH] ARM: OMAP: mcbsp: Fix possible memory corruption
Commits 09d28d (ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src)
and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions)
incorrectly set two struct omap_mcbsp_platform_data fields after
omap_device_build_ss and kfree calls.
Fix this by moving these pdata assignments before those calls.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Reported-by: ne...@suse.de
---
For 3.2, 3.1 is ok.
---
arch/arm/mach-omap2/mcbsp.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 292eee3..28fcb27 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -145,6 +145,9 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
pdata-reg_size = 4;
pdata-has_ccr = true;
}
+ pdata-set_clk_src = omap2_mcbsp_set_clk_src;
+ if (id == 1)
+ pdata-mux_signal = omap2_mcbsp1_mux_rx_clk;
if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
if (id == 2)
@@ -174,9 +177,6 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
name, oh-name);
return PTR_ERR(pdev);
}
- pdata-set_clk_src = omap2_mcbsp_set_clk_src;
- if (id == 1)
- pdata-mux_signal = omap2_mcbsp1_mux_rx_clk;
omap_mcbsp_count++;
return 0;
}
--
1.7.7.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
[PATCH] ARM: OMAP: McSPI: Remove unused flag from struct omap2_mcspi_device_config
Flag single_channel in struct omap2_mcspi_device_config is not used
by drivers/spi/spi-omap2-mcspi.c so we may remove it from include/plat/mcspi.h
and affected board files.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap2/board-cm-t35.c |1 -
arch/arm/mach-omap2/board-n8x0.c |1 -
arch/arm/mach-omap2/board-rx51-peripherals.c |3 ---
arch/arm/mach-omap2/board-zoom-display.c |1 -
arch/arm/mach-omap2/common-board-devices.c |1 -
arch/arm/plat-omap/include/plat/mcspi.h |3 ---
6 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index b38cd7b..4cc2f04 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -280,7 +280,6 @@ static struct omap_dss_board_info cm_t35_dss_data = {
static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
.turbo_mode = 0,
- .single_channel = 1,/* 0: slave, 1: master */
};
static struct tdo24m_platform_data tdo24m_config = {
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 05107d8..74065e6 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -140,7 +140,6 @@ static void __init n8x0_usb_init(void) {}
static struct omap2_mcspi_device_config p54spi_mcspi_config = {
.turbo_mode = 0,
- .single_channel = 1,
};
static struct spi_board_info n800_spi_board_info[] __initdata = {
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e9eff00..c01c175 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -138,17 +138,14 @@ static struct lp5523_platform_data
rx51_lp5523_platform_data = {
static struct omap2_mcspi_device_config wl1251_mcspi_config = {
.turbo_mode = 0,
- .single_channel = 1,
};
static struct omap2_mcspi_device_config mipid_mcspi_config = {
.turbo_mode = 0,
- .single_channel = 1,
};
static struct omap2_mcspi_device_config tsc2005_mcspi_config = {
.turbo_mode = 0,
- .single_channel = 1,
};
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
index d4683ba..2818290 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -117,7 +117,6 @@ static struct omap_dss_board_info zoom_dss_data = {
static struct omap2_mcspi_device_config dss_lcd_mcspi_config = {
.turbo_mode = 1,
- .single_channel = 1, /* 0: slave, 1: master */
};
static struct spi_board_info nec_8048_spi_board_info[] __initdata = {
diff --git a/arch/arm/mach-omap2/common-board-devices.c
b/arch/arm/mach-omap2/common-board-devices.c
index bcb0c58..2d1d775 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -33,7 +33,6 @@
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
static struct omap2_mcspi_device_config ads7846_mcspi_config = {
.turbo_mode = 0,
- .single_channel = 1,/* 0: slave, 1: master */
};
static struct ads7846_platform_data ads7846_config = {
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 3d51b18..a357eb2 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -18,9 +18,6 @@ struct omap2_mcspi_dev_attr {
struct omap2_mcspi_device_config {
unsigned turbo_mode:1;
-
- /* Do we want one channel enabled at the same time? */
- unsigned single_channel:1;
};
#endif
--
1.7.7.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: [PATCHv8 2/5] omap3: voltage: fix channel configuration
On Fri, 2011-12-09 at 16:21 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
OMAP3 uses the default settings for VDD1 channel, otherwise the settings
will
overlap with VDD2 and attempting to modify VDD1 voltage will actually change
VDD2 voltage.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc3xxx_data.c |1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/vc3xxx_data.c
b/arch/arm/mach-omap2/vc3xxx_data.c
index cfe348e..0136ad5 100644
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -46,6 +46,7 @@ static struct omap_vc_common omap3_vc_common = {
};
struct omap_vc_channel omap3_vc_mpu = {
+ .flags = OMAP_VC_CHANNEL_DEFAULT,
.common = omap3_vc_common,
.smps_sa_reg = OMAP3_PRM_VC_SMPS_SA_OFFSET,
.smps_volra_reg = OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET,
Looking more at the flow diagram you mentioned in the OMAP3 TRM, I don't
think this is right for OMAP3.
Setting the USE_DEFAULTS flags means that VDD1 will only ever be able to
use [slave address | voltage reg | command reg] zero. While this is
quite likely in most scenarios, the HW doesn't limit this like it does
on OMAP4.
On OMAP3, it's very possible to configure VDD1 to use
[slave address | voltage reg | command reg] one if you want (even though
I'm not sure why you would.)
In any case, my point is that setting the USE_DEFAULTS flag forces an
OMAP4 restriction onto OMAP3 which the hardware doesn't have.
Well, the voltage control does not work at all if this is not done. I am
not sure what is the root cause for this, as I don't have currently
oscilloscope available so that I could take a look at the bus traffic.
The voltage rail behavior is incorrect unless this change is in, this is
easily seen by measuring the voltage levels and trying to change the
voltages by sw.
-Tero
--
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: [PATCHv4 00/15] voltdm cleanup + auto-ret / auto-off support
On Fri, 2011-12-09 at 12:23 -0800, Kevin Hilman wrote: Hi Tero, Tero Kristo t-kri...@ti.com writes: Changes compared to previous version: - merged most of the voltagedomain cleanup fixes to patch 2 - moved pmic latencies to omap_voltdm_pmic struct - renamed omap_lp_params to omap2_oscillator as it only contains osc info now - major changes to usecount support (patch 11+, needed for auto-ret) * added usecounts to voltagedomain / powerdomain * fixed usecount tracking so that the numbers are sane now * changed behavior of some usecounting sources that they do not update the counts (autoidle support) - added auto-ret / auto-off support, based on fixed usecounting * smartreflex disabled / enabled * auto-ret / auto-off enabled based on target state - some other minor tweaks I have probably forgotten to mention This series is looking really good. Thanks! One thing I'd like to see is a bit more comments. Particularily, the new functions in the VC core need kerneldoc comments and verbose descriptions. The differences in timing setups between retention and off are not obvious when reading the code (and are easily forgotten). They also equire a bit of TRM (re)reading to understand what's going on. Some summary comments in the code, along with TRM references would be most helpful so when coming back to this code in a few months or more, we can easily remember what's going on (or at least where to look.) Thanks. Okay, I'll try to figure out more comments on next rev. This has never been too strong point in the code I write I guess. :) Tested on omap3 beagle: - voltages for vdd1 and vdd2 change when entering idle - both suspend and dynamic idle tested - tested that voltages reach target levels for both ret / off Tested on omap4 blaze with custom kernel - this requires a few additional patches missing from this set as omap4 PM support is still not merged MPUSS support is now queued (in Tony's tree), but CORE PM is still missing. I can take a look at this part also, but CORE PM is needed for this set for testing purposes I believe, otherwise the auto-ret part does nothing and is rather impossible to test (not sure if mpu part scales without CORE PM, it might actually.) - will post missing patches once possible from upstream point of view - voltages for vdd1 and vdd3 change when entering idle Applies on top of Kevin's for_3.2/voltage-cleanup branch. You can use mainline now as that branch is merged. Ah okay, good to know. Also, please Cc linux-arm-kernel on future versions of this series. Can do. -Tero -- 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: [PATCHv4 01/15] OMAP3+: PM: VP: use uV for max and min voltage limits
On Fri, 2011-12-09 at 10:07 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: From: Nishanth Menon n...@ti.com Every PMIC has it's own eccentricities, For example, one of the PMIC has MSB set to 1 for a specific function - voltage enable! using an hardcoded value specific for TWL when copied over to such an implementation causes the system to crash as the MSB bit was 0 and the voltage got disabled!. Instead we use actual values and depend on the convertion routines to abstract out the eccentricities of each PMIC. With this, we can now move the voltages to a common location in voltage.h as they are no longer dependent on PMICs and expect the PMIC's conversion routines to set a cap if the voltage is out of reach for the PMIC. Nice. Reported-by: Jon Hunter jon-hun...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Vishwanath BS vishwanath...@ti.com Also needs your sign-off, since you're on the delivery path now. Oh sorry about that, I'll add it. -Tero -- 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: [PATCHv4 05/15] omap: add support for oscillator setup
On Fri, 2011-12-09 at 10:27 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: This contains startup and shutdown times for the oscillator. By default use MAX_INT. nit: code uses ULONG_MAX Oops, will fix the comment. Oscillator setup is used for calculating and setting up latencies for sleep modes that disable oscillator. Signed-off-by: Tero Kristo t-kri...@ti.com Otherwise, looks fine. Kevin -- 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: [PATCHv4 10/15] omap: beagle: set oscillator startup time to 10ms for rev c4
On Fri, 2011-12-09 at 11:11 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Based on the oscillator datasheet for this device. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/board-omap3beagle.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index a7c3d60..5e3f575 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -516,6 +516,9 @@ static void __init beagle_opp_init(void) opp_disable(mpu_dev, 72000); opp_disable(iva_dev, 52000); } + + /* Setup oscillator startup time to 10ms */ + omap_pm_setup_oscillator(1, 0); } ...but shutdown time is probably not zero. :) This should probably be -1, or ULONG_MAX. Yes, I see that tshut isn't even used on OMAP3, so it doesn't matter, but it does help readability IMO. Exactly the reason it was set as zero... I'll think of something for the next rev for this. Maybe use -1 as you suggested (and add a comment), it is not going to break anything. -Tero -- 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: [PATCHv4 11/15] omap3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
On Fri, 2011-12-09 at 11:37 -0800, Kevin Hilman wrote:
+Paul
Tero Kristo t-kri...@ti.com writes:
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain.
Excellent!
This dramatically improves the usefulness of debugfs/pm_debug/count.
Adding the voltage domains to that debugfs would help even more.
Also, the changelog should be a bit more verbose about the new clk-autoidle
field, it's usage, and how it affects usecounting.
Okay, will try to add some more beef here.
Speaking of debugfs: not a requirement for this series, but another
nice to have (which you can do while waiting for the slow maintainers
to review :) would be for this debugfs to show the clkdomains under the
powerdomains they are in, and the powerdomains under the voltage domains
(instead of the current list of pwrdms followed by clkdms.) Maybe using
voltdm_for_each_pwrdm() + pwrdm_for_each_clkdm() might help there.
Yea, I have used something close to this myself for testing purposes, I
can maybe add something for this in next version.
This patch also adds support for usecount tracking on powerdomain and
voltagedomain levels.
The clock/clkdm/pwrdm changes should probably be split separate patch
for review/merge by Paul. Then the voltdm changes can included in this
series. Although, with Paul's ack on the clock/clkdm/powerdomain
changes, I'll be happy to queue this as well.
Okay, will wait for Paul's comment on this.
[...]
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index df4b968..f18dd5f 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -254,6 +254,7 @@ struct clk {
void(*init)(struct clk *);
u8 enable_bit;
s8 usecount;
+ u8 autoidle;
should be bool, and assignments using true | false.
Yea can change that one.
-Tero
--
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 v1 6/7] media: video: introduce face detection driver module
Hi, On Mon, Dec 12, 2011 at 1:43 AM, Sylwester Nawrocki snj...@gmail.com For OMAP4 FD, it is not needed to include FD into MC framework since a intermediate buffer is always required. If your HW doesn't belong to this case, what is the output of your HW FD in the link? Also sounds FD results may not be needed at all for use space application in the case. The result data is similar to OMAP4 one, plus a few other attributes. User buffers may be filled by other than FD device driver. OK. Could you provide some practical use cases about these? As above, and any device with a camera that controls something and makes decision according to presence of human face in his view. Sounds a reasonable case, :-) If FD result is associated with a frame, how can user space get the frame seq if no v4l2 buffer is involved? Without a frame sequence, it is a bit difficult to retrieve FD results from user space. If you pass image data in memory buffers from user space, yes, it could be impossible. It is easy to get the frame sequence from v4l2_buffer for the case too, :-) Not really, still v4l2_buffer may be used by other (sub)driver within same video processing pipeline. OK. A related question: how can we make one application to support the two kinds of devices(input from user space data as OMAP4, input from SoC bus as Samsung) at the same time? Maybe some capability info is to be exported to user space? or other suggestions? And will your Samsung FD HW support to detect faces from memory? or just only detect from SoC bus? It will be included in the FD result... or in a dedicated v4l2 event data structure. More important, at the end of the day, we'll be getting buffers with image data at some stage of a video pipeline, which would contain same frame identifier (I think we can ignore v4l2_buffer.field for FD purpose). OK, I will associate FD result with frame identifier, and not invent a dedicated v4l2 event for query frame seq now until a specific requirement for it is proposed. I will convert/integrate recent discussions into patches of v2 for further review, and sub device support will be provided. But before starting to do it, I am still not clear how to integrate FD into MC framework. I understand FD sub device is only a media entity, so how can FD sub device find the media device(struct media_device)? or just needn't to care about it now? thanks, -- Ming Lei -- 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: [PATCHv4 12/15] vc: omap3: auto_ret / auto_off support
On Fri, 2011-12-09 at 12:13 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Voltage code will now enable / disable auto_ret / auto_off dynamically
according to the voltagedomain usecounts. This is accomplished via
the usage of the voltdm callback functions for sleep / wakeup.
Signed-off-by: Tero Kristo t-kri...@ti.com
[...]
-static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
+static void omap3_set_core_off_timings(struct voltagedomain *voltdm)
{
+ u32 tstart, tshut;
nit: insert blank line here
Okay.
+ omap_pm_get_oscillator(tstart, tshut);
+ omap3_set_clksetup(tstart, voltdm);
omap3_set_off_timings(voltdm);
}
+static void omap3_vc_channel_sleep(struct voltagedomain *voltdm)
+{
+ /* Set off timings if entering off */
+ if (voltdm-target_state == PWRDM_POWER_OFF)
+ omap3_set_off_timings(voltdm);
+ else
+ omap3_set_i2c_timings(voltdm, 0);
Comment probably applies more to patch 2 since that's where it was
introduced, but this is where I got confused, so mentioning it here:
Calling this 'set_i2c_timings' is a bit confusing IMO because reading
the code there is a choice between 'i2c' timings and 'off' timings.
Maybe just calling these 'ret' and 'off' timings will be better for
readability.
Well, actually, you can use i2c timings when scaling voltage to off
level also. You have following options for voltage scaling on omap3:
- scale to ret level (0.975V) using i2c command
- scale to off level (0.6V) using i2c command
- switch to off (0V) using pmic scripts
I was kind of trying to reflect this here, even though the pmic script
support is missing.
+}
+
+static void omap3_vc_channel_wakeup(struct voltagedomain *voltdm)
+{
+}
nit: empty function not needed since code checks for non-NULL function
pointer.
Yea can drop that away, I left it there because I thought it might need
some beef in it at some point.
+static void omap3_vc_core_sleep(struct voltagedomain *voltdm)
+{
+ u8 mode;
+
+ switch (voltdm-target_state) {
+ case PWRDM_POWER_OFF:
+ mode = OMAP3430_AUTO_OFF_MASK;
+ break;
+ case PWRDM_POWER_RET:
+ mode = OMAP3430_AUTO_RET_MASK;
+ break;
+ default:
+ mode = OMAP3430_AUTO_SLEEP_MASK;
+ break;
+ }
+
+ if (mode OMAP3430_AUTO_OFF_MASK)
AND vs. == ?
Oh yea, some strange logic here for sure, I'll change that to ==. :)
speaking of which, this function probably needs a comment mentioning
that these bits are all mutually exclusive (with a TRM reference.)
Can add that too.
-Tero
--
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: [PATCHv10 06/14] omap3: pm: use prcm chain handler
On Fri, 2011-12-09 at 15:23 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to serve IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.
Also, elaborate that this means this core event code should no longer
clear the IO events since they are now handled by their own handlers.
Okay.
Signed-off-by: Tero Kristo t-kri...@ti.com
[...]
@@ -880,12 +848,20 @@ static int __init omap3_pm_init(void)
* supervised mode for powerdomains */
prcm_setup_regs();
- ret = request_irq(INT_34XX_PRCM_MPU_IRQ,
- (irq_handler_t)prcm_interrupt_handler,
- IRQF_DISABLED, prcm, NULL);
+ ret = request_irq(omap_prcm_event_to_irq(wkup),
+ _prcm_int_handle_wakeup, 0, pm_wkup, NULL);
+
+ if (ret) {
+ printk(KERN_ERR Failed to request pm_wkup irq\n);
+ goto err1;
+ }
+
+ /* IO interrupt is shared with mux code */
+ ret = request_irq(omap_prcm_event_to_irq(io),
+ _prcm_int_handle_io, IRQF_SHARED, pm_io, omap3_pm_init);
+
Why does the hwmod_io use IRQF_NO_SUSPEND and this one doesn't?
Hmm, good question. Must have been a remain from some old tweak, I'll
take a look at what the flags should actually be.
-Tero
--
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: [PATCHv10 00/14] PRCM chain handler
On Fri, 2011-12-09 at 14:36 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Once more a new version, it was decided that the PRM driver will be dropped for now, and we will have the chain handler support under mach-omap2 directory. This will most likely be addressed in future. Just to clarify for others: We decided that since the PRM driver is going to take some more time to sort out, we would at least get the chained IRQ support in now so we can unblock drivers that need it for wakeup support (like UART, USB host, etc.) Other than that, the code is pretty close to what was in version 9, just location has changed from /drivers/mfd to /arch/arm/mach-omap2. Tested with omap3 beagleboard, with dynamic idle and suspend, both retention and off. omap4 should not be an issue seeing the code is close to what was in version 9. TEMP patches can be ignored, they are provided only for testing purposes, and shall be replaced by uart runtime support. Can you repost a series without the TEMP patches, and Cc linux-arm-kernel as well. For testing purposes, you can make a branch available with the temp patches included, and mention it in the changelog. Okay, I'll repost once I have fixed this version hopefully. -Tero -- 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: [PATCHv10 04/14] omap: prm: add support for suspend prepare and finish callbacks
On Fri, 2011-12-09 at 15:04 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: These are needed because runtime PM is disabled during suspend, and it is bad if we get interrupts from the PRCM chain handler during it. This patch masks all the PRCM interrupt events, but does not ack them, if an interrupt is received during suspend. Once suspend-finish is called, all the masked events will be re-enabled, which causes immediate PRCM interrupt and handles the postponed event. The suspend prepare and complete callbacks will be called from pm34xx.c / pm44xx.c files in the following patches. You might just update this changelog to clarify why you're using the the driver-specific prepare complete terminology whereas this code is using begin/finish hooks as part of platform_pm_ops. IOW, state that this will soon be becoming a real driver, so you're using the driver terminology. Also note that subject uses prepare finish instead of prepare complete. Yea this changelog is outdated, will fix. -Tero -- 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: [PATCHv10 05/14] OMAP2+: mux: add support for PAD wakeup interrupts
On Fri, 2011-12-09 at 15:13 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: OMAP mux now provides a service routine to parse pending wakeup events and to call registered ISR whenever active wakeups are detected. Good. This routine is called directly from PRCM interrupt handler. I think this comment is out of date with the code, since you're now using a shared IRQ and the interrupt is directly called from the IRQ core. I'd update the changelog here just commenting on what this IRQ is shared with, and how the interrupts are shared. Also, a question on optimization. For every IO wakeup, this will go through the list of *all* enabled hwmods. This could be pretty expensive with lots of wakeups. Maybe we should have another flag for hwmods that have wakeups enabled so walking the list of potential wakeup-capable hwmods will be as fast as possible. Optimization of this code is sure possible, and probably even desirable. In some of the earlier sets I had a separate list for the pad scan, but it was dropped out due to some comments. It would be possible to add either a separate list for these within omap_hwmod / mux, or either a flag which checks for enabled io wakeups. -Tero -- 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] ARM: OMAP: mcbsp: Fix possible memory corruption
On 12/12/11 10:38, Jarkko Nikula wrote:
Commits 09d28d (ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src)
and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions)
incorrectly set two struct omap_mcbsp_platform_data fields after
omap_device_build_ss and kfree calls.
Fix this by moving these pdata assignments before those calls.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
Reported-by: ne...@suse.de
Perhaps, should be:
Reported-by: NeilBrown ne...@suse.de
and
Cc: sta...@vger.kernel.org[3.1]
as for below.
---
For 3.2, 3.1 is ok.
---
arch/arm/mach-omap2/mcbsp.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 292eee3..28fcb27 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -145,6 +145,9 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
pdata-reg_size = 4;
pdata-has_ccr = true;
}
+ pdata-set_clk_src = omap2_mcbsp_set_clk_src;
+ if (id == 1)
+ pdata-mux_signal = omap2_mcbsp1_mux_rx_clk;
if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
if (id == 2)
@@ -174,9 +177,6 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
name, oh-name);
return PTR_ERR(pdev);
}
- pdata-set_clk_src = omap2_mcbsp_set_clk_src;
- if (id == 1)
- pdata-mux_signal = omap2_mcbsp1_mux_rx_clk;
omap_mcbsp_count++;
return 0;
}
--
Regards,
Igor.
--
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: Should I worry about omap-mcbsp.2: alias fck already exists or is it expected?
+ Paul and Peter
Hi Neil,
On 12/12/2011 12:35 AM, NeilBrown wrote:
In 3.2-rc5 (and some earlier kernels) I'm getting the boot-time warning:
[0.186828] omap-mcbsp.2: alias fck already exists
and
[0.188476] omap-mcbsp.3: alias fck already exists
This happens because omap_alloc_device() contains:
for (i = 0; i oh_cnt; i++) {
hwmods[i]-od = od;
_add_hwmod_clocks_clkdev(od, hwmods[i]);
}
so if oh_cnt is ever 1 (which is is for mcbsp.2 and .3 in
omap_hwmod_3xxx_data.c as they both declare a '.devattr'), then
_add_hwmod_clocks_clkdev will be called twice with the one 'od', and both
calls will try to add an alias 'fsck' to that same device, and the second
will always give a warning.
Is this actually a bug,
It is indeed a bug. The point is that in theory most hwmod should have
an unique device to represent them. But in the case of the Mcbsp2 and 3,
due to the tightly coupled sidetone, and because each one has a
dedicated OCP port, it was decided to have 2 hwmods but only one
omap_device.
I'm wondering now if another device should not be considered, but I'll
let Peter decide for the McBSP driver organization.
or should we silence the warning on second and
subsequent calls to omap_alloc_device()?
We can have only one fck alias per device, so preventing to register
any subsequent fck seems the good approach to me.
The warning was added to detect a potential static version of the clkdev
and thus eliminate it, so we should keep it.
Like this?
Thanks,
NeilBrown
omap: don't try to register the main clock twice.
ARM: OMAP2+: Don't try to register the main clock twice
If omap_device_alloc is given 2 or more struct omap_hwmod it will try to
register the 'main_clk' of each of them with the same alias - fck - against
the same device. This fails.
So to avoid a warning, don't even try.
Signed-off-by: NeilBrownne...@suse.de
Acked-by: Benoit Cousson b-cous...@ti.com
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index e8d9869..11012bd 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -294,6 +294,7 @@ static void _add_clkdev(struct omap_device *od, const char
*clk_alias,
* and main clock
* @od: struct omap_device *od
* @oh: struct omap_hwmod *oh
+ * @sub: this is a subordinate device, so don't try to register fck
*
* For the main clock and every optional clock present per hwmod per
* omap_device, this function adds an entry in the clkdev table of the
@@ -309,11 +310,12 @@ static void _add_clkdev(struct omap_device *od, const
char *clk_alias,
* No return value.
*/
static void _add_hwmod_clocks_clkdev(struct omap_device *od,
-struct omap_hwmod *oh)
+struct omap_hwmod *oh, int sub)
{
int i;
- _add_clkdev(od, fck, oh-main_clk);
+ if (!sub)
+ _add_clkdev(od, fck, oh-main_clk);
for (i = 0; i oh-opt_clks_cnt; i++)
_add_clkdev(od, oh-opt_clks[i].role, oh-opt_clks[i].clk);
@@ -576,7 +578,7 @@ static struct omap_device *omap_device_alloc(struct
platform_device *pdev,
for (i = 0; i oh_cnt; i++) {
hwmods[i]-od = od;
- _add_hwmod_clocks_clkdev(od, hwmods[i]);
+ _add_hwmod_clocks_clkdev(od, hwmods[i], i);
}
return od;
Thanks for the fix.
Regards,
Benoit
--
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 1/2] video: omap: Staticise non-exported symbols
On Fri, 2011-12-09 at 09:37 +0800, Axel Lin wrote: These symbols are not used outside it's driver so no need to make the symbol global. Signed-off-by: Axel Lin axel@gmail.com Thanks, applied to DSS tree. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/3] video: omap: convert drivers/video/omap/* to use module_platform_driver()
On Fri, 2011-12-09 at 09:59 +0800, Axel Lin wrote: This patch converts the drivers in drivers/video/omap/* to use the module_platform_driver() macro which makes the code smaller and a bit simpler. Cc: Jonathan McDowell nood...@earth.li Cc: Cory Maccarrone darkstar6...@gmail.com Cc: Laurent Gonzalez palmte.li...@free.fr Cc: Marek Vasut marek.va...@gmail.com Signed-off-by: Axel Lin axel@gmail.com Thanks, applied to DSS tree. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP3LOGIC: Adding DSS support
Hi,
On Thu, 2011-12-08 at 14:05 +0200, Alex wrote:
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD
and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
arch/arm/mach-omap2/board-omap3logic.c | 151
1 files changed, 151 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 7c0f193..86175fa 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -7,6 +7,9 @@
* Copyright (C) 2010 Logic Product Development, Inc.
* Peter Barada peter.bar...@logicpd.com
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin al...@meprolight.com
+ *
* Modified from Beagle, EVM, and RX51
*
* This program is free software; you can redistribute it and/or modify
@@ -44,6 +47,10 @@
#include plat/gpmc-smsc911x.h
#include plat/gpmc.h
#include plat/sdrc.h
+#include plat/vram.h
+
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
#define OMAP3LOGIC_SMSC911X_CS 1
@@ -58,6 +65,14 @@ static struct regulator_consumer_supply
omap3logic_vmmc1_supply[] = {
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
};
+static struct regulator_consumer_supply omap3logic_vdds_supplies[] = {
+ REGULATOR_SUPPLY(vdds_sdi, omapdss),
+ REGULATOR_SUPPLY(vdds_dsi, omapdss),
+};
+
+static struct regulator_consumer_supply omap3logic_vdac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omapdss_venc);
+
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA)
*/
static struct regulator_init_data omap3logic_vmmc1 = {
.constraints = {
@@ -74,6 +89,34 @@ static struct regulator_init_data omap3logic_vmmc1 = {
.consumer_supplies = omap3logic_vmmc1_supply,
};
+static struct regulator_init_data omap3logic_vpll2 = {
+ .constraints = {
+ .name = VDDS_DSI,
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .always_on = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3logic_vdds_supplies),
+ .consumer_supplies = omap3logic_vdds_supplies,
+};
+
+static struct regulator_init_data omap3logic_vdac = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3logic_vdac_supply,
+};
+
static struct twl4030_gpio_platform_data omap3logic_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
@@ -91,6 +134,8 @@ static struct twl4030_platform_data omap3logic_twldata = {
/* platform_data for children goes here */
.gpio = omap3logic_gpio_data,
.vmmc1 = omap3logic_vmmc1,
+ .vpll2 = omap3logic_vpll2,
+ .vdac = omap3logic_vdac,
};
The regulators are already set up in twl-common.c, so there shouldn't be
need for the code above.
static int __init omap3logic_i2c_init(void)
@@ -182,6 +227,110 @@ static inline void __init board_smsc911x_init(void)
gpmc_smsc911x_init(board_smsc911x_data);
}
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+#define OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO 154
+#define OMAP3_TORPEDO_LCD_ENABLE_GPIO155
+#define OMAP3_TORPEDO_LCD_PWM_GPIO 56
The PWM gpio doesn't seem to be used. Is it needed for something?
+static struct gpio omap3logic_dss_gpios[] __initdata = {
+ {OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, lcd_bl_pwr},
+ {OMAP3_TORPEDO_LCD_PWM_GPIO, GPIOF_OUT_INIT_LOW, lcd bl enable},
+ {OMAP3_TORPEDO_LCD_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, lcd enable},
+};
+
+static int omap3logic_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 1);
+ msleep(20);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 1);
+
+ return 0;
+}
+
+static void omap3logic_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ msleep(20);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+}
Is there a particular reason for msleep(20) in the enable and
Re: [PATCH] ARM: OMAP: mcbsp: Fix possible memory corruption
Hi On 12/12/2011 12:23 PM, Igor Grinberg wrote: On 12/12/11 10:38, Jarkko Nikula wrote: Commits 09d28d (ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src) and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions) incorrectly set two struct omap_mcbsp_platform_data fields after omap_device_build_ss and kfree calls. Fix this by moving these pdata assignments before those calls. Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com Reported-by: ne...@suse.de Perhaps, should be: Reported-by: NeilBrown ne...@suse.de and Cc: sta...@vger.kernel.org [3.1] as for below. --- For 3.2, 3.1 is ok. --- No need to cc stable since the issue is not in stable kernels. -- Jarkko -- 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 08/10] omapfb: lcd_ams_delta: Drive control lines over GPIO
On Sun, 2011-12-11 at 21:12 +0100, Janusz Krzysztofik wrote: Don't use Amstrad Delta custom I/O functions any longer, use GPIO API instead. Depends on patch 5/10 MTD: NAND: ams-delta: Use GPIO instead of custom I/O. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- arch/arm/mach-omap1/board-ams-delta.c | 10 --- arch/arm/plat-omap/include/plat/board-ams-delta.h |2 - drivers/video/omap/lcd_ams_delta.c| 27 +++- 3 files changed, 20 insertions(+), 19 deletions(-) Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH RESEND v2 0/2] PMIC TPS65910 fixes
Hi Mohamed, On Tue, Nov 08, 2011 at 06:53:35PM +0530, Afzal Mohammed wrote: Hi, This series applies over Kyle Manna's v3 patch series, https://lkml.org/lkml/2011/11/3/257, with changes as per comments on his/her 1/6 mfd: TPS65910: Handle non-existent devices Kyle has not updated the patchset, afaik. So your patches don't apply on top of my for-next branch. Please rebase them. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] ARM: OMAP: mcbsp: Fix possible memory corruption
On 12/12/11 13:22, Jarkko Nikula wrote: Hi On 12/12/2011 12:23 PM, Igor Grinberg wrote: On 12/12/11 10:38, Jarkko Nikula wrote: Commits 09d28d (ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src) and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions) incorrectly set two struct omap_mcbsp_platform_data fields after omap_device_build_ss and kfree calls. Fix this by moving these pdata assignments before those calls. Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com Reported-by: ne...@suse.de Perhaps, should be: Reported-by: NeilBrown ne...@suse.de and Cc: sta...@vger.kernel.org [3.1] as for below. --- For 3.2, 3.1 is ok. --- No need to cc stable since the issue is not in stable kernels. Ah, so I've misunderstood what was that about... So it has been introduced in 3.2-rc cycle. Ok. Then now it is the perfect time to fix this ;) -- Regards, Igor. -- 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 v1 6/7] media: video: introduce face detection driver module
Hi Ming, It's maybe late, but I want to suggest one thing about FD API. This OMAP FD block looks detection ability of just face. But, It's possible to occur another device which can detect specific object or patterns. Moreover, this API can expand object recognition area. So, I think it's good to change the API name like v4l2_recog. Actually, I'm preparing similar control class for mainline with m5mols camera sensor driver. The m5mols camera sensor has the function about face detection. But, I has experienced about Robot Recognition, and I remember the image processing chip which can detect spefic pattern. So, I hesitated naming the API(control or ioctl whatever) with face. It can be possible to provide just object or pattern, not face. Even user library on windows, there is famous OpenCV. And this is also support not only face, but also object. The function of OMAP FDIF looks like m5mols ISP's one. please understand I don't have experience about OMAP AP. But, I can tell you it's better to use the name object recognition, not the face detection, for any other device or driver. In a few days, I'll share the CIDs I have thought for m5mols driver. And, I hope to discuss about this with OMAP FDIF. Thank you. Regards, Heungjun Kim -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Ming Lei Sent: Monday, December 12, 2011 6:50 PM To: Sylwester Nawrocki Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; linux-me...@vger.kernel.org Subject: Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module Hi, On Mon, Dec 12, 2011 at 1:43 AM, Sylwester Nawrocki snj...@gmail.com For OMAP4 FD, it is not needed to include FD into MC framework since a intermediate buffer is always required. If your HW doesn't belong to this case, what is the output of your HW FD in the link? Also sounds FD results may not be needed at all for use space application in the case. The result data is similar to OMAP4 one, plus a few other attributes. User buffers may be filled by other than FD device driver. OK. Could you provide some practical use cases about these? As above, and any device with a camera that controls something and makes decision according to presence of human face in his view. Sounds a reasonable case, :-) If FD result is associated with a frame, how can user space get the frame seq if no v4l2 buffer is involved? Without a frame sequence, it is a bit difficult to retrieve FD results from user space. If you pass image data in memory buffers from user space, yes, it could be impossible. It is easy to get the frame sequence from v4l2_buffer for the case too, :-) Not really, still v4l2_buffer may be used by other (sub)driver within same video processing pipeline. OK. A related question: how can we make one application to support the two kinds of devices(input from user space data as OMAP4, input from SoC bus as Samsung) at the same time? Maybe some capability info is to be exported to user space? or other suggestions? And will your Samsung FD HW support to detect faces from memory? or just only detect from SoC bus? It will be included in the FD result... or in a dedicated v4l2 event data structure. More important, at the end of the day, we'll be getting buffers with image data at some stage of a video pipeline, which would contain same frame identifier (I think we can ignore v4l2_buffer.field for FD purpose). OK, I will associate FD result with frame identifier, and not invent a dedicated v4l2 event for query frame seq now until a specific requirement for it is proposed. I will convert/integrate recent discussions into patches of v2 for further review, and sub device support will be provided. But before starting to do it, I am still not clear how to integrate FD into MC framework. I understand FD sub device is only a media entity, so how can FD sub device find the media device(struct media_device)? or just needn't to care about it now? thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media 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] ARM: OMAP3LOGIC: Adding DSS support
From: Tomi Valkeinen [tomi.valkei...@ti.com]
Sent: Monday, December 12, 2011 1:10 PM
To: Alex Gershgorin
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
tim.nord...@logicpd.com; bar...@tkos.co.il
Subject: Re: [PATCH] ARM: OMAP3LOGIC: Adding DSS support
Hi,
On Thu, 2011-12-08 at 14:05 +0200, Alex wrote:
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD
and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
arch/arm/mach-omap2/board-omap3logic.c | 151
1 files changed, 151 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 7c0f193..86175fa 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -7,6 +7,9 @@
* Copyright (C) 2010 Logic Product Development, Inc.
* Peter Barada peter.bar...@logicpd.com
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin al...@meprolight.com
+ *
* Modified from Beagle, EVM, and RX51
*
* This program is free software; you can redistribute it and/or modify
@@ -44,6 +47,10 @@
#include plat/gpmc-smsc911x.h
#include plat/gpmc.h
#include plat/sdrc.h
+#include plat/vram.h
+
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
#define OMAP3LOGIC_SMSC911X_CS 1
@@ -58,6 +65,14 @@ static struct regulator_consumer_supply
omap3logic_vmmc1_supply[] = {
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
};
+static struct regulator_consumer_supply omap3logic_vdds_supplies[] = {
+ REGULATOR_SUPPLY(vdds_sdi, omapdss),
+ REGULATOR_SUPPLY(vdds_dsi, omapdss),
+};
+
+static struct regulator_consumer_supply omap3logic_vdac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omapdss_venc);
+
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA)
*/
static struct regulator_init_data omap3logic_vmmc1 = {
.constraints = {
@@ -74,6 +89,34 @@ static struct regulator_init_data omap3logic_vmmc1 = {
.consumer_supplies = omap3logic_vmmc1_supply,
};
+static struct regulator_init_data omap3logic_vpll2 = {
+ .constraints = {
+ .name = VDDS_DSI,
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .always_on = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3logic_vdds_supplies),
+ .consumer_supplies = omap3logic_vdds_supplies,
+};
+
+static struct regulator_init_data omap3logic_vdac = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3logic_vdac_supply,
+};
+
static struct twl4030_gpio_platform_data omap3logic_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
@@ -91,6 +134,8 @@ static struct twl4030_platform_data omap3logic_twldata = {
/* platform_data for children goes here */
.gpio = omap3logic_gpio_data,
.vmmc1 = omap3logic_vmmc1,
+ .vpll2 = omap3logic_vpll2,
+ .vdac = omap3logic_vdac,
};
The regulators are already set up in twl-common.c, so there shouldn't be
need for the code above.
I will correct it .
static int __init omap3logic_i2c_init(void)
@@ -182,6 +227,110 @@ static inline void __init board_smsc911x_init(void)
gpmc_smsc911x_init(board_smsc911x_data);
}
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+#define OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO 154
+#define OMAP3_TORPEDO_LCD_ENABLE_GPIO155
+#define OMAP3_TORPEDO_LCD_PWM_GPIO 56
The PWM gpio doesn't seem to be used. Is it needed for something?
Excuse me for my neglect, I shall have it set to default in the function
omap3logic_display_init.
+static struct gpio omap3logic_dss_gpios[] __initdata = {
+ {OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, lcd_bl_pwr},
+ {OMAP3_TORPEDO_LCD_PWM_GPIO, GPIOF_OUT_INIT_LOW, lcd bl enable},
+ {OMAP3_TORPEDO_LCD_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, lcd enable},
+};
+
+static int omap3logic_enable_lcd(struct omap_dss_device *dssdev)
+{
+
[PATCH] ARM: OMAP2+: Fix: Don't wait for the idle status if modulemode is not supported
If the module does not have any modulemode, the _disable_module function
will do nothing. There is then no point waiting for a idle status change.
It will remove the following warnings.
[0.331848] omap_hwmod: dmm: _wait_target_disable failed
[0.339935] omap_hwmod: emif_fw: _wait_target_disable failed
[0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed
[0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed
[0.365600] omap_hwmod: l4_abe: _wait_target_disable failed
[0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed
[0.382263] omap_hwmod: l4_per: _wait_target_disable failed
[0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed
[0.399536] omap_hwmod: dma_system: _wait_target_disable failed
[0.408325] omap_hwmod: dss_core: _wait_target_disable failed
[0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed
[0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed
[0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed
[0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed
[0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed
[0.459564] omap_hwmod: dss_venc: _wait_target_disable failed
[0.489471] omap_hwmod: mailbox: _wait_target_disable failed
[0.505920] omap_hwmod: spinlock: _wait_target_disable failed
Note: For such module, the state is managed automatically by HW according
to clock domain transition. It is then not possible to wait for idle even
later in the _idle function since the status will change at clock domain
boundary.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 207a2ff..dc9acac 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -710,16 +710,16 @@ static void _enable_module(struct omap_hwmod *oh)
* @oh: struct omap_hwmod *
*
* Disable the PRCM module mode related to the hwmod @oh.
- * No return value.
+ * Return EINVAL if the modulemode is not supported and 0 in case of success.
*/
-static void _disable_module(struct omap_hwmod *oh)
+int _disable_module(struct omap_hwmod *oh)
{
/* The module mode does not exist prior OMAP4 */
if (cpu_is_omap24xx() || cpu_is_omap34xx())
- return;
+ return -EINVAL;
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
- return;
+ return -EINVAL;
pr_debug(omap_hwmod: %s: _disable_module\n, oh-name);
@@ -727,6 +727,8 @@ static void _disable_module(struct omap_hwmod *oh)
oh-clkdm-cm_inst,
oh-clkdm-clkdm_offs,
oh-prcm.omap4.clkctrl_offs);
+
+ return 0;
}
/**
@@ -1537,11 +1539,20 @@ static int _idle(struct omap_hwmod *oh)
if (oh-class-sysc)
_idle_sysc(oh);
_del_initiator_dep(oh, mpu_oh);
- _disable_module(oh);
- ret = _wait_target_disable(oh);
- if (ret)
- pr_warn(omap_hwmod: %s: _wait_target_disable failed\n,
- oh-name);
+ ret = _disable_module(oh);
+
+ /*
+* If the module does not have any modulemode, the previous
+* function will do nothing. There is then no point waiting
+* for a idle status change.
+*/
+ if (!ret) {
+ ret = _wait_target_disable(oh);
+ if (ret)
+ pr_warn(omap_hwmod: %s: _wait_target_disable failed\n,
+ oh-name);
+ }
+
/*
* The module must be in idle mode before disabling any parents
* clocks. Otherwise, the parent clock might be disabled before
--
1.7.0.4
--
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: [PATCHv8 2/5] omap3: voltage: fix channel configuration
Tero Kristo t-kri...@ti.com writes:
On Fri, 2011-12-09 at 16:21 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
OMAP3 uses the default settings for VDD1 channel, otherwise the settings
will
overlap with VDD2 and attempting to modify VDD1 voltage will actually
change
VDD2 voltage.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc3xxx_data.c |1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/vc3xxx_data.c
b/arch/arm/mach-omap2/vc3xxx_data.c
index cfe348e..0136ad5 100644
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -46,6 +46,7 @@ static struct omap_vc_common omap3_vc_common = {
};
struct omap_vc_channel omap3_vc_mpu = {
+ .flags = OMAP_VC_CHANNEL_DEFAULT,
.common = omap3_vc_common,
.smps_sa_reg = OMAP3_PRM_VC_SMPS_SA_OFFSET,
.smps_volra_reg = OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET,
Looking more at the flow diagram you mentioned in the OMAP3 TRM, I don't
think this is right for OMAP3.
Setting the USE_DEFAULTS flags means that VDD1 will only ever be able to
use [slave address | voltage reg | command reg] zero. While this is
quite likely in most scenarios, the HW doesn't limit this like it does
on OMAP4.
On OMAP3, it's very possible to configure VDD1 to use
[slave address | voltage reg | command reg] one if you want (even though
I'm not sure why you would.)
In any case, my point is that setting the USE_DEFAULTS flag forces an
OMAP4 restriction onto OMAP3 which the hardware doesn't have.
Well, the voltage control does not work at all if this is not done. I am
not sure what is the root cause for this, as I don't have currently
oscilloscope available so that I could take a look at the bus traffic.
The voltage rail behavior is incorrect unless this change is in, this is
easily seen by measuring the voltage levels and trying to change the
voltages by sw.
Yeah, I understand why it's broken now and the question is only whether
to make the same default channel restriction exist for OMAP3 as exists
for OMAP4. For now, I'm OK with this restriction, so this patch is
fine.
Kevin
--
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: [PATCHv4 12/15] vc: omap3: auto_ret / auto_off support
Tero Kristo t-kri...@ti.com writes:
On Fri, 2011-12-09 at 12:13 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Voltage code will now enable / disable auto_ret / auto_off dynamically
according to the voltagedomain usecounts. This is accomplished via
the usage of the voltdm callback functions for sleep / wakeup.
Signed-off-by: Tero Kristo t-kri...@ti.com
[...]
-static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
+static void omap3_set_core_off_timings(struct voltagedomain *voltdm)
{
+ u32 tstart, tshut;
nit: insert blank line here
Okay.
+ omap_pm_get_oscillator(tstart, tshut);
+ omap3_set_clksetup(tstart, voltdm);
omap3_set_off_timings(voltdm);
}
+static void omap3_vc_channel_sleep(struct voltagedomain *voltdm)
+{
+ /* Set off timings if entering off */
+ if (voltdm-target_state == PWRDM_POWER_OFF)
+ omap3_set_off_timings(voltdm);
+ else
+ omap3_set_i2c_timings(voltdm, 0);
Comment probably applies more to patch 2 since that's where it was
introduced, but this is where I got confused, so mentioning it here:
Calling this 'set_i2c_timings' is a bit confusing IMO because reading
the code there is a choice between 'i2c' timings and 'off' timings.
Maybe just calling these 'ret' and 'off' timings will be better for
readability.
Well, actually, you can use i2c timings when scaling voltage to off
level also. You have following options for voltage scaling on omap3:
- scale to ret level (0.975V) using i2c command
- scale to off level (0.6V) using i2c command
- switch to off (0V) using pmic scripts
I was kind of trying to reflect this here, even though the pmic script
support is missing.
OK, makes sense now. Being more vebose in the changelog, or better,
having verbose kernel comments for the functions would help here.
Kevin
--
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: [PATCHv10 05/14] OMAP2+: mux: add support for PAD wakeup interrupts
Tero Kristo t-kri...@ti.com writes: On Fri, 2011-12-09 at 15:13 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: OMAP mux now provides a service routine to parse pending wakeup events and to call registered ISR whenever active wakeups are detected. Good. This routine is called directly from PRCM interrupt handler. I think this comment is out of date with the code, since you're now using a shared IRQ and the interrupt is directly called from the IRQ core. I'd update the changelog here just commenting on what this IRQ is shared with, and how the interrupts are shared. Also, a question on optimization. For every IO wakeup, this will go through the list of *all* enabled hwmods. This could be pretty expensive with lots of wakeups. Maybe we should have another flag for hwmods that have wakeups enabled so walking the list of potential wakeup-capable hwmods will be as fast as possible. Optimization of this code is sure possible, and probably even desirable. In some of the earlier sets I had a separate list for the pad scan, but it was dropped out due to some comments. It would be possible to add either a separate list for these within omap_hwmod / mux, or either a flag which checks for enabled io wakeups. OK, if you prefer, we can optimize in a future patch so we can still target v3.3 for this series. Kevin -- 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] ARM: OMAP3LOGIC: Adding DSS support
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
arch/arm/mach-omap2/board-omap3logic.c | 106
1 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 7c0f193..e030c71 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -7,6 +7,9 @@
* Copyright (C) 2010 Logic Product Development, Inc.
* Peter Barada peter.bar...@logicpd.com
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin al...@meprolight.com
+ *
* Modified from Beagle, EVM, and RX51
*
* This program is free software; you can redistribute it and/or modify
@@ -44,6 +47,10 @@
#include plat/gpmc-smsc911x.h
#include plat/gpmc.h
#include plat/sdrc.h
+#include plat/vram.h
+
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
#define OMAP3LOGIC_SMSC911X_CS 1
@@ -95,6 +102,13 @@ static struct twl4030_platform_data omap3logic_twldata = {
static int __init omap3logic_i2c_init(void)
{
+ omap3_pmic_get_config(omap3logic_twldata, TWL_COMMON_PDATA_USB,
+ TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
+
+ omap3logic_twldata.vdac-constraints.apply_uV = true;
+ omap3logic_twldata.vpll2-constraints.apply_uV = true;
+ omap3logic_twldata.vpll2-constraints.name = VDSI;
+
omap3_pmic_init(twl4030, omap3logic_twldata);
return 0;
}
@@ -182,6 +196,97 @@ static inline void __init board_smsc911x_init(void)
gpmc_smsc911x_init(board_smsc911x_data);
}
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+#define OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO 154
+#define OMAP3_TORPEDO_LCD_ENABLE_GPIO 155
+#define OMAP3_TORPEDO_LCD_PWM_GPIO 56
+
+static struct gpio omap3logic_dss_gpios[] __initdata = {
+ {OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, lcd_bl_pwr},
+ {OMAP3_TORPEDO_LCD_PWM_GPIO, GPIOF_OUT_INIT_LOW, lcd bl enable},
+ {OMAP3_TORPEDO_LCD_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, lcd enable},
+};
+
+static int omap3logic_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 1);
+
+ return 0;
+}
+
+static void omap3logic_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+}
+
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = sharp_lq,
+ .platform_enable= omap3logic_enable_lcd,
+ .platform_disable = omap3logic_disable_lcd,
+};
+
+static struct omap_dss_device omap3logic_lcd_device = {
+ .name = lcd,
+ .driver_name= generic_dpi_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .data = lcd_panel,
+ .phy.dpi.data_lines = 16,
+};
+
+static struct omap_dss_device omap3logic_tv_device = {
+ .name = tv,
+ .driver_name= venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static struct omap_dss_device *omap3logic_dss_devices[] = {
+ omap3logic_lcd_device,
+ omap3logic_tv_device,
+};
+
+static struct omap_dss_board_info omap3logic_dss_data = {
+ .num_devices= ARRAY_SIZE(omap3logic_dss_devices),
+ .devices= omap3logic_dss_devices,
+ .default_device = omap3logic_lcd_device,
+};
+
+static void __init omap3logic_display_init(void)
+{
+ int r;
+
+ r = gpio_request_array(omap3logic_dss_gpios,
+ ARRAY_SIZE(omap3logic_dss_gpios));
+ if (r) {
+ printk(KERN_ERR failed to get lcd_panel_* gpios\n);
+ return;
+ }
+
+ gpio_export(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_export(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_export(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
+
+ gpio_set_value(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
+
+ msleep(50);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 1);
+
+ r = omap_display_init(omap3logic_dss_data);
+ if (r) {
+ pr_err(OMAP3LOGIC: failed to register DSS device\n);
+ gpio_free_array(omap3logic_dss_gpios,
+ ARRAY_SIZE(omap3logic_dss_gpios));
+ }
+}
+#else
+static void __init omap3logic_display_init(void) { }
+#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
+
#ifdef CONFIG_OMAP_MUX
[PATCH v5 0/6] PM QoS: implement the OMAP low level constraints management code
From: Jean Pihet j-pi...@ti.com . Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer . Implement the low level code which controls the power domains next power states, through the hwmod and pwrdm layers . Add cpuidle and power domains wake-up latency figures for OMAP3, cf. comments in the code and [1] for the details on where the numbers are magically coming from . Implement the relation between the cpuidle and per-device PM QoS frameworks in the OMAP3 specific idle callbacks. The chosen C-state shall satisfy the following conditions: . the 'valid' field is enabled, . it satisfies the enable_off_mode flag, . the next state for MPU and CORE power domains is not lower than the state programmed by the per-device PM QoS. ToDo: 1. validate the constraints framework on OMAP4 HW (done on OMAP3) 2. Re-visit the OMAP power domains states initialization procedure. Currently the power states that have been changed from the constraints API which were applied before the initialization of the power domains are lost 3. Further clean-up the OMAP PM layer, use the generic frameworks instead (OPP, PM QoS...) Based on the pm-qos branch of the linux-omap git tree (3.2.0-rc4), cf. [2]. Tested on OMAP3 Beagleboard (ES2.x) with constraints on MPU, CORE, PER in RETention and OFF modes. [1] http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement [2] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git v5: . rebased on latest linux-omap [2] . rework after Kevin's comments on the MLs v4: . split up the patches which remove the omap_pm_ code from the patch set. Those patches are to be submitted later, on top of this patch set. . latency numbers: provide the measurements setup and conditions in the code comments, added the link to the details on wiki [1]. . improved kerneldoc . split big functions into smaller ones, in order to improve the readability v3: reworked the error return path and improved the kerneldoc v2: reworked the OMAP specific cpuidle code to demote the initial C-state to a valid C-state which fulfills the per-device constraints v1: initial version Jean Pihet (6): OMAP2+: powerdomain: control power domains next state OMAP2+: omap_hwmod: manage the wake-up latency constraints OMAP: PM: register to the per-device PM QoS framework OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints OMAP3: update cpuidle latency and threshold figures OMAP3: powerdomain data: add wake-up latency figures arch/arm/mach-omap2/cpuidle34xx.c| 107 +++- arch/arm/mach-omap2/omap_hwmod.c | 27 +++- arch/arm/mach-omap2/pm.c | 71 - arch/arm/mach-omap2/pm.h | 17 ++- arch/arm/mach-omap2/powerdomain.c| 245 ++ arch/arm/mach-omap2/powerdomain.h| 36 - arch/arm/mach-omap2/powerdomains3xxx_data.c | 83 + arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + 8 files changed, 539 insertions(+), 49 deletions(-) -- 1.7.5.4 -- 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 1/6] OMAP2+: powerdomain: control power domains next state
From: Jean Pihet j-pi...@ti.com
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power domain.
The power domains get the next power state programmed directly in the
registers via pwrdm_wakeuplat_update_pwrst.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using
wake-up latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 245 +
arch/arm/mach-omap2/powerdomain.h | 36 +-
2 files changed, 279 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 8a18d1b..677a182 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -17,8 +17,10 @@
#include linux/kernel.h
#include linux/types.h
#include linux/list.h
+#include linux/slab.h
#include linux/errno.h
#include linux/string.h
+#include linux/pm_qos.h
#include trace/events/power.h
#include cm2xxx_3xxx.h
@@ -112,6 +114,12 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
+ /* Initialize the per-device wake-up constraints framework data */
+ spin_lock_init(pwrdm-wkup_lat_plist_lock);
+ plist_head_init(pwrdm-wkup_lat_plist_head);
+ pwrdm-wkup_lat_next_state = PWRDM_POWER_OFF;
+
+ /* Initialize the pwrdm state */
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
@@ -199,6 +207,158 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
return 0;
}
+/**
+ * _pwrdm_wakeuplat_update_list - Set/update/remove a powerdomain wakeup
+ * latency constraint from the pwrdm's constraint list
+ * @pwrdm: struct powerdomain * which the constraint applies to
+ * @cookie: constraint identifier, used for tracking.
+ * @min_latency: minimum wakeup latency constraint (in microseconds) for
+ * the given pwrdm. The value of PM_QOS_DEV_LAT_DEFAULT_VALUE removes
+ * the constraint.
+ * @user: pointer to the current list entry
+ * @new_user: allocated list entry, used for insertion of new constraints
+ * in the list
+ * @free_new_user: set to non-zero if the newly allocated list entry
+ * is unused and needs to be freed
+ * @free_node: set to non-zero if the current list entry is not in use
+ * anymore and needs to be freed
+ *
+ * Tracks the constraints by @cookie.
+ * Constraint set/update: Adds a new entry to powerdomain's wake-up latency
+ * constraint list.
+ * If the constraint identifier already exists in the list, the old value is
+ * overwritten.
+ * Constraint removal: Removes the identifier's entry from powerdomain's
+ * wakeup latency constraint list.
+ *
+ * Called with the pwrdm wakeup latency spinlock held.
+ *
+ * Returns 0 upon success, -EINVAL if the constraint is not existing.
+ */
+static inline int _pwrdm_update_wakeuplat_list(
+ struct powerdomain *pwrdm,
+ void *cookie,
+ long min_latency,
+ struct pwrdm_wkup_constraints_entry *user,
+ struct pwrdm_wkup_constraints_entry *new_user,
+ int *free_new_user,
+ int *free_node)
+{
+ struct pwrdm_wkup_constraints_entry *tmp_user;
+
+ /* Check if there already is a constraint for cookie */
+ plist_for_each_entry(tmp_user, pwrdm-wkup_lat_plist_head, node) {
+ if (tmp_user-cookie == cookie) {
+ user = tmp_user;
+ break;
+ }
+ }
+
+ if (min_latency != PM_QOS_DEV_LAT_DEFAULT_VALUE) {
+ /* If nothing to update, job done */
+ if (user (user-node.prio == min_latency))
+ return 0;
+
+ if (!user) {
+ /* Add new entry to the list */
+ user = new_user;
+ user-cookie = cookie;
+ *free_new_user = 0;
+ } else {
+ /* Update existing entry */
+ plist_del(user-node, pwrdm-wkup_lat_plist_head);
+ }
+
+ plist_node_init(user-node, min_latency);
+ plist_add(user-node, pwrdm-wkup_lat_plist_head);
+ } else {
+ if (user) {
+ /* Remove the constraint from the list */
+ plist_del(user-node, pwrdm-wkup_lat_plist_head);
+ *free_node = 1;
+ } else {
+ /* Constraint not existing or list empty, do nothing */
+ return -EINVAL;
+
[PATCH 2/6] OMAP2+: omap_hwmod: manage the wake-up latency constraints
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 529142a..c3a4cc4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -143,6 +143,7 @@
#include powerdomain.h
#include plat/clock.h
#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include plat/prcm.h
#include cm2xxx_3xxx.h
@@ -2616,10 +2617,34 @@ ohsps_unlock:
}
/**
+ * omap_hwmod_set_wkup_constraint- set/release a wake-up latency constraint
+ *
+ * @oh: struct omap_hwmod* to which the target device belongs to.
+ * @cookie: identifier of the constraints list for @oh.
+ * @min_latency: the minimum allowed wake-up latency for @oh.
+ *
+ * Returns 0 upon success, -EINVAL in case of invalid parameters, or
+ * the return value from pwrdm_set_wkup_lat_constraint.
+ */
+int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh,
+ void *cookie, long min_latency)
+{
+ struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh);
+
+ if (!pwrdm) {
+ pr_err(%s: Error: could not find powerdomain
+ for %s\n, __func__, oh-name);
+ return -EINVAL;
+ }
+
+ return pwrdm_set_wkup_lat_constraint(pwrdm, cookie, min_latency);
+}
+
+/**
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
* count for this device.
*
* Returns the context loss count of the powerdomain assocated with @oh
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8b372ed..222f792 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -600,6 +600,8 @@ int omap_hwmod_for_each_by_class(const char *classname,
void *user);
int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state);
+int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh, void *cookie,
+ long min_latency);
int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
--
1.7.5.4
--
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 3/6] OMAP: PM: register to the per-device PM QoS framework
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm.c | 71 +-
1 files changed, 70 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..a40d4f3 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -11,15 +11,18 @@
#include linux/kernel.h
#include linux/init.h
+#include linux/notifier.h
#include linux/io.h
#include linux/err.h
#include linux/opp.h
+#include linux/pm_qos.h
#include linux/export.h
#include plat/omap-pm.h
#include plat/omap_device.h
-#include common.h
+#include plat/omap_hwmod.h
+#include common.h
#include voltage.h
#include powerdomain.h
#include clockdomain.h
@@ -215,12 +218,78 @@ static void __init omap4_init_voltages(void)
omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva);
}
+/* Interface to the per-device PM QoS framework */
+static int omap2_dev_pm_qos_handler(struct notifier_block *nb,
+ unsigned long new_value,
+ void *req)
+{
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ struct dev_pm_qos_request *dev_pm_qos_req = req;
+
+ pr_debug(OMAP PM constraints: req@0x%p, new_value=%lu\n,
+req, new_value);
+
+ /* Look for the platform device for the constraint target device */
+ pdev = to_platform_device(dev_pm_qos_req-dev);
+
+ /* Try to catch non platform devices */
+ if (pdev-name == NULL) {
+ pr_err(%s: Error: platform device for device %s not valid\n,
+ __func__, dev_name(dev_pm_qos_req-dev));
+ return -EINVAL;
+ }
+
+ /* Find the associated omap_device for dev */
+ od = to_omap_device(pdev);
+ if (od == NULL) {
+ pr_err(%s: Error: no omap_device for device %s\n,
+ __func__, dev_name(dev_pm_qos_req-dev));
+ return -EINVAL;
+ }
+
+ /* Check that the omap_device has an unique hwmod entry */
+ if (od-hwmods_cnt != 1) {
+ pr_err(%s: Error: No unique hwmod for device %s\n,
+ __func__, dev_name(dev_pm_qos_req-dev));
+ return -EINVAL;
+ }
+
+ /* Find the primary omap_hwmod for dev */
+ oh = od-hwmods[0];
+
+ pr_debug(OMAP PM constraints: req@0x%p, dev=0x%p, new_value=%lu\n,
+req, dev_pm_qos_req-dev, new_value);
+
+ /* Apply the constraint */
+ return omap_hwmod_set_wkup_lat_constraint(oh, dev_pm_qos_req,
+ new_value);
+}
+
+static struct notifier_block omap2_dev_pm_qos_notifier = {
+ .notifier_call = omap2_dev_pm_qos_handler,
+};
+
+static int __init omap2_dev_pm_qos_init(void)
+{
+ int ret;
+
+ ret = dev_pm_qos_add_global_notifier(omap2_dev_pm_qos_notifier);
+ WARN(ret, KERN_ERR Cannot add global notifier for dev PM QoS\n);
+
+ return ret;
+}
+
static int __init omap2_common_pm_init(void)
{
if (!of_have_populated_dt())
omap2_init_processor_devices();
omap_pm_if_init();
+ /* Register to the per-device PM QoS framework */
+ omap2_dev_pm_qos_init();
+
return 0;
}
postcore_initcall(omap2_common_pm_init);
--
1.7.5.4
--
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 4/6] OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints
From: Jean Pihet j-pi...@ti.com
The MPU latency figures for cpuidle include the MPU itself and also
the peripherals needed for the MPU to execute instructions (e.g.
main memory, caches, IRQ controller, MMU etc). On OMAP3 those
peripherals belong to the MPU and CORE power domains and so the
cpuidle C-states are a combination of MPU and CORE states.
This patch implements the relation between the cpuidle and per-
device PM QoS frameworks in the OMAP3 specific idle callbacks.
The chosen C-state shall satisfy the following conditions:
. the 'valid' field is enabled,
. it satisfies the enable_off_mode flag,
. the next state for MPU and CORE power domains is not lower than the
next state calculated by the per-device PM QoS.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 57
arch/arm/mach-omap2/pm.h | 17 ++-
2 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1f71ebb..c67835f 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -40,7 +40,7 @@
#ifdef CONFIG_CPU_IDLE
/*
- * The latencies/thresholds for various C states have
+ * The MPU latencies/thresholds for various C states have
* to be configured from the respective board files.
* These are some default values (which might not provide
* the best power savings) used on boards which do not
@@ -75,14 +75,14 @@ struct omap3_idle_statedata
omap3_idle_data[OMAP3_NUM_STATES];
struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
+ struct clockdomain *clkdm)
{
clkdm_allow_idle(clkdm);
return 0;
}
static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
+ struct clockdomain *clkdm)
{
clkdm_deny_idle(clkdm);
return 0;
@@ -96,10 +96,13 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
*
* Called from the CPUidle framework to program the device to the
* specified target state selected by the governor.
+ *
+ * Note: this function does not check for any pending activity or dependency
+ * between power domains states, so the caller shall check the parameters
+ * correctness.
*/
static int omap3_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+ struct cpuidle_driver *drv, int index)
{
struct omap3_idle_statedata *cx =
cpuidle_get_statedata(dev-states_usage[index]);
@@ -174,18 +177,23 @@ return_sleep_time:
* to the caller. Else, this function searches for a lower c-state which is
* still valid (as defined in omap3_power_states[]) and returns its index.
*
- * A state is valid if the 'valid' field is enabled and
- * if it satisfies the enable_off_mode condition.
+ * A state is valid if:
+ * . the 'valid' field is enabled,
+ * . it satisfies the enable_off_mode flag,
+ * . the next state for MPU and CORE power domains is not lower than the
+ * state programmed by the per-device PM QoS.
*/
static int next_valid_state(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+ struct cpuidle_driver *drv, int index)
{
struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
struct cpuidle_state *curr = drv-states[index];
struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
+ u32 mpu_pm_qos_next_state = mpu_pd-wkup_lat_next_state;
+ u32 core_pm_qos_next_state = core_pd-wkup_lat_next_state;
+
int next_index = -1;
if (enable_off_mode) {
@@ -202,7 +210,9 @@ static int next_valid_state(struct cpuidle_device *dev,
/* Check if current state is valid */
if ((cx-valid)
(cx-mpu_state = mpu_deepest_state)
- (cx-core_state = core_deepest_state)) {
+ (cx-core_state = core_deepest_state)
+ (cx-mpu_state = mpu_pm_qos_next_state)
+ (cx-core_state = core_pm_qos_next_state)) {
return index;
} else {
int idx = OMAP3_NUM_STATES - 1;
@@ -227,7 +237,9 @@ static int next_valid_state(struct cpuidle_device *dev,
cx = cpuidle_get_statedata(dev-states_usage[idx]);
if ((cx-valid)
(cx-mpu_state = mpu_deepest_state)
- (cx-core_state =
[PATCH 5/6] OMAP3: update cpuidle latency and threshold figures
From: Jean Pihet j-pi...@ti.com
Update the data from the measurements performed at HW and SW levels.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers coming from.
ToDo:
- Measure the wake-up latencies for all power domains for OMAP3
- Correct some numbers when sys_clkreq and sys_offmode are supported
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 52 +++-
1 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index c67835f..3caa932 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -40,27 +40,41 @@
#ifdef CONFIG_CPU_IDLE
/*
- * The MPU latencies/thresholds for various C states have
- * to be configured from the respective board files.
- * These are some default values (which might not provide
- * the best power savings) used on boards which do not
- * pass these details from the board file.
+ * The MPU latency and threshold values for the C-states are the worst case
+ * values from the HW and SW, as described in details at
+ *
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#cpuidle_results
+ *
+ * Measurements conditions and remarks:
+ * . the measurements have been performed at OPP50
+ * . the sys_offmode signal is not supported and so not used for the
+ *measurements. Instead the latency and threshold values for C9 are
+ *corrected with the value for Triton 2, which is 11.5ms
+ * . the sys_clkreq signal is not used and so a correction is needed - TBD
+ * . the sys_clkoff signal is supported, this value need to be corrected with
+ *the correct value of SYSCLK on/off timings (1ms for sysclk on, 2.5ms
+ *for sysclk off)
+ * . in order to force the cpuidle algorithm to chose the power efficient
+ *C-states (C1, C3, C5, C7) in preference, the other C-states have a
+ *threshold value equal to the next power efficient C-state
+ *
+ * The latency and threshold values can be overriden by data from the board
+ * files, using omap3_pm_init_cpuidle.
*/
static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 */
- {2 + 2, 5, 1},
- /* C2 */
- {10 + 10, 30, 1},
- /* C3 */
- {50 + 50, 300, 1},
- /* C4 */
- {1500 + 1800, 4000, 1},
- /* C5 */
- {2500 + 7500, 12000, 1},
- /* C6 */
- {3000 + 8500, 15000, 1},
- /* C7 */
- {1 + 3, 30, 1},
+ /* C1 . MPU WFI + Core active */
+ {73 + 78, 152, 1},
+ /* C2 . MPU WFI + Core inactive */
+ {165 + 88, 345, 1},
+ /* C3 . MPU CSWR + Core inactive */
+ {163 + 182, 345, 1},
+ /* C4 . MPU OFF + Core inactive */
+ {2852 + 605, 15, 1},
+ /* C5 . MPU RET + Core RET */
+ {800 + 366, 2120, 1},
+ /* C6 . MPU OFF + Core RET */
+ {4080 + 801, 215000, 1},
+ /* C7 . MPU OFF + Core OFF */
+ {4300 + 13000, 215000, 1},
};
#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
--
1.7.5.4
--
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 6/6] OMAP3: powerdomain data: add wake-up latency figures
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are preliminary and
shall be added.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers coming from.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 83 +++
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index 8ef26da..63a3afd 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -31,6 +31,19 @@
/*
* Powerdomains
+ *
+ * The wakeup_lat values are derived from HW and SW measurements on
+ * the actual target. For more details cf.
+ *
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#Results_for_individual_power_domains
+ *
+ * Note: the latency figures for MPU, PER, CORE, NEON have been obtained
+ * from actual measurements.
+ * The latency figures for the other power domains are preliminary and
+ * shall be added.
+ *
+ * Note: only the SW restore timing values are taken into account.
+ * The HW impact of the sys_clkreq and sys_offmode signals is not taken
+ * into account - TDB
*/
static struct powerdomain iva2_pwrdm = {
@@ -51,6 +64,13 @@ static struct powerdomain iva2_pwrdm = {
[2] = PWRSTS_OFF_ON,
[3] = PWRSTS_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1100,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 350,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = mpu_iva },
};
@@ -67,6 +87,13 @@ static struct powerdomain mpu_3xxx_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_OFF_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1830,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 121,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = mpu_iva },
};
@@ -94,6 +121,13 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
[0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
[1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 3082,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 153,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = core },
};
@@ -116,6 +150,13 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
[0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
[1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 3082,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 153,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = core },
};
@@ -131,6 +172,13 @@ static struct powerdomain dss_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 70,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 20,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = core },
};
@@ -152,6 +200,13 @@ static struct powerdomain sgx_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = core },
};
@@ -167,6 +222,13 @@ static struct powerdomain cam_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 850,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 35,
+
Re: [linux-pm] [PATCH 4/6] OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints
Hi Kevin, On Wed, Nov 23, 2011 at 8:43 PM, Kevin Hilman khil...@ti.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: On Thu, Nov 17, 2011 at 10:29 PM, Kevin Hilman khil...@ti.com wrote: jean.pi...@newoldbits.com writes: From: Jean Pihet j-pi...@ti.com The MPU latency figures for cpuidle include the MPU itself and also the peripherals needed for the MPU to execute instructions (e.g. main memory, caches, IRQ controller, MMU etc). On OMAP3 those peripherals belong to the MPU and CORE power domains and so the cpuidle C-states are a combination of MPU and CORE states. This patch implements the relation between the cpuidle and per- device PM QoS frameworks in the OMAP3 specific idle callbacks. The chosen C-state shall satisfy the following conditions: . the 'valid' field is enabled, . it satisfies the enable_off_mode flag, Not directly related to this patch, but is there any reason to keep the 'enable_off_mode' flag after this series? enable_off_mode could be removed completely after this series unless there is a need to prevent OFF mode for debug reasons. Great. For debug reasons, we can just as easily set constraints to prevent off mode, so I would like to see it disappear. I have a WIP patch that removes the enable_off_mode flag and will post it as soon as this series is in the upstream pipe. Thanks, Jean Kevin -- 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/2] OMAP: PM: switch from omap_pm_ functions to PM QoS
Hi Kevin, Paul, ping on this series Thanks, Jean On Wed, Oct 19, 2011 at 4:28 PM, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com . Convert the OMAP I2C driver to the PM QoS API for MPU latency constraints . Remove the latency related functions from OMAP PM in favor of the generic per-device PM QoS API Apply on top of the OMAP PM QoS patch set [1]. Based on the pm-qos branch of the linux-pm git tree (3.1.0-rc3), cf. [2]. Tested on OMAP3 Beagleboard (ES2.x) with constraints on MPU, CORE, PER in RETention and OFF modes. [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/65971 [2] git://github.com/rjwysocki/linux-pm.git Jean Pihet (2): OMAP: convert I2C driver to PM QoS for latency constraints OMAP: PM: remove the latency related functions from the API Documentation/arm/OMAP/omap_pm | 55 +++- arch/arm/plat-omap/i2c.c | 20 -- arch/arm/plat-omap/include/plat/omap-pm.h | 99 - arch/arm/plat-omap/omap-pm-noop.c | 88 - drivers/i2c/busses/i2c-omap.c | 30 +- include/linux/i2c-omap.h | 1 - 6 files changed, 24 insertions(+), 269 deletions(-) -- 1.7.4.1 -- 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/4] fixes for twl4030-irq in mainline
Hi Neil, On Sun, Nov 27, 2011 at 07:17:41AM +1100, NeilBrown wrote: Hi, The recent tidying up of twl4030-irq seems to have left it broken. At least it doesn't work for me on my gta04 (www.gta04.org). The first interrupt from the device freezes the whole system (by being constantly delivered) The following 4 patches make it work for me and addresses some other less critical issues like a typo in a comment :-) Thanks, I applied all 4 of them. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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/7] mfd: twl4030-irq: set irq nested flag
On Thu, Jun 30, 2011 at 12:51 PM, Felipe Balbi ba...@ti.com wrote:
threads from twl4030's children will be called
nested in the context of the demultiplexing
handler on twl4030-irq.c.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/twl4030-irq.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 1b9ab2f..ff16e9c 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -304,7 +304,7 @@ static irqreturn_t handle_twl4030_pih(int irq, void
*devid)
pih_isr;
pih_isr = 1, module_irq++) {
if (pih_isr 0x1)
- generic_handle_irq(module_irq);
+ handle_nested_irq(module_irq);
But handle_nested_irq calls action-thread_fn, which is NULL for the
sih handlers that are set-up below; handle_twl4030_sih will never be
called.
}
return IRQ_HANDLED;
@@ -596,9 +596,7 @@ static void handle_twl4030_sih(unsigned irq, struct
irq_desc *desc)
int isr;
/* reading ISR acks the IRQs, using clear-on-read mode */
- local_irq_enable();
isr = sih_read_isr(sih);
- local_irq_disable();
But handle_twl4030_sih is still not nested.
Fortunately, Neil Brown already fixed the issues in this patch by
making handle_twl4030_sih truly nested:
http://article.gmane.org/gmane.linux.kernel/1220708
Cheers.
--
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: [PATCHv7 5/7] mfd: twl-core: pass driver data from pdata to add_regulator for VDD1 and VDD2
Hi Tero, On Mon, Nov 28, 2011 at 04:53:23PM +0200, Tero Kristo wrote: This way, we can add custom flags for VDD1 and VDD2 regulators that get passed all the way to regulator init. This is needed for SMPS regulator support to select used controller mode for these regulators (either voltage processor or default.) Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/twl-core.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 01ecfee..af93fce 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -846,12 +846,14 @@ add_children(struct twl4030_platform_data *pdata, unsigned long features) return PTR_ERR(child); child = add_regulator(TWL4030_REG_VDD1, pdata-vdd1, - features); + features | + (u32)pdata-vdd1-driver_data); That looks hackish to me. Do you have any guarantee that your driver_data and your features bitmaps have zero intersections ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 01/10] GPIO: gpio-generic: Move initialization up to postcore
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Care to explain a bit more why you need to initialize those devices
early on?
Usually moving things earlier and earlier is an endless loop
adding more and more nasty dependencies..
I'd rather see things getting initialized later as regular
device drivers so we have decent kernel error messages when
something goes wrong without having to enable debug_ll.
Regards,
Tony
Created against linux-3.2-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/gpio/gpio-generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 4e24436..a6eaf38 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -528,7 +528,7 @@ static int __init bgpio_platform_init(void)
{
return platform_driver_register(bgpio_driver);
}
-module_init(bgpio_platform_init);
+postcore_initcall(bgpio_platform_init);
static void __exit bgpio_platform_exit(void)
{
--
1.7.3.4
--
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
[PATCHv11 0/8] OMAP3+: PRCM chain handler
Hi, PRCM chain handler is adding a support to the omap3+ kernel that allows different drivers to use PRCM interrupt events for their own purposes, typically this means IO wakeups. This work was attempted to integrate as its own driver at some point of the evolution of this set, however this was now postponed as the lacking support is basically blocking a few drivers. This is the version 11 of this set, now posted to linux-arm-kernel also as cc. Contains just a couple of minor changes compared to previous version proposed by Kevin Hilman. Also, patch 8 is new (posted as a separate patch to l-o list earlier), for supporting different irqs for different pads on the same hwmod. This is needed at least by USB driver. This version tested on omap3 beagle board, dynamic idle + suspend, with and without off-mode. I have pushed two branches on a public git tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: chain-prcm-v11 branch2: chain-prcm-v11-debug Debug branch contains a few debugging related patches I've used for testing purposes. -Tero -- 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
[PATCHv11 1/8] ARM: OMAP2+: hwmod: Add API to enable IO ring wakeup.
From: R, Govindraj govindraj.r...@ti.com
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hwmod idle transition based on whether wakeup_flag is
set or cleared.
Map the enable/disable pad wakeup API's to hwmod_wakeup_enable/disable.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6b3088d..8d37d83 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2059,6 +2059,34 @@ static int __init omap_hwmod_setup_all(void)
core_initcall(omap_hwmod_setup_all);
/**
+ * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
+ * @oh: struct omap_hwmod *
+ * @set: bool value indicating to set or clear wakeup status.
+ *
+ * Set or Clear wakeup flag for the io_pad.
+ */
+static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ struct omap_device_pad *pad;
+ int ret = -EINVAL, j;
+
+ if (oh-mux oh-mux-enabled) {
+ for (j = 0; j oh-mux-nr_pads_dynamic; j++) {
+ pad = oh-mux-pads_dynamic[j];
+ if (pad-flags OMAP_DEVICE_PAD_WAKEUP) {
+ if (set_wake)
+ pad-idle |= OMAP_WAKEUP_EN;
+ else
+ pad-idle = ~OMAP_WAKEUP_EN;
+ ret = 0;
+ }
+ }
+ }
+
+ return ret;
+}
+
+/**
* omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2390,6 +2418,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
{
return _del_initiator_dep(oh, init_oh);
}
+/**
+ * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * set wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Enable pad wake-up capability */
+ return omap_hwmod_set_ioring_wakeup(oh, true);
+}
+
+/**
+ * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Disable pad wakeup capability */
+ return omap_hwmod_set_ioring_wakeup(oh, false);
+}
/**
* omap_hwmod_enable_wakeup - allow device to wake up the system
@@ -2416,6 +2473,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_enable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ omap_hwmod_enable_ioring_wakeup(oh);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
@@ -2446,6 +2504,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_disable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ omap_hwmod_disable_ioring_wakeup(oh);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
--
1.7.4.1
--
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
[PATCHv11 2/8] ARM: OMAP2+: hwmod: Add API to check IO PAD wakeup status
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h| 13 +++
arch/arm/mach-omap2/omap_hwmod.c |7 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
4 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 655e948..5f15ab8 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -351,6 +351,36 @@ err1:
return NULL;
}
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup event is set for pad else false
+ * if wakeup is not occured or pads are not avialable.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ int i;
+ unsigned int val;
+ u8 ret = false;
+
+ for (i = 0; i hmux-nr_pads; i++) {
+ struct omap_device_pad *pad = hmux-pads[i];
+
+ if (pad-flags OMAP_DEVICE_PAD_WAKEUP) {
+ val = omap_mux_read(pad-partition,
+ pad-mux-reg_offset);
+ if (val OMAP_WAKEUP_EVENT) {
+ ret = true;
+ break;
+ }
+ }
+ }
+
+ return ret;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..8b2150a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Called only from omap_hwmod.c, do not use.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
#else
+static inline bool
+omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8d37d83..d7f4623 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2721,3 +2721,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+ if (oh oh-mux)
+ return omap_hwmod_mux_get_wake_status(oh-mux);
+ return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8b372ed..1b81dfb 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -604,6 +604,7 @@ int omap_hwmod_get_context_loss_count(struct omap_hwmod
*oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
* to use initcalls once the initial boot ordering is straightened out
--
1.7.4.1
--
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
[PATCHv11 3/8] ARM: OMAP: prm: add support for chain interrupt handler
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.
PRCM interrupts have two priority levels, high or normal. High priority
is needed for IO event handling, so that we can be sure that IO events
are processed before other events. This reduces latency for IO event
customers and also prevents incorrect ack sequence on OMAP3.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Avinash.H.M avinas...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/prcm-common.h | 29 +
arch/arm/mach-omap2/prcm.c | 229
arch/arm/mach-omap2/prm2xxx_3xxx.c | 21
arch/arm/mach-omap2/prm44xx.c | 21
4 files changed, 300 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 0363dcb..3c54e3c 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -408,6 +408,35 @@
extern void __iomem *prm_base;
extern void __iomem *cm_base;
extern void __iomem *cm2_base;
+
+struct omap_prcm_irq {
+ const char *name;
+ unsigned int offset;
+ bool priority;
+};
+
+struct omap_prcm_irq_setup {
+ u32 ack;
+ u32 mask;
+ int nr_regs;
+ int nr_irqs;
+ const struct omap_prcm_irq *irqs;
+ u32 *saved_mask;
+ u32 *priority_mask;
+ int base_irq;
+ int irq;
+};
+
+#define OMAP_PRCM_IRQ(_name, _offset, _priority) { \
+ .name = _name, \
+ .offset = _offset, \
+ .priority = _priority \
+ }
+
+extern void omap_prcm_irq_cleanup(void);
+extern int omap_prcm_register_chain_handler(
+ struct omap_prcm_irq_setup *irq_setup);
+extern int omap_prcm_event_to_irq(const char *event);
# endif
#endif
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 597e2da..948247f 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -24,6 +24,9 @@
#include linux/io.h
#include linux/delay.h
#include linux/export.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/slab.h
#include mach/system.h
#include plat/common.h
@@ -45,6 +48,10 @@ void __iomem *cm_base;
void __iomem *cm2_base;
#define MAX_MODULE_ENABLE_WAIT 10
+#define OMAP_PRCM_MAX_NR_PENDING_REG 2
+
+static struct irq_chip_generic **prcm_irq_chips;
+static struct omap_prcm_irq_setup *prcm_irq_setup;
u32 omap_prcm_get_reset_sources(void)
{
@@ -159,3 +166,225 @@ void __init omap2_set_globals_prcm(struct omap_globals
*omap2_globals)
if (omap2_globals-cm2)
cm2_base = omap2_globals-cm2;
}
+
+static inline u32 prcm_irq_read_reg(int offset)
+{
+ return __raw_readl(prm_base + offset);
+}
+
+static inline void prcm_irq_write_reg(u32 value, int offset)
+{
+ __raw_writel(value, prm_base + offset);
+}
+
+static void omap_prm_pending_events(unsigned long *events)
+{
+ u32 mask, st;
+ int i;
+
+ memset(events, 0, prcm_irq_setup-nr_regs * sizeof(unsigned long));
+
+ for (i = 0; i prcm_irq_setup-nr_regs; i++) {
+ mask = prcm_irq_read_reg(prcm_irq_setup-mask + i * 4);
+ st = prcm_irq_read_reg(prcm_irq_setup-ack + i * 4);
+ events[i] = mask st;
+ }
+}
+
+/*
+ * Move priority events from events to priority_events array
+ */
+static void omap_prm_events_filter_priority(unsigned long *events,
+ unsigned long *priority_events)
+{
+ int i;
+
+ for (i = 0; i prcm_irq_setup-nr_regs; i++) {
+ priority_events[i] =
+ events[i] prcm_irq_setup-priority_mask[i];
+ events[i] ^= priority_events[i];
+ }
+}
+
+/*
+ * PRCM Interrupt Handler
+ *
+ * This is a common handler for the OMAP PRCM interrupts. Pending
+ * interrupts are detected by a call to prm_pending_events and
+ * dispatched accordingly. Clearing of the wakeup events should be
+ * done by the SoC specific individual handlers.
+ */
+static void omap_prcm_irq_handler(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned long pending[OMAP_PRCM_MAX_NR_PENDING_REG];
+ unsigned long priority_pending[OMAP_PRCM_MAX_NR_PENDING_REG];
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int virtirq;
+ int nr_irqs = prcm_irq_setup-nr_regs * 32;
+
+ /*
+* Loop until all pending irqs are handled, since
+* generic_handle_irq() can cause new irqs to come
+*/
+ while (1) {
+
[PATCHv11 5/8] ARM: OMAP2+: mux: add support for PAD wakeup interrupts
OMAP mux now parses active wakeup events from pad registers and
calls corresponding hwmod ISRs once a wakeup is detected. This is
accomplished by registering an interrupt handler for PRCM IO event,
which is raised every time the HW detects wakeups.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 5f15ab8..0d1962e 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -32,6 +32,8 @@
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/uaccess.h
+#include linux/irq.h
+#include linux/interrupt.h
#include asm/system.h
@@ -39,6 +41,7 @@
#include control.h
#include mux.h
+#include prcm-common.h
#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
#define OMAP_MUX_BASE_SZ 0x5ca
@@ -381,6 +384,33 @@ bool omap_hwmod_mux_get_wake_status(struct
omap_hwmod_mux_info *hmux)
return ret;
}
+/**
+ * omap_hwmod_mux_handle_irq - Process wakeup events for a single hwmod
+ *
+ * Checks a single hwmod for every wakeup capable pad to see if there is an
+ * active wakeup event. If this is the case, call the corresponding ISR.
+ */
+static int _omap_hwmod_mux_handle_irq(struct omap_hwmod *oh, void *data)
+{
+ if (!oh-mux || !oh-mux-enabled)
+ return 0;
+ if (omap_hwmod_mux_get_wake_status(oh-mux))
+ generic_handle_irq(oh-mpu_irqs[0].irq);
+ return 0;
+}
+
+/**
+ * omap_hwmod_mux_handle_irq - Process pad wakeup irqs.
+ *
+ * Calls a function for each registered omap_hwmod to check
+ * pad wakeup statuses.
+ */
+static irqreturn_t omap_hwmod_mux_handle_irq(int irq, void *unused)
+{
+ omap_hwmod_for_each(_omap_hwmod_mux_handle_irq, NULL);
+ return IRQ_HANDLED;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
@@ -745,6 +775,7 @@ static void __init omap_mux_free_names(struct omap_mux *m)
static int __init omap_mux_late_init(void)
{
struct omap_mux_partition *partition;
+ int ret;
list_for_each_entry(partition, mux_partitions, node) {
struct omap_mux_entry *e, *tmp;
@@ -765,6 +796,13 @@ static int __init omap_mux_late_init(void)
}
}
+ ret = request_irq(omap_prcm_event_to_irq(io),
+ omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+ hwmod_io, omap_mux_late_init);
+
+ if (ret)
+ printk(KERN_WARNING Failed to setup hwmod io irq %d\n, ret);
+
omap_mux_dbg_init();
return 0;
--
1.7.4.1
--
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
[PATCHv11 7/8] ARM: OMAP3: pm: do not enable PRCM MPU interrupts manually
This is handled automatically by the PRCM chain interrupt mechanism now. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/pm34xx.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 5fd99e5..d5ce8d2 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -668,10 +668,6 @@ static void __init prcm_setup_regs(void) OMAP3430_GRPSEL_GPT1_MASK | OMAP3430_GRPSEL_GPT12_MASK, WKUP_MOD, OMAP3430_PM_MPUGRPSEL); - /* For some reason IO doesn't generate wakeup event even if -* it is selected to mpu wakeup goup */ - omap2_prm_write_mod_reg(OMAP3430_IO_EN_MASK | OMAP3430_WKUP_EN_MASK, - OCP_MOD, OMAP3_PRM_IRQENABLE_MPU_OFFSET); /* Enable PM_WKEN to support DSS LPR */ omap2_prm_write_mod_reg(OMAP3430_PM_WKEN_DSS_EN_DSS_MASK, -- 1.7.4.1 -- 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
[PATCHv11 4/8] ARM: OMAP: prcm: add suspend prepare / finish support
PRCM chain handler needs to disable forwarding of interrupts during
suspend, because runtime PM is disabled and most of the drivers
are potentially not able to handle interrupts coming at this time.
This patch masks all the PRCM interrupt events if a PRCM interrupt
occurs during suspend, but does not ack them. Once suspend finish
is called, all the masked events will be re-enabled, which causes
immediate PRCM interrupt and handles the postponed event.
The suspend prepare and complete callbacks will be called from
pm34xx.c / pm44xx.c files in the following patches.
The functions defined in this patch should eventually be moved to
suspend-prepare and suspend-finish driver hooks, once the PRCM
chain handler will be made as its own driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/prcm-common.h |4 +++
arch/arm/mach-omap2/prcm.c| 46 -
2 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 3c54e3c..6cb0daf 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -425,6 +425,8 @@ struct omap_prcm_irq_setup {
u32 *priority_mask;
int base_irq;
int irq;
+ bool suspended;
+ bool suspend_save_flag;
};
#define OMAP_PRCM_IRQ(_name, _offset, _priority) { \
@@ -437,6 +439,8 @@ extern void omap_prcm_irq_cleanup(void);
extern int omap_prcm_register_chain_handler(
struct omap_prcm_irq_setup *irq_setup);
extern int omap_prcm_event_to_irq(const char *event);
+extern void omap_prcm_irq_prepare(void);
+extern void omap_prcm_irq_complete(void);
# endif
#endif
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 948247f..e7c8f3f 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -221,12 +221,28 @@ static void omap_prcm_irq_handler(unsigned int irq,
struct irq_desc *desc)
struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned int virtirq;
int nr_irqs = prcm_irq_setup-nr_regs * 32;
+ int i;
+
+ /*
+* If we are suspended, mask all interrupts from PRCM level,
+* this does not ack them, and they will be pending until
+* we re-enable the interrupts, at which point the
+* omap_prcm_irq_handler will be executed again
+*/
+ if (prcm_irq_setup-suspended) {
+ for (i = 0; i prcm_irq_setup-nr_regs; i++) {
+ prcm_irq_setup-saved_mask[i] =
+ prcm_irq_read_reg(prcm_irq_setup-mask + i * 4);
+ prcm_irq_write_reg(0, prcm_irq_setup-mask + i * 4);
+ }
+ prcm_irq_setup-suspend_save_flag = true;
+ }
/*
* Loop until all pending irqs are handled, since
* generic_handle_irq() can cause new irqs to come
*/
- while (1) {
+ while (!prcm_irq_setup-suspended) {
omap_prm_pending_events(pending);
/* No bit set, then all IRQs are handled */
@@ -307,6 +323,34 @@ void omap_prcm_irq_cleanup(void)
prcm_irq_setup-base_irq = 0;
}
+void omap_prcm_irq_prepare(void)
+{
+ prcm_irq_setup-suspended = true;
+}
+
+void omap_prcm_irq_complete(void)
+{
+ int i;
+
+ prcm_irq_setup-suspended = false;
+
+ /* If we have not saved the masks, do not attempt to restore */
+ if (!prcm_irq_setup-suspend_save_flag)
+ return;
+
+ prcm_irq_setup-suspend_save_flag = false;
+
+ /*
+* Re-enable all masked PRCM irq sources, this
+* causes the PRCM interrupt to fire immediately
+* if the events were masked previously in the chain
+* handler
+*/
+ for (i = 0; i prcm_irq_setup-nr_regs; i++)
+ prcm_irq_write_reg(prcm_irq_setup-saved_mask[i],
+ prcm_irq_setup-mask + i * 4);
+}
+
/*
* Initializes the prcm chain handler based on provided parameters
*/
--
1.7.4.1
--
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
[PATCHv11 8/8] ARM: OMAP: mux: add support for selecting mpu_irq for each wakeup pad
By default all registered pads will trigger mpu_irqs[0]. Now there is
an API for selecting used mpu_irq on pad basis, which can be used to
trigger different irq handlers for different pads in the same hwmod.
Each pad that requires its interrupt to be re-routed this way must
have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq).
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c| 67 ++
arch/arm/mach-omap2/omap_hwmod.c |7 ---
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 ++
3 files changed, 61 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 0d1962e..2da3f3d 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -354,19 +354,53 @@ err1:
return NULL;
}
+int omap_hwmod_pad_route_irq(struct omap_hwmod *oh, int pad_idx,
+ int irq_idx)
+{
+ int nr_irqs;
+
+ if (!oh || !oh-mux || !oh-mpu_irqs || pad_idx 0 ||
+ pad_idx = oh-mux-nr_pads_dynamic)
+ return -EINVAL;
+
+ /* Check the number of available mpu_irqs */
+ for (nr_irqs = 0; oh-mpu_irqs[nr_irqs].irq = 0; nr_irqs++)
+ ;
+
+ if (irq_idx = nr_irqs)
+ return -EINVAL;
+
+ if (!oh-mux-irqs) {
+ oh-mux-irqs = kzalloc(sizeof(int) * oh-mux-nr_pads_dynamic,
+ GFP_KERNEL);
+ if (!oh-mux-irqs)
+ return -ENOMEM;
+ }
+ oh-mux-irqs[pad_idx] = irq_idx;
+
+ return 0;
+}
+
/**
- * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * omap_hwmod_mux_scan_wakeups - omap hwmod scan wakeup pads
* @hmux: Pads for a hwmod
+ * @mpu_irqs: MPU irq array for a hwmod
*
- * Gets the wakeup status of given pad from omap-hwmod.
- * Returns true if wakeup event is set for pad else false
- * if wakeup is not occured or pads are not avialable.
+ * Scans the wakeup status of pads for a single hwmod.
+ * If an irq array is defined for this mux, the parser
+ * will call the registered ISRs for corresponding pads,
+ * otherwise the parser will stop at the first wakeup
+ * active pad and return.
+ * Returns true if there is a pending and non-served
+ * wakeup event for the mux, otherwise false.
*/
-bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+static bool omap_hwmod_mux_scan_wakeups(struct omap_hwmod_mux_info *hmux,
+ struct omap_hwmod_irq_info *mpu_irqs)
{
int i;
unsigned int val;
- u8 ret = false;
+ u32 handled_irqs = 0;
+ int irq;
for (i = 0; i hmux-nr_pads; i++) {
struct omap_device_pad *pad = hmux-pads[i];
@@ -375,13 +409,26 @@ bool omap_hwmod_mux_get_wake_status(struct
omap_hwmod_mux_info *hmux)
val = omap_mux_read(pad-partition,
pad-mux-reg_offset);
if (val OMAP_WAKEUP_EVENT) {
- ret = true;
- break;
+ if (hmux-irqs) {
+ irq = hmux-irqs[i];
+ /*
+* make sure we only handle each
+* irq once
+*/
+ if (handled_irqs 1 irq)
+ continue;
+
+ handled_irqs |= 1 irq;
+
+ generic_handle_irq(mpu_irqs[irq].irq);
+ } else {
+ return true;
+ }
}
}
}
- return ret;
+ return false;
}
/**
@@ -394,7 +441,7 @@ static int _omap_hwmod_mux_handle_irq(struct omap_hwmod
*oh, void *data)
{
if (!oh-mux || !oh-mux-enabled)
return 0;
- if (omap_hwmod_mux_get_wake_status(oh-mux))
+ if (omap_hwmod_mux_scan_wakeups(oh-mux, oh-mpu_irqs))
generic_handle_irq(oh-mpu_irqs[0].irq);
return 0;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d7f4623..8d37d83 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2721,10 +2721,3 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
-
-int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
-{
- if (oh oh-mux)
- return omap_hwmod_mux_get_wake_status(oh-mux);
- return -EINVAL;
-}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1b81dfb..a5f0a5f 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++
[PATCHv11 6/8] ARM: OMAP3: pm: use prcm chain handler
PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to serve IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.
Core event code is also changed in accordance to this, as PRCM
interrupt handling is done by independent handlers, and the core
handler should not clear the IO events anymore.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 111 ++--
arch/arm/mach-omap2/prm2xxx_3xxx.c |1 +
2 files changed, 45 insertions(+), 67 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index efa6649..5fd99e5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -194,7 +194,7 @@ static void omap3_save_secure_ram_context(void)
* that any peripheral wake-up events occurring while attempting to
* clear the PM_WKST_x are detected and cleared.
*/
-static int prcm_clear_mod_irqs(s16 module, u8 regs)
+static int prcm_clear_mod_irqs(s16 module, u8 regs, u32 ignore_bits)
{
u32 wkst, fclk, iclk, clken;
u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
@@ -206,6 +206,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, grpsel_off);
+ wkst = ~ignore_bits;
if (wkst) {
iclk = omap2_cm_read_mod_reg(module, iclk_off);
fclk = omap2_cm_read_mod_reg(module, fclk_off);
@@ -221,6 +222,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
omap2_cm_set_mod_reg_bits(clken, module, fclk_off);
omap2_prm_write_mod_reg(wkst, module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, wkst_off);
+ wkst = ~ignore_bits;
c++;
}
omap2_cm_write_mod_reg(iclk, module, iclk_off);
@@ -230,76 +232,35 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
return c;
}
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_io(int irq, void *unused)
{
int c;
- c = prcm_clear_mod_irqs(WKUP_MOD, 1);
- c += prcm_clear_mod_irqs(CORE_MOD, 1);
- c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
- if (omap_rev() OMAP3430_REV_ES1_0) {
- c += prcm_clear_mod_irqs(CORE_MOD, 3);
- c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
- }
+ c = prcm_clear_mod_irqs(WKUP_MOD, 1,
+ ~(OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK));
- return c;
+ return c ? IRQ_HANDLED : IRQ_NONE;
}
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
{
- u32 irqenable_mpu, irqstatus_mpu;
- int c = 0;
-
- irqenable_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQENABLE_MPU_OFFSET);
- irqstatus_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- irqstatus_mpu = irqenable_mpu;
-
- do {
- if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
-OMAP3430_IO_ST_MASK)) {
- c = _prcm_int_handle_wakeup();
-
- /*
-* Is the MPU PRCM interrupt handler racing with the
-* IVA2 PRCM interrupt handler ?
-*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
-but no wakeup sources are marked\n);
- } else {
- /* XXX we need to expand our PRCM interrupt handler */
- WARN(1, prcm: WARNING: PRCM interrupt received, but
-no code to handle it (%08x)\n, irqstatus_mpu);
- }
-
-
Re: [PATCH RESEND v5 0/3] Add support for TI814X processor series
* Hemant Pedanekar hema...@ti.com [111209 17:27]: This patch set adds support for DM814x/AM387x device series having Cortex-A8 MPU. The technical documents are available from following link: http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html This series is referred in code as TI814X. Since these devices share similar architecture as TI816X devices, existing TI816X code is updated to accomodate TI814X support. The code shared across TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable, while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific execution differences. Thanks applying 1 2 into soc branch and 3 into board 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
Interrupt issue in twl4030_keypad
Hi, The short version is this: either we revert this patch[1], or we apply this patch series[2], as well as its essential fixes[3]. The long version is this. There's a synchronization issue with the current keypad driver and twl core; the irq is marked as handled even though the thread that is supposed to handle it hasn't run yet, and since it's clear-on-read, and it hasn't been read, it's detected again, so they keypad driver receives two interrupt callbacks instead of one, and in the second one reads nothing from the i2c register, so a key release is assumed. This makes key-presses as simple as shift+a impossible. In other words, it's totally unreliable. This might not be isolated to the keypard driver, but other nested interrupts from twl core that started using request_threaded_irq prematurely (before it was supported by the twl core). But at least I haven't tried those. This patch was applied on 2.6.33, which means all versions before 3.2 are affected, including 3.1. What do you think about fixing this on stable kernels? Cheers. [1] http://article.gmane.org/gmane.linux.kernel/932255 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/59958 [3] http://article.gmane.org/gmane.linux.ports.arm.omap/67333 -- 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] ARM: OMAP: mcbsp: Fix possible memory corruption
* Igor Grinberg grinb...@compulab.co.il [111212 03:25]: On 12/12/11 13:22, Jarkko Nikula wrote: Hi On 12/12/2011 12:23 PM, Igor Grinberg wrote: On 12/12/11 10:38, Jarkko Nikula wrote: Commits 09d28d (ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src) and 7bc0c4 (ARM: OMAP: mcbsp: Start generalize signal muxing functions) incorrectly set two struct omap_mcbsp_platform_data fields after omap_device_build_ss and kfree calls. Fix this by moving these pdata assignments before those calls. Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com Reported-by: ne...@suse.de Perhaps, should be: Reported-by: NeilBrown ne...@suse.de and Cc: sta...@vger.kernel.org [3.1] as for below. --- For 3.2, 3.1 is ok. --- No need to cc stable since the issue is not in stable kernels. Ah, so I've misunderstood what was that about... So it has been introduced in 3.2-rc cycle. Ok. Then now it is the perfect time to fix this ;) Applying into fixes. 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 1/8] omap: musb: Adding support for ti81xx
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]:
From: Ravi Babu ravib...@ti.com
Added musb support for ti81xx platform which has two instances of musb
interface and uses CPPI4.1 DMA. The current patch set adds support for
single instance and in PIO mode only.
Applying into musb branch.
Tony
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index a65145b..8bceeca 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -143,6 +143,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
if (cpu_is_omap3517() || cpu_is_omap3505()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
+ } else if (cpu_is_ti81xx()) {
+ oh_name = usb_otg_hs;
+ name = musb-ti81xx;
} else {
oh_name = usb_otg_hs;
name = musb-omap2430;
--
1.6.2.4
--
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 2/8] omap: musb: ti81xx: Add phy power function
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]: Adding ti81xx_musb_phy_power() which will be used by musb driver through its function pointer in board_data. Applying into musb branch. 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 3/8] ti816evm: Add support for musb interface
* Gupta, Ajay Kumar ajay.gu...@ti.com [111011 09:33]: Hi, Adding musb support in ti816 EVM board file. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com Acked-by: Felipe Balbi ba...@ti.com This patch can result in a merge conflict, therefore I think this one should be taken through Tony's tree. Also you should work together with Hemant Pedanekar and someone of you should rebase on top of the other otherwise one of the patches (yours or Hemant's) possibly will not apply. Ok sure. I will submit the patches (v5) after creating it on top of Hemant's and Vaibhav's patches. Here is the v5 of this patch created against latest Hemant's patch set. Applying into musb branch. 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 5/8] usb: musb: Add support for ti81xx platform
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]: From: Ravi Babu ravib...@ti.com TI81XX platform has two musb interfaces and uses CPPI4.1 DMA engine. It has builtin USB PHYs as AM35x. The current set of patches adds support for one instance and only in PIO mode. This one should get queued by Felipe via the USB tree. Tony Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com --- Same as v3. dropping plat/usb.h will be done in a seperate patch as discussed in the list. drivers/usb/musb/Kconfig |6 + drivers/usb/musb/Makefile|1 + drivers/usb/musb/musb_core.c |4 +- drivers/usb/musb/musb_dsps.c | 693 ++ 4 files changed, 703 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/musb_dsps.c diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index fc34b8b..d6abdec 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -8,6 +8,7 @@ config USB_MUSB_HDRC depends on USB USB_GADGET depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if SOC_OMAPTI81XX select TWL4030_USB if MACH_OMAP_3430SDP select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA select USB_OTG_UTILS @@ -54,6 +55,10 @@ config USB_MUSB_AM35X tristate AM35x depends on ARCH_OMAP +config USB_MUSB_DSPS + tristate TI DSPS platforms + depends on SOC_OMAPTI81XX + config USB_MUSB_BLACKFIN tristate Blackfin depends on (BF54x !BF544) || (BF52x ! BF522 !BF523) @@ -68,6 +73,7 @@ config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X + default SOC_OMAPTI81XX help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index d8fd9d0..d92d110 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -13,6 +13,7 @@ musb_hdrc-$(CONFIG_DEBUG_FS)+= musb_debugfs.o # Hardware Glue Layer obj-$(CONFIG_USB_MUSB_OMAP2PLUS) += omap2430.o obj-$(CONFIG_USB_MUSB_AM35X) += am35x.o +obj-$(CONFIG_USB_MUSB_DSPS) += musb_dsps.o obj-$(CONFIG_USB_MUSB_TUSB6010) += tusb6010.o obj-$(CONFIG_USB_MUSB_DAVINCI) += davinci.o obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 20a2873..b04790d 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1014,7 +1014,9 @@ static void musb_shutdown(struct platform_device *pdev) || defined(CONFIG_USB_MUSB_OMAP2PLUS) \ || defined(CONFIG_USB_MUSB_OMAP2PLUS_MODULE)\ || defined(CONFIG_USB_MUSB_AM35X) \ - || defined(CONFIG_USB_MUSB_AM35X_MODULE) + || defined(CONFIG_USB_MUSB_AM35X_MODULE)\ + || defined(CONFIG_USB_MUSB_DSPS)\ + || defined(CONFIG_USB_MUSB_DSPS_MODULE) static ushort __initdata fifo_mode = 4; #elif defined(CONFIG_USB_MUSB_UX500) \ || defined(CONFIG_USB_MUSB_UX500_MODULE) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c new file mode 100644 index 000..fb59e34 --- /dev/null +++ b/drivers/usb/musb/musb_dsps.c @@ -0,0 +1,693 @@ +/* + * Texas Instruments DSPS platforms glue layer + * + * Copyright (C) 2011, by Texas Instruments + * + * Based on the am35x glue layer code. + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux 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. + * + * The Inventra Controller Driver for Linux 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 The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + * musb_dsps.c will be a common file for all the TI DSPS platforms + * such as dm64x, dm36x, dm35x, da8x, am35x and ti81x. + * For now only ti81x is using this and in future davinci.c, am35x.c + * da8xx.c would be merged to this file after testing. + */ + +#include linux/init.h +#include linux/io.h +#include
Re: [PATCH 6/8] am335xevm: Add support for musb interface
* Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]: Adding musb support in am335x EVM board file. These last two patches are pending on the machine_id change for the board file. 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 5/8] usb: musb: Add support for ti81xx platform
On Mon, Dec 12, 2011 at 10:49:01AM -0800, Tony Lindgren wrote: * Ajay Kumar Gupta ajay.gu...@ti.com [111011 03:53]: From: Ravi Babu ravib...@ti.com TI81XX platform has two musb interfaces and uses CPPI4.1 DMA engine. It has builtin USB PHYs as AM35x. The current set of patches adds support for one instance and only in PIO mode. This one should get queued by Felipe via the USB tree. Yeah, I was mostly waiting until you applied your part so we wouldn't have a file without a user in the tree ;-) Let's just refresh this one a bit and add devicetree match table so it's ready for the long run -- balbi signature.asc Description: Digital signature
Re: Interrupt issue in twl4030_keypad
Hi, On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote: The short version is this: either we revert this patch[1], or we apply this patch series[2], as well as its essential fixes[3]. The long version is this. There's a synchronization issue with the current keypad driver and twl core; the irq is marked as handled even though the thread that is supposed to handle it hasn't run yet, and since it's clear-on-read, and it hasn't been read, it's detected again, so they keypad driver receives two interrupt callbacks instead of one, and in the second one reads nothing from the i2c register, so a key release is assumed. This makes key-presses as simple as shift+a impossible. In other words, it's totally unreliable. This might not be isolated to the keypard driver, but other nested interrupts from twl core that started using request_threaded_irq prematurely (before it was supported by the twl core). But at least I haven't tried those. This patch was applied on 2.6.33, which means all versions before 3.2 are affected, including 3.1. What do you think about fixing this on stable kernels? I believe Samuel has already applied those to the MFD tree. The funny part is that those patches were pending on linux-omap for over 2 months I have refreshed them over and over again and asked for help from other people to test. Everything went smooth on my simple beagle board with no keypad and I couldn't see any issues, unfortunately. Still, 2 months is a whole lot of time to NAK a patch, but nobody said anything so, of course, Samuel assumed it was ok and, like I said above, it worked for my simple GPIO usecase with beagleboard. Oh well, it won't change anything now, Sam has applied Neil's fixes. -- balbi signature.asc Description: Digital signature
Re: Interrupt issue in twl4030_keypad
On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote: Hi, The short version is this: either we revert this patch[1], or we apply this patch series[2], as well as its essential fixes[3]. The long version is this. There's a synchronization issue with the current keypad driver and twl core; the irq is marked as handled even though the thread that is supposed to handle it hasn't run yet, and since it's clear-on-read, and it hasn't been read, it's detected again, so they keypad driver receives two interrupt callbacks instead of one, and in the second one reads nothing from the i2c register, so a key release is assumed. This makes key-presses as simple as shift+a impossible. In other words, it's totally unreliable. This might not be isolated to the keypard driver, but other nested interrupts from twl core that started using request_threaded_irq prematurely (before it was supported by the twl core). But at least I haven't tried those. This patch was applied on 2.6.33, which means all versions before 3.2 are affected, including 3.1. What do you think about fixing this on stable kernels? I think you need to tell me exactly what git commit ids in Linus's tree that you want to see in the stable kernel releases, which you didn't do here :( Also, please use sta...@vger.kernel.org, sta...@kernel.org has been dead since August. 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: [PATCH] omap: rx51: initialize isp1704 properly
* Felipe Contreras felipe.contre...@gmail.com [111208 11:52]: On Thu, Dec 8, 2011 at 4:40 PM, Heikki Krogerus kro...@gmail.com wrote: On Wed, Dec 07, 2011 at 09:56:56PM +0200, Felipe Contreras wrote: From: Heikki Krogerus kro...@gmail.com I would prefer that you change this so this is from you, like it actually is. You can mention me in the commit message if you like. Well, you came with the fix, I just typed it down, but as you wish :) Without this USB networking doesn't work as the link is never detected. What this changes is, it leaves the transceiver powered by default instead of setting it into power off mode. So not only USB networking is affected by this. If isp1704_charger is not enabled with RX51, USB does not work at all. Please change the comment. I've updated the patch. Sorry what's the deal with this one? Is this the one to use or is there some other patch? 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 4/5] clk: basic gateable and fixed-rate clks
Hi Mike +int clk_register_gate(struct device *dev, const char *name, unsigned long flags, + struct clk *fixed_parent, void __iomem *reg, u8 bit_idx, +int set_to_enable) + How do you suggest handling gated clocks which are already running when calling the register function? On my kirkwood bases system, the bootloader has already turned on a number of clocks. It does not seem right to start messing with clk-enable_count and clk-prepare_count. Could clk_register_gate() have one more parameter, a bool indicating running? The kirkwood mach code keeps a bitmap of which platform_data init functions are called from the board file. In a late_initcall function it then enables and disables clocks as needed. What i was thinking is i can ask the hardware what clocks are already running before i register them and register them as running/not running. Then let the driver probe functions use the API to enable clocks which are really needed. In a late_initcall function, i would then call clk_disable(), clk_unprepare() on clocks which the boot loader started, thus turning them off if no driver has claimed them. Is this how you envisage it working? Thanks Andrew -- 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] ARM: remove header files included more than once
Hi Haojian, On Sun, Dec 11, 2011 at 7:10 PM, Haojian Zhuang haojian.zhu...@gmail.com wrote: ... Hi Omar, Thanks for your patch. Could you help to split your patches into small pieces? Since different people are handling for different files. For example, I can help to handle files in arch-pxa. But I can't handle other files. No problem, I'll split the patch to be included by independent trees. Thanks, 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: Interrupt issue in twl4030_keypad
On Mon, Dec 12, 2011 at 9:12 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote: The short version is this: either we revert this patch[1], or we apply this patch series[2], as well as its essential fixes[3]. The long version is this. There's a synchronization issue with the current keypad driver and twl core; the irq is marked as handled even though the thread that is supposed to handle it hasn't run yet, and since it's clear-on-read, and it hasn't been read, it's detected again, so they keypad driver receives two interrupt callbacks instead of one, and in the second one reads nothing from the i2c register, so a key release is assumed. This makes key-presses as simple as shift+a impossible. In other words, it's totally unreliable. This might not be isolated to the keypard driver, but other nested interrupts from twl core that started using request_threaded_irq prematurely (before it was supported by the twl core). But at least I haven't tried those. This patch was applied on 2.6.33, which means all versions before 3.2 are affected, including 3.1. What do you think about fixing this on stable kernels? I believe Samuel has already applied those to the MFD tree. Yeap, I think Linus' tree is going to be fine (3.2), but I'm trying to find out what to do with previous kernels: as in, what should be done for stable trees. The funny part is that those patches were pending on linux-omap for over 2 months I have refreshed them over and over again and asked for help from other people to test. You mean these patches? [1] There's nothing wrong with pushing them forward, but I'm actually talking about this one [2]. Everything went smooth on my simple beagle board with no keypad and I couldn't see any issues, unfortunately. That's because you didn't get a single interrupt. You could have added a BUG() on handle_twl4030_pih() and you still wouldn't have noticed anything. Still, 2 months is a whole lot of time to NAK a patch, but nobody said anything so, of course, It's actually almost 2 years :) Samuel assumed it was ok and, like I said above, it worked for my simple GPIO usecase with beagleboard. Well, for 3.2 I think the situation is fine, but that's not what I'm talking about. About your GPIO tests, are you sure you got the interrupts through twl4030 irq handling? Cheers. [1] http://article.gmane.org/gmane.linux.ports.arm.omap/59958 [2] http://article.gmane.org/gmane.linux.kernel/932255 -- 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: Interrupt issue in twl4030_keypad
On Mon, Dec 12, 2011 at 9:23 PM, Greg KH gre...@suse.de wrote: On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote: The short version is this: either we revert this patch[1], or we apply this patch series[2], as well as its essential fixes[3]. The long version is this. There's a synchronization issue with the current keypad driver and twl core; the irq is marked as handled even though the thread that is supposed to handle it hasn't run yet, and since it's clear-on-read, and it hasn't been read, it's detected again, so they keypad driver receives two interrupt callbacks instead of one, and in the second one reads nothing from the i2c register, so a key release is assumed. This makes key-presses as simple as shift+a impossible. In other words, it's totally unreliable. This might not be isolated to the keypard driver, but other nested interrupts from twl core that started using request_threaded_irq prematurely (before it was supported by the twl core). But at least I haven't tried those. This patch was applied on 2.6.33, which means all versions before 3.2 are affected, including 3.1. What do you think about fixing this on stable kernels? I think you need to tell me exactly what git commit ids in Linus's tree that you want to see in the stable kernel releases, which you didn't do here :( All right, I guess that rules out the revert option. Once Linus merges the latest fixes I can send you the commit ids, and they will work for 3.1, but I'm not sure for all the other versions since 2.6.33. The surest thing would be to just revert the patch I mentioned, which is a relatively small change compared to picking all those commits. Also, please use sta...@vger.kernel.org, sta...@kernel.org has been dead since August. Ok. -- 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 v3 4/5] clk: basic gateable and fixed-rate clks
On Mon, Dec 12, 2011 at 11:47 AM, Andrew Lunn and...@lunn.ch wrote: Hi Mike +int clk_register_gate(struct device *dev, const char *name, unsigned long flags, + struct clk *fixed_parent, void __iomem *reg, u8 bit_idx, + int set_to_enable) + How do you suggest handling gated clocks which are already running when calling the register function? On my kirkwood bases system, the bootloader has already turned on a number of clocks. It does not seem right to start messing with clk-enable_count and clk-prepare_count. Could clk_register_gate() have one more parameter, a bool indicating running? I don't like this approach. If the bool for a particular clk is statically defined then it could be wrong (bootloader/kernel mismatch). I've been thinking of adding a clk-ops-init callback in clk_init, which is defined for a platform to use however the author sees fit. There have been a few cases where it would be nice to init a clk only once, when it is registered. That code could also handle detecting if a clk is enabled or not. On the other hand we already have a .get_parent callback which is only good for figuring out which parent a mux clk is using... maybe a .is_enabled or .get_enabled would be a good idea which also served the purpose of dynamically determining whether a clk is disabled or running. In general though I think we should try to keep the solution in the core code, not by having platform code pass in a bool. The kirkwood mach code keeps a bitmap of which platform_data init functions are called from the board file. In a late_initcall function it then enables and disables clocks as needed. What i was thinking is i can ask the hardware what clocks are already running before i register them and register them as running/not running. Then let the driver probe functions use the API to enable clocks which are really needed. In a late_initcall function, i would then call clk_disable(), clk_unprepare() on clocks which the boot loader started, thus turning them off if no driver has claimed them. The problem here is that you're solving the disabled unused clks issue in platform code. I've started to lay out a little groundwork for that with a flag in struct clk: http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=include/linux/clk.h;h=3b0eb3f1caf1d6346b62c785b74a648587bfcc7f;hb=586c6e8922a889a2893ba4467bb3d13b471656a9#l35 The idea behind CLK_IGNORE_UNUSED flag on line 35 is that the common clk framework can walk the tree (probably as part of a late_initcall, as you suggested) and disable any clks that aren't already enabled and don't have this flag set. This involves zero platform-specific code, but I haven't gotten around to introducing the feature yet as I'm really trying to minimize footprint for the core code (and I'm not doing a good job of that since it keeps growing). Regards, Mike Is this how you envisage it working? Thanks Andrew -- 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: Interrupt issue in twl4030_keypad
On Mon, Dec 12, 2011 at 11:04:35PM +0200, Felipe Contreras wrote: On Mon, Dec 12, 2011 at 9:23 PM, Greg KH gre...@suse.de wrote: On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote: The short version is this: either we revert this patch[1], or we apply this patch series[2], as well as its essential fixes[3]. The long version is this. There's a synchronization issue with the current keypad driver and twl core; the irq is marked as handled even though the thread that is supposed to handle it hasn't run yet, and since it's clear-on-read, and it hasn't been read, it's detected again, so they keypad driver receives two interrupt callbacks instead of one, and in the second one reads nothing from the i2c register, so a key release is assumed. This makes key-presses as simple as shift+a impossible. In other words, it's totally unreliable. This might not be isolated to the keypard driver, but other nested interrupts from twl core that started using request_threaded_irq prematurely (before it was supported by the twl core). But at least I haven't tried those. This patch was applied on 2.6.33, which means all versions before 3.2 are affected, including 3.1. What do you think about fixing this on stable kernels? I think you need to tell me exactly what git commit ids in Linus's tree that you want to see in the stable kernel releases, which you didn't do here :( All right, I guess that rules out the revert option. Once Linus merges the latest fixes I can send you the commit ids, and they will work for 3.1, but I'm not sure for all the other versions since 2.6.33. The surest thing would be to just revert the patch I mentioned, which is a relatively small change compared to picking all those commits. Then it also needs to be reverted in Linus's tree, is it? And again, you never told me what commit id the offending patch is here, you just pointed at some random urls, and for the majority of today, I only had email access, no web access, so I have no idea what you are referring to. But, odds are, we should also just backport the needed patches from Linus's tree, please send the git commit ids of them to sta...@vger.kernel.org when they hit his tree, and the backports if needed. 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: Interrupt issue in twl4030_keypad
Hi, On Mon, Dec 12, 2011 at 10:55:11PM +0200, Felipe Contreras wrote: Samuel assumed it was ok and, like I said above, it worked for my simple GPIO usecase with beagleboard. Well, for 3.2 I think the situation is fine, but that's not what I'm talking about. About your GPIO tests, are you sure you got the interrupts through twl4030 irq handling? Card detect GPIO on beagleboard is a TWL GPIO. Checking that removing/adding the card actually triggers an IRQ, should be enough. No? -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks
I don't like this approach. If the bool for a particular clk is statically defined then it could be wrong (bootloader/kernel mismatch). I've been thinking of adding a clk-ops-init callback in clk_init, which is defined for a platform to use however the author sees fit. There have been a few cases where it would be nice to init a clk only once, when it is registered. That code could also handle detecting if a clk is enabled or not. On the other hand we already have a .get_parent callback which is only good for figuring out which parent a mux clk is using... maybe a .is_enabled or .get_enabled would be a good idea which also served the purpose of dynamically determining whether a clk is disabled or running. In general though I think we should try to keep the solution in the core code, not by having platform code pass in a bool. Hi Mike How about simply reading the bit in the control register? You are already doing a read/modify/write when enabling/disabling the clock, so it seems reasonably safe to assume the read gives you the current state. For those platforms which this does not work, you could add another flag disabling this read to get the initial state. Andrew -- 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/4] fixes for twl4030-irq in mainline
On Mon, 12 Dec 2011 18:38:19 +0100 Samuel Ortiz sa...@linux.intel.com wrote: Hi Neil, On Sun, Nov 27, 2011 at 07:17:41AM +1100, NeilBrown wrote: Hi, The recent tidying up of twl4030-irq seems to have left it broken. At least it doesn't work for me on my gta04 (www.gta04.org). The first interrupt from the device freezes the whole system (by being constantly delivered) The following 4 patches make it work for me and addresses some other less critical issues like a typo in a comment :-) Thanks, I applied all 4 of them. Thanks. I have a couple of other twl4030 patches, these ones related to battery charging. Hopefully I'll be ready to post them later this week. Would they go through you too? NeilBrown signature.asc Description: PGP signature
Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module
Hi, On 12/12/2011 10:49 AM, Ming Lei wrote: If FD result is associated with a frame, how can user space get the frame seq if no v4l2 buffer is involved? Without a frame sequence, it is a bit difficult to retrieve FD results from user space. If you pass image data in memory buffers from user space, yes, it could be impossible. It is easy to get the frame sequence from v4l2_buffer for the case too, :-) Oops, have mixed something up ;) Not really, still v4l2_buffer may be used by other (sub)driver within same video processing pipeline. OK. A related question: how can we make one application to support the two kinds of devices(input from user space data as OMAP4, input from SoC bus as Samsung) at the same time? Maybe some capability info is to be exported to user space? or other suggestions? Good question. To let applications know that a video device is not just an ordinary video output device I suppose we'll need a new object detection/recognition capability flag. V4L2_CAPS_OBJECT_DETECTION, V4L2_CAP_OBJECT_RECOGNITION or something similar. It's probably safe to assume the SoC will support either input method at time, not both simultaneously. Then it could be, for example, modelled with a video node and a subdev: user image data video capture for FDstream +-+ +-+ | /dev/video0 | | /dev/video0 | | OUTPUT| | CAPTURE| +--+--+ +--+--+ || v^ ..--++--+--+--+-+| image | link0 | pad | face | pad || sensor +---+ 0 | detector | 1 || sub-dev +---+ | | sub-dev | || ..--+| +-+--+-+| | | | +--+--++-+ | | | pad | image | pad | | +---+ 0 | processing | 1 +--+ link1 | | sub-dev| | +-++-+ User space can control state of link0. If the link is active (streaming) then access to /dev/video0 would be blocked by the driver, e.g. with EBUSY errno. This means that only one data source can be attached to an input pad (pad0). These are intrinsic properties of Media Controller/v4l2 subdev API. And will your Samsung FD HW support to detect faces from memory? or just only detect from SoC bus? I think we should be prepared for both configurations, as on a diagram above. [...] OK, I will associate FD result with frame identifier, and not invent a dedicated v4l2 event for query frame seq now until a specific requirement for it is proposed. I will convert/integrate recent discussions into patches of v2 for further Sure, sounds like a good idea. review, and sub device support will be provided. But before starting to do it, I am still not clear how to integrate FD into MC framework. I understand FD sub device is only a media entity, so how can FD sub device find the media device(struct media_device)? or just needn't to care about it now? The media device driver will register all entities that belong to it and will create relevant links between entities' pads, which then can be activated by applications. How the entities are registered is another topic, that we don't need to be concerned about at the moment. If you're curious see drivers/media/video/omap3isp or driver/media/video/s5p-fimc for example media device drivers. -- Regards, Sylwester -- 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
[GIT PULL] omap hsmmc platform code changes for v3.3 merge window
Hi Arnd Olof, Please pull omap hsmmc platform code changes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap hsmmc Ideally arch/arm/mach-omap2/hsmmc.c file will completely disappear with device tree, but looks like we're still some more patches away from that. Meanwhile, these are needed for various board files. Regards, Tony The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416: Linus Torvalds (1): Linux 3.2-rc4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap hsmmc Abhilash K V (1): ARM: OMAP: hsmmc: Support for AM3517 MMC1 voltages Eliad Peller (3): omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume ARM: OMAP: hsmmc: add pm_caps field ARM: OMAP: hsmmc: board-sdp4430: declare support for MMC_PM_KEEP_POWER Igor Grinberg (1): ARM: OMAP: hsmmc: Add support for MMC 2 setup for AM35x Thomas Weber (1): ARM: OMAP: hsmmc: Add support for non-OMAP pins Vaibhav Hiremath (1): ARM: OMAP: hsmmc: Add support for AM3517EVM base-board MMC slot arch/arm/mach-omap2/board-4430sdp.c |1 + arch/arm/mach-omap2/board-am3517evm.c | 22 arch/arm/mach-omap2/hsmmc.c | 59 arch/arm/mach-omap2/hsmmc.h |1 + arch/arm/plat-omap/include/plat/mmc.h |1 + drivers/mmc/host/omap_hsmmc.c | 26 +- 6 files changed, 86 insertions(+), 24 deletions(-) -- 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
[GIT PULL] Two non-critical DMA fixes for v3.3 merge window
Hi Arnd Olof, Please pull two non-critical DMA fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical These are workarounds for corner cases. There's no rush to get them in during the -rc cycle, these are fixes for features that never worked before. Regards, Tony The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416: Linus Torvalds (1): Linux 3.2-rc4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-non-critical Peter Ujfalusi (2): ARM: OMAP2+: DMA: Workaround for invalid source position ARM: OMAP2+: DMA: Workaround for invalid destination position arch/arm/plat-omap/dma.c | 22 +- 1 files changed, 21 insertions(+), 1 deletions(-) -- 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 1/2] ARM: OMAP: dmtimer: fix sleeping function called from invalid context
* Ramirez Luna, Omar omar.rami...@ti.com [111209 13:38]:
On Fri, Dec 9, 2011 at 3:34 PM, Tony Lindgren t...@atomide.com wrote:
+ ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
...
EXPORT_SYMBOL_GPL(omap_dm_timer_request);
This does not seem right.. It seems that you're hardcoding the source
clock to 32 KiHz clock while other sources are available too?
Agree, but... (below)
+ ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
...
And here too?
Agree but that is the default behavior set by dm timer framework:
@@ -134,22 +134,13 @@ static void omap_dm_timer_reset(struct
omap_dm_timer *timer)
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
...
- ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
...
All clocks requested are set to 32 KHz first, even with the current
approach, there exists another API to set a new source.
To be honest I don't know why the clocks are set to 32 KHz first,
maybe the default call path for users should be:
You need a functional clock for the timer registers to work
I believe.
omap_dm_timer_request
Yes this would make sense. The omap_timer_list should be protected
by a mutex. There should not be a need for spinlock there as
omap_dm_timer_request should be only called during init. If that's
not the case, the the driver using it is broken.
omap_dm_timer_set_source (new explicit call)
omap_dm_timer_start
Once the timer has been requested, there should not be a need
for locking as there should be only one timer user using the
timer specific registers.
And remove setting the source to 32 KHz by default in omap_dm_timer_request.
That you may need to be able to do anything with the timer :)
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 01/10] GPIO: gpio-generic: Move initialization up to postcore
(adding Greg Kroah-Hartman and linux-ser...@vger.kernel.org to Cc:)
On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Care to explain a bit more why you need to initialize those devices
early on?
Let me try.
From patch 2/10 ARM: OMAP1: ams-delta: Convert latches to
basic_mmio_gpio:
@@ -307,8 +487,8 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
+ platform_add_devices(_latch_devices, ARRAY_SIZE(_latch_devices));
+ BUG_ON(gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios)));
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
Here I'm accessing the latches from ams_delta_init() (.init_machine
hook) with gpio_request_array() in order to:
a) clear their contents,
b) avoid accessing them, from ams_delta_latch_write(), never requested.
I could imagine clearing their contents with something like
*(volatile __u8 *) AMS_DELTA_LATCH2_VIRT = 0;
*(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = 0;
instead, i.e., the way the old code used to, than accessing those GPIO
pins not requested, until they are finally requested by drivers updated
to use gpiolib with successive patche. Would this be acceptable?
However,
From patch 6/10 ARM: OMAP1: ams-delta: Use GPIO API in modem setup:
@@ -482,6 +472,12 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void _modem_pm(struct uart_port *port, unsigned int state, unsigned
old)
+{
+ if (state != old)
+ gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(_MODEM_VIRT),
@@ -492,6 +488,7 @@ static struct plat_serial8250_port
ams_delta_modem_ports[] = {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = _modem_pm,
},
{ },
};
@@ -504,6 +501,24 @@ static struct platform_device ams_delta_modem_device = {
},
};
+static struct gpio _modem_gpios[] __initconst = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_IRQ,
+ .flags = GPIOF_DIR_IN,
+ .label = modem_irq,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_nreset,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_codec,
+ },
+};
+
static int __init ams_delta_modem_init(void)
{
int err;
@@ -515,16 +530,11 @@ static int __init ams_delta_modem_init(void)
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
- err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, modem);
+ err = gpio_request_array(_modem_gpios, ARRAY_SIZE(_modem_gpios));
if (err) {
- pr_err(Couldn't request gpio pin for modem\n);
+ pr_err(Couldn't request gpio pins for modem\n);
return err;
}
- gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
-
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
return platform_device_register(ams_delta_modem_device);
}
Before the change, only one GPIO pin, that IRQ, driven with omap_gpio
driver which is registered from postcore, was gpio_request()ed. Now, two
more, gpio-generic driven pins, are also requested _and_ initialized in
order to make the modem accessible. The ams_delta_modem_init() is
installed with arch_initcall().
I could imagine initializing those modem pins the old way I've suggested
above, but I can see no good solution to delegate calling of that
gpio_request*() to the 8250 driver. For me, the only hook passed to the
driver with platform_data that can be suitable is the .pm hook. However,
when I tried to remove powering up the modem (rising up
AMS_DELTA_GPIO_PIN_MODEM_NRESET) from the arch init and do this only
from that .pm hook, the device was not detected, so I wonder if and when
that hook is called, and if it is before probe, then perhaps powering
up the modem chip from there is too late for the device to get up before
being examined. But then, maybe if we initialize the pin the old way
from arch init, it would be enough for the device to be
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 14:36]:
(adding Greg Kroah-Hartman and linux-ser...@vger.kernel.org to Cc:)
On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Care to explain a bit more why you need to initialize those devices
early on?
Let me try.
From patch 2/10 ARM: OMAP1: ams-delta: Convert latches to
basic_mmio_gpio:
@@ -307,8 +487,8 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
+ platform_add_devices(_latch_devices, ARRAY_SIZE(_latch_devices));
+ BUG_ON(gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios)));
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
Here I'm accessing the latches from ams_delta_init() (.init_machine
hook) with gpio_request_array() in order to:
a) clear their contents,
b) avoid accessing them, from ams_delta_latch_write(), never requested.
I could imagine clearing their contents with something like
*(volatile __u8 *) AMS_DELTA_LATCH2_VIRT = 0;
*(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = 0;
instead, i.e., the way the old code used to, than accessing those GPIO
pins not requested, until they are finally requested by drivers updated
to use gpiolib with successive patche. Would this be acceptable?
Thanks for explaining, it's best to use gpio calls instead :)
How about just add some __initcall into your board-*.c file to
do the required setups a bit later? Just make sure you exit
early if (!machine_is...) fails.
However,
From patch 6/10 ARM: OMAP1: ams-delta: Use GPIO API in modem setup:
@@ -482,6 +472,12 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void _modem_pm(struct uart_port *port, unsigned int state, unsigned
old)
+{
+ if (state != old)
+ gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(_MODEM_VIRT),
@@ -492,6 +488,7 @@ static struct plat_serial8250_port
ams_delta_modem_ports[] = {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = _modem_pm,
},
{ },
};
@@ -504,6 +501,24 @@ static struct platform_device ams_delta_modem_device =
{
},
};
+static struct gpio _modem_gpios[] __initconst = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_IRQ,
+ .flags = GPIOF_DIR_IN,
+ .label = modem_irq,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_nreset,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_codec,
+ },
+};
+
static int __init ams_delta_modem_init(void)
{
int err;
@@ -515,16 +530,11 @@ static int __init ams_delta_modem_init(void)
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
- err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, modem);
+ err = gpio_request_array(_modem_gpios, ARRAY_SIZE(_modem_gpios));
if (err) {
- pr_err(Couldn't request gpio pin for modem\n);
+ pr_err(Couldn't request gpio pins for modem\n);
return err;
}
- gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
-
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
return platform_device_register(ams_delta_modem_device);
}
Before the change, only one GPIO pin, that IRQ, driven with omap_gpio
driver which is registered from postcore, was gpio_request()ed. Now, two
more, gpio-generic driven pins, are also requested _and_ initialized in
order to make the modem accessible. The ams_delta_modem_init() is
installed with arch_initcall().
I could imagine initializing those modem pins the old way I've suggested
above, but I can see no good solution to delegate calling of that
gpio_request*() to the 8250 driver. For me, the only hook passed to the
driver with platform_data that can be suitable is the .pm hook. However,
when I tried to remove powering up the modem (rising up
AMS_DELTA_GPIO_PIN_MODEM_NRESET) from the arch init and do this only
from that .pm hook, the device was not detected,
Re: [PATCH] ARM: OMAP: McSPI: Remove unused flag from struct omap2_mcspi_device_config
* Jarkko Nikula jarkko.nik...@bitmer.com [111212 00:45]: Flag single_channel in struct omap2_mcspi_device_config is not used by drivers/spi/spi-omap2-mcspi.c so we may remove it from include/plat/mcspi.h and affected board files. Thanks applying into cleanup 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 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Thanks, Janusz -- 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 01/10] GPIO: gpio-generic: Move initialization up to postcore
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. 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 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. I think I've got it, thanks! Janusz -- 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: [PATCHv11 5/8] ARM: OMAP2+: mux: add support for PAD wakeup interrupts
* Tero Kristo t-kri...@ti.com [111212 09:44]: OMAP mux now parses active wakeup events from pad registers and calls corresponding hwmod ISRs once a wakeup is detected. This is accomplished by registering an interrupt handler for PRCM IO event, which is raised every time the HW detects wakeups. Signed-off-by: Tero Kristo t-kri...@ti.com This will need to be updated once we are using the pinctrl framework, for now this looks good to me: Acked-by: Tony Lindgren t...@atomide.com -- 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: [PATCHv11 8/8] ARM: OMAP: mux: add support for selecting mpu_irq for each wakeup pad
* Tero Kristo t-kri...@ti.com [111212 09:44]: By default all registered pads will trigger mpu_irqs[0]. Now there is an API for selecting used mpu_irq on pad basis, which can be used to trigger different irq handlers for different pads in the same hwmod. Each pad that requires its interrupt to be re-routed this way must have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq). Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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: [PATCHv11 3/8] ARM: OMAP: prm: add support for chain interrupt handler
* Tero Kristo t-kri...@ti.com [111212 09:44]: Introduce a chained interrupt handler mechanism for the PRCM interrupt, so that individual PRCM event can cleanly be handled by handlers in separate drivers. We do this by introducing PRCM event names, which are then matched to the particular PRCM interrupt bit depending on the specific OMAP SoC being used. PRCM interrupts have two priority levels, high or normal. High priority is needed for IO event handling, so that we can be sure that IO events are processed before other events. This reduces latency for IO event customers and also prevents incorrect ack sequence on OMAP3. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Avinash.H.M avinas...@ti.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Govindraj.R govindraj.r...@ti.com Assuming Paul will queue these: Acked-by: Tony Lindgren t...@atomide.com -- 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: [PATCHv11 2/8] ARM: OMAP2+: hwmod: Add API to check IO PAD wakeup status
* Tero Kristo t-kri...@ti.com [111212 09:44]: From: R, Govindraj govindraj.r...@ti.com Add API to determine IO-PAD wakeup event status for a given hwmod dynamic_mux pad. Signed-off-by: Govindraj.R govindraj.r...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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: [PATCHv11 0/8] OMAP3+: PRCM chain handler
Tero Kristo t-kri...@ti.com writes: PRCM chain handler is adding a support to the omap3+ kernel that allows different drivers to use PRCM interrupt events for their own purposes, typically this means IO wakeups. This work was attempted to integrate as its own driver at some point of the evolution of this set, however this was now postponed as the lacking support is basically blocking a few drivers. This is the version 11 of this set, now posted to linux-arm-kernel also as cc. Contains just a couple of minor changes compared to previous version proposed by Kevin Hilman. Thanks Tero for the quick update. All of this series can go through Paul, so from my side Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Kevin Hilman khil...@ti.com Kevin -- 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 1/2] ARM: OMAP: dmtimer: fix sleeping function called from invalid context
On Mon, Dec 12, 2011 at 5:08 PM, Tony Lindgren t...@atomide.com wrote:
...
@@ -134,22 +134,13 @@ static void omap_dm_timer_reset(struct
omap_dm_timer *timer)
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
...
- ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
...
All clocks requested are set to 32 KHz first, even with the current
approach, there exists another API to set a new source.
To be honest I don't know why the clocks are set to 32 KHz first,
maybe the default call path for users should be:
You need a functional clock for the timer registers to work
I believe.
Sounds logic :)
omap_dm_timer_request
Yes this would make sense. The omap_timer_list should be protected
by a mutex. There should not be a need for spinlock there as
omap_dm_timer_request should be only called during init. If that's
not the case, the the driver using it is broken.
Ok, I made this patch thinking that 'request' could be called from any
context, but if that is not the case mutex should be fine.
omap_dm_timer_set_source (new explicit call)
omap_dm_timer_start
Once the timer has been requested, there should not be a need
for locking as there should be only one timer user using the
timer specific registers.
And remove setting the source to 32 KHz by default in omap_dm_timer_request.
That you may need to be able to do anything with the timer :)
Well the intention was for the user to call it explicitly so it didn't
look as a hard coded setting, but I can keep it.
IIUC, mutex should be held instead of spin lock, I can do the change
instead of this patch and see how it goes.
Thanks,
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: [RFC PATCH v1 1/7] omap4: introduce fdif(face detect module) hwmod
Hi guys,
Gentle ping on this patch, :-)
thanks,
--
Ming Lei
On Fri, Dec 2, 2011 at 5:12 PM, Ming Lei ming@canonical.com wrote:
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 81
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6cf21ee..30db754 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -53,6 +53,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod;
static struct omap_hwmod omap44xx_dsp_hwmod;
static struct omap_hwmod omap44xx_dss_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
+static struct omap_hwmod omap44xx_fdif_hwmod;
static struct omap_hwmod omap44xx_hsi_hwmod;
static struct omap_hwmod omap44xx_ipu_hwmod;
static struct omap_hwmod omap44xx_iss_hwmod;
@@ -354,6 +355,14 @@ static struct omap_hwmod_ocp_if
omap44xx_dma_system__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* fdif - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_fdif__l3_main_2 = {
+ .master = omap44xx_fdif_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk = l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* hsi - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_hsi__l3_main_2 = {
.master = omap44xx_hsi_hwmod,
@@ -5444,6 +5453,75 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+/* 'fdif' class */
+static struct omap_hwmod_class_sysconfig omap44xx_fdif_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART),
+ .sysc_fields = omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_fdif_hwmod_class = {
+ .name = fdif,
+ .sysc = omap44xx_fdif_sysc,
+};
+
+/*fdif*/
+static struct omap_hwmod_addr_space omap44xx_fdif_addrs[] = {
+ {
+ .pa_start = 0x4a10a000,
+ .pa_end = 0x4a10afff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - fdif */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__fdif = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_fdif_hwmod,
+ .clk = l4_div_ck,
+ .addr = omap44xx_fdif_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* fdif slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_fdif_slaves[] = {
+ omap44xx_l4_cfg__fdif,
+};
+static struct omap_hwmod_irq_info omap44xx_fdif_irqs[] = {
+ { .irq = 69 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+/* fdif master ports */
+static struct omap_hwmod_ocp_if *omap44xx_fdif_masters[] = {
+ omap44xx_fdif__l3_main_2,
+};
+
+static struct omap_hwmod omap44xx_fdif_hwmod = {
+ .name = fdif,
+ .class = omap44xx_fdif_hwmod_class,
+ .clkdm_name = iss_clkdm,
+ .mpu_irqs = omap44xx_fdif_irqs,
+ .main_clk = fdif_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_CAM_FDIF_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_CAM_FDIF_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_fdif_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_fdif_slaves),
+ .masters = omap44xx_fdif_masters,
+ .masters_cnt = ARRAY_SIZE(omap44xx_fdif_masters),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5593,6 +5671,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[]
= {
omap44xx_wd_timer2_hwmod,
omap44xx_wd_timer3_hwmod,
+ /* fdif class */
+ omap44xx_fdif_hwmod,
+
NULL,
};
thanks,
--
Ming Lei
--
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:
https://docs.google.com/document/d/1-MgXERW0_TNnd0VK2caXYhDXtT58z1DJ0laAmJajrEs/edit -- 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 v1 6/7] media: video: introduce face detection driver module
Hi, On Mon, Dec 12, 2011 at 8:08 PM, HeungJun, Kim riverful@samsung.com wrote: Hi Ming, It's maybe late, but I want to suggest one thing about FD API. This OMAP FD block looks detection ability of just face. But, It's possible to occur another device which can detect specific object or patterns. Moreover, this API can expand object recognition area. So, I think it's good to change the API name like v4l2_recog. IMO, object detection is better, at least now OMAP4 and samsung has face detection IP module, and face recognition is often done on results of face detection and more complicated interfaces will be involved. Actually, I'm preparing similar control class for mainline with m5mols camera sensor driver. The m5mols camera sensor has the function about face detection. But, I has experienced about Robot Recognition, and I remember the image processing chip which can detect spefic pattern. So, I hesitated naming the API(control or ioctl whatever) with face. It can be possible to provide just object or pattern, not face. Even user library on windows, there is famous OpenCV. And this is also support not only face, but also object. Yes, object is better than face, and we can use enum flag to describe that the objects detected are which kind of objects. In fact, I plan to rename the face detection generic driver as object detection generic driver and let hardware driver to handle the object detection details. The function of OMAP FDIF looks like m5mols ISP's one. please understand I don't have experience about OMAP AP. But, I can tell you it's better to use the name object recognition, not the face detection, for any other device or driver. In a few days, I'll share the CIDs I have thought for m5mols driver. And, I hope to discuss about this with OMAP FDIF. You have been doing it already, :-) thanks, -- Ming Lei Thank you. Regards, Heungjun Kim -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Ming Lei Sent: Monday, December 12, 2011 6:50 PM To: Sylwester Nawrocki Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; linux-me...@vger.kernel.org Subject: Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module Hi, On Mon, Dec 12, 2011 at 1:43 AM, Sylwester Nawrocki snj...@gmail.com For OMAP4 FD, it is not needed to include FD into MC framework since a intermediate buffer is always required. If your HW doesn't belong to this case, what is the output of your HW FD in the link? Also sounds FD results may not be needed at all for use space application in the case. The result data is similar to OMAP4 one, plus a few other attributes. User buffers may be filled by other than FD device driver. OK. Could you provide some practical use cases about these? As above, and any device with a camera that controls something and makes decision according to presence of human face in his view. Sounds a reasonable case, :-) If FD result is associated with a frame, how can user space get the frame seq if no v4l2 buffer is involved? Without a frame sequence, it is a bit difficult to retrieve FD results from user space. If you pass image data in memory buffers from user space, yes, it could be impossible. It is easy to get the frame sequence from v4l2_buffer for the case too, :-) Not really, still v4l2_buffer may be used by other (sub)driver within same video processing pipeline. OK. A related question: how can we make one application to support the two kinds of devices(input from user space data as OMAP4, input from SoC bus as Samsung) at the same time? Maybe some capability info is to be exported to user space? or other suggestions? And will your Samsung FD HW support to detect faces from memory? or just only detect from SoC bus? It will be included in the FD result... or in a dedicated v4l2 event data structure. More important, at the end of the day, we'll be getting buffers with image data at some stage of a video pipeline, which would contain same frame identifier (I think we can ignore v4l2_buffer.field for FD purpose). OK, I will associate FD result with frame identifier, and not invent a dedicated v4l2 event for query frame seq now until a specific requirement for it is proposed. I will convert/integrate recent discussions into patches of v2 for further review, and sub device support will be provided. But before starting to do it, I am still not clear how to integrate FD into MC framework. I understand FD sub device is only a media entity, so how can FD sub device find the media device(struct media_device)? or just needn't to care about it now? thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at
RE: [RFC PATCH v1 6/7] media: video: introduce face detection driver module
Hi Ming and Sylwester, Thanks for the reply. -Original Message- From: Ming Lei [mailto:ming@canonical.com] Sent: Tuesday, December 13, 2011 1:02 PM To: HeungJun, Kim Cc: Sylwester Nawrocki; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux- me...@vger.kernel.org Subject: Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module Hi, On Mon, Dec 12, 2011 at 8:08 PM, HeungJun, Kim riverful@samsung.com wrote: Hi Ming, It's maybe late, but I want to suggest one thing about FD API. This OMAP FD block looks detection ability of just face. But, It's possible to occur another device which can detect specific object or patterns. Moreover, this API can expand object recognition area. So, I think it's good to change the API name like v4l2_recog. IMO, object detection is better, at least now OMAP4 and samsung has face detection IP module, and face recognition is often done on results of face detection and more complicated interfaces will be involved. Actually, the detection point is different, I guess. The OMAP has the detection block separately, named FDIF. But, Samsung Exynos doing detection process with externel sensor - m5mols, in our case. This sensor(m5mols) has ISP function, and these ISP can process detection. The expert of FIMC is Sylwester. Probably, he can tell the differences between both in more details. :) Actually, I'm preparing similar control class for mainline with m5mols camera sensor driver. The m5mols camera sensor has the function about face detection. But, I has experienced about Robot Recognition, and I remember the image processing chip which can detect spefic pattern. So, I hesitated naming the API(control or ioctl whatever) with face. It can be possible to provide just object or pattern, not face. Even user library on windows, there is famous OpenCV. And this is also support not only face, but also object. Yes, object is better than face, and we can use enum flag to describe that the objects detected are which kind of objects. In fact, I plan to rename the face detection generic driver as object detection generic driver and let hardware driver to handle the object detection details. The function of OMAP FDIF looks like m5mols ISP's one. please understand I don't have experience about OMAP AP. But, I can tell you it's better to use the name object recognition, not the face detection, for any other device or driver. In a few days, I'll share the CIDs I have thought for m5mols driver. And, I hope to discuss about this with OMAP FDIF. You have been doing it already, :-) Yeah, actually I did. :) But, until I see OMAP FDIF case, I did not recognize AP(like OMAP) can have detection capability. :) So, although I did not think about at that time, I also think we should re-consider this case for now. As I look around your patch quickly, the functions is very similar with ours. (even detection of left/right eye) So, the problem is there are two ways to proceed recognition. - Does it handle at the level of IOCTLs? or CIDs? If the detection algorithm is proceeded at the level of HW block, it's right the platform driver provide APIs as IOCTLs(as you're FDIF patches). On the other hand, if it is proceeded at the sensor(subdevice) level, I think it's more right to control using CIDs. We need the solution including those two cases. And the name - object detection? object recognition? So, do you have any good ideas? ps. There can be another not-matched HW block level issues. But, the problem which I can check is just above issue for now. Thanks, Heungjun Kim thanks, -- Ming Lei Thank you. Regards, Heungjun Kim -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Ming Lei Sent: Monday, December 12, 2011 6:50 PM To: Sylwester Nawrocki Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; linux-me...@vger.kernel.org Subject: Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module Hi, On Mon, Dec 12, 2011 at 1:43 AM, Sylwester Nawrocki snj...@gmail.com For OMAP4 FD, it is not needed to include FD into MC framework since a intermediate buffer is always required. If your HW doesn't belong to this case, what is the output of your HW FD in the link? Also sounds FD results may not be needed at all for use space application in the case. The result data is similar to OMAP4 one, plus a few other attributes. User buffers may be filled by other than FD device driver. OK. Could you provide some practical use cases about these? As above, and any device with a camera that controls something and makes decision according to presence of human face in his view. Sounds a reasonable case, :-) If FD result is
[PATCH 1/2] OMAPDSS: HDMI: Move duplicate code from boardfile
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
arch/arm/mach-omap2/display.c | 23 +++
include/video/omapdss.h|2 ++
4 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73b1e99..c3bd640 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -595,20 +595,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static void sdp4430_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
@@ -838,9 +824,9 @@ static void omap_4430sdp_display_init(void)
pr_err(%s: Could not get display_sel GPIO\n, __func__);
sdp4430_lcd_init();
- sdp4430_hdmi_mux_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
+ omap_hdmi_init();
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a5b576b..d95df2e 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -478,21 +478,6 @@ int __init omap4_panda_dvi_init(void)
return r;
}
-
-static void omap4_panda_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
@@ -555,8 +540,8 @@ void omap4_panda_display_init(void)
if (r)
pr_err(error initializing panda DVI\n);
- omap4_panda_hdmi_mux_init();
omap_display_init(omap4_panda_dss_data);
+ omap_hdmi_init();
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index dce9905..8436088 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -29,6 +29,7 @@
#include plat/omap-pm.h
#include plat/common.h
+#include mux.h
#include control.h
#include display.h
@@ -96,6 +97,20 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static void omap4_hdmi_mux_pads()
+{
+ /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
+ omap_mux_init_signal(hdmi_hpd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_cec,
+ OMAP_PIN_INPUT_PULLUP);
+ /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
+ omap_mux_init_signal(hdmi_ddc_scl,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_ddc_sda,
+ OMAP_PIN_INPUT_PULLUP);
+}
+
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift;
@@ -129,6 +144,14 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
+int omap_hdmi_init(void)
+{
+ if (cpu_is_omap44xx())
+ omap4_hdmi_mux_pads();
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
if (cpu_is_omap44xx())
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 378c7ed..0cb0469 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -309,6 +309,8 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+/* HDMI mux init*/
+extern int omap_hdmi_init(void);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe
[PATCH 2/2] OMAPDSS: HDMI: Disable DDC internal pull up
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are expernal pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 13 -
arch/arm/mach-omap2/board-omap4panda.c | 14 +-
arch/arm/mach-omap2/display.c | 17 ++---
include/video/omapdss.h|4 +++-
4 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c3bd640..1b7c5e5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -826,7 +826,18 @@ static void omap_4430sdp_display_init(void)
sdp4430_lcd_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
- omap_hdmi_init();
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor - This is a change needed in
+* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze Boards as the
+* external pull up are present. This is needed to avoid
+* EDID read failure.
+*/
+ if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2))
+ omap_hdmi_init(OMAP_HDMI_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d95df2e..212e06c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -541,7 +541,19 @@ void omap4_panda_display_init(void)
pr_err(error initializing panda DVI\n);
omap_display_init(omap4_panda_dss_data);
- omap_hdmi_init();
+
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor - This is a change needed in
+* OMAP4460 Panda and OMAP4430 ES2.3 Panda Boards as the
+* external pull up are present. This is needed to avoid
+* EDID read failure.
+*/
+ if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2))
+ omap_hdmi_init(OMAP_HDMI_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 8436088..a75e179 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -97,8 +97,11 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
-static void omap4_hdmi_mux_pads()
+static void omap4_hdmi_mux_pads(int flags)
{
+ u32 reg;
+ u16 control_i2c_1;
+
/* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
omap_mux_init_signal(hdmi_hpd,
OMAP_PIN_INPUT_PULLUP);
@@ -109,6 +112,14 @@ static void omap4_hdmi_mux_pads()
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
OMAP_PIN_INPUT_PULLUP);
+
+ if (flags OMAP_HDMI_EXTERNAL_PULLUP) {
+ control_i2c_1 = OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_1;
+ reg = omap4_ctrl_pad_readl(control_i2c_1);
+ reg |= (OMAP4_HDMI_DDC_SDA_PULLUPRESX_MASK |
+ OMAP4_HDMI_DDC_SCL_PULLUPRESX_MASK);
+ omap4_ctrl_pad_writel(reg, control_i2c_1);
+ }
}
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
@@ -144,10 +155,10 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
-int omap_hdmi_init(void)
+int omap_hdmi_init(int flags)
{
if (cpu_is_omap44xx())
- omap4_hdmi_mux_pads();
+ omap4_hdmi_mux_pads(flags);
return 0;
}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 0cb0469..df585b5 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -49,6 +49,8 @@
#define DISPC_IRQ_FRAMEDONETV (1 24)
#define DISPC_IRQ_WBBUFFEROVERFLOW (1 25)
+#define OMAP_HDMI_EXTERNAL_PULLUP 0x1
+
struct omap_dss_device;
struct omap_overlay_manager;
@@ -310,7 +312,7 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
/* HDMI mux init*/
-extern int omap_hdmi_init(void);
+extern int omap_hdmi_init(int flags);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module
On Tue, Dec 13, 2011 at 1:59 PM, HeungJun, Kim riverful@samsung.com wrote: Hi Ming and Sylwester, Thanks for the reply. -Original Message- From: Ming Lei [mailto:ming@canonical.com] Sent: Tuesday, December 13, 2011 1:02 PM To: HeungJun, Kim Cc: Sylwester Nawrocki; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux- me...@vger.kernel.org Subject: Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module Hi, On Mon, Dec 12, 2011 at 8:08 PM, HeungJun, Kim riverful@samsung.com wrote: Hi Ming, It's maybe late, but I want to suggest one thing about FD API. This OMAP FD block looks detection ability of just face. But, It's possible to occur another device which can detect specific object or patterns. Moreover, this API can expand object recognition area. So, I think it's good to change the API name like v4l2_recog. IMO, object detection is better, at least now OMAP4 and samsung has face detection IP module, and face recognition is often done on results of face detection and more complicated interfaces will be involved. Actually, the detection point is different, I guess. The OMAP has the detection block separately, named FDIF. But, Samsung Exynos doing detection process with externel sensor - m5mols, in our case. This sensor(m5mols) has ISP function, and these ISP can process detection. The expert of FIMC is Sylwester. Probably, he can tell the differences between both in more details. :) Actually, I'm preparing similar control class for mainline with m5mols camera sensor driver. The m5mols camera sensor has the function about face detection. But, I has experienced about Robot Recognition, and I remember the image processing chip which can detect spefic pattern. So, I hesitated naming the API(control or ioctl whatever) with face. It can be possible to provide just object or pattern, not face. Even user library on windows, there is famous OpenCV. And this is also support not only face, but also object. Yes, object is better than face, and we can use enum flag to describe that the objects detected are which kind of objects. In fact, I plan to rename the face detection generic driver as object detection generic driver and let hardware driver to handle the object detection details. The function of OMAP FDIF looks like m5mols ISP's one. please understand I don't have experience about OMAP AP. But, I can tell you it's better to use the name object recognition, not the face detection, for any other device or driver. In a few days, I'll share the CIDs I have thought for m5mols driver. And, I hope to discuss about this with OMAP FDIF. You have been doing it already, :-) Yeah, actually I did. :) But, until I see OMAP FDIF case, I did not recognize AP(like OMAP) can have detection capability. :) So, although I did not think about at that time, I also think we should re-consider this case for now. As I look around your patch quickly, the functions is very similar with ours. (even detection of left/right eye) So, the problem is there are two ways to proceed recognition. - Does it handle at the level of IOCTLs? or CIDs? The patch introduces two IOCTL to retrieve object detection result. I think it should be handled by IOCTL. The interface is a little complex, so it is not easy to handle it by CIDs, IMO. If the detection algorithm is proceeded at the level of HW block, it's right the platform driver provide APIs as IOCTLs(as you're FDIF patches). On the other hand, if it is proceeded at the sensor(subdevice) level, I think it's more right to control using CIDs. Certainly, some generic CIDs for object detection will be introduced later and will be handled in the object detection(the current fdif generic driver, patch 6/7) generic driver. We need the solution including those two cases. And the name - object detection? object recognition? I think object detection is better. For example, face detection is very different with face recognition, isn't it? thanks, -- Ming Lei So, do you have any good ideas? ps. There can be another not-matched HW block level issues. But, the problem which I can check is just above issue for now. Thanks, Heungjun Kim thanks, -- Ming Lei Thank you. Regards, Heungjun Kim -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Ming Lei Sent: Monday, December 12, 2011 6:50 PM To: Sylwester Nawrocki Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; linux-me...@vger.kernel.org Subject: Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module Hi, On Mon, Dec 12, 2011 at 1:43 AM, Sylwester Nawrocki snj...@gmail.com For OMAP4 FD, it is not needed to include FD into MC framework since a intermediate buffer is
Re: [PATCHv7 5/7] mfd: twl-core: pass driver data from pdata to add_regulator for VDD1 and VDD2
On Mon, 2011-12-12 at 19:04 +0100, Samuel Ortiz wrote: Hi Tero, On Mon, Nov 28, 2011 at 04:53:23PM +0200, Tero Kristo wrote: This way, we can add custom flags for VDD1 and VDD2 regulators that get passed all the way to regulator init. This is needed for SMPS regulator support to select used controller mode for these regulators (either voltage processor or default.) Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/twl-core.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 01ecfee..af93fce 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -846,12 +846,14 @@ add_children(struct twl4030_platform_data *pdata, unsigned long features) return PTR_ERR(child); child = add_regulator(TWL4030_REG_VDD1, pdata-vdd1, - features); + features | + (u32)pdata-vdd1-driver_data); That looks hackish to me. Do you have any guarantee that your driver_data and your features bitmaps have zero intersections ? That is somewhat hackish yes. I changed the implementation a bit for v8 (which you should also have in your inbox now, I sent it out on Friday), I split the driver_data to a struct that contains a couple of function pointers and the features flag. It is still using a bitwise OR for setting the flags inside twl-core.c, but the entity that initializes the driver_data sets the features always at zero, so twl-core is the only one who sets these. That version of the patch could be changed from twl-core point of view to just set the features field instead of OR. v8 of the patch set actually merges the regulator driver and the twl-core data passing parts together to avoid merge conflicts, so you should take a look at the twl-core.c / include/linux/i2c/twl.h part of patch: [PATCHv8 4/5] twl4030: add support for external voltage get/set -Tero -- 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
