Re: [PATCH v2t2 00/17] omap: mailbox:
From: Hiroshi DOYU Subject: Re: [PATCH v2t2 00/17] omap: mailbox: Date: Sat, 22 May 2010 08:14:15 +0300 (EEST) > From: ext Felipe Contreras > Subject: Re: [PATCH v2t2 00/17] omap: mailbox: > Date: Sat, 22 May 2010 01:34:52 +0200 > >> On Sat, May 22, 2010 at 1:15 AM, Russell King - ARM Linux >> wrote: >>> On Sat, May 22, 2010 at 01:09:12AM +0300, Felipe Contreras wrote: On Sat, May 22, 2010 at 12:57 AM, Russell King - ARM Linux wrote: > The only reason 3 would be loaded due to that dependency is if 2 were > being modprobed, which means it's going to be inserted after 3 anyway. > > I don't see anything else in 3 which would trigger it to be loaded. > > The "platform:omap2-mailbox" module alias of 2 should result in 2 > being modprobed, I see, at initialization? >>> >>> That's the theory - and it should be that same mechanism which allows >>> things like already plugged in PCMCIA and the like cards to be properly >>> dealt with at boot time. >>> > causing 3 to be loaded to satisfy the dependency. > As already pointed out, this should happen as a result of udev or > (older) hotplug initialization. Well, in the minimal system I have in my beagleboard it doesn't happen. I load bridgedriver, which loads mailbox, but fails immediately because mailbox_mach is not there. >>> >>> I assume that having the MMC host driver built in, but the MMC block >>> driver as a module also doesn't work on your setup? >> >> I wouldn't know because my file-system is on the MMC. > > I guess that your other platform drivers wouldn't work as dynamic module. > >>> I don't see this as something that should be worked around in the >>> kernel by making things non-modular - I view the missing userspace >>> functionality causing the problem. >> >> First of all, most of the cleanups are independent of the built-in >> option, although that was my motivation, the patches are good by > > Your cleanup patches are ok. > >> themselves: there's no need to export >> omap_mbox_register()/_unregister() unnecessarily when the platform >> data can be used, right? > > This is not the point. > >> Now, regarding the built-in mode; for the iommu case you said it >> should be built-in: >> http://article.gmane.org/gmane.linux.ports.arm.kernel/58555 > > Right. > >> Apparently it's not, so it's not clear to me how omap3-iommu would be >> loaded since there's no "platform:" alias. > > This alias is only necessary for platform drivers. > >> Moreover, Tony says that anything that registers platform devices >> should be built-in, but omap3-iommu does register devices and is not >> built-in. > > It seems that this makes you confused. It should have been > build-in;). This is going to be integrated into omap hwmod framework > soon. For built-in part, it could be something like: >From a09c2040e083f23a43232f97cb29b9aefc9c0d11 Mon Sep 17 00:00:00 2001 From: Hiroshi DOYU Date: Mon, 24 May 2010 09:35:11 +0300 Subject: [PATCH 1/1] omap iommu: Make omap-iommu.o built-in This is a platform device registration. Signed-off-by: Hiroshi DOYU --- arch/arm/mach-omap2/Makefile |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 7d2cf0f..4d754f6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -89,7 +89,10 @@ obj-$(CONFIG_OMAP3_EMU) += emu.o obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o mailbox_mach-objs := mailbox.o -obj-$(CONFIG_OMAP_IOMMU) := iommu2.o omap-iommu.o +obj-$(CONFIG_OMAP_IOMMU) := iommu2.o + +iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o +obj-y += $(iommu-m) $(iommu-y) i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o obj-y += $(i2c-omap-m) $(i2c-omap-y) -- 1.7.1.rc1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Suspend block api (version 8)
On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote: On Saturday 22 May 2010, Arve Hjønnevåg wrote: This patch series adds a suspend-block api that provides the same functionality as the android wakelock api. This version adds a delay before suspending again if no suspend blockers were used during the last suspend attempt. Patches [1-6/8] applied to suspend-2.6/linux-next funny thing is that even without sorting out the concerns plenty of developers had on the other thread, this series is still taken. What's the point in dicussing/reviewing the patches then ? -- 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
[PATCH 2/3] omap: iommu-add functionality to get TLB miss interrupt
In order to enable TLB miss interrupt, the TWL should be
disabled. This patch provides the functionality to get the
MMU fault interrupt for a TLB miss in the cases where the
users are working with the locked TLB entries and with TWL
disabled.
New interface is added to select twl and to enable TLB miss
interrupt.
Signed-off-by: Hari Kanigeri
Signed-off-by: Ramesh Gupta
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-omap2/iommu2.c| 32 ++
arch/arm/plat-omap/include/plat/iommu.h |2 +
arch/arm/plat-omap/iommu.c | 17
3 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index ebbdae2..edf7cd4 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -65,6 +65,26 @@
((pgsz) == MMU_CAM_PGSZ_64K) ? 0x :\
((pgsz) == MMU_CAM_PGSZ_4K) ? 0xf000 : 0)
+
+static void __iommu_set_twl(struct iommu *obj, bool on)
+{
+ u32 l = iommu_read_reg(obj, MMU_CNTL);
+
+ if (on)
+ iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
+ else
+ iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+
+ l &= ~MMU_CNTL_MASK;
+ if (on)
+ l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
+ else
+ l |= (MMU_CNTL_MMU_EN);
+
+ iommu_write_reg(obj, l, MMU_CNTL);
+}
+
+
static int omap2_iommu_enable(struct iommu *obj)
{
u32 l, pa;
@@ -100,13 +120,9 @@ static int omap2_iommu_enable(struct iommu *obj)
l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
iommu_write_reg(obj, l, MMU_SYSCONFIG);
- iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
iommu_write_reg(obj, pa, MMU_TTB);
- l = iommu_read_reg(obj, MMU_CNTL);
- l &= ~MMU_CNTL_MASK;
- l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
- iommu_write_reg(obj, l, MMU_CNTL);
+ __iommu_set_twl(obj, true);
return 0;
}
@@ -122,6 +138,11 @@ static void omap2_iommu_disable(struct iommu *obj)
dev_dbg(obj->dev, "%s is shutting down\n", obj->name);
}
+static void omap2_iommu_set_twl(struct iommu *obj, bool on)
+{
+ __iommu_set_twl(obj, false);
+}
+
static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
{
int i;
@@ -304,6 +325,7 @@ static const struct iommu_functions omap2_iommu_ops = {
.enable = omap2_iommu_enable,
.disable= omap2_iommu_disable,
+ .set_twl= omap2_iommu_set_twl,
.fault_isr = omap2_iommu_fault_isr,
.tlb_read_cr= omap2_tlb_read_cr,
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 0752af9..33c7d41 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -80,6 +80,7 @@ struct iommu_functions {
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
+ void (*set_twl)(struct iommu *obj, bool on);
u32 (*fault_isr)(struct iommu *obj, u32 *ra);
void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
@@ -143,6 +144,7 @@ extern void iotlb_cr_to_e(struct cr_regs *cr, struct
iotlb_entry *e);
extern u32 iotlb_cr_to_virt(struct cr_regs *cr);
extern int load_iotlb_entry(struct iommu *obj, struct iotlb_entry *e);
+extern void iommu_set_twl(struct iommu *obj, bool on);
extern void flush_iotlb_page(struct iommu *obj, u32 da);
extern void flush_iotlb_range(struct iommu *obj, u32 start, u32 end);
extern void flush_iotlb_all(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b2b3937..aa064e1 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -370,6 +370,23 @@ void flush_iotlb_all(struct iommu *obj)
}
EXPORT_SYMBOL_GPL(flush_iotlb_all);
+/**
+ * iommu_set_twl - enable/disable table walking logic
+ * @obj: target iommu
+ * @on:enable/disable
+ *
+ * Function used to enable/disable TWL. If one wants to work
+ * exclusively with locked TLB entries and receive notifications
+ * for TLB miss then call this function to disable TWL.
+ */
+void iommu_set_twl(struct iommu *obj, bool on)
+{
+ clk_enable(obj->clk);
+ arch_iommu->set_twl(obj, on);
+ clk_disable(obj->clk);
+}
+EXPORT_SYMBOL_GPL(iommu_set_twl);
+
#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
--
1.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3][v3] omap:iommu-enable TLB miss interrupt
The current iommu module doesn't provide the mechanism to get MMU fault on TLB miss when working with locked TLB entries and TWL disabled. To get the TLB miss interrupt, the TWL should be disabled. This patch set provides the option to enable/disable TWL and to enable TLB miss interrupt. Based on Hiroshi, the initial patch set was revised to add more flexibility to enable TWL and cleanup the part of the code that had layering violations. https://patchwork.kernel.org/patch/101336/ Hari Kanigeri (2): omap: iommu-update irq mask to be specific about twl and tlb omap: iommu-add functionality to get TLB miss interrupt Hiroshi DOYU (1): omap iommu: move iommu_disable at fault to the above layer arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 19 + 3 files changed, 56 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] omap iommu: move iommu_disable at fault to the above layer
From: Hiroshi DOYU
The function prefix "omap2_iommu_" indicates that the prefixed
function belongs to "omap2_iommu_ops" to provide iommu basic
functionalities for the above layers. It's better to avoid the
prefixed function called in the same prefixed ones internally, like
nested here. Now "iommu_disable" is called just after fault_isr() in
the above layer. This is a little bit more sensible to keep the
consistency of module layers.
Signed-off-by: Hiroshi DOYU
---
arch/arm/mach-omap2/iommu2.c |2 +-
arch/arm/plat-omap/iommu.c |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index edf7cd4..14ee686 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -172,7 +172,7 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
printk("\n");
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
- omap2_iommu_disable(obj);
+
return stat;
}
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index aa064e1..344af31 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -782,6 +782,8 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
if (!stat)
return IRQ_HANDLED;
+ iommu_disable(obj);
+
iopgd = iopgd_offset(obj, da);
if (!(*iopgd & IOPGD_TABLE)) {
--
1.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] omap: iommu-update irq mask to be specific about twl and tlb
Revise the IRQ mask definitions to handle the MMU faults related to TWL fault as well as TLB miss fault. Signed-off-by: Hari Kanigeri Signed-off-by: Hiroshi Doyu --- arch/arm/mach-omap2/iommu2.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c index e82da68..ebbdae2 100644 --- a/arch/arm/mach-omap2/iommu2.c +++ b/arch/arm/mach-omap2/iommu2.c @@ -44,9 +44,13 @@ #define MMU_IRQ_EMUMISS(1 << 2) #define MMU_IRQ_TRANSLATIONFAULT (1 << 1) #define MMU_IRQ_TLBMISS(1 << 0) -#define MMU_IRQ_MASK \ - (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_EMUMISS | \ -MMU_IRQ_TRANSLATIONFAULT) + +#define __MMU_IRQ_FAULT\ + (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_EMUMISS | MMU_IRQ_TRANSLATIONFAULT) +#define MMU_IRQ_MASK \ + (__MMU_IRQ_FAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_TLBMISS) +#define MMU_IRQ_TWL_MASK (__MMU_IRQ_FAULT | MMU_IRQ_TABLEWALKFAULT) +#define MMU_IRQ_TLB_MISS_MASK (__MMU_IRQ_FAULT | MMU_IRQ_TLBMISS) /* MMU_CNTL */ #define MMU_CNTL_SHIFT 1 @@ -96,7 +100,7 @@ static int omap2_iommu_enable(struct iommu *obj) l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE); iommu_write_reg(obj, l, MMU_SYSCONFIG); - iommu_write_reg(obj, MMU_IRQ_MASK, MMU_IRQENABLE); + iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE); iommu_write_reg(obj, pa, MMU_TTB); l = iommu_read_reg(obj, MMU_CNTL); -- 1.7.0 -- 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 1/2] omap: mailbox: initial hwmod support
Felipe,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Felipe Contreras
> Sent: Saturday, May 22, 2010 12:25 PM
> To: linux-omap
> Cc: Hiroshi Doyu; Kevin Hilman; Paul Walmsley; Ohad Ben-Cohen; Felipe
> Contreras
> Subject: [RFC/PATCH 1/2] omap: mailbox: initial hwmod support
>
> Only OMAP3 would work.
-- This is good start.
I will look into adding/verifying OMAP4 support. If any one already started
this effort please inform.
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-
> omap2/omap_hwmod_3xxx_data.c
> index ed60840..62b8fa8 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -164,12 +164,57 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
> };
>
-- Probably this should form a new patch.
Thank you,
Best regards,
Hari
--
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 015/199] Video omap lcd_omap3beagle.c: duplicated include
drivers/video/omap/lcd_omap3beagle.c: plat/mux.h is included more than once. Signed-off-by: Andrea Gelmini --- drivers/video/omap/lcd_omap3beagle.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap/lcd_omap3beagle.c b/drivers/video/omap/lcd_omap3beagle.c index ca75cc2..ac715f9 100644 --- a/drivers/video/omap/lcd_omap3beagle.c +++ b/drivers/video/omap/lcd_omap3beagle.c @@ -26,7 +26,6 @@ #include #include -#include #include #include "omapfb.h" -- 1.7.1.251.gf80a2 -- 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
Looking for definition of omap_set_dma_src_endian_type
omap_set_dma_src_endian_type is defined in dma.h, but not dma.c. Should this patch have been applied? http://www.mail-archive.com/linux-omap@vger.kernel.org/msg07201.html Philip -- 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] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
> > >"incompatible Kconfig role setting" > > there's a patch making that a warning instead of an #error > if I'm not wrong. It's not an #error, it's a dev_err(). But more to the point, it's reporting a real error. As the comment in the code explains: /* The driver might handle more features than * the board; OK. * Fail when the board needs a feature that's * not enabled. */ Ut;s simple: OTG connectors require OTG support. Host connectors require host support. Peripheral connectors require peripheral support. Why is anyone confused?? -- 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] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
--- On Fri, 5/21/10, Gupta, Ajay Kumar wrote: > > >Then I think these #ifdefferys are required in all > the board files. As I already explained: *NO*. Unless the board has been designed in a flakey manner (like the DM6446 EVM) it should have no #ifdeffery in the MUSB configuration. > > >Then if I choose to compile the Kernel only for > peripheral mode > > >(Case-B above) then I would get below error from > musb_core.c. > > > > > >"incompatible Kconfig role setting" That's a *correct* report that your config is broken. The hardware has an OTG connector, so the kernel should be supporting OTG mode. If it's not, that's an error; don't try to hide such errors. - Dave -- 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 v3] ARM: mach-shmobile: add framebuffer support for ap4evb
On Sun, May 23, 2010 at 04:04:03PM +0200, Guennadi Liakhovetski wrote: > ap4evb uses an LCD, connected to the SoC over the MIPI bus. This patch adds > platform data to configure this display and a static clock activation. > > Signed-off-by: Guennadi Liakhovetski > Tested-by: Damian Hobson-Garcia Please just repost the entire series with the updates. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5 v3] ARM: mach-shmobile: add framebuffer support for ap4evb
ap4evb uses an LCD, connected to the SoC over the MIPI bus. This patch adds
platform data to configure this display and a static clock activation.
Signed-off-by: Guennadi Liakhovetski
Tested-by: Damian Hobson-Garcia
---
v2 -> v3:
1. updated to the current genesis tree
2. changed clock names to match the new implementation
3. adjusted the subject line
arch/arm/mach-shmobile/Kconfig|1 +
arch/arm/mach-shmobile/board-ap4evb.c | 121 +
2 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index a8bd47f..368e41d 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -40,6 +40,7 @@ config MACH_AP4EVB
bool "AP4EVB board"
depends on ARCH_SH7372
select ARCH_REQUIRE_GPIOLIB
+ select SH_LCD_MIPI_DSI
comment "SH-Mobile System Configuration"
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index 6905ec4..e02e09a 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -17,6 +17,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include
#include
#include
#include
@@ -35,8 +36,14 @@
#include
#include
#include
+
+#include
+#include
+
#include
+#include
#include
+
#include
#include
#include
@@ -294,12 +301,87 @@ static struct platform_device usb1_host_device = {
.resource = usb1_host_resources,
};
+static struct sh_mobile_lcdc_info sh_mobile_lcdc_info = {
+ .clock_source = LCDC_CLK_PERIPHERAL, /* One of interface clocks */
+ .ch[0] = {
+ .chan = LCDC_CHAN_MAINLCD,
+ .bpp = 16,
+ .interface_type = RGB24,
+ .clock_divider = 1,
+ .flags = LCDC_FLAGS_DWPOL,
+ .lcd_cfg = {
+ .name = "R63302(QHD)",
+ .xres = 544,
+ .yres = 961,
+ .left_margin = 72,
+ .right_margin = 600,
+ .hsync_len = 16,
+ .upper_margin = 8,
+ .lower_margin = 8,
+ .vsync_len = 2,
+ .sync = FB_SYNC_VERT_HIGH_ACT | FB_SYNC_HOR_HIGH_ACT,
+ },
+ .lcd_size_cfg = {
+ .width = 44,
+ .height = 79,
+ },
+ }
+};
+
+static struct resource lcdc_resources[] = {
+ [0] = {
+ .name = "LCDC",
+ .start = 0xfe94, /* P4-only space */
+ .end= 0xfe943fff,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0x580),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device lcdc_device = {
+ .name = "sh_mobile_lcdc_fb",
+ .num_resources = ARRAY_SIZE(lcdc_resources),
+ .resource = lcdc_resources,
+ .dev= {
+ .platform_data = &sh_mobile_lcdc_info,
+ .coherent_dma_mask = ~0,
+ },
+};
+
+static struct resource mipidsi0_resources[] = {
+ [0] = {
+ .start = 0xffc6,
+ .end= 0xffc68fff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct sh_mipi_dsi_info mipidsi0_info = {
+ .data_format= MIPI_RGB888,
+ .lcd_chan = &sh_mobile_lcdc_info.ch[0],
+};
+
+static struct platform_device mipidsi0_device = {
+ .name = "sh-mipi-dsi",
+ .num_resources = ARRAY_SIZE(mipidsi0_resources),
+ .resource = mipidsi0_resources,
+ .id = 0,
+ .dev= {
+ .platform_data = &mipidsi0_info,
+ },
+};
+
static struct platform_device *ap4evb_devices[] __initdata = {
&nor_flash_device,
&smc911x_device,
&keysc_device,
&sdhi0_device,
&usb1_host_device,
+ &lcdc_device,
+ &mipidsi0_device,
};
/* TouchScreen (Needs SW3 set to OFF) */
@@ -343,6 +425,45 @@ static void __init ap4evb_map_io(void)
shmobile_setup_console();
}
+/* This function will disappear when we switch to (runtime) PM */
+static int __init ap4evb_init_display_clk(void)
+{
+ struct clk *lcdc_clk;
+ struct clk *dsitx_clk;
+ int ret;
+
+ lcdc_clk = clk_get(&lcdc_device.dev, "sh_mobile_lcdc_fb.0");
+ if (IS_ERR(lcdc_clk))
+ return PTR_ERR(lcdc_clk);
+
+ dsitx_clk = clk_get(&mipidsi0_device.dev, "sh-mipi-dsi.0");
+ if (IS_ERR(dsitx_clk)) {
+ ret = PTR_ERR(dsitx_clk);
+ goto eclkdsitxget;
+ }
+
+ ret = clk_enable(lcdc_clk);
+ if (ret < 0)
+ goto eclklcdcon;
+
+ ret = clk_enable(dsi
[PATCH 4/5 v3] sh-mobile: add support for displays, connected over the MIPI bus
Some SH-mobile SoCs have a MIPI DSI controller, that can be used to connect
MIPI displays to LCDC. This patch adds a platform driver for SH-mobile MIPI DSI
unit. It uses existing hooks in the sh_mobile_lcdcfb.c driver for display
activation and deactivation.
Signed-off-by: Guennadi Liakhovetski
Tested-by: Damian Hobson-Garcia
---
v2 -> v3:
1. added the missing header
2. switched back to PLL clock multiplier = 23: with the current kernel 13
produces flicker on the display.
drivers/video/Kconfig |8 +
drivers/video/Makefile |1 +
drivers/video/sh_mipi_dsi.c | 505 +++
include/video/sh_mipi_dsi.h | 35 +++
4 files changed, 549 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/sh_mipi_dsi.c
create mode 100644 include/video/sh_mipi_dsi.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6e16244..773c4a6 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1879,6 +1879,13 @@ config FB_W100
If unsure, say N.
+config SH_MIPI_DSI
+ tristate
+ depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
+
+config SH_LCD_MIPI_DSI
+ bool
+
config FB_SH_MOBILE_LCDC
tristate "SuperH Mobile LCDC framebuffer support"
depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
@@ -1887,6 +1894,7 @@ config FB_SH_MOBILE_LCDC
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
+ select SH_MIPI_DSI if SH_LCD_MIPI_DSI
---help---
Frame buffer driver for the on-chip SH-Mobile LCD controller.
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ddc2af2..3c3bf86 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -123,6 +123,7 @@ obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o
obj-$(CONFIG_FB_PS3) += ps3fb.o
obj-$(CONFIG_FB_SM501)+= sm501fb.o
obj-$(CONFIG_FB_XILINX) += xilinxfb.o
+obj-$(CONFIG_SH_MIPI_DSI)+= sh_mipi_dsi.o
obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o
obj-$(CONFIG_FB_OMAP) += omap/
obj-y += omap2/
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
new file mode 100644
index 000..017ae9f
--- /dev/null
+++ b/drivers/video/sh_mipi_dsi.c
@@ -0,0 +1,505 @@
+/*
+ * Renesas SH-mobile MIPI DSI support
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define CMTSRTCTR 0x80d0
+#define CMTSRTREQ 0x8070
+
+#define DSIINTE0x0060
+
+/* E.g., sh7372 has 2 MIPI-DSIs - one for each LCDC */
+#define MAX_SH_MIPI_DSI 2
+
+struct sh_mipi {
+ void __iomem*base;
+ struct clk *dsit_clk;
+ struct clk *dsip_clk;
+};
+
+static struct sh_mipi *mipi_dsi[MAX_SH_MIPI_DSI];
+
+/* Protect the above array */
+static DEFINE_MUTEX(array_lock);
+
+static struct sh_mipi *sh_mipi_by_handle(int handle)
+{
+ if (handle >= ARRAY_SIZE(mipi_dsi) || handle < 0)
+ return NULL;
+
+ return mipi_dsi[handle];
+}
+
+static int sh_mipi_send_short(struct sh_mipi *mipi, u8 dsi_cmd,
+ u8 cmd, u8 param)
+{
+ u32 data = (dsi_cmd << 24) | (cmd << 16) | (param << 8);
+ int cnt = 100;
+
+ /* transmit a short packet to LCD panel */
+ iowrite32(1 | data, mipi->base + 0x80d0); /* CMTSRTCTR */
+ iowrite32(1, mipi->base + 0x8070); /* CMTSRTREQ */
+
+ while ((ioread32(mipi->base + 0x8070) & 1) && --cnt)
+ udelay(1);
+
+ return cnt ? 0 : -ETIMEDOUT;
+}
+
+#define LCD_CHAN2MIPI(c) ((c) < LCDC_CHAN_MAINLCD || (c) > LCDC_CHAN_SUBLCD ? \
+ -EINVAL : (c) - 1)
+
+static int sh_mipi_dcs(int handle, u8 cmd)
+{
+ struct sh_mipi *mipi = sh_mipi_by_handle(LCD_CHAN2MIPI(handle));
+ if (!mipi)
+ return -ENODEV;
+ return sh_mipi_send_short(mipi, MIPI_DSI_DCS_SHORT_WRITE, cmd, 0);
+}
+
+static int sh_mipi_dcs_param(int handle, u8 cmd, u8 param)
+{
+ struct sh_mipi *mipi = sh_mipi_by_handle(LCD_CHAN2MIPI(handle));
+ if (!mipi)
+ return -ENODEV;
+ return sh_mipi_send_short(mipi, MIPI_DSI_DCS_SHORT_WRITE_PARAM, cmd,
+ param);
+}
+
+static void sh_mipi_dsi_enable(struct sh_mipi *mipi, bool enable)
+{
+ /*
+* enable LCDC data tx, transition to LPS after completion of each HS
+* packet
+*/
+ iowrite32(0x0002 | enable, mipi->base + 0x8000); /* DTCTR */
+}
+
+static void sh_mipi_shutdown(struct platform_device *pdev)
+{
+ struct sh_mipi *mipi = platform_get_drvdata(pdev);
+
+ sh_mip
[PATCH 2/5 v2] ARM: mach-shmobile: add LCDC and MIPI DSI-Tx clock definitions to sh7372
Define clock objects for switching on and off clocks for LCDC0, LCDC1 and MIPI
DSI-Tx.
Signed-off-by: Guennadi Liakhovetski
---
v1 -> v2:
1. reimplemented based on the arm-shmobile clocking scheme v2. Please,
verify, that this is ok now, also that the naming choise is suitable.
2. adjusted the subject line
arch/arm/mach-shmobile/clock-sh7372.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-sh7372.c
b/arch/arm/mach-shmobile/clock-sh7372.c
index ac46b4b..d6414ad 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -241,7 +241,10 @@ struct clk div6_clks[DIV6_NR] = {
};
enum { MSTP001,
- MSTP131, MSTP130, MSTP129, MSTP128, MSTP116, MSTP106, MSTP101,
+ MSTP131, MSTP130,
+ MSTP129, MSTP128,
+ MSTP118, MSTP117, MSTP116,
+ MSTP106, MSTP101, MSTP100,
MSTP223,
MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
MSTP329, MSTP323, MSTP322, MSTP314, MSTP313,
@@ -257,9 +260,12 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP130] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 30, 0), /* VEU2 */
[MSTP129] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 29, 0), /* VEU1 */
[MSTP128] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 28, 0), /* VEU0 */
+ [MSTP118] = MSTP(&div6_clks[DIV4_B], SMSTPCR1, 18, 0), /* DSITX */
+ [MSTP117] = MSTP(&div6_clks[DIV4_B], SMSTPCR1, 17, 0), /* LCDC1 */
[MSTP116] = MSTP(&div6_clks[DIV6_SUB], SMSTPCR1, 16, 0), /* IIC0 */
[MSTP106] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 6, 0), /* JPU */
[MSTP101] = MSTP(&div4_clks[DIV4_M1], SMSTPCR1, 1, 0), /* VPU */
+ [MSTP100] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 0, 0), /* LCDC0 */
[MSTP223] = MSTP(&div6_clks[DIV6_SPU], SMSTPCR2, 23, 0), /* SPU2 */
[MSTP207] = MSTP(&div6_clks[DIV6_SUB], SMSTPCR2, 7, 0), /* SCIFA5 */
[MSTP206] = MSTP(&div6_clks[DIV6_SUB], SMSTPCR2, 6, 0), /* SCIFB */
@@ -335,9 +341,12 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("uio_pdrv_genirq.2", &mstp_clks[MSTP130]), /* VEU2 */
CLKDEV_DEV_ID("uio_pdrv_genirq.1", &mstp_clks[MSTP129]), /* VEU1 */
CLKDEV_DEV_ID("uio_pdrv_genirq.0", &mstp_clks[MSTP128]), /* VEU0 */
+ CLKDEV_DEV_ID("sh-mipi-dsi.0", &mstp_clks[MSTP118]), /* DSITX */
+ CLKDEV_DEV_ID("sh_mobile_lcdc_fb.1", &mstp_clks[MSTP117]), /* LCDC1 */
CLKDEV_DEV_ID("i2c-sh_mobile.0", &mstp_clks[MSTP116]), /* IIC0 */
CLKDEV_DEV_ID("uio_pdrv_genirq.5", &mstp_clks[MSTP106]), /* JPU */
CLKDEV_DEV_ID("uio_pdrv_genirq.0", &mstp_clks[MSTP101]), /* VPU */
+ CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", &mstp_clks[MSTP100]), /* LCDC0 */
CLKDEV_DEV_ID("uio_pdrv_genirq.6", &mstp_clks[MSTP223]), /* SPU2DSP0 */
CLKDEV_DEV_ID("uio_pdrv_genirq.7", &mstp_clks[MSTP223]), /* SPU2DSP1 */
CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP207]), /* SCIFA5 */
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][RFT][PATCH] OMAPFB: LCDC: change update_mode to DISABLED when going suspend
Monday 17 May 2010 03:20:13 Janusz Krzysztofik wrote:
> I was observing the following error messages on my OMAP1 based Amstrad
> Delta board when first changing from text to graphics mode or vice versa
> after the LCD display had been blanked:
> omapfb omapfb: timeout waiting for FRAME DONE
> with a followup error message while unblanking it back:
> omapfb omapfb: resetting (status 0xffb2,reset count 1)
> As a visible result, image pixels happened to be shifted by a few bits,
> giving wrong colors.
>
> Examining the code, I found that this problem occures when an OMAP1
> internal LCD controller is disabled from omap_lcdc_suspend() and then a
> subsequent omap_lcdc_setup_plane() calls disable_controller() again. This
> potentially error provoking behaviour is triggered by the lcdc.update_mode
> flag being kept at OMAP_AUTO_UPDATE, regardless of the controller and panel
> being suspended.
>
> This patch tries to correct the problem by replacing both
> omap_lcdc_suspend() and omap_lcdc_resume() function bodies with single
> calls to
> omap_lcdc_set_update_mode() with a respective OMAP_UPDATE_DISABLE or
> OMAP_AUTO_UPDATE argument. As a result, exactly the same lower level
> operations are performed, with addition of changing the lcdc.update_mode
> flag to a value better suited for the controller state. This prevents any
> further calls to disable_controller() from omap_lcdc_setup_plane() while
> the display is suspended.
Hi,
One more week of successfull, trouble-free testing on my side. Although there
were no other test reports, no objections nor change requests were raised as
well on this relatively simple and straightforward patch. Could we then agree
on it being accepted for inclusion? Tomi?
Thanks,
Janusz
> Created against linux-2.6.34-rc7.
> Tested on Amstrad Delta.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> Hi,
>
> Those of you having access to other display equipped OMAP1 boards, could
> you please test if this patch doesn't break anything?
>
> Thanks,
> Janusz
>
> drivers/video/omap/lcdc.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> --- git/drivers/video/omap/lcdc.c.orig2010-05-16 21:39:20.0
> +0200
> +++ git/drivers/video/omap/lcdc.c 2010-05-17 00:00:43.0 +0200
> @@ -572,22 +572,12 @@ static enum omapfb_update_mode omap_lcdc
> /* PM code called only in internal controller mode */
> static void omap_lcdc_suspend(void)
> {
> - if (lcdc.update_mode == OMAPFB_AUTO_UPDATE) {
> - disable_controller();
> - omap_stop_lcd_dma();
> - }
> + omap_lcdc_set_update_mode(OMAPFB_UPDATE_DISABLED);
> }
>
> static void omap_lcdc_resume(void)
> {
> - if (lcdc.update_mode == OMAPFB_AUTO_UPDATE) {
> - setup_regs();
> - load_palette();
> - setup_lcd_dma();
> - set_load_mode(OMAP_LCDC_LOAD_FRAME);
> - enable_irqs(OMAP_LCDC_IRQ_DONE);
> - enable_controller();
> - }
> + omap_lcdc_set_update_mode(OMAPFB_AUTO_UPDATE);
> }
>
> static void omap_lcdc_get_caps(int plane, struct omapfb_caps *caps)
--
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: omap: Build failure with tip of Linus' tree
On Sun, May 23, 2010 at 03:11:08AM +0300, Amit Kucheria wrote: > Tony, > > I see the following build failure with the latest tip from Linus. I'm not > sure if something is yet to be merged for other subsystem trees before -rc1, > but a patch to fix the build is attached. FWIw: Acked-by: Felipe Balbi -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
