Re: [GIT PULL] pending DT patches and cleanup for map_io for v3.2 merge window
* Tony Lindgren t...@atomide.com [111024 10:42]: Arnd, As discussed in the ARM kernel meeting yesterday, here's are the pending omap things to pull for v3.2 merge window. These would be nice to get still in as other people's work such as Nico's map_io changes need #2 below. 1. Initial DT support posted few weeks ago Please see the earlier pull request at: http://lkml.org/lkml/2011/10/4/441 2. Cleanup for map_io posted few weeks ago This depends on the #1 above, and also requires the ioremap_exec patch. Russell said he has applied into devel-stable (But not pushed out yet?). When you have the ioremap_exec patch from Russell, please pull this from: git://github.com/tmlind/linux.git sram-map-io FYI, the ioremap_exec patch seems is available as commit 6c5482d53f195d3ca61c9ec1be25b0f4a92575fe (ARM: 7129/1: Add __arm_ioremap_exec for mapping external memory) in Russell's for-linus branch. Pull request against #1 attached below. Regards, Tony The following changes since commit 3ae3e253db7385238dd9d6c67c085afa3e770a56: Tony Lindgren (1): Merge branch 'for_3.2/3_omap_devicetree' of git://gitorious.org/omap-pm/linux into dt are available in the git repository at: git://github.com/tmlind/linux.git sram-map-io Tony Lindgren (6): ARM: OMAP1: Use generic map_io, init_early and init_irq ARM: OMAP: Avoid cpu_is_omap usage until map_io is done ARM: OMAP: Remove calls to SRAM allocations for framebuffer ARM: OMAP: Map SRAM later on with ioremap_exec() ARM: OMAP: Move set_globals initialization to happen in init_early ARM: OMAP: Warn if omap_ioremap is called before SoC detection arch/arm/mach-omap1/board-ams-delta.c| 16 +--- arch/arm/mach-omap1/board-fsample.c | 76 +- arch/arm/mach-omap1/board-generic.c | 16 +--- arch/arm/mach-omap1/board-h2.c | 16 +--- arch/arm/mach-omap1/board-h3.c | 16 +--- arch/arm/mach-omap1/board-htcherald.c| 12 +-- arch/arm/mach-omap1/board-innovator.c| 36 - arch/arm/mach-omap1/board-nokia770.c | 34 +++- arch/arm/mach-omap1/board-osk.c | 16 +--- arch/arm/mach-omap1/board-palmte.c | 16 +--- arch/arm/mach-omap1/board-palmtt.c | 16 +--- arch/arm/mach-omap1/board-palmz71.c | 18 + arch/arm/mach-omap1/board-perseus2.c | 75 +- arch/arm/mach-omap1/board-sx1.c | 17 +--- arch/arm/mach-omap1/board-voiceblue.c| 16 +--- arch/arm/mach-omap1/devices.c|3 + arch/arm/mach-omap1/io.c | 57 ++ arch/arm/mach-omap2/board-omap3beagle.c |7 +-- arch/arm/mach-omap2/board-ti8168evm.c|1 - arch/arm/mach-omap2/common.c | 50 ++-- arch/arm/mach-omap2/control.c| 16 +--- arch/arm/mach-omap2/io.c | 127 +++--- arch/arm/mach-omap2/io.h |7 -- arch/arm/mach-omap2/omap-smp.c |7 +- arch/arm/mach-omap2/prcm.c | 19 ++--- arch/arm/mach-omap2/sdrc.c | 13 +-- arch/arm/plat-omap/include/plat/common.h | 17 +++-- arch/arm/plat-omap/include/plat/io.h | 29 ++- arch/arm/plat-omap/io.c | 10 +++ arch/arm/plat-omap/sram.c| 85 +--- 30 files changed, 335 insertions(+), 509 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 -- 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
[RFC] Change ECC algorithm from userspace
Hello, We've a custom board using an ARM OMAP DM3730 whose ROM boot loader only supports 1-bit ECC correction using Hamming algorithm. So, in order to be able to boot from the NAND, we have to configure the GPMC (OMAP's memory controller that interfaces with NAND devices) to use 1-bit HW ECC and write the loader binary to the first NAND sector. That way the ROM boot will take this sector as valid and load the loader binary to RAM. The problem is that the SLC NAND device that we are using has a minimum required ECC of 4-bit correction per each 512 bytes. I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? What is the best approach to store data in a NAND device using different ECC techniques? I've think of two approaches: 1- Adding an ioctl to mtdchar (something like ECCSETBITS) to change the ECC technique used. 2- Use a platform data field to notify the omap2 nand driver that the ROM boot only supports 1-bit ECC. So it can use a 1-bit ECC to write and read the first 4 sectors but a 4-bit ECC for the rest. Of course both approaches can only be used if the none of the nand memory partitions are mounted. Thank you and best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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: [GIT PULL] pending DT patches and cleanup for map_io for v3.2 merge window
On Fri, Oct 28, 2011 at 11:39:21AM +0200, Tony Lindgren wrote: FYI, the ioremap_exec patch seems is available as commit 6c5482d53f195d3ca61c9ec1be25b0f4a92575fe (ARM: 7129/1: Add __arm_ioremap_exec for mapping external memory) in Russell's for-linus branch. And is in mainline. -- 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] Change ECC algorithm from userspace
Hi, Javier Martinez Canillas a écrit : Hello, I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? We use raw programming and compute the ecc in software. What is the best approach to store data in a NAND device using different ECC techniques? I've think of two approaches: 1- Adding an ioctl to mtdchar (something like ECCSETBITS) to change the ECC technique used. But this won't work if there is concurrent acess to mtd. One program may want 1 bit ecc other want 4 bits ecc. 2- Use a platform data field to notify the omap2 nand driver that the ROM boot only supports 1-bit ECC. So it can use a 1-bit ECC to write and read the first 4 sectors but a 4-bit ECC for the rest. This may be better. Matthieu PS : note that some OMAP ROM support a better protection than Hamming (but the details are not public AFAIK) From OMAP34xx Multimedia Device, Silicon Revision 3.1.x, public version : Pages can contain errors caused by memory alteration. To correct these errors, the ROM code uses ECC, based on Hamming codes for SLC NAND and BCH (Bose, Ray-Chaudhuri, Hocquenghem) code for multilevel cell (MLC) devices. The computed ECC is compared to ECC stored in the spare area of the corresponding page. If there are uncorrectable errors, the ROM code returns with FAIL. -- 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] Change ECC algorithm from userspace
Jon Povey a écrit : linux-mtd-boun...@lists.infradead.org wrote: I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC layout to Linux. What is the best approach to store data in a NAND device using different ECC techniques? What I have done is write a utility that calculates ECC and writes to the mtd device in RAW mode. So to rewrite the bootloader I take care of the ECC and layout at application level without changing the kernel. Note that the kernel raw mode doesn't write the page in one time : it write data and then ecc. This may cause problem with NOP1 nand. see http://lists.infradead.org/pipermail/linux-mtd/2010-August/031262.html Matthieu -- 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] Change ECC algorithm from userspace
Javier: That's why most people boot from NOR Flash where a 1-bit ECC is adequate. I don't see how you can possibly expect to reliably, successfully boot from a NAND Flash using just 1 bit ECC; you've either got to change the boot loader to allow more ECC or use more-reliable Flash hardware. Atlant -Original Message- From: linux-mtd-boun...@lists.infradead.org [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of Javier Martinez Canillas Sent: Friday, October 28, 2011 05:43 To: linux-...@lists.infradead.org; linux-omap@vger.kernel.org Cc: Enric Balletbo i Serra Subject: [RFC] Change ECC algorithm from userspace Hello, We've a custom board using an ARM OMAP DM3730 whose ROM boot loader only supports 1-bit ECC correction using Hamming algorithm. So, in order to be able to boot from the NAND, we have to configure the GPMC (OMAP's memory controller that interfaces with NAND devices) to use 1-bit HW ECC and write the loader binary to the first NAND sector. That way the ROM boot will take this sector as valid and load the loader binary to RAM. The problem is that the SLC NAND device that we are using has a minimum required ECC of 4-bit correction per each 512 bytes. I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? What is the best approach to store data in a NAND device using different ECC techniques? I've think of two approaches: 1- Adding an ioctl to mtdchar (something like ECCSETBITS) to change the ECC technique used. 2- Use a platform data field to notify the omap2 nand driver that the ROM boot only supports 1-bit ECC. So it can use a 1-bit ECC to write and read the first 4 sectors but a 4-bit ECC for the rest. Of course both approaches can only be used if the none of the nand memory partitions are mounted. Thank you and best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ Click https://www.mailcontrol.com/sr/y76zW8+ioPrTndxI!oX7Ulvwl1GqFAPr!F7OwTKhhUGNVQ5EfYl!2UQwm7gCP9RqaL!eAyER2lwjp+mmMV7JIw== to report this email as spam. This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email.
[PATCH v9 0/4] cpuidle: Global registration of idle states with per-cpu statistics
Version 6 of this patch series dated 22nd Sept 2011 was Acked-by: Arjan van de Ven ar...@linux.intel.com Acked-by: Kevin Hilman khil...@ti.com for OMAP specific parts. Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Jean Pihet j-pi...@ti.com Hi Len, Can you please queue this series for the next mainline merge window by merging it into your development tree and also linux-next for further testing. I have also tested it by applying these patches on your ACPI tree hosted @github. Thanks -Deepthi -- The following patch series implements global registration of cpuidle states, and also has the necessary data structure changes to accommodate the per-cpu writable members of the cpuidle_states structure. This patch series had been in discussion earlier and following are the links to the previous discussions. v8 -- https://lkml.org/lkml/2011/10/3/52 v7 -- https://lkml.org/lkml/2011/9/27/74 v6 -- https://lkml.org/lkml/2011/9/22/58 v5 -- https://lkml.org/lkml/2011/6/6/259 v4 -- https://lkml.org/lkml/2011/4/28/312 v3 -- https://lkml.org/lkml/2011/2/8/73 v2 -- https://lkml.org/lkml/2011/1/13/98 v1 -- https://lkml.org/lkml/2011/3/22/161 Changes from previous version (v8): 1. Rebased and tested on 3.1 Tests done: 1. Compile tested for ARM using the following configs: da8xx_omapl_defconfig, kirkwood_defconfig, omap2plus_defconfig, at91rm9200_defconfig 2. Boot tested on x86 nehalem with multiple C-states for both intel_idle and acpi_idle drivers. 3. Boot tested on T60p thinkpad that has T2600 cpu with multiple C-states. Also tested the case when there is dynamic changes in C-states AC - Battery Power switch. Brief description of the patches: Core change in this series is to split the cpuidle_device structure into two parts, i.e global and per-cpu basis. The per-cpu pieces are mostly generic statistics that can be independent of current running driver. As a result of these changes, there is single copy of cpuidle_states structure and single registration done by one cpu. The low level driver is free to set per-cpu driver data on each cpu if needed using the cpuidle_set_statedata() as the case today. Only in very rare cases asymmetric C-states exist which can be handled within the cpuidle driver. Most architectures do not have asymmetric C-states. First two patches in the series facilitate splitting of cpuidle_states and cpuidle_device structure and next two patches do the actual split, change the API's and make existing code follow the changed API. [1/4] - Move the idle residency accounting part from cpuidle.c to the respective low level drivers, so that the accounting can be accurately maintained if the driver decides to demote the chosen (suggested) by the governor. [2/4] - removes the cpuidle_device()-prepare API since is is not widely used and the only use case was to allow software demotion using CPUIDLE_FLAG_IGNORE flag. Both these functions can be absorbed within the cpuidle back-end driver ad hence deprecating the prepare routine and the CPUIDLE_FLAG_IGNORE flag. - Ref: https://lkml.org/lkml/2011/3/25/52 [3/4] - Splits the usage statistics (read/write) part out of cpuidle_state structure, so that the states can become read only and hence made global. [4/4] - Most APIs will now need to pass pointer to both global cpuidle_driver and per-cpu cpuidle_device structure. arch/arm/mach-at91/cpuidle.c | 41 +++-- arch/arm/mach-davinci/cpuidle.c | 51 --- arch/arm/mach-exynos4/cpuidle.c | 30 ++-- arch/arm/mach-kirkwood/cpuidle.c | 42 +++--- arch/arm/mach-omap2/cpuidle34xx.c | 133 +++-- arch/sh/kernel/cpu/shmobile/cpuidle.c | 28 ++-- drivers/acpi/processor_driver.c | 20 --- drivers/acpi/processor_idle.c | 251 +++-- drivers/cpuidle/cpuidle.c | 86 --- drivers/cpuidle/driver.c | 25 +++ drivers/cpuidle/governors/ladder.c| 41 - drivers/cpuidle/governors/menu.c | 29 ++-- drivers/cpuidle/sysfs.c | 22 ++- drivers/idle/intel_idle.c | 130 + include/acpi/processor.h |1 include/linux/cpuidle.h | 52 --- 16 files changed, 650 insertions(+), 332 deletions(-) -- -Deepthi -- 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 v9 1/4] cpuidle: Move dev-last_residency update to driver enter routine; remove dev-last_state
Cpuidle governor only suggests the state to enter using the
governor-select() interface, but allows the low level driver to
override the recommended state. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver and can be accounted
correctly. Current cpuidle code uses last_state field to capture the
actual state entered and based on that updates the statistics for the
state entered.
Ideally the driver enter routine should update the counters,
and it should return the state actually entered rather than the time
spent there. The generic cpuidle code should simply handle where
the counters live in the sysfs namespace, not updating the counters.
Reference:
https://lkml.org/lkml/2011/3/25/52
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
Tested-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Acked-by: Arjan van de Ven ar...@linux.intel.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-at91/cpuidle.c | 10 +++-
arch/arm/mach-davinci/cpuidle.c |9 +++-
arch/arm/mach-exynos4/cpuidle.c |7 ++-
arch/arm/mach-kirkwood/cpuidle.c | 12 -
arch/arm/mach-omap2/cpuidle34xx.c | 67 +
arch/sh/kernel/cpu/shmobile/cpuidle.c | 12 +++--
drivers/acpi/processor_idle.c | 75 ++---
drivers/cpuidle/cpuidle.c | 32 +++---
drivers/cpuidle/governors/ladder.c| 13 ++
drivers/cpuidle/governors/menu.c |7 ++-
drivers/idle/intel_idle.c | 12 -
include/linux/cpuidle.h |7 +--
12 files changed, 164 insertions(+), 99 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 1cfeac1..4696a0d 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,7 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
struct timeval before, after;
int idle_time;
@@ -41,10 +41,10 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
do_gettimeofday(before);
- if (state == dev-states[0])
+ if (index == 0)
/* Wait for interrupt state */
cpu_do_idle();
- else if (state == dev-states[1]) {
+ else if (index == 1) {
asm(b 1f; .align 5; 1:);
asm(mcr p15, 0, r0, c7, c10, 4); /* drain write buffer */
saved_lpr = sdram_selfrefresh_enable();
@@ -55,7 +55,9 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ dev-last_residency = idle_time;
+ return index;
}
/* Initialize CPU idle by registering the idle states */
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index bd59f31..ca8582a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,9 +78,9 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(state);
+ struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
struct timeval before, after;
int idle_time;
@@ -98,7 +98,10 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ dev-last_residency = idle_time;
+
+ return index;
}
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-exynos4/cpuidle.c
index bf7e96f..ea026e7 100644
--- a/arch/arm/mach-exynos4/cpuidle.c
+++ b/arch/arm/mach-exynos4/cpuidle.c
@@ -16,7 +16,7 @@
#include asm/proc-fns.h
static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state);
+ int index);
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -37,7 +37,7 @@ static struct cpuidle_driver exynos4_idle_driver = {
};
static int exynos4_enter_idle(struct cpuidle_device *dev,
-
[PATCH v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev-prepare()
The cpuidle_device-prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time. State demotion is now handled by the driver and it returns
the actual state entered. Hence, this mechanism is not required.
Also this removes per-cpu flags from cpuidle_state enabling
it to be made global.
Reference:
https://lkml.org/lkml/2011/3/25/52
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
Tested-by: Jean Pihet j-pi...@ti.com
Acked-by: Arjan van de Ven ar...@linux.intel.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
drivers/cpuidle/cpuidle.c| 10 --
drivers/cpuidle/governors/menu.c |2 --
include/linux/cpuidle.h |3 ---
3 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 8faf3a6..984d178 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -83,16 +83,6 @@ int cpuidle_idle_call(void)
hrtimer_peek_ahead_timers();
#endif
- /*
-* Call the device's prepare function before calling the
-* governor's select function. -prepare gives the device's
-* cpuidle driver a chance to update any dynamic information
-* of its cpuidle states for the current idle period, e.g.
-* state availability, latencies, residencies, etc.
-*/
- if (dev-prepare)
- dev-prepare(dev);
-
/* ask the governor for the next state */
next_state = cpuidle_curr_governor-select(dev);
if (need_resched()) {
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 3c44c53..31dd287 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -288,8 +288,6 @@ static int menu_select(struct cpuidle_device *dev)
for (i = CPUIDLE_DRIVER_STATE_START; i dev-state_count; i++) {
struct cpuidle_state *s = dev-states[i];
- if (s-flags CPUIDLE_FLAG_IGNORE)
- continue;
if (s-target_residency data-predicted_us)
continue;
if (s-exit_latency latency_req)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 8da811b..c6d85cf 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -47,7 +47,6 @@ struct cpuidle_state {
/* Idle State Flags */
#define CPUIDLE_FLAG_TIME_VALID(0x01) /* is residency time measurable?
*/
-#define CPUIDLE_FLAG_IGNORE(0x100) /* ignore during this idle period */
#define CPUIDLE_DRIVER_FLAGS_MASK (0x)
@@ -93,8 +92,6 @@ struct cpuidle_device {
struct completion kobj_unregister;
void*governor_data;
int safe_state_index;
-
- int (*prepare) (struct cpuidle_device *dev);
};
DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
--
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 v9 3/4] cpuidle: Split cpuidle_state structure and move per-cpu statistics fields
This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
Tested-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Acked-by: Arjan van de Ven ar...@linux.intel.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-davinci/cpuidle.c |5 ++--
arch/arm/mach-omap2/cpuidle34xx.c | 13 ++
drivers/acpi/processor_idle.c | 25 ++--
drivers/cpuidle/cpuidle.c | 11 +
drivers/cpuidle/sysfs.c | 19 ++-
drivers/idle/intel_idle.c | 46 +++--
include/linux/cpuidle.h | 25
7 files changed, 90 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index ca8582a..f2d2f34 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -80,7 +80,8 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
static int davinci_enter_idle(struct cpuidle_device *dev,
int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
+ struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
struct timeval before, after;
int idle_time;
@@ -142,7 +143,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
strcpy(device-states[1].desc, WFI and DDR Self Refresh);
if (pdata-ddr2_pdown)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
- cpuidle_set_statedata(device-states[1], davinci_states[1]);
+ cpuidle_set_statedata(device-states_usage[1], davinci_states[1]);
device-state_count = DAVINCI_CPUIDLE_MAX_STATES;
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 58425c7..d3fce7b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -97,7 +97,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
int index)
{
struct omap3_idle_statedata *cx =
- cpuidle_get_statedata(dev-states[index]);
+ cpuidle_get_statedata(dev-states_usage[index]);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
int idle_time;
@@ -160,8 +160,9 @@ return_sleep_time:
static int next_valid_state(struct cpuidle_device *dev,
int index)
{
+ struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
struct cpuidle_state *curr = dev-states[index];
- struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr);
+ struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
int next_index = -1;
@@ -202,7 +203,7 @@ static int next_valid_state(struct cpuidle_device *dev,
*/
idx--;
for (; idx = 0; idx--) {
- cx = cpuidle_get_statedata(dev-states[idx]);
+ cx = cpuidle_get_statedata(dev-states_usage[idx]);
if ((cx-valid)
(cx-mpu_state = mpu_deepest_state)
(cx-core_state = core_deepest_state)) {
@@ -231,7 +232,6 @@ static int next_valid_state(struct cpuidle_device *dev,
static int omap3_enter_idle_bm(struct cpuidle_device *dev,
int index)
{
- struct cpuidle_state *state = dev-states[index];
int new_state_idx;
u32 core_next_state, per_next_state = 0, per_saved_state = 0, cam_state;
struct omap3_idle_statedata *cx;
@@ -264,7 +264,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
* Prevent PER off if CORE is not in retention or off as this
* would disable PER wakeups completely.
*/
- cx = cpuidle_get_statedata(state);
+ cx = cpuidle_get_statedata(dev-states_usage[index]);
core_next_state = cx-core_state;
per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
if ((per_next_state == PWRDM_POWER_OFF)
@@ -318,6 +318,7 @@ static inline struct omap3_idle_statedata *_fill_cstate(
{
struct omap3_idle_statedata *cx = omap3_idle_data[idx];
struct cpuidle_state *state = dev-states[idx];
+ struct cpuidle_state_usage *state_usage = dev-states_usage[idx];
[PATCH v9 4/4] cpuidle: Single/Global registration of idle states
This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driver
and architectures such as POWER do not have asymmetric C-states.
Having single/global registration of all the idle states,
dynamic C-state transitions on x86 are handled by
the boot cpu. Here, the boot cpu would disable all the devices,
re-populate the states and later enable all the devices,
irrespective of the cpu that would receive the notification first.
Reference:
https://lkml.org/lkml/2011/4/25/83
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
Tested-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Acked-by: Arjan van de Ven ar...@linux.intel.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-at91/cpuidle.c | 31 +++--
arch/arm/mach-davinci/cpuidle.c | 39 ---
arch/arm/mach-exynos4/cpuidle.c | 23 ++--
arch/arm/mach-kirkwood/cpuidle.c | 30 +++--
arch/arm/mach-omap2/cpuidle34xx.c | 73 -
arch/sh/kernel/cpu/shmobile/cpuidle.c | 18 ++-
drivers/acpi/processor_driver.c | 20 +--
drivers/acpi/processor_idle.c | 191 +
drivers/cpuidle/cpuidle.c | 45 ++--
drivers/cpuidle/driver.c | 25
drivers/cpuidle/governors/ladder.c| 28 +++--
drivers/cpuidle/governors/menu.c | 20 ++-
drivers/cpuidle/sysfs.c |3 -
drivers/idle/intel_idle.c | 80 +++---
include/acpi/processor.h |1
include/linux/cpuidle.h | 19 ++-
16 files changed, 439 insertions(+), 207 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 4696a0d..93178f6 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,6 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct timeval before, after;
@@ -64,27 +65,29 @@ static int at91_enter_idle(struct cpuidle_device *dev,
static int at91_init_cpuidle(void)
{
struct cpuidle_device *device;
-
- cpuidle_register_driver(at91_idle_driver);
+ struct cpuidle_driver *driver = at91_idle_driver;
device = per_cpu(at91_cpuidle_device, smp_processor_id());
device-state_count = AT91_MAX_STATES;
+ driver-state_count = AT91_MAX_STATES;
/* Wait for interrupt state */
- device-states[0].enter = at91_enter_idle;
- device-states[0].exit_latency = 1;
- device-states[0].target_residency = 1;
- device-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[0].name, WFI);
- strcpy(device-states[0].desc, Wait for interrupt);
+ driver-states[0].enter = at91_enter_idle;
+ driver-states[0].exit_latency = 1;
+ driver-states[0].target_residency = 1;
+ driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver-states[0].name, WFI);
+ strcpy(driver-states[0].desc, Wait for interrupt);
/* Wait for interrupt and RAM self refresh state */
- device-states[1].enter = at91_enter_idle;
- device-states[1].exit_latency = 10;
- device-states[1].target_residency = 1;
- device-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[1].name, RAM_SR);
- strcpy(device-states[1].desc, WFI and RAM Self Refresh);
+ driver-states[1].enter = at91_enter_idle;
+ driver-states[1].exit_latency = 10;
+ driver-states[1].target_residency = 1;
+ driver-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver-states[1].name, RAM_SR);
+ strcpy(driver-states[1].desc, WFI and RAM Self Refresh);
+
+ cpuidle_register_driver(at91_idle_driver);
if (cpuidle_register_device(device)) {
printk(KERN_ERR at91_init_cpuidle: Failed registering\n);
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index f2d2f34..dbeeccd 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,6 +78,7 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct cpuidle_state_usage *state_usage =
RE: [RFC] Change ECC algorithm from userspace
linux-mtd-boun...@lists.infradead.org wrote: I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC layout to Linux. What is the best approach to store data in a NAND device using different ECC techniques? What I have done is write a utility that calculates ECC and writes to the mtd device in RAW mode. So to rewrite the bootloader I take care of the ECC and layout at application level without changing the kernel. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network -- 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] Change ECC algorithm from userspace
On Fri, Oct 28, 2011 at 12:30 PM, Matthieu CASTET matthieu.cas...@parrot.com wrote: Hi, Javier Martinez Canillas a écrit : Hello, I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? We use raw programming and compute the ecc in software. Hi Matthieu, We also thought that solution but it wasn't clear for me if doing a RAW write to the mtd device I skip the NAND driver and could also write the oob section without that value being recalculate and rewrite by the driver. What is the best approach to store data in a NAND device using different ECC techniques? I've think of two approaches: 1- Adding an ioctl to mtdchar (something like ECCSETBITS) to change the ECC technique used. But this won't work if there is concurrent acess to mtd. One program may want 1 bit ecc other want 4 bits ecc. 2- Use a platform data field to notify the omap2 nand driver that the ROM boot only supports 1-bit ECC. So it can use a 1-bit ECC to write and read the first 4 sectors but a 4-bit ECC for the rest. This may be better. Matthieu PS : note that some OMAP ROM support a better protection than Hamming (but the details are not public AFAIK) From OMAP34xx Multimedia Device, Silicon Revision 3.1.x, public version : Pages can contain errors caused by memory alteration. To correct these errors, the ROM code uses ECC, based on Hamming codes for SLC NAND and BCH (Bose, Ray-Chaudhuri, Hocquenghem) code for multilevel cell (MLC) devices. The computed ECC is compared to ECC stored in the spare area of the corresponding page. If there are uncorrectable errors, the ROM code returns with FAIL. Yes I've read that on the DM3730 TRM but as far as I understand only applies to MLC devices, but ours is SLC. Thank you and best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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] Change ECC algorithm from userspace
On Fri, Oct 28, 2011 at 12:33 PM, Jon Povey jon.po...@racelogic.co.uk wrote: linux-mtd-boun...@lists.infradead.org wrote: I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC layout to Linux. What is the best approach to store data in a NAND device using different ECC techniques? What I have done is write a utility that calculates ECC and writes to the mtd device in RAW mode. So to rewrite the bootloader I take care of the ECC and layout at application level without changing the kernel. Hi Jon, Thanks for your help. I see that both you and Matthieu use the same approach so I guess that is the common workaround for this problem. I will do the same. Is your utility publicly available? It would be great if I can use it as an starting point. Thank you and best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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: HSI framework for linux-next
On Fri, 2011-10-28 at 12:27 +0300, Carlos Chinea wrote: Hi Stephen, I have been working in an HSI framework for linux: https://lkml.org/lkml/2011/6/10/280 The framework is in good shape and is currently being used for some people so we would like it to see it integrated, if possible, for 3.3 Latest discussion for integration: https://lkml.org/lkml/2011/10/20/177 Stephen, I confirm that this is useful and solid framework, works well, and we are also interested to see it upstream. Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [RFC] Change ECC algorithm from userspace
Javier Martinez Canillas a écrit : On Fri, Oct 28, 2011 at 12:30 PM, Matthieu CASTET matthieu.cas...@parrot.com wrote: PS : note that some OMAP ROM support a better protection than Hamming (but the details are not public AFAIK) From OMAP34xx Multimedia Device, Silicon Revision 3.1.x, public version : Pages can contain errors caused by memory alteration. To correct these errors, the ROM code uses ECC, based on Hamming codes for SLC NAND and BCH (Bose, Ray-Chaudhuri, Hocquenghem) code for multilevel cell (MLC) devices. The computed ECC is compared to ECC stored in the spare area of the corresponding page. If there are uncorrectable errors, the ROM code returns with FAIL. Yes I've read that on the DM3730 TRM but as far as I understand only applies to MLC devices, but ours is SLC. It also works on SLC devices. We are using it on micron slc that need 4 bits ECC. Matthieu -- 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] Change ECC algorithm from userspace
On Fri, Oct 28, 2011 at 1:51 PM, Matthieu CASTET matthieu.cas...@parrot.com wrote: Javier Martinez Canillas a écrit : On Fri, Oct 28, 2011 at 12:30 PM, Matthieu CASTET matthieu.cas...@parrot.com wrote: PS : note that some OMAP ROM support a better protection than Hamming (but the details are not public AFAIK) From OMAP34xx Multimedia Device, Silicon Revision 3.1.x, public version : Pages can contain errors caused by memory alteration. To correct these errors, the ROM code uses ECC, based on Hamming codes for SLC NAND and BCH (Bose, Ray-Chaudhuri, Hocquenghem) code for multilevel cell (MLC) devices. The computed ECC is compared to ECC stored in the spare area of the corresponding page. If there are uncorrectable errors, the ROM code returns with FAIL. Yes I've read that on the DM3730 TRM but as far as I understand only applies to MLC devices, but ours is SLC. It also works on SLC devices. We are using it on micron slc that need 4 bits ECC. That is a great thing to know, I didn't get that from the documentation (DM3730 TRM). And this ECC scheme that is supported for SLC devices it is also BCH? Or the ROM boot uses a different algorithm to calculate the codes to be stored on the oob? Thank and best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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
[RFC 0/1] change prcm chain handler to support pad to irq mapping
Hi, The following patch supports pad to irq mapping for the PRCM IO wakeups. This patch applies on top of the PRCM chain handler set (v9) from me. Any comments welcome, I will most likely add this to the next version of the PRCM chain set, but will send this as an RFC for now. -Tero Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 0115040-6. Domicile: Helsinki -- 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
[RFC] omap: mux: add support for selecting mpu_irq for each wakeup pad
By default all registered pads will trigger mpu_irqs[0]. Now there is
an API for selecting used mpu_irq on pad basis, which can be used to
trigger different irq handlers for different pads in the same hwmod.
Each pad that requires its interrupt to be re-routed this way must
have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq).
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c| 53 +++---
arch/arm/mach-omap2/omap_hwmod.c |7 ---
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 ++
3 files changed, 51 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 642fe3f..cfe36ee 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -354,6 +354,33 @@ err1:
return NULL;
}
+int omap_hwmod_pad_route_irq(struct omap_hwmod *oh, int pad_idx,
+ int irq_idx)
+{
+ int nr_irqs;
+
+ if (!oh || !oh-mux || !oh-mpu_irqs || pad_idx 0 ||
+ pad_idx = oh-mux-nr_pads_dynamic)
+ return -EINVAL;
+
+ /* Check the number of available mpu_irqs */
+ for (nr_irqs = 0; oh-mpu_irqs[nr_irqs].irq = 0; nr_irqs++)
+ ;
+
+ if (irq_idx = nr_irqs)
+ return -EINVAL;
+
+ if (!oh-mux-irqs) {
+ oh-mux-irqs = kzalloc(sizeof(int) * oh-mux-nr_pads_dynamic,
+ GFP_KERNEL);
+ if (!oh-mux-irqs)
+ return -ENOMEM;
+ }
+ oh-mux-irqs[pad_idx] = irq_idx;
+
+ return 0;
+}
+
/**
* omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
* @hmux: Pads for a hwmod
@@ -362,11 +389,13 @@ err1:
* Returns true if wakeup event is set for pad else false
* if wakeup is not occured or pads are not avialable.
*/
-bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+static bool omap_hwmod_mux_scan_wakeups(struct omap_hwmod_mux_info *hmux,
+ struct omap_hwmod_irq_info *mpu_irqs)
{
int i;
unsigned int val;
- u8 ret = false;
+ u32 handled_irqs = 0;
+ int irq;
for (i = 0; i hmux-nr_pads; i++) {
struct omap_device_pad *pad = hmux-pads[i];
@@ -375,15 +404,27 @@ bool omap_hwmod_mux_get_wake_status(struct
omap_hwmod_mux_info *hmux)
val = omap_mux_read(pad-partition,
pad-mux-reg_offset);
if (val OMAP_WAKEUP_EVENT) {
- ret = true;
pr_info(wkup detected: %04x\n,
pad-mux-reg_offset);
- break;
+ if (hmux-irqs) {
+ irq = hmux-irqs[i];
+ /*
+* make sure we only handle each
+* irq once
+*/
+ if (handled_irqs 1 irq)
+ continue;
+
+ handled_irqs |= 1 irq;
+
+ generic_handle_irq(mpu_irqs[irq].irq);
+ } else
+ return true;
}
}
}
- return ret;
+ return false;
}
/**
@@ -396,7 +437,7 @@ static int _omap_hwmod_mux_handle_irq(struct omap_hwmod
*oh, void *data)
{
if (!oh-mux || !oh-mux-enabled)
return 0;
- if (omap_hwmod_mux_get_wake_status(oh-mux))
+ if (omap_hwmod_mux_scan_wakeups(oh-mux, oh-mpu_irqs))
generic_handle_irq(oh-mpu_irqs[0].irq);
return 0;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a8b24d7..e751dd9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2724,10 +2724,3 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
-
-int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
-{
- if (oh oh-mux)
- return omap_hwmod_mux_get_wake_status(oh-mux);
- return -EINVAL;
-}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 9c70cc8..4a89a06 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -97,6 +97,7 @@ struct omap_hwmod_mux_info {
struct omap_device_pad *pads;
int nr_pads_dynamic;
struct omap_device_pad **pads_dynamic;
+ int *irqs;
boolenabled;
};
@@ -607,6 +608,9 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
Hi Again,
I created a new version of the patch which should be better than this
hack, I'll send it as an RFC to the l-o list in a bit.
On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote:
On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote:
On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
0115040-6. Kotipaikka: Helsinki
Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business
ID: 0115040-6. Domicile: Helsinki
Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID:
0115040-6. Domicile: Helsinki
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com
wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:
But the question arises here , why do we need these ehci and ohci
as
two
different hwmods containing only irq and base address? It is
required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods for
ehci
and ohci are needed to enable prcm chain-handler to uniquely
identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci
and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by tero
Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.
Hello Tero,
I would like to draw your attention to the following thread:
We need to support the following:
1. Ability to associate multiple mux info to a hwmod.
2. Able to associate a particular irq handler to a mux info.
3. PRCM Chain handler should loop through all mux-info arrays
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, Oct 28, 2011 at 5:33 PM, Tero Kristo t-kri...@ti.com wrote:
Hi Again,
I created a new version of the patch which should be better than this
hack, I'll send it as an RFC to the l-o list in a bit.
cool ! our discussion helped me.
please send the patch..
On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote:
On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote:
On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
0115040-6. Kotipaikka: Helsinki
Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business
ID: 0115040-6. Domicile: Helsinki
Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID:
0115040-6. Domicile: Helsinki
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com
wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:
But the question arises here , why do we need these ehci and ohci
as
two
different hwmods containing only irq and base address? It is
required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods
for
ehci
and ohci are needed to enable prcm chain-handler to uniquely
identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci
and
ohci hwmods to enable I/O wakeup capability for respective
IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for
ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by
tero
Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32 mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.
Hello Tero,
I would like to draw your attention to the following thread:
We need to support the following:
1. Ability to associate
RE: [PATCH v2] arm: omap: Fix errors and warnings when building for one board
-Original Message- From: Premi, Sanjeev Sent: Thursday, October 13, 2011 9:44 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: Premi, Sanjeev Subject: [PATCH v2] arm: omap: Fix errors and warnings when building for one board When customizing omap2plus_defconfig to build for only one board (omap3evm), I came across these warnings and errors (filenames truncated): arch/arm/mach-omap2/board-generic.c:76:20: warning: 'omap4_init' defined but not used arch/arm/mach-omap2/built-in.o: In function `omap2420_init_early': arch/arm/mach-omap2/io.c:364: undefined reference to `omap2_set_globals_242x' arch/arm/mach-omap2/io.c:366: undefined reference to `omap2xxx_voltagedomains_init' arch/arm/mach-omap2/io.c:367: undefined reference to `omap242x_powerdomains_init' arch/arm/mach-omap2/io.c:368: undefined reference to `omap242x_clockdomains_init' arch/arm/mach-omap2/io.c:369: undefined reference to `omap2420_hwmod_init' arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early': arch/arm/mach-omap2/io.c:376: undefined reference to `omap2_set_globals_243x' arch/arm/mach-omap2/io.c:378: undefined reference to `omap2xxx_voltagedomains_init' arch/arm/mach-omap2/io.c:379: undefined reference to `omap243x_powerdomains_init' arch/arm/mach-omap2/io.c:380: undefined reference to `omap243x_clockdomains_init' arch/arm/mach-omap2/io.c:381: undefined reference to `omap2430_hwmod_init' arch/arm/mach-omap2/built-in.o: In function `omap4430_init_early': arch/arm/mach-omap2/io.c:436: undefined reference to `omap2_set_globals_443x' arch/arm/mach-omap2/io.c:438: undefined reference to `omap44xx_voltagedomains_init' arch/arm/mach-omap2/io.c:439: undefined reference to `omap44xx_powerdomains_init' arch/arm/mach-omap2/io.c:440: undefined reference to `omap44xx_clockdomains_init' arch/arm/mach-omap2/io.c:441: undefined reference to `omap44xx_hwmod_init' This patch fixes them. Signed-off-by: Sanjeev Premi pr...@ti.com --- Changes since v1: - #if defined() to #ifdef - Moved an #ifdef to take care of additional warning related to sdp4430_twldata. Had missed squashing the patch before sending v1. Adding ifdefs makes the code bit ugly and is prone to propagate further. Not sure if DT will help here, but this patch would be useful for people trying to build for individual boards. Compile tested for OMAP3EVM. Applies to linux-omap/master at: fb4df0f : ARM: OMAP1: Fix warnings about enabling 32 KiHz timer arch/arm/mach-omap2/board-generic.c |8 arch/arm/mach-omap2/io.c|6 ++ 2 files changed, 14 insertions(+), 0 deletions(-) Tony, Just wanted to check the status of this patch. ~sanjeev-- 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 v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev-prepare()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/28/2011 3:50 AM, Deepthi Dharwar wrote: The cpuidle_device-prepare() mechanism causes updates to the cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE to tell the governor not to chose a state on a per-cpu basis at run-time. State demotion is now handled by the driver and it returns the actual state entered. Hence, this mechanism is not required. Also this removes per-cpu flags from cpuidle_state enabling it to be made global. having worked on some newer platforms this one is really still needed. doing this inside the actual states does not work, because if the deepest 3 states are invalid, the same (somewhat expensive) test would have to be done 3 times, and each of the states would have to fail before the 4th one gets chosen. that's just not going to work (in the state handler you can't know what other state to fall back to, and especially not how to enter such a fallback state) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJOqrsGAAoJEEHdSxh4DVnEu7EH/i5lEJctBAIubJOcZz/tvBFp XYmAe/HqNtSXeHOVsJkTf8y4ppE8487exF7xxMik4GRN0CZNCtkyMezqDVu+eDim O/UUbScsAc5cSY6mkjOFXLFup+mi1nkRUnAbxXEyTMhWwcbfr2OvcuO7l7TmATML hu87P3PVEafEop3q2+uWMc57fFxnNFfEDqRx6N9V+OJKV5dHrRYL4G4E01fYGFLo xTR0IW7nB15L0C29zk9uk/Dqow8SoJZA83c7p7AieP5zdntb6p7noIf03qmdp19f fulwMwembCHivo+pLO+jAMhKD1T6VYoCyiYW0LHrQ2E07fayBhFJCxlazgKFcl0= =FL6o -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HSI framework for linux-next
On Friday 28 October 2011 04:53 PM, Artem Bityutskiy wrote: On Fri, 2011-10-28 at 12:27 +0300, Carlos Chinea wrote: Hi Stephen, I have been working in an HSI framework for linux: https://lkml.org/lkml/2011/6/10/280 The framework is in good shape and is currently being used for some people so we would like it to see it integrated, if possible, for 3.3 Latest discussion for integration: https://lkml.org/lkml/2011/10/20/177 Stephen, I confirm that this is useful and solid framework, works well, and we are also interested to see it upstream. Yes also it may help others to hook up their controller support. Thanks! -- 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 17/51] ARM: OMAP: convert reset to use arm_arch_reset (fwd)
fyi
- Paul
-- Forwarded message --
Date: Fri, 28 Oct 2011 15:43:45 +0100
From: Will Deacon will.dea...@arm.com
To: linux-arm-ker...@lists.infradead.org
Cc: Paul Walmsley p...@pwsan.com, Will Deacon will.dea...@arm.com
Subject: [PATCH 17/51] ARM: OMAP: convert reset to use arm_arch_reset
From: Paul Walmsley p...@pwsan.com
Align the OMAP reset code with Will Deacon's ARM: reset: introduce
arm_arch_reset function pointer cleanup patch.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/arm/mach-omap1/board-voiceblue.c|2 +-
arch/arm/mach-omap1/io.c |4
arch/arm/mach-omap1/reset.c |2 --
arch/arm/mach-omap2/io.c |7 ++-
arch/arm/mach-omap2/prcm.c |4 +---
arch/arm/plat-omap/include/plat/system.h |6 +-
6 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap1/board-voiceblue.c
b/arch/arm/mach-omap1/board-voiceblue.c
index 036edc0e..e2a24a0 100644
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ b/arch/arm/mach-omap1/board-voiceblue.c
@@ -296,7 +296,7 @@ static void __init voiceblue_init(void)
omap_writeb(0x00, OMAP_LPG1_LCR);
omap_writeb(0x00, OMAP_LPG1_PMR); /* Disable clock */
- arch_reset = voiceblue_reset;
+ arm_arch_reset = voiceblue_reset;
}
MACHINE_START(VOICEBLUE, VoiceBlue OMAP5910)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 870886a..d3b54da 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -15,8 +15,10 @@
#include asm/tlb.h
#include asm/mach/map.h
+#include asm/system.h
#include plat/mux.h
#include plat/tc.h
+#include plat/system.h
#include clock.h
@@ -140,6 +142,8 @@ void __init omap1_init_common_hw(void)
omap1_clk_init();
omap1_mux_init();
+
+ arm_arch_reset = omap1_arch_reset;
}
/*
diff --git a/arch/arm/mach-omap1/reset.c b/arch/arm/mach-omap1/reset.c
index ad951ee..a5ed979 100644
--- a/arch/arm/mach-omap1/reset.c
+++ b/arch/arm/mach-omap1/reset.c
@@ -21,5 +21,3 @@ void omap1_arch_reset(char mode, const char *cmd)
omap_writew(1, ARM_RSTCT1);
}
-
-void (*arch_reset)(char, const char *) = omap1_arch_reset;
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2ce1ce6..b94e1a2 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -31,6 +31,7 @@
#include plat/sram.h
#include plat/sdrc.h
#include plat/serial.h
+#include plat/system.h
#include clock2xxx.h
#include clock3xxx.h
@@ -44,6 +45,8 @@
#include plat/omap_hwmod.h
#include plat/multi.h
+#include prcm-common.h
+
/*
* The machine specific code may provide the extra mapping besides the
* default mapping provided here.
@@ -358,7 +361,9 @@ void __init omap2_init_common_infrastructure(void)
omap44xx_hwmod_init();
} else {
pr_err(Could not init hwmod data - unknown SoC\n);
-}
+ }
+
+ arm_arch_reset = omap_prcm_arch_reset;
/* Set the default postsetup state for all hwmods */
#ifdef CONFIG_PM_RUNTIME
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 2e40a5c..ad3ac5c 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -58,7 +58,7 @@ u32 omap_prcm_get_reset_sources(void)
EXPORT_SYMBOL(omap_prcm_get_reset_sources);
/* Resets clock rates and reboots the system. Only called from system.h */
-static void omap_prcm_arch_reset(char mode, const char *cmd)
+void omap_prcm_arch_reset(char mode, const char *cmd)
{
s16 prcm_offs = 0;
@@ -109,8 +109,6 @@ static void omap_prcm_arch_reset(char mode, const char *cmd)
omap2_prm_read_mod_reg(prcm_offs, OMAP2_RM_RSTCTRL); /* OCP barrier */
}
-void (*arch_reset)(char, const char *) = omap_prcm_arch_reset;
-
/**
* omap2_cm_wait_idlest - wait for IDLEST bit to indicate module readiness
* @reg: physical address of module IDLEST register
diff --git a/arch/arm/plat-omap/include/plat/system.h
b/arch/arm/plat-omap/include/plat/system.h
index c5fa9e9..ac32d88 100644
--- a/arch/arm/plat-omap/include/plat/system.h
+++ b/arch/arm/plat-omap/include/plat/system.h
@@ -12,6 +12,10 @@ static inline void arch_idle(void)
cpu_do_idle();
}
-extern void (*arch_reset)(char, const char *);
+/* To be removed in a future ARM-wide cleanup */
+static inline void arch_reset(char mode, const char *cmd) {}
+
+extern void omap1_arch_reset(char mode, const char *cmd);
+extern void omap_prcm_arch_reset(char mode, const char *cmd);
#endif
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HSI framework for linux-next
Hi Carlos, On Fri, 28 Oct 2011 12:27:46 +0300 Carlos Chinea carlos.chi...@nokia.com wrote: I have been working in an HSI framework for linux: https://lkml.org/lkml/2011/6/10/280 The framework is in good shape and is currently being used for some people so we would like it to see it integrated, if possible, for 3.3 Latest discussion for integration: https://lkml.org/lkml/2011/10/20/177 Therefore, could you add the following tree to linux-next ? I will try to remember, but if I forget, then ping me when v3.2-rc1 has been released. I don't put future code into linux-next until after -rc1 to save false problems with the stuff that has still not been sent to Linus. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpvjAHilnK97.pgp Description: PGP signature
[PATCH] regulator: provide dummy supply support
Hi, The following patch allows it for boards to register a dummy supply for devices for which no software controllable regulator is available. The current CONFIG_REGULATOR_DUMMY and (unused) regulator_use_dummy_regulator() mechanisms only allow to provide a dummy regulator for *all* devices for which no regulator is found. This would shadow real errors and thus is not really an option for production kernels. This patch may eventually superseed the current all-or-nothing approach. This came to me while looking over Linus' smsc911x regulator support patch and so I added all people affected by this patch to Cc. Sascha -- 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] regulator: Provide dummy supply support
Currently we have CONFIG_REGULATOR_DUMMY which provides a fallback
dummy regulator if none is found. Enabling this option shadows
real regulator_get errors though and can't be used in production.
Also there is regulator_use_dummy_regulator() which has the
same behaviour but can be used during runtime.
This patch allows a board to register dummy supplies for devices
which need a regulator but which is not software controllable
on this board.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/regulator/Makefile|2 +-
drivers/regulator/dummy-supply.c | 88 +
include/linux/regulator/machine.h | 18
3 files changed, 107 insertions(+), 1 deletions(-)
create mode 100644 drivers/regulator/dummy-supply.c
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 040d5aa..ff618b9 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -3,7 +3,7 @@
#
-obj-$(CONFIG_REGULATOR) += core.o dummy.o
+obj-$(CONFIG_REGULATOR) += core.o dummy.o dummy-supply.o
obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
diff --git a/drivers/regulator/dummy-supply.c b/drivers/regulator/dummy-supply.c
new file mode 100644
index 000..4e62b1f
--- /dev/null
+++ b/drivers/regulator/dummy-supply.c
@@ -0,0 +1,88 @@
+/*
+ * dummy-supply.c
+ *
+ * Copyright 2011 Sascha Hauer s.ha...@pengutronix.de, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This is useful for systems with mixed controllable and
+ * non-controllable regulators, as well as for allowing testing on
+ * systems with no controllable regulators.
+ */
+#include linux/err.h
+#include linux/slab.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+
+struct dummy_regulator {
+ struct regulator_desc desc;
+ struct regulator_init_data initdata;
+ struct regulator_dev *rdev;
+};
+
+static struct regulator_ops dummy_ops;
+
+/**
+ * regulator_register_dummy - register a dummy supply
+ *
+ * Calling this function will register a dummy regulator
+ * for devices for which no software controllable regulator
+ * is available.
+ */
+struct dummy_regulator *regulator_register_dummy(
+ struct regulator_consumer_supply *__supply,
+ int num_supplies)
+{
+ struct dummy_regulator *dummy;
+ struct regulator_consumer_supply *supply;
+
+ dummy = kzalloc(sizeof(*dummy), GFP_KERNEL);
+ if (!dummy)
+ return NULL;
+
+ dummy-desc.name = dummy;
+ dummy-desc.id = -1;
+ dummy-desc.type = REGULATOR_VOLTAGE;
+ dummy-desc.owner = THIS_MODULE;
+ dummy-desc.ops = dummy_ops;
+
+ supply = kzalloc(sizeof(*supply) * num_supplies, GFP_KERNEL);
+ if (!supply)
+ goto err_alloc;
+ memcpy(supply, __supply, sizeof(*supply) * num_supplies);
+
+ dummy-initdata.num_consumer_supplies = num_supplies;
+ dummy-initdata.consumer_supplies = supply,
+
+ dummy-rdev = regulator_register(dummy-desc, NULL,
+ dummy-initdata, NULL);
+ if (!dummy-rdev)
+ goto err_register;
+
+ return dummy;
+
+err_register:
+ kfree(supply);
+err_alloc:
+ kfree(dummy);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(regulator_register_dummy);
+
+/**
+ * regulator_unregister_dummy - unregister a dummy supply
+ *
+ * This function unregisters a supply previously registered
+ * with regulator_register_dummy.
+ */
+void regulator_unregister_dummy(struct dummy_regulator *dummy)
+{
+ regulator_unregister(dummy-rdev);
+ kfree(dummy-initdata.consumer_supplies);
+ kfree(dummy);
+}
+EXPORT_SYMBOL_GPL(regulator_unregister_dummy);
diff --git a/include/linux/regulator/machine.h
b/include/linux/regulator/machine.h
index ce3127a..13245cb 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -186,12 +186,20 @@ struct regulator_init_data {
void *driver_data; /* core does not touch this */
};
+/**
+ * cookie for regulator_register_dummy
+ */
+struct dummy_regulator;
+
int regulator_suspend_prepare(suspend_state_t state);
int regulator_suspend_finish(void);
#ifdef CONFIG_REGULATOR
void regulator_has_full_constraints(void);
void regulator_use_dummy_regulator(void);
+struct dummy_regulator *regulator_register_dummy(
+ struct regulator_consumer_supply *, int);
+void regulator_unregister_dummy(struct dummy_regulator *);
#else
static inline void regulator_has_full_constraints(void)
{
@@ -200,6 +208,16 @@ static inline void regulator_has_full_constraints(void)
Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
Hi Linus, On Thu, Oct 27, 2011 at 02:48:11PM +0200, Linus Walleij wrote: From: Robert Marklund robert.markl...@stericsson.com Add some basic regulator support for the power pins, as needed by the ST-Ericsson Snowball platform that powers up the SMSC911 chip using an external regulator. Platforms that use regulators and the smsc911x and have no defined regulator for the smsc911x and claim complete regulator constraints with no dummy regulators will need to provide it, for example using a fixed voltage regulator. It appears that this may affect (apart from Ux500 Snowball) possibly these archs/machines that from some grep:s appear to define both CONFIG_SMSC911X and CONFIG_REGULATOR: - ARM Freescale mx3 and OMAP 2 plus, Raumfeld machines - Blackfin - Super-H ... + +/* + * Request or free resources, currently just regulators. + * + * The SMSC911x has two power pins: vddvario and vdd33a, in designs where + * these are not always-on we need to request regulators to be turned on + * before we can try to access the device registers. + */ +static int smsc911x_request_free_resources(struct platform_device *pdev, + bool request) I had to look twice at this function name. First I thought request the free resources?, which other resources would you request if not the free ones? I think it would be nicer to have two functions instead. Just my 2 cents. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] regulator: provide dummy supply support
On Fri, Oct 28, 2011 at 10:26:57PM +0200, Sascha Hauer wrote: The following patch allows it for boards to register a dummy supply for devices for which no software controllable regulator is available. The current CONFIG_REGULATOR_DUMMY and (unused) regulator_use_dummy_regulator() Please don't send cover letters for single patch serieses, if there's content it should probably be in the changelog... -- 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] regulator: Provide dummy supply support
On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote: drivers/regulator/Makefile|2 +- drivers/regulator/dummy-supply.c | 88 + We already have a dummy regulator driver and a fixed voltage regulator driver, we shouldn't be adding a third implementation of the same thing. Just use the fixed voltage regulator for this. -- 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] regulator: Provide dummy supply support
On Fri, Oct 28, 2011 at 11:59:31PM +0200, Mark Brown wrote: On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote: drivers/regulator/Makefile|2 +- drivers/regulator/dummy-supply.c | 88 + We already have a dummy regulator driver and a fixed voltage regulator driver, we shouldn't be adding a third implementation of the same thing. Just use the fixed voltage regulator for this. I explained in my mail why I think that the current implementation of the dummy regulator is not suitable for things apart from debugging. My main concern with the fixed regulator is that it needs quite much boilerplate code just to say that we have no regulator at all for a given device. That could also be handled with a helper function which registers a fixed regulator and only takes the regulator_consumer_supply as an argument. Would that be ok for you? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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/1] omap: serial: Add RS-485 standard support
This patch adds TIA/EIA-485 standard support to OMAP-UART controller driver
by adding handlers for TIOCSRS485 and TIOCGRS485 ioctl commands.
This patch is based on Ilya Yanok ya...@emcraft.com patch [1] but it changes
the function serial_omap_update_rts() that raises and lows the Ready-to-Send
control signal. Also, it forces to update the RTS signal when the serial-core
calls serial_omap_set_mctrl().
[1]: http://www.spinics.net/lists/linux-omap/msg58546.html
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |2 +
drivers/tty/serial/Makefile |2 +-
drivers/tty/serial/omap-serial.c | 139 ++--
include/linux/serial_reg.h|2 +
4 files changed, 132 insertions(+), 13 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 2682043..b7c2c29 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -111,6 +111,8 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
charname[20];
unsigned long port_activity;
+ struct serial_rs485 rs485;
+ unsigned inttx_in_progress:1, tx_wait_end:1;
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 83b4da6..865f238 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -71,7 +71,7 @@ obj-$(CONFIG_SERIAL_VR41XX) += vr41xx_siu.o
obj-$(CONFIG_SERIAL_SGI_IOC4) += ioc4_serial.o
obj-$(CONFIG_SERIAL_SGI_IOC3) += ioc3_serial.o
obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
-obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
+#obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
obj-$(CONFIG_SERIAL_MSM_HS) += msm_serial_hs.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 5e713d3..d1789f4 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -37,6 +37,7 @@
#include linux/clk.h
#include linux/serial_core.h
#include linux/irq.h
+#include linux/uaccess.h
#include plat/dma.h
#include plat/dmtimer.h
@@ -114,6 +115,56 @@ static void serial_omap_enable_ms(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
+static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
+{
+ if (!(up-ier UART_IER_THRI)) {
+ up-ier |= UART_IER_THRI;
+ serial_out(up, UART_IER, up-ier);
+ }
+}
+
+static inline void serial_omap_disable_ier_thri(struct uart_omap_port *up)
+{
+ if (up-ier UART_IER_THRI) {
+ up-ier = ~UART_IER_THRI;
+ serial_out(up, UART_IER, up-ier);
+ }
+}
+
+static inline void serial_omap_thri_mode(struct uart_omap_port *up)
+{
+ unsigned char scr = serial_in(up, UART_OMAP_SCR);
+
+ if (up-tx_wait_end)
+ scr |= UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+ else
+ scr = ~UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+ serial_out(up, UART_OMAP_SCR, scr);
+}
+
+
+static inline void serial_omap_update_rts(struct uart_omap_port *up)
+{
+ unsigned char mcr = up-mcr;
+ int rts_on_send = up-rs485.flags SER_RS485_RTS_ON_SEND;
+
+ if (up-rs485.flags SER_RS485_ENABLED) {
+ if (up-tx_in_progress) {
+ if (rts_on_send)
+ mcr |= UART_MCR_RTS;
+ else
+ mcr = ~UART_MCR_RTS;
+ } else {
+ if (rts_on_send)
+ mcr = ~UART_MCR_RTS;
+ else
+ mcr |= ~UART_MCR_RTS;
+ }
+ }
+
+ serial_out(up, UART_MCR, mcr);
+}
+
static void serial_omap_stop_tx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -131,9 +182,14 @@ static void serial_omap_stop_tx(struct uart_port *port)
up-uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
}
- if (up-ier UART_IER_THRI) {
- up-ier = ~UART_IER_THRI;
- serial_out(up, UART_IER, up-ier);
+ if (!(up-rs485.flags SER_RS485_ENABLED))
+ serial_omap_disable_ier_thri(up);
+ else {
+ up-tx_in_progress = 0;
+ serial_omap_update_rts(up);
+ up-tx_wait_end = 1;
+ serial_omap_thri_mode(up);
+ serial_omap_enable_ier_thri(up);
}
}
@@ -246,14 +302,6 @@ static void transmit_chars(struct uart_omap_port *up)
serial_omap_stop_tx(up-port);
}
-static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
-{
- if (!(up-ier UART_IER_THRI)) {
- up-ier
Re: [PATCH] regulator: Provide dummy supply support
On Sat, Oct 29, 2011 at 00:47, Sascha Hauer wrote: On Fri, Oct 28, 2011 at 11:59:31PM +0200, Mark Brown wrote: On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote: drivers/regulator/Makefile | 2 +- drivers/regulator/dummy-supply.c | 88 + We already have a dummy regulator driver and a fixed voltage regulator driver, we shouldn't be adding a third implementation of the same thing. Just use the fixed voltage regulator for this. I explained in my mail why I think that the current implementation of the dummy regulator is not suitable for things apart from debugging. My main concern with the fixed regulator is that it needs quite much boilerplate code just to say that we have no regulator at all for a given device. That could also be handled with a helper function which registers a fixed regulator and only takes the regulator_consumer_supply as an argument. Would that be ok for you? i think Mark's point is that we have code in dummy.c already to provide a dummy regulator. so your needs sounds like it could be satisfied with some Kconfig/ifdef massaging and the existing drivers/regulator/dummy.c rather than introducing a completely parallel file that is always enabled ? -mike -- 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] regulator: provide dummy supply support
On Fri, Oct 28, 2011 at 23:57, Mark Brown wrote: On Fri, Oct 28, 2011 at 10:26:57PM +0200, Sascha Hauer wrote: The following patch allows it for boards to register a dummy supply for devices for which no software controllable regulator is available. The current CONFIG_REGULATOR_DUMMY and (unused) regulator_use_dummy_regulator() Please don't send cover letters for single patch serieses, if there's content it should probably be in the changelog... sorry for the additional noise, but +1 -mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
On Fri, Oct 28, 2011 at 22:33, Sascha Hauer wrote: On Thu, Oct 27, 2011 at 02:48:11PM +0200, Linus Walleij wrote: +/* + * Request or free resources, currently just regulators. + * + * The SMSC911x has two power pins: vddvario and vdd33a, in designs where + * these are not always-on we need to request regulators to be turned on + * before we can try to access the device registers. + */ +static int smsc911x_request_free_resources(struct platform_device *pdev, + bool request) I had to look twice at this function name. First I thought request the free resources?, which other resources would you request if not the free ones? I think it would be nicer to have two functions instead. Just my 2 cents. i'll add my 2 cents and we'll almost have a nickle. maybe i'm dense, but i had to look (more than) twice at both funcs before i could get my head around what was happening. no, it's not complicated, but it is unusual in the kernel world. either that or i haven't read enough kernel code to consider this a common paradigm. hopefully it's the former ;). -mike -- 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] usb: ehci: report Data Buffer Error in debug mode
From: Vikram Pandita vikram.pand...@ti.com
Data Buffer Error as per spec section 4.15.1.1.2
results when there is Underrun or Overrun condition.
This error is considered non-fatal and never gets reported.
Its a very good indication on things going wrong at system level,
like running memory at much slower speed.
This is a good error to flag allowing system level corrections.
An issue was found with OMAP4460 board where DDR had to be run
at full speed and this logging helped.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/usb/host/ehci-q.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 4e4066c..2451361 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -373,6 +373,20 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh *qh)
retry_xacterr:
if ((token QTD_STS_ACTIVE) == 0) {
+ /* Report Data Buffer Error: non-fatal but useful */
+ if (token QTD_STS_DBE) {
+
+ ehci_dbg(ehci,
+ detected DataBufferErr %s for urb %p ep%d%s
len %d, qtd %p [qh %p]\n,
+ (urb-ep-desc.bEndpointAddress USB_DIR_IN) ?
+ OVER-RUN : UNDER-RUN,
+ urb, urb-ep-desc.bEndpointAddress 0x0f,
+ (urb-ep-desc.bEndpointAddress USB_DIR_IN) ?
in : out,
+ urb-transfer_buffer_length,
+ qtd, urb-ep-hcpriv);
+
+ }
+
/* on STALL, error, and short reads this urb must
* complete and all its qtds must be recycled.
*/
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: report Data Buffer Error in debug mode
From: Vikram Pandita vikram.pand...@ti.com
Data Buffer Error as per spec section 4.15.1.1.2
results when there is Underrun or Overrun condition.
This error is considered non-fatal and never gets reported.
Its a very good indication on things going wrong at system level,
like running memory at much slower speed.
This is a good error to flag allowing system level corrections.
An issue was found with OMAP4460 board where DDR had to be run
at full speed and this logging helped.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/usb/host/ehci-q.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 4e4066c..2451361 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -373,6 +373,20 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh
*qh) retry_xacterr:
if ((token QTD_STS_ACTIVE) == 0) {
+ /* Report Data Buffer Error: non-fatal but useful */
+ if (token QTD_STS_DBE) {
+
+ ehci_dbg(ehci,
+ detected DataBufferErr %s for urb %p ep%d%s
len
%d, qtd %p [qh
%p]\n, + (urb-ep-desc.bEndpointAddress
USB_DIR_IN) ?
+ OVER-RUN : UNDER-RUN,
+ urb, urb-ep-desc.bEndpointAddress 0x0f,
+ (urb-ep-desc.bEndpointAddress USB_DIR_IN) ?
in : out,
+ urb-transfer_buffer_length,
+ qtd, urb-ep-hcpriv);
+
+ }
+
/* on STALL, error, and short reads this urb must
* complete and all its qtds must be recycled.
*/
Looks basically ok to me.
Reviewed-by: Marek Vasut marek.va...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH] ARM: OMAP: Fix build for OMAP3 only builds
Thank you Sekhar,
Can you please test the following patch
[PATCH v2] arm: omap: Fix errors and warnings when building for one board
ThomasN�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
