Re: [PATCH 01/20] OMAP: McBSP: Provide functions for ASoC frame syncronization
On Thursday 30 July 2009 15:49:24 Valentin Eduardo (Nokia-D/Helsinki) wrote:
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
ASoC has an annoying bug letting either L or R channel to be
played on L channel. In other words, L and R channels can
switch at random. This provides McBSP funtionality that may
be used to fix this feature.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |2 +
arch/arm/plat-omap/mcbsp.c | 52
+++ 2 files changed, 54 insertions(+), 0
deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h index bb154ea..77191c5 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -389,6 +389,8 @@ int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
void omap_mcbsp_start(unsigned int id);
void omap_mcbsp_stop(unsigned int id);
+void omap_mcbsp_xmit_enable(unsigned int id, u8 enable);
+void omap_mcbsp_recv_enable(unsigned int id, u8 enable);
void omap_mcbsp_xmit_word(unsigned int id, u32 word);
u32 omap_mcbsp_recv_word(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index efa0e01..84cc323 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -398,6 +398,58 @@ void omap_mcbsp_stop(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_stop);
+void omap_mcbsp_xmit_enable(unsigned int id, u8 enable)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *io_base;
+ u16 w;
+
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
+ return;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return;
+ }
+
+ mcbsp = id_to_mcbsp_ptr(id);
+ io_base = mcbsp-io_base;
+
+ w = OMAP_MCBSP_READ(io_base, XCCR);
+
+ if (enable)
+ OMAP_MCBSP_WRITE(io_base, XCCR, w ~(XDISABLE));
+ else
+ OMAP_MCBSP_WRITE(io_base, XCCR, w | XDISABLE);
Have you tried to play with the SPCR2:XRST bit instead of the XCCR:XDISABLE?
It places the transmitter to reset, thus disabling it also, furthermore it is
available on OMAP1 as well, so we can use the same code there as well...
+}
+EXPORT_SYMBOL(omap_mcbsp_xmit_enable);
+
+void omap_mcbsp_recv_enable(unsigned int id, u8 enable)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *io_base;
+ u16 w;
+
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
+ return;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return;
+ }
+
+ mcbsp = id_to_mcbsp_ptr(id);
+ io_base = mcbsp-io_base;
+
+ w = OMAP_MCBSP_READ(io_base, RCCR);
+
+ if (enable)
+ OMAP_MCBSP_WRITE(io_base, RCCR, w ~(RDISABLE));
+ else
+ OMAP_MCBSP_WRITE(io_base, RCCR, w | RDISABLE);
Same goes here: can you try the SPCR1:RRST bit here instead of the
RCCR:RDISABLE?
+}
+EXPORT_SYMBOL(omap_mcbsp_recv_enable);
+
/* polled mcbsp i/o operations */
int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
{
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] ARM:OMAP4 iommu:changes in iommu for OMAP4
* Russell King - ARM Linux li...@arm.linux.org.uk [090805 01:45]:
On Tue, Aug 04, 2009 at 05:30:23PM -0500, Kanigeri, Hari wrote:
- obj-clk = clk_get(pdev-dev, pdata-clk_name);
- if (IS_ERR(obj-clk))
- goto err_clk;
+ /*
+* FIX-ME: Replace with correct clk node when clk
+* framework is available
+*/
+ if (!cpu_is_omap44xx()) {
+ obj-clk = clk_get(pdev-dev, pdata-clk_name);
+ if (IS_ERR(obj-clk))
+ goto err_clk;
+ }
I've no visibility on when these are going to get resolved, and it's
starting to concern me that there appears to be no progress on it,
especially as we have more and more code being merged with these
workarounds. It's getting towards the point where enough is enough
and we need OMAP4 clk support in place, even if it is just a simple
stop-gap implementation rather than all these horrible hacks spread
through the code which one day will need to be found and removed.
Yeah I agree.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
On Thu, 30 Jul 2009 15:49:34 +0300
Eduardo Valentin eduardo.valen...@nokia.com wrote:
From: Peter Ujfalusi peter.ujfal...@nokia.com
It adds a new sysfs file, where the user can configure the mcbsp mode to use.
If the mcbsp channel is in use, it does not allow the change.
Than in omap_pcm_open we can call the omap_mcbsp_get_opmode to get the mode,
store it, than use it to implement the different modes.
...
+/** McBSP DMA operating modes **/
+#define MCBSP_DMA_MODE_ELEMENT 0
+#define MCBSP_DMA_MODE_THRESHOLD 1
+#define MCBSP_DMA_MODE_FRAME 2
...
+static ssize_t dma_op_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct omap_mcbsp *mcbsp = dev_get_drvdata(dev);
+ int dma_op_mode;
+
+ spin_lock_irq(mcbsp-lock);
+ dma_op_mode = mcbsp-dma_op_mode;
+ spin_unlock_irq(mcbsp-lock);
+
+ return sprintf(buf, %d\n, dma_op_mode);
It would be good to handle this as an ascii like e.g /sys/power/state
does. element, threshold or frame. A number value doesn't tell
much (for me when testing).
@@ -1195,12 +1266,14 @@ static int __devinit omap_mcbsp_probe
(struct platform_device *pdev)
if (cpu_is_omap34xx()) {
mcbsp-max_tx_thres = max_thres(mcbsp);
mcbsp-max_rx_thres = max_thres(mcbsp);
+ mcbsp-dma_op_mode = MCBSP_DMA_MODE_THRESHOLD;
if (omap_additional_add(pdev))
dev_warn(pdev-dev,
Unable to create threshold controls\n);
} else {
mcbsp-max_tx_thres = -EINVAL;
mcbsp-max_rx_thres = -EINVAL;
+ mcbsp-dma_op_mode = MCBSP_DMA_MODE_ELEMENT;
}
I would say the default mode for the omap34xx should be also element as
it keeps the omap_pcm_pointer behavior the same than currently and
avoids possible regression.
--
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 03/20] OMAP: McBSP: Change wakeup signals
On Thursday 30 July 2009 15:49:26 Valentin Eduardo (Nokia-D/Helsinki) wrote: Configure only XRDYEN and RRDYEN wakeup signals in order to get better power consumption. @@ -264,9 +264,7 @@ #define REOFEN 0x0004 #define RFSREN 0x0002 #define RSYNCERREN 0x0001 -#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \ - XSYNCERREN | RRDYEN | REOFEN | RFSREN | \ - RSYNCERREN) +#define WAKEUPEN_ALL (XRDYEN | RRDYEN) Or don't use the WAKEUPEN_ALL in the code, but replace it with (XRDYEN | RRDYEN)? It is confusing to use WAKEUPEN_ALL, which is actually _not_ enabling all wakeups. -- Péter -- To unsubscribe from this list: send the line unsubscribe 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 16/20] ASoC: OMAP: Use McBSP threshold again
On Thu, 30 Jul 2009 15:49:39 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: Now this patch implements again the McBSP threshold usage for OMAP ASoC. We figured out that there is no need to have so much SW control in order to have DMA in idle state during audio streaming. Configuring McBSP threshold value and DMA to FRAME_SYNC are sufficient. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c | 37 +++-- 1 files changed, 35 insertions(+), 2 deletions(-) @@ -192,6 +203,12 @@ static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: prtd-period_index = 0; + /* Configure McBSP internal buffer usage */ + if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) + omap_mcbsp_set_tx_threshold(bus_id, samples - 1); + else + omap_mcbsp_set_rx_threshold(bus_id, samples - 1); + omap_start_dma(prtd-dma_ch); break; Oops, didn't notice this before. This will hard glue the DMA and McBSP together. Even currently there is only McBSP based DAI link driver, there can be others as well. EAC DAI for OMAP2420 would be necessary for instance if one wants to develop ASoC support for Nokia N800. Nokia N810 could use that too. -- 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 v1 3/3] ARM:OMAP4 iommu:provide build support for omap4 iommu
On Wed, Aug 05, 2009 at 07:35:38AM +0300, Hiroshi DOYU wrote: From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [PATCH v1 3/3] ARM:OMAP4 iommu:provide build support for omap4 iommu Date: Wed, 5 Aug 2009 00:42:41 +0200 On Tue, Aug 04, 2009 at 05:32:12PM -0500, Kanigeri, Hari wrote: diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index efe85d0..50aaefb 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -118,8 +118,11 @@ config OMAP_MBOX_FWK DSP, IVA1.0 and IVA2 in OMAP1/2/3. config OMAP_IOMMU - tristate - + tristate iommu Insufficiently verbose description. OMAP IOMMU Support would be better. I thought the idea here was to arrange for things to select OMAP_IOMMU when they require it rather than offering it as a separate configuration option. The former way has the advantage that you don't need to know that you need IOMMU support to (eg) use the Camera - enabling the Camera should automatically enable IOMMU support. The following is the original discussion. http://lists.arm.linux.org.uk/lurker/message/20090518.130233.3f238e72.en.html Quite. I'm repeating myself. So the question is why the original discussion didn't produce a change. -- To unsubscribe from this list: send the line unsubscribe 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: Settings for enabling LCD + Framebuffer in 3430SDP?
Try with the attached defconfig which has the fb enabled in it. Regards Teerth -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto Sent: Tuesday, August 04, 2009 8:39 PM To: Linux OMAP Users Cc: Kevin Hilman Subject: PM: Settings for enabling LCD + Framebuffer in 3430SDP? Hi all, First of all: I'm working on latest PM branch. Does anybody of you know how to enable the Framebuffer + LCD in 3430SDP board? I've loaded omap3_pm_defconfig as a reference, and I want to be able to see the framebuffer in my LCD... Thanks in advance! Regards, Sergio -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html omap3_pm_defconfig Description: omap3_pm_defconfig
Re: MMC3 Overo
u-boot_snip MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\ You must have input enable on CLK line for MMC3 or it won't work for some reason (MMC 1 and 2 doesn't need that). Without this part of the host controller hardware doesn't get the clock I guess, or something like that. You won't believe how much time we've wasted on 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: arch/arm/mach-omap* organization
On Tue, Aug 04, 2009 at 09:05:27AM +0200, ext Tony Lindgren wrote: * Ben Goska gos...@onid.oregonstate.edu [090804 01:53]: Is there a reason why omap2, omap3, and now omap4 files are all packed into the mach-omap2 directory? It seems like it would make more sense for each omap version to have it's own directory. Majority of the mach-omap2 code is shared across them. For example, the initial patch to add minimal omap3 support on top of the omap2 code was about 500 lines of diff. The situation was pretty much the same to add minimal omap4 support on top of omap3. If we wanted to, in the long run we could move more of the shared code to plat-omap, and just keep board-*.c files under each mach-* directory. I guess that will start to show as a necessary change since we would be able to remove several if (cpu_is_omapXXX()) from platform_device registration code and related changes. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
On Wed, 5 Aug 2009 10:21:49 +0300
Jarkko Nikula jhnik...@gmail.com wrote:
If my analysis is correct, the best solution I can see would be starting
McBSP
transfer for one direction only, not both, so the opposite direction can be
started when needed. That requires deeper and wider OMAP knowledge and a
change in omap_mcbsp_start() API though. I am not in a position to deal
with
this myself, I'm afraid.
I favor this change. Actually I remember I was thinking shortly to
change API of omap_mcbsp_start and _stop more than year back or so but
didn't find it necessary back then.
I think change will be trivial. Basically two new arguments indicating
are the TX/RX active and let the first/last caller to deal with
sample-rate generator and frame sync activation/de-activation.
I hacked a patch below. Can you test does it help?
--
Jarkko
---
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index bb154ea..57249bb 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -387,8 +387,8 @@ void omap_mcbsp_register_board_cfg(struct
omap_mcbsp_platform_data *config,
void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg *
config);
int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
-void omap_mcbsp_start(unsigned int id);
-void omap_mcbsp_stop(unsigned int id);
+void omap_mcbsp_start(unsigned int id, int tx, int rx);
+void omap_mcbsp_stop(unsigned int id, int tx, int rx);
void omap_mcbsp_xmit_word(unsigned int id, u32 word);
u32 omap_mcbsp_recv_word(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index efa0e01..d7645b3 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -328,14 +328,15 @@ void omap_mcbsp_free(unsigned int id)
EXPORT_SYMBOL(omap_mcbsp_free);
/*
- * Here we start the McBSP, by enabling the sample
- * generator, both transmitter and receivers,
- * and the frame sync.
+ * Here we start the McBSP, by enabling transmitter, receiver or both.
+ * If no transmitter or receiver is active prior calling, then sample-rate
+ * generator and frame sync are started.
*/
-void omap_mcbsp_start(unsigned int id)
+void omap_mcbsp_start(unsigned int id, int tx, int rx)
{
struct omap_mcbsp *mcbsp;
void __iomem *io_base;
+ int idle;
u16 w;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -348,32 +349,40 @@ void omap_mcbsp_start(unsigned int id)
mcbsp-rx_word_length = (OMAP_MCBSP_READ(io_base, RCR1) 5) 0x7;
mcbsp-tx_word_length = (OMAP_MCBSP_READ(io_base, XCR1) 5) 0x7;
- /* Start the sample generator */
- w = OMAP_MCBSP_READ(io_base, SPCR2);
- OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1 6));
+ idle = !((OMAP_MCBSP_READ(io_base, SPCR2) |
+ OMAP_MCBSP_READ(io_base, SPCR1)) 1);
+
+ if (idle) {
+ /* Start the sample generator */
+ w = OMAP_MCBSP_READ(io_base, SPCR2);
+ OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1 6));
+ }
/* Enable transmitter and receiver */
w = OMAP_MCBSP_READ(io_base, SPCR2);
- OMAP_MCBSP_WRITE(io_base, SPCR2, w | 1);
+ OMAP_MCBSP_WRITE(io_base, SPCR2, w | (tx 1));
w = OMAP_MCBSP_READ(io_base, SPCR1);
- OMAP_MCBSP_WRITE(io_base, SPCR1, w | 1);
+ OMAP_MCBSP_WRITE(io_base, SPCR1, w | (rx 1));
udelay(100);
- /* Start frame sync */
- w = OMAP_MCBSP_READ(io_base, SPCR2);
- OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1 7));
+ if (idle) {
+ /* Start frame sync */
+ w = OMAP_MCBSP_READ(io_base, SPCR2);
+ OMAP_MCBSP_WRITE(io_base, SPCR2, w | (1 7));
+ }
/* Dump McBSP Regs */
omap_mcbsp_dump_reg(id);
}
EXPORT_SYMBOL(omap_mcbsp_start);
-void omap_mcbsp_stop(unsigned int id)
+void omap_mcbsp_stop(unsigned int id, int tx, int rx)
{
struct omap_mcbsp *mcbsp;
void __iomem *io_base;
+ int idle;
u16 w;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -386,15 +395,20 @@ void omap_mcbsp_stop(unsigned int id)
/* Reset transmitter */
w = OMAP_MCBSP_READ(io_base, SPCR2);
- OMAP_MCBSP_WRITE(io_base, SPCR2, w ~(1));
+ OMAP_MCBSP_WRITE(io_base, SPCR2, w ~(tx 1));
/* Reset receiver */
w = OMAP_MCBSP_READ(io_base, SPCR1);
- OMAP_MCBSP_WRITE(io_base, SPCR1, w ~(1));
+ OMAP_MCBSP_WRITE(io_base, SPCR1, w ~(rx 1));
- /* Reset the sample rate generator */
- w = OMAP_MCBSP_READ(io_base, SPCR2);
- OMAP_MCBSP_WRITE(io_base, SPCR2, w ~(1 6));
+ idle = !((OMAP_MCBSP_READ(io_base, SPCR2) |
+ OMAP_MCBSP_READ(io_base, SPCR1)) 1);
+
+ if (idle) {
+ /* Reset the sample rate generator */
+ w = OMAP_MCBSP_READ(io_base, SPCR2);
+
Re: [PATCH]OMAP4: McSPI Support for OMAP_4430
* Shilimkar, Santosh santosh.shilim...@ti.com [090703 07:52]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of David Brownell Sent: Friday, July 03, 2009 5:57 AM To: Syed, Rafiuddin Cc: spi-devel-gene...@lists.sourceforge.net; linux-omap@vger.kernel.org Subject: Re: [PATCH]OMAP4: McSPI Support for OMAP_4430 On Monday 29 June 2009, Syed Rafiuddin wrote: This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Acked-by: Tony Lindgren t...@atomide.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com I'd add my ack if this patch weren't mangled. :) --- arch/arm/mach-omap2/devices.c | 25 + Since *most* of this is arch/arm stuff, I think this patch should go to mainine through Tony. That's the best way to make sure it doesn't cause conflicts with other patches he sends. Tony suggested that this patch can be sent through SPI mailing list. Refer this thread. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14011.html Just to confirm, this is OK for me to merge via the SPI once the mangling is removed. Tony drivers/spi/omap2_mcspi.c | 10 ++ 2 files changed, 27 insertions(+), 8 deletions(-) None of this seemed particularly controversial. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 2/2] McSPI Slave and DMA,FIFO support
* David Brownell davi...@pacbell.net [090703 03:22]: On Tuesday 23 June 2009, Hemanth V wrote: This patch adds support for McSPI slave and FIFO. DMA and FIFO could be enabled together for better throughput. This has a dependency on patch [RESEND][PATCH 1/2] McSPI Slave and DMA,FIFO support ... in this case I'd think they would better be part of a single patch. However, anything related to SPI slave support should be separated entirely from FIFO support. Ditto anything adding more SPI_DEBUG support. Oh, and use the BIT(n) syntax not (1 n) in the new constants you define... the patch making this driver use that style finally went upstream. I agree with Dave's comments. Maybe repost one more time, then I'd actually prefer these get merged via the SPI list once everybody's happy. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]OMAP4: McSPI Support for OMAP_4430
* Shilimkar, Santosh santosh.shilim...@ti.com [090703 07:52]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of David Brownell Sent: Friday, July 03, 2009 5:57 AM To: Syed, Rafiuddin Cc: spi-devel-gene...@lists.sourceforge.net; linux-omap@vger.kernel.org Subject: Re: [PATCH]OMAP4: McSPI Support for OMAP_4430 On Monday 29 June 2009, Syed Rafiuddin wrote: This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Acked-by: Tony Lindgren t...@atomide.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com I'd add my ack if this patch weren't mangled. :) --- arch/arm/mach-omap2/devices.c | 25 + Since *most* of this is arch/arm stuff, I think this patch should go to mainine through Tony. That's the best way to make sure it doesn't cause conflicts with other patches he sends. Tony suggested that this patch can be sent through SPI mailing list. Refer this thread. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14011.html Just to confirm, this is OK for me to merge via the SPI once the mangling is removed. Tony I have resubmitted the patch by removing the mangling, It can be found at this link location http://marc.info/?l=linux-omapm=124827089126638w=2 drivers/spi/omap2_mcspi.c | 10 ++ 2 files changed, 27 insertions(+), 8 deletions(-) None of this seemed particularly controversial. -- To unsubscribe from this list: send the line unsubscribe 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
[APPLIED] [PATCH v2] OMAP2/3: DMA errata correction
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 8b865a1ee739b9057e14637ff4f42cc8dfa2239b PatchWorks http://patchwork.kernel.org/patch/32946/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=8b865a1ee739b9057e14637ff4f42cc8dfa2239b -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
Hi,
Sorry for the long delay on replying to this one.
* Wang Sawsd-A24013 cqw...@motorola.com [090602 02:25]:
This patch adds irq_enable and irq_disable for OMAP GPIO IRQ chip, and
also only enable WAKEUPEN
When GPIO edge detection is enabled, also clear the gpio event
triggering configurations to avoid
Pending interrupt status which is generated regardless of the IRQEN and
WKUPEN bit, the pending
IRQ status may prevent GPIO module acknowledge IDLE request and prevent
PER and thus RETENTION.
This is only applied for OMAP2/3 GPIO IRQs.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/gpio.c | 44
++--
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index bd04b40..19e0461 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -581,7 +581,7 @@ void omap_set_gpio_debounce_time(int gpio, int
enc_time)
EXPORT_SYMBOL(omap_set_gpio_debounce_time);
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
-static inline void set_24xx_gpio_triggering(struct gpio_bank *bank, int
gpio,
+static void set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
int trigger)
{
void __iomem *base = bank-base;
@@ -597,7 +597,12 @@ static inline void set_24xx_gpio_triggering(struct
gpio_bank *bank, int gpio,
trigger IRQ_TYPE_EDGE_FALLING);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
- if (trigger != 0)
+ /*
+ * GPIO wakeup request can only be generated on edge
+ * transitions, see OMAP34xx_ES3.1_TRM_V_Q G25.5.3.1
+ * wake-up request note for detail
+ */
+ if ((trigger IRQ_TYPE_EDGE_BOTH) != 0)
__raw_writel(1 gpio, bank-base
+ OMAP24XX_GPIO_SETWKUENA);
else
To me it looks like the right way to deal with the level gpio
would be to change it temporarily to be edge for the duration of
idle, then change it back to be level after returning from idle.
@@ -1133,6 +1138,39 @@ static void gpio_ack_irq(unsigned int irq)
_clear_gpio_irqstatus(bank, gpio);
}
+static void gpio_enable_irq(unsigned int irq)
+{
+ unsigned int gpio = irq - IH_GPIO_BASE;
+ struct gpio_bank *bank = get_irq_chip_data(irq);
+ int trigger = irq_desc[irq].status IRQ_TYPE_SENSE_MASK;
+
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+ set_24xx_gpio_triggering(bank, get_gpio_index(gpio), trigger);
+#endif
+ _set_gpio_irqenable(bank, gpio, 1);
+}
+
+static void gpio_disable_irq(unsigned int irq)
+{
+ unsigned int gpio = irq - IH_GPIO_BASE;
+ struct gpio_bank *bank = get_irq_chip_data(irq);
+
+ _set_gpio_irqenable(bank, gpio, 0);
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+ /*
+ * Clear the event detect setting and IRQ status to prevent
+ * IRQ staus been set or pending there While IRQ is disabled,
+ * otherwise GPIO module will not acknowledge the IDLE request
+ * from PER power domain, this may prevent System wide retention
+ * See OMAP34xx_ES3.1_TRM_V_Q G25.5.3.1 GPIO interrupt and
wakeup
+ * enable note for detail
+ */
+ set_24xx_gpio_triggering(bank, get_gpio_index(gpio),
IRQ_TYPE_NONE);
+ _clear_gpio_irqstatus(bank, gpio);
+#endif
+
+}
+
static void gpio_mask_irq(unsigned int irq)
{
unsigned int gpio = irq - IH_GPIO_BASE;
@@ -1160,6 +1198,8 @@ static void gpio_unmask_irq(unsigned int irq)
static struct irq_chip gpio_irq_chip = {
.name = GPIO,
.shutdown = gpio_irq_shutdown,
+ .enable = gpio_enable_irq,
+ .disable= gpio_disable_irq,
.ack= gpio_ack_irq,
.mask = gpio_mask_irq,
.unmask = gpio_unmask_irq,
Also, this irq_enable/disable should be a separate patch.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
Hi, Peter Ujfalusi wrote: On Tuesday 04 August 2009 23:46:09 ext Janusz Krzysztofik wrote: For both playback start while capturing and capture start while playing, XSYNC_ERR/RSYNC_ERR is clear and XRDY/RRDY is ready, This means that XRDY/RRDY is set (1)? Yes, trasmit/recieve confirmed at first while(!(readw(...) XRDY/RRDY)) attempt. In case of playback start while capture: What is the state of the XEMPTY bit (SPCR2:2)? Is it 0? It should. Have not checked, but will do for completness. I think the reason is quite simple: on OMAP1 the DMA request is edge sensitive (compared to OMAP2 and OMAP3 where it is level based). This means: Good recap. The danger with the pollwrite/pollread is: If the stream is not mono, than you kind of ensure a certain channel shift (channel switch in case of stereo stream). Good point, I was trying break all not mono. If my analysis is correct, the best solution I can see would be starting McBSP transfer for one direction only, not both, so the opposite direction can be started when needed. That requires deeper and wider OMAP knowledge and a change in omap_mcbsp_start() API though. I am not in a position to deal with this myself, I'm afraid. I agree, this would be the best solution for the problem. I was also considering omap_mcbsp_restart(id, direction) as a more conservative solution, but now, after Jarkko has subbmitted his patch on omap_mcbsp_start(), it's not an option any longer, I think. Cheers, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: GPIO: Avoid generating extra IRQs
Hi,
* ext-eero.nurkk...@nokia.com ext-eero.nurkk...@nokia.com [090703 09:27]:
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
It is possible for GPIO IRQ lines configured with
falling edge triggering only to get IRQs at the
rising edge upon the exit of offmode. And vice
versa. Prevent such IRQs to arrive by generating
the IRQ obeying the detection scheme.
Is the situation still the same if we temporarily change the
level lines to edge for the duration of idle? This would allow
waking up even if the line is level.
Also one question below.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
arch/arm/plat-omap/gpio.c | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 26b387c..7a270c0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1804,7 +1804,7 @@ void omap2_gpio_resume_after_retention(void)
return;
for (i = 0; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
- u32 l;
+ u32 l, gen, gen0, gen1;
if (!(bank-enabled_non_wakeup_gpios))
continue;
@@ -1825,14 +1825,33 @@ void omap2_gpio_resume_after_retention(void)
#endif
l ^= bank-saved_datain;
l = bank-non_wakeup_gpios;
- if (l) {
+
+ /*
+ * No need to generate IRQs for the rising edge for gpio IRQs
+ * configured with falling edge only; and vice versa.
+ */
+ gen0 = l bank-saved_fallingdetect;
+ gen0 = bank-saved_datain;
+
+ gen1 = l bank-saved_risingdetect;
+ gen1 = ~(bank-saved_datain);
+
Is the gen0 = correct or should it also clear the bits?
Also, have you checked the code flow on omap1 when l, gen, gen0 gen1
are not initialized? Just wondering ;)
Tony
+ /* FIXME: Consider GPIO IRQs with level detections properly! */
+ gen = l (~(bank-saved_fallingdetect)
+ ~(bank-saved_risingdetect));
+ /* Consider all GPIO IRQs needed to be updated */
+ gen |= gen0 | gen1;
+
+ if (gen) {
u32 old0, old1;
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) || \
defined(CONFIG_ARCH_OMAP4)
old0 = __raw_readl(bank-base +
OMAP24XX_GPIO_LEVELDETECT0);
old1 = __raw_readl(bank-base +
OMAP24XX_GPIO_LEVELDETECT1);
- __raw_writel(old0 | l, bank-base +
OMAP24XX_GPIO_LEVELDETECT0);
- __raw_writel(old1 | l, bank-base +
OMAP24XX_GPIO_LEVELDETECT1);
+ __raw_writel(old0 | gen, bank-base +
+ OMAP24XX_GPIO_LEVELDETECT0);
+ __raw_writel(old1 | gen, bank-base +
+ OMAP24XX_GPIO_LEVELDETECT1);
__raw_writel(old0, bank-base +
OMAP24XX_GPIO_LEVELDETECT0);
__raw_writel(old1, bank-base +
OMAP24XX_GPIO_LEVELDETECT1);
#endif
--
1.6.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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] OMAP3: EHCI: Allow EHCI to work as a module again
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: master Initial commit ID (Likely to change): 4baadee6e2dd5228e1b17cb5f931c4e0ed8fcb96 PatchWorks http://patchwork.kernel.org/patch/34200/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=4baadee6e2dd5228e1b17cb5f931c4e0ed8fcb96 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] DSPBRIDGE: Move resource cleanup to bridge_release
Instead of doing lazy resource cleanup in bridge_open, this patch will move
it to bridge_release. This way the resources allocated will be cleaned up
when that instance of the open is closed and will not wait till the next
instance of open happens.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/rmgr/drv_interface.c | 132 ---
1 files changed, 52 insertions(+), 80 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 8cbdeee..2fcd6f9 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -562,102 +562,74 @@ static void __exit bridge_exit(void)
platform_driver_unregister(bridge_driver);
}
-/* This function is called when an application opens handle to the
- * bridge driver. */
-
+/*
+ * This function is called when an application opens handle to the
+ * bridge driver.
+ */
static int bridge_open(struct inode *ip, struct file *filp)
{
int status = 0;
-#ifndef RES_CLEANUP_DISABLE
- u32 hProcess;
- DSP_STATUS dsp_status = DSP_SOK;
- HANDLE hDrvObject = NULL;
- struct PROCESS_CONTEXT*pPctxt = NULL;
- struct PROCESS_CONTEXT *next_node = NULL;
- struct PROCESS_CONTEXT*pCtxtclosed = NULL;
- struct PROCESS_CONTEXT*pCtxttraverse = NULL;
- struct task_struct *tsk = NULL;
- GT_0trace(driverTrace, GT_ENTER, - driver_open\n);
- dsp_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
+ DSP_STATUS dsp_status;
+ HANDLE hDrvObject;
+ struct PROCESS_CONTEXT *pr_ctxt = NULL;
- /* Checking weather task structure for all process existing
-* in the process context list If not removing those processes*/
- if (DSP_FAILED(dsp_status))
- goto func_cont;
+ GT_0trace(driverTrace, GT_ENTER, - bridge_open\n);
- DRV_GetProcCtxtList(pCtxtclosed, (struct DRV_OBJECT *)hDrvObject);
- while (pCtxtclosed != NULL) {
- tsk = find_task_by_vpid(pCtxtclosed-pid);
- next_node = pCtxtclosed-next;
-
- if ((tsk == NULL) || (tsk-exit_state == EXIT_ZOMBIE)) {
-
- GT_1trace(driverTrace, GT_5CLASS,
-***Task structure not existing for
-process***%d\n, pCtxtclosed-pid);
- DRV_RemoveAllResources(pCtxtclosed);
- if (pCtxtclosed-hProcessor != NULL) {
- DRV_GetProcCtxtList(pCtxttraverse,
- (struct DRV_OBJECT *)hDrvObject);
- if (pCtxttraverse-next == NULL) {
- PROC_Detach(pCtxtclosed-hProcessor);
- } else {
- if ((pCtxtclosed-pid ==
- pCtxttraverse-pid)
- (pCtxttraverse-next != NULL)) {
- pCtxttraverse =
- pCtxttraverse-next;
- }
- while ((pCtxttraverse != NULL)
-(pCtxtclosed-hProcessor
-!= pCtxttraverse-hProcessor)) {
- pCtxttraverse =
- pCtxttraverse-next;
- if ((pCtxttraverse != NULL)
- (pCtxtclosed-pid ==
- pCtxttraverse-pid)) {
- pCtxttraverse =
- pCtxttraverse-next;
- }
- }
- if (pCtxttraverse == NULL) {
- PROC_Detach
-(pCtxtclosed-hProcessor);
- }
- }
- }
- DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
-pCtxtclosed,
-(void *)pCtxtclosed-pid);
+ dsp_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
+ if (DSP_SUCCEEDED(dsp_status)) {
+ /*
+* Allocate a new process context and insert it into global
+* process context list.
+*/
+ DRV_InsertProcContext(hDrvObject, pr_ctxt);
+
[PATCH 1/3] DSPBRIDGE: Cleanup bridge_release and remove DSP_Close
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/dspdrv.h | 17
drivers/dsp/bridge/rmgr/drv_interface.c | 19 ++---
drivers/dsp/bridge/rmgr/dspdrv.c | 26 -
3 files changed, 3 insertions(+), 59 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dspdrv.h
b/arch/arm/plat-omap/include/dspbridge/dspdrv.h
index f500ffb..3d04967 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspdrv.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspdrv.h
@@ -50,23 +50,6 @@
#define MAX_DEV 10 /* Max support of 10 devices */
/*
- * DSP_Close
- * Purpose:
- * Called when the client application/driver unloads the DDSP DLL. Upon
- * unloading, the DDSP DLL will call CloseFile().
- * Parameters:
- * dwDeviceContext:Handle returned by XXX_Open used to identify
- * the open context of the device
- * Returns:
- * TRUE indicates the device is successfully closed. FALSE indicates
- * otherwise.
- * Requires:
- * dwOpenContext!= NULL.
- * Ensures:The Application instance owned objects are cleaned up.
- */
-extern bool DSP_Close(u32 dwDeviceContext);
-
-/*
* DSP_Deinit
* Purpose:
* This function is called by Device Manager to de-initialize a device.
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 24f6336..8cbdeee 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -655,22 +655,9 @@ func_cont:
* driver. */
static int bridge_release(struct inode *ip, struct file *filp)
{
- int status;
- u32 pid;
-
- GT_0trace(driverTrace, GT_ENTER, - driver_release\n);
-
- /* Return PID instead of process handle */
- pid = current-pid;
-
- status = DSP_Close(pid);
-
-
- (status == true) ? (status = 0) : (status = -1);
-
- GT_0trace(driverTrace, GT_ENTER, - driver_release\n);
-
- return status;
+ GT_0trace(driverTrace, GT_ENTER, - bridge_release\n);
+ GT_0trace(driverTrace, GT_ENTER, - bridge_release\n);
+ return 0;
}
/* This function provides IO interface to the bridge driver. */
diff --git a/drivers/dsp/bridge/rmgr/dspdrv.c b/drivers/dsp/bridge/rmgr/dspdrv.c
index a7a74fc..b5caf39 100644
--- a/drivers/dsp/bridge/rmgr/dspdrv.c
+++ b/drivers/dsp/bridge/rmgr/dspdrv.c
@@ -248,29 +248,3 @@ bool DSP_Deinit(u32 deviceContext)
return retVal;
}
-
-/*
- * DSP_Close
- * The Calling Process handle is passed to DEV_CleanupProcesState
- * for cleaning up of any resources used by the application
- */
-bool DSP_Close(u32 dwOpenContext)
-{
- bool retVal = false;
-
- DBC_Require(dwOpenContext != 0);
-
- GT_0trace(curTrace, GT_ENTER, Entering DSP_Close\n);
-
-#ifdef RES_CLEANUP_DISABLE
-
- if (DSP_SUCCEEDED(DEV_CleanupProcessState((HANDLE) dwOpenContext))) {
- GT_0trace(curTrace, GT_1CLASS, DSP_Close Succeeded \r\n);
- retVal = true;
- } else {
- GT_0trace(curTrace, GT_7CLASS, DSP_Close failed \r\n);
- }
-#endif
-
- return retVal;
-}
--
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] DSPBRIDGE: Use TGID instead of PID for resource accounting
This patch uses TGID instead of PID for accounting resources tied to a
user space process. This should fix all the issues related to user space
multithreading and resource cleanup.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/pmgr/cmm.c |4 ++--
drivers/dsp/bridge/rmgr/drv_interface.c |2 +-
drivers/dsp/bridge/rmgr/node.c | 12 ++--
drivers/dsp/bridge/rmgr/proc.c | 22 +++---
drivers/dsp/bridge/rmgr/strm.c | 16
drivers/dsp/bridge/services/kfile.c |7 ++-
drivers/dsp/bridge/wmd/chnl_sm.c|4 ++--
7 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/cmm.c b/drivers/dsp/bridge/pmgr/cmm.c
index 99a2432..7dea18c 100644
--- a/drivers/dsp/bridge/pmgr/cmm.c
+++ b/drivers/dsp/bridge/pmgr/cmm.c
@@ -284,8 +284,8 @@ void *CMM_CallocBuf(struct CMM_OBJECT *hCmmMgr, u32 uSize,
* We'll need to free up a process's alloc'd SM if the
* client process goes away.
*/
- /* Return PID instead of process handle */
- pNode-hClientProc = current-pid;
+ /* Return TGID instead of process handle */
+ pNode-hClientProc = current-tgid;
/* put our node on InUse list */
LST_PutTail(pAllocator-pInUseListHead,
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 2fcd6f9..80c0eeb 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -584,7 +584,7 @@ static int bridge_open(struct inode *ip, struct file *filp)
DRV_InsertProcContext(hDrvObject, pr_ctxt);
if (pr_ctxt) {
DRV_ProcUpdatestate(pr_ctxt, PROC_RES_ALLOCATED);
- DRV_ProcSetPID(pr_ctxt, current-pid);
+ DRV_ProcSetPID(pr_ctxt, current-tgid);
} else {
status = -ENOMEM;
}
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index 53a42bf..5ff87e9 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -789,8 +789,8 @@ func_cont2:
#ifndef RES_CLEANUP_DISABLE
if (DSP_SUCCEEDED(status)) {
- /* Return PID instead of process handle */
- hProcess = current-pid;
+ /* Return TGID instead of process handle */
+ hProcess = current-tgid;
res_status = CFG_GetObject((u32 *)hDrvObject,
REG_DRV_OBJECT);
@@ -813,8 +813,8 @@ func_cont2:
}
}
if (DSP_SUCCEEDED(status)) {
- /* Return PID instead of process handle */
- hProcess = current-pid;
+ /* Return TGID instead of process handle */
+ hProcess = current-tgid;
res_status = CFG_GetObject((u32 *)hDrvObject,
REG_DRV_OBJECT);
if (DSP_SUCCEEDED(res_status)) {
@@ -1793,8 +1793,8 @@ func_cont1:
/* Free host-side resources allocated by NODE_Create()
* DeleteNode() fails if SM buffers not freed by client! */
#ifndef RES_CLEANUP_DISABLE
- /* Return PID instead of process handle */
- hProcess = current-pid;
+ /* Return TGID instead of process handle */
+ hProcess = current-tgid;
res_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
if (DSP_FAILED(res_status))
goto func_cont;
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 0af05eb..469cf21 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -215,7 +215,7 @@ DSP_STATUS PROC_CleanupAllResources(void)
goto func_end;
DRV_GetProcCtxtList(pCtxtclosed, (struct DRV_OBJECT *)hDrvObject);
while (pCtxtclosed != NULL) {
- if (current-pid != pCtxtclosed-pid) {
+ if (current-tgid != pCtxtclosed-pid) {
GT_1trace(PROC_DebugMask, GT_5CLASS,
***Cleanup of
process***%d\n, pCtxtclosed-pid);
@@ -308,8 +308,8 @@ PROC_Attach(u32 uProcessor, OPTIONAL CONST struct
DSP_PROCESSORATTRIN *pAttrIn,
pProcObject-hMgrObject = hMgrObject;
pProcObject-uProcessor = devType;
/* Get Caller Process and store it */
- /* Return PID instead of process handle */
- pProcObject-hProcess = current-pid;
+ /* Return TGID instead of process handle */
+ pProcObject-hProcess = current-tgid;
if (pAttrIn)
pProcObject-uTimeout = pAttrIn-uTimeout;
@@ -385,8 +385,8 @@ func_end:
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
Jarkko Nikula wrote: On Wed, 5 Aug 2009 10:21:49 +0300 Jarkko Nikula jhnik...@gmail.com wrote: If my analysis is correct, the best solution I can see would be starting McBSP transfer for one direction only, not both, so the opposite direction can be started when needed. That requires deeper and wider OMAP knowledge and a change in omap_mcbsp_start() API though. I am not in a position to deal with this myself, I'm afraid. I favor this change. Actually I remember I was thinking shortly to change API of omap_mcbsp_start and _stop more than year back or so but didn't find it necessary back then. I think change will be trivial. Basically two new arguments indicating are the TX/RX active and let the first/last caller to deal with sample-rate generator and frame sync activation/de-activation. I hacked a patch below. Can you test does it help? Will do tonight (CET). Now seeing how easy it was (for you ;), I think I could try to follow that way an modify omap_mcbsp_config() in the same spirit, if you find it of any use. Cheers, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH v2] OMAP3: RX51: Define TWL4030 USB transceiver in board file
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 9cea4f1eda7e18a59a6f6a5d9edc6384318df492 PatchWorks http://patchwork.kernel.org/patch/34410/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=9cea4f1eda7e18a59a6f6a5d9edc6384318df492 -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3: PM: Fix SDRC register addresses
SDRC addresses are offset from OMAP3430_SDRC_RT_BASE and not OMAP3430_SMS_RT_BASE. This fixes OFF mode on EMU/HS devices. Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com --- arch/arm/mach-omap2/sleep34xx.S | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 807b23e..53b6da9 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -49,13 +49,13 @@ #define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\ + SCRATCHPAD_MEM_OFFS) #define SDRC_POWER_V OMAP34XX_SDRC_REGADDR(SDRC_POWER) -#define SDRC_SYSCONFIG_P (OMAP3430_SMS_RT_BASE + SDRC_SYSCONFIG) -#define SDRC_MR_0_P(OMAP3430_SMS_RT_BASE + SDRC_MR_0) -#define SDRC_EMR2_0_P (OMAP3430_SMS_RT_BASE + SDRC_EMR2_0) -#define SDRC_MANUAL_0_P(OMAP3430_SMS_RT_BASE + SDRC_MANUAL_0) -#define SDRC_MR_1_P(OMAP3430_SMS_RT_BASE + SDRC_MR_1) -#define SDRC_EMR2_1_P (OMAP3430_SMS_RT_BASE + SDRC_EMR2_1) -#define SDRC_MANUAL_1_P(OMAP3430_SMS_RT_BASE + SDRC_MANUAL_1) +#define SDRC_SYSCONFIG_P (OMAP3430_SDRC_RT_BASE + SDRC_SYSCONFIG) +#define SDRC_MR_0_P(OMAP3430_SDRC_RT_BASE + SDRC_MR_0) +#define SDRC_EMR2_0_P (OMAP3430_SDRC_RT_BASE + SDRC_EMR2_0) +#define SDRC_MANUAL_0_P(OMAP3430_SDRC_RT_BASE + SDRC_MANUAL_0) +#define SDRC_MR_1_P(OMAP3430_SDRC_RT_BASE + SDRC_MR_1) +#define SDRC_EMR2_1_P (OMAP3430_SDRC_RT_BASE + SDRC_EMR2_1) +#define SDRC_MANUAL_1_P(OMAP3430_SDRC_RT_BASE + SDRC_MANUAL_1) #define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) #define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL) -- 1.6.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: [PATCH] fix omap3 sram virtual addres overlap vmalloc space after increasing vmalloc size
* Paul Walmsley p...@pwsan.com [090721 19:10]: On Tue, 21 Jul 2009, Janboe Ye wrote: Thanks, Paul Tony Is there some issue about this patch? Tony's on vacation right now, so you shouldn't expect a response from him until he returns. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14015.html I've added this patch to my omap-fixes queue, had to apply it manually because of the omap4 defines. Tony - Paul Thanks Janboe Ye On Fri, 2009-07-17 at 16:04 -0600, Paul Walmsley wrote: On Thu, 16 Jul 2009, Janboe Ye wrote: resend for mini coding style fixing commit e85c205ac1427f2405021a36f083280ff0d0a35e increase vmalloc size. vmalloc space will overlap with OMAP3 sram virtual address. Makes sense to me. I'm not sure how we missed this in the original patch. Reviewed-by: Paul Walmsley p...@pwsan.com - Paul Signed-off-by: Li Hong Mei hong-mei...@motorola.com Signed-off-by: Janboe Ye yuan-bo...@motorola.com --- arch/arm/plat-omap/sram.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index a2e60e7..755ccaa 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -41,9 +41,9 @@ #define OMAP2_SRAM_VA 0xe300 #define OMAP2_SRAM_PUB_VA (OMAP2_SRAM_VA + 0x800) #define OMAP3_SRAM_PA 0x4020 -#define OMAP3_SRAM_VA 0xd700 +#define OMAP3_SRAM_VA 0xe300 #define OMAP3_SRAM_PUB_PA 0x40208000 -#define OMAP3_SRAM_PUB_VA 0xd7008000 +#define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000) #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) #define SRAM_BOOTLOADER_SZ 0x00 - Paul - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] ARM: Overo: Fix smsc911x platform device resource value
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 8a333860f6d99652489c3b0fd3761d73d9af8bcf PatchWorks http://patchwork.kernel.org/patch/38244/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=8a333860f6d99652489c3b0fd3761d73d9af8bcf -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Few more omap fixes for 2.6.31
Hi all, Here are few more fixes for omap for review. Regards, Tony --- Janboe Ye (1): OMAP3: Fix omap3 sram virtual addres overlap vmalloc space after increasing vmalloc size Roger Quadros (2): OMAP3: RX51: Define TWL4030 USB transceiver in board file OMAP: GPIO: Fix incorrect gpio_get logic for output GPIOs Sergio Aguirre (1): OMAP3: Overo: Fix smsc911x platform device resource value Vikram Pandita (1): OMAP2/3: DMA errata correction arch/arm/mach-omap2/board-overo.c|2 - arch/arm/mach-omap2/board-rx51-peripherals.c |5 ++ arch/arm/plat-omap/dma.c |4 +- arch/arm/plat-omap/gpio.c| 68 -- arch/arm/plat-omap/sram.c|4 +- 5 files changed, 75 insertions(+), 8 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP: GPIO: Fix incorrect gpio_get logic for output GPIOs
From: Roger Quadros ext-roger.quad...@nokia.com
gpio_get() should return DATAIN register value when the GPIO
is configured as input whereas it should return DATAOUT register
value when the GPIO is configured as output.
Now /sys/kernel/debug/gpio shows proper values for output GPIOs
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/gpio.c | 68 ++---
1 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 26b387c..e702b88 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -476,14 +476,12 @@ static void _set_gpio_dataout(struct gpio_bank *bank, int
gpio, int enable)
__raw_writel(l, reg);
}
-static int __omap_get_gpio_datain(int gpio)
+static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
{
- struct gpio_bank *bank;
void __iomem *reg;
if (check_gpio(gpio) 0)
return -EINVAL;
- bank = get_gpio_bank(gpio);
reg = bank-base;
switch (bank-method) {
#ifdef CONFIG_ARCH_OMAP1
@@ -524,6 +522,53 @@ static int __omap_get_gpio_datain(int gpio)
(1 get_gpio_index(gpio))) != 0;
}
+static int _get_gpio_dataout(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg;
+
+ if (check_gpio(gpio) 0)
+ return -EINVAL;
+ reg = bank-base;
+
+ switch (bank-method) {
+#ifdef CONFIG_ARCH_OMAP1
+ case METHOD_MPUIO:
+ reg += OMAP_MPUIO_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP15XX
+ case METHOD_GPIO_1510:
+ reg += OMAP1510_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP16XX
+ case METHOD_GPIO_1610:
+ reg += OMAP1610_GPIO_DATAOUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP730
+ case METHOD_GPIO_730:
+ reg += OMAP730_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#ifdef CONFIG_ARCH_OMAP850
+ case METHOD_GPIO_850:
+ reg += OMAP850_GPIO_DATA_OUTPUT;
+ break;
+#endif
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) || \
+ defined(CONFIG_ARCH_OMAP4)
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_DATAOUT;
+ break;
+#endif
+ default:
+ return -EINVAL;
+ }
+
+ return (__raw_readl(reg) (1 get_gpio_index(gpio))) != 0;
+}
+
#define MOD_REG_BIT(reg, bit_mask, set)\
do { \
int l = __raw_readl(base + reg); \
@@ -1350,9 +1395,24 @@ static int gpio_input(struct gpio_chip *chip, unsigned
offset)
return 0;
}
+static int gpio_is_input(struct gpio_bank *bank, int mask);
+
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
- return __omap_get_gpio_datain(chip-base + offset);
+ struct gpio_bank *bank;
+ void __iomem *reg;
+ int gpio;
+ u32 mask;
+
+ gpio = chip-base + offset;
+ bank = get_gpio_bank(gpio);
+ reg = bank-base;
+ mask = 1 get_gpio_index(gpio);
+
+ if (gpio_is_input(bank, mask))
+ return _get_gpio_datain(bank, gpio);
+ else
+ return _get_gpio_dataout(bank, gpio);
}
static int gpio_output(struct gpio_chip *chip, unsigned offset, int value)
--
To unsubscribe from this list: send the line unsubscribe 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/5] OMAP2/3: DMA errata correction
From: Vikram Pandita vikram.pand...@ti.com
This errata is valid for:
OMAP2420 Errata 1.85 Impacts all 2420 ES rev
OMAP2430 Errata 1.10 Impacts only ES1.0
Description: DMA may hang when several channels are used in parallel
OMAP3430: Not impacted, so remove the errata fix for omap3
Fixed issue reported on cpu_is_omap24xx check reported by Nishant Kamat
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Reviewed-by: Nishant Kamat nska...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/dma.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7677a4a..e3ac94f 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -946,7 +946,9 @@ void omap_start_dma(int lch)
cur_lch = next_lch;
} while (next_lch != -1);
- } else if (cpu_class_is_omap2()) {
+ } else if (cpu_is_omap242x() ||
+ (cpu_is_omap243x() omap_type() = OMAP2430_REV_ES1_0)) {
+
/* Errata: Need to write lch even if not using chaining */
dma_write(lch, CLNK_CTRL(lch));
}
--
To unsubscribe from this list: send the line unsubscribe 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/5] OMAP3: Fix omap3 sram virtual addres overlap vmalloc space after increasing vmalloc size
From: Janboe Ye yuan-bo...@motorola.com commit e85c205ac1427f2405021a36f083280ff0d0a35e increase vmalloc size. vmalloc space will overlap with OMAP3 sram virtual address. Signed-off-by: Li Hong Mei hong-mei...@motorola.com Signed-off-by: Janboe Ye yuan-bo...@motorola.com Reviewed-by: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/sram.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index 4ea7380..2890b11 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -44,9 +44,9 @@ #define OMAP2_SRAM_VA 0xe300 #define OMAP2_SRAM_PUB_VA (OMAP2_SRAM_VA + 0x800) #define OMAP3_SRAM_PA 0x4020 -#define OMAP3_SRAM_VA 0xd700 +#define OMAP3_SRAM_VA 0xe300 #define OMAP3_SRAM_PUB_PA 0x40208000 -#define OMAP3_SRAM_PUB_VA 0xd7008000 +#define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000) #define OMAP4_SRAM_PA 0x4020 /*0x402f*/ #define OMAP4_SRAM_VA 0xd700 /*0xd70f*/ -- To unsubscribe from this list: send the line unsubscribe 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/15] OMAP: Add VRAM manager
Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:
- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations
The upcoming DSS2 uses VRAM manager.
VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/io.c |2 +
arch/arm/plat-omap/Kconfig |3 +
arch/arm/plat-omap/Makefile|1 +
arch/arm/plat-omap/include/mach/vram.h | 63 +++
arch/arm/plat-omap/sram.c |8 +
arch/arm/plat-omap/vram.c | 655
6 files changed, 732 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vram.h
create mode 100644 arch/arm/plat-omap/vram.c
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 7a54e12..e37f736 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -32,6 +32,7 @@
#include mach/sram.h
#include mach/sdrc.h
#include mach/gpmc.h
+#include mach/vram.h
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdev is ready */
#include clock.h
@@ -240,6 +241,7 @@ void __init omap2_map_common_io(void)
omap2_check_revision();
omap_sram_init();
omapfb_reserve_sdram();
+ omap_vram_reserve_sdram();
}
/*
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index efe85d0..ca06037 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -183,6 +183,9 @@ config OMAP_SERIAL_WAKE
to data on the serial RX line. This allows you to wake the
system from serial console.
+config OMAP2_VRAM
+ bool
+
endmenu
endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a832795..0472bbe 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -25,3 +25,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
+obj-$(CONFIG_OMAP2_VRAM) += vram.o
diff --git a/arch/arm/plat-omap/include/mach/vram.h
b/arch/arm/plat-omap/include/mach/vram.h
new file mode 100644
index 000..fe72f81
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vram.h
@@ -0,0 +1,63 @@
+/*
+ * VRAM manager for OMAP
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@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, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRAM_H__
+#define __OMAP_VRAM_H__
+
+#include linux/autoconf.h
+#include linux/types.h
+
+#define OMAP_VRAM_MEMTYPE_SDRAM0
+#define OMAP_VRAM_MEMTYPE_SRAM 1
+#define OMAP_VRAM_MEMTYPE_MAX 1
+
+extern int omap_vram_add_region(unsigned long paddr, size_t size);
+extern int omap_vram_free(unsigned long paddr, size_t size);
+extern int omap_vram_alloc(int mtype, size_t size, unsigned long *paddr);
+extern int omap_vram_reserve(unsigned long paddr, size_t size);
+extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
+ unsigned long *largest_free_block);
+
+#ifdef CONFIG_OMAP2_VRAM
+extern void omap_vram_set_sdram_vram(u32 size, u32 start);
+extern void omap_vram_set_sram_vram(u32 size, u32 start);
+
+extern void omap_vram_reserve_sdram(void);
+extern unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+ unsigned long size_avail);
+#else
+static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
+static inline void omap_vram_set_sram_vram(u32 size, u32 start) { }
+
+static inline void omap_vram_reserve_sdram(void) { }
+static inline unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned
[PATCH 05/15] OMAP: DSS2: Documentation for DSS2
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- Documentation/arm/OMAP/DSS | 317 1 files changed, 317 insertions(+), 0 deletions(-) create mode 100644 Documentation/arm/OMAP/DSS diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS new file mode 100644 index 000..0af0e9e --- /dev/null +++ b/Documentation/arm/OMAP/DSS @@ -0,0 +1,317 @@ +OMAP2/3 Display Subsystem +- + +This is an almost total rewrite of the OMAP FB driver in drivers/video/omap +(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, +TV-out and multiple display support, but there are lots of small improvements +also. + +The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB, +panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live +currently side by side, you can choose which one to use. + +Features + + +Working and tested features include: + +- MIPI DPI (parallel) output +- MIPI DSI output in command mode +- MIPI DBI (RFBI) output +- SDI output +- TV output +- All pieces can be compiled as a module or inside kernel +- Use DISPC to update any of the outputs +- Use CPU to update RFBI or DSI output +- OMAP DISPC planes +- RGB16, RGB24 packed, RGB24 unpacked +- YUV2, UYVY +- Scaling +- Adjusting DSS FCK to find a good pixel clock +- Use DSI DPLL to create DSS FCK + +Tested boards include: +- OMAP3 SDP board +- Beagle board +- N810 + +omapdss driver +-- + +The DSS driver does not itself have any support for Linux framebuffer, V4L or +such like the current ones, but it has an internal kernel API that upper level +drivers can use. + +The DSS driver models OMAP's overlays, overlay managers and displays in a +flexible way to enable non-common multi-display configuration. In addition to +modelling the hardware overlays, omapdss supports virtual overlays and overlay +managers. These can be used when updating a display with CPU or system DMA. + +Panel and controller drivers + + +The drivers implement panel or controller specific functionality and are not +usually visible to users except through omapfb driver. They register +themselves to the DSS driver. + +omapfb driver +- + +The omapfb driver implements arbitrary number of standard linux framebuffers. +These framebuffers can be routed flexibly to any overlays, thus allowing very +dynamic display architecture. + +The driver exports some omapfb specific ioctls, which are compatible with the +ioctls in the old driver. + +The rest of the non standard features are exported via sysfs. Whether the final +implementation will use sysfs, or ioctls, is still open. + +V4L2 drivers + + +V4L2 is being implemented in TI. + +From omapdss point of view the V4L2 drivers should be similar to framebuffer +driver. + +Architecture + + +Some clarification what the different components do: + +- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the + pixel data for the image. Framebuffer has width and height and color + depth. +- Overlay defines where the pixels are read from and where they go on the + screen. The overlay may be smaller than framebuffer, thus displaying only + part of the framebuffer. The position of the overlay may be changed if + the overlay is smaller than the display. +- Overlay manager combines the overlays in to one image and feeds them to + display. +- Display is the actual physical display device. + +A framebuffer can be connected to multiple overlays to show the same pixel data +on all of the overlays. Note that in this case the overlay input sizes must be +the same, but, in case of video overlays, the output size can be different. Any +framebuffer can be connected to any overlay. + +An overlay can be connected to one overlay manager. Also DISPC overlays can be +connected only to DISPC overlay managers, and virtual overlays can be only +connected to virtual overlays. + +An overlay manager can be connected to one display. There are certain +restrictions which kinds of displays an overlay manager can be connected: + +- DISPC TV overlay manager can be only connected to TV display. +- Virtual overlay managers can only be connected to DBI or DSI displays. +- DISPC LCD overlay manager can be connected to all displays, except TV + display. + +Sysfs +- +The sysfs interface is mainly used for testing. I don't think sysfs +interface is the best for this in the final version, but I don't quite know +what would be the best interfaces for these things. + +The sysfs interface is divided to two parts: DSS and FB. + +/sys/class/graphics/fb? directory: +mirror 0=off, 1=on +rotate Rotation 0-3 for 0, 90, 180, 270 degrees +rotate_type0 = DMA rotation, 1 = VRFB rotation +overlays List of overlay numbers to which framebuffer pixels go +phys_addr Physical
[PATCH 07/15] OMAP: DSS2: VENC driver
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/venc.c | 797
1 files changed, 797 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/venc.c
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
new file mode 100644
index 000..091ecc4
--- /dev/null
+++ b/drivers/video/omap2/dss/venc.c
@@ -0,0 +1,797 @@
+/*
+ * linux/drivers/video/omap2/dss/venc.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * VENC settings from TI's DSS driver
+ *
+ * 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/.
+ */
+
+#define DSS_SUBSYS_NAME VENC
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/string.h
+#include linux/seq_file.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+
+#include mach/display.h
+#include mach/cpu.h
+
+#include dss.h
+
+#define VENC_BASE 0x48050C00
+
+/* Venc registers */
+#define VENC_REV_ID0x00
+#define VENC_STATUS0x04
+#define VENC_F_CONTROL 0x08
+#define VENC_VIDOUT_CTRL 0x10
+#define VENC_SYNC_CTRL 0x14
+#define VENC_LLEN 0x1C
+#define VENC_FLENS 0x20
+#define VENC_HFLTR_CTRL0x24
+#define VENC_CC_CARR_WSS_CARR 0x28
+#define VENC_C_PHASE 0x2C
+#define VENC_GAIN_U0x30
+#define VENC_GAIN_V0x34
+#define VENC_GAIN_Y0x38
+#define VENC_BLACK_LEVEL 0x3C
+#define VENC_BLANK_LEVEL 0x40
+#define VENC_X_COLOR 0x44
+#define VENC_M_CONTROL 0x48
+#define VENC_BSTAMP_WSS_DATA 0x4C
+#define VENC_S_CARR0x50
+#define VENC_LINE210x54
+#define VENC_LN_SEL0x58
+#define VENC_L21__WC_CTL 0x5C
+#define VENC_HTRIGGER_VTRIGGER 0x60
+#define VENC_SAVID__EAVID 0x64
+#define VENC_FLEN__FAL 0x68
+#define VENC_LAL__PHASE_RESET 0x6C
+#define VENC_HS_INT_START_STOP_X 0x70
+#define VENC_HS_EXT_START_STOP_X 0x74
+#define VENC_VS_INT_START_X0x78
+#define VENC_VS_INT_STOP_X__VS_INT_START_Y 0x7C
+#define VENC_VS_INT_STOP_Y__VS_EXT_START_X 0x80
+#define VENC_VS_EXT_STOP_X__VS_EXT_START_Y 0x84
+#define VENC_VS_EXT_STOP_Y 0x88
+#define VENC_AVID_START_STOP_X 0x90
+#define VENC_AVID_START_STOP_Y 0x94
+#define VENC_FID_INT_START_X__FID_INT_START_Y 0xA0
+#define VENC_FID_INT_OFFSET_Y__FID_EXT_START_X 0xA4
+#define VENC_FID_EXT_START_Y__FID_EXT_OFFSET_Y 0xA8
+#define VENC_TVDETGP_INT_START_STOP_X 0xB0
+#define VENC_TVDETGP_INT_START_STOP_Y 0xB4
+#define VENC_GEN_CTRL 0xB8
+#define VENC_OUTPUT_CONTROL0xC4
+#define VENC_OUTPUT_TEST 0xC8
+#define VENC_DAC_B__DAC_C 0xC8
+
+struct venc_config {
+ u32 f_control;
+ u32 vidout_ctrl;
+ u32 sync_ctrl;
+ u32 llen;
+ u32 flens;
+ u32 hfltr_ctrl;
+ u32 cc_carr_wss_carr;
+ u32 c_phase;
+ u32 gain_u;
+ u32 gain_v;
+ u32 gain_y;
+ u32 black_level;
+ u32 blank_level;
+ u32 x_color;
+ u32 m_control;
+ u32 bstamp_wss_data;
+ u32 s_carr;
+ u32 line21;
+ u32 ln_sel;
+ u32 l21__wc_ctl;
+ u32 htrigger_vtrigger;
+ u32 savid__eavid;
+ u32 flen__fal;
+ u32 lal__phase_reset;
+ u32 hs_int_start_stop_x;
+ u32 hs_ext_start_stop_x;
+ u32 vs_int_start_x;
+ u32 vs_int_stop_x__vs_int_start_y;
+ u32 vs_int_stop_y__vs_ext_start_x;
+ u32 vs_ext_stop_x__vs_ext_start_y;
+ u32 vs_ext_stop_y;
+ u32 avid_start_stop_x;
+ u32 avid_start_stop_y;
+ u32 fid_int_start_x__fid_int_start_y;
+ u32
[PATCH 02/15] OMAP: OMAPFB: add omapdss device
The upcoming new display subsystem driver is divided to two devices,
omapdss and omapfb, of which omapdss handles the actual hardware.
This patch adds a dummy omapdss platform device for the current omapfb
driver, which is then used to get the clocks. This will make it possible
for the current and the new display drivers to co-exist.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/clock24xx.c |8
arch/arm/mach-omap2/clock34xx.c | 10 +-
drivers/video/omap/dispc.c | 19 ---
3 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 44de027..402a3d4 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, mdm_ick, mdm_ick, CK_243X),
CLK(NULL, mdm_osc_ck, mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK(omapfb, ick, dss_ick, CK_243X | CK_242X),
- CLK(omapfb, dss1_fck, dss1_fck, CK_243X | CK_242X),
- CLK(omapfb, dss2_fck, dss2_fck, CK_243X | CK_242X),
- CLK(omapfb, tv_fck, dss_54m_fck, CK_243X | CK_242X),
+ CLK(omapdss, ick, dss_ick, CK_243X | CK_242X),
+ CLK(omapdss, dss1_fck, dss1_fck, CK_243X | CK_242X),
+ CLK(omapdss, dss2_fck, dss2_fck, CK_243X | CK_242X),
+ CLK(omapdss, tv_fck, dss_54m_fck, CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_243X | CK_242X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 045da92..dd7bba2 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -200,11 +200,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_343X),
CLK(NULL, sha11_ick,sha11_ick, CK_343X),
CLK(NULL, des1_ick, des1_ick, CK_343X),
- CLK(omapfb, dss1_fck, dss1_alwon_fck, CK_343X),
- CLK(omapfb, tv_fck, dss_tv_fck,CK_343X),
- CLK(omapfb, video_fck,dss_96m_fck, CK_343X),
- CLK(omapfb, dss2_fck, dss2_alwon_fck, CK_343X),
- CLK(omapfb, ick, dss_ick, CK_343X),
+ CLK(omapdss, dss1_fck, dss1_alwon_fck, CK_343X),
+ CLK(omapdss, tv_fck, dss_tv_fck,CK_343X),
+ CLK(omapdss, video_fck,dss_96m_fck, CK_343X),
+ CLK(omapdss, dss2_fck, dss2_alwon_fck, CK_343X),
+ CLK(omapdss, ick, dss_ick, CK_343X),
CLK(NULL, cam_mclk, cam_mclk, CK_343X),
CLK(NULL, cam_ick, cam_ick, CK_343X),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 06438d0..cde3d18 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -24,6 +24,7 @@
#include linux/vmalloc.h
#include linux/clk.h
#include linux/io.h
+#include linux/platform_device.h
#include mach/sram.h
#include mach/board.h
@@ -188,6 +189,11 @@ static struct {
struct omapfb_color_key color_key;
} dispc;
+static struct platform_device omapdss_device = {
+ .name = omapdss,
+ .id = -1,
+};
+
static void enable_lcd_clocks(int enable);
static void inline dispc_write_reg(int idx, u32 val)
@@ -907,20 +913,20 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
static int get_dss_clocks(void)
{
- dispc.dss_ick = clk_get(dispc.fbdev-dev, ick);
+ dispc.dss_ick = clk_get(omapdss_device.dev, ick);
if (IS_ERR(dispc.dss_ick)) {
dev_err(dispc.fbdev-dev, can't get ick\n);
return PTR_ERR(dispc.dss_ick);
}
- dispc.dss1_fck = clk_get(dispc.fbdev-dev, dss1_fck);
+ dispc.dss1_fck = clk_get(omapdss_device.dev, dss1_fck);
if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev-dev, can't get dss1_fck\n);
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
- dispc.dss_54m_fck = clk_get(dispc.fbdev-dev, tv_fck);
+ dispc.dss_54m_fck = clk_get(omapdss_device.dev, tv_fck);
if (IS_ERR(dispc.dss_54m_fck)) {
dev_err(dispc.fbdev-dev, can't get tv_fck\n);
clk_put(dispc.dss_ick);
@@ -1371,6 +1377,12 @@ static int omap_dispc_init(struct omapfb_device *fbdev,
int ext_mode,
int skip_init = 0;
int i;
+ r = platform_device_register(omapdss_device);
+ if (r) {
+ dev_err(fbdev-dev, can't register omapdss device\n);
+ return r;
+ }
+
memset(dispc, 0, sizeof(dispc));
[PATCH 00/15] OMAP: DSS intro
This patch set implement new display subsystem driver (DSS2) and omapfb driver for OMAP2/3. The patches can also be found from http://gitorious.org/linux-omap-dss2/linux The patches include DSS documentation patch that includes more instructions for module parameters, sysfs files etc. The patches enable DSS2 for SDP, Beagle and Overo boards. I don't currently have any OMAP2 board to test DSS2, but it has worked on OMAP2 and the possible fixes needed should be minimal. OMAP1 is not supported, and so the old DSS needs to be used on OMAP1 boards. DSS2 is partly based on the old omapfb driver by Imre Deak, and Imre has also contributed to DSS2 quite a bit. Ville Syrjälä has been contributing to scaling and tv-out work. Also some contributions have been made by Hardik Shah, Vaibhav Hiremath, and perhaps some others that I have forgotten =). --- [PATCH 01/15] OMAP: OMAPFB: split omapfb.h [PATCH 02/15] OMAP: OMAPFB: add omapdss device [PATCH 03/15] OMAP: Add VRAM manager [PATCH 04/15] OMAP: Add support for VRFB rotation engine [PATCH 05/15] OMAP: DSS2: Documentation for DSS2 [PATCH 06/15] OMAP: DSS2: Display Subsystem Driver core [PATCH 07/15] OMAP: DSS2: VENC driver [PATCH 08/15] OMAP: DSS2: RFBI driver [PATCH 09/15] OMAP: DSS2: SDI driver [PATCH 10/15] OMAP: DSS2: DSI driver [PATCH 11/15] OMAP: DSS2: omapfb driver [PATCH 12/15] OMAP: DSS2: Add panel drivers [PATCH 13/15] OMAP: SDP: Enable DSS2 for OMAP3 SDP board [PATCH 14/15] OMAP: Beagle: Enable DSS2 for Beagle board [PATCH 15/15] OMAP: Overo: Enable DSS2 for Overo --- Documentation/arm/OMAP/DSS | 317 ++ arch/arm/configs/omap3_beagle_defconfig| 26 +- arch/arm/configs/omap_3430sdp_defconfig| 31 +- arch/arm/configs/overo_defconfig | 265 +-- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-3430sdp.c| 171 +- arch/arm/mach-omap2/board-n800.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c| 119 +- arch/arm/mach-omap2/board-overo.c | 149 +- arch/arm/mach-omap2/clock24xx.c|8 +- arch/arm/mach-omap2/clock34xx.c| 10 +- arch/arm/mach-omap2/io.c |4 +- arch/arm/plat-omap/Kconfig |6 + arch/arm/plat-omap/Makefile|2 + arch/arm/plat-omap/fb.c| 41 +- arch/arm/plat-omap/include/mach/display.h | 542 +++ arch/arm/plat-omap/include/mach/omapfb.h | 398 --- arch/arm/plat-omap/include/mach/vram.h | 63 + arch/arm/plat-omap/include/mach/vrfb.h | 46 + arch/arm/plat-omap/sram.c |8 + arch/arm/plat-omap/vram.c | 655 arch/arm/plat-omap/vrfb.c | 281 ++ drivers/video/Kconfig |1 + drivers/video/Makefile |1 + drivers/video/omap/Kconfig |5 +- drivers/video/omap/blizzard.c |2 +- drivers/video/omap/dispc.c | 21 +- drivers/video/omap/hwa742.c|2 +- drivers/video/omap/lcd_2430sdp.c |2 +- drivers/video/omap/lcd_ams_delta.c |2 +- drivers/video/omap/lcd_apollon.c |2 +- drivers/video/omap/lcd_h3.c|2 +- drivers/video/omap/lcd_h4.c|2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |2 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c |2 +- drivers/video/omap/lcd_omap3beagle.c |2 +- drivers/video/omap/lcd_omap3evm.c |2 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c|2 +- drivers/video/omap/lcd_palmtt.c|2 +- drivers/video/omap/lcd_palmz71.c |2 +- drivers/video/omap/lcdc.c |3 +- drivers/video/omap/omapfb.h| 227 ++ drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c |3 +- drivers/video/omap/sossi.c |2 +- drivers/video/omap2/Kconfig|3 + drivers/video/omap2/Makefile |3 + drivers/video/omap2/displays/Kconfig | 22 + drivers/video/omap2/displays/Makefile |3 + drivers/video/omap2/displays/panel-generic.c | 104 +
[PATCH 08/15] OMAP: DSS2: RFBI driver
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/rfbi.c | 1310
1 files changed, 1310 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/rfbi.c
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
new file mode 100644
index 000..9dd2349
--- /dev/null
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -0,0 +1,1310 @@
+/*
+ * linux/drivers/video/omap2/dss/rfbi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * 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/.
+ */
+
+#define DSS_SUBSYS_NAME RFBI
+
+#include linux/kernel.h
+#include linux/dma-mapping.h
+#include linux/vmalloc.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/kfifo.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+#include linux/seq_file.h
+
+#include mach/board.h
+#include mach/display.h
+#include dss.h
+
+/*#define MEASURE_PERF*/
+
+#define RFBI_BASE 0x48050800
+
+struct rfbi_reg { u16 idx; };
+
+#define RFBI_REG(idx) ((const struct rfbi_reg) { idx })
+
+#define RFBI_REVISION RFBI_REG(0x)
+#define RFBI_SYSCONFIG RFBI_REG(0x0010)
+#define RFBI_SYSSTATUS RFBI_REG(0x0014)
+#define RFBI_CONTROL RFBI_REG(0x0040)
+#define RFBI_PIXEL_CNT RFBI_REG(0x0044)
+#define RFBI_LINE_NUMBER RFBI_REG(0x0048)
+#define RFBI_CMD RFBI_REG(0x004c)
+#define RFBI_PARAM RFBI_REG(0x0050)
+#define RFBI_DATA RFBI_REG(0x0054)
+#define RFBI_READ RFBI_REG(0x0058)
+#define RFBI_STATUSRFBI_REG(0x005c)
+
+#define RFBI_CONFIG(n) RFBI_REG(0x0060 + (n)*0x18)
+#define RFBI_ONOFF_TIME(n) RFBI_REG(0x0064 + (n)*0x18)
+#define RFBI_CYCLE_TIME(n) RFBI_REG(0x0068 + (n)*0x18)
+#define RFBI_DATA_CYCLE1(n)RFBI_REG(0x006c + (n)*0x18)
+#define RFBI_DATA_CYCLE2(n)RFBI_REG(0x0070 + (n)*0x18)
+#define RFBI_DATA_CYCLE3(n)RFBI_REG(0x0074 + (n)*0x18)
+
+#define RFBI_VSYNC_WIDTH RFBI_REG(0x0090)
+#define RFBI_HSYNC_WIDTH RFBI_REG(0x0094)
+
+#define RFBI_CMD_FIFO_LEN_BYTES (16 * sizeof(struct update_param))
+
+#define REG_FLD_MOD(idx, val, start, end) \
+ rfbi_write_reg(idx, FLD_MOD(rfbi_read_reg(idx), val, start, end))
+
+/* To work around an RFBI transfer rate limitation */
+#define OMAP_RFBI_RATE_LIMIT1
+
+enum omap_rfbi_cycleformat {
+ OMAP_DSS_RFBI_CYCLEFORMAT_1_1 = 0,
+ OMAP_DSS_RFBI_CYCLEFORMAT_2_1 = 1,
+ OMAP_DSS_RFBI_CYCLEFORMAT_3_1 = 2,
+ OMAP_DSS_RFBI_CYCLEFORMAT_3_2 = 3,
+};
+
+enum omap_rfbi_datatype {
+ OMAP_DSS_RFBI_DATATYPE_12 = 0,
+ OMAP_DSS_RFBI_DATATYPE_16 = 1,
+ OMAP_DSS_RFBI_DATATYPE_18 = 2,
+ OMAP_DSS_RFBI_DATATYPE_24 = 3,
+};
+
+enum omap_rfbi_parallelmode {
+ OMAP_DSS_RFBI_PARALLELMODE_8 = 0,
+ OMAP_DSS_RFBI_PARALLELMODE_9 = 1,
+ OMAP_DSS_RFBI_PARALLELMODE_12 = 2,
+ OMAP_DSS_RFBI_PARALLELMODE_16 = 3,
+};
+
+enum update_cmd {
+ RFBI_CMD_UPDATE = 0,
+ RFBI_CMD_SYNC = 1,
+};
+
+static int rfbi_convert_timings(struct rfbi_timings *t);
+static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
+static void process_cmd_fifo(void);
+
+static struct {
+ void __iomem*base;
+
+ unsigned long l4_khz;
+
+ enum omap_rfbi_datatype datatype;
+ enum omap_rfbi_parallelmode parallelmode;
+
+ enum omap_rfbi_te_mode te_mode;
+ int te_enabled;
+
+ void (*framedone_callback)(void *data);
+ void *framedone_callback_data;
+
+ struct omap_dss_device *dssdev[2];
+
+ struct kfifo *cmd_fifo;
+ spinlock_tcmd_lock;
+ struct completion cmd_done;
+ atomic_t cmd_fifo_full;
+ atomic_t cmd_pending;
+#ifdef MEASURE_PERF
+ unsigned perf_bytes;
+ ktime_t perf_setup_time;
+ ktime_t perf_start_time;
+#endif
+} rfbi;
+
+struct update_region {
+ u16 x;
+ u16 y;
+ u16 w;
+ u16 h;
+};
+
+struct update_param {
+ u8 rfbi_module;
+ u8 cmd;
+
+ union {
+ struct update_region r;
+ struct completion *sync;
+ } par;
+};
+
+static inline void rfbi_write_reg(const struct rfbi_reg idx, u32 val)
+{
+
[PATCH 09/15] OMAP: DSS2: SDI driver
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/sdi.c | 370 +
1 files changed, 370 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/sdi.c
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
new file mode 100644
index 000..2f4d226
--- /dev/null
+++ b/drivers/video/omap2/dss/sdi.c
@@ -0,0 +1,370 @@
+/*
+ * linux/drivers/video/omap2/dss/sdi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@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/.
+ */
+
+#define DSS_SUBSYS_NAME SDI
+
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/io.h
+
+#include mach/board.h
+#include mach/display.h
+#include dss.h
+
+#define CONTROL_PADCONF_BASE 0x48002000
+
+#define OMAP_SDI_PAD_DIS(pe, pu) ((7 0) | /* MODE 7 = safe */ \
+(((pe) ? 1 : 0) 3) | /* PULL_ENA */ \
+(((pu) ? 1 : 0) 4) | /* PULL_UP */ \
+(1 8))/* INPUT_EN */
+
+#define OMAP_SDI_PAD_EN (1 0) /* MODE 1 =
SDI_xx */
+
+#define OMAP_SDI_PAD_MASK OMAP_SDI_PAD_DIS(1, 1)
+
+static struct {
+ bool skip_init;
+ bool update_enabled;
+} sdi;
+
+/* CONTROL_PADCONF_DSS_DATAXX */
+static const u16 sdi_pads[] =
+{
+ 0x0f0, /* 10[ 7..0]:SDI_DAT1N */
+ 0x0f2, /* 10[15..0]:SDI_DAT1P */
+ 0x0f4, /* 12[ 7..0]:SDI_DAT2N */
+ 0x0f6, /* 12[15..0]:SDI_DAT2P */
+ 0x0f8, /* 14[ 7..0]:SDI_DAT3N */
+ 0x0fa, /* 14[15..0]:SDI_DAT3P */
+ 0x108, /* 22[ 7..0]:SDI_CLKN */
+ 0x10a, /* 22[15..0]:SDI_CLKP */
+};
+
+/*
+ * Check if bootloader / platform code has configured the SDI pads properly.
+ * This means it either configured all required pads for SDI mode, or that it
+ * left all the required pads unconfigured.
+ */
+static int sdi_pad_init(struct omap_dss_device *dssdev)
+{
+ unsigned req_map;
+ bool configured = false;
+ bool unconfigured = false;
+ int data_pairs;
+ int i;
+
+ data_pairs = dssdev-phy.sdi.datapairs;
+ req_map = (1 (data_pairs * 2)) - 1; /* data lanes */
+ req_map |= 3 6; /* clk lane */
+ for (i = 0; i ARRAY_SIZE(sdi_pads); i++) {
+ u32 reg;
+ u32 val;
+
+ if (!((1 i) req_map))
+ /* Ignore unneded pads. */
+ continue;
+ reg = CONTROL_PADCONF_BASE + sdi_pads[i];
+ val = omap_readw(reg);
+ switch (val 0x07) { /* pad mode */
+ case 1:
+ if (unconfigured)
+ break;
+ /* Is the pull configuration ok for SDI mode? */
+ if ((val OMAP_SDI_PAD_MASK) != OMAP_SDI_PAD_EN)
+ break;
+ configured = true;
+ break;
+ case 0:
+ case 7:
+ if (configured)
+ break;
+ unconfigured = true;
+ break;
+ default:
+ break;
+ }
+ }
+ if (i != ARRAY_SIZE(sdi_pads)) {
+ DSSERR(SDI: invalid pad configuration\n);
+ return -1;
+ }
+
+ return 0;
+}
+
+static void sdi_pad_config(struct omap_dss_device *dssdev, bool enable)
+{
+ int data_pairs;
+ bool pad_off_pe, pad_off_pu;
+ unsigned req_map;
+ int i;
+
+ data_pairs = dssdev-phy.sdi.datapairs;
+ pad_off_pe = dssdev-phy.sdi.pad_off_pe;
+ pad_off_pu = dssdev-phy.sdi.pad_off_pu;
+ req_map = (1 (data_pairs * 2)) - 1; /* data lanes */
+ req_map |= 3 6; /* clk lane */
+ for (i = 0; i ARRAY_SIZE(sdi_pads); i++) {
+ u32 reg;
+ u16 val;
+
+ if (!((1 i) req_map))
+ continue;
+ if (enable)
+ val = OMAP_SDI_PAD_EN;
+ else
+ val =
[PATCH 14/15] OMAP: Beagle: Enable DSS2 for Beagle board
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/configs/omap3_beagle_defconfig | 26 ++-
arch/arm/mach-omap2/board-omap3beagle.c | 119 ---
2 files changed, 116 insertions(+), 29 deletions(-)
diff --git a/arch/arm/configs/omap3_beagle_defconfig
b/arch/arm/configs/omap3_beagle_defconfig
index c4726f0..1740be3 100644
--- a/arch/arm/configs/omap3_beagle_defconfig
+++ b/arch/arm/configs/omap3_beagle_defconfig
@@ -792,10 +792,30 @@ CONFIG_FB_CFB_IMAGEBLIT=y
#
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
-CONFIG_FB_OMAP=y
-# CONFIG_FB_OMAP_LCDC_EXTERNAL 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_FB_OMAP_CONSISTENT_DMA_SIZE=2
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=6
+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=0
+
+#
+# OMAP2/3 Display Device Drivers
+#
+CONFIG_PANEL_GENERIC=y
+# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set
+# CONFIG_PANEL_SHARP_LS037V7DW01 is not set
+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
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index b6a68d5..d27c63f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -30,6 +30,7 @@
#include linux/regulator/machine.h
#include linux/i2c/twl4030.h
+#include linux/omapfb.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -44,6 +45,7 @@
#include mach/mux.h
#include mach/usb.h
#include mach/timer-gp.h
+#include mach/display.h
#include mmc-twl4030.h
@@ -106,6 +108,92 @@ static struct platform_device omap3beagle_nand_device = {
.resource = omap3beagle_nand_resource,
};
+/* DSS */
+
+static int beagle_enable_dvi(struct omap_dss_device *dssdev)
+{
+ if (dssdev-reset_gpio != -1)
+ gpio_set_value(dssdev-reset_gpio, 1);
+
+ return 0;
+}
+
+static void beagle_disable_dvi(struct omap_dss_device *dssdev)
+{
+ if (dssdev-reset_gpio != -1)
+ 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 int beagle_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void beagle_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+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,
+ .platform_enable = beagle_panel_enable_tv,
+ .platform_disable = beagle_panel_disable_tv,
+};
+
+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_vdda_dac_supply = {
+ .supply = vdda_dac,
+ .dev= beagle_dss_device.dev,
+};
+
+static struct regulator_consumer_supply beagle_vdds_dsi_supply = {
+ .supply = vdds_dsi,
+ .dev= beagle_dss_device.dev,
+};
+
+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 omap_uart_config omap3_beagle_uart_config __initdata = {
@@ -121,15 +209,6 @@ static struct twl4030_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,
};
[PATCH 12/15] OMAP: DSS2: Add panel drivers
- Generic panel
- Samsung LTE430WQ-F0C LCD Panel
- Sharp LS037V7DW01 LCD Panel
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/displays/Kconfig | 18 +++
drivers/video/omap2/displays/Makefile |3 +
drivers/video/omap2/displays/panel-generic.c | 104 +
.../omap2/displays/panel-samsung-lte430wq-f0c.c| 113 +++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 153
5 files changed, 391 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-generic.c
create mode 100644 drivers/video/omap2/displays/panel-samsung-lte430wq-f0c.c
create mode 100644 drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 8bdc33c..396905d 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,4 +1,22 @@
menu OMAP2/3 Display Device Drivers
depends on OMAP2_DSS
+config PANEL_GENERIC
+tristate Generic Panel
+help
+ Generic panel driver.
+ Used for DVI output for Beagle and OMAP3 SDP.
+
+config PANEL_SAMSUNG_LTE430WQ_F0C
+tristate Samsung LTE430WQ-F0C LCD Panel
+depends on OMAP2_DSS
+help
+ LCD Panel used on Overo Palo43
+
+config PANEL_SHARP_LS037V7DW01
+tristate Sharp LS037V7DW01 LCD Panel
+depends on OMAP2_DSS
+help
+ LCD Panel used in TI's SDP3430 and EVM boards
+
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index e69de29..a26bbd2 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
+obj-$(CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C) += panel-samsung-lte430wq-f0c.o
+obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
new file mode 100644
index 000..738147e
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -0,0 +1,104 @@
+/*
+ * Generic panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@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/module.h
+#include linux/delay.h
+
+#include mach/display.h
+
+static struct omap_video_timings generic_panel_timings = {
+ /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = 640,
+ .y_res = 480,
+ .pixel_clock= 23500,
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 7,
+};
+
+static int generic_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT;
+ dssdev-panel.timings = generic_panel_timings;
+
+ return 0;
+}
+
+static void generic_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int generic_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void generic_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+}
+
+static int generic_panel_suspend(struct omap_dss_device *dssdev)
+{
+ generic_panel_disable(dssdev);
+ return 0;
+}
+
+static int generic_panel_resume(struct omap_dss_device *dssdev)
+{
+ return generic_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver generic_driver = {
+ .probe = generic_panel_probe,
+ .remove = generic_panel_remove,
+
+ .enable = generic_panel_enable,
+ .disable= generic_panel_disable,
+ .suspend= generic_panel_suspend,
+ .resume = generic_panel_resume,
+
+ .driver = {
+ .name = generic_panel,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init generic_panel_drv_init(void)
+{
+ return omap_dss_register_driver(generic_driver);
+}
+
+static void __exit generic_panel_drv_exit(void)
+{
+
[PATCH 15/15] OMAP: Overo: Enable DSS2 for Overo
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- arch/arm/configs/overo_defconfig | 265 - arch/arm/mach-omap2/board-overo.c | 149 +++-- 2 files changed, 196 insertions(+), 218 deletions(-) diff --git a/arch/arm/configs/overo_defconfig b/arch/arm/configs/overo_defconfig index a57f9e4..93d911c 100644 --- a/arch/arm/configs/overo_defconfig +++ b/arch/arm/configs/overo_defconfig @@ -994,225 +994,76 @@ CONFIG_SSB_POSSIBLE=y # # CONFIG_MFD_CORE is not set # CONFIG_MFD_SM501 is not set +# CONFIG_MFD_ASIC3 is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set -# CONFIG_UCB1400_CORE is not set +# CONFIG_TPS65010 is not set +# CONFIG_TWL4030_CORE is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC6387XB is not set # CONFIG_MFD_TC6393XB is not set - -# -# Multimedia devices -# - -# -# Multimedia core support -# -CONFIG_VIDEO_DEV=m -CONFIG_VIDEO_V4L2_COMMON=m -CONFIG_VIDEO_ALLOW_V4L1=y -CONFIG_VIDEO_V4L1_COMPAT=y -CONFIG_DVB_CORE=m -CONFIG_VIDEO_MEDIA=m - -# -# Multimedia drivers -# -CONFIG_MEDIA_ATTACH=y -CONFIG_MEDIA_TUNER=m -# CONFIG_MEDIA_TUNER_CUSTOMIZE is not set -CONFIG_MEDIA_TUNER_SIMPLE=m -CONFIG_MEDIA_TUNER_TDA8290=m -CONFIG_MEDIA_TUNER_TDA827X=m -CONFIG_MEDIA_TUNER_TDA18271=m -CONFIG_MEDIA_TUNER_TDA9887=m -CONFIG_MEDIA_TUNER_TEA5761=m -CONFIG_MEDIA_TUNER_TEA5767=m -CONFIG_MEDIA_TUNER_MT20XX=m -CONFIG_MEDIA_TUNER_MT2060=m -CONFIG_MEDIA_TUNER_MT2266=m -CONFIG_MEDIA_TUNER_QT1010=m -CONFIG_MEDIA_TUNER_XC2028=m -CONFIG_MEDIA_TUNER_XC5000=m -CONFIG_MEDIA_TUNER_MXL5005S=m -CONFIG_VIDEO_V4L2=m -CONFIG_VIDEO_V4L1=m -CONFIG_VIDEO_TVEEPROM=m -CONFIG_VIDEO_TUNER=m -CONFIG_VIDEO_CAPTURE_DRIVERS=y -# CONFIG_VIDEO_ADV_DEBUG is not set -CONFIG_VIDEO_HELPER_CHIPS_AUTO=y -CONFIG_VIDEO_MSP3400=m -CONFIG_VIDEO_CS53L32A=m -CONFIG_VIDEO_WM8775=m -CONFIG_VIDEO_SAA711X=m -CONFIG_VIDEO_CX25840=m -CONFIG_VIDEO_CX2341X=m -# CONFIG_VIDEO_VIVI is not set -# CONFIG_VIDEO_CPIA is not set -# CONFIG_VIDEO_CPIA2 is not set -# CONFIG_VIDEO_SAA5246A is not set -# CONFIG_VIDEO_SAA5249 is not set -# CONFIG_TUNER_3036 is not set -# CONFIG_VIDEO_AU0828 is not set -CONFIG_V4L_USB_DRIVERS=y -CONFIG_USB_VIDEO_CLASS=m -CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y -# CONFIG_USB_GSPCA is not set -CONFIG_VIDEO_PVRUSB2=m -CONFIG_VIDEO_PVRUSB2_SYSFS=y -CONFIG_VIDEO_PVRUSB2_DVB=y -# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set -# CONFIG_VIDEO_EM28XX is not set -CONFIG_VIDEO_USBVISION=m -CONFIG_VIDEO_USBVIDEO=m -CONFIG_USB_VICAM=m -CONFIG_USB_IBMCAM=m -CONFIG_USB_KONICAWC=m -CONFIG_USB_QUICKCAM_MESSENGER=m -# CONFIG_USB_ET61X251 is not set -CONFIG_VIDEO_OVCAMCHIP=m -CONFIG_USB_W9968CF=m -CONFIG_USB_OV511=m -CONFIG_USB_SE401=m -CONFIG_USB_SN9C102=m -CONFIG_USB_STV680=m -# CONFIG_USB_ZC0301 is not set -CONFIG_USB_PWC=m -# CONFIG_USB_PWC_DEBUG is not set -CONFIG_USB_ZR364XX=m -# CONFIG_USB_STKWEBCAM is not set -# CONFIG_USB_S2255 is not set -# CONFIG_SOC_CAMERA is not set -# CONFIG_VIDEO_SH_MOBILE_CEU is not set -CONFIG_RADIO_ADAPTERS=y -# CONFIG_USB_DSBR is not set -# CONFIG_USB_SI470X is not set -CONFIG_DVB_CAPTURE_DRIVERS=y -# CONFIG_TTPCI_EEPROM is not set - -# -# Supported USB Adapters -# -CONFIG_DVB_USB=m -# CONFIG_DVB_USB_DEBUG is not set -CONFIG_DVB_USB_A800=m -CONFIG_DVB_USB_DIBUSB_MB=m -# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set -CONFIG_DVB_USB_DIBUSB_MC=m -CONFIG_DVB_USB_DIB0700=m -CONFIG_DVB_USB_UMT_010=m -CONFIG_DVB_USB_CXUSB=m -CONFIG_DVB_USB_M920X=m -CONFIG_DVB_USB_GL861=m -CONFIG_DVB_USB_AU6610=m -CONFIG_DVB_USB_DIGITV=m -CONFIG_DVB_USB_VP7045=m -CONFIG_DVB_USB_VP702X=m -CONFIG_DVB_USB_GP8PSK=m -CONFIG_DVB_USB_NOVA_T_USB2=m -CONFIG_DVB_USB_TTUSB2=m -CONFIG_DVB_USB_DTT200U=m -CONFIG_DVB_USB_OPERA1=m -CONFIG_DVB_USB_AF9005=m -CONFIG_DVB_USB_AF9005_REMOTE=m -# CONFIG_DVB_USB_DW2102 is not set -# CONFIG_DVB_USB_ANYSEE is not set -CONFIG_DVB_TTUSB_BUDGET=m -CONFIG_DVB_TTUSB_DEC=m -CONFIG_DVB_CINERGYT2=m -# CONFIG_DVB_CINERGYT2_TUNING is not set -# CONFIG_DVB_SIANO_SMS1XXX is not set - -# -# Supported FlexCopII (B2C2) Adapters -# -# CONFIG_DVB_B2C2_FLEXCOP is not set - -# -# Supported DVB Frontends -# - -# -# Customise DVB Frontends -# -# CONFIG_DVB_FE_CUSTOMISE is not set - -# -# DVB-S (satellite) frontends -# -CONFIG_DVB_CX24110=m -CONFIG_DVB_CX24123=m -CONFIG_DVB_MT312=m -CONFIG_DVB_S5H1420=m -CONFIG_DVB_STV0299=m -CONFIG_DVB_TDA8083=m -CONFIG_DVB_TDA10086=m -CONFIG_DVB_VES1X93=m -CONFIG_DVB_TUNER_ITD1000=m -CONFIG_DVB_TDA826X=m -CONFIG_DVB_TUA6100=m - -# -# DVB-T (terrestrial) frontends -# -CONFIG_DVB_SP8870=m -CONFIG_DVB_SP887X=m -CONFIG_DVB_CX22700=m -CONFIG_DVB_CX22702=m -# CONFIG_DVB_DRX397XD is not set -CONFIG_DVB_L64781=m -CONFIG_DVB_TDA1004X=m -CONFIG_DVB_NXT6000=m -CONFIG_DVB_MT352=m -CONFIG_DVB_ZL10353=m -CONFIG_DVB_DIB3000MB=m -CONFIG_DVB_DIB3000MC=m -CONFIG_DVB_DIB7000M=m -CONFIG_DVB_DIB7000P=m -CONFIG_DVB_TDA10048=m - -# -# DVB-C (cable) frontends -# -CONFIG_DVB_VES1820=m -CONFIG_DVB_TDA10021=m
[PATCH 01/15] OMAP: OMAPFB: split omapfb.h
Split arch/arm/plat-omap/include/mach/omapfb.h into two files: include/linux/omapfb.h - ioctls etc for userspace and some kernel stuff for board files drivers/video/omap/omapfb.h - for omapfb internal use This cleans up omapfb.h and also makes it easier for the upcoming new DSS driver to co-exist with the old driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-n800.c |2 +- arch/arm/mach-omap2/io.c |2 +- arch/arm/plat-omap/fb.c |2 +- arch/arm/plat-omap/include/mach/omapfb.h | 398 -- drivers/video/omap/blizzard.c|2 +- drivers/video/omap/dispc.c |2 +- drivers/video/omap/hwa742.c |2 +- drivers/video/omap/lcd_2430sdp.c |2 +- drivers/video/omap/lcd_ams_delta.c |2 +- drivers/video/omap/lcd_apollon.c |2 +- drivers/video/omap/lcd_h3.c |2 +- drivers/video/omap/lcd_h4.c |2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |2 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c|2 +- drivers/video/omap/lcd_omap3beagle.c |2 +- drivers/video/omap/lcd_omap3evm.c|2 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c |2 +- drivers/video/omap/lcd_palmtt.c |2 +- drivers/video/omap/lcd_palmz71.c |2 +- drivers/video/omap/lcdc.c|3 +- drivers/video/omap/omapfb.h | 227 + drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c|3 +- drivers/video/omap/sossi.c |2 +- include/linux/omapfb.h | 197 +++ 31 files changed, 455 insertions(+), 427 deletions(-) delete mode 100644 arch/arm/plat-omap/include/mach/omapfb.h create mode 100644 drivers/video/omap/omapfb.h create mode 100644 include/linux/omapfb.h diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index ed2a48a..6fbde33 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -14,6 +14,7 @@ #include linux/platform_device.h #include linux/input.h #include linux/clk.h +#include linux/omapfb.h #include linux/spi/spi.h #include linux/spi/ads7846.h @@ -32,7 +33,6 @@ #include mach/keypad.h #include mach/common.h #include mach/dsp_common.h -#include mach/omapfb.h #include mach/hwa742.h #include mach/lcd_mipid.h #include mach/mmc.h diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c index 23296e9..e2907ac 100644 --- a/arch/arm/mach-omap2/board-n800.c +++ b/arch/arm/mach-omap2/board-n800.c @@ -22,6 +22,7 @@ #include linux/interrupt.h #include linux/irq.h #include linux/i2c.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach-types.h #include asm/mach/arch.h @@ -34,7 +35,6 @@ #include mach/lcd_mipid.h #include mach/clock.h #include mach/menelaus.h -#include mach/omapfb.h #include mach/blizzard.h #include mach/onenand.h #include mach/board-nokia.h diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 3a86b0f..7a54e12 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -22,13 +22,13 @@ #include linux/init.h #include linux/io.h #include linux/clk.h +#include linux/omapfb.h #include asm/tlb.h #include asm/mach/map.h #include mach/mux.h -#include mach/omapfb.h #include mach/sram.h #include mach/sdrc.h #include mach/gpmc.h diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c index 3746222..40615a6 100644 --- a/arch/arm/plat-omap/fb.c +++ b/arch/arm/plat-omap/fb.c @@ -28,13 +28,13 @@ #include linux/platform_device.h #include linux/bootmem.h #include linux/io.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach/map.h #include mach/board.h #include mach/sram.h -#include mach/omapfb.h #if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE) diff --git a/arch/arm/plat-omap/include/mach/omapfb.h b/arch/arm/plat-omap/include/mach/omapfb.h deleted file mode 100644 index b226bdf..000 --- a/arch/arm/plat-omap/include/mach/omapfb.h +++ /dev/null @@ -1,398 +0,0 @@ -/* - * File: arch/arm/plat-omap/include/mach/omapfb.h - * - * Framebuffer driver for TI OMAP boards - * - * Copyright (C) 2004 Nokia Corporation - * Author: Imre Deak imre.d...@nokia.com - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any
[PATCH 4/5] OMAP3: Overo: Fix smsc911x platform device resource value
From: Sergio Aguirre saagui...@ti.com
Fixes a wrong setting of resource parameter list in
SMSC911x platform driver data structure for Overo case.
This fixes folowing warning when compiling for Overo board:
warning: initialization from incompatible pointer type
Introduced since commit id:
commit 172ef275444efa12d834fb9d1b1acdac92db47f7
Author: Steve Sakoman sako...@gmail.com
Date: Mon Feb 2 06:27:49 2009 +
ARM: Add SMSC911X support to Overo platform (V2)
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-overo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index dff5528..fec1bb1 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -146,7 +146,7 @@ static struct platform_device overo_smsc911x_device = {
.name = smsc911x,
.id = -1,
.num_resources = ARRAY_SIZE(overo_smsc911x_resources),
- .resource = overo_smsc911x_resources,
+ .resource = overo_smsc911x_resources,
.dev= {
.platform_data = overo_smsc911x_config,
},
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] OMAP3: RX51: Define TWL4030 USB transceiver in board file
From: Roger Quadros ext-roger.quad...@nokia.com
Add OTG transceiver to RX51 platform data to prevent kernel NULL pointer
dereference during MUSB initialisation.
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a0bf67..56d931a 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -278,6 +278,10 @@ static struct twl4030_gpio_platform_data rx51_gpio_data = {
.setup = rx51_twlgpio_setup,
};
+static struct twl4030_usb_data rx51_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
static struct twl4030_platform_data rx51_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -286,6 +290,7 @@ static struct twl4030_platform_data rx51_twldata = {
.gpio = rx51_gpio_data,
.keypad = rx51_kp_data,
.madc = rx51_madc_data,
+ .usb= rx51_usb_data,
.vaux1 = rx51_vaux1,
.vaux2 = rx51_vaux2,
--
To unsubscribe from this list: send the line unsubscribe 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 04/15] OMAP: Add support for VRFB rotation engine
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:
VRFB rotation engine is a block in OMAP2/3 that offers 12 independent
contexts that can be used for framebuffer rotation.
Each context has a backend area of real memory, where it stores the
pixels in undisclosed format. This memory is offered to users via 4
virtual memory areas, which see the same memory area in different
rotation angles (0, 90, 180 and 270 degrees).
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/plat-omap/Kconfig |3 +
arch/arm/plat-omap/Makefile|1 +
arch/arm/plat-omap/include/mach/vrfb.h | 46 +
arch/arm/plat-omap/vrfb.c | 281
4 files changed, 331 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vrfb.h
create mode 100644 arch/arm/plat-omap/vrfb.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ca06037..2d6ae55 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -186,6 +186,9 @@ config OMAP_SERIAL_WAKE
config OMAP2_VRAM
bool
+config OMAP2_VRFB
+ bool
+
endmenu
endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 0472bbe..462edf3 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -26,3 +26,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP2_VRAM) += vram.o
+obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
Can you please place this file under drivers/video?
diff --git a/arch/arm/plat-omap/include/mach/vrfb.h
b/arch/arm/plat-omap/include/mach/vrfb.h
new file mode 100644
index 000..8790612
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vrfb.h
@@ -0,0 +1,46 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@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, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRFB_H__
+#define __OMAP_VRFB_H__
+
+#define OMAP_VRFB_LINE_LEN 2048
+
+struct vrfb {
+ u8 context;
+ void __iomem *vaddr[4];
+ unsigned long paddr[4];
+ u16 xoffset;
+ u16 yoffset;
+ u8 bytespp;
+};
+
+extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_suspend_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_resume_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp);
+extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height,
+ unsigned bytespp, bool yuv_mode);
+extern void omap_vrfb_restore_context(void);
+
+#endif /* __VRFB_H */
diff --git a/arch/arm/plat-omap/vrfb.c b/arch/arm/plat-omap/vrfb.c
new file mode 100644
index 000..240058f
--- /dev/null
+++ b/arch/arm/plat-omap/vrfb.c
@@ -0,0 +1,281 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@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, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/ioport.h
+#include linux/io.h
+#include linux/bitops.h
+#include linux/mutex.h
+
+#include mach/io.h
+#include mach/vrfb.h
+/*#define DEBUG*/
+
+#ifdef DEBUG
+#define DBG(format, ...) pr_debug(VRFB: format, ## __VA_ARGS__)
+#else
+#define DBG(format, ...)
+#endif
+
+#define SMS_ROT_VIRT_BASE(context, rot) \
+ (((context = 4) ? 0xD000 : 0x7000) \
+ + (0x400 * (context)) \
+ + (0x100 * (rot)))
+
+#define OMAP_VRFB_SIZE
Re: [PATCH 01/15] OMAP: OMAPFB: split omapfb.h
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]: Split arch/arm/plat-omap/include/mach/omapfb.h into two files: include/linux/omapfb.h - ioctls etc for userspace and some kernel stuff for board files drivers/video/omap/omapfb.h - for omapfb internal use This cleans up omapfb.h and also makes it easier for the upcoming new DSS driver to co-exist with the old driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-n800.c |2 +- arch/arm/mach-omap2/io.c |2 +- arch/arm/plat-omap/fb.c |2 +- arch/arm/plat-omap/include/mach/omapfb.h | 398 -- drivers/video/omap/blizzard.c|2 +- drivers/video/omap/dispc.c |2 +- drivers/video/omap/hwa742.c |2 +- drivers/video/omap/lcd_2430sdp.c |2 +- drivers/video/omap/lcd_ams_delta.c |2 +- drivers/video/omap/lcd_apollon.c |2 +- drivers/video/omap/lcd_h3.c |2 +- drivers/video/omap/lcd_h4.c |2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |2 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c|2 +- drivers/video/omap/lcd_omap3beagle.c |2 +- drivers/video/omap/lcd_omap3evm.c|2 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c |2 +- drivers/video/omap/lcd_palmtt.c |2 +- drivers/video/omap/lcd_palmz71.c |2 +- drivers/video/omap/lcdc.c|3 +- drivers/video/omap/omapfb.h | 227 + drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c|3 +- drivers/video/omap/sossi.c |2 +- include/linux/omapfb.h | 197 +++ 31 files changed, 455 insertions(+), 427 deletions(-) delete mode 100644 arch/arm/plat-omap/include/mach/omapfb.h create mode 100644 drivers/video/omap/omapfb.h create mode 100644 include/linux/omapfb.h diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index ed2a48a..6fbde33 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -14,6 +14,7 @@ #include linux/platform_device.h #include linux/input.h #include linux/clk.h +#include linux/omapfb.h #include linux/spi/spi.h #include linux/spi/ads7846.h @@ -32,7 +33,6 @@ #include mach/keypad.h #include mach/common.h #include mach/dsp_common.h -#include mach/omapfb.h #include mach/hwa742.h #include mach/lcd_mipid.h #include mach/mmc.h diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c index 23296e9..e2907ac 100644 --- a/arch/arm/mach-omap2/board-n800.c +++ b/arch/arm/mach-omap2/board-n800.c @@ -22,6 +22,7 @@ #include linux/interrupt.h #include linux/irq.h #include linux/i2c.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach-types.h #include asm/mach/arch.h @@ -34,7 +35,6 @@ #include mach/lcd_mipid.h #include mach/clock.h #include mach/menelaus.h -#include mach/omapfb.h #include mach/blizzard.h #include mach/onenand.h #include mach/board-nokia.h diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 3a86b0f..7a54e12 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -22,13 +22,13 @@ #include linux/init.h #include linux/io.h #include linux/clk.h +#include linux/omapfb.h #include asm/tlb.h #include asm/mach/map.h #include mach/mux.h -#include mach/omapfb.h #include mach/sram.h #include mach/sdrc.h #include mach/gpmc.h diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c index 3746222..40615a6 100644 --- a/arch/arm/plat-omap/fb.c +++ b/arch/arm/plat-omap/fb.c @@ -28,13 +28,13 @@ #include linux/platform_device.h #include linux/bootmem.h #include linux/io.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach/map.h #include mach/board.h #include mach/sram.h -#include mach/omapfb.h #if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE) diff --git a/arch/arm/plat-omap/include/mach/omapfb.h b/arch/arm/plat-omap/include/mach/omapfb.h deleted file mode 100644 index b226bdf..000 --- a/arch/arm/plat-omap/include/mach/omapfb.h +++ /dev/null @@ -1,398 +0,0 @@ -/* - * File: arch/arm/plat-omap/include/mach/omapfb.h - * - * Framebuffer driver for TI OMAP boards - * - * Copyright (C) 2004 Nokia Corporation - * Author: Imre Deak imre.d...@nokia.com
Re: [PATCH 02/15] OMAP: OMAPFB: add omapdss device
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:
The upcoming new display subsystem driver is divided to two devices,
omapdss and omapfb, of which omapdss handles the actual hardware.
This patch adds a dummy omapdss platform device for the current omapfb
driver, which is then used to get the clocks. This will make it possible
for the current and the new display drivers to co-exist.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/clock24xx.c |8
arch/arm/mach-omap2/clock34xx.c | 10 +-
drivers/video/omap/dispc.c | 19 ---
3 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 44de027..402a3d4 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, mdm_ick, mdm_ick, CK_243X),
CLK(NULL, mdm_osc_ck, mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK(omapfb, ick, dss_ick, CK_243X | CK_242X),
- CLK(omapfb, dss1_fck, dss1_fck, CK_243X | CK_242X),
- CLK(omapfb, dss2_fck, dss2_fck, CK_243X | CK_242X),
- CLK(omapfb, tv_fck, dss_54m_fck, CK_243X | CK_242X),
+ CLK(omapdss, ick, dss_ick, CK_243X | CK_242X),
+ CLK(omapdss, dss1_fck, dss1_fck, CK_243X | CK_242X),
+ CLK(omapdss, dss2_fck, dss2_fck, CK_243X | CK_242X),
+ CLK(omapdss, tv_fck, dss_54m_fck, CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_243X | CK_242X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 045da92..dd7bba2 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -200,11 +200,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_343X),
CLK(NULL, sha11_ick,sha11_ick, CK_343X),
CLK(NULL, des1_ick, des1_ick, CK_343X),
- CLK(omapfb, dss1_fck, dss1_alwon_fck, CK_343X),
- CLK(omapfb, tv_fck, dss_tv_fck,CK_343X),
- CLK(omapfb, video_fck,dss_96m_fck, CK_343X),
- CLK(omapfb, dss2_fck, dss2_alwon_fck, CK_343X),
- CLK(omapfb, ick, dss_ick, CK_343X),
+ CLK(omapdss, dss1_fck, dss1_alwon_fck, CK_343X),
+ CLK(omapdss, tv_fck, dss_tv_fck,CK_343X),
+ CLK(omapdss, video_fck,dss_96m_fck, CK_343X),
+ CLK(omapdss, dss2_fck, dss2_alwon_fck, CK_343X),
+ CLK(omapdss, ick, dss_ick, CK_343X),
CLK(NULL, cam_mclk, cam_mclk, CK_343X),
CLK(NULL, cam_ick, cam_ick, CK_343X),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 06438d0..cde3d18 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -24,6 +24,7 @@
#include linux/vmalloc.h
#include linux/clk.h
#include linux/io.h
+#include linux/platform_device.h
#include mach/sram.h
#include mach/board.h
@@ -188,6 +189,11 @@ static struct {
struct omapfb_color_key color_key;
} dispc;
+static struct platform_device omapdss_device = {
+ .name = omapdss,
+ .id = -1,
+};
+
static void enable_lcd_clocks(int enable);
static void inline dispc_write_reg(int idx, u32 val)
@@ -907,20 +913,20 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
static int get_dss_clocks(void)
{
- dispc.dss_ick = clk_get(dispc.fbdev-dev, ick);
+ dispc.dss_ick = clk_get(omapdss_device.dev, ick);
if (IS_ERR(dispc.dss_ick)) {
dev_err(dispc.fbdev-dev, can't get ick\n);
return PTR_ERR(dispc.dss_ick);
}
- dispc.dss1_fck = clk_get(dispc.fbdev-dev, dss1_fck);
+ dispc.dss1_fck = clk_get(omapdss_device.dev, dss1_fck);
if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev-dev, can't get dss1_fck\n);
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
- dispc.dss_54m_fck = clk_get(dispc.fbdev-dev, tv_fck);
+ dispc.dss_54m_fck = clk_get(omapdss_device.dev, tv_fck);
if (IS_ERR(dispc.dss_54m_fck)) {
dev_err(dispc.fbdev-dev, can't get tv_fck\n);
clk_put(dispc.dss_ick);
@@ -1371,6 +1377,12 @@ static int omap_dispc_init(struct omapfb_device
*fbdev, int ext_mode,
int skip_init = 0;
int i;
+ r = platform_device_register(omapdss_device);
+ if (r) {
+ dev_err(fbdev-dev, can't register
Re: [PATCH 03/15] OMAP: Add VRAM manager
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:
Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:
- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations
The upcoming DSS2 uses VRAM manager.
VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/io.c |2 +
arch/arm/plat-omap/Kconfig |3 +
arch/arm/plat-omap/Makefile|1 +
arch/arm/plat-omap/include/mach/vram.h | 63 +++
arch/arm/plat-omap/sram.c |8 +
arch/arm/plat-omap/vram.c | 655
6 files changed, 732 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vram.h
create mode 100644 arch/arm/plat-omap/vram.c
Can you place vram.c under drivers/video/omap?
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 7a54e12..e37f736 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -32,6 +32,7 @@
#include mach/sram.h
#include mach/sdrc.h
#include mach/gpmc.h
+#include mach/vram.h
#ifndef CONFIG_ARCH_OMAP4/* FIXME: Remove this once clkdev is ready */
#include clock.h
@@ -240,6 +241,7 @@ void __init omap2_map_common_io(void)
omap2_check_revision();
omap_sram_init();
omapfb_reserve_sdram();
+ omap_vram_reserve_sdram();
}
/*
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index efe85d0..ca06037 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -183,6 +183,9 @@ config OMAP_SERIAL_WAKE
to data on the serial RX line. This allows you to wake the
system from serial console.
+config OMAP2_VRAM
+ bool
+
endmenu
endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a832795..0472bbe 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -25,3 +25,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
+obj-$(CONFIG_OMAP2_VRAM) += vram.o
diff --git a/arch/arm/plat-omap/include/mach/vram.h
b/arch/arm/plat-omap/include/mach/vram.h
new file mode 100644
index 000..fe72f81
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vram.h
@@ -0,0 +1,63 @@
+/*
+ * VRAM manager for OMAP
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@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, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRAM_H__
+#define __OMAP_VRAM_H__
+
+#include linux/autoconf.h
+#include linux/types.h
+
+#define OMAP_VRAM_MEMTYPE_SDRAM 0
+#define OMAP_VRAM_MEMTYPE_SRAM 1
+#define OMAP_VRAM_MEMTYPE_MAX1
+
+extern int omap_vram_add_region(unsigned long paddr, size_t size);
+extern int omap_vram_free(unsigned long paddr, size_t size);
+extern int omap_vram_alloc(int mtype, size_t size, unsigned long *paddr);
+extern int omap_vram_reserve(unsigned long paddr, size_t size);
+extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
+ unsigned long *largest_free_block);
+
+#ifdef CONFIG_OMAP2_VRAM
+extern void omap_vram_set_sdram_vram(u32 size, u32 start);
+extern void omap_vram_set_sram_vram(u32 size, u32 start);
+
+extern void omap_vram_reserve_sdram(void);
+extern unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+ unsigned long size_avail);
+#else
+static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
+static inline void omap_vram_set_sram_vram(u32 size, u32 start) { }
+
+static inline void
Re: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
Tony Lindgren t...@atomide.com writes:
Hi,
Sorry for the long delay on replying to this one.
Tony, this one has been superceded, and the irq_enable/disable stuff no
longer is needed due to the patch
OMAP: GPIO: clear/restore level/edge detect settings on mask/unmask
from my PM fixes queue.
An updated version (currently in the PM branch) is here:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=c80a909697ad931ffad9d30ed321469fa699b208
but...
* Wang Sawsd-A24013 cqw...@motorola.com [090602 02:25]:
This patch adds irq_enable and irq_disable for OMAP GPIO IRQ chip, and
also only enable WAKEUPEN
When GPIO edge detection is enabled, also clear the gpio event
triggering configurations to avoid
Pending interrupt status which is generated regardless of the IRQEN and
WKUPEN bit, the pending
IRQ status may prevent GPIO module acknowledge IDLE request and prevent
PER and thus RETENTION.
This is only applied for OMAP2/3 GPIO IRQs.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/gpio.c | 44
++--
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index bd04b40..19e0461 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -581,7 +581,7 @@ void omap_set_gpio_debounce_time(int gpio, int
enc_time)
EXPORT_SYMBOL(omap_set_gpio_debounce_time);
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
-static inline void set_24xx_gpio_triggering(struct gpio_bank *bank, int
gpio,
+static void set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
int trigger)
{
void __iomem *base = bank-base;
@@ -597,7 +597,12 @@ static inline void set_24xx_gpio_triggering(struct
gpio_bank *bank, int gpio,
trigger IRQ_TYPE_EDGE_FALLING);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
-if (trigger != 0)
+/*
+ * GPIO wakeup request can only be generated on edge
+ * transitions, see OMAP34xx_ES3.1_TRM_V_Q G25.5.3.1
+ * wake-up request note for detail
+ */
+if ((trigger IRQ_TYPE_EDGE_BOTH) != 0)
__raw_writel(1 gpio, bank-base
+ OMAP24XX_GPIO_SETWKUENA);
else
To me it looks like the right way to deal with the level gpio
would be to change it temporarily to be edge for the duration of
idle, then change it back to be level after returning from idle.
Not sure about that. That would have to be experimented with to
see if there are any other side effects.
In any case, that kind of change would be independent of this change
as this change just fixes a bug so wake-enables are only set on
edge-triggered GPIOs.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] OMAP: SDP: Enable DSS2 for OMAP3 SDP board
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/configs/omap_3430sdp_defconfig | 31 +-
arch/arm/mach-omap2/board-3430sdp.c | 171
+++
2 files changed, 181 insertions(+), 21 deletions(-)
diff --git a/arch/arm/configs/omap_3430sdp_defconfig
b/arch/arm/configs/omap_3430sdp_defconfig
index 73e0128..a0dce8f 100644
--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -1336,10 +1336,35 @@ CONFIG_FB_CFB_IMAGEBLIT=y
#
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
-CONFIG_FB_OMAP=y
-# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_LCD_VGA is not set
+# CONFIG_FB_OMAP_031M3R is not set
+# CONFIG_FB_OMAP_048M3R is not set
+# CONFIG_FB_OMAP_079M3R is not set
+# CONFIG_FB_OMAP_092M9R is not set
# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
-CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=6
+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=0
+
+#
+# OMAP2/3 Display Device Drivers
+#
+CONFIG_PANEL_GENERIC=y
+# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set
+CONFIG_PANEL_SHARP_LS037V7DW01=y
+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
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 21b4a52..ef8cf4f 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -36,6 +36,7 @@
#include mach/common.h
#include mach/dma.h
#include mach/gpmc.h
+#include mach/display.h
#include mach/control.h
#include mach/keypad.h
@@ -148,23 +149,149 @@ static struct spi_board_info sdp3430_spi_board_info[]
__initdata = {
},
};
-static struct platform_device sdp3430_lcd_device = {
- .name = sdp2430_lcd,
- .id = -1,
+
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+static int dvi_enabled;
+
+static void __init sdp3430_display_init(void)
+{
+ int r;
+
+ enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
+ backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+
+ r = gpio_request(enable_gpio, LCD reset);
+ if (r) {
+ printk(KERN_ERR failed to get LCD reset GPIO\n);
+ goto err0;
+ }
+
+ r = gpio_request(backlight_gpio, LCD Backlight);
+ if (r) {
+ printk(KERN_ERR failed to get LCD backlight GPIO\n);
+ goto err1;
+ }
+
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+
+ return;
+err1:
+ gpio_free(enable_gpio);
+err0:
+ return;
+}
+
+static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ if (dvi_enabled) {
+ printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
+ return -EINVAL;
+ }
+
+ gpio_direction_output(enable_gpio, 1);
+ gpio_direction_output(backlight_gpio, 1);
+
+ lcd_enabled = 1;
+
+ return 0;
+}
+
+static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ lcd_enabled = 0;
+
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+}
+
+static int sdp3430_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ if (lcd_enabled) {
+ printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
+ return -EINVAL;
+ }
+
+ dvi_enabled = 1;
+
+ return 0;
+}
+
+static void sdp3430_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ dvi_enabled = 0;
+}
+
+static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+
+static struct omap_dss_device sdp3430_lcd_device = {
+ .name = lcd,
+ .driver_name = sharp_ls_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 16,
+ .platform_enable = sdp3430_panel_enable_lcd,
+ .platform_disable = sdp3430_panel_disable_lcd,
};
Please check the formatting of data so they're tabbed.
-static struct regulator_consumer_supply sdp3430_vdac_supply = {
- .supply = vdac,
- .dev= sdp3430_lcd_device.dev,
+static struct omap_dss_device sdp3430_dvi_device = {
+ .name = dvi,
+
Re: [PATCH 14/15] OMAP: Beagle: Enable DSS2 for Beagle board
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/configs/omap3_beagle_defconfig | 26 ++-
arch/arm/mach-omap2/board-omap3beagle.c | 119
---
2 files changed, 116 insertions(+), 29 deletions(-)
snip snip
+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,
+};
...
Just nitpicking about the data tabbing in general, other than that:
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: GPIO: Avoid generating extra IRQs
l ^= bank-saved_datain;
l = bank-non_wakeup_gpios;
- if (l) {
+
+ /*
+ * No need to generate IRQs for the rising edge for gpio IRQs
+ * configured with falling edge only; and vice versa.
+ */
+ gen0 = l bank-saved_fallingdetect;
+ gen0 = bank-saved_datain;
+
+ gen1 = l bank-saved_risingdetect;
+ gen1 = ~(bank-saved_datain);
+
Is the gen0 = correct or should it also clear the bits?
What do you mean, eg, what bits should be cleared?
gen0 = (bit has changed) and is falling_edge
gen0 = (the bit has changed) is falling edge and former state was HIGH
(transition from HIGH to LOW has occurred)
for rising edge, needed is LOW to HIGH transition.
- Eero--
To unsubscribe from this list: send the line unsubscribe 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 07/15] OMAP: DSS2: VENC driver
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]: Please add a description and tell what VENC means. And check the data tabbing here too. Other than that: Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- drivers/video/omap2/dss/venc.c | 797 1 files changed, 797 insertions(+), 0 deletions(-) create mode 100644 drivers/video/omap2/dss/venc.c snip -- To unsubscribe from this list: send the line unsubscribe 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 13/15] OMAP: SDP: Enable DSS2 for OMAP3 SDP board
Hi,
ext Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:
+
+static struct omap_dss_device sdp3430_lcd_device = {
+ .name = lcd,
+ .driver_name = sharp_ls_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 16,
+ .platform_enable = sdp3430_panel_enable_lcd,
+ .platform_disable = sdp3430_panel_disable_lcd,
};
Please check the formatting of data so they're tabbed.
Do you mean something like:
static struct omap_dss_device sdp3430_lcd_device = {
.name = lcd,
.driver_name= sharp_ls_panel,
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/15] OMAP: DSS2: RFBI driver
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]: Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com Please add description. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/15] OMAP: DSS2: SDI driver
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/sdi.c | 370
+
1 files changed, 370 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/sdi.c
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
new file mode 100644
index 000..2f4d226
--- /dev/null
+++ b/drivers/video/omap2/dss/sdi.c
@@ -0,0 +1,370 @@
+/*
+ * linux/drivers/video/omap2/dss/sdi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@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/.
+ */
+
+#define DSS_SUBSYS_NAME SDI
+
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/io.h
+
+#include mach/board.h
+#include mach/display.h
+#include dss.h
+
+#define CONTROL_PADCONF_BASE 0x48002000
+
+#define OMAP_SDI_PAD_DIS(pe, pu) ((7 0) | /* MODE 7 = safe */ \
+ (((pe) ? 1 : 0) 3) | /* PULL_ENA */ \
+ (((pu) ? 1 : 0) 4) | /* PULL_UP */ \
+ (1 8))/* INPUT_EN */
+
+#define OMAP_SDI_PAD_EN (1 0) /* MODE 1 =
SDI_xx */
+
+#define OMAP_SDI_PAD_MASKOMAP_SDI_PAD_DIS(1, 1)
+
+static struct {
+ bool skip_init;
+ bool update_enabled;
+} sdi;
+
+/* CONTROL_PADCONF_DSS_DATAXX */
+static const u16 sdi_pads[] =
+{
+ 0x0f0, /* 10[ 7..0]:SDI_DAT1N */
+ 0x0f2, /* 10[15..0]:SDI_DAT1P */
+ 0x0f4, /* 12[ 7..0]:SDI_DAT2N */
+ 0x0f6, /* 12[15..0]:SDI_DAT2P */
+ 0x0f8, /* 14[ 7..0]:SDI_DAT3N */
+ 0x0fa, /* 14[15..0]:SDI_DAT3P */
+ 0x108, /* 22[ 7..0]:SDI_CLKN */
+ 0x10a, /* 22[15..0]:SDI_CLKP */
+};
Aaargh, NAK for custom pin muxing. Please do it in mux.[ch], see
arch/arm/mach-omap2/mux.c.
+
+/*
+ * Check if bootloader / platform code has configured the SDI pads properly.
+ * This means it either configured all required pads for SDI mode, or that it
+ * left all the required pads unconfigured.
+ */
+static int sdi_pad_init(struct omap_dss_device *dssdev)
+{
+ unsigned req_map;
+ bool configured = false;
+ bool unconfigured = false;
+ int data_pairs;
+ int i;
+
+ data_pairs = dssdev-phy.sdi.datapairs;
+ req_map = (1 (data_pairs * 2)) - 1; /* data lanes */
+ req_map |= 3 6; /* clk lane */
+ for (i = 0; i ARRAY_SIZE(sdi_pads); i++) {
+ u32 reg;
+ u32 val;
+
+ if (!((1 i) req_map))
+ /* Ignore unneded pads. */
+ continue;
+ reg = CONTROL_PADCONF_BASE + sdi_pads[i];
+ val = omap_readw(reg);
+ switch (val 0x07) { /* pad mode */
+ case 1:
+ if (unconfigured)
+ break;
+ /* Is the pull configuration ok for SDI mode? */
+ if ((val OMAP_SDI_PAD_MASK) != OMAP_SDI_PAD_EN)
+ break;
+ configured = true;
+ break;
+ case 0:
+ case 7:
+ if (configured)
+ break;
+ unconfigured = true;
+ break;
+ default:
+ break;
+ }
+ }
+ if (i != ARRAY_SIZE(sdi_pads)) {
+ DSSERR(SDI: invalid pad configuration\n);
+ return -1;
+ }
+
+ return 0;
+}
+
+static void sdi_pad_config(struct omap_dss_device *dssdev, bool enable)
+{
+ int data_pairs;
+ bool pad_off_pe, pad_off_pu;
+ unsigned req_map;
+ int i;
+
+ data_pairs = dssdev-phy.sdi.datapairs;
+ pad_off_pe = dssdev-phy.sdi.pad_off_pe;
+ pad_off_pu = dssdev-phy.sdi.pad_off_pu;
+ req_map = (1 (data_pairs * 2)) - 1; /* data lanes */
+ req_map |= 3 6; /* clk lane */
+ for (i = 0; i ARRAY_SIZE(sdi_pads); i++) {
+ u32 reg;
+ u16 val;
+
+ if (!((1 i) req_map))
+
Re: [PATCH 10/15] OMAP: DSS2: DSI driver
* Tomi Valkeinen tomi.valkei...@nokia.com [090805 17:19]:
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/dss/dsi.c | 3509
+
1 files changed, 3509 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/dsi.c
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
snip snip
+int dsi_vc_dcs_read(int channel, u8 dcs_cmd, u8 *buf, int buflen)
+{
+ u32 val;
+ u8 dt;
+ int r;
+
+ if (dsi.debug_read)
+ DSSDBG(dsi_vc_dcs_read(ch%d, dcs_cmd %u)\n, channel, dcs_cmd);
+
+ r = dsi_vc_send_short(channel, DSI_DT_DCS_READ, dcs_cmd, 0);
+ if (r)
+ return r;
+
+ r = dsi_vc_send_bta_sync(channel);
+ if (r)
+ return r;
+
+ /* RX_FIFO_NOT_EMPTY */
+ if (REG_GET(DSI_VC_CTRL(channel), 20, 20) == 0) {
+ DSSERR(RX fifo empty when trying to read.\n);
+ return -EIO;
+ }
+
+ val = dsi_read_reg(DSI_VC_SHORT_PACKET_HEADER(channel));
+ if (dsi.debug_read)
+ DSSDBG(\theader: %08x\n, val);
+ dt = FLD_GET(val, 5, 0);
+ if (dt == DSI_DT_RX_ACK_WITH_ERR) {
+ u16 err = FLD_GET(val, 23, 8);
+ dsi_show_rx_ack_with_err(err);
+ return -1;
Return something from err.h instead of -1 in various places in this function?
+
+ } else if (dt == DSI_DT_RX_SHORT_READ_1) {
+ u8 data = FLD_GET(val, 15, 8);
+ if (dsi.debug_read)
+ DSSDBG(\tDCS short response, 1 byte: %02x\n, data);
+
+ if (buflen 1)
+ return -1;
+
+ buf[0] = data;
+
+ return 1;
+ } else if (dt == DSI_DT_RX_SHORT_READ_2) {
+ u16 data = FLD_GET(val, 23, 8);
+ if (dsi.debug_read)
+ DSSDBG(\tDCS short response, 2 byte: %04x\n, data);
+
+ if (buflen 2)
+ return -1;
+
+ buf[0] = data 0xff;
+ buf[1] = (data 8) 0xff;
+
+ return 2;
+ } else if (dt == DSI_DT_RX_DCS_LONG_READ) {
+ int w;
+ int len = FLD_GET(val, 23, 8);
+ if (dsi.debug_read)
+ DSSDBG(\tDCS long response, len %d\n, len);
+
+ if (len buflen)
+ return -1;
+
+ /* two byte checksum ends the packet, not included in len */
+ for (w = 0; w len + 2;) {
+ int b;
+ val = dsi_read_reg(DSI_VC_SHORT_PACKET_HEADER(channel));
+ if (dsi.debug_read)
+ DSSDBG(\t\t%02x %02x %02x %02x\n,
+ (val 0) 0xff,
+ (val 8) 0xff,
+ (val 16) 0xff,
+ (val 24) 0xff);
+
+ for (b = 0; b 4; ++b) {
+ if (w len)
+ buf[w] = (val (b * 8)) 0xff;
+ /* we discard the 2 byte checksum */
+ ++w;
+ }
+ }
+
+ return len;
+
+ } else {
+ DSSERR(\tunknown datatype 0x%02x\n, dt);
+ return -1;
+ }
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
* Kevin Hilman khil...@deeprootsystems.com [090805 17:36]: Tony Lindgren t...@atomide.com writes: Hi, Sorry for the long delay on replying to this one. Tony, this one has been superceded, and the irq_enable/disable stuff no longer is needed due to the patch OMAP: GPIO: clear/restore level/edge detect settings on mask/unmask from my PM fixes queue. An updated version (currently in the PM branch) is here: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=c80a909697ad931ffad9d30ed321469fa699b208 OK, thanks. but... snip To me it looks like the right way to deal with the level gpio would be to change it temporarily to be edge for the duration of idle, then change it back to be level after returning from idle. Not sure about that. That would have to be experimented with to see if there are any other side effects. In any case, that kind of change would be independent of this change as this change just fixes a bug so wake-enables are only set on edge-triggered GPIOs. OK. Just FYI, I think I experimented on that for 2420 at some point and it worked, but that was several years ago. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Fix SDRC register addresses
Roger Quadros ext-roger.quad...@nokia.com writes: SDRC addresses are offset from OMAP3430_SDRC_RT_BASE and not OMAP3430_SMS_RT_BASE. This fixes OFF mode on EMU/HS devices. Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com Indeed, this was a merge goof on my part. Will fold into earlier patch to undo. Thanks, Kevin --- arch/arm/mach-omap2/sleep34xx.S | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 807b23e..53b6da9 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -49,13 +49,13 @@ #define SCRATCHPAD_BASE_P(OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\ + SCRATCHPAD_MEM_OFFS) #define SDRC_POWER_V OMAP34XX_SDRC_REGADDR(SDRC_POWER) -#define SDRC_SYSCONFIG_P (OMAP3430_SMS_RT_BASE + SDRC_SYSCONFIG) -#define SDRC_MR_0_P (OMAP3430_SMS_RT_BASE + SDRC_MR_0) -#define SDRC_EMR2_0_P(OMAP3430_SMS_RT_BASE + SDRC_EMR2_0) -#define SDRC_MANUAL_0_P (OMAP3430_SMS_RT_BASE + SDRC_MANUAL_0) -#define SDRC_MR_1_P (OMAP3430_SMS_RT_BASE + SDRC_MR_1) -#define SDRC_EMR2_1_P(OMAP3430_SMS_RT_BASE + SDRC_EMR2_1) -#define SDRC_MANUAL_1_P (OMAP3430_SMS_RT_BASE + SDRC_MANUAL_1) +#define SDRC_SYSCONFIG_P (OMAP3430_SDRC_RT_BASE + SDRC_SYSCONFIG) +#define SDRC_MR_0_P (OMAP3430_SDRC_RT_BASE + SDRC_MR_0) +#define SDRC_EMR2_0_P(OMAP3430_SDRC_RT_BASE + SDRC_EMR2_0) +#define SDRC_MANUAL_0_P (OMAP3430_SDRC_RT_BASE + SDRC_MANUAL_0) +#define SDRC_MR_1_P (OMAP3430_SDRC_RT_BASE + SDRC_MR_1) +#define SDRC_EMR2_1_P(OMAP3430_SDRC_RT_BASE + SDRC_EMR2_1) +#define SDRC_MANUAL_1_P (OMAP3430_SDRC_RT_BASE + SDRC_MANUAL_1) #define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) #define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL) -- 1.6.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: [PATCH] OMAP: GPIO: Avoid generating extra IRQs
* ext-eero.nurkk...@nokia.com ext-eero.nurkk...@nokia.com [090805 17:45]:
l ^= bank-saved_datain;
l = bank-non_wakeup_gpios;
- if (l) {
+
+ /*
+ * No need to generate IRQs for the rising edge for gpio IRQs
+ * configured with falling edge only; and vice versa.
+ */
+ gen0 = l bank-saved_fallingdetect;
+ gen0 = bank-saved_datain;
+
+ gen1 = l bank-saved_risingdetect;
+ gen1 = ~(bank-saved_datain);
+
Is the gen0 = correct or should it also clear the bits?
What do you mean, eg, what bits should be cleared?
gen0 = (bit has changed) and is falling_edge
gen0 = (the bit has changed) is falling edge and former state was HIGH
(transition from HIGH to LOW has occurred)
for rising edge, needed is LOW to HIGH transition.
OK, my comment was just based on looking at the patch, sounds like
you have verified that it's correct.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: RX51: Updated rx51_defconfig
Tony, This will be required to get linux-omap booting on rx51. any comments on this? cheers, -roger ext Roger Quadros wrote: Added REGULATOR, MMC and updated default CMDLINE. Linux-omap now boots on RX51. Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com --- arch/arm/configs/rx51_defconfig | 294 +++ 1 files changed, 172 insertions(+), 122 deletions(-) diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig index eb2cb31..713d707 100644 --- a/arch/arm/configs/rx51_defconfig +++ b/arch/arm/configs/rx51_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.29-rc8 -# Fri Mar 13 15:28:56 2009 +# Linux kernel version: 2.6.31-rc1-omap1 +# Fri Jun 26 15:20:45 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -9,7 +9,6 @@ CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y -# CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -18,13 +17,12 @@ CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y # # General setup @@ -38,6 +36,7 @@ CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set @@ -65,6 +64,9 @@ CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y @@ -86,18 +88,30 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y + +# +# Performance Counters +# CONFIG_VM_EVENT_COUNTERS=y +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_KRETPROBES=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_GCOV_KERNEL is not set +# CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y @@ -109,8 +123,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_BLOCK=y -# CONFIG_LBD is not set -# CONFIG_BLK_DEV_IO_TRACE is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -137,12 +150,14 @@ CONFIG_FREEZER=y # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set -# CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -151,24 +166,25 @@ CONFIG_FREEZER=y # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KIRKWOOD is not set -# CONFIG_ARCH_KS8695 is not set -# CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_LOKI is not set # CONFIG_ARCH_MV78XX0 is not set -# CONFIG_ARCH_MXC is not set # CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_MSM is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y -# CONFIG_ARCH_MSM is not set -# CONFIG_ARCH_W90X900 is not set # # TI OMAP Implementations @@ -177,6 +193,7 @@ CONFIG_ARCH_OMAP_OTG=y # CONFIG_ARCH_OMAP1 is not set # CONFIG_ARCH_OMAP2 is not set CONFIG_ARCH_OMAP3=y +# CONFIG_ARCH_OMAP4 is not set # # OMAP Feature Selections @@ -188,6 +205,7 @@ CONFIG_OMAP_MUX=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_OMAP_MUX_WARNINGS=y CONFIG_OMAP_MCBSP=y +# CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 @@ -195,19 +213,20 @@ CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set
Re: [PATCH] OMAP2/3: mmc-twl4030: Free up MMC regulators while cleaning up
Tony,
any comments on this?
regards,
-roger
ext Roger Quadros wrote:
twl_mmc_cleanup() must free up the regulators that were
allocated by twl_mmc_late_init().
This eliminates the below error when 'omap_hsmmc' module is
repeatedly loaded and unloaded.
sysfs: cannot create duplicate filename '/devices/platform
/mmci-omap-hs.0/microamps_requested_vmmc'
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
arch/arm/mach-omap2/mmc-twl4030.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 06b252f..0007115 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -119,6 +119,7 @@ static int twl_mmc_late_init(struct device *dev)
if (i != 0)
break;
ret = PTR_ERR(reg);
+ hsmmc[i].vcc = NULL;
goto err;
}
hsmmc[i].vcc = reg;
@@ -165,8 +166,13 @@ done:
static void twl_mmc_cleanup(struct device *dev)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
+ int i;
gpio_free(mmc-slots[0].switch_pin);
+ for(i = 0; i ARRAY_SIZE(hsmmc); i++) {
+ regulator_put(hsmmc[i].vcc);
+ regulator_put(hsmmc[i].vcc_aux);
+ }
}
#ifdef CONFIG_PM
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: PM: warn if CONFIG_CPU_IDLE is not enabled
Paul Walmsley p...@pwsan.com writes: For MPU latency constraints to work, CONFIG_CPU_IDLE must be enabled, since CPUIdle is where the constraints are evaluated. Warn during compilation if CONFIG_CPU_IDLE is not defined. Signed-off-by: Paul Walmsley p...@pwsan.com Thanks, pushing to PM branch. Kevin --- arch/arm/mach-omap2/resource34xx.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c index 25535a3..1693e9b 100644 --- a/arch/arm/mach-omap2/resource34xx.c +++ b/arch/arm/mach-omap2/resource34xx.c @@ -28,6 +28,10 @@ #include cm.h #include cm-regbits-34xx.h +#ifndef CONFIG_CPU_IDLE +#warning MPU latency constraints require CONFIG_CPU_IDLE to function! +#endif + /** * init_latency - Initializes the mpu/core latency resource. * @resp: Latency resource to be initalized -- 1.6.3.GIT -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: MMC3 Overo
-- Forwarded message -- From: John Sarman johnsar...@gmail.com Date: Wed, Aug 5, 2009 at 12:01 PM Subject: Re: MMC3 Overo To: Grazvydas Ignotas nota...@gmail.com On Wed, Aug 5, 2009 at 4:32 AM, Grazvydas Ignotasnota...@gmail.com wrote: u-boot_snip MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\ You must have input enable on CLK line for MMC3 or it won't work for some reason (MMC 1 and 2 doesn't need that). Without this part of the host controller hardware doesn't get the clock I guess, or something like that. You won't believe how much time we've wasted on this! MUX_VAL(CP(ETK_CLK_ES2), (IEN | PTU | EN | M2)) /*MMC3_CLK*/\ Works Beautifully, Thank you so much. I have also burnt too much midnight oil on this problem. So looks like Overo MMC3 works like a champ! John Sarman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT 3/4] OMAP3: PM: PRCM interrupt: only handle selected PRCM interrupts
Paul Walmsley p...@pwsan.com writes:
On Fri, 24 Jul 2009, Kevin Hilman wrote:
From: Paul Walmsley p...@pwsan.com
Clearing wakeup sources is now only done when the PRM indicates a
wakeup source interrupt. Since we don't handle any other types of
PRCM interrupts right now, warn if we get any other type of PRCM
interrupt. Either code needs to be added to the PRCM interrupt
handler to react to these, or these other interrupts should be masked
off at init.
Looks good to me, Kevin -
Signed-off-by: Paul Walmsley p...@pwsan.com
Thanks for doing the heavy lifting to update this and the previous patch
after Jon's work.
Pushing to PM branch.
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 46
+
1 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 25372b7..348a683 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -204,7 +204,7 @@ static void omap3_save_secure_ram_context(u32
target_mpu_state)
* that any peripheral wake-up events occurring while attempting to
* clear the PM_WKST_x are detected and cleared.
*/
-static void prcm_clear_mod_irqs(s16 module, u8 regs)
+static int prcm_clear_mod_irqs(s16 module, u8 regs)
{
u32 wkst, fclk, iclk;
u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
@@ -212,6 +212,7 @@ static void prcm_clear_mod_irqs(s16 module, u8 regs)
u16 iclk_off = (regs == 3) ? CM_ICLKEN3 : CM_ICLKEN1;
u16 grpsel_off = (regs == 3) ?
OMAP3430ES2_PM_MPUGRPSEL3 : OMAP3430_PM_MPUGRPSEL;
+int c = 0;
wkst = prm_read_mod_reg(module, wkst_off);
wkst = prm_read_mod_reg(module, grpsel_off);
@@ -223,10 +224,28 @@ static void prcm_clear_mod_irqs(s16 module, u8 regs)
cm_set_mod_reg_bits(wkst, module, fclk_off);
prm_write_mod_reg(wkst, module, wkst_off);
wkst = prm_read_mod_reg(module, wkst_off);
+c++;
}
cm_write_mod_reg(iclk, module, iclk_off);
cm_write_mod_reg(fclk, module, fclk_off);
}
+
+return c;
+}
+
+static int _prcm_int_handle_wakeup(void)
+{
+int c;
+
+c = prcm_clear_mod_irqs(WKUP_MOD, 1);
+c += prcm_clear_mod_irqs(CORE_MOD, 1);
+c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
+if (omap_rev() OMAP3430_REV_ES1_0) {
+c += prcm_clear_mod_irqs(CORE_MOD, 3);
+c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
+}
+
+return c;
}
/*
@@ -249,18 +268,27 @@ static void prcm_clear_mod_irqs(s16 module, u8 regs)
static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
{
u32 irqstatus_mpu;
+int c = 0;
do {
-prcm_clear_mod_irqs(WKUP_MOD, 1);
-prcm_clear_mod_irqs(CORE_MOD, 1);
-prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
-if (omap_rev() OMAP3430_REV_ES1_0) {
-prcm_clear_mod_irqs(CORE_MOD, 3);
-prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
-}
-
irqstatus_mpu = prm_read_mod_reg(OCP_MOD,
OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+
+if (irqstatus_mpu (OMAP3430_WKUP_ST | OMAP3430_IO_ST)) {
+c = _prcm_int_handle_wakeup();
+
+/*
+ * Is the MPU PRCM interrupt handler racing with the
+ * IVA2 PRCM interrupt handler ?
+ */
+WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
+ but no wakeup sources are marked\n);
+} else {
+/* XXX we need to expand our PRCM interrupt handler */
+WARN(1, prcm: WARNING: PRCM interrupt received, but
+ no code to handle it (%08x)\n, irqstatus_mpu);
+}
+
prm_write_mod_reg(irqstatus_mpu, OCP_MOD,
OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
--
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
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 1/3] ARM:OMAP4 iommu:changes in iommu for OMAP4
Russell / Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, August 05, 2009 12:50 PM
To: Russell King - ARM Linux
Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; Hiroshi DOYU;
Shilimkar, Santosh
Subject: Re: [PATCH v1 1/3] ARM:OMAP4 iommu:changes in iommu for OMAP4
* Russell King - ARM Linux li...@arm.linux.org.uk [090805 01:45]:
On Tue, Aug 04, 2009 at 05:30:23PM -0500, Kanigeri, Hari wrote:
- obj-clk = clk_get(pdev-dev, pdata-clk_name);
- if (IS_ERR(obj-clk))
- goto err_clk;
+ /*
+ * FIX-ME: Replace with correct clk node when clk
+ * framework is available
+ */
+ if (!cpu_is_omap44xx()) {
+ obj-clk = clk_get(pdev-dev, pdata-clk_name);
+ if (IS_ERR(obj-clk))
+ goto err_clk;
+ }
I've no visibility on when these are going to get resolved, and it's
starting to concern me that there appears to be no progress on it,
especially as we have more and more code being merged with these
workarounds. It's getting towards the point where enough is enough
and we need OMAP4 clk support in place, even if it is just a simple
stop-gap implementation rather than all these horrible hacks spread
through the code which one day will need to be found and removed.
Yeah I agree.
The initial set of clock patches are more or less ready now and we
will posting them in next few days.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 1/3] ARM:OMAP4 iommu:changes in iommu for OMAP4
Russell, Tony, Santosh,
Russell / Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, August 05, 2009 12:50 PM
To: Russell King - ARM Linux
Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; Hiroshi DOYU;
Shilimkar, Santosh
Subject: Re: [PATCH v1 1/3] ARM:OMAP4 iommu:changes in iommu for OMAP4
* Russell King - ARM Linux li...@arm.linux.org.uk [090805 01:45]:
On Tue, Aug 04, 2009 at 05:30:23PM -0500, Kanigeri, Hari wrote:
- obj-clk = clk_get(pdev-dev, pdata-clk_name);
- if (IS_ERR(obj-clk))
- goto err_clk;
+ /*
+* FIX-ME: Replace with correct clk node when clk
+* framework is available
+*/
+ if (!cpu_is_omap44xx()) {
+ obj-clk = clk_get(pdev-dev, pdata-clk_name);
+ if (IS_ERR(obj-clk))
+ goto err_clk;
+ }
I've no visibility on when these are going to get resolved, and it's
starting to concern me that there appears to be no progress on it,
especially as we have more and more code being merged with these
workarounds. It's getting towards the point where enough is enough
and we need OMAP4 clk support in place, even if it is just a simple
stop-gap implementation rather than all these horrible hacks spread
through the code which one day will need to be found and removed.
Yeah I agree.
The initial set of clock patches are more or less ready now and we
will posting them in next few days.
-- Ok, then. I will wait for the clock patches to resend the iommu patches.
Thank you,
Best regards,
Hari
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: MMC3 Overo
On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilmankhil...@deeprootsystems.com wrote: John Sarman johnsar...@gmail.com writes: -- Forwarded message -- From: John Sarman johnsar...@gmail.com Date: Wed, Aug 5, 2009 at 12:01 PM Subject: Re: MMC3 Overo To: Grazvydas Ignotas nota...@gmail.com On Wed, Aug 5, 2009 at 4:32 AM, Grazvydas Ignotasnota...@gmail.com wrote: u-boot_snip MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\ You must have input enable on CLK line for MMC3 or it won't work for some reason (MMC 1 and 2 doesn't need that). Without this part of the host controller hardware doesn't get the clock I guess, or something like that. You won't believe how much time we've wasted on this! MUX_VAL(CP(ETK_CLK_ES2), (IEN | PTU | EN | M2)) /*MMC3_CLK*/\ Works Beautifully, Thank you so much. I have also burnt too much midnight oil on this problem. So looks like Overo MMC3 works like a champ! Might I suggest a kernel patch for this rather than fixing u-boot so that all the midnight oil you've burnt does not have to be duplicated by others. Well I dont know how to answer that. Because the Mux architecture is slightly on the scary side. I personally have had success with it, but everytime you need to add a new pin functionality you have to update mux.h. I finally decided to just focus on having the MUX correct at boot up via u-boot. I could just add the code to update the mux without using the mux architecture. I would appreciate some opinions on this. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 3/3] ARM:OMAP4 iommu:provide build support for omap4 iommu
Hi Russell and Hiroshi, Thanks for your comments. Please see my below comments. -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Tuesday, August 04, 2009 11:36 PM To: Kanigeri, Hari Cc: linux-omap@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk; Shilimkar, Santosh Subject: Re: [PATCH v1 3/3] ARM:OMAP4 iommu:provide build support for omap4 iommu From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [PATCH v1 3/3] ARM:OMAP4 iommu:provide build support for omap4 iommu Date: Wed, 5 Aug 2009 00:42:41 +0200 On Tue, Aug 04, 2009 at 05:32:12PM -0500, Kanigeri, Hari wrote: diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index efe85d0..50aaefb 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -118,8 +118,11 @@ config OMAP_MBOX_FWK DSP, IVA1.0 and IVA2 in OMAP1/2/3. config OMAP_IOMMU - tristate - + tristate iommu Insufficiently verbose description. OMAP IOMMU Support would be better. I thought the idea here was to arrange for things to select OMAP_IOMMU when they require it rather than offering it as a separate configuration option. The former way has the advantage that you don't need to know that you need IOMMU support to (eg) use the Camera - enabling the Camera should automatically enable IOMMU support. The following is the original discussion. http://lists.arm.linux.org.uk/lurker/message/20090518.130233.3f238e72.en.h tml -- I agree with your comments from OMAP3 point of view. For OMAP4, I guess Camera is not going to use IOMMU module. IOMMU modules will be used only by the IPC that are communicating with 2 remote Cores (Ducati and Tesla). Having said this, there might not be any clients of IOMMU in the Kernel space as we are looking at the option of using the IOMMU as a character driver from User-space. For this reason, I think we should have the configuration option to build iommu. Please let me know your comments. Thank you, Best regards, Hari -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: MMC3 Overo
On Wed, Aug 5, 2009 at 9:35 AM, John Sarmanjohnsar...@gmail.com wrote: On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilmankhil...@deeprootsystems.com wrote: Might I suggest a kernel patch for this rather than fixing u-boot so that all the midnight oil you've burnt does not have to be duplicated by others. Well I dont know how to answer that. Because the Mux architecture is slightly on the scary side. I personally have had success with it, but everytime you need to add a new pin functionality you have to update mux.h. I finally decided to just focus on having the MUX correct at boot up via u-boot. I could just add the code to update the mux without using the mux architecture. I would appreciate some opinions on this. I get discouraged every time I look at using kernel pinmuxing. It seems to assume that some mux settings are standard when in my experience that is often not so. So I face having to write code to undo what it does (and face glitches on the gpio lines), or the bigger task of restructuring the code to do the right thing. And up to now in each case I shrug and say no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot 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: Fwd: MMC3 Overo
Steve Sakoman wrote: On Wed, Aug 5, 2009 at 9:35 AM, John Sarmanjohnsar...@gmail.com wrote: On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilmankhil...@deeprootsystems.com wrote: Might I suggest a kernel patch for this rather than fixing u-boot so that all the midnight oil you've burnt does not have to be duplicated by others. Well I dont know how to answer that. Because the Mux architecture is slightly on the scary side. I personally have had success with it, but everytime you need to add a new pin functionality you have to update mux.h. I finally decided to just focus on having the MUX correct at boot up via u-boot. I could just add the code to update the mux without using the mux architecture. I would appreciate some opinions on this. I get discouraged every time I look at using kernel pinmuxing. It seems to assume that some mux settings are standard when in my experience that is often not so. So I face having to write code to undo what it does (and face glitches on the gpio lines), or the bigger task of restructuring the code to do the right thing. And up to now in each case I shrug and say no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot Does it make sense to do __ALL__ pin-muxing in the board-files for a given board? That way, we have the pin-mux setting in the kernel, plus a nice set of debug logs from CONFIG_MUX_DEBUG to tell if something is not right, plus it's as good as doing it in u-boot anyway? What say? - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: GPIO: Avoid generating extra IRQs
It is possible for GPIO IRQ lines configured with falling edge triggering only to get IRQs at the rising edge upon the exit of offmode. And vice versa. Prevent such IRQs to arrive by generating the IRQ obeying the detection scheme. Is the situation still the same if we temporarily change the level lines to edge for the duration of idle? This would allow waking up even if the line is level. I admit that I haven't tested such a schenario. But I guess it's not different than what it used to be ... Is there a sample to try out? However, if there's no edge detection (nor and or level detection) set at all, it will still generate soft IRQs, which possibly needs some rethinking (maybe WARN if no egde nor level detection on the GPIO IRQ). But it's been that way, so I figured no need to change that. Also, have you checked the code flow on omap1 when l, gen, gen0 gen1 are not initialized? Just wondering ;) Tony Right, possibly a compile warning. - Eero-- To unsubscribe from this list: send the line unsubscribe 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: Fwd: MMC3 Overo
Steve Sakoman wrote: On Wed, Aug 5, 2009 at 9:35 AM, John Sarmanjohnsar...@gmail.com wrote: On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilmankhil...@deeprootsystems.com wrote: Might I suggest a kernel patch for this rather than fixing u-boot so that all the midnight oil you've burnt does not have to be duplicated by others. Well I dont know how to answer that. Because the Mux architecture is slightly on the scary side. I personally have had success with it, but everytime you need to add a new pin functionality you have to update mux.h. I finally decided to just focus on having the MUX correct at boot up via u-boot. I could just add the code to update the mux without using the mux architecture. I would appreciate some opinions on this. I get discouraged every time I look at using kernel pinmuxing. It seems to assume that some mux settings are standard when in my experience that is often not so. So I face having to write code to undo what it does (and face glitches on the gpio lines), or the bigger task of restructuring the code to do the right thing. And up to now in each case I shrug and say no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot I agree there are lots of shortcomings in the current mux code and we've been hitting them regularily lately. That being said, for mux settings that done one-time only at boot, what are the problems you're running into? All that should be necessary for a one-time setup is possibly adding and entry to mux.h and then calling omap_cfg_reg() in your board init code. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: MMC3 Overo
On Wed, Aug 5, 2009 at 10:58 AM, Kevin Hilmankhil...@deeprootsystems.com wrote: Steve Sakoman wrote: And up to now in each case I shrug and say no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot I agree there are lots of shortcomings in the current mux code and we've been hitting them regularily lately. That being said, for mux settings that done one-time only at boot, what are the problems you're running into? It's been a few months since I last encountered this, so the exact details are a bit fuzzy. I seem to recall that there were some basic issues with enabling kernel pinmuxing in that some of the setup that was done for all machines was just wrong for my particular machine. IIRC, it was due to assumptions about which pad was used for a particular function (for those functions which can be steered to multiple GPIO pads). So I faced having to undo that change in my board file as well as any issues that may have arisen from glitches on the GPIO pins during the process. And since there were several of these I gave up and turned off kernel pinmuxing. I'd be happy if we cleaned up the one size fits all pinmuxing to just that subset that truly does fit all boards, and leave the rest to the board files. I'd also be content to have it all done in the board file for each machine. 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: Fwd: MMC3 Overo
Steve Sakoman wrote: On Wed, Aug 5, 2009 at 10:58 AM, Kevin Hilmankhil...@deeprootsystems.com wrote: Steve Sakoman wrote: And up to now in each case I shrug and say no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot I agree there are lots of shortcomings in the current mux code and we've been hitting them regularily lately. That being said, for mux settings that done one-time only at boot, what are the problems you're running into? It's been a few months since I last encountered this, so the exact details are a bit fuzzy. I seem to recall that there were some basic issues with enabling kernel pinmuxing in that some of the setup that was done for all machines was just wrong for my particular machine. IIRC, it was due to assumptions about which pad was used for a particular function (for those functions which can be steered to multiple GPIO pads). So I faced having to undo that change in my board file as well as any issues that may have arisen from glitches on the GPIO pins during the process. And since there were several of these I gave up and turned off kernel pinmuxing. I'd be happy if we cleaned up the one size fits all pinmuxing to just that subset that truly does fit all boards, and leave the rest to the board files. I'd also be content to have it all done in the board file for each machine. Indeed, any assumptions about common muxing that are not indeed common are bugs and should be fixed. The right solution is to have everything in the kernel, and split across SoC common init and board specific init. Of course u-boot will still have to do some early muxing, but it should be redone in the kernel so it's trivial to change bootloaders. So the real missing piece is someone to step up and rework the mux code. The bigger problem is that the vast majority of folks don't care about the common case and only care about getting thing working for a specific platform. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC3 Overo
Hi, There are a couple of other things relating to pix mux settings, specific to the Overo, that is currently in u-boot, that should be moved to the kernel, e.g. bluetooth subsystem of the wi2wi chipset, used on the Overo Air/Fire modules. Best regards, Elvis On Aug 5, 2009, at 8:25 PM, Kevin Hilman wrote: Might I suggest a kernel patch for this rather than fixing u-boot so that all the midnight oil you've burnt does not have to be duplicated by others. -- To unsubscribe from this list: send the line unsubscribe 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: Fwd: MMC3 Overo
Kevin Hilman wrote: Steve Sakoman wrote: On Wed, Aug 5, 2009 at 10:58 AM, Kevin Hilmankhil...@deeprootsystems.com wrote: Steve Sakoman wrote: And up to now in each case I shrug and say no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot I agree there are lots of shortcomings in the current mux code and we've been hitting them regularily lately. That being said, for mux settings that done one-time only at boot, what are the problems you're running into? It's been a few months since I last encountered this, so the exact details are a bit fuzzy. I seem to recall that there were some basic issues with enabling kernel pinmuxing in that some of the setup that was done for all machines was just wrong for my particular machine. IIRC, it was due to assumptions about which pad was used for a particular function (for those functions which can be steered to multiple GPIO pads). So I faced having to undo that change in my board file as well as any issues that may have arisen from glitches on the GPIO pins during the process. And since there were several of these I gave up and turned off kernel pinmuxing. I'd be happy if we cleaned up the one size fits all pinmuxing to just that subset that truly does fit all boards, and leave the rest to the board files. I'd also be content to have it all done in the board file for each machine. Indeed, any assumptions about common muxing that are not indeed common are bugs and should be fixed. The right solution is to have everything in the kernel, and split across SoC common init and board specific init. Of course u-boot will still have to do some early muxing, but it should be redone in the kernel so it's trivial to change bootloaders. So the real missing piece is someone to step up and rework the mux code. The bigger problem is that the vast majority of folks don't care about the common case and only care about getting thing working for a specific platform. I posted some changes to add support for changing the Beagle expansion connector MCSPI muxing in the board file and some general muxing questions and received no comments (OK, a number of people were on vacation). If people would like I can repost it to aid in discussion. I agree we need to more muxing in the kernel and less in u-boot. I do not want a different u-boot for the Beagle based on what I have connected to the expansion connector. (Same applies to the Overo) The current mux requires you make an entry in an enum, then a corresponding entry in an array to configure the pin. SO the enum length is basically number of pins * the number of possible pin configurations. There is no way to account for the different packages the OMAP3 is available in. Is the code omap specific, or is it shared with other chips? Philip Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html smime.p7s Description: S/MIME Cryptographic Signature
RE: DSS2 Video Overlay Scaling Patch
Tomi, I tried the patch you sent and after just a little testing I'm fairly confident the change works just fine. Thanks. I couple of comments on the configure_overlay() function. Unless I'm mis-understanding the code the overlay output rectangle is defined by the local variable x/y/outw/outh. I find it quite confusing that there are separate w h locals, since it makes it appear as if x y should be paired with w h to make a rectangle. Further more, I see x w added together, which similarly makes them appear to be part of the same rectangle. I would lightly suggest changing the x y locals to outx and outy, just for clarity sake. Also, I wonder about the code that adds x w or even y h. Shouldn't that code be adding x outw or y outh? Again, maybe I'm mis-understanding the code. Steve. -Original Message- From: Fischer Steven-P27614 Sent: Tuesday, August 04, 2009 5:22 PM To: 'Tomi Valkeinen' Cc: linux-omap@vger.kernel.org Subject: RE: DSS2 Video Overlay Scaling Patch I'll try out your patch, hopefully tomorrow, and let you know. Thanks, Steve. -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Tuesday, August 04, 2009 6:06 AM To: Fischer Steven-P27614 Cc: linux-omap@vger.kernel.org Subject: Re: DSS2 Video Overlay Scaling Patch Hi, ext Fischer Steven-P27614 wrote: Ugh, messed up morning, forgot the patch as well :( -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Fischer Steven-P27614 Sent: Tuesday, July 07, 2009 8:05 AM To: linux-omap@vger.kernel.org Subject: RE: DSS2 Video Overlay Scaling Patch Sorry, missed the subject line. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Fischer Steven-P27614 Sent: Tuesday, July 07, 2009 7:54 AM To: linux-omap@vger.kernel.org Subject: All, The DSS2 code base seems to inadvertently prevent downscaling of video overlay frames. Attached is my attempt at a patch to resolve this issue. As I gather from the code, there is an attempt to limit the overlay output frame size (x, y, outw, outh) to the managers updated window (mc-x, mc-y, mc-w, mc-h). The problem is that the input frame size (w h) is being used to instead of the output frame size (outw, outh). Due to this, when the input frame size is large than the output frame size, the input frame is being cropped, thus no downscaling occurs. My patch corrects this issue and also attempts to properly scale the input frame size if indeed the output frame is cropped. In my particular case, the output frame size is never cropped, so I have not explicitly tested these equations, but I believe they are mathematically correct. With this patch overlay downscaling is functional. It was indeed slightly broken. The code is there because we cannot use partial update for scaled overlays, but we need to update the whole overlay. Otherwise there could be visual errors on the screen. However, your patch didn't apply to my tree, and I think it can be solved in slightly more clear way. If the overlay in question is scaled, we don't even need to run that code. All we have to do is to adjust x/y depending on the x/y of the update area. Here's a patch, can you check if it works for you? Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] DSPBRIDGE: Move resource cleanup to bridge_release
Hi,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ameya Palande
Sent: Wednesday, August 05, 2009 8:25 AM
To: linux-omap@vger.kernel.org
Cc: hiroshi.d...@nokia.com; Guzman Lugo, Fernando; Ramirez Luna, Omar;
roman.tereshon...@nokia.com; Moogi, Suyog
Subject: [PATCH 2/3] DSPBRIDGE: Move resource cleanup to bridge_release
Instead of doing lazy resource cleanup in bridge_open, this patch will
move
it to bridge_release. This way the resources allocated will be cleaned up
when that instance of the open is closed and will not wait till the next
instance of open happens.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/rmgr/drv_interface.c | 132 --
-
1 files changed, 52 insertions(+), 80 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 8cbdeee..2fcd6f9 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -562,102 +562,74 @@ static void __exit bridge_exit(void)
platform_driver_unregister(bridge_driver);
}
-/* This function is called when an application opens handle to the
- * bridge driver. */
-
+/*
+ * This function is called when an application opens handle to the
+ * bridge driver.
+ */
static int bridge_open(struct inode *ip, struct file *filp)
{
int status = 0;
-#ifndef RES_CLEANUP_DISABLE
- u32 hProcess;
- DSP_STATUS dsp_status = DSP_SOK;
- HANDLE hDrvObject = NULL;
- struct PROCESS_CONTEXT*pPctxt = NULL;
- struct PROCESS_CONTEXT *next_node = NULL;
- struct PROCESS_CONTEXT*pCtxtclosed = NULL;
- struct PROCESS_CONTEXT*pCtxttraverse = NULL;
- struct task_struct *tsk = NULL;
- GT_0trace(driverTrace, GT_ENTER, - driver_open\n);
- dsp_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
+ DSP_STATUS dsp_status;
+ HANDLE hDrvObject;
+ struct PROCESS_CONTEXT *pr_ctxt = NULL;
- /* Checking weather task structure for all process existing
- * in the process context list If not removing those processes*/
- if (DSP_FAILED(dsp_status))
- goto func_cont;
+ GT_0trace(driverTrace, GT_ENTER, - bridge_open\n);
- DRV_GetProcCtxtList(pCtxtclosed, (struct DRV_OBJECT *)hDrvObject);
- while (pCtxtclosed != NULL) {
- tsk = find_task_by_vpid(pCtxtclosed-pid);
- next_node = pCtxtclosed-next;
-
- if ((tsk == NULL) || (tsk-exit_state == EXIT_ZOMBIE)) {
-
- GT_1trace(driverTrace, GT_5CLASS,
- ***Task structure not existing for
- process***%d\n, pCtxtclosed-pid);
- DRV_RemoveAllResources(pCtxtclosed);
- if (pCtxtclosed-hProcessor != NULL) {
- DRV_GetProcCtxtList(pCtxttraverse,
- (struct DRV_OBJECT *)hDrvObject);
- if (pCtxttraverse-next == NULL) {
- PROC_Detach(pCtxtclosed-hProcessor);
- } else {
- if ((pCtxtclosed-pid ==
- pCtxttraverse-pid)
- (pCtxttraverse-next != NULL)) {
- pCtxttraverse =
- pCtxttraverse-next;
- }
- while ((pCtxttraverse != NULL)
- (pCtxtclosed-hProcessor
- != pCtxttraverse-hProcessor)) {
- pCtxttraverse =
- pCtxttraverse-next;
- if ((pCtxttraverse != NULL)
- (pCtxtclosed-pid ==
- pCtxttraverse-pid)) {
- pCtxttraverse =
-pCtxttraverse-next;
- }
- }
- if (pCtxttraverse == NULL) {
- PROC_Detach
- (pCtxtclosed-hProcessor);
- }
- }
- }
- DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
- pCtxtclosed,
-
how to implement and use the Software Booting Configuration Structure in OMAP3530
Can someone offer some insight or point to an example in code (kernel or u-boot) regarding how software sets up the SW Booting Configuration Structure (as described in TRM 25.4.4.4)? Particularly, must the structure itself be stored in a particular area in scratchpad memory? Is the value at 0x48002910 supposed to be a pointer to the SW Booting Config Structure or the start of the structure itself? Thanks, twebb -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] DSPBRIDGE: Move resource cleanup to bridge_release
Hi Ernesto,
ext Ramos Falcon, Ernesto wrote:
Hi,
We have detected a use case where if an application creates a child process
using fork call, and then the child and father processes call
DSPProcessor_Attach() and create a new process context with new tgid; when
the processes are terminated, only the last process calls bridge_release
cleaning only the resources in the father process, leaving the child
resources unreleased.
One solution we have seen is to perform goes through the entire process
context list, clean up all the resources for all terminated processes or in
zombie state, as below,
DRV_GetProcCtxtList(pCtxtclosed, (struct DRV_OBJECT *)hDrvObject);
while (pCtxtclosed != NULL) {
printk(pCtxtclosed-pid = %d\n,pCtxtclosed-pid);
tsk = find_task_by_pid(pCtxtclosed-pid);
if ((tsk == NULL) || (tsk-exit_state == EXIT_ZOMBIE)) {
GT_1trace(driverTrace, GT_5CLASS,
***Task structure not existing for
process***%d\n, pCtxtclosed-pid);
DRV_RemoveAllResources(pCtxtclosed);
if (pCtxtclosed-hProcessor != NULL) {
PROC_Detach
(pCtxtclosed-hProcessor);
}
pTmp = pCtxtclosed-next;
DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
pCtxtclosed,
(void *)pCtxtclosed-pid);
} else {
pTmp = pCtxtclosed-next;
}
pCtxtclosed = pTmp;
}
Please let me know your comments.
/Ernesto
Good point :)
I would like to simplify this use case ;)
If we call DSPProcessor_Attach() twice in the same process and kill the process,
then it will leak memory for 1st instance of PROCESSOR object.
When we call open() on /dev/DspBridge a new PROCESS_CONTEXT is allocated, and it
should be allocated **only once** in bridge_open() unlike in NODE_Allocate() and
PROC_Attach(). PROCESS_CONTEXT tracks all the resources allocated on behalf of
an open file handle(and not the process / thread). When this handle is closed
all these resources should be freed in bridge_release(). Accountability of
resources should be done using PROCESS_CONTEXT and **not pid (which will be
different for different thread) / tgid (which will be different for parent and
child).
Above problem occurs because PROCESS_CONTEXT by design tracks only one PROCESSOR
object which gets freed in bridge_release().
Let me know your comments on this, and then we can proceed to fix this issue.
Cheers,
Ameya.
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3: PM: Add function omap_device_find_pdev to omap_device layer
Ranjith Lohithakshan ranji...@ti.com writes:
This patch adds a function, omap_device_find_pdev, which will get the
omap_device associated with the platform_device provided. This is currently
required by the SRF layer for setting max_dev_wakeup_lat and getting
dev_context_loss_count.
Signed-off-by: Ranjith Lohithakshan ranji...@ti.com
Thanks, appying this to PM branch for now to get SRF working again but
Paul will review/comment/merge into his omap_device branch for
upstream.
Kevin
---
arch/arm/plat-omap/include/mach/omap_device.h |2 +-
arch/arm/plat-omap/omap_device.c | 22 ++
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/omap_device.h
b/arch/arm/plat-omap/include/mach/omap_device.h
index bd0e136..5874af2 100644
--- a/arch/arm/plat-omap/include/mach/omap_device.h
+++ b/arch/arm/plat-omap/include/mach/omap_device.h
@@ -136,6 +136,6 @@ struct omap_device_pm_latency {
int (*activate_func)(struct omap_device *od);
};
-
+struct omap_device *omap_device_find_pdev(struct platform_device *pdev);
#endif
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 2c409fc..b947faf 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -685,3 +685,25 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+/**
+ * omap_device_find_pdev - look up an OMAP module by platform_device
+ * @pdev: platform_device to find
+ *
+ * Finds a registered OMAP module by the platform_device associated
+ * with it in the omap_device structure. Returns a pointer to the
+ * struct omap_device if found, or NULL otherwise.
+ */
+
+struct omap_device *omap_device_find_pdev(struct platform_device *pdev)
+{
+ struct omap_device *od;
+
+ if (!pdev)
+ return NULL;
+
+ od = _find_by_pdev(pdev);
+
+ return od;
+}
+
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] Maintainers update for hsmmc driver
Hi, I intend to post this patch upstream for TI OMAP 2430/3430 HSMMC controller driver maintainance. Any thoughts or comments welcome. Regards, Madhu Signed-off-by: Madhusudhan Chikkature madhu...@ti.com --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) Index: linux-omap-2.6/MAINTAINERS === --- linux-omap-2.6.orig/MAINTAINERS +++ linux-omap-2.6/MAINTAINERS @@ -3700,6 +3700,12 @@ L: linux-omap@vger.kernel.org S: Maintained F: drivers/mmc/host/*omap* +OMAP HS MMC SUPPORT +M: Madhusudhan Chikkature madhu...@ti.com +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/mmc/host/*omap_hsmmc* + OMAP RANDOM NUMBER GENERATOR SUPPORT M: Deepak Saxena dsax...@plexity.net S: Maintained -- To unsubscribe from this list: send the line unsubscribe 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] Maintainers update for hsmmc driver
Chikkature Rajashekar, Madhusudhan had written, on 08/05/2009 06:42 PM, the following: no body? Signed-off-by: Madhusudhan Chikkature madhu...@ti.com --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) Index: linux-omap-2.6/MAINTAINERS === --- linux-omap-2.6.orig/MAINTAINERS +++ linux-omap-2.6/MAINTAINERS @@ -3700,6 +3700,12 @@ L: linux-omap@vger.kernel.org S: Maintained F: drivers/mmc/host/*omap* this regex *omap* and your regex *omap_hsmmc* are conflicting IMHO. maybe Jarkko Lavinen jarkko.lavi...@nokia.com should comment on reducing scope? +OMAP HS MMC SUPPORT +M: Madhusudhan Chikkature madhu...@ti.com +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/mmc/host/*omap_hsmmc* + OMAP RANDOM NUMBER GENERATOR SUPPORT M: Deepak Saxena dsax...@plexity.net S: Maintained -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
Wednesday 05 August 2009 15:26:47 Janusz Krzysztofik wrote: Jarkko Nikula wrote: On Wed, 5 Aug 2009 10:21:49 +0300 I hacked a patch below. Can you test does it help? Will do tonight (CET). Sorry, but I was not able to perform any tests in a consistent way. Something strange was happening to my hardware, no matter with or without your patch, omap_mcbsp_dump_reg() readings was somewhat random. Will retry tomorrow. Now seeing how easy it was (for you ;), I think I could try to follow that way an modify omap_mcbsp_config() in the same spirit, if you find it of any use. Maybe not omap_mcbsp_config() itself, but rather asoc omap functions that prepare data for it, not sure yet. The idea would be to enable independent (asymmetric) configuration of streams. Janusz -- To unsubscribe from this list: send the line unsubscribe 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] Maintainers update for hsmmc driver
Madhusudhan said the following on 08/05/2009 07:00 PM: Signed-off-by: Madhusudhan Chikkature madhu...@ti.com --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) Index: linux-omap-2.6/MAINTAINERS === --- linux-omap-2.6.orig/MAINTAINERS +++ linux-omap-2.6/MAINTAINERS @@ -3700,6 +3700,12 @@ L: linux-omap@vger.kernel.org S: Maintained F: drivers/mmc/host/*omap* this regex *omap* and your regex *omap_hsmmc* are conflicting IMHO. Why do you think so? The omap driver which could support OMAP1 + 2420 vs omap_hsmmc driver which support 2430/3430 controller are two separate drivers. Simple: $ ls drivers/mmc/host/*omap* drivers/mmc/host/omap.c drivers/mmc/host/omap_hsmmc.c $ ls drivers/mmc/host/*omap_hsmmc* drivers/mmc/host/omap_hsmmc.c Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MMC3 Overo
On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilmankhil...@deeprootsystems.com wrote: Steve Sakoman wrote: On Wed, Aug 5, 2009 at 10:58 AM, Kevin Hilmankhil...@deeprootsystems.com wrote: Steve Sakoman wrote: And up to now in each case I shrug and say no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot I agree there are lots of shortcomings in the current mux code and we've been hitting them regularily lately. That being said, for mux settings that done one-time only at boot, what are the problems you're running into? It's been a few months since I last encountered this, so the exact details are a bit fuzzy. I seem to recall that there were some basic issues with enabling kernel pinmuxing in that some of the setup that was done for all machines was just wrong for my particular machine. IIRC, it was due to assumptions about which pad was used for a particular function (for those functions which can be steered to multiple GPIO pads). So I faced having to undo that change in my board file as well as any issues that may have arisen from glitches on the GPIO pins during the process. And since there were several of these I gave up and turned off kernel pinmuxing. I'd be happy if we cleaned up the one size fits all pinmuxing to just that subset that truly does fit all boards, and leave the rest to the board files. I'd also be content to have it all done in the board file for each machine. Indeed, any assumptions about common muxing that are not indeed common are bugs and should be fixed. The right solution is to have everything in the kernel, and split across SoC common init and board specific init. Of course u-boot will still have to do some early muxing, but it should be redone in the kernel so it's trivial to change bootloaders. So the real missing piece is someone to step up and rework the mux code. The bigger problem is that the vast majority of folks don't care about the common case and only care about getting thing working for a specific platform. Kevin I like the idea of having the board file configure the mux. First of all lets address the shortcomings of mux.h. The Pin values are labeled as so: snip from mux.h * NOTE: Please use the following naming style for new pin entries. * For example, W8_1610_MMC2_DAT0, where: * - W8 = ball * - 1610 = 1510 or 1610, none if common for both 1510 and 1610 * - MMC2_DAT0 = function But lets take the 3530 as an example. The 3530 has three separate packages. CBB, CBC, and CUS. Now lets look at MMC3_clk (the root of my original problem that started this thread) CBB CBC CUS mmc3_clk AB1 / AF10 R9 / AB2 AC1 So to properly add these to mux.h we need to add 5 entries for mmc3_clk AB1_35XXCBB_MMC3_CLK AF10_35XXCBB_MMC3_CLK R9_35XXCBC_MMC3_CLK AB2_35XXCBC_MMC3_CLK AC1_35XXCUS_MMC3_CLK We would then have to update mux.c making sure the position matches and add the proper settings. So this is obviously a maintenance nightmare. Another option is to add a CONFIG_35XX_CBB or CBC or CUS when selecting a board example in menuconfig selecting MACH_OVERO would select CONFIG_35XX_CBB. Then in a new mux_35xx.h located in the mach_omap2 folder have #ifdef CONFIG_35XX_CBB //all muxable balls #define N4 0x078 #define AB1 0x164 etc . #endif where we just use the Ball name defined as its offset in the 35xx case then we create a file say board_overo_mux.c in it we call configure_pin(AB1, MODE3, INPUT | PU | PE); for every ball that is muxable. voila, we have a predefined limit of pins so once mux_35xx.h is fully defined, and the driver code is in place then the only thing that a developer would need to do to leverage the mux is edit his board file. Im sure I have glossed ove many details but this is a general outline. -- To unsubscribe from this list: send the line unsubscribe 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: Fwd: MMC3 Overo
On Wednesday 05 August 2009 11:55, Philip Balister wrote: Kevin Hilman wrote: Steve Sakoman wrote: On Wed, Aug 5, 2009 at 10:58 AM, Kevin Hilmankhil...@deeprootsystems.com wrote: Steve Sakoman wrote: And up to now in each case I shrug and say no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot I agree there are lots of shortcomings in the current mux code and we've been hitting them regularily lately. That being said, for mux settings that done one-time only at boot, what are the problems you're running into? It's been a few months since I last encountered this, so the exact details are a bit fuzzy. I seem to recall that there were some basic issues with enabling kernel pinmuxing in that some of the setup that was done for all machines was just wrong for my particular machine. IIRC, it was due to assumptions about which pad was used for a particular function (for those functions which can be steered to multiple GPIO pads). So I faced having to undo that change in my board file as well as any issues that may have arisen from glitches on the GPIO pins during the process. And since there were several of these I gave up and turned off kernel pinmuxing. I'd be happy if we cleaned up the one size fits all pinmuxing to just that subset that truly does fit all boards, and leave the rest to the board files. I'd also be content to have it all done in the board file for each machine. Indeed, any assumptions about common muxing that are not indeed common are bugs and should be fixed. The right solution is to have everything in the kernel, and split across SoC common init and board specific init. Of course u-boot will still have to do some early muxing, but it should be redone in the kernel so it's trivial to change bootloaders. So the real missing piece is someone to step up and rework the mux code. The bigger problem is that the vast majority of folks don't care about the common case and only care about getting thing working for a specific platform. I posted some changes to add support for changing the Beagle expansion connector MCSPI muxing in the board file and some general muxing questions and received no comments (OK, a number of people were on vacation). If people would like I can repost it to aid in discussion. I agree we need to more muxing in the kernel and less in u-boot. I do not want a different u-boot for the Beagle based on what I have connected to the expansion connector. (Same applies to the Overo) It is worse then that. Doing it in U-boot implies a static mux config. I can see cases where there is a need to change the mux config during run time. For example on the OMAP3 Beagle board platform, there is an LCD connector with a signals that is shared with the onboard DVI framer and potentially an external LCD. Due to the limited number of signals, some of the shared lines might be used for a different function when the LCD is active but have to revert to the DSS control if the DVI framer is used. This would require the mux be dynamically programmable. The current mux requires you make an entry in an enum, then a corresponding entry in an array to configure the pin. SO the enum length is basically number of pins * the number of possible pin configurations. There is no way to account for the different packages the OMAP3 is available in. Is the code omap specific, or is it shared with other chips? My understanding iis the code is OMAP specific. OMAP2 and OMAP3 are very similar. One idea that was thrown around on the Beagle IRC channel is to replace this code with an API that would solve the scaling problem. Something like this: omap_pinmux_config( PACKAGE_PIN_ID, MODE_N, INPUT_EN | PULL_UP ); Where PACKAGE_PIN_ID would be a #define or an enum used to map to a register. The name should encode the packagename and the pin/ball. This avoids the current confusion as the current enums do not indicate what package. The MODE_N is an ID to indicate which mode the pin should be put into. INPUT_EN|PULL_UP are the options for the ball. For ease of integrating with existing code, #defines matching the current enum name can be created to map them the options. Such a define would also add back self documenting feature of the enum names. This is a very crude proposal but does this sound like something better? The other unknown is I am not familiar enough with the OMAP1 pinmux to know if this would work. Philip Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hunyue Yau -- To unsubscribe from this list: send the line unsubscribe 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] Maintainers update for hsmmc driver
Madhusudhan said the following on 08/05/2009 07:00 PM: Signed-off-by: Madhusudhan Chikkature madhu...@ti.com --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) Index: linux-omap-2.6/MAINTAINERS === --- linux-omap-2.6.orig/MAINTAINERS +++ linux-omap-2.6/MAINTAINERS @@ -3700,6 +3700,12 @@ L: linux-omap@vger.kernel.org S:Maintained F:drivers/mmc/host/*omap* this regex *omap* and your regex *omap_hsmmc* are conflicting IMHO. Why do you think so? The omap driver which could support OMAP1 + 2420 vs omap_hsmmc driver which support 2430/3430 controller are two separate drivers. Simple: $ ls drivers/mmc/host/*omap* drivers/mmc/host/omap.c drivers/mmc/host/omap_hsmmc.c $ ls drivers/mmc/host/*omap_hsmmc* drivers/mmc/host/omap_hsmmc.c I got your point now. I will resubmit the patch by explicitly changing *omap* to omap.c and *omap_hsmmc* to omap_hsmmc.c. Regards, Madhu Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
