Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
David Vrabel wrote: On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. I'll try to update the patches in the next few days. David -- Sincerely yours, 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] OMAP PM: MPU/DMA Latency constraints
Kevin, Paul,
Do you have any comments on this patch?
Regards
Vishwa
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
Sent: Tuesday, August 10, 2010 10:43 AM
To: Kevin Hilman
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH] OMAP PM: MPU/DMA Latency constraints
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, August 09, 2010 11:59 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP PM: MPU/DMA Latency constraints
Vishwanath Sripathy vishwanath...@ti.com writes:
This patch has implementation for OMAP MPU/DMA Latency constraints using
PM
QOS.
Changelog is missing description of the problem being solved and the
motivation for the solution.
In particular, a system-wide API is being changed here with no
description of the problem or the reason for this particular solution.
On first glance, the idea here seems wrong. In getting rid of the device
pointer, how do you plan to handle per-device constraints?
Sorry for not being a very descriptive.
The motivation here is to remove the dependency on SRF for implementing
mpu/dma
latency constraints. Instead they have been implemented using pm_qos
infrastructure.
Latest pm_qos apis take pm_qos handle to distinguish different pm_qos
requests (or
use counting mechanism). Hence drivers need to pass pm_qos handle instead of
device pointer. Drivers just to define a handle and this handle gets
initialized when
they make the first request. So from driver's point of view, it's an opaque
handle.
That's why you see the change in signature of the api.
Regards
Vishwa
Kevin
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
---
arch/arm/plat-omap/Kconfig|3 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h |9 +-
arch/arm/plat-omap/omap-pm-noop.c | 20 +--
arch/arm/plat-omap/omap-pm.c | 309
+
6 files changed, 328 insertions(+), 17 deletions(-)
create mode 100755 arch/arm/plat-omap/omap-pm.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 286b606..ce544b0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -194,6 +194,9 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool No-op/debug PM layer
+config OMAP_PM
+ depends on PM
+ bool OMAP PM layer implementation
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 2a15191..fad2475 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM) += omap-pm.o
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..29dc45a
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -145,7 +145,8 @@ static inline int omap1_i2c_add_bus(struct
platform_device
*pdev, int bus_id)
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev,
long
t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ struct pm_qos_request_list *qos_handle = NULL;
+ omap_pm_set_max_mpu_wakeup_lat(qos_handle, t);
}
static inline int omap2_i2c_add_bus(struct platform_device *pdev, int
bus_id)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-
omap/include/plat/omap-pm.h
index 728fbb9..47ba9e6 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,6 +19,7 @@
#include linux/clk.h
#include powerdomain.h
+#include linux/pm_qos_params.h
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
@@ -86,7 +87,7 @@ void omap_pm_if_exit(void);
/**
* omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup
latency
- * @dev: struct device * requesting the constraint
+ * @qos_request: handle for the constraint. The pointer should be
initialized to
NULL
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
@@ -118,7 +119,7 @@ void omap_pm_if_exit(void);
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list
**qos_request, long t);
/**
@@ -185,7 +186,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Hello, On Wed, 01 Sep 2010 15:51:40 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: Looking closer at this, keeping track of a list of devices and constraints is what the regulator framework does as well. Before we get too far down this path, we need to start working with Thomas Petazzoni to better understand how we can use the regulator framework for much of the management levels of the voltage layer. Yes, as discussed on IRC with Kevin, I think that some of this voltage layer mechanisms would benefit from using the existing kernel regulator framework. The regulator framework already keeps tracks of consumers (in your patch set called vdd users), and for each consumer, keeps track of the requested voltage. The maximum requested voltage is then applied to the regulator. It seems to fit quite well some of the mechanisms you're introducing in this patch set. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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 1/5] ARM: omap/fb: move omap_init_fb to .init.text
omap_init_fb() is only called as arch_initcall and so can live in
.init.text.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/plat-omap/fb.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 0054b95..a727133 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -336,7 +336,7 @@ void omapfb_set_ctrl_platform_data(void *data)
omapfb_config.ctrl_platform_data = data;
}
-static inline int omap_init_fb(void)
+static int __init omap_init_fb(void)
{
const struct omap_lcd_config *conf;
@@ -381,7 +381,7 @@ void omapfb_set_platform_data(struct omapfb_platform_data
*data)
omapfb_config = *data;
}
-static inline int omap_init_fb(void)
+static int __init omap_init_fb(void)
{
return platform_device_register(omap_fb_device);
}
--
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
[PATCH 4/5] ARM: omap: move omap_get_config et al. to .init.text
All callers of these functions live in .init.text, so these can go there,
too. There they must not be exported anymore, this is no problem though,
as all callers are always built-in.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/plat-omap/common.c |6 ++
arch/arm/plat-omap/include/plat/board.h |4 ++--
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 3008e71..227d985 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -71,17 +71,15 @@ static const void *get_config(u16 tag, size_t len, int
skip, size_t *len_out)
return kinfo-data;
}
-const void *__omap_get_config(u16 tag, size_t len, int nr)
+const void *__init __omap_get_config(u16 tag, size_t len, int nr)
{
return get_config(tag, len, nr, NULL);
}
-EXPORT_SYMBOL(__omap_get_config);
-const void *omap_get_var_config(u16 tag, size_t *len)
+const void *__init omap_get_var_config(u16 tag, size_t *len)
{
return get_config(tag, NO_LENGTH_CHECK, 0, len);
}
-EXPORT_SYMBOL(omap_get_var_config);
void __init omap_reserve(void)
{
diff --git a/arch/arm/plat-omap/include/plat/board.h
b/arch/arm/plat-omap/include/plat/board.h
index 3cf4fa2..97126df 100644
--- a/arch/arm/plat-omap/include/plat/board.h
+++ b/arch/arm/plat-omap/include/plat/board.h
@@ -151,14 +151,14 @@ struct omap_board_config_kernel {
const void *data;
};
-extern const void *__omap_get_config(u16 tag, size_t len, int nr);
+extern const void *__init __omap_get_config(u16 tag, size_t len, int nr);
#define omap_get_config(tag, type) \
((const type *) __omap_get_config((tag), sizeof(type), 0))
#define omap_get_nr_config(tag, type, nr) \
((const type *) __omap_get_config((tag), sizeof(type), (nr)))
-extern const void *omap_get_var_config(u16 tag, size_t *len);
+extern const void *__init omap_get_var_config(u16 tag, size_t *len);
extern struct omap_board_config_kernel *omap_board_config;
extern int omap_board_config_size;
--
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
[PATCH 3/5] ARM: omap/fb: move get_fbmem_region() to .init.text
get_fbmem_region() is only called by omapfb_reserve_sdram_memblock() and
omapfb_reserve_sram() that both live in .init.text. So get_fbmem_region
can go there, too.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/plat-omap/fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 72a36ca..fffc1a0 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -94,7 +94,7 @@ static int fbmem_region_reserved(unsigned long start, size_t
size)
* Get the region_idx`th region from board config/ATAG and convert it to
* our internal format.
*/
-static int get_fbmem_region(int region_idx, struct omapfb_mem_region *rg)
+static int __init get_fbmem_region(int region_idx, struct omapfb_mem_region
*rg)
{
const struct omap_fbmem_config *conf;
u32 paddr;
--
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
[PATCH 2/5] ARM: omap/fb: move omapfb_reserve_sram to .init.text
This function is only called by omap_detect_sram which lives in .init.text,
too.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/plat-omap/fb.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index a727133..72a36ca 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -262,7 +262,7 @@ void __init omapfb_reserve_sdram_memblock(void)
* this point, since the driver built as a module would have problem with
* freeing / reallocating the regions.
*/
-unsigned long omapfb_reserve_sram(unsigned long sram_pstart,
+unsigned long __init omapfb_reserve_sram(unsigned long sram_pstart,
unsigned long sram_vstart,
unsigned long sram_size,
unsigned long pstart_avail,
@@ -392,7 +392,7 @@ void omapfb_reserve_sdram_memblock(void)
{
}
-unsigned long omapfb_reserve_sram(unsigned long sram_pstart,
+unsigned long __init omapfb_reserve_sram(unsigned long sram_pstart,
unsigned long sram_vstart,
unsigned long sram_size,
unsigned long start_avail,
@@ -411,7 +411,7 @@ void omapfb_reserve_sdram_memblock(void)
{
}
-unsigned long omapfb_reserve_sram(unsigned long sram_pstart,
+unsigned long __init omapfb_reserve_sram(unsigned long sram_pstart,
unsigned long sram_vstart,
unsigned long sram_size,
unsigned long start_avail,
--
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
[PATCH 5/5] wip: ARM: omap: move omap_board_config_kernel to .init.data
Probably this works ... --- arch/arm/plat-omap/common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index 227d985..c8451c2 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -46,7 +46,7 @@ #define NO_LENGTH_CHECK 0x -struct omap_board_config_kernel *omap_board_config; +struct omap_board_config_kernel *omap_board_config __initdata; int omap_board_config_size; static const void *get_config(u16 tag, size_t len, int skip, size_t *len_out) -- 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: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
-Original Message- From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev- boun...@lists.linaro.org] On Behalf Of Amit Kucheria Sent: Thursday, September 02, 2010 1:26 PM To: Kevin Hilman Cc: linaro-...@lists.linaro.org; linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement On 10 Aug 27, Kevin Hilman wrote: vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. Kevin, I agree. We discussed this a little in our weekly meeting. Vishwa's main concern was the lack of ability to instrument the last bit of SRAM code. I have a feeling that even with caches on when we enter this code, we won't see too much variance in the latency to execute this bit of code. Vishwa is going to confirm that now. If that hypothesis is true, we can indeed move to using tracepoints in the idle path and use external tools to track latency. There will be difference with and without caches but the delta latency will be constant with caches and without caches. Another important point is he lowest level code should be just profiled once and for worst CPU/BUS clock speed. Even if it isn't true, the rest of the idle path could still contain tracepoints. I also think this would be better approach considering a generic solution. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Thomas Petazzoni had written, on 09/02/2010 02:43 AM, the following: Hello, On Wed, 01 Sep 2010 15:51:40 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: Looking closer at this, keeping track of a list of devices and constraints is what the regulator framework does as well. Before we get too far down this path, we need to start working with Thomas Petazzoni to better understand how we can use the regulator framework for much of the management levels of the voltage layer. Yes, as discussed on IRC with Kevin, I think that some of this voltage layer mechanisms would benefit from using the existing kernel regulator framework. The regulator framework already keeps tracks of consumers (in your patch set called vdd users), and for each consumer, keeps track of the requested voltage. The maximum requested voltage is then applied to the regulator. It seems to fit quite well some of the mechanisms you're introducing in this patch set. Just brainstorming - if we use the regulator framework - there are potential benefits - agreed. BUT, consider the cpuidle path - currently we disable SR while hitting off/ret for class3, this is done in irq locked context while the regulator framework uses locks by itself - we would probably have to evolve an entirely different mechanism to handle this. SR by itself can easily be represented I believe and my thoughts when i initialy looked at that option had been: a) latency overheads b) flexibility we achieve vs complexity in s/w implementation c) lock handling - esp impact on omap_sram_idle paths.. -- Regards, Nishanth Menon PS:personally though concept of latency additions when scaling voltages, disabling SR etc should be a parameter in userspace governor decisions (the fact that cpuidle and cpufreq are independent statemachine is not my personal fav either). But this is a larger topic of discussion not pertinent to this thread.. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Hi Amit, Santosh, On Thu, Sep 2, 2010 at 10:11 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: ... The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. Kevin, I agree. We discussed this a little in our weekly meeting. Vishwa's main concern was the lack of ability to instrument the last bit of SRAM code. I have a feeling that even with caches on when we enter this code, we won't see too much variance in the latency to execute this bit of code. Vishwa is going to confirm that now. If that hypothesis is true, we can indeed move to using tracepoints in the idle path and use external tools to track latency. I agree. Can you confirm this asap? I am looking at the instrumentation tracepoints now. I think it would be ideal to provide multiple tracepoints in both sleep and wake-up paths. There will be difference with and without caches but the delta latency will be constant with caches and without caches. Another important point is he lowest level code should be just profiled once and for worst CPU/BUS clock speed. Ok. Even if it isn't true, the rest of the idle path could still contain tracepoints. I am looking at the best way to introduce tracepoints in the low level code, in case it is needed. I also think this would be better approach considering a generic solution. Good! Regards, Santosh Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
On Thu, 2 Sep 2010 03:17:56 -0500, Nishanth Menon n...@ti.com wrote: Just brainstorming - if we use the regulator framework - there are potential benefits - agreed. BUT, consider the cpuidle path - currently we disable SR while hitting off/ret for class3, this is done in irq locked context while the regulator framework uses locks by itself - we wouldn't it be enough to: spin_unlock(sr_lock); call_whatever_regulator_api(); spin_lock(sr_lock); [...] spin_unlock_irqrestore(sr_lock, flags); ?? otherwise we will have yet another OMAP-only API to maintain. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Felipe Balbi had written, on 09/02/2010 05:00 AM, the following: On Thu, 2 Sep 2010 03:17:56 -0500, Nishanth Menon n...@ti.com wrote: Just brainstorming - if we use the regulator framework - there are potential benefits - agreed. BUT, consider the cpuidle path - currently we disable SR while hitting off/ret for class3, this is done in irq locked context while the regulator framework uses locks by itself - we wouldn't it be enough to: spin_unlock(sr_lock); call_whatever_regulator_api(); spin_lock(sr_lock); [...] spin_unlock_irqrestore(sr_lock, flags); ?? otherwise we will have yet another OMAP-only API to maintain. unfortunately no. look at omap_sram_idle function in arch/arm/mach-omap2/pm34xx.c we do irq_lock_save to prevent interrupts from messing up our decision logic apply a lot of checks to translate C state to mean which domain is going to go to which OMAP domain state mode - ret/off/inactive etc.. add a bunch of erratas on top of it finally see if the core/mpu domains (in case of omap4 ivahd domain as well) is going to ret/off state - if yes, SR is disabled for that domain. note - if we allow unlock of irqs at this point, we cannot predictably progress down the logic. the option is to move up the sr disable out of omap_sram_idle into yet to be determined logic where irqs are enabled, c state is decided and if c state is lower than a threshold (meaning if mpu OR core OR ivahd can go to lower power states), disable SR.. not efficient and without looking deeper at logic and considering multiple omap generations not sure if this will scale either.. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Hi, On Thu, 2 Sep 2010 05:17:01 -0500, Nishanth Menon n...@ti.com wrote: note - if we allow unlock of irqs at this point, we cannot predictably progress down the logic. spin_unlock() would not re-enable IRQs, would it ? Isn't it so that spin_unlock_irq() would be the one re-enabling IRQ ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Felipe Balbi had written, on 09/02/2010 05:28 AM, the following: Hi, On Thu, 2 Sep 2010 05:17:01 -0500, Nishanth Menon n...@ti.com wrote: note - if we allow unlock of irqs at this point, we cannot predictably progress down the logic. spin_unlock() would not re-enable IRQs, would it ? Isn't it so that spin_unlock_irq() would be the one re-enabling IRQ ? oopss.. my bad.. if we were to do regulator based implementation of voltage framework, looking closer at the code, driver/regulator/core.c - rdev-mutex is held for set_voltage, set_mode and all entry functions for regulator operations - this would be the only concern i have.. I may be barking up the wrong tree here, but i think if i read Documentation/mutex-design.txt right, contexts such as tasklets and timers and mutexes may not be used in hardware or software interrupt means to me dont do this in irq locked context such as the sitn in omap_sram_idle? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Hi, On Thu, 2 Sep 2010 05:40:56 -0500, Nishanth Menon n...@ti.com wrote: Felipe Balbi had written, on 09/02/2010 05:28 AM, the following: Hi, On Thu, 2 Sep 2010 05:17:01 -0500, Nishanth Menon n...@ti.com wrote: note - if we allow unlock of irqs at this point, we cannot predictably progress down the logic. spin_unlock() would not re-enable IRQs, would it ? Isn't it so that spin_unlock_irq() would be the one re-enabling IRQ ? oopss.. my bad.. if we were to do regulator based implementation of voltage framework, looking closer at the code, driver/regulator/core.c - rdev-mutex is held for set_voltage, set_mode and all entry functions for regulator operations - this would be the only concern i have.. I may be barking up the wrong tree here, but i think if i read Documentation/mutex-design.txt right, contexts such as tasklets and timers and mutexes may not be used in hardware or software interrupt means to me dont do this in irq locked context such as the sitn in omap_sram_idle? true, some re-work would have to be done if you want to use requlator framework. -- 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: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, September 01, 2010 9:00 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha; Nayak,
Rajendra; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
[...]
+static void omap2_dm_timer_enable(struct platform_device *pdev)
+{
+ if (!pdev) {
+ dev_err(pdev-dev, %s: invalid pdev\n, __func__);
+ return;
+ }
+ pm_runtime_get_sync(pdev-dev);
+}
+
+static void omap2_dm_timer_disable(struct platform_device *pdev)
+{
+ if (!pdev) {
+ dev_err(pdev-dev, %s: invalid pdev\n, __func__);
+ return;
+ }
+ pm_runtime_put_sync(pdev-dev);
+}
There is no need for these functions. Driver should be calling runtime
PM API directly.
In that case, driver will have to make call by directly accessing
acquired timer's internal variables as shown below.
pm_runtime_put_sync(timer-pdev-dev);
However, I believe we would like other drivers' perform all operations
on acquired timers through exported APIs and keep the
pm_runtime_put_sync() call internal to exported APIs as is the case
current implementation.
Let me know if I am missing anything here!!
These new functions are not part of the exported API. You have made
them static, and part of the device layer.
These are created as wrappers to pm_runtime_* API which are then called
by the driver layer. What I suggest is not creating these functions
(and the pdata- function pointers to wrap them) but instead calling the
runtime PM api directly instead of using the pdata- function pointers.
OK.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] initial support for LogicPD's OMAP3530LV SOM and OMAP35x Torpedo dev boards
On Tue, Aug 24, 2010 at 11:53:37PM -0400, Jacob Tanenbaum wrote:
+/* 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
+ * lies in the boot strap code. We correct this part if we have ported
+ * U-Boot and X-Load. */
+void init_sdram(struct omap_sdrc_params *sdrc_cs0){
static? { on the following line?
+ sdrc_cs0[0].actim_ctrla = 0xaa9db4c6;
+ sdrc_cs0[0].actim_ctrlb = 0x00011517;
+ sdrc_cs0[0].rfr_ctrl= 0x0004e201;
+ sdrc_cs0[1].rate= 165941176;
+ sdrc_cs0[1].actim_ctrla = 0xaa9db4c6;
+ sdrc_cs0[1].actim_ctrlb = 0x00011217;
+ sdrc_cs0[1].rfr_ctrl= 0x0004dc01;
+ sdrc_cs0[2].actim_ctrla = 0x8a99b481;
+ sdrc_cs0[2].actim_ctrlb = 0x00011312;
+ sdrc_cs0[2].rfr_ctrl= 0x0003de017;
36-bit hex numbers?
+ sdrc_cs0[3].actim_ctrla = 0x8a99b481;
+ sdrc_cs0[3].actim_ctrlb = 0x00011312;
+ sdrc_cs0[3].rfr_ctrl= 0x0003de01;
+}
+
+static struct regulator_consumer_supply omap3logic_vmmc1_supply = {
+ .supply = vmmc,
Any reason for the additional tabs?
--
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/4] Low-level init of hsmmc controller for LogicPD's OMAP3530LV SOM and OMAP 35x Torpedo dev boards
On Tue, Aug 24, 2010 at 11:53:38PM -0400, Jacob Tanenbaum wrote:
From: jake j...@glados.(none)
Not a valid address... please fix.
ARM: OMAP3LOGIC: Adding SDMMC support
Add low-level initialization for hsmmc controller for
LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board.
Tested against: 81e09f50c93edff607259cbe374a3006c9c5fa74
Signed-off-by: Jacob Tanenbaum jacob.tanenb...@logicpd.com
I'm confused why these comments are indented.
+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 */
missing tab?
+ } 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 */
missing tab?
+ } else {
+ printk(KERN_ERR %s(): unknown machine type\n, __func__);
+ return;
missing tab?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Enabling Ethernet support for LogicPD's OMAP 3530LV SOM and OMAP 35x Torpedo dev board
On Tue, Aug 24, 2010 at 11:53:40PM -0400, Jacob Tanenbaum wrote:
+static inline void __init board_smsc911x_init(void)
+{
+ /* OMAP3530 LV SOM board */
+ if (machine_is_omap3530_lv_som()) {
+ board_smsc911x_data.gpio_irq =
+ OMAP3530_LV_SOM_SMSC911X_GPIO_IRQ;
+ /* board_smsc911x_data.gpio_reset
+ driven by SYS_nRESWARM, no GPIO */
+ /* omap_cfg_reg(AE1_34XX_GPIO152_UP); */
+ omap_mux_init_signal(gpio_152, OMAP_PIN_INPUT);
+
+/* omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);*/
+
+ /* OMAP3 Torpedo board */
missing tab? Maybe it would make sense to put this after the line below?
+ } else if (machine_is_omap3_torpedo()) {
+ board_smsc911x_data.gpio_irq = OMAP3_TORPEDO_SMSC911X_GPIO_IRQ;
+ /* board_smsc911x_data.gpio_reset driven
+ by SYS_nRESWARM, no GPIO */
+ /*omap_cfg_reg(AE1_34XX_GPIO152_UP);*/
+ omap_mux_init_signal(gpio_129, OMAP_PIN_INPUT);
+ /* TODO/FIXME (comment by Peter Barada, LogicPD):
+ * On Torpedo, LAN9221 IRQ is an MMC1_DATA7 pin
+ * and IRQ1760 IRQ is MMC1_DATA4 pin - need
+ * to update PBIAS to get voltage to the device
+ * so the IRQs works correctly rather than float
+ * and cause an IRQ storm...
+ */
+ omap3torpedo_fix_pbias_voltage();
+ /* unsupported board */
missing tab? or maybe it should be moved after the line below.
+ } else {
+ printk(KERN_ERR %s(): unknown machine type\n, __func__);
+ return;
+ }
+ gpmc_smsc911x_init(board_smsc911x_data);
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] Low-level init of hsmmc controller for LogicPD's OMAP3530LV SOM and OMAP 35x Torpedo dev boards
Basically same comments as previous patches. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
On Mon, Aug 30, 2010 at 03:55:27PM -0700, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [100820 04:59]:
* Russell King - ARM Linux li...@arm.linux.org.uk [100819 13:13]:
On Thu, Aug 19, 2010 at 12:57:06PM +0300, Tony Lindgren wrote:
Looks like something is not quite right with smp_on_up part of
__fixup_smp,
returning early before smp_on_up does not produce that.
It's probably overwriting some register it shouldn't be. I might be
able to look at this sometime during the coming week... assuming that
the weather is as bad as they forecast and I have 'net connectivity.
This seems to fix it.
Thanks, merged that into my original patch - so here it is again with
everything updated.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9295110..725a463 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1166,6 +1166,18 @@ config SMP
If you don't know what to do here, say N.
+config SMP_ON_UP
+ bool Allow booting SMP kernel on uniprocessor systems (EXPERIMENTAL)
+ depends on SMP !XIP
+ default y
+ help
+ SMP kernels contain instructions which fail on non-SMP processors.
+ Enabling this option allows the kernel to modify itself to make
+ these instructions safe. Disabling it allows about 1K of space
+ savings.
+
+ If you don' tknow what to do here, say Y.
+
config HAVE_ARM_SCU
bool
depends on SMP
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 6e8f05c..55974d2 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -154,16 +154,32 @@
.long b,9001f;\
.popsection
+#ifdef CONFIG_SMP
+#define SMP(instr...) \
+9998: instr
+#define UP(instr...) \
+ .pushsection .smpalt.init, a;\
+ .word 9998b ;\
+ instr ;\
+ .popsection
+#else
+#define SMP(instr...)
+#define UP(instr...) instr
+#endif
+
/*
* SMP data memory barrier
*/
.macro smp_dmb
#ifdef CONFIG_SMP
#if __LINUX_ARM_ARCH__ = 7
- dmb
+ SMP(dmb)
#elif __LINUX_ARM_ARCH__ == 6
- mcr p15, 0, r0, c7, c10, 5 @ dmb
+ SMP(mcr p15, 0, r0, c7, c10, 5) @ dmb
+#else
+#error Incompatible SMP platform
#endif
+ UP(nop)
#endif
.endm
diff --git a/arch/arm/include/asm/smp_midr.h b/arch/arm/include/asm/smp_midr.h
index e69de29..4538ba4 100644
--- a/arch/arm/include/asm/smp_midr.h
+++ b/arch/arm/include/asm/smp_midr.h
@@ -0,0 +1,17 @@
+#ifndef ASMARM_SMP_MIDR_H
+#define ASMARM_SMP_MIDR_H
+
+#define hard_smp_processor_id()
\
+ ({ \
+ unsigned int cpunum;\
+ __asm__(\n\
+ 1: mrc p15, 0, %0, c0, c0, 5\n\
+ .pushsection \.smpalt.init\, \a\\n \
+ .word 1b\n \
+ mov %0, #0\n \
+ .popsection\
+ : =r (cpunum)); \
+ cpunum = 0x0F; \
+ })
+
+#endif
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 33b546a..1fd0db9 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -70,6 +70,10 @@
#undef _TLB
#undef MULTI_TLB
+#ifdef CONFIG_SMP_ON_UP
+#define MULTI_TLB 1
+#endif
+
#define v3_tlb_flags (TLB_V3_FULL | TLB_V3_PAGE)
#ifdef CONFIG_CPU_TLB_V3
@@ -185,12 +189,15 @@
# define v6wbi_always_flags(-1UL)
#endif
-#ifdef CONFIG_SMP
-#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \
+#define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \
TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID)
-#else
-#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BTB | \
+#define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BTB | \
TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID)
+
+#ifdef CONFIG_SMP
+#define v7wbi_tlb_flagsv7wbi_tlb_flags_smp
+#else
+#define v7wbi_tlb_flagsv7wbi_tlb_flags_up
#endif
#ifdef CONFIG_CPU_TLB_V7
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index bb8e93a..bb2ef60 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -965,11 +965,8 @@ kuser_cmpxchg_fixup:
beq 1b
rsbsr0, r3, #0
/* beware -- each __kuser slot must be 8 instructions max */
[PATCH 0/1] omap-sham: use prefetch mechanism to increase transfer speed
Samu Onkalo (1): crypto: omap-sham: Adjust DMA parameters drivers/crypto/omap-sham.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: otg: twl4030: fix phy initialization
From: Ming Lei tom.leim...@gmail.com Commit 461c317705eca5cac09a360f488715927fd0a927(into 2.6.36-v3) is put forward to power down phy if no usb cable is connected, but does introduce the two issues below: 1), phy is not into work state if usb cable is connected with PC during poweron, so musb device mode is not usable in such case, follows the reasons: -twl4030_phy_resume is not called, so regulators are not enabled i2c access are not enabled usb mode not configurated 2), The kernel warings[1] of regulators 'unbalanced disables' is caused if poweron without usb cable connected with PC or b-device. This patch fixes the two issues above: -power down phy only if no usb cable is connected with PC and b-device -do phy initialization(via __twl4030_phy_resume) if usb cable is connected with PC(vbus event) or another b-device(ID event) in twl4030_usb_probe. This patch is verified OK on Beagle board either connected with usb cable or not when poweron. [1]. warnings of 'unbalanced disables' of regulators. [r...@omap3evm /]# dmesg [ cut here ] WARNING: at drivers/regulator/core.c:1357 _regulator_disable+0x38/0x128() unbalanced disables for VUSB1V8 Modules linked in: Backtrace: [c0030c48] (dump_backtrace+0x0/0x110) from [c034f5a8] (dump_stack+0x18/0x1c) r7:c78179d8 r6:c01ed6b8 r5:c0410822 r4:054d [c034f590] (dump_stack+0x0/0x1c) from [c0057da8] (warn_slowpath_common+0x54/0x6c) [c0057d54] (warn_slowpath_common+0x0/0x6c) from [c0057e64] (warn_slowpath_fmt+0x38/0x40) r9: r8: r7:c78e6608 r6: r5:fffb r4:c78e6c00 [c0057e2c] (warn_slowpath_fmt+0x0/0x40) from [c01ed6b8] (_regulator_disable+0x38/0x128) r3:c0410e53 r2:c0410ad5 [c01ed680] (_regulator_disable+0x0/0x128) from [c01ed87c] (regulator_disable+0x24/0x38) r7:c78e6608 r6: r5:c78e6c40 r4:c78e6c00 [c01ed858] (regulator_disable+0x0/0x38) from [c02382dc] (twl4030_phy_power+0x15c/0x17c) r5:c78595c0 r4: [c0238180] (twl4030_phy_power+0x0/0x17c) from [c023831c] (twl4030_phy_suspend+0x20/0x2c) r6: r5:c78595c0 r4:c78595c0 [c02382fc] (twl4030_phy_suspend+0x0/0x2c) from [c0238638] (twl4030_usb_irq+0x11c/0x16c) r5:c78595c0 r4:0040 [c023851c] (twl4030_usb_irq+0x0/0x16c) from [c034ec18] (twl4030_usb_probe+0x2c4/0x32c) r6: r5: r4:c78595c0 [c034e954] (twl4030_usb_probe+0x0/0x32c) from [c02152a0] (platform_drv_probe+0x20/0x24) r7: r6:c047d49c r5:c78e6608 r4:c047d49c [c0215280] (platform_drv_probe+0x0/0x24) from [c0214244] (driver_probe_device+0xd0/0x190) [c0214174] (driver_probe_device+0x0/0x190) from [c02143d4] (__device_attach+0x44/0x48) r7: r6:c78e6608 r5:c78e6608 r4:c047d49c [c0214390] (__device_attach+0x0/0x48) from [c0213694] (bus_for_each_drv+0x50/0x90) r5:c0214390 r4: [c0213644] (bus_for_each_drv+0x0/0x90) from [c0214474] (device_attach+0x70/0x94) r6:c78e663c r5:c78e6608 r4:c78e6608 [c0214404] (device_attach+0x0/0x94) from [c02134fc] (bus_probe_device+0x2c/0x48) r7: r6:0002 r5:c78e6608 r4:c78e6600 [c02134d0] (bus_probe_device+0x0/0x48) from [c0211e48] (device_add+0x340/0x4b4) [c0211b08] (device_add+0x0/0x4b4) from [c021597c] (platform_device_add+0x110/0x16c) [c021586c] (platform_device_add+0x0/0x16c) from [c0220cb0] (add_numbered_child+0xd8/0x118) r7: r6:c045f15c r5:c78e6600 r4: [c0220bd8] (add_numbered_child+0x0/0x118) from [c001c618] (twl_probe+0x3a4/0x72c) [c001c274] (twl_probe+0x0/0x72c) from [c02601ac] (i2c_device_probe+0x7c/0xa4) [c0260130] (i2c_device_probe+0x0/0xa4) from [c0214244] (driver_probe_device+0xd0/0x190) r5:c7856e20 r4:c047c860 [c0214174] (driver_probe_device+0x0/0x190) from [c02143d4] (__device_attach+0x44/0x48) r7:c7856e04 r6:c7856e20 r5:c7856e20 r4:c047c860 [c0214390] (__device_attach+0x0/0x48) from [c0213694] (bus_for_each_drv+0x50/0x90) r5:c0214390 r4: [c0213644] (bus_for_each_drv+0x0/0x90) from [c0214474] (device_attach+0x70/0x94) r6:c7856e54 r5:c7856e20 r4:c7856e20 [c0214404] (device_attach+0x0/0x94) from [c02134fc] (bus_probe_device+0x2c/0x48) r7:c7856e04 r6:c78fd048 r5:c7856e20 r4:c7856e20 [c02134d0] (bus_probe_device+0x0/0x48) from [c0211e48] (device_add+0x340/0x4b4) [c0211b08] (device_add+0x0/0x4b4) from [c0211fd8] (device_register+0x1c/0x20) [c0211fbc] (device_register+0x0/0x20) from [c0260aa8] (i2c_new_device+0xec/0x150) r5:c7856e00 r4:c7856e20 [c02609bc] (i2c_new_device+0x0/0x150) from [c0260dc0] (i2c_register_adapter+0xa0/0x1c4) r7: r6:c78fd078 r5:c78fd048 r4:c781d5c0 [c0260d20] (i2c_register_adapter+0x0/0x1c4) from [c0260f80] (i2c_add_numbered_adapter+0x9c/0xb4) r7:0a28 r6:c04600a8 r5:c78fd048 r4: [c0260ee4] (i2c_add_numbered_adapter+0x0/0xb4) from [c034efa4] (omap_i2c_probe+0x324/0x3e8) r5: r4:c78fd000 [c034ec80] (omap_i2c_probe+0x0/0x3e8) from [c02152a0] (platform_drv_probe+0x20/0x24) [c0215280] (platform_drv_probe+0x0/0x24) from
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
* Russell King - ARM Linux li...@arm.linux.org.uk [100902 06:29]: On Mon, Aug 30, 2010 at 03:55:27PM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [100820 04:59]: * Russell King - ARM Linux li...@arm.linux.org.uk [100819 13:13]: On Thu, Aug 19, 2010 at 12:57:06PM +0300, Tony Lindgren wrote: Looks like something is not quite right with smp_on_up part of __fixup_smp, returning early before smp_on_up does not produce that. It's probably overwriting some register it shouldn't be. I might be able to look at this sometime during the coming week... assuming that the weather is as bad as they forecast and I have 'net connectivity. This seems to fix it. Thanks, merged that into my original patch - so here it is again with everything updated. Your patch sure makes things simpler! The problem still is the V6 vs V7 SMP code though. Will post my six patches that apply on top of your patch as a reply to this mail. With those, everything seems to work, at least after testing on omap3630 (Cortex-A8 UP) and omap4430 (Cortex-A9 SMP). Will, maybe see if there are some parts in your patchset that should be used instead? I noticed pretty much all the earlier hacks are no longer needed :) 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
[PATCH 1/6] ARM: Add inline function smp_on_up() for early init testing
From 7044c13594c3023da6095f8d432eda260bc3207f Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Mon, 30 Aug 2010 14:00:54 -0700
Subject: [PATCH 1/6] ARM: Add inline function smp_on_up() for early init testing
Add inline function smp_on_up() for early init checks, and
change build_mem_type_table to use it.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/include/asm/smp_plat.h | 16
arch/arm/mm/mmu.c | 20 +++-
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 8db3512..5ef4114 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -39,4 +39,20 @@ static inline int cache_ops_need_broadcast(void)
#define UP(instr...) _str(instr)
#endif
+static inline int smp_on_up(void)
+{
+#ifdef CONFIG_SMP_ON_UP
+ int smp_on_up;
+
+ asm(\
+ SMP(mov %0, #0) \
+ UP(mov %0, #1) \
+ : =r (smp_on_up));
+
+ return smp_on_up;
+#else
+ return 0;
+#endif
+}
+
#endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 6e1c4f6..f320901 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -430,15 +430,17 @@ static void __init build_mem_type_table(void)
/*
* Mark memory with the shared attribute for SMP systems
*/
- user_pgprot |= L_PTE_SHARED;
- kern_pgprot |= L_PTE_SHARED;
- vecs_pgprot |= L_PTE_SHARED;
- mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
- mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
- mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
- mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ if (!smp_on_up()) {
+ user_pgprot |= L_PTE_SHARED;
+ kern_pgprot |= L_PTE_SHARED;
+ vecs_pgprot |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
+ mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ }
#endif
}
--
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
[PATCH 2/6] ARM: Use SMP and UP macros for cacheflush
From 16c866489613ef8ea9d28ecf861f5a7ff4d60377 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Thu, 2 Sep 2010 08:20:02 -0700 Subject: [PATCH 2/6] ARM: Use SMP and UP macros for cacheflush Use SMP and UP macros for cacheflush. Note that __flush_icache_all currently won't work properly on ARMv7 SMP if support for ARMv6 is compiled in. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/include/asm/cacheflush.h |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h index 4656a24..09a893e 100644 --- a/arch/arm/include/asm/cacheflush.h +++ b/arch/arm/include/asm/cacheflush.h @@ -16,6 +16,7 @@ #include asm/shmparam.h #include asm/cachetype.h #include asm/outercache.h +#include asm/smp_plat.h #define CACHE_COLOUR(vaddr)((vaddr (SHMLBA - 1)) PAGE_SHIFT) @@ -372,8 +373,10 @@ static inline void __flush_icache_all(void) extern void v6_icache_inval_all(void); v6_icache_inval_all(); #elif defined(CONFIG_SMP) __LINUX_ARM_ARCH__ = 7 - asm(mcrp15, 0, %0, c7, c1, 0 @ invalidate I-cache inner shareable\n - : + asm(\ + SMP(mcr p15, 0, %0, c7, c1, 0 @ inv I-cache inner shareable) \ + UP(mcr p15, 0, %0, c7, c5, 0 @ invalidate I-cache) \ + : \ : r (0)); #else asm(mcrp15, 0, %0, c7, c5, 0 @ invalidate I-cache\n -- 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
[PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP
From 253e91b76e104dbdf05c5c3eaf9cbf426972c938 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Wed, 1 Sep 2010 16:49:13 -0700 Subject: [PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP Fix v7wbi_tlb_flags for SMP on UP. Note that we must enable MULTI_TLB to avoid undefined reference to cpu_tlb error. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/include/asm/tlbflush.h | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h index 1fd0db9..55e1dd9 100644 --- a/arch/arm/include/asm/tlbflush.h +++ b/arch/arm/include/asm/tlbflush.h @@ -189,20 +189,32 @@ # define v6wbi_always_flags(-1UL) #endif +#define v7wbi_tlb_flags_common (TLB_WB | TLB_DCLEAN) #define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \ TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID) #define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BTB | \ TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID) #ifdef CONFIG_SMP +#ifdef CONFIG_SMP_ON_UP +#define v7wbi_tlb_flags(v7wbi_tlb_flags_smp | v7wbi_tlb_flags_up) +#else #define v7wbi_tlb_flagsv7wbi_tlb_flags_smp +#endif #else #define v7wbi_tlb_flagsv7wbi_tlb_flags_up #endif #ifdef CONFIG_CPU_TLB_V7 # define v7wbi_possible_flags v7wbi_tlb_flags -# define v7wbi_always_flagsv7wbi_tlb_flags +# ifdef CONFIG_SMP_ON_UP +# define v7wbi_always_flags v7wbi_tlb_flags_common +# ifndef MULTI_TLB +# define MULTI_TLB 1 +# endif +# else +# define v7wbi_always_flags v7wbi_tlb_flags +# endif # ifdef _TLB # define MULTI_TLB 1 # else -- 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
[PATCH 4/6] ARM: Do not call test_for_ipi or test_for_ltrirq on UP systems
From f80d3cc85327ba84748646bb44a0c45103ef66bc Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Wed, 1 Sep 2010 20:40:47 -0700 Subject: [PATCH 4/6] ARM: Do not call test_for_ipi or test_for_ltrirq on UP systems Do not call test_for_ipi or test_for_ltrirq on UP systems. Note that we can't put test_for_ltriq into SMP statement as it's inlined into the code and the remaining lines of the macro would still run before UP macro line. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/kernel/entry-armv.S |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index bb2ef60..b8c1ec7 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -40,6 +40,11 @@ bne asm_do_IRQ #ifdef CONFIG_SMP +#ifdef CONFIG_SMP_ON_UP + adr lr, BSYM(2f)@ set lr to end of macro for early return + SMP(nop)@ continue on SMP hardware + UP(mov pc, lr) @ return early on UP +#endif /* * XXX * @@ -57,6 +62,7 @@ adrne lr, BSYM(1b) bne do_local_timer #endif +2: #endif .endm -- 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
[PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7
From 8b22546af2ba9a0d96c2f419bfcec1f3c01a414d Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Mon, 30 Aug 2010 14:03:28 -0700
Subject: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7
Don't set TLB ops broadcasting on UP ARMv7. Looks like these bits
are also different on A8 and A9.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mm/proc-v7.S |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 07fc660..51a063d 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -191,7 +191,8 @@ __v7_setup:
UP(mov r0, #(1 6)) @ fake it for UP
tst r0, #(1 6) @ SMP/nAMP mode enabled?
orreq r0, r0, #(1 6) | (1 0)@ Enable SMP/nAMP mode and
- mcreq p15, 0, r0, c1, c0, 1 @ TLB ops broadcasting
+ SMP(mcreq p15, 0, r0, c1, c0, 1) @ TLB ops broadcasting
+ UP(nop) @ Don't enable on UP
#endif
adr r12, __v7_setup_stack @ the local stack
stmia r12, {r0-r5, r7, r9, r11, lr}
--
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
[PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi-omap
From c04a57fc3b41d886f56ccdc27cf9758de0c95202 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Tue, 17 Aug 2010 13:33:23 +0300
Subject: [PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi-omap
Fix SMP on UP interrupt handling for multi-omap
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap-smp.c | 13 +
arch/arm/mach-omap2/timer-gp.c |7 +--
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 9e9f70e..a8bb49c 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -22,6 +22,7 @@
#include asm/cacheflush.h
#include asm/localtimer.h
+#include asm/smp_plat.h
#include asm/smp_scu.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -114,11 +115,15 @@ void __init smp_init_cpus(void)
{
unsigned int i, ncores;
- /* Never released */
- scu_base = ioremap(OMAP44XX_SCU_BASE, SZ_256);
- BUG_ON(!scu_base);
+ if (smp_on_up()) {
+ ncores = 1;
+ } else {
+ /* Never released */
+ scu_base = ioremap(OMAP44XX_SCU_BASE, SZ_256);
+ BUG_ON(!scu_base);
- ncores = get_core_count();
+ ncores = get_core_count();
+ }
for (i = 0; i ncores; i++)
set_cpu_possible(i, true);
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 74fbed8..badf5f2 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -37,6 +37,7 @@
#include linux/clockchips.h
#include asm/mach/time.h
+#include asm/smp_plat.h
#include plat/dmtimer.h
#include asm/localtimer.h
@@ -228,8 +229,10 @@ static void __init omap2_gp_clocksource_init(void)
static void __init omap2_gp_timer_init(void)
{
#ifdef CONFIG_LOCAL_TIMERS
- twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
- BUG_ON(!twd_base);
+ if (smp_on_up()) {
+ twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
+ BUG_ON(!twd_base);
+ }
#endif
omap_dm_timer_init();
--
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: [PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP
On Thu, Sep 02, 2010 at 09:20:40AM -0700, Tony Lindgren wrote: From 253e91b76e104dbdf05c5c3eaf9cbf426972c938 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Wed, 1 Sep 2010 16:49:13 -0700 Subject: [PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP Fix v7wbi_tlb_flags for SMP on UP. Note that we must enable MULTI_TLB to avoid undefined reference to cpu_tlb error. This isn't required, as it is already covered by my 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
Re: [PATCH 4/4] omap: Fix SMP on UP interrupt handling for multi-omap
* Tony Lindgren t...@atomide.com [100817 04:23]: * srinidhi srinidhi.kasa...@stericsson.com [100817 14:00]: On Tue, 2010-08-17 at 12:53 +0200, Tony Lindgren wrote: Fix SMP on UP interrupt handling for multi-omap Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/include/mach/entry-macro.S | 22 ++ arch/arm/mach-omap2/omap-smp.c | 16 arch/arm/mach-omap2/timer-gp.c |7 +-- 3 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 06e64e1..75c67aa 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S There is one patch lying in Russell's tracker (6284/1) which attempts to use the common IRQ helper macros instead of platforms duplicating this file. Perhaps you may need to re-base to that if Russell is ok with that patch, of course. Nice to see. Ideally test_for_ipi and test_for_ltirq would return early automatically when running SMP kernel on UP. For the record, posted a patch to return early, so no more hacks needed for the entry-macro.S. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP
* Russell King - ARM Linux li...@arm.linux.org.uk [100902 09:18]: On Thu, Sep 02, 2010 at 09:20:40AM -0700, Tony Lindgren wrote: From 253e91b76e104dbdf05c5c3eaf9cbf426972c938 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Wed, 1 Sep 2010 16:49:13 -0700 Subject: [PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP Fix v7wbi_tlb_flags for SMP on UP. Note that we must enable MULTI_TLB to avoid undefined reference to cpu_tlb error. This isn't required, as it is already covered by my patch. Yup, seems to be working without this patch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7
On Thu, Sep 02, 2010 at 09:22:20AM -0700, Tony Lindgren wrote: From 8b22546af2ba9a0d96c2f419bfcec1f3c01a414d Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 30 Aug 2010 14:03:28 -0700 Subject: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7 Don't set TLB ops broadcasting on UP ARMv7. Looks like these bits are also different on A8 and A9. This is already taken care of. diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 07fc660..51a063d 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -191,7 +191,8 @@ __v7_setup: UP(mov r0, #(1 6)) @ fake it for UP If it's UP, we set r0 to 1 6, which... tst r0, #(1 6) @ SMP/nAMP mode enabled? means this test produces a non-zero result. orreq r0, r0, #(1 6) | (1 0)@ Enable SMP/nAMP mode and - mcreq p15, 0, r0, c1, c0, 1 @ TLB ops broadcasting And therefore these instructions will not be executed. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ARM: Add inline function smp_on_up() for early init testing
On Thu, Sep 02, 2010 at 09:18:47AM -0700, Tony Lindgren wrote:
From 7044c13594c3023da6095f8d432eda260bc3207f Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Mon, 30 Aug 2010 14:00:54 -0700
Subject: [PATCH 1/6] ARM: Add inline function smp_on_up() for early init
testing
Add inline function smp_on_up() for early init checks, and
change build_mem_type_table to use it.
Isn't something missing from this - such as a C-mode definition of
SMP() and UP() ?
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 8db3512..5ef4114 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -39,4 +39,20 @@ static inline int cache_ops_need_broadcast(void)
#define UP(instr...) _str(instr)
#endif
+static inline int smp_on_up(void)
+{
+#ifdef CONFIG_SMP_ON_UP
+ int smp_on_up;
+
+ asm(\
+ SMP(mov %0, #0) \
+ UP(mov %0, #1) \
+ : =r (smp_on_up));
+
+ return smp_on_up;
+#else
+ return 0;
+#endif
I think this is the wrong approach - rather than a function which tells us
just if we are a SMP kernel running on UP, why not something which returns
whether we're running on SMP and use that to eliminate some of these ifdefs?
--
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/6] ARM: Add inline function smp_on_up() for early init testing
* Russell King - ARM Linux li...@arm.linux.org.uk [100902 10:00]: On Thu, Sep 02, 2010 at 09:18:47AM -0700, Tony Lindgren wrote: From 7044c13594c3023da6095f8d432eda260bc3207f Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 30 Aug 2010 14:00:54 -0700 Subject: [PATCH 1/6] ARM: Add inline function smp_on_up() for early init testing Add inline function smp_on_up() for early init checks, and change build_mem_type_table to use it. Isn't something missing from this - such as a C-mode definition of SMP() and UP() ? Oops, here's the missing patch. Tony From e52db459dba0088fcff66904069630a24a811db8 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Wed, 1 Sep 2010 15:02:50 -0700 Subject: [PATCH] ARM: Add SMP and UP macros for inline assembly We can't use the macros in asm/assembler.h in C inline functions. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 55974d2..340795c 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -154,6 +154,10 @@ .long b,9001f;\ .popsection +/* + * SMP and UP defines for assembly code. See also asm/smp_plat.h + * for the SMP and UP defines for inline code. + */ #ifdef CONFIG_SMP #define SMP(instr...) \ 9998: instr diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h index e621530..8db3512 100644 --- a/arch/arm/include/asm/smp_plat.h +++ b/arch/arm/include/asm/smp_plat.h @@ -18,4 +18,25 @@ static inline int cache_ops_need_broadcast(void) return ((read_cpuid_ext(CPUID_EXT_MMFR3) 12) 0xf) 1; } +/* + * SMP and UP defines for inline functions. See also asm/assembler.h + * for the SMP and UP defines for assembly code. + */ +#ifdef CONFIG_SMP +#define _str(s...) #s +#define _9998(s...)_str(9998: s\n) + +#define SMP(instr...) \ + _9998(instr) + +#define UP(instr...) \ + _str(.pushsection .smpalt.init, a\n)\ + _str(.word 9998b\n)\ + _str(instr\n) \ + _str(.popsection\n) +#else +#define SMP(instr...) +#define UP(instr...) _str(instr) +#endif + #endif -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7
* Russell King - ARM Linux li...@arm.linux.org.uk [100902 09:50]: On Thu, Sep 02, 2010 at 09:22:20AM -0700, Tony Lindgren wrote: From 8b22546af2ba9a0d96c2f419bfcec1f3c01a414d Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 30 Aug 2010 14:03:28 -0700 Subject: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7 Don't set TLB ops broadcasting on UP ARMv7. Looks like these bits are also different on A8 and A9. This is already taken care of. diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 07fc660..51a063d 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -191,7 +191,8 @@ __v7_setup: UP(mov r0, #(1 6)) @ fake it for UP If it's UP, we set r0 to 1 6, which... tst r0, #(1 6) @ SMP/nAMP mode enabled? means this test produces a non-zero result. orreq r0, r0, #(1 6) | (1 0)@ Enable SMP/nAMP mode and - mcreq p15, 0, r0, c1, c0, 1 @ TLB ops broadcasting And therefore these instructions will not be executed. AFAIK these bits are different for Cortex-A8 and A9, bit 6 is IBE on A8. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ARM: Add inline function smp_on_up() for early init testing
* Russell King - ARM Linux li...@arm.linux.org.uk [100902 10:00]:
On Thu, Sep 02, 2010 at 09:18:47AM -0700, Tony Lindgren wrote:
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -39,4 +39,20 @@ static inline int cache_ops_need_broadcast(void)
#define UP(instr...) _str(instr)
#endif
+static inline int smp_on_up(void)
+{
+#ifdef CONFIG_SMP_ON_UP
+ int smp_on_up;
+
+ asm(\
+ SMP(mov %0, #0) \
+ UP(mov %0, #1) \
+ : =r (smp_on_up));
+
+ return smp_on_up;
+#else
+ return 0;
+#endif
I think this is the wrong approach - rather than a function which tells us
just if we are a SMP kernel running on UP, why not something which returns
whether we're running on SMP and use that to eliminate some of these ifdefs?
Sure. Will has something like this in his patches:
static inline int cpu_is_part_of_mp_system(void)
{
u32 mpidr;
asm volatile(mrc p15, 0, %0, c0, c0, 5 : =r (mpidr));
return (mpidr 31) ? !(mpidr 30) : 0;
}
BTW, so far looks like we should only need this during init to set up things.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Nishanth Menon n...@ti.com writes: Thomas Petazzoni had written, on 09/02/2010 02:43 AM, the following: Hello, On Wed, 01 Sep 2010 15:51:40 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: Looking closer at this, keeping track of a list of devices and constraints is what the regulator framework does as well. Before we get too far down this path, we need to start working with Thomas Petazzoni to better understand how we can use the regulator framework for much of the management levels of the voltage layer. Yes, as discussed on IRC with Kevin, I think that some of this voltage layer mechanisms would benefit from using the existing kernel regulator framework. The regulator framework already keeps tracks of consumers (in your patch set called vdd users), and for each consumer, keeps track of the requested voltage. The maximum requested voltage is then applied to the regulator. It seems to fit quite well some of the mechanisms you're introducing in this patch set. Just brainstorming - if we use the regulator framework - there are potential benefits - agreed. BUT, consider the cpuidle path - currently we disable SR while hitting off/ret for class3, this is done in irq locked context while the regulator framework uses locks by itself - we would probably have to evolve an entirely different mechanism to handle this. SR by itself can easily be represented I believe and my thoughts when i initialy looked at that option had been: a) latency overheads b) flexibility we achieve vs complexity in s/w implementation c) lock handling - esp impact on omap_sram_idle paths.. If you look at the current PM branch (specifically pm-sr), you'll see that with the updated SR layer, there is no SR enable/disable in the idle path because there is no voltage scaling during idle. That being said, even if this is add later, the idle path can potentialy call the SR API directly if needed for the enable/disable. The concern Thomas and I are raising is that we don't want to re-invent regulator framework functionality in the OMAP voltage layer. Rather, we should keep the OMAP voltage layer as the part that touches the HW, but use the regulator framework for the higher-level management of users and constraints. Performance issues can be addressed as we hit them, but at this level of the design, I want to make sure the frameworks make sense. 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] OMAP CPUIDLE: CPU Idle latency measurement
Amit Kucheria amit.kuche...@linaro.org writes: On 10 Aug 27, Kevin Hilman wrote: vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. Kevin, I agree. We discussed this a little in our weekly meeting. Vishwa's main concern was the lack of ability to instrument the last bit of SRAM code. I have a feeling that even with caches on when we enter this code, we won't see too much variance in the latency to execute this bit of code. Vishwa is going to confirm that now. If that hypothesis is true, we can indeed move to using tracepoints in the idle path and use external tools to track latency. Even if it isn't true, the rest of the idle path could still contain tracepoints. Yes. As Santosh pointed out, that low-level code be a fixed latency and can likely be profiled once. That being said, it should still be possible to trace the low-level code. Jean Pihet and I discussed implementing a fake tracepoint in SRAM during that part of the execution which could then be copied out later. This would minimize the custom tracing code and allow us to continue to use userspace tools to analyze the entire path. Jean is investigating this now. 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 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7
On Thu, Sep 02, 2010 at 10:21:33AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100902 09:50]: On Thu, Sep 02, 2010 at 09:22:20AM -0700, Tony Lindgren wrote: From 8b22546af2ba9a0d96c2f419bfcec1f3c01a414d Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 30 Aug 2010 14:03:28 -0700 Subject: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7 Don't set TLB ops broadcasting on UP ARMv7. Looks like these bits are also different on A8 and A9. This is already taken care of. diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 07fc660..51a063d 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -191,7 +191,8 @@ __v7_setup: UP(mov r0, #(1 6)) @ fake it for UP If it's UP, we set r0 to 1 6, which... tst r0, #(1 6) @ SMP/nAMP mode enabled? means this test produces a non-zero result. orreq r0, r0, #(1 6) | (1 0)@ Enable SMP/nAMP mode and - mcreq p15, 0, r0, c1, c0, 1 @ TLB ops broadcasting And therefore these instructions will not be executed. AFAIK these bits are different for Cortex-A8 and A9, bit 6 is IBE on A8. So what? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7
* Russell King - ARM Linux li...@arm.linux.org.uk [100902 10:54]: On Thu, Sep 02, 2010 at 10:21:33AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100902 09:50]: On Thu, Sep 02, 2010 at 09:22:20AM -0700, Tony Lindgren wrote: From 8b22546af2ba9a0d96c2f419bfcec1f3c01a414d Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 30 Aug 2010 14:03:28 -0700 Subject: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7 Don't set TLB ops broadcasting on UP ARMv7. Looks like these bits are also different on A8 and A9. This is already taken care of. diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 07fc660..51a063d 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -191,7 +191,8 @@ __v7_setup: UP(mov r0, #(1 6)) @ fake it for UP If it's UP, we set r0 to 1 6, which... tst r0, #(1 6) @ SMP/nAMP mode enabled? means this test produces a non-zero result. orreq r0, r0, #(1 6) | (1 0)@ Enable SMP/nAMP mode and - mcreq p15, 0, r0, c1, c0, 1 @ TLB ops broadcasting And therefore these instructions will not be executed. AFAIK these bits are different for Cortex-A8 and A9, bit 6 is IBE on A8. So what? Ah right, sorry I should have looked more carefully. You're right, this patch is no longer needed either. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7
On Thu, Sep 02, 2010 at 11:13:17AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100902 10:54]: On Thu, Sep 02, 2010 at 10:21:33AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100902 09:50]: On Thu, Sep 02, 2010 at 09:22:20AM -0700, Tony Lindgren wrote: diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 07fc660..51a063d 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -191,7 +191,8 @@ __v7_setup: UP(mov r0, #(1 6)) @ fake it for UP If it's UP, we set r0 to 1 6, which... tst r0, #(1 6) @ SMP/nAMP mode enabled? means this test produces a non-zero result. orreq r0, r0, #(1 6) | (1 0)@ Enable SMP/nAMP mode and - mcreq p15, 0, r0, c1, c0, 1 @ TLB ops broadcasting And therefore these instructions will not be executed. AFAIK these bits are different for Cortex-A8 and A9, bit 6 is IBE on A8. So what? Ah right, sorry I should have looked more carefully. You're right, this patch is no longer needed either. Thanks - I was wondering whether I was missing something. -- 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: otg: twl4030: fix phy initialization
Hi,
On Thu, 2 Sep 2010 23:58:18 +0800, tom.leim...@gmail.com wrote:
From: Ming Lei tom.leim...@gmail.com
Commit 461c317705eca5cac09a360f488715927fd0a927(into 2.6.36-v3)
is put forward to power down phy if no usb cable is connected,
but does introduce the two issues below:
1), phy is not into work state if usb cable is connected
with PC during poweron, so musb device mode is not usable
in such case, follows the reasons:
I'm pretty sure I verified both cases.
-twl4030_phy_resume is not called, so
regulators are not enabled
i2c access are not enabled
usb mode not configurated
2), The kernel warings[1] of regulators 'unbalanced disables'
is caused if poweron without usb cable connected
with PC or b-device.
This patch fixes the two issues above:
-power down phy only if no usb cable is connected with PC
and b-device
-do phy initialization(via __twl4030_phy_resume) if usb cable
is connected with PC(vbus event) or another b-device(ID event) in
twl4030_usb_probe.
This patch is verified OK on Beagle board either connected with
usb cable or not when poweron.
I kinda doubt it, would have to test it myself, but I'm without
enough gear to test it again.
[1]. warnings of 'unbalanced disables' of regulators.
[r...@omap3evm /]# dmesg
[ cut here ]
WARNING: at drivers/regulator/core.c:1357
_regulator_disable+0x38/0x128()
this should not have been caused by that patch, though.
Cc: Felipe Balbi felipe.ba...@nokia.com
this email doesn't exist anymore... I'm yet to subscribe the new one,
for now keep this one in Cc, sorry for that.
diff --git a/drivers/usb/otg/twl4030-usb.c
b/drivers/usb/otg/twl4030-usb.c
index 05aaac1..df6381f 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -347,11 +347,22 @@ static void twl4030_i2c_access(struct twl4030_usb
*twl, int on)
}
}
-static void twl4030_phy_power(struct twl4030_usb *twl, int on)
+static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
+ u8 old_pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
u8 pwr;
- pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
+ if (on)
+ pwr = old_pwr ~PHY_PWR_PHYPWD;
+ else
+ pwr = old_pwr | PHY_PWR_PHYPWD;
+
+ if (pwr != old_pwr)
+ WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
writing 1 if register is one won't cause any problems, you're just
wasting a variable.
+static void twl4030_phy_power(struct twl4030_usb *twl, int on)
+{
if (on) {
regulator_enable(twl-usb3v1);
regulator_enable(twl-usb1v8);
@@ -365,15 +376,13 @@ static void twl4030_phy_power(struct twl4030_usb
*twl, int on)
twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0,
VUSB_DEDICATED2);
regulator_enable(twl-usb1v5);
- pwr = ~PHY_PWR_PHYPWD;
- WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
+ __twl4030_phy_power(twl, 1);
twl4030_usb_write(twl, PHY_CLK_CTRL,
twl4030_usb_read(twl, PHY_CLK_CTRL) |
(PHY_CLK_CTRL_CLOCKGATING_EN |
PHY_CLK_CTRL_CLK32K_EN));
} else {
- pwr |= PHY_PWR_PHYPWD;
- WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
+ __twl4030_phy_power(twl, 0);
regulator_disable(twl-usb1v5);
regulator_disable(twl-usb1v8);
regulator_disable(twl-usb3v1);
@@ -387,19 +396,25 @@ static void twl4030_phy_suspend(struct twl4030_usb
*twl, int controller_off)
twl4030_phy_power(twl, 0);
twl-asleep = 1;
+ dev_dbg(twl-dev, %s\n, __func__);
this is noise.
}
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_resume(struct twl4030_usb *twl)
{
- if (!twl-asleep)
- return;
-
twl4030_phy_power(twl, 1);
twl4030_i2c_access(twl, 1);
twl4030_usb_set_mode(twl, twl-usb_mode);
if (twl-usb_mode == T2_USB_MODE_ULPI)
twl4030_i2c_access(twl, 0);
+}
+
+static void twl4030_phy_resume(struct twl4030_usb *twl)
+{
+ if (!twl-asleep)
+ return;
+ __twl4030_phy_resume(twl);
twl-asleep = 0;
+ dev_dbg(twl-dev, %s\n, __func__);
this is noise.
@@ -502,6 +517,26 @@ static irqreturn_t twl4030_usb_irq(int irq, void
*_twl)
return IRQ_HANDLED;
}
+static void twl4030_usb_phy_init(struct twl4030_usb *twl)
+{
+ int status;
+
+ status = twl4030_usb_linkstat(twl);
+ if (status = 0) {
+ if (status == USB_EVENT_NONE) {
+ __twl4030_phy_power(twl, 0);
+ twl-asleep = 1;
+ } else {
+
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Kevin Hilman had written, on 09/02/2010 12:47 PM, the following:
Nishanth Menon n...@ti.com writes:
Thomas Petazzoni had written, on 09/02/2010 02:43 AM, the following:
Hello,
On Wed, 01 Sep 2010 15:51:40 -0700
Kevin Hilman khil...@deeprootsystems.com wrote:
Looking closer at this, keeping track of a list of devices and
constraints is what the regulator framework does as well.
Before we get too far down this path, we need to start working with
Thomas Petazzoni to better understand how we can use the regulator
framework for much of the management levels of the voltage layer.
Yes, as discussed on IRC with Kevin, I think that some of this voltage
layer mechanisms would benefit from using the existing kernel regulator
framework.
The regulator framework already keeps tracks of consumers (in your
patch set called vdd users), and for each consumer, keeps track of
the requested voltage. The maximum requested voltage is then applied to
the regulator. It seems to fit quite well some of the mechanisms you're
introducing in this patch set.
Just brainstorming - if we use the regulator framework - there are
potential benefits - agreed. BUT, consider the cpuidle path -
currently we disable SR while hitting off/ret for class3, this is done
in irq locked context while the regulator framework uses locks by
itself - we would probably have to evolve an entirely different
mechanism to handle this.
SR by itself can easily be represented I believe and my thoughts when
i initialy looked at that option had been:
a) latency overheads
b) flexibility we achieve vs complexity in s/w implementation
c) lock handling - esp impact on omap_sram_idle paths..
If you look at the current PM branch (specifically pm-sr), you'll see
that with the updated SR layer, there is no SR enable/disable in the
idle path because there is no voltage scaling during idle.
This is interesting and I wonder if it works in reality, class 3 operation:
you enable SR h/w monitoring loop as part of dvfs, and when you hit
cpuidle and you discover that domain x is going to idle,
you'd do:
omap_sram_idle() {
figureout a lot of stuff
if (core_next_state == OFF)
disable_sr(core);
if (mpu_next_state == OFF)
disable_sr(mpu);
__omap_sram_idle()
if (core_next_state == OFF)
enable_sr(core);
if (mpu_next_state == OFF)
enable_sr(mpu);
}
disable_sr(domain){
disable hw loop
forceupdate to nominal voltage
}
enable_sr(domain){
enable hw loop
}
in the days of SRF, we used to have a patch as well.. see one of the
first versions:
http://marc.info/?l=linux-omapm=122000411826768w=2
That being said, even if this is add later, the idle path can potentialy
call the SR API directly if needed for the enable/disable.
not clean if it was directly implemented by regulator framework
The concern Thomas and I are raising is that we don't want to re-invent
regulator framework functionality in the OMAP voltage layer. Rather, we
should keep the OMAP voltage layer as the part that touches the HW, but
use the regulator framework for the higher-level management of users and
constraints.
I completely like the idea of going down the regulator path for voltage
management, only brainstorming on how to make that happen.
btw, I was playing around with something(attached) that might show how
it might be done by enhancing the regulator framework for folks who may
want to manage their own exclusivity.. e.g. see attachment..
note: I am not saying this is the way to do it, just that: we need to
allow regulator operations in irq_locked context if we want to do SR
operations (including voltage transitions)
Performance issues can be addressed as we hit them, but at this level of
the design, I want to make sure the frameworks make sense.
I agree.
Kevin
--
Regards,
Nishanth Menon
From 296cd903f0ce5b70e23a052515d8de1ebb9a15cd Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Thu, 2 Sep 2010 13:24:35 -0500
Subject: {HACK}[PATCH 1/2] regulator: core: change exclusive to flags
we currently use an int for exclusivity, instead change it to
a flag based usage. this allows us to extend this to additional flags
as well
Signed-off-by: Nishanth Menon n...@ti.com
---
this patch is meant to be for demonstration purposes only.
drivers/regulator/core.c |6 +++---
include/linux/regulator/driver.h |4 +++-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 422a709..0a1e199 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1127,7 +1127,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
return regulator;
found:
- if (rdev-exclusive) {
+ if (rdev-flags REGULATOR_EXCLUSIVE_FLAG) {
regulator = ERR_PTR(-EPERM);
goto out;
}
@@ -1148,7 +1148,7 @@ found:
rdev-open_count++;
if (exclusive) {
-
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Nishanth Menon n...@ti.com writes: Kevin Hilman had written, on 09/02/2010 12:47 PM, the following: [...] If you look at the current PM branch (specifically pm-sr), you'll see that with the updated SR layer, there is no SR enable/disable in the idle path because there is no voltage scaling during idle. [...] That being said, even if this is add later, the idle path can potentialy call the SR API directly if needed for the enable/disable. not clean if it was directly implemented by regulator framework The idea (so far) is that there will still be a low-level SmartReflex API, and just a regulator wrapper. Thomas P. is experimenting with extending the regulator framework to be able to call into external low-level code which does the heavy lifting. He can probably post an RFC soon. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: Add inline function smp_cpu() for early init testing
* Tony Lindgren t...@atomide.com [100902 10:35]:
* Russell King - ARM Linux li...@arm.linux.org.uk [100902 10:00]:
On Thu, Sep 02, 2010 at 09:18:47AM -0700, Tony Lindgren wrote:
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -39,4 +39,20 @@ static inline int cache_ops_need_broadcast(void)
#define UP(instr...) _str(instr)
#endif
+static inline int smp_on_up(void)
+{
+#ifdef CONFIG_SMP_ON_UP
+ int smp_on_up;
+
+ asm(\
+ SMP(mov %0, #0) \
+ UP(mov %0, #1) \
+ : =r (smp_on_up));
+
+ return smp_on_up;
+#else
+ return 0;
+#endif
I think this is the wrong approach - rather than a function which tells us
just if we are a SMP kernel running on UP, why not something which returns
whether we're running on SMP and use that to eliminate some of these ifdefs?
Sure. Will has something like this in his patches:
static inline int cpu_is_part_of_mp_system(void)
{
u32 mpidr;
asm volatile(mrc p15, 0, %0, c0, c0, 5 : =r (mpidr));
return (mpidr 31) ? !(mpidr 30) : 0;
}
BTW, so far looks like we should only need this during init to set up things.
Here's this one updated to replace smp_cpu() instead of smp_on_up().
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 30 Aug 2010 14:00:54 -0700
Subject: [PATCH] ARM: Add inline function smp_cpu() for early init testing
Add inline function smp_cpu() for early init checks, and
change build_mem_type_table to use it.
Inline function copied from cpu_is_part_of_mp_system() by
Will Deacon will.dea...@arm.com.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 8db3512..82bc488 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -39,4 +39,11 @@ static inline int cache_ops_need_broadcast(void)
#define UP(instr...) _str(instr)
#endif
+static inline int smp_cpu(void)
+{
+u32 mpidr;
+asm volatile(mrc p15, 0, %0, c0, c0, 5 : =r (mpidr));
+return (mpidr 31) ? !(mpidr 30) : 0;
+}
+
#endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 6e1c4f6..2bfaefd 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -430,15 +430,17 @@ static void __init build_mem_type_table(void)
/*
* Mark memory with the shared attribute for SMP systems
*/
- user_pgprot |= L_PTE_SHARED;
- kern_pgprot |= L_PTE_SHARED;
- vecs_pgprot |= L_PTE_SHARED;
- mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
- mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
- mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
- mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ if (smp_cpu()) {
+ user_pgprot |= L_PTE_SHARED;
+ kern_pgprot |= L_PTE_SHARED;
+ vecs_pgprot |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
+ mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ }
#endif
}
Re: [PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi-omap
* Tony Lindgren t...@atomide.com [100902 09:16]:
From c04a57fc3b41d886f56ccdc27cf9758de0c95202 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Tue, 17 Aug 2010 13:33:23 +0300
Subject: [PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi-omap
Fix SMP on UP interrupt handling for multi-omap
Here's this one updated to use !smp_cpu() instead of smp_on_up().
Looks like the description and subject needed some refreshing too.
Tony
From e791c682fe2e3989e76f0bce7e0c9d97e65c2137 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Tue, 17 Aug 2010 13:33:23 +0300
Subject: [PATCH] omap: Fix SMP on UP initialization for multi-omap
Fix SMP on UP initialization for multi-omap.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 9e9f70e..3695232 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -22,6 +22,7 @@
#include asm/cacheflush.h
#include asm/localtimer.h
+#include asm/smp_plat.h
#include asm/smp_scu.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -114,11 +115,15 @@ void __init smp_init_cpus(void)
{
unsigned int i, ncores;
- /* Never released */
- scu_base = ioremap(OMAP44XX_SCU_BASE, SZ_256);
- BUG_ON(!scu_base);
+ if (!smp_cpu()) {
+ ncores = 1;
+ } else {
+ /* Never released */
+ scu_base = ioremap(OMAP44XX_SCU_BASE, SZ_256);
+ BUG_ON(!scu_base);
- ncores = get_core_count();
+ ncores = get_core_count();
+ }
for (i = 0; i ncores; i++)
set_cpu_possible(i, true);
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 74fbed8..a21b4a4 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -37,6 +37,7 @@
#include linux/clockchips.h
#include asm/mach/time.h
+#include asm/smp_plat.h
#include plat/dmtimer.h
#include asm/localtimer.h
@@ -228,8 +229,10 @@ static void __init omap2_gp_clocksource_init(void)
static void __init omap2_gp_timer_init(void)
{
#ifdef CONFIG_LOCAL_TIMERS
- twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
- BUG_ON(!twd_base);
+ if (!smp_cpu()) {
+ twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
+ BUG_ON(!twd_base);
+ }
#endif
omap_dm_timer_init();
Re: [PATCH 7/8] : Hwmod api changes
Hello Benoît, Rajendra, Hema, On Mon, 9 Aug 2010, Cousson, Benoit wrote: On 8/9/2010 11:37 AM, Nayak, Rajendra wrote: From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, August 09, 2010 1:51 PM On Mon, 9 Aug 2010, Nayak, Rajendra wrote: Does it make sense for the framework itself to enable wakeup for all devices when the slave port is programmed to be in Smartidle It seems to me that they are separate mechanisms? If a module is programmed for slave smart-idle, then the module prevents the PRCM from shutting off the module clock(s) until the module is not busy. This seems distinct from ENAWAKEUP, which I thought simply controlled whether the module would assert the SWakeup signal to the PRCM when an external wakeup condition occurred for that module. Is that an accurate summary? hmm.. the reason I thought the two were related was because the need to assert a SWakeup will arise only when the module is programmed in smart-idle. If the module is either in no-idle (in which case no idle-ack is asserted by the module) or force-idle (when the module is forced to idle and expected to stay idle) there might not be a need for the module to be capable of asserting a SWakeup. In fact, the SWakeup is asserted as soon as the module is in idle (idle_ack = 1) and cannot use the OCP interface to communicate a IRQ_REQ or DMA_REQ. But the wakeup capability is disabled by setting the SidleMode to Force-Idle, regardless of the value of Wakeup enable. Bottom-line is that the SWakeup can be asserted only if the module is in smart-idle. In that case, it sounds like Rajendra's patch would be useful (to automatically enable ENAWAKEUP during target smart-idle, and disable it during target no-idle or force-idle, would be worthwhile)? One other situation that we should consider would be if it ever makes sense to program a module to target smart-idle, but disable ENAWAKEUP. I suppose it should only be necessary if there is a hardware bug where an IP block generates spurious SWakeups. -- But if we have no current need for this type of workaround, maybe we can just ignore this case and have the ENAWAKEUP bit follow target smart-idle status. Then if such a hardware bug appears, we can separate ENAWAKEUP programming later. Thoughts? - Paul
[PATCH v2 00/10] split out emac cpdma and mdio for reuse
Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine. These hardware modules are not restricted to EMAC device alone. For example, CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules internally. This patch series separates out EMAC's MDIO and CPDMA functionality, allowing these individual pieces to be reused across TI hardware. This patch series has been broadly organized as follows: MDIO: - Add new functionality netdev: separate out davinci mdio controller code - Hookup new functionality davinci: add mdio platform devices omap: add mdio platform devices netdev: switch davinci emac to new mdio driver - Cleanup left over cruft davinci: cleanup unused davinci mdio arch code omap: cleanup unused davinci mdio arch code netdev: cleanup unused davinci mdio emac code CPDMA: - Add new functionality netdev: separate out davinci cpdma controller code - Hookup new functionality netdev: switch davinci emac to new cpdma layer - Cleanup left over cruft netdev: cleanup unused davinci emac cpdma code This series has been tested on dm365 and tnetv107x (with additional cpsw patches) hardware. Although am3517 (omap) board support code has been updated as needed, emac does not work on this platform. Changes from v1: 1. Fixed memory leak in cpdma_chan_create() failure case 2. Included new omap patches for am3517, avoids build breakage Cyril Chemparathy (8): netdev: separate out davinci mdio controller code davinci: add mdio platform devices omap: add mdio platform devices net: davinci_emac: switch to new mdio davinci: cleanup unused davinci mdio arch code omap: cleanup unused davinci mdio arch code net: davinci_emac: cleanup unused mdio emac code net: davinci_emac: separate out cpdma code net: davinci_emac: switch to new cpdma layer net: davinci_emac: cleanup unused cpdma code arch/arm/mach-davinci/board-da830-evm.c |5 - arch/arm/mach-davinci/board-da850-evm.c |6 - arch/arm/mach-davinci/board-dm365-evm.c |7 - arch/arm/mach-davinci/board-dm644x-evm.c|7 - arch/arm/mach-davinci/board-dm646x-evm.c|8 - arch/arm/mach-davinci/board-neuros-osd2.c |7 - arch/arm/mach-davinci/board-sffsdr.c|7 - arch/arm/mach-davinci/devices-da8xx.c | 31 +- arch/arm/mach-davinci/dm365.c | 23 +- arch/arm/mach-davinci/dm644x.c | 23 +- arch/arm/mach-davinci/dm646x.c | 22 +- arch/arm/mach-davinci/include/mach/dm365.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- arch/arm/mach-davinci/include/mach/dm646x.h |2 +- arch/arm/mach-omap2/board-am3517evm.c | 31 +- drivers/net/Kconfig | 21 + drivers/net/Makefile|2 + drivers/net/davinci_cpdma.c | 837 + drivers/net/davinci_cpdma.h | 105 +++ drivers/net/davinci_emac.c | 1325 --- drivers/net/davinci_mdio.c | 386 include/linux/davinci_emac.h|8 +- 22 files changed, 1635 insertions(+), 1232 deletions(-) create mode 100644 drivers/net/davinci_cpdma.c create mode 100644 drivers/net/davinci_cpdma.h create mode 100644 drivers/net/davinci_mdio.c -- 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 v2 01/10] net: davinci_emac: separate out davinci mdio
Davinci's MDIO controller is present on other TI devices, without an
accompanying EMAC. For example, on tnetv107x, the same MDIO module is used in
conjunction with a 3-port switch hardware.
By separating the MDIO controller code into its own platform driver, this
patch allows common logic to be reused on such platforms.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/net/Kconfig | 10 +
drivers/net/Makefile |1 +
drivers/net/davinci_mdio.c | 386 ++
include/linux/davinci_emac.h |4 +
4 files changed, 401 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/davinci_mdio.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2cc81a5..c5c86e0 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -958,6 +958,16 @@ config TI_DAVINCI_EMAC
To compile this driver as a module, choose M here: the module
will be called davinci_emac_driver. This is recommended.
+config TI_DAVINCI_MDIO
+ tristate TI DaVinci MDIO Support
+ depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 )
+ select PHYLIB
+ help
+ This driver supports TI's DaVinci MDIO module.
+
+ To compile this driver as a module, choose M here: the module
+ will be called davinci_mdio. This is recommended.
+
config DM9000
tristate DM9000 support
depends on ARM || BLACKFIN || MIPS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 3e8f150..d38a7ab 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_MDIO) += mdio.o
obj-$(CONFIG_PHYLIB) += phy/
obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
+obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_E1000E) += e1000e/
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
new file mode 100644
index 000..d34a53a
--- /dev/null
+++ b/drivers/net/davinci_mdio.c
@@ -0,0 +1,386 @@
+/*
+ * DaVinci MDIO Module driver
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * Shamelessly ripped out of davinci_emac.c, original copyrights follow:
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * ---
+ *
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * ---
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/sched.h
+#include linux/slab.h
+#include linux/phy.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/davinci_emac.h
+
+#define PHY_REG_MASK 0x1f
+#define PHY_ID_MASK0x1f
+
+#define DEF_OUT_FREQ 220 /* 2.2 MHz */
+
+struct davinci_mdio_regs {
+ u32 version;
+ u32 control;
+#define CONTROL_IDLE BIT(31)
+#define CONTROL_ENABLE BIT(30)
+#define CONTROL_MAX_DIV(0xff)
+
+ u32 alive;
+ u32 link;
+ u32 linkintraw;
+ u32 linkintmasked;
+ u32 __reserved_0[2];
+ u32 userintraw;
+ u32 userintmasked;
+ u32 userintmaskset;
+ u32 userintmaskclr;
+ u32 __reserved_1[20];
+
+ struct {
+ u32 access;
+#define USERACCESS_GO BIT(31)
+#define USERACCESS_WRITE BIT(30)
+#define USERACCESS_ACK BIT(29)
+#define USERACCESS_READ(0)
+#define USERACCESS_DATA(0x)
+
+ u32 physel;
+ } user[0];
+};
+
+struct mdio_platform_data default_pdata = {
+ .bus_freq = DEF_OUT_FREQ,
+};
+
+struct davinci_mdio_data {
+ struct mdio_platform_data pdata;
+ struct davinci_mdio_regs __iomem *regs;
+ spinlock_t lock;
+ struct clk *clk;
+ struct device *dev;
+ struct mii_bus *bus;
+ boolsuspended;
+};
+
+/* wait until hardware is ready for another user access */
+static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
+{
+ struct davinci_mdio_regs __iomem *regs = data-regs;
+ u32 reg;
+
+ while ((reg = __raw_readl(regs-user[0].access)) USERACCESS_GO)
+ ;
+
+
[PATCH v2 08/10] net: davinci_emac: separate out cpdma code
In addition to being embedded into the EMAC controller, the CPDMA hardware
block is used in TI's CPSW switch controller. Fortunately, the programming
interface to this hardware block remains pretty nicely consistent across these
devices.
This patch adds a new CPDMA services layer, which can then be reused across
EMAC and CPSW drivers.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/net/Kconfig | 10 +
drivers/net/Makefile|1 +
drivers/net/davinci_cpdma.c | 837 +++
drivers/net/davinci_cpdma.h | 105 ++
4 files changed, 953 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/davinci_cpdma.c
create mode 100644 drivers/net/davinci_cpdma.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 911e7f1..775fd87 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -952,6 +952,7 @@ config TI_DAVINCI_EMAC
tristate TI DaVinci EMAC Support
depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 )
select TI_DAVINCI_MDIO
+ select TI_DAVINCI_CPDMA
select PHYLIB
help
This driver supports TI's DaVinci Ethernet .
@@ -969,6 +970,15 @@ config TI_DAVINCI_MDIO
To compile this driver as a module, choose M here: the module
will be called davinci_mdio. This is recommended.
+config TI_DAVINCI_CPDMA
+ tristate TI DaVinci CPDMA Support
+ depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 )
+ help
+ This driver supports TI's DaVinci CPDMA dma engine.
+
+ To compile this driver as a module, choose M here: the module
+ will be called davinci_cpdma. This is recommended.
+
config DM9000
tristate DM9000 support
depends on ARM || BLACKFIN || MIPS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d38a7ab..65da885 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PHYLIB) += phy/
obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
+obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_E1000E) += e1000e/
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
new file mode 100644
index 000..ab7ecd7
--- /dev/null
+++ b/drivers/net/davinci_cpdma.c
@@ -0,0 +1,837 @@
+/*
+ * Texas Instruments CPDMA Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include linux/kernel.h
+#include linux/spinlock.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/dma-mapping.h
+#include linux/io.h
+
+#include davinci_cpdma.h
+
+/* DMA Registers */
+#define CPDMA_TXIDVER 0x00
+#define CPDMA_TXCONTROL0x04
+#define CPDMA_TXTEARDOWN 0x08
+#define CPDMA_RXIDVER 0x10
+#define CPDMA_RXCONTROL0x14
+#define CPDMA_SOFTRESET0x1c
+#define CPDMA_RXTEARDOWN 0x18
+#define CPDMA_TXINTSTATRAW 0x80
+#define CPDMA_TXINTSTATMASKED 0x84
+#define CPDMA_TXINTMASKSET 0x88
+#define CPDMA_TXINTMASKCLEAR 0x8c
+#define CPDMA_MACINVECTOR 0x90
+#define CPDMA_MACEOIVECTOR 0x94
+#define CPDMA_RXINTSTATRAW 0xa0
+#define CPDMA_RXINTSTATMASKED 0xa4
+#define CPDMA_RXINTMASKSET 0xa8
+#define CPDMA_RXINTMASKCLEAR 0xac
+#define CPDMA_DMAINTSTATRAW0xb0
+#define CPDMA_DMAINTSTATMASKED 0xb4
+#define CPDMA_DMAINTMASKSET0xb8
+#define CPDMA_DMAINTMASKCLEAR 0xbc
+#define CPDMA_DMAINT_HOSTERR BIT(1)
+
+/* the following exist only if has_ext_regs is set */
+#define CPDMA_DMACONTROL 0x20
+#define CPDMA_DMASTATUS0x24
+#define CPDMA_RXBUFFOFS0x28
+#define CPDMA_EM_CONTROL 0x2c
+
+/* Descriptor mode bits */
+#define CPDMA_DESC_SOP BIT(31)
+#define CPDMA_DESC_EOP BIT(30)
+#define CPDMA_DESC_OWNER BIT(29)
+#define CPDMA_DESC_EOQ BIT(28)
+#define CPDMA_DESC_TD_COMPLETE BIT(27)
+#define CPDMA_DESC_PASS_CRCBIT(26)
+
+#define CPDMA_TEARDOWN_VALUE 0xfffc
+
+struct cpdma_desc {
+ /* hardware fields */
+ u32 hw_next;
+ u32 hw_buffer;
+ u32 hw_len;
+ u32 hw_mode;
+ /* software fields */
+ void*sw_token;
+ u32 sw_buffer;
+ u32 sw_len;
+};
+
+struct cpdma_desc_pool {
+ u32 phys;
+ void __iomem*iomap; /*
[PATCH v2 09/10] net: davinci_emac: switch to new cpdma layer
This patch hooks up the emac driver with the newly separated cpdma driver.
Key differences introduced here:
- The old buffer list scheme is no longer required
- The original code maintained mac address per rx channel, even if only one
rx channel was being used. With this change, mac address is maintained
device wide. If support for multiple rx channels is added in future, this
will need to be reworked a bit.
- The new CPDMA code handles short packets better than before. The
earlier code was adjusting the length up, without ensuring that the tail
end of the padding was cleared - a possible security issue. This has been
fixed to use skb_padto().
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/net/davinci_emac.c | 232
1 files changed, 147 insertions(+), 85 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 036681a..4147d32 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -63,6 +63,8 @@
#include asm/irq.h
#include asm/page.h
+#include davinci_cpdma.h
+
static int debug_level;
module_param(debug_level, int, 0);
MODULE_PARM_DESC(debug_level, DaVinci EMAC debug level (NETIF_MSG bits));
@@ -113,6 +115,7 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
#define EMAC_DEF_MAX_FRAME_SIZE(1500 + 14 + 4 + 4)
#define EMAC_DEF_TX_CH (0) /* Default 0th channel */
#define EMAC_DEF_RX_CH (0) /* Default 0th channel */
+#define EMAC_DEF_RX_NUM_DESC (128)
#define EMAC_DEF_MAX_TX_CH (1) /* Max TX channels configured */
#define EMAC_DEF_MAX_RX_CH (1) /* Max RX channels configured */
#define EMAC_POLL_WEIGHT (64) /* Default NAPI poll weight */
@@ -460,6 +463,9 @@ struct emac_priv {
u32 hw_ram_addr;
struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
+ struct cpdma_ctlr *dma;
+ struct cpdma_chan *txchan;
+ struct cpdma_chan *rxchan;
u32 link; /* 1=link on, 0=link off */
u32 speed; /* 0=Auto Neg, 1=No PHY, 10,100, 1000 - mbps */
u32 duplex; /* Link duplex: 0=Half, 1=Full */
@@ -1151,6 +1157,57 @@ static irqreturn_t emac_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static struct sk_buff *emac_rx_alloc(struct emac_priv *priv)
+{
+ struct sk_buff *skb = dev_alloc_skb(priv-rx_buf_size);
+ if (WARN_ON(!skb))
+ return NULL;
+ skb-dev = priv-ndev;
+ skb_reserve(skb, NET_IP_ALIGN);
+ return skb;
+}
+
+static void emac_rx_handler(void *token, int len, int status)
+{
+ struct sk_buff *skb = token;
+ struct net_device *ndev = skb-dev;
+ struct emac_priv*priv = netdev_priv(ndev);
+ int ret;
+
+ if (status 0) {
+ /* error */
+ goto recycle;
+ }
+
+ skb_put(skb, len);
+ skb-protocol = eth_type_trans(skb, ndev);
+ netif_receive_skb(skb);
+ ndev-stats.rx_bytes += len;
+ ndev-stats.rx_packets++;
+
+ /* alloc a new packet for receive */
+ skb = emac_rx_alloc(priv);
+
+recycle:
+ if (skb) {
+ ret = cpdma_chan_submit(priv-rxchan, skb, skb-data,
+ skb_tailroom(skb), GFP_KERNEL);
+ WARN_ON(ret 0);
+ }
+}
+
+static void emac_tx_handler(void *token, int len, int status)
+{
+ struct sk_buff *skb = token;
+ struct net_device *ndev = skb-dev;
+
+ if (unlikely(netif_queue_stopped(ndev)))
+ netif_start_queue(ndev);
+ ndev-stats.tx_packets++;
+ ndev-stats.tx_bytes += len;
+ dev_kfree_skb_any(skb);
+}
+
/** EMAC on-chip buffer descriptor memory
*
* WARNING: Please note that the on chip memory is used for both TX and RX
@@ -1532,42 +1589,36 @@ static int emac_dev_xmit(struct sk_buff *skb, struct
net_device *ndev)
{
struct device *emac_dev = ndev-dev;
int ret_code;
- struct emac_netbufobj tx_buf; /* buffer obj-only single frame support */
- struct emac_netpktobj tx_packet; /* packet object */
struct emac_priv *priv = netdev_priv(ndev);
/* If no link, return */
if (unlikely(!priv-link)) {
if (netif_msg_tx_err(priv) net_ratelimit())
dev_err(emac_dev, DaVinci EMAC: No link to transmit);
- return NETDEV_TX_BUSY;
+ goto fail_tx;
}
- /* Build the buffer and packet objects - Since only single fragment is
-* supported, need not set length and token in both packet object.
-* Doing so for completeness sake to show that this needs to be done
-* in multifragment case
-*/
- tx_packet.buf_list = tx_buf;
- tx_packet.num_bufs = 1; /* only single fragment
[PATCH v2 10/10] net: davinci_emac: cleanup unused cpdma code
Having switched over to the newly introduced cpdma layer, this patch now
removes a whole bunch of code that is now unused. This patch has been
maintained separate strictly for reasons of readability.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/net/davinci_emac.c | 930
1 files changed, 0 insertions(+), 930 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 4147d32..525b84c 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -127,7 +127,6 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
/* EMAC register related defines */
#define EMAC_ALL_MULTI_REG_VALUE (0x)
#define EMAC_NUM_MULTICAST_BITS(64)
-#define EMAC_TEARDOWN_VALUE(0xFFFC)
#define EMAC_TX_CONTROL_TX_ENABLE_VAL (0x1)
#define EMAC_RX_CONTROL_RX_ENABLE_VAL (0x1)
#define EMAC_MAC_HOST_ERR_INTMASK_VAL (0x2)
@@ -214,24 +213,10 @@ static const char emac_version_string[] = TI DaVinci
EMAC Linux v6.1;
#define EMAC_DEF_MAX_MULTICAST_ADDRESSES (64) /* Max mcast addr's */
/* EMAC Peripheral Device Register Memory Layout structure */
-#define EMAC_TXIDVER 0x0
-#define EMAC_TXCONTROL 0x4
-#define EMAC_TXTEARDOWN0x8
-#define EMAC_RXIDVER 0x10
-#define EMAC_RXCONTROL 0x14
-#define EMAC_RXTEARDOWN0x18
-#define EMAC_TXINTSTATRAW 0x80
-#define EMAC_TXINTSTATMASKED 0x84
-#define EMAC_TXINTMASKSET 0x88
-#define EMAC_TXINTMASKCLEAR0x8C
#define EMAC_MACINVECTOR 0x90
#define EMAC_DM646X_MACEOIVECTOR 0x94
-#define EMAC_RXINTSTATRAW 0xA0
-#define EMAC_RXINTSTATMASKED 0xA4
-#define EMAC_RXINTMASKSET 0xA8
-#define EMAC_RXINTMASKCLEAR0xAC
#define EMAC_MACINTSTATRAW 0xB0
#define EMAC_MACINTSTATMASKED 0xB4
#define EMAC_MACINTMASKSET 0xB8
@@ -258,12 +243,6 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
#define EMAC_MACADDRHI 0x504
#define EMAC_MACINDEX 0x508
-/* EMAC HDP and Completion registors */
-#define EMAC_TXHDP(ch) (0x600 + (ch * 4))
-#define EMAC_RXHDP(ch) (0x620 + (ch * 4))
-#define EMAC_TXCP(ch) (0x640 + (ch * 4))
-#define EMAC_RXCP(ch) (0x660 + (ch * 4))
-
/* EMAC statistics registers */
#define EMAC_RXGOODFRAMES 0x200
#define EMAC_RXBCASTFRAMES 0x204
@@ -328,120 +307,6 @@ static const char emac_version_string[] = TI DaVinci
EMAC Linux v6.1;
/* EMAC Stats Clear Mask */
#define EMAC_STATS_CLR_MASK(0x)
-/** net_buf_obj: EMAC network bufferdata structure
- *
- * EMAC network buffer data structure
- */
-struct emac_netbufobj {
- void *buf_token;
- char *data_ptr;
- int length;
-};
-
-/** net_pkt_obj: EMAC network packet data structure
- *
- * EMAC network packet data structure - supports buffer list (for future)
- */
-struct emac_netpktobj {
- void *pkt_token; /* data token may hold tx/rx chan id */
- struct emac_netbufobj *buf_list; /* array of network buffer objects */
- int num_bufs;
- int pkt_length;
-};
-
-/** emac_tx_bd: EMAC TX Buffer descriptor data structure
- *
- * EMAC TX Buffer descriptor data structure
- */
-struct emac_tx_bd {
- int h_next;
- int buff_ptr;
- int off_b_len;
- int mode; /* SOP, EOP, ownership, EOQ, teardown,Qstarv, length */
- struct emac_tx_bd __iomem *next;
- void *buf_token;
-};
-
-/** emac_txch: EMAC TX Channel data structure
- *
- * EMAC TX Channel data structure
- */
-struct emac_txch {
- /* Config related */
- u32 num_bd;
- u32 service_max;
-
- /* CPPI specific */
- u32 alloc_size;
- void __iomem *bd_mem;
- struct emac_tx_bd __iomem *bd_pool_head;
- struct emac_tx_bd __iomem *active_queue_head;
- struct emac_tx_bd __iomem *active_queue_tail;
- struct emac_tx_bd __iomem *last_hw_bdprocessed;
- u32 queue_active;
- u32 teardown_pending;
- u32 *tx_complete;
-
- /** statistics */
- u32 proc_count; /* TX: # of times emac_tx_bdproc is called */
- u32 mis_queued_packets;
- u32 queue_reinit;
- u32 end_of_queue_add;
- u32 out_of_tx_bd;
- u32 no_active_pkts; /* IRQ when there were no packets to process */
- u32 active_queue_count;
-};
-
-/** emac_rx_bd: EMAC RX Buffer descriptor data structure
- *
- * EMAC RX Buffer descriptor data structure
- */
-struct emac_rx_bd {
- int h_next;
- int buff_ptr;
- int off_b_len;
- int mode;
- struct emac_rx_bd __iomem *next;
- void *data_ptr;
- void *buf_token;
-};
-
-/** emac_rxch: EMAC RX Channel data structure
- *
- * EMAC RX Channel data structure
- */
-struct emac_rxch {
- /* configuration info */
- u32 num_bd;
- u32 service_max;
- u32 buf_size;
- char mac_addr[6];
-
- /** CPPI specific
[PATCH v2 06/10] omap: cleanup unused davinci mdio arch code
This patch removes davinci architecture code that has now been rendered
useless by the previous patches in the MDIO separation series.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 5dd1b73..5225df6 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -39,7 +39,6 @@
#include mux.h
-#define AM35XX_EVM_PHY_MASK(0xF)
#define AM35XX_EVM_MDIO_FREQUENCY (100)
static struct mdio_platform_data am3517_evm_mdio_pdata = {
@@ -64,8 +63,6 @@ static struct platform_device am3517_mdio_device = {
};
static struct emac_platform_data am3517_evm_emac_pdata = {
- .phy_mask = AM35XX_EVM_PHY_MASK,
- .mdio_max_freq = AM35XX_EVM_MDIO_FREQUENCY,
.rmii_en= 1,
};
@@ -135,7 +132,6 @@ void am3517_evm_ethernet_init(struct emac_platform_data
*pdata)
pdata-ctrl_reg_offset = AM35XX_EMAC_CNTRL_OFFSET;
pdata-ctrl_mod_reg_offset = AM35XX_EMAC_CNTRL_MOD_OFFSET;
pdata-ctrl_ram_offset = AM35XX_EMAC_CNTRL_RAM_OFFSET;
- pdata-mdio_reg_offset = AM35XX_EMAC_MDIO_OFFSET;
pdata-ctrl_ram_size= AM35XX_EMAC_CNTRL_RAM_SIZE;
pdata-version = EMAC_VERSION_2;
pdata-hw_ram_addr = AM35XX_EMAC_HW_RAM_ADDR;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/10] davinci: cleanup unused davinci mdio arch code
This patch removes davinci architecture code that has now been rendered
useless by the previous patches in the MDIO separation series.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-davinci/board-da830-evm.c |5 -
arch/arm/mach-davinci/board-da850-evm.c |6 --
arch/arm/mach-davinci/board-dm365-evm.c |7 ---
arch/arm/mach-davinci/board-dm644x-evm.c|7 ---
arch/arm/mach-davinci/board-dm646x-evm.c|8
arch/arm/mach-davinci/board-neuros-osd2.c |7 ---
arch/arm/mach-davinci/board-sffsdr.c|7 ---
arch/arm/mach-davinci/devices-da8xx.c |2 --
arch/arm/mach-davinci/dm365.c |1 -
arch/arm/mach-davinci/dm644x.c |1 -
arch/arm/mach-davinci/dm646x.c |1 -
arch/arm/mach-davinci/include/mach/dm365.h |1 -
arch/arm/mach-davinci/include/mach/dm644x.h |1 -
arch/arm/mach-davinci/include/mach/dm646x.h |1 -
14 files changed, 0 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index de82739..d91d12d 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -31,9 +31,6 @@
#include mach/usb.h
#include mach/aemif.h
-#define DA830_EVM_PHY_MASK 0x0
-#define DA830_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
-
/*
* USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4].
*/
@@ -558,8 +555,6 @@ static __init void da830_evm_init(void)
da830_evm_usb_init();
- soc_info-emac_pdata-phy_mask = DA830_EVM_PHY_MASK;
- soc_info-emac_pdata-mdio_max_freq = DA830_EVM_MDIO_FREQUENCY;
soc_info-emac_pdata-rmii_en = 1;
ret = davinci_cfg_reg_list(da830_cpgmac_pins);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index c1d45d7..3aa4e6b 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -38,9 +38,6 @@
#include mach/mux.h
#include mach/aemif.h
-#define DA850_EVM_PHY_MASK 0x1
-#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
-
#define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8)
#define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15)
@@ -678,9 +675,6 @@ static int __init da850_evm_config_emac(void)
/* Enable/Disable MII MDIO clock */
gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, rmii_en);
- soc_info-emac_pdata-phy_mask = DA850_EVM_PHY_MASK;
- soc_info-emac_pdata-mdio_max_freq = DA850_EVM_MDIO_FREQUENCY;
-
ret = da8xx_register_emac();
if (ret)
pr_warning(da850_evm_init: emac registration failed: %d\n,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 60c59dd..f697914 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -54,9 +54,6 @@ static inline int have_tvp7002(void)
return 0;
}
-#define DM365_EVM_PHY_MASK (0x2)
-#define DM365_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
-
/*
* A MAX-II CPLD is used for various board control functions.
*/
@@ -530,16 +527,12 @@ fail:
/* externally mux MMC1/ENET/AIC33 to imager */
mux |= BIT(6) | BIT(5) | BIT(3);
} else {
- struct davinci_soc_info *soc_info = davinci_soc_info;
-
/* we can use MMC1 ... */
dm365evm_mmc_configure();
davinci_setup_mmc(1, dm365evm_mmc_config);
/* ... and ENET ... */
dm365evm_emac_configure();
- soc_info-emac_pdata-phy_mask = DM365_EVM_PHY_MASK;
- soc_info-emac_pdata-mdio_max_freq = DM365_EVM_MDIO_FREQUENCY;
resets = ~BIT(3);
/* ... and AIC33 */
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 65bb940..c86bf23 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -39,9 +39,6 @@
#include mach/usb.h
#include mach/aemif.h
-#define DM644X_EVM_PHY_MASK(0x2)
-#define DM644X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
-
#define LXT971_PHY_ID (0x001378e2)
#define LXT971_PHY_MASK(0xfff0)
@@ -672,7 +669,6 @@ static int davinci_phy_fixup(struct phy_device *phydev)
static __init void davinci_evm_init(void)
{
struct clk *aemif_clk;
- struct davinci_soc_info *soc_info = davinci_soc_info;
aemif_clk = clk_get(NULL, aemif);
clk_enable(aemif_clk);
@@ -707,9 +703,6 @@ static __init void davinci_evm_init(void)
davinci_serial_init(uart_config);
dm644x_init_asp(dm644x_evm_snd_data);
- soc_info-emac_pdata-phy_mask = DM644X_EVM_PHY_MASK;
-
[PATCH v2 07/10] net: davinci_emac: cleanup unused mdio emac code
This patch removes code that has been rendered useless by the previous patches
in this series.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/net/davinci_emac.c | 107 --
include/linux/davinci_emac.h |3 -
2 files changed, 0 insertions(+), 110 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 6ed779d..036681a 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -113,7 +113,6 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
#define EMAC_DEF_MAX_FRAME_SIZE(1500 + 14 + 4 + 4)
#define EMAC_DEF_TX_CH (0) /* Default 0th channel */
#define EMAC_DEF_RX_CH (0) /* Default 0th channel */
-#define EMAC_DEF_MDIO_TICK_MS (10) /* typically 1 tick=1 ms) */
#define EMAC_DEF_MAX_TX_CH (1) /* Max TX channels configured */
#define EMAC_DEF_MAX_RX_CH (1) /* Max RX channels configured */
#define EMAC_POLL_WEIGHT (64) /* Default NAPI poll weight */
@@ -303,25 +302,6 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
#define EMAC_DM644X_INTMIN_INTVL 0x1
#define EMAC_DM644X_INTMAX_INTVL (EMAC_DM644X_EWINTCNT_MASK)
-/* EMAC MDIO related */
-/* Mask Control defines */
-#define MDIO_CONTROL_CLKDIV(0xFF)
-#define MDIO_CONTROL_ENABLEBIT(30)
-#define MDIO_USERACCESS_GO BIT(31)
-#define MDIO_USERACCESS_WRITE BIT(30)
-#define MDIO_USERACCESS_READ (0)
-#define MDIO_USERACCESS_REGADR (0x1F 21)
-#define MDIO_USERACCESS_PHYADR (0x1F 16)
-#define MDIO_USERACCESS_DATA (0x)
-#define MDIO_USERPHYSEL_LINKSELBIT(7)
-#define MDIO_VER_MODID (0x 16)
-#define MDIO_VER_REVMAJ(0xFF8)
-#define MDIO_VER_REVMIN(0xFF)
-
-#define MDIO_USERACCESS(inst) (0x80 + (inst * 8))
-#define MDIO_USERPHYSEL(inst) (0x84 + (inst * 8))
-#define MDIO_CONTROL (0x04)
-
/* EMAC DM646X control module registers */
#define EMAC_DM646X_CMINTCTRL 0x0C
#define EMAC_DM646X_CMRXINTEN 0x14
@@ -493,13 +473,6 @@ struct emac_priv {
u32 mac_hash2;
u32 multicast_hash_cnt[EMAC_NUM_MULTICAST_BITS];
u32 rx_addr_type;
- /* periodic timer required for MDIO polling */
- struct timer_list periodic_timer;
- u32 periodic_ticks;
- u32 timer_active;
- u32 phy_mask;
- /* mii_bus,phy members */
- struct mii_bus *mii_bus;
const char *phy_id;
struct phy_device *phydev;
spinlock_t lock;
@@ -511,7 +484,6 @@ struct emac_priv {
/* clock frequency for EMAC */
static struct clk *emac_clk;
static unsigned long emac_bus_frequency;
-static unsigned long mdio_max_freq;
#define emac_virt_to_phys(addr, priv) \
(((u32 __force)(addr) - (u32 __force)(priv-emac_ctrl_ram)) \
@@ -549,9 +521,6 @@ static char *emac_rxhost_errcodes[16] = {
#define emac_ctrl_read(reg) ioread32((priv-ctrl_base + (reg)))
#define emac_ctrl_write(reg, val) iowrite32(val, (priv-ctrl_base + (reg)))
-#define emac_mdio_read(reg) ioread32(bus-priv + (reg))
-#define emac_mdio_write(reg, val) iowrite32(val, (bus-priv + (reg)))
-
/**
* emac_dump_regs: Dump important EMAC registers to debug terminal
* @priv: The DaVinci EMAC private adapter structure
@@ -657,9 +626,6 @@ static void emac_dump_regs(struct emac_priv *priv)
emac_read(EMAC_RXDMAOVERRUNS));
}
-/*
- * EMAC MDIO/Phy Functionality
- */
/**
* emac_get_drvinfo: Get EMAC driver information
* @ndev: The DaVinci EMAC network adapter
@@ -2349,79 +2315,6 @@ void emac_poll_controller(struct net_device *ndev)
}
#endif
-/* PHY/MII bus related */
-
-/* Wait until mdio is ready for next command */
-#define MDIO_WAIT_FOR_USER_ACCESS\
- while ((emac_mdio_read((MDIO_USERACCESS(0))) \
- MDIO_USERACCESS_GO) != 0)
-
-static int emac_mii_read(struct mii_bus *bus, int phy_id, int phy_reg)
-{
- unsigned int phy_data = 0;
- unsigned int phy_control;
-
- /* Wait until mdio is ready for next command */
- MDIO_WAIT_FOR_USER_ACCESS;
-
- phy_control = (MDIO_USERACCESS_GO |
- MDIO_USERACCESS_READ |
- ((phy_reg 21) MDIO_USERACCESS_REGADR) |
- ((phy_id 16) MDIO_USERACCESS_PHYADR) |
- (phy_data MDIO_USERACCESS_DATA));
- emac_mdio_write(MDIO_USERACCESS(0), phy_control);
-
- /* Wait until mdio is ready for next command */
- MDIO_WAIT_FOR_USER_ACCESS;
-
- return emac_mdio_read(MDIO_USERACCESS(0)) MDIO_USERACCESS_DATA;
-
-}
-
-static int emac_mii_write(struct mii_bus *bus, int phy_id,
- int phy_reg, u16 phy_data)
-{
-
- unsigned int control;
-
- /*
[PATCH v2 02/10] davinci: add mdio platform devices
This patch adds mdio platform devices on SoCs that have the necessary
hardware. Clock lookup entries (aliases) have also been added, so that the
MDIO and EMAC drivers can independently enable/disable a shared underlying
clock. Further, the EMAC MMR region has been split down into separate MDIO
and EMAC regions.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 29 +-
arch/arm/mach-davinci/dm365.c | 22 +++-
arch/arm/mach-davinci/dm644x.c | 22 +++-
arch/arm/mach-davinci/dm646x.c | 21 ++-
arch/arm/mach-davinci/include/mach/dm365.h |1 +
arch/arm/mach-davinci/include/mach/dm644x.h |1 +
arch/arm/mach-davinci/include/mach/dm646x.h |1 +
7 files changed, 92 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index caeb7f4..9039221 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -352,7 +352,7 @@ int __init da8xx_register_watchdog(void)
static struct resource da8xx_emac_resources[] = {
{
.start = DA8XX_EMAC_CPPI_PORT_BASE,
- .end= DA8XX_EMAC_CPPI_PORT_BASE + 0x5000 - 1,
+ .end= DA8XX_EMAC_CPPI_PORT_BASE + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
{
@@ -396,9 +396,34 @@ static struct platform_device da8xx_emac_device = {
.resource = da8xx_emac_resources,
};
+static struct resource da8xx_mdio_resources[] = {
+ {
+ .start = DA8XX_EMAC_MDIO_BASE,
+ .end= DA8XX_EMAC_MDIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device da8xx_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(da8xx_mdio_resources),
+ .resource = da8xx_mdio_resources,
+};
+
int __init da8xx_register_emac(void)
{
- return platform_device_register(da8xx_emac_device);
+ int ret;
+
+ ret = platform_device_register(da8xx_mdio_device);
+ if (ret 0)
+ return ret;
+ ret = platform_device_register(da8xx_emac_device);
+ if (ret 0)
+ return ret;
+ ret = clk_add_alias(NULL, dev_name(da8xx_mdio_device.dev),
+ NULL, da8xx_emac_device.dev);
+ return ret;
}
static struct resource da830_mcasp1_resources[] = {
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 7781e35..0add1ca 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -699,7 +699,7 @@ static struct emac_platform_data dm365_emac_pdata = {
static struct resource dm365_emac_resources[] = {
{
.start = DM365_EMAC_BASE,
- .end= DM365_EMAC_BASE + 0x47ff,
+ .end= DM365_EMAC_BASE + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
{
@@ -734,6 +734,21 @@ static struct platform_device dm365_emac_device = {
.resource = dm365_emac_resources,
};
+static struct resource dm365_mdio_resources[] = {
+ {
+ .start = DM365_EMAC_MDIO_BASE,
+ .end= DM365_EMAC_MDIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm365_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(dm365_mdio_resources),
+ .resource = dm365_mdio_resources,
+};
+
static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_VDINT0]= 2,
[IRQ_VDINT1]= 6,
@@ -1219,7 +1234,12 @@ static int __init dm365_init_devices(void)
davinci_cfg_reg(DM365_INT_EDMA_CC);
platform_device_register(dm365_edma_device);
+
+ platform_device_register(dm365_mdio_device);
platform_device_register(dm365_emac_device);
+ clk_add_alias(NULL, dev_name(dm365_mdio_device.dev),
+ NULL, dm365_emac_device.dev);
+
/* Add isif clock alias */
clk_add_alias(master, dm365_isif_dev.name, vpss_master, NULL);
platform_device_register(dm365_vpss_device);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 5e5b0a7..7dc71c1 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -330,7 +330,7 @@ static struct emac_platform_data dm644x_emac_pdata = {
static struct resource dm644x_emac_resources[] = {
{
.start = DM644X_EMAC_BASE,
- .end= DM644X_EMAC_BASE + 0x47ff,
+ .end= DM644X_EMAC_BASE + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
{
@@ -350,6 +350,21 @@ static struct platform_device
[PATCH v2 04/10] net: davinci_emac: switch to new mdio
This patch switches the emac implementation over to the newly separated
MDIO driver.
With this, the mdio bus frequency defaults to a safe 2.2MHz. Boards may
optionally specify a bus frequency via platform data.
The phy identification scheme has been modified to use a phy bus id instead
of a mask. This largely serves to eliminate the phy search code in emac
init.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
drivers/net/Kconfig |1 +
drivers/net/davinci_emac.c | 88 ++---
include/linux/davinci_emac.h |1 +
3 files changed, 32 insertions(+), 58 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c5c86e0..911e7f1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -951,6 +951,7 @@ config NET_NETX
config TI_DAVINCI_EMAC
tristate TI DaVinci EMAC Support
depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 )
+ select TI_DAVINCI_MDIO
select PHYLIB
help
This driver supports TI's DaVinci Ethernet .
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 7fbd052..6ed779d 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -500,6 +500,7 @@ struct emac_priv {
u32 phy_mask;
/* mii_bus,phy members */
struct mii_bus *mii_bus;
+ const char *phy_id;
struct phy_device *phydev;
spinlock_t lock;
/*platform specific members*/
@@ -686,7 +687,7 @@ static int emac_get_settings(struct net_device *ndev,
struct ethtool_cmd *ecmd)
{
struct emac_priv *priv = netdev_priv(ndev);
- if (priv-phy_mask)
+ if (priv-phydev)
return phy_ethtool_gset(priv-phydev, ecmd);
else
return -EOPNOTSUPP;
@@ -704,7 +705,7 @@ static int emac_get_settings(struct net_device *ndev,
static int emac_set_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
{
struct emac_priv *priv = netdev_priv(ndev);
- if (priv-phy_mask)
+ if (priv-phydev)
return phy_ethtool_sset(priv-phydev, ecmd);
else
return -EOPNOTSUPP;
@@ -841,7 +842,7 @@ static void emac_update_phystatus(struct emac_priv *priv)
mac_control = emac_read(EMAC_MACCONTROL);
cur_duplex = (mac_control EMAC_MACCONTROL_FULLDUPLEXEN) ?
DUPLEX_FULL : DUPLEX_HALF;
- if (priv-phy_mask)
+ if (priv-phydev)
new_duplex = priv-phydev-duplex;
else
new_duplex = DUPLEX_FULL;
@@ -2485,6 +2486,11 @@ static int emac_devioctl(struct net_device *ndev, struct
ifreq *ifrq, int cmd)
return -EOPNOTSUPP;
}
+static int match_first_device(struct device *dev, void *data)
+{
+ return 1;
+}
+
/**
* emac_dev_open: EMAC device open
* @ndev: The DaVinci EMAC network adapter
@@ -2499,7 +2505,6 @@ static int emac_dev_open(struct net_device *ndev)
{
struct device *emac_dev = ndev-dev;
u32 rc, cnt, ch;
- int phy_addr;
struct resource *res;
int q, m;
int i = 0;
@@ -2560,28 +2565,26 @@ static int emac_dev_open(struct net_device *ndev)
emac_set_coalesce(ndev, coal);
}
- /* find the first phy */
priv-phydev = NULL;
- if (priv-phy_mask) {
- emac_mii_reset(priv-mii_bus);
- for (phy_addr = 0; phy_addr PHY_MAX_ADDR; phy_addr++) {
- if (priv-mii_bus-phy_map[phy_addr]) {
- priv-phydev = priv-mii_bus-phy_map[phy_addr];
- break;
- }
- }
+ /* use the first phy on the bus if pdata did not give us a phy id */
+ if (!priv-phy_id) {
+ struct device *phy;
- if (!priv-phydev) {
- printk(KERN_ERR %s: no PHY found\n, ndev-name);
- return -1;
- }
+ phy = bus_find_device(mdio_bus_type, NULL, NULL,
+ match_first_device);
+ if (phy)
+ priv-phy_id = dev_name(phy);
+ }
- priv-phydev = phy_connect(ndev, dev_name(priv-phydev-dev),
- emac_adjust_link, 0, PHY_INTERFACE_MODE_MII);
+ if (priv-phy_id) {
+ priv-phydev = phy_connect(ndev, priv-phy_id,
+ emac_adjust_link, 0,
+ PHY_INTERFACE_MODE_MII);
if (IS_ERR(priv-phydev)) {
- printk(KERN_ERR %s: Could not attach to PHY\n,
- ndev-name);
+ dev_err(emac_dev, could not connect to phy %s\n,
+ priv-phy_id);
+ priv-phydev = NULL;
return PTR_ERR(priv-phydev);
[PATCH v2 03/10] omap: add mdio platform devices
This patch adds mdio platform devices on SoCs that have the necessary
hardware. Clock lookup entries (aliases) have also been added, so that the
MDIO and EMAC drivers can independently enable/disable a shared underlying
clock. Further, the EMAC MMR region has been split down into separate MDIO
and EMAC regions.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 4d0f585..5dd1b73 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
+#include linux/clk.h
#include linux/platform_device.h
#include linux/gpio.h
#include linux/i2c/pca953x.h
@@ -41,6 +42,27 @@
#define AM35XX_EVM_PHY_MASK(0xF)
#define AM35XX_EVM_MDIO_FREQUENCY (100)
+static struct mdio_platform_data am3517_evm_mdio_pdata = {
+ .bus_freq = AM35XX_EVM_MDIO_FREQUENCY,
+};
+
+static struct resource am3517_mdio_resources[] = {
+ {
+ .start = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+ .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device am3517_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(am3517_mdio_resources),
+ .resource = am3517_mdio_resources,
+ .dev.platform_data = am3517_evm_mdio_pdata,
+};
+
static struct emac_platform_data am3517_evm_emac_pdata = {
.phy_mask = AM35XX_EVM_PHY_MASK,
.mdio_max_freq = AM35XX_EVM_MDIO_FREQUENCY,
@@ -50,7 +72,7 @@ static struct emac_platform_data am3517_evm_emac_pdata = {
static struct resource am3517_emac_resources[] = {
{
.start = AM35XX_IPSS_EMAC_BASE,
- .end= AM35XX_IPSS_EMAC_BASE + 0x3,
+ .end= AM35XX_IPSS_EMAC_BASE + 0x2,
.flags = IORESOURCE_MEM,
},
{
@@ -121,6 +143,9 @@ void am3517_evm_ethernet_init(struct emac_platform_data
*pdata)
pdata-interrupt_disable= am3517_disable_ethernet_int;
am3517_emac_device.dev.platform_data= pdata;
platform_device_register(am3517_emac_device);
+ platform_device_register(am3517_mdio_device);
+ clk_add_alias(NULL, dev_name(am3517_mdio_device.dev),
+ NULL, am3517_emac_device.dev);
regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
regval = regval (~(AM35XX_CPGMACSS_SW_RST));
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP
* Tony Lindgren t...@atomide.com [100902 09:29]: * Russell King - ARM Linux li...@arm.linux.org.uk [100902 09:18]: On Thu, Sep 02, 2010 at 09:20:40AM -0700, Tony Lindgren wrote: From 253e91b76e104dbdf05c5c3eaf9cbf426972c938 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Wed, 1 Sep 2010 16:49:13 -0700 Subject: [PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP Fix v7wbi_tlb_flags for SMP on UP. Note that we must enable MULTI_TLB to avoid undefined reference to cpu_tlb error. This isn't required, as it is already covered by my patch. Yup, seems to be working without this patch. Correction, only boots on SMP hardawre. On UP hardware I still need the following patch. Left out forcing MULTI_TLB as looks like your patch already does that. Also noticed I'm now getting unhandled fault on SMP system which I was not getting earlier. Will try to track it down. Tony From: Tony Lindgren t...@atomide.com Date: Wed, 1 Sep 2010 16:49:13 -0700 Subject: [PATCH] ARM: Fix v7wbi_tlb_flags for SMP on UP Fix v7wbi_tlb_flags for SMP on UP. Note that depends on MULTI_TLB to avoid undefined reference to cpu_tlb error. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h index 1fd0db9..692e9cf 100644 --- a/arch/arm/include/asm/tlbflush.h +++ b/arch/arm/include/asm/tlbflush.h @@ -189,20 +189,29 @@ # define v6wbi_always_flags (-1UL) #endif +#define v7wbi_tlb_flags_common (TLB_WB | TLB_DCLEAN) #define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \ TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID) #define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BTB | \ TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID) #ifdef CONFIG_SMP +#ifdef CONFIG_SMP_ON_UP +#define v7wbi_tlb_flags (v7wbi_tlb_flags_smp | v7wbi_tlb_flags_up) +#else #define v7wbi_tlb_flags v7wbi_tlb_flags_smp +#endif #else #define v7wbi_tlb_flags v7wbi_tlb_flags_up #endif #ifdef CONFIG_CPU_TLB_V7 # define v7wbi_possible_flags v7wbi_tlb_flags -# define v7wbi_always_flags v7wbi_tlb_flags +# ifdef CONFIG_SMP_ON_UP +# define v7wbi_always_flags v7wbi_tlb_flags_common +# else +# define v7wbi_always_flags v7wbi_tlb_flags +# endif # ifdef _TLB # define MULTI_TLB 1 # else
Re: [PATCH] USB: otg: twl4030: fix phy initialization
2010/9/3 Felipe Balbi m...@felipebalbi.com:
Hi,
thanks for your comments.
On Thu, 2 Sep 2010 23:58:18 +0800, tom.leim...@gmail.com wrote:
From: Ming Lei tom.leim...@gmail.com
Commit 461c317705eca5cac09a360f488715927fd0a927(into 2.6.36-v3)
is put forward to power down phy if no usb cable is connected,
but does introduce the two issues below:
1), phy is not into work state if usb cable is connected
with PC during poweron, so musb device mode is not usable
in such case, follows the reasons:
I'm pretty sure I verified both cases.
Could you verify the beagle board in such case? If you commit is
reverted, no issue #1 for me.
-twl4030_phy_resume is not called, so
regulators are not enabled
i2c access are not enabled
usb mode not configurated
2), The kernel warings[1] of regulators 'unbalanced disables'
is caused if poweron without usb cable connected
with PC or b-device.
This patch fixes the two issues above:
-power down phy only if no usb cable is connected with PC
and b-device
-do phy initialization(via __twl4030_phy_resume) if usb cable
is connected with PC(vbus event) or another b-device(ID event) in
twl4030_usb_probe.
This patch is verified OK on Beagle board either connected with
usb cable or not when poweron.
I kinda doubt it, would have to test it myself, but I'm without
enough gear to test it again.
See my analysis below.
[1]. warnings of 'unbalanced disables' of regulators.
[r...@omap3evm /]# dmesg
[ cut here ]
WARNING: at drivers/regulator/core.c:1357
_regulator_disable+0x38/0x128()
this should not have been caused by that patch, though.
It is surely caused by usb twl4030 otg driver if otg phy is not power down
in bootloader.
See my analysis below.
Cc: Felipe Balbi felipe.ba...@nokia.com
this email doesn't exist anymore... I'm yet to subscribe the new one,
for now keep this one in Cc, sorry for that.
diff --git a/drivers/usb/otg/twl4030-usb.c
b/drivers/usb/otg/twl4030-usb.c
index 05aaac1..df6381f 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -347,11 +347,22 @@ static void twl4030_i2c_access(struct twl4030_usb
*twl, int on)
}
}
-static void twl4030_phy_power(struct twl4030_usb *twl, int on)
+static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
+ u8 old_pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
u8 pwr;
- pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
+ if (on)
+ pwr = old_pwr ~PHY_PWR_PHYPWD;
+ else
+ pwr = old_pwr | PHY_PWR_PHYPWD;
+
+ if (pwr != old_pwr)
+ WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
writing 1 if register is one won't cause any problems, you're just
wasting a variable.
+static void twl4030_phy_power(struct twl4030_usb *twl, int on)
+{
if (on) {
regulator_enable(twl-usb3v1);
regulator_enable(twl-usb1v8);
@@ -365,15 +376,13 @@ static void twl4030_phy_power(struct twl4030_usb
*twl, int on)
twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0,
VUSB_DEDICATED2);
regulator_enable(twl-usb1v5);
- pwr = ~PHY_PWR_PHYPWD;
- WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
+ __twl4030_phy_power(twl, 1);
twl4030_usb_write(twl, PHY_CLK_CTRL,
twl4030_usb_read(twl, PHY_CLK_CTRL) |
(PHY_CLK_CTRL_CLOCKGATING_EN |
PHY_CLK_CTRL_CLK32K_EN));
} else {
- pwr |= PHY_PWR_PHYPWD;
- WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
+ __twl4030_phy_power(twl, 0);
regulator_disable(twl-usb1v5);
regulator_disable(twl-usb1v8);
regulator_disable(twl-usb3v1);
@@ -387,19 +396,25 @@ static void twl4030_phy_suspend(struct twl4030_usb
*twl, int controller_off)
twl4030_phy_power(twl, 0);
twl-asleep = 1;
+ dev_dbg(twl-dev, %s\n, __func__);
this is noise.
It is useful to troubleshoot the two issues above, and I can
remove it if you doesn't like it.
}
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_resume(struct twl4030_usb *twl)
{
- if (!twl-asleep)
- return;
-
twl4030_phy_power(twl, 1);
twl4030_i2c_access(twl, 1);
twl4030_usb_set_mode(twl, twl-usb_mode);
if (twl-usb_mode == T2_USB_MODE_ULPI)
twl4030_i2c_access(twl, 0);
+}
+
+static void twl4030_phy_resume(struct twl4030_usb *twl)
+{
+ if (!twl-asleep)
+ return;
+ __twl4030_phy_resume(twl);
twl-asleep = 0;
+ dev_dbg(twl-dev, %s\n, __func__);
this is noise.
see above.
@@ -502,6 +517,26 @@ static
Re: [PATCH 1/6] ARM: Add inline function smp_cpu() for early init testing
* Tony Lindgren t...@atomide.com [100902 17:00]:
* Tony Lindgren t...@atomide.com [100902 12:20]:
Heh, turns out there's a bit of a bug in the code snippet above :) It should
be !((mpidr 30) 1) instead, otherwise it always returns 0.
This too can check for value of 2. Also we probably want to do the
CPU type checks too. Updated patch below.
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 30 Aug 2010 14:00:54 -0700
Subject: [PATCH] ARM: Add inline function smp_cpu() for early init testing
Add inline function smp_cpu() for early init checks, and
change build_mem_type_table to use it.
Inline function copied from cpu_is_part_of_mp_system() by
Will Deacon will.dea...@arm.com.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 8db3512..50a4f0b 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -39,4 +39,24 @@ static inline int cache_ops_need_broadcast(void)
#define UP(instr...) _str(instr)
#endif
+static inline int smp_cpu(void)
+{
+u32 val;
+
+ val = read_cpuid(CPUID_ID);
+
+ /* Check for ARM CPU */
+ if ((val 0xff00) != 0x4100)
+ return 0;
+
+ /* Check for ARMv6 or 7 */
+ if ((val 0x0007) != 0x0007)
+ return 0;
+
+ /* Check MPIDR */
+asm (mrc p15, 0, %0, c0, c0, 5 : =r (val));
+
+return (val 30) == 2;
+}
+
#endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 6e1c4f6..2bfaefd 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -430,15 +430,17 @@ static void __init build_mem_type_table(void)
/*
* Mark memory with the shared attribute for SMP systems
*/
- user_pgprot |= L_PTE_SHARED;
- kern_pgprot |= L_PTE_SHARED;
- vecs_pgprot |= L_PTE_SHARED;
- mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
- mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
- mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
- mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ if (smp_cpu()) {
+ user_pgprot |= L_PTE_SHARED;
+ kern_pgprot |= L_PTE_SHARED;
+ vecs_pgprot |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
+ mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ }
#endif
}
Re: [PATCH V2] OMAP: DSS2: don't power off a panel twice
Hi, Tomi, Tomi Valkeinen wrote: snip Otherwise this looks fine, except that panel-taal.c does not need modifications, as it already handles this case. I will send a V3 to remove the panel-taal.c part. Also, at some point I (or somebody else =) should think how to do proper locking for the panel drivers. Currently it's rather broken, and, for example, enabling and disabling a panel at the same time will cause problems. Except for panel-taal, which uses its own lock. First, I don't think there is any occasion where you need to enable and disable a panel at the same time. If so, what kind of result do you want ? enabled or disabled ? Second, now the dssdev-state can do the lock job properly. It can ensure only one function can run if both disable() and enable are called at the same time. Stanley. Tomi -- 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 V3] OMAP: DSS2: don't power off a panel twice
If we blank the panel by
echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank
Then, we reboot the sytem, the kernel will crash at
drivers/video/omap2/dss/core.c:323
This is because the panel is closed twice. Now check the state of a dssdev
to forbid a panel is power on or power off twice.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
drivers/video/omap2/displays/panel-acx565akm.c |6 ++
drivers/video/omap2/displays/panel-generic.c |6 ++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 ++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 ++
.../video/omap2/displays/panel-toppoly-tdo35s.c|6 ++
.../video/omap2/displays/panel-tpo-td043mtea1.c|6 ++
6 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index 07fbb8a..e773106 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -587,6 +587,9 @@ static int acx_panel_power_on(struct omap_dss_device
*dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
mutex_lock(md-mutex);
r = omapdss_sdi_display_enable(dssdev);
@@ -644,6 +647,9 @@ static void acx_panel_power_off(struct omap_dss_device
*dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
mutex_lock(md-mutex);
if (!md-enabled) {
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..395a68d 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -39,6 +39,9 @@ static int generic_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -58,6 +61,9 @@ err0:
static void generic_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
index 1026746..0c6896c 100644
--- a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
+++ b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
@@ -43,6 +43,9 @@ static int sharp_lq_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -65,6 +68,9 @@ err0:
static void sharp_lq_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 7d9eb2b..9a138f6 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -135,6 +135,9 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
{
int r = 0;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -157,6 +160,9 @@ err0:
static void sharp_ls_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
index e320e67..526e906 100644
--- a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
+++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
@@ -46,6 +46,9 @@ static int toppoly_tdo_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -65,6 +68,9 @@ err0:
static void toppoly_tdo_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index e866e76..dbe9d43 100644
---
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
On Fri, Sep 3, 2010 at 12:16 AM, Tony Lindgren t...@atomide.com wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100902 06:29]: On Mon, Aug 30, 2010 at 03:55:27PM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [100820 04:59]: * Russell King - ARM Linux li...@arm.linux.org.uk [100819 13:13]: On Thu, Aug 19, 2010 at 12:57:06PM +0300, Tony Lindgren wrote: Looks like something is not quite right with smp_on_up part of __fixup_smp, returning early before smp_on_up does not produce that. It's probably overwriting some register it shouldn't be. I might be able to look at this sometime during the coming week... assuming that the weather is as bad as they forecast and I have 'net connectivity. This seems to fix it. Thanks, merged that into my original patch - so here it is again with everything updated. Your patch sure makes things simpler! The problem still is the V6 vs V7 SMP code though. Will post my six patches that apply on top of your patch as a reply to this mail. With those, everything seems to work, at least after testing on omap3630 (Cortex-A8 UP) and omap4430 (Cortex-A9 SMP). Awesome, where can get those finalize the patches for testing? After that I can test our Ubuntu kernel on both boards. Thanks, -Bryan -- 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
