Re: usb_nop_xceiv_register() missing when OTG built as modules
Hi,
On Sun, May 23, 2010 at 01:53:10AM +0200, ext Amit Kucheria wrote:
From 3df714f995b0895e905090760482194233f66a1d Mon Sep 17 00:00:00 2001
Message-Id:
3df714f995b0895e905090760482194233f66a1d.1274570700.git.amit.kuche...@canonical.com
From: Amit Kucheria amit.kuche...@canonical.com
Date: Sun, 23 May 2010 01:35:00 +0300
Subject: [PATCH] omap: remove calls to usb_nop_xceiv_register from board files
This will allow the OMAP USB drivers to be compiled in as modules. At the
moment, CONFIG_NOP_USB_XCEIV cannot be a module.
Signed-off-by: Amit Kucheria amit.kuche...@canonical.com
---
arch/arm/mach-omap2/board-4430sdp.c | 10 --
arch/arm/mach-omap2/board-omap3evm.c | 11 ---
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index e4a5d66..131f0fd 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -110,8 +110,16 @@ static struct platform_device sdp4430_lcd_device = {
.id = -1,
};
+static struct platform_device sdp4430_nop_usb_device = {
+ .name = nop_usb_xceiv,
+ .id = -1,
+ .resource = NULL,
+ .num_resources = 0,
you don't need to zero-initialize a static variable. So you can just
drop .resource and .num_resources altogether.
--
balbi
DefectiveByDesign.org
--
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: usb_nop_xceiv_register() missing when OTG built as modules
Hi, On Mon, May 24, 2010 at 09:07:37AM +0200, ext Gupta, Ajay Kumar wrote: Attempting to remove usb_nop_xceiv_register() completely will require someone with more knowledge of davinci and blackfin archs to comment on what boards need the platform_device defined. NAK.. This is an incorrect fix as it duplicates the code snippet which is already present in nop file. I don't believe you understood the purpose of the original patch: I did and that's why an alternative patch. The idea is that currently, it's impossible to build a board which uses nop transceiver and have that be a module because when you'll have an undefined function being used on a board file. I know. Removing the call to nop_xceiv_register() and using a platform_device_register() is the way to go, since it's only 4 ~ 5 lines of code anyway. 4 ~5 lines would keep on repeating for all current and future boards requiring to use NOP. ps: you really think that adding more and more ifdefs is better than Amit's patch ?? Yes, when compared to the approach of repeating those 4 ~5 line in all the board files requiring NOP. -Ajay -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Add support for TMP105
On Tue, 25 May 2010 13:21:27 +0100, Jonathan Cameron wrote:
On 05/25/10 13:12, Datta, Shubhrajyoti wrote:
Adds the driver support for the TMP105 temperature sensor device. The
interface is I2C.The driver supports the read of the temperature values.
Still on the wrong list... cc'ing lm-sensors...
Please check MAINTAINERS for the correct mailing list for patches.
Please re-send this patch to me and the lm-sensors list. Otherwise I
can't apply it.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Jonathan Cameron ji...@cam.ac.uk
---
drivers/hwmon/Kconfig |3 ++-
drivers/hwmon/lm75.c |2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index a4a5352..7a137d5 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -483,7 +483,8 @@ config SENSORS_LM75
- NXP's LM75A
- ST Microelectronics STDS75
- TelCom (now Microchip) TCN75
- - Texas Instruments TMP100, TMP101, TMP75, TMP175, TMP275
+ - Texas Instruments TMP100, TMP101, TMP105, TMP75, TMP175,
+ TMP275
This driver supports driver model based binding through board
specific I2C device tables.
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 8ae2cfe..5646342 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -46,6 +46,7 @@ enum lm75_type { /* keep sorted in alphabetical
order */
tcn75,
tmp100,
tmp101,
+ tmp105,
tmp175,
tmp275,
tmp75,
@@ -220,6 +221,7 @@ static const struct i2c_device_id lm75_ids[] = {
{ tcn75, tcn75, },
{ tmp100, tmp100, },
{ tmp101, tmp101, },
+ { tmp105, tmp105, },
{ tmp175, tmp175, },
{ tmp275, tmp275, },
{ tmp75, tmp75, },
--
Jean Delvare
--
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: usb_nop_xceiv_register() missing when OTG built as modules
ps: you really think that adding more and more ifdefs is better than
Amit's patch ??
We can avoid using #ifdefs by introducing '.neednop' flag to board_data.
Here is the patch for this which can be used on top of my earlier patch.
--- cut here ---
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 77af4c9..fb29837 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -137,6 +137,7 @@ static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
.mode = MUSB_PERIPHERAL,
.power = 100,
+ .neednop= 1,
};
static struct omap2_hsmmc_info mmc[] = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 83d3aa5..609f021 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -665,6 +665,7 @@ static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 100,
+ .neednop= 1,
};
static void __init omap3_evm_init(void)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index a32d3af..b53489a 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -69,6 +69,7 @@ struct omap_musb_board_data {
u8 mode;
u16 power;
unsigned extvbus:1;
+ unsigned neednop:1; /* NOP transceiver */
};
enum musb_interface{MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index e71049c..b774312 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1964,6 +1964,7 @@ bad_config:
musb-board_set_power = plat-set_power;
musb-set_clock = plat-set_clock;
musb-min_power = plat-min_power;
+ musb-board_data = plat-board_data;
/* Clock usage is chip-specific ... functional clock (DaVinci,
* OMAP2430), or PHY ref (some TUSB6010 boards). All this core
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index eaabf98..b72e2e5 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -392,6 +392,7 @@ struct musb {
int (*board_set_power)(int state);
int (*set_clock)(struct clk *clk, int is_active);
+ void*board_data;
u8 min_power; /* vbus for periph, in mA/2 */
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 58acd0c..8488a23 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -198,12 +198,11 @@ int __init musb_platform_init(struct musb *musb, void
*board_data)
omap_cfg_reg(AE5_2430_USB0HS_STP);
#endif
-#if defined(CONFIG_MACH_OMAP3EVM) || defined(CONFIG_MACH_OMAP_4430SDP)
/* OMAP3EVM used ISP150x and OMAP4 SDP uses internal transceiver
* so register nop transceiver
*/
- usb_nop_xceiv_register();
-#endif
+ if (data-neednop)
+ usb_nop_xceiv_register();
/* We require some kind of external transceiver, hooked
* up through ULPI. TWL4030-family PMICs include one,
@@ -330,10 +329,10 @@ static int musb_platform_resume(struct musb *musb)
int musb_platform_exit(struct musb *musb)
{
+ struct omap_musb_board_data *data = musb-board_data;
musb_platform_suspend(musb);
-#if defined(CONFIG_MACH_OMAP3EVM) || defined(CONFIG_MACH_OMAP_4430SDP)
- usb_nop_xceiv_unregister();
-#endif
+ if (data-neednop)
+ usb_nop_xceiv_unregister();
return 0;
}
-Ajay
--
balbi
DefectiveByDesign.org
--
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 PATCHv2 2/7] OMAP SSI: Introducing OMAP SSI driver
On Tue, 2010-05-18 at 16:05 +0200, ext Sebastien Jan wrote: On Tuesday 18 May 2010 11:07:20 Carlos Chinea wrote: [cut] + val |= __raw_readl(omap_ssi-sys + SSI_MPU_ENABLE_REG(port-num, 0)); + __raw_writel(val, omap_ssi-sys + SSI_MPU_ENABLE_REG(port-num, 0)); + + msg-status = HSI_STATUS_COMPLETED; + msg-actual_len = sg_dma_len(msg-sgt.sgl); + spin_unlock(omap_ssi-lock); +} Don't you need to check the queue related to this transfer at this point, to start the potentially next queued transfer on the same channel? (calling ssi_start_transfer(), like in ssi_pio_complete()?) No this is done in ssi_pio_complete(). Notice that we do not call the complete callback at any point here. We just arm the pio interrupt for that channel and transfer direction. AFAIK, this is the SW logic expected by the OMAP SSI HW. Ok, though I would not expect the interrupt to fire in an Rx scenario as the fifo would have already been emptied by the DMA for this transfer (unless you rely on the next transfer initiated by the peer to make the Rx interrupt fire on this channel?)? No I do not rely on the next RX transfer. I rely on the fact that the GDD(DMA) controller does not reset the RX status bit for that channel when RX transfer is finished. Br, -- Carlos Chinea carlos.chi...@nokia.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
[PATCH 0/3] omap: rx51: board-rx51-peripherals.c updates
Hi There are now required sound/soc/ patches in mainline and linux-omap to get basic Nokia N900 audio working. Patch 1/3 is continuation to earlier set, see http://marc.info/?l=linux-omapm=127306914008392w=2 IMO, it should go for 2.6.35 as it's kind of fix for unworking audio due codec being in unknown reset state. Patches 2-3/3 are posted earlier but now based on top 1/3 since it has priority over them. Patches 2/3/3 are not important for 2.6.35 but they are preparation for 2.6.36 and must hit the mainline before adding headphone support to sound/soc/omap/rx51.c. -- 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
[PATCH 1/3] omap: rx51: Add platform_data for tlv320aic3x with reset gpio number
Proper operation of the tlv320aic3x audio codec requires that reset
sequencing is done in pair with supply voltages when using the regulator
framework. Add the codec reset gpio used in Nokia RX51 to tlv320aic3x
data.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index abdf321..7a604e0 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -33,6 +33,8 @@
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include sound/tlv320aic3x.h
+
#include mux.h
#include hsmmc.h
@@ -707,6 +709,10 @@ static struct twl4030_platform_data rx51_twldata
__initdata = {
.vio= rx51_vio,
};
+static struct aic3x_pdata rx51_aic3x_data __initdata = {
+ .gpio_reset = 60,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_1[] = {
{
I2C_BOARD_INFO(twl5030, 0x48),
@@ -719,6 +725,7 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
+ .platform_data = rx51_aic3x_data,
},
};
--
1.7.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
[PATCHv3 2/3] omap: rx51: Use REGULATOR_SUPPLY macro when initializing regulator consumers
There is REGULATOR_SUPPLY macro available for initializing the struct
regulator_consumer_supply so use it where applicable (all other supplies
than vdds_sdi) as it improves the readability.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v3:
No functional changes. Rebased on top of 1/3.
v2:
No functional changes but short description added, rebased on top of 7b93a0d
and added Eduardo's ack to v1.
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 43 ++---
1 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 7a604e0..0f9d2e9 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -302,48 +302,27 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct regulator_consumer_supply rx51_vmmc1_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.0,
-};
+static struct regulator_consumer_supply rx51_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
-static struct regulator_consumer_supply rx51_vaux3_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vaux3_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
-static struct regulator_consumer_supply rx51_vsim_supply = {
- .supply = vmmc_aux,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vsim_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
- {
- .supply = AVDD,
- .dev_name = 2-0018,
- },
- {
- .supply = DRVDD,
- .dev_name = 2-0018,
- },
+ REGULATOR_SUPPLY(AVDD, 2-0018),
+ REGULATOR_SUPPLY(DRVDD, 2-0018),
/* Keep vmmc as last item. It is not iterated for newer boards */
- {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
- },
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
static struct regulator_consumer_supply rx51_vio_supplies[] = {
/* tlv320aic3x digital supplies */
- {
- .supply = IOVDD,
- .dev_name = 2-0018
- },
- {
- .supply = DVDD,
- .dev_name = 2-0018
- },
+ REGULATOR_SUPPLY(IOVDD, 2-0018),
+ REGULATOR_SUPPLY(DVDD, 2-0018),
};
#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
--
1.7.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
[PATCHv3 3/3] omap: rx51: Add supply and data for the tpa6130a2 headphone amplifier
With these and upcoming change to tpa6130a2 driver it's possible to add
support for the TPA6130A2 headphone amplifier.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
v3:
- No functional changes. Rebased on top of 1/3.
v2:
- Rebased on top of 7b93a0d
- Only Vdd supply added as the CPVSS turned out to be miss defined in
tpa6130a2. Thanks to Eduardo Valentin eduardo.valen...@nokia.com for
noticing.
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 0f9d2e9..87e00b8 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,6 +34,7 @@
#include plat/gpmc-smc91x.h
#include sound/tlv320aic3x.h
+#include sound/tpa6130a2-plat.h
#include mux.h
#include hsmmc.h
@@ -315,6 +316,8 @@ static struct regulator_consumer_supply
rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
REGULATOR_SUPPLY(AVDD, 2-0018),
REGULATOR_SUPPLY(DRVDD, 2-0018),
+ /* tpa6130a2 */
+ REGULATOR_SUPPLY(Vdd, 2-0060),
/* Keep vmmc as last item. It is not iterated for newer boards */
REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
@@ -692,6 +695,11 @@ static struct aic3x_pdata rx51_aic3x_data __initdata = {
.gpio_reset = 60,
};
+static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = {
+ .id = TPA6130A2,
+ .power_gpio = 98,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_1[] = {
{
I2C_BOARD_INFO(twl5030, 0x48),
@@ -706,6 +714,10 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
I2C_BOARD_INFO(tlv320aic3x, 0x18),
.platform_data = rx51_aic3x_data,
},
+ {
+ I2C_BOARD_INFO(tpa6130a2, 0x60),
+ .platform_data = rx51_tpa6130a2_data,
+ }
};
static int __init rx51_i2c_init(void)
--
1.7.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: [RFC] Initial attempt to make ARM use LMB
On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote: So, below is a patch to sanitize the code in arch/arm/plat-omap/fb.c. The logic in this file is rather convoluted, but essentially: I've tried the patch below with the patches from your lmb branch up to this one and I can see tux on my osk5912 and n900: Acked-by: Tony Lindgren t...@atomide.com Interesting patch name! After applying the next patch in your lmb branch ARM: OMAP: Convert to use -reserve method to reserve boot time memory tux still works on 5912osk, but not on n900. The difference is that osk5912 uses the old omapfb code. I guess this is because I don't have board-n900.c in my tree. All OMAP boards need a .reserve = omap_reserve, line added in their machine descriptor. I just noticed that board-n8x0.c contains more than one machine descriptor, which I've now fixed up. Then, looks like reordering of the patches now causes patch ARM: initial LMB trial to fail with: arch/arm/mm/init.c:301: error: conflicting types for 'bootmem_init' arch/arm/mm/mm.h:32: error: previous declaration of 'bootmem_init' was here arch/arm/mm/init.c: In function 'bootmem_init': arch/arm/mm/init.c:312: error: 'mdesc' undeclared (first use in this function) arch/arm/mm/init.c:312: error: (Each undeclared identifier is reported only once arch/arm/mm/init.c:312: error: for each function it appears in.) make[1]: *** [arch/arm/mm/init.o] Error 1 Now fixed, thanks. Also, the last patch in lmb branch ARM: use LMB to allocate system memory MMIO resource structures causes both osk5912 and n900 to hang very early. Maybe I'm missing some patch again.. Hmm, I'll take a look later today. Anyways, I've picked the patches from lmb branch up to the one below into omap-testing. Will add more of them once we get them working. You should now be able to pick all but the last patch. -- 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
omapfb problem (omapfb: irq error status 4020)
Hi, I have taken latest Linux Kernel for beagle board (C3). I tried my image in that board. But getting omapfb error. DISPC version 3.0 initialized omapfb: irq error status 4020 ... I feel this is known issue. Could you please reply whats need to be done. Regards, -S -- 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 V2] misc : ROHM BH1780GLI Ambient light sensor Driver
From: Hemanth V heman...@ti.com
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports read/update of power state and
read of lux value (through SYSFS). Writing value 3 to power_state enables the
sensor and current lux value could be read.
Jonathan, Daniel
If there are no more comments, do you know howto push this to linus tree.
Thanks
Hemanth
Signed-off-by: Hemanth V heman...@ti.com
Reviewed-by: Daniel Mack dan...@caiaq.de
Acked-by: Jonathan Cameron ji...@cam.ac.uk
---
drivers/misc/Kconfig | 10 ++
drivers/misc/Makefile|1 +
drivers/misc/bh1780gli.c | 273
++
3 files changed, 284 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/bh1780gli.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0d0d625..3f5bf0f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -278,6 +278,16 @@ config SENSORS_TSL2550
This driver can also be built as a module. If so, the module
will be called tsl2550.
+config SENSORS_BH1780
+ tristate ROHM BH1780GLI ambient light sensor
+ depends on I2C SYSFS
+ help
+ If you say yes here you get support for the ROHM BH1780GLI
+ ambient light sensor.
+
+ This driver can also be built as a module. If so, the module
+ will be called bh1780gli.
+
config EP93XX_PWM
tristate EP93xx PWM support
depends on ARCH_EP93XX
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7b6f7ee..c479d91 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/
obj-y+= eeprom/
obj-y+= cb710/
obj-$(CONFIG_VMWARE_BALLOON) += vmware_balloon.o
+obj-$(CONFIG_SENSORS_BH1780) += bh1780gli.o
diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
new file mode 100644
index 000..774531d
--- /dev/null
+++ b/drivers/misc/bh1780gli.c
@@ -0,0 +1,273 @@
+/*
+ * bh1780gli.c
+ * ROHM Ambient Light Sensor Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V heman...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/platform_device.h
+#include linux/delay.h
+
+#define BH1780_REG_CONTROL 0x80
+#define BH1780_REG_PARTID0x8A
+#define BH1780_REG_MANFID0x8B
+#define BH1780_REG_DLOW 0x8C
+#define BH1780_REG_DHIGH 0x8D
+
+#define BH1780_REVMASK (0xf)
+#define BH1780_POWMASK (0x3)
+#define BH1780_POFF (0x0)
+#define BH1780_PON (0x3)
+
+/* power on settling time in ms */
+#define BH1780_PON_DELAY 2
+
+struct bh1780_data {
+ struct i2c_client *client;
+ int power_state;
+ /* lock for sysfs operations */
+ struct mutex lock;
+};
+
+static int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char *msg)
+{
+ int ret = i2c_smbus_write_byte_data(ddata-client, reg, val);
+ if (ret 0)
+ dev_err(ddata-client-dev,
+ i2c_smbus_write_byte_data failed error %d\
+ Register (%s)\n, ret, msg);
+ return ret;
+}
+
+static int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)
+{
+ int ret = i2c_smbus_read_byte_data(ddata-client, reg);
+ if (ret 0)
+ dev_err(ddata-client-dev,
+ i2c_smbus_read_byte_data failed error %d\
+ Register (%s)\n, ret, msg);
+ return ret;
+}
+
+static ssize_t bh1780_show_lux(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct bh1780_data *ddata = platform_get_drvdata(pdev);
+ int lsb, msb;
+
+ lsb = bh1780_read(ddata, BH1780_REG_DLOW, DLOW);
+ if (lsb 0)
+ return lsb;
+
+ msb = bh1780_read(ddata, BH1780_REG_DHIGH, DHIGH);
+ if (msb 0)
+ return msb;
+
+ return sprintf(buf, %d\n, (msb 8) | lsb);
+}
+
+static ssize_t bh1780_show_power_state(struct device *dev,
+
Re: [PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver
On 05/26/10 09:30, Hemanth V wrote:
From: Hemanth V heman...@ti.com
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports read/update of power state and
read of lux value (through SYSFS). Writing value 3 to power_state enables the
sensor and current lux value could be read.
Jonathan, Daniel
If there are no more comments, do you know howto push this to linus tree.
It's in misc, so send a copy (with reference back to review thread)
to Andrew Morton a...@linux-foundation.org
Andrew tends to pick things up eventually for lkml, but he'll notice
it quicker if you cc him in on relevant emails!
Jonathan
Thanks
Hemanth
Signed-off-by: Hemanth V heman...@ti.com
Reviewed-by: Daniel Mack dan...@caiaq.de
Acked-by: Jonathan Cameron ji...@cam.ac.uk
---
drivers/misc/Kconfig | 10 ++
drivers/misc/Makefile|1 +
drivers/misc/bh1780gli.c | 273
++
3 files changed, 284 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/bh1780gli.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0d0d625..3f5bf0f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -278,6 +278,16 @@ config SENSORS_TSL2550
This driver can also be built as a module. If so, the module
will be called tsl2550.
+config SENSORS_BH1780
+tristate ROHM BH1780GLI ambient light sensor
+depends on I2C SYSFS
+help
+ If you say yes here you get support for the ROHM BH1780GLI
+ ambient light sensor.
+
+ This driver can also be built as a module. If so, the module
+ will be called bh1780gli.
+
config EP93XX_PWM
tristate EP93xx PWM support
depends on ARCH_EP93XX
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7b6f7ee..c479d91 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/
obj-y += eeprom/
obj-y += cb710/
obj-$(CONFIG_VMWARE_BALLOON)+= vmware_balloon.o
+obj-$(CONFIG_SENSORS_BH1780)+= bh1780gli.o
diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
new file mode 100644
index 000..774531d
--- /dev/null
+++ b/drivers/misc/bh1780gli.c
@@ -0,0 +1,273 @@
+/*
+ * bh1780gli.c
+ * ROHM Ambient Light Sensor Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Hemanth V heman...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/platform_device.h
+#include linux/delay.h
+
+#define BH1780_REG_CONTROL 0x80
+#define BH1780_REG_PARTID 0x8A
+#define BH1780_REG_MANFID 0x8B
+#define BH1780_REG_DLOW 0x8C
+#define BH1780_REG_DHIGH0x8D
+
+#define BH1780_REVMASK (0xf)
+#define BH1780_POWMASK (0x3)
+#define BH1780_POFF (0x0)
+#define BH1780_PON (0x3)
+
+/* power on settling time in ms */
+#define BH1780_PON_DELAY2
+
+struct bh1780_data {
+struct i2c_client *client;
+int power_state;
+/* lock for sysfs operations */
+struct mutex lock;
+};
+
+static int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char
*msg)
+{
+int ret = i2c_smbus_write_byte_data(ddata-client, reg, val);
+if (ret 0)
+dev_err(ddata-client-dev,
+i2c_smbus_write_byte_data failed error %d\
+Register (%s)\n, ret, msg);
+return ret;
+}
+
+static int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)
+{
+int ret = i2c_smbus_read_byte_data(ddata-client, reg);
+if (ret 0)
+dev_err(ddata-client-dev,
+i2c_smbus_read_byte_data failed error %d\
+ Register (%s)\n, ret, msg);
+return ret;
+}
+
+static ssize_t bh1780_show_lux(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+struct platform_device *pdev = to_platform_device(dev);
+struct bh1780_data *ddata = platform_get_drvdata(pdev);
+int lsb, msb;
+
+lsb = bh1780_read(ddata, BH1780_REG_DLOW, DLOW);
+if (lsb 0)
+
Re: [PATCH 0/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote: This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered useful, which by looking through current Android kernels is many of them. That depends on the maintainers of these subsystems, who still have the power to reject requested changes. So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that? I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether. -- Arve Hjønnevåg -- 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/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote: On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote: This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered useful, which by looking through current Android kernels is many of them. That depends on the maintainers of these subsystems, who still have the power to reject requested changes. So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that? I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether. So why again was this such a great scheme? Go fix your userspace to not not run when not needed. -- 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/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 2:45 AM, Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote: On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote: This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered useful, which by looking through current Android kernels is many of them. That depends on the maintainers of these subsystems, who still have the power to reject requested changes. So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that? I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether. So why again was this such a great scheme? Go fix your userspace to not not run when not needed. Thanks for your constructive feedback. Brian -- 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 v2 2/7] DSPBRIDGE: maintain mapping and page info
On Mon, May 24, 2010 at 7:05 PM, Ohad Ben-Cohen o...@wizery.com wrote: Every time the MM application calls proc_map to map a memory area, remember the details of that mapping, together with the related page structures. Whenever a buffer is unmapped, clean up the mapping information resources. This information is maintained as part of the DMM resource tracking mechanism. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- If you want, you can also reach me at ohadb at ti dot com . arch/arm/plat-omap/include/dspbridge/dspdefs.h | 3 +- drivers/dsp/bridge/core/io_sm.c | 11 ++- drivers/dsp/bridge/core/tiomap3430.c | 9 ++- drivers/dsp/bridge/rmgr/proc.c | 125 ++-- 4 files changed, 113 insertions(+), 35 deletions(-) diff --git a/arch/arm/plat-omap/include/dspbridge/dspdefs.h b/arch/arm/plat-omap/include/dspbridge/dspdefs.h index 3dfe406..f09bdbd 100644 --- a/arch/arm/plat-omap/include/dspbridge/dspdefs.h +++ b/arch/arm/plat-omap/include/dspbridge/dspdefs.h @@ -182,7 +182,8 @@ typedef dsp_status(*fxn_brd_memwrite) (struct bridge_dev_context typedef dsp_status(*fxn_brd_memmap) (struct bridge_dev_context * hDevContext, u32 ul_mpu_addr, u32 ulVirtAddr, u32 ul_num_bytes, - u32 ulMapAttrs); + u32 ulMapAttrs, + struct page **mapped_pages); /* * bridge_brd_mem_un_map diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c index d6c1a98..7fda364 100644 --- a/drivers/dsp/bridge/core/io_sm.c +++ b/drivers/dsp/bridge/core/io_sm.c @@ -503,7 +503,8 @@ dsp_status bridge_io_on_loaded(struct io_mgr *hio_mgr) hio_mgr-intf_fxns- pfn_brd_mem_map(hio_mgr-hbridge_context, pa_curr, va_curr, - page_size[i], map_attrs); + page_size[i], map_attrs, + NULL); if (DSP_FAILED(status)) goto func_end; pa_curr += page_size[i]; @@ -568,7 +569,8 @@ dsp_status bridge_io_on_loaded(struct io_mgr *hio_mgr) hio_mgr-intf_fxns- pfn_brd_mem_map(hio_mgr-hbridge_context, pa_curr, va_curr, - page_size[i], map_attrs); + page_size[i], map_attrs, + NULL); dev_dbg(bridge, shm MMU PTE entry PA %x VA %x DSP_VA %x Size %x\n, @@ -636,7 +638,8 @@ dsp_status bridge_io_on_loaded(struct io_mgr *hio_mgr) hio_mgr-ext_proc_info.ty_tlb[i]. ul_gpp_phys, hio_mgr-ext_proc_info.ty_tlb[i]. - ul_dsp_virt, 0x10, map_attrs); + ul_dsp_virt, 0x10, map_attrs, + NULL); } } if (DSP_FAILED(status)) @@ -655,7 +658,7 @@ dsp_status bridge_io_on_loaded(struct io_mgr *hio_mgr) status = hio_mgr-intf_fxns-pfn_brd_mem_map (hio_mgr-hbridge_context, l4_peripheral_table[i].phys_addr, l4_peripheral_table[i].dsp_virt_addr, HW_PAGE_SIZE4KB, - map_attrs); + map_attrs, NULL); if (DSP_FAILED(status)) goto func_end; i++; diff --git a/drivers/dsp/bridge/core/tiomap3430.c b/drivers/dsp/bridge/core/tiomap3430.c index c7b0d83..e122f04 100644 --- a/drivers/dsp/bridge/core/tiomap3430.c +++ b/drivers/dsp/bridge/core/tiomap3430.c @@ -101,7 +101,8 @@ static dsp_status bridge_brd_mem_write(struct bridge_dev_context *dev_context, u32 ul_num_bytes, u32 ulMemType); static dsp_status bridge_brd_mem_map(struct bridge_dev_context *hDevContext, u32 ul_mpu_addr, u32 ulVirtAddr, - u32 ul_num_bytes, u32 ul_map_attr); + u32 ul_num_bytes, u32 ul_map_attr, + struct page **mapped_pages); static dsp_status bridge_brd_mem_un_map(struct bridge_dev_context *hDevContext, u32 ulVirtAddr, u32
Re: [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 11:45:06 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote: On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote: This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered useful, which by looking through current Android kernels is many of them. That depends on the maintainers of these subsystems, who still have the power to reject requested changes. So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that? I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether. So why again was this such a great scheme? Go fix your userspace to not not run when not needed. Hi Peter! This was already mentioned in one of these threads. The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants. So anything relying on (all) userspace solves a different problem. Cheers, Flo -- 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 0/8] Suspend block api (version 8)
2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote: On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote: This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered useful, which by looking through current Android kernels is many of them. That depends on the maintainers of these subsystems, who still have the power to reject requested changes. So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that? I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether. So why again was this such a great scheme? Go fix your userspace to not not run when not needed. I was not talking about our user-space code. Suspend has to be called by a running thread, so at least one runqueue is not empty. -- Arve Hjønnevåg -- 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/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote: The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants. So anything relying on (all) userspace solves a different problem. So what stops an application from grabbing a suspend blocker? -- 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/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote: I was not talking about our user-space code. Suspend has to be called by a running thread, so at least one runqueue is not empty. But why would you need to suspend if the machine is fully idle? Is it because you're using broken hardware that has lower power consumption in suspend state as in idle? Couldn't you make the runtime-pm smarter and utilize the suspend states? -- 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/8] Suspend block api (version 8)
On Wed, 26 May 2010 12:08:04 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote: The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants. So anything relying on (all) userspace solves a different problem. So what stops an application from grabbing a suspend blocker? Well, I don't own any android devices, but If I read this all correctly, an app can request the permission to grab an suspend blocker at installation time. (This application is requesting permission to keep the device from sleeping, thus possibly reducing your battery time. Are you shure you want to continue? [Yes,No]) every app grabbing a suspend blocker is showing up in a these programs stop suspend kind of battery-app and are thus well accounted for. _And the user knows who to blame_. Maybe this is implemented via fs-permissions? Anyway, I'm shure, that the access control uses a well established method. :) Cheers, Flo -- 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/8] Suspend block api (version 8)
2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote: I was not talking about our user-space code. Suspend has to be called by a running thread, so at least one runqueue is not empty. But why would you need to suspend if the machine is fully idle? I have never seen a system that is fully idle for hours or even minutes. Is it because you're using broken hardware that has lower power consumption in suspend state as in idle? Initially, yes, but for shipping android phones, no. Couldn't you make the runtime-pm smarter and utilize the suspend states? I don't think runtime-pm is relevant here. We don't use suspend to power down devices that are not in use, we use suspend to enter system power states that we cannot enter from idle, and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. -- Arve Hjønnevåg -- 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/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. So don't you think working on making it possible for systems to be idle _that_ long would improve things for everybody? as opposed to this auto-suspend which only improves matters for those that (can) use it? -- 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/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. So don't you think working on making it possible for systems to be idle _that_ long would improve things for everybody? as opposed to this auto-suspend which only improves matters for those that (can) use it? As we've stated a number of times in the several weeks of discussion (this time around) of this patchset, we are all in favor of improving runtime pm, finding and resolving issues that prevent idle, and heading toward ever lower power states in idle -- after all, this benefits our battery life in the cases when the system is not suspended as well as moving us closer to a future where the power savings between actively entering suspend and not doing so approach zero. Aggressively entering the lowest possible power state at all times is our goal here. At the moment, the power savings from opportunistic suspend do directly lead to improved battery life, and there are some advantages to this model in the face of a non-optimal userspace (as we encounter in a world where there are not restrictions on what applications users may install and run). Brian -- 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/8] Suspend block api (version 8)
2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. So don't you think working on making it possible for systems to be idle _that_ long would improve things for everybody? as opposed to this auto-suspend which only improves matters for those that (can) use it? I'm not preventing anyone from working on improving this. Currently both the kernel and our user-space code polls way too much. I don't think it is reasonable to demand that no one should run any user-space code with periodic timers when we have not even fixed the kernel to not do this. -- Arve Hjønnevåg -- 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/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote: 2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. So don't you think working on making it possible for systems to be idle _that_ long would improve things for everybody? as opposed to this auto-suspend which only improves matters for those that (can) use it? I'm not preventing anyone from working on improving this. Currently both the kernel and our user-space code polls way too much. I don't think it is reasonable to demand that no one should run any user-space code with periodic timers when we have not even fixed the kernel to not do this. All I'm saying is that merging a stop-gap measure will decrease the urgency and thus the time spend fixing the actual issues while adding the burden of maintaining this stop-gap measure. -- 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/8] Suspend block api (version 8)
2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote: 2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. So don't you think working on making it possible for systems to be idle _that_ long would improve things for everybody? as opposed to this auto-suspend which only improves matters for those that (can) use it? I'm not preventing anyone from working on improving this. Currently both the kernel and our user-space code polls way too much. I don't think it is reasonable to demand that no one should run any user-space code with periodic timers when we have not even fixed the kernel to not do this. All I'm saying is that merging a stop-gap measure will decrease the urgency and thus the time spend fixing the actual issues while adding the burden of maintaining this stop-gap measure. Fixing the actually issue means fixing all user-space code, and replacing most x86 hardware. I don't think keeping this feature out of the kernel will significantly accelerate this. -- Arve Hjønnevåg -- 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 V2] misc : ROHM BH1780GLI Ambient light sensor Driver
- Original Message - From: Jonathan Cameron On 05/26/10 09:30, Hemanth V wrote: From: Hemanth V heman...@ti.com Date: Fri, 21 May 2010 15:52:03 +0530 Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver This patch adds support for ROHM BH1780GLI Ambient light sensor. BH1780 supports I2C interface. Driver supports read/update of power state and read of lux value (through SYSFS). Writing value 3 to power_state enables the sensor and current lux value could be read. Jonathan, Daniel If there are no more comments, do you know howto push this to linus tree. It's in misc, so send a copy (with reference back to review thread) to Andrew Morton a...@linux-foundation.org Andrew tends to pick things up eventually for lkml, but he'll notice it quicker if you cc him in on relevant emails! Andrew, Could you pull the patch listed in https://patchwork.kernel.org/patch/101860/ This is version 2 of the patch. Review comments and discussion are listed part of https://patchwork.kernel.org/patch/101396/ Thanks Hemanth -- 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/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote: 2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote: 2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. So don't you think working on making it possible for systems to be idle _that_ long would improve things for everybody? as opposed to this auto-suspend which only improves matters for those that (can) use it? I'm not preventing anyone from working on improving this. Currently both the kernel and our user-space code polls way too much. I don't think it is reasonable to demand that no one should run any user-space code with periodic timers when we have not even fixed the kernel to not do this. All I'm saying is that merging a stop-gap measure will decrease the urgency and thus the time spend fixing the actual issues while adding the burden of maintaining this stop-gap measure. Fixing the actually issue means fixing all user-space code, and replacing most x86 hardware. I don't think keeping this feature out of the kernel will significantly accelerate this. I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere near fast enough for this to be usable. My laptop still takes several seconds to suspend (Lenovo T500), and resume (aside from some userspace bustage) takes the same amount of time. That is quick enough for manual suspend, but I'd hate it to try and auto-suspend. Getting longer idle periods however is something that everybody benefits from. On x86 we're nowhere close to hitting the max idle time of the platform, you get _tons_ of wakeups on current 'desktop' software. But x86 being a PITA shouldn't stop people from working on this, there's plenty other architectures out there, I remember fixing a NO_HZ bug with davem on sparc64 because his niagra had cores idling for very long times indeed. So yes, I do think merging this will delay the effort in fixing userspace, simply because all the mobile/embedded folks don't care about it anymore. -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 12:02 PM, Florian Mickler flor...@mickler.org wrote: So why again was this such a great scheme? Go fix your userspace to not not run when not needed. Hi Peter! This was already mentioned in one of these threads. The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants. I don't see this as a valid point. Everyone can run a different kernel where nothing will just work. Are you aiming protection against that as well? ~Vitaly -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/5/26 Arve Hjønnevåg a...@android.com: Fixing the actually issue means fixing all user-space code, and replacing most x86 hardware. I don't think keeping this feature out of the kernel will significantly accelerate this. But if this feature gets merged, I bet you'll find another 100 reasons to not fix the actual issue. I wouldn't say so if you haven't provided the irrelevant points already, like replacing x86 hardware. You're trying to merge the approach which makes the bad way of handing things the easiest way. This shouldn't get in as it is IMO. ~Vitaly -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org wrote: This is not protection. This is functioning properly in a real world scenario. Why would the user change the kernel, if the device would be buggy after that? (Except maybe he is a geek) Hmm... Why would the user continue to use the program if it slows down his device and sucks the battery as a vampire (Except maybe he's a moron)? ;) ~Vitaly -- 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
Delay in performing suspend-to-ram issued via RT thread (SCHED_FIFO)
Hello Everyone, I am currently working with the linux 2.6.29-omap1 kernel. Right now I am porting a legacy application code that puts the OMAP 5912 host to sleep. The host wakes up after 4 secs via an RTC interrupt which is configured to be the wake-up source. Everything seems to be fine running in a loop. The system wakes up and goes back to sleep in 4 seconds every time. But I am observing a behavior that I am unable to explain. The legacy application thread that puts the system to sleep is originally an RT thread with the scheduling policy (SCHED_FIFO) and priority 5. The thread runs in a loop. The following bash script mimics the behavior of this thread exactly (however you will probably need some wake up source like an RTC interrupt to try it on your side): ## Script start # #!/bin/bash NAME_OF_THE_SCRIPT=`basename $0` SELF_PID=`pidof $NAME_OF_THE_SCRIPT` /usr/bin/chrt -f -p 5 $SELF_PID sleep 1 while (true) do echo mem /sys/power/state usleep 3 done ## Script end ### With this thread running, I see the following messages looping repeatedly on the target console screen: ## Console o/p start # PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.92 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: OMAP16212316 is trying to enter deep sleep... PM: OMAP16212316 is re-starting from deep sleep... Restarting tasks ... RTC IRQ cleared done. PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.90 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: OMAP16212316 is trying to enter deep sleep... PM: OMAP16212316 is re-starting from deep sleep... Restarting tasks ... RTC IRQ cleared done. PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.92 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: OMAP16212316 is trying to enter deep sleep... PM: OMAP16212316 is re-starting from deep sleep... Restarting tasks ... RTC IRQ cleared done. ## Console o/p end ### You can observe from the above messages that the elapsed time in Freezing the user processes is in the order of around 0.9 seconds. Also, (although not evident here) when the message Restarting tasks ... appears it takes around a second for the done. message to follow. Now comes the fun part. When I do not fiddle around with the scheduling policy and priority of the legacy RT thread and just let it be a normal user space thread (SCHED_OTHER with priority 20, nice 0) (You can achieve this in the script that I shared with you all by simply commenting out the command that says /usr/bin/chrt -f -p 5 $SELF_PID). Then there is almost no delay at all during Freezing and Restarting (I should probably call this Thawing) the user space tasks. That is, I now have the following console o/p: ## Console o/p start # PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: OMAP16212316 is trying to enter deep sleep... PM: OMAP16212316 is re-starting from deep sleep... Restarting tasks ... RTC IRQ cleared done. PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: OMAP16212316 is trying to enter deep sleep... PM: OMAP16212316 is re-starting from deep sleep... Restarting tasks ... RTC IRQ cleared done. PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: OMAP16212316 is trying to enter deep sleep... PM: OMAP16212316 is re-starting from deep sleep... Restarting tasks ... RTC IRQ cleared done. ## Console o/p end ### As you can see from the above log that the time elapsed during freeze is now reported as 0.00 seconds. And I observed here that there is no time delay between printing Restarting tasks ... and done.. I am having a tough time searching for an explanation to this behavior. And I hoping that some of you might have already experienced this behavior or knows what is happening and can explain this to me. Many thanks in advance. Best regards, Uthappa Please do not print this email unless it is absolutely necessary. Spread environmental awareness.
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 14:01:49 +0200 Vitaly Wool vitalyw...@gmail.com wrote: On Wed, May 26, 2010 at 1:37 PM, Florian Mickler flor...@mickler.org wrote: This is not protection. This is functioning properly in a real world scenario. Why would the user change the kernel, if the device would be buggy after that? (Except maybe he is a geek) Hmm... Why would the user continue to use the program if it slows down his device and sucks the battery as a vampire (Except maybe he's a moron)? ;) ~Vitaly Because he is using a robust kernel that provides suspend blockers and is preventing the vampire from sucking power? Most users don't even grasp the simple concept of different programs. They just have a device and click here and there and are happy. Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. Cheers, Flo -- 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/8] Suspend block api (version 8)
I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere near fast enough for this to be usable. Yet... My laptop still takes several seconds to suspend (Lenovo T500), and resume (aside from some userspace bustage) takes the same amount of time. That is quick enough for manual suspend, but I'd hate it to try and auto-suspend. This is an area where machines are improving and where the ability to do stuff like autosuspend, the technology like the OLPC screen and so on create an incentive for the BIOS and platform people to improve their bits of it. So yes, I do think merging this will delay the effort in fixing userspace, simply because all the mobile/embedded folks don't care about it anymore. The mobile space probably doesn't care too much about many of the large bloated desktop apps anyway and traditional embedded generally has a very small fixed application set where the optimise both halves of the system together. Alan -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. -- balbi DefectiveByDesign.org -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Hi, On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote: But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. and that's enough to push hacks into the kernel ? I don't think so. Do it like apple and prevent multi-tasking for any non-apple applications :-p -- balbi DefectiveByDesign.org -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote: On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. Provide the developers and users with tools. Notify the users that their phone is using power at an unadvised rate due to proglet $foo. Also, if you can integrate into the development environment and provide developers instant feedback on suckage of their app they can react and fix before letting users run into the issue. -- 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/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote: This is an area where machines are improving and where the ability to do stuff like autosuspend, the technology like the OLPC screen and so on create an incentive for the BIOS and platform people to improve their bits of it. But do you think its a sensible thing to do? Explicitly not running runnable tasks just sounds wrong. Also, at the extreme end, super fast suspend is basically an efficient idle mode. Why would the code holding suspend blockers be any more or less important than any other piece of runnable code. In fact, having runnable but non suspend blocking tasks around will delay the completion of the suspend blocker, so will we start removing those? This whole thing introduces an artificial segregation of code. My 'cool' code is more important than your 'uncool' code. Without a clear definition of what makes code cool or not. So yes, I do think merging this will delay the effort in fixing userspace, simply because all the mobile/embedded folks don't care about it anymore. The mobile space probably doesn't care too much about many of the large bloated desktop apps anyway and traditional embedded generally has a very small fixed application set where the optimise both halves of the system together. Sure, but at least we share the kernel. It was said that the kernel generates too many wakeups (and iwlagn certainly is the top most waker on my laptop). Improvements to the kernel will benefit all, regardless of whatever userspace we run. -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 15:35:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: Hi, On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote: But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. and that's enough to push hacks into the kernel ? I don't think so. Do it like apple and prevent multi-tasking for any non-apple applications :-p :) It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other. So merging this patch set will allow android to continue their work _on mainline_ while everybody else can continue as before. All points about the impact on the kernel have already been raised. So you should be happy there. Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not. Also I expect there to be synergies between android development and mainline kernel development _only_ if android development can use mainline kernel. And as for the quality of the hack: I think you find this ugly, just because you don't like the concept of degrading user space guaranties on timers and stuff. But look at it this way: Suspend blockers are a way for the kernel to make user space programs accountable for using the resource power. If a user space program needs the traditional guaranties for functioning properly, it needs to take a suspend blocker. But _THEN_ it better be well behaved. This is a kind of contract between userspace and kernelspace. On the other hand, if I don't need these traditional guaranties on timers and stuff, I don't have to know device specific things about power consumption. I can just use whatever facilities the programming language provides without needing to worry about low level details. This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like). Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. You almost always need to hack the mainline software for a production system. So do it here as well. Make sure the hack is well isolated and local. You can even submit it to the mainline, better as a configuration option, _unless_ it is a *framework* that provokes writing code in an ugly and unsafe way. ~Vitaly -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 14:41:29 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote: On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. Provide the developers and users with tools. Notify the users that their phone is using power at an unadvised rate due to proglet $foo. Also, if you can integrate into the development environment and provide developers instant feedback on suckage of their app they can react and fix before letting users run into the issue. Yeah. And I personally agree with you there. But this is a policy decision that should not prevent android from doing it differently. The kernel can not win if it does not try to integrate any use of it. After all, we are a free comunity and if someone wants to use it their way, why not allow for it? (As long as it does not directly impact other uses) The best solution wins, but not by decision of some kernel development gatekeepers, but because it is superior. There are no clear markings of the better solution. Time will tell. Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote: It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other. That's exactly what we always do. If we were not to do so, the kernel would be a bloated incoherent piece of crap. So merging this patch set will allow android to continue their work _on mainline_ while everybody else can continue as before. Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not. I really think we should not do so. Let them help in fixing the real issue instead of creating a new class of userspace that is more important than another. But look at it this way: Suspend blockers are a way for the kernel to make user space programs accountable for using the resource power. How is userspace without suspend blockers not accountable? We can easily account runtime and in fact have several ways to do so. -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote: The kernel can not win if it does not try to integrate any use of it. If we'd integrate every patch that came to lkml, you'd run away screaming. We most certainly do not want to integrate _any_ use. -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else The whole API feels wrong to me. It's breaking rule #1 of technology You cannot solve a social problem with technology. In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying App XYZ is using all your battery and red-amber-green powermeter scores in app stores. That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ? - You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this - You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1] That maps onto two existing ideas Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like setpidle(getpid(), something); exec() where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API. And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone. Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers. Alan -- [1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. Static simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states) -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not. That seems to me to be conflating models of behaviour and implementations. This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like). You would do better to concentrate on technical issues that the assignment of malicious intent to other parties. Alan -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 14:55:31 +0200 Vitaly Wool vitalyw...@gmail.com wrote: On Wed, May 26, 2010 at 2:24 PM, Florian Mickler flor...@mickler.org wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. You almost always need to hack the mainline software for a production system. So do it here as well. Make sure the hack is well isolated and local. You can even submit it to the mainline, better as a configuration option, _unless_ it is a *framework* that provokes writing code in an ugly and unsafe way. ~Vitaly I don't think that the in-kernel suspend block is a bad idea. You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not. Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a suspend as soon as possible semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away). Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 15:07:27 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote: The kernel can not win if it does not try to integrate any use of it. If we'd integrate every patch that came to lkml, you'd run away screaming. We most certainly do not want to integrate _any_ use. We most certainly do want to integrate any use that is not harmful to others. I don't buy the argument that this is harmful. Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 14:19:42 +0100 Alan Cox a...@lxorguk.ukuu.org.uk wrote: This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like). You would do better to concentrate on technical issues that the assignment of malicious intent to other parties. Alan This was nothing the kind of! He explicitly said this: On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. And I responded that if the kernel would do this, then that would be a _big_ plus for attracting 3d party programs. I had no intent in attacking anyone or putting word's in someones mouth. Sorry if this was unclearly written. Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Alan, On Wed, 26 May 2010, Alan Cox wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else The whole API feels wrong to me. It's breaking rule #1 of technology You cannot solve a social problem with technology. In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying App XYZ is using all your battery and red-amber-green powermeter scores in app stores. I completely agree. We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist. In the mobile app space it's basically the same problem. Users can influence the app writers simply by voting and setting up public lists of apps which are crappy or excellent. All it needs is a nice powertop tool for the phone which allows the users to identify the crap on their phones. That provides much more incentive - especially for commercial players - to fix their crappy code. Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel is just counter productive as it signals to the app provider: Go ahead, keep on coding crap! That's not a solution, that's just capitulation. It's absurd that some folks believe that giving up the most efficient tool to apply pressure to crappy app providers is a good idea. Thanks, tglx -- 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 2/2] Adding low-level init for hsmmc controller for OMAP 3530 LV SOM and OMAP 35x Torpedo
ARM: OMAP3LOGIC: Adding SDMMC support
Add low-level initialization for hsmmc controller for
LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board.
Signed-off-by: Jacob Tanenbaum jacob.tanenb...@logicpd.com
---
arch/arm/mach-omap2/board-omap3logic.c | 69 +++-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index fe5db85..13e0b16 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -33,13 +33,18 @@
#include asm/mach/map.h
#include mux.h
-
+#include hsmmc.h
#include plat/mux.h
#include plat/board.h
#include plat/common.h
#include plat/gpmc.h
#include plat/timer-gp.h
+#define OMAP3530_LV_SOM_MMC_GPIO_CD 110
+#define OMAP3530_LV_SOM_MMC_GPIO_WP 126
+#define OMAP3_TORPEDO_MMC_GPIO_CD 127
+#define OMAP3_TORPEDO_MMC_GPIO_WP (-EINVAL)
+
/* Micron MT46H32M32LF-6 */
/* FIXME: borrowed from sdram-micron-mt46h32m32lf-6.h because on LogicPD
* boards we can't use the default values -- why? I suspect the reason
@@ -80,6 +85,28 @@ static struct omap_sdrc_params mt46h32m32lf6_sdrc_params[] =
{
},
};
+
+static struct regulator_consumer_supply omap3logic_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
+static struct regulator_init_data omap3logic_vmmc1 = {
+ .constraints = {
+ .name = VMMC1,
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3logic_vmmc1_supply,
+};
+
+
static int omap3logic_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -121,6 +148,44 @@ static int __init omap3logic_i2c_init(void)
return 0;
}
+
+static struct omap2_hsmmc_info __initdata board_mmc_info[] = {
+ {
+ .name = external,
+ .mmc= 1,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ {} /* Terminator */
+};
+
+static void __init board_mmc_init(void)
+{
+ /* OMAP3530 LV SOM board */
+ if (machine_is_omap3530_lv_som()) {
+ board_mmc_info[0].gpio_cd = OMAP3530_LV_SOM_MMC_GPIO_CD;
+ board_mmc_info[0].gpio_wp = OMAP3530_LV_SOM_MMC_GPIO_WP;
+ omap_mux_init_signal(gpio_110, OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(gpio_126, OMAP_PIN_OUTPUT);
+
+
+ /* OMAP3 Torpedo board */
+ } else if (machine_is_omap3_torpedo()) {
+ board_mmc_info[0].gpio_cd = OMAP3_TORPEDO_MMC_GPIO_CD;
+ omap_mux_init_signal(gpio_127, OMAP_PIN_OUTPUT);
+ /* unsupported board */
+ } else {
+ printk(KERN_ERR %s(): unknown machine type\n, __func__);
+ return;
+ }
+
+ omap2_hsmmc_init(board_mmc_info);
+ /* link regulators to MMC adapters */
+ omap3logic_vmmc1_supply.dev = board_mmc_info[0].dev;
+}
+
+
static struct omap_board_config_kernel omap3logic_config[] __initdata = {
};
@@ -164,6 +229,7 @@ static void __init omap3logic_map_io(void)
MACHINE_START(OMAP3_TORPEDO, Logic OMAP3 Torpedo board)
/* Maintainer: Peter Barada pet...@logicpd.com */
+
.phys_io= 0x4800,
.io_pg_offst= ((0xd800) 18) 0xfffc,
.boot_params= 0x8100,
@@ -175,6 +241,7 @@ MACHINE_END
MACHINE_START(OMAP3530_LV_SOM, OMAP Logic 3530 LV SOM board)
/* Maintainer: Peter Barada pet...@logicpd.com */
+
.phys_io= 0x4800,
.io_pg_offst= ((0xd800) 18) 0xfffc,
.boot_params= 0x8100,
--
1.6.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
[PATCH 1/2] Adding LogicPD OMAP 3530 LV SOM and OMAP 35x Torpedo
Adding LogicPD OMAP3 board support Adding support for LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board. Signed-off-by: Jacob Tanenbaum jacob.tanenb...@logicpd.com --- arch/arm/configs/omap3_logic_defconfig | 990 arch/arm/mach-omap2/Kconfig|8 + arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/board-omap3logic.c | 185 ++ 4 files changed, 1187 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/omap3_logic_defconfig create mode 100644 arch/arm/mach-omap2/board-omap3logic.c diff --git a/arch/arm/configs/omap3_logic_defconfig b/arch/arm/configs/omap3_logic_defconfig new file mode 100644 index 000..90f5ecd --- /dev/null +++ b/arch/arm/configs/omap3_logic_defconfig @@ -0,0 +1,990 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.32 +# Wed May 5 19:56:47 2010 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ARCH_HAS_CPUFREQ=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_OPROFILE_ARMV7=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set + +# +# RCU Subsystem +# +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set +# CONFIG_TREE_RCU_TRACE is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +# CONFIG_SYSFS_DEPRECATED_V2 is not set +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +# CONFIG_ELF_CORE is not set +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# +CONFIG_VM_EVENT_COUNTERS=y +# CONFIG_COMPAT_BRK is not set +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_PROFILING=y +CONFIG_TRACEPOINTS=y +CONFIG_OPROFILE=y +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_GCOV_KERNEL is not set +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_FORCE_LOAD=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=cfq +CONFIG_FREEZER=y + +# +# System Type +# +CONFIG_MMU=y +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_NOMADIK is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_L7200 is not set +# CONFIG_ARCH_KIRKWOOD is not set +# CONFIG_ARCH_LOKI is not set +# CONFIG_ARCH_MV78XX0 is not set +#
Re: [RFC] Initial attempt to make ARM use LMB
* Russell King - ARM Linux li...@arm.linux.org.uk [100526 00:45]: On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote: After applying the next patch in your lmb branch ARM: OMAP: Convert to use -reserve method to reserve boot time memory tux still works on 5912osk, but not on n900. The difference is that osk5912 uses the old omapfb code. I guess this is because I don't have board-n900.c in my tree. All OMAP boards need a .reserve = omap_reserve, line added in their machine descriptor. It's there but well hidden, board-rx51.c is the one for n900. I just noticed that board-n8x0.c contains more than one machine descriptor, which I've now fixed up. OK good catch. Anyways, I've picked the patches from lmb branch up to the one below into omap-testing. Will add more of them once we get them working. You should now be able to pick all but the last patch. Yeah I'll do that once the dss2 code has been verified to work. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010, Florian Mickler wrote: I don't think that the in-kernel suspend block is a bad idea. You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not. That's not how it works. Drivers aren't supposed to abort unconditional suspend -- not without a really good reason (for example, the device received a wakeup event before it was fully suspended). In short, suspends should be considered to be _always_ possible. Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a suspend as soon as possible semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away). That's different. Suspend blockers could block (not abort!) regular suspends, just as they do opportunistic suspends. But why should they? I mean, if userspace wants to initiate a suspend that is capable of being blocked by a kernel suspend blocker, then all it has to do is initiate an opportunistic suspend instead of a normal suspend. Alan Stern -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do echo opportunistic /sys/power/policy How about we don't merge that junk and don't give you the opportunity to do silly things like that? :-) -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Alan Cox a...@lxorguk.ukuu.org.uk writes: [1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. Static simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states) Completely agree with this. I used the static/dynamic names out of habit, but since on most embedded devices, there is really no difference in hardware power state, I agree that the difference is only a matter of wakeup latency. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Hi, On Wed, May 26, 2010 at 03:46:55PM +0200, Thomas Gleixner wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else The whole API feels wrong to me. It's breaking rule #1 of technology You cannot solve a social problem with technology. In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying App XYZ is using all your battery and red-amber-green powermeter scores in app stores. I completely agree. We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist. In the mobile app space it's basically the same problem. Users can influence the app writers simply by voting and setting up public lists of apps which are crappy or excellent. All it needs is a nice powertop tool for the phone which allows the users to identify the crap on their phones. That provides much more incentive - especially for commercial players - to fix their crappy code. Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel is just counter productive as it signals to the app provider: Go ahead, keep on coding crap! That's not a solution, that's just capitulation. It's absurd that some folks believe that giving up the most efficient tool to apply pressure to crappy app providers is a good idea. I couldn't agree more with both of you. I also have stated that a powertop application with a fancy UI would do the job. Also building some sort of power estimations on the SDK would allow the developer the have fast feedback about potential power consumption caused by his app on the device. On top of that, the app stores can use the same power estimation technology to rate apps automatically and even reject apps that are wy too badly written. I also feel that kernel shouldn't have to deal, fix, hide bad behavior from apps. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. It is a contract - but not the right one. You are removing autonomy from the kernel when only the kernel can measure the full picture and when the kernel is actually supposed to be responsible for resource management. On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker. Even the the model is wrong. I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android Disagree. It's an arbitary and misleading divide that happens to reflect a specific vendors current phones. Worse yet it may not reflect their own future products. It assumes for example that their is some power level that is 'suspend' that is singular, application understood and can be effectively user space managed. Big assumptions and not ones that seem to be sensible. It also breaks another rule - when the hardware changes your application blocker policies will be wrong. Do you want multiple hand optimised copies of each app ? Take a look at what happened to CPU designs where the assumption was you'd recompile the app for each CPU version to get any useful performance. If you are instead expressing it as must be able to respond in time X and must be able to wake up from an event on an active device then your interface is generic and hardware independant. If bouncing cows says 'need to wake up every 0.3 seconds you want the kernel to decide how best to do that. It will vary by hardware. On todays desktop PC thats probably a low power state limit. On some current embedded hardware it might be a special deep sleep mode. On one or two devices it might be 'suspend'. It might also be that the properties have been set to 2 seconds already so it gets told it can't have 0.3. The app cannot be allowed to know platform specific stuff or your portability comes apart and you end up with a disaster area where each app only comes on a subset of devices. Express the requirement right and you get a simple clean interface that continues to work. Express it wrong and you get a mess. userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do Thats a very big hammer and it doesn't express what I actually want, which is to allow the cows to run as efficiently as possible. echo opportunistic /sys/power/policy in the first place. But you can do this properly by having a per process idle requirement, and that can encompass things like hard real time as well (or even gaming). The suspend blockers break all the global policy, don't solve real time and don't allow for sensible expansion models. They don't solve our existing wakeup versus device problems either. How does this address the loss of wakeup events while using suspend? (For example the 2 issues formulated by Alan Stern in [1]) In this environment the problem cannot occur in the first place unless there are kernel code bugs, if there are then they are in GPL code and can be fixed. But you are mixing up interfaces and implementations which I find is usually a bad idea. Doing the right thing badly gives you an interface to an implementation you can later fix. Doing the wrong thing well leaves you stuck down a hole. p.s.: d...@schatten /usr/src/linux $ grep -r setpidle . Yes I know - no point having a new function which has an in use name is there ? It's trivial to add per process idling or wakeup requirements. Alan -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. I think that's the point of it. -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote: On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. I think that's the point of it. Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again. -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 17:45:00 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote: On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. I think that's the point of it. Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again. I'm sorry if I offend you. I indeed read Alan's emails. It's just they have more content than yours. So it takes longer. Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 17:47:35 +0200 Florian Mickler flor...@mickler.org wrote: On Wed, 26 May 2010 17:45:00 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote: On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case. That's backwards. I think that's the point of it. Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again. I'm sorry if I offend you. I indeed read Alan's emails. It's just they have more content than yours. So it takes longer. Cheers, Flo p.s.: also they encourage me to think more before answering. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/17] drivers/video/omap2/displays: Add missing mutex_unlock
From: Julia Lawall ju...@diku.dk
Add a mutex_unlock missing on the error paths. The use of the mutex is
balanced elsewhere in the file.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression E1;
@@
* mutex_lock(E1,...);
+... when != E1
if (...) {
... when != E1
* return ...;
}
...+
* mutex_unlock(E1,...);
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
drivers/video/omap2/displays/panel-acx565akm.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index 1f8eb70..07fbb8a 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -592,7 +592,7 @@ static int acx_panel_power_on(struct omap_dss_device
*dssdev)
r = omapdss_sdi_display_enable(dssdev);
if (r) {
pr_err(%s sdi enable failed\n, __func__);
- return r;
+ goto fail_unlock;
}
/*FIXME tweak me */
@@ -633,6 +633,8 @@ static int acx_panel_power_on(struct omap_dss_device
*dssdev)
return acx565akm_bl_update_status(md-bl_dev);
fail:
omapdss_sdi_display_disable(dssdev);
+fail_unlock:
+ mutex_unlock(md-mutex);
return r;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Florian, On Wed, 26 May 2010, Florian Mickler wrote: On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker. This is an option which they currently don't have. Wrong. A well coded power aware application is very well able to express that in various ways already today. Admittedly it's far from perfect, but that can be fixed by adding interfaces which allow the power aware coder to express the requirements of his application actively, not by avoiding it. suspend blockers are completely backwards as they basically disable the kernels ability to do resource management. Also they enforce a black and white scheme (suspend or run) on the kernel which is stupid, as there are more options to efficiently save power than those two. While current android devices might not provide them, later hardware will have it and any atom based device has them already. So what the kernel needs to know to make better decisions are things like: - how much slack can timers have (exisiting interface) - how much delay of wakeups is tolerated (missing interface) and probably some others. That information would allow the kernel to make better decisions versus power states, grouping timers, race to idle and other things which influence the power consumption based on the hardware you are running on. I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do echo opportunistic /sys/power/policy in the first place. This optionally being badly written, who cares? is a new feature the kernel can provide to applications. It's a misfeature which the kernel should not provide at all. It sends out the completely wrong message: Hey, we can deal with your crappy code, keep on coding that way. While this seems to sound cool to certain people in the mobile space, it's completely backwards and will backfire in no time. The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users. Thanks, tglx -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users. Even if you believe the kernel should be containing junk the model that works and is used for everything else is resource management. Not giving various tasks the ability to override rules, otherwise you end up needing suspend blocker blockers next week. A model based on the idea that a task can set its desired wakeup behaviour *subject to hard limits* (ie soft/hard process wakeup) works both for the sane system where its elegantly managing hard RT, and for the crud where you sandbox it to stop it making a nasty mess. Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the trick ? Alan -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 19:02:04 +0100 Alan Cox a...@lxorguk.ukuu.org.uk wrote: The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users. Even if you believe the kernel should be containing junk the model that works and is used for everything else is resource management. Not giving various tasks the ability to override rules, otherwise you end up needing suspend blocker blockers next week. A model based on the idea that a task can set its desired wakeup behaviour *subject to hard limits* (ie soft/hard process wakeup) works both for the sane system where its elegantly managing hard RT, and for the crud where you sandbox it to stop it making a nasty mess. Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the trick ? Alan Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it? Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote: Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it? What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap? ~Vitaly -- 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:VFPv3:enable {d16-d31} access
On Wed, May 26, 2010 at 05:13:24PM +0530, DebBarma, Tarun Kanti wrote:
1) With the existing implementation I am not able to correctly
write/read {d0-d15} but not the {d16-d31} set
2) With my changes I am able to write/read correctly.
The reason this happens is simple. In vfp_get_double(), we have:
1: fmrrd r0, r1, d\dr
1: mrrcp11, 3, r0, r1, c\dr@ fmrrd r0, r1, d\dr
but in vfp_put_double(), we have:
1: fmdrr d\dr, r0, r1
1: mcrrp11, 3, r1, r2, c\dr@ fmdrr r1, r2, d\dr
Note the different registers. Change r1, r2 to r0, r1 and it
should work.
--
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/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 02:53:16PM +0200, Peter Zijlstra wrote: On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote: This is an area where machines are improving and where the ability to do stuff like autosuspend, the technology like the OLPC screen and so on create an incentive for the BIOS and platform people to improve their bits of it. But do you think its a sensible thing to do? Explicitly not running runnable tasks just sounds wrong. [...] Why would the code holding suspend blockers be any more or less important than any other piece of runnable code. With my userspace developer hat on, I'd *kill* for a way to tell the kernel that there are more important things for the system to be doing than executing my runnable task. In some cases, the set of more important things the system might include running other tasks, but it also might include conserving power. I'd like to have my program tell the kernel things like wake me up in 0.1 seconds, plus or minus a year if you have something better to do. With my sysadmin hat on (which is nearly identical to my phone owner hat, BTW), I'd like whatever syscall implements those features to take a PID argument, so I can impose my importance decisions on other processes. I'd also like to set the relative importance of keeping the CPU idle on the same scale, so that I could raise or lower the importance of keeping the CPU idle as power availability changes. This whole thing introduces an artificial segregation of code. My 'cool' code is more important than your 'uncool' code. Without a clear definition of what makes code cool or not. It's impossible in the general case for an application to know whether it's important or not, so it's also impossible for the kernel to derive this information from the application's behavior--and impossible, in the general case, to decide whether the application is more important than the battery or some other scarce resource the kernel might also be managing (e.g. if the machine is running hot, heat dissipation might be scarce, and we'd want to be idle then too). This is similar to niceness and SCHED_RR/FIFO: there's no way for the kernel to automatically assign those values either, they have to be specified by a user or administrator. Of course, programs are free--within limits--to specify these values about themselves. Consider a traditional Unix program like sort. Seriously, how is sort supposed to know that it's the most important application on the system (because I need my contacts list alphabetized *now*), or the least (because the screensaver needs to know which is the oldest graphics hack in the list)? sort gets invoked from a shell, cooperating with other processes to do its work. It knows very little about the context in which it is executing (nor should it). Should sort sprout command-line arguments for every possible scheduling latency and power management policy option, or should sort not care, and defer such decisions to other command-line tools which set these options before exec()ing sort, or to a management utility like top that implements policy across the entire system? -- 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: NULL Pointer Deference: NFS Telnet
Thanks Eric, David,
[..]
- if (skb_shinfo(skb)-nr_frags) {
+ if (skb_shinfo(skb)-nr_frags skb_has_frags(skb)) {
int i;
for (i = 0; i skb_shinfo(skb)-nr_frags; i++)
put_page(skb_shinfo(skb)-frags[i].page);
skb_shinfo(skb)-nr_frags counts the number of entries contained
in the skb_shinfo(skb)-frags[] array.
This has nothing to do with the frag list pointer,
skb_shinfo(skb)-frag_list, which is what skb_has_frags()
tests.
You've got some kind of memory corruption going on and it
appears to have nothing to do with the code paths you're
playing with here.
Do you have any recommendation on debugging technique/tool for this memory
corruption issue?
[..]
It seems quite strange. You have a skb-nr_frags 0 value, but a
frags[i].page = 0 value
You might add following function :
shinfo_check(struct sk_buff *skb)
{
struct skb_shared_info *shinfo = skb_shinfo(skb);
int i;
WARN_ON(shinfo-nr_frags = MAX_SKB_FRAGS);
for (i = 0; i shinfo-nr_frags; i++)
WARN_ON(!shinfo-frags[i].page);
}
And call it from various points, to check who corrupts your skb.
By increasing the allocation length of our rx skbuff the corruption issue is
fixed... I have increased it by 2... Were we writing outside our boundaries of
skb data?
Please let me know about this approach...
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index b4fb07a..6da81e1 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -504,7 +504,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
ks-rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
if (rxlen 0) {
- skb = netdev_alloc_skb(ks-netdev, rxlen + 2 + 8);
+ skb = netdev_alloc_skb(ks-netdev, rxlen + 4 + 8);
if (!skb) {
Best Regards
Abraham
--
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: NULL Pointer Deference: NFS Telnet
Le mercredi 26 mai 2010 à 15:19 -0500, Arce, Abraham a écrit :
By increasing the allocation length of our rx skbuff the corruption issue is
fixed... I have increased it by 2... Were we writing outside our boundaries
of skb data?
Please let me know about this approach...
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index b4fb07a..6da81e1 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -504,7 +504,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
ks-rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
if (rxlen 0) {
- skb = netdev_alloc_skb(ks-netdev, rxlen + 2 + 8);
+ skb = netdev_alloc_skb(ks-netdev, rxlen + 4 + 8);
if (!skb) {
Best Regards
Abraham
Yes that makes sense, nr_frag is right after the packet (padded to L1
cache size)
But please do the correct allocation ?
Also, we dont need FCS ?
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index b4fb07a..05bd312 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -503,8 +503,9 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
ks8851_wrreg16(ks, KS_RXQCR,
ks-rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
- if (rxlen 0) {
- skb = netdev_alloc_skb(ks-netdev, rxlen + 2 + 8);
+ if (rxlen 4) {
+ rxlen -= 4;
+ skb = netdev_alloc_skb(ks-netdev, 2 + 8 + ALIGN(rxlen,
4));
if (!skb) {
/* todo - dump frame and move on */
}
@@ -513,7 +514,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
* for the status header and 4 bytes of garbage */
skb_reserve(skb, 2 + 4 + 4);
- rxpkt = skb_put(skb, rxlen - 4) - 8;
+ rxpkt = skb_put(skb, rxlen) - 8;
/* align the packet length to 4 bytes, and add 4 bytes
* as we're getting the rx status header as well */
@@ -526,7 +527,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
netif_rx(skb);
ks-netdev-stats.rx_packets++;
- ks-netdev-stats.rx_bytes += rxlen - 4;
+ ks-netdev-stats.rx_bytes += rxlen;
}
ks8851_wrreg16(ks, KS_RXQCR, ks-rc_rxqcr);
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
suspend blockers are completely backwards as they basically disable the kernels ability to do resource management. I don't think this is a defect in the approach but the point of it. I think it's both. It's the point of it, and that itself is a defect. Its designed wrongly. drivers code is needed anyway. What looses the kernel by implementing suspend blockers, and later a more finegrained approach and mapping the userspace part of suspend blockers on that finegrained approach later on? The Linux approach is to do the job right. That means getting the interface right and so it works across all the interested parties (or as close as we can get). - how much delay of wakeups is tolerated (missing interface) Doesn't solve the segregation problem and is probably overkill for most applications. I see this as an orthogonal thing (i.e. not affecting this merge). The key question that matters for suspend management is 'what wakeup delay is tolerated'. So it's absolutely fundamental. True. But I wouldnt say, that it is the linux kernel who should force this politics onto its users. This is the Linux way of doing things. It's like the GPL and being shouted at by Linus. They are things you accept when you choose to take part. Google chose to use Linux, if they want a feature upstream then the way you get it there is to figure out how to solve the real problem and make *everyone* (within reason) happy. We now have suggestions how to do the job properly so the right thing is probably to go and explore those suggestions not merge crap. Merging crap won't help anyway. The rest of the kernel community can still simply stonewall those interfaces, and a volunteer community has ways of dealing with abuse of process, notably by simply not getting around to, or implementing things directly contrary to the crap bits. So it's not even in the interest of people to play political games. Even if you get away with in the short term the people who rely on the junk will end up out on a limb and holding the baby when the crap hits the fan (see reiserfs) Alan -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore. It's as ridiculous (albeit usually less damaging) as a file system saying Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else The whole API feels wrong to me. It's breaking rule #1 of technology You cannot solve a social problem with technology. In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying App XYZ is using all your battery and red-amber-green powermeter scores in app stores. That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ? Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it. - You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this - You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1] That maps onto two existing ideas Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response. setpidle(getpid(), something); exec() where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API. And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone. Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers. What about platforms that currently cannot enter low power states from idle? Do you remove suspend support from the kernel? Alan -- [1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. Static simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in
Re: [PATCH v2] serial: Add OMAP high-speed UART driver
Govindraj.R govindraj.r...@ti.com writes: This patch adds driver support for OMAP3/4 high speed UART. The driver is made separate from 8250 driver as we cannot over load 8250 driver with omap platform specific configuration for features like DMA, it makes easier to implement features like DMA and hardware flow control and software flow control configuration with this driver as required for the omap-platform.This patch involves only the core driver and its dependent. Cc: Tony Lindgren t...@atomide.com Tested-by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- Platform data support for this driver is currently present in Kevin's PM tree remotes/origin/pm-wip/uart branch This branch contains uart-hwmod platform conversion which utilizes the omap-hwmod framework. Tested using OMAP 3430/3630/4430SDP boards. arch/arm/plat-omap/include/plat/omap-serial.h | 129 +++ drivers/serial/Kconfig| 27 + drivers/serial/Makefile |1 + drivers/serial/omap-serial.c | 1318 + include/linux/serial_core.h |3 + 5 files changed, 1478 insertions(+), 0 deletions(-) [...] diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index f55c494..4346bfa 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1387,6 +1387,33 @@ config SERIAL_OF_PLATFORM Currently, only 8250 compatible ports are supported, but others can easily be added. +config SERIAL_OMAP + tristate OMAP serial port support + depends on ARCH_OMAP3 || ARCH_OMAP4 FYI... this also works on OMAP2. I tested it on my n810 along with UART hwmod conversion and it works just fine there. 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/8] Suspend block api (version 8)
2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote: 2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote: 2010/5/26 Peter Zijlstra pet...@infradead.org: On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. So don't you think working on making it possible for systems to be idle _that_ long would improve things for everybody? as opposed to this auto-suspend which only improves matters for those that (can) use it? I'm not preventing anyone from working on improving this. Currently both the kernel and our user-space code polls way too much. I don't think it is reasonable to demand that no one should run any user-space code with periodic timers when we have not even fixed the kernel to not do this. All I'm saying is that merging a stop-gap measure will decrease the urgency and thus the time spend fixing the actual issues while adding the burden of maintaining this stop-gap measure. Fixing the actually issue means fixing all user-space code, and replacing most x86 hardware. I don't think keeping this feature out of the kernel will significantly accelerate this. I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere near fast enough for this to be usable. x86 systems already auto-suspend. My laptop still takes several seconds to suspend (Lenovo T500), and resume (aside from some userspace bustage) takes the same amount of time. That is quick enough for manual suspend, but I'd hate it to try and auto-suspend. Why? If your suspend is currently set to sleep after 30 minutes of inactivity, you can still have the same setting with opportunistic suspend. With opportunistic suspend you can have an alarm set to run a task at a specific time without risking that this task does not run at that time just because your inactivity timer expired at the same time as the alarm went off. Getting longer idle periods however is something that everybody benefits from. On x86 we're nowhere close to hitting the max idle time of the platform, you get _tons_ of wakeups on current 'desktop' software. But x86 being a PITA shouldn't stop people from working on this, there's plenty other architectures out there, I remember fixing a NO_HZ bug with davem on sparc64 because his niagra had cores idling for very long times indeed. So yes, I do think merging this will delay the effort in fixing userspace, simply because all the mobile/embedded folks don't care about it anymore. To me this is not a good argument for not merging the code. If people stop caring about the problem if this feature is merged that means it solved a problem for them. You want to prevent merging a feature _because_ it solves a problem. -- Arve Hjønnevåg -- 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] OMAP24xx: CM: fix mask used for checking IDLEST status
On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3. The mask used to check this was using the bit position instead of the bit mask. This patch fixes the problem by using the bit mask instead of the bit field. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- Found when testing UART hwmods on OMAP2420 (n810) arch/arm/mach-omap2/cm.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cm.c b/arch/arm/mach-omap2/cm.c index 2d83565..721c3b6 100644 --- a/arch/arm/mach-omap2/cm.c +++ b/arch/arm/mach-omap2/cm.c @@ -50,15 +50,15 @@ int omap2_cm_wait_module_ready(s16 prcm_mod, u8 idlest_id, u8 idlest_shift) cm_idlest_reg = cm_idlest_offs[idlest_id - 1]; + mask = 1 idlest_shift; + if (cpu_is_omap24xx()) - ena = idlest_shift; + ena = mask; else if (cpu_is_omap34xx()) ena = 0; else BUG(); - mask = 1 idlest_shift; - /* XXX should be OMAP2 CM */ omap_test_timeout(((cm_read_mod_reg(prcm_mod, cm_idlest_reg) mask) == ena), MAX_MODULE_READY_TIME, i); -- 1.7.0.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH pm-wip/uart 0/4] misc. fixes for IDLEST and OMAP24xx support
This series on top of my pm-wip/uart branch fixes up various issues with UART hwmods for 24xx as well as IDLEST issues after Benoit's fixes/cleanup series. Tested on OMAP3 (omap3evm) and OMAP2 (n810/2420). Note that for OMAP2, this recently posted patch is required as well: [PATCH] OMAP24xx: CM: fix mask used for checking IDLEST status These ares posted as FYI, and will be folded into the original hwmod data for OMAP2+ UARTs. Kevin Kevin Hilman (4): OMAP3: hwmod: UART: add module offs OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST OMAP2420: hwmod: UART3 needs prcm_reg_id = 2 24xx: need .module_offs = CORE_MOD arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 ++--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 +++ 3 files changed, 27 insertions(+), 11 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
[PATCH pm-wip/uart 1/4] OMAP3: hwmod: UART: add module offs
fold into OMAP3 hwmod patch
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f88bfff..5bf8690 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -287,6 +287,7 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
.main_clk = uart1_fck,
.prcm = {
.omap2 = {
+ .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_UART1_SHIFT,
},
@@ -321,6 +322,7 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
.main_clk = uart2_fck,
.prcm = {
.omap2 = {
+ .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_UART2_SHIFT,
},
@@ -355,6 +357,7 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
.main_clk = uart3_fck,
.prcm = {
.omap2 = {
+ .module_offs = OMAP3430_PER_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_UART3_SHIFT,
},
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH pm-wip/uart 2/4] OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 ++---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 ++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index bbe3006..b9a957d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -66,7 +66,8 @@ static struct omap_hwmod omap2420_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
.slaves = omap2420_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap2420_l4_wkup_hwmod;
@@ -156,7 +157,8 @@ static struct omap_hwmod omap2420_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
.slaves = omap2420_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_WKUP interconnect */
@@ -176,7 +178,8 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
.slaves = omap2420_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
/* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 45767b1..d7faef2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -66,7 +66,8 @@ static struct omap_hwmod omap2430_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
.slaves = omap2430_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap2430_l4_wkup_hwmod;
@@ -155,7 +156,8 @@ static struct omap_hwmod omap2430_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
.slaves = omap2430_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_WKUP interconnect */
@@ -178,7 +180,8 @@ static struct omap_hwmod omap2430_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
.slaves = omap2430_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5bf8690..6bc1173 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -77,7 +77,8 @@ static struct omap_hwmod omap3xxx_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
.slaves = omap3xxx_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
@@ -185,7 +186,8 @@ static struct omap_hwmod omap3xxx_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
.slaves = omap3xxx_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_PER interconnect */
@@ -207,7 +209,8 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_per_masters),
.slaves = omap3xxx_l4_per_slaves,
.slaves_cnt
[PATCH pm-wip/uart 3/4] OMAP2420: hwmod: UART3 needs prcm_reg_id = 2
PRCM bits for UART3 are in PRCM reg id 2 (CM_IDLEST2_CORE, etc.)
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b9a957d..c1618a5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -307,7 +307,7 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.main_clk = uart3_fck,
.prcm = {
.omap2 = {
- .prcm_reg_id = 1,
+ .prcm_reg_id = 2,
.module_bit = OMAP24XX_EN_UART3_SHIFT,
},
},
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH pm-wip/uart 4/4] 24xx: need .module_offs = CORE_MOD
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index c1618a5..682eecd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -239,6 +239,7 @@ static struct omap_hwmod omap2420_uart1_hwmod = {
.main_clk = uart1_fck,
.prcm = {
.omap2 = {
+ .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP24XX_EN_UART1_SHIFT,
},
@@ -273,6 +274,7 @@ static struct omap_hwmod omap2420_uart2_hwmod = {
.main_clk = uart2_fck,
.prcm = {
.omap2 = {
+ .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP24XX_EN_UART2_SHIFT,
},
@@ -307,6 +309,7 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.main_clk = uart3_fck,
.prcm = {
.omap2 = {
+ .module_offs = CORE_MOD,
.prcm_reg_id = 2,
.module_bit = OMAP24XX_EN_UART3_SHIFT,
},
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg a...@android.com wrote: On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends. This is policy and platform specific. The OLPC can suspend with the screen on. Should I write my app to know about this once for Android and once for OLPC (and no doubt once for Apple). In the OLPC case cows could indeed suspend to RAM between frames if the wakeup time was suitable. My app simply should not have to know this sort of crap, that's the whole point of an OS. What you are essentially arguing for is for the kernel to disobey the userspace. No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore. Don't get me wrong - opportunistic suspend isn't the problem. Suspend blockers are - or more precisely - the manner in which they express intent from userspace. Opportunistic suspend is wonderful stuff for all sorts of things and if it persuades people like netbook manufacturers to think harder, and Linux driver authors to optimise their suspend/resume paths we all win. Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it. Opportunistic suspend isn't special. Suspend is just a very deep idle. In fact some of the low power states on processors look little different to suspend - the OS executes a whole pile of CPU state saving and cache flushing. It might be a hardware state machine, it might be buried in firmware or it might be quite explicit (eg mrst). So we already have differing degrees of doing additional work in different states. User triggered suspend is a bit special in that the user is usually right in that case to override the power management policy. Note I'm not suggesting we run off and restructure all our power management code to take this view right now. I'm suggesting we need a clean 'opportunistic suspend is not special' view by user space. How the kernel handles this is addressible later without app breakage, but only if we get the interface wrong to begin with. Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response. But you can express user suspend blocking in this manner. Your call incoming code would say 'I want good latency'. As someone needs good latency the box won't suspend. If your approach is to start with an initial 'anyone can set a low latency we don't care' then anyone can block suspends. Equally your call handling example is about latency not about suspend. You want the phone to stay on, to fetch a picture and display it promptly. So what are expressing 'I am using device 'screen' please keep it live' (which may or may not block suspend - see OLPC). I guess your display server and kernel support manage this bit. 'I want the photo to appear in a resonable timescale' (latency). It's not a suspend question - an imaginary non suspend idle mode with a 20 second latency would be just as annoying yes ? At the moment we have a very real bigger problem that your problem is part of. - Hard real time people want to be able to limit the CPU sleeping behaviour based upon what tasks are running - Certain gaming types want their boxes to be good power citizens except when committing digital mass murder. Right now that involves wrapping the game in a script with bits occurring as root and that generally breaks if the game crashes so the script doesn't run nicely on exit - Virtual machine people desperately want to see latency data to help schedule stuff in a power efficient manner. In a virtual machine environment
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/5/26 Alan Cox a...@lxorguk.ukuu.org.uk: On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg a...@android.com wrote: On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app) And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends. This is policy and platform specific. The OLPC can suspend with the screen on. Should I write my app to know about this once for Android and once for OLPC (and no doubt once for Apple). In the OLPC case cows could indeed suspend to RAM between frames if the wakeup time was suitable. Are you still talking about Linux suspend? If you can enter S3 from idle and still wake up for the next timer or interrupt, then do that. Suspend blockers should have not effect on this. My app simply should not have to know this sort of crap, that's the whole point of an OS. Most apps does not have to know about this with opportunistic suspend either. If the user is interacting with the device, we don't suspend. If your apps needs to run when the user is not interacting with the device, then you can block suspend. What you are essentially arguing for is for the kernel to disobey the userspace. No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore. Don't get me wrong - opportunistic suspend isn't the problem. Suspend blockers are - or more precisely - the manner in which they express intent from userspace. Opportunistic suspend is wonderful stuff for all sorts of things and if it persuades people like netbook manufacturers to think harder, and Linux driver authors to optimise their suspend/resume paths we all win. Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it. Opportunistic suspend isn't special. Suspend is just a very deep idle. In Suspend as it is currently implemented in Linux is special. Regular timers stop, and only specially marked wakeup events can bring the system back to the normal state. fact some of the low power states on processors look little different to suspend - the OS executes a whole pile of CPU state saving and cache flushing. It might be a hardware state machine, it might be buried in firmware or it might be quite explicit (eg mrst). So we already have differing degrees of doing additional work in different states. User triggered suspend is a bit special in that the user is usually right in that case to override the power management policy. On a phone this is not the case. The user manually can toggle the screen on and off, and we may or may not enter suspend when the screen is off. If we forced suspend when the user turned the screen off, we could miss phone calls. Note I'm not suggesting we run off and restructure all our power management code to take this view right now. I'm suggesting we need a clean 'opportunistic suspend is not special' view by user space. How the kernel handles this is addressible later without app breakage, but only if we get the interface wrong to begin with. Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response. But you can express user suspend blocking in this manner. Your call incoming code would say 'I want good latency'. As someone needs good latency the box won't suspend. If your approach is to start with an initial 'anyone can set a low latency we don't care' then anyone can block suspends. Equally your call handling example is about latency not about suspend. You want the phone to stay on, to fetch a picture and display it promptly. I don't think a latency api is the right way to express this since the only latency values we
RE: [PATCH] ARM:VFPv3:enable {d16-d31} access
Russell,
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, May 27, 2010 1:40 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH] ARM:VFPv3:enable {d16-d31} access
On Wed, May 26, 2010 at 05:13:24PM +0530, DebBarma, Tarun Kanti wrote:
1) With the existing implementation I am not able to correctly
write/read {d0-d15} but not the {d16-d31} set
2) With my changes I am able to write/read correctly.
The reason this happens is simple. In vfp_get_double(), we have:
1: fmrrd r0, r1, d\dr
1: mrrcp11, 3, r0, r1, c\dr@ fmrrd r0, r1, d\dr
but in vfp_put_double(), we have:
1: fmdrr d\dr, r0, r1
1: mcrrp11, 3, r1, r2, c\dr@ fmdrr r1, r2, d\dr
Note the different registers. Change r1, r2 to r0, r1 and it
should work.
Yes, that's right. I figured that out yesterday and confirmed the test results.
Thanks!
Can I go ahead with next version of the patch?
BR
Tarun
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 22:03:37 +0200 Vitaly Wool vitalyw...@gmail.com wrote: On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org wrote: Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it? What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap? ~Vitaly Because quite frankly, for a good part of linux users, suspend blockers is already in the kernel. It's just an historical mistake that they are not in the linux kernel's hosted on kernel.org. So why don't we do what we always do? Improve existing interfaces step by step? Top Down approaches fail from time to time. Also it is not clear, that that proposed interface works for the use cases. This has to be proven by providing an implementation. Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 23:09:43 +0100 Alan Cox a...@lxorguk.ukuu.org.uk wrote: We now have suggestions how to do the job properly so the right thing is probably to go and explore those suggestions not merge crap. Merging crap won't help anyway. The rest of the kernel community can still simply stonewall those interfaces, and a volunteer community has ways of dealing with abuse of process, notably by simply not getting around to, or implementing things directly contrary to the crap bits. So it's not even in the interest of people to play political games. Even if you get away with in the short term the people who rely on the junk will end up out on a limb and holding the baby when the crap hits the fan (see reiserfs) Alan I'm not interested in abusing processes. I just think, this is in limbo for too long already. Just decide something. One way or the other. The world will continue. Cheers, Flo -- 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
