Re: [PATCH 2/2] omap: iommu-add functionality to get TLB miss interrupt
Hi Hari,
From: ext Hari Kanigeri h-kanige...@ti.com
Subject: [PATCH 2/2] omap: iommu-add functionality to get TLB miss interrupt
Date: Tue, 18 May 2010 01:12:30 +0200
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.
I want to keep leave the functionality to allow the locked TLB and
TWL enabled at the same time too. Is it still feasible with this?
New interface is added to disable twl and enable TLB miss
interrupt.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ramesh Gupta grgu...@ti.com
---
arch/arm/mach-omap2/iommu2.c| 13 +
arch/arm/plat-omap/include/plat/iommu.h |2 ++
arch/arm/plat-omap/iommu.c | 12
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index fcf4f4a..2e78cea 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -124,6 +124,18 @@ static void omap2_iommu_disable(struct iommu *obj)
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
+static void omap2_iommu_disable_twl(struct iommu *obj)
+{
+ u32 l = iommu_read_reg(obj, MMU_CNTL);
+
+ l = ~MMU_CNTL_MASK;
+ l |= (MMU_CNTL_MMU_EN);
+ iommu_write_reg(obj, l, MMU_CNTL);
+
+ /* Enable TLB miss interrupt */
+ iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+}
+
static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
{
int i;
@@ -306,6 +318,7 @@ static const struct iommu_functions omap2_iommu_ops = {
.enable = omap2_iommu_enable,
.disable= omap2_iommu_disable,
+ .disable_twl= omap2_iommu_disable_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..52a3852 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 (*disable_twl)(struct iommu *obj);
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_disable_twl(struct iommu *obj);
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..d64a4d8 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -370,6 +370,18 @@ void flush_iotlb_all(struct iommu *obj)
}
EXPORT_SYMBOL_GPL(flush_iotlb_all);
+/**
+ * Call this function if working with locked TLB entries and
+ * TWL disabled
+ */
nitpick: It may be better to follow this for global func.
From linux/Documentation/kernel-doc-nano-HOWTO.txt:
...
Example kernel-doc function comment:
/**
* foobar() - short function description of foobar
* @arg1: Describe the first argument to foobar.
* @arg2: Describe the second argument to foobar.
* One can provide multiple line descriptions
* for arguments.
*
* A longer description, with more discussion of the function foobar()
* that might be useful to those using or modifying it. Begins with
* empty comment line, and may include additional embedded empty
* comment lines.
*
* The longer description can have multiple paragraphs.
*/
+extern void iommu_disable_twl(struct iommu *obj)
extern?
+{
+ clk_enable(obj-clk);
+ arch_iommu-disable_twl(obj);
+ clk_disable(obj-clk);
+}
+EXPORT_SYMBOL_GPL(iommu_disable_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
Re: [PATCH 1/2] omap: iommu-update irq mask to be specific about twl
Hi Hari, From: ext Hari Kanigeri h-kanige...@ti.com Subject: [PATCH 1/2] omap: iommu-update irq mask to be specific about twl Date: Tue, 18 May 2010 01:12:29 +0200 Update the irq mask so that is is clear that the MMU ~~typo? interrupt is related to TWL fault. Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/mach-omap2/iommu2.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c index e82da68..fcf4f4a 100644 --- a/arch/arm/mach-omap2/iommu2.c +++ b/arch/arm/mach-omap2/iommu2.c @@ -46,7 +46,13 @@ #define MMU_IRQ_TLBMISS (1 0) #define MMU_IRQ_MASK \ (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_EMUMISS | \ - MMU_IRQ_TRANSLATIONFAULT) + MMU_IRQ_TRANSLATIONFAULT | MMU_IRQ_TLBMISS) +#define MMU_IRQ_TWL_MASK \ + (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_EMUMISS | \ + MMU_IRQ_TRANSLATIONFAULT) +#define MMU_IRQ_TLB_MISS_MASK\ + (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_TLBMISS | MMU_IRQ_EMUMISS | \ + MMU_IRQ_TRANSLATIONFAULT) nitpick: The above could look better as blew? #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 +102,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 0/6] DSPBRIDGE: fix mem+cache API issues
Hi Felipe, On Mon, May 17, 2010 at 3:05 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, May 17, 2010 at 2:25 AM, Ohad Ben-Cohen o...@wizery.com wrote: Out of curiosity, what board/environment do you use to play with the code ? I'd like to run the same use cases you do, so I can reproduce any issue you may bump into. I use a beagleboard, use the DSP firmware in L23.i3.3[1], do simple tests with dsp-test[2], and real tests with gst-dsp[3]. I just pushed my latest changes of dsp-tools, which include an app called dsp-test that sends buffers back and forth (like TI's dmmcopy.out), but has options to trigger MMU faults, change buffer sizes, and number of iterations, along with a trivial DSP socket-node. The whole thing (app + socket-node) is 15K and you don't even need dynreg.out to load. Also, the code is really really simple. There are no dependencies, so you can just type 'make'. I'm not sure if you are familiar with GStreamer, but that's pretty much all you need to compile gst-dsp. If you have problems we have a relatively active mailing list. Thanks for the detailed answer! I'll surely look into this. Ohad. Cheers. [1] http://www.omapedia.org/wiki/L23.i3.3_Release_Notes [2] http://github.com/felipec/dsp-tools [3] http://github.com/felipec/gst-dsp -- Felipe Contreras -- 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 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote: Right, because Firmware writers are from the rugged unresponsive uplands of planet ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and Software writers are from the emollient responsive groves of planet harmony. Obviously what would work for one wouldn't work for the other. As a software writer, I fully buy into that world view. The trouble is that when I go to dinner with hardware people, they seem to be awfully nice chaps ... almost exactly like me, in fact ... what does this add to suspend_blockers discussion ? -- 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: [RFC] Initial attempt to make ARM use LMB
On Mon, 2010-05-17 at 19:37 +0200, ext Tony Lindgren wrote: Sorry if I've been confused about what vram.c is doing. How about change vram.c to use dma_alloc_coherent for now? That would break the non-standard behaviour to preserve the log set by the bootloader, but that should be OK until we know how to deal with that properly. After that you could just optionally reserve the bootloader memory area using LMB based on some flags in the platform init data. From vram.c's commit log about features vram.c supports but dma_alloc_* doesn't: - Support for OMAP2's SRAM - Allocate without ioremapping - Allocate at defined physical addresses - Allows larger VRAM area and larger allocations I haven't heard anybody using OMAP2's SRAM for framebuffer, so that's probably not an issue. Reserving the memory at defined physical address is needed for the bootloader-framebuffer, but I think it's only used on N900's product kernel with some additional hacks. So that's probably not an issue either. Allocating without ioremapping... dma_alloc_* always ioremaps the allocated area, even though it's never used (in some cases). I think this is the case when using OMAP's VRFB rotation HW. This may or may not be an issue, depending on the amount of memory allocated and the available virtual mem area. And the last point, I think there was a limit of about 8MB when allocating with dma_alloc_* (I may remember wrong). This could be a problem for some use cases. So, I guess it's possible to use dma_alloc_*, but there may be some complications. I still haven't found time to look at the LMB stuff, but I hope I'll manage to do that this week. 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: dss2 for-next BUG at drivers/video/omap2/dss/core.c:323!
On Mon, 2010-05-17 at 16:30 +0200, ext Robert Nelson wrote: Hi Tomi, I've been using your dss2 branch with much success. http://gitorious.org/linux-omap-dss2/linux/commits/for-next I've just ran into a weird BUG that occurs on reboot on my headless beagles and wondering if you've ran into it too... The kernel I'm currently testing is 2.6.34-rc7 plus the 2.6.35 dss2 for-next commits.. I was assuming http://gitorious.org/linux-omap-dss2/linux/commit/89627989c6b4408c4578a41bcd5f9d04545797ad would fix it, but it hasn't fixed the Opps'ing... log on attempt to reboot: http://pastebin.com/iqAHMVD4 It looks like there's a mismatch with clock enables and disables somewhere... I haven't seen that. Can you tell me more details of your beagle? Does headless mean that it's standard beagle board, but no display is connected to it? Tomi Ps. Added linux-omap to cc, somebody there may have encountered this. -- 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 0/6] DSPBRIDGE: fix mem+cache API issues
On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras felipe.contre...@gmail.com wrote: So currently (v2.6.33), before sending a read-olny buffer (TO_DEVICE), we do dmac_flush_range (should be clean, but whatever) and before sending a write-only (FROM_DEVICE), we do dmac_inv_range. On v2.6.33 the same could be achieved with only dma_map_* functions, but on v2.6.34 that's not the case. Sorry, I didn't completely follow you here, let's take a look at the mapping code: ENTRY(v7_dma_map_area) add r1, r1, r0 teq r2, #DMA_FROM_DEVICE beq v7_dma_inv_range b v7_dma_clean_range ENDPROC(v7_dma_map_area) DMA_FROM_DEVICE will get the cache invalidated and then cleaned, and DMA_BIDIRECTIONAL/DMA_TO_DEVICE will get the cache only cleaned. Unfortunately I don't have a setup right now to test this, but the code seems to be ok for our needs, don't you think ? Thanks, Ohad. -- 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 PATCHv2 1/7] HSI: Introducing HSI framework
On Fri, 2010-05-14 at 16:22 +0200, ext Sebastien Jan wrote:
Hi Carlos,
After review, I do not have many comments on the interface, as we already
aligned on most of it.
Please see my comments inlined below.
On Friday 07 May 2010 17:18:31 Carlos Chinea wrote:
[strip]
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
[strip]
+/**
+ * hsi_start_tx - Signal the port that the client wants to start a TX
+ * @cl: Pointer to the HSI client
+ *
+ * Return -errno on failure, 0 on success
+ */
+static inline int hsi_start_tx(struct hsi_client *cl)
+{
+ if (!hsi_port_claimed(cl))
+ return -EACCES;
+ return hsi_get_port(cl)-start_tx(cl);
+}
+
+/**
+ * hsi_stop_tx - Signal the port that the client no longer wants to
transmit + * @cl: Pointer to the HSI client
+ *
+ * Return -errno on failure, 0 on success
+ */
+static inline int hsi_stop_tx(struct hsi_client *cl)
+{
+ if (!hsi_port_claimed(cl))
+ return -EACCES;
+ return hsi_get_port(cl)-stop_tx(cl);
+}
As I can see, these two I/F functions are the way an HSI protocol layer can
play with Tx_wake lines if it has to, right?
Right
I suppose it allows more flexibility with regards to 3/4 wires HSI flavors
management and avoids additional callbacks to Tx_wake related events?
Yep
Br,
Carlos Chinea
--
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] Initial attempt to make ARM use LMB
On Tue, May 18, 2010 at 10:47:57AM +0300, Tomi Valkeinen wrote: Allocating without ioremapping... dma_alloc_* always ioremaps the allocated area, even though it's never used (in some cases). What do you mean by that? Are you suggesting that something does phys_to_virt() on the returned DMA pointer? Why is it that OMAP seems to do all these _wrong_ things? -- 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 00/17] omap: mailbox: reorganize init
Hi Felipe, From: ext Felipe Contreras felipe.contre...@gmail.com Subject: [PATCH v2 00/17] omap: mailbox: reorganize init Date: Fri, 14 May 2010 17:01:33 +0200 Hi, The main purpose of this patch series is to be able to compile mach platform data as built-in. Otherwise, client modules such as bridgedriver will load the platform code, but not the mach code when mailbox is built as a module. I think that this is the *udev* responsibility. The udev should take care of loading mailbox_mach.ko since the mailbox platform device was registered by devices.ko at bootup. devices.ko is built in earlier than dspbridge.ko, so the mailbox platform device is registered earlier than the dsp device, C6410. this registration ordering should take care of the dependency if the udevd works correctly. Unfortunately, there's no easy way to do that since plat and mach code are deepely interrelated. So the first patches try to separate the mailbox registering through a defined omap_mbox_platform_data. Also, it's worth noting that mailboxes are not a one-to-one mapping to resources; that is, some resources belong to multiple mboxes. So it's best to think of mailboxes as fake devices. That is why custom platform_data is required. Actually there were logical mailbox devices/instances implemented, but it was broken partially when dropping mailbox class support by accident(*1). This is the reason whey omap_mbox struct has unused dev pointer now. At that time, the sysfs interface was not necessary but the device creation itself should not have been removed. I'll get this code back again soon. The role of each modules were/should be: - devices.ko: a platform device, based on its resource. - mailbox_mach.ko:a platform driver to register multiple logical mboxes/devices. - mailbox.ko: a kind of framework which holds multiple logical mboxes/devices. The sysfs structure is like below: ~# tree -d -L 2 /sys/devices/platform/omap2-mailbox/ /sys/devices/platform/omap2-mailbox/ |-- driver - ../../../bus/platform/drivers/omap2-mailbox |-- mbox | |-- dsp - they are each instances of logical mailbox. | |-- ducati | |-- iva2 | |-- mbox01 | |-- mbox02 | |-- mbox03 | `-- tesla |-- power `-- subsystem - ../../../bus/platform The platform device omap2-mailbox accomodatess logical mboxes. Finally, a bunch of cleaning up is done in the very first patches, specially for OMAP1. Most of the cleanups are quite ok. Would it be possible to rebase them on the top of my coming patch to get back logical device entry? Sorry for the late reply, it took some time to recall my bad memory... *1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19546.html The initial RFC included comments from Felipe Balbi, and this proposal includes comments from Tony Lindgren. v2: * Rebased on top of Hiroshi's v2.6.34-rc7.mailbox * A bit more extra cleanups v1 was tested on OMAP3 (beagleboard), and compiled-tested for OMAP1. v2 was compile-tested for OMAP3 and 1. Felipe Contreras (17): omap: mailbox: trivial whitespace cleanups omap: mailbox: trivial cleanups omap: mailbox: reorganize structures omap: mailbox: 2420 should be detected at run-time omap: mailbox: use correct config for omap1 omap: mailbox: update omap1 probing omap: mailbox: reorganize registering omap: mailbox: only compile for configured archs omap: mailbox: reorganize omap platform_device omap: mailbox: move more stuff to omap_mbox_init() omap: mailbox: trivial sync between omap1 and 2 omap: mailbox: split platform driver omap: mailbox: always built-in platform data omap: mailbox: reorganize headers omap: mailbox: don't export unecessary symbols omap: mailbox: mark some resources as __initdata omap: mailbox: don't export register/unregister arch/arm/mach-omap1/Makefile |6 +- arch/arm/mach-omap1/devices.c | 40 - arch/arm/mach-omap1/mailbox.c | 118 -- arch/arm/mach-omap2/Makefile |5 +- arch/arm/mach-omap2/devices.c | 92 --- arch/arm/mach-omap2/mailbox.c | 254 - arch/arm/plat-omap/include/plat/mailbox.h | 10 +- arch/arm/plat-omap/mailbox.c | 89 +++--- 8 files changed, 290 insertions(+), 324 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/5] omap3: pm: Generic TRITON power scriptsforOMAP3 based boards
-Original Message- From: Peter 'p2' De Schrijver [mailto:peter.de-schrij...@nokia.com] Sent: Monday, May 17, 2010 4:29 PM To: ext Lesly Arackal Manuel Cc: linux-omap@vger.kernel.org; 'Lesly A M'; 'Nishanth Menon'; 'David Derrick'; 'Samuel Ortiz' Subject: Re: [PATCH v5 3/5] omap3: pm: Generic TRITON power scriptsforOMAP3 based boards Hi, Hi Peter, The RES_TYPE field is same for all messages. The resource which can go to low-power mode with clk_req sig de- asserting is configured as RES_TYPE2 = '2'. And the resource which can go to low- power mode with sys_off sig de-asserting is configured as RES_TYPE2 = '1'. The RES_TYPE2 is '2' for P3 wakeup and the msg will applicable for Resource which have their TYPE2 field configured '2' (RES_VINTANA1, RES_VINTANA2, RES_VINTDIG, VIO, RES_CLKEN, RES_HFCLKOUT). RES_TYPE2 = '1' for P1_P2 wakeup. (Applicable for res: RES_VPLL1, RES_VDD1, RES_VDD2, RES_REGEN, RES_NRES_PWRON, RES_SYSEN) Ok. But why not just assign the resources to the appropriate groups ? Eg. assign VIO to P3 and assign VPLL1 to P1_P2 ? Then you only need one message type. Also, why are you using RES_TYPE2 instead of RES_TYPE ? Hi Peter, This sequence is recommended by the Hardware team. Because some resource have non-zero reset values for RES_TYPE, and may be used in some other seq (eg: power_up). Regards, Lesly A M -- 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] Initial attempt to make ARM use LMB
On Tue, 2010-05-18 at 10:40 +0200, ext Russell King - ARM Linux wrote: On Tue, May 18, 2010 at 10:47:57AM +0300, Tomi Valkeinen wrote: Allocating without ioremapping... dma_alloc_* always ioremaps the allocated area, even though it's never used (in some cases). What do you mean by that? Are you suggesting that something does phys_to_virt() on the returned DMA pointer? No. VRFB rotation HW uses the real memory as a backend storage, and exposes 0/90/180/270 degree views of that memory area via its own memory areas. So we need to reserve the real memory, program it to VRFB HW, and then map VRFB's memory areas, which are used as framebuffers. The real memory is never used directly in this case. And even when not using VRFB, I think it's not really required to map the framebuffer into kernel virtual memory. The kernel doesn't read/write from/to the framebuffer (except when using FB console), it's the user space, SGX or DSP that does the writing, and DSS which does the reading. However, currently the framebuffer is always mapped. 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: [RFC PATCHv2 2/7] OMAP SSI: Introducing OMAP SSI driver
On Fri, 2010-05-14 at 16:41 +0200, ext Sebastien Jan wrote:
Hi Carlos,
Please see my comments inlined.
On Friday 07 May 2010 17:18:32 Carlos Chinea wrote:
[strip]
diff --git a/drivers/hsi/controllers/omap_ssi.c
[strip]
+
+/**
+ * struct omap_ssm_ctx - OMAP synchronous serial module (TX/RX) context
+ * @mode: Bit transmission mode
+ * @channels: Number of channels
+ * @framesize: Frame size in bits
+ * @timeout: RX frame timeout
+ * @divisot: TX divider
Typo: s/divisot/divisor
+ * @arb_mode: Arbitration mode for TX frame (Round robin, priority)
+ */
+struct omap_ssm_ctx {
+ u32 mode;
+ u32 channels;
+ u32 frame_size;
+ union {
+ u32 timeout; /* Rx Only */
+ struct {
+ u32 arb_mode;
+ u32 divisor;
+ }; /* Tx only */
+ };
+};
+
+/**
+ * struct omap_ssi_port - OMAP SSI port data
+ * @dev: device associated to the port (HSI port)
+ * @sst_dma: SSI transmitter physical base address
+ * @ssr_dma: SSI receiver physical base address
+ * @sst_base: SSI transmitter base address
+ * @ssr_base: SSI receiver base address
wk_lock description is missing here
+ * @lock: Spin lock to serialize access to the SSI port
+ * @channels: Current number of channels configured (1,2,4 or 8)
+ * @txqueue: TX message queues
+ * @rxqueue: RX message queues
+ * @brkqueue: Queue of incoming HWBREAK requests (FRAME mode)
+ * @irq: IRQ number
+ * @wake_irq: IRQ number for incoming wake line (-1 if none)
+ * @pio_tasklet: Bottom half for PIO transfers and events
+ * @wake_tasklet: Bottom half for incoming wake events
+ * @wkin_cken: Keep track of clock references due to the incoming wake
line
+ * @wake_refcount: Reference count for output wake line
s/wake_refcount/wk_refcount
+ * @sys_mpu_enable: Context for the interrupt enable register for irq 0
+ * @sst: Context for the synchronous serial transmitter
+ * @ssr: Context for the synchronous serial receiver
+ */
+struct omap_ssi_port {
+ struct device *dev;
+ dma_addr_t sst_dma;
+ dma_addr_t ssr_dma;
+ unsigned long sst_base;
+ unsigned long ssr_base;
+ spinlock_t wk_lock;
+ spinlock_t lock;
+ unsigned intchannels;
+ struct list_headtxqueue[SSI_MAX_CHANNELS];
+ struct list_headrxqueue[SSI_MAX_CHANNELS];
+ struct list_headbrkqueue;
+ unsigned intirq;
+ int wake_irq;
+ struct tasklet_struct pio_tasklet;
+ struct tasklet_struct wake_tasklet;
+ unsigned intwkin_cken:1; /* Workaround */
+ int wk_refcount;
+ /* OMAP SSI port context */
+ u32 sys_mpu_enable; /* We use only one irq */
+ struct omap_ssm_ctx sst;
+ struct omap_ssm_ctx ssr;
+};
+
[strip]
+
+static void ssi_pio_complete(struct hsi_port *port, struct list_head
*queue) +{
+ struct hsi_controller *ssi =
to_hsi_controller(port-device.parent); + struct omap_ssi_controller
*omap_ssi = hsi_controller_drvdata(ssi); + struct omap_ssi_port
*omap_port = hsi_port_drvdata(port);
+ struct hsi_msg *msg;
+ u32 *buf;
+ u32 val;
+
+ spin_lock(omap_port-lock);
+ msg = list_first_entry(queue, struct hsi_msg, link);
+ if ((!msg-sgt.nents) || (!msg-sgt.sgl-length)) {
+ msg-actual_len = 0;
+ msg-status = HSI_STATUS_PENDING;
+ }
+ if (msg-status == HSI_STATUS_PROCEDING) {
+ buf = sg_virt(msg-sgt.sgl) + msg-actual_len;
+ if (msg-ttype == HSI_MSG_WRITE)
+ __raw_writel(*buf, omap_port-sst_base +
+
SSI_SST_BUFFER_CH_REG(msg-channel)); +else
+ *buf = __raw_readl(omap_port-ssr_base +
+
SSI_SSR_BUFFER_CH_REG(msg-channel)); +
dev_dbg(port-device, ch %d ttype %d 0x%08x\n, msg-channel, +
msg-ttype, *buf); +
msg-actual_len += sizeof(*buf);
+ if (msg-actual_len = msg-sgt.sgl-length)
+ msg-status = HSI_STATUS_COMPLETED;
+ /*
+* Wait for the last written frame to be really sent before
+* we call the complete callback
+*/
+ if ((msg-status == HSI_STATUS_PROCEDING) ||
+ ((msg-status == HSI_STATUS_COMPLETED)
+
Re: [PATCH 6/6] musb: dma: use optimal transfer element for sdma
Hello.
Ajay Kumar Gupta wrote:
Use optimal values of transfer element based on buffer address in system
DMA programming. This would improve the performance.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musbhsdma.c | 29 ++---
1 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index d29e487..39c1801 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -52,11 +52,34 @@ static void musb_sdma_channel_program(struct musb *musb,
struct musb_dma_channel *musb_channel,
dma_addr_t dma_addr, u32 len)
{
+ u16 frame = len;
+ int data_type = OMAP_DMA_DATA_TYPE_S8;
+
+ switch (dma_addr 0x3) {
+ case 0:
+ if ((len % 4) == 0) {
+ data_type = OMAP_DMA_DATA_TYPE_S32;
+ frame = len / 4;
+ break;
+ }
+ case 2:
+ if ((len % 2) == 0) {
+ data_type = OMAP_DMA_DATA_TYPE_S16;
+ frame = len / 2;
+ break;
+ }
+ case 1:
+ case 3:
+ default:
+ data_type = OMAP_DMA_DATA_TYPE_S8;
+ frame = len;
+ break;
The *break* is overindented.
WBR, Sergei
--
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] musb: AM35x: Workaround for fifo read issue
Hello.
Ajay Kumar Gupta wrote:
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v2:
- fixed multipline comment style
drivers/usb/musb/am3517.c| 31 +++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c
index b74e664..c68c784 100644
--- a/drivers/usb/musb/am3517.c
+++ b/drivers/usb/musb/am3517.c
@@ -515,3 +515,34 @@ void musb_platform_restore_context(struct
musb_context_registers
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if ((likely((0x03 (unsigned long) dst) == 0)) len = 4) {
You don't need to put likely() in parens.
+ readsl(fifo, dst, len 2);
+ dst += (len ~0x03);
You don't need parens here as well.
+ len = 0x03;
+ }
+ /*
+* Now read the rest 1 to 3 bytes or complete length if
+* unaligned address.
+*/
+ if (len 4) {
+ for (i = 0; i (len 2); i++) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, 4);
Can't you do away with memcpy() here?
+ dst += 4;
+ }
+ len %= 4;
+ }
+ if (len 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, len);
+ }
+}
WBR, Sergei
--
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 17/18] omap: rx51: Add supplies for the tlv320aic3x codec driver
On Thu, 6 May 2010 10:00:18 +0300
Eduardo Valentin eduardo.valen...@nokia.com wrote:
+static struct regulator_consumer_supply rx51_vio_supplies[] = {
+ /* tlv320aic3x digital supplies */
+ {
+ .supply = IOVDD,
+ .dev_name = 2-0018
+ },
+ {
+ .supply = DVDD,
+ .dev_name = 2-0018
+ },
+};
This isn't mandatory, but I find the code more readable if you use the
REGULATOR_SUPPLY macro,
which kinda suitable for cases like yours, where you are passing the pair
supplydev_name.
Yeah, I was just following how the MMC supplies were defined in this
file and it's better to convert all of these to use REGULATOR_SUPPLY
macro. I'll send conversion patch on top of this + one adding couple
supplies more I would like to get in during this merge window.
+static struct regulator_init_data rx51_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
I'm not sure if we would ever change voltage level in VIO in rx51 case.
It could enter sleep mode. But even there it wouldn't change voltage level.
Except, of cource, during off mode transition. But then, the regfw wouldn't
care.
Actually, one correction here, even during off mode transition I believe we
need to
keep it, otherwise some wake up source would be screwed.
What do you think about those other TWL regulators, do they have valid
mask bits so would it make sense to correct all of them at once? I'm
not expert with TWL RX51 HW but I'm thinking if there are also other
regulators which should not change. At least many regulators have the
same min_uV and max_uV defined.
--
Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] musb: AM35x: Workaround for fifo read issue
Hi,
Ajay Kumar Gupta wrote:
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v2:
- fixed multipline comment style
drivers/usb/musb/am3517.c| 31 +++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c
index b74e664..c68c784 100644
--- a/drivers/usb/musb/am3517.c
+++ b/drivers/usb/musb/am3517.c
@@ -515,3 +515,34 @@ void musb_platform_restore_context(struct
musb_context_registers
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if ((likely((0x03 (unsigned long) dst) == 0)) len = 4) {
You don't need to put likely() in parens.
Ok.
+ readsl(fifo, dst, len 2);
+ dst += (len ~0x03);
You don't need parens here as well.
Ok.
+ len = 0x03;
+ }
+ /*
+* Now read the rest 1 to 3 bytes or complete length if
+* unaligned address.
+*/
+ if (len 4) {
+ for (i = 0; i (len 2); i++) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, 4);
Can't you do away with memcpy() here?
Are you asking for change below?
*(u32 *)dst = musb_readl(fifo, 0);
-Ajay
+ dst += 4;
+ }
+ len %= 4;
+ }
+ if (len 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, len);
+ }
+}
WBR, Sergei
--
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 6/6] musb: dma: use optimal transfer element for sdma
Hi,
Ajay Kumar Gupta wrote:
Use optimal values of transfer element based on buffer address in system
DMA programming. This would improve the performance.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musbhsdma.c | 29 ++---
1 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index d29e487..39c1801 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -52,11 +52,34 @@ static void musb_sdma_channel_program(struct musb
*musb,
struct musb_dma_channel *musb_channel,
dma_addr_t dma_addr, u32 len)
{
+ u16 frame = len;
+ int data_type = OMAP_DMA_DATA_TYPE_S8;
+
+ switch (dma_addr 0x3) {
+ case 0:
+ if ((len % 4) == 0) {
+ data_type = OMAP_DMA_DATA_TYPE_S32;
+ frame = len / 4;
+ break;
+ }
+ case 2:
+ if ((len % 2) == 0) {
+ data_type = OMAP_DMA_DATA_TYPE_S16;
+ frame = len / 2;
+ break;
+ }
+ case 1:
+ case 3:
+ default:
+ data_type = OMAP_DMA_DATA_TYPE_S8;
+ frame = len;
+ break;
The *break* is overindented.
Ok.
-Ajay
WBR, Sergei
--
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] musb: AM35x: Workaround for fifo read issue
Hi,
Ajay Kumar Gupta wrote:
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v2:
- fixed multipline comment style
drivers/usb/musb/am3517.c| 31 +++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c
index b74e664..c68c784 100644
--- a/drivers/usb/musb/am3517.c
+++ b/drivers/usb/musb/am3517.c
@@ -515,3 +515,34 @@ void musb_platform_restore_context(struct
musb_context_registers
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if ((likely((0x03 (unsigned long) dst) == 0)) len = 4) {
You don't need to put likely() in parens.
Ok.
+ readsl(fifo, dst, len 2);
+ dst += (len ~0x03);
You don't need parens here as well.
Ok.
+ len = 0x03;
+ }
+ /*
+ * Now read the rest 1 to 3 bytes or complete length if
+ * unaligned address.
+ */
+ if (len 4) {
+ for (i = 0; i (len 2); i++) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, 4);
Can't you do away with memcpy() here?
Are you asking for change below?
*(u32 *)dst = musb_readl(fifo, 0);
This one is safe and works but the other memcpy (below one) would
not be safe to replace as the length would be 1 to 3 bytes.
-Ajay
+ dst += 4;
+ }
+ len %= 4;
+ }
+ if (len 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, len);
+ }
+}
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 0/6] DSPBRIDGE: fix mem+cache API issues
On Tue, May 18, 2010 at 11:05 AM, Ohad Ben-Cohen o...@wizery.com wrote: On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras felipe.contre...@gmail.com wrote: So currently (v2.6.33), before sending a read-olny buffer (TO_DEVICE), we do dmac_flush_range (should be clean, but whatever) and before sending a write-only (FROM_DEVICE), we do dmac_inv_range. On v2.6.33 the same could be achieved with only dma_map_* functions, but on v2.6.34 that's not the case. Sorry, I didn't completely follow you here, let's take a look at the mapping code: ENTRY(v7_dma_map_area) add r1, r1, r0 teq r2, #DMA_FROM_DEVICE beq v7_dma_inv_range b v7_dma_clean_range ENDPROC(v7_dma_map_area) DMA_FROM_DEVICE will get the cache invalidated and then cleaned, and DMA_BIDIRECTIONAL/DMA_TO_DEVICE will get the cache only cleaned. No, when DMA_FROM_DEVICE, only v7_dma_inv_range is executed (see the mov pc, lr at the end). Unfortunately I don't have a setup right now to test this, but the code seems to be ok for our needs, don't you think ? But yeah, actually that fits our needs; calling the dma_map only, while still wrong, will give us the same behavior we have right now (v2.6.33). So my table was wrong, it's actually: in: begin BIDI: dma_clean_range out: begin FROM_DEV: dma_inv_range out: end FROM_DEV: dma_inv_range in: end BIDI: dma_inv_range Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap: rx51: Use REGULATOR_SUPPLY macro when initializing regulator consumers
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 43 ++---
1 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 8179d55..ead7ee1 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -272,48 +272,27 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct regulator_consumer_supply rx51_vmmc1_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.0,
-};
+static struct regulator_consumer_supply rx51_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
-static struct regulator_consumer_supply rx51_vaux3_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vaux3_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
-static struct regulator_consumer_supply rx51_vsim_supply = {
- .supply = vmmc_aux,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vsim_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
- {
- .supply = AVDD,
- .dev_name = 2-0018,
- },
- {
- .supply = DRVDD,
- .dev_name = 2-0018,
- },
+ REGULATOR_SUPPLY(AVDD, 2-0018),
+ REGULATOR_SUPPLY(DRVDD, 2-0018),
/* Keep vmmc as last item. It is not iterated for newer boards */
- {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
- },
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
static struct regulator_consumer_supply rx51_vio_supplies[] = {
/* tlv320aic3x digital supplies */
- {
- .supply = IOVDD,
- .dev_name = 2-0018
- },
- {
- .supply = DVDD,
- .dev_name = 2-0018
- },
+ REGULATOR_SUPPLY(IOVDD, 2-0018),
+ REGULATOR_SUPPLY(DVDD, 2-0018),
};
static struct regulator_init_data rx51_vaux1 = {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: rx51: Add supplies and data for the tpa6130a2 headphone amplifier
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
This is build and boot safe but required if wanting to add support for
headphones in upcoming sound/soc/omap/rx51.c.
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ead7ee1..2376ef7 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -33,6 +33,8 @@
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include sound/tpa6130a2-plat.h
+
#include mux.h
#include hsmmc.h
@@ -285,6 +287,9 @@ static struct regulator_consumer_supply
rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
REGULATOR_SUPPLY(AVDD, 2-0018),
REGULATOR_SUPPLY(DRVDD, 2-0018),
+ /* tpa6130a2 */
+ REGULATOR_SUPPLY(CPVSS, 2-0060),
+ REGULATOR_SUPPLY(Vdd, 2-0060),
/* Keep vmmc as last item. It is not iterated for newer boards */
REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
@@ -652,10 +657,19 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
},
};
+static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = {
+ .id = TPA6130A2,
+ .power_gpio = 98,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
},
+ {
+ I2C_BOARD_INFO(tpa6130a2, 0x60),
+ .platform_data = rx51_tpa6130a2_data,
+ }
};
static int __init rx51_i2c_init(void)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
On Tue, May 18, 2010 at 2:02 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, May 18, 2010 at 11:05 AM, Ohad Ben-Cohen o...@wizery.com wrote: On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras felipe.contre...@gmail.com wrote: So currently (v2.6.33), before sending a read-olny buffer (TO_DEVICE), we do dmac_flush_range (should be clean, but whatever) and before sending a write-only (FROM_DEVICE), we do dmac_inv_range. On v2.6.33 the same could be achieved with only dma_map_* functions, but on v2.6.34 that's not the case. Sorry, I didn't completely follow you here, let's take a look at the mapping code: ENTRY(v7_dma_map_area) add r1, r1, r0 teq r2, #DMA_FROM_DEVICE beq v7_dma_inv_range b v7_dma_clean_range ENDPROC(v7_dma_map_area) DMA_FROM_DEVICE will get the cache invalidated and then cleaned, and DMA_BIDIRECTIONAL/DMA_TO_DEVICE will get the cache only cleaned. No, when DMA_FROM_DEVICE, only v7_dma_inv_range is executed (see the mov pc, lr at the end). Oh, sure. thanks for pointing that out. Unfortunately I don't have a setup right now to test this, but the code seems to be ok for our needs, don't you think ? But yeah, actually that fits our needs; calling the dma_map only, while still wrong, will give us the same behavior we have right now (v2.6.33). Great, so are you ok with this patchset proposal ? I'll just add support for the VM_IO path you mentioned. Thanks, Ohad. So my table was wrong, it's actually: in: begin BIDI: dma_clean_range out: begin FROM_DEV: dma_inv_range out: end FROM_DEV: dma_inv_range in: end BIDI: dma_inv_range Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] omap3 nand: cleanup exiting platform related code
The following set of patches applies on top of for-next branch. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle board And these are the patches required to address the following input - 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. v2: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28467.html Few functionality was missing like - There should be some locking as only one chipselect can use the ECC or prefetch engine at a time. If you have NAND in two chipselects, bad things would happen. v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28164.html Additionally, it was needed to implement more functions for the platform init code to use. Sukumar Ghorai (3): omap3 gpmc: functionality enhancement omap3 nand: cleanup virtual address usages omap3 nand: fix issue in board file to detect nand arch/arm/mach-omap2/board-cm-t35.c | 20 +--- arch/arm/mach-omap2/board-devkit8000.c | 25 +--- arch/arm/mach-omap2/board-omap3beagle.c| 24 +--- arch/arm/mach-omap2/board-omap3touchbook.c | 25 +--- arch/arm/mach-omap2/board-overo.c | 24 +--- arch/arm/mach-omap2/gpmc-nand.c| 39 ++ arch/arm/mach-omap2/gpmc.c |9 - arch/arm/plat-omap/include/plat/gpmc.h |7 +- arch/arm/plat-omap/include/plat/nand.h |6 +- drivers/mtd/nand/omap2.c | 242 +--- 10 files changed, 93 insertions(+), 328 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 v3 1/3] omap3 gpmc: functionality enhancement
few functions added in gpmc module and to be used by other drivers like NAND.
E.g.: - ioctl function
- ecc functions
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 246 +++-
arch/arm/plat-omap/include/plat/gpmc.h | 35 -
drivers/mtd/nand/omap2.c |4 +-
3 files changed, 274 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..7e6d821
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -46,8 +46,9 @@
#define GPMC_ECC_CONFIG0x1f4
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
+#define GPMC_ECC1_RESULT0x200
-#define GPMC_CS0 0x60
+#define GPMC_CS0_BASE 0x60
#define GPMC_CS_SIZE 0x30
#define GPMC_MEM_START 0x
@@ -92,7 +93,9 @@ struct omap3_gpmc_regs {
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
-static unsignedgpmc_cs_map;
+static unsignedint gpmc_cs_map;/* flag for cs which are
initialized */
+static int gpmc_pref_used = -EINVAL; /* cs using prefetch engine */
+static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
static void __iomem *gpmc_base;
@@ -108,11 +111,27 @@ static u32 gpmc_read_reg(int idx)
return __raw_readl(gpmc_base + idx);
}
+static void gpmc_cs_write_byte(int cs, int idx, u8 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ __raw_writeb(val, reg_addr);
+}
+
+static u8 gpmc_cs_read_byte(int cs, int idx)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ return __raw_readb(reg_addr);
+}
+
void gpmc_cs_write_reg(int cs, int idx, u32 val)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
@@ -120,7 +139,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
@@ -419,8 +438,100 @@ void gpmc_cs_free(int cs)
EXPORT_SYMBOL(gpmc_cs_free);
/**
+ * gpmc_hwcontrol - hardware specific access (read/ write) control
+ * @cs: chip select number
+ * @cmd: command type
+ * @write: 1 for write; 0 for read
+ * @wval: value to write
+ * @rval: read pointer
+ */
+int gpmc_hwcontrol(int cs, int cmd, int write, int wval, int *rval)
+{
+ u32 regval = 0;
+
+ if (!write !rval)
+ return -EINVAL;
+
+ switch (cmd) {
+ case GPMC_STATUS_BUFFER:
+ regval = gpmc_read_reg(GPMC_STATUS);
+ /* 1 : buffer is available to write */
+ *rval = regval GPMC_STATUS_BUFF_EMPTY;
+ break;
+
+ case GPMC_GET_SET_IRQ_STATUS:
+ if (write)
+ gpmc_write_reg(GPMC_IRQSTATUS, wval);
+ else
+ *rval = gpmc_read_reg(GPMC_IRQSTATUS);
+ break;
+
+ case GPMC_PREFETCH_FIFO_CNT:
+ regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ *rval = GPMC_PREFETCH_STATUS_FIFO_CNT(regval);
+ break;
+
+ case GPMC_PREFETCH_COUNT:
+ regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ *rval = GPMC_PREFETCH_STATUS_COUNT(regval);
+ break;
+
+ case GPMC_CONFIG_WP:
+ regval = gpmc_read_reg(GPMC_CONFIG);
+ if (wval)
+ regval = ~GPMC_CONFIG_WRITEPROTECT; /* WP is ON */
+ else
+ regval |= GPMC_CONFIG_WRITEPROTECT; /* WP is OFF */
+ gpmc_write_reg(GPMC_CONFIG, regval);
+ break;
+
+ case GPMC_CONFIG_RDY_BSY:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_CONFIG_DEV_SIZE:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= GPMC_CONFIG1_DEVICESIZE(wval);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_CONFIG_DEV_TYPE:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= GPMC_CONFIG1_DEVICETYPE(wval);
+ if (wval == GPMC_DEVICETYPE_NOR)
+ regval |= GPMC_CONFIG1_MUXADDDATA;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_NAND_COMMAND:
+
[PATCH v3 3/3] omap3 nand: fix issue in board file to detect nand
Board file modified for not to provide gpmc phys_base address to nand driver.
The gpmc_nand_init funciton is now used to detect the nand and required to
adopt _prob function as in nand/omap2.c
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 20 +---
arch/arm/mach-omap2/board-devkit8000.c | 25 +
arch/arm/mach-omap2/board-omap3beagle.c| 24 +---
arch/arm/mach-omap2/board-omap3touchbook.c | 25 +
arch/arm/mach-omap2/board-overo.c | 24 +---
5 files changed, 5 insertions(+), 113 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index f4e8063..8a41268
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -61,8 +61,6 @@
#define SB_T35_SMSC911X_GPIO 65
#define NAND_BLOCK_SIZESZ_128K
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS0_BASE_ADDR (OMAP34XX_GPMC_VIRT + GPMC_CS0_BASE)
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include linux/smsc911x.h
@@ -223,28 +221,12 @@ static struct omap_nand_platform_data cm_t35_nand_data = {
.nr_parts = ARRAY_SIZE(cm_t35_nand_partitions),
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
.cs = 0,
- .gpmc_cs_baseaddr = (void __iomem *)GPMC_CS0_BASE_ADDR,
- .gpmc_baseaddr = (void __iomem *)OMAP34XX_GPMC_VIRT,
};
-static struct resource cm_t35_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device cm_t35_nand_device = {
- .name = omap2-nand,
- .id = -1,
- .num_resources = 1,
- .resource = cm_t35_nand_resource,
- .dev= {
- .platform_data = cm_t35_nand_data,
- },
-};
-
static void __init cm_t35_init_nand(void)
{
- if (platform_device_register(cm_t35_nand_device) 0)
+ if (gpmc_nand_init(cm_t35_nand_data) 0)
pr_err(CM-T35: Unable to register NAND device\n);
}
#else
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 6d910df..b172414
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -58,9 +58,6 @@
#include mux.h
#include hsmmc.h
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
#define OMAP_DM9000_GPIO_IRQ 25
@@ -104,20 +101,6 @@ static struct omap_nand_platform_data devkit8000_nand_data
= {
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
};
-static struct resource devkit8000_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device devkit8000_nand_device = {
- .name = omap2-nand,
- .id = -1,
- .dev= {
- .platform_data = devkit8000_nand_data,
- },
- .num_resources = 1,
- .resource = devkit8000_nand_resource,
-};
-
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -581,8 +564,6 @@ static void __init devkit8000_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
- u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
-
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -604,13 +585,9 @@ static void __init devkit8000_flash_init(void)
if (nandcs GPMC_CS_NUM) {
devkit8000_nand_data.cs = nandcs;
- devkit8000_nand_data.gpmc_cs_baseaddr = (void *)
- (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
- devkit8000_nand_data.gpmc_baseaddr = (void *)
- (gpmc_base_add);
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
- if (platform_device_register(devkit8000_nand_device) 0)
+ if (gpmc_nand_init(devkit8000_nand_data) 0)
printk(KERN_ERR Unable to register NAND device\n);
}
}
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5df89f6..9ec3ef8 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -47,9 +47,6 @@
#include mux.h
#include hsmmc.h
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
static struct mtd_partition omap3beagle_nand_partitions[] = {
@@ -92,20 +89,6 @@ static struct omap_nand_platform_data omap3beagle_nand_data
= {
.dev_ready = NULL,
};
-static struct resource omap3beagle_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device
[PATCH v3 2/3] omap3 nand: cleanup virtual address usages
This patch removes direct reference of gpmc address from generic nand platform
code.
Nand platform code now uses wrapper functions which are implemented in gpmc
module.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c| 39 ++
arch/arm/mach-omap2/gpmc.c |9 --
arch/arm/plat-omap/include/plat/gpmc.h |7 +-
arch/arm/plat-omap/include/plat/nand.h |6 +-
drivers/mtd/nand/omap2.c | 242 ++--
5 files changed, 88 insertions(+), 215 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..80f5d94
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -19,8 +19,6 @@
#include plat/board.h
#include plat/gpmc.h
-#define WR_RD_PIN_MONITORING 0x0060
-
static struct omap_nand_platform_data *gpmc_nand_data;
static struct resource gpmc_nand_resource = {
@@ -71,10 +69,10 @@ static int omap2_nand_gpmc_retime(void)
t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
/* Configure GPMC */
- gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
- GPMC_CONFIG1_DEVICETYPE_NAND);
-
+ gpmc_hwcontrol(gpmc_nand_data-cs,
+ GPMC_CONFIG_DEV_SIZE, 1, gpmc_nand_data-devsize, NULL);
+ gpmc_hwcontrol(gpmc_nand_data-cs,
+ GPMC_CONFIG_DEV_TYPE, 1, GPMC_DEVICETYPE_NAND, NULL);
err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
if (err)
return err;
@@ -82,27 +80,13 @@ static int omap2_nand_gpmc_retime(void)
return 0;
}
-static int gpmc_nand_setup(void)
-{
- struct device *dev = gpmc_nand_device.dev;
-
- /* Set timings in GPMC */
- if (omap2_nand_gpmc_retime() 0) {
- dev_err(dev, Unable to set gpmc timings\n);
- return -EINVAL;
- }
-
- return 0;
-}
-
int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
{
- unsigned int val;
int err = 0;
struct device *dev = gpmc_nand_device.dev;
gpmc_nand_data = _nand_data;
- gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_data-nand_setup = omap2_nand_gpmc_retime;
gpmc_nand_device.dev.platform_data = gpmc_nand_data;
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
@@ -112,19 +96,17 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
- err = gpmc_nand_setup();
+/* Set timings in GPMC */
+ err = omap2_nand_gpmc_retime();
if (err 0) {
- dev_err(dev, NAND platform setup failed: %d\n, err);
+ dev_err(dev, Unable to set gpmc timings: %d\n, err);
return err;
}
/* Enable RD PIN Monitoring Reg */
if (gpmc_nand_data-dev_ready) {
- val = gpmc_cs_read_reg(gpmc_nand_data-cs,
-GPMC_CS_CONFIG1);
- val |= WR_RD_PIN_MONITORING;
- gpmc_cs_write_reg(gpmc_nand_data-cs,
- GPMC_CS_CONFIG1, val);
+ gpmc_hwcontrol(gpmc_nand_data-cs,
+ GPMC_CONFIG_RDY_BSY, 1, 1, NULL);
}
err = platform_device_register(gpmc_nand_device);
@@ -140,3 +122,4 @@ out_free_cs:
return err;
}
+
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f414aeb..cbe0efb
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -589,15 +589,6 @@ int gpmc_prefetch_reset(int cs)
}
EXPORT_SYMBOL(gpmc_prefetch_reset);
-/**
- * gpmc_prefetch_status - reads prefetch status of engine
- */
-int gpmc_prefetch_status(void)
-{
- return gpmc_read_reg(GPMC_PREFETCH_STATUS);
-}
-EXPORT_SYMBOL(gpmc_prefetch_status);
-
static void __init gpmc_mem_init(void)
{
int cs;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 67a3442..2386ff6
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -25,9 +25,6 @@
#define GPMC_CS_NAND_ADDRESS 0x20
#define GPMC_CS_NAND_DATA 0x24
-#define GPMC_CONFIG0x50
-#define GPMC_STATUS0x54
-
/* Control Commands */
#define GPMC_CONFIG_WP 0x0001
#define GPMC_CONFIG_RDY_BSY0x0002
@@ -63,7 +60,6 @@
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
-#define GPMC_CONFIG1_DEVICETYPE_NANDGPMC_CONFIG1_DEVICETYPE(2)
#define GPMC_CONFIG1_MUXADDDATA (1 9)
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 4)
#define GPMC_CONFIG1_FCLK_DIV(val) (val 3)
@@ -77,7 +73,7
Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
On Tue, May 18, 2010 at 2:14 PM, Ohad Ben-Cohen o...@wizery.com wrote: Unfortunately I don't have a setup right now to test this, but the code seems to be ok for our needs, don't you think ? But yeah, actually that fits our needs; calling the dma_map only, while still wrong, will give us the same behavior we have right now (v2.6.33). Great, so are you ok with this patchset proposal ? I thought you were going to add separate ioctls, one for dma_map, and another for dma_unmap that receive direction as an argument. Then, map the current PROC_FLUSH/INVALIDATE to those without changing their semantics, but marking them as deprecated. I'll just add support for the VM_IO path you mentioned. Cool. I actually tried your patches to render to the framebuffer, and everything seemed to work fine. I didn't check for error codes or anything, so I'm not sure what's going on. -- Felipe Contreras -- 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 0/6] DSPBRIDGE: fix mem+cache API issues
On Tue, May 18, 2010 at 2:43 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, May 18, 2010 at 2:14 PM, Ohad Ben-Cohen o...@wizery.com wrote: Unfortunately I don't have a setup right now to test this, but the code seems to be ok for our needs, don't you think ? But yeah, actually that fits our needs; calling the dma_map only, while still wrong, will give us the same behavior we have right now (v2.6.33). Great, so are you ok with this patchset proposal ? I thought you were going to add separate ioctls, one for dma_map, and another for dma_unmap that receive direction as an argument. Then, map the current PROC_FLUSH/INVALIDATE to those without changing their semantics, but marking them as deprecated. Yes, I am (this and a few other small stuff we mentioned in the threads) - I was just asking generally about the move to dma_(un)map_* API. Anyway, I'll prepare a v2 and resubmit. I'll just add support for the VM_IO path you mentioned. Cool. I actually tried your patches to render to the framebuffer, and everything seemed to work fine. I didn't check for error codes or anything, so I'm not sure what's going on. How is the framebuffer mmap'ed ? Can you please tell me more about this scenario ? (applications + drivers involved). How do I test this scenario ? using the tools you sent me ? Do I have to have a beagle board or will ZOOM do ? Thanks, Ohad. -- Felipe Contreras -- 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 00/17] omap: mailbox: reorganize init
On Tue, May 18, 2010 at 11:46 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Felipe Contreras felipe.contre...@gmail.com Subject: [PATCH v2 00/17] omap: mailbox: reorganize init Date: Fri, 14 May 2010 17:01:33 +0200 Hi, The main purpose of this patch series is to be able to compile mach platform data as built-in. Otherwise, client modules such as bridgedriver will load the platform code, but not the mach code when mailbox is built as a module. I think that this is the *udev* responsibility. The udev should take care of loading mailbox_mach.ko since the mailbox platform device was registered by devices.ko at bootup. devices.ko is built in earlier than dspbridge.ko, so the mailbox platform device is registered earlier than the dsp device, C6410. this registration ordering should take care of the dependency if the udevd works correctly. I'm not familiar with this kind of module loading, but certainly not all systems have udev. I realized the problem because I have a bare-bones system in my beagleboard where I had to manually load mailbox_mach. Unfortunately, there's no easy way to do that since plat and mach code are deepely interrelated. So the first patches try to separate the mailbox registering through a defined omap_mbox_platform_data. Also, it's worth noting that mailboxes are not a one-to-one mapping to resources; that is, some resources belong to multiple mboxes. So it's best to think of mailboxes as fake devices. That is why custom platform_data is required. Actually there were logical mailbox devices/instances implemented, but it was broken partially when dropping mailbox class support by accident(*1). This is the reason whey omap_mbox struct has unused dev pointer now. At that time, the sysfs interface was not necessary but the device creation itself should not have been removed. I'll get this code back again soon. The role of each modules were/should be: - devices.ko: a platform device, based on its resource. - mailbox_mach.ko: a platform driver to register multiple logical mboxes/devices. - mailbox.ko: a kind of framework which holds multiple logical mboxes/devices. The sysfs structure is like below: ~# tree -d -L 2 /sys/devices/platform/omap2-mailbox/ I don't see the point of having 'omap2' there, at best it should be 'omap-mailbox', or perhaps even just 'mailbox'. The platform device omap2-mailbox accomodatess logical mboxes. Wouldn't it be better the way my patches handle them? * devices.ko: doesn't care about mbox * mach_omap1/mailbox.ko: registers omap-mailbox platform device with a list of logical mboxes for OMAP1 * mach_omap2/mailbox.ko: registers omap-mailbox platform device with a list of logical mboxes for OMAP2 * plat-omap/mailbox.ko: creates platform driver based on logical list of mboxes from platform device and handles the list internally The end result would be the exactly same, except that there's no hard dependency between the mach, and plat code. Finally, a bunch of cleaning up is done in the very first patches, specially for OMAP1. Most of the cleanups are quite ok. Would it be possible to rebase them on the top of my coming patch to get back logical device entry? Where is that? Sorry for the late reply, it took some time to recall my bad memory... No worries. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap: rx51: Use REGULATOR_SUPPLY macro when initializing regulator consumers
Moi Jarkko,
On Tue, May 18, 2010 at 01:06:00PM +0200, Jarkko Nikula wrote:
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
I don't have any major objections on this one. I'd just add a patch description
though.
Other than that:
Acked-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 43 ++---
1 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 8179d55..ead7ee1 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -272,48 +272,27 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct regulator_consumer_supply rx51_vmmc1_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.0,
-};
+static struct regulator_consumer_supply rx51_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
-static struct regulator_consumer_supply rx51_vaux3_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vaux3_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
-static struct regulator_consumer_supply rx51_vsim_supply = {
- .supply = vmmc_aux,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vsim_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
- {
- .supply = AVDD,
- .dev_name = 2-0018,
- },
- {
- .supply = DRVDD,
- .dev_name = 2-0018,
- },
+ REGULATOR_SUPPLY(AVDD, 2-0018),
+ REGULATOR_SUPPLY(DRVDD, 2-0018),
/* Keep vmmc as last item. It is not iterated for newer boards */
- {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
- },
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
static struct regulator_consumer_supply rx51_vio_supplies[] = {
/* tlv320aic3x digital supplies */
- {
- .supply = IOVDD,
- .dev_name = 2-0018
- },
- {
- .supply = DVDD,
- .dev_name = 2-0018
- },
+ REGULATOR_SUPPLY(IOVDD, 2-0018),
+ REGULATOR_SUPPLY(DVDD, 2-0018),
};
static struct regulator_init_data rx51_vaux1 = {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/14] OMAP2: Devkit8000: change lcd panel to generic
Choose the generic panel to use with Devkit8000.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 887e1a1..e989136 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -175,7 +175,7 @@ static struct regulator_consumer_supply
devkit8000_vio_supplies[] = {
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
- .driver_name= innolux_at_panel,
+ .driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.platform_enable= devkit8000_panel_enable_lcd,
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] OMAP2: Devkit8000: Cleanup for supplies
Corrected the wrong supplies in devkit8000 code.
Add supply for ads7846 to support the new regulator framework for
touchscreen.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 6d910df..887e1a1 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -168,6 +168,10 @@ static struct regulator_consumer_supply
devkit8000_vsim_supply = {
.supply = vmmc_aux,
};
+/* ads7846 on SPI */
+static struct regulator_consumer_supply devkit8000_vio_supplies[] = {
+ REGULATOR_SUPPLY(vcc, spi2.0)
+};
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
@@ -282,7 +286,7 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
.setup = devkit8000_twl_gpio_setup,
};
-static struct regulator_consumer_supply devkit8000_vpll2_supplies[] = {
+static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
{
.supply = vdvi,
.dev= devkit8000_lcd_device.dev,
@@ -337,8 +341,8 @@ static struct regulator_init_data devkit8000_vdac = {
.consumer_supplies = devkit8000_vdda_dac_supply,
};
-/* VPLL2 for digital video outputs */
-static struct regulator_init_data devkit8000_vpll2 = {
+/* VPLL1 for digital video outputs */
+static struct regulator_init_data devkit8000_vpll1 = {
.constraints = {
.name = VDVI,
.min_uV = 180,
@@ -348,8 +352,23 @@ static struct regulator_init_data devkit8000_vpll2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = ARRAY_SIZE(devkit8000_vpll2_supplies),
- .consumer_supplies = devkit8000_vpll2_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(devkit8000_vpll1_supplies),
+ .consumer_supplies = devkit8000_vpll1_supplies,
+};
+
+/* VAUX4 for ads7846 and nubs */
+static struct regulator_init_data devkit8000_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(devkit8000_vio_supplies),
+ .consumer_supplies = devkit8000_vio_supplies,
};
static struct twl4030_usb_data devkit8000_usb_data = {
@@ -376,7 +395,8 @@ static struct twl4030_platform_data devkit8000_twldata = {
.vmmc1 = devkit8000_vmmc1,
.vsim = devkit8000_vsim,
.vdac = devkit8000_vdac,
- .vpll2 = devkit8000_vpll2,
+ .vpll1 = devkit8000_vpll1,
+ .vio= devkit8000_vio,
.keypad = devkit8000_kp_data,
};
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/14] OMAP2: Devkit8000: Fixing comment about pins used
Fix the comment about the pins support by the vmmc1 power source.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 4a633f8..d8c1d81 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -291,7 +291,7 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
static struct regulator_consumer_supply devkit8000_vpll1_supply =
REGULATOR_SUPPLY(vdds_dsi, omapdss);
-/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT7 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data devkit8000_vmmc1 = {
.constraints = {
.min_uV = 185,
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/14] OMAP2: Devkit8000: Correct regulator
Devkit8000 uses the TPS65930 and not the TWL4030.
The TPS65930 uses only a subset of the voltage
regulators of the TWL4030.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 81000e4..96836fe 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -377,7 +377,7 @@ static struct twl4030_platform_data devkit8000_twldata = {
static struct i2c_board_info __initdata devkit8000_i2c_boardinfo[] = {
{
- I2C_BOARD_INFO(twl4030, 0x48),
+ I2C_BOARD_INFO(tps65930, 0x48),
.flags = I2C_CLIENT_WAKE,
.irq = INT_34XX_SYS_NIRQ,
.platform_data = devkit8000_twldata,
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/14] OMAP2: Devkit8000: Remove en-/disable for tv panel
This patch removes devkit8000_panel_enable_tv and devkit8000_panel_disable_tv
because they are already done in DSS2 code.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 7d68016..543becc 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -158,16 +158,6 @@ static void devkit8000_panel_disable_dvi(struct
omap_dss_device *dssdev)
gpio_set_value(dssdev-reset_gpio, 0);
}
-static int devkit8000_panel_enable_tv(struct omap_dss_device *dssdev)
-{
-
- return 0;
-}
-
-static void devkit8000_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct regulator_consumer_supply devkit8000_vmmc1_supply = {
.supply = vmmc,
};
@@ -201,8 +191,6 @@ static struct omap_dss_device devkit8000_tv_device = {
.driver_name= venc,
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable= devkit8000_panel_enable_tv,
- .platform_disable = devkit8000_panel_disable_tv,
};
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/14] OMAP2: Devkit8000: Remove nonexisting vsim
The Devkit8000 uses the cost reduced variant tps65930 of the twl4030.
The TPS65930 only has vdd1, vdd2, vpll1, vio, vmmc1, vdac and vaux2.
vaux2 is not used.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 22 --
1 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 4611274..7d68016 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -168,15 +168,10 @@ static void devkit8000_panel_disable_tv(struct
omap_dss_device *dssdev)
{
}
-
static struct regulator_consumer_supply devkit8000_vmmc1_supply = {
.supply = vmmc,
};
-static struct regulator_consumer_supply devkit8000_vsim_supply = {
- .supply = vmmc_aux,
-};
-
/* ads7846 on SPI */
static struct regulator_consumer_supply devkit8000_vio_supplies[] = {
REGULATOR_SUPPLY(vcc, spi2.0)
@@ -281,7 +276,6 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* link regulators to MMC adapters */
devkit8000_vmmc1_supply.dev = mmc[0].dev;
- devkit8000_vsim_supply.dev = mmc[0].dev;
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
@@ -334,21 +328,6 @@ static struct regulator_init_data devkit8000_vmmc1 = {
.consumer_supplies = devkit8000_vmmc1_supply,
};
-/* VSIM for MMC1 pins DAT4..DAT7 (2 mA, plus card == max 50 mA) */
-static struct regulator_init_data devkit8000_vsim = {
- .constraints = {
- .min_uV = 180,
- .max_uV = 300,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = 1,
- .consumer_supplies = devkit8000_vsim_supply,
-};
-
/* VDAC for DSS driving S-Video (8 mA unloaded, max 65 mA) */
static struct regulator_init_data devkit8000_vdac = {
.constraints = {
@@ -414,7 +393,6 @@ static struct twl4030_platform_data devkit8000_twldata = {
.gpio = devkit8000_gpio_data,
.codec = devkit8000_codec_data,
.vmmc1 = devkit8000_vmmc1,
- .vsim = devkit8000_vsim,
.vdac = devkit8000_vdac,
.vpll1 = devkit8000_vpll1,
.vio= devkit8000_vio,
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/14] OMAP2: Devkit8000: Fix comment
The comment says VAUX4 which is not used for ads7846.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 637a2c3..bb3f3f5 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -334,7 +334,7 @@ static struct regulator_init_data devkit8000_vpll1 = {
.consumer_supplies = devkit8000_vpll1_supply,
};
-/* VAUX4 for ads7846 and nubs */
+/* VIO for ads7846 */
static struct regulator_init_data devkit8000_vio = {
.constraints = {
.min_uV = 180,
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/14] OMAP2: Devkit8000: Fix whitespace with tab
Signed-off-by: Thomas Weber we...@corscience.de --- arch/arm/mach-omap2/board-devkit8000.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index d8c1d81..637a2c3 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -262,7 +262,7 @@ static int devkit8000_twl_gpio_setup(struct device *dev, /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; -/* gpio + 1 is LCD_PWREN (out, active high) */ + /* gpio + 1 is LCD_PWREN (out, active high) */ devkit8000_lcd_device.reset_gpio = gpio + 1; gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN); /* Disable until needed */ -- 1.6.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/14] OMAP2: Devkit8000: Use the REGULATOR_SUPPLY macro
Replacing the supplies with the REGULATOR_SUPPLY macro.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 36 +++
1 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 543becc..4a633f8 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -158,14 +158,13 @@ static void devkit8000_panel_disable_dvi(struct
omap_dss_device *dssdev)
gpio_set_value(dssdev-reset_gpio, 0);
}
-static struct regulator_consumer_supply devkit8000_vmmc1_supply = {
- .supply = vmmc,
-};
+static struct regulator_consumer_supply devkit8000_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
+
/* ads7846 on SPI */
-static struct regulator_consumer_supply devkit8000_vio_supplies[] = {
- REGULATOR_SUPPLY(vcc, spi2.0)
-};
+static struct regulator_consumer_supply devkit8000_vio_supply =
+ REGULATOR_SUPPLY(vcc, spi2.0);
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
@@ -214,10 +213,8 @@ static struct platform_device devkit8000_dss_device = {
},
};
-static struct regulator_consumer_supply devkit8000_vdda_dac_supply = {
- .supply = vdda_dac,
- .dev= devkit8000_dss_device.dev,
-};
+static struct regulator_consumer_supply devkit8000_vdda_dac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omapdss);
static int board_keymap[] = {
KEY(0, 0, KEY_1),
@@ -262,9 +259,6 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
mmc[0].gpio_cd = gpio + 0;
omap2_hsmmc_init(mmc);
- /* link regulators to MMC adapters */
- devkit8000_vmmc1_supply.dev = mmc[0].dev;
-
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
@@ -294,12 +288,8 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
.setup = devkit8000_twl_gpio_setup,
};
-static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
- {
- .supply = vdds_dsi,
- .dev= devkit8000_dss_device.dev,
- }
-};
+static struct regulator_consumer_supply devkit8000_vpll1_supply =
+ REGULATOR_SUPPLY(vdds_dsi, omapdss);
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data devkit8000_vmmc1 = {
@@ -340,8 +330,8 @@ static struct regulator_init_data devkit8000_vpll1 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = ARRAY_SIZE(devkit8000_vpll1_supplies),
- .consumer_supplies = devkit8000_vpll1_supplies,
+ .num_consumer_supplies = 1,
+ .consumer_supplies = devkit8000_vpll1_supply,
};
/* VAUX4 for ads7846 and nubs */
@@ -355,8 +345,8 @@ static struct regulator_init_data devkit8000_vio = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = ARRAY_SIZE(devkit8000_vio_supplies),
- .consumer_supplies = devkit8000_vio_supplies,
+ .num_consumer_supplies = 1,
+ .consumer_supplies = devkit8000_vio_supply,
};
static struct twl4030_usb_data devkit8000_usb_data = {
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/14] OMAP2: Devkit8000: Remove unneeded VDVI
The VDVI is no longer needed with the new DSS2 interface. This
patch removes the supply from board code.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 37b047e..4611274 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -314,10 +314,6 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
{
- .supply = vdvi,
- .dev= devkit8000_lcd_device.dev,
- },
- {
.supply = vdds_dsi,
.dev= devkit8000_dss_device.dev,
}
@@ -370,7 +366,6 @@ static struct regulator_init_data devkit8000_vdac = {
/* VPLL1 for digital video outputs */
static struct regulator_init_data devkit8000_vpll1 = {
.constraints = {
- .name = VDVI,
.min_uV = 180,
.max_uV = 180,
.valid_modes_mask = REGULATOR_MODE_NORMAL
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/14] Multiple fixes for Devkit8000
Some of these patches were submitted earlier but got no comments so I am sending them one more time. These patches correct errors that were done while using the board code from beagle board for Devkit8000. The Devkit8000 uses the TPS65930, an reduced version of the TWL4030. So not all power supplies from the TWL4030 are available. There were also a wrong comment about the pins supported by the vmmc1. The DSS2 do not need a VDVI any longer so it is removed. The definition of the supplies are changed to use the new REGULATOR_SUPPLY macro. The pins for lcd and dvi powerdown are corrected. Kan-Ru Chen (1): OMAP2: Devkit8000: Setup LCD reset Thomas Weber (13): OMAP2: Devkit8000: Cleanup for supplies OMAP2: Devkit8000: change lcd panel to generic OMAP2: Devkit8000: Enable DVI-D output OMAP2: Devkit8000: Remove unneeded VDVI OMAP2: Devkit8000: Remove nonexisting vsim OMAP2: Devkit8000: Remove en-/disable for tv panel OMAP2: Devkit8000: Use the REGULATOR_SUPPLY macro OMAP2: Devkit8000: Fixing comment about pins used OMAP2: Devkit8000: Fix whitespace with tab OMAP2: Devkit8000: Fix comment OMAP2: Devkit8000: Using gpio_is_valid OMAP2: Devkit8000: Remove unused omap_board_config OMAP2: Devkit8000: Correct regulator arch/arm/mach-omap2/board-devkit8000.c | 125 +++- 1 files changed, 58 insertions(+), 67 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 13/14] OMAP2: Devkit8000: Remove unused omap_board_config
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index de7c28a..81000e4 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -126,8 +126,6 @@ static struct omap2_hsmmc_info mmc[] = {
},
{} /* Terminator */
};
-static struct omap_board_config_kernel devkit8000_config[] __initdata = {
-};
static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
{
@@ -461,8 +459,6 @@ static struct platform_device keys_gpio = {
static void __init devkit8000_init_irq(void)
{
- omap_board_config = devkit8000_config;
- omap_board_config_size = ARRAY_SIZE(devkit8000_config);
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
omap_init_irq();
@@ -794,8 +790,6 @@ static void __init devkit8000_init(void)
devkit8000_i2c_init();
platform_add_devices(devkit8000_devices,
ARRAY_SIZE(devkit8000_devices));
- omap_board_config = devkit8000_config;
- omap_board_config_size = ARRAY_SIZE(devkit8000_config);
spi_register_board_info(devkit8000_spi_board_info,
ARRAY_SIZE(devkit8000_spi_board_info));
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/14] OMAP2: Devkit8000: Using gpio_is_valid
Using the macro gpio_is_valid for check of valid gpio pins.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index bb3f3f5..de7c28a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -134,27 +134,27 @@ static int devkit8000_panel_enable_lcd(struct
omap_dss_device *dssdev)
twl_i2c_write_u8(TWL4030_MODULE_GPIO, 0x80, REG_GPIODATADIR1);
twl_i2c_write_u8(TWL4030_MODULE_LED, 0x0, 0x0);
- if (dssdev-reset_gpio != -EINVAL)
+ if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
- if (dssdev-reset_gpio != -EINVAL)
+ if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value(dssdev-reset_gpio, 0);
}
static int devkit8000_panel_enable_dvi(struct omap_dss_device *dssdev)
{
- if (dssdev-reset_gpio != -EINVAL)
+ if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_dvi(struct omap_dss_device *dssdev)
{
- if (dssdev-reset_gpio != -EINVAL)
+ if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value(dssdev-reset_gpio, 0);
}
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/14] OMAP2: Devkit8000: Enable DVI-D output
This patch corrects the DVI-D output setup of Devkit8000.
Devkit8000 has different DVI reset pin with the BeagleBoard. On
Devkit8000 the TWL4030 GPIO_7 is assigned to do the job.
Signed-off-by: Kan-Ru Chen ka...@0xlab.org
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index e989136..c6b9ed4 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -140,13 +140,18 @@ static int devkit8000_panel_enable_lcd(struct
omap_dss_device *dssdev)
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
}
+
static int devkit8000_panel_enable_dvi(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_dvi(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 0);
}
static int devkit8000_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -186,6 +191,7 @@ static struct omap_dss_device devkit8000_dvi_device = {
.driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
+ .reset_gpio = -EINVAL, /* will be replaced */
.platform_enable= devkit8000_panel_enable_dvi,
.platform_disable = devkit8000_panel_disable_dvi,
};
@@ -272,6 +278,15 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
devkit8000_vmmc1_supply.dev = mmc[0].dev;
devkit8000_vsim_supply.dev = mmc[0].dev;
+ /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
+ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+
+ /* gpio + 7 is DVI_PD (out, active low) */
+ devkit8000_dvi_device.reset_gpio = gpio + 7;
+ gpio_request(devkit8000_dvi_device.reset_gpio, DVI PowerDown);
+ /* Disable until needed */
+ gpio_direction_output(devkit8000_dvi_device.reset_gpio, 0);
+
return 0;
}
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/14] OMAP2: Devkit8000: Setup LCD reset
From: Kan-Ru Chen ka...@0xlab.org
This patch corrects the LCD reset pin config.
Original code from early devkit8000 patch sets the TWL4030 GPIO_1
to EHCI_nOC and TWL4030_GPIO_MAX+1 to ledA. Indeed these two pins
are both LCD_PWREN. Setup the lcd reset_gpio properly so it can be
disabled when other display is turned on.
Signed-off-by: Kan-Ru Chen ka...@0xlab.org
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index c6b9ed4..37b047e 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -134,11 +134,15 @@ static int devkit8000_panel_enable_lcd(struct
omap_dss_device *dssdev)
twl_i2c_write_u8(TWL4030_MODULE_GPIO, 0x80, REG_GPIODATADIR1);
twl_i2c_write_u8(TWL4030_MODULE_LED, 0x0, 0x0);
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 0);
}
static int devkit8000_panel_enable_dvi(struct omap_dss_device *dssdev)
@@ -183,6 +187,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
.driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
+ .reset_gpio = -EINVAL, /* will be replaced */
.platform_enable= devkit8000_panel_enable_lcd,
.platform_disable = devkit8000_panel_disable_lcd,
};
@@ -281,6 +286,12 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+/* gpio + 1 is LCD_PWREN (out, active high) */
+ devkit8000_lcd_device.reset_gpio = gpio + 1;
+ gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN);
+ /* Disable until needed */
+ gpio_direction_output(devkit8000_lcd_device.reset_gpio, 0);
+
/* gpio + 7 is DVI_PD (out, active low) */
devkit8000_dvi_device.reset_gpio = gpio + 7;
gpio_request(devkit8000_dvi_device.reset_gpio, DVI PowerDown);
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6 v2] musb: dma: use optimal transfer element for sdma
Use optimal values of transfer element based on buffer address in system
DMA programming. This would improve the performance.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v1:
- fixed extra identation in switch statement.
drivers/usb/musb/musbhsdma.c | 29 ++---
1 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index d29e487..22a2978 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -52,11 +52,34 @@ static void musb_sdma_channel_program(struct musb *musb,
struct musb_dma_channel *musb_channel,
dma_addr_t dma_addr, u32 len)
{
+ u16 frame = len;
+ int data_type = OMAP_DMA_DATA_TYPE_S8;
+
+ switch (dma_addr 0x3) {
+ case 0:
+ if ((len % 4) == 0) {
+ data_type = OMAP_DMA_DATA_TYPE_S32;
+ frame = len / 4;
+ break;
+ }
+ case 2:
+ if ((len % 2) == 0) {
+ data_type = OMAP_DMA_DATA_TYPE_S16;
+ frame = len / 2;
+ break;
+ }
+ case 1:
+ case 3:
+ default:
+ data_type = OMAP_DMA_DATA_TYPE_S8;
+ frame = len;
+ break;
+ }
/* set transfer parameters */
omap_set_dma_transfer_params(musb_channel-sysdma_channel,
- OMAP_DMA_DATA_TYPE_S8,
- len ? len : 1, 1, /* One frame */
- OMAP_DMA_SYNC_ELEMENT,
+ data_type,
+ len ? frame : 1, 1, /* One frame */
+ OMAP_DMA_SYNC_FRAME,
OMAP24XX_DMA_NO_DEVICE,
0); /* Src Sync */
--
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
[PATCH 3/3 v2] musb: AM35x: Workaround for fifo read issue
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v1:
- removed unnecessary parens.
- Removed 'memcpy' for 32 bit read loops.
drivers/usb/musb/am3517.c| 30 ++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c
index b74e664..3299c66 100644
--- a/drivers/usb/musb/am3517.c
+++ b/drivers/usb/musb/am3517.c
@@ -515,3 +515,33 @@ void musb_platform_restore_context(struct
musb_context_registers
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 (unsigned long) dst) == 0) len = 4) {
+ readsl(fifo, dst, len 2);
+ dst += len ~0x03;
+ len = 0x03;
+ }
+ /*
+* Now read the rest 1 to 3 bytes or complete length if
+* unaligned address.
+*/
+ if (len 4) {
+ for (i = 0; i (len 2); i++) {
+ *(u32 *) dst = musb_readl(fifo, 0);
+ dst += 4;
+ }
+ len %= 4;
+ }
+ if (len 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, len);
+ }
+}
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 4093f6d..9c59a8e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -262,6 +262,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
const u8 *src)
}
}
+#if !defined(CONFIG_MACH_OMAP3517EVM)
/*
* Unload an endpoint's FIFO
*/
@@ -299,6 +300,7 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8
*dst)
readsb(fifo, dst, len);
}
}
+#endif
#endif /* normal PIO */
--
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/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
On Tue, May 18, 2010 at 2:57 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Tue, May 18, 2010 at 2:43 PM, Felipe Contreras felipe.contre...@gmail.com wrote: I'll just add support for the VM_IO path you mentioned. Cool. I actually tried your patches to render to the framebuffer, and everything seemed to work fine. I didn't check for error codes or anything, so I'm not sure what's going on. How is the framebuffer mmap'ed ? mmap(NULL, self-mem_info.size, PROT_WRITE, MAP_SHARED, self-overlay_fd, 0); Can you please tell me more about this scenario ? (applications + drivers involved). I use gst-omapfb[1], and then it's very easy with a gst-launch command (part of GStreamer): gst-launch filesrc location=video.avi ! avidemux ! dspvdec ! omapfbsink How do I test this scenario ? using the tools you sent me ? Do I have to have a beagle board or will ZOOM do ? I guess you would need to modify dsp-tools to use framebuffer memory. Or you can do what I do and use gst-dsp + gst-omapfb. I don't have a zoom, so I haven't tried, but gst-dsp should work on any platform, and I have tried to make gst-omapfb the same, although YMMV. You could also try these binaries: http://people.freedesktop.org/~felipec/dsp/gst-omap-test.tar.bz Put on any system, on /opt/gst, and then PATH=/opt/gst/bin. Cheers. [1] http://github.com/felipec/gst-omapfb [2] http://people.freedesktop.org/~felipec/beagle-2.6.32-rc3/ -- Felipe Contreras -- 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 v6 0/7] omap3: pm: Update TRITON power scripts and making it generic
T2 script changes rebased on top of Thara's SmartReflex patches. This series of patch implements a updated TRITON power scripts. Also moving the sleep, wakeup warm_reset sequence to a generic script file, which can be used by different OMAP3 board with the power companion chip TWL4030. This patch series is based off Kevin's tree remotes/origin/pm-wip-sr branch, which have the SmartReflex changes done by Thara Gopinath. Changes to fix Kevin's Peter's comments. This changes are tested on OMAP3430 SDP board with: enable_off_mode voltage_off_while_idle sleep_while_idle (VDD1/VDD2 voltage scaling to 0v) enabled in cpuidle and suspned path. Lesly A M (7): omap3: pm: fix for twl4030 script load omap3: pm: Using separate clk/volt setup_time for RET and OFF states omap3: pm: re-programing the setup time based on CORE_DOMAIN target state. omap3: pm: changing vdd0_/vdd1_ to vdd1_/vdd2_ in VC param structure. omap3: pm: Generic TRITON power scripts for OMAP3 based boards omap3: pm: Use generic TRITON power scripts for 3430SDP board omap3: pm: Use generic TRITON power scripts for ZOOM[2,3], 3630SDP board arch/arm/mach-omap2/Makefile | 12 +- arch/arm/mach-omap2/board-3430sdp.c | 111 +--- arch/arm/mach-omap2/board-zoom-peripherals.c |6 + arch/arm/mach-omap2/pm.h | 18 --- arch/arm/mach-omap2/pm34xx.c | 26 +--- arch/arm/mach-omap2/twl4030.c| 185 ++ arch/arm/mach-omap2/twl4030.h| 15 ++ arch/arm/mach-omap2/voltage.c| 157 +- arch/arm/mach-omap2/voltage.h| 26 drivers/mfd/twl4030-power.c |5 +- include/linux/i2c/twl.h |4 + 11 files changed, 373 insertions(+), 192 deletions(-) create mode 100644 arch/arm/mach-omap2/twl4030.c create mode 100644 arch/arm/mach-omap2/twl4030.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/7] omap3: pm: fix for twl4030 script load
This patch will fix the TRITON sleep/wakeup sequence.
Since the function to populate the sleep script is getting called always
irrespective of the flag TWL4030_SLEEP_SCRIPT, other scripts data
is getting over written by the sleep script.
Print warning if the sleep script is loaded before wakeup script.
Because there is a chance that the Power chip may go to sleep before
the wakeup script is completely loaded, which can cause a system hang.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/twl4030-power.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..b4fc190 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -451,12 +451,13 @@ static int __init load_twl4030_script(struct
twl4030_script *tscript,
if (err)
goto out;
}
- if (tscript-flags TWL4030_SLEEP_SCRIPT)
- if (order)
+ if (tscript-flags TWL4030_SLEEP_SCRIPT) {
+ if (!order)
pr_warning(TWL4030: Bad order of scripts (sleep \
script before wakeup) Leads to boot\
failure on some boards\n);
err = twl4030_config_sleep_sequence(address);
+ }
out:
return err;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dss2 for-next BUG at drivers/video/omap2/dss/core.c:323!
On Tue, May 18, 2010 at 2:55 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: On Mon, 2010-05-17 at 16:30 +0200, ext Robert Nelson wrote: Hi Tomi, I've been using your dss2 branch with much success. http://gitorious.org/linux-omap-dss2/linux/commits/for-next I've just ran into a weird BUG that occurs on reboot on my headless beagles and wondering if you've ran into it too... The kernel I'm currently testing is 2.6.34-rc7 plus the 2.6.35 dss2 for-next commits.. I was assuming http://gitorious.org/linux-omap-dss2/linux/commit/89627989c6b4408c4578a41bcd5f9d04545797ad would fix it, but it hasn't fixed the Opps'ing... log on attempt to reboot: http://pastebin.com/iqAHMVD4 It looks like there's a mismatch with clock enables and disables somewhere... I haven't seen that. Can you tell me more details of your beagle? Does headless mean that it's standard beagle board, but no display is connected to it? Correct, just a beagle with no display connected.. I upgraded to 2.6.34 final plus dss2 for-next and enabled omapfb.debug and a generic modesetting to see if would make any difference in the bootargs. Same result.. http://www.pastie.org/965380 I should also mention, this only occurs after a small length of time (about 10 minutes).. I can't seem to trigger it after a frresh reboot (1-2 minutes).. config for reference: http://bazaar.launchpad.net/~beagleboard-kernel/+junk/2.6.34-devel/annotate/head:/patches/lucid-defconfig Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/7] omap3: pm: Using separate clk/volt setup_time for RET and OFF states
This patch will have the changes to use separate clk/volt setup_time
for RET and OFF state.
Create separate copies of VC parameters for each Si in voltage.c.
Updates the VC setuptime struct during init based on the OMAP Si.
Removes the VC setuptime struct from board files.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/board-3430sdp.c | 19 ---
arch/arm/mach-omap2/pm.h| 18 ---
arch/arm/mach-omap2/voltage.c | 93 +-
arch/arm/mach-omap2/voltage.h | 25 +
4 files changed, 93 insertions(+), 62 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 75c66dd..c7f0fa8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -47,7 +47,6 @@
#include sdram-qimonda-hyb18m512160af-6.h
#include hsmmc.h
#include pm.h
-#include voltage.h
#include omap3-opp.h
#include smartreflex-class3.h
@@ -77,23 +76,6 @@ static struct cpuidle_params omap3_cpuidle_params_table[] = {
{1, 1, 3, 30},
};
-/* FIXME: These are not the optimal setup values to be used on 3430sdp*/
-static struct prm_setup_vc omap3_setuptime_table = {
- .clksetup = 0xff,
- .voltsetup_time1 = 0xfff,
- .voltsetup_time2 = 0xfff,
- .voltoffset = 0xff,
- .voltsetup2 = 0xff,
- .vdd0_on = 0x30,
- .vdd0_onlp = 0x20,
- .vdd0_ret = 0x1e,
- .vdd0_off = 0x00,
- .vdd1_on = 0x2c,
- .vdd1_onlp = 0x20,
- .vdd1_ret = 0x1e,
- .vdd1_off = 0x00,
-};
-
static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -347,7 +329,6 @@ static void __init omap_3430sdp_init_irq(void)
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap3_pm_init_opp_table();
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
- omap_voltage_init_vc(omap3_setuptime_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
omap_gpio_init();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b608490..bad9058 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -40,24 +40,6 @@ inline void omap3_pm_init_cpuidle(struct cpuidle_params
*cpuidle_board_params)
}
#endif
-struct prm_setup_vc {
- u16 clksetup;
- u16 voltsetup_time1;
- u16 voltsetup_time2;
- u16 voltoffset;
- u16 voltsetup2;
-/* PRM_VC_CMD_VAL_0 specific bits */
- u16 vdd0_on;
- u16 vdd0_onlp;
- u16 vdd0_ret;
- u16 vdd0_off;
-/* PRM_VC_CMD_VAL_1 specific bits */
- u16 vdd1_on;
- u16 vdd1_onlp;
- u16 vdd1_ret;
- u16 vdd1_off;
-};
-
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index c5e9c42..efa16d4 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -127,14 +127,26 @@ struct vc_reg_info {
} vc_reg;
/*
- * Default voltage controller settings for OMAP3
+ * Default voltage controller settings for OMAP3430
*/
-static struct prm_setup_vc vc_config = {
- .clksetup = 0xff,
- .voltsetup_time1 = 0xfff,
- .voltsetup_time2 = 0xfff,
- .voltoffset = 0xff,
- .voltsetup2 = 0xff,
+struct __initdata prm_setup_vc omap3430_vc_config = {
+ /* CLK VOLT SETUPTIME for RET */
+ .ret = {
+ .clksetup = 0x1,
+ .voltsetup1_vdd1 = 0x005B,
+ .voltsetup1_vdd2 = 0x0055,
+ .voltsetup2 = 0x0,
+ .voltoffset = 0x0,
+ },
+ /* CLK VOLT SETUPTIME for OFF */
+ .off = {
+ .clksetup = 0x14A,
+ .voltsetup1_vdd1 = 0x00B3,
+ .voltsetup1_vdd2 = 0x00A0,
+ .voltsetup2 = 0x118,
+ .voltoffset = 0x32,
+ },
+ /* VC COMMAND VALUES for VDD1/VDD2 */
.vdd0_on = 0x30,/* 1.2v */
.vdd0_onlp = 0x20, /* 1.0v */
.vdd0_ret = 0x1e, /* 0.975v */
@@ -146,6 +158,39 @@ static struct prm_setup_vc vc_config = {
};
/*
+ * Default voltage controller settings for OMAP3630
+ */
+struct __initdata prm_setup_vc omap3630_vc_config = {
+ /* CLK VOLT SETUPTIME for RET */
+ .ret = {
+ .clksetup = 0x1,
+ .voltsetup1_vdd1 = 0x005B,
+ .voltsetup1_vdd2 = 0x0055,
+ .voltsetup2 = 0x0,
+ .voltoffset = 0x0,
+ },
+ /* CLK VOLT SETUPTIME for OFF */
+ .off = {
+ .clksetup = 0x14A,
+ .voltsetup1_vdd1 = 0x00B3,
+ .voltsetup1_vdd2 = 0x00A0,
+ .voltsetup2 = 0x118,
+ .voltoffset = 0x32,
+
[PATCH v6 3/7] omap3: pm: re-programing the setup time based on CORE_DOMAIN target state
This patch will add a new function omap_voltage_vc_update() to re-program
the VC parameters while entering low power mode, based on CORE_DOMAIN target
state.
The voltsetup2 is used only when the device exits sys_off mode
(with PRM_VOLTCTRL[3]SEL_OFF set to 1).
Also removed the clearing of PRM_VOLTCTRL register bits, because this will be
used only when it goes to low power mode next time.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/pm34xx.c | 26 +++---
arch/arm/mach-omap2/voltage.c | 41 +
arch/arm/mach-omap2/voltage.h |1 +
3 files changed, 45 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 5039b35..1ff6293 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -439,20 +439,12 @@ void omap_sram_idle(void)
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
- if (core_next_state == PWRDM_POWER_OFF) {
- u32 voltctrl = OMAP3430_AUTO_OFF;
+ /* Update the voltsetup time for RET/OFF */
+ omap_voltage_vc_update(core_next_state);
- if (voltage_off_while_idle)
- voltctrl |= OMAP3430_SEL_OFF;
- prm_set_mod_reg_bits(voltctrl,
-OMAP3430_GR_MOD,
-OMAP3_PRM_VOLTCTRL_OFFSET);
+ if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
- } else if (core_next_state == PWRDM_POWER_RET) {
- prm_set_mod_reg_bits(OMAP3430_AUTO_RET,
- OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTCTRL_OFFSET);
}
}
@@ -510,18 +502,6 @@ void omap_sram_idle(void)
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
- if (core_next_state == PWRDM_POWER_OFF) {
- u32 voltctrl = OMAP3430_AUTO_OFF;
-
- if (voltage_off_while_idle)
- voltctrl |= OMAP3430_SEL_OFF;
- prm_clear_mod_reg_bits(voltctrl,
- OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTCTRL_OFFSET);
- } else if (core_next_state == PWRDM_POWER_RET)
- prm_clear_mod_reg_bits(OMAP3430_AUTO_RET,
- OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTCTRL_OFFSET);
}
omap3_intc_resume_idle();
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index efa16d4..f4069db 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -943,6 +943,47 @@ void __init omap_voltage_init_vc(struct prm_setup_vc
*setup_vc)
vc_config.off.clksetup = setup_vc-off.clksetup;
}
+void omap_voltage_vc_update(int core_next_state)
+{
+ u32 voltctrl = 0;
+
+ /* update voltsetup time */
+ if (core_next_state == PWRDM_POWER_OFF) {
+ voltctrl = OMAP3430_AUTO_OFF;
+ prm_write_mod_reg(vc_config.off.clksetup, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ prm_write_mod_reg((vc_config.off.voltsetup1_vdd2
+ OMAP3430_SETUP_TIME2_SHIFT) |
+ (vc_config.off.voltsetup1_vdd1
+ OMAP3430_SETUP_TIME1_SHIFT),
+ OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
+
+ if (voltage_off_while_idle) {
+ voltctrl |= OMAP3430_SEL_OFF;
+ prm_write_mod_reg(vc_config.off.voltsetup2,
+ OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ }
+
+ } else if (core_next_state == PWRDM_POWER_RET) {
+ voltctrl = OMAP3430_AUTO_RET;
+ prm_write_mod_reg(vc_config.ret.clksetup, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ prm_write_mod_reg((vc_config.ret.voltsetup1_vdd2
+ OMAP3430_SETUP_TIME2_SHIFT) |
+ (vc_config.ret.voltsetup1_vdd1
+ OMAP3430_SETUP_TIME1_SHIFT),
+ OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
+
+ /* clear voltsetup2_reg if sys_off not enabled */
+
[PATCH 01/23] OMAP: Enable DSS2 in OMAP3EVM defconfig
From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com [tomi.valkei...@nokia.com: removed the board file changes] Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- arch/arm/configs/omap3_evm_defconfig | 51 +- 1 files changed, 50 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap3_evm_defconfig b/arch/arm/configs/omap3_evm_defconfig index a6dd6d1..b02e371 100644 --- a/arch/arm/configs/omap3_evm_defconfig +++ b/arch/arm/configs/omap3_evm_defconfig @@ -911,7 +911,56 @@ CONFIG_DAB=y # # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=m -# CONFIG_FB is not set +CONFIG_FB=y +# CONFIG_FIRMWARE_EDID is not set +# CONFIG_FB_DDC is not set +# CONFIG_FB_BOOT_VESA_SUPPORT is not set +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set +# CONFIG_FB_SYS_FILLRECT is not set +# CONFIG_FB_SYS_COPYAREA is not set +# CONFIG_FB_SYS_IMAGEBLIT is not set +# CONFIG_FB_FOREIGN_ENDIAN is not set +# CONFIG_FB_SYS_FOPS is not set +# CONFIG_FB_SVGALIB is not set +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +# CONFIG_FB_MODE_HELPERS is not set +# CONFIG_FB_TILEBLITTING is not set + +# +# Frame buffer hardware drivers +# +# CONFIG_FB_S1D13XXX is not set +# CONFIG_FB_VIRTUAL is not set +# CONFIG_FB_METRONOME is not set +# CONFIG_FB_MB862XX is not set +# CONFIG_FB_BROADSHEET is not set +# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set +CONFIG_OMAP2_VRAM=y +CONFIG_OMAP2_VRFB=y +CONFIG_OMAP2_DSS=y +CONFIG_OMAP2_VRAM_SIZE=4 +# CONFIG_OMAP2_DSS_DEBUG_SUPPORT is not set +# CONFIG_OMAP2_DSS_RFBI is not set +CONFIG_OMAP2_DSS_VENC=y +# CONFIG_OMAP2_DSS_SDI is not set +# CONFIG_OMAP2_DSS_DSI is not set +# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set +CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 +CONFIG_FB_OMAP2=y +# CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set +# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set +CONFIG_FB_OMAP2_NUM_FBS=3 + +# +# OMAP2/3 Display Device Drivers +# +CONFIG_PANEL_GENERIC=y +# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set +CONFIG_PANEL_SHARP_LS037V7DW01=y # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/23] OMAP DSS patches for 2.6.35 merge window
Here are OMAP DSS patches for 2.6.35 merge window. They have been previously reviewed on linux-omap and fbdev lists. Tomi Carlos Lopez (1): OMAP2: DSS: Add missing line for update bg color Grazvydas Ignotas (1): OMAP: DSS2: TPO-TD03MTEA1: fix Kconfig dependency Jani Nikula (6): OMAP: DSS2: fix lock_fb_info() and omapfb_lock() locking order OMAP: DSS2: check lock_fb_info() return value OMAP: DSS2: VENC: don't call platform_enable/disable() twice OMAP: DSS2: Fix device disable when driver is not loaded OMAP: DSS2: omap_dss_probe() conditional compilation cleanup OMAP: DSS2: Fix omap_dss_probe() error path Kishore Y (1): OMAP3630: DSS2: Updating MAX divider value Koen Kooi (1): board-omap3-beagle: add DSS2 support Roger Quadros (7): OMAP: DSS2: Add Kconfig option for DPI display type OMAP: DSS2: Remove redundant enable/disable calls from SDI OMAP: DSS2: Use vdds_sdi regulator supply in SDI OMAP: RX51: Add LCD Panel support OMAP: RX51: Add Touch Controller in SPI board info OMAP: DSS2: Add ACX565AKM Panel Driver OMAP: RX51: Update board defconfig Tomi Valkeinen (2): OMAP: DSS2: Make partial update width even OMAP: DSS2: Taal: add mutex to protect panel data Vaibhav Hiremath (3): OMAP: Enable DSS2 in OMAP3EVM defconfig OMAP: AM3517: Enable DSS2 in AM3517EVM defconfig OMAP: LCD LS037V7DW01: Add Backlight driver support Ville Syrjälä (1): OMAP: DSS2: Taal: Fix DSI bus locking problem arch/arm/configs/am3517_evm_defconfig | 52 ++- arch/arm/configs/omap3_evm_defconfig | 51 ++- arch/arm/configs/rx51_defconfig| 39 +- arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-omap3beagle.c| 101 ++- arch/arm/mach-omap2/board-rx51-peripherals.c | 28 + arch/arm/mach-omap2/board-rx51-video.c | 109 +++ arch/arm/mach-omap2/board-rx51.c |2 + drivers/video/omap2/displays/Kconfig |9 +- drivers/video/omap2/displays/Makefile |1 + drivers/video/omap2/displays/panel-acx565akm.c | 819 .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 78 ++ drivers/video/omap2/displays/panel-taal.c | 143 +++- drivers/video/omap2/dss/Kconfig|6 + drivers/video/omap2/dss/Makefile |3 +- drivers/video/omap2/dss/core.c | 85 ++- drivers/video/omap2/dss/display.c |9 +- drivers/video/omap2/dss/dss.c | 24 +- drivers/video/omap2/dss/dss.h | 50 ++ drivers/video/omap2/dss/manager.c | 21 + drivers/video/omap2/dss/sdi.c | 26 +- drivers/video/omap2/dss/venc.c | 15 +- drivers/video/omap2/omapfb/omapfb-ioctl.c |5 +- drivers/video/omap2/omapfb/omapfb-sysfs.c | 25 +- 24 files changed, 1573 insertions(+), 129 deletions(-) create mode 100644 arch/arm/mach-omap2/board-rx51-video.c create mode 100644 drivers/video/omap2/displays/panel-acx565akm.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/23] OMAP: DSS2: Add Kconfig option for DPI display type
From: Roger Quadros roger.quad...@nokia.com
This allows us to disable DPI on systems that do not have it
Signed-off-by: Roger Quadros roger.quad...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/Kconfig |6 ++
drivers/video/omap2/dss/Makefile |3 ++-
drivers/video/omap2/dss/core.c|4
drivers/video/omap2/dss/display.c |4
4 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 87afb81..43b6440 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -36,6 +36,12 @@ config OMAP2_DSS_COLLECT_IRQ_STATS
debugfs/omapdss/dispc_irq for DISPC interrupts, and
debugfs/omapdss/dsi_irq for DSI interrupts.
+config OMAP2_DSS_DPI
+ bool DPI support
+ default y
+ help
+ DPI Interface. This is the Parallel Display Interface.
+
config OMAP2_DSS_RFBI
bool RFBI support
default n
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index 980c72c..d71b5d9 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
-omapdss-y := core.o dss.o dispc.o dpi.o display.o manager.o overlay.o
+omapdss-y := core.o dss.o dispc.o display.o manager.o overlay.o
+omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 7ebe50b..6d54467 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -526,11 +526,13 @@ static int omap_dss_probe(struct platform_device *pdev)
}
#endif
+#ifdef CONFIG_OMAP2_DSS_DPI
r = dpi_init(pdev);
if (r) {
DSSERR(Failed to initialize dpi\n);
goto fail0;
}
+#endif
r = dispc_init();
if (r) {
@@ -601,7 +603,9 @@ static int omap_dss_remove(struct platform_device *pdev)
venc_exit();
#endif
dispc_exit();
+#ifdef CONFIG_OMAP2_DSS_DPI
dpi_exit();
+#endif
#ifdef CONFIG_OMAP2_DSS_RFBI
rfbi_exit();
#endif
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 6a74ea1..7138963 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -392,7 +392,9 @@ void dss_init_device(struct platform_device *pdev,
int r;
switch (dssdev-type) {
+#ifdef CONFIG_OMAP2_DSS_DPI
case OMAP_DISPLAY_TYPE_DPI:
+#endif
#ifdef CONFIG_OMAP2_DSS_RFBI
case OMAP_DISPLAY_TYPE_DBI:
#endif
@@ -413,9 +415,11 @@ void dss_init_device(struct platform_device *pdev,
}
switch (dssdev-type) {
+#ifdef CONFIG_OMAP2_DSS_DPI
case OMAP_DISPLAY_TYPE_DPI:
r = dpi_init_display(dssdev);
break;
+#endif
#ifdef CONFIG_OMAP2_DSS_RFBI
case OMAP_DISPLAY_TYPE_DBI:
r = rfbi_init_display(dssdev);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/23] OMAP: DSS2: fix lock_fb_info() and omapfb_lock() locking order
From: Jani Nikula ext-jani.1.nik...@nokia.com
Framebuffer ioctl processing forces lock_fb_info() - omapfb_lock()
locking order. Follow that order to avoid possible circular locking
dependency, detected by lockdep.
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/omapfb/omapfb-ioctl.c |4 ++--
drivers/video/omap2/omapfb/omapfb-sysfs.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 1ffa760..2c0f01c 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -183,13 +183,13 @@ int omapfb_update_window(struct fb_info *fbi,
struct omapfb2_device *fbdev = ofbi-fbdev;
int r;
- omapfb_lock(fbdev);
lock_fb_info(fbi);
+ omapfb_lock(fbdev);
r = omapfb_update_window_nolock(fbi, x, y, w, h);
- unlock_fb_info(fbi);
omapfb_unlock(fbdev);
+ unlock_fb_info(fbi);
return r;
}
diff --git a/drivers/video/omap2/omapfb/omapfb-sysfs.c
b/drivers/video/omap2/omapfb/omapfb-sysfs.c
index 62bb88f..e104450 100644
--- a/drivers/video/omap2/omapfb/omapfb-sysfs.c
+++ b/drivers/video/omap2/omapfb/omapfb-sysfs.c
@@ -137,8 +137,8 @@ static ssize_t show_overlays(struct device *dev,
ssize_t l = 0;
int t;
- omapfb_lock(fbdev);
lock_fb_info(fbi);
+ omapfb_lock(fbdev);
for (t = 0; t ofbi-num_overlays; t++) {
struct omap_overlay *ovl = ofbi-overlays[t];
@@ -154,8 +154,8 @@ static ssize_t show_overlays(struct device *dev,
l += snprintf(buf + l, PAGE_SIZE - l, \n);
- unlock_fb_info(fbi);
omapfb_unlock(fbdev);
+ unlock_fb_info(fbi);
return l;
}
@@ -195,8 +195,8 @@ static ssize_t store_overlays(struct device *dev, struct
device_attribute *attr,
if (buf[len - 1] == '\n')
len = len - 1;
- omapfb_lock(fbdev);
lock_fb_info(fbi);
+ omapfb_lock(fbdev);
if (len 0) {
char *p = (char *)buf;
@@ -303,8 +303,8 @@ static ssize_t store_overlays(struct device *dev, struct
device_attribute *attr,
r = count;
out:
- unlock_fb_info(fbi);
omapfb_unlock(fbdev);
+ unlock_fb_info(fbi);
return r;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/7] omap3: pm: changing vdd0_/vdd1_ to vdd1_/vdd2_ in VC param structure
Rename vdd0_/vdd1_ to vdd1_/vdd2_ in VC param structure.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/voltage.c | 34 +-
arch/arm/mach-omap2/voltage.h | 10 +-
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index f4069db..1c3f9ed 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -147,14 +147,14 @@ struct __initdata prm_setup_vc omap3430_vc_config = {
.voltoffset = 0x32,
},
/* VC COMMAND VALUES for VDD1/VDD2 */
- .vdd0_on = 0x30,/* 1.2v */
- .vdd0_onlp = 0x20, /* 1.0v */
- .vdd0_ret = 0x1e, /* 0.975v */
- .vdd0_off = 0x00, /* 0.6v */
- .vdd1_on = 0x2c,/* 1.15v */
+ .vdd1_on = 0x30,/* 1.2v */
.vdd1_onlp = 0x20, /* 1.0v */
- .vdd1_ret = 0x1e, /* .975v */
+ .vdd1_ret = 0x1e, /* 0.975v */
.vdd1_off = 0x00, /* 0.6v */
+ .vdd2_on = 0x2c,/* 1.15v */
+ .vdd2_onlp = 0x20, /* 1.0v */
+ .vdd2_ret = 0x1e, /* 0.975v */
+ .vdd2_off = 0x00, /* 0.6v */
};
/*
@@ -178,14 +178,14 @@ struct __initdata prm_setup_vc omap3630_vc_config = {
.voltoffset = 0x32,
},
/* VC COMMAND VALUES for VDD1/VDD2 */
- .vdd0_on = 0x28,/* 1.1v */
- .vdd0_onlp = 0x20, /* 1.0v */
- .vdd0_ret = 0x13, /* 0.83v */
- .vdd0_off = 0x00, /* 0.6v */
- .vdd1_on = 0x2B,/* 1.1375v */
+ .vdd1_on = 0x28,/* 1.1v */
.vdd1_onlp = 0x20, /* 1.0v */
.vdd1_ret = 0x13, /* 0.83v */
.vdd1_off = 0x00, /* 0.6v */
+ .vdd2_on = 0x2B,/* 1.1375v */
+ .vdd2_onlp = 0x20, /* 1.0v */
+ .vdd2_ret = 0x13, /* 0.83v */
+ .vdd2_off = 0x00, /* 0.6v */
};
static struct prm_setup_vc vc_config;
@@ -279,17 +279,17 @@ static void __init init_voltagecontroller(void)
VC_VOLRA0_SHIFT));
voltage_write_reg(vc_reg.cmdval0_reg,
- (vc_config.vdd0_on VC_CMD_ON_SHIFT) |
- (vc_config.vdd0_onlp VC_CMD_ONLP_SHIFT) |
- (vc_config.vdd0_ret VC_CMD_RET_SHIFT) |
- (vc_config.vdd0_off VC_CMD_OFF_SHIFT));
-
- voltage_write_reg(vc_reg.cmdval1_reg,
(vc_config.vdd1_on VC_CMD_ON_SHIFT) |
(vc_config.vdd1_onlp VC_CMD_ONLP_SHIFT) |
(vc_config.vdd1_ret VC_CMD_RET_SHIFT) |
(vc_config.vdd1_off VC_CMD_OFF_SHIFT));
+ voltage_write_reg(vc_reg.cmdval1_reg,
+ (vc_config.vdd2_on VC_CMD_ON_SHIFT) |
+ (vc_config.vdd2_onlp VC_CMD_ONLP_SHIFT) |
+ (vc_config.vdd2_ret VC_CMD_RET_SHIFT) |
+ (vc_config.vdd2_off VC_CMD_OFF_SHIFT));
+
voltage_write_reg(vc_ch_conf_reg, VC_CMD1 | VC_RAV1);
voltage_write_reg(vc_i2c_cfg_reg, VC_MCODE_SHIFT | VC_HSEN);
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index f8462c3..04c3bdf 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -28,15 +28,15 @@ struct prm_setup_vc {
/* CLK VOLT SETUPTIME for OFF */
struct setuptime_vc off;
/* PRM_VC_CMD_VAL_0 specific bits */
- u16 vdd0_on;
- u16 vdd0_onlp;
- u16 vdd0_ret;
- u16 vdd0_off;
-/* PRM_VC_CMD_VAL_1 specific bits */
u16 vdd1_on;
u16 vdd1_onlp;
u16 vdd1_ret;
u16 vdd1_off;
+/* PRM_VC_CMD_VAL_1 specific bits */
+ u16 vdd2_on;
+ u16 vdd2_onlp;
+ u16 vdd2_ret;
+ u16 vdd2_off;
};
#define VOLTSCALE_VPFORCEUPDATE1
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/23] OMAP: DSS2: Fix device disable when driver is not loaded
From: Jani Nikula ext-jani.1.nik...@nokia.com
Only call driver disable when device isn't already disabled, which also
handles the driver not loaded case.
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/display.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 7138963..ef8c852 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -545,7 +545,10 @@ int dss_resume_all_devices(void)
static int dss_disable_device(struct device *dev, void *data)
{
struct omap_dss_device *dssdev = to_dss_device(dev);
- dssdev-driver-disable(dssdev);
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED)
+ dssdev-driver-disable(dssdev);
+
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 http://vger.kernel.org/majordomo-info.html
[PATCH 05/23] OMAP: DSS2: Use vdds_sdi regulator supply in SDI
From: Roger Quadros roger.quad...@nokia.com
This patch enables the use of vdds_sdi regulator in SDI subsystem.
We can disable the vdds_sdi voltage when not in use to save
power.
Signed-off-by: Roger Quadros roger.quad...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/sdi.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 3de3c1e..ee07a3c 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -23,13 +23,16 @@
#include linux/clk.h
#include linux/delay.h
#include linux/err.h
+#include linux/regulator/consumer.h
#include plat/display.h
+#include plat/cpu.h
#include dss.h
static struct {
bool skip_init;
bool update_enabled;
+ struct regulator *vdds_sdi_reg;
} sdi;
static void sdi_basic_init(void)
@@ -57,6 +60,10 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
goto err0;
}
+ r = regulator_enable(sdi.vdds_sdi_reg);
+ if (r)
+ goto err1;
+
/* In case of skip_init sdi_init has already enabled the clocks */
if (!sdi.skip_init)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
@@ -120,6 +127,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
return 0;
err2:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ regulator_disable(sdi.vdds_sdi_reg);
err1:
omap_dss_stop_device(dssdev);
err0:
@@ -135,6 +143,8 @@ void omapdss_sdi_display_disable(struct omap_dss_device
*dssdev)
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ regulator_disable(sdi.vdds_sdi_reg);
+
omap_dss_stop_device(dssdev);
}
EXPORT_SYMBOL(omapdss_sdi_display_disable);
@@ -151,6 +161,11 @@ int sdi_init(bool skip_init)
/* we store this for first display enable, then clear it */
sdi.skip_init = skip_init;
+ sdi.vdds_sdi_reg = dss_get_vdds_sdi();
+ if (IS_ERR(sdi.vdds_sdi_reg)) {
+ DSSERR(can't get VDDS_SDI regulator\n);
+ return PTR_ERR(sdi.vdds_sdi_reg);
+ }
/*
* Enable clocks already here, otherwise there would be a toggle
* of them until sdi_display_enable is called.
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/23] OMAP: DSS2: Make partial update width even
There are some strange problems with DSI and updates with odd widths. One
particular problem is that HS TX timeout triggers easily with updates with
odd widths.
This patch makes the updates widths even, circumventing the problem. There
should be no ill side effects with increasing the update area slightly to
make the width even.
Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/manager.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 0820986..32ec2ff 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -940,6 +940,22 @@ static int configure_dispc(void)
return r;
}
+/* Make the coordinates even. There are some strange problems with OMAP and
+ * partial DSI update when the update widths are odd. */
+static void make_even(u16 *x, u16 *w)
+{
+ u16 x1, x2;
+
+ x1 = *x;
+ x2 = *x + *w;
+
+ x1 = ~1;
+ x2 = ALIGN(x2, 2);
+
+ *x = x1;
+ *w = x2 - x1;
+}
+
/* Configure dispc for partial update. Return possibly modified update
* area */
void dss_setup_partial_planes(struct omap_dss_device *dssdev,
@@ -968,6 +984,8 @@ void dss_setup_partial_planes(struct omap_dss_device
*dssdev,
return;
}
+ make_even(x, w);
+
spin_lock_irqsave(dss_cache.lock, flags);
/* We need to show the whole overlay if it is scaled. So look for
@@ -1029,6 +1047,8 @@ void dss_setup_partial_planes(struct omap_dss_device
*dssdev,
w = x2 - x1;
h = y2 - y1;
+ make_even(x, w);
+
DSSDBG(changing upd area due to ovl(%d) scaling %d,%d %dx%d\n,
i, x, y, w, h);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/23] OMAP: DSS2: VENC: don't call platform_enable/disable() twice
From: Jani Nikula ext-jani.1.nik...@nokia.com
platform_enable/disable() is already called in venc_power_on/off(), so
don't do it again in venc_panel_enable/disable().
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/venc.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index f0ba573..eff3505 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -479,12 +479,6 @@ static int venc_panel_enable(struct omap_dss_device
*dssdev)
goto err1;
}
- if (dssdev-platform_enable) {
- r = dssdev-platform_enable(dssdev);
- if (r)
- goto err2;
- }
-
venc_power_on(dssdev);
venc.wss_data = 0;
@@ -494,13 +488,9 @@ static int venc_panel_enable(struct omap_dss_device
*dssdev)
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
- mutex_unlock(venc.venc_lock);
-
- return r;
-err2:
- venc_power_off(dssdev);
err1:
mutex_unlock(venc.venc_lock);
+
return r;
}
@@ -524,9 +514,6 @@ static void venc_panel_disable(struct omap_dss_device
*dssdev)
/* wait at least 5 vsyncs after disabling the LCD */
msleep(100);
- if (dssdev-platform_disable)
- dssdev-platform_disable(dssdev);
-
dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
end:
mutex_unlock(venc.venc_lock);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/7] omap3: pm: Generic TRITON power scripts for OMAP3 based boards
This pacth will create the generic TRITON power scripts which can be used
by different OMAP3 boards with the same power companion chip (TWL4030 series).
Added the api(twl4030_get_scripts/twl4030_get_vc_timings) to update the
sleep/wakeup/warm_rest sequence, resource configuration voltsetup_time
in the board file.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/twl4030.c | 185 +
arch/arm/mach-omap2/twl4030.h | 15
arch/arm/mach-omap2/voltage.c |5 +-
3 files changed, 202 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/twl4030.c
create mode 100644 arch/arm/mach-omap2/twl4030.h
diff --git a/arch/arm/mach-omap2/twl4030.c b/arch/arm/mach-omap2/twl4030.c
new file mode 100644
index 000..b5b3f3c
--- /dev/null
+++ b/arch/arm/mach-omap2/twl4030.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Lesly A M x0080...@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.
+ */
+
+#ifdef CONFIG_TWL4030_POWER
+
+#include twl4030.h
+
+static struct prm_setup_vc twl4030_voltsetup_time = {
+ /* VOLT SETUPTIME for RET */
+ .ret = {
+ .voltsetup1_vdd1 = 0x005B,
+ .voltsetup1_vdd2 = 0x0055,
+ .voltsetup2 = 0x0,
+ .voltoffset = 0x0,
+ },
+ /* VOLT SETUPTIME for OFF */
+ .off = {
+ .voltsetup1_vdd1 = 0x00B3,
+ .voltsetup1_vdd2 = 0x00A0,
+ .voltsetup2 = 0x118,
+ .voltoffset = 0x32,
+ },
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system goes into sleep.
+ * Executed upon P1_P2/P3 transition for sleep.
+ */
+static struct twl4030_ins __initdata sleep_on_seq[] = {
+ /* Broadcast message to put res to sleep */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_SLEEP), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_SLEEP), 2},
+};
+
+static struct twl4030_script sleep_on_script __initdata = {
+ .script = sleep_on_seq,
+ .size = ARRAY_SIZE(sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system wakeup from sleep.
+ * Executed upon P1_P2 transition for wakeup.
+ */
+static struct twl4030_ins wakeup_p12_seq[] __initdata = {
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p12_script __initdata = {
+ .script = wakeup_p12_seq,
+ .size = ARRAY_SIZE(wakeup_p12_seq),
+ .flags = TWL4030_WAKEUP12_SCRIPT,
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system wakeup from sleep.
+ * Executed upon P3 transition for wakeup.
+ */
+static struct twl4030_ins wakeup_p3_seq[] __initdata = {
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p3_script __initdata = {
+ .script = wakeup_p3_seq,
+ .size = ARRAY_SIZE(wakeup_p3_seq),
+ .flags = TWL4030_WAKEUP3_SCRIPT,
+};
+
+/*
+ * Sequence to reset the TRITON Power resources,
+ * when the system gets warm reset.
+ * Executed upon warm reset signal.
+ */
+static struct twl4030_ins wrst_seq[] __initdata = {
+/*
+ * Reset twl4030.
+ * Reset Main_Ref.
+ * Reset All type2_group2.
+ * Reset VUSB_3v1.
+ * Reset All type2_group1.
+ * Reset RC.
+ * Reenable twl4030.
+ */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_Main_Ref, RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_WRST), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VUSB_3V1, RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_RC, RES_TYPE_ALL, RES_TYPE2_R0,
+ RES_STATE_WRST), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size =
[PATCH 11/23] OMAP: DSS2: Taal: add mutex to protect panel data
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/displays/panel-taal.c | 140 -
1 files changed, 119 insertions(+), 21 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 4f3988a..1799096 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -31,6 +31,7 @@
#include linux/completion.h
#include linux/workqueue.h
#include linux/slab.h
+#include linux/mutex.h
#include plat/display.h
@@ -67,6 +68,8 @@
static int _taal_enable_te(struct omap_dss_device *dssdev, bool enable);
struct taal_data {
+ struct mutex lock;
+
struct backlight_device *bldev;
unsigned long hw_guard_end; /* next value of jiffies when we can
@@ -510,6 +513,8 @@ static int taal_probe(struct omap_dss_device *dssdev)
}
td-dssdev = dssdev;
+ mutex_init(td-lock);
+
td-esd_wq = create_singlethread_workqueue(taal_esd);
if (td-esd_wq == NULL) {
dev_err(dssdev-dev, can't create ESD workqueue\n);
@@ -733,54 +738,96 @@ static void taal_power_off(struct omap_dss_device *dssdev)
static int taal_enable(struct omap_dss_device *dssdev)
{
+ struct taal_data *td = dev_get_drvdata(dssdev-dev);
int r;
+
dev_dbg(dssdev-dev, enable\n);
- if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED)
- return -EINVAL;
+ mutex_lock(td-lock);
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED) {
+ r = -EINVAL;
+ goto err;
+ }
r = taal_power_on(dssdev);
if (r)
- return r;
+ goto err;
dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+ mutex_unlock(td-lock);
+
+ return 0;
+err:
+ dev_dbg(dssdev-dev, enable failed\n);
+ mutex_unlock(td-lock);
return r;
}
static void taal_disable(struct omap_dss_device *dssdev)
{
+ struct taal_data *td = dev_get_drvdata(dssdev-dev);
+
dev_dbg(dssdev-dev, disable\n);
+ mutex_lock(td-lock);
+
if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
taal_power_off(dssdev);
dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+
+ mutex_unlock(td-lock);
}
static int taal_suspend(struct omap_dss_device *dssdev)
{
+ struct taal_data *td = dev_get_drvdata(dssdev-dev);
+ int r;
+
dev_dbg(dssdev-dev, suspend\n);
- if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
- return -EINVAL;
+ mutex_lock(td-lock);
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE) {
+ r = -EINVAL;
+ goto err;
+ }
taal_power_off(dssdev);
dssdev-state = OMAP_DSS_DISPLAY_SUSPENDED;
+ mutex_unlock(td-lock);
+
return 0;
+err:
+ mutex_unlock(td-lock);
+ return r;
}
static int taal_resume(struct omap_dss_device *dssdev)
{
+ struct taal_data *td = dev_get_drvdata(dssdev-dev);
int r;
+
dev_dbg(dssdev-dev, resume\n);
- if (dssdev-state != OMAP_DSS_DISPLAY_SUSPENDED)
- return -EINVAL;
+ mutex_lock(td-lock);
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_SUSPENDED) {
+ r = -EINVAL;
+ goto err;
+ }
r = taal_power_on(dssdev);
dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ mutex_unlock(td-lock);
+
+ return r;
+err:
+ mutex_unlock(td-lock);
return r;
}
@@ -799,6 +846,7 @@ static int taal_update(struct omap_dss_device *dssdev,
dev_dbg(dssdev-dev, update %d, %d, %d x %d\n, x, y, w, h);
+ mutex_lock(td-lock);
dsi_bus_lock();
if (!td-enabled) {
@@ -820,18 +868,24 @@ static int taal_update(struct omap_dss_device *dssdev,
goto err;
/* note: no bus_unlock here. unlock is in framedone_cb */
+ mutex_unlock(td-lock);
return 0;
err:
dsi_bus_unlock();
+ mutex_unlock(td-lock);
return r;
}
static int taal_sync(struct omap_dss_device *dssdev)
{
+ struct taal_data *td = dev_get_drvdata(dssdev-dev);
+
dev_dbg(dssdev-dev, sync\n);
+ mutex_lock(td-lock);
dsi_bus_lock();
dsi_bus_unlock();
+ mutex_unlock(td-lock);
dev_dbg(dssdev-dev, sync done\n);
@@ -861,13 +915,16 @@ static int _taal_enable_te(struct omap_dss_device
*dssdev, bool enable)
static int taal_enable_te(struct omap_dss_device *dssdev, bool enable)
{
+ struct taal_data *td = dev_get_drvdata(dssdev-dev);
int r;
+ mutex_lock(td-lock);
dsi_bus_lock();
r = _taal_enable_te(dssdev, enable);
dsi_bus_unlock();
+ mutex_unlock(td-lock);
return r;
}
@@ -875,7 +932,13 @@ static int taal_enable_te(struct omap_dss_device *dssdev,
bool enable)
static int taal_get_te(struct omap_dss_device *dssdev)
{
[PATCH 16/23] OMAP: RX51: Add Touch Controller in SPI board info
From: Roger Quadros roger.quad...@nokia.com
The Touch controller and LCD Panel share the same SPI bus 1.
So, we need to define the touch controller in the SPI board info
else, the SPI bus will be contended due to invalid state of
Touch controller's Chip Select thus preventing the LCD panel
from working.
Signed-off-by: Roger Quadros roger.quad...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index f404537..d27a4ef 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -46,6 +46,7 @@
enum {
RX51_SPI_WL1251,
RX51_SPI_MIPID, /* LCD panel */
+ RX51_SPI_TSC2005, /* Touch Controller */
};
static struct wl12xx_platform_data wl1251_pdata;
@@ -60,6 +61,11 @@ static struct omap2_mcspi_device_config mipid_mcspi_config =
{
.single_channel = 1,
};
+static struct omap2_mcspi_device_config tsc2005_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -77,6 +83,15 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.max_speed_hz = 600,
.controller_data= mipid_mcspi_config,
},
+ [RX51_SPI_TSC2005] = {
+ .modalias = tsc2005,
+ .bus_num= 1,
+ .chip_select= 0,
+ /* .irq = OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),*/
+ .max_speed_hz = 600,
+ .controller_data= tsc2005_mcspi_config,
+ /* .platform_data = tsc2005_config,*/
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/23] OMAP: DSS2: check lock_fb_info() return value
From: Jani Nikula ext-jani.1.nik...@nokia.com
Give up if lock_fb_info() fails, following the same convention as other
lock_fb_info() users.
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/omapfb/omapfb-ioctl.c |3 ++-
drivers/video/omap2/omapfb/omapfb-sysfs.c | 21 ++---
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 2c0f01c..9c73618 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -183,7 +183,8 @@ int omapfb_update_window(struct fb_info *fbi,
struct omapfb2_device *fbdev = ofbi-fbdev;
int r;
- lock_fb_info(fbi);
+ if (!lock_fb_info(fbi))
+ return -ENODEV;
omapfb_lock(fbdev);
r = omapfb_update_window_nolock(fbi, x, y, w, h);
diff --git a/drivers/video/omap2/omapfb/omapfb-sysfs.c
b/drivers/video/omap2/omapfb/omapfb-sysfs.c
index e104450..5179219 100644
--- a/drivers/video/omap2/omapfb/omapfb-sysfs.c
+++ b/drivers/video/omap2/omapfb/omapfb-sysfs.c
@@ -57,7 +57,8 @@ static ssize_t store_rotate_type(struct device *dev,
if (rot_type != OMAP_DSS_ROT_DMA rot_type != OMAP_DSS_ROT_VRFB)
return -EINVAL;
- lock_fb_info(fbi);
+ if (!lock_fb_info(fbi))
+ return -ENODEV;
r = 0;
if (rot_type == ofbi-rotation_type)
@@ -105,7 +106,8 @@ static ssize_t store_mirror(struct device *dev,
if (mirror != 0 mirror != 1)
return -EINVAL;
- lock_fb_info(fbi);
+ if (!lock_fb_info(fbi))
+ return -ENODEV;
ofbi-mirror = mirror;
@@ -137,7 +139,8 @@ static ssize_t show_overlays(struct device *dev,
ssize_t l = 0;
int t;
- lock_fb_info(fbi);
+ if (!lock_fb_info(fbi))
+ return -ENODEV;
omapfb_lock(fbdev);
for (t = 0; t ofbi-num_overlays; t++) {
@@ -195,7 +198,8 @@ static ssize_t store_overlays(struct device *dev, struct
device_attribute *attr,
if (buf[len - 1] == '\n')
len = len - 1;
- lock_fb_info(fbi);
+ if (!lock_fb_info(fbi))
+ return -ENODEV;
omapfb_lock(fbdev);
if (len 0) {
@@ -317,7 +321,8 @@ static ssize_t show_overlays_rotate(struct device *dev,
ssize_t l = 0;
int t;
- lock_fb_info(fbi);
+ if (!lock_fb_info(fbi))
+ return -ENODEV;
for (t = 0; t ofbi-num_overlays; t++) {
l += snprintf(buf + l, PAGE_SIZE - l, %s%d,
@@ -345,7 +350,8 @@ static ssize_t store_overlays_rotate(struct device *dev,
if (buf[len - 1] == '\n')
len = len - 1;
- lock_fb_info(fbi);
+ if (!lock_fb_info(fbi))
+ return -ENODEV;
if (len 0) {
char *p = (char *)buf;
@@ -416,7 +422,8 @@ static ssize_t store_size(struct device *dev, struct
device_attribute *attr,
size = PAGE_ALIGN(simple_strtoul(buf, NULL, 0));
- lock_fb_info(fbi);
+ if (!lock_fb_info(fbi))
+ return -ENODEV;
for (i = 0; i ofbi-num_overlays; i++) {
if (ofbi-overlays[i]-info.enabled) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/23] OMAP: RX51: Add LCD Panel support
From: Roger Quadros roger.quad...@nokia.com
Adds basic support for LCD Panel on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 13 +++
arch/arm/mach-omap2/board-rx51-video.c | 109 ++
arch/arm/mach-omap2/board-rx51.c |2 +
4 files changed, 125 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rx51-video.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..b03cbb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
board-rx51-peripherals.o \
+ board-rx51-video.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..f404537 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -45,6 +45,7 @@
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata;
@@ -54,6 +55,11 @@ static struct omap2_mcspi_device_config wl1251_mcspi_config
= {
.single_channel = 1,
};
+static struct omap2_mcspi_device_config mipid_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -64,6 +70,13 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.controller_data= wl1251_mcspi_config,
.platform_data = wl1251_pdata,
},
+ [RX51_SPI_MIPID] = {
+ .modalias = acx565akm,
+ .bus_num= 1,
+ .chip_select= 2,
+ .max_speed_hz = 600,
+ .controller_data= mipid_mcspi_config,
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
new file mode 100644
index 000..b743a4f
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -0,0 +1,109 @@
+/*
+ * linux/arch/arm/mach-omap2/board-rx51-video.c
+ *
+ * Copyright (C) 2010 Nokia
+ *
+ * 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/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/spi/spi.h
+#include linux/mm.h
+
+#include asm/mach-types.h
+#include plat/mux.h
+#include plat/display.h
+#include plat/vram.h
+#include plat/mcspi.h
+
+#include mux.h
+
+#define RX51_LCD_RESET_GPIO90
+
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+static int rx51_lcd_enable(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dssdev-reset_gpio, 1);
+ return 0;
+}
+
+static void rx51_lcd_disable(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dssdev-reset_gpio, 0);
+}
+
+static struct omap_dss_device rx51_lcd_device = {
+ .name = lcd,
+ .driver_name= panel-acx565akm,
+ .type = OMAP_DISPLAY_TYPE_SDI,
+ .phy.sdi.datapairs = 2,
+ .reset_gpio = RX51_LCD_RESET_GPIO,
+ .platform_enable= rx51_lcd_enable,
+ .platform_disable = rx51_lcd_disable,
+};
+
+static struct omap_dss_device *rx51_dss_devices[] = {
+ rx51_lcd_device,
+};
+
+static struct omap_dss_board_info rx51_dss_board_info = {
+ .num_devices= ARRAY_SIZE(rx51_dss_devices),
+ .devices= rx51_dss_devices,
+ .default_device = rx51_lcd_device,
+};
+
+struct platform_device rx51_display_device = {
+ .name = omapdss,
+ .id = -1,
+ .dev= {
+ .platform_data = rx51_dss_board_info,
+ },
+};
+
+static struct platform_device *rx51_video_devices[] __initdata = {
+ rx51_display_device,
+};
+
+static int __init rx51_video_init(void)
+{
+ if (!machine_is_nokia_rx51())
+ return 0;
+
+ if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO,
[PATCH v6 6/7] omap3: pm: Use generic TRITON power scripts for 3430SDP board
This patch will removed the sleep/wakeup/warm_rest sequence resource
configuration
from the 3430SDP board file and use the generic script.
Updating the sleep/wakeup/warm_rest sequence resource configuration in the
board file from generic script file.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-3430sdp.c | 92 +-
include/linux/i2c/twl.h |4 ++
3 files changed, 9 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 184badd..f60dca3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -127,7 +127,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)+= board-omap3pandora.o
\
hsmmc.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
hsmmc.o \
- board-sdp-flash.o
+ board-sdp-flash.o \
+ twl4030.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index c7f0fa8..91d8cc6 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -46,6 +46,7 @@
#include mux.h
#include sdram-qimonda-hyb18m512160af-6.h
#include hsmmc.h
+#include twl4030.h
#include pm.h
#include omap3-opp.h
#include smartreflex-class3.h
@@ -424,95 +425,7 @@ static struct twl4030_madc_platform_data sdp3430_madc_data
= {
.irq_line = 1,
};
-
-static struct twl4030_ins __initdata sleep_on_seq[] = {
- /* Turn off HFCLKOUT */
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_OFF), 2},
- /* Turn OFF VDD1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 2},
- /* Turn OFF VDD2 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_OFF), 2},
- /* Turn OFF VPLL1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 2},
-};
-
-static struct twl4030_script sleep_on_script __initdata = {
- .script = sleep_on_seq,
- .size = ARRAY_SIZE(sleep_on_seq),
- .flags = TWL4030_SLEEP_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p12_seq[] __initdata = {
- /* Turn on HFCLKOUT */
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- /* Turn ON VDD1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 2},
- /* Turn ON VDD2 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 2},
- /* Turn ON VPLL1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p12_script __initdata = {
- .script = wakeup_p12_seq,
- .size = ARRAY_SIZE(wakeup_p12_seq),
- .flags = TWL4030_WAKEUP12_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p3_seq[] __initdata = {
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p3_script __initdata = {
- .script = wakeup_p3_seq,
- .size = ARRAY_SIZE(wakeup_p3_seq),
- .flags = TWL4030_WAKEUP3_SCRIPT,
-};
-
-static struct twl4030_ins wrst_seq[] __initdata = {
-/*
- * Reset twl4030.
- * Reset VDD1 regulator.
- * Reset VDD2 regulator.
- * Reset VPLL1 regulator.
- * Enable sysclk output.
- * Reenable twl4030.
- */
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
-};
-static struct twl4030_script wrst_script __initdata = {
- .script = wrst_seq,
- .size = ARRAY_SIZE(wrst_seq),
- .flags = TWL4030_WRST_SCRIPT,
-};
-
-static struct twl4030_script *twl4030_scripts[] __initdata = {
- sleep_on_script,
- wakeup_p12_script,
- wakeup_p3_script,
- wrst_script,
-};
-
-static struct twl4030_resconfig twl4030_rconfig[] = {
- { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
- .type2 = -1 },
- { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
- .type2 = -1 },
- { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
- .type2 = -1 },
- { 0, 0},
-};
-
-static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
- .scripts= twl4030_scripts,
- .num= ARRAY_SIZE(twl4030_scripts),
- .resource_config = twl4030_rconfig,
-};
+static struct
[PATCH 18/23] OMAP: RX51: Update board defconfig
From: Roger Quadros roger.quad...@nokia.com Add LCD, Boot-up logo, framebuffer console, Keypad and Power button support Signed-off-by: Roger Quadros roger.quad...@nokia.com Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- arch/arm/configs/rx51_defconfig | 39 ++- 1 files changed, 38 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig index 473f9e1..56d4928 100644 --- a/arch/arm/configs/rx51_defconfig +++ b/arch/arm/configs/rx51_defconfig @@ -784,6 +784,7 @@ CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_KEYBOARD_GPIO=m +CONFIG_KEYBOARD_TWL4030=y # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set @@ -809,6 +810,7 @@ CONFIG_INPUT_MISC=y # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set +CONFIG_INPUT_TWL4030_PWRBUTTON=y CONFIG_INPUT_UINPUT=m # @@ -1110,7 +1112,40 @@ CONFIG_RADIO_ADAPTERS=y # # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set -# CONFIG_FB is not set +CONFIG_FB=y +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y + +# Frame buffer hardware drivers +# +CONFIG_OMAP2_VRAM=y +CONFIG_OMAP2_VRFB=y +CONFIG_OMAP2_DSS=y +CONFIG_OMAP2_VRAM_SIZE=0 +# CONFIG_OMAP2_DSS_DEBUG_SUPPORT is not set +# CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set +# CONFIG_OMAP2_DSS_DPI is not set +# CONFIG_OMAP2_DSS_RFBI is not set +# CONFIG_OMAP2_DSS_VENC is not set +CONFIG_OMAP2_DSS_SDI=y +# CONFIG_OMAP2_DSS_DSI is not set +# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set +CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 +CONFIG_FB_OMAP2=y +CONFIG_FB_OMAP2_DEBUG_SUPPORT=y +CONFIG_FB_OMAP2_NUM_FBS=3 + +# +# OMAP2/3 Display Device Drivers +# +# CONFIG_PANEL_GENERIC is not set +# CONFIG_PANEL_SHARP_LS037V7DW01 is not set +# CONFIG_PANEL_SHARP_LQ043T1DG01 is not set +# CONFIG_PANEL_TOPPOLY_TDO35S is not set +# CONFIG_PANEL_TPO_TD043MTEA1 is not set +CONFIG_PANEL_ACX565AKM=y + # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # @@ -1127,6 +1162,8 @@ CONFIG_DISPLAY_SUPPORT=y # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_LOGO=y CONFIG_SOUND=y # CONFIG_SOUND_OSS_CORE is not set CONFIG_SND=y -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/23] OMAP: AM3517: Enable DSS2 in AM3517EVM defconfig
From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com [tomi.valkei...@nokia.com: removed the board file changes] Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- arch/arm/configs/am3517_evm_defconfig | 52 - 1 files changed, 51 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/am3517_evm_defconfig b/arch/arm/configs/am3517_evm_defconfig index 66a10b5..214ef42 100644 --- a/arch/arm/configs/am3517_evm_defconfig +++ b/arch/arm/configs/am3517_evm_defconfig @@ -692,7 +692,57 @@ CONFIG_SSB_POSSIBLE=y # # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set -# CONFIG_FB is not set +CONFIG_FB=y +# CONFIG_FIRMWARE_EDID is not set +# CONFIG_FB_DDC is not set +# CONFIG_FB_BOOT_VESA_SUPPORT is not set +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set +# CONFIG_FB_SYS_FILLRECT is not set +# CONFIG_FB_SYS_COPYAREA is not set +# CONFIG_FB_SYS_IMAGEBLIT is not set +# CONFIG_FB_FOREIGN_ENDIAN is not set +# CONFIG_FB_SYS_FOPS is not set +# CONFIG_FB_SVGALIB is not set +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +# CONFIG_FB_MODE_HELPERS is not set +# CONFIG_FB_TILEBLITTING is not set + +# +# Frame buffer hardware drivers +# +# CONFIG_FB_ARMCLCD is not set +# CONFIG_FB_S1D13XXX is not set +# CONFIG_FB_VIRTUAL is not set +# CONFIG_FB_METRONOME is not set +# CONFIG_FB_MB862XX is not set +# CONFIG_FB_BROADSHEET is not set +# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set +CONFIG_OMAP2_VRAM=y +CONFIG_OMAP2_VRFB=y +CONFIG_OMAP2_DSS=y +CONFIG_OMAP2_VRAM_SIZE=4 +CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y +# CONFIG_OMAP2_DSS_RFBI is not set +CONFIG_OMAP2_DSS_VENC=y +# CONFIG_OMAP2_DSS_SDI is not set +# CONFIG_OMAP2_DSS_DSI is not set +# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set +CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 +CONFIG_FB_OMAP2=y +CONFIG_FB_OMAP2_DEBUG_SUPPORT=y +# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set +CONFIG_FB_OMAP2_NUM_FBS=3 + +# +# OMAP2/3 Display Device Drivers +# +CONFIG_PANEL_GENERIC=y +# CONFIG_PANEL_SHARP_LS037V7DW01 is not set +CONFIG_PANEL_SHARP_LQ043T1DG01=y # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/23] OMAP: LCD LS037V7DW01: Add Backlight driver support
From: Vaibhav Hiremath hvaib...@ti.com
Tested on OMAP3EVM for OMAP3530 and AM/DM 3730.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
[tomi.valkei...@nokia.com: added slab.h include]
[tomi.valkei...@nokia.com: added dependency to BACKLIGHT_CLASS_DEVICE]
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/displays/Kconfig |1 +
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 78
2 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index dfb57ee..ea8ccd3 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -10,6 +10,7 @@ config PANEL_GENERIC
config PANEL_SHARP_LS037V7DW01
tristate Sharp LS037V7DW01 LCD Panel
depends on OMAP2_DSS
+select BACKLIGHT_CLASS_DEVICE
help
LCD Panel used in TI's SDP3430 and EVM boards
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 8d51a5e..7d9eb2b 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -20,10 +20,17 @@
#include linux/module.h
#include linux/delay.h
#include linux/device.h
+#include linux/backlight.h
+#include linux/fb.h
#include linux/err.h
+#include linux/slab.h
#include plat/display.h
+struct sharp_data {
+ struct backlight_device *bl;
+};
+
static struct omap_video_timings sharp_ls_timings = {
.x_res = 480,
.y_res = 640,
@@ -39,18 +46,89 @@ static struct omap_video_timings sharp_ls_timings = {
.vbp= 1,
};
+static int sharp_ls_bl_update_status(struct backlight_device *bl)
+{
+ struct omap_dss_device *dssdev = dev_get_drvdata(bl-dev);
+ int level;
+
+ if (!dssdev-set_backlight)
+ return -EINVAL;
+
+ if (bl-props.fb_blank == FB_BLANK_UNBLANK
+ bl-props.power == FB_BLANK_UNBLANK)
+ level = bl-props.brightness;
+ else
+ level = 0;
+
+ return dssdev-set_backlight(dssdev, level);
+}
+
+static int sharp_ls_bl_get_brightness(struct backlight_device *bl)
+{
+ if (bl-props.fb_blank == FB_BLANK_UNBLANK
+ bl-props.power == FB_BLANK_UNBLANK)
+ return bl-props.brightness;
+
+ return 0;
+}
+
+static const struct backlight_ops sharp_ls_bl_ops = {
+ .get_brightness = sharp_ls_bl_get_brightness,
+ .update_status = sharp_ls_bl_update_status,
+};
+
+
+
static int sharp_ls_panel_probe(struct omap_dss_device *dssdev)
{
+ struct backlight_properties props;
+ struct backlight_device *bl;
+ struct sharp_data *sd;
+ int r;
+
dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
OMAP_DSS_LCD_IHS;
dssdev-panel.acb = 0x28;
dssdev-panel.timings = sharp_ls_timings;
+ sd = kzalloc(sizeof(*sd), GFP_KERNEL);
+ if (!sd)
+ return -ENOMEM;
+
+ dev_set_drvdata(dssdev-dev, sd);
+
+ memset(props, 0, sizeof(struct backlight_properties));
+ props.max_brightness = dssdev-max_backlight_level;
+
+ bl = backlight_device_register(sharp-ls, dssdev-dev, dssdev,
+ sharp_ls_bl_ops, props);
+ if (IS_ERR(bl)) {
+ r = PTR_ERR(bl);
+ kfree(sd);
+ return r;
+ }
+ sd-bl = bl;
+
+ bl-props.fb_blank = FB_BLANK_UNBLANK;
+ bl-props.power = FB_BLANK_UNBLANK;
+ bl-props.brightness = dssdev-max_backlight_level;
+ r = sharp_ls_bl_update_status(bl);
+ if (r 0)
+ dev_err(dssdev-dev, failed to set lcd brightness\n);
+
return 0;
}
static void sharp_ls_panel_remove(struct omap_dss_device *dssdev)
{
+ struct sharp_data *sd = dev_get_drvdata(dssdev-dev);
+ struct backlight_device *bl = sd-bl;
+
+ bl-props.power = FB_BLANK_POWERDOWN;
+ sharp_ls_bl_update_status(bl);
+ backlight_device_unregister(bl);
+
+ kfree(sd);
}
static int sharp_ls_power_on(struct omap_dss_device *dssdev)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 7/7] omap3: pm: Use generic TRITON power scripts for ZOOM[2,3], 3630SDP board
Adding the power script data for zoom board to TWL4030 platform data.
Updating the sleep/wakeup/warm_rest sequence resource configuration
from generic script file.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/Makefile |9 ++---
arch/arm/mach-omap2/board-zoom-peripherals.c |6 ++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f60dca3..ba3de05 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -137,14 +137,17 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
hsmmc.o \
- board-zoom-debugboard.o
+ board-zoom-debugboard.o \
+ twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
hsmmc.o \
- board-zoom-debugboard.o
+ board-zoom-debugboard.o \
+ twl4030.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
- hsmmc.o
+ hsmmc.o \
+ twl4030.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..5c8a329 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -26,6 +26,7 @@
#include mux.h
#include hsmmc.h
+#include twl4030.h
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -94,6 +95,8 @@ static struct twl4030_keypad_data zoom_kp_twl4030_data = {
.rep= 1,
};
+static struct twl4030_power_data zoom_t2scripts_data __initdata;
+
static struct regulator_consumer_supply zoom_vmmc1_supply = {
.supply = vmmc,
};
@@ -239,6 +242,7 @@ static struct twl4030_platform_data zoom_twldata = {
.usb= zoom_usb_data,
.gpio = zoom_gpio_data,
.keypad = zoom_kp_twl4030_data,
+ .power = zoom_t2scripts_data,
.codec = zoom_codec_data,
.vmmc1 = zoom_vmmc1,
.vmmc2 = zoom_vmmc2,
@@ -279,6 +283,8 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
+ twl4030_get_scripts(zoom_t2scripts_data);
+
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/23] OMAP3630: DSS2: Updating MAX divider value
From: Kishore Y kishor...@ti.com
In DPLL4 M3, M4, M5 and M6 field width has been increased by 1 bit in 3630.
So the max divider value that can be achived will be 32 and not 16.
In 3630 the functional clock is x1 of DPLL4 and not x2. Hence multiplier 2
is removed.
Signed-off-by: Sudeep Basavaraj sudeep.basava...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/dss.c | 24 +++-
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 5434418..24b1825 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -223,7 +223,13 @@ void dss_dump_clocks(struct seq_file *s)
seq_printf(s, dpll4_ck %lu\n, dpll4_ck_rate);
- seq_printf(s, dss1_alwon_fclk = %lu / %lu * 2 = %lu\n,
+ if (cpu_is_omap3630())
+ seq_printf(s, dss1_alwon_fclk = %lu / %lu = %lu\n,
+ dpll4_ck_rate,
+ dpll4_ck_rate / dpll4_m4_ck_rate,
+ dss_clk_get_rate(DSS_CLK_FCK1));
+ else
+ seq_printf(s, dss1_alwon_fclk = %lu / %lu * 2 = %lu\n,
dpll4_ck_rate,
dpll4_ck_rate / dpll4_m4_ck_rate,
dss_clk_get_rate(DSS_CLK_FCK1));
@@ -293,7 +299,8 @@ int dss_calc_clock_rates(struct dss_clock_info *cinfo)
{
unsigned long prate;
- if (cinfo-fck_div 16 || cinfo-fck_div == 0)
+ if (cinfo-fck_div (cpu_is_omap3630() ? 32 : 16) ||
+ cinfo-fck_div == 0)
return -EINVAL;
prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
@@ -329,7 +336,10 @@ int dss_get_clock_div(struct dss_clock_info *cinfo)
if (cpu_is_omap34xx()) {
unsigned long prate;
prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
- cinfo-fck_div = prate / (cinfo-fck / 2);
+ if (cpu_is_omap3630())
+ cinfo-fck_div = prate / (cinfo-fck);
+ else
+ cinfo-fck_div = prate / (cinfo-fck / 2);
} else {
cinfo-fck_div = 0;
}
@@ -402,10 +412,14 @@ retry:
goto found;
} else if (cpu_is_omap34xx()) {
- for (fck_div = 16; fck_div 0; --fck_div) {
+ for (fck_div = (cpu_is_omap3630() ? 32 : 16);
+ fck_div 0; --fck_div) {
struct dispc_clock_info cur_dispc;
- fck = prate / fck_div * 2;
+ if (cpu_is_omap3630())
+ fck = prate / fck_div;
+ else
+ fck = prate / fck_div * 2;
if (fck DISPC_MAX_FCK)
continue;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/23] OMAP: DSS2: Remove redundant enable/disable calls from SDI
From: Roger Quadros roger.quad...@nokia.com
Panel enable/disable is now done via the panel driver, so we should not
call the panel driver again
Signed-off-by: Roger Quadros roger.quad...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/sdi.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 12eb404..3de3c1e 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -115,17 +115,9 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
dssdev-manager-enable(dssdev-manager);
- if (dssdev-driver-enable) {
- r = dssdev-driver-enable(dssdev);
- if (r)
- goto err3;
- }
-
sdi.skip_init = 0;
return 0;
-err3:
- dssdev-manager-disable(dssdev-manager);
err2:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
err1:
@@ -137,9 +129,6 @@ EXPORT_SYMBOL(omapdss_sdi_display_enable);
void omapdss_sdi_display_disable(struct omap_dss_device *dssdev)
{
- if (dssdev-driver-disable)
- dssdev-driver-disable(dssdev);
-
dssdev-manager-disable(dssdev-manager);
dss_sdi_disable();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/23] OMAP: DSS2: Taal: Fix DSI bus locking problem
From: Ville Syrjälä ville.syrj...@nokia.com If omapdss_dsi_display_enable() failed the DSI bus was left locked. Also if the operation failed later omapdss_dsi_display_disable() would get called without holding the bus lock. Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- drivers/video/omap2/displays/panel-taal.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c index 1799096..aaf5d30 100644 --- a/drivers/video/omap2/displays/panel-taal.c +++ b/drivers/video/omap2/displays/panel-taal.c @@ -702,10 +702,9 @@ static int taal_power_on(struct omap_dss_device *dssdev) return 0; err: - dsi_bus_unlock(); - omapdss_dsi_display_disable(dssdev); err0: + dsi_bus_unlock(); if (dssdev-platform_disable) dssdev-platform_disable(dssdev); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/23] OMAP2: DSS: Add missing line for update bg color
From: Carlos Lopez carlos.c...@sasken.com The driver set the background color canvas but never writes it in DISPC_DEFAULT_COLOR_m register, which changes the background color on the LCD or TV. This patch adds a line to call to dispc_set_default_color() which is the function in charge to write the DISPC_DEFAULT_COLOR_m register. Signed-off-by: Carlos Lopez carlos.c...@sasken.com Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- drivers/video/omap2/dss/manager.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c index 32ec2ff..9e1fbe5 100644 --- a/drivers/video/omap2/dss/manager.c +++ b/drivers/video/omap2/dss/manager.c @@ -843,6 +843,7 @@ static void configure_manager(enum omap_channel channel) c = dss_cache.manager_cache[channel]; + dispc_set_default_color(channel, c-default_color); dispc_set_trans_key(channel, c-trans_key_type, c-trans_key); dispc_enable_trans_key(channel, c-trans_enabled); dispc_enable_alpha_blending(channel, c-alpha_enabled); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/23] board-omap3-beagle: add DSS2 support
From: Koen Kooi koen.k...@gmail.com
This patch adds DSS2 support to the beagleboard boardfile. DVI and
TV-out are supported.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 101 +++
1 files changed, 75 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 962d377..69b154c 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -39,6 +39,7 @@
#include plat/board.h
#include plat/common.h
+#include plat/display.h
#include plat/gpmc.h
#include plat/nand.h
#include plat/usb.h
@@ -106,6 +107,77 @@ static struct platform_device omap3beagle_nand_device = {
.resource = omap3beagle_nand_resource,
};
+/* DSS */
+
+static int beagle_enable_dvi(struct omap_dss_device *dssdev)
+{
+ if (gpio_is_valid(dssdev-reset_gpio))
+ gpio_set_value(dssdev-reset_gpio, 1);
+
+ return 0;
+}
+
+static void beagle_disable_dvi(struct omap_dss_device *dssdev)
+{
+ if (gpio_is_valid(dssdev-reset_gpio))
+ gpio_set_value(dssdev-reset_gpio, 0);
+}
+
+static struct omap_dss_device beagle_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = dvi,
+ .driver_name = generic_panel,
+ .phy.dpi.data_lines = 24,
+ .reset_gpio = 170,
+ .platform_enable = beagle_enable_dvi,
+ .platform_disable = beagle_disable_dvi,
+};
+
+static struct omap_dss_device beagle_tv_device = {
+ .name = tv,
+ .driver_name = venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static struct omap_dss_device *beagle_dss_devices[] = {
+ beagle_dvi_device,
+ beagle_tv_device,
+};
+
+static struct omap_dss_board_info beagle_dss_data = {
+ .num_devices = ARRAY_SIZE(beagle_dss_devices),
+ .devices = beagle_dss_devices,
+ .default_device = beagle_dvi_device,
+};
+
+static struct platform_device beagle_dss_device = {
+ .name = omapdss,
+ .id= -1,
+ .dev= {
+ .platform_data = beagle_dss_data,
+ },
+};
+
+static struct regulator_consumer_supply beagle_vdac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omapdss);
+
+static struct regulator_consumer_supply beagle_vdvi_supply =
+ REGULATOR_SUPPLY(vdds_dsi, omapdss);
+
+static void __init beagle_display_init(void)
+{
+ int r;
+
+ r = gpio_request(beagle_dvi_device.reset_gpio, DVI reset);
+ if (r 0) {
+ printk(KERN_ERR Unable to get DVI reset GPIO\n);
+ return;
+ }
+
+ gpio_direction_output(beagle_dvi_device.reset_gpio, 0);
+}
+
#include sdram-micron-mt46h32m32lf-6.h
static struct omap2_hsmmc_info mmc[] = {
@@ -117,15 +189,6 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct platform_device omap3_beagle_lcd_device = {
- .name = omap3beagle_lcd,
- .id = -1,
-};
-
-static struct omap_lcd_config omap3_beagle_lcd_config __initdata = {
- .ctrl_name = internal,
-};
-
static struct regulator_consumer_supply beagle_vmmc1_supply = {
.supply = vmmc,
};
@@ -181,16 +244,6 @@ static struct twl4030_gpio_platform_data beagle_gpio_data
= {
.setup = beagle_twl_gpio_setup,
};
-static struct regulator_consumer_supply beagle_vdac_supply = {
- .supply = vdac,
- .dev= omap3_beagle_lcd_device.dev,
-};
-
-static struct regulator_consumer_supply beagle_vdvi_supply = {
- .supply = vdvi,
- .dev= omap3_beagle_lcd_device.dev,
-};
-
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data beagle_vmmc1 = {
.constraints = {
@@ -349,14 +402,8 @@ static struct platform_device keys_gpio = {
},
};
-static struct omap_board_config_kernel omap3_beagle_config[] __initdata = {
- { OMAP_TAG_LCD, omap3_beagle_lcd_config },
-};
-
static void __init omap3_beagle_init_irq(void)
{
- omap_board_config = omap3_beagle_config;
- omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
omap_init_irq();
@@ -367,9 +414,9 @@ static void __init omap3_beagle_init_irq(void)
}
static struct platform_device *omap3_beagle_devices[] __initdata = {
- omap3_beagle_lcd_device,
leds_gpio,
keys_gpio,
+ beagle_dss_device,
};
static void __init omap3beagle_flash_init(void)
@@ -456,6 +503,8 @@ static void __init omap3_beagle_init(void)
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
[PATCH 14/23] OMAP: DSS2: TPO-TD03MTEA1: fix Kconfig dependency
From: Grazvydas Ignotas nota...@gmail.com This panel depends on SPI, not I2C. Signed-off-by: Grazvydas Ignotas nota...@gmail.com Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- drivers/video/omap2/displays/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig index ea8ccd3..4221957 100644 --- a/drivers/video/omap2/displays/Kconfig +++ b/drivers/video/omap2/displays/Kconfig @@ -34,7 +34,7 @@ config PANEL_TOPPOLY_TDO35S config PANEL_TPO_TD043MTEA1 tristate TPO TD043MTEA1 LCD Panel -depends on OMAP2_DSS I2C +depends on OMAP2_DSS SPI help LCD Panel used in OMAP3 Pandora -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/23] OMAP: DSS2: Add ACX565AKM Panel Driver
From: Roger Quadros roger.quad...@nokia.com
This is the panel used on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-acx565akm.c | 819
3 files changed, 826 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-acx565akm.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 4221957..881c9f7 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -38,4 +38,10 @@ config PANEL_TPO_TD043MTEA1
help
LCD Panel used in OMAP3 Pandora
+config PANEL_ACX565AKM
+ tristate ACX565AKM Panel
+ depends on OMAP2_DSS_SDI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ This is the LCD panel used on Nokia N900
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index e2bb321..aa38609 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) +=
panel-sharp-lq043t1dg01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
+obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
new file mode 100644
index 000..1f8eb70
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -0,0 +1,819 @@
+/*
+ * Support for ACX565AKM LCD Panel used on Nokia N900
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * Original Driver Author: Imre Deak imre.d...@nokia.com
+ * Based on panel-generic.c by Tomi Valkeinen tomi.valkei...@nokia.com
+ * Adapted to new DSS2 framework: Roger Quadros roger.quad...@nokia.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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/jiffies.h
+#include linux/sched.h
+#include linux/backlight.h
+#include linux/fb.h
+
+#include plat/display.h
+
+#define MIPID_CMD_READ_DISP_ID 0x04
+#define MIPID_CMD_READ_RED 0x06
+#define MIPID_CMD_READ_GREEN 0x07
+#define MIPID_CMD_READ_BLUE0x08
+#define MIPID_CMD_READ_DISP_STATUS 0x09
+#define MIPID_CMD_RDDSDR 0x0F
+#define MIPID_CMD_SLEEP_IN 0x10
+#define MIPID_CMD_SLEEP_OUT0x11
+#define MIPID_CMD_DISP_OFF 0x28
+#define MIPID_CMD_DISP_ON 0x29
+#define MIPID_CMD_WRITE_DISP_BRIGHTNESS0x51
+#define MIPID_CMD_READ_DISP_BRIGHTNESS 0x52
+#define MIPID_CMD_WRITE_CTRL_DISP 0x53
+
+#define CTRL_DISP_BRIGHTNESS_CTRL_ON (1 5)
+#define CTRL_DISP_AMBIENT_LIGHT_CTRL_ON(1 4)
+#define CTRL_DISP_BACKLIGHT_ON (1 2)
+#define CTRL_DISP_AUTO_BRIGHTNESS_ON (1 1)
+
+#define MIPID_CMD_READ_CTRL_DISP 0x54
+#define MIPID_CMD_WRITE_CABC 0x55
+#define MIPID_CMD_READ_CABC0x56
+
+#define MIPID_VER_LPH8923 3
+#define MIPID_VER_LS041Y3 4
+#define MIPID_VER_L4F00311 8
+#define MIPID_VER_ACX565AKM9
+
+struct acx565akm_device {
+ char*name;
+ int enabled;
+ int model;
+ int revision;
+ u8 display_id[3];
+ unsignedhas_bc:1;
+ unsignedhas_cabc:1;
+ unsignedcabc_mode;
+ unsigned long hw_guard_end; /* next value of jiffies
+ when we can issue the
+ next sleep in/out command */
+ unsigned long hw_guard_wait; /* max guard time in jiffies */
+
+ struct spi_device *spi;
+ struct mutexmutex;
+
+ struct omap_dss_device *dssdev;
+ struct backlight_device *bl_dev;
+};
+
+static struct acx565akm_device acx_dev;
+static int acx565akm_bl_update_status(struct backlight_device *dev);
+
+/*MIPID
[PATCH 23/23] OMAP: DSS2: Fix omap_dss_probe() error path
From: Jani Nikula ext-jani.1.nik...@nokia.com
Perform graceful cleanup on errors instead of just bailing out.
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/core.c | 54 ++-
1 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 92ee067..b3a498f 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -507,7 +507,7 @@ static int omap_dss_probe(struct platform_device *pdev)
r = dss_get_clocks();
if (r)
- goto fail0;
+ goto err_clocks;
dss_clk_enable_all_no_ctx();
@@ -523,57 +523,64 @@ static int omap_dss_probe(struct platform_device *pdev)
r = dss_init(skip_init);
if (r) {
DSSERR(Failed to initialize DSS\n);
- goto fail0;
+ goto err_dss;
}
r = rfbi_init();
if (r) {
DSSERR(Failed to initialize rfbi\n);
- goto fail0;
+ goto err_rfbi;
}
r = dpi_init(pdev);
if (r) {
DSSERR(Failed to initialize dpi\n);
- goto fail0;
+ goto err_dpi;
}
r = dispc_init();
if (r) {
DSSERR(Failed to initialize dispc\n);
- goto fail0;
+ goto err_dispc;
}
r = venc_init(pdev);
if (r) {
DSSERR(Failed to initialize venc\n);
- goto fail0;
+ goto err_venc;
}
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
DSSERR(Failed to initialize SDI\n);
- goto fail0;
+ goto err_sdi;
}
r = dsi_init(pdev);
if (r) {
DSSERR(Failed to initialize DSI\n);
- goto fail0;
+ goto err_dsi;
}
}
r = dss_initialize_debugfs();
if (r)
- goto fail0;
+ goto err_debugfs;
for (i = 0; i pdata-num_devices; ++i) {
struct omap_dss_device *dssdev = pdata-devices[i];
r = omap_dss_register_device(dssdev);
- if (r)
- DSSERR(device reg failed %d\n, i);
+ if (r) {
+ DSSERR(device %d %s register failed %d\n, i,
+ dssdev-name ?: unnamed, r);
+
+ while (--i = 0)
+ omap_dss_unregister_device(pdata-devices[i]);
+
+ goto err_register;
+ }
if (def_disp_name strcmp(def_disp_name, dssdev-name) == 0)
pdata-default_device = dssdev;
@@ -583,8 +590,29 @@ static int omap_dss_probe(struct platform_device *pdev)
return 0;
- /* XXX fail correctly */
-fail0:
+err_register:
+ dss_uninitialize_debugfs();
+err_debugfs:
+ if (cpu_is_omap34xx())
+ dsi_exit();
+err_dsi:
+ if (cpu_is_omap34xx())
+ sdi_exit();
+err_sdi:
+ venc_exit();
+err_venc:
+ dispc_exit();
+err_dispc:
+ dpi_exit();
+err_dpi:
+ rfbi_exit();
+err_rfbi:
+ dss_exit();
+err_dss:
+ dss_clk_disable_all_no_ctx();
+ dss_put_clocks();
+err_clocks:
+
return r;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/23] OMAP: DSS2: omap_dss_probe() conditional compilation cleanup
From: Jani Nikula ext-jani.1.nik...@nokia.com
Move a number of #ifdefs from code into dss.h and elsewhere, and
conditionally define no-op static inline functions, cleaning up the
code. This style is according to Documentation/SubmittingPatches.
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/core.c | 35 ---
drivers/video/omap2/dss/dss.h | 50
2 files changed, 61 insertions(+), 24 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 6d54467..92ee067 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -482,6 +482,14 @@ static void dss_uninitialize_debugfs(void)
if (dss_debugfs_dir)
debugfs_remove_recursive(dss_debugfs_dir);
}
+#else /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
+static inline int dss_initialize_debugfs(void)
+{
+ return 0;
+}
+static inline void dss_uninitialize_debugfs(void)
+{
+}
#endif /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
/* PLATFORM DEVICE */
@@ -518,56 +526,47 @@ static int omap_dss_probe(struct platform_device *pdev)
goto fail0;
}
-#ifdef CONFIG_OMAP2_DSS_RFBI
r = rfbi_init();
if (r) {
DSSERR(Failed to initialize rfbi\n);
goto fail0;
}
-#endif
-#ifdef CONFIG_OMAP2_DSS_DPI
r = dpi_init(pdev);
if (r) {
DSSERR(Failed to initialize dpi\n);
goto fail0;
}
-#endif
r = dispc_init();
if (r) {
DSSERR(Failed to initialize dispc\n);
goto fail0;
}
-#ifdef CONFIG_OMAP2_DSS_VENC
+
r = venc_init(pdev);
if (r) {
DSSERR(Failed to initialize venc\n);
goto fail0;
}
-#endif
+
if (cpu_is_omap34xx()) {
-#ifdef CONFIG_OMAP2_DSS_SDI
r = sdi_init(skip_init);
if (r) {
DSSERR(Failed to initialize SDI\n);
goto fail0;
}
-#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
+
r = dsi_init(pdev);
if (r) {
DSSERR(Failed to initialize DSI\n);
goto fail0;
}
-#endif
}
-#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
r = dss_initialize_debugfs();
if (r)
goto fail0;
-#endif
for (i = 0; i pdata-num_devices; ++i) {
struct omap_dss_device *dssdev = pdata-devices[i];
@@ -595,27 +594,15 @@ static int omap_dss_remove(struct platform_device *pdev)
int i;
int c;
-#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
dss_uninitialize_debugfs();
-#endif
-#ifdef CONFIG_OMAP2_DSS_VENC
venc_exit();
-#endif
dispc_exit();
-#ifdef CONFIG_OMAP2_DSS_DPI
dpi_exit();
-#endif
-#ifdef CONFIG_OMAP2_DSS_RFBI
rfbi_exit();
-#endif
if (cpu_is_omap34xx()) {
-#ifdef CONFIG_OMAP2_DSS_DSI
dsi_exit();
-#endif
-#ifdef CONFIG_OMAP2_DSS_SDI
sdi_exit();
-#endif
}
dss_exit();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 24326a5..786f433 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -242,11 +242,22 @@ int dss_calc_clock_div(bool is_tft, unsigned long req_pck,
struct dispc_clock_info *dispc_cinfo);
/* SDI */
+#ifdef CONFIG_OMAP2_DSS_SDI
int sdi_init(bool skip_init);
void sdi_exit(void);
int sdi_init_display(struct omap_dss_device *display);
+#else
+static inline int sdi_init(bool skip_init)
+{
+ return 0;
+}
+static inline void sdi_exit(void)
+{
+}
+#endif
/* DSI */
+#ifdef CONFIG_OMAP2_DSS_DSI
int dsi_init(struct platform_device *pdev);
void dsi_exit(void);
@@ -270,11 +281,30 @@ void dsi_pll_uninit(void);
void dsi_get_overlay_fifo_thresholds(enum omap_plane plane,
u32 fifo_size, enum omap_burst_size *burst_size,
u32 *fifo_low, u32 *fifo_high);
+#else
+static inline int dsi_init(struct platform_device *pdev)
+{
+ return 0;
+}
+static inline void dsi_exit(void)
+{
+}
+#endif
/* DPI */
+#ifdef CONFIG_OMAP2_DSS_DPI
int dpi_init(struct platform_device *pdev);
void dpi_exit(void);
int dpi_init_display(struct omap_dss_device *dssdev);
+#else
+static inline int dpi_init(struct platform_device *pdev)
+{
+ return 0;
+}
+static inline void dpi_exit(void)
+{
+}
+#endif
/* DISPC */
int dispc_init(void);
@@ -362,12 +392,23 @@ int dispc_get_clock_div(struct dispc_clock_info *cinfo);
/* VENC */
+#ifdef CONFIG_OMAP2_DSS_VENC
int venc_init(struct platform_device *pdev);
void venc_exit(void);
void
Re: [PATCH 2/2] omap: rx51: Add supplies and data for the tpa6130a2 headphone amplifier
Hei Jarkko,
On Tue, May 18, 2010 at 01:06:01PM +0200, Jarkko Nikula wrote:
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
This is build and boot safe but required if wanting to add support for
headphones in upcoming sound/soc/omap/rx51.c.
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ead7ee1..2376ef7 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -33,6 +33,8 @@
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include sound/tpa6130a2-plat.h
+
#include mux.h
#include hsmmc.h
@@ -285,6 +287,9 @@ static struct regulator_consumer_supply
rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
REGULATOR_SUPPLY(AVDD, 2-0018),
REGULATOR_SUPPLY(DRVDD, 2-0018),
+ /* tpa6130a2 */
+ REGULATOR_SUPPLY(CPVSS, 2-0060),
Isn't CPVSS grounded? Well that wouldn't hurt to put it here, but it doesnt
belong to vmmc2 though.
+ REGULATOR_SUPPLY(Vdd, 2-0060),
/* Keep vmmc as last item. It is not iterated for newer boards */
REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
@@ -652,10 +657,19 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
},
};
+static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = {
+ .id = TPA6130A2,
+ .power_gpio = 98,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[]
= {
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
},
+ {
+ I2C_BOARD_INFO(tpa6130a2, 0x60),
+ .platform_data = rx51_tpa6130a2_data,
+ }
};
static int __init rx51_i2c_init(void)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
On Tue, May 18, 2010 at 3:24 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Cool. I actually tried your patches to render to the framebuffer, and everything seemed to work fine. I didn't check for error codes or anything, so I'm not sure what's going on. How is the framebuffer mmap'ed ? mmap(NULL, self-mem_info.size, PROT_WRITE, MAP_SHARED, self-overlay_fd, 0); Can you please tell me more about this scenario ? (applications + drivers involved). I use gst-omapfb[1], and then it's very easy with a gst-launch command Ok, thanks. I think I know why it worked for you - The framebuffer is mmap'ed as uncacheable on ARM (check out fb_pgprotect in fbmem.c), which makes the whole dspbridge cache manipulations on it redundant. In our case the cache operations silently failed, but it didn't matter. We can probably just return whenever a dspbridge DMA operation will be requested on VM_IO buffers (unless there are other VM_IO dspbrdige use cases which are different). -- 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 v2] musb: AM35x: Workaround for fifo read issue
Hello. Ajay Kumar Gupta wrote: AM35x supports only 32bit read operations so we need to have workaround for 8bit and 16bit read operations. But don't we need to override musb_readb() and musb_readw() then? Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: trivial: checkpatch cleanups to board files
- Fix space before tabs
- Add missing printk log level
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
Cleanup only - no functional changes
I can break up this into one patch per file if needed,
but I suppose that's unnecessary
arch/arm/mach-omap2/board-am3517evm.c|6 +++---
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-h4.c | 10 +-
arch/arm/mach-omap2/board-igep0020.c | 12 ++--
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
6 files changed, 17 insertions(+), 17 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/board-am3517evm.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
+++ linux-omap-2.6/arch/arm/mach-omap2/board-am3517evm.c
@@ -287,7 +287,7 @@ static struct omap_dss_device am3517_evm
.type = OMAP_DISPLAY_TYPE_DPI,
.name = lcd,
.driver_name= sharp_lq_panel,
- .phy.dpi.data_lines = 16,
+ .phy.dpi.data_lines = 16,
.platform_enable= am3517_evm_panel_enable_lcd,
.platform_disable = am3517_evm_panel_disable_lcd,
};
@@ -302,8 +302,8 @@ static void am3517_evm_panel_disable_tv(
}
static struct omap_dss_device am3517_evm_tv_device = {
- .type = OMAP_DISPLAY_TYPE_VENC,
- .name = tv,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = tv,
.driver_name= venc,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
.platform_enable= am3517_evm_panel_enable_tv,
Index: linux-omap-2.6/arch/arm/mach-omap2/board-apollon.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-apollon.c
+++ linux-omap-2.6/arch/arm/mach-omap2/board-apollon.c
@@ -326,7 +326,7 @@ static void __init omap_apollon_init(voi
omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
/*
-* Make sure the serial ports are muxed on at this point.
+* Make sure the serial ports are muxed on at this point.
* You have to mux them off in device drivers later on
* if not needed.
*/
Index: linux-omap-2.6/arch/arm/mach-omap2/board-h4.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-h4.c
+++ linux-omap-2.6/arch/arm/mach-omap2/board-h4.c
@@ -138,11 +138,11 @@ static struct platform_device h4_flash_d
static struct omap_kp_platform_data h4_kp_data = {
.rows = 6,
.cols = 7,
- .keymap = h4_keymap,
- .keymapsize = ARRAY_SIZE(h4_keymap),
+ .keymap = h4_keymap,
+ .keymapsize = ARRAY_SIZE(h4_keymap),
.rep= 1,
- .row_gpios = row_gpios,
- .col_gpios = col_gpios,
+ .row_gpios = row_gpios,
+ .col_gpios = col_gpios,
};
static struct platform_device h4_kp_device = {
@@ -260,7 +260,7 @@ static void __init h4_init_flash(void)
unsigned long base;
if (gpmc_cs_request(H4_FLASH_CS, SZ_64M, base) 0) {
- printk(Can't request GPMC CS for flash\n);
+ printk(KERN_ERR Can't request GPMC CS for flash\n);
return;
}
h4_flash_resource.start = base;
Index: linux-omap-2.6/arch/arm/mach-omap2/board-igep0020.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-igep0020.c
+++ linux-omap-2.6/arch/arm/mach-omap2/board-igep0020.c
@@ -38,12 +38,12 @@
#define IGEP2_SMSC911X_CS 5
#define IGEP2_SMSC911X_GPIO 176
#define IGEP2_GPIO_USBH_NRESET 24
-#define IGEP2_GPIO_LED0_GREEN 26
-#define IGEP2_GPIO_LED0_RED27
-#define IGEP2_GPIO_LED1_RED28
+#define IGEP2_GPIO_LED0_GREEN 26
+#define IGEP2_GPIO_LED0_RED27
+#define IGEP2_GPIO_LED1_RED28
#define IGEP2_GPIO_DVI_PUP 170
-#define IGEP2_GPIO_WIFI_NPD94
-#define IGEP2_GPIO_WIFI_NRESET 95
+#define IGEP2_GPIO_WIFI_NPD94
+#define IGEP2_GPIO_WIFI_NRESET 95
#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
@@ -518,7 +518,7 @@ static void __init igep2_init(void)
if ((gpio_request(IGEP2_GPIO_WIFI_NPD, GPIO_WIFI_NPD) == 0)
(gpio_direction_output(IGEP2_GPIO_WIFI_NPD, 1) == 0)) {
gpio_export(IGEP2_GPIO_WIFI_NPD, 0);
-/* gpio_set_value(IGEP2_GPIO_WIFI_NPD, 0); */
+/* gpio_set_value(IGEP2_GPIO_WIFI_NPD, 0); */
} else
pr_warning(IGEP v2: Could not obtain gpio GPIO_WIFI_NPD\n);
Index: linux-omap-2.6/arch/arm/mach-omap2/board-ldp.c
===
---
Re: [PATCH v2 00/17] omap: mailbox: reorganize init
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCH v2 00/17] omap: mailbox: reorganize init Date: Tue, 18 May 2010 14:03:26 +0200 On Tue, May 18, 2010 at 11:46 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Felipe Contreras felipe.contre...@gmail.com Subject: [PATCH v2 00/17] omap: mailbox: reorganize init Date: Fri, 14 May 2010 17:01:33 +0200 Hi, The main purpose of this patch series is to be able to compile mach platform data as built-in. Otherwise, client modules such as bridgedriver will load the platform code, but not the mach code when mailbox is built as a module. I think that this is the *udev* responsibility. The udev should take care of loading mailbox_mach.ko since the mailbox platform device was registered by devices.ko at bootup. devices.ko is built in earlier than dspbridge.ko, so the mailbox platform device is registered earlier than the dsp device, C6410. this registration ordering should take care of the dependency if the udevd works correctly. I'm not familiar with this kind of module loading, but certainly not all systems have udev. I realized the problem because I have a bare-bones system in my beagleboard where I had to manually load mailbox_mach. With udev or something equivalent, it should work fine. Unfortunately, there's no easy way to do that since plat and mach code are deepely interrelated. So the first patches try to separate the mailbox registering through a defined omap_mbox_platform_data. Also, it's worth noting that mailboxes are not a one-to-one mapping to resources; that is, some resources belong to multiple mboxes. So it's best to think of mailboxes as fake devices. That is why custom platform_data is required. Actually there were logical mailbox devices/instances implemented, but it was broken partially when dropping mailbox class support by accident(*1). This is the reason whey omap_mbox struct has unused dev pointer now. At that time, the sysfs interface was not necessary but the device creation itself should not have been removed. I'll get this code back again soon. The role of each modules were/should be: - devices.ko: a platform device, based on its resource. - mailbox_mach.ko: a platform driver to register multiple logical mboxes/devices. - mailbox.ko: a kind of framework which holds multiple logical mboxes/devices. The sysfs structure is like below: ~# tree -d -L 2 /sys/devices/platform/omap2-mailbox/ I don't see the point of having 'omap2' there, at best it should be 'omap-mailbox', or perhaps even just 'mailbox'. Sounds nice. The platform device omap2-mailbox accomodatess logical mboxes. Wouldn't it be better the way my patches handle them? * devices.ko: doesn't care about mbox * mach_omap1/mailbox.ko: registers omap-mailbox platform device with a list of logical mboxes for OMAP1 * mach_omap2/mailbox.ko: registers omap-mailbox platform device with a list of logical mboxes for OMAP2 * plat-omap/mailbox.ko: creates platform driver based on logical list of mboxes from platform device and handles the list internally The end result would be the exactly same, except that there's no hard dependency between the mach, and plat code. With the attachemnt, which is just 17 lines of code, you will get the structure of logical mbox devices, which are located under the single platform device, omap2-mailbox. This is more _descriptive_ since it displays the connection of a platform device and logical devices, IOW, where these logical ones come. I don't see any point of not using this struture. Finally, a bunch of cleaning up is done in the very first patches, specially for OMAP1. Most of the cleanups are quite ok. Would it be possible to rebase them on the top of my coming patch to get back logical device entry? Where is that? Attached. Would it be possible to rebase the cleanups on this one? Sorry for the late reply, it took some time to recall my bad memory... No worries. Cheers. -- Felipe Contreras From c7e5d7342c3d0b975601ae4a6b8bdbe77b4d6a5d Mon Sep 17 00:00:00 2001 From: Hiroshi DOYU hiroshi.d...@nokia.com Date: Tue, 18 May 2010 15:45:23 +0300 Subject: [PATCH 1/1] omap mailbox: Set a device in logical mbox instances for traceability With this patch, you'll get the following sysfs directories. This structure implies that a single platform device, omap2-mailbox holds multiple logical mbox instances. This could be the base to add sysfs files for each logical mboxes. Then userland application can access a mbox through sysfs entries if necessary(ex: setting kfifo size dynamically) ~# tree -d -L 2 /sys/devices/platform/omap2-mailbox/ /sys/devices/platform/omap2-mailbox/ |-- driver - ../../../bus/platform/drivers/omap2-mailbox |-- mbox | |-- dsp - they are each instances of logical mailbox. | |-- ducati | |-- iva2 | |-- mbox01 | |-- mbox02 | |-- mbox03 | |--
Re: [PATCH 14/18] omap: Overo: Add support for second ethernet port
On Wed, May 5, 2010 at 12:33 PM, Tony Lindgren t...@atomide.com wrote:
From: Steve Sakoman st...@sakoman.com
Some Overo add-on boards include a second ethernet port. This patch
adds support for that second port.
Signed-off-by: Steve Sakoman st...@sakoman.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-overo.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 8848c7c..79ac414 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -63,6 +63,8 @@
#define OVERO_SMSC911X_CS 5
#define OVERO_SMSC911X_GPIO 176
+#define OVERO_SMSC911X2_CS 4
+#define OVERO_SMSC911X2_GPIO 65
#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
@@ -137,6 +139,16 @@ static struct resource overo_smsc911x_resources[] = {
},
};
+static struct resource overo_smsc911x2_resources[] = {
+ {
+ .name = smsc911x2-memory,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
static struct smsc911x_platform_config overo_smsc911x_config = {
.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
.irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
@@ -146,7 +158,7 @@ static struct smsc911x_platform_config
overo_smsc911x_config = {
static struct platform_device overo_smsc911x_device = {
.name = smsc911x,
- .id = -1,
+ .id = 0,
.num_resources = ARRAY_SIZE(overo_smsc911x_resources),
.resource = overo_smsc911x_resources,
.dev = {
--
I just noticed that somehow a good portion of my original patch got
dropped in this version!
Original:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26350.html
How would you like to handle getting the missing chuncks?
Steve
--
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 v2] musb: AM35x: Workaround for fifo read issue
Hi AM35x supports only 32bit read operations so we need to have workaround for 8bit and 16bit read operations. But don't we need to override musb_readb() and musb_readw() then? Yes, Correct. I do have another patch on that which I will cleanup and submit later. Anyways with currebt three patch set, basic Host and device operation has been tested. -Ajay Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com WBR, Sergei -- 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 PATCHv2 2/7] OMAP SSI: Introducing OMAP SSI driver
On Tuesday 18 May 2010 11:07:20 Carlos Chinea wrote: [cut] + val |= __raw_readl(omap_ssi-sys + SSI_MPU_ENABLE_REG(port-num, 0)); + __raw_writel(val, omap_ssi-sys + SSI_MPU_ENABLE_REG(port-num, 0)); + + msg-status = HSI_STATUS_COMPLETED; + msg-actual_len = sg_dma_len(msg-sgt.sgl); + spin_unlock(omap_ssi-lock); +} Don't you need to check the queue related to this transfer at this point, to start the potentially next queued transfer on the same channel? (calling ssi_start_transfer(), like in ssi_pio_complete()?) No this is done in ssi_pio_complete(). Notice that we do not call the complete callback at any point here. We just arm the pio interrupt for that channel and transfer direction. AFAIK, this is the SW logic expected by the OMAP SSI HW. Ok, though I would not expect the interrupt to fire in an Rx scenario as the fifo would have already been emptied by the DMA for this transfer (unless you rely on the next transfer initiated by the peer to make the Rx interrupt fire on this channel?)? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/11] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/gpio.c | 113
1 files changed, 113 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..bc339ef
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,113 @@
+/*
+ * gpio.c - OMAP2PLUS-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@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/gpio.h
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int omap2_init_gpio(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ struct omap_gpio_platform_data *pdata;
+ char *name = omap-gpio;
+ static int id;
+ struct omap_gpio_dev_attr *gpio_dev_data;
+
+ if (!oh)
+ pr_err(Could not look up omap gpio %d\n, id + 1);
+
+ pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ pr_err(Memory allocation failed gpio%d\n, id + 1);
+ return -ENOMEM;
+ }
+
+ gpio_dev_data = (struct omap_gpio_dev_attr *)oh-dev_attr;
+ pdata-gpio_attr = gpio_dev_data;
+ pdata-method = (int)user;
+ pdata-virtual_irq_start = IH_GPIO_BASE + 32 * id;
+
+ od = omap_device_build(name, id, oh, pdata,
+ sizeof(*pdata), omap_gpio_latency,
+ ARRAY_SIZE(omap_gpio_latency),
+ false);
+ WARN(IS_ERR(od), Cant build omap_device for %s:%s.\n,
+ name, oh-name);
+
+ id++;
+ return 0;
+}
+
+static int __init gpio_init(int method)
+{
+ return omap_hwmod_for_each_by_class(gpio, omap2_init_gpio,
+ (void *)method);
+}
+
+/*
+ * gpio_init needs to be done before
+ * machine_init functions access gpio APIs.
+ * Hence gpio_init is a postcore_initcall.
+ */
+#ifdef CONFIG_ARCH_OMAP2
+static int __init omap242x_gpio_init(void)
+{ if (!cpu_is_omap2420())
+ return -EINVAL;
+
+ return gpio_init(METHOD_GPIO_24XX);
+}
+postcore_initcall(omap242x_gpio_init);
+
+static int __init omap243x_gpio_init(void)
+{
+ if (!cpu_is_omap2430())
+ return -EINVAL;
+
+ return gpio_init(METHOD_GPIO_24XX);
+}
+postcore_initcall(omap243x_gpio_init);
+#endif
+
+#ifdef CONFIG_ARCH_OMAP3
+static int __init omap3xxx_gpio_init(void)
+{
+ if (!cpu_is_omap34xx())
+ return -EINVAL;
+
+ return gpio_init(METHOD_GPIO_24XX);
+}
+postcore_initcall(omap3xxx_gpio_init);
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+static int __init omap44xx_gpio_init(void)
+{
+ if (!cpu_is_omap44xx())
+ return -EINVAL;
+
+ return gpio_init(METHOD_GPIO_44XX);
+}
+postcore_initcall(omap44xx_gpio_init);
+#endif
--
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 06/11] OMAP: GPIO: add GPIO hwmods structures for OMAP3
Add hwmod structures for GPIO module on OMAP3
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 357 +++-
1 files changed, 356 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5f74c34..499be79 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -20,6 +20,7 @@
#include plat/serial.h
#include plat/l4_3xxx.h
#include plat/mmc.h
+#include plat/gpio.h
#include omap_hwmod_common_data.h
@@ -89,6 +90,12 @@ static struct omap_hwmod omap3xxx_uart3_hwmod;
static struct omap_hwmod omap3xxx_mmc1_hwmod;
static struct omap_hwmod omap3xxx_mmc2_hwmod;
static struct omap_hwmod omap3xxx_mmc3_hwmod;
+static struct omap_hwmod omap3xxx_gpio1_hwmod;
+static struct omap_hwmod omap3xxx_gpio2_hwmod;
+static struct omap_hwmod omap3xxx_gpio3_hwmod;
+static struct omap_hwmod omap3xxx_gpio4_hwmod;
+static struct omap_hwmod omap3xxx_gpio5_hwmod;
+static struct omap_hwmod omap3xxx_gpio6_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
@@ -226,6 +233,114 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmc3 = {
.flags = OMAP_FIREWALL_L4
};
+/* L4 WKUP - GPIO1 interface */
+static struct omap_hwmod_addr_space omap3xxx_gpio1_addr_space[] = {
+ {
+ .pa_start = OMAP34XX_GPIO1_BASE,
+ .pa_end = OMAP34XX_GPIO1_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__gpio1 = {
+ .master = omap3xxx_l4_wkup_hwmod,
+ .slave = omap3xxx_gpio1_hwmod,
+ .clk= gpio1_ick,
+ .addr = omap3xxx_gpio1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO2 interface */
+static struct omap_hwmod_addr_space omap3xxx_gpio2_addr_space[] = {
+ {
+ .pa_start = OMAP34XX_GPIO2_BASE,
+ .pa_end = OMAP34XX_GPIO2_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio2 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio2_hwmod,
+ .clk= gpio2_ick,
+ .addr = omap3xxx_gpio2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO3 interface */
+static struct omap_hwmod_addr_space omap3xxx_gpio3_addr_space[] = {
+ {
+ .pa_start = OMAP34XX_GPIO3_BASE,
+ .pa_end = OMAP34XX_GPIO3_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio3_hwmod,
+ .clk= gpio3_ick,
+ .addr = omap3xxx_gpio3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO4 interface */
+static struct omap_hwmod_addr_space omap3xxx_gpio4_addr_space[] = {
+ {
+ .pa_start = OMAP34XX_GPIO4_BASE,
+ .pa_end = OMAP34XX_GPIO4_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio4 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio4_hwmod,
+ .clk= gpio4_ick,
+ .addr = omap3xxx_gpio4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO5 interface */
+static struct omap_hwmod_addr_space omap3xxx_gpio5_addr_space[] = {
+ {
+ .pa_start = OMAP34XX_GPIO5_BASE,
+ .pa_end = OMAP34XX_GPIO5_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio5 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio5_hwmod,
+ .clk= gpio5_ick,
+ .addr = omap3xxx_gpio5_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio5_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO6 interface */
+static struct omap_hwmod_addr_space omap3xxx_gpio6_addr_space[] = {
+ {
+ .pa_start = OMAP34XX_GPIO6_BASE,
+ .pa_end = OMAP34XX_GPIO6_BASE + SZ_4K - 1,
+ .flags =
[PATCH 07/11] OMAP: GPIO: add GPIO hwmods structures for OMAP242X
Add hwmod structures for GPIO module on OMAP242X
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 222
1 files changed, 222 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index eb7ee24..4d05a9a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/gpio.h
#include omap_hwmod_common_data.h
@@ -32,6 +33,10 @@
static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_l3_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_gpio1_hwmod;
+static struct omap_hwmod omap2420_gpio2_hwmod;
+static struct omap_hwmod omap2420_gpio3_hwmod;
+static struct omap_hwmod omap2420_gpio4_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3__l4_core = {
@@ -87,6 +92,78 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[]
= {
omap2420_l4_core__l4_wkup,
};
+/* L4 WKUP - GPIO1 interface */
+static struct omap_hwmod_addr_space omap2420_gpio1_addr_space[] = {
+ {
+ .pa_start = OMAP242X_GPIO1_BASE,
+ .pa_end = OMAP242X_GPIO1_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio1 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_gpio1_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2420_gpio1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO2 interface */
+static struct omap_hwmod_addr_space omap2420_gpio2_addr_space[] = {
+ {
+ .pa_start = OMAP242X_GPIO2_BASE,
+ .pa_end = OMAP242X_GPIO2_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio2 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_gpio2_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2420_gpio2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO3 interface */
+static struct omap_hwmod_addr_space omap2420_gpio3_addr_space[] = {
+ {
+ .pa_start = OMAP242X_GPIO3_BASE,
+ .pa_end = OMAP242X_GPIO3_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio3 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_gpio3_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2420_gpio3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO4 interface */
+static struct omap_hwmod_addr_space omap2420_gpio4_addr_space[] = {
+ {
+ .pa_start = OMAP242X_GPIO4_BASE,
+ .pa_end = OMAP242X_GPIO4_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio4 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_gpio4_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2420_gpio4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* L4 CORE */
static struct omap_hwmod omap2420_l4_core_hwmod = {
.name = l4_core_hwmod,
@@ -101,6 +178,10 @@ static struct omap_hwmod omap2420_l4_core_hwmod = {
/* Slave interfaces on the L4_WKUP interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_wkup_slaves[] = {
omap2420_l4_core__l4_wkup,
+ omap2420_l4_wkup__gpio1,
+ omap2420_l4_wkup__gpio2,
+ omap2420_l4_wkup__gpio3,
+ omap2420_l4_wkup__gpio4,
};
/* Master interfaces on the L4_WKUP interconnect */
@@ -133,11 +214,152 @@ static struct omap_hwmod omap2420_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/* GPIO common */
+
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .gpio_bank_count = 4,
+ .gpio_bank_bits = 32,
+ .dbck_flag = false,
+ .fck_flag = true,
+};
+
+static struct omap_hwmod_class_sysconfig gpio_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+
[PATCH 02/11] OMAP: GPIO: Include platform_data structure for GPIO
This patch introduces platform_data structure for GPIO
so that GPIO module can be implemented in platform device model.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/plat-omap/include/plat/gpio.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index a06acb6..d2d310b 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -28,6 +28,7 @@
#include linux/io.h
#include mach/irqs.h
+#include linux/platform_device.h
#define OMAP1_MPUIO_BASE 0xfffb5000
#define OMAP1_MPUIO_VBASE OMAP1_MPUIO_BASE
@@ -137,6 +138,20 @@
IH_MPUIO_BASE + ((nr) 0x0f) : \
IH_GPIO_BASE + (nr))
+struct omap_gpio_dev_attr {
+ int gpio_bank_count;
+ int gpio_bank_bits;
+ bool dbck_flag;
+ bool fck_flag;
+ bool arm_gpio_ck_flag;
+};
+
+struct omap_gpio_platform_data {
+ u16 virtual_irq_start;
+ int method;
+ struct omap_gpio_dev_attr *gpio_attr;
+};
+
extern int omap_gpio_init(void); /* Call from board init only */
extern void omap2_gpio_prepare_for_retention(void);
extern void omap2_gpio_resume_after_retention(void);
--
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 00/11] OMAP: GPIO: Implement GPIO in HWMOD way
This patch series implements GPIO module in platform device model. It also makes OMAP2PLUS specific GPIO implemented in HWMOD FW way. This patch series is created on origin/pm-wip/runtime. This patch series is tested on OMAP3430 SDP board. It would be of great help if someone could test the same on OMAP1 and OMAP2 boards. Charulatha V (11): OMAP: GPIO: Modify init() in preparation for platform device implementation OMAP: GPIO: Include platform_data structure for GPIO OMAP: GPIO: Introduce support for OMAP15xx chip GPIO init OMAP: GPIO: Introduce support for OMAP16xx chip GPIO init OMAP: GPIO: Introduce support for OMAP7xx chip GPIO init OMAP: GPIO: add GPIO hwmods structures for OMAP3 OMAP: GPIO: add GPIO hwmods structures for OMAP242X OMAP: GPIO: add GPIO hwmods structures for OMAP243X OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init OMAP: GPIO: Implement GPIO as a platform device OMAP: GPIO: Remove omap_gpio_init() arch/arm/mach-omap1/Makefile |6 + arch/arm/mach-omap1/board-ams-delta.c |1 - arch/arm/mach-omap1/board-fsample.c|1 - arch/arm/mach-omap1/board-h2.c |1 - arch/arm/mach-omap1/board-h3.c |1 - arch/arm/mach-omap1/board-htcherald.c |1 - arch/arm/mach-omap1/board-innovator.c |1 - arch/arm/mach-omap1/board-nokia770.c |1 - arch/arm/mach-omap1/board-osk.c|1 - arch/arm/mach-omap1/board-palmte.c |1 - arch/arm/mach-omap1/board-palmz71.c|1 - arch/arm/mach-omap1/board-perseus2.c |1 - arch/arm/mach-omap1/board-sx1.c|1 - arch/arm/mach-omap1/board-voiceblue.c |1 - arch/arm/mach-omap1/clock_data.c |2 +- arch/arm/mach-omap1/gpio15xx.c | 104 + arch/arm/mach-omap1/gpio16xx.c | 202 + arch/arm/mach-omap1/gpio7xx.c | 266 arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/board-2430sdp.c|1 - arch/arm/mach-omap2/board-3430sdp.c|1 - arch/arm/mach-omap2/board-3630sdp.c|1 - arch/arm/mach-omap2/board-4430sdp.c|1 - arch/arm/mach-omap2/board-am3517evm.c |1 - arch/arm/mach-omap2/board-apollon.c|1 - arch/arm/mach-omap2/board-cm-t35.c |1 - arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-h4.c |1 - arch/arm/mach-omap2/board-igep0020.c |1 - arch/arm/mach-omap2/board-ldp.c|1 - arch/arm/mach-omap2/board-n8x0.c |1 - arch/arm/mach-omap2/board-omap3beagle.c|1 - arch/arm/mach-omap2/board-omap3evm.c |1 - arch/arm/mach-omap2/board-omap3pandora.c |1 - arch/arm/mach-omap2/board-omap3touchbook.c |1 - arch/arm/mach-omap2/board-overo.c |1 - arch/arm/mach-omap2/board-rx51.c |1 - arch/arm/mach-omap2/board-zoom2.c |1 - arch/arm/mach-omap2/board-zoom3.c |1 - arch/arm/mach-omap2/clock2420_data.c | 10 +- arch/arm/mach-omap2/clock2430_data.c | 14 +- arch/arm/mach-omap2/clock3xxx_data.c | 24 +- arch/arm/mach-omap2/clock44xx_data.c | 24 +- arch/arm/mach-omap2/gpio.c | 113 + arch/arm/mach-omap2/omap_hwmod_2420_data.c | 222 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 270 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 357 - arch/arm/plat-omap/gpio.c | 622 ++-- arch/arm/plat-omap/include/plat/gpio.h | 84 - 49 files changed, 1886 insertions(+), 469 deletions(-) create mode 100644 arch/arm/mach-omap1/gpio15xx.c create mode 100644 arch/arm/mach-omap1/gpio16xx.c create mode 100644 arch/arm/mach-omap1/gpio7xx.c create mode 100644 arch/arm/mach-omap2/gpio.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] OMAP: GPIO: Introduce support for OMAP15xx chip GPIO init
This patch adds support for handling OMAP15xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c | 99
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/gpio15xx.c
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
new file mode 100644
index 000..c9082bd
--- /dev/null
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -0,0 +1,99 @@
+/*
+ * gpio15xx.c - OMAP15XX-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@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/gpio.h
+
+static struct omap_gpio_dev_attr omap15xx_gpio_attr = {
+ .gpio_bank_count= 2,
+ .gpio_bank_bits = 16,
+ .arm_gpio_ck_flag = true,
+};
+
+/*
+ * OMAP15XX GPIO1 interface data
+ */
+static struct __initdata resource omap15xx_mpu_gpio_resources[] = {
+ {
+ .start = OMAP1_MPUIO_VBASE,
+ .end= OMAP1_MPUIO_VBASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_MPUIO,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap15xx_mpu_gpio_config = {
+ .virtual_irq_start = IH_MPUIO_BASE,
+ .method = METHOD_MPUIO,
+ .gpio_attr = omap15xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap15xx_mpu_gpio = {
+ .name = omap-gpio,
+ .id = 0,
+ .dev= {
+ .platform_data = omap15xx_mpu_gpio_config,
+ },
+ .num_resources = ARRAY_SIZE(omap15xx_mpu_gpio_resources),
+ .resource = omap15xx_mpu_gpio_resources,
+};
+
+/*
+ * OMAP15XX GPIO2 interface data
+ */
+static struct __initdata resource omap15xx_gpio_resources[] = {
+ {
+ .start = OMAP1510_GPIO_BASE,
+ .end= OMAP1510_GPIO_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_GPIO_BANK1,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
+ .virtual_irq_start = IH_GPIO_BASE,
+ .method = METHOD_GPIO_1510,
+ .gpio_attr = omap15xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap15xx_gpio = {
+ .name = omap-gpio,
+ .id = 1,
+ .dev= {
+ .platform_data = omap15xx_gpio_config,
+ },
+ .num_resources = ARRAY_SIZE(omap15xx_gpio_resources),
+ .resource = omap15xx_gpio_resources,
+};
+
+/*
+ * omap15xx_gpio_init needs to be done before
+ * machine_init functions access gpio APIs.
+ * Hence omap15xx_gpio_init is a postcore_initcall.
+ */
+static int __init omap15xx_gpio_init(void)
+{
+ if (!cpu_is_omap15xx())
+ return -EINVAL;
+
+ platform_device_register(omap15xx_mpu_gpio);
+ platform_device_register(omap15xx_gpio);
+
+ return 0;
+}
+postcore_initcall(omap15xx_gpio_init);
--
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/11] OMAP: GPIO: Implement GPIO as a platform device
This patch implements GPIO as a platform device. Also it
implements OMAP2PLUS specific GPIO as HWMOD FW adapted device.
GPIO APIs are used in machine_init functions. Hence it is
required to complete GPIO probe before machine_init. Therefore
GPIO device register and driver register are implemented as
postcore_initcalls.
Inorder to convert GPIO as platform device, modifications are
required in clock_data.c files so that device names can be
used to obtain clock instead of getting clocks by name/NULL ptr.
GPIO driver uses runtime APIs.Clock FW APIs are used to enable
iclk and fclk when CONFIG_PM_RUNTIME is not defined.
omap_gpio_init() does nothing now and this function would be
removed in the next patch as it's usage is spread across most of
the board files.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap1/Makefile |6 +
arch/arm/mach-omap1/clock_data.c |2 +-
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/clock2420_data.c | 10 +-
arch/arm/mach-omap2/clock2430_data.c | 14 +-
arch/arm/mach-omap2/clock3xxx_data.c | 24 +-
arch/arm/mach-omap2/clock44xx_data.c | 24 +-
arch/arm/plat-omap/gpio.c| 389 +++---
8 files changed, 178 insertions(+), 293 deletions(-)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index b6a537c..dabd2be 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -45,6 +45,12 @@ ifeq ($(CONFIG_ARCH_OMAP15XX),y)
obj-$(CONFIG_MACH_OMAP_INNOVATOR) += fpga.o
endif
+# GPIO
+obj-$(CONFIG_ARCH_OMAP730) += gpio7xx.o
+obj-$(CONFIG_ARCH_OMAP850) += gpio7xx.o
+obj-$(CONFIG_ARCH_OMAP15XX)+= gpio15xx.o
+obj-$(CONFIG_ARCH_OMAP16XX)+= gpio16xx.o
+
# LEDs support
led-$(CONFIG_MACH_OMAP_H2) += leds-h2p2-debug.o
led-$(CONFIG_MACH_OMAP_H3) += leds-h2p2-debug.o
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index aa8558a..9bc2aa1 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -589,7 +589,7 @@ static struct omap_clk omap_clks[] = {
CLK(NULL, ck_sossi, sossi_ck, CK_16XX),
CLK(NULL, arm_ck, arm_ck,CK_16XX | CK_1510 |
CK_310),
CLK(NULL, armper_ck,armper_ck.clk, CK_16XX | CK_1510 |
CK_310),
- CLK(NULL, arm_gpio_ck, arm_gpio_ck, CK_1510 | CK_310),
+ CLK(omap-gpio.0, arm_gpio_ck, arm_gpio_ck, CK_1510 | CK_310),
CLK(NULL, armxor_ck,armxor_ck.clk, CK_16XX | CK_1510 |
CK_310 | CK_7XX),
CLK(NULL, armtim_ck,armtim_ck.clk, CK_16XX | CK_1510 |
CK_310),
CLK(omap_wdt, fck, armwdt_ck.clk, CK_16XX | CK_1510 |
CK_310),
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 58a0474..d2d63ca 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
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o gpio.o
omap-2-3-common= irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index d932b14..a693403 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1802,8 +1802,14 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, uart2_fck,uart2_fck, CK_242X),
CLK(NULL, uart3_ick,uart3_ick, CK_242X),
CLK(NULL, uart3_fck,uart3_fck, CK_242X),
- CLK(NULL, gpios_ick,gpios_ick, CK_242X),
- CLK(NULL, gpios_fck,gpios_fck, CK_242X),
+ CLK(omap-gpio.0, ick, gpios_ick, CK_242X),
+ CLK(omap-gpio.1, ick, gpios_ick, CK_242X),
+ CLK(omap-gpio.2, ick, gpios_ick, CK_242X),
+ CLK(omap-gpio.3, ick, gpios_ick, CK_242X),
+ CLK(omap-gpio.0, fck, gpios_fck, CK_242X),
+ CLK(omap-gpio.1, fck, gpios_fck, CK_242X),
+ CLK(omap-gpio.2, fck, gpios_fck, CK_242X),
+ CLK(omap-gpio.3, fck, gpios_fck, CK_242X),
CLK(omap_wdt, ick, mpu_wdt_ick, CK_242X),
CLK(omap_wdt, fck, mpu_wdt_fck, CK_242X),
CLK(NULL, sync_32k_ick, sync_32k_ick, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 0438b6e..56bbcbc 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1896,8 +1896,14 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, uart2_fck,uart2_fck, CK_243X),
CLK(NULL, uart3_ick,uart3_ick,
[PATCH 05/11] OMAP: GPIO: Introduce support for OMAP7xx chip GPIO init
This patch adds support for handling OMAP7xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap1/gpio7xx.c | 266 +
1 files changed, 266 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/gpio7xx.c
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
new file mode 100644
index 000..56a482c
--- /dev/null
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -0,0 +1,266 @@
+/*
+ * gpio7xx.c - OMAP7XX-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@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/gpio.h
+
+static struct omap_gpio_dev_attr omap7xx_gpio_attr = {
+ .gpio_bank_count= 7,
+ .gpio_bank_bits = 32,
+ .arm_gpio_ck_flag = false,
+};
+
+/*
+ * OMAP7XX MPU GPIO interface data
+ */
+static struct __initdata resource omap7xx_mpu_gpio_resources[] = {
+ {
+ .start = OMAP1_MPUIO_VBASE,
+ .end= OMAP1_MPUIO_VBASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_7XX_MPUIO,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
+ .virtual_irq_start = IH_MPUIO_BASE,
+ .method = METHOD_MPUIO,
+ .gpio_attr = omap7xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap7xx_mpu_gpio = {
+ .name = omap-gpio,
+ .id = 0,
+ .dev= {
+ .platform_data = omap7xx_mpu_gpio_config,
+ },
+ .num_resources = ARRAY_SIZE(omap7xx_mpu_gpio_resources),
+ .resource = omap7xx_mpu_gpio_resources,
+};
+
+/*
+ * OMAP7XX GPIO1 interface data
+ */
+static struct __initdata resource omap7xx_gpio1_resources[] = {
+ {
+ .start = OMAP7XX_GPIO1_BASE,
+ .end= OMAP7XX_GPIO1_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_7XX_GPIO_BANK1,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
+ .virtual_irq_start = IH_GPIO_BASE,
+ .method = METHOD_GPIO_7XX,
+ .gpio_attr = omap7xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap7xx_gpio1 = {
+ .name = omap-gpio,
+ .id = 1,
+ .dev= {
+ .platform_data = omap7xx_gpio1_config,
+ },
+ .num_resources = ARRAY_SIZE(omap7xx_gpio1_resources),
+ .resource = omap7xx_gpio1_resources,
+};
+
+/*
+ * OMAP7XX GPIO2 interface data
+ */
+static struct __initdata resource omap7xx_gpio2_resources[] = {
+ {
+ .start = OMAP7XX_GPIO2_BASE,
+ .end= OMAP7XX_GPIO2_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_7XX_GPIO_BANK2,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap7xx_gpio2_config = {
+ .virtual_irq_start = IH_GPIO_BASE + 32,
+ .method = METHOD_GPIO_7XX,
+ .gpio_attr = omap7xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap7xx_gpio2 = {
+ .name = omap-gpio,
+ .id = 2,
+ .dev= {
+ .platform_data = omap7xx_gpio2_config,
+ },
+ .num_resources = ARRAY_SIZE(omap7xx_gpio2_resources),
+ .resource = omap7xx_gpio2_resources,
+};
+
+/*
+ * OMAP7XX GPIO3 interface data
+ */
+static struct __initdata resource omap7xx_gpio3_resources[] = {
+ {
+ .start = OMAP7XX_GPIO3_BASE,
+ .end= OMAP7XX_GPIO3_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_7XX_GPIO_BANK3,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap7xx_gpio3_config = {
+ .virtual_irq_start = IH_GPIO_BASE + 64,
+ .method = METHOD_GPIO_7XX,
+ .gpio_attr = omap7xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap7xx_gpio3 = {
+ .name = omap-gpio,
+ .id = 3,
+ .dev= {
+ .platform_data = omap7xx_gpio3_config,
+ },
+ .num_resources = ARRAY_SIZE(omap7xx_gpio3_resources),
+ .resource = omap7xx_gpio3_resources,
+};
+
+/*
+ * OMAP7XX GPIO4 interface data
+ */
+static struct
[PATCH 08/11] OMAP: GPIO: add GPIO hwmods structures for OMAP243X
Add hwmod structures for GPIO module on OMAP243X
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 270
1 files changed, 270 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index d9c92aa..57a7d80 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -16,6 +16,7 @@
#include plat/cpu.h
#include plat/dma.h
#include plat/mmc.h
+#include plat/gpio.h
#include omap_hwmod_common_data.h
@@ -73,6 +74,11 @@ static struct omap_hwmod omap2430_l3_hwmod = {
static struct omap_hwmod omap2430_l4_wkup_hwmod;
static struct omap_hwmod omap2430_mmc1_hwmod;
static struct omap_hwmod omap2430_mmc2_hwmod;
+static struct omap_hwmod omap2430_gpio1_hwmod;
+static struct omap_hwmod omap2430_gpio2_hwmod;
+static struct omap_hwmod omap2430_gpio3_hwmod;
+static struct omap_hwmod omap2430_gpio4_hwmod;
+static struct omap_hwmod omap2430_gpio5_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2430_l4_core__l4_wkup = {
@@ -117,10 +123,100 @@ static struct omap_hwmod_ocp_if omap2430_l4_core__mmc2 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L4 WKUP - GPIO1 interface */
+static struct omap_hwmod_addr_space omap2430_gpio1_addr_space[] = {
+ {
+ .pa_start = OMAP243X_GPIO1_BASE,
+ .pa_end = OMAP243X_GPIO1_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio1 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_gpio1_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2430_gpio1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO2 interface */
+static struct omap_hwmod_addr_space omap2430_gpio2_addr_space[] = {
+ {
+ .pa_start = OMAP243X_GPIO2_BASE,
+ .pa_end = OMAP243X_GPIO2_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio2 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_gpio2_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2430_gpio2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO3 interface */
+static struct omap_hwmod_addr_space omap2430_gpio3_addr_space[] = {
+ {
+ .pa_start = OMAP243X_GPIO3_BASE,
+ .pa_end = OMAP243X_GPIO3_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio3 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_gpio3_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2430_gpio3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO4 interface */
+static struct omap_hwmod_addr_space omap2430_gpio4_addr_space[] = {
+ {
+ .pa_start = OMAP243X_GPIO4_BASE,
+ .pa_end = OMAP243X_GPIO4_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio4 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_gpio4_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2430_gpio4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - GPIO5 interface */
+static struct omap_hwmod_addr_space omap2430_gpio5_addr_space[] = {
+ {
+ .pa_start = OMAP243X_GPIO5_BASE,
+ .pa_end = OMAP243X_GPIO5_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__gpio5 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_gpio5_hwmod,
+ .clk= gpio5_ick,
+ .addr = omap2430_gpio5_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio5_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2430_l4_core_slaves[] = {
omap2430_l3__l4_core,
+ omap2430_l4_core__gpio5,
};
/* Master interfaces on the L4_CORE interconnect */
@@ -144,6 +240,10 @@ static struct omap_hwmod omap2430_l4_core_hwmod = {
/* Slave interfaces
[PATCH 11/11] OMAP: GPIO: Remove omap_gpio_init()
This patch removes the usage of omap_gpio_init() in from all
omap board files since omap_gpio_init() does nothing, after gpio
is implemented as a platform device.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap1/board-ams-delta.c |1 -
arch/arm/mach-omap1/board-fsample.c|1 -
arch/arm/mach-omap1/board-h2.c |1 -
arch/arm/mach-omap1/board-h3.c |1 -
arch/arm/mach-omap1/board-htcherald.c |1 -
arch/arm/mach-omap1/board-innovator.c |1 -
arch/arm/mach-omap1/board-nokia770.c |1 -
arch/arm/mach-omap1/board-osk.c|1 -
arch/arm/mach-omap1/board-palmte.c |1 -
arch/arm/mach-omap1/board-palmz71.c|1 -
arch/arm/mach-omap1/board-perseus2.c |1 -
arch/arm/mach-omap1/board-sx1.c|1 -
arch/arm/mach-omap1/board-voiceblue.c |1 -
arch/arm/mach-omap2/board-2430sdp.c|1 -
arch/arm/mach-omap2/board-3430sdp.c|1 -
arch/arm/mach-omap2/board-3630sdp.c|1 -
arch/arm/mach-omap2/board-4430sdp.c|1 -
arch/arm/mach-omap2/board-am3517evm.c |1 -
arch/arm/mach-omap2/board-apollon.c|1 -
arch/arm/mach-omap2/board-cm-t35.c |1 -
arch/arm/mach-omap2/board-devkit8000.c |1 -
arch/arm/mach-omap2/board-h4.c |1 -
arch/arm/mach-omap2/board-igep0020.c |1 -
arch/arm/mach-omap2/board-ldp.c|1 -
arch/arm/mach-omap2/board-n8x0.c |1 -
arch/arm/mach-omap2/board-omap3beagle.c|1 -
arch/arm/mach-omap2/board-omap3evm.c |1 -
arch/arm/mach-omap2/board-omap3pandora.c |1 -
arch/arm/mach-omap2/board-omap3touchbook.c |1 -
arch/arm/mach-omap2/board-overo.c |1 -
arch/arm/mach-omap2/board-rx51.c |1 -
arch/arm/mach-omap2/board-zoom2.c |1 -
arch/arm/mach-omap2/board-zoom3.c |1 -
arch/arm/plat-omap/gpio.c |6 --
arch/arm/plat-omap/include/plat/gpio.h |1 -
35 files changed, 0 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 7fc11c3..7c0c812 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -134,7 +134,6 @@ static void __init ams_delta_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
}
static struct map_desc ams_delta_io_desc[] __initdata = {
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 096f2ed..8d9d6e8 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -313,7 +313,6 @@ static void __init omap_fsample_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
fsample_init_smc91x();
}
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index d1100e4..dd04ef5 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -383,7 +383,6 @@ static void __init h2_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
h2_init_smc91x();
}
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index a53ab82..ac8af4b 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -422,7 +422,6 @@ static void __init h3_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
h3_init_smc91x();
}
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index e36639f..82a9a59 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -279,7 +279,6 @@ static void __init htcherald_init(void)
{
printk(KERN_INFO HTC Herald init.\n);
- omap_gpio_init();
omap_board_config = htcherald_config;
omap_board_config_size = ARRAY_SIZE(htcherald_config);
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index 5d12fd3..28bb2cd 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -290,7 +290,6 @@ static void __init innovator_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap1510()) {
omap1510_fpga_init_irq();
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 71e1a3f..6ea838c 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -379,7 +379,6 @@ static void __init omap_nokia770_init(void)
platform_add_devices(nokia770_devices, ARRAY_SIZE(nokia770_devices));
spi_register_board_info(nokia770_spi_board_info,
