Re: [PATCH-V2 1/3] RTC:s35390a: Add Alarm interrupt support
Hi, please break your lines at 80-characters. Also the [Hiremath, Vaibhav] is unnecessary. On Mon, Aug 23, 2010 at 06:58:42AM +0200, ext Hiremath, Vaibhav wrote: don't you need some locking on the irq handler ? a mutex maybe ? Just wondering... [Hiremath, Vaibhav] Yes definitely we do need locking here, I thought of adding locking mechanism in subsequent patch, does it makes sense? so you add a buggy patch and fix it later ? If you already know it's buggy, why not changing the patch that adds the bug ? -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 broken with 36-rc1
Hi Ameya,
Ameya Palande wrote:
Hi Tomi,
When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
following error messages:
[0.124145] OMAP DSS rev 2.0
[0.124237] OMAP DISPC rev 3.0
[0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
[0.805419] omapfb omapfb: failed to allocate framebuffer
[0.810882] omapfb omapfb: failed to allocate fbmem
[0.815856] omapfb omapfb: failed to setup omapfb
[0.820648] omapfb: probe of omapfb failed with error -12
Can you try this one:
From 28de4496224d1e2ae72dcb5bb52b72d850d3cc49 Mon Sep 17 00:00:00 2001
From: Mike Rapoport m...@compulab.co.il
Date: Mon, 23 Aug 2010 09:40:09 +0300
Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
ioremap for other memory types
Reported-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
drivers/video/omap2/omapfb/omapfb-main.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 04034d4..7f7b1c2 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1436,7 +1436,10 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi,
unsigned long size,
}
if (ofbi-rotation_type != OMAP_DSS_ROT_VRFB) {
- vaddr = ioremap_wc(paddr, size);
+ if (region_mem_type(paddr) == OMAP_VRAM_MEMTYPE_SDRAM)
+ vaddr = phys_to_virt(paddr);
+ else
+ vaddr = ioremap_wc(paddr, size);
if (!vaddr) {
dev_err(fbdev-dev, failed to ioremap framebuffer\n);
--
1.6.6.2
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 broken with 36-rc1
Mike Rapoport wrote:
Hi Ameya,
Ameya Palande wrote:
Hi Tomi,
When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
following error messages:
[0.124145] OMAP DSS rev 2.0
[0.124237] OMAP DISPC rev 3.0
[0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
[0.805419] omapfb omapfb: failed to allocate framebuffer
[0.810882] omapfb omapfb: failed to allocate fbmem
[0.815856] omapfb omapfb: failed to setup omapfb
[0.820648] omapfb: probe of omapfb failed with error -12
Please discard the previous patch, it's buggy :(
Sorry for the noise.
From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001
From: Mike Rapoport m...@compulab.co.il
Date: Mon, 23 Aug 2010 09:40:09 +0300
Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
ioremap for other memory types
Reported-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/plat-omap/include/plat/vram.h |1 +
drivers/video/omap2/omapfb/omapfb-main.c |2 +-
drivers/video/omap2/vram.c | 10 ++
3 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vram.h
b/arch/arm/plat-omap/include/plat/vram.h
index 0aa4ecd..b1b137c 100644
--- a/arch/arm/plat-omap/include/plat/vram.h
+++ b/arch/arm/plat-omap/include/plat/vram.h
@@ -33,6 +33,7 @@ extern int omap_vram_alloc(int mtype, size_t size, unsigned
long *paddr);
extern int omap_vram_reserve(unsigned long paddr, size_t size);
extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
unsigned long *largest_free_block);
+extern void __iomem *omap_vram_remap(size_t size, unsigned long paddr);
#ifdef CONFIG_OMAP2_VRAM
extern void omap_vram_set_sdram_vram(u32 size, u32 start);
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 04034d4..39f53b1 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1436,7 +1436,7 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi,
unsigned long size,
}
if (ofbi-rotation_type != OMAP_DSS_ROT_VRFB) {
- vaddr = ioremap_wc(paddr, size);
+ vaddr = omap_vram_remap(size, paddr);
if (!vaddr) {
dev_err(fbdev-dev, failed to ioremap framebuffer\n);
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index f6fdc20..37557b6 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -30,6 +30,7 @@
#include linux/debugfs.h
#include linux/jiffies.h
#include linux/module.h
+#include linux/io.h
#include asm/setup.h
@@ -425,6 +426,15 @@ void omap_vram_get_info(unsigned long *vram,
}
EXPORT_SYMBOL(omap_vram_get_info);
+void __iomem *omap_vram_remap(size_t size, unsigned long paddr)
+{
+ if (region_mem_type(paddr) == OMAP_VRAM_MEMTYPE_SDRAM)
+ return phys_to_virt(paddr);
+
+ return ioremap_wc(paddr, size);
+}
+EXPORT_SYMBOL(omap_vram_remap);
+
#if defined(CONFIG_DEBUG_FS)
static int vram_debug_show(struct seq_file *s, void *unused)
{
--
1.6.6.2
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 broken with 36-rc1
On Mon, 2010-08-23 at 08:46 +0200, ext Mike Rapoport wrote: Hi Ameya, Ameya Palande wrote: Hi Tomi, When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with following error messages: [0.124145] OMAP DSS rev 2.0 [0.124237] OMAP DISPC rev 3.0 [0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected [0.805419] omapfb omapfb: failed to allocate framebuffer [0.810882] omapfb omapfb: failed to allocate fbmem [0.815856] omapfb omapfb: failed to setup omapfb [0.820648] omapfb: probe of omapfb failed with error -12 I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that works, but not N900... Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH] PM: runtime PM + idle: allow usage when interrupts are disabled
Hi! When using runtime PM in combination with CPUidle, the runtime PM transtions of some devices may be triggered during the idle path. Late in the idle sequence, interrupts will likely be disabled when runtime PM for these devices is initiated. Currently, the runtime PM core assumes methods are called with interrupts enabled. However, if it is called with interrupts disabled, the internal locking unconditionally enables interrupts, for example: ... Unconditionally enabling interrupts late in the idle sequence is not desired behavior. To fix, use the save/restore versions of the spinlock API. Reported-by: Partha Basak p-bas...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- RFC: I'm not crazy about having the 'flags' in struct dev_pm_info, but since the locks are taken and released in separate functions, this seems better than changing the function APIs to pass around the flags. There are restrictions on what you're allowed to do with the flags, but I don't remember exactly what they are. There used to be 'flags must local variable, and enable/disable must happen in same function' restriction on sparc. Not sure if it is still present. Ask davem? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: DSS2 broken with 36-rc1
Tomi Valkeinen wrote: On Mon, 2010-08-23 at 08:46 +0200, ext Mike Rapoport wrote: Hi Ameya, Ameya Palande wrote: Hi Tomi, When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with following error messages: [0.124145] OMAP DSS rev 2.0 [0.124237] OMAP DISPC rev 3.0 [0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected [0.805419] omapfb omapfb: failed to allocate framebuffer [0.810882] omapfb omapfb: failed to allocate fbmem [0.815856] omapfb omapfb: failed to setup omapfb [0.820648] omapfb: probe of omapfb failed with error -12 I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that works, but not N900... May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer memory from the RAM that is not managed by the kernel, e.g with something like mem=RAM size - fb size vram=fb size,0x8.. ? Tomi -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 broken with 36-rc1
On Mon, 2010-08-23 at 09:19 +0200, ext Mike Rapoport wrote: Tomi Valkeinen wrote: I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that works, but not N900... May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer memory from the RAM that is not managed by the kernel, e.g with something like mem=RAM size - fb size vram=fb size,0x8.. ? No, SRAM cannot be used on OMAP3s, as SRAM is too small to hold a framebuffer. And no, I don't think it's reserving it from RAM not managed by the kernel. What is actually failing there? Looking at Ameya's original post, the problem is in allocating the framebuffer. Your patch is doing something _after_ the allocation has failed, so I don't see Ameya's problem having anything to do with ioremap. Ameya, you could try turning on the debugs in drivers/video/omap2/vram.c, and checking what it says. Or see what is in debugfs/vram file Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] [PM-WIP-MMC] OMAP4 hwmod: Updating hwmod data for MMC controllers
Hi Kishore,
On 8/20/2010 10:10 PM, Kadiyala, Kishore wrote:
Update register offsets and dev attributes for MMC controllers on
OMAP4
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Benoit Coussonb-cous...@ti.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index b7268f6..db62b84 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/mmc.h
#include omap_hwmod_common_data.h
@@ -408,8 +409,8 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
*/
static struct omap_hwmod_class_sysconfig omap44xx_mmc_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
+ .rev_offs = 0x02FC,
+ .sysc_offs = 0x0110,
You should not use these registers. MMC is one of the few IP that
contains both legacy and highlander version of the registers, hence the
_HL prefix for the MMCHS_HL_REV and MMCHS_HL_SYSCONFIG.
I don't know why the legacy registers are still there, but you should
use the highlander version.
Regards,
Benoit
.syss_offs = 0x0114,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
SYSC_HAS_SOFTRESET | SYSC_HAS_MIDLEMODE),
@@ -424,6 +425,11 @@ static struct omap_hwmod_class omap44xx_mmc_hwmod_class = {
};
/* mmc1 */
+
+static struct mmc_dev_attr mmc1_dev_attr = {
+ .flags = MMC_INTERNAL_XCVR,
+};
+
static struct omap_hwmod_irq_info omap44xx_mmc1_irqs[] = {
{ .irq = 83 + OMAP44XX_IRQ_GIC_START },
};
@@ -478,10 +484,16 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc1_slaves),
.masters= omap44xx_mmc1_masters,
.masters_cnt= ARRAY_SIZE(omap44xx_mmc1_masters),
+ .dev_attr =mmc1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc2 */
+
+static struct mmc_dev_attr mmc2_dev_attr = {
+ .flags = MMC_SUPPORTS_EXTERNAL_XCVR,
+};
+
static struct omap_hwmod_irq_info omap44xx_mmc2_irqs[] = {
{ .irq = 86 + OMAP44XX_IRQ_GIC_START },
};
@@ -536,6 +548,7 @@ static struct omap_hwmod omap44xx_mmc2_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc2_slaves),
.masters= omap44xx_mmc2_masters,
.masters_cnt= ARRAY_SIZE(omap44xx_mmc2_masters),
+ .dev_attr =mmc2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
--
To unsubscribe from this list: send the line unsubscribe 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: DSS2 broken with 36-rc1
Tomi Valkeinen wrote:
On Mon, 2010-08-23 at 09:19 +0200, ext Mike Rapoport wrote:
Tomi Valkeinen wrote:
I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
works, but not N900...
May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer
memory from the RAM that is not managed by the kernel, e.g with something like
mem=RAM size - fb size vram=fb size,0x8.. ?
No, SRAM cannot be used on OMAP3s, as SRAM is too small to hold a
framebuffer. And no, I don't think it's reserving it from RAM not
managed by the kernel.
The N900 only sets omap_vram_sdram_{start,size} in rx51_video_mem_init.
I think that it should also call omap_vram_reserve_sdram_memblock():
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 5a1005b..fdfe844 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -101,6 +101,7 @@ void __init rx51_video_mem_init(void)
*/
omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
+ omap_vram_reserve_sdram_memblock();
}
#else
What is actually failing there? Looking at Ameya's original post, the
problem is in allocating the framebuffer. Your patch is doing something
_after_ the allocation has failed, so I don't see Ameya's problem having
anything to do with ioremap.
You are right, I've misread the Ameya's original post. I'm fixing another
problem:
OMAPFB: omapfb_init
OMAPFB: omapfb_probe
OMAPFB: create 3 framebuffers
OMAPFB: fb_infos allocated
OMAPFB: allocating 614400 bytes for fb 0
VRAM: alloc mem type 0 size 614400
VRAM: checking region 8f00 4096
VRAM: found 8f00, end 9000
[ cut here ]
WARNING: at arch/arm/mm/ioremap.c:207 __arm_ioremap_pfn_caller+0x48/0x18c()
Modules linked in:
[c004e458] (unwind_backtrace+0x0/0xec) from [c007dfe8]
(warn_slowpath_common+0x4c/0x64)
[c007dfe8] (warn_slowpath_common+0x4c/0x64) from [c007e018]
(warn_slowpath_null+0x18/0x1c)
[c007e018] (warn_slowpath_null+0x18/0x1c) from [c00500c8]
(__arm_ioremap_pfn_caller+0x48/0x18c)
[c00500c8] (__arm_ioremap_pfn_caller+0x48/0x18c) from [c0050270]
(__arm_ioremap_caller+0x54/0x58)
[c0050270] (__arm_ioremap_caller+0x54/0x58) from [c02561e0]
(omapfb_alloc_fbmem+0xf0/0x19c)
[c02561e0] (omapfb_alloc_fbmem+0xf0/0x19c) from [c0257584]
(omapfb_allocate_all_fbs+0x2b8/0x34c)
[c0257584] (omapfb_allocate_all_fbs+0x2b8/0x34c) from [c0257a80]
(omapfb_probe+0x468/0x8dc)
[c0257a80] (omapfb_probe+0x468/0x8dc) from [c028330c]
(platform_drv_probe+0x18/0x1c)
[c028330c] (platform_drv_probe+0x18/0x1c) from [c0282344]
(driver_probe_device+0xc8/0x184)
[c0282344] (driver_probe_device+0xc8/0x184) from [c0282468]
(__driver_attach+0x68/0x8c)
[c0282468] (__driver_attach+0x68/0x8c) from [c0281afc]
(bus_for_each_dev+0x44/0x74)
[c0281afc] (bus_for_each_dev+0x44/0x74) from [c0281438]
(bus_add_driver+0x100/0x288)
[c0281438] (bus_add_driver+0x100/0x288) from [c028275c]
(driver_register+0xa8/0x134)
[c028275c] (driver_register+0xa8/0x134) from [c0022b34]
(omapfb_init+0x24/0x4c)
[c0022b34] (omapfb_init+0x24/0x4c) from [c00483ac]
(do_one_initcall+0xbc/0x194)
[c00483ac] (do_one_initcall+0xbc/0x194) from [c0008574]
(kernel_init+0x94/0x14c)
[c0008574] (kernel_init+0x94/0x14c) from [c0049930]
(kernel_thread_exit+0x0/0x8)
---[ end trace 1b75b31a2719ed1f ]---
omapfb omapfb: failed to ioremap framebuffer
VRAM: free mem paddr 8f00 size 614400
omapfb omapfb: failed to allocate fbmem
OMAPFB: free_resources
OMAPFB: free all fbmem
omapfb omapfb: failed to setup omapfb
omapfb: probe of omapfb failed with error -12
Ameya, you could try turning on the debugs in
drivers/video/omap2/vram.c, and checking what it says. Or see what is in
debugfs/vram file
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 1/3] RTC:s35390a: Add Alarm interrupt support
-Original Message- From: Felipe Balbi [mailto:felipe.ba...@nokia.com] Sent: Monday, August 23, 2010 12:00 PM To: Hiremath, Vaibhav Cc: Balbi Felipe (Nokia-MS/Helsinki); linux-ker...@vger.kernel.org; a...@linux-foundation.org; byron.bbrad...@gmail.com; linux- o...@vger.kernel.org Subject: Re: [PATCH-V2 1/3] RTC:s35390a: Add Alarm interrupt support Hi, please break your lines at 80-characters. Normally I do take care of this, but missed this time. I will be more careful in the future. Also the [Hiremath, Vaibhav] is unnecessary. On Mon, Aug 23, 2010 at 06:58:42AM +0200, ext Hiremath, Vaibhav wrote: don't you need some locking on the irq handler ? a mutex maybe ? Just wondering... [Hiremath, Vaibhav] Yes definitely we do need locking here, I thought of adding locking mechanism in subsequent patch, does it makes sense? so you add a buggy patch and fix it later ? If you already know it's buggy, why not changing the patch that adds the bug ? [Hiremath, Vaibhav] Nothing to argue here, I have to admit/accept and fix this. Thanks, Vaibhav -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC: PATCH] Fix to support multiple HWMODS for a single device
The current HWMOD code expects multiple HWMODS to be filled in consecutive
memory location before passing to omap_device_build_ss(). Ignoring this
will result in incorrect HWMOD data being extracted. This means before calling
omap_device_build_ss() the user has to create memory chunks, copy all the HWMOD
structures to it taking care of the mutex.
This fix uses the pointer to pointer to OMAP_HWMOD structure passed to
omap_device_build_ss() to correctly extract the appropriate
OMAP_HWMOD structure.
This patch is created on top of origin/pm-wip/hwmods-omap4.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/plat-omap/omap_device.c | 42 +++---
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d2b1609..e94bd7a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -257,12 +257,12 @@ static inline struct omap_device *_find_by_pdev(struct
platform_device *pdev)
*/
int omap_device_count_resources(struct omap_device *od)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int c = 0;
int i;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- c += omap_hwmod_count_resources(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ c += omap_hwmod_count_resources(*oh);
pr_debug(omap_device: %s: counted %d total resources across %d
hwmods\n, od-pdev.name, c, od-hwmods_cnt);
@@ -289,12 +289,12 @@ int omap_device_count_resources(struct omap_device *od)
*/
int omap_device_fill_resources(struct omap_device *od, struct resource *res)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int c = 0;
int i, r;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++) {
- r = omap_hwmod_fill_resources(oh, res);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++) {
+ r = omap_hwmod_fill_resources(*oh, res);
res += r;
c += r;
}
@@ -566,7 +566,7 @@ int omap_device_shutdown(struct platform_device *pdev)
{
int ret, i;
struct omap_device *od;
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
od = _find_by_pdev(pdev);
@@ -579,8 +579,8 @@ int omap_device_shutdown(struct platform_device *pdev)
ret = _omap_device_deactivate(od, IGNORE_WAKEUP_LAT);
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- omap_hwmod_shutdown(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ omap_hwmod_shutdown(*oh);
od-_state = OMAP_DEVICE_STATE_SHUTDOWN;
@@ -692,11 +692,11 @@ void __iomem *omap_device_get_rt_va(struct omap_device
*od)
*/
int omap_device_enable_hwmods(struct omap_device *od)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int i;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- omap_hwmod_enable(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ omap_hwmod_enable(*oh);
/* XXX pass along return value here? */
return 0;
@@ -710,11 +710,11 @@ int omap_device_enable_hwmods(struct omap_device *od)
*/
int omap_device_idle_hwmods(struct omap_device *od)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int i;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- omap_hwmod_idle(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ omap_hwmod_idle(*oh);
/* XXX pass along return value here? */
return 0;
@@ -729,11 +729,11 @@ int omap_device_idle_hwmods(struct omap_device *od)
*/
int omap_device_disable_clocks(struct omap_device *od)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int i;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- omap_hwmod_disable_clocks(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ omap_hwmod_disable_clocks(*oh);
/* XXX pass along return value here? */
return 0;
@@ -748,11 +748,11 @@ int omap_device_disable_clocks(struct omap_device *od)
*/
int omap_device_enable_clocks(struct omap_device *od)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int i;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- omap_hwmod_enable_clocks(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ omap_hwmod_enable_clocks(*oh);
/* XXX pass along return value here? */
return 0;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [RFC: PATCH] Fix to support multiple HWMODS for a single device
Hi Vijay,
On 8/23/2010 12:46 PM, ABRAHAM, KISHON VIJAY wrote:
The current HWMOD code expects multiple HWMODS to be filled in consecutive
memory location before passing to omap_device_build_ss().
Just a minor comment: this is not the The current HWMOD code but the
omap_device core code.
Ignoring this
will result in incorrect HWMOD data being extracted. This means before calling
omap_device_build_ss() the user has to create memory chunks, copy all the HWMOD
structures to it taking care of the mutex.
I don't think it was an expectation, this is simply a bug :-)
So copying hwmod structures before calling this API is clearly not the
right way to do fix that...
This fix uses the pointer to pointer to OMAP_HWMOD structure passed to
omap_device_build_ss() to correctly extract the appropriate
OMAP_HWMOD structure.
Yes, this is the proper way of fixing that.
This patch is created on top of origin/pm-wip/hwmods-omap4.
You can do it on the mainline too, there is no dependency with lo/master
or pm-wip for that one. That fix will be able to go to mainline faster.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
arch/arm/plat-omap/omap_device.c | 42 +++---
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d2b1609..e94bd7a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -257,12 +257,12 @@ static inline struct omap_device *_find_by_pdev(struct
platform_device *pdev)
*/
int omap_device_count_resources(struct omap_device *od)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int c = 0;
int i;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- c += omap_hwmod_count_resources(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ c += omap_hwmod_count_resources(*oh);
In that case, you might prefer using array type of access in order to
make the code more readable (i.e. oh[i]). Or even avoid the oh variable.
+ c += omap_hwmod_count_resources(od-hwmods[i]);
Just for my information, what kind of device are you working on that
require multiple hwmods?
Otherwise, this is a good catch. Thanks for fixing that.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC: PATCH] Fix to support multiple HWMODS for a single device
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
Sent: Monday, August 23, 2010 5:20 PM
To: ABRAHAM, KISHON VIJAY
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com;
p...@pwsan.com
Subject: Re: [RFC: PATCH] Fix to support multiple HWMODS for a single
device
Hi Vijay,
On 8/23/2010 12:46 PM, ABRAHAM, KISHON VIJAY wrote:
The current HWMOD code expects multiple HWMODS to be filled in
consecutive
memory location before passing to omap_device_build_ss().
Just a minor comment: this is not the The current HWMOD code but the
omap_device core code.
Ignoring this
will result in incorrect HWMOD data being extracted. This means before
calling
omap_device_build_ss() the user has to create memory chunks, copy all
the HWMOD
structures to it taking care of the mutex.
I don't think it was an expectation, this is simply a bug :-)
So copying hwmod structures before calling this API is clearly not the
right way to do fix that...
This fix uses the pointer to pointer to OMAP_HWMOD structure passed to
omap_device_build_ss() to correctly extract the appropriate
OMAP_HWMOD structure.
Yes, this is the proper way of fixing that.
This patch is created on top of origin/pm-wip/hwmods-omap4.
You can do it on the mainline too, there is no dependency with lo/master
or pm-wip for that one. That fix will be able to go to mainline faster.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
arch/arm/plat-omap/omap_device.c | 42 +++---
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
omap/omap_device.c
index d2b1609..e94bd7a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -257,12 +257,12 @@ static inline struct omap_device
*_find_by_pdev(struct platform_device *pdev)
*/
int omap_device_count_resources(struct omap_device *od)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int c = 0;
int i;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- c += omap_hwmod_count_resources(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ c += omap_hwmod_count_resources(*oh);
In that case, you might prefer using array type of access in order to
make the code more readable (i.e. oh[i]). Or even avoid the oh variable.
+ c += omap_hwmod_count_resources(od-hwmods[i]);
Just for my information, what kind of device are you working on that
require multiple hwmods?
The McBSP qualifies for 2 hwmods and 1 device as OMAP3 has sidetone support
also.
Otherwise, this is a good catch. Thanks for fixing that.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAP: hwmod: Force a softreset during _setup
Hi Partha,
Here is a small patch that should fix that issue:
The approach is quite basic, I'm just enabling all the optional clocks
if the flag is set.
Could you give it a try?
Thanks,
Benoit
---
From 37cda332362d58e584cf3df190a9dceb9c9db8ab Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Mon, 23 Aug 2010 15:45:24 +0200
Subject: [PATCH] OMAP: hwmod: Fix softreset for modules with optional clocks
Some modules (like GPIO, DSS...) require optionals clock to be enabled
in order to complete the sofreset properly.
Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
to be enabled before reset. Disabled them once the reset is done.
Reported-by: Partha Basak p-bas...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 53
+
1 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 9bd99ad..5466c30 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -545,6 +545,36 @@ static int _disable_clocks(struct omap_hwmod *oh)
return 0;
}
+static void _enable_optional_clocks(struct omap_hwmod *oh)
+{
+ struct omap_hwmod_opt_clk *oc;
+ int i;
+
+ pr_debug(omap_hwmod: %s: enabling optional clocks\n, oh-name);
+
+ for (i = oh-opt_clks_cnt, oc = oh-opt_clks; i 0; i--, oc++)
+ if (oc-_clk) {
+ pr_debug(omap_hwmod: enable %s:%s\n, oc-role,
+ oc-_clk-name);
+ clk_enable(oc-_clk);
+ }
+}
+
+static void _disable_optional_clocks(struct omap_hwmod *oh)
+{
+ struct omap_hwmod_opt_clk *oc;
+ int i;
+
+ pr_debug(omap_hwmod: %s: disabling optional clocks\n, oh-name);
+
+ for (i = oh-opt_clks_cnt, oc = oh-opt_clks; i 0; i--, oc++)
+ if (oc-_clk) {
+ pr_debug(omap_hwmod: disable %s:%s\n, oc-role,
+ oc-_clk-name);
+ clk_disable(oc-_clk);
+ }
+}
+
/**
* _find_mpu_port_index - find hwmod OCP slave port ID intended for
MPU use
* @oh: struct omap_hwmod *
@@ -845,8 +875,9 @@ static int _wait_target_ready(struct omap_hwmod *oh)
*/
static int _reset(struct omap_hwmod *oh)
{
- u32 r, v;
+ u32 v;
int c = 0;
+ int ret = 0;
if (!oh-class-sysc ||
!(oh-class-sysc-sysc_flags SYSC_HAS_SOFTRESET) ||
@@ -860,12 +891,16 @@ static int _reset(struct omap_hwmod *oh)
return -EINVAL;
}
- pr_debug(omap_hwmod: %s: resetting\n, oh-name);
+ /* For some modules, all optionnal clocks need to be enabled as well */
+ if (oh-flags HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+ _enable_optional_clocks(oh);
+
+ pr_debug(omap_hwmod: %s: resetting\n, oh-name);
v = oh-_sysc_cache;
- r = _set_softreset(oh, v);
- if (r)
- return r;
+ ret = _set_softreset(oh, v);
+ if (ret)
+ goto dis_opt_clks;
_write_sysconfig(v, oh);
omap_test_timeout((omap_hwmod_readl(oh, oh-class-sysc-syss_offs)
@@ -883,7 +918,13 @@ static int _reset(struct omap_hwmod *oh)
* _wait_target_ready() or _reset()
*/
- return (c == MAX_MODULE_RESET_WAIT) ? -ETIMEDOUT : 0;
+ ret = (c == MAX_MODULE_RESET_WAIT) ? -ETIMEDOUT : 0;
+
+dis_opt_clks:
+ if (oh-flags HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+ _disable_optional_clocks(oh);
+
+ return ret;
}
/**
--
1.6.0.4
On 8/19/2010 1:57 PM, Basak, Partha wrote:
From: Cousson, Benoit
Sent: Wednesday, August 18, 2010 8:31 PM
Hi Partha,
On 8/17/2010 2:46 PM, Basak, Partha wrote:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
Sent: Thursday, August 05, 2010 3:43 AM
Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
omap2/omap_hwmod.c
index 53b08e3..91ad9c6 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -856,8 +856,8 @@ static int _reset(struct omap_hwmod *oh)
/* clocks must be on for this operation */
if (oh-_state != _HWMOD_STATE_ENABLED) {
- WARN(1, omap_hwmod: %s: reset can only be entered from
-enabled state\n, oh-name);
+ pr_warning(omap_hwmod: %s:
Re: [linux-pm] [PATCH] PM: runtime PM + idle: allow usage when interrupts are disabled
Alan Stern st...@rowland.harvard.edu writes: On Thu, 19 Aug 2010, Kevin Hilman wrote: In any case, I don't really like this change. It seems that we would be better off preventing the runtime PM calls from occurring in the first place while interrupts are disabled. Why? Because that's how the Runtime PM framework was designed. Drivers expect interrupts to be enabled when their runtime PM callbacks are invoked. And the framework internally depends on it as well. In fact, it's hard to see what could cause this to happen at all. As I mentioned in the changelog, this happens when trying to use runtime PM in combination with CPUidle. As has been suggested elsewhere[1], there is a need to do runtime PM on some devices in combination with CPU idle transitions managed by CPUidle. However, late in the idle path, at the time we want to manage these IO devices, interrupts are disabled. Then it isn't really feasible to use the runtime PM framework for those devices. Not unless the framework is extended with new functions meant to be used without interrupts enabled (in which case it doesn't seem to matter much whether you are in process context or not). Currently, on OMAP, we are already managing the power state of certain IO devices along with CPUidle transitions using more brute force methods. IMO, using runtime PM for this would be a much cleaner approach. The only obstacle is the assumption that the API must be called with interrupts enabled. That's a big obstacle. Why can't you manage these devices earlier, while interrupts are still enabled? Indeed, that's a good question. I'm exploring this more thoroughly now. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH] PM: runtime PM + idle: allow usage when interrupts are disabled
Rafael J. Wysocki r...@sisk.pl writes: On Thursday, August 19, 2010, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Tuesday, August 10, 2010, Kevin Hilman wrote: When using runtime PM in combination with CPUidle, the runtime PM transtions of some devices may be triggered during the idle path. Late in the idle sequence, interrupts will likely be disabled when runtime PM for these devices is initiated. Currently, the runtime PM core assumes methods are called with interrupts enabled. However, if it is called with interrupts disabled, the internal locking unconditionally enables interrupts, for example: pm_runtime_put_sync() Please don't use that from interrupt context. I'm not using this in interrupt context. I'm using it in process context where interrupts are disabled, specifically, the idle thread. There's pm_runtime_put() exactly for this purpose that puts the _idle() call into a workqueue. * If I'm in my CPU's idle path, I don't want to activate a workqueue because then I'll no longer be idle. Well, what about: - idle - check if devices have been suspended - enter idle if so - call pm_request_idle() for devices The workqueue will activate and put the devices into low-power states and then your idle callback will be called again, with the devices suspended. The problem with this is that after we leave idle, the decision about which C-state to enter will likely change, which will affect the set of devices that need to be suspended. I'm not sure this will be an entirely predictable process with current CPUidle governors, but it certainly merits some more experiments. 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 10/13 v5] OMAP: GPIO: Implement GPIO as a platform device
-Original Message-
From: Basak, Partha
Sent: Thursday, August 12, 2010 5:35 PM
To: 'Paul Walmsley'
Cc: Kevin Hilman; Varadarajan, Charulatha; linux-omap@vger.kernel.org;
Cousson, Benoit; Nayak, Rajendra
Subject: RE: [PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform
device
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, August 11, 2010 11:17 AM
To: Basak, Partha
Cc: Kevin Hilman; Varadarajan, Charulatha; linux-omap@vger.kernel.org;
Cousson, Benoit; Nayak, Rajendra
Subject: RE: [PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform
device
On Tue, 10 Aug 2010, Basak, Partha wrote:
As per our discussion with Paul you during workshop, I believe,
optional clock control should be done using clock APIs. So, I would go
by your suggestion 1 of exposing an API to expose the optional clocks
in
the hwmod, something like:
struct omap_hwmod_opt_clk * omap_hwmod_get_opt_clks(struct omap_hwmod
*oh);
If agreed, Charu will send updated patch.
This should be done by modifying the hwmod code to call clk_add_alias()
for the clock names for the optional clocks. I don't think any extra
API
is needed.
Lets see, if I got it right:
Refer to the OMAP3 hwmod data-base (omap_hwmod_3xxx.c):
static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
{ .role = dbclk, .clk = gpio1_dbck, },
};
Clock database(Clock3xxx_data.c):
CLK(NULL, gpio1_dbck, gpio1_dbck,CK_3XXX),
Refer to the OMAP4 hwmod database(omap_hwmod_44xx.c):
static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
{ .role = dbclk, .clk = sys_32k_ck },
Clock database(Clock44xx_data.c):
CLK(NULL, sys_32k_ck, sys_32k_ck,CK_443X),
/*int clk_add_alias(const char *alias, const char *alias_dev_name, char
*id,
struct device *dev);*/
I believe, you are suggesting to do the following in the hwmod framework,
say _setup(?):
clk_add_alias ( gpio1_opt_clks.role,
oh-od.pdev.name,
gpio1_opt_clks.clk,
NULL);
Then, from the driver, we can simply do a
clk_get(dev_ptr,
role--dbclk); /*hard-coded in the driver to be same
as in the hwmod database*/
Sent patch [PATCH] OMAP: HWMOD: Handle opt clocks using clk_add_alias.
- 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
[PATCH 11/20] Move dispc init to dispc probe
From: Senthilvadivu Guruswamy svad...@ti.com
DISPC init and exit moved to dispc probe and remove.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 5030a84..a72d2fa 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -205,12 +205,6 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
- r = dispc_init();
- if (r) {
- DSSERR(Failed to initialize dispc\n);
- goto err_dispc;
- }
-
r = venc_init(pdev);
if (r) {
DSSERR(Failed to initialize venc\n);
@@ -268,8 +262,6 @@ err_dsi:
err_sdi:
venc_exit();
err_venc:
- dispc_exit();
-err_dispc:
dpi_exit();
err_dpi:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
@@ -286,7 +278,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
venc_exit();
- dispc_exit();
dpi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
@@ -326,11 +317,21 @@ static int omap_dss_resume(struct platform_device *pdev)
/* DISPC HW IP initialisation */
static int omap_dispchw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ r = dispc_init();
+ if (r) {
+ DSSERR(Failed to initialize dispc\n);
+ goto err_dispc;
+ }
+err_dispc:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ return r;
}
static int omap_dispchw_remove(struct platform_device *pdev)
{
+ dispc_exit();
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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/20] Create platform_driver for each DSS HW IP
From: Senthilvadivu Guruswamy svad...@ti.com
Platform driver of DSS HW IP are to be registered in sequence before
the omapdss platform driver is registered.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 121
1 files changed, 121 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index bcbb077..3b6a309 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -707,6 +707,62 @@ static int omap_dss_resume(struct platform_device *pdev)
return dss_resume_all_devices();
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+/* DSI1 HW IP initialisation */
+static int omap_dsi1hw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsi1hw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+/* RFBI HW IP initialisation */
+static int omap_rfbihw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_rfbihw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+/* VENC HW IP initialisation */
+static int omap_venchw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_venchw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+
static struct platform_driver omap_dss_driver = {
.probe = omap_dss_probe,
.remove = omap_dss_remove,
@@ -719,6 +775,66 @@ static struct platform_driver omap_dss_driver = {
},
};
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .shutdown = NULL,
+ .suspend= NULL,
+ .resume = NULL,
+ .driver = {
+ .name = dss,
+ .owner = THIS_MODULE,
+ },
+};
+
+static struct platform_driver omap_dispchw_driver = {
+ .probe = omap_dispchw_probe,
+ .remove = omap_dispchw_remove,
+ .shutdown = NULL,
+ .suspend= NULL,
+ .resume = NULL,
+ .driver = {
+ .name = dss_dispc,
+ .owner = THIS_MODULE,
+ },
+};
+
+static struct platform_driver omap_dsi1hw_driver = {
+ .probe = omap_dsi1hw_probe,
+ .remove = omap_dsi1hw_remove,
+ .shutdown = NULL,
+ .suspend= NULL,
+ .resume = NULL,
+ .driver = {
+ .name = dss_dsi1,
+ .owner = THIS_MODULE,
+ },
+};
+
+static struct platform_driver omap_rfbihw_driver = {
+ .probe = omap_rfbihw_probe,
+ .remove = omap_rfbihw_remove,
+ .shutdown = NULL,
+ .suspend= NULL,
+ .resume = NULL,
+ .driver = {
+ .name = dss_rfbi,
+ .owner = THIS_MODULE,
+ },
+};
+
+static struct platform_driver omap_venchw_driver = {
+ .probe = omap_venchw_probe,
+ .remove = omap_venchw_remove,
+ .shutdown = NULL,
+ .suspend= NULL,
+ .resume = NULL,
+ .driver = {
+ .name = dss_venc,
+ .owner = THIS_MODULE,
+ },
+};
+
/* BUS */
static int dss_bus_match(struct device *dev, struct device_driver *driver)
{
@@ -984,6 +1100,11 @@ static int __init omap_dss_init(void)
static int __init omap_dss_init2(void)
{
+ platform_driver_register(omap_dsshw_driver);
+ platform_driver_register(omap_dispchw_driver);
+ platform_driver_register(omap_dsi1hw_driver);
+ platform_driver_register(omap_rfbihw_driver);
+ platform_driver_register(omap_venchw_driver);
return platform_driver_register(omap_dss_driver);
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 18/20] Get DSI base addr with platform device
From: Senthilvadivu Guruswamy svad...@ti.com
DSI base addr got from platform device. Hardcoding of
base addr removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dsi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 3af207b..6f9739d 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -42,7 +42,6 @@
/*#define VERBOSE_IRQ*/
#define DSI_CATCH_MISSING_TE
-#define DSI_BASE 0x4804FC00
struct dsi_reg { u16 idx; };
@@ -3278,6 +3277,7 @@ int dsi_init(struct platform_device *pdev)
{
u32 rev;
int r;
+ struct resource *dsi_mem;
spin_lock_init(dsi.errors_lock);
dsi.errors = 0;
@@ -3301,7 +3301,8 @@ int dsi_init(struct platform_device *pdev)
dsi.te_timer.function = dsi_te_timeout;
dsi.te_timer.data = 0;
#endif
- dsi.base = ioremap(DSI_BASE, DSI_SZ_REGS);
+ dsi_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ dsi.base = ioremap(dsi_mem-start, resource_size(dsi_mem));
if (!dsi.base) {
DSSERR(can't ioremap DSI\n);
r = -ENOMEM;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 10/20] Move rfbi init to rfbi probe
From: Senthilvadivu Guruswamy svad...@ti.com
RFBI init and exit moved to rfbi probe and remove.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 90a8f77..5030a84 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -199,12 +199,6 @@ static int omap_dss_probe(struct platform_device *pdev)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
- r = rfbi_init();
- if (r) {
- DSSERR(Failed to initialize rfbi\n);
- goto err_rfbi;
- }
-
r = dpi_init(pdev);
if (r) {
DSSERR(Failed to initialize dpi\n);
@@ -278,8 +272,6 @@ err_venc:
err_dispc:
dpi_exit();
err_dpi:
- rfbi_exit();
-err_rfbi:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
return r;
@@ -296,7 +288,6 @@ static int omap_dss_remove(struct platform_device *pdev)
venc_exit();
dispc_exit();
dpi_exit();
- rfbi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
sdi_exit();
@@ -357,11 +348,21 @@ static int omap_dsi1hw_remove(struct platform_device
*pdev)
/* RFBI HW IP initialisation */
static int omap_rfbihw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ r = rfbi_init();
+ if (r) {
+ DSSERR(Failed to initialize rfbi\n);
+ goto err_rfbi;
+ }
+err_rfbi:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ return r;
}
static int omap_rfbihw_remove(struct platform_device *pdev)
{
+ rfbi_exit();
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/20] Get VENC base addr from platform device
From: Senthilvadivu Guruswamy svad...@ti.com
VENC base addr got from platform device. Hardcoding
of base addr removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/venc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 576f0df..e618b09 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -39,7 +39,6 @@
#include dss.h
-#define VENC_BASE 0x48050C00
/* Venc registers */
#define VENC_REV_ID0x00
@@ -659,13 +658,15 @@ struct regulator *dss_get_vdda_dac(void)
int venc_init(struct platform_device *pdev)
{
u8 rev_id;
+ struct resource *venc_mem;
mutex_init(venc.venc_lock);
venc.pdev = pdev;
venc.wss_data = 0;
- venc.base = ioremap(VENC_BASE, SZ_1K);
+ venc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ venc.base = ioremap(venc_mem-start, resource_size(venc_mem));
if (!venc.base) {
DSSERR(can't ioremap VENC\n);
return -ENOMEM;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 08/20] Replace clk_enable/disable APIs with HWMOD APIs
From: Senthilvadivu Guruswamy svad...@ti.com
when DSS ICK, FCK are requested, dss HWMOD APIs are used for enable
and disable. The remaining clocks (dss opt clks in HWMOD database)
continue to use clk APIs, since HWMOD APIs are not fully available
for the dss opt clocks without the usage of clk framework.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dss.c | 28
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 15d0399..098ff96 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -61,6 +61,7 @@ struct dss_reg {
static struct {
struct platform_device *pdev;
+ struct omap_display_platform_data *pdata;
void __iomem*base;
int ctx_id;
@@ -310,14 +311,26 @@ static unsigned count_clk_bits(enum dss_clock clks)
return num_clks;
}
+static inline void enable_clocks(bool enable)
+ {
+ static int use_count;
+
+ use_count += enable ? 1 : -1;
+ if (use_count 0)
+ use_count = 0;
+
+ if (enable use_count == 1)
+ dss.pdata-device_enable(dss.pdev);
+ else if (!enable use_count == 0)
+ dss.pdata-device_idle(dss.pdev);
+}
+
static void dss_clk_enable_no_ctx(enum dss_clock clks)
{
unsigned num_clks = count_clk_bits(clks);
- if (clks DSS_CLK_ICK)
- clk_enable(dss.dss_ick);
- if (clks DSS_CLK_FCK1)
- clk_enable(dss.dss1_fck);
+ if ((clks DSS_CLK_ICK) || (clks DSS_CLK_FCK1))
+ enable_clocks(1);
if (clks DSS_CLK_FCK2)
clk_enable(dss.dss2_fck);
if (clks DSS_CLK_54M)
@@ -342,10 +355,8 @@ static void dss_clk_disable_no_ctx(enum dss_clock clks)
{
unsigned num_clks = count_clk_bits(clks);
- if (clks DSS_CLK_ICK)
- clk_disable(dss.dss_ick);
- if (clks DSS_CLK_FCK1)
- clk_disable(dss.dss1_fck);
+ if ((clks DSS_CLK_ICK) || (clks DSS_CLK_FCK1))
+ enable_clocks(0);
if (clks DSS_CLK_FCK2)
clk_disable(dss.dss2_fck);
if (clks DSS_CLK_54M)
@@ -447,6 +458,7 @@ static int omap_dsshw_probe(struct platform_device *pdev)
int r;
dss.pdev = pdev;
+ dss.pdata = dss.pdev-dev.platform_data;
r = dss_get_clocks();
if (r)
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 19/20] Get RFBI baseaddr with platform device
From: Senthilvadivu Guruswamy svad...@ti.com
RFBI base addr got from platform device. Hardcoding of
base addr removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/rfbi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index fe4f423..690f7bf 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -36,7 +36,6 @@
#include plat/display.h
#include dss.h
-#define RFBI_BASE 0x48050800
struct rfbi_reg { u16 idx; };
@@ -961,6 +960,7 @@ int rfbi_init(struct platform_device *pdev)
{
u32 rev;
u32 l;
+ struct resource *rfbi_mem;
spin_lock_init(rfbi.cmd_lock);
@@ -968,7 +968,8 @@ int rfbi_init(struct platform_device *pdev)
atomic_set(rfbi.cmd_fifo_full, 0);
atomic_set(rfbi.cmd_pending, 0);
- rfbi.base = ioremap(RFBI_BASE, SZ_256);
+ rfbi_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ rfbi.base = ioremap(rfbi_mem-start, resource_size(rfbi_mem));
if (!rfbi.base) {
DSSERR(can't ioremap RFBI\n);
return -ENOMEM;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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/20] Move dss platform driver to dss.c
From: Senthilvadivu Guruswamy svad...@ti.com
dsshw_probe and remove functions are moved to dss.c
To maintain the order of init, through the dsshw_probe, omap_dss_init2
is made as device_init_call_sync.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 26 +-
drivers/video/omap2/dss/dss.c | 29 +
2 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 3b6a309..f01e8e6 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -707,17 +707,6 @@ static int omap_dss_resume(struct platform_device *pdev)
return dss_resume_all_devices();
}
-/* DSS HW IP initialisation */
-static int omap_dsshw_probe(struct platform_device *pdev)
-{
- return 0;
-}
-
-static int omap_dsshw_remove(struct platform_device *pdev)
-{
- return 0;
-}
-
/* DISPC HW IP initialisation */
static int omap_dispchw_probe(struct platform_device *pdev)
{
@@ -775,18 +764,6 @@ static struct platform_driver omap_dss_driver = {
},
};
-static struct platform_driver omap_dsshw_driver = {
- .probe = omap_dsshw_probe,
- .remove = omap_dsshw_remove,
- .shutdown = NULL,
- .suspend= NULL,
- .resume = NULL,
- .driver = {
- .name = dss,
- .owner = THIS_MODULE,
- },
-};
-
static struct platform_driver omap_dispchw_driver = {
.probe = omap_dispchw_probe,
.remove = omap_dispchw_remove,
@@ -1100,7 +1077,6 @@ static int __init omap_dss_init(void)
static int __init omap_dss_init2(void)
{
- platform_driver_register(omap_dsshw_driver);
platform_driver_register(omap_dispchw_driver);
platform_driver_register(omap_dsi1hw_driver);
platform_driver_register(omap_rfbihw_driver);
@@ -1109,7 +1085,7 @@ static int __init omap_dss_init2(void)
}
core_initcall(omap_dss_init);
-device_initcall(omap_dss_init2);
+device_initcall_sync(omap_dss_init2);
#endif
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com);
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 24b1825..5f91e37 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -122,6 +122,29 @@ void dss_restore_context(void)
#undef SR
#undef RR
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .shutdown = NULL,
+ .suspend= NULL,
+ .resume = NULL,
+ .driver = {
+ .name = dss,
+ .owner = THIS_MODULE,
+ },
+};
+
void dss_sdi_init(u8 datapairs)
{
u32 l;
@@ -633,3 +656,9 @@ void dss_exit(void)
iounmap(dss.base);
}
+static int __init omap_dss_init1(void)
+{
+ return platform_driver_register(omap_dsshw_driver);
+}
+
+device_initcall(omap_dss_init1);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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/20] Build omap_device for each DSS HW IP
From: Senthilvadivu Guruswamy svad...@ti.com
Looks up the HWMOD database for each of the given DSS HW IP
and builds omap_device which inturn does the platform device
register for each of DSS HW IP
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/devices.c | 46 +
arch/arm/plat-omap/include/plat/display.h | 10 ++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 523ce27..8faac13 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,8 @@
#include plat/mmc.h
#include plat/dma.h
#include plat/display.h
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
#include mux.h
@@ -824,9 +826,53 @@ static struct platform_device omap_display_device = {
},
};
+static struct omap_device_pm_latency omap_dss_latency[] = {
+ [0] = {
+ .deactivate_func= omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ },
+};
+
void __init omap_display_init(struct omap_dss_board_info
*board_data)
{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ int l, i;
+ struct omap_display_platform_data pdata;
+ char oh_name[5][MAX_OMAP_DSS_HWMOD_NAME_LEN] = {
+ dss,
+ dss_dispc,
+ dss_dsi1,
+ dss_rfbi,
+ dss_venc
+ };
+
+ for (i = 0; i 5; i++) {
+ l = snprintf(oh_name[i], MAX_OMAP_DSS_HWMOD_NAME_LEN,
+oh_name[i]);
+ WARN(l = MAX_OMAP_DSS_HWMOD_NAME_LEN,
+ String buffer overflow in DSS device setup\n);
+
+ oh = omap_hwmod_lookup(oh_name[i]);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name[i]);
+ return ;
+ }
+ strcpy(pdata.name, oh_name[i]);
+ pdata.board_data= board_data;
+ pdata.board_data-get_last_off_on_transaction_id = NULL;
+ pdata.device_enable= omap_device_enable;
+ pdata.device_idle = omap_device_idle;
+ pdata.device_shutdown = omap_device_shutdown;
+ od = omap_device_build(oh_name[i], -1, oh, pdata,
+ sizeof(struct omap_display_platform_data),
+ omap_dss_latency,
+ ARRAY_SIZE(omap_dss_latency), 0);
+
+ WARN((IS_ERR(od)), Could not build omap_device for %s\n,
+ oh_name[i]);
+ }
omap_display_device.dev.platform_data = board_data;
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index f5da4ae..996964a 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -26,6 +26,8 @@
#include linux/platform_device.h
#include asm/atomic.h
+#define MAX_OMAP_DSS_HWMOD_NAME_LEN 16
+
#define DISPC_IRQ_FRAMEDONE(1 0)
#define DISPC_IRQ_VSYNC(1 1)
#define DISPC_IRQ_EVSYNC_EVEN (1 2)
@@ -255,6 +257,14 @@ struct omap_dss_board_info {
/* Init with the board info */
extern void omap_display_init(struct omap_dss_board_info *board_data);
+struct omap_display_platform_data{
+ char name[MAX_OMAP_DSS_HWMOD_NAME_LEN];
+ struct omap_dss_board_info *board_data;
+ int (*device_enable)(struct platform_device *pdev);
+ int (*device_shutdown)(struct platform_device *pdev);
+ int (*device_idle)(struct platform_device *pdev);
+};
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 16/20] Get DISPC base addr with platform device
From: Senthilvadivu Guruswamy svad...@ti.com
DISPC Base addr got from the platform device. Hadrcoding of base
addr removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dispc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ae18b5f..8a7a086 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -40,7 +40,6 @@
#include dss.h
/* DISPC */
-#define DISPC_BASE 0x48050400
#define DISPC_SZ_REGS SZ_1K
@@ -3094,6 +3093,7 @@ static void _omap_dispc_initial_config(void)
int dispc_init(struct platform_device *pdev)
{
u32 rev;
+ struct resource *dispc_mem;
spin_lock_init(dispc.irq_lock);
@@ -3104,7 +3104,8 @@ int dispc_init(struct platform_device *pdev)
INIT_WORK(dispc.error_work, dispc_error_worker);
- dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+ dispc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ dispc.base = ioremap(dispc_mem-start, resource_size(dispc_mem));
if (!dispc.base) {
DSSERR(can't ioremap DISPC\n);
return -ENOMEM;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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/20] DSS HWMOD database generation for OMAP3
From: Senthilvadivu Guruswamy svad...@ti.com
OMAP3 HWMOD database for DSS is added and is applicable for 34xx and 36xx.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 346
1 files changed, 346 insertions(+), 0 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..e736bb7 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
@@ -31,6 +32,11 @@
* elsewhere.
*/
+static struct omap_hwmod omap3xxx_dss_hwmod;
+static struct omap_hwmod omap3xxx_dss_dispc_hwmod;
+static struct omap_hwmod omap3xxx_dss_dsi1_hwmod;
+static struct omap_hwmod omap3xxx_dss_rfbi_hwmod;
+static struct omap_hwmod omap3xxx_dss_venc_hwmod;
static struct omap_hwmod omap3xxx_mpu_hwmod;
static struct omap_hwmod omap3xxx_iva_hwmod;
static struct omap_hwmod omap3xxx_l3_main_hwmod;
@@ -58,6 +64,14 @@ static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
.user = OCP_USER_MPU,
};
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap3xxx_dss__l3 = {
+ .master = omap3xxx_dss_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+
/* Slave interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l3_main_slaves[] = {
omap3xxx_mpu__l3_main,
@@ -197,6 +211,333 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap3xxx_dss_sysc,
+};
+
+
+/* dss */
+static struct omap_hwmod_irq_info omap3xxx_dss_irqs[] = {
+ { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+ { .name = dsi1, .dma_req = 74 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_masters[] = {
+ omap3xxx_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_dss_hwmod,
+ .clk= dss_ick,
+ .addr = omap3xxx_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dss_addrs),
+ .user = OCP_USER_MPU,
+};
+
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_slaves[] = {
+ omap3xxx_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = tv_clk, .clk = dss_tv_fck },
+ { .role = dssclk, .clk = dss_96m_fck },
+ { .role = sys_clk, .clk = dss2_alwon_fck },
+};
+
+static struct omap_hwmod omap3xxx_dss_hwmod = {
+ .name = dss,
+ .class = omap3xxx_dss_hwmod_class,
+ .main_clk = dss1_alwon_fck, /* instead of dss_fck */
+ .mpu_irqs = omap3xxx_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_dss_irqs),
+ .sdma_reqs = omap3xxx_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap3xxx_dss_sdma_chs),
+
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_DSS1_SHIFT,
+ .module_offs = OMAP3430_DSS_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430ES2_ST_DSS_IDLE_SHIFT,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+ .slaves = omap3xxx_dss_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_dss_slaves),
+ .masters= omap3xxx_dss_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_dss_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags =
[PATCH 14/20] Pass platform_device argument to rfbi,dispc
From: Senthilvadivu Guruswamy svad...@ti.com
Add platform_device argument to rfbi_init and dispc_init
to pass the pdev to the driver.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c |4 ++--
drivers/video/omap2/dss/dispc.c |2 +-
drivers/video/omap2/dss/dss.h |6 +++---
drivers/video/omap2/dss/rfbi.c |2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index ce1f83b..f6fdf6a 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -286,7 +286,7 @@ static int omap_dispchw_probe(struct platform_device *pdev)
{
int r;
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
- r = dispc_init();
+ r = dispc_init(pdev);
if (r) {
DSSERR(Failed to initialize dispc\n);
goto err_dispc;
@@ -331,7 +331,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
{
int r;
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
- r = rfbi_init();
+ r = rfbi_init(pdev);
if (r) {
DSSERR(Failed to initialize rfbi\n);
goto err_rfbi;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e777e35..ae18b5f 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3091,7 +3091,7 @@ static void _omap_dispc_initial_config(void)
dispc_read_plane_fifo_sizes();
}
-int dispc_init(void)
+int dispc_init(struct platform_device *pdev)
{
u32 rev;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 3f79292..7f9cdf5 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -311,7 +311,7 @@ static inline void dpi_exit(void)
#endif
/* DISPC */
-int dispc_init(void);
+int dispc_init(struct platform_device *pdev);
void dispc_exit(void);
void dispc_dump_clocks(struct seq_file *s);
void dispc_dump_irqs(struct seq_file *s);
@@ -413,7 +413,7 @@ static inline void venc_exit(void)
/* RFBI */
#ifdef CONFIG_OMAP2_DSS_RFBI
-int rfbi_init(void);
+int rfbi_init(struct platform_device *pdev);
void rfbi_exit(void);
void rfbi_dump_regs(struct seq_file *s);
@@ -425,7 +425,7 @@ void rfbi_set_timings(int rfbi_module, struct rfbi_timings
*t);
unsigned long rfbi_get_max_tx_rate(void);
int rfbi_init_display(struct omap_dss_device *display);
#else
-static inline int rfbi_init(void)
+static inline int rfbi_init(struct platform_device *pdev)
{
return 0;
}
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index cc23f53..fe4f423 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -957,7 +957,7 @@ void rfbi_dump_regs(struct seq_file *s)
#undef DUMPREG
}
-int rfbi_init(void)
+int rfbi_init(struct platform_device *pdev)
{
u32 rev;
u32 l;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 15/20] Use platform device to get DSS base addr
From: Senthilvadivu Guruswamy svad...@ti.com
DSS Base addr got form platform device. Hardcoding of base addr could be
removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dss.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index cbad9ff..21005c6 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -973,8 +973,10 @@ int dss_init(bool skip_init)
{
int r;
u32 rev;
+ struct resource *dss_mem;
- dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+ dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
+ dss.base = ioremap(dss_mem-start, resource_size(dss_mem));
if (!dss.base) {
DSSERR(can't ioremap DSS\n);
r = -ENOMEM;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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/20] Move DSS driver register from board to mach_omap2
From: Senthilvadivu Guruswamy svad...@ti.com
Move the DSS driver register from board file to devices.c.
Regulator initialisation done with driver name instead of the device name.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 25 +++---
arch/arm/mach-omap2/devices.c | 32 +
arch/arm/plat-omap/include/plat/display.h |4 +++
drivers/video/omap2/dss/core.c|2 +
4 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 67b95b5..9b721a4 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -301,22 +301,8 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = sdp3430_lcd_device,
};
-static struct platform_device sdp3430_dss_device = {
- .name = omapdss,
- .id = -1,
- .dev= {
- .platform_data = sdp3430_dss_data,
- },
-};
-
-static struct regulator_consumer_supply sdp3430_vdda_dac_supply = {
- .supply = vdda_dac,
- .dev= sdp3430_dss_device.dev,
-};
-
-static struct platform_device *sdp3430_devices[] __initdata = {
- sdp3430_dss_device,
-};
+static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omapdss);
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
@@ -540,10 +526,7 @@ static struct regulator_init_data sdp3430_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
- {
- .supply = vdds_dsi,
- .dev= sdp3430_dss_device.dev,
- }
+ REGULATOR_SUPPLY(vdds_dsi, omapdss),
};
static struct regulator_init_data sdp3430_vpll2 = {
@@ -797,7 +780,7 @@ static void __init omap_3430sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
- platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+ omap_display_init(sdp3430_dss_data);
if (omap_rev() OMAP3430_REV_ES1_0)
ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
else
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..523ce27 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -28,6 +28,7 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/dma.h
+#include plat/display.h
#include mux.h
@@ -813,6 +814,37 @@ static inline void omap_hdq_init(void) {}
#endif
/*---*/
+#ifdef CONFIG_OMAP2_DSS
+
+static struct platform_device omap_display_device = {
+ .name = omapdss,
+ .id= -1,
+ .dev= {
+ .platform_data = NULL,
+ },
+};
+
+void __init omap_display_init(struct omap_dss_board_info
+ *board_data)
+{
+
+ omap_display_device.dev.platform_data = board_data;
+
+ if (platform_device_register(omap_display_device) 0)
+ printk(KERN_ERR Unable to register OMAP-Display device\n);
+
+
+ return ;
+}
+
+#else
+void __init omap_display_init(struct omap_dss_board_info *board_data)
+{
+}
+#endif
+
+
+/*---*/
#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 1c529ce..f5da4ae 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -23,6 +23,7 @@
#include linux/list.h
#include linux/kobject.h
#include linux/device.h
+#include linux/platform_device.h
#include asm/atomic.h
#define DISPC_IRQ_FRAMEDONE(1 0)
@@ -251,6 +252,9 @@ struct omap_dss_board_info {
struct omap_dss_device *default_device;
};
+/* Init with the board info */
+extern void omap_display_init(struct omap_dss_board_info *board_data);
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index b3a498f..bcbb077 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -52,6 +52,7 @@ static struct {
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
struct regulator *vdda_dac_reg;
+ struct omap_dss_board_info *pdata;
} core;
static void dss_clk_enable_all_no_ctx(void);
@@ -501,6 +502,7 @@ static int omap_dss_probe(struct platform_device *pdev)
int i;
core.pdev = pdev;
+ core.pdata = pdev-dev.platform_data;
dss_init_overlay_managers(pdev);
[PATCH 06/20] DSS driver name change in clock database
From: Senthilvadivu Guruswamy svad...@ti.com
Change the dss driver name from omapdss to dss in clock
database against the dss related clocks
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 138646d..980daf8 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3320,13 +3320,13 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_343X),
CLK(NULL, sha11_ick,sha11_ick, CK_343X),
CLK(NULL, des1_ick, des1_ick, CK_343X),
- CLK(omapdss, dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
- CLK(omapdss, dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2 |
CK_AM35XX),
- CLK(omapdss, tv_fck, dss_tv_fck,CK_3XXX),
- CLK(omapdss, video_fck,dss_96m_fck, CK_3XXX),
- CLK(omapdss, dss2_fck, dss2_alwon_fck, CK_3XXX),
- CLK(omapdss, ick, dss_ick_3430es1, CK_3430ES1),
- CLK(omapdss, ick, dss_ick_3430es2, CK_3430ES2 |
CK_AM35XX),
+ CLK(dss, dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
+ CLK(dss, dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2 |
CK_AM35XX),
+ CLK(dss, tv_fck, dss_tv_fck,CK_3XXX),
+ CLK(dss, video_fck,dss_96m_fck, CK_3XXX),
+ CLK(dss, dss2_fck, dss2_alwon_fck, CK_3XXX),
+ CLK(dss, ick, dss_ick_3430es1, CK_3430ES1),
+ CLK(dss, ick, dss_ick_3430es2, CK_3430ES2 |
CK_AM35XX),
CLK(NULL, cam_mclk, cam_mclk, CK_343X),
CLK(NULL, cam_ick, cam_ick, CK_343X),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_343X),
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/20] Move venc init to venc probe
From: Senthilvadivu Guruswamy svad...@ti.com
VENC init and exit moved to venc probe and remove.
regulator used by venc is moved to venc driver alone.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
drivers/video/omap2/dss/core.c | 40 +-
drivers/video/omap2/dss/venc.c | 19
3 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 9b721a4..cb66d65 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -302,7 +302,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
};
static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
- REGULATOR_SUPPLY(vdda_dac, omapdss);
+ REGULATOR_SUPPLY(vdda_dac, dss_venc);
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index a72d2fa..df0cfea 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -43,7 +43,6 @@ static struct {
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
- struct regulator *vdda_dac_reg;
struct omap_dss_board_info *pdata;
} core;
@@ -90,19 +89,6 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
}
-struct regulator *dss_get_vdda_dac(void)
-{
- struct regulator *reg;
-
- if (core.vdda_dac_reg != NULL)
- return core.vdda_dac_reg;
-
- reg = regulator_get(core.pdev-dev, vdda_dac);
- if (!IS_ERR(reg))
- core.vdda_dac_reg = reg;
-
- return reg;
-}
#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
@@ -205,12 +191,6 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
- r = venc_init(pdev);
- if (r) {
- DSSERR(Failed to initialize venc\n);
- goto err_venc;
- }
-
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
@@ -260,8 +240,6 @@ err_dsi:
if (cpu_is_omap34xx())
sdi_exit();
err_sdi:
- venc_exit();
-err_venc:
dpi_exit();
err_dpi:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
@@ -277,7 +255,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
- venc_exit();
dpi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
@@ -370,11 +347,21 @@ static int omap_rfbihw_remove(struct platform_device
*pdev)
/* VENC HW IP initialisation */
static int omap_venchw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ r = venc_init(pdev);
+ if (r) {
+ DSSERR(Failed to initialize venc\n);
+ goto err_venc;
+ }
+err_venc:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ return r;
}
static int omap_venchw_remove(struct platform_device *pdev)
{
+ venc_exit();
return 0;
}
@@ -684,11 +671,6 @@ static void __exit omap_dss_exit(void)
core.vdds_sdi_reg = NULL;
}
- if (core.vdda_dac_reg != NULL) {
- regulator_put(core.vdda_dac_reg);
- core.vdda_dac_reg = NULL;
- }
-
platform_driver_unregister(omap_dss_driver);
omap_dss_bus_unregister();
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index eff3505..576f0df 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -293,6 +293,7 @@ static struct {
struct mutex venc_lock;
u32 wss_data;
struct regulator *vdda_dac_reg;
+ struct platform_device *pdev;
} venc;
static inline void venc_write_reg(int idx, u32 val)
@@ -641,7 +642,19 @@ static struct omap_dss_driver venc_driver = {
};
/* driver end */
+struct regulator *dss_get_vdda_dac(void)
+{
+ struct regulator *reg;
+
+ if (venc.vdda_dac_reg != NULL)
+ return venc.vdda_dac_reg;
+
+ reg = regulator_get(venc.pdev-dev, vdda_dac);
+ if (!IS_ERR(reg))
+ venc.vdda_dac_reg = reg;
+ return reg;
+}
int venc_init(struct platform_device *pdev)
{
@@ -649,6 +662,7 @@ int venc_init(struct platform_device *pdev)
mutex_init(venc.venc_lock);
+ venc.pdev = pdev;
venc.wss_data = 0;
venc.base = ioremap(VENC_BASE, SZ_1K);
@@ -676,6 +690,11 @@ int venc_init(struct platform_device *pdev)
void venc_exit(void)
{
+ if (venc.vdda_dac_reg != NULL) {
+ regulator_put(venc.vdda_dac_reg);
+ venc.vdda_dac_reg = NULL;
+ }
+
omap_dss_unregister_driver(venc_driver);
iounmap(venc.base);
--
[PATCH 09/20] Move dss_init to dsshw_probe
From: Senthilvadivu Guruswamy svad...@ti.com
Move dss_init and dss_exit from core driver to dss driver
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 15 ---
drivers/video/omap2/dss/dss.c | 17 -
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 24b93d5..90a8f77 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -199,18 +199,6 @@ static int omap_dss_probe(struct platform_device *pdev)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
-#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
- /* DISPC_CONTROL */
- if (omap_readl(0x48050440) 1) /* LCD enabled? */
- skip_init = 1;
-#endif
-
- r = dss_init(skip_init);
- if (r) {
- DSSERR(Failed to initialize DSS\n);
- goto err_dss;
- }
-
r = rfbi_init();
if (r) {
DSSERR(Failed to initialize rfbi\n);
@@ -292,8 +280,6 @@ err_dispc:
err_dpi:
rfbi_exit();
err_rfbi:
- dss_exit();
-err_dss:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
return r;
@@ -316,7 +302,6 @@ static int omap_dss_remove(struct platform_device *pdev)
sdi_exit();
}
- dss_exit();
dss_uninit_overlays(pdev);
dss_uninit_overlay_managers(pdev);
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 098ff96..cbad9ff 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -456,6 +456,7 @@ void dss_debug_dump_clocks(struct seq_file *s)
static int omap_dsshw_probe(struct platform_device *pdev)
{
int r;
+ int skip_init = 0;
dss.pdev = pdev;
dss.pdata = dss.pdev-dev.platform_data;
@@ -469,8 +470,20 @@ static int omap_dsshw_probe(struct platform_device *pdev)
dss.ctx_id = dss_get_ctx_id();
DSSDBG(initial ctx id %u\n, dss.ctx_id);
-err_clocks:
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
+
+ r = dss_init(skip_init);
+ if (r) {
+ DSSERR(Failed to initialize DSS\n);
+ goto err_dss;
+ }
+err_clocks:
+err_dss:
return r;
}
@@ -478,6 +491,8 @@ static int omap_dsshw_remove(struct platform_device *pdev)
{
int c;
+ dss_exit();
+
/* these should be removed at some point */
c = dss.dss_ick-usecount;
if (c 0) {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 20/20] Get DSS IRQ with platform device
From: Senthilvadivu Guruswamy svad...@ti.com
DSS IRQ got from platform device. Hardcoding of baseaddr,
IRQ removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dss.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 21005c6..a22ba65 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -34,7 +34,6 @@
#include plat/clock.h
#include dss.h
-#define DSS_BASE 0x4805
#define DSS_SZ_REGSSZ_512
@@ -971,7 +970,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
int dss_init(bool skip_init)
{
- int r;
+ int r, dss_irq;
u32 rev;
struct resource *dss_mem;
@@ -1012,15 +1011,18 @@ int dss_init(bool skip_init)
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); /* venc clock mode = normal */
#endif
- r = request_irq(INT_24XX_DSS_IRQ,
+ dss_irq = platform_get_irq(dss.pdev, 0);
+ if (dss_irq) {
+ r = request_irq(dss_irq,
cpu_is_omap24xx()
? dss_irq_handler_omap2
: dss_irq_handler_omap3,
0, OMAP DSS, NULL);
- if (r 0) {
- DSSERR(omap2 dss: request_irq failed\n);
- goto fail1;
+ if (r 0) {
+ DSSERR(omap2 dss: request_irq failed\n);
+ goto fail1;
+ }
}
if (cpu_is_omap34xx()) {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe 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 13/20] Move dsi init to dsi probe
From: Senthilvadivu Guruswamy svad...@ti.com
DSI init and exit moved to dsi probe and remove.
regulator in dsi could be taken care in board file as
REGULATOR_SUPPLY(vdds_dsi, dss_dsi1), but not added as part
of this patch.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index df0cfea..ce1f83b 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -197,12 +197,6 @@ static int omap_dss_probe(struct platform_device *pdev)
DSSERR(Failed to initialize SDI\n);
goto err_sdi;
}
-
- r = dsi_init(pdev);
- if (r) {
- DSSERR(Failed to initialize DSI\n);
- goto err_dsi;
- }
}
r = dss_initialize_debugfs();
@@ -235,9 +229,6 @@ err_register:
dss_uninitialize_debugfs();
err_debugfs:
if (cpu_is_omap34xx())
- dsi_exit();
-err_dsi:
- if (cpu_is_omap34xx())
sdi_exit();
err_sdi:
dpi_exit();
@@ -257,7 +248,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dpi_exit();
if (cpu_is_omap34xx()) {
- dsi_exit();
sdi_exit();
}
@@ -315,11 +305,24 @@ static int omap_dispchw_remove(struct platform_device
*pdev)
/* DSI1 HW IP initialisation */
static int omap_dsi1hw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ if (cpu_is_omap34xx()) {
+ r = dsi_init(pdev);
+ if (r) {
+ DSSERR(Failed to initialize DSI\n);
+ goto err_dsi;
+ }
+ }
+err_dsi:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ return r;
}
static int omap_dsi1hw_remove(struct platform_device *pdev)
{
+ if (cpu_is_omap34xx())
+ dsi_exit();
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 00/20] HWMOD Adaptation for DSS
From: Senthilvadivu Guruswamy svad...@ti.com
Patch Base:
===
url = git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
branch pm-wip/hwmods-omap4
Commit id: f6f7f1103b80b4dc0ace8a0314d95d1b1ebca726
Description: Merge branch 'pm-wip/hwmods' into pm-wip/hwmods-omap4-base
RFC focus on the proposed design of the HWMOD adaptation to the current DSS
driver. DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each
corresponding to the HWMOD class in the HWMOD database.
No Hardcoding of silicon data:
HWMOD database abstracts the SOC data like base addr, irq numbers and are
implemented in this patch series.
Continue to have custom bus for display panels:
omapdss driver continues to be a platform driver that registers the custom
bus. It also continues to register the display panels(omap_dss_device) on the
board to the panel drivers (omap_dss_driver)
For Eg: primary lcd device would be registered with lcd panel driver.
lcd panel driver if it is on a parallel interface would use library functions
exported from dpi.o. if it is on a dsi interface would use library functions
exported from dsi platform driver(dsi.o).
Clocks:
Handling of clocks in DSS only is one of the design approach, that does not
change the existing implementation. If each of the DSS HW IPs had to handle
their own clocks, then corresponding clock changes are requested in the HWMOD
database as well which is not the present scenario.
For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart
for the dss main clocks. Currently VENC driver needs to be aware of this and
has to
use clk_get/put, clk_enable/disable, since VENC HWMOD is not aware of 54MCLK.
Current dss driver:
---
1. Omapdss platform driver
- initialises necessary Ips dss, dispc.
- also initialises Ips like sdi, dsi, venc, rfbi
- creates a custom bus and registers the display devices/drivers
connected on the board to the custom bus.
2. Suspend/resume of omapdss
- in turn sends suspend/resume calls for each of the display devices
registered to it.
Proposed change:
Platform driver for each DSS HW IP in addition to the software omapdss
driver.
Omapdss platform driver
- initialises necessary software libraries like dpi, sdi.
- continues to have a custom bus and registers the display devices
and drivers connected on the board to the custom bus.
- continues to handle suspend/resume of the display devices registered
to the custom bus.
DSS platform driver
- initialises DSS IP alone
- Handles the clocks related to the DSS and other DSSHW IPs like RFBI,
DSI, VENC, DISPC. Previously this was a part of omapdss driver in
core.c
- Continues to handle the DSS IRQs.
- No suspend/resume hooks.
DISPC platform driver
- initialises DSS IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.
DSI platform driver
- initialises DSI IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.
RFBI, VENC platform drivers
- initialises DSI,VENC IPs
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.
The patches are tested on OMAP3430 and 3630.
The below points are yet to be done, still the RFC is put out to start the
discussion on the design approach taken.
Yet to be implemented:
1) All the platform driver registration except DSS, are within the file core.c.
Registeration of these driver would go out of order when seperated to its own
file.
Will test the implementation and send in the next version for review.
2) Usage of regulators by different drivers needs to implemented.
For Eg: Regulator used by VENC is moved to venc driver. But vdda_dac would be
needed by DPI and DSI as well. Need to verify if a patch like this would work.
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss),
+ REGULATOR_SUPPLY(vdds_dsi, dss_dsi1),
};
3) SYSCONFIG of each of the dss HW IP has to be removed from the driver.
HWMOD framework is supposed to take care of it. This change would be done in
the next version of the patch series.
4) OMAP2 HWMOD database is yet to be generated.
5) Number of DSS HW IPs in a silicon are hardcoded in devices.c.
It is not evident from HWMOD database. Need to find a cleaner way to register
for OMAP2,3,4.
6) Module support for omapdss driver as per current DSS2 design.
Senthilvadivu Guruswamy (20):
DSS HWMOD database generation for OMAP3
Move DSS driver
Re: [RFC: PATCH] Fix to support multiple HWMODS for a single device
Thanks Benoit for your review comments.
On Monday 23 August 2010 05:31 PM, Datta, Shubhrajyoti wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
Sent: Monday, August 23, 2010 5:20 PM
To: ABRAHAM, KISHON VIJAY
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com;
p...@pwsan.com
Subject: Re: [RFC: PATCH] Fix to support multiple HWMODS for a single
device
Hi Vijay,
On 8/23/2010 12:46 PM, ABRAHAM, KISHON VIJAY wrote:
The current HWMOD code expects multiple HWMODS to be filled in
consecutive
memory location before passing to omap_device_build_ss().
Just a minor comment: this is not the The current HWMOD code but the
omap_device core code.
Ignoring this
will result in incorrect HWMOD data being extracted. This means before
calling
omap_device_build_ss() the user has to create memory chunks, copy all
the HWMOD
structures to it taking care of the mutex.
I don't think it was an expectation, this is simply a bug :-)
So copying hwmod structures before calling this API is clearly not the
right way to do fix that...
This fix uses the pointer to pointer to OMAP_HWMOD structure passed to
omap_device_build_ss() to correctly extract the appropriate
OMAP_HWMOD structure.
Yes, this is the proper way of fixing that.
This patch is created on top of origin/pm-wip/hwmods-omap4.
You can do it on the mainline too, there is no dependency with lo/master
or pm-wip for that one. That fix will be able to go to mainline faster.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
arch/arm/plat-omap/omap_device.c | 42 +++---
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
omap/omap_device.c
index d2b1609..e94bd7a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -257,12 +257,12 @@ static inline struct omap_device
*_find_by_pdev(struct platform_device *pdev)
*/
int omap_device_count_resources(struct omap_device *od)
{
- struct omap_hwmod *oh;
+ struct omap_hwmod **oh;
int c = 0;
int i;
- for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
- c += omap_hwmod_count_resources(oh);
+ for (i = 0, oh = od-hwmods; i od-hwmods_cnt; i++, oh++)
+ c += omap_hwmod_count_resources(*oh);
In that case, you might prefer using array type of access in order to
make the code more readable (i.e. oh[i]). Or even avoid the oh variable.
+c += omap_hwmod_count_resources(od-hwmods[i]);
Just for my information, what kind of device are you working on that
require multiple hwmods?
The McBSP qualifies for 2 hwmods and 1 device as OMAP3 has sidetone support
also.
Otherwise, this is a good catch. Thanks for fixing that.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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 00/20] HWMOD Adaptation for DSS
On 8/23/2010 5:57 PM, Guruswamy, Senthilvadivu wrote:
From: Senthilvadivu Guruswamysvad...@ti.com
Patch Base:
===
url = git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
branch pm-wip/hwmods-omap4
Commit id: f6f7f1103b80b4dc0ace8a0314d95d1b1ebca726
Description: Merge branch 'pm-wip/hwmods' into pm-wip/hwmods-omap4-base
RFC focus on the proposed design of the HWMOD adaptation to the current DSS
driver. DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each
corresponding to the HWMOD class in the HWMOD database.
No Hardcoding of silicon data:
HWMOD database abstracts the SOC data like base addr, irq numbers and are
implemented in this patch series.
Continue to have custom bus for display panels:
omapdss driver continues to be a platform driver that registers the custom
bus. It also continues to register the display panels(omap_dss_device) on the
board to the panel drivers (omap_dss_driver)
For Eg: primary lcd device would be registered with lcd panel driver.
lcd panel driver if it is on a parallel interface would use library functions
exported from dpi.o. if it is on a dsi interface would use library functions
exported from dsi platform driver(dsi.o).
Clocks:
Handling of clocks in DSS only is one of the design approach, that does not
change the existing implementation. If each of the DSS HW IPs had to handle
their own clocks, then corresponding clock changes are requested in the HWMOD
database as well which is not the present scenario.
For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart
for the dss main clocks. Currently VENC driver needs to be aware of this and
has to
use clk_get/put, clk_enable/disable, since VENC HWMOD is not aware of 54MCLK.
Current dss driver:
---
1. Omapdss platform driver
- initialises necessary Ips dss, dispc.
- also initialises Ips like sdi, dsi, venc, rfbi
- creates a custom bus and registers the display devices/drivers
connected on the board to the custom bus.
2. Suspend/resume of omapdss
- in turn sends suspend/resume calls for each of the display devices
registered to it.
Proposed change:
Platform driver for each DSS HW IP in addition to the software omapdss
driver.
Omapdss platform driver
- initialises necessary software libraries like dpi, sdi.
- continues to have a custom bus and registers the display devices
and drivers connected on the board to the custom bus.
- continues to handle suspend/resume of the display devices registered
to the custom bus.
DSS platform driver
- initialises DSS IP alone
- Handles the clocks related to the DSS and other DSSHW IPs like RFBI,
DSI, VENC, DISPC. Previously this was a part of omapdss driver in
core.c
- Continues to handle the DSS IRQs.
- No suspend/resume hooks.
DISPC platform driver
- initialises DSS IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.
DSI platform driver
- initialises DSI IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.
RFBI, VENC platform drivers
- initialises DSI,VENC IPs
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.
The patches are tested on OMAP3430 and 3630.
The below points are yet to be done, still the RFC is put out to start the
discussion on the design approach taken.
Yet to be implemented:
1) All the platform driver registration except DSS, are within the file core.c.
Registeration of these driver would go out of order when seperated to its own
file.
Will test the implementation and send in the next version for review.
2) Usage of regulators by different drivers needs to implemented.
For Eg: Regulator used by VENC is moved to venc driver. But vdda_dac would be
needed by DPI and DSI as well. Need to verify if a patch like this would work.
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss),
+ REGULATOR_SUPPLY(vdds_dsi, dss_dsi1),
You can add any consumer you want for a given regulator supply as soon
as you have a valid dev or dev_name.
};
3) SYSCONFIG of each of the dss HW IP has to be removed from the driver.
HWMOD framework is supposed to take care of it. This change would be done in
the next version of the patch series.
4) OMAP2 HWMOD database is yet to be generated.
5) Number of DSS HW IPs in a silicon are hardcoded in devices.c.
It is not evident from HWMOD database. Need to find a cleaner way to register
Re: [PATCH 15/20] Use platform device to get DSS base addr
On 8/23/2010 5:58 PM, Guruswamy, Senthilvadivu wrote:
From: Senthilvadivu Guruswamysvad...@ti.com
DSS Base addr got form platform device. Hardcoding of base addr could be
removed.
Signed-off-by: Senthilvadivu Guruswamysvad...@ti.com
---
drivers/video/omap2/dss/dss.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index cbad9ff..21005c6 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -973,8 +973,10 @@ int dss_init(bool skip_init)
{
int r;
u32 rev;
+ struct resource *dss_mem;
- dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+ dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
platform_get_resource can fail, so you have to check the returned value.
Please note that this comment applies as well to all the other patches
from 16 to 19.
Benoit
+ dss.base = ioremap(dss_mem-start, resource_size(dss_mem));
if (!dss.base) {
DSSERR(can't ioremap DSS\n);
r = -ENOMEM;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] OMAP4: runtime: Enable PM runtime core for OMAP4
Rajendra Nayak rna...@ti.com writes: The PM runtime core functions are implemented in pm_bus.c which needs to be compiled for CONFIG_ARCH_OMAP4 for runtime api's to work. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com I'll fold this one into the OMAP runtime PM core series (pm-wip/runtime branch) so this goes upstream with the core code. Thanks, Kevin --- arch/arm/mach-omap2/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 800b430..18db759 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -50,7 +50,7 @@ ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o pm_bus.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 -- To unsubscribe from this list: send the line unsubscribe 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/5] OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430
Rajendra Nayak rna...@ti.com writes:
From: Paul Walmsley p...@pwsan.com
Add hwmod structures for I2C controllers on OMAP2420/2430.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 134 ++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 140
+++-
2 files changed, 270 insertions(+), 4 deletions(-)
[...]
+static struct omap_hwmod omap2420_i2c1_hwmod = {
+ .name = i2c1,
+ .mpu_irqs = i2c1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(i2c1_mpu_irqs),
+ .sdma_chs = i2c1_sdma_chs,
+ .sdma_chs_cnt = ARRAY_SIZE(i2c1_sdma_chs),
+ .main_clk = i2c1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP2420_EN_I2C1_SHIFT,
+ },
+ },
This needs to be validated on OMAP2.
I think the enable will fail without the .idlest* fields filled out.
Kevin
+
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
Rajendra Nayak rna...@ti.com writes:
This patch converts the i2c driver to use PM runtime apis for OMAP2+
and omap_device api's for OMAP1
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Some minor comments below, but otherwise looks like the right direction.
Kevin
---
drivers/i2c/busses/i2c-omap.c | 81
++---
1 files changed, 35 insertions(+), 46 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7674efb..387f9c6 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -39,6 +39,7 @@
#include linux/io.h
#include linux/slab.h
#include linux/i2c-omap.h
+#include linux/pm_runtime.h
/* I2C controller revisions */
#define OMAP_I2C_REV_2 0x20
@@ -175,8 +176,6 @@ struct omap_i2c_dev {
void __iomem*base; /* virtual */
int irq;
int reg_shift; /* bit shift for I2C register
addresses */
- struct clk *iclk; /* Interface clock */
- struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
struct resource *ioarea;
u32 latency;/* maximum mpu wkup latency */
@@ -265,45 +264,25 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
+static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
- int ret;
-
- dev-iclk = clk_get(dev-dev, ick);
- if (IS_ERR(dev-iclk)) {
- ret = PTR_ERR(dev-iclk);
- dev-iclk = NULL;
- return ret;
- }
-
- dev-fclk = clk_get(dev-dev, fck);
- if (IS_ERR(dev-fclk)) {
- ret = PTR_ERR(dev-fclk);
- if (dev-iclk != NULL) {
- clk_put(dev-iclk);
- dev-iclk = NULL;
- }
- dev-fclk = NULL;
- return ret;
- }
+ struct platform_device *pdev;
+ struct omap_i2c_bus_platform_data *pdata;
- return 0;
-}
+ WARN_ON(!dev-idle);
-static void omap_i2c_put_clocks(struct omap_i2c_dev *dev)
-{
- clk_put(dev-fclk);
- dev-fclk = NULL;
- clk_put(dev-iclk);
- dev-iclk = NULL;
-}
+ pdev = container_of(dev-dev, struct platform_device, dev);
linux/platform_device.h provides to_platform_device() for this
+ pdata = pdev-dev.platform_data;
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- WARN_ON(!dev-idle);
+ pm_runtime_get_sync(pdev-dev);
+ /*
+ * This is needed for now to have OMAP1
+ * working as PM runtime is not yet
+ * supported on OMAP1
+ */
+ if (pdata-device_enable)
+ pdata-device_enable(pdev);
OMAP1 should work fine on the pm-wip/rutime branch as there is a simple
runtime PM core for OMAP1 implemented that just manages clocks.
- clk_enable(dev-iclk);
- clk_enable(dev-fclk);
if (cpu_is_omap34xx()) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
@@ -326,10 +305,15 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
+ struct platform_device *pdev;
+ struct omap_i2c_bus_platform_data *pdata;
u16 iv;
WARN_ON(dev-idle);
+ pdev = container_of(dev-dev, struct platform_device, dev);
+ pdata = pdev-dev.platform_data;
+
dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
if (dev-rev = OMAP_I2C_REV_ON_4430)
omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 1);
@@ -345,8 +329,15 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
}
dev-idle = 1;
- clk_disable(dev-fclk);
- clk_disable(dev-iclk);
+
+ pm_runtime_put_sync(pdev-dev);
+ /*
+ * This is needed for now to have OMAP1
+ * working as PM runtime is not yet
+ * supported on OMAP1
+ */
+ if (pdata-device_idle)
+ pdata-device_idle(pdev);
ditto
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -356,6 +347,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long fclk_rate = 1200;
unsigned long timeout;
unsigned long internal_clk = 0;
+ struct clk *fclk;
if (dev-rev = OMAP_I2C_REV_2) {
/* Disable I2C controller before soft reset */
@@ -414,7 +406,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* always returns 12MHz for the functional clock, we can
* do this
Re: [PATCH] dmtimer: hwmod: OMAP1: device registration
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This patch converts OMAP1 dual mode timers into platform devices,
adds support for registering them through generic linux platform
device layer.
...and changes the init sequence ordering from a sys_timer to an
arch_initcall (more on this below...)
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Tested on ... ?
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/dmtimer.c | 146
arch/arm/mach-omap1/timer32k.c |3 -
3 files changed, 147 insertions(+), 4 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap1/Makefile
create mode 100755 arch/arm/mach-omap1/dmtimer.c
mode change 100644 = 100755 arch/arm/mach-omap1/timer32k.c
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
old mode 100644
new mode 100755
index 9a304d8..0001659
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
-obj-y += clock.o clock_data.o opp_data.o
+obj-y += clock.o clock_data.o opp_data.o dmtimer.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/dmtimer.c b/arch/arm/mach-omap1/dmtimer.c
new file mode 100755
index 000..b06d096
--- /dev/null
+++ b/arch/arm/mach-omap1/dmtimer.c
@@ -0,0 +1,146 @@
+/**
+ * OMAP1 Dual-Mode Timers
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include linux/slab.h
+#include mach/irqs.h
+#include plat/dmtimer.h
+
+#define OMAP1610_GPTIMER1_BASE 0xfffb1400
+#define OMAP1610_GPTIMER2_BASE 0xfffb1c00
+#define OMAP1610_GPTIMER3_BASE 0xfffb2400
+#define OMAP1610_GPTIMER4_BASE 0xfffb2c00
+#define OMAP1610_GPTIMER5_BASE 0xfffb3400
+#define OMAP1610_GPTIMER6_BASE 0xfffb3c00
+#define OMAP1610_GPTIMER7_BASE 0xfffb7400
+#define OMAP1610_GPTIMER8_BASE 0xfffbd400
+
+#define OMAP1_DM_TIMER_COUNT 8
+
+static int omap1_dm_timer_set_clk(struct platform_device *pdev,
+ int source)
+{
+ int n = (pdev-id) 1;
+ u32 l;
+
+ l = omap_readl(MOD_CONF_CTRL_1) ~(0x03 n);
+ l |= source n;
+ omap_writel(l, MOD_CONF_CTRL_1);
+
+ return 0;
+}
+
+int __init omap1_dm_timer_init(void)
+{
+ int i;
+
+ if (!cpu_is_omap16xx())
+ return 0;
+
+ for (i = 0; i OMAP1_DM_TIMER_COUNT; i++) {
+ struct platform_device *pdev;
+ struct omap_dmtimer_platform_data *pdata;
+ struct resource res[2];
+ u32 base, irq;
+ int ret;
+
+ switch (i) {
+ case 0:
+ base = OMAP1610_GPTIMER1_BASE;
+ irq = INT_1610_GPTIMER1;
+ break;
+ case 1:
+ base = OMAP1610_GPTIMER2_BASE;
+ irq = INT_1610_GPTIMER2;
+ break;
+ case 2:
+ base = OMAP1610_GPTIMER3_BASE;
+ irq = INT_1610_GPTIMER3;
+ break;
+ case 3:
+ base = OMAP1610_GPTIMER4_BASE;
+ irq = INT_1610_GPTIMER4;
+ break;
+ case 4:
+ base = OMAP1610_GPTIMER5_BASE;
+ irq = INT_1610_GPTIMER5;
+ break;
+ case 5:
+ base = OMAP1610_GPTIMER6_BASE;
+ irq = INT_1610_GPTIMER6;
+ break;
+ case 6:
+ base = OMAP1610_GPTIMER7_BASE;
+ irq = INT_1610_GPTIMER7;
+ break;
+ case 7:
+ base = OMAP1610_GPTIMER8_BASE;
+ irq = INT_1610_GPTIMER8;
+ break;
+ default:
+ /* Should never reach here */
+ return -EINVAL;
+ }
IMO, this would be much cleaner to just have a static list of
platform_devices with the base and IRQ resources hard coded and use
platform_add_devices(..., ARRAY_SIZE(...))
instead of looping over the allocate/init/register
+ pdev = platform_device_alloc(dmtimer, i);
+ if (!pdev) {
+ pr_err(%s: Unable to
Re: [PATCH 4/13] dmtimer: hwmod: OMAP: api to read omap_hwmod _clk
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This patch adds the omap_hwmod_get_clk() to access the _clk
field needed while setting clock sources of the timers.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
To help understand the motivation for the change, please explain in the
changelog the intended usage of the API, e.g. what drivers/devices will
use this API and why.
Also, this patch (with a more descriptive changelog) should be separate
from this series as it affects the omap_hwmod core.
I see it's usage later in this series, but this change (if accepted)
would upstream separately from the dmtimer series.
Kevin
---
arch/arm/mach-omap2/omap_hwmod.c | 21 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 22 insertions(+), 0 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/omap_hwmod.c
mode change 100644 = 100755 arch/arm/plat-omap/include/plat/omap_hwmod.h
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 7f3c023..7188f0c
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1759,6 +1759,27 @@ void __iomem *omap_hwmod_get_mpu_rt_va(struct
omap_hwmod *oh)
}
/**
+ * omap_hwmod_get_clk - returns pointer to this module's struct clk
+ * @oh: struct omap_hwmod *
+ *
+ * Return the struct clk pointer associated with the OMAP module
+ * Returns NULL on error, or a struct clk * on success.
+ */
+struct clk *omap_hwmod_get_clk(struct omap_hwmod *oh)
+{
+ if (!oh)
+ return NULL;
+
+ if (oh-_int_flags _HWMOD_NO_MPU_PORT)
+ return NULL;
+
+ if (oh-_state == _HWMOD_STATE_UNKNOWN)
+ return NULL;
+
+ return oh-_clk;
+}
+
+/**
* omap_hwmod_add_initiator_dep - add sleepdep from @init_oh to @oh
* @oh: struct omap_hwmod *
* @init_oh: struct omap_hwmod * (initiator)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 6adbb63..a2b85a5
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -538,6 +538,7 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res);
struct powerdomain *omap_hwmod_get_pwrdm(struct omap_hwmod *oh);
void __iomem *omap_hwmod_get_mpu_rt_va(struct omap_hwmod *oh);
+struct clk *omap_hwmod_get_clk(struct omap_hwmod *oh);
int omap_hwmod_add_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_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: [PATCHv2 5/13] dmtimer: hwmod: OMAP: conversion to platform driver
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Thara Gopinath th...@ti.com
This essentially involves moving out interrupt and base address
related info from plat-omap/dmtimer.c and making certain clock related
functions platform data. This patch also initializes dmtimer driver
as a earlydriver. This is to enable early timer devices required during
system boot initialized early.
no need for 'hwmod' in $SUBJECT
incorporated comments:
(1) use list instead of array to manage timers
(2) introduced appropriate cleanup in failure paths of probe function
(3) made spinlock a static variable initialized at bootup so that it
is available both during early init and later.
(4) pm_runtime support
(5) corrected un-even number of pm_runtime_enable() associated with
early millisecond timers
This patch needs to be broken up into more pieces.
The conversion to platform_device should be patch on its own. The
addition of runtime PM support followed by the addition of the new timer
types should also be separate patches.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/dmtimer.c | 549
+
arch/arm/plat-omap/include/plat/dmtimer.h | 10 +-
2 files changed, 255 insertions(+), 304 deletions(-)
mode change 100644 = 100755 arch/arm/plat-omap/dmtimer.c
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 44bafda..0915a37
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -10,6 +10,12 @@
* Copyright (C) 2009 Texas Instruments
* Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
*
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * - hwmod support
+ * - omap4 support
+ *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -37,9 +43,13 @@
#include linux/delay.h
#include linux/io.h
#include linux/module.h
+#include linux/slab.h
#include mach/hardware.h
+#include linux/pm_runtime.h
#include plat/dmtimer.h
+#include plat/omap_device.h
#include mach/irqs.h
+#include linux/interrupt.h
/* register offsets */
#define _OMAP_TIMER_ID_OFFSET0x00
@@ -151,144 +161,30 @@
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR WPSHIFT))
struct omap_dm_timer {
- unsigned long phys_base;
+ int id;
+ unsigned long fclk_rate;
int irq;
-#ifdef CONFIG_ARCH_OMAP2PLUS
- struct clk *iclk, *fclk;
-#endif
void __iomem *io_base;
unsigned reserved:1;
unsigned enabled:1;
unsigned posted:1;
+ unsigned is_initialized:1;
+ struct platform_device *pdev;
+ struct list_head node;
};
-static int dm_timer_count;
-
-#ifdef CONFIG_ARCH_OMAP1
-static struct omap_dm_timer omap1_dm_timers[] = {
- { .phys_base = 0xfffb1400, .irq = INT_1610_GPTIMER1 },
- { .phys_base = 0xfffb1c00, .irq = INT_1610_GPTIMER2 },
- { .phys_base = 0xfffb2400, .irq = INT_1610_GPTIMER3 },
- { .phys_base = 0xfffb2c00, .irq = INT_1610_GPTIMER4 },
- { .phys_base = 0xfffb3400, .irq = INT_1610_GPTIMER5 },
- { .phys_base = 0xfffb3c00, .irq = INT_1610_GPTIMER6 },
- { .phys_base = 0xfffb7400, .irq = INT_1610_GPTIMER7 },
- { .phys_base = 0xfffbd400, .irq = INT_1610_GPTIMER8 },
-};
-
-static const int omap1_dm_timer_count = ARRAY_SIZE(omap1_dm_timers);
-
-#else
-#define omap1_dm_timers NULL
-#define omap1_dm_timer_count 0
-#endif /* CONFIG_ARCH_OMAP1 */
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct omap_dm_timer omap2_dm_timers[] = {
- { .phys_base = 0x48028000, .irq = INT_24XX_GPTIMER1 },
- { .phys_base = 0x4802a000, .irq = INT_24XX_GPTIMER2 },
- { .phys_base = 0x48078000, .irq = INT_24XX_GPTIMER3 },
- { .phys_base = 0x4807a000, .irq = INT_24XX_GPTIMER4 },
- { .phys_base = 0x4807c000, .irq = INT_24XX_GPTIMER5 },
- { .phys_base = 0x4807e000, .irq = INT_24XX_GPTIMER6 },
- { .phys_base = 0x4808, .irq = INT_24XX_GPTIMER7 },
- { .phys_base = 0x48082000, .irq = INT_24XX_GPTIMER8 },
- { .phys_base = 0x48084000, .irq = INT_24XX_GPTIMER9 },
- { .phys_base = 0x48086000, .irq = INT_24XX_GPTIMER10 },
- { .phys_base = 0x48088000, .irq = INT_24XX_GPTIMER11 },
- { .phys_base = 0x4808a000, .irq = INT_24XX_GPTIMER12 },
-};
-
-static const char *omap2_dm_source_names[] __initdata = {
- sys_ck,
- func_32k_ck,
- alt_ck,
- NULL
-};
-
-static
Re: [PATCH-V2 3/3] RTC:s35390a: Add update_irq (per Min interrupt) support
On Sat, 21 Aug 2010 18:00:29 +0530
hvaib...@ti.com wrote:
+static int s35390a_update_irq_enable(struct i2c_client *client,
+ unsigned enabled)
+{
+ struct s35390a *s35390a = i2c_get_clientdata(client);
+ char buf[1];
+
+ if (s35390a_get_reg(s35390a, S35390A_CMD_STATUS2, buf, sizeof(buf)) 0)
+ return -EIO;
+
+ /* This chip returns the bits of each byte in reverse order */
+ buf[0] = bitrev8(buf[0]);
+
+ buf[0] = ~S35390A_INT1_MODE_MASK;
+ if (enabled)
+ buf[0] |= S35390A_INT1_MODE_PMIN_STDY;
+ else
+ buf[0] |= S35390A_INT1_MODE_NOINTR;
+
+ /* This chip expects the bits of each byte in reverse order */
+ buf[0] = bitrev8(buf[0]);
grumble. We bit-reverse it, fiddle a couple of bits and then
bit-reverse it again. Lazy.
Why not leave it bit-reversed and just bit-reverse the constants?
Extra marks are awarded for coming up with a compile-time bitrev8() ;)
+ return s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, buf, sizeof(buf));
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Thara Gopinath th...@ti.com
This patch converts dmtimers into platform devices using omap hwmod,
omap device and runtime pm frameworks. It also allows GPTIMER1 and
GPTIMER2 and GPTIMER10 to be registered as early devices. This allows
any one of the these three to be registered as system timer very early
during system boot sequence. Later during normal plaform_device_register
these are converted to normal platform device.
What about GPT12 which is used as system timer on Beagle due to a board
bug on early revs of board?
comments incorporated:
(1) registration of devices through automatic learning from hwmod database
(2) enabling functionality both with and without pm_runtime
(3) extract device id from hwmod structure's name field.
(4) free platform data at the end of successful platform device registration
I still don't like the way early devices are implemented. My comments
from the first time I reviewed this series appear to have been ignored.
It is not at all clear why the separate pdata functions are needed for
early and normal devices. Many more questions/comments on this below...
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/dmtimer.c | 403
arch/arm/mach-omap2/dmtimer.h | 19 ++
arch/arm/mach-omap2/io.c |2 +
arch/arm/mach-omap2/timer-gp.c |1 -
5 files changed, 425 insertions(+), 2 deletions(-)
create mode 100755 arch/arm/mach-omap2/dmtimer.c
create mode 100755 arch/arm/mach-omap2/dmtimer.h
mode change 100644 = 100755 arch/arm/mach-omap2/io.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9b44773..c54f6e8 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
dmtimer.o
omap-2-3-common = irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
new file mode 100755
index 000..2c40a9b
--- /dev/null
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -0,0 +1,403 @@
+/**
+ * linux/arch/arm/mach-omap2/dmtimer.c
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * - Highlander ip support on omap4
+ * - hwmod support
+ *
+ * OMAP2 Dual-Mode Timers
+ * 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 linux/clk.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/err.h
+#include linux/slab.h
+
+#include mach/irqs.h
+#include plat/dmtimer.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include linux/pm_runtime.h
+
+static int early_timer_count __initdata;
+static int is_early_init __initdata = 1;
+
+static char *omap2_dm_source_names[] __initdata = {
+ sys_ck,
+ func_32k_ck,
+ alt_ck,
+ NULL
+};
+static struct clk *omap2_dm_source_clocks[3];
+static char *omap3_dm_source_names[] __initdata = {
+ sys_ck,
+ omap_32k_fck,
+ NULL
+};
+static struct clk *omap3_dm_source_clocks[2];
+
+static char *omap4_dm_source_names[] __initdata = {
+ sys_clkin_ck,
+ sys_32k_ck,
+ syc_clk_div_ck,
+ NULL
+};
+static struct clk *omap4_dm_source_clocks[3];
+
+static struct clk **omap_dm_source_clocks;
The clock names should all be part of pdata too. There is no reason
to keep these SoC specifics in the driver.
+static void omap2_dm_timer_enable(struct platform_device *pdev)
+{
+ if (!pdev) {
+ dev_err(pdev-dev, %s: invalid pdev\n, __func__);
+ return;
+ }
+ pm_runtime_get_sync(pdev-dev);
+}
+
+static void omap2_dm_timer_disable(struct platform_device *pdev)
+{
+ if (!pdev) {
+ dev_err(pdev-dev, %s: invalid pdev\n, __func__);
+ return;
+ }
+ pm_runtime_put_sync(pdev-dev);
+}
There is no need for these functions. Driver should be calling runtime
PM API directly.
+static void omap2_dm_early_timer_enable(struct platform_device *pdev)
+{
+#ifdef CONFIG_PM_RUNTIME
+ /* when pm_runtime is enabled, it is still inactive at this point
wrong multi-line comment style
+ * that is why this call is needed as it is not enabled by default
+ */
so
Re: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
+/**
+* omap2_dm_timer_early_init - top level early timer initialization
+* called in the last part of omap2_init_common_hw
+*
+* uses dedicated hwmod api to parse through hwmod database for
+* given class name and then build and register the timer device.
+* at the end driver is registered and early probe initiated.
+**/
+void __init omap2_dm_timer_early_init(void)
+{
+ omap_hwmod_for_each_by_class(timer_1ms,
+ omap_dm_timer_early_init, NULL);
+ omap2_dm_timer_setup();
+ early_platform_driver_register_all(earlytimer);
+ early_platform_driver_probe(earlytimer, early_timer_count + 1, 0);
+}
It's not clear (or documented) why on the 1ms timers should be the only
earlydevices.
For example, GPT12 is used as the system timer on Beagle due to a board
bug in early revs of the board. That will no longer function with this
approach.
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: [PATCHv2 8/13] dmtimer: OMAP: multi-platform register access support
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
This patch uses the new register structures and mappings in functions
in order to access register offsets thereby supporting multi-platform
environment.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/dmtimer.c | 51
--
1 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 14a20e0..24ca283 100755
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -154,6 +154,7 @@ struct omap_dm_timer {
unsigned long fclk_rate;
int irq;
void __iomem *io_base;
+ u32 *regs;
unsigned reserved:1;
unsigned enabled:1;
unsigned posted:1;
@@ -174,13 +175,14 @@ static DEFINE_SPINLOCK(dm_timer_lock);
* pending bit must be checked. Otherwise a read of a non completed write
* will produce an error.
**/
-static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer, u32
reg)
+static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer, int
reg)
'reg' could stay unsigned, it's a non-zero index. If anything, you
could change it to a u8.
{
if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base + \
'\' is not needed
[...]
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 v2] omap: 4430sdp board support for the the GPIO keys
omap 4430sdp board support for the 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
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 61 +++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..85b0e0c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
+#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
@@ -40,6 +41,8 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_SFH7741_ENABLE_GPIO 188
static struct gpio_led sdp4430_gpio_leds[] = {
{
@@ -77,11 +80,47 @@ static struct gpio_led sdp4430_gpio_leds[] = {
};
+static struct gpio_keys_button sdp4430_gpio_keys[] = {
+ {
+ .desc = Proximity Sensor,
+ .type = EV_SW,
+ .code = SW_FRONT_PROXIMITY,
+ .gpio = OMAP4_SFH7741_SENSOR_OUTPUT_GPIO,
+ .active_low = 0,
+ }
+};
+
static struct gpio_led_platform_data sdp4430_led_data = {
.leds = sdp4430_gpio_leds,
.num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
};
+static int omap_prox_activate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ return 0;
+}
+
+static void omap_prox_deactivate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 0);
+}
+
+static struct gpio_keys_platform_data sdp4430_gpio_keys_data = {
+ .buttons= sdp4430_gpio_keys,
+ .nbuttons = ARRAY_SIZE(sdp4430_gpio_keys),
+ .enable = omap_prox_activate,
+ .disable= omap_prox_deactivate,
+};
+
+static struct platform_device sdp4430_gpio_keys_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_gpio_keys_data,
+ },
+};
+
static struct platform_device sdp4430_leds_gpio = {
.name = leds-gpio,
.id = -1,
@@ -161,6 +200,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
};
@@ -426,6 +466,26 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
+
+static void __init omap_sfh7741prox_init(void)
+{
+ int error;
+
+ error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(%s:failed to request GPIO %d, error %d\n,
+ __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ return;
+ }
+
+ error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 0);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d,error %d\n,
+__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
+ }
+}
+
static void __init omap_4430sdp_init(void)
{
int status;
@@ -448,6 +508,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ omap_sfh7741prox_init();
}
static void __init omap_4430sdp_map_io(void)
--
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
