[GIT PULL] OMAP USB Changes for Merge Window
Hi Tony, please queue the following two patches for Merge Window. The following changes since commit b79540fcbbcf9b379c9197f63c5a883bbe3adfd4: Linux-omap rebuilt: Merged branches from Paul and Kevin and mux changes (2010-12-22 19:13:33 -0800) are available in the git repository at: git://gitorious.org/usb/usb.git for-tony Felipe Balbi (1): arm: omap: tusb6010: add name for MUSB IRQ Srinath (1): arm: omap: craneboard: Add USB EHCI support arch/arm/mach-omap2/board-am3517crane.c | 48 +++ arch/arm/mach-omap2/usb-tusb6010.c |1 + 2 files changed, 49 insertions(+), 0 deletions(-) -- 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
[PATCH 2/2] arm: omap: tusb6010: add name for MUSB IRQ
commit fcf173e4511193b1efeccb0f22a8c641b464353b
(add names for IRQs in structure resource)
forgot to take care of tusb6010 making it
fail to probe due to a missing resource.
Fix it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index 1e998ea..30f112b 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -216,6 +216,7 @@ static struct resource tusb_resources[] = {
.flags = IORESOURCE_MEM,
},
{ /* IRQ */
+ .name = mc,
.flags = IORESOURCE_IRQ,
},
};
--
1.7.3.4.598.g85356
--
To unsubscribe from this list: send the line unsubscribe 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 v1 02/10] OMAP: McBSP: Convert McBSP to platform device model
Kishon,
On Tue, Dec 21, 2010 at 13:10, Kishon Vijay Abraham I kis...@ti.com wrote:
Implement McBSP as platform device and add support for
registering through platform device layer using resource
structures.
Later in this patch series, OMAP2+ McBSP driver would be modified to
use hwmod framework after populating the omap2+ hwmod database.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap1/mcbsp.c | 383 ++---
arch/arm/mach-omap2/mcbsp.c | 708
+--
arch/arm/plat-omap/devices.c | 10 +-
arch/arm/plat-omap/include/plat/mcbsp.h | 14 +-
arch/arm/plat-omap/mcbsp.c | 60 +++-
5 files changed, 969 insertions(+), 206 deletions(-)
diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
index 372ea71..4324ba4 100644
--- a/arch/arm/mach-omap1/mcbsp.c
+++ b/arch/arm/mach-omap1/mcbsp.c
@@ -10,6 +10,7 @@
*
* Multichannel mode not supported.
*/
+#include linux/ioport.h
#include linux/module.h
#include linux/init.h
#include linux/clk.h
@@ -78,114 +79,354 @@ static struct omap_mcbsp_ops omap1_mcbsp_ops = {
};
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
+struct resource omap7xx_mcbsp_res[][6] = {
+ {
+ {
+ .name = mpu,
+ .start = OMAP7XX_MCBSP1_BASE,
+ .end = OMAP7XX_MCBSP1_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = dma,
+ .start = OMAP7XX_MCBSP1_BASE,
+ .end = OMAP7XX_MCBSP1_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
The above two resources looks similar except for the name. It would be
good to mention the reason for
providing two resource names for a single resource.
Same comment applicable to all McBSPs in other OMAPs too.
-V Charulatha
--
To unsubscribe from this list: send the line unsubscribe 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] smsc911x: add disable and re-enable Rx int to de-assert interrupt pin
When kernel enters irqhanlder, it will check the Rx interrupt status
bit, if Rx status is set but can't call napi_schedule(), it will do
nothing and directly return form irqhandler. This situation is prone
to be produced when we repeatly call irqhandler through netpoll
interface(i.e kgdboe connecting).
This is a potential risk for those level triggered platforms(i.e
ti_omap3evm), because if we don't handle Rx int and just return from
irqhandler, the irq pin will be keeping asserted, the level triggered
platforms will have no chance to jump out from the Rx irq. The whole
system will hung into the irq subsystem.
To solve it, we add a disable/re-enable Rx int operation for this
situation, this operation can de-assert interrupt pin for this time
and will leave the received data and status in the FIFO for later
interrupts to handle.
Signed-off-by: Jason Wang jason77.w...@gmail.com
---
drivers/net/smsc911x.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index 64bfdae..dd6312f 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -1492,14 +1492,20 @@ static irqreturn_t smsc911x_irqhandler(int irq, void
*dev_id)
}
if (likely(intsts inten INT_STS_RSFL_)) {
- if (likely(napi_schedule_prep(pdata-napi))) {
- /* Disable Rx interrupts */
- temp = smsc911x_reg_read(pdata, INT_EN);
- temp = (~INT_EN_RSFL_EN_);
- smsc911x_reg_write(pdata, INT_EN, temp);
+ /* Disable Rx interrupts first, if doesn't meet
+* napi_schedule_prep(), we will re-enable Rx interrupts. This
+* disable and re-enable pair operation can De-assert interrupt
+* line and is more safer to those level triggered platforms. */
+ temp = smsc911x_reg_read(pdata, INT_EN);
+ temp = (~INT_EN_RSFL_EN_);
+ smsc911x_reg_write(pdata, INT_EN, temp);
+
+ if (likely(napi_schedule_prep(pdata-napi)))
/* Schedule a NAPI poll */
__napi_schedule(pdata-napi);
- } else {
+ else {
+ temp |= INT_EN_RSFL_EN_;
+ smsc911x_reg_write(pdata, INT_EN, temp);
SMSC_WARNING(RX_ERR,
napi_schedule_prep failed);
}
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe 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 v7 12/12] OMAP2: dmtimer: set wakeup enable explicitly in plat
Benoit,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti
Sent: Wednesday, December 22, 2010 5:02 PM
To: Cousson, Benoit
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH v7 12/12] OMAP2: dmtimer: set wakeup enable explicitly
in plat
Hello Benoit,
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, December 21, 2010 4:42 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v7 12/12] OMAP2: dmtimer: set wakeup enable
explicitly
in plat
Hi Tarun,
On 12/20/2010 11:05 PM, DebBarma, Tarun Kanti wrote:
For some reason the wakeup enable bit is not getting set on OMAP2430,
OMAP2420. This is inspite of the fact that SYSC_HAS_ENAWAKEUP flag is
present in the hwmod database.
This is indeed strange. Did you observe that on OMAP3 4?
I am NOT seeing this on OMAP3 and OMAP4.
Did you use the patch that Kevin did recently to fix an issue with the
ENAWAKEUP bit?
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-
pm.git;a=commit;h=d15ae13fc7428a95b02c1935ebf92324fcb80a5f
No, I have tested on mainline. Right now I am testing on Kevin's
PM branch and will see the result.
The point is that this fix is not really acceptable for my point of
view:-
(
You really have to check what is going on in the hwmod _enable_wakeup
function.
Yes, I understand. Let's check if this problem goes away in Kevin's
setup.
I am seeing the problem with Kevin's setup as well.
--
Tarun
I am not sure if there is already a patch to fix this problem. Until
the
reason is found we need this patch to boot on the above platforms.
Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-
omap/dmtimer.c
index f4aa4a1..007b754 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -227,6 +227,7 @@ static void omap_dm_timer_write_reg(struct
omap_dm_timer *timer, u32 reg,
static void omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
+ u32 l;
struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
if (!pdata-is_omap16xx) {
@@ -243,6 +244,18 @@ static void omap_dm_timer_prepare(struct
omap_dm_timer *timer)
if (pdata-dm_timer_reset)
pdata-dm_timer_reset(timer);
+ /*
+ * Enable wake-up on OMAP2420, OMAP2430 CPUs.
+ * FIXME: SYSC_HAS_ENAWAKEUP flag is already set in hwmod
database.
+ * But the setting does not seem to work. Need to investigate
why
+ * this is happening.
+ */
+ if (cpu_is_omap2430() || cpu_is_omap2420()) {
+ l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG);
+ l |= 1 2;
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_REG, l);
+ }
+
omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
/* Match hardware reset default of posted mode */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
Hi Thara,
On 12/20/2010 6:00 PM, Gopinath, Thara wrote:
From: Benoit Coussonb-cous...@ti.com
This patch adds the hwmod details for OMAP4 smartreflex modules.
Signed-off-by: Benoit Coussonb-cous...@ti.com
You're s-o-b is missing, along with the changed you did to the patch.
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 168
1 files changed, 168 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7367648..0a6e674 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1740,6 +1740,169 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'smartreflex' class
+ * smartreflex module (monitor silicon performance and outputs a measure of
+ * performance error)
+ */
+
+/* The IP is not compliant to type1 / type2 scheme */
+static struct omap_hwmod_sysc_fields omap_hwmod_sysc_type_smartreflex = {
+ .sidle_shift= 24,
+ .enwkup_shift = 26,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_smartreflex_sysc = {
+ .sysc_offs = 0x0038,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
The newly added SIDLE_SMART_WKUP flag is missing.
+ .sysc_fields=omap_hwmod_sysc_type_smartreflex,
+};
+
+static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
+ .name = smartreflex,
+ .sysc =omap44xx_smartreflex_sysc,
+ .rev = 2,
+};
+
+/* smartreflex_core */
+static struct omap_hwmod omap44xx_smartreflex_core_hwmod;
+static struct omap_hwmod_irq_info omap44xx_smartreflex_core_irqs[] = {
+ { .irq = 19 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_smartreflex_core_addrs[] = {
+ {
+ .pa_start = 0x4a0dd000,
+ .pa_end = 0x4a0dd03f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - smartreflex_core */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__smartreflex_core = {
+ .master =omap44xx_l4_cfg_hwmod,
+ .slave =omap44xx_smartreflex_core_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_smartreflex_core_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* smartreflex_core slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_smartreflex_core_slaves[] = {
+ omap44xx_l4_cfg__smartreflex_core,
+};
+
+static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
+ .name = smartreflex_core,
+ .class =omap44xx_smartreflex_hwmod_class,
+ .mpu_irqs = omap44xx_smartreflex_core_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_irqs),
+ .main_clk = smartreflex_core_fck,
+ .vdd_name = core,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_ALWON_SR_CORE_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_smartreflex_core_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* smartreflex_iva */
+static struct omap_hwmod omap44xx_smartreflex_iva_hwmod;
+static struct omap_hwmod_irq_info omap44xx_smartreflex_iva_irqs[] = {
+ { .irq = 102 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_smartreflex_iva_addrs[] = {
+ {
+ .pa_start = 0x4a0db000,
+ .pa_end = 0x4a0db03f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - smartreflex_iva */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__smartreflex_iva = {
+ .master =omap44xx_l4_cfg_hwmod,
+ .slave =omap44xx_smartreflex_iva_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_smartreflex_iva_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* smartreflex_iva slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_smartreflex_iva_slaves[] = {
+ omap44xx_l4_cfg__smartreflex_iva,
+};
+
+static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
+ .name = smartreflex_iva,
+ .class =omap44xx_smartreflex_hwmod_class,
+ .mpu_irqs = omap44xx_smartreflex_iva_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_irqs),
+ .main_clk = smartreflex_iva_fck,
+ .vdd_name = iva,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_ALWON_SR_IVA_CLKCTRL,
+ },
+ },
+ .slaves
Re: [PATCH 1/6] Add infrastructure for conditional code and data sections
Hi, On Wed, 22 Dec 2010, Tony Lindgren wrote: * Thomas Petazzoni thomas.petazz...@free-electrons.com [101221 14:00]: On Tue, 21 Dec 2010 11:27:35 -0800 Tony Lindgren t...@atomide.com wrote: Therefore, we introduce an infrastructure that allows to put code and data into specific sections, called conditional sections. All those sections are compiled into the final kernel image, but at runtime, by calling a function, we can get rid of the unused sections. Great, something is certainly needed to free the unused memory. Nice to see that the idea is welcome. Did you had a look at the implementation in patch 1/6 ? No not yet, will take a look after we're done with this upcoming merge window.. I also think the idea is good, and this should be maybe posted to wider audience than just linux-omap. However, in order to be able to free each section independently from another, I have to page align all those conditional sections. This means that having one section for only a tiny amount of data is going to waste space instead of saving space. So the conditional section should gather a sufficiently large amount of data ( 4 KB) to actually be valuable. Yeah I don't know how much non-init data we have for each board-*.c file. Maybe there is not much for each machine. I took a quick look at omap2plus_defconfig kernel, and non-init text/data for 29 boards takes 85K. If we would page align those memory consumption would increase during init to 29*8=232K, but after other boards are freed we would eventually save 85-8=77K. Under mach-omap2, another big consumer is clock data which takes also around 80 K, while e.g. on 2420 only 14 K is needed. A. -- To unsubscribe from this list: send the line unsubscribe 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] Add infrastructure for conditional code and data sections
On Thu, 23 Dec 2010 14:31:46 +0200 (EET)
Aaro Koskinen aaro.koski...@nokia.com wrote:
No not yet, will take a look after we're done with this upcoming
merge window..
I also think the idea is good, and this should be maybe posted to wider
audience than just linux-omap.
Yes, definitely. As the proof of concept implementation was
demonstrating usage on OMAP, I wanted to have some early comments of
a few kernel developers before going to a wider audience.
Yeah I don't know how much non-init data we have for each board-*.c
file. Maybe there is not much for each machine.
I took a quick look at omap2plus_defconfig kernel, and non-init text/data
for 29 boards takes 85K. If we would page align those memory consumption
would increase during init to 29*8=232K, but after other boards are
freed we would eventually save 85-8=77K.
Thanks for those numbers. 77K is nice, but is not really a huge saving.
Under mach-omap2, another big consumer is clock data which takes also
around 80 K, while e.g. on 2420 only 14 K is needed.
My patch 3/6 (which didn't make it to the list, since it was probably
too large) already marked some OMAP2 clock data.
Unfortunately, I haven't found a nice way of putting strings into a
separate sections. For example:
static struct foobar __omap2 foo = {
.name = blabla,
.id = 12,
};
The struct foobar goes into the OMAP2-specific section (8 bytes), but
the blabla string (6 bytes) remains in the global .rodata section,
without anyway from removing it. The only solution I see so far would
be :
static char __omap2 foo_name[] = blabla;
static struct foobar __omap2 foo = {
.name = foo_name,
.id = 12,
};
but it's really unpleasant.
Other ideas ?
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
Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
On Thu, Dec 23, 2010 at 06:07, Cousson, Benoit b-cous...@ti.com wrote: Please note the following log when enabling SR in Class 3 on an OMAP4430/sdp: [ 2.362182] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu [ 2.369384] omap2_set_init_voltage: Unable to put vdd_mpu to its init voltage [ 2.369384] [ 2.378875] omap2_set_init_voltage: unable to find boot up OPP for vdd_iva [ 2.386108] omap2_set_init_voltage: Unable to put vdd_iva to its init voltage [ 2.386108] [ 2.396484] Power Management for TI OMAP4. [ 2.401031] sr_init: No PMIC hook to init smartreflex [ 2.406494] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [ 2.414825] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [ 2.423187] smartreflex smartreflex.2: omap_sr_probe: SmartReflex driver initialized [ 2.431732] SmartReflex Class3 initialized Dumb question: how are you testing this? just boot log? or additional patch for DVFS? 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
Last OMAP4 hwmod data cleanup for 2.6.38
Hi Tony, The merge of both SDMA series from Manju and SR series from Thara changed the expected order of the hwmod data structures for OMAP4. In order to have a clean base for 2.6.38, and to avoid starting 2.6.39 with a cleanup patch again, I'd like to fix that right now. Even if, I do agree, this is not a big deal. I squeezed the 3 original small fixes I did (SDMA, SR and alignment) into one to avoid overloading your mailbox 2 days before Xmas. The patch will be available here, based on omap-for-linus. git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod_fixes It should not affect any functionality, and it is boot tested on OMAP4430/sdp. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
On 12/23/2010 2:25 PM, Menon, Nishanth wrote: On Thu, Dec 23, 2010 at 06:07, Cousson, Benoitb-cous...@ti.com wrote: Please note the following log when enabling SR in Class 3 on an OMAP4430/sdp: [2.362182] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu [2.369384] omap2_set_init_voltage: Unable to put vdd_mpu to its init voltage [2.369384] [2.378875] omap2_set_init_voltage: unable to find boot up OPP for vdd_iva [2.386108] omap2_set_init_voltage: Unable to put vdd_iva to its init voltage [2.386108] [2.396484] Power Management for TI OMAP4. [2.401031] sr_init: No PMIC hook to init smartreflex [2.406494] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [2.414825] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [2.423187] smartreflex smartreflex.2: omap_sr_probe: SmartReflex driver initialized [2.431732] SmartReflex Class3 initialized Dumb question: how are you testing this? just boot log? or additional patch for DVFS? Unfortunately, it is just a boot log since I do not have any DVFS code on top of it :-( That's why I was not expecting any errors at that time. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
Benoit,
-Original Message-
From: Cousson, Benoit [mailto:b-cous...@ti.com]
Sent: Thursday, December 23, 2010 5:37 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
khil...@deeprootsystems.com; p...@pwsan.com; Sripathy,
Vishwanath; Sawant, Anand; Menon, Nishanth
Subject: Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for
smartreflex modules.
Hi Thara,
On 12/20/2010 6:00 PM, Gopinath, Thara wrote:
From: Benoit Coussonb-cous...@ti.com
This patch adds the hwmod details for OMAP4 smartreflex modules.
Signed-off-by: Benoit Coussonb-cous...@ti.com
You're s-o-b is missing, along with the changed you did to the patch.
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 168
1 files changed, 168 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7367648..0a6e674 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1740,6 +1740,169 @@ static struct omap_hwmod
omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'smartreflex' class
+ * smartreflex module (monitor silicon performance and outputs a
measure of
+ * performance error)
+ */
+
+/* The IP is not compliant to type1 / type2 scheme */
+static struct omap_hwmod_sysc_fields
omap_hwmod_sysc_type_smartreflex = {
+ .sidle_shift= 24,
+ .enwkup_shift = 26,
+};
+
+static struct omap_hwmod_class_sysconfig
omap44xx_smartreflex_sysc = {
+ .sysc_offs = 0x0038,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP |
SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
The newly added SIDLE_SMART_WKUP flag is missing.
+ .sysc_fields=omap_hwmod_sysc_type_smartreflex,
+};
+
+static struct omap_hwmod_class
omap44xx_smartreflex_hwmod_class = {
+ .name = smartreflex,
+ .sysc =omap44xx_smartreflex_sysc,
+ .rev = 2,
+};
+
+/* smartreflex_core */
+static struct omap_hwmod omap44xx_smartreflex_core_hwmod;
+static struct omap_hwmod_irq_info
omap44xx_smartreflex_core_irqs[] = {
+ { .irq = 19 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space
omap44xx_smartreflex_core_addrs[] = {
+ {
+ .pa_start = 0x4a0dd000,
+ .pa_end = 0x4a0dd03f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - smartreflex_core */
+static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__smartreflex_core = {
+ .master =omap44xx_l4_cfg_hwmod,
+ .slave =omap44xx_smartreflex_core_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_smartreflex_core_addrs,
+ .addr_cnt =
ARRAY_SIZE(omap44xx_smartreflex_core_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* smartreflex_core slave ports */
+static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_core_slaves[] = {
+ omap44xx_l4_cfg__smartreflex_core,
+};
+
+static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
+ .name = smartreflex_core,
+ .class =omap44xx_smartreflex_hwmod_class,
+ .mpu_irqs = omap44xx_smartreflex_core_irqs,
+ .mpu_irqs_cnt =
ARRAY_SIZE(omap44xx_smartreflex_core_irqs),
+ .main_clk = smartreflex_core_fck,
+ .vdd_name = core,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg =
OMAP4430_CM_ALWON_SR_CORE_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_smartreflex_core_slaves,
+ .slaves_cnt =
ARRAY_SIZE(omap44xx_smartreflex_core_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* smartreflex_iva */
+static struct omap_hwmod omap44xx_smartreflex_iva_hwmod;
+static struct omap_hwmod_irq_info
omap44xx_smartreflex_iva_irqs[] = {
+ { .irq = 102 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space
omap44xx_smartreflex_iva_addrs[] = {
+ {
+ .pa_start = 0x4a0db000,
+ .pa_end = 0x4a0db03f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - smartreflex_iva */
+static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__smartreflex_iva = {
+ .master =omap44xx_l4_cfg_hwmod,
+ .slave =omap44xx_smartreflex_iva_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_smartreflex_iva_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* smartreflex_iva slave ports */
+static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_iva_slaves[] = {
+ omap44xx_l4_cfg__smartreflex_iva,
+};
+
+static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
+ .name =
Re: Last OMAP4 hwmod data cleanup for 2.6.38
On Thu, Dec 23, 2010 at 03:02:31PM +0100, Cousson, Benoit wrote: Hi Tony, The merge of both SDMA series from Manju and SR series from Thara changed the expected order of the hwmod data structures for OMAP4. In order to have a clean base for 2.6.38, and to avoid starting 2.6.39 with a cleanup patch again, I'd like to fix that right now. Even if, I do agree, this is not a big deal. I squeezed the 3 original small fixes I did (SDMA, SR and alignment) into one to avoid overloading your mailbox 2 days before Xmas. The patch will be available here, based on omap-for-linus. git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod_fixes It should not affect any functionality, and it is boot tested on OMAP4430/sdp. Boot tested on SDP4430 and all DMA tests passes as expected. Tested-by: G, Manjunath Kondaiah manj...@ti.com -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
Vishwanath Sripathy vishwanath...@ti.com writes: [...] Please note the following log when enabling SR in Class 3 on an OMAP4430/sdp: [2.362182] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu [2.369384] omap2_set_init_voltage: Unable to put vdd_mpu to its init voltage [2.369384] [2.378875] omap2_set_init_voltage: unable to find boot up OPP for vdd_iva [2.386108] omap2_set_init_voltage: Unable to put vdd_iva to its init voltage [2.386108] [2.396484] Power Management for TI OMAP4. [2.401031] sr_init: No PMIC hook to init smartreflex [2.406494] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [2.414825] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [2.423187] smartreflex smartreflex.2: omap_sr_probe: SmartReflex driver initialized [2.431732] SmartReflex Class3 initialized Is it expected? Why do we have that blank line in-between? I think turbo OPPs are disabled by default in OPP table where as uboot is setting mpu and iva to turbo OPP. That's why you are getting this error. That explains the MPU OPPs, but only raises more questions. On what platforms was this tested? with *and* without turbo OPPs enabled? Does the voltage layer properly initialized if the boot up OPP is not found, and the initial voltage is not set? You should not get this error if you enable turbo opps in opp table. You would still get missing boot up OPP for IVA, as there are currenly no OMAP4 OPPs for IVA. Again, begging the question... how was this tested. 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] musb: am35x: fix compile error due to control apis
On Fri, 3 Dec 2010 23:42:45 +0530, Ajay Kumar Gupta ajay.gu...@ti.com wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. Is this change slated to go into 2.6.37? As it stands it looks like 2.6.37 will be released with completely broken musb support on many boards (including the BeagleBoard). - Ben -- To unsubscribe from this list: send the line unsubscribe 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] OMAP4: hwmod data: Fix SR flags, structures order and field alignment
Benoit Cousson b-cous...@ti.com writes:
Smartreflex is missing the recently introduced SIDLE_SMART_WKUP
flag in idlemodes field.
The merge of the DMA and SR series on top of the already modified
omap_hwmod_data_44xx.c moved the dma_system structure at the wrong
position in the file. The same thing happened for the SR structure.
- Re-order the structures properly.
In order to be fully aligned with the Python generator output,
change a couple of fields.
- Add tab in class and dev_attr structures to align fields
- Add a comma at the end of the following line to simplify the
code generation:
.pre_shutdown = omap2_wd_timer_disable,
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 573
++--
1 files changed, 285 insertions(+), 288 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e2ad1b6..c2806bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -66,7 +66,7 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod;
* instance(s): dmm
*/
static struct omap_hwmod_class omap44xx_dmm_hwmod_class = {
- .name = dmm,
+ .name = dmm,
};
/* dmm interface data */
@@ -121,7 +121,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod = {
* instance(s): emif_fw
*/
static struct omap_hwmod_class omap44xx_emif_fw_hwmod_class = {
- .name = emif_fw,
+ .name = emif_fw,
};
/* emif_fw interface data */
@@ -170,7 +170,7 @@ static struct omap_hwmod omap44xx_emif_fw_hwmod = {
* instance(s): l3_instr, l3_main_1, l3_main_2, l3_main_3
*/
static struct omap_hwmod_class omap44xx_l3_hwmod_class = {
- .name = l3,
+ .name = l3,
};
/* l3_instr interface data */
@@ -254,6 +254,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
};
/* l3_main_2 interface data */
+/* dma_system - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
+ .master = omap44xx_dma_system_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* iva - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_iva__l3_main_2 = {
.master = omap44xx_iva_hwmod,
@@ -270,14 +278,6 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_1__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* dma_system - l3_main_2 */
-static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
- .master = omap44xx_dma_system_hwmod,
- .slave = omap44xx_l3_main_2_hwmod,
- .clk= l3_div_ck,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
/* l4_cfg - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = {
.master = omap44xx_l4_cfg_hwmod,
@@ -347,7 +347,7 @@ static struct omap_hwmod omap44xx_l3_main_3_hwmod = {
* instance(s): l4_abe, l4_cfg, l4_per, l4_wkup
*/
static struct omap_hwmod_class omap44xx_l4_hwmod_class = {
- .name = l4,
+ .name = l4,
};
/* l4_abe interface data */
@@ -461,7 +461,7 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
* instance(s): mpu_private
*/
static struct omap_hwmod_class omap44xx_mpu_bus_hwmod_class = {
- .name = mpu_bus,
+ .name = mpu_bus,
};
/* mpu_private interface data */
@@ -506,7 +506,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* ctrl_module_pad_wkup
* ctrl_module_wkup
* debugss
- * dma_system
* dmic
* dss
* dss_dispc
@@ -556,9 +555,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* sl2if
* slimbus1
* slimbus2
- * smartreflex_core
- * smartreflex_iva
- * smartreflex_mpu
* spinlock
* timer1
* timer10
@@ -580,12 +576,98 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
*/
/*
+ * 'dma' class
+ * dma controller for data exchange between memory to memory (i.e. internal
or
+ * external memory) and gp peripherals to memory or memory to gp peripherals
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+SYSC_HAS_EMUFREE | SYSC_HAS_MIDLEMODE |
+SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+MSTANDBY_FORCE | MSTANDBY_NO |
RE: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
Nishant, -Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Thursday, December 23, 2010 10:55 PM To: Kevin Hilman Cc: Vishwanath Sripathy; Benoit Cousson; Thara Gopinath; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; p...@pwsan.com; Anand Sawant Subject: Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules. Kevin Hilman had written, on 12/23/2010 11:15 AM, the following: Vishwanath Sripathy vishwanath...@ti.com writes: [...] Please note the following log when enabling SR in Class 3 on an OMAP4430/sdp: [2.362182] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu [2.369384] omap2_set_init_voltage: Unable to put vdd_mpu to its init voltage [2.369384] [2.378875] omap2_set_init_voltage: unable to find boot up OPP for vdd_iva [2.386108] omap2_set_init_voltage: Unable to put vdd_iva to its init voltage [2.386108] [2.396484] Power Management for TI OMAP4. [2.401031] sr_init: No PMIC hook to init smartreflex [2.406494] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [2.414825] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [2.423187] smartreflex smartreflex.2: omap_sr_probe: SmartReflex driver initialized [2.431732] SmartReflex Class3 initialized Is it expected? Why do we have that blank line in-between? I think turbo OPPs are disabled by default in OPP table where as uboot is setting mpu and iva to turbo OPP. That's why you are getting this error. That explains the MPU OPPs, but only raises more questions. On what platforms was this tested? with *and* without turbo OPPs enabled? Does the voltage layer properly initialized if the boot up OPP is not found, and the initial voltage is not set? You should not get this error if you enable turbo opps in opp table. If the platform SDP4430 is capable of booting up in higher (turbo) OPP, that OPP should have been enabled in the board file! I have'nt seen a patch for that yet You would still get missing boot up OPP for IVA, as there are currenly no OMAP4 OPPs for IVA. Again, begging the question... how was this tested. Further, why is SR enabled by default on this platform if it does not have all domains available to be enabled (e.x. we dont have it on PandaBoard even though it is OMAP4 rt?) Why do you think SR is enabled by default? The above log says that SR Module is initialized. However sr auto compensation is not started by default. Vishwa -- 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] smsc911x: add disable and re-enable Rx int to de-assert interrupt pin
From: Jason Wang jason77.w...@gmail.com Date: Thu, 23 Dec 2010 18:43:13 +0800 When kernel enters irqhanlder, it will check the Rx interrupt status bit, if Rx status is set but can't call napi_schedule(), it will do nothing and directly return form irqhandler. This situation is prone to be produced when we repeatly call irqhandler through netpoll interface(i.e kgdboe connecting). This is a potential risk for those level triggered platforms(i.e ti_omap3evm), because if we don't handle Rx int and just return from irqhandler, the irq pin will be keeping asserted, the level triggered platforms will have no chance to jump out from the Rx irq. The whole system will hung into the irq subsystem. To solve it, we add a disable/re-enable Rx int operation for this situation, this operation can de-assert interrupt pin for this time and will leave the received data and status in the FIFO for later interrupts to handle. Signed-off-by: Jason Wang jason77.w...@gmail.com You absolutely cannot do this. You now can race with the NAPI completion code turning the RX interrupts back on, and you'll leave the chip with RX interrupts disabled. You must solve your level triggered interrupt some other way, every NAPI based device must manage the interrupt disabling carefully and only when the napi POLL is successfully scheduled in order to avoid races. And especially you must not make a crazy hack like this for obscure things like kgdboe. -- To unsubscribe from this list: send the line unsubscribe 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] Add infrastructure for conditional code and data sections
* Aaro Koskinen aaro.koski...@nokia.com [101223 04:31]: Hi, On Wed, 22 Dec 2010, Tony Lindgren wrote: * Thomas Petazzoni thomas.petazz...@free-electrons.com [101221 14:00]: On Tue, 21 Dec 2010 11:27:35 -0800 Tony Lindgren t...@atomide.com wrote: Therefore, we introduce an infrastructure that allows to put code and data into specific sections, called conditional sections. All those sections are compiled into the final kernel image, but at runtime, by calling a function, we can get rid of the unused sections. Great, something is certainly needed to free the unused memory. Nice to see that the idea is welcome. Did you had a look at the implementation in patch 1/6 ? No not yet, will take a look after we're done with this upcoming merge window.. I also think the idea is good, and this should be maybe posted to wider audience than just linux-omap. However, in order to be able to free each section independently from another, I have to page align all those conditional sections. This means that having one section for only a tiny amount of data is going to waste space instead of saving space. So the conditional section should gather a sufficiently large amount of data ( 4 KB) to actually be valuable. Yeah I don't know how much non-init data we have for each board-*.c file. Maybe there is not much for each machine. I took a quick look at omap2plus_defconfig kernel, and non-init text/data for 29 boards takes 85K. If we would page align those memory consumption would increase during init to 29*8=232K, but after other boards are freed we would eventually save 85-8=77K. That does not sounds like a huge savings as some bootloaders like nolo have a 2MB kernel size limitation.. Under mach-omap2, another big consumer is clock data which takes also around 80 K, while e.g. on 2420 only 14 K is needed. This eventually should be all __initdata and only the clock data for the booted omap should be allocated during the boot. Sounds like the best way to reduce the size of the image immediately is to make everything possible a module for the defconfigs, then use the standard minimal kernel + initramfs booting. That will make it easy for all the distros to use it too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
Vishwanath Sripathy had written, on 12/23/2010 11:36 AM, the following: [..] Further, why is SR enabled by default on this platform if it does not have all domains available to be enabled (e.x. we dont have it on PandaBoard even though it is OMAP4 rt?) Why do you think SR is enabled by default? The above log says that SR Module is initialized. However sr auto compensation is not started by default. oops.. my bad. Apologies, I missed that this is part of probe path not part of sr_classX_init path. looking at the code, I will refrain from commenting further on probe function at this point. -- 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
Status of CONFIG_OMAP_DM_TIMER
While compiling a kernel today I found the build was failing with a fair number of errors while linking vmlinux, arch/arm/mach-omap2/built-in.o: In function `omap2_gp_timer_set_mode': /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:84: undefined reference to `omap_dm_timer_stop' /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:88: undefined reference to `omap_dm_timer_get_fclk' /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:90: undefined reference to `omap_dm_timer_set_load_start' ... After investigating a bit more deeply, I found that I had neglected to enable OMAP_DM_TIMER. Looking further, I found that ARCH_OMAP2PLUS builds timer_gp.o, which itself has symbol dependencies on the dm_timer framework. Given this face, it seems that the easiest solution would be to do as I have done in this patch and make ARCH_OMAP2PLUS depend on OMAP_DM_TIMER, since it will not build without it. That being said, is it necessary to keep OMAP_DM_TIMER configurable? What is this option actually buying us? Cheers, - Ben -- To unsubscribe from this list: send the line unsubscribe 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] omap2: Make OMAP2PLUS select OMAP_DM_TIMER
It appears that arch/arm/mach-omap2/timer-gp.o is needed by OMAP2PLUS. Since timer-gp.o has direct dependencies on omap_dm_timer_*, it seems correct for the architecture to depend upon OMAP_DM_TIMER, otherwise unsuspecting integrators will be faced with a whole bunch of linker errors at the end of their kernel build: arch/arm/mach-omap2/built-in.o: In function `omap2_gp_timer_set_mode': /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:84: undefined reference to `omap_dm_timer_stop' /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:88: undefined reference to `omap_dm_timer_get_fclk' /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:90: undefined reference to `omap_dm_timer_set_load_start' ... --- arch/arm/plat-omap/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 92c5bb7..784c06c 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -18,6 +18,7 @@ config ARCH_OMAP1 config ARCH_OMAP2PLUS bool TI OMAP2/3/4 select COMMON_CLKDEV + select OMAP_DM_TIMER help Systems based on OMAP2, OMAP3 or OMAP4 -- 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: linux-next: manual merge of the usb tree with the omap tree
+ Paul the omap clock guru. At first glance, that seems almost good. Except for a couple of nodes that seems to lose their 3630 support. I'm just wondering why the original usb clock node is kept after the introduction of the ehci-omap.0 clock node. But this is anyway harmless. What commits are generating this conflict? On 12/23/2010 7:18 AM, Stephen Rothwell wrote: Hi Greg, Today's linux-next merge of the usb tree got a conflict in arch/arm/mach-omap2/clock3xxx_data.c and arch/arm/mach-omap2/clock44xx_data.c between various commits from the omap tree and various commits from the usb tree. I did a quick fix (which may be completely wrong - see below). diff --cc arch/arm/mach-omap2/clock3xxx_data.c index 9ab817e,0579604..000 --- a/arch/arm/mach-omap2/clock3xxx_data.c +++ b/arch/arm/mach-omap2/clock3xxx_data.c @@@ -3275,17 -3267,18 +3275,18 @@@ static struct omap_clk omap3xxx_clks[] CLK(NULL, gfx_l3_ick, gfx_l3_ick,CK_3430ES1), CLK(NULL, gfx_cg1_ck, gfx_cg1_ck,CK_3430ES1), CLK(NULL, gfx_cg2_ck, gfx_cg2_ck,CK_3430ES1), -CLK(NULL, sgx_fck, sgx_fck, CK_3430ES2 | CK_3517), -CLK(NULL, sgx_ick, sgx_ick, CK_3430ES2 | CK_3517), +CLK(NULL, sgx_fck, sgx_fck, CK_3430ES2PLUS | CK_3517 | CK_36XX), +CLK(NULL, sgx_ick, sgx_ick, CK_3430ES2PLUS | CK_3517 | CK_36XX), CLK(NULL, d2d_26m_fck, d2d_26m_fck, CK_3430ES1), -CLK(NULL, modem_fck,modem_fck, CK_343X), -CLK(NULL, sad2d_ick,sad2d_ick, CK_343X), -CLK(NULL, mad2d_ick,mad2d_ick, CK_343X), +CLK(NULL, modem_fck,modem_fck, CK_34XX | CK_36XX), +CLK(NULL, sad2d_ick,sad2d_ick, CK_34XX | CK_36XX), +CLK(NULL, mad2d_ick,mad2d_ick, CK_34XX | CK_36XX), CLK(NULL, gpt10_fck,gpt10_fck, CK_3XXX), CLK(NULL, gpt11_fck,gpt11_fck, CK_3XXX), -CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2 | CK_AM35XX), -CLK(NULL, ts_fck, ts_fck,CK_3430ES2 | CK_AM35XX), -CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2 | CK_AM35XX), +CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX), +CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS | CK_AM35XX | CK_36XX), +CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS | CK_AM35XX | CK_36XX), That one could be removed after the introduction of the following one if the clk_get(dev, usbtll_fck) API is used. + CLK(ehci-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2 | CK_AM35XX), If only that one is kept it should be: + CLK(ehci-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2PLUS | CK_AM35XX | CK_36XX), Assuming that one of the conflicting commits was trying to add the 3630 support. CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX), CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX), CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX), @@@ -3309,26 -3302,27 +3310,27 @@@ CLK(NULL, core_12m_fck, core_12m_fck, CK_3XXX), CLK(omap_hdq.0, fck,hdq_fck, CK_3XXX), CLK(NULL, ssi_ssr_fck, ssi_ssr_fck_3430es1, CK_3430ES1), -CLK(NULL, ssi_ssr_fck, ssi_ssr_fck_3430es2, CK_3430ES2), +CLK(NULL, ssi_ssr_fck, ssi_ssr_fck_3430es2, CK_3430ES2PLUS | CK_36XX), CLK(NULL, ssi_sst_fck, ssi_sst_fck_3430es1, CK_3430ES1), -CLK(NULL, ssi_sst_fck, ssi_sst_fck_3430es2, CK_3430ES2), +CLK(NULL, ssi_sst_fck, ssi_sst_fck_3430es2, CK_3430ES2PLUS | CK_36XX), CLK(NULL, core_l3_ick, core_l3_ick, CK_3XXX), - CLK(musb_hdrc,ick, hsotgusb_ick_3430es1, CK_3430ES1), - CLK(musb_hdrc,ick, hsotgusb_ick_3430es2, CK_3430ES2PLUS | CK_36XX), + CLK(musb-omap2430,ick, hsotgusb_ick_3430es1, CK_3430ES1), -CLK(musb-omap2430,ick, hsotgusb_ick_3430es2, CK_3430ES2), ++CLK(musb-omap2430,ick, hsotgusb_ick_3430es2, CK_3430ES2PLUS | CK_36XX), CLK(NULL, sdrc_ick, sdrc_ick, CK_3XXX), CLK(NULL, gpmc_fck, gpmc_fck, CK_3XXX), -CLK(NULL, security_l3_ick, security_l3_ick, CK_343X), -CLK(NULL, pka_ick, pka_ick, CK_343X), +CLK(NULL, security_l3_ick, security_l3_ick, CK_34XX | CK_36XX), +CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX), CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX), -CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2 | CK_AM35XX), +CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS | CK_AM35XX | CK_36XX), + CLK(ehci-omap.0, usbtll_ick, usbtll_ick,CK_3430ES2 | CK_AM35XX), ditto, should probably be:
Re: [PATCH] mcspi: Add support for GPIO chip select lines
* Ben Gamari bgamari.f...@gmail.com [101221 09:56]:
This mechanism is in large part stolen from the s3c64xx-spi module. To
use this functionality, one simply must define a set_level function to
set the CS state and a omap2_mcspi_csinfo struct for each chip select in
the board file.
Each spi_board_info.controller_data should then be set
to point to the appropriate csinfo struct. This will cause the driver to
call the csinfo-set_level function instead of toggling the McSPI chip
select lines.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
This one should go via the SPI list:
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/include/plat/mcspi.h | 14 ++
drivers/spi/omap2_mcspi.c | 14 +-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 1254e49..ab84b8d 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -1,6 +1,20 @@
#ifndef _OMAP2_MCSPI_H
#define _OMAP2_MCSPI_H
+/**
+ * struct omap2_mcspi_csinfo - Chip Select description
+ * @line: Custom 'identity' of the CS line
+ * @set_level: Function to set the state of a given CS line
+ *
+ * This is to allow use of GPIO lines as CS lines. Allocate and initialize
one
+ * in the machine init code and make spi_board_info.controller_data point to
+ * it.
+ */
+struct omap2_mcspi_csinfo {
+unsigned line;
+void (*set_level)(unsigned line_id, int lvl);
+};
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
};
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..92ccbd6 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -35,6 +35,7 @@
#include linux/slab.h
#include linux/spi/spi.h
+#include linux/gpio.h
#include plat/dma.h
#include plat/clock.h
@@ -235,11 +236,14 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active)
{
- u32 l;
-
- l = mcspi_cached_chconf0(spi);
- MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
- mcspi_write_chconf0(spi, l);
+ if (spi-controller_data) {
+ struct omap2_mcspi_csinfo *csinfo = spi-controller_data;
+ (*csinfo-set_level)(csinfo-line, cs_active);
+ } else {
+ u32 l = mcspi_cached_chconf0(spi);
+ MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
+ mcspi_write_chconf0(spi, l);
+ }
}
static void omap2_mcspi_set_master_mode(struct spi_master *master)
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP USB Changes for Merge Window
* Felipe Balbi ba...@ti.com [101223 00:47]: Hi Tony, please queue the following two patches for Merge Window. The following changes since commit b79540fcbbcf9b379c9197f63c5a883bbe3adfd4: Linux-omap rebuilt: Merged branches from Paul and Kevin and mux changes (2010-12-22 19:13:33 -0800) This can't be pulled as it would pull in tons of non-mainline commits from the linux-omap master branch. Everybody, all the pullable branches must be based on something in the mainline kernel, like a recent -rc tag. If that won't work, then some commit needs to be agreed on separately that will go to mainline, like the omap-for-linus branch. Further, please wait few days before sending the pull request in case somebody wants to ack your patches. Sending a pull request with the patches to be reviewed is kind of pointless.. Sure in this case these are pretty trivial patches, but still. Anyways, I'll apply these into a temporary branch and will merge into omap-for-linus within next few days assuming no problems. 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] OMAP4: hwmod data: Fix SR flags, structures order and field alignment
* Benoit Cousson b-cous...@ti.com [101223 06:14]:
Smartreflex is missing the recently introduced SIDLE_SMART_WKUP
flag in idlemodes field.
So this actually also changes something too?
The merge of the DMA and SR series on top of the already modified
omap_hwmod_data_44xx.c moved the dma_system structure at the wrong
position in the file. The same thing happened for the SR structure.
- Re-order the structures properly.
In order to be fully aligned with the Python generator output,
change a couple of fields.
- Add tab in class and dev_attr structures to align fields
- Add a comma at the end of the following line to simplify the
code generation:
.pre_shutdown = omap2_wd_timer_disable,
To me it sounds like this should be at least two separate patches:
One that adds the SIDLE_SMART_WKUP, then another patch that
only does clean-up with no functional changes.
Also this patch applied (contactenated multiple patches?) turns
into a hard to read interleaved patch for some parts:
-static struct omap_hwmod_irq_info omap44xx_uart2_irqs[] = {
- { .irq = 73 + OMAP44XX_IRQ_GIC_START },
-};
-
-static struct omap_hwmod_dma_info omap44xx_uart2_sdma_reqs[] = {
- { .name = tx, .dma_req = 50 + OMAP44XX_DMA_REQ_START },
- { .name = rx, .dma_req = 51 + OMAP44XX_DMA_REQ_START },
+/* smartreflex_iva */
+static struct omap_hwmod omap44xx_smartreflex_iva_hwmod;
+static struct omap_hwmod_irq_info omap44xx_smartreflex_iva_irqs[] = {
+ { .irq = 102 + OMAP44XX_IRQ_GIC_START },
};
-static struct omap_hwmod_addr_space omap44xx_uart2_addrs[] = {
+static struct omap_hwmod_addr_space omap44xx_smartreflex_iva_addrs[] = {
{
- .pa_start = 0x4806c000,
- .pa_end = 0x4806c0ff,
+ .pa_start = 0x4a0db000,
+ .pa_end = 0x4a0db03f,
.flags = ADDR_TYPE_RT
},
};
...
So sounds like your original three patches would be the better
way to go.
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] omap2: Make OMAP2PLUS select OMAP_DM_TIMER
* Ben Gamari bgamari.f...@gmail.com [101223 10:07]: It appears that arch/arm/mach-omap2/timer-gp.o is needed by OMAP2PLUS. Since timer-gp.o has direct dependencies on omap_dm_timer_*, it seems correct for the architecture to depend upon OMAP_DM_TIMER, otherwise unsuspecting integrators will be faced with a whole bunch of linker errors at the end of their kernel build: Can you please repost this with linux-arm-kernel list also Cc'd? Thanks, 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] mcspi: Add support for GPIO chip select lines
On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari bgamari.f...@gmail.com wrote:
This mechanism is in large part stolen from the s3c64xx-spi module. To
use this functionality, one simply must define a set_level function to
set the CS state and a omap2_mcspi_csinfo struct for each chip select in
the board file.
Each spi_board_info.controller_data should then be set
to point to the appropriate csinfo struct. This will cause the driver to
call the csinfo-set_level function instead of toggling the McSPI chip
select lines.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
I'd rather see the spi driver modified to use the gpio api directly.
The drivers are already tending in that direction and it doesn't
require machine specific set_level functions to be defined.
g.
---
arch/arm/plat-omap/include/plat/mcspi.h | 14 ++
drivers/spi/omap2_mcspi.c | 14 +-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 1254e49..ab84b8d 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -1,6 +1,20 @@
#ifndef _OMAP2_MCSPI_H
#define _OMAP2_MCSPI_H
+/**
+ * struct omap2_mcspi_csinfo - Chip Select description
+ * @line: Custom 'identity' of the CS line
+ * @set_level: Function to set the state of a given CS line
+ *
+ * This is to allow use of GPIO lines as CS lines. Allocate and initialize
one
+ * in the machine init code and make spi_board_info.controller_data point to
+ * it.
+ */
+struct omap2_mcspi_csinfo {
+ unsigned line;
+ void (*set_level)(unsigned line_id, int lvl);
+};
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
};
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..92ccbd6 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -35,6 +35,7 @@
#include linux/slab.h
#include linux/spi/spi.h
+#include linux/gpio.h
#include plat/dma.h
#include plat/clock.h
@@ -235,11 +236,14 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active)
{
- u32 l;
-
- l = mcspi_cached_chconf0(spi);
- MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
- mcspi_write_chconf0(spi, l);
+ if (spi-controller_data) {
+ struct omap2_mcspi_csinfo *csinfo = spi-controller_data;
+ (*csinfo-set_level)(csinfo-line, cs_active);
+ } else {
+ u32 l = mcspi_cached_chconf0(spi);
+ MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
+ mcspi_write_chconf0(spi, l);
+ }
}
static void omap2_mcspi_set_master_mode(struct spi_master *master)
--
1.7.1
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP4: hwmod data: Fix SR flags, structures order and field alignment
On 12/23/2010 9:46 PM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [101223 06:14]:
Smartreflex is missing the recently introduced SIDLE_SMART_WKUP
flag in idlemodes field.
So this actually also changes something too?
Not yet, because we are not doing any clock domain transition to
INACTIVE for the moment, so the wakeup is still not used.
The merge of the DMA and SR series on top of the already modified
omap_hwmod_data_44xx.c moved the dma_system structure at the wrong
position in the file. The same thing happened for the SR structure.
- Re-order the structures properly.
In order to be fully aligned with the Python generator output,
change a couple of fields.
- Add tab in class and dev_attr structures to align fields
- Add a comma at the end of the following line to simplify the
code generation:
.pre_shutdown =omap2_wd_timer_disable,
To me it sounds like this should be at least two separate patches:
One that adds the SIDLE_SMART_WKUP, then another patch that
only does clean-up with no functional changes.
OK
Also this patch applied (contactenated multiple patches?) turns
into a hard to read interleaved patch for some parts:
Mmm, I do not understand how did you get that diff? This is not
like that in the patch I sent you?
The patch should apply cleanely on top of your omap-for-linus
branch.
-static struct omap_hwmod_irq_info omap44xx_uart2_irqs[] = {
- { .irq = 73 + OMAP44XX_IRQ_GIC_START },
-};
-
-static struct omap_hwmod_dma_info omap44xx_uart2_sdma_reqs[] = {
- { .name = tx, .dma_req = 50 + OMAP44XX_DMA_REQ_START },
- { .name = rx, .dma_req = 51 + OMAP44XX_DMA_REQ_START },
+/* smartreflex_iva */
+static struct omap_hwmod omap44xx_smartreflex_iva_hwmod;
+static struct omap_hwmod_irq_info omap44xx_smartreflex_iva_irqs[] = {
+ { .irq = 102 + OMAP44XX_IRQ_GIC_START },
};
-static struct omap_hwmod_addr_space omap44xx_uart2_addrs[] = {
+static struct omap_hwmod_addr_space omap44xx_smartreflex_iva_addrs[] = {
{
- .pa_start = 0x4806c000,
- .pa_end = 0x4806c0ff,
+ .pa_start = 0x4a0db000,
+ .pa_end = 0x4a0db03f,
.flags = ADDR_TYPE_RT
},
};
...
So sounds like your original three patches would be the better
way to go.
OK, as a special gift for you, you will have 4 patches :-)
Same place:
git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod_fixes
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] OMAP4: hwmod data: Fix missing SIDLE_SMART_WKUP in smartreflex sysc
Add the missing SIDLE_SMART_WKUP flag in idlemodes field of
the smartreflex sysconfig structure.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e2ad1b6..3e9015a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1857,7 +1857,8 @@ static struct omap_hwmod_sysc_fields
omap_hwmod_sysc_type_smartreflex = {
static struct omap_hwmod_class_sysconfig omap44xx_smartreflex_sysc = {
.sysc_offs = 0x0038,
.sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
.sysc_fields= omap_hwmod_sysc_type_smartreflex,
};
--
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 2/4] OMAP4: hwmod data: Move the smartreflex structures
The merge of the SR series on top of the already modified
omap_hwmod_data_44xx.c moved the smartreflex structures at the wrong
position in the file.
- Re-order the structures properly.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 341 ++--
1 files changed, 169 insertions(+), 172 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3e9015a..378d4a7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -556,9 +556,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* sl2if
* slimbus1
* slimbus2
- * smartreflex_core
- * smartreflex_iva
- * smartreflex_mpu
* spinlock
* timer1
* timer10
@@ -1393,6 +1390,170 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'smartreflex' class
+ * smartreflex module (monitor silicon performance and outputs a measure of
+ * performance error)
+ */
+
+/* The IP is not compliant to type1 / type2 scheme */
+static struct omap_hwmod_sysc_fields omap_hwmod_sysc_type_smartreflex = {
+ .sidle_shift= 24,
+ .enwkup_shift = 26,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_smartreflex_sysc = {
+ .sysc_offs = 0x0038,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type_smartreflex,
+};
+
+static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
+ .name = smartreflex,
+ .sysc = omap44xx_smartreflex_sysc,
+ .rev = 2,
+};
+
+/* smartreflex_core */
+static struct omap_hwmod omap44xx_smartreflex_core_hwmod;
+static struct omap_hwmod_irq_info omap44xx_smartreflex_core_irqs[] = {
+ { .irq = 19 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_smartreflex_core_addrs[] = {
+ {
+ .pa_start = 0x4a0dd000,
+ .pa_end = 0x4a0dd03f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - smartreflex_core */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__smartreflex_core = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_smartreflex_core_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_smartreflex_core_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* smartreflex_core slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_smartreflex_core_slaves[] = {
+ omap44xx_l4_cfg__smartreflex_core,
+};
+
+static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
+ .name = smartreflex_core,
+ .class = omap44xx_smartreflex_hwmod_class,
+ .mpu_irqs = omap44xx_smartreflex_core_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_irqs),
+ .main_clk = smartreflex_core_fck,
+ .vdd_name = core,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_ALWON_SR_CORE_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_smartreflex_core_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* smartreflex_iva */
+static struct omap_hwmod omap44xx_smartreflex_iva_hwmod;
+static struct omap_hwmod_irq_info omap44xx_smartreflex_iva_irqs[] = {
+ { .irq = 102 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_smartreflex_iva_addrs[] = {
+ {
+ .pa_start = 0x4a0db000,
+ .pa_end = 0x4a0db03f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - smartreflex_iva */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__smartreflex_iva = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_smartreflex_iva_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_smartreflex_iva_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* smartreflex_iva slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_smartreflex_iva_slaves[] = {
+ omap44xx_l4_cfg__smartreflex_iva,
+};
+
+static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
+ .name = smartreflex_iva,
+ .class = omap44xx_smartreflex_hwmod_class,
+ .mpu_irqs = omap44xx_smartreflex_iva_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_irqs),
+ .main_clk = smartreflex_iva_fck,
+ .vdd_name =
[PATCH 3/4] OMAP4: hwmod data: Move the DMA structures
The merge of the DMA series on top of the already modified
omap_hwmod_data_44xx.c put the dma_system structures at
the wrong position in the file.
Re-order it properly.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 196 ++--
1 files changed, 97 insertions(+), 99 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 378d4a7..f35a99d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -254,6 +254,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
};
/* l3_main_2 interface data */
+/* dma_system - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
+ .master = omap44xx_dma_system_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* iva - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_iva__l3_main_2 = {
.master = omap44xx_iva_hwmod,
@@ -270,14 +278,6 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_1__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* dma_system - l3_main_2 */
-static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
- .master = omap44xx_dma_system_hwmod,
- .slave = omap44xx_l3_main_2_hwmod,
- .clk= l3_div_ck,
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
/* l4_cfg - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = {
.master = omap44xx_l4_cfg_hwmod,
@@ -506,7 +506,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* ctrl_module_pad_wkup
* ctrl_module_wkup
* debugss
- * dma_system
* dmic
* dss
* dss_dispc
@@ -577,6 +576,92 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
*/
/*
+ * 'dma' class
+ * dma controller for data exchange between memory to memory (i.e. internal or
+ * external memory) and gp peripherals to memory or memory to gp peripherals
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap44xx_dma_sysc,
+};
+
+/* dma dev_attr */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+ .lch_count = 32,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
+ { .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
+ { .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
+ { .name = 2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
+ { .name = 3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_masters[] = {
+ omap44xx_dma_system__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
+ {
+ .pa_start = 0x4a056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dma_system = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_slaves[] = {
+ omap44xx_l4_cfg__dma_system,
+};
+
+static struct omap_hwmod omap44xx_dma_system_hwmod = {
+ .name = dma_system,
+ .class = omap44xx_dma_hwmod_class,
+ .mpu_irqs = omap44xx_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_SDMA_SDMA_CLKCTRL,
+ },
+ },
+
[PATCH 4/4] OMAP4: hwmod data: Fix alignment and end of line in structure fields
In order to be fully aligned with the Python generator output,
change a couple of fields.
- Add tab in class structures to align attributes
- Add a comma at the end of the following line to simplify
the generation by having always the same eol:
.pre_shutdown = omap2_wd_timer_disable,
- Add a blank line before the first entry of the
omap44xx_hwmods array.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 43 ++-
1 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f35a99d..c2806bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -66,7 +66,7 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod;
* instance(s): dmm
*/
static struct omap_hwmod_class omap44xx_dmm_hwmod_class = {
- .name = dmm,
+ .name = dmm,
};
/* dmm interface data */
@@ -121,7 +121,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod = {
* instance(s): emif_fw
*/
static struct omap_hwmod_class omap44xx_emif_fw_hwmod_class = {
- .name = emif_fw,
+ .name = emif_fw,
};
/* emif_fw interface data */
@@ -170,7 +170,7 @@ static struct omap_hwmod omap44xx_emif_fw_hwmod = {
* instance(s): l3_instr, l3_main_1, l3_main_2, l3_main_3
*/
static struct omap_hwmod_class omap44xx_l3_hwmod_class = {
- .name = l3,
+ .name = l3,
};
/* l3_instr interface data */
@@ -347,7 +347,7 @@ static struct omap_hwmod omap44xx_l3_main_3_hwmod = {
* instance(s): l4_abe, l4_cfg, l4_per, l4_wkup
*/
static struct omap_hwmod_class omap44xx_l4_hwmod_class = {
- .name = l4,
+ .name = l4,
};
/* l4_abe interface data */
@@ -461,7 +461,7 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
* instance(s): mpu_private
*/
static struct omap_hwmod_class omap44xx_mpu_bus_hwmod_class = {
- .name = mpu_bus,
+ .name = mpu_bus,
};
/* mpu_private interface data */
@@ -667,7 +667,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
*/
static struct omap_hwmod_class omap44xx_dsp_hwmod_class = {
- .name = dsp,
+ .name = dsp,
};
/* dsp */
@@ -764,15 +764,15 @@ static struct omap_hwmod_class_sysconfig
omap44xx_gpio_sysc = {
};
static struct omap_hwmod_class omap44xx_gpio_hwmod_class = {
- .name = gpio,
- .sysc = omap44xx_gpio_sysc,
- .rev = 2,
+ .name = gpio,
+ .sysc = omap44xx_gpio_sysc,
+ .rev= 2,
};
/* gpio dev_attr */
static struct omap_gpio_dev_attr gpio_dev_attr = {
- .bank_width = 32,
- .dbck_flag = true,
+ .bank_width = 32,
+ .dbck_flag = true,
};
/* gpio1 */
@@ -1109,8 +1109,8 @@ static struct omap_hwmod_class_sysconfig
omap44xx_i2c_sysc = {
};
static struct omap_hwmod_class omap44xx_i2c_hwmod_class = {
- .name = i2c,
- .sysc = omap44xx_i2c_sysc,
+ .name = i2c,
+ .sysc = omap44xx_i2c_sysc,
};
/* i2c1 */
@@ -1331,7 +1331,7 @@ static struct omap_hwmod omap44xx_i2c4_hwmod = {
*/
static struct omap_hwmod_class omap44xx_iva_hwmod_class = {
- .name = iva,
+ .name = iva,
};
/* iva */
@@ -1440,7 +1440,7 @@ static struct omap_hwmod omap44xx_iva_hwmod = {
*/
static struct omap_hwmod_class omap44xx_mpu_hwmod_class = {
- .name = mpu,
+ .name = mpu,
};
/* mpu */
@@ -1495,9 +1495,9 @@ static struct omap_hwmod_class_sysconfig
omap44xx_smartreflex_sysc = {
};
static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
- .name = smartreflex,
- .sysc = omap44xx_smartreflex_sysc,
- .rev = 2,
+ .name = smartreflex,
+ .sysc = omap44xx_smartreflex_sysc,
+ .rev= 2,
};
/* smartreflex_core */
@@ -1656,8 +1656,8 @@ static struct omap_hwmod_class_sysconfig
omap44xx_uart_sysc = {
};
static struct omap_hwmod_class omap44xx_uart_hwmod_class = {
- .name = uart,
- .sysc = omap44xx_uart_sysc,
+ .name = uart,
+ .sysc = omap44xx_uart_sysc,
};
/* uart1 */
@@ -1889,7 +1889,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_wd_timer_sysc = {
static struct omap_hwmod_class omap44xx_wd_timer_hwmod_class = {
.name = wd_timer,
.sysc = omap44xx_wd_timer_sysc,
- .pre_shutdown = omap2_wd_timer_disable
+ .pre_shutdown = omap2_wd_timer_disable,
};
/* wd_timer2 */
@@ -2002,6 +2002,7 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
};
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
+
/* dmm class */
omap44xx_dmm_hwmod,
--
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
Re: [PATCH 05/12] staging:tidspbridge - set5 remove hungarian from structs
Hi Dan, On Wed, Dec 15, 2010 at 2:53 AM, Dan Carpenter erro...@gmail.com wrote: On Tue, Dec 14, 2010 at 02:33:11PM -0600, Rene Sapiens wrote: - pfn_unload(pnode-nldr_node_obj, + load(pnode-nldr_node_obj, NLDR_EXECUTE); Unload got swapped with load here. This might have been easier to with Coccinelle instead of by hand... I'm sorry for the delay, i did use some scripts to identify/replace the words, this last one should be because of my lasts coding style fixes after changes, i will fix it and send the patch again. Indeed Coccinelle is a very good option too. -- Regards, Rene Sapiens -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On Wed, Nov 24, 2010 at 04:49:47PM -0800, Kevin Hilman wrote:
Gregory CLEMENT gregory.clem...@free-electrons.com writes:
As request by Grant Likely, there is no more cover letter. Full changelog
is following.
I am still reluctant to add this changelog in the patch description, as it
adds no value to
the patch itself: when it was needed I try to updat comments or patch
description.
You're right, the changelog should not be in the patch description.
This bit of meta-description and changelog should go after the '---'
just after your signoff. That way, git tools can still auto-apply the
email, and git ignores stuff after the '---' so it doesn't end up in the
git history.
Actually, I used to have the same opinion, but dwmw2 clued me in that
it really is valuable and proper to have the revision history and
changelog in the patch description. When looking back at what
actually got committed into Linus' tree, the changelog gives hints as
to which exact version of the patch got committed (for instance, if a
v6 got merged, but a v7 was also posted that didn't get merged.)
BTW, this thread has some discussion about this patch not actually
working correctly. What is the state? Should this version get
merged, or do I need to wait for a v6?
g.
I understand that Grant Likely would need an ack from other user as this
patch fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his Ack by
or at least his Review by.
I haven't actually tested it, only reviewed it, so you can add a
Reviewed by for me, but I'm not SPI-aware enough to ack this patch or
test it thoroughly. Also, I have some more comments below...
Also, in the last patch I suggested you do more of a save/restore of
this value instead of a restore to a hard-coded value. IOW, save the
value in the suspend method, restore it in resume. I thought you had
agreed to that. I'm not an SPI expert, so not sure if it makes sense,
but it seems more robust that way and more future proof.
Changelog:
* Change from v1 to v2:
Rebase on linus/master (after 2.6.37-rc1)
Do some clean-up and fix indentation on both patches
Add more explanations for patch 2
* Change from v2 to v3:
Use directly resume function of spi_master instead of using function
from spi_device as Grant Likely pointed it out.
Force this transition explicitly for each CS used by a device.
* Change from v3 to v4:
Patch clean-up according to Kevin Hilman and checkpatch.
Now force CS to be in inactive state only if it was inactive when it was
suspended.
* Change from v4 to v5:
Rebase on linus/master (after 2.6.37-rc3)
Collapse some lines as pointed by Grant Likely
Fix a spelling
== CUT HERE ==
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the
clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that
on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
This is where any changelog and extra info for reviewers should go.
drivers/spi/omap2_mcspi.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..dcc024a 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state
at
+ * wake up.
+ */
please fix multi-line comment style. Search for 'multi-line' in
CodingStyle.
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+ struct spi_master *master = dev_get_drvdata(pdev-dev);
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+ struct omap2_mcspi_cs *cs;
+
+ omap2_mcspi_enable_clocks(mcspi);
+ list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node) {
+ if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+ /* We need to toggle CS state for OMAP take this
+* change in account.
+*/
multi-line coding style
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ MOD_REG_BIT(cs-chconf0,
Re: [PATCH] mcspi: Add support for GPIO chip select lines
On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari bgamari.f...@gmail.com wrote: This mechanism is in large part stolen from the s3c64xx-spi module. To use this functionality, one simply must define a set_level function to set the CS state and a omap2_mcspi_csinfo struct for each chip select in the board file. Each spi_board_info.controller_data should then be set to point to the appropriate csinfo struct. This will cause the driver to call the csinfo-set_level function instead of toggling the McSPI chip select lines. Signed-off-by: Ben Gamari bgamari.f...@gmail.com I'd rather see the spi driver modified to use the gpio api directly. The drivers are already tending in that direction and it doesn't require machine specific set_level functions to be defined. The reason I left this up to the board is it's easy to foresee cases where you want a non-trivial mapping between logical CS numbers and CS pin states. In my case, I using a 2-to-4 multiplexer as the source of chip select. - Ben -- To unsubscribe from this list: send the line unsubscribe 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] OMAP4: hwmod data: Fix SR flags, structures order and field alignment
* Cousson, Benoit b-cous...@ti.com [101223 14:24]: Also this patch applied (contactenated multiple patches?) turns into a hard to read interleaved patch for some parts: Mmm, I do not understand how did you get that diff? This is not like that in the patch I sent you? The patch should apply cleanely on top of your omap-for-linus branch. The same interleaving also showed up in year earlier branch for some reason.. OK, as a special gift for you, you will have 4 patches :-) OK thanks for updating, looks good to me now. 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] mcspi: Add support for GPIO chip select lines
On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari bgamari.f...@gmail.com wrote: On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari bgamari.f...@gmail.com wrote: This mechanism is in large part stolen from the s3c64xx-spi module. To use this functionality, one simply must define a set_level function to set the CS state and a omap2_mcspi_csinfo struct for each chip select in the board file. Each spi_board_info.controller_data should then be set to point to the appropriate csinfo struct. This will cause the driver to call the csinfo-set_level function instead of toggling the McSPI chip select lines. Signed-off-by: Ben Gamari bgamari.f...@gmail.com I'd rather see the spi driver modified to use the gpio api directly. The drivers are already tending in that direction and it doesn't require machine specific set_level functions to be defined. The reason I left this up to the board is it's easy to foresee cases where you want a non-trivial mapping between logical CS numbers and CS pin states. In my case, I using a 2-to-4 multiplexer as the source of chip select. Hi Ben, I understand and appreciate the motivation. However in practice, the gpio api is sufficient for pretty much any use case, even when the backing gpio controller driver ends up driving some oddball device with different constraints. The big downside to using a callback is that it forces all users to do the extra work of implementing the callback. With the gpio api, only the oddball cases have to do extra code (to adapt the custom device to the gpio api). g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] smsc911x: add disable and re-enable Rx int to de-assert interrupt pin
David Miller wrote:
From: Jason Wang jason77.w...@gmail.com
Date: Thu, 23 Dec 2010 18:43:13 +0800
When kernel enters irqhanlder, it will check the Rx interrupt status
bit, if Rx status is set but can't call napi_schedule(), it will do
nothing and directly return form irqhandler. This situation is prone
to be produced when we repeatly call irqhandler through netpoll
interface(i.e kgdboe connecting).
This is a potential risk for those level triggered platforms(i.e
ti_omap3evm), because if we don't handle Rx int and just return from
irqhandler, the irq pin will be keeping asserted, the level triggered
platforms will have no chance to jump out from the Rx irq. The whole
system will hung into the irq subsystem.
To solve it, we add a disable/re-enable Rx int operation for this
situation, this operation can de-assert interrupt pin for this time
and will leave the received data and status in the FIFO for later
interrupts to handle.
Signed-off-by: Jason Wang jason77.w...@gmail.com
Hi David,
Thanks for your comments.
You absolutely cannot do this.
You now can race with the NAPI completion code turning the RX
interrupts back on, and you'll leave the chip with RX interrupts
disabled.
I think my modification almost have the same execution path as the
original design and don't produce the race condition with NAPI threads.
The original design is:
If (can call napi_schedule) {
disable rx int;
call napi_schedule()
} else {
keep rx int enabled;
return;
}
my modification is:
disable rx int;
if (can call napi_schedule) {
call napi_schedule();
} else {
re-enable rx int; // this will de-assert interrupt pin for this time
return;
}
So my modification is: if we can call napi_schedule(), we will disable
the rx int until the NAPI thread re-enable it. if we can't call
napi_schedule(), the rx int will keep enabled. This logic is almost same
as the original design. I can't figure out why original design is safe
while my modification is risky.
Add more info:
the Freescale imx31pdk, imx51pdk and ti_omap3evm boards all use this
driver, before apply this modification, their kgdboe connecting is not
stable. After applied this patch, their nfs root is as good as before
and their kgdboe connecting is stable.
Thanks,
Jason.
You must solve your level triggered interrupt some other way, every
NAPI based device must manage the interrupt disabling carefully and
only when the napi POLL is successfully scheduled in order to avoid
races.
And especially you must not make a crazy hack like this for obscure
things like kgdboe.
--
To unsubscribe from this list: send the line unsubscribe 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] mcspi: Add support for GPIO chip select lines
On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely grant.lik...@secretlab.ca wrote: On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari bgamari.f...@gmail.com wrote: The reason I left this up to the board is it's easy to foresee cases where you want a non-trivial mapping between logical CS numbers and CS pin states. In my case, I using a 2-to-4 multiplexer as the source of chip select. Hi Ben, I understand and appreciate the motivation. However in practice, the gpio api is sufficient for pretty much any use case, even when the backing gpio controller driver ends up driving some oddball device with different constraints. The big downside to using a callback is that it forces all users to do the extra work of implementing the callback. With the gpio api, only the oddball cases have to do extra code (to adapt the custom device to the gpio api). I understand your concerns, but I'm not sure how to satisfy them without crippling the design's ability to accomodate my use-case. I can't pass a GPIO line per spi_board_info since in my case of a multiplexed CS configuration a single pin's state does not uniquely determine the desired CS. The only other option I can think of is that we somehow provide a list of GPIOs for each bus and map the CS numbers to permutations of GPIO states. Unfortunately, I don't know of any suitable structure to put this GPIO list in. Perhaps I'm missing something obvious? - Ben -- To unsubscribe from this list: send the line unsubscribe 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] omap2: Make OMAP2PLUS select OMAP_DM_TIMER
It appears that arch/arm/mach-omap2/timer-gp.o is needed by OMAP2PLUS. Since timer-gp.o has direct dependencies on omap_dm_timer_*, it seems correct for the architecture to depend upon OMAP_DM_TIMER, otherwise unsuspecting integrators will be faced with a whole bunch of linker errors at the end of their kernel build: arch/arm/mach-omap2/built-in.o: In function `omap2_gp_timer_set_mode': /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:84: undefined reference to `omap_dm_timer_stop' /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:88: undefined reference to `omap_dm_timer_get_fclk' /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:90: undefined reference to `omap_dm_timer_set_load_start' ... --- arch/arm/plat-omap/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 92c5bb7..784c06c 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -18,6 +18,7 @@ config ARCH_OMAP1 config ARCH_OMAP2PLUS bool TI OMAP2/3/4 select COMMON_CLKDEV + select OMAP_DM_TIMER help Systems based on OMAP2, OMAP3 or OMAP4 -- 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] omap2: Make OMAP2PLUS select OMAP_DM_TIMER
It appears that arch/arm/mach-omap2/timer-gp.o is needed by OMAP2PLUS. Since timer-gp.o has direct dependencies on omap_dm_timer_*, it seems correct for the architecture to depend upon OMAP_DM_TIMER, otherwise unsuspecting integrators will be faced with a whole bunch of linker errors at the end of their kernel build: arch/arm/mach-omap2/built-in.o: In function `omap2_gp_timer_set_mode': /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:84: undefined reference to `omap_dm_timer_stop' /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:88: undefined reference to `omap_dm_timer_get_fclk' /home/bgamari/trees/linux-2.6/arch/arm/mach-omap2/timer-gp.c:90: undefined reference to `omap_dm_timer_set_load_start' ... --- arch/arm/plat-omap/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 92c5bb7..784c06c 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -18,6 +18,7 @@ config ARCH_OMAP1 config ARCH_OMAP2PLUS bool TI OMAP2/3/4 select COMMON_CLKDEV + select OMAP_DM_TIMER help Systems based on OMAP2, OMAP3 or OMAP4 -- 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] omap2: Make OMAP2PLUS select OMAP_DM_TIMER
On Thu, 23 Dec 2010 12:49:04 -0800, Tony Lindgren t...@atomide.com wrote: * Ben Gamari bgamari.f...@gmail.com [101223 10:07]: It appears that arch/arm/mach-omap2/timer-gp.o is needed by OMAP2PLUS. Since timer-gp.o has direct dependencies on omap_dm_timer_*, it seems correct for the architecture to depend upon OMAP_DM_TIMER, otherwise unsuspecting integrators will be faced with a whole bunch of linker errors at the end of their kernel build: Can you please repost this with linux-arm-kernel list also Cc'd? Done. Sorry for all of the list noise. - Ben -- To unsubscribe from this list: send the line unsubscribe 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] mcspi: Add support for GPIO chip select lines
On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote: On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely grant.lik...@secretlab.ca wrote: On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari bgamari.f...@gmail.com wrote: The reason I left this up to the board is it's easy to foresee cases where you want a non-trivial mapping between logical CS numbers and CS pin states. In my case, I using a 2-to-4 multiplexer as the source of chip select. Hi Ben, I understand and appreciate the motivation. However in practice, the gpio api is sufficient for pretty much any use case, even when the backing gpio controller driver ends up driving some oddball device with different constraints. The big downside to using a callback is that it forces all users to do the extra work of implementing the callback. With the gpio api, only the oddball cases have to do extra code (to adapt the custom device to the gpio api). I understand your concerns, but I'm not sure how to satisfy them without crippling the design's ability to accomodate my use-case. I can't pass a GPIO line per spi_board_info since in my case of a multiplexed CS configuration a single pin's state does not uniquely determine the desired CS. The only other option I can think of is that we somehow provide a list of GPIOs for each bus and map the CS numbers to permutations of GPIO states. Unfortunately, I don't know of any suitable structure to put this GPIO list in. Perhaps I'm missing something obvious? Close, but not quite. Assign one gpio number to each cs state, and write a gpio controller driver that maps the linux-gpio number to the physical gpio state permutation. The mapping from gpio# to ss# is 1:1, but the driver behind the gpio# can do whatever you need it to do. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mcspi: Add support for GPIO chip select lines
On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely grant.lik...@secretlab.ca wrote: On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote: I understand your concerns, but I'm not sure how to satisfy them without crippling the design's ability to accomodate my use-case. I can't pass a GPIO line per spi_board_info since in my case of a multiplexed CS configuration a single pin's state does not uniquely determine the desired CS. The only other option I can think of is that we somehow provide a list of GPIOs for each bus and map the CS numbers to permutations of GPIO states. Unfortunately, I don't know of any suitable structure to put this GPIO list in. Perhaps I'm missing something obvious? Close, but not quite. Assign one gpio number to each cs state, and write a gpio controller driver that maps the linux-gpio number to the physical gpio state permutation. The mapping from gpio# to ss# is 1:1, but the driver behind the gpio# can do whatever you need it to do. I see. I'm still not convinced that this is the route to take, however. It seems like this virtual gpio interface is not only pretty clunky (simple board file glue turns into an entire gpio chip driver), it seems like this is a very inaccurate and not very useful way to expose a multiplexed CS configuration; e.g. what is this chip driver to do if the user tries to set two CS pins at once? Is there precedent for using the GPIO subsystem in this way? Cheers, - Ben -- To unsubscribe from this list: send the line unsubscribe 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/5] staging:tidspbridge - Remove unused defined constants
Hi, On Thu, Dec 16, 2010 at 7:18 PM, Armando Uribe x0095...@ti.com wrote: Remove defined constants not being used. Signed-off-by: Armando Uribe x0095...@ti.com Pushed the entire series to dspbridge. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: remove code referred by OPT_ZERO_COPY_LOADER
Hi, On Mon, Dec 20, 2010 at 3:23 PM, Ernesto Ramos erne...@ti.com wrote: Remove code referred by OPT_ZERO_COPY_LOADER since it is not used. Signed-off-by: Ernesto Ramos erne...@ti.com --- drivers/staging/tidspbridge/dynload/cload.c | 60 +-- 1 files changed, 20 insertions(+), 40 deletions(-) Pushed to dspbridge. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
