Re: [PATCH v2 5/6] OMAP1: Amstrad Delta: add support for camera
On Thu, 23 Sep 2010, Tony Lindgren wrote: > * Janusz Krzysztofik [100923 16:52]: > > Friday 24 September 2010 01:26:17 Tony Lindgren napisał(a): > > > * Tony Lindgren [100923 16:06]: > > > > * Janusz Krzysztofik [100910 18:20]: > > > > > This patch adds configuration data and initialization code required > > > > > for > > > > > camera support to the Amstrad Delta board. > > > > > > > > > > Three devices are declared: SoC camera, OMAP1 camera interface and > > > > > OV6650 sensor. > > > > > > > > > > Default 12MHz clock has been selected for driving the sensor. Pixel > > > > > clock has been limited to get reasonable frame rates, not exceeding > > > > > the > > > > > board capabilities. Since both devices (interface and sensor) support > > > > > both pixel clock polarities, decision on polarity selection has been > > > > > left to drivers. Interface GPIO line has been found not functional, > > > > > thus not configured. > > > > > > > > > > Created and tested against linux-2.6.36-rc3. > > > > > > > > > > Works on top of previous patches from the series, at least 1/6, 2/6 > > > > > and > > > > > 3/6. > > > > > > > > Queuing these last two patches of the series (5/6 and 6/6) for the > > > > upcoming merge window. > > > > > > BTW, these still depend on updated 2/6 to make compile happy. > > > > Not so simple: still depends on struct omap1_cam_platform_data definition > > from > > , included from . Are you ready to > > accept another temporary workaround? > > Heh I guess so. Or do you want to queue everything via linux-media? Yes, we often have to select via which tree to go, then the maintainer of the other tree just acks the patches. Sometimes we push them via different trees and try to enforce a specific merge order... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe 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: [RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
On Thu, 23 Sep 2010, Tony Lindgren wrote: > * Janusz Krzysztofik [100923 16:37]: > > Friday 24 September 2010 01:23:10 Tony Lindgren napisał(a): > > > > > > I think you can just move the OMAP1_CAMERA_IOSIZE to the devices.c or > > > someplace like that? > > > > Tony, > > Not exactly. I use the OMAP1_CAMERA_IOSIZE inside the driver when reserving > > space for register cache. > > > > I think that I could just duplicate its definition in the devices.c for > > now, > > than clean things up with a folloup patch when both parts already get > > merged. > > Would this be acceptable? > > Yeah, that sounds good to me. ...better yet put a zero-length cache array at the end of your struct omap1_cam_dev and allocate it dynamically, calculated from the resource size. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe 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 00/14] omap sram, omap4 control module and es2.0 support
Tony, > -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Friday, September 24, 2010 6:43 AM > To: Shilimkar, Santosh > Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH 00/14] omap sram, omap4 control module and es2.0 > support > > Santosh, the "Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries" should > get tested in the arm tree to avoid nasty surprises. Please do the > following > split: > > 1. A series for Russell to pull > ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries > omap: Map only available sram memory > davinci: map sram using MT_MEMORY_NONCACHED instead of MT_DEVICE > > You can add my Acked-by: Tony Lindgren to > the "Map only available sram memory" patch. Have submitted above three patches to RMK's patch system with your ack on the mentioned patch - patch 6407/1 - patch 6408/1 - patch 6409/1 They are also available at: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap_for_2.6.37-rmk > > 2. A series for me to pull > omap4: sram: Fix start address > omap4: Update id.c and cpu.h for es2.0 > omap4: l2x0: Fix init parameter for es2.0 > omap4: Panda: Add DEBUG_LL support > omap4: Fix bootup crash observed with higher CPU clocks > The pull request is sent to you with patches rebased on v2.6.36-rc5 > 3. A series for Paul to pull (already in omap4_scm_2.6.37) > omap4: control: Add ctrl_pad_base to omap_globals > omap4: control: Add accessor api's for pad control module > omap4: control: Add the register definition headers > omap4: control: Fix the control module register accesses > This series is already available. I just rebased on v2.6.36-rc5 as you suggested. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap: sram fixes and omap4 es2.0 support
Tony, The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c: Linus Torvalds (1): Linux 2.6.36-rc5 are available in the git repository at: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap_for_2.6.37 David Anders (1): omap4: Panda: Add DEBUG_LL support Santosh Shilimkar (3): omap4: Update id.c and cpu.h for es2.0 omap4: l2x0: Fix init parameter for es2.0 omap4: Fix bootup crash observed with higher CPU clocks Vikram Pandita (2): omap: sram: fix is_sram_locked check omap4: sram: Fix start address arch/arm/mach-omap2/id.c | 38 +- arch/arm/mach-omap2/omap4-common.c | 10 +-- arch/arm/plat-omap/dmtimer.c |2 +- arch/arm/plat-omap/include/plat/cpu.h|5 +++- arch/arm/plat-omap/include/plat/uncompress.h |1 + arch/arm/plat-omap/sram.c| 13 +--- 6 files changed, 46 insertions(+), 23 deletions(-) Regards, Santosh (As per thread: http://www.spinics.net/lists/linux-omap/msg37131.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 00/11] omap patches for review for v2.6.37 merge window
On Thu, 23 Sep 2010 18:50:38 -0700 Tony Lindgren wrote: > Hi all, > > Here are some omap patches that have not yet been posted to > linux-arm-kernel for review. > > Jarkko Nikula (4): > omap: n8x0: Cleanup i2c1 and menelaus registration > omap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810 > omap: n8x0: Mux i2s codec port pins for McBSP block > omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and docleanups > ... > Subramaniam C.A (1): > omap: i2c: Avoid compilation error in case the header is included > multiple times > Hmm... I wonder do I have something wrong or in patchwork but it looks like somehow a line feed gets introduced to subject line of some of my patches. And it seems to do with my patches only. Original patch in my mailbox or archive doesn't show it but it is in patchwork. http://marc.info/?l=linux-omap&m=128324955316265&w=2 https://patchwork.kernel.org/patch/144841/mbox -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9 v3] usb : musb: Using runtime pm apis for musb.
Hi,
>-Original Message-
>From: linux-usb-ow...@vger.kernel.org
>[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Kalliguddi, Hema
>Sent: Thursday, September 23, 2010 9:10 PM
>To: Kevin Hilman; Balbi, Felipe
>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>Basak, Partha; Tony Lindgren; Cousson, Benoit; Paul Walmsley
>Subject: RE: [PATCH 8/9 v3] usb : musb: Using runtime pm apis for musb.
>
>
>
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Thursday, September 23, 2010 9:00 PM
>>To: Balbi, Felipe
>>Cc: Kalliguddi, Hema; linux-omap@vger.kernel.org;
>>linux-...@vger.kernel.org; Basak, Partha; Tony Lindgren;
>>Cousson, Benoit; Paul Walmsley
>>Subject: Re: [PATCH 8/9 v3] usb : musb: Using runtime pm apis
>for musb.
>>
>>Felipe Balbi writes:
>>
>>> Hi,
>>>
>>> On Wed, Sep 22, 2010 at 07:30:30PM -0500, Kalliguddi, Hema wrote:
Calling runtime pm APIs pm_runtime_put_sync() and
>>pm_runtime_get_sync()
for enabling/disabling the clocks,sysconfig settings.
Also need to put the USB in force standby and force idle
>>mode when usb not used
and set it back to no idle and no stndby after wakeup.
For OMAP3 auto idle bit has to be disabled because of the
>>errata.So using
HWMOD_NO_OCP_AUTOIDLE flag for OMAP3430.
>>
>>[...]
>>
@@ -2424,13 +2425,16 @@ static int musb_suspend(struct device *d
* they will even be wakeup-enabled.
*/
}
+ pm_runtime_put_sync(dev);
+#ifndef CONFIG_PM_RUNTIME
musb_save_context(musb);
if (musb->set_clock)
musb->set_clock(musb->clock, 0);
else
clk_disable(musb->clock);
+#endif
>>>
>>> I would rather remove these, adding ifdefs is bad :-( Unless
>>other archs
>>> (blackfin, davinci) would have problems if we remove those.
>>
>>I didn't like these #ifdefs either, but davinci doesn't have
>>runtime PM,
>>and I don't think blackfin does either.
>>
>>But, rather than the ifdef here, this could be done with different
>>pointers in struct dev_pm_ops based on the arch.
>>
>>Also, this shouldn't be based on CONFIG_PM_RUNTIME, but rather on the
>>arch. We can still enable runtime PM on davinci for other subsystems
>>(PCI, USB core, etc.) but not have it supported for on-chip devices.
>>
>Is it a good idea to use the musb->set_clock function pointer
>for OMAP architure and
>call the runtime pm apis from this function defined in the usb
>platform driver(omap2430)
>
>>Kevin
Here is the patch which is making use of already existing platform set_clock
functions pointer.
With this we don't need to use #ifdefs.
If it looks good I will post it again along with series.
arch/arm/mach-omap2/usb-musb.c | 18 +
drivers/usb/musb/musb_core.c | 12 +++
drivers/usb/musb/omap2430.c| 43 ++---
3 files changed, 45 insertions(+), 28 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
@@ -46,6 +47,7 @@ static struct platform_device dummy_pdev
static void __iomem *otg_base;
static struct clk *otg_clk;
+static struct omap_hwmod *oh_p;
static void __init usb_musb_pm_init(void)
{
@@ -129,6 +131,20 @@ static struct omap_device_pm_latency oma
},
};
+void omap_set_clock(struct clk *clock , int is_on)
+{
+
+ struct omap_hwmod *oh = oh_p;
+ struct omap_device *od = oh->od;
+ struct platform_device *pdev = &od->pdev;
+ struct device *dev = &pdev->dev;
+
+ if(is_on)
+ pm_runtime_get_sync(dev);
+ else
+ pm_runtime_put_sync(dev);
+}
+
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
struct omap_hwmod *oh;
@@ -154,8 +170,10 @@ void __init usb_musb_init(struct omap_mu
musb_plat.power = board_data->power >> 1;
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
+ musb_plat.set_clock = omap_set_clock;
pdata = &musb_plat;
+ oh_p = oh;
od = omap_device_build(name, bus_id, oh, pdata,
sizeof(*pdata), omap_musb_latency,
Index: linux-omap-pm/drivers/usb/musb/musb_core.c
===
--- linux-omap-pm.orig/drivers/usb/musb/musb_core.c
+++ linux-omap-pm/drivers/usb/musb/musb_core.c
@@ -98,6 +98,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_ARM
#include
@@ -2457,9 +2458,20 @@ static int musb_resume_noirq(struct devi
return 0;
}
+static int musb_runtime_suspend(struct device *dev)
+{
+ return 0;
+}
+
+static int musb_runtime_resume(struct device *dev)
+{
+ return 0;
+}
static co
RE: [PATCH 00/14] omap sram, omap4 control module and es2.0 support
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Friday, September 24, 2010 6:43 AM > To: Shilimkar, Santosh > Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH 00/14] omap sram, omap4 control module and es2.0 > support > > * Shilimkar, Santosh [100918 00:24]: > > -Original Message- > > > From: Paul Walmsley [mailto:p...@pwsan.com] > > > Sent: Friday, September 17, 2010 11:21 PM > > > To: Shilimkar, Santosh > > > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org > > > Subject: Re: [PATCH 00/14] omap sram, omap4 control module and es2.0 > > > support > > > > > > Hello Santosh > > > > > > On Fri, 17 Sep 2010, Santosh Shilimkar wrote: > > > > > > > This is consolidated patch series targetted for 2.6.37 merge window. > > > > All of these patches have been already posted/reviewed on the list. > > > > > > Patch 6 is missing, could you please look into why? > > > > > Mostly because of size of the patch, You can pick this from the > > below git link > > > > > Also, please split all of the SCM changes out into a separate > > > series/branch since they will be going in through my tree. Am > reviewing > > > those now. > > > > > Ok done. I have split the series and kept scm changes on > 'omap4_scm_2.6.37' > > head and rest on 'omap_for_2.6.37' > > Santosh, the "Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries" should > get tested in the arm tree to avoid nasty surprises. Please do the > following > split: > > 1. A series for Russell to pull > ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries > omap: Map only available sram memory > davinci: map sram using MT_MEMORY_NONCACHED instead of MT_DEVICE > > You can add my Acked-by: Tony Lindgren to > the "Map only available sram memory" patch. > > 2. A series for me to pull > omap4: sram: Fix start address > omap4: Update id.c and cpu.h for es2.0 > omap4: l2x0: Fix init parameter for es2.0 > omap4: Panda: Add DEBUG_LL support > omap4: Fix bootup crash observed with higher CPU clocks > > 3. A series for Paul to pull (already in omap4_scm_2.6.37) > omap4: control: Add ctrl_pad_base to omap_globals > omap4: control: Add accessor api's for pad control module > omap4: control: Add the register definition headers > omap4: control: Fix the control module register accesses > > Please base them either on v2.6.35 or v2.6.36-rc5. > Will do arrange patches as you suggested. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP: features: export symbol omap3_features
From: Kevin Hilman
Since omap3_features is a global variable, only code
built-in the kernel can make use of it and thus use
omap_has ##feat functions; exporting this as a kernel
symbol makes modules able to use feature detection
framework too.
Thread: http://marc.info/?l=linux-omap&m=128528822902211&w=2
Signed-off-by: Kevin Hilman
Signed-off-by: Omar Ramirez Luna
CC: Tony Lindgren
CC: Russell King
CC: Nishanth Menon
CC: Paul Walmsley
CC: Sanjeev Premi
CC: linux-omap@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
---
arch/arm/mach-omap2/id.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 9a879f9..a8c6d19 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -31,6 +31,7 @@ static struct omap_chip_id omap_chip;
static unsigned int omap_revision;
u32 omap3_features;
+EXPORT_SYMBOL(omap3_features);
unsigned int omap_rev(void)
{
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: mailbox: fix detection for previously supported chips
Fix the mailbox detection for OMAP3630, 3530/25 and 2430.
Given that 2430 has an iva too include it, as the same steps
for omap3 apply.
Signed-off-by: Omar Ramirez Luna
CC: Tony Lindgren
CC: Russell King
CC: Hiroshi DOYU
CC: Felipe Contreras
CC: Suman Anna
CC: Kevin Hilman
CC: linux-omap@vger.kernel.org
---
arch/arm/mach-omap2/mailbox.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 42dbfa4..26d6fb0 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -394,15 +394,19 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (false)
;
-#if defined(CONFIG_ARCH_OMAP3430)
- else if (cpu_is_omap3430()) {
+#if defined(CONFIG_ARCH_OMAP3)
+ else if (omap3_has_iva()) {
list = omap3_mboxes;
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
}
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
- else if (cpu_is_omap2420()) {
+#if defined(CONFIG_ARCH_OMAP2)
+ else if (cpu_is_omap2430()) {
+ list = omap2_mboxes;
+
+ list[0]->irq = platform_get_irq_byname(pdev, "dsp");
+ } else if (cpu_is_omap2420()) {
list = omap2_mboxes;
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] omap: mmc: extended to pass host capabilities from board file
From: Sukumar Ghorai
wires variable is renamed, extended and this single variable to be used to
pass the platform capabilities, e.g DDR mode. Also removed the hardcoded
value was using as bus-width.
Signed-off-by: Sukumar Ghorai
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-2430sdp.c |3 ++-
arch/arm/mach-omap2/board-3430sdp.c |5 +++--
arch/arm/mach-omap2/board-4430sdp.c |4 ++--
arch/arm/mach-omap2/board-cm-t35.c |5 +++--
arch/arm/mach-omap2/board-devkit8000.c |3 ++-
arch/arm/mach-omap2/board-igep0020.c |5 +++--
arch/arm/mach-omap2/board-ldp.c |3 ++-
arch/arm/mach-omap2/board-n8x0.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |3 ++-
arch/arm/mach-omap2/board-omap3evm.c |3 ++-
arch/arm/mach-omap2/board-omap3pandora.c |7 ---
arch/arm/mach-omap2/board-omap3stalker.c |3 ++-
arch/arm/mach-omap2/board-omap3touchbook.c |3 ++-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-overo.c|5 +++--
arch/arm/mach-omap2/board-rx51-peripherals.c |5 +++--
arch/arm/mach-omap2/board-zoom-peripherals.c |5 +++--
arch/arm/mach-omap2/devices.c| 16 +---
arch/arm/mach-omap2/hsmmc.c | 16 ++--
arch/arm/mach-omap2/hsmmc.h |3 ++-
arch/arm/plat-omap/include/plat/mmc.h|7 +++
drivers/mmc/host/omap.c |2 +-
drivers/mmc/host/omap_hsmmc.c| 18 ++
23 files changed, 67 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 8538e41..fc178a0 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -190,7 +191,7 @@ static int __init omap2430_i2c_init(void)
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.mmc= 1,
- .wires = 4,
+ .caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ext_clock = 1,
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 67b95b5..3eb9839 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -353,12 +354,12 @@ static struct omap2_hsmmc_info mmc[] = {
/* 8 bits (default) requires S6.3 == ON,
* so the SIM card isn't used; else 4 bits.
*/
- .wires = 8,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 4,
},
{
.mmc= 2,
- .wires = 8,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 7,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..e379bef 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -193,12 +193,12 @@ static struct omap_musb_board_data musb_board_data = {
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
- .wires = 8,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
},
{
.mmc= 2,
- .wires = 8,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.nonremovable = true,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e10bc10..b72009a 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -579,14 +580,14 @@ static struct twl4030_keypad_data cm_t35_kp_data = {
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
- .wires = 4,
+ .caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
},
{
.mmc= 2,
- .wires = 4,
+ .caps = MMC_CAP_4_BIT_DATA,
.transceiver= 1,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
diff --git a/arch/arm/mach-o
[PATCH 10/11] omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and docleanups
From: Jarkko Nikula
This 'legacy' OMAP2420 McBSP2 muxing code is currently broken after recent
conversion to new mux code. The omap_mcbsp_request calling this code is
usually called after booting whereas the omap_mux_init_signal is __init
marked so null pointer dereference would occur.
Fix this by removing the muxing code and let the bootloader or board file to
do it if necessary. Remove also omap2_mcbsp_ops as there is no use for it.
Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mcbsp.c | 39 ---
1 files changed, 0 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 467aae2..88b8790 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -23,29 +23,6 @@
#include
#include
-#include "mux.h"
-
-static void omap2_mcbsp2_mux_setup(void)
-{
- omap_mux_init_signal("eac_ac_sclk.mcbsp2_clkx", OMAP_PULL_ENA);
- omap_mux_init_signal("eac_ac_fs.mcbsp2_fsx", OMAP_PULL_ENA);
- omap_mux_init_signal("eac_ac_din.mcbsp2_dr", OMAP_PULL_ENA);
- omap_mux_init_signal("eac_ac_dout.mcbsp2_dx", OMAP_PULL_ENA);
- omap_mux_init_gpio(117, OMAP_PULL_ENA);
- /*
-* TODO: Need to add MUX settings for OMAP 2430 SDP
-*/
-}
-
-static void omap2_mcbsp_request(unsigned int id)
-{
- if (cpu_is_omap2420() && (id == OMAP_MCBSP2))
- omap2_mcbsp2_mux_setup();
-}
-
-static struct omap_mcbsp_ops omap2_mcbsp_ops = {
- .request= omap2_mcbsp_request,
-};
#ifdef CONFIG_ARCH_OMAP2420
static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
@@ -55,7 +32,6 @@ static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= &omap2_mcbsp_ops,
},
{
.phys_base = OMAP24XX_MCBSP2_BASE,
@@ -63,7 +39,6 @@ static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
- .ops= &omap2_mcbsp_ops,
},
};
#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
@@ -82,7 +57,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= &omap2_mcbsp_ops,
},
{
.phys_base = OMAP24XX_MCBSP2_BASE,
@@ -90,7 +64,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
- .ops= &omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP3_BASE,
@@ -98,7 +71,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
- .ops= &omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP4_BASE,
@@ -106,7 +78,6 @@ static struct omap_mcbsp_platform_data
omap2430_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP4_TX,
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
- .ops= &omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP5_BASE,
@@ -114,7 +85,6 @@ static struct omap_mcbsp_platform_data
omap2430_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP5_TX,
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
- .ops= &omap2_mcbsp_ops,
},
};
#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
@@ -133,7 +103,6 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= &omap2_mcbsp_ops,
.buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
@@ -143,7 +112,6 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
[PATCH 07/11] omap: crypto: updates to enable omap aes
From: Dmitry Kasatkin
Updates to enable omap aes
Signed-off-by: Dmitry Kasatkin
[t...@atomide.com: updated to use CONFIG_ARCH_OMAP2/3 instead of old 24XX/34XX]
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock2420_data.c |2 -
arch/arm/mach-omap2/clock2430_data.c |2 -
arch/arm/mach-omap2/clock3xxx_data.c |2 -
arch/arm/mach-omap2/devices.c| 71 ++
4 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 37d65d6..5f2066a 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1838,7 +1838,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "des_ick", &des_ick, CK_242X),
CLK("omap-sham","ick", &sha_ick, CK_242X),
CLK("omap_rng", "ick", &rng_ick, CK_242X),
- CLK(NULL, "aes_ick", &aes_ick, CK_242X),
+ CLK("omap-aes", "ick", &aes_ick, CK_242X),
CLK(NULL, "pka_ick", &pka_ick, CK_242X),
CLK(NULL, "usb_fck", &usb_fck, CK_242X),
CLK("musb_hdrc","fck", &osc_ck,CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index b33118f..701a171 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1926,7 +1926,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, "des_ick", &des_ick, CK_243X),
CLK("omap-sham","ick", &sha_ick, CK_243X),
CLK("omap_rng", "ick", &rng_ick, CK_243X),
- CLK(NULL, "aes_ick", &aes_ick, CK_243X),
+ CLK("omap-aes", "ick", &aes_ick, CK_243X),
CLK(NULL, "pka_ick", &pka_ick, CK_243X),
CLK(NULL, "usb_fck", &usb_fck, CK_243X),
CLK("musb_hdrc","ick", &usbhs_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index dfdce2d..c73906d 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3288,7 +3288,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "usbtll_ick", &usbtll_ick,CK_3430ES2 | CK_AM35XX),
CLK("mmci-omap-hs.2", "ick", &mmchs3_ick,CK_3430ES2 | CK_AM35XX),
CLK(NULL, "icr_ick", &icr_ick, CK_343X),
- CLK(NULL, "aes2_ick", &aes2_ick, CK_343X),
+ CLK("omap-aes", "ick", &aes2_ick, CK_343X),
CLK("omap-sham","ick", &sha12_ick, CK_343X),
CLK(NULL, "des2_ick", &des2_ick, CK_343X),
CLK("mmci-omap-hs.1", "ick", &mmchs2_ick,CK_3XXX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..dc49c07 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -498,6 +498,76 @@ static void omap_init_sham(void)
static inline void omap_init_sham(void) { }
#endif
+#if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
+
+#ifdef CONFIG_ARCH_OMAP2
+static struct resource omap2_aes_resources[] = {
+ {
+ .start = OMAP24XX_SEC_AES_BASE,
+ .end= OMAP24XX_SEC_AES_BASE + 0x4C,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP24XX_DMA_AES_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .start = OMAP24XX_DMA_AES_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+static int omap2_aes_resources_sz = ARRAY_SIZE(omap2_aes_resources);
+#else
+#define omap2_aes_resourcesNULL
+#define omap2_aes_resources_sz 0
+#endif
+
+#ifdef CONFIG_ARCH_OMAP3
+static struct resource omap3_aes_resources[] = {
+ {
+ .start = OMAP34XX_SEC_AES_BASE,
+ .end= OMAP34XX_SEC_AES_BASE + 0x4C,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP34XX_DMA_AES2_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .start = OMAP34XX_DMA_AES2_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+static int omap3_aes_resources_sz = ARRAY_SIZE(omap3_aes_resources);
+#else
+#define omap3_aes_resourcesNULL
+#define omap3_aes_resources_sz 0
+#endif
+
+static struct platform_device aes_device = {
+ .name = "omap-aes",
+ .id = -1,
+};
+
+static void omap_init_aes(void)
+{
+ if (cpu_is_omap24xx()) {
+ aes_device.resource = omap2_aes_resources;
+ aes_device.num_resources = omap2_aes_resources_sz;
+ } else if (cpu_is_omap34xx()) {
+ aes_device.resource = omap3_aes_resources;
+ aes_device.num_resources = omap3_ae
[PATCH 08/11] omap: i2c: Avoid compilation error in case the header is included multiple times
From: Subramaniam C.A Added defines to avoid compilation error. Signed-off-by: Subramaniam C.A Acked-by: Felipe Balbi Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/include/plat/i2c.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/i2c.h b/arch/arm/plat-omap/include/plat/i2c.h index 87f6bf2..36a0bef 100644 --- a/arch/arm/plat-omap/include/plat/i2c.h +++ b/arch/arm/plat-omap/include/plat/i2c.h @@ -18,6 +18,8 @@ * 02110-1301 USA * */ +#ifndef __ASM__ARCH_OMAP_I2C_H +#define __ASM__ARCH_OMAP_I2C_H #include @@ -36,3 +38,5 @@ static inline int omap_register_i2c_bus(int bus_id, u32 clkrate, void __init omap1_i2c_mux_pins(int bus_id); void __init omap2_i2c_mux_pins(int bus_id); + +#endif /* __ASM__ARCH_OMAP_I2C_H */ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/11] omap: McBSP: Do not enable SRG in slave mode
From: Peter Ujfalusi
McBSP SRG (Sample Rate Generator) and FSG (Frame Sync
Generator) is only needed to be enabled, when McBSP
is master.
In McBSP slave mode, the SRG, and FSG can be kept disabled,
which might save some power at the end in this configuration.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/mcbsp.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e31496e..ecbfe39 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -878,7 +878,7 @@ EXPORT_SYMBOL(omap_mcbsp_free);
void omap_mcbsp_start(unsigned int id, int tx, int rx)
{
struct omap_mcbsp *mcbsp;
- int idle;
+ int enable_srg = 0;
u16 w;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -893,10 +893,13 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
mcbsp->rx_word_length = (MCBSP_READ_CACHE(mcbsp, RCR1) >> 5) & 0x7;
mcbsp->tx_word_length = (MCBSP_READ_CACHE(mcbsp, XCR1) >> 5) & 0x7;
- idle = !((MCBSP_READ_CACHE(mcbsp, SPCR2) |
- MCBSP_READ_CACHE(mcbsp, SPCR1)) & 1);
+ /* Only enable SRG, if McBSP is master */
+ w = MCBSP_READ_CACHE(mcbsp, PCR0);
+ if (w & (FSXM | FSRM | CLKXM | CLKRM))
+ enable_srg = !((MCBSP_READ_CACHE(mcbsp, SPCR2) |
+ MCBSP_READ_CACHE(mcbsp, SPCR1)) & 1);
- if (idle) {
+ if (enable_srg) {
/* Start the sample generator */
w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 << 6));
@@ -919,7 +922,7 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
*/
udelay(500);
- if (idle) {
+ if (enable_srg) {
/* Start frame sync */
w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 << 7));
--
To unsubscribe from this list: send the line "unsubscribe 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 04/11] omap: n8x0: Mux i2s codec port pins for McBSP block
From: Jarkko Nikula
Bootloader on Nokia N800 and N810 muxes I2C codec port pins for EAC block.
As there is no driver and use for EAC, mux those pins for McBSP instead
since N810 ASoC drivers can use it.
Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-n8x0.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 7863633..8fd2269 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -660,6 +660,11 @@ static void __init n8x0_init_irq(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* I2S codec port pins for McBSP block */
+ OMAP2420_MUX(EAC_AC_SCLK, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP2420_MUX(EAC_AC_FS, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP2420_MUX(EAC_AC_DIN, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP2420_MUX(EAC_AC_DOUT, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
To unsubscribe from this list: send the line "unsubscribe 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 05/11] omap3: Remove non-existent config option
From: Yogesh Marathe
The definition of "iva2" device in iommu_device
is wrapped inside CONFIG_MPU_BRIDGE_IOMMU, but
this option is not defined in KConfig.
This patch removes the wrapper and makes "iva2"
available as another iommu_device.
Signed-off-by: Yogesh Marathe
Signed-off-by: Sanjeev Premi
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/omap-iommu.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..bb8c01d 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -35,7 +35,6 @@ static struct iommu_device omap3_devices[] = {
.clk_name = "cam_ick",
},
},
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
{
.base = 0x5d00,
.irq = 28,
@@ -45,7 +44,6 @@ static struct iommu_device omap3_devices[] = {
.clk_name = "iva2_ck",
},
},
-#endif
};
#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] omap: usb: fix build warning
From: Anand Gadiyar
Fix this and similar build warnings when building with
omap_4430sdp_defconfig.
CC arch/arm/mach-omap2/board-4430sdp.o
In file included from arch/arm/mach-omap2/board-4430sdp.c:36:
arch/arm/plat-omap/include/plat/usb.h:109: warning: return type defaults to
'int'
Signed-off-by: Anand Gadiyar
Acked-by: Felipe Balbi
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/include/plat/usb.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 2a9427c..6674562 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -105,7 +105,7 @@ static inline void omap1_usb_init(struct omap_usb_config
*pdata)
#if defined(CONFIG_ARCH_OMAP_OTG) || defined(CONFIG_ARCH_OMAP_OTG_MODULE)
void omap2_usbfs_init(struct omap_usb_config *pdata);
#else
-static inline omap2_usbfs_init(struct omap_usb_config *pdata)
+static inline void omap2_usbfs_init(struct omap_usb_config *pdata)
{
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] omap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810
From: Jarkko Nikula
Second i2c bus on Nokia N800 and N810 shares both common and hw specific
peripherals. Register now this bus and add board info with tlv320aic3x for
N810. Common peripherals may be added as an additional board info to
omap_register_i2c_bus(2, ...);
Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-n8x0.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 313ce5e..7863633 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -633,6 +634,17 @@ static struct i2c_board_info __initdata
n8x0_i2c_board_info_1[] __initdata = {
},
};
+static struct aic3x_pdata n810_aic33_data __initdata = {
+ .gpio_reset = 118,
+};
+
+static struct i2c_board_info n810_i2c_board_info_2[] __initdata = {
+ {
+ I2C_BOARD_INFO("tlv320aic3x", 0x18),
+ .platform_data = &n810_aic33_data,
+ },
+};
+
static void __init n8x0_map_io(void)
{
omap2_set_globals_242x();
@@ -662,6 +674,10 @@ static void __init n8x0_init_machine(void)
ARRAY_SIZE(n800_spi_board_info));
omap_register_i2c_bus(1, 400, n8x0_i2c_board_info_1,
ARRAY_SIZE(n8x0_i2c_board_info_1));
+ omap_register_i2c_bus(2, 400, NULL, 0);
+ if (machine_is_nokia_n810())
+ i2c_register_board_info(2, n810_i2c_board_info_2,
+ ARRAY_SIZE(n810_i2c_board_info_2));
omap_serial_init();
n8x0_onenand_init();
--
To unsubscribe from this list: send the line "unsubscribe 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 02/11] omap: n8x0: Cleanup i2c1 and menelaus registration
From: Jarkko Nikula
- Move n8x0_i2c_board_info_1 out from #ifdef CONFIG_MENELAUS block,
register i2c1 in n8x0_init_machine and do a few clean-ups around these.
Code looks better if board infos are grouped together
- Mark n8x0_i2c_board_info_1 and n8x0_menelaus_platform_data with __initdata
Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-n8x0.c | 34 +++---
1 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index a3e2b49..313ce5e 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -614,30 +614,25 @@ static int n8x0_menelaus_late_init(struct device *dev)
return 0;
}
-static struct i2c_board_info __initdata n8x0_i2c_board_info_1[] = {
+#else
+static int n8x0_menelaus_late_init(struct device *dev)
+{
+ return 0;
+}
+#endif
+
+static struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = {
+ .late_init = n8x0_menelaus_late_init,
+};
+
+static struct i2c_board_info __initdata n8x0_i2c_board_info_1[] __initdata = {
{
I2C_BOARD_INFO("menelaus", 0x72),
.irq = INT_24XX_SYS_NIRQ,
+ .platform_data = &n8x0_menelaus_platform_data,
},
};
-static struct menelaus_platform_data n8x0_menelaus_platform_data = {
- .late_init = n8x0_menelaus_late_init,
-};
-
-static void __init n8x0_menelaus_init(void)
-{
- n8x0_i2c_board_info_1[0].platform_data = &n8x0_menelaus_platform_data;
- omap_register_i2c_bus(1, 400, n8x0_i2c_board_info_1,
- ARRAY_SIZE(n8x0_i2c_board_info_1));
-}
-
-#else
-static inline void __init n8x0_menelaus_init(void)
-{
-}
-#endif
-
static void __init n8x0_map_io(void)
{
omap2_set_globals_242x();
@@ -665,9 +660,10 @@ static void __init n8x0_init_machine(void)
/* FIXME: add n810 spi devices */
spi_register_board_info(n800_spi_board_info,
ARRAY_SIZE(n800_spi_board_info));
+ omap_register_i2c_bus(1, 400, n8x0_i2c_board_info_1,
+ ARRAY_SIZE(n8x0_i2c_board_info_1));
omap_serial_init();
- n8x0_menelaus_init();
n8x0_onenand_init();
n8x0_mmc_init();
n8x0_usb_init();
--
To unsubscribe from this list: send the line "unsubscribe 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 01/11] omap2: fix assorted compiler warnings
From: Sanjeev Premi
This patch fixes these compiler warnings:
CC arch/arm/mach-omap2/mux.o
arch/arm/mach-omap2/mux.c: In function 'omap_mux_init_gpio':
arch/arm/mach-omap2/mux.c:90: warning: 'gpio_mux' may be used uninitial
ized in this function
CC arch/arm/plat-omap/gpio.o
arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_resume_after_idle':
arch/arm/plat-omap/gpio.c:2152: warning: 'l' may be used uninitialized
in this function
arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_prepare_for_idle':
arch/arm/plat-omap/gpio.c:2085: warning: 'l2' may be used uninitialized
in this function
arch/arm/plat-omap/gpio.c:2085: warning: 'l1' may be used uninitialized
in this function
CC arch/arm/mach-omap2/board-omap4panda.o
arch/arm/mach-omap2/board-omap4panda.c: In function 'omap4_panda_init':
arch/arm/mach-omap2/board-omap4panda.c:277: warning: unused variable 's
tatus'
Signed-off-by: Sanjeev Premi
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-omap4panda.c |2 --
arch/arm/mach-omap2/mux.c |2 +-
arch/arm/plat-omap/gpio.c |4 ++--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c03d1d5..96f5bbb 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -274,8 +274,6 @@ static int __init omap4_panda_i2c_init(void)
}
static void __init omap4_panda_init(void)
{
- int status;
-
omap4_panda_i2c_init();
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index ab403b2..6c2f8f0 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -87,7 +87,7 @@ static char *omap_mux_options;
int __init omap_mux_init_gpio(int gpio, int val)
{
struct omap_mux_entry *e;
- struct omap_mux *gpio_mux;
+ struct omap_mux *gpio_mux = NULL;
u16 old_mode;
u16 mux_mode;
int found = 0;
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 11c5b0e..c05c653 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2084,7 +2084,7 @@ void omap2_gpio_prepare_for_idle(int power_state)
for (i = min; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
- u32 l1, l2;
+ u32 l1 = 0, l2 = 0;
int j;
for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
@@ -2152,7 +2152,7 @@ void omap2_gpio_resume_after_idle(void)
min = 1;
for (i = min; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
- u32 l, gen, gen0, gen1;
+ u32 l = 0, gen, gen0, gen1;
int j;
for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
--
To unsubscribe from this list: send the line "unsubscribe 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 00/11] omap patches for review for v2.6.37 merge window
Hi all, Here are some omap patches that have not yet been posted to linux-arm-kernel for review. Regards, Tony --- Anand Gadiyar (1): omap: usb: fix build warning Dmitry Kasatkin (1): omap: crypto: updates to enable omap aes Jarkko Nikula (4): omap: n8x0: Cleanup i2c1 and menelaus registration omap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810 omap: n8x0: Mux i2s codec port pins for McBSP block omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and docleanups Peter Ujfalusi (1): omap: McBSP: Do not enable SRG in slave mode Sanjeev Premi (1): omap2: fix assorted compiler warnings Subramaniam C.A (1): omap: i2c: Avoid compilation error in case the header is included multiple times Sukumar Ghorai (1): omap: mmc: extended to pass host capabilities from board file Yogesh Marathe (1): omap3: Remove non-existent config option arch/arm/mach-omap2/board-2430sdp.c |3 + arch/arm/mach-omap2/board-3430sdp.c |5 + arch/arm/mach-omap2/board-4430sdp.c |4 + arch/arm/mach-omap2/board-cm-t35.c |5 + arch/arm/mach-omap2/board-devkit8000.c |3 + arch/arm/mach-omap2/board-igep0020.c |5 + arch/arm/mach-omap2/board-ldp.c |3 + arch/arm/mach-omap2/board-n8x0.c | 51 ++- arch/arm/mach-omap2/board-omap3beagle.c |3 + arch/arm/mach-omap2/board-omap3evm.c |3 + arch/arm/mach-omap2/board-omap3pandora.c |7 +- arch/arm/mach-omap2/board-omap3stalker.c |3 + arch/arm/mach-omap2/board-omap3touchbook.c |3 + arch/arm/mach-omap2/board-omap4panda.c |4 - arch/arm/mach-omap2/board-overo.c|5 + arch/arm/mach-omap2/board-rx51-peripherals.c |5 + arch/arm/mach-omap2/board-zoom-peripherals.c |5 + arch/arm/mach-omap2/clock2420_data.c |2 - arch/arm/mach-omap2/clock2430_data.c |2 - arch/arm/mach-omap2/clock3xxx_data.c |2 - arch/arm/mach-omap2/devices.c| 87 -- arch/arm/mach-omap2/hsmmc.c | 16 +++-- arch/arm/mach-omap2/hsmmc.h |3 + arch/arm/mach-omap2/mcbsp.c | 39 arch/arm/mach-omap2/mux.c|2 - arch/arm/mach-omap2/omap-iommu.c |2 - arch/arm/plat-omap/gpio.c|4 + arch/arm/plat-omap/include/plat/i2c.h|4 + arch/arm/plat-omap/include/plat/mmc.h|7 +- arch/arm/plat-omap/include/plat/usb.h|2 - arch/arm/plat-omap/mcbsp.c | 13 ++-- drivers/mmc/host/omap.c |2 - drivers/mmc/host/omap_hsmmc.c| 18 + 33 files changed, 190 insertions(+), 132 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] omap sram, omap4 control module and es2.0 support
* Shilimkar, Santosh [100918 00:24]: > -Original Message- > > From: Paul Walmsley [mailto:p...@pwsan.com] > > Sent: Friday, September 17, 2010 11:21 PM > > To: Shilimkar, Santosh > > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH 00/14] omap sram, omap4 control module and es2.0 > > support > > > > Hello Santosh > > > > On Fri, 17 Sep 2010, Santosh Shilimkar wrote: > > > > > This is consolidated patch series targetted for 2.6.37 merge window. > > > All of these patches have been already posted/reviewed on the list. > > > > Patch 6 is missing, could you please look into why? > > > Mostly because of size of the patch, You can pick this from the > below git link > > > Also, please split all of the SCM changes out into a separate > > series/branch since they will be going in through my tree. Am reviewing > > those now. > > > Ok done. I have split the series and kept scm changes on 'omap4_scm_2.6.37' > head and rest on 'omap_for_2.6.37' Santosh, the "Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries" should get tested in the arm tree to avoid nasty surprises. Please do the following split: 1. A series for Russell to pull ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries omap: Map only available sram memory davinci: map sram using MT_MEMORY_NONCACHED instead of MT_DEVICE You can add my Acked-by: Tony Lindgren to the "Map only available sram memory" patch. 2. A series for me to pull omap4: sram: Fix start address omap4: Update id.c and cpu.h for es2.0 omap4: l2x0: Fix init parameter for es2.0 omap4: Panda: Add DEBUG_LL support omap4: Fix bootup crash observed with higher CPU clocks 3. A series for Paul to pull (already in omap4_scm_2.6.37) omap4: control: Add ctrl_pad_base to omap_globals omap4: control: Add accessor api's for pad control module omap4: control: Add the register definition headers omap4: control: Fix the control module register accesses Please base them either on v2.6.35 or v2.6.36-rc5. 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: [GIT PULL] pm-next: misc. PM updates for 2.6.37
* Kevin Hilman [100923 17:16]: > Tony, > > Please pull the misc PM updates below for 2.6.37. > > Note that this pull request should've come before the pm-runtime one > since the pm-runtime branch has some a build dependency on the omap_device > patches in this series. OK. Pulling both branches into omap-for-linus. 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: [GIT PULL] OMAP: hwmod fixes and improvements for 2.6.37
* Paul Walmsley [100923 00:14]: > > Hi Tony, > > The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c: > > Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700) > > are available in the git repository at: > git://git.pwsan.com/linux-2.6 hwmod_2.6.37 Thanks, pulling into omap-for-linus. Ton -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/6] OMAP1: Amstrad Delta: add support for camera
* Janusz Krzysztofik [100923 16:52]: > Friday 24 September 2010 01:26:17 Tony Lindgren napisał(a): > > * Tony Lindgren [100923 16:06]: > > > * Janusz Krzysztofik [100910 18:20]: > > > > This patch adds configuration data and initialization code required for > > > > camera support to the Amstrad Delta board. > > > > > > > > Three devices are declared: SoC camera, OMAP1 camera interface and > > > > OV6650 sensor. > > > > > > > > Default 12MHz clock has been selected for driving the sensor. Pixel > > > > clock has been limited to get reasonable frame rates, not exceeding the > > > > board capabilities. Since both devices (interface and sensor) support > > > > both pixel clock polarities, decision on polarity selection has been > > > > left to drivers. Interface GPIO line has been found not functional, > > > > thus not configured. > > > > > > > > Created and tested against linux-2.6.36-rc3. > > > > > > > > Works on top of previous patches from the series, at least 1/6, 2/6 and > > > > 3/6. > > > > > > Queuing these last two patches of the series (5/6 and 6/6) for the > > > upcoming merge window. > > > > BTW, these still depend on updated 2/6 to make compile happy. > > Not so simple: still depends on struct omap1_cam_platform_data definition > from > , included from . Are you ready to > accept another temporary workaround? Heh I guess so. Or do you want to queue everything via linux-media? 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: [RFC] omap: mailbox: fix detection for previously supported chips
Kevin Hilman wrote:
> "Ramirez Luna, Omar" writes:
>
>> Ramirez Luna, Omar wrote:
>>> Fix the mailbox support detection for OMAP3630, 3530/25 and 2430.
>>>
>>> Signed-off-by: Omar Ramirez Luna
>>> ---
>>> - Testing was made under 3630 and 3430 boards.
>>> - Given that 2430 uses similar initialization than OMAP3, changes
>>> to handle this case was added to the patch.
>>> - HWMOD adaptation hopefully should solve this mess, but as of now
>>> mailbox should work as before at least.
>>>
>>> arch/arm/mach-omap2/mailbox.c | 12
>>> 1 files changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/mailbox.c
>>> b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..26d6fb0 100644 ---
>>> a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c
>>> @@ -394,15 +394,19 @@ static int __devinit omap2_mbox_probe(struct
>>> platform_device *pdev)
>>>
>>> if (false)
>>> ;
>>> -#if defined(CONFIG_ARCH_OMAP3430)
>>> - else if (cpu_is_omap3430()) {
>>> +#if defined(CONFIG_ARCH_OMAP3)
>>> + else if (omap3_has_iva()) {
>>
>> Hmm, seems omap3_has_ ##feat are only available for built-in and not
>> module configurations, this patch is not so good after all since it
>> throws:
>>
>> ERROR: "omap3_features" [arch/arm/mach-omap2/mailbox_mach.ko]
>> undefined!
>
> Well, feature detection certainly should be available to modules.
>
> How about proposing a simple fix for this. Something like the
> following (untested) should work, since the individual omap3_has_*
> checks are static inlines.
Ok great, I wasn't sure if exporting this variable as a symbol was desired.
Will try and resend.
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] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
* Cory Maccarrone [100923 10:18]: > On Thu, Sep 23, 2010 at 10:22 AM, Tony Lindgren wrote: > > * Cory Maccarrone [100817 21:28]: > >> This change adds in MMC and I2C support to the HTC Herald board, as well > >> as adding the HTCPLD driver for the PLD used on this phone. It also > >> adds in the gpio-keys entries for the front directional keys and > >> selector and the cursor keys on the slide-out keyboard, and gpio-leds > >> support for the LEDs attached to the htcpld. > >> > >> Additionally, SPI bus support (using the spi100k driver) and > >> touchscreen support (using the ads7846 driver) were added. > > > > Thanks, I'll add this into omap-for-linus for the upcoming merge > > window. Cory, can you please check if you have other pending > > patches? I don't see others in patchwork.kernel.org, but thought > > there may be some that did not get merged last merge window? > > > > I believe you have everything. I had submitted a series of 5 patches > that you commented on, and this one was the boiled down combination of > all of those (minus one element which I'm still looking into). So, > just this one should be pending. OK 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: [RFC] omap: mailbox: fix detection for previously supported chips
"Ramirez Luna, Omar" writes:
> Ramirez Luna, Omar wrote:
>> Fix the mailbox support detection for OMAP3630, 3530/25 and 2430.
>>
>> Signed-off-by: Omar Ramirez Luna
>> ---
>> - Testing was made under 3630 and 3430 boards.
>> - Given that 2430 uses similar initialization than OMAP3, changes
>> to handle this case was added to the patch.
>> - HWMOD adaptation hopefully should solve this mess, but as of now
>> mailbox should work as before at least.
>>
>> arch/arm/mach-omap2/mailbox.c | 12
>> 1 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/mailbox.c
>> b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..26d6fb0 100644 ---
>> a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c
>> @@ -394,15 +394,19 @@ static int __devinit omap2_mbox_probe(struct
>> platform_device *pdev)
>>
>> if (false)
>> ;
>> -#if defined(CONFIG_ARCH_OMAP3430)
>> -else if (cpu_is_omap3430()) {
>> +#if defined(CONFIG_ARCH_OMAP3)
>> +else if (omap3_has_iva()) {
>
> Hmm, seems omap3_has_ ##feat are only available for built-in and not module
> configurations, this patch is not so good after all since it throws:
>
> ERROR: "omap3_features" [arch/arm/mach-omap2/mailbox_mach.ko] undefined!
Well, feature detection certainly should be available to modules.
How about proposing a simple fix for this. Something like the following
(untested) should work, since the individual omap3_has_* checks are
static inlines.
Kevin
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 9a879f9..a8c6d19 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -31,6 +31,7 @@ static struct omap_chip_id omap_chip;
static unsigned int omap_revision;
u32 omap3_features;
+EXPORT_SYMBOL(omap3_features);
unsigned int omap_rev(void)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] pm-next: misc. PM updates for 2.6.37
Tony, Please pull the misc PM updates below for 2.6.37. Note that this pull request should've come before the pm-runtime one since the pm-runtime branch has some a build dependency on the omap_device patches in this series. Thanks, Kevin The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c: Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-next Benoit Cousson (2): OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2 OMAP4: pm: Change l3_main to l3_main_1 during bus device init Kevin Hilman (5): OMAP3: PM: whitespace cleanup around IO wakeup enable OMAP3: PM: move device-specific special cases from PM core into CPUidle Revert "OMAP: omap_device: add omap_device_is_valid()" OMAP: omap_device: make all devices a child of a new parent device OMAP: GPIO: ensure debounce clocks are disabled during idle/suspend Paul Walmsley (1): OMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts Santosh Shilimkar (3): omap: pm-debug: Move common debug code to pm-debug.c omap: pm-debug: Enable wakeup_timer_milliseconds debugfs entry omap: pm: Move set_pwrdm_state routine to common pm.c Thara Gopinath (2): OMAP: PM debugfs removing OMAP3 hardcodings. OMAP4: pm.c extensions for OMAP4 support arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/clockdomain.c | 110 +- arch/arm/mach-omap2/cpuidle34xx.c | 58 +++- arch/arm/mach-omap2/io.c |7 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 482 + arch/arm/mach-omap2/pm-debug.c| 42 ++- arch/arm/mach-omap2/pm.c | 75 - arch/arm/mach-omap2/pm.h |4 +- arch/arm/mach-omap2/pm34xx.c | 99 +- arch/arm/plat-omap/Makefile |2 +- arch/arm/plat-omap/gpio.c |6 +- arch/arm/plat-omap/include/plat/common.h |3 +- arch/arm/plat-omap/include/plat/omap_device.h |4 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/omap_device.c | 32 +- 15 files changed, 696 insertions(+), 230 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] OMAP3: PM: move device-specific special cases from PM core into CPUidle
Kevin Hilman writes:
> Paul Walmsley writes:
>
>> Hi Kevin
>>
>> On Tue, 21 Sep 2010, Kevin Hilman wrote:
>>
>>> Paul Walmsley writes:
>>>
>>> > On Wed, 15 Sep 2010, Kevin Hilman wrote:
>>> >
>>> >> In an effort to simplify the core idle path, move any device-specific
>>> >> special case handling from the core PM idle path into the CPUidle
>>> >> pre-idle checking path.
>>> >
>>> > As with the original patch, I don't quite understand the improvement
>>> > here. In particular, this part:
>>> >
>>> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>>> >> b/arch/arm/mach-omap2/cpuidle34xx.c
>>> >> index 3d3d035..0923b82 100644
>>> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>>> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>>> >> @@ -233,14 +234,54 @@ static int omap3_enter_idle_bm(struct
>>> >> cpuidle_device *dev,
>>> >> struct cpuidle_state *state)
>>> >> {
>>> >> struct cpuidle_state *new_state = next_valid_state(dev, state);
>>> >> +u32 core_next_state, per_next_state = 0, per_saved_state = 0;
>>> >> +u32 cam_state;
>>> >> +struct omap3_processor_cx *cx;
>>> >> +int ret;
>>> >>
>>> >> if ((state->flags & CPUIDLE_FLAG_CHECK_BM) &&
>>> >> omap3_idle_bm_check()) {
>>> >> BUG_ON(!dev->safe_state);
>>> >> new_state = dev->safe_state;
>>> >> +goto select_state;
>>> >> +}
>>> >> +
>>> >> +cx = cpuidle_get_statedata(state);
>>> >> +core_next_state = cx->core_state;
>>> >> +
>>> >> +/*
>>> >> + * Prevent idle completely if CAM is active.
>>> >> + * CAM does not have wakeup capability in OMAP3.
>>> >> + */
>>> >> +cam_state = pwrdm_read_pwrst(cam_pd);
>>> >> +if (cam_state == PWRDM_POWER_ON) {
>>> >> +new_state = dev->safe_state;
>>> >> +goto select_state;
>>> >> }
>>> >>
>>> >> +/*
>>> >> + * Prevent PER off if CORE is not in retention or off as this
>>> >> + * would disable PER wakeups completely.
>>> >> + */
>>> >> +per_next_state = per_saved_state =
>>> >> pwrdm_read_next_pwrst(per_pd);
>>> >> +if ((per_next_state == PWRDM_POWER_OFF) &&
>>> >> +(core_next_state > PWRDM_POWER_RET)) {
>>> >> +per_next_state = PWRDM_POWER_RET;
>>> >> +pwrdm_set_next_pwrst(per_pd, per_next_state);
>>> >> +}
>>> >> +
>>> >> +/* Are we changing PER target state? */
>>> >> +if (per_next_state != per_saved_state)
>>> >> +pwrdm_set_next_pwrst(per_pd, per_next_state);
>>> >
>>> > In this case, the PER / CORE constraints don't have anything to do with
>>> > the MPU or CPUIdle, so they don't seem to belong in the CPUIdle code.
>>> > The
>>> > extra comments are certainly nice -- they make it more clear as to what
>>> > is
>>> > going on here -- but maybe those can just be added to pm34xx.c ?
>>>
>>> CPUidle currently manages MPU and CORE powerdomains, so the CORE
>>> constraints seem to make perfect sense here (at least to me.)
>>
>> I do mean CORE also -- basically, anything that is not the CPU. IMHO
>> CPUIdle shouldn't manage CORE directly since it's not part of the CPU.
>> Also since OMAPs have other processors (e.g., DSP, DMA, etc) that can use
>> the CORE independently of the CPU's power state, it doesn't make sense for
>> that code to live inside CPUIdle -- probably it should live in some type
>> of SystemIdle, CORE powerdomain idle or L3 idle. Again IMHO, the C states
>> should only represent the MPU's idle state.
>>
>>> The question is probably more about the PER constraints.
>>>
>>> The basic goal of this is to streamline the core idle (omap_sram_idle())
>>> to be the minimum streamline idle, and to move all the constraint
>>> checking and activity checking to higher layers (like CPUidle.)
>>> Specifically, I'm working towards moving the device-specific idle
>>> constraints out of the core idle path (omap_sram_idle()) and move them
>>> into higher layers where we're checking for activity etc.
>>>
>>> This is just a baby step towards moving the device-idle out of CPUidle
>>> completely to a place where it can be managed by the driver themeselves
>>> using runtime PM or by using constraints instead of these hard-coded
>>> hacks.
>>
>> I agree completely with the goal; it's the implementation that I don't
>> like ;-) But if you agree with the basic idea, that CORE / PER /
>> whatever-idle should ultimately go elsewhere, since I don't have time to
>> come up with a constructive alternative at the moment, would you be
>> willing to just drop a FIXME comment in that code, near the CAM and the
>> PER / CORE stuff, that mentions that that code should ultimately be
>> segmented out into its own idle code?
>
> Absolutely... will do.
>
Here's an updated patch, which will be included in the forthcoming
pm-next pull request. I updat
RE: [RFC] omap: mailbox: fix detection for previously supported chips
Ramirez Luna, Omar wrote:
> Fix the mailbox support detection for OMAP3630, 3530/25 and 2430.
>
> Signed-off-by: Omar Ramirez Luna
> ---
> - Testing was made under 3630 and 3430 boards.
> - Given that 2430 uses similar initialization than OMAP3, changes
> to handle this case was added to the patch.
> - HWMOD adaptation hopefully should solve this mess, but as of now
> mailbox should work as before at least.
>
> arch/arm/mach-omap2/mailbox.c | 12
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mailbox.c
> b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..26d6fb0 100644 ---
> a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c
> @@ -394,15 +394,19 @@ static int __devinit omap2_mbox_probe(struct
> platform_device *pdev)
>
> if (false)
> ;
> -#if defined(CONFIG_ARCH_OMAP3430)
> - else if (cpu_is_omap3430()) {
> +#if defined(CONFIG_ARCH_OMAP3)
> + else if (omap3_has_iva()) {
Hmm, seems omap3_has_ ##feat are only available for built-in and not module
configurations, this patch is not so good after all since it throws:
ERROR: "omap3_features" [arch/arm/mach-omap2/mailbox_mach.ko] undefined!
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
runtime_pm_get_sync() from ISR with IRQs disabled?
Hello, Looking for advice for a little runtime PM dilemma... After some inactivity, a driver decides to supend iteslf using pm_runtime_put_sync(). The device is now suspended, it's ->runtime_suspend() method has disabled its clock, so its registers cannot be accessed anymore. Now, as interrupts are still enabled, an interrupt for this device might still arrive. For example, if this device is a wakeup source, its ->runtime_suspend() method may not have masked its interrupt. So, the IRQ fires, and the drivers ISR is called. The driver wants to access the device registers, but since it has been runtime suspended, it's registers are not available. The first reflex would be to simply do a pm_runtime_get_sync() in the ISR, however this is not safe if the ISR is an IRQs-disabled handler (as is the case for me, where the problematic handler is chained handler used for demuxing GPIO IRQs.) So, what is the "right" thing to do here? A quick hack would be to for the drivers ISR to do a pm_runtime_get_noresume() and directly call the its ->runtime_resume() method, then do its normal stuff, followed by a pm_runtime_put() at the end of the ISR. Is this an acceptable hack given that it's only needed for the increasingly rare cases of ISRs with interrupts disabled? Or should we think of making a version of _get_sync() that is safe for IRQs disabled contexts like this where we know the device is already RPM_SUSPENDED? Any advice appreciated... 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 v2 5/6] OMAP1: Amstrad Delta: add support for camera
Friday 24 September 2010 01:26:17 Tony Lindgren napisał(a): > * Tony Lindgren [100923 16:06]: > > * Janusz Krzysztofik [100910 18:20]: > > > This patch adds configuration data and initialization code required for > > > camera support to the Amstrad Delta board. > > > > > > Three devices are declared: SoC camera, OMAP1 camera interface and > > > OV6650 sensor. > > > > > > Default 12MHz clock has been selected for driving the sensor. Pixel > > > clock has been limited to get reasonable frame rates, not exceeding the > > > board capabilities. Since both devices (interface and sensor) support > > > both pixel clock polarities, decision on polarity selection has been > > > left to drivers. Interface GPIO line has been found not functional, > > > thus not configured. > > > > > > Created and tested against linux-2.6.36-rc3. > > > > > > Works on top of previous patches from the series, at least 1/6, 2/6 and > > > 3/6. > > > > Queuing these last two patches of the series (5/6 and 6/6) for the > > upcoming merge window. > > BTW, these still depend on updated 2/6 to make compile happy. Not so simple: still depends on struct omap1_cam_platform_data definition from , included from . Are you ready to accept another temporary workaround? Thanks, Janusz > > 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 -- To unsubscribe from this list: send the line "unsubscribe 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: [RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
* Janusz Krzysztofik [100923 16:37]: > Friday 24 September 2010 01:23:10 Tony Lindgren napisał(a): > > > > I think you can just move the OMAP1_CAMERA_IOSIZE to the devices.c or > > someplace like that? > > Tony, > Not exactly. I use the OMAP1_CAMERA_IOSIZE inside the driver when reserving > space for register cache. > > I think that I could just duplicate its definition in the devices.c for now, > than clean things up with a folloup patch when both parts already get merged. > Would this be acceptable? Yeah, that sounds good to me. 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 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
Kevin Hilman writes: [...] >> >> We cannot do a get_sync() from ISR context, right? > > Right, but we *should* be able to. ;) > > I'm still trying to craft a good description of this problem so I can > argue better for it on linux-pm. > > Until then... > > A bit of a hack, but you could do a _get_noresume() (which is safe from > interrupt context) and directly call the drivers ->runtime_resume() > method, which would be the equivalent of a _get_sync(). Followed of > course by a _put() (async version, also interrupt safe) at the end of > the ISR to keep the usecount correct. You probably figured this out already, but I just realized that this won't currently work either as omap_hwmod is using mutexes, and is safe in ISR context either. :( What about for now just directly enabling (and re-disabling) the hwmod clocks in the ISR using omap_hwmod_[enable|disable]_clocks() Since this is a core driver in arch/arm/*omap*, you can directly call the omap_hwmod API. 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 03/10] OMAP3: PM: move device-specific special cases from PM core into CPUidle
Paul Walmsley writes:
> Hi Kevin
>
> On Tue, 21 Sep 2010, Kevin Hilman wrote:
>
>> Paul Walmsley writes:
>>
>> > On Wed, 15 Sep 2010, Kevin Hilman wrote:
>> >
>> >> In an effort to simplify the core idle path, move any device-specific
>> >> special case handling from the core PM idle path into the CPUidle
>> >> pre-idle checking path.
>> >
>> > As with the original patch, I don't quite understand the improvement
>> > here. In particular, this part:
>> >
>> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>> >> b/arch/arm/mach-omap2/cpuidle34xx.c
>> >> index 3d3d035..0923b82 100644
>> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> >> @@ -233,14 +234,54 @@ static int omap3_enter_idle_bm(struct
>> >> cpuidle_device *dev,
>> >> struct cpuidle_state *state)
>> >> {
>> >> struct cpuidle_state *new_state = next_valid_state(dev, state);
>> >> + u32 core_next_state, per_next_state = 0, per_saved_state = 0;
>> >> + u32 cam_state;
>> >> + struct omap3_processor_cx *cx;
>> >> + int ret;
>> >>
>> >> if ((state->flags & CPUIDLE_FLAG_CHECK_BM) && omap3_idle_bm_check()) {
>> >> BUG_ON(!dev->safe_state);
>> >> new_state = dev->safe_state;
>> >> + goto select_state;
>> >> + }
>> >> +
>> >> + cx = cpuidle_get_statedata(state);
>> >> + core_next_state = cx->core_state;
>> >> +
>> >> + /*
>> >> + * Prevent idle completely if CAM is active.
>> >> + * CAM does not have wakeup capability in OMAP3.
>> >> + */
>> >> + cam_state = pwrdm_read_pwrst(cam_pd);
>> >> + if (cam_state == PWRDM_POWER_ON) {
>> >> + new_state = dev->safe_state;
>> >> + goto select_state;
>> >> }
>> >>
>> >> + /*
>> >> + * Prevent PER off if CORE is not in retention or off as this
>> >> + * would disable PER wakeups completely.
>> >> + */
>> >> + per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
>> >> + if ((per_next_state == PWRDM_POWER_OFF) &&
>> >> + (core_next_state > PWRDM_POWER_RET)) {
>> >> + per_next_state = PWRDM_POWER_RET;
>> >> + pwrdm_set_next_pwrst(per_pd, per_next_state);
>> >> + }
>> >> +
>> >> + /* Are we changing PER target state? */
>> >> + if (per_next_state != per_saved_state)
>> >> + pwrdm_set_next_pwrst(per_pd, per_next_state);
>> >
>> > In this case, the PER / CORE constraints don't have anything to do with
>> > the MPU or CPUIdle, so they don't seem to belong in the CPUIdle code. The
>> > extra comments are certainly nice -- they make it more clear as to what is
>> > going on here -- but maybe those can just be added to pm34xx.c ?
>>
>> CPUidle currently manages MPU and CORE powerdomains, so the CORE
>> constraints seem to make perfect sense here (at least to me.)
>
> I do mean CORE also -- basically, anything that is not the CPU. IMHO
> CPUIdle shouldn't manage CORE directly since it's not part of the CPU.
> Also since OMAPs have other processors (e.g., DSP, DMA, etc) that can use
> the CORE independently of the CPU's power state, it doesn't make sense for
> that code to live inside CPUIdle -- probably it should live in some type
> of SystemIdle, CORE powerdomain idle or L3 idle. Again IMHO, the C states
> should only represent the MPU's idle state.
>
>> The question is probably more about the PER constraints.
>>
>> The basic goal of this is to streamline the core idle (omap_sram_idle())
>> to be the minimum streamline idle, and to move all the constraint
>> checking and activity checking to higher layers (like CPUidle.)
>> Specifically, I'm working towards moving the device-specific idle
>> constraints out of the core idle path (omap_sram_idle()) and move them
>> into higher layers where we're checking for activity etc.
>>
>> This is just a baby step towards moving the device-idle out of CPUidle
>> completely to a place where it can be managed by the driver themeselves
>> using runtime PM or by using constraints instead of these hard-coded
>> hacks.
>
> I agree completely with the goal; it's the implementation that I don't
> like ;-) But if you agree with the basic idea, that CORE / PER /
> whatever-idle should ultimately go elsewhere, since I don't have time to
> come up with a constructive alternative at the moment, would you be
> willing to just drop a FIXME comment in that code, near the CAM and the
> PER / CORE stuff, that mentions that that code should ultimately be
> segmented out into its own idle code?
Absolutely... will do.
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: [RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
Friday 24 September 2010 01:23:10 Tony Lindgren napisał(a): > * Janusz Krzysztofik [100910 18:26]: > > This patch adds support for SoC camera interface to OMAP1 devices. > > > > Created and tested against linux-2.6.36-rc3 on Amstrad Delta. > > > > For successfull compilation, requires a header file provided by PATCH 1/6 > > from this series, "SoC Camera: add driver for OMAP1 camera interface". > > > > > diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h > > linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h > > --- > > linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h > > 2010-09-0 > >3 22:34:03.0 +0200 +++ > > linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h 2010-09-09 > > 18:42:30.0 +0200 @@ -0,0 +1,8 @@ > > +#ifndef __ASM_ARCH_CAMERA_H_ > > +#define __ASM_ARCH_CAMERA_H_ > > + > > +#include > > + > > +extern void omap1_set_camera_info(struct omap1_cam_platform_data *); > > + > > +#endif /* __ASM_ARCH_CAMERA_H_ */ > > Care to refresh this patch so it does not include media/omap1_camera.h? > > That way things keep building if I merge this one along with the omap > patches and the drivers/media patches can get merged their via media. > > I think you can just move the OMAP1_CAMERA_IOSIZE to the devices.c or > someplace like that? Tony, Not exactly. I use the OMAP1_CAMERA_IOSIZE inside the driver when reserving space for register cache. I think that I could just duplicate its definition in the devices.c for now, than clean things up with a folloup patch when both parts already get merged. Would this be acceptable? Thanks, Janusz > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/6] OMAP1: Amstrad Delta: add support for camera
* Tony Lindgren [100923 16:06]: > * Janusz Krzysztofik [100910 18:20]: > > This patch adds configuration data and initialization code required for > > camera > > support to the Amstrad Delta board. > > > > Three devices are declared: SoC camera, OMAP1 camera interface and OV6650 > > sensor. > > > > Default 12MHz clock has been selected for driving the sensor. Pixel clock > > has > > been limited to get reasonable frame rates, not exceeding the board > > capabilities. Since both devices (interface and sensor) support both pixel > > clock polarities, decision on polarity selection has been left to drivers. > > Interface GPIO line has been found not functional, thus not configured. > > > > Created and tested against linux-2.6.36-rc3. > > > > Works on top of previous patches from the series, at least 1/6, 2/6 and 3/6. > > Queuing these last two patches of the series (5/6 and 6/6) for the upcoming > merge window. BTW, these still depend on updated 2/6 to make compile happy. 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 03/10] OMAP3: PM: move device-specific special cases from PM core into CPUidle
Hi Kevin
On Tue, 21 Sep 2010, Kevin Hilman wrote:
> Paul Walmsley writes:
>
> > On Wed, 15 Sep 2010, Kevin Hilman wrote:
> >
> >> In an effort to simplify the core idle path, move any device-specific
> >> special case handling from the core PM idle path into the CPUidle
> >> pre-idle checking path.
> >
> > As with the original patch, I don't quite understand the improvement
> > here. In particular, this part:
> >
> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> >> b/arch/arm/mach-omap2/cpuidle34xx.c
> >> index 3d3d035..0923b82 100644
> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> >> @@ -233,14 +234,54 @@ static int omap3_enter_idle_bm(struct cpuidle_device
> >> *dev,
> >> struct cpuidle_state *state)
> >> {
> >>struct cpuidle_state *new_state = next_valid_state(dev, state);
> >> + u32 core_next_state, per_next_state = 0, per_saved_state = 0;
> >> + u32 cam_state;
> >> + struct omap3_processor_cx *cx;
> >> + int ret;
> >>
> >>if ((state->flags & CPUIDLE_FLAG_CHECK_BM) && omap3_idle_bm_check()) {
> >>BUG_ON(!dev->safe_state);
> >>new_state = dev->safe_state;
> >> + goto select_state;
> >> + }
> >> +
> >> + cx = cpuidle_get_statedata(state);
> >> + core_next_state = cx->core_state;
> >> +
> >> + /*
> >> + * Prevent idle completely if CAM is active.
> >> + * CAM does not have wakeup capability in OMAP3.
> >> + */
> >> + cam_state = pwrdm_read_pwrst(cam_pd);
> >> + if (cam_state == PWRDM_POWER_ON) {
> >> + new_state = dev->safe_state;
> >> + goto select_state;
> >>}
> >>
> >> + /*
> >> + * Prevent PER off if CORE is not in retention or off as this
> >> + * would disable PER wakeups completely.
> >> + */
> >> + per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
> >> + if ((per_next_state == PWRDM_POWER_OFF) &&
> >> + (core_next_state > PWRDM_POWER_RET)) {
> >> + per_next_state = PWRDM_POWER_RET;
> >> + pwrdm_set_next_pwrst(per_pd, per_next_state);
> >> + }
> >> +
> >> + /* Are we changing PER target state? */
> >> + if (per_next_state != per_saved_state)
> >> + pwrdm_set_next_pwrst(per_pd, per_next_state);
> >
> > In this case, the PER / CORE constraints don't have anything to do with
> > the MPU or CPUIdle, so they don't seem to belong in the CPUIdle code. The
> > extra comments are certainly nice -- they make it more clear as to what is
> > going on here -- but maybe those can just be added to pm34xx.c ?
>
> CPUidle currently manages MPU and CORE powerdomains, so the CORE
> constraints seem to make perfect sense here (at least to me.)
I do mean CORE also -- basically, anything that is not the CPU. IMHO
CPUIdle shouldn't manage CORE directly since it's not part of the CPU.
Also since OMAPs have other processors (e.g., DSP, DMA, etc) that can use
the CORE independently of the CPU's power state, it doesn't make sense for
that code to live inside CPUIdle -- probably it should live in some type
of SystemIdle, CORE powerdomain idle or L3 idle. Again IMHO, the C states
should only represent the MPU's idle state.
> The question is probably more about the PER constraints.
>
> The basic goal of this is to streamline the core idle (omap_sram_idle())
> to be the minimum streamline idle, and to move all the constraint
> checking and activity checking to higher layers (like CPUidle.)
> Specifically, I'm working towards moving the device-specific idle
> constraints out of the core idle path (omap_sram_idle()) and move them
> into higher layers where we're checking for activity etc.
>
> This is just a baby step towards moving the device-idle out of CPUidle
> completely to a place where it can be managed by the driver themeselves
> using runtime PM or by using constraints instead of these hard-coded
> hacks.
I agree completely with the goal; it's the implementation that I don't
like ;-) But if you agree with the basic idea, that CORE / PER /
whatever-idle should ultimately go elsewhere, since I don't have time to
come up with a constructive alternative at the moment, would you be
willing to just drop a FIXME comment in that code, near the CAM and the
PER / CORE stuff, that mentions that that code should ultimately be
segmented out into its own idle code?
thanks
- Paul
--
To unsubscribe from this list: send the line "unsubscribe 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: [RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
* Janusz Krzysztofik [100910 18:26]: > This patch adds support for SoC camera interface to OMAP1 devices. > > Created and tested against linux-2.6.36-rc3 on Amstrad Delta. > > For successfull compilation, requires a header file provided by PATCH 1/6 > from > this series, "SoC Camera: add driver for OMAP1 camera interface". > diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h > linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h > --- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h > 2010-09-03 22:34:03.0 +0200 > +++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h > 2010-09-09 18:42:30.0 +0200 > @@ -0,0 +1,8 @@ > +#ifndef __ASM_ARCH_CAMERA_H_ > +#define __ASM_ARCH_CAMERA_H_ > + > +#include > + > +extern void omap1_set_camera_info(struct omap1_cam_platform_data *); > + > +#endif /* __ASM_ARCH_CAMERA_H_ */ Care to refresh this patch so it does not include media/omap1_camera.h? That way things keep building if I merge this one along with the omap patches and the drivers/media patches can get merged their via media. I think you can just move the OMAP1_CAMERA_IOSIZE to the devices.c or someplace like that? 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 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
"Basak, Partha" writes:
>
>
>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> Sent: Thursday, September 23, 2010 9:08 PM
>> To: Basak, Partha
>> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Tero Kristo
>> Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of
>> interrupts-disabled idle path
>>
>> "Basak, Partha" writes:
>>
>> >
>> >
>> >> -Original Message-
>> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> >> Sent: Tuesday, September 14, 2010 10:28 PM
>> >> To: Basak, Partha
>> >> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha;
>> Tero Kristo
>> >> Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of
>> >> interrupts-disabled idle path
>> >>
>> >> "Basak, Partha" writes:
>> >>
>> >> >> From: Kevin Hilman
>> >> >>
>> >> >> Currently, we wait until late in the idle path where
>> interrupts are
>> >> >> disabled to do runtime-PM-like management for certain
>> special-case
>> >> >> devices like GPIO.
>> >> >>
>> >> >> As a prerequiste to moving GPIO to the new runtime PM
>> >> framework, move
>> >> >> this runtime-PM-like code out of the late idle path
>> into new device
>> >> >> idle and resume functions that can be called before
>> interrupts are
>> >> >> disabled by CPUidle and/or suspend.
>> >> >>
>> >> >> In addition, move all the GPIO-specific logic into the GPIO core
>> >> >> instead of keeping GPIO-specific knowledge of
>> power-states, context
>> >> >> saving etc. in the PM core.
>> >> >>
>> >> >> Also, call the new device-idle and -resume methods from
>> CPUidle and
>> >> >> static suspend path.
>> >> >>
>> >> >> Signed-off-by: Kevin Hilman
>> >> >> ---
>> >> >> arch/arm/mach-omap2/cpuidle34xx.c |4 ++
>> >> >> arch/arm/mach-omap2/pm.h |2 +
>> >> >> arch/arm/mach-omap2/pm24xx.c |2 +-
>> >> >> arch/arm/mach-omap2/pm34xx.c | 38
>> >> +
>> >> >> arch/arm/plat-omap/gpio.c | 57
>> >> >>
>> >> >> arch/arm/plat-omap/include/plat/gpio.h |4 +--
>> >> >> 6 files changed, 67 insertions(+), 40 deletions(-)
>> >> >>
>> >> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>> >> >> b/arch/arm/mach-omap2/cpuidle34xx.c
>> >> >> index 0923b82..681d823 100644
>> >> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> >> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> >> >> @@ -274,9 +274,13 @@ static int omap3_enter_idle_bm(struct
>> >> >> cpuidle_device *dev,
>> >> >>pwrdm_set_next_pwrst(per_pd, per_next_state);
>> >> >>
>> >> >> select_state:
>> >> >> + omap3_device_idle();
>> >> >> +
>> >> >>dev->last_state = new_state;
>> >> >>ret = omap3_enter_idle(dev, new_state);
>> >> >>
>> >> >> + omap3_device_resume();
>> >> >> +
>> >> > In the generic cpu_idle() in process.c, interrupts are
>> >> already disabled
>> >> > before control comes to cpuidle_idle_call() via pm_idle()
>> >> > local_irq_disable();
>> >> > if (hlt_counter) {
>> >> > local_irq_enable();
>> >> > cpu_relax();
>> >> > } else {
>> >> > stop_critical_timings();
>> >> > pm_idle();
>> >> > start_critical_timings();
>> >> > /*
>> >> > * This will eventually be
>> >> removed - pm_idle
>> >> > * functions should always
>> >> return with IRQs
>> >> > * enabled.
>> >> > */
>> >> > WARN_ON(irqs_disabled());
>> >> > local_irq_enable();
>> >> > }
>> >> >
>> >> > omap3_enter_idle_bm() will be called from inside
>> >> cpuidle_idle_call()
>> >> > via target_state->enter(dev, target_state).
>> >> > So, interrupts are already disabled here.
>> >> >
>> >> > Am I missing something?
>> >>
>> >> You're right.
>> >>
>> >> I knew this was the case for !CPUIDLE setup, but had
>> thought (without
>> >> testing) that the CPUidle core had re-enabled interrupts during the
>> >> governor selection process etc.
>> >>
>> >> While I investigate ways to manage this in CPUidle, the
>> >> following should
>> >> be fine for now to include with $SUBJECT patch.
>> >>
>> >> Kevin
>> >>
>> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>> >> b/arch/arm/mach-omap2/cpuidle34xx.c
>> >> index 681d823..c5cb9d0 100644
>> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> >> @@ -245,6 +245,14 @@ static int omap3_enter_idle_bm(struct
>> >> cpuidle_device *dev,
>> >> goto select_state;
>> >> }
>> >>
>> >> + /*
>> >> + * Enable IRQs during the device activity
Re: [PATCH v2 5/6] OMAP1: Amstrad Delta: add support for camera
* Janusz Krzysztofik [100910 18:20]: > This patch adds configuration data and initialization code required for > camera > support to the Amstrad Delta board. > > Three devices are declared: SoC camera, OMAP1 camera interface and OV6650 > sensor. > > Default 12MHz clock has been selected for driving the sensor. Pixel clock has > been limited to get reasonable frame rates, not exceeding the board > capabilities. Since both devices (interface and sensor) support both pixel > clock polarities, decision on polarity selection has been left to drivers. > Interface GPIO line has been found not functional, thus not configured. > > Created and tested against linux-2.6.36-rc3. > > Works on top of previous patches from the series, at least 1/6, 2/6 and 3/6. Queuing these last two patches of the series (5/6 and 6/6) for the upcoming merge window. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] omap4: platform changes for CMA3000
* Hemanth V [100907 23:11]: > From 8082870cc704d901d98cf0d6af90e45860927ceb Mon Sep 17 00:00:00 2001 > From: Hemanth V > Date: Thu, 26 Aug 2010 17:49:12 +0530 > Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver > > Update 4430 SDP board file with platform data for accelerometer driver > and select the driver in kconfig > > Signed-off-by: Hemanth V > --- > arch/arm/mach-omap2/Kconfig |2 ++ > arch/arm/mach-omap2/board-4430sdp.c | 30 ++ > 2 files changed, 32 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index a928fd6..e87c049 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -255,6 +255,8 @@ config MACH_OMAP_4430SDP > depends on ARCH_OMAP4 > select INPUT_TOUCHSCREEN > select TOUCHSCREEN_SYNTM12XX > + select INPUT_MISC > + select INPUT_CMA3000_I2C > > config MACH_OMAP4_PANDA > bool "OMAP4 Panda Board" This does not apply, can you please refresh against the current devel-boards branch in the linux-omap tree. I'm getting: patching file arch/arm/mach-omap2/Kconfig Hunk #1 FAILED at 255. 1 out of 1 hunk FAILED -- rejects in file arch/arm/mach-omap2/Kconfig patching file arch/arm/mach-omap2/board-4430sdp.c Hunk #2 FAILED at 46. Hunk #3 succeeded at 441 (offset -46 lines). Hunk #4 succeeded at 479 with fuzz 2 (offset -62 lines). Hunk #5 succeeded at 518 (offset -80 lines). 1 out of 5 hunks FAILED -- rejects in file arch/arm/mach-omap2/board-4430sdp.c Patch apply does not apply (enforce with -f) 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] omap mmc: extended to pass host capabilities from board file
* Sukumar Ghorai [100915 07:41]: > wires variable is renamed, extended and this single variable to be used to > pass the platform capabilities, e.g DDR mode. Also removed the hardcoded > value was using as bus-width. This looks like a nice clean-up, I'll queue this via the omap patches. 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: [GIT PULL] omap2 sparse fixes
* G, Manjunath Kondaiah [100922 01:48]:
> Hi Tony,
>
> Please pull omap2 sparse fixes from:
>
> git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git sparse_fixes
>
> Regards,
> Manjunath
>
>
> The following changes since commit 8b15575cae7a93a784c3005c42b069edd9ba64dd:
> Sage Weil (1):
> fs: {lock,unlock}_flocks() stubs to prepare for BKL removal
>
> are available in the git repository at:
>
> git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git sparse_fixes
>
> G, Manjunath Kondaiah (10):
> OMAP: mach-omap2: Fix incorrect assignment warnings
> OMAP: mach-omap2: Fix static declaration warnings
> OMAP: mach-omap2: Fix static function warnings
> OMAP: mach-omap2: Fix miscellaneous sparse warnings
> OMAP: plat-omap: Fix static function warnings
> OMAP: NAND: Fix static declaration warning
> TWL CORE: Fix sparse warning
> TWL IRQ: Fix fucntion declaration warnings
> OMAP2/3: Convert write/read functions to raw read/write
> OMAP3: Keypad: Fix incorrect type initializer
Manjunath, this looks safe to pull, however one request though:
Can you please rebase it on v2.6.35 or v2.6.36-rc5?
Now your branch is on some commit after the -rc5 tag.
It's better to base branches at the most recent stable tag
(v2.6.35) or a recent -rc tag (v2.6.36-rc5).
Otherwise we end up moving our linux-omap tree forward too unless
I use git pull --rebase option.. I've updated the elinux.org wiki
instructions for that too, sorry if the earlier instructions there
were a bit unclear.
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 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, September 23, 2010 9:08 PM
> To: Basak, Partha
> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Tero Kristo
> Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of
> interrupts-disabled idle path
>
> "Basak, Partha" writes:
>
> >
> >
> >> -Original Message-
> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> >> Sent: Tuesday, September 14, 2010 10:28 PM
> >> To: Basak, Partha
> >> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha;
> Tero Kristo
> >> Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of
> >> interrupts-disabled idle path
> >>
> >> "Basak, Partha" writes:
> >>
> >> >> From: Kevin Hilman
> >> >>
> >> >> Currently, we wait until late in the idle path where
> interrupts are
> >> >> disabled to do runtime-PM-like management for certain
> special-case
> >> >> devices like GPIO.
> >> >>
> >> >> As a prerequiste to moving GPIO to the new runtime PM
> >> framework, move
> >> >> this runtime-PM-like code out of the late idle path
> into new device
> >> >> idle and resume functions that can be called before
> interrupts are
> >> >> disabled by CPUidle and/or suspend.
> >> >>
> >> >> In addition, move all the GPIO-specific logic into the GPIO core
> >> >> instead of keeping GPIO-specific knowledge of
> power-states, context
> >> >> saving etc. in the PM core.
> >> >>
> >> >> Also, call the new device-idle and -resume methods from
> CPUidle and
> >> >> static suspend path.
> >> >>
> >> >> Signed-off-by: Kevin Hilman
> >> >> ---
> >> >> arch/arm/mach-omap2/cpuidle34xx.c |4 ++
> >> >> arch/arm/mach-omap2/pm.h |2 +
> >> >> arch/arm/mach-omap2/pm24xx.c |2 +-
> >> >> arch/arm/mach-omap2/pm34xx.c | 38
> >> +
> >> >> arch/arm/plat-omap/gpio.c | 57
> >> >>
> >> >> arch/arm/plat-omap/include/plat/gpio.h |4 +--
> >> >> 6 files changed, 67 insertions(+), 40 deletions(-)
> >> >>
> >> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> >> >> b/arch/arm/mach-omap2/cpuidle34xx.c
> >> >> index 0923b82..681d823 100644
> >> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> >> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> >> >> @@ -274,9 +274,13 @@ static int omap3_enter_idle_bm(struct
> >> >> cpuidle_device *dev,
> >> >> pwrdm_set_next_pwrst(per_pd, per_next_state);
> >> >>
> >> >> select_state:
> >> >> + omap3_device_idle();
> >> >> +
> >> >> dev->last_state = new_state;
> >> >> ret = omap3_enter_idle(dev, new_state);
> >> >>
> >> >> + omap3_device_resume();
> >> >> +
> >> > In the generic cpu_idle() in process.c, interrupts are
> >> already disabled
> >> > before control comes to cpuidle_idle_call() via pm_idle()
> >> > local_irq_disable();
> >> > if (hlt_counter) {
> >> > local_irq_enable();
> >> > cpu_relax();
> >> > } else {
> >> > stop_critical_timings();
> >> > pm_idle();
> >> > start_critical_timings();
> >> > /*
> >> > * This will eventually be
> >> removed - pm_idle
> >> > * functions should always
> >> return with IRQs
> >> > * enabled.
> >> > */
> >> > WARN_ON(irqs_disabled());
> >> > local_irq_enable();
> >> > }
> >> >
> >> > omap3_enter_idle_bm() will be called from inside
> >> cpuidle_idle_call()
> >> > via target_state->enter(dev, target_state).
> >> > So, interrupts are already disabled here.
> >> >
> >> > Am I missing something?
> >>
> >> You're right.
> >>
> >> I knew this was the case for !CPUIDLE setup, but had
> thought (without
> >> testing) that the CPUidle core had re-enabled interrupts during the
> >> governor selection process etc.
> >>
> >> While I investigate ways to manage this in CPUidle, the
> >> following should
> >> be fine for now to include with $SUBJECT patch.
> >>
> >> Kevin
> >>
> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> >> b/arch/arm/mach-omap2/cpuidle34xx.c
> >> index 681d823..c5cb9d0 100644
> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> >> @@ -245,6 +245,14 @@ static int omap3_enter_idle_bm(struct
> >> cpuidle_device *dev,
> >>goto select_state;
> >>}
> >>
> >> + /*
> >> + * Enable IRQs during the device activity checking and
> >> idle management.
> >> + * IRQs are later (re)disabled when entering the actual
> >> idle function.
> >> + * Device idle management that is using runtime PM needs to have
> >> + * interrupts enabled when calling into the runtime PM core.
Re: [PATCH v2] omap: beagle: add support for wl1271 on the board file
On Thu, 2010-09-23 at 15:42 +0200, ext Robert Nelson wrote: > On Thu, Sep 23, 2010 at 7:52 AM, Luciano Coelho > wrote: > > On Thu, 2010-09-23 at 14:03 +0200, ext Robert Nelson wrote: > >> On Thu, Sep 23, 2010 at 5:30 AM, Grazvydas Ignotas > >> wrote: > >> > On Thu, Sep 23, 2010 at 11:20 AM, Luciano Coelho > >> > wrote: > >> >> Add board configuration for the wl1271 daughter board. This patch is > >> >> based > >> >> on Ohad Ben-Cohen's patches for Zoom boards. > >> > > >> > Hm can that daughter board be detected? With your patch all beagle > >> > users will get GPIO139 toggled, and if someone has that wired to > >> > chainsaw switch somebody might get hurt. > >> > >> Expansion boards really need to follow: > >> > >> http://elinux.org/BeagleBoardPinMux#Expansion_boards > >> > >> Is there any eeprom on i2c bus #2 for identification on this board? > > > > Hmmm... > > > > Yes, it does. :) This makes perfect sense. > > > > My bootloader (U-Boot 2010.03) doesn't seem to detect it, though: > > > > > > Probing for expansion boards, if none are connected you'll see a > > harmless I2C error. > > > > No EEPROM on expansion board > > > > I'd first add the board to the list on the wiki to protect the > expansion board id. Okay, I'll do that. > Here's the current patch for u-boot for these expansion boards, it > only implements id's for the boards listed at the time. > > http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=95993d1fee62ef64b2f58c1e186176ca9033c35e Thanks for the pointer. Now I understand how this works. > > Do I need a special bootloader? > > > > Is there any standard way to recognize the expansion board and configure > > it properly? > > Yeap, you need a special bootloader, which is a downside to the > current implementation... It relies on u-boot to do the i2c probing > and detect which expansion board is connected, it would be nice if the > kernel could do it on it's own.. Is there any technical problem which would prevent this from being done in the kernel? Or is it just legacy and nobody has implemented it properly in the kernel side? > So currently u-boot probes, then notifies the kernel thru a "buddy" > variable that gets passed with the bootargs.. I see. The good thing is that if someone is using a boot loader that is not probing and passing the variable, it can be specified manually in the kernel bootargs. > board-omap3beagle.c then parse's the "buddy" variable to setup the > expansion device, like as shown for the zippy1/2 expansion boards: > > http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/0007-ARM-OMAP-beagleboard-Add-infrastructure-to-do-fixups.patch > > (note there are patches applied before this and after, so it's won't > apply cleanly to mainline) Thanks for this pointer too. I see that the beagle board files are indeed different from what is in the mainline. Any ideas if/when this is going to be integrated into the mainline? -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED]
MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Perl Net::SMTP This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-omap-misc Initial commit ID (Likely to change): 2ce9be1e551d76d5c57c566820e423b87a626ad8 PatchWorks http://patchwork.kernel.org/patch/164051/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2ce9be1e551d76d5c57c566820e423b87a626ad8 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] runtime PM core for OMAP for 2.6.37
Tony, Pull request below to add the runtime PM core for OMAP. Also note that this depends on an additional driver core patch from me that is queued by Greg KH for 2.6.37: driver core: platform_bus: allow runtime override of dev_pm_ops You can find this as commit 441d87898e039c155493c12696a4d7cfd7001b49 in linux-next, or you can cherry-pick it from my pm-backports branch and put it in omap-testing until the final merge. Thanks, Kevin The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c: Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-runtime Kevin Hilman (2): OMAP2+: PM: initial runtime PM core support OMAP1: PM: add simple runtime PM layer to manage clocks arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/pm_bus.c | 98 ++ arch/arm/mach-omap2/Makefile | 10 +++- arch/arm/mach-omap2/pm_bus.c | 85 4 files changed, 191 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-omap1/pm_bus.c create mode 100644 arch/arm/mach-omap2/pm_bus.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2
From: Benoit Cousson
The current version contains only the interconnects and the
mpu hwmods.
The remaining hwmods will be introduced by further patches on
top of this one.
- enable as well omap_hwmod.c build for OMAP4 Soc
Please not that this file uses the new naming convention for
naming HW IPs. This convention will be backported soon for previous
OMAP2 & 3 data files.
new nametrm name
- ---
counter_32k synctimer_32k
l3_main l3
timerX gptimerX / dmtimerX
mmcXmmchsX / sdmmcX
dma_system sdma
smartreflex_X sr_X / sr?
usb_host_fs usbfshost
usb_otg_hs hsusbotg
usb_tll_hs usbtllhs_config
wd_timerX wdtimerX
ipu cortexm3 / ducati
dsp c6x / tesla
iva ivahd / iva2.2
kbd kbdocp / keyboard
mailbox system_mailbox
mpu cortexa9 / chiron
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Rajendra Nayak
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/io.c |7 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 482 ++
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
5 files changed, 489 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_44xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..29d40b2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_ARCH_OMAP2430) += opp2430_data.o
obj-$(CONFIG_ARCH_OMAP2420)+= omap_hwmod_2420_data.o
obj-$(CONFIG_ARCH_OMAP2430)+= omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
+obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU)+= emu.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b9ea70b..490d870 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -323,6 +323,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap2430_hwmod_init();
else if (cpu_is_omap34xx())
omap3xxx_hwmod_init();
+ else if (cpu_is_omap44xx())
+ omap44xx_hwmod_init();
+
/* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
@@ -342,9 +345,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
#ifndef CONFIG_PM_RUNTIME
skip_setup_idle = 1;
#endif
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
- omap_hwmod_late_init(skip_setup_idle);
-
+ omap_hwmod_late_init(skip_setup_idle);
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
new file mode 100644
index 000..e20b0ee
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -0,0 +1,482 @@
+/*
+ * Hardware modules present on the OMAP44xx chips
+ *
+ * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2009-2010 Nokia Corporation
+ *
+ * Paul Walmsley
+ * Benoit Cousson
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap@vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include
+#include
+
+#include "omap_hwmod_common_data.h"
+
+#include "cm.h"
+#include "prm-regbits-44xx.h"
+
+/* Base offset for all OMAP4 interrupts external to MPUSS */
+#define OMAP44XX_IRQ_GIC_START 32
+
+/* Base offset for all OMAP4 dma requests */
+#define OMAP44XX_DMA_REQ_START 1
+
+/* Backward references (IPs with Bus Master capability) */
+static struct omap_hwmod omap44xx_dmm_hwmod;
+static struct omap_hwmod omap44xx_emif_fw_hwmod;
+static struct omap_hwmod omap44xx_l3_instr_hwmod;
+static struct omap_hwmod omap44xx_l3_main_1_hwmod;
+static struct omap_hwmod omap44xx_l3_main_2_hwmod;
+static struct omap_hwmod omap44xx_l3_main_3_hwmod;
+static struct omap_hwmod omap44xx_l4_abe_hwmod;
+static struct omap_hwmod omap44xx_l4_cfg_hwmod;
+static struct omap_hwmod omap44xx_l4_per_hwmod;
+static struct omap_hwmod omap44xx_l4_wkup_hwmod;
+static struct omap_hwmod omap44xx_mpu_hwmod;
+static struct omap_hwmod omap44xx_mpu_privat
[PATCH 2/3] OMAP4: pm: Change l3_main to l3_main_1 during bus device init
From: Benoit Cousson
The OMAP4 L3 interconnect is split in 3 part for power saving reason.
Because of that there is no l3_main like on OMAP2 & 3 but 3 differentes
l3_main_X instances.
In the case of OMAP4, query only the l3_main_1 part. The clock and
voltage are shared across the 3 instances.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 4477d5d..59ca03b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -81,9 +81,12 @@ static void omap2_init_processor_devices(void)
{
_init_omap_device("mpu", &mpu_dev);
_init_omap_device("iva", &iva_dev);
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
+ _init_omap_device("l3_main_1", &l3_dev);
_init_omap_device("dsp", &dsp_dev);
- _init_omap_device("l3_main", &l3_dev);
+ } else {
+ _init_omap_device("l3_main", &l3_dev);
+ }
}
/*
--
1.7.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAP: GPIO: ensure debounce clocks are disabled during idle/suspend
If a GPIO bank has more than one GPIO with debounce enabled, the
debounce clock will not be fully disabled before going to
idle/suspend.
In the idle path, we just do a single clk_disable() of the bank's
debounce clock. If there are multiple debounce-enabled GPIOs in the
bank, that clocks usage count will be > 1, so the clk_disable() will
not actually disable the clock.
So the fix is to clk_disable() for every debounce-enabled GPIO in the
bank (and an equivalent clk_enable() of course.)
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/gpio.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 7951eef..11c5b0e 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2085,8 +2085,9 @@ void omap2_gpio_prepare_for_idle(int power_state)
for (i = min; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
u32 l1, l2;
+ int j;
- if (bank->dbck_enable_mask)
+ for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
clk_disable(bank->dbck);
if (power_state > PWRDM_POWER_OFF)
@@ -2152,8 +2153,9 @@ void omap2_gpio_resume_after_idle(void)
for (i = min; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
u32 l, gen, gen0, gen1;
+ int j;
- if (bank->dbck_enable_mask)
+ for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
clk_enable(bank->dbck);
if (!workaround_enabled)
--
1.7.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAP: pm-next: few more PM updates for 2.6.37
Here area few more PM updates targetted for 2.6.37. These are added to the pm-next brach available here: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-next Benoit Cousson (2): OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2 OMAP4: pm: Change l3_main to l3_main_1 during bus device init Kevin Hilman (1): OMAP: GPIO: ensure debounce clocks are disabled during idle/suspend arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/io.c |7 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 482 ++ arch/arm/mach-omap2/pm.c |7 +- arch/arm/plat-omap/Makefile |2 +- arch/arm/plat-omap/gpio.c|6 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + 7 files changed, 498 insertions(+), 8 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- 1.7.2.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] omap4: board-omap4panda: adding leds status1 and status2
* Ricardo Salveti de Araujo [100906 14:55]: > At Pandaboard we have 2 status leds, so adding them with similar usage as > we have for Beagleboard (heartbeat and mmc0). The patch basically adds the > platform data required by leds-gpio driver. Adding this, 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
[PATCH] OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
OMAP USBOTG module has a requirement to set the autoidle bit only after
setting smartidle bit. Modified the _sys_enable api to set the smartidle
first and then the autoidle bit. Setting this will not have any impact on the
other modules.
Signed-off-by: Hema HK
Signed-off-by: Basak, Partha
Cc: Felipe Balbi
Cc: Tony Lindgren
Cc: Kevin Hilman
Cc: Cousson, Benoit
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/omap_hwmod.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/omap_hwmod.c
+++ linux-omap-pm/arch/arm/mach-omap2/omap_hwmod.c
@@ -654,12 +654,6 @@ static void _sysc_enable(struct omap_hwm
_set_master_standbymode(oh, idlemode, &v);
}
- if (sf & SYSC_HAS_AUTOIDLE) {
- idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
- 0 : 1;
- _set_module_autoidle(oh, idlemode, &v);
- }
-
/* XXX OCP ENAWAKEUP bit? */
/*
@@ -672,6 +666,18 @@ static void _sysc_enable(struct omap_hwm
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
_write_sysconfig(v, oh);
+
+ /*
+* Set the autoidle bit only after setting the smartidle bit
+* as this is requirement for some modules like USBOTG.
+* Setting this will not have any impact on the other modules.
+*/
+ if (sf & SYSC_HAS_AUTOIDLE) {
+ idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
+ 0 : 1;
+ _set_module_autoidle(oh, idlemode, &v);
+ _write_sysconfig(v, oh);
+ }
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: 4430sdp board support for proximity sensor
* Shubhrajyoti D [100831 23:09]: > omap 4430sdp board support for the proximity sensor via GPIO keys. > The proximity sensor is connected to GPIO and is registered as a > GPIO key. > - Making the default state of the sensor off at bootup > - The init is called before platform_add_devices Adding this, 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
[APPLIED] [PATCH 2/2] omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-omap-misc Initial commit ID (Likely to change): 02c63d25237f1485c488d849edc13b67a23d3310 PatchWorks http://patchwork.kernel.org/patch/144841/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=02c63d25237f1485c488d849edc13b67a23d3310 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] OMAP: McBSP: Do not enable SRG in slave mode
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-omap-misc Initial commit ID (Likely to change): d0db27786b9fabeac6cb330ccf127451c249af73 PatchWorks http://patchwork.kernel.org/patch/144621/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=d0db27786b9fabeac6cb330ccf127451c249af73 -- To unsubscribe from this list: send the line "unsubscribe 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: SYS_OFF_MODE signaling and CORE domain Transition to OFF Mode
Laine Walker-Avina writes: > I'm having some troubles putting my OMAP3503(the one without the DSP > or SGX modules) board to sleep. I'm using the current master on the > l-o git repository. Looks like you're wanting to use off-mode. There are many drivers that do not yet support off mode, as they need to do context save/restore in their suspend/resume paths in order to support off mode. In particular, MMC in l-o master does not yet have this support, so you should not expect MMC to work after an off mode transition. This is why off-mode is disabled by default, it has to be manually enabled by: echo 1 > /debug/pm_debug/enable_off_mode. Do things work as expected if you leave off-mode disabled? > This is the output from dmesg and the count file after suspending > twice. The first time it wakes immediately after going down, and the > second time stays asleep but says that the core domain didn't enter > OFF mode. This is not easy to debug with the current kernel dump. The way I suggest debugging this is by first getting to a minimal kernel that can suspend/resume as you expect. Then you add in the drivers to see which one is causing the problem, or keeping the system away. Clearly the MMC driver has some problems in it's suspend/resume hooks with unbalanced regulator enable/disables, so for starters, I'd suggest disabling MMC. I'd also suggest disabling musb, but basically the best way is to disable everything except a minimal kernel, and then work back up to the config you want. You might try using my PM branch (link below) which comes with a minimal kernel config for this purpose: omap3_pm_defconfig. > In either case, the SYS_OFF_MODE signal never asserts. I added some > debug code into map_sram_idle() to capture CM_CORE_IDLEST1 and 3 right > before it jumps to the final sleep code in SRAM. For looking at the idlest regs, you might want to try the patch from my pm-debug branch (included in my pm branch) which takes a snapshot of all the PM registers just before SRAM idle and right after resume. You can then see the registers using debugfs. This is documented on the OMAP PM wiki: http://elinux.org/OMAP_Power_Management Hope that helps a little, 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 7/7] omap3: make coresight register save across OFF modes a sysfs option
* Cousson, Benoit [100904 01:49]: > > These patches are still using static virtual to physical mapping in > io.h, shouldn't we take the opportunity of this series to fix that > and use ioremap instead? Hmm, well the amba device should ioremap, but we need the virt address for sleep34xx.S also. So to me it seems like we're missing the static ioremap entries for plat-omap/io.c for the virtual addresses. Alexander, can you please check that and repost the remaining three patches one more time? 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 9/9 v3] usb : musb: Offmode fix for idle path
"Kalliguddi, Hema" writes:
[...]
static u64 musb_dmamask = DMA_BIT_MASK(32);
@@ -80,6 +89,7 @@ void __init usb_musb_init(struct omap_mu
const char *oh_name = "usb_otg_hs";
struct musb_hdrc_platform_data *pdata;
+ core_pwrdm = pwrdm_lookup("per_pwrdm");
>>>
>>>per or core ???
>>>
>>Oh! It should be core. Now I understand why save/restore
>>counts were not matching with
>>Core-off counts.
>>Thanks for pointing this out.
>
> If I call pm_runtime_put_sync and pm_runtime_get_sync based on the core
> domain state then
> the USB connect/reset interrupt is not triggered once the core hits off.
>
> In omap3_enter_idle_bm() there is no core next state being programmed to PRCM
> register,
>
> but the drivers functions which are called from omap3_device_idle are suppose
> to read the
> core next state from the PRCM register.
> I am missing something here?
Ah, this is indeed a big problem. Good catch.
Both the CORE and MPU states are programmed in omap3_enter_idle(), but
that doesn't happen until after omap3_device_idle(). hmmm
> If I use the per_pwrdm states to save the context and restore everything
> works fine.
Yes, because PER is programmed in omap3_enter_idle_bm() so it's
available already in the registers.
I've updated my "idle reorg" series which creates omap3_device_idle &
_resume (and enables interrupts in CPUidle.) I updated it to
not call omap3_device_idle until the MPU & CORE registers are
programmed (diff below.) This is in my pm-wip/idle-reorg branch, which
is based on pm-core.
Thanks,
Kevin
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index cf4207f..51fef17 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -125,14 +125,16 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
current_cx_state = *cx;
- /* Used to keep track of the total time in idle */
- getnstimeofday(&ts_preidle);
+ pwrdm_set_next_pwrst(mpu_pd, mpu_state);
+ pwrdm_set_next_pwrst(core_pd, core_state);
+
+ omap3_device_idle();
local_irq_disable();
local_fiq_disable();
- pwrdm_set_next_pwrst(mpu_pd, mpu_state);
- pwrdm_set_next_pwrst(core_pd, core_state);
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(&ts_preidle);
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
@@ -157,6 +159,8 @@ return_sleep_time:
local_irq_enable();
local_fiq_enable();
+ omap3_device_resume();
+
return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH]omap: i2c: Avoid compilation error in case the header is
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-omap-misc Initial commit ID (Likely to change): 6ce3fc011cdd5b7eb72d0cacb236bbfa51f17dad PatchWorks http://patchwork.kernel.org/patch/127371/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=6ce3fc011cdd5b7eb72d0cacb236bbfa51f17dad -- To unsubscribe from this list: send the line "unsubscribe 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 8/9 v3] usb : musb: Using runtime pm apis for musb.
"Kalliguddi, Hema" writes: > > >>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Thursday, September 23, 2010 9:00 PM >>To: Balbi, Felipe >>Cc: Kalliguddi, Hema; linux-omap@vger.kernel.org; >>linux-...@vger.kernel.org; Basak, Partha; Tony Lindgren; >>Cousson, Benoit; Paul Walmsley >>Subject: Re: [PATCH 8/9 v3] usb : musb: Using runtime pm apis for musb. >> >>Felipe Balbi writes: >> >>> Hi, >>> >>> On Wed, Sep 22, 2010 at 07:30:30PM -0500, Kalliguddi, Hema wrote: Calling runtime pm APIs pm_runtime_put_sync() and >>pm_runtime_get_sync() for enabling/disabling the clocks,sysconfig settings. Also need to put the USB in force standby and force idle >>mode when usb not used and set it back to no idle and no stndby after wakeup. For OMAP3 auto idle bit has to be disabled because of the >>errata.So using HWMOD_NO_OCP_AUTOIDLE flag for OMAP3430. >> >>[...] >> @@ -2424,13 +2425,16 @@ static int musb_suspend(struct device *d * they will even be wakeup-enabled. */ } + pm_runtime_put_sync(dev); +#ifndef CONFIG_PM_RUNTIME musb_save_context(musb); if (musb->set_clock) musb->set_clock(musb->clock, 0); else clk_disable(musb->clock); +#endif >>> >>> I would rather remove these, adding ifdefs is bad :-( Unless >>other archs >>> (blackfin, davinci) would have problems if we remove those. >> >>I didn't like these #ifdefs either, but davinci doesn't have >>runtime PM, >>and I don't think blackfin does either. >> >>But, rather than the ifdef here, this could be done with different >>pointers in struct dev_pm_ops based on the arch. >> >>Also, this shouldn't be based on CONFIG_PM_RUNTIME, but rather on the >>arch. We can still enable runtime PM on davinci for other subsystems >>(PCI, USB core, etc.) but not have it supported for on-chip devices. >> > Is it a good idea to use the musb->set_clock function pointer for OMAP > architure and > call the runtime pm apis from this function defined in the usb platform > driver(omap2430) I guess that's Felipe's call, but I don't like that option. I think it's cleaner to have the ->set_clock hook be a noop on OMAP and the runtime hooks be noops on the other platforms. 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
[APPLIED] [PATCH] Adding i2c eeprom driver to read EDID
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-boards Initial commit ID (Likely to change): 0e84240346c171b552177ac792bb46037d7bac7a PatchWorks http://patchwork.kernel.org/patch/120871/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0e84240346c171b552177ac792bb46037d7bac7a -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH 1/2] crypto: updates to enable omap aes
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-omap-misc Initial commit ID (Likely to change): 7f348732d17b1c2a2e8412fc13015e0dd2038204 PatchWorks http://patchwork.kernel.org/patch/120630/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7f348732d17b1c2a2e8412fc13015e0dd2038204 -- To unsubscribe from this list: send the line "unsubscribe 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 v6 1/3] ARM: OMAP: Beagle: revision detection
* Jarkko Nikula [100820 04:55]: > On Thu, 19 Aug 2010 21:38:44 -0500 > Robert Nelson wrote: > > > Due to the omap3530 ES3.0 Silicon being used on both the > > B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx() > > routines to differentiate the Beagle Boards. > > > > However gpio pins 171,172,173 where setup for this prupose, so > > lets use them. > > > > Changes: > > for older U-Boot's, use omap_mux_init_gpio() > > keep Beagle Rev in board-omap3beagle.c > > gpio_free on gpio request failure > > > > Tested on Beagle Revisions: B5, C2, C4, and xMA > > > > Signed-off-by: Robert Nelson > > Cc: Jarkko Nikula > > --- > > To this set: > > Acked-by: Jarkko Nikula Adding all three. 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] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
On Thu, Sep 23, 2010 at 10:22 AM, Tony Lindgren wrote: > * Cory Maccarrone [100817 21:28]: >> This change adds in MMC and I2C support to the HTC Herald board, as well >> as adding the HTCPLD driver for the PLD used on this phone. It also >> adds in the gpio-keys entries for the front directional keys and >> selector and the cursor keys on the slide-out keyboard, and gpio-leds >> support for the LEDs attached to the htcpld. >> >> Additionally, SPI bus support (using the spi100k driver) and >> touchscreen support (using the ads7846 driver) were added. > > Thanks, I'll add this into omap-for-linus for the upcoming merge > window. Cory, can you please check if you have other pending > patches? I don't see others in patchwork.kernel.org, but thought > there may be some that did not get merged last merge window? > I believe you have everything. I had submitted a series of 5 patches that you commented on, and this one was the boiled down combination of all of those (minus one element which I'm still looking into). So, just this one should be pending. Thanks - Cory -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
* Cory Maccarrone [100817 21:28]: > This change adds in MMC and I2C support to the HTC Herald board, as well > as adding the HTCPLD driver for the PLD used on this phone. It also > adds in the gpio-keys entries for the front directional keys and > selector and the cursor keys on the slide-out keyboard, and gpio-leds > support for the LEDs attached to the htcpld. > > Additionally, SPI bus support (using the spi100k driver) and > touchscreen support (using the ads7846 driver) were added. Thanks, I'll add this into omap-for-linus for the upcoming merge window. Cory, can you please check if you have other pending patches? I don't see others in patchwork.kernel.org, but thought there may be some that did not get merged last merge window? 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 v8 3/6] OMAP2430: hwmod data: Add watchdog timer
Hello Russell,
On Thu, 23 Sep 2010, Russell King - ARM Linux wrote:
> On Thu, Sep 23, 2010 at 08:02:40PM +0530, Varadarajan, Charulatha wrote:
> > +static struct omap_hwmod omap2430_wd_timer2_hwmod = {
> > + .name = "wd_timer2",
> > + .class = &omap2430_wd_timer_hwmod_class,
> > + .main_clk = "mpu_wdt_fck",
>
> Why are we going backwards to naming clocks by source rather than
> looking them up by device + connection ?
(Device, connection) clock addressing is still used by device drivers.
It is a superior method for drivers, and one that's not going anywhere.
Drivers still should do:
c = clk_get(dev, "fck");
... if it needs to work with clocks directly. [ Most drivers won't even
need to do this now, unless they wish to change clock sources or rates,
since pm_runtime_{get,put}() will automatically enable/disable clocks on
OMAP. ]
The OMAP clock code still uses clkdev to map (device, connection name) to
the appropriate struct clk. The utility of that dual naming is not in
question. For driver code, that clock naming scheme is crucial to having
drivers that can work across multiple SoCs without modification.
The hwmod data, however, describes the hardware at a fundamental level:
one that is independent of the Linux driver model. Like the OMAP struct
clks, clockdomains, and powerdomains, this data is intended to be
autogenerated from the TI hardware database. This is data that, in an
ideal world, would be in ROM somewhere on the OMAP: ideally it should
never change across the life of the device. For the OMAP core code that
uses this data, it doesn't care whether there is a platform_device above
it, an of_device, or an omap_device, or whether someone has just written a
new driver that groups devices differently. This hwmod data describes the
hardware itself and is used for basic IP block control: to reset,
initialize, enable, idle, and disable on-chip IP blocks. Much of this
happens very early in boot, before the Linux driver model code enumerates
devices.
So the clock names used here are intended to be the TI hardware database
clock names, which also appear in the OMAP struct clk.name. The only
place the hwmod clock names are used in the kernel is by the hwmod core
code. There is a core-internal function in the OMAP clock code used by
the hwmod code to connect the autogenerated struct clks to the
autogenerated hwmod data. Any other part of the kernel that works with
struct devices must use the (device, connection) naming scheme, via the
clock code.
I appreciate the comments,
- Paul
--
To unsubscribe from this list: send the line "unsubscribe 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/1] omap2/3: Update revision identification
* Sanjeev Premi [100816 08:46]:
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -366,21 +366,23 @@ static void __init omap3_cpuinfo(void)
> strcpy(cpu_rev, "1.0");
> break;
> case OMAP_REVBITS_01:
> - strcpy(cpu_rev, "1.1");
> + if (cpu_is_omap3630()) {
> + strcpy(cpu_rev, "1.1");
> + } else {
> + strcpy(cpu_rev, "2.0");
> + }
> break;
No { } brackets needed if it's one line + one line if else
statement.
> case OMAP_REVBITS_02:
> - strcpy(cpu_rev, "1.2");
> - break;
> - case OMAP_REVBITS_10:
> - strcpy(cpu_rev, "2.0");
> - break;
> - case OMAP_REVBITS_20:
> - strcpy(cpu_rev, "2.1");
> + if (cpu_is_omap3630()) {
> + strcpy(cpu_rev, "1.2");
> + } else {
> + strcpy(cpu_rev, "2.1");
> + }
> break;
Not needed here either.
> - case OMAP_REVBITS_30:
> + case OMAP_REVBITS_03:
> strcpy(cpu_rev, "3.0");
> break;
> - case OMAP_REVBITS_40:
> + case OMAP_REVBITS_04:
> /* FALLTHROUGH */
> default:
> /* Use the latest known revision as default */
Also, maybe just set a separate switch for 36xx?
In the long run it's best to avoid sprinkiling the cpu_is_omap
tests as that adds more places to patch when new omap xyz is
added.
> -#define OMAP2420_REV_ES2_0 0x24201024
> +#define OMAP2420_REV_ES1_0 (OMAP242X_CLASS)
> +#define OMAP2420_REV_ES2_0 (OMAP242X_CLASS | (OMAP_REVBITS_01 << 8))
No parens needed around OMAP242X_CLASS if it's just one value.
> #define OMAP243X_CLASS 0x24300024
> -#define OMAP2430_REV_ES1_0 0x24300024
> +#define OMAP2430_REV_ES1_0 (OMAP243X_CLASS)
Not needed around OMAP243X_CLASS either. Please check
the other places 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: [RFC] omap: mailbox: fix detection for previously supported chips
Hi Omar,
> -Original Message-
> From: Ramirez Luna, Omar
> Sent: Thursday, September 23, 2010 11:12 AM
> To: Aguirre, Sergio; Tony Lindgren; Hiroshi DOYU; Felipe Contreras; Anna,
> Suman; linux-omap@vger.kernel.org
> Subject: RE: [RFC] omap: mailbox: fix detection for previously supported
> chips
>
> Hi Sergio,
>
> Aguirre, Sergio wrote:
> > Hi Omar,
> >>
> ...
> >> +#if defined(CONFIG_ARCH_OMAP2)
> >> + else if (cpu_is_omap2430()) {
> >> + list = omap2_mboxes;
> >> +
> >> + list[0]->irq = platform_get_irq_byname(pdev, "dsp");
> >> + } else if (cpu_is_omap2420()) {
> >
> > Isn't both 2430 and 2420 doing the exact same?
> >
>
> Code is not the same, it is 2 line which apply for both but couldn't find
> an easy way of making them share the request for dsp mailbox without
> changing more code, perhaps a macro to detect if omap2 and then a nested
> if for the 2420 case, but since HWMOD should handle it better, I left it
> as is.
>
> As the code previous to reorganization treated 2430 has a user with one
> single mailbox (same as omap3) I added the code to at least detect it,
> 2420 has 2 mailboxes one for iva and other for the dsp. From the diagrams
> for OMAP2430[1] and OMAP2420[2], it made sense as in the later both dsp
> and iva seem to be separated entities; unfortunately I don't have the
> hardware to test on any of them.
>
> The patched code should look like:
>
> #if defined(CONFIG_ARCH_OMAP2)
> else if (cpu_is_omap2430()) {
> list = omap2_mboxes;
>
> list[0]->irq = platform_get_irq_byname(pdev, "dsp");
> } else if (cpu_is_omap2420()) {
> list = omap2_mboxes;
>
> list[0]->irq = platform_get_irq_byname(pdev, "dsp");
> list[1]->irq = platform_get_irq_byname(pdev, "iva");
> }
> #endif
Ok, I understand.
I guess I missed to see the second element in the list for acquiring IVA irq.
Thanks for the explanation.
Regards,
Sergio
>
> Regards,
>
> Omar
>
> ---
>
> [1]
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=467
> 2&navigationId=12609&templateId=6123
> [2]
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=61
> 23&navigationId=11990&contentId=4671
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database
On 9/23/2010 11:34 AM, Basak, Partha wrote:
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 23, 2010 3:10 AM
"G, Manjunath Kondaiah" writes:
Hi Tarun,
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
<...>
+static u32 omap_timer_reg_map_v1[] = {
+ [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_SYS_STAT_REG] = (0x14 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_STAT_REG] = (0x18 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_INT_EN_REG] = (0x1c | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_WAKEUP_EN_REG] = (0x20 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_CTRL_REG] = (0x24 | (WP_TCLR<< WPSHIFT)),
+ [OMAP_TIMER_COUNTER_REG]= (0x28 | (WP_TCRR<< WPSHIFT)),
+ [OMAP_TIMER_LOAD_REG] = (0x2c | (WP_TLDR<< WPSHIFT)),
+ [OMAP_TIMER_TRIGGER_REG]= (0x30 | (WP_TTGR<< WPSHIFT)),
+ [OMAP_TIMER_WRITE_PEND_REG] = (0x34 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_MATCH_REG] = (0x38 | (WP_TMAR<< WPSHIFT)),
+ [OMAP_TIMER_CAPTURE_REG]= (0x3c | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_IF_CTRL_REG]= (0x40 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_CAPTURE2_REG] = (0x44 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_TICK_POS_REG] = (0x48 | (WP_TPIR<< WPSHIFT)),
+ [OMAP_TIMER_TICK_NEG_REG] = (0x4c | (WP_TNIR<< WPSHIFT)),
+ [OMAP_TIMER_TICK_COUNT_REG] = (0x50 | (WP_TCVR<< WPSHIFT)),
+ [OMAP_TIMER_TICK_INT_MASK_SET_REG] = (0x54 |
(WP_TOCR<< WPSHIFT)),
+ [OMAP_TIMER_TICK_INT_MASK_COUNT_REG]= (0x58 |
(WP_TOWR<< WPSHIFT)),
+};
+
+/* OMAP4 timers register map */
+static u32 omap_timer_reg_map_v2[] = {
+ [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_SYS_STAT_REG] = (0x14 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_STAT_REG] = (0x28 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_INT_EN_REG] = (0x2c | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_WAKEUP_EN_REG] = (0x34 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_CTRL_REG] = (0x38 | (WP_TCLR<< WPSHIFT)),
+ [OMAP_TIMER_COUNTER_REG]= (0x3c | (WP_TCRR<< WPSHIFT)),
+ [OMAP_TIMER_LOAD_REG] = (0x40 | (WP_TLDR<< WPSHIFT)),
+ [OMAP_TIMER_TRIGGER_REG]= (0x44 | (WP_TTGR<< WPSHIFT)),
+ [OMAP_TIMER_WRITE_PEND_REG] = (0x48 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_MATCH_REG] = (0x4c | (WP_TMAR<< WPSHIFT)),
+ [OMAP_TIMER_CAPTURE_REG]= (0x50 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_IF_CTRL_REG]= (0x54 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_CAPTURE2_REG] = (0x58 | (WP_NONE<< WPSHIFT)),
+ [OMAP_TIMER_INT_CLR_REG]= (0x30 | (WP_NONE<< WPSHIFT)),
+};
+
Why not these defines in mach-omap2/dmtimer.c? since
register offsets are
same for omap2plus except omap4 which has additional
register offsets. Same
register offsets are getting repeated in all the omap2plus
hwmod database.
I agree with Manjunath.
Manju, the number of tables needed to manage the information are same really.
Its only where they are located changes from the mach layer to the hwmod
database. So, thats not the point. dev_attrs are pointing to the reg-map
tables, they are not duplicating them.
The offset differences are stemming from the IP differences.
To my understanding, only IP-integration specific idiosyncrasies into a given
SOC qualifiy as dev_attrs.
IP specific details like reg-map information should be maintained within the
driver.
So, this approach will break this paradigm& also not follow existing
implementation
of drivers which support this. A given driver may support a set of IPs but still
may cater to even non-OMAP platforms not supporting hwmod.
However, if we see the general usage of dev_attrs, there is no clear line of
demarcation
really what should make it and what should not, as is used to plug this sort of
small gotchas and reduce CPU checks in the code.
You do not really need that to reduce the CPU check in the code.
In that case, only the IP version should be stored in the dev_attr.
Based on that IP version, you know exactly what register map you have to
handle. For the moment you just have 2 layouts to handle + the extra
register for the 1ms timers.
Also, I'm not sure that you have to handle each register separately
considering that you have one offset to handle for the functional register.
The change in sysconfig and interrupt register are all standard mapping
that stick to TI highlander standard.
Meaning, as soon as an IP is a v2 (highlander version) all these
registers will be at the same place... at least in theory :-)
Here are the deltas between the legacy and the new one:
[OMAP_TIMER_ID_REG] 0x00,
[OMAP_TIMER_OCP_CFG_REG]0x10, same
[OMAP_TIMER_SYS_STAT_REG]
Re: [PATCH 1/1] omap: fix section mismatch errors
* Sanjeev Premi [100816 08:24]:
> This patch fixes miltiple section mismatch errors
> observed with the latest master.
Few comments below.
> @@ -134,7 +134,7 @@ static inline void board_smc91x_init(void)
>
> #endif
>
> -static struct omap_board_config_kernel sdp2430_config[] = {
> +static struct omap_board_config_kernel sdp2430_config[] __initdata = {
> {OMAP_TAG_LCD, &sdp2430_lcd_config},
> };
...
Let's just get rid of omap_get_config stuff. The OMAP_TAG_LCD
and OMAP_TAG_FBMEM are the last remaining legacy tags. They should
be replaced with just platform_data. And while at it, it should
be done for all the boards.
Tomi, do you see any problems with that?
> --- a/arch/arm/mach-omap2/board-zoom-peripherals.c
> +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
> @@ -171,7 +171,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
> {} /* Terminator */
> };
>
> -static int zoom_twl_gpio_setup(struct device *dev,
> +static int __init zoom_twl_gpio_setup(struct device *dev,
> unsigned gpio, unsigned ngpio)
> {
> /* gpio + 0 is "mmc0_cd" (input/IRQ) */
This should be safe to do for all the board, pdata->setup is only
called during the probe.
> @@ -209,27 +209,27 @@ static struct twl4030_usb_data zoom_usb_data = {
> .usb_mode = T2_USB_MODE_ULPI,
> };
>
> -static struct twl4030_gpio_platform_data zoom_gpio_data = {
> +static struct twl4030_gpio_platform_data zoom_gpio_data __initdata = {
> .gpio_base = OMAP_MAX_GPIO_LINES,
> .irq_base = TWL4030_GPIO_IRQ_BASE,
> .irq_end= TWL4030_GPIO_IRQ_END,
> .setup = zoom_twl_gpio_setup,
> };
But this is not safe to do as twl4030-gpio.c uses pdata in
gpio_twl4030_remove.
It's best to split the initdata changes so you make one change for
all the boards per patch, that way it's possible to check if it's
OK to do that change from the driver point of view.
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 2/2] omap: zoom: Move new code introduced by ASoC m-c to board-zoom-peripherals
On Thu, Sep 23, 2010 at 07:11:54PM +0300, Jarkko Nikula wrote: > ASoC Multi-Component Support moves some code from sound/soc/omap/zoom2.c into > arch/arm/mach-omap2/board-zoom2.c. However, that code should go to > board-zoom-peripherals.c instead as there is common code and registration > for zoom boards. > > Signed-off-by: Jarkko Nikula Acked-by: Mark Brown -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap: zoom2: Fix ASoC multi-component build breakage by removing dead code
On Thu, Sep 23, 2010 at 07:11:53PM +0300, Jarkko Nikula wrote: > ASoC Multi-Component Support patch removes #if 0 in board-zoom2.c that was > used to protect some uncompiling dead code. Remove that code as it seems to > be here quite some time since commit 479f12c. > > Signed-off-by: Jarkko Nikula Acked-by: Mark Brown -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap: zoom2: Fix ASoC multi-component build breakage by removing dead code
ASoC Multi-Component Support patch removes #if 0 in board-zoom2.c that was
used to protect some uncompiling dead code. Remove that code as it seems to
be here quite some time since commit 479f12c.
Signed-off-by: Jarkko Nikula
Cc: Vikram Pandita
Cc: Tony Lindgren
---
Sorry for not noticing this before. Somehow my own test config didn't include
zoom2 like omap3_defconfig does.
---
arch/arm/mach-omap2/board-zoom2.c | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index efbcd8f..86d4515 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -41,10 +41,6 @@ void zoom2_set_hs_extmute(int mute)
gpio_set_value(ZOOM2_HEADSET_EXTMUTE_GPIO, mute);
}
-static struct twl4030_madc_platform_data zoom2_madc_data = {
- .irq_line = 1,
-};
-
static struct twl4030_codec_audio_data zoom2_audio_data = {
.audio_mclk = 2600,
.ramp_delay_value = 3, /* 161 ms */
@@ -62,15 +58,7 @@ static struct twl4030_platform_data zoom2_twldata = {
.irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
- .bci= &zoom2_bci_data,
- .madc = &zoom2_madc_data,
- .usb= &zoom2_usb_data,
- .gpio = &zoom2_gpio_data,
- .keypad = &zoom2_kp_twl4030_data,
.codec = &zoom2_codec_data,
- .vmmc1 = &zoom2_vmmc1,
- .vmmc2 = &zoom2_vmmc2,
- .vsim = &zoom2_vsim,
};
static struct i2c_board_info __initdata zoom2_i2c_boardinfo[] = {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: zoom: Move new code introduced by ASoC m-c to board-zoom-peripherals
ASoC Multi-Component Support moves some code from sound/soc/omap/zoom2.c into
arch/arm/mach-omap2/board-zoom2.c. However, that code should go to
board-zoom-peripherals.c instead as there is common code and registration
for zoom boards.
Signed-off-by: Jarkko Nikula
Cc: Vikram Pandita
Cc: Lopez Cruz, Misael
Cc: Jorge Eduardo Candelaria
Cc: Tony Lindgren
---
I don't have this HW so not tested. This is omap architecture patch but I
think this should go together with ASoC Multi-Component.
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 12 +++
arch/arm/mach-omap2/board-zoom2.c| 44 --
2 files changed, 12 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..3c65304 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -24,6 +24,8 @@
#include
#include
+#include
+
#include "mux.h"
#include "hsmmc.h"
@@ -188,6 +190,11 @@ static int zoom_twl_gpio_setup(struct device *dev,
return 0;
}
+/* EXTMUTE callback function */
+void zoom2_set_hs_extmute(int mute)
+{
+ gpio_set_value(ZOOM2_HEADSET_EXTMUTE_GPIO, mute);
+}
static int zoom_batt_table[] = {
/* 0 C*/
@@ -257,6 +264,11 @@ static struct i2c_board_info __initdata
zoom_i2c_boardinfo[] = {
static int __init omap_i2c_init(void)
{
+ if (machine_is_omap_zoom2()) {
+ zoom_audio_data.ramp_delay_value = 3; /* 161 ms */
+ zoom_audio_data.hs_extmute = 1;
+ zoom_audio_data.set_hs_extmute = zoom2_set_hs_extmute;
+ }
omap_register_i2c_bus(1, 2400, zoom_i2c_boardinfo,
ARRAY_SIZE(zoom_i2c_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 86d4515..00c8f83 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -35,49 +35,6 @@ static void __init omap_zoom2_init_irq(void)
omap_gpio_init();
}
-/* EXTMUTE callback function */
-void zoom2_set_hs_extmute(int mute)
-{
- gpio_set_value(ZOOM2_HEADSET_EXTMUTE_GPIO, mute);
-}
-
-static struct twl4030_codec_audio_data zoom2_audio_data = {
- .audio_mclk = 2600,
- .ramp_delay_value = 3, /* 161 ms */
- .hs_extmute = 1,
- .set_hs_extmute = zoom2_set_hs_extmute,
-};
-
-static struct twl4030_codec_data zoom2_codec_data = {
- .audio_mclk = 2600,
- .audio = &zoom2_audio_data,
-};
-
-static struct twl4030_platform_data zoom2_twldata = {
- .irq_base = TWL4030_IRQ_BASE,
- .irq_end= TWL4030_IRQ_END,
-
- /* platform_data for children goes here */
- .codec = &zoom2_codec_data,
-};
-
-static struct i2c_board_info __initdata zoom2_i2c_boardinfo[] = {
- {
- I2C_BOARD_INFO("twl4030", 0x48),
- .flags = I2C_CLIENT_WAKE,
- .irq = INT_34XX_SYS_NIRQ,
- .platform_data = &zoom2_twldata,
- },
-};
-
-static int __init omap3_zoom2_i2c_init(void)
-{
- omap_register_i2c_bus(1, 2600, zoom2_i2c_boardinfo,
- ARRAY_SIZE(zoom2_i2c_boardinfo));
- return 0;
-}
-
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
/* WLAN IRQ - GPIO 162 */
@@ -144,7 +101,6 @@ static void __init omap_zoom2_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
zoom_peripherals_init();
- omap3_zoom2_i2c_init();
board_nand_init(zoom_nand_partitions,
ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] omap: mailbox: fix detection for previously supported chips
Hi Sergio,
Aguirre, Sergio wrote:
> Hi Omar,
>>
...
>> +#if defined(CONFIG_ARCH_OMAP2)
>> +else if (cpu_is_omap2430()) {
>> +list = omap2_mboxes;
>> +
>> +list[0]->irq = platform_get_irq_byname(pdev, "dsp");
>> +} else if (cpu_is_omap2420()) {
>
> Isn't both 2430 and 2420 doing the exact same?
>
Code is not the same, it is 2 line which apply for both but couldn't find an
easy way of making them share the request for dsp mailbox without changing more
code, perhaps a macro to detect if omap2 and then a nested if for the 2420
case, but since HWMOD should handle it better, I left it as is.
As the code previous to reorganization treated 2430 has a user with one single
mailbox (same as omap3) I added the code to at least detect it, 2420 has 2
mailboxes one for iva and other for the dsp. From the diagrams for OMAP2430[1]
and OMAP2420[2], it made sense as in the later both dsp and iva seem to be
separated entities; unfortunately I don't have the hardware to test on any of
them.
The patched code should look like:
#if defined(CONFIG_ARCH_OMAP2)
else if (cpu_is_omap2430()) {
list = omap2_mboxes;
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
} else if (cpu_is_omap2420()) {
list = omap2_mboxes;
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
list[1]->irq = platform_get_irq_byname(pdev, "iva");
}
#endif
Regards,
Omar
---
[1]
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=4672&navigationId=12609&templateId=6123
[2]
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=11990&contentId=4671--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [RFC PATCH] hmc5843: Digital compass board file
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-boards Initial commit ID (Likely to change): 4a65d1d872bc6ae3c59936a10feb0694d24b8c78 PatchWorks http://patchwork.kernel.org/patch/119657/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=4a65d1d872bc6ae3c59936a10feb0694d24b8c78 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thu, 23 Sep 2010, Janusz Krzysztofik wrote:
> Thursday 23 September 2010 15:33:54 Guennadi Liakhovetski napisał(a):
> > On Wed, 22 Sep 2010, Janusz Krzysztofik wrote:
> > > Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
> > > > On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
> > > > > +
> > > > > + vb = &buf->vb;
> > > > > + if (waitqueue_active(&vb->done)) {
> > > > > + if (!pcdev->ready && result != VIDEOBUF_ERROR)
> > > > > + /*
> > > > > + * No next buffer has been entered into the DMA
> > > > > + * programming register set on time, so best we
> > > > > can do
> > > > > + * is stopping the capture before last DMA
> > > > > block,
> > > > > + * whether our CONTIG mode whole buffer or its
> > > > > last
> > > > > + * sgbuf in SG mode, gets overwritten by next
> > > > > frame.
> > > > > + */
> > > >
> > > > Hm, why do you think it's a good idea? This specific buffer completed
> > > > successfully, but you want to fail it just because the next buffer is
> > > > missing? Any specific reason for this?
> > >
> > > Maybe my comment is not clear enough, but the below suspend_capture()
> > > doesn't indicate any failure on a frame just captured. It only prevents
> > > the frame from being overwritten by the already autoreinitialized DMA
> > > engine, pointing back to the same buffer once again.
> > >
> > > > Besides, you seem to also be
> > > > considering the possibility of your ->ready == NULL, but the queue
> > > > non-empty, in which case you just take the next buffer from the queue
> > > > and continue with it. Why error out in this case?
> > >
> > > pcdev->ready == NULL means no buffer was available when it was time to
> > > put it into the DMA programming register set.
> >
> > But how? Buffers are added onto the list in omap1_videobuf_queue() under
> > spin_lock_irqsave(); and there you also check ->ready and fill it in.
>
> Guennadi,
> Yes, but only if pcdev->active is NULL, ie. both DMA and FIFO are idle, never
> if active:
>
> + list_add_tail(&vb->queue, &pcdev->capture);
> + vb->state = VIDEOBUF_QUEUED;
> +
> + if (pcdev->active)
> + return;
>
> Since the transfer of the DMA programming register set content to the DMA
> working register set is done automatically by the DMA hardware, this can
> pretty well happen while I keep the lock here, so I can't be sure if it's not
> too late for entering new data into the programming register set. Then, I
> decided that this operation should be done only just after the DMA interrupt
> occured, ie. the current DMA programming register set content has just been
> used and can be overwriten.
>
> I'll emphasize the above return; with a comment.
Ok
> > In
> > your completion you set ->ready = NULL, but then also call
> > prepare_next_vb() to get the next buffer from the list - if there are any,
> > so, how can it be NULL with a non-empty list?
>
> It happens after the above mentioned prepare_next_vb() gets nothing from an
> empty queue, so nothing is entered into the DMA programming register set,
> only the last, just activated, buffer is processed, then
> omap1_videobuf_queue() puts a new buffer into the queue while the active
> buffer is still filled in, and finally the DMA ISR is called on this last
> active buffer completion.
>
> I hope this helps.
Let's assume it does:) You seem to really understand how this is working
and even be willing to document the driver, thus making it possibly the
best documented soc-camera related piece of software;)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe 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 8/9 v3] usb : musb: Using runtime pm apis for musb.
>-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Thursday, September 23, 2010 9:00 PM >To: Balbi, Felipe >Cc: Kalliguddi, Hema; linux-omap@vger.kernel.org; >linux-...@vger.kernel.org; Basak, Partha; Tony Lindgren; >Cousson, Benoit; Paul Walmsley >Subject: Re: [PATCH 8/9 v3] usb : musb: Using runtime pm apis for musb. > >Felipe Balbi writes: > >> Hi, >> >> On Wed, Sep 22, 2010 at 07:30:30PM -0500, Kalliguddi, Hema wrote: >>>Calling runtime pm APIs pm_runtime_put_sync() and >pm_runtime_get_sync() >>>for enabling/disabling the clocks,sysconfig settings. >>> >>>Also need to put the USB in force standby and force idle >mode when usb not used >>>and set it back to no idle and no stndby after wakeup. >>>For OMAP3 auto idle bit has to be disabled because of the >errata.So using >>>HWMOD_NO_OCP_AUTOIDLE flag for OMAP3430. > >[...] > >>>@@ -2424,13 +2425,16 @@ static int musb_suspend(struct device *d >>> * they will even be wakeup-enabled. >>> */ >>> } >>>+pm_runtime_put_sync(dev); >>> >>>+#ifndef CONFIG_PM_RUNTIME >>> musb_save_context(musb); >>> >>> if (musb->set_clock) >>> musb->set_clock(musb->clock, 0); >>> else >>> clk_disable(musb->clock); >>>+#endif >> >> I would rather remove these, adding ifdefs is bad :-( Unless >other archs >> (blackfin, davinci) would have problems if we remove those. > >I didn't like these #ifdefs either, but davinci doesn't have >runtime PM, >and I don't think blackfin does either. > >But, rather than the ifdef here, this could be done with different >pointers in struct dev_pm_ops based on the arch. > >Also, this shouldn't be based on CONFIG_PM_RUNTIME, but rather on the >arch. We can still enable runtime PM on davinci for other subsystems >(PCI, USB core, etc.) but not have it supported for on-chip devices. > Is it a good idea to use the musb->set_clock function pointer for OMAP architure and call the runtime pm apis from this function defined in the usb platform driver(omap2430) >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 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
"Basak, Partha" writes:
>
>
>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> Sent: Tuesday, September 14, 2010 10:28 PM
>> To: Basak, Partha
>> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Tero Kristo
>> Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of
>> interrupts-disabled idle path
>>
>> "Basak, Partha" writes:
>>
>> >> From: Kevin Hilman
>> >>
>> >> Currently, we wait until late in the idle path where interrupts are
>> >> disabled to do runtime-PM-like management for certain special-case
>> >> devices like GPIO.
>> >>
>> >> As a prerequiste to moving GPIO to the new runtime PM
>> framework, move
>> >> this runtime-PM-like code out of the late idle path into new device
>> >> idle and resume functions that can be called before interrupts are
>> >> disabled by CPUidle and/or suspend.
>> >>
>> >> In addition, move all the GPIO-specific logic into the GPIO core
>> >> instead of keeping GPIO-specific knowledge of power-states, context
>> >> saving etc. in the PM core.
>> >>
>> >> Also, call the new device-idle and -resume methods from CPUidle and
>> >> static suspend path.
>> >>
>> >> Signed-off-by: Kevin Hilman
>> >> ---
>> >> arch/arm/mach-omap2/cpuidle34xx.c |4 ++
>> >> arch/arm/mach-omap2/pm.h |2 +
>> >> arch/arm/mach-omap2/pm24xx.c |2 +-
>> >> arch/arm/mach-omap2/pm34xx.c | 38
>> +
>> >> arch/arm/plat-omap/gpio.c | 57
>> >>
>> >> arch/arm/plat-omap/include/plat/gpio.h |4 +--
>> >> 6 files changed, 67 insertions(+), 40 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>> >> b/arch/arm/mach-omap2/cpuidle34xx.c
>> >> index 0923b82..681d823 100644
>> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> >> @@ -274,9 +274,13 @@ static int omap3_enter_idle_bm(struct
>> >> cpuidle_device *dev,
>> >> pwrdm_set_next_pwrst(per_pd, per_next_state);
>> >>
>> >> select_state:
>> >> + omap3_device_idle();
>> >> +
>> >> dev->last_state = new_state;
>> >> ret = omap3_enter_idle(dev, new_state);
>> >>
>> >> + omap3_device_resume();
>> >> +
>> > In the generic cpu_idle() in process.c, interrupts are
>> already disabled
>> > before control comes to cpuidle_idle_call() via pm_idle()
>> >local_irq_disable();
>> >if (hlt_counter) {
>> >local_irq_enable();
>> >cpu_relax();
>> >} else {
>> >stop_critical_timings();
>> >pm_idle();
>> >start_critical_timings();
>> >/*
>> > * This will eventually be
>> removed - pm_idle
>> > * functions should always
>> return with IRQs
>> > * enabled.
>> > */
>> >WARN_ON(irqs_disabled());
>> >local_irq_enable();
>> >}
>> >
>> > omap3_enter_idle_bm() will be called from inside
>> cpuidle_idle_call()
>> > via target_state->enter(dev, target_state).
>> > So, interrupts are already disabled here.
>> >
>> > Am I missing something?
>>
>> You're right.
>>
>> I knew this was the case for !CPUIDLE setup, but had thought (without
>> testing) that the CPUidle core had re-enabled interrupts during the
>> governor selection process etc.
>>
>> While I investigate ways to manage this in CPUidle, the
>> following should
>> be fine for now to include with $SUBJECT patch.
>>
>> Kevin
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>> b/arch/arm/mach-omap2/cpuidle34xx.c
>> index 681d823..c5cb9d0 100644
>> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> @@ -245,6 +245,14 @@ static int omap3_enter_idle_bm(struct
>> cpuidle_device *dev,
>> goto select_state;
>> }
>>
>> +/*
>> + * Enable IRQs during the device activity checking and
>> idle management.
>> + * IRQs are later (re)disabled when entering the actual
>> idle function.
>> + * Device idle management that is using runtime PM needs to have
>> + * interrupts enabled when calling into the runtime PM core.
>> + */
>> +local_irq_enable();
>
> After put_sync() retuns, there will be a time window where interrupts
> are enabled but clocks are disabled before the interrupts are disabled again.
> Accessing any register to service a device interrupt coming during this window
> will lead to a crash for cases where iclk and fclks are same and we have the
> iclk defined as the main_clk as well.
>
> Same argument holds while returning from Idle. We are facing this issue for
> OMAP3
> GPIO while trying to define the main_clk = interface clock based on your
> other com
RE: [PATCH 9/9 v3] usb : musb: Offmode fix for idle path
Kevin,
>-Original Message-
>From: linux-usb-ow...@vger.kernel.org
>[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Kalliguddi, Hema
>Sent: Thursday, September 23, 2010 1:29 PM
>To: Balbi, Felipe
>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>Mankad, Maulik Ojas; Tony Lindgren; Kevin Hilman; Cousson,
>Benoit; Paul Walmsley
>Subject: RE: [PATCH 9/9 v3] usb : musb: Offmode fix for idle path
>
> Hi,
>
>>-Original Message-
>>From: Balbi, Felipe
>>Sent: Thursday, September 23, 2010 12:19 PM
>>To: Kalliguddi, Hema
>>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>>Mankad, Maulik Ojas; Balbi, Felipe; Tony Lindgren; Kevin
>>Hilman; Cousson, Benoit; Paul Walmsley
>>Subject: Re: [PATCH 9/9 v3] usb : musb: Offmode fix for idle path
>>
>>Hi,
>>
>>On Wed, Sep 22, 2010 at 07:30:46PM -0500, Kalliguddi, Hema wrote:
>>>With OMAP core-off support musb was not functional as context
>>was getting
>>>lost after wakeup from core-off. And also musb was blocking
>>the core-off
>>>after loading the gadget driver even with no cable connected
>>sometimes.
>>>
>>>Added the idle and wakeup APIs in the platform layer which will
>>>be called in the idle and wakeup path.
>>>
>>>Used the pm_runtime_put_sysc API to configure the
>>
>>pm_runtime_put_sync(), typo.
>>
>>>musb to force idle/standby modes, saving the context and
>>disable the clk in
>>>while idling if there is no activity on the usb bus.
>>
>>this part is a bit fuzzy, care to re-phrase ?
>>
>Ok. I will re-phrase it.
>
>>>Used the pm_runtime_get_sync API to configure the musb to
>>>no idle/standby modes, enable the clock and restore the context
>>>after wakeup when there is no activity on the usb bus.
>>>
>>>Signed-off-by: Hema HK
>>>Signed-off-by: Maulik Mankad
>>>Cc: Felipe Balbi
>>>Cc: Tony Lindgren
>>>Cc: Kevin Hilman
>>>Cc: Cousson, Benoit
>>>Cc: Paul Walmsley
>>>
>>>---
>>> arch/arm/mach-omap2/cpuidle34xx.c |1
>>> arch/arm/mach-omap2/pm34xx.c |3
>>> arch/arm/mach-omap2/usb-musb.c| 107
>>++
>>> arch/arm/plat-omap/include/plat/usb.h |2
>>> drivers/usb/musb/musb_core.c | 15
>>> drivers/usb/musb/omap2430.c | 14
>>> include/linux/usb/musb.h |9 ++
>>> 7 files changed, 149 insertions(+), 2 deletions(-)
>>>
>>>Index: linux-omap-pm/arch/arm/mach-omap2/cpuidle34xx.c
>>>===
>>>--- linux-omap-pm.orig/arch/arm/mach-omap2/cpuidle34xx.c
>>>+++ linux-omap-pm/arch/arm/mach-omap2/cpuidle34xx.c
>>>@@ -31,6 +31,7 @@
>>> #include
>>> #include
>>> #include
>>>+#include
>>>
>>> #include "pm.h"
>>>
>>>Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
>>>===
>>>--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
>>>+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
>>>@@ -38,6 +38,7 @@
>>> #include
>>> #include
>>> #include
>>>+#include
>>>
>>> #include
>>>
>>>@@ -324,11 +325,13 @@ static void restore_table_entry(void)
>>> void omap3_device_idle(void)
>>> {
>>> omap2_gpio_prepare_for_idle();
>>>+musb_prepare_for_idle();
>>> }
>>>
>>> void omap3_device_resume(void)
>>> {
>>> omap2_gpio_resume_after_idle();
>>>+musb_wakeup_from_idle();
>>> }
>>>
>>> void omap_sram_idle(void)
>>>Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
>>>===
>>>--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c
>>>+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
>>>@@ -25,16 +25,21 @@
>>> #include
>>>
>>> #include
>>>+#include
>>>
>>> #include
>>> #include
>>> #include
>>> #include
>>>+#include
>>>
>>> #ifdef CONFIG_USB_MUSB_SOC
>>> static const char name[] = "musb_hdrc";
>>> #define MAX_OMAP_MUSB_HWMOD_NAME_LEN16
>>>
>>>+struct omap_hwmod *oh_p;
>>>+static struct powerdomain *core_pwrdm;
>>>+
>>> static struct musb_hdrc_config musb_config = {
>>> .multipoint = 1,
>>> .dyn_fifo = 1,
>>>@@ -58,6 +63,10 @@ static struct musb_hdrc_platform_data mu
>>> * "mode", and should be passed to usb_musb_init().
>>> */
>>> .power = 50, /* up to 100 mA */
>>>+
>>>+/* OMAP supports offmode */
>>>+.save_context = 1,
>>>+.restore_context= 1,
>>> };
>>>
>>> static u64 musb_dmamask = DMA_BIT_MASK(32);
>>>@@ -80,6 +89,7 @@ void __init usb_musb_init(struct omap_mu
>>> const char *oh_name = "usb_otg_hs";
>>> struct musb_hdrc_platform_data *pdata;
>>>
>>>+core_pwrdm = pwrdm_lookup("per_pwrdm");
>>
>>per or core ???
>>
>Oh! It should be core. Now I understand why save/restore
>counts were not matching with
>Core-off counts.
>Thanks for pointing this out.
If I call pm_runtime_put_sync and pm_runtime_get_sync based on the core domain
state then
the USB connect/reset interrupt is not triggered once the core hits off.
In omap3_enter_idle_bm() the
Re: [PATCH 8/9 v3] usb : musb: Using runtime pm apis for musb.
Felipe Balbi writes: > Hi, > > On Wed, Sep 22, 2010 at 07:30:30PM -0500, Kalliguddi, Hema wrote: >>Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync() >>for enabling/disabling the clocks,sysconfig settings. >> >>Also need to put the USB in force standby and force idle mode when usb not >>used >>and set it back to no idle and no stndby after wakeup. >>For OMAP3 auto idle bit has to be disabled because of the errata.So using >>HWMOD_NO_OCP_AUTOIDLE flag for OMAP3430. [...] >>@@ -2424,13 +2425,16 @@ static int musb_suspend(struct device *d >> * they will even be wakeup-enabled. >> */ >> } >>+ pm_runtime_put_sync(dev); >> >>+#ifndef CONFIG_PM_RUNTIME >> musb_save_context(musb); >> >> if (musb->set_clock) >> musb->set_clock(musb->clock, 0); >> else >> clk_disable(musb->clock); >>+#endif > > I would rather remove these, adding ifdefs is bad :-( Unless other archs > (blackfin, davinci) would have problems if we remove those. I didn't like these #ifdefs either, but davinci doesn't have runtime PM, and I don't think blackfin does either. But, rather than the ifdef here, this could be done with different pointers in struct dev_pm_ops based on the arch. Also, this shouldn't be based on CONFIG_PM_RUNTIME, but rather on the arch. We can still enable runtime PM on davinci for other subsystems (PCI, USB core, etc.) but not have it supported for on-chip devices. 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 v8 3/6] OMAP2430: hwmod data: Add watchdog timer
On Thu, Sep 23, 2010 at 08:02:40PM +0530, Varadarajan, Charulatha wrote:
> +static struct omap_hwmod omap2430_wd_timer2_hwmod = {
> + .name = "wd_timer2",
> + .class = &omap2430_wd_timer_hwmod_class,
> + .main_clk = "mpu_wdt_fck",
Why are we going backwards to naming clocks by source rather than
looking them up by device + connection ?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9 v3] usb: musb: Using omap_device_build for musb device registration
Felipe Balbi writes:
> Hi,
>
> On Wed, Sep 22, 2010 at 07:29:10PM -0500, Kalliguddi, Hema wrote:
>>+#define MAX_OMAP_MUSB_HWMOD_NAME_LEN 16
>
> this isn't used anywhere.
>
>>@@ -75,31 +62,30 @@ static struct musb_hdrc_platform_data mu
>>
>> static u64 musb_dmamask = DMA_BIT_MASK(32);
>>
>>-static struct platform_device musb_device = {
>>- .name = "musb_hdrc",
>>- .id = -1,
>>- .dev = {
>>- .dma_mask = &musb_dmamask,
>>- .coherent_dma_mask = DMA_BIT_MASK(32),
>>- .platform_data = &musb_plat,
>>+static struct omap_device_pm_latency omap_musb_latency[] = {
>>+ {
>>+ .deactivate_func = omap_device_idle_hwmods,
>>+ .activate_func = omap_device_enable_hwmods,
>>+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
>> },
>>- .num_resources = ARRAY_SIZE(musb_resources),
>>- .resource = musb_resources,
>> };
>>
>> void __init usb_musb_init(struct omap_musb_board_data *board_data)
>> {
>>- if (cpu_is_omap243x()) {
>>- musb_resources[0].start = OMAP243X_HS_BASE;
>>- } else if (cpu_is_omap34xx()) {
>>- musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
>>- } else if (cpu_is_omap44xx()) {
>>- musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
>>- musb_resources[1].start = OMAP44XX_IRQ_HS_USB_MC_N;
>>- musb_resources[2].start = OMAP44XX_IRQ_HS_USB_DMA_N;
>>+ struct omap_hwmod *oh;
>>+ struct omap_device *od;
>>+ struct platform_device *pdev;
>>+ struct device *dev;
>>+ int bus_id = -1;
>>+ const char *oh_name = "usb_otg_hs";
>>+ struct musb_hdrc_platform_data *pdata;
>>+
>>+ oh = omap_hwmod_lookup(oh_name);
>>+
>>+ if (!oh) {
>>+ pr_err("Could not look up %s\n", oh_name);
>>+ return;
>> }
>
> Paul, Kevin, to me it looks like a duplication that all devices will
> have to:
>
> oh = omap_hwmod_lookup("my_hwmod_name");
> omap_device_build("my_device_name", bus_id, oh, pdata, sizeof(*pdata));
>
> could the omap_hwmod_lookup() part be moved to omap_device_build ? Or
> maybe create a omap_hwmod_lookup_and_build(oh_name, dev_name, bus_id,
> pdata, sizeof(*pdata)) ??
I don't think that this is too much extra work.
Also, many drivers are not doing a single hwmod lookup, they are using
an iterator to iterate over a bunch of hwmods in a given class (c.f.
omap_hwmod_for_each_by_class)
So, IMO, keeping the lookup and build separate is better.
>>@@ -110,8 +96,23 @@ void __init usb_musb_init(struct omap_mu
>> musb_plat.mode = board_data->mode;
>> musb_plat.extvbus = board_data->extvbus;
>>
>>- if (platform_device_register(&musb_device) < 0)
>>- printk(KERN_ERR "Unable to register HS-USB (MUSB) device\n");
>>+ pdata = &musb_plat;
>>+
>>+ od = omap_device_build(name, bus_id, oh, pdata,
>>+sizeof(struct musb_hdrc_platform_data),
>
> use sizeof(*pdata), if we change the name of that structure (very
> unlikely, but still) it'll avoid unwanted compile breakage.
>
>>+ pdev = &od->pdev;
>>+ dev = &pdev->dev;
>>+ get_device(dev);
>>+ dev->dma_mask = &musb_dmamask;
>>+ dev->coherent_dma_mask = musb_dmamask;
>>+ put_device(dev);
>
> I think this is also a duplication, it's gonna on all hwmod device
> registration, no ?
Only for devices setting DMA masks.
This is no more duplication than we have today for all platform_devices.
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 v2 1/6] SoC Camera: add driver for OMAP1 camera interface
Thursday 23 September 2010 15:33:54 Guennadi Liakhovetski napisał(a):
> On Wed, 22 Sep 2010, Janusz Krzysztofik wrote:
> > Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
> > > On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
> > > > +
> > > > + vb = &buf->vb;
> > > > + if (waitqueue_active(&vb->done)) {
> > > > + if (!pcdev->ready && result != VIDEOBUF_ERROR)
> > > > + /*
> > > > +* No next buffer has been entered into the DMA
> > > > +* programming register set on time, so best we
> > > > can do
> > > > +* is stopping the capture before last DMA
> > > > block,
> > > > +* whether our CONTIG mode whole buffer or its
> > > > last
> > > > +* sgbuf in SG mode, gets overwritten by next
> > > > frame.
> > > > +*/
> > >
> > > Hm, why do you think it's a good idea? This specific buffer completed
> > > successfully, but you want to fail it just because the next buffer is
> > > missing? Any specific reason for this?
> >
> > Maybe my comment is not clear enough, but the below suspend_capture()
> > doesn't indicate any failure on a frame just captured. It only prevents
> > the frame from being overwritten by the already autoreinitialized DMA
> > engine, pointing back to the same buffer once again.
> >
> > > Besides, you seem to also be
> > > considering the possibility of your ->ready == NULL, but the queue
> > > non-empty, in which case you just take the next buffer from the queue
> > > and continue with it. Why error out in this case?
> >
> > pcdev->ready == NULL means no buffer was available when it was time to
> > put it into the DMA programming register set.
>
> But how? Buffers are added onto the list in omap1_videobuf_queue() under
> spin_lock_irqsave(); and there you also check ->ready and fill it in.
Guennadi,
Yes, but only if pcdev->active is NULL, ie. both DMA and FIFO are idle, never
if active:
+ list_add_tail(&vb->queue, &pcdev->capture);
+ vb->state = VIDEOBUF_QUEUED;
+
+ if (pcdev->active)
+ return;
Since the transfer of the DMA programming register set content to the DMA
working register set is done automatically by the DMA hardware, this can
pretty well happen while I keep the lock here, so I can't be sure if it's not
too late for entering new data into the programming register set. Then, I
decided that this operation should be done only just after the DMA interrupt
occured, ie. the current DMA programming register set content has just been
used and can be overwriten.
I'll emphasize the above return; with a comment.
> In
> your completion you set ->ready = NULL, but then also call
> prepare_next_vb() to get the next buffer from the list - if there are any,
> so, how can it be NULL with a non-empty list?
It happens after the above mentioned prepare_next_vb() gets nothing from an
empty queue, so nothing is entered into the DMA programming register set,
only the last, just activated, buffer is processed, then
omap1_videobuf_queue() puts a new buffer into the queue while the active
buffer is still filled in, and finally the DMA ISR is called on this last
active buffer completion.
I hope this helps.
> > As a result, a next DMA transfer has
> > just been autoreinitialized with the same buffer parameters as before. To
> > protect the buffer from being overwriten unintentionally, we have to stop
> > the DMA transfer as soon as possible, hopefully before the sensor starts
> > sending out next frame data.
> >
> > If a new buffer has been queued meanwhile, best we can do is stopping
> > everything, programming the DMA with the new buffer, and setting up for a
> > new transfer hardware auto startup on nearest frame start, be it the next
> > one if we are lucky enough, or one after the next if we are too slow.
> >
> > > And even if also the queue
> > > is empty - still not sure, why.
> >
> > I hope the above explanation clarifies why.
> >
> > I'll try to rework the above comment to be more clear, OK? Any hints?
> >
> > > > linux-2.6.36-rc3.orig/include/media/omap1_camera.h 2010-09-03
> > > > 22:34:02.0 +0200 +++
> > > > linux-2.6.36-rc3/include/media/omap1_camera.h 2010-09-08
> > > > 23:41:12.0 +0200 @@ -0,0 +1,35 @@
> > > > +/*
> > > > + * Header for V4L2 SoC Camera driver for OMAP1 Camera Interface
> > > > + *
> > > > + * Copyright (C) 2010, Janusz Krzysztofik
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or
> > > > modify + * it under the terms of the GNU General Public License
> > > > version 2 as + * published by the Free Software Foundation.
> > > > + */
> > > > +
> > > > +#ifndef __MEDIA_OMAP1_CAMERA_H_
> > > > +#define __MEDIA_OMAP1_CAMERA_H_
> > > > +
> > > > +#include
> > > > +
> > > > +#define OMAP1_CAMERA_IOSIZE0x1c
> > > > +
> > > > +enum omap1_cam_vb_mode {
> >
Re: [PATCH v3] power: introduce library for device-specific OPPs
Nishanth Menon writes: > Rafael J. Wysocki had written, on 09/22/2010 07:03 PM, the following: >> [Trimming the CC list slightly.] > [...] > >> ... >> >> First, thanks for addressing the previous comments, things look much better >> now. In particular the documentation has been improved a lot in my view. > Thanks for the excellent reviews :) > > [...] > >>> + >>> +WARNING on OPP List Modification Vs Query operations: >>> + >>> +The OPP layer's query functions are expected to be used in multiple >>> contexts >>> +(including calls from interrupt locked context) based on SoC framework >>> +implementation. Only OPP modification functions are guaranteed exclusivity >>> by >>> +the OPP library. Exclusivity between query functions and modification >>> functions >>> +should be handled by the users such as the SoC framework appropriately; >>> else, >>> +there is a risk for the query functions to retrieve stale data. >> >> Well, this sounds like a good use case for RCU. > Kevin did point out rwlock but am I confusing with > http://lwn.net/Articles/364583/ > If I get the message right, rwlock is more or less on it's way out? RCU is different from the reader-writer locks that are on their way out. Let's think about RCU a little more and see if it might be worth using. As these APIs are infrequencly accessed, I'm thinking a single spinlock to protect the whole list from concurrent access/modification is sufficient. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 4/6] OMAP4: hwmod data: Add watchdog timer
From: Benoit Cousson
Add watchdog timer hwmod data for OMAP4 chip
Note: wd_timer3 in enabled in the hwmod list but it is
not yet supported by the watchdog driver.
Signed-off-by: Benoit Cousson
Signed-off-by: Charulatha V
---
This patch is extracted from the below patch sent by Benoit
https://patchwork.kernel.org/patch/117347/
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 135
1 files changed, 135 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 e20b0ee..8660fea 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -452,6 +452,136 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_wd_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_wd_timer_hwmod_class = {
+ .name = "wd_timer",
+ .sysc = &omap44xx_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod omap44xx_wd_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_wd_timer2_irqs[] = {
+ { .irq = 80 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_wd_timer2_addrs[] = {
+ {
+ .pa_start = 0x4a314000,
+ .pa_end = 0x4a31407f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> wd_timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__wd_timer2 = {
+ .master = &omap44xx_l4_wkup_hwmod,
+ .slave = &omap44xx_wd_timer2_hwmod,
+ .clk= "l4_wkup_clk_mux_ck",
+ .addr = omap44xx_wd_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_wd_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* wd_timer2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_wd_timer2_slaves[] = {
+ &omap44xx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
+ .name = "wd_timer2",
+ .class = &omap44xx_wd_timer_hwmod_class,
+ .mpu_irqs = omap44xx_wd_timer2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_wd_timer2_irqs),
+ .main_clk = "wd_timer2_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_WDT2_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_wd_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* wd_timer3 */
+static struct omap_hwmod omap44xx_wd_timer3_hwmod;
+static struct omap_hwmod_irq_info omap44xx_wd_timer3_irqs[] = {
+ { .irq = 36 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_wd_timer3_addrs[] = {
+ {
+ .pa_start = 0x4013,
+ .pa_end = 0x4013007f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe -> wd_timer3 */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__wd_timer3 = {
+ .master = &omap44xx_l4_abe_hwmod,
+ .slave = &omap44xx_wd_timer3_hwmod,
+ .clk= "ocp_abe_iclk",
+ .addr = omap44xx_wd_timer3_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_wd_timer3_addrs),
+ .user = OCP_USER_MPU,
+};
+
+/* l4_abe -> wd_timer3 (dma) */
+static struct omap_hwmod_addr_space omap44xx_wd_timer3_dma_addrs[] = {
+ {
+ .pa_start = 0x4903,
+ .pa_end = 0x4903007f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__wd_timer3_dma = {
+ .master = &omap44xx_l4_abe_hwmod,
+ .slave = &omap44xx_wd_timer3_hwmod,
+ .clk= "ocp_abe_iclk",
+ .addr = omap44xx_wd_timer3_dma_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_wd_timer3_dma_addrs),
+ .user = OCP_USER_SDMA,
+};
+
+/* wd_timer3 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_wd_timer3_slaves[] = {
+ &omap44xx_l4_abe__wd_timer3,
+ &omap44xx_l4_abe__wd_timer3_dma,
+};
+
+static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
+ .name = "wd_timer3",
+ .class = &omap44xx_wd_timer_hwmod_class,
+ .mpu_irqs = omap44xx_wd_timer3_irqs,
+
[PATCH v8 1/6] OMAP3: hwmod data: Add watchdog timer
Add watchdog timer hwmod data for OMAP3 chip
Signed-off-by: Charulatha V
Acked-by: Cousson, Benoit
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66
1 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..5bfe9c9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -21,6 +21,7 @@
#include "omap_hwmod_common_data.h"
#include "prm-regbits-34xx.h"
+#include "cm-regbits-34xx.h"
/*
* OMAP3xxx hardware module integration data
@@ -36,6 +37,7 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
+static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -197,6 +199,69 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
};
+/* l4_wkup -> wd_timer2 */
+static struct omap_hwmod_addr_space omap3xxx_wd_timer2_addrs[] = {
+ {
+ .pa_start = 0x48314000,
+ .pa_end = 0x4831407f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__wd_timer2 = {
+ .master = &omap3xxx_l4_wkup_hwmod,
+ .slave = &omap3xxx_wd_timer2_hwmod,
+ .clk= "wdt2_ick",
+ .addr = omap3xxx_wd_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_wd_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_wd_timer_hwmod_class = {
+ .name = "wd_timer",
+ .sysc = &omap3xxx_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod_ocp_if *omap3xxx_wd_timer2_slaves[] = {
+ &omap3xxx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap3xxx_wd_timer2_hwmod = {
+ .name = "wd_timer2",
+ .class = &omap3xxx_wd_timer_hwmod_class,
+ .main_clk = "wdt2_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_WDT2_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_ST_WDT2_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_wd_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l3_main_hwmod,
&omap3xxx_l4_core_hwmod,
@@ -204,6 +269,7 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l4_wkup_hwmod,
&omap3xxx_mpu_hwmod,
&omap3xxx_iva_hwmod,
+ &omap3xxx_wd_timer2_hwmod,
NULL,
};
--
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 v8 3/6] OMAP2430: hwmod data: Add watchdog timer
Add watchdog timer hwmod data for OMAP2430 chip
Signed-off-by: Charulatha V
Acked-by: Cousson, Benoit
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 64
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4526628..7ec927a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -19,6 +19,7 @@
#include "omap_hwmod_common_data.h"
#include "prm-regbits-24xx.h"
+#include "cm-regbits-24xx.h"
/*
* OMAP2430 hardware module integration data
@@ -33,6 +34,7 @@ static struct omap_hwmod omap2430_mpu_hwmod;
static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
+static struct omap_hwmod omap2430_wd_timer2_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -165,12 +167,74 @@ static struct omap_hwmod omap2430_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
};
+/* l4_wkup -> wd_timer2 */
+static struct omap_hwmod_addr_space omap2430_wd_timer2_addrs[] = {
+ {
+ .pa_start = 0x49016000,
+ .pa_end = 0x4901607f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__wd_timer2 = {
+ .master = &omap2430_l4_wkup_hwmod,
+ .slave = &omap2430_wd_timer2_hwmod,
+ .clk= "mpu_wdt_ick",
+ .addr = omap2430_wd_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_wd_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_wd_timer_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_wd_timer_hwmod_class = {
+ .name = "wd_timer",
+ .sysc = &omap2430_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod_ocp_if *omap2430_wd_timer2_slaves[] = {
+ &omap2430_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap2430_wd_timer2_hwmod = {
+ .name = "wd_timer2",
+ .class = &omap2430_wd_timer_hwmod_class,
+ .main_clk = "mpu_wdt_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MPU_WDT_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MPU_WDT_SHIFT,
+ },
+ },
+ .slaves = omap2430_wd_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_wd_timer2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+};
+
static __initdata struct omap_hwmod *omap2430_hwmods[] = {
&omap2430_l3_main_hwmod,
&omap2430_l4_core_hwmod,
&omap2430_l4_wkup_hwmod,
&omap2430_mpu_hwmod,
&omap2430_iva_hwmod,
+ &omap2430_wd_timer2_hwmod,
NULL,
};
--
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 v8 2/6] OMAP2420: hwmod data: Add watchdog timer
Add watchdog timer hwmod data for OMAP2420 chip
Signed-off-by: Charulatha V
Acked-by: Cousson, Benoit
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 64
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 3cc768e..66678d9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -19,6 +19,7 @@
#include "omap_hwmod_common_data.h"
#include "prm-regbits-24xx.h"
+#include "cm-regbits-24xx.h"
/*
* OMAP2420 hardware module integration data
@@ -33,6 +34,7 @@ static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_wd_timer2_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -165,12 +167,74 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
+/* l4_wkup -> wd_timer2 */
+static struct omap_hwmod_addr_space omap2420_wd_timer2_addrs[] = {
+ {
+ .pa_start = 0x48022000,
+ .pa_end = 0x4802207f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__wd_timer2 = {
+ .master = &omap2420_l4_wkup_hwmod,
+ .slave = &omap2420_wd_timer2_hwmod,
+ .clk= "mpu_wdt_ick",
+ .addr = omap2420_wd_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_wd_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_wd_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_wd_timer_hwmod_class = {
+ .name = "wd_timer",
+ .sysc = &omap2420_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod_ocp_if *omap2420_wd_timer2_slaves[] = {
+ &omap2420_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap2420_wd_timer2_hwmod = {
+ .name = "wd_timer2",
+ .class = &omap2420_wd_timer_hwmod_class,
+ .main_clk = "mpu_wdt_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MPU_WDT_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MPU_WDT_SHIFT,
+ },
+ },
+ .slaves = omap2420_wd_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_wd_timer2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_l3_main_hwmod,
&omap2420_l4_core_hwmod,
&omap2420_l4_wkup_hwmod,
&omap2420_mpu_hwmod,
&omap2420_iva_hwmod,
+ &omap2420_wd_timer2_hwmod,
NULL,
};
--
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 v8 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings instead of using
clock FW APIs.
Signed-off-by: Charulatha V
Acked-by: Cousson, Benoit
---
drivers/watchdog/omap_wdt.c | 42 +++---
1 files changed, 7 insertions(+), 35 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 76b58ab..dbbc580 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -38,11 +38,11 @@
#include
#include
#include
-#include
#include
#include
#include
#include
+#include
#include
#include
@@ -61,8 +61,6 @@ struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
int omap_wdt_users;
- struct clk *ick;
- struct clk *fck;
struct resource *mem;
struct miscdevice omap_wdt_miscdev;
};
@@ -146,8 +144,7 @@ static int omap_wdt_open(struct inode *inode, struct file
*file)
if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
return -EBUSY;
- clk_enable(wdev->ick);/* Enable the interface clock */
- clk_enable(wdev->fck);/* Enable the functional clock */
+ pm_runtime_get_sync(wdev->dev);
/* initialize prescaler */
while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
@@ -177,8 +174,7 @@ static int omap_wdt_release(struct inode *inode, struct
file *file)
omap_wdt_disable(wdev);
- clk_disable(wdev->ick);
- clk_disable(wdev->fck);
+ pm_runtime_put_sync(wdev->dev);
#else
printk(KERN_CRIT "omap_wdt: Unexpected close, not stopping!\n");
#endif
@@ -292,19 +288,7 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
wdev->omap_wdt_users = 0;
wdev->mem = mem;
-
- wdev->ick = clk_get(&pdev->dev, "ick");
- if (IS_ERR(wdev->ick)) {
- ret = PTR_ERR(wdev->ick);
- wdev->ick = NULL;
- goto err_clk;
- }
- wdev->fck = clk_get(&pdev->dev, "fck");
- if (IS_ERR(wdev->fck)) {
- ret = PTR_ERR(wdev->fck);
- wdev->fck = NULL;
- goto err_clk;
- }
+ wdev->dev = &pdev->dev;
wdev->base = ioremap(res->start, resource_size(res));
if (!wdev->base) {
@@ -314,8 +298,8 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, wdev);
- clk_enable(wdev->ick);
- clk_enable(wdev->fck);
+ pm_runtime_enable(wdev->dev);
+ pm_runtime_get_sync(wdev->dev);
omap_wdt_disable(wdev);
omap_wdt_adjust_timeout(timer_margin);
@@ -333,11 +317,7 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
__raw_readl(wdev->base + OMAP_WATCHDOG_REV) & 0xFF,
timer_margin);
- /* autogate OCP interface clock */
- __raw_writel(0x01, wdev->base + OMAP_WATCHDOG_SYS_CONFIG);
-
- clk_disable(wdev->ick);
- clk_disable(wdev->fck);
+ pm_runtime_put_sync(wdev->dev);
omap_wdt_dev = pdev;
@@ -349,12 +329,6 @@ err_misc:
err_ioremap:
wdev->base = NULL;
-
-err_clk:
- if (wdev->ick)
- clk_put(wdev->ick);
- if (wdev->fck)
- clk_put(wdev->fck);
kfree(wdev);
err_kzalloc:
@@ -386,8 +360,6 @@ static int __devexit omap_wdt_remove(struct platform_device
*pdev)
release_mem_region(res->start, resource_size(res));
platform_set_drvdata(pdev, NULL);
- clk_put(wdev->ick);
- clk_put(wdev->fck);
iounmap(wdev->base);
kfree(wdev);
--
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 v8 5/6] OMAP: WDT: Split OMAP1 and OMAP2PLUS device registration
This patch splits omap_init_wdt() into separate omap_init_wdt()
functions under mach-omap1 and mach-omap2 and set them up with
subsys_initcall.
Also it uses omap_device_build() API instead of
platform_device_register() for watchdog timer device registration
for OMAP2plus chips.
For OMAP2plus chips, the device specific data defined in centralized
hwmod database will be used.
Signed-off-by: Charulatha V
Acked-by: Cousson, Benoit
---
arch/arm/mach-omap1/devices.c | 27 +++
arch/arm/mach-omap2/devices.c | 39 +++
arch/arm/plat-omap/devices.c | 41 -
3 files changed, 66 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index aa07256..39447fa 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -232,3 +232,30 @@ static int __init omap1_init_devices(void)
}
arch_initcall(omap1_init_devices);
+#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
+
+static struct resource wdt_resources[] = {
+ {
+ .start = 0xfffeb000,
+ .end= 0xfffeb07F,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_wdt_device = {
+ .name = "omap_wdt",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(wdt_resources),
+ .resource = wdt_resources,
+};
+
+static int __init omap_init_wdt(void)
+{
+ if (!cpu_is_omap16xx())
+ return;
+
+ platform_device_register(&omap_wdt_device);
+ return 0;
+}
+subsys_initcall(omap_init_wdt);
+#endif
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..439bfb3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,8 @@
#include
#include
#include
+#include
+#include
#include "mux.h"
@@ -859,3 +862,39 @@ static int __init omap2_init_devices(void)
return 0;
}
arch_initcall(omap2_init_devices);
+
+#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
+struct omap_device_pm_latency omap_wdt_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int __init omap_init_wdt(void)
+{
+ int id = -1;
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ char *oh_name = "wd_timer2";
+ char *dev_name = "omap_wdt";
+
+ if (!cpu_class_is_omap2())
+ return 0;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("Could not look up wd_timer%d hwmod\n", id);
+ return -EINVAL;
+ }
+
+ od = omap_device_build(dev_name, id, oh, NULL, 0,
+ omap_wdt_latency,
+ ARRAY_SIZE(omap_wdt_latency), 0);
+ WARN(IS_ERR(od), "Cant build omap_device for %s:%s.\n",
+ dev_name, oh->name);
+ return 0;
+}
+subsys_initcall(omap_init_wdt);
+#endif
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index d1920be..8e88e0e 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -232,46 +232,6 @@ static void omap_init_uwire(void)
static inline void omap_init_uwire(void) {}
#endif
-/*-*/
-
-#ifdefined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-
-static struct resource wdt_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap_wdt_device = {
- .name = "omap_wdt",
- .id = -1,
- .num_resources = ARRAY_SIZE(wdt_resources),
- .resource = wdt_resources,
-};
-
-static void omap_init_wdt(void)
-{
- if (cpu_is_omap16xx())
- wdt_resources[0].start = 0xfffeb000;
- else if (cpu_is_omap2420())
- wdt_resources[0].start = 0x48022000; /* WDT2 */
- else if (cpu_is_omap2430())
- wdt_resources[0].start = 0x49016000; /* WDT2 */
- else if (cpu_is_omap343x())
- wdt_resources[0].start = 0x48314000; /* WDT2 */
- else if (cpu_is_omap44xx())
- wdt_resources[0].start = 0x4a314000;
- else
- return;
-
- wdt_resources[0].end = wdt_resources[0].start + 0x4f;
-
- (void) platform_device_register(&omap_wdt_device);
-}
-#else
-static inline void omap_init_wdt(void) {}
-#endif
-
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like
[PATCH v8 0/6] OMAP: WDT: Implement WDT in hwmod way
Series of patches to port watchdog module to use hwmod APIs for OMAP2PLUS chips and use runtime APIs for all OMAP chips. For this hwmod database for OMAP2PLUS watchdog instances are populated and implements watchdog module to use PM runtime APIs. This patch series is generated on "origin/pm-core" which has Kevin's pm-next series, the runtime PM core patch series, and a collection of hwmod fixes that Paul/Benoit have lined up for 2.6.37. Tested on OMAP2430, OMAP4430 (ES1.0 & ES2.0), OMAP3430 SDP boards and zoom3 board. Also verified that this patch series does not break the OMAP1 build. This series is tested on OMAP4430 ES2 using the below series (dependency series for ES2.0 silicon) http://www.spinics.net/lists/linux-omap/msg36023.html Version History: --- Version v8: *Enable wd_timer3 in the hwmod list Version v7: *Use EN_*SHIFT macros for module_bit and ST_*SHIFT macros for idlest_idle_bit in OMAP2&3 hwmod database (based on suggestions given by Paul for I2C hwmod series) *Remove new definitions of EN_*SHIFT macros as they already exist Some of the v7 links: https://patchwork.kernel.org/patch/197022/ Version v6: *Split omap_init_wdt() into separate omap_init_wdt functions under mach-omap1 and mach-omap2 and set them up with subsys_initcall *Include wd_timer3 database for OMAP4 *In hwmod database follow naming convention "wd_timerX" Some of the v6 links: http://www.spinics.net/lists/linux-omap/msg36678.html https://patchwork.kernel.org/patch/188242/ https://patchwork.kernel.org/patch/188222/ Version v5: *Delete wdt_runtime_resume and wdt_runtime_suspend functions as the fix for the return values in the generic runtime PM calls has been queued for 2.6.37 (see below link) https://lists.linux-foundation.org/pipermail/linux-pm/2010-September/028466.html Some of the v5 links: https://patchwork.kernel.org/patch/181812/ https://patchwork.kernel.org/patch/181782/ https://patchwork.kernel.org/patch/181772/ https://patchwork.kernel.org/patch/181792/ Version v4: *Implement hwmod adapdation first and then PM runtime adaptation as two different patches in the series *Remove inclusion of omap_device.h in the driver file. Some of the v4 links: https://patchwork.kernel.org/patch/174672/ https://patchwork.kernel.org/patch/174662/ Version v3: *Fix Minor comments like renaming omap1 watchdog structures with an omap1_ prefix Some of the v3 links: https://patchwork.kernel.org/patch/119698/ https://patchwork.kernel.org/patch/119696/ Version v2: *Rebase to latest kernel Some of the v2 links: http://www.spinics.net/lists/linux-omap/msg34741.html http://www.spinics.net/lists/linux-omap/msg34673.html Version v1: *Initial series Some of the v1 links: http://www.spinics.net/lists/linux-omap/msg30628.html http://www.spinics.net/lists/linux-omap/msg30625.html Benoit Cousson (1): OMAP4: hwmod data: Add watchdog timer Varadarajan, Charulatha (5): OMAP3: hwmod data: Add watchdog timer OMAP2420: hwmod data: Add watchdog timer OMAP2430: hwmod data: Add watchdog timer OMAP2PLUS: WDT: use omap_device_build for device registration OMAP: WDT: Use PM runtime APIs instead of clk FW APIs arch/arm/mach-omap1/devices.c | 27 ++ arch/arm/mach-omap2/devices.c | 39 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 64 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 64 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 135 arch/arm/plat-omap/devices.c | 41 - drivers/watchdog/omap_wdt.c| 42 ++--- 8 files changed, 402 insertions(+), 76 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 2/2] OMAP4: PRCM: Fix usage of prm/cm accessor api's for OMAP4
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Nayak, Rajendra > Sent: Tuesday, August 10, 2010 8:33 PM > To: linux-omap@vger.kernel.org > Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Nayak, > Rajendra > Subject: [RFC][PATCH 2/2] OMAP4: PRCM: Fix usage of prm/cm accessor api's for > OMAP4 > > OMAP's have always had PRCM split into PRM for power and reset > management and CM for clock management. > In OMAP4 the split (physically) is not very straight forward and > there are instances of clock management control registers in PRM > and vice versa. > However it still makes sense, even on OMAP4 to logically split > PRCM into PRM and CM for better understanding and to avoid adding > additonal complexity in higher level frameworks which rely on the > accessor api;s to do the low level register accesses. > > Hence this patch makes sure that any clock management code can > use the cm_read/write* accessor apis (without knowing the physical split) > and power and reset management code can use prm_read/write* > accessor api;s. > > To do this the submodule offsets within PRM/CM1 and CM2 have additonal > info embedded in them specifying what base address to use while > trying to access registers in the given submodule. > > The 16 bit signed submodule offset is defined for OMAP4 as > || > | | > > For older OMAP's the base identifier is always set to 0. Hi Paul, Any thoughts on this patch/approach? Regards, Rajendra > > Signed-off-by: Rajendra Nayak > Cc: Kevin Hilman > Cc: Paul Walmsley > Cc: Benoit Cousson > --- > arch/arm/mach-omap2/cm.h |4 +- > arch/arm/mach-omap2/prcm-common.h | 58 -- > - > arch/arm/mach-omap2/prcm.c| 68 > ++-- > arch/arm/mach-omap2/prm.h |4 +- > 4 files changed, 105 insertions(+), 29 deletions(-) > > diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h > index a02ca30..7b7ef09 100644 > --- a/arch/arm/mach-omap2/cm.h > +++ b/arch/arm/mach-omap2/cm.h > @@ -23,9 +23,9 @@ > #define OMAP34XX_CM_REGADDR(module, reg) \ > OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE + (module) + > (reg)) > #define OMAP44XX_CM1_REGADDR(module, reg)\ > - OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + (module) + > (reg)) > + OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + ((module) & > (MOD_MASK)) + (reg)) > #define OMAP44XX_CM2_REGADDR(module, reg)\ > - OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + (module) + > (reg)) > + OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + ((module) & > (MOD_MASK)) + (reg)) > > #include "cm44xx.h" > > diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm- > common.h > index 995b7ed..b93d33e 100644 > --- a/arch/arm/mach-omap2/prcm-common.h > +++ b/arch/arm/mach-omap2/prcm-common.h > @@ -57,10 +57,26 @@ > #define BITFIELD(l_bit, u_bit) \ > (BITS(u_bit) & ~((BITS(l_bit)) >> 1)) > > -/* OMAP44XX specific module offsets */ > +/* > + * OMAP44XX specific module offsets > + * The 16 bit submodule offset is defined for OMAP4 as > + * || > + * | | > + */ > > -/* CM1 instances */ > +#define DEFAULT_BASE 0x0 > +#define PRM_BASE 0x1 > +#define PRCM_MPU_BASE0x2 > +#define CM2_BASE 0x3 > > +#define BASE_ID_SHIFT13 > +#define MOD_MASK ((1 << BASE_ID_SHIFT)-1) > + > +#define PRM_BASE_ID (PRM_BASE << BASE_ID_SHIFT) > +#define PRCM_MPU_BASE_ID (PRCM_MPU_BASE << BASE_ID_SHIFT) > +#define CM2_BASE_ID (CM2_BASE << BASE_ID_SHIFT) > + > +/* CM1 instances */ > #define OMAP4430_CM1_OCP_SOCKET_MOD 0x > #define OMAP4430_CM1_CKGEN_MOD 0x0100 > #define OMAP4430_CM1_MPU_MOD 0x0300 > @@ -71,19 +87,19 @@ > > /* CM2 instances */ > > -#define OMAP4430_CM2_OCP_SOCKET_MOD 0x > -#define OMAP4430_CM2_CKGEN_MOD 0x0100 > -#define OMAP4430_CM2_ALWAYS_ON_MOD 0x0600 > -#define OMAP4430_CM2_CORE_MOD0x0700 > -#define OMAP4430_CM2_IVAHD_MOD 0x0f00 > -#define OMAP4430_CM2_CAM_MOD 0x1000 > -#define OMAP4430_CM2_DSS_MOD 0x1100 > -#define OMAP4430_CM2_GFX_MOD 0x1200 > -#define OMAP4430_CM2_L3INIT_MOD 0x1300 > -#define OMAP4430_CM2_L4PER_MOD 0x1400 > -#define OMAP4430_CM2_CEFUSE_MOD 0x1600 > -#define OMAP4430_CM2_RESTORE_MOD 0x1e00 > -#define OMAP4430_CM2_INSTR_MOD 0x1f00 > +#define OMAP4430_CM2_OCP_SOCKET_MOD 0x | CM2_BASE_ID > +#define OMAP4430_CM2_CKGEN_MOD 0x0100 | CM2_BASE_ID > +#define OMAP4430_CM2_ALWAYS_ON_MOD 0x0600 | CM2_BASE_ID > +#define OMAP4430_CM2_CORE_MOD0x0700 | CM2_BASE_ID > +#define OMAP4430_CM2_IVAHD_MOD
Re: [PATCH v2] omap: beagle: add support for wl1271 on the board file
On Thu, Sep 23, 2010 at 7:52 AM, Luciano Coelho wrote: > On Thu, 2010-09-23 at 14:03 +0200, ext Robert Nelson wrote: >> On Thu, Sep 23, 2010 at 5:30 AM, Grazvydas Ignotas wrote: >> > On Thu, Sep 23, 2010 at 11:20 AM, Luciano Coelho >> > wrote: >> >> Add board configuration for the wl1271 daughter board. This patch is >> >> based >> >> on Ohad Ben-Cohen's patches for Zoom boards. >> > >> > Hm can that daughter board be detected? With your patch all beagle >> > users will get GPIO139 toggled, and if someone has that wired to >> > chainsaw switch somebody might get hurt. >> >> Expansion boards really need to follow: >> >> http://elinux.org/BeagleBoardPinMux#Expansion_boards >> >> Is there any eeprom on i2c bus #2 for identification on this board? > > Hmmm... > > Yes, it does. :) This makes perfect sense. > > My bootloader (U-Boot 2010.03) doesn't seem to detect it, though: > > > Probing for expansion boards, if none are connected you'll see a > harmless I2C error. > > No EEPROM on expansion board > I'd first add the board to the list on the wiki to protect the expansion board id. Here's the current patch for u-boot for these expansion boards, it only implements id's for the boards listed at the time. http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=95993d1fee62ef64b2f58c1e186176ca9033c35e > Do I need a special bootloader? > > Is there any standard way to recognize the expansion board and configure > it properly? Yeap, you need a special bootloader, which is a downside to the current implementation... It relies on u-boot to do the i2c probing and detect which expansion board is connected, it would be nice if the kernel could do it on it's own.. So currently u-boot probes, then notifies the kernel thru a "buddy" variable that gets passed with the bootargs.. board-omap3beagle.c then parse's the "buddy" variable to setup the expansion device, like as shown for the zippy1/2 expansion boards: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/0007-ARM-OMAP-beagleboard-Add-infrastructure-to-do-fixups.patch (note there are patches applied before this and after, so it's won't apply cleanly to mainline) Regards, -- Robert Nelson http://www.rcn-ee.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 v2 1/6] SoC Camera: add driver for OMAP1 camera interface
On Wed, 22 Sep 2010, Janusz Krzysztofik wrote:
> Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
> > On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
> > > +
> > > + vb = &buf->vb;
> > > + if (waitqueue_active(&vb->done)) {
> > > + if (!pcdev->ready && result != VIDEOBUF_ERROR)
> > > + /*
> > > + * No next buffer has been entered into the DMA
> > > + * programming register set on time, so best we can do
> > > + * is stopping the capture before last DMA block,
> > > + * whether our CONTIG mode whole buffer or its last
> > > + * sgbuf in SG mode, gets overwritten by next frame.
> > > + */
> >
> > Hm, why do you think it's a good idea? This specific buffer completed
> > successfully, but you want to fail it just because the next buffer is
> > missing? Any specific reason for this?
>
> Maybe my comment is not clear enough, but the below suspend_capture() doesn't
> indicate any failure on a frame just captured. It only prevents the frame
> from being overwritten by the already autoreinitialized DMA engine, pointing
> back to the same buffer once again.
>
> > Besides, you seem to also be
> > considering the possibility of your ->ready == NULL, but the queue
> > non-empty, in which case you just take the next buffer from the queue and
> > continue with it. Why error out in this case?
>
> pcdev->ready == NULL means no buffer was available when it was time to put it
> into the DMA programming register set.
But how? Buffers are added onto the list in omap1_videobuf_queue() under
spin_lock_irqsave(); and there you also check ->ready and fill it in. In
your completion you set ->ready = NULL, but then also call
prepare_next_vb() to get the next buffer from the list - if there are any,
so, how can it be NULL with a non-empty list?
> As a result, a next DMA transfer has
> just been autoreinitialized with the same buffer parameters as before. To
> protect the buffer from being overwriten unintentionally, we have to stop the
> DMA transfer as soon as possible, hopefully before the sensor starts sending
> out next frame data.
>
> If a new buffer has been queued meanwhile, best we can do is stopping
> everything, programming the DMA with the new buffer, and setting up for a new
> transfer hardware auto startup on nearest frame start, be it the next one if
> we are lucky enough, or one after the next if we are too slow.
>
> > And even if also the queue
> > is empty - still not sure, why.
>
> I hope the above explanation clarifies why.
>
> I'll try to rework the above comment to be more clear, OK? Any hints?
> > > linux-2.6.36-rc3.orig/include/media/omap1_camera.h2010-09-03
> > > 22:34:02.0 +0200 +++
> > > linux-2.6.36-rc3/include/media/omap1_camera.h 2010-09-08
> > > 23:41:12.0 +0200 @@ -0,0 +1,35 @@
> > > +/*
> > > + * Header for V4L2 SoC Camera driver for OMAP1 Camera Interface
> > > + *
> > > + * Copyright (C) 2010, Janusz Krzysztofik
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> > > +
> > > +#ifndef __MEDIA_OMAP1_CAMERA_H_
> > > +#define __MEDIA_OMAP1_CAMERA_H_
> > > +
> > > +#include
> > > +
> > > +#define OMAP1_CAMERA_IOSIZE 0x1c
> > > +
> > > +enum omap1_cam_vb_mode {
> > > + CONTIG = 0,
> > > + SG,
> > > +};
> >
> > See above - are these needed here?
> >
> > > +
> > > +#define OMAP1_CAMERA_MIN_BUF_COUNT(x)((x) == CONTIG ? 3 : 2)
> >
> > ditto
>
> I moved them both over to the header file because I was using the
> OMAP1_CAMERA_MIN_BUF_COUNT(CONTIG) macro once from the platform code in order
> to calculate the buffer size when calling the then NAKed
> dma_preallocate_coherent_memory(). Now I could put them back into the driver
> code, but if we ever get back to the concept of preallocating a contignuos
> piece of memory from the platform init code, we might need them back here, so
> maybe I should rather keep them, only rename the two enum values using a
> distinct name space. What do you think is better for now?
Yeah, up to you, I'd say, but if you decide to keep them in the header,
please, use a namespace.
I'm satisfied with your answers to the rest of my questions / comments:)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] omap: mailbox: fix detection for previously supported chips
Hi Omar,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Omar Ramirez Luna
> Sent: Wednesday, September 22, 2010 7:22 PM
> To: Tony Lindgren; Hiroshi DOYU; Felipe Contreras; Anna, Suman; linux-
> o...@vger.kernel.org
> Cc: Ramirez Luna, Omar
> Subject: [RFC] omap: mailbox: fix detection for previously supported chips
>
> Fix the mailbox support detection for OMAP3630, 3530/25 and 2430.
>
> Signed-off-by: Omar Ramirez Luna
> ---
> - Testing was made under 3630 and 3430 boards.
> - Given that 2430 uses similar initialization than OMAP3, changes
> to handle this case was added to the patch.
> - HWMOD adaptation hopefully should solve this mess, but as of now
> mailbox should work as before at least.
>
> arch/arm/mach-omap2/mailbox.c | 12
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
> index 42dbfa4..26d6fb0 100644
> --- a/arch/arm/mach-omap2/mailbox.c
> +++ b/arch/arm/mach-omap2/mailbox.c
> @@ -394,15 +394,19 @@ static int __devinit omap2_mbox_probe(struct
> platform_device *pdev)
>
> if (false)
> ;
> -#if defined(CONFIG_ARCH_OMAP3430)
> - else if (cpu_is_omap3430()) {
> +#if defined(CONFIG_ARCH_OMAP3)
> + else if (omap3_has_iva()) {
> list = omap3_mboxes;
>
> list[0]->irq = platform_get_irq_byname(pdev, "dsp");
> }
> #endif
> -#if defined(CONFIG_ARCH_OMAP2420)
> - else if (cpu_is_omap2420()) {
> +#if defined(CONFIG_ARCH_OMAP2)
> + else if (cpu_is_omap2430()) {
> + list = omap2_mboxes;
> +
> + list[0]->irq = platform_get_irq_byname(pdev, "dsp");
> + } else if (cpu_is_omap2420()) {
Isn't both 2430 and 2420 doing the exact same?
If yes, How about just doing:
else if (cpu_is_omap2430() || cpu_is_omap2420()) {
> list = omap2_mboxes;
>
> list[0]->irq = platform_get_irq_byname(pdev, "dsp");
Regards,
Sergio
> --
> 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: [PATCH 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Tuesday, September 14, 2010 10:28 PM
> To: Basak, Partha
> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Tero Kristo
> Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of
> interrupts-disabled idle path
>
> "Basak, Partha" writes:
>
> >> From: Kevin Hilman
> >>
> >> Currently, we wait until late in the idle path where interrupts are
> >> disabled to do runtime-PM-like management for certain special-case
> >> devices like GPIO.
> >>
> >> As a prerequiste to moving GPIO to the new runtime PM
> framework, move
> >> this runtime-PM-like code out of the late idle path into new device
> >> idle and resume functions that can be called before interrupts are
> >> disabled by CPUidle and/or suspend.
> >>
> >> In addition, move all the GPIO-specific logic into the GPIO core
> >> instead of keeping GPIO-specific knowledge of power-states, context
> >> saving etc. in the PM core.
> >>
> >> Also, call the new device-idle and -resume methods from CPUidle and
> >> static suspend path.
> >>
> >> Signed-off-by: Kevin Hilman
> >> ---
> >> arch/arm/mach-omap2/cpuidle34xx.c |4 ++
> >> arch/arm/mach-omap2/pm.h |2 +
> >> arch/arm/mach-omap2/pm24xx.c |2 +-
> >> arch/arm/mach-omap2/pm34xx.c | 38
> +
> >> arch/arm/plat-omap/gpio.c | 57
> >>
> >> arch/arm/plat-omap/include/plat/gpio.h |4 +--
> >> 6 files changed, 67 insertions(+), 40 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> >> b/arch/arm/mach-omap2/cpuidle34xx.c
> >> index 0923b82..681d823 100644
> >> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> >> @@ -274,9 +274,13 @@ static int omap3_enter_idle_bm(struct
> >> cpuidle_device *dev,
> >>pwrdm_set_next_pwrst(per_pd, per_next_state);
> >>
> >> select_state:
> >> + omap3_device_idle();
> >> +
> >>dev->last_state = new_state;
> >>ret = omap3_enter_idle(dev, new_state);
> >>
> >> + omap3_device_resume();
> >> +
> > In the generic cpu_idle() in process.c, interrupts are
> already disabled
> > before control comes to cpuidle_idle_call() via pm_idle()
> > local_irq_disable();
> > if (hlt_counter) {
> > local_irq_enable();
> > cpu_relax();
> > } else {
> > stop_critical_timings();
> > pm_idle();
> > start_critical_timings();
> > /*
> > * This will eventually be
> removed - pm_idle
> > * functions should always
> return with IRQs
> > * enabled.
> > */
> > WARN_ON(irqs_disabled());
> > local_irq_enable();
> > }
> >
> > omap3_enter_idle_bm() will be called from inside
> cpuidle_idle_call()
> > via target_state->enter(dev, target_state).
> > So, interrupts are already disabled here.
> >
> > Am I missing something?
>
> You're right.
>
> I knew this was the case for !CPUIDLE setup, but had thought (without
> testing) that the CPUidle core had re-enabled interrupts during the
> governor selection process etc.
>
> While I investigate ways to manage this in CPUidle, the
> following should
> be fine for now to include with $SUBJECT patch.
>
> Kevin
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index 681d823..c5cb9d0 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -245,6 +245,14 @@ static int omap3_enter_idle_bm(struct
> cpuidle_device *dev,
> goto select_state;
> }
>
> + /*
> + * Enable IRQs during the device activity checking and
> idle management.
> + * IRQs are later (re)disabled when entering the actual
> idle function.
> + * Device idle management that is using runtime PM needs to have
> + * interrupts enabled when calling into the runtime PM core.
> + */
> + local_irq_enable();
After put_sync() retuns, there will be a time window where interrupts
are enabled but clocks are disabled before the interrupts are disabled again.
Accessing any register to service a device interrupt coming during this window
will lead to a crash for cases where iclk and fclks are same and we have the
iclk defined as the main_clk as well.
Same argument holds while returning from Idle. We are facing this issue for
OMAP3
GPIO while trying to define the main_clk = interface clock based on your other
commment.
> +
> cx = cpuidle_get_statedata(state);
> core_next_state = cx->core_state;
>
> k
> --
To unsubscribe from this l
