Re: [PATCH 09/12] CORE OFF support in omap_sram_idle
Hello Rajendra, one more comment from me...
"ext Rajendra Nayak" <[EMAIL PROTECTED]> writes:
> struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
> Index: linux-omap-2.6/arch/arm/mach-omap2/pm34xx.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/pm34xx.c 2008-09-01
> 18:23:19.0 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/pm34xx.c 2008-09-01
> 18:24:02.0
> +0530
> @@ -27,10 +27,13 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> +#include
> #include
>
> #include "cm.h"
> @@ -58,6 +61,7 @@ static struct powerdomain *mpu_pwrdm, *n
> static struct powerdomain *core_pwrdm, *per_pwrdm;
>
> int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
> +void omap3_restore_sram_ctx(void);
>
> u32 context_mem[128];
>
> @@ -91,6 +95,16 @@ static void gpio_fclk_mask(u32 *fclk)
> *fclk &= ~(0x1f << 13);
> }
>
> +void omap3_save_per_ctx(void)
> +{
> + omap3_gpio_save();
> +}
> +
> +void omap3_restore_per_ctx(void)
> +{
> + omap3_gpio_restore();
> +}
> +
> /* PRCM Interrupt Handler for wakeups */
> static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
> {
> @@ -225,6 +239,7 @@ void omap_sram_idle(void)
> int mpu_next_state = PWRDM_POWER_ON;
> int per_next_state = PWRDM_POWER_ON;
> int core_next_state = PWRDM_POWER_ON;
> + int core_prev_state, per_prev_state;
>
> if (!_omap_sram_idle)
> return;
> @@ -261,15 +276,27 @@ void omap_sram_idle(void)
> /* PER changes only with core */
> per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
> if (per_next_state < PWRDM_POWER_ON) {
> + if (per_next_state == PWRDM_POWER_OFF) {
> + omap3_save_per_ctx();
> + omap3_save_uart_ctx(2);
> + }
> if (clocks_off_while_idle) {
> per_gpio_clk_disable();
> omap_serial_enable_clocks(0, 2);
> }
> }
> + if (core_next_state == PWRDM_POWER_OFF) {
> + omap3_save_core_ctx();
> + omap3_save_prcm_ctx();
Prcm is saved twice, once here...
> + omap3_save_uart_ctx(0);
> + omap3_save_uart_ctx(1);
> + }
> if (clocks_off_while_idle) {
> omap_serial_enable_clocks(0, 0);
> omap_serial_enable_clocks(0, 1);
> }
> + if (core_next_state == PWRDM_POWER_OFF)
> + omap3_save_prcm_ctx();
And then again here.
--
Jouni Högander
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HyperSPARC RT625 Cache Controler, Ross CY7C605 Cache Controler, Cache Aliases, and Linux MM Code
From: Piet Delaney <[EMAIL PROTECTED]> Date: Mon, 08 Sep 2008 22:07:26 -0700 > Wonder why the update_mmu_cache() for sun4c has to do so much more > work that sun4m. Caches are virtually indexed and virtually tagged on sun4c, that's why. Keep on wonderin' > Wonder why SPARC has to do more work that ARM. ARMs that have the cache issues aren't SMP, that's why. Keep on wonderin' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: setting GOLCD bit for shadow registers to make effect
On Tue, Sep 9, 2008 at 1:32 AM, Måns Rullgård <[EMAIL PROTECTED]> wrote: > "arun c" <[EMAIL PROTECTED]> writes: > >> A shadow register change has no direct effect on the display >> configuration until the GOLCD (DISPC_CONTROL[5]) is set. >> >> Signed-off-by: Arun C <[EMAIL PROTECTED]> >> --- >> drivers/video/omap/dispc.c |5 + >> 1 files changed, 5 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c >> index 82ba030..2e7af85 100644 >> --- a/drivers/video/omap/dispc.c >> +++ b/drivers/video/omap/dispc.c >> @@ -436,6 +436,11 @@ static inline int _setup_plane(int plane, int >> channel_out, >> >> dispc_write_reg(ri_reg[plane], (screen_width - width) * bpp / 8 + 1); >> >> + /* Wait untill GOLCD bit is cleared and set it */ > > Nit: "until" (one l) > >> + while (dispc_read_reg(DISPC_CONTROL) & (1 << 5)) >> + continue; >> + MOD_REG_FLD(DISPC_CONTROL, 1 << 5, 1 << 5); >> + >> return height * screen_width * bpp / 8; >> } > > This looks good. However, the same thing is needed in > omap_dispc_enable_plane() as well. Placing the loop+set in a function > (go_lcd()?) would make sense. > Thanks. Yes that will be nice, I still see modification of shadow registers in some more places with out issuing a GOLCD. I agree the best method is to make it a function > -- > Måns Rullgård > [EMAIL PROTECTED] > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc3-omap1] omap2_nand updates
* Felipe Balbi <[EMAIL PROTECTED]> [080831 14:54]:
> On Sun, Aug 31, 2008 at 02:19:05PM -0700, David Brownell wrote:
> > From: David Brownell <[EMAIL PROTECTED]>
> >
> > Minor updates to the OMAP{2,3} NAND driver:
> >
> > - Rename those buffer PIO routines as *_buf16()
> > - Get rid of pointless LE16 data conversions; OMAP is always LE
> > - Speed up buffer reads by switching to __raw_readsl()
> >
> > Right now this driver only handles 16-bit NAND, but eventually it
> > should handle 8-bit too. Moreover it may be worth using DMA...
> >
> > Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
> Thanks Dave, I'll melded it up in my queue.
Pushing to linux-omap tree today.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/5] ALSA: ASoC: Add support for TWL4030 audio codec (rev 3)
* Steve Sakoman <[EMAIL PROTECTED]> [080908 11:16]: > On Mon, Sep 8, 2008 at 2:56 AM, Mark Brown <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 06, 2008 at 11:41:42PM -0700, [EMAIL PROTECTED] wrote: > > > >> + > >> +config SND_SOC_TWL4030 > >> + tristate > >> + depends on SND_SOC && I2C > >> + > > > > Sorry, didn't notice earlier: this should depend on whatever the config > > option is for the TWL4030 core driver rather than on I2C since it > > doesn't actually interact with I2C directly. Although in most > > applications this won't make much odds since the machine driver will > > select the codec driver and select ignores the dependencies anyway. > > You are correct. Good catch, though as you say it doesn't really > matter in practice. > > I will re-submit a version with this fixed nonetheless. Pushing this series to linux-omap today with the re-submitted version of patch 3/5. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2 rev2] McBSP and ASoC OMAP update patches for 2430 and 34xx
* Jarkko Nikula <[EMAIL PROTECTED]> [080908 03:30]: > Here is second version of patch adding support for 2430 in McBSP driver. > Updated version uses phys_base instead of virt_base. See following commits > from Russell King: > > ecec3b3e080464cc1b4e792cf4d8e7e89d50b011 > 2cfd6fcda3b8c6ee7a5fa9a4573e3246532a0716 > > Second patch is the same than first version. It's for testing ASoC OMAP > and eventually it will go through the alsa-devel. Thanks, pushing these to l-o tree. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - Omapzoom] [NAND] Add prefetch and DMA support
On Monday 08 September 2008, Kamat, Nishant wrote: > +config MTD_NAND_OMAP_PREFETCH > + bool "GPMC prefetch support for NAND Flash device" > + depends on MTD_NAND && MTD_NAND_OMAP2 > + default n > + help > + The NAND device can be accessed for Read/Write using GPMC PREFETCH > engine > + to improve the performance. Is there a reason this isn't always enabled, and the choice is just whether to use DMA or not? I'd be interested to see performance measurements for the three cases. - current/slow code - the readsw() update I sent previously - this "prefetch engine" And I'd expect this "prefetch engine" code would also be improved by using readsw() and writesw() when DMA isn't in use. On one ARM926 I observed a 16% speedup *just* from switching from slow byte-at-a-time PIO to using readsb ... this current code has that same pessimization. - Dave > + > +choice > + prompt "Prefetch engine support for GPMC" > + depends on MTD_NAND_OMAP_PREFETCH > + help > + The GPMC PREFETCH engine can be configured eigther in MPU interrupt > mode > + or in DMA interrupt mode. > + > +config MTD_NAND_OMAP_PREFETCH_MPU > + depends on MTD_NAND_OMAP_PREFETCH > + bool "MPU mode always for spare area + MPU mode for main area" > + help > + Say y if... you want MPU interrupt mode for both spare area and main > area accesses. > + > +config MTD_NAND_OMAP_PREFETCH_DMA > + depends on MTD_NAND_OMAP_PREFETCH > + bool "MPU mode always for spare area + DMA mode for main area" > + help > + Say y if... you want MPU interrupt mode for spare area and DMA mode > for main > + area access. > + > +endchoice > + -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend][PATCH - Omapzoom][NAND] Add prefetch and DMA support
On Monday 08 September 2008, Russell King - ARM Linux wrote: > > - while (len--) > > - *p++ = cpu_to_le16(readw(info->nand.IO_ADDR_R)); > > This driver needs work (see endianness explaination below.) Already done, but this patch doesn't build on that patch... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - Omapzoom] [NAND] Add prefetch and DMA support
On Monday 08 September 2008, Kamat, Nishant wrote:
> - while (len--)
> - *p++ = cpu_to_le16(readw(info->nand.IO_ADDR_R));
> + if (use_prefetch) {
Em, clearly this does not go on top of the NAND patch I
sent recently ... please do that instead, so we don't
need to repeat the cleanups.
http://marc.info/?l=linux-omap&m=122021756032341&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/5] ALSA: ASoC: Add support for TWL4030 audio codec (rev 4)
From: Steve Sakoman <[EMAIL PROTECTED]>
Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]>
Acked-by: Mark Brown <[EMAIL PROTECTED]>
---
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/twl4030.c | 653
sound/soc/codecs/twl4030.h | 197 +
4 files changed, 857 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/twl4030.c
create mode 100644 sound/soc/codecs/twl4030.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 1db04a2..2f00e1e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -50,3 +50,8 @@ config SND_SOC_CS4270_VD33_ERRATA
config SND_SOC_TLV320AIC3X
tristate
depends on I2C
+
+config SND_SOC_TWL4030
+ tristate
+ depends on SND_SOC && TWL4030_CORE
+
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index d7b97ab..a519ced 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -10,6 +10,7 @@ snd-soc-wm9712-objs := wm9712.o
snd-soc-wm9713-objs := wm9713.o
snd-soc-cs4270-objs := cs4270.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
+snd-soc-twl4030-objs := twl4030.o
obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o
obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o
@@ -23,3 +24,4 @@ obj-$(CONFIG_SND_SOC_WM9712) += snd-soc-wm9712.o
obj-$(CONFIG_SND_SOC_WM9713) += snd-soc-wm9713.o
obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
+obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
new file mode 100644
index 000..ee2f0d3
--- /dev/null
+++ b/sound/soc/codecs/twl4030.c
@@ -0,0 +1,653 @@
+/*
+ * ALSA SoC TWL4030 codec driver
+ *
+ * Author: Steve Sakoman, <[EMAIL PROTECTED]>
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "twl4030.h"
+
+/*
+ * twl4030 register cache & default register settings
+ */
+static const u8 twl4030_reg[TWL4030_CACHEREGNUM] = {
+ 0x00, /* this register not used */
+ 0x93, /* REG_CODEC_MODE (0x1) */
+ 0xc3, /* REG_OPTION (0x2) */
+ 0x00, /* REG_UNKNOWN(0x3) */
+ 0x00, /* REG_MICBIAS_CTL(0x4) */
+ 0x24, /* REG_ANAMICL(0x5) */
+ 0x04, /* REG_ANAMICR(0x6) */
+ 0x0a, /* REG_AVADC_CTL (0x7) */
+ 0x00, /* REG_ADCMICSEL (0x8) */
+ 0x00, /* REG_DIGMIXING (0x9) */
+ 0x0c, /* REG_ATXL1PGA (0xA) */
+ 0x0c, /* REG_ATXR1PGA (0xB) */
+ 0x00, /* REG_AVTXL2PGA (0xC) */
+ 0x00, /* REG_AVTXR2PGA (0xD) */
+ 0x01, /* REG_AUDIO_IF (0xE) */
+ 0x00, /* REG_VOICE_IF (0xF) */
+ 0x00, /* REG_ARXR1PGA (0x10) */
+ 0x00, /* REG_ARXL1PGA (0x11) */
+ 0x6c, /* REG_ARXR2PGA (0x12) */
+ 0x6c, /* REG_ARXL2PGA (0x13) */
+ 0x00, /* REG_VRXPGA (0x14) */
+ 0x00, /* REG_VSTPGA (0x15) */
+ 0x00, /* REG_VRX2ARXPGA (0x16) */
+ 0x0c, /* REG_AVDAC_CTL (0x17) */
+ 0x00, /* REG_ARX2VTXPGA (0x18) */
+ 0x00, /* REG_ARXL1_APGA_CTL (0x19) */
+ 0x00, /* REG_ARXR1_APGA_CTL (0x1A) */
+ 0x4b, /* REG_ARXL2_APGA_CTL (0x1B) */
+ 0x4b, /* REG_ARXR2_APGA_CTL (0x1C) */
+ 0x00, /* REG_ATX2ARXPGA (0x1D) */
+ 0x00, /* REG_BT_IF (0x1E) */
+ 0x00, /* REG_BTPGA (0x1F) */
+ 0x00, /* REG_BTSTPGA(0x20) */
+ 0x00, /* REG_EAR_CTL(0x21) */
+ 0x24, /* REG_HS_SEL (0x22) */
+ 0x0a, /* REG_HS_GAIN_SET(0x23) */
+ 0x00, /* REG_HS_POPN_SET(0x24) */
+ 0x00, /* REG_PREDL_CTL (0x25) */
+ 0x00, /* REG_PREDR_CTL (0x26) */
+ 0x00, /* REG_PRECKL_CTL (0x27) */
+ 0x00, /* REG_PRECKR_CTL (0x28) */
+ 0x00, /* REG_HFL_CTL(0x29) */
+
Re: [PATCH 32/33] add omap 1-wire interface driver
On Mon, Sep 08, 2008 at 11:05:21AM -0700, Tony Lindgren wrote: > * Madhusudhan Chikkature <[EMAIL PROTECTED]> [080908 05:15]: > > > > - Original Message - > > From: "Tony Lindgren" <[EMAIL PROTECTED]> > > To: "Madhusudhan Chikkature" <[EMAIL PROTECTED]> > > Cc: "Felipe Balbi" <[EMAIL PROTECTED]>; ; > > "Felipe Balbi" <[EMAIL PROTECTED]> > > Sent: Friday, September 05, 2008 11:29 PM > > Subject: Re: [PATCH 32/33] add omap 1-wire interface driver > > > > > > >* Madhusudhan Chikkature <[EMAIL PROTECTED]> [080901 06:16]: > > >> Hi, > > >> > > >> The HDQ patchset that I posted to Tony were given ACK by Evgeniy > > >> Polyakov on the omap list. I hope that helps. > > > > > > Madhu, can you post your 1-wire driver to LKML and Cc Evgeniy Polyakov > > > so we can get that integrated? Also Cc l-o list. > > I have a question regarding this. In fact it can be a generic question > > which might apply for other drivers as well. How do we post the OMAP3 > > related driver patches to LKML or any other driver specific lists if OMAP3 > > base support is not already present there? > > Well the drivers should not have dependencies to omap3 headers. > And hopefully we'll have the minimal omap3 support integrated when > 2.6.28 opens. > > Also, you're already getting IORESOURCE_MEM as rerource. And isn't > this driver also on 24XX chips too? > > BTW, how about change it to use __raw_read/write instead of > omap_read/write? Just ioremap the IORESOURCE_MEM, see > the recent ioremap changes. Last point - shouldn't it be converted to using mutexes instead of semaphores? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: setting GOLCD bit for shadow registers to make effect
"arun c" <[EMAIL PROTECTED]> writes: > A shadow register change has no direct effect on the display > configuration until the GOLCD (DISPC_CONTROL[5]) is set. > > Signed-off-by: Arun C <[EMAIL PROTECTED]> > --- > drivers/video/omap/dispc.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c > index 82ba030..2e7af85 100644 > --- a/drivers/video/omap/dispc.c > +++ b/drivers/video/omap/dispc.c > @@ -436,6 +436,11 @@ static inline int _setup_plane(int plane, int > channel_out, > > dispc_write_reg(ri_reg[plane], (screen_width - width) * bpp / 8 + 1); > > + /* Wait untill GOLCD bit is cleared and set it */ Nit: "until" (one l) > + while (dispc_read_reg(DISPC_CONTROL) & (1 << 5)) > + continue; > + MOD_REG_FLD(DISPC_CONTROL, 1 << 5, 1 << 5); > + > return height * screen_width * bpp / 8; > } This looks good. However, the same thing is needed in omap_dispc_enable_plane() as well. Placing the loop+set in a function (go_lcd()?) would make sense. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]Add 3430 SDP board level support for HSMMC2
On Wednesday 13 August 2008, Madhusudhan Chikkature wrote: > > A better way to do this would be to let the boards say exactly > > what the hardware configuration is, rather than requiring all > > OMAP3 boards to be set up exactly like the SDP... > > I think the initial version was written specific to SDP. Later > on it was changed to hsmmc.c and the platforms which required > simillar setup as SDP started using it. Right ... > Now, if support for a new board is required which is unlike SDP a > new file can still be added for that perticular board, right? Each board already gets a board-XYZ.c file. So the clean way to do this is to have that file set up its hsmmc config ... NOT to clone versions of hsmmc.c for each board! -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/5] ALSA: ASoC: Add support for TWL4030 audio codec (rev 3)
On Mon, Sep 8, 2008 at 2:56 AM, Mark Brown <[EMAIL PROTECTED]> wrote: > On Sat, Sep 06, 2008 at 11:41:42PM -0700, [EMAIL PROTECTED] wrote: > >> + >> +config SND_SOC_TWL4030 >> + tristate >> + depends on SND_SOC && I2C >> + > > Sorry, didn't notice earlier: this should depend on whatever the config > option is for the TWL4030 core driver rather than on I2C since it > doesn't actually interact with I2C directly. Although in most > applications this won't make much odds since the machine driver will > select the codec driver and select ignores the dependencies anyway. You are correct. Good catch, though as you say it doesn't really matter in practice. I will re-submit a version with this fixed nonetheless. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend][PATCH - Omapzoom][NAND] Add prefetch and DMA support
On Mon, Sep 08, 2008 at 01:03:35PM -0500, [EMAIL PROTECTED] wrote:
> +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
> + static int use_prefetch = 1;
> +
> + /* "modprobe ... use_prefetch=0" etc */
> + module_param(use_prefetch, bool, 0);
> + MODULE_PARM_DESC(use_prefetch, "enable/disable use of PREFETCH");
Don't indent C code just because there's preprocessor stuff around it.
> @@ -127,6 +148,9 @@
> unsigned long phys_base;
> void __iomem*gpmc_cs_baseaddr;
> void __iomem*gpmc_baseaddr;
> + void __iomem*nand_pref_fifo_add;
Ok, nand_pref_fifo_add is MMIO.
> + struct completion comp;
> + int dma_ch;
> };
>
> /*
> @@ -190,6 +214,85 @@
> __raw_writeb(cmd, info->nand.IO_ADDR_W);
> }
>
> +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
> +/*
> + * omap_nand_dma_cb: callback on the completion of dma transfer
> + * @lch: logical channel
> + * @ch_satuts: channel status
> + * @data: pointer to completion data structure
> + */
> +static void omap_nand_dma_cb(int lch, u16 ch_status, void *data)
> +{
> + complete((struct completion *) data);
> +}
> +
> +/*
> + * omap_nand_dma_transfer: configer and start dma transfer
> + * @mtd: MTD device structure
> + * @addr: virtual address in RAM of source/destination
> + * @count: number of data bytes to be transferred
> + * @is_write: flag for read/write operation
> + */
> +static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
> + unsigned int count, int is_write)
> +{
> + struct omap_nand_info *info = container_of(mtd,
> + struct omap_nand_info, mtd);
> +
> + uint32_t prefetch_status = 0;
> +
> + /* The fifo depth is 64 bytes. We have a synch at each frame and frame
> + * length is 64 bytes.
> + */
> + int buf_len = count/64;
> +
> + if (is_write) {
> + omap_set_dma_dest_params(info->dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
> + info->phys_base, 0, 0);
> + omap_set_dma_dest_burst_mode(info->dma_ch, OMAP_DMA_DATA_BURST_16);
> + omap_set_dma_src_params(info->dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
> + virt_to_phys(addr), 0, 0);
> + omap_set_dma_src_burst_mode(info->dma_ch, OMAP_DMA_DATA_BURST_16);
> + omap_set_dma_transfer_params(info->dma_ch, OMAP_DMA_DATA_TYPE_S32,
> + 0x10, buf_len, OMAP_DMA_SYNC_FRAME,
> + OMAP24XX_DMA_GPMC, OMAP_DMA_DST_SYNC);
> + } else {
> + omap_set_dma_src_params(info->dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
> + info->phys_base, 0, 0);
> + omap_set_dma_src_burst_mode(info->dma_ch, OMAP_DMA_DATA_BURST_16);
> + omap_set_dma_dest_params(info->dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
> + virt_to_phys(addr), 0, 0);
> + omap_set_dma_dest_burst_mode(info->dma_ch, OMAP_DMA_DATA_BURST_16);
> + omap_set_dma_transfer_params(info->dma_ch, OMAP_DMA_DATA_TYPE_S32,
> + 0x10, buf_len, OMAP_DMA_SYNC_FRAME,
> + OMAP24XX_DMA_GPMC, OMAP_DMA_SRC_SYNC);
> + }
> +
> + /* configure and start prefetch transfer */
> + gpmc_prefetch_start(info->gpmc_cs, 0x1, count, is_write);
> + init_completion(&info->comp);
> + dma_sync_single_for_cpu(&info->pdev->dev,
> + virt_to_phys(addr), count, DMA_TO_DEVICE);
Please read the DMA API and use the proper functions. This is an abuse
of the DMA API.
> + omap_start_dma(info->dma_ch);
> + wait_for_completion(&info->comp);
> + if (!is_write)
> + dma_sync_single_for_cpu(&info->pdev->dev,
> + virt_to_phys(addr), count, DMA_FROM_DEVICE);
Ditto. This is an abuse of the API. This is how it's supposed to work:
enum dma_direction dir = is_write ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
dma_addr_t dma_addr;
dma_addr = dma_map_single(&info->pdev->dev, addr, count, dir);
/* setup and start DMA using dma_addr */
wait_for_completion(&info->comp);
dma_unmap_single(&info->pdev->dev, dma_addr, count, dir);
> + prefetch_status = gpmc_prefetch_status();
> + while (prefetch_status & 0x3FFF)
> + prefetch_status = gpmc_prefetch_status();
> +
> + /* disable and stop the PFPW engine */
> + gpmc_prefetch_stop();
> + return 0;
> +}
> +#else
> +static void omap_nand_dma_cb(int lch, u16 ch_status, void *data) {}
> +static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
> + unsigned int count, int is_write)
> +{return 0; }
> +#endif
> +
> /*
> * omap_read_bu
[PATCH - Omapzoom][ONENAND] Add synchronous burst support
From: Vimal Singh <[EMAIL PROTECTED]>
Following patch taken over the omapzoom.org tree adds
synchronous burst read support to the OMAP2/3 onenand driver.
Signed-off-by: Vimal Singh <[EMAIL PROTECTED]>
Signed-off-by: Nishant Kamat <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-3430sdp-flash.c | 59 +++---
drivers/mtd/onenand/Kconfig |6 +++
2 files changed, 60 insertions(+), 5 deletions(-)
Index: omapkernel/drivers/mtd/onenand/Kconfig
===
--- omapkernel.orig/drivers/mtd/onenand/Kconfig 2008-09-08 12:35:43.0
+0530
+++ omapkernel/drivers/mtd/onenand/Kconfig 2008-09-08 13:00:39.0
+0530
@@ -70,4 +70,10 @@
The simulator may simulate various OneNAND flash chips for the
OneNAND MTD layer.
+config MTD_ONENAND_SYNC_BURST_READ
+ bool "OneNand Synchronous burst read support"
+ help
+ Support for synchronous burst reads for a OneNand flash
+ device
+
endif # MTD_ONENAND
Index: omapkernel/arch/arm/mach-omap2/board-3430sdp-flash.c
===
--- omapkernel.orig/arch/arm/mach-omap2/board-3430sdp-flash.c 2008-09-08
12:35:43.0 +0530
+++ omapkernel/arch/arm/mach-omap2/board-3430sdp-flash.c2008-09-08
13:00:39.0 +0530
@@ -76,8 +76,16 @@
};
struct gpmc_cs_config pdc_onenand_gpmc_setting[] = {
+#ifdef CONFIG_MTD_ONENAND_SYNC_BURST_READ
+ {0x60801200, 0xF0900, 0x00030200, 0x0F040901, 0x0109100A, 0x1F06},
+#else
{0x1200, 0x000F0F01, 0x00030301, 0x0F040F04, 0x010F1010, 0x1F06},
+#endif
+#ifdef CONFIG_MTD_ONENAND_SYNC_BURST_READ
+ {0x62801201, 0xF1000, 0x00030200, 0x0F041002, 0x02101013, 0x1F06}
+#else
{0x1200, 0x000F0F01, 0x00030301, 0x0F040F04, 0x010F1010, 0x1F06}
+#endif
};
struct gpmc_cs_config fpga_gpmc_setting[] = {
@@ -252,15 +260,56 @@
.resource = &sdp_nand_resource,
};
-/*
- * sdp_onenand_setup - The function configures the onenand flash.
- * @onenand_base: Onenand base address
+static unsigned short omap2_onenand_readw(void __iomem *addr)
+{
+ return readw(addr);
+}
+
+static void omap2_onenand_writew(unsigned short value, void __iomem *addr)
+{
+ writew(value, addr);
+}
+
+static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
+ int freq)
+{
+#ifdef CONFIG_MTD_ONENAND_SYNC_BURST_READ
+ u32 reg;
+
+ /* Configure OneNAND for sync read */
+ reg = omap2_onenand_readw(onenand_base + ONENAND_REG_SYS_CFG1);
+ reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
+ reg |= (0x06 << ONENAND_SYS_CFG1_BRL_SHIFT) |
+ ONENAND_SYS_CFG1_SYNC_READ |
+ ONENAND_SYS_CFG1_BL_8 | 0x04;
+ omap2_onenand_writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
+
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, 0xf1000);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, 0x00030200);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, 0x0f041002);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG5, 0x02101013);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG6, 0x1f06);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, 0x62801201);
+#endif
+ return 0;
+}
+
+/**
+ * sdp_onenand_setup - Set the onenand sync mode
+ * @onenand_base: The onenand base address in GPMC memory map
*
- * @return int:Currently always returning zero.
*/
static int sdp_onenand_setup(void __iomem *onenand_base, int freq)
{
- /* Onenand setup does nothing at present */
+ struct omap_onenand_platform_data *datap = &sdp_onenand_data;
+ struct device *dev = &sdp_onenand_device.dev;
+
+ /* Set sync timings in GPMC */
+ if (omap2_onenand_set_sync_mode(datap->cs, onenand_base, freq) < 0) {
+ dev_err(dev, "Unable to set synchronous mode\n");
+ return -EINVAL;
+ }
+
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 32/33] add omap 1-wire interface driver
* Madhusudhan Chikkature <[EMAIL PROTECTED]> [080908 05:15]: > > - Original Message - > From: "Tony Lindgren" <[EMAIL PROTECTED]> > To: "Madhusudhan Chikkature" <[EMAIL PROTECTED]> > Cc: "Felipe Balbi" <[EMAIL PROTECTED]>; ; "Felipe > Balbi" <[EMAIL PROTECTED]> > Sent: Friday, September 05, 2008 11:29 PM > Subject: Re: [PATCH 32/33] add omap 1-wire interface driver > > > >* Madhusudhan Chikkature <[EMAIL PROTECTED]> [080901 06:16]: > >> Hi, > >> > >> The HDQ patchset that I posted to Tony were given ACK by Evgeniy Polyakov > >> on the omap list. I hope that helps. > > > > Madhu, can you post your 1-wire driver to LKML and Cc Evgeniy Polyakov > > so we can get that integrated? Also Cc l-o list. > I have a question regarding this. In fact it can be a generic question which > might apply for other drivers as well. How do we post the OMAP3 related > driver patches to LKML or any other driver specific lists if OMAP3 base > support is not already present there? Well the drivers should not have dependencies to omap3 headers. And hopefully we'll have the minimal omap3 support integrated when 2.6.28 opens. Also, you're already getting IORESOURCE_MEM as rerource. And isn't this driver also on 24XX chips too? BTW, how about change it to use __raw_read/write instead of omap_read/write? Just ioremap the IORESOURCE_MEM, see the recent ioremap changes. Regards, Tony > > Regards, > Madhu > > > > Thanks, > > > > Tony > > > >> > >> Regards, > >> Madhu > >> > >> - Original Message - > >> From: "Felipe Balbi" <[EMAIL PROTECTED]> > >> To: > >> Cc: "Felipe Balbi" <[EMAIL PROTECTED]> > >> Sent: Saturday, August 30, 2008 10:46 PM > >> Subject: [PATCH 32/33] add omap 1-wire interface driver > >> > >> > >> > From: Felipe Balbi <[EMAIL PROTECTED]> > >> > > >> > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> > >> > --- > >> > arch/arm/plat-omap/include/mach/irqs.h |2 + > >> > drivers/w1/masters/Kconfig |7 + > >> > drivers/w1/masters/Makefile|1 + > >> > drivers/w1/masters/omap_hdq.c | 704 > >> > > >> > 4 files changed, 714 insertions(+), 0 deletions(-) > >> > create mode 100644 drivers/w1/masters/omap_hdq.c > >> > > >> > diff --git a/arch/arm/plat-omap/include/mach/irqs.h > >> > b/arch/arm/plat-omap/include/mach/irqs.h > >> > index 17248bb..c9e95a6 100644 > >> > --- a/arch/arm/plat-omap/include/mach/irqs.h > >> > +++ b/arch/arm/plat-omap/include/mach/irqs.h > >> > @@ -54,6 +54,8 @@ > >> > #define INT_TIMER2 30 > >> > #define INT_LCD_CTRL 31 > >> > > >> > +#define INT_24XX_HDQ_IRQ 58 /* Temporarily here for driver to build */ > >> > + > >> > /* > >> > * OMAP-1510 specific IRQ numbers for interrupt handler 1 > >> > */ > >> > diff --git a/drivers/w1/masters/Kconfig b/drivers/w1/masters/Kconfig > >> > index c449309..636d4f7 100644 > >> > --- a/drivers/w1/masters/Kconfig > >> > +++ b/drivers/w1/masters/Kconfig > >> > @@ -42,6 +42,13 @@ config W1_MASTER_DS1WM > >> >in HP iPAQ devices like h5xxx, h2200, and ASIC3-based like > >> >hx4700. > >> > > >> > +config HDQ_MASTER_OMAP > >> > + tristate "OMAP HDQ driver" > >> > + depends on ARCH_OMAP2430 || ARCH_OMAP34XX > >> > + help > >> > + Say Y here if you want support for the 1-wire or HDQ Interface > >> > + on an OMAP processor. > >> > + > >> > config W1_MASTER_GPIO > >> > tristate "GPIO 1-wire busmaster" > >> > depends on GENERIC_GPIO > >> > diff --git a/drivers/w1/masters/Makefile b/drivers/w1/masters/Makefile > >> > index 1420b5b..1daeb6e 100644 > >> > --- a/drivers/w1/masters/Makefile > >> > +++ b/drivers/w1/masters/Makefile > >> > @@ -6,4 +6,5 @@ obj-$(CONFIG_W1_MASTER_MATROX) += matrox_w1.o > >> > obj-$(CONFIG_W1_MASTER_DS2490) += ds2490.o > >> > obj-$(CONFIG_W1_MASTER_DS2482) += ds2482.o > >> > obj-$(CONFIG_W1_MASTER_DS1WM) += ds1wm.o > >> > +obj-$(CONFIG_HDQ_MASTER_OMAP) += omap_hdq.o > >> > obj-$(CONFIG_W1_MASTER_GPIO) += w1-gpio.o > >> > diff --git a/drivers/w1/masters/omap_hdq.c > >> > b/drivers/w1/masters/omap_hdq.c > >> > new file mode 100644 > >> > index 000..880e282 > >> > --- /dev/null > >> > +++ b/drivers/w1/masters/omap_hdq.c > >> > @@ -0,0 +1,704 @@ > >> > +/* > >> > + * drivers/w1/masters/omap_hdq.c > >> > + * > >> > + * Copyright (C) 2007 Texas Instruments, Inc. > >> > + * > >> > + * This file is licensed under the terms of the GNU General Public > >> > License > >> > + * version 2. This program is licensed "as is" without any warranty of > >> > any > >> > + * kind, whether express or implied. > >> > + * > >> > + */ > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > + > >> > +#include "../w1.h" > >> > +#include "../w1_int.h" > >> > + > >> > +#define MOD_NAME "OMAP_HDQ:" > >> > + > >> > +#define OMAP_HDQ_REVISION 0x00 > >> > +#define OMAP_HDQ_TX_DATA 0x04 > >> > +#define OMAP_HDQ_RX_DATA 0x08 > >> > +#define
[Resend][PATCH - Omapzoom][NAND] Add prefetch and DMA support
From: Vimal Singh <[EMAIL PROTECTED]>
Following patch taken over the omapzoom.org tree adds
prefetch and DMA support to the OMAP2/3 nand driver.
Signed-off-by: Vimal Singh <[EMAIL PROTECTED]>
Signed-off-by: Nishant Kamat <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/gpmc.c | 95 +++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 30
drivers/mtd/nand/omap2.c | 199 ++---
4 files changed, 310 insertions(+), 18 deletions(-)
Index: omapkernel/arch/arm/mach-omap2/gpmc.c
===
--- omapkernel.orig/arch/arm/mach-omap2/gpmc.c 2008-09-08 18:23:29.0
+0530
+++ omapkernel/arch/arm/mach-omap2/gpmc.c 2008-09-08 18:34:22.0
+0530
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH7
+#define DMA_MPU_MODE 2
+#endif
+
#ifdef CONFIG_OMAP3_PM
/*
* Structure to save/restore gpmc context
@@ -407,6 +413,92 @@
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/*
+ * gpmc_prefetch_init - configures default configuration for prefetch engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 << 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
+
+/*
+ * gpmc_prefetch_start - configures and starts prefetch transfer
+ * @cs - nand cs (chip select) number
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+void gpmc_prefetch_start(int cs, int dma_mode,
+ unsigned int u32_count, int is_write)
+{
+ uint32_t prefetch_config1;
+ if (is_write) {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the post write and enable the engine
+* Set which cs is using the post write
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= ((cs << CS_NUM_SHIFT) |
+ (dma_mode << DMA_MPU_MODE) |
+ (1 << ENABLE_PREFETCH) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ } else {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the prefech read and enable the engine
+* Set which cs is using the prefetch
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= (((cs << CS_NUM_SHIFT) |
+ (dma_mode << DMA_MPU_MODE) |
+ (1 << ENABLE_PREFETCH)) & ~0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ }
+ /* Start the prefetch engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_start);
+
+/*
+ * gpmc_prefetch_stop - disables and stops the prefetch engine
+ */
+void gpmc_prefetch_stop(void)
+{
+ uint32_t prefetch_config1;
+ /* stop the PFPW engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+
+ /* Disable the PFPW engine */
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 &= ~((0x07 << CS_NUM_SHIFT) |
+ (1 << ENABLE_PREFETCH) |
+ (1 << DMA_MPU_MODE) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_stop);
+
+/*
+ * gpmc_prefetch_status - reads prefetch status of engine
+ */
+int gpmc_prefetch_status(void)
+{
+ return gpmc_read_reg(GPMC_PREFETCH_STATUS);
+}
+EXPORT_SYMBOL(gpmc_prefetch_status);
+#else
+int gpmc_prefetch_status(void) {return 0; }
+void gpmc_prefetch_stop(void) {}
+void gpmc_prefetch_start(int cs, int dma_mode, unsigned int u32_count,
+ int is_write) {}
+#endif
+
static void __init gpmc_mem_init(void)
{
int cs;
@@ -462,6 +554,9 @@
gpmc_freq_cfg.freq_cfg = NULL;
gpmc_freq_cfg.total_no_of_freq = 0;
#endif
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+ gpmc_prefetch_init();
+#endif
gpmc_mem_init();
}
Index: omapkernel/arch/arm/plat-omap/include/mach/gpmc.h
===
--- omapkernel.orig/arch/arm/pla
[PATCH - Omapzoom] [NAND] Add prefetch and DMA support
From: Vimal Singh <[EMAIL PROTECTED]>
Following patch taken over the omapzoom.org tree adds
prefetch and DMA support to the OMAP2/3 nand driver.
Signed-off-by: Vimal Singh <[EMAIL PROTECTED]>
Signed-off-by: Nishant Kamat <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/gpmc.c | 95 +++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 30
drivers/mtd/nand/omap2.c | 199 ++---
4 files changed, 310 insertions(+), 18 deletions(-)
Index: omapkernel/arch/arm/mach-omap2/gpmc.c
===
--- omapkernel.orig/arch/arm/mach-omap2/gpmc.c 2008-09-08 18:23:29.0
+0530
+++ omapkernel/arch/arm/mach-omap2/gpmc.c 2008-09-08 18:34:22.0
+0530
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH7
+#define DMA_MPU_MODE 2
+#endif
+
#ifdef CONFIG_OMAP3_PM
/*
* Structure to save/restore gpmc context
@@ -407,6 +413,92 @@
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/*
+ * gpmc_prefetch_init - configures default configuration for prefetch engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 << 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
+
+/*
+ * gpmc_prefetch_start - configures and starts prefetch transfer
+ * @cs - nand cs (chip select) number
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+void gpmc_prefetch_start(int cs, int dma_mode,
+ unsigned int u32_count, int is_write)
+{
+ uint32_t prefetch_config1;
+ if (is_write) {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the post write and enable the engine
+* Set which cs is using the post write
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= ((cs << CS_NUM_SHIFT) |
+ (dma_mode << DMA_MPU_MODE) |
+ (1 << ENABLE_PREFETCH) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ } else {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the prefech read and enable the engine
+* Set which cs is using the prefetch
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= (((cs << CS_NUM_SHIFT) |
+ (dma_mode << DMA_MPU_MODE) |
+ (1 << ENABLE_PREFETCH)) & ~0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ }
+ /* Start the prefetch engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_start);
+
+/*
+ * gpmc_prefetch_stop - disables and stops the prefetch engine
+ */
+void gpmc_prefetch_stop(void)
+{
+ uint32_t prefetch_config1;
+ /* stop the PFPW engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+
+ /* Disable the PFPW engine */
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 &= ~((0x07 << CS_NUM_SHIFT) |
+ (1 << ENABLE_PREFETCH) |
+ (1 << DMA_MPU_MODE) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_stop);
+
+/*
+ * gpmc_prefetch_status - reads prefetch status of engine
+ */
+int gpmc_prefetch_status(void)
+{
+ return gpmc_read_reg(GPMC_PREFETCH_STATUS);
+}
+EXPORT_SYMBOL(gpmc_prefetch_status);
+#else
+int gpmc_prefetch_status(void) {return 0; }
+void gpmc_prefetch_stop(void) {}
+void gpmc_prefetch_start(int cs, int dma_mode, unsigned int u32_count,
+ int is_write) {}
+#endif
+
static void __init gpmc_mem_init(void)
{
int cs;
@@ -462,6 +554,9 @@
gpmc_freq_cfg.freq_cfg = NULL;
gpmc_freq_cfg.total_no_of_freq = 0;
#endif
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+ gpmc_prefetch_init();
+#endif
gpmc_mem_init();
}
Index: omapkernel/arch/arm/plat-omap/include/mach/gpmc.h
===
--- omapkernel.orig/arch/arm/plat-o
[PATCH] Fixed CPU type check for OMAP3
ES version definitions were incorrect, also GP/EMU/SEC etc. types were not
detected at all.
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/id.c |11 +--
arch/arm/plat-omap/include/mach/cpu.h |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a526c0f..290b88c 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -53,6 +53,13 @@ static struct omap_id omap_ids[] __initdata = {
{ .hawkeye = 0xb68a, .dev = 0x0, .type = 0x2430 },
};
+static const char omap3_revs[][4] = {
+ "1.0",
+ "2.0",
+ "2.1",
+ "3.0"
+};
+
static struct omap_chip_id omap_chip;
/**
@@ -224,7 +231,7 @@ void __init omap2_check_revision(void)
* Note that rev cannot be used directly as ES1.0 uses value 0.
*/
if (hawkeye == 0xb7ae) {
- system_rev = 0x3430 | ((1 + rev) << 12);
- pr_info("OMAP%04x ES2.%i\n", system_rev >> 16, rev);
+ _set_system_rev(0x3430 | (rev << 12), rev);
+ pr_info("OMAP%04x ES%s\n", system_rev >> 16, omap3_revs[rev]);
_set_omap_chip();
return;
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index e046418..e170d29 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -357,7 +357,7 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES1_0 0x3430
#define OMAP3430_REV_ES2_0 0x34301000
#define OMAP3430_REV_ES2_1 0x34302000
-#define OMAP3430_REV_ES2_2 0x34303000
+#define OMAP3430_REV_ES3_0 0x34303000
/*
* omap_chip bits
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed CPU type check for OMAP3
Oops, minor bug here, pr_info is still putting out wrong data, should be
from the array I added. Sending new patch soon.
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of ext Tero Kristo
>Sent: 08 September, 2008 19:34
>To: linux-omap@vger.kernel.org
>Subject: [PATCH] Fixed CPU type check for OMAP3
>
>ES version definitions were incorrect, also GP/EMU/SEC etc.
>types were not detected at all.
>
>Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>---
> arch/arm/mach-omap2/id.c |9 -
> arch/arm/plat-omap/include/mach/cpu.h |2 +-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/id.c
>b/arch/arm/mach-omap2/id.c index a526c0f..290b88c 100644
>--- a/arch/arm/mach-omap2/id.c
>+++ b/arch/arm/mach-omap2/id.c
>@@ -53,6 +53,13 @@ static struct omap_id omap_ids[] __initdata = {
> { .hawkeye = 0xb68a, .dev = 0x0, .type = 0x2430 }, };
>
>+static const char omap3_revs[][4] = {
>+ "1.0",
>+ "2.0",
>+ "2.1",
>+ "3.0"
>+};
>+
> static struct omap_chip_id omap_chip;
>
> /**
>@@ -224,7 +231,7 @@ void __init omap2_check_revision(void)
>* Note that rev cannot be used directly as ES1.0 uses value 0.
>*/
> if (hawkeye == 0xb7ae) {
>- system_rev = 0x3430 | ((1 + rev) << 12);
>+ _set_system_rev(0x3430 | (rev << 12), rev);
> pr_info("OMAP%04x ES2.%i\n", system_rev >> 16, rev);
> _set_omap_chip();
> return;
>diff --git a/arch/arm/plat-omap/include/mach/cpu.h
>b/arch/arm/plat-omap/include/mach/cpu.h
>index e046418..e170d29 100644
>--- a/arch/arm/plat-omap/include/mach/cpu.h
>+++ b/arch/arm/plat-omap/include/mach/cpu.h
>@@ -357,7 +357,7 @@ IS_OMAP_TYPE(3430, 0x3430)
> #define OMAP3430_REV_ES1_00x3430
> #define OMAP3430_REV_ES2_00x34301000
> #define OMAP3430_REV_ES2_10x34302000
>-#define OMAP3430_REV_ES2_20x34303000
>+#define OMAP3430_REV_ES3_00x34303000
>
> /*
> * omap_chip bits
>--
>1.5.4.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in the body of a message to
>[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixed CPU type check for OMAP3
ES version definitions were incorrect, also GP/EMU/SEC etc. types were not
detected at all.
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/id.c |9 -
arch/arm/plat-omap/include/mach/cpu.h |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a526c0f..290b88c 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -53,6 +53,13 @@ static struct omap_id omap_ids[] __initdata = {
{ .hawkeye = 0xb68a, .dev = 0x0, .type = 0x2430 },
};
+static const char omap3_revs[][4] = {
+ "1.0",
+ "2.0",
+ "2.1",
+ "3.0"
+};
+
static struct omap_chip_id omap_chip;
/**
@@ -224,7 +231,7 @@ void __init omap2_check_revision(void)
* Note that rev cannot be used directly as ES1.0 uses value 0.
*/
if (hawkeye == 0xb7ae) {
- system_rev = 0x3430 | ((1 + rev) << 12);
+ _set_system_rev(0x3430 | (rev << 12), rev);
pr_info("OMAP%04x ES2.%i\n", system_rev >> 16, rev);
_set_omap_chip();
return;
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index e046418..e170d29 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -357,7 +357,7 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES1_0 0x3430
#define OMAP3430_REV_ES2_0 0x34301000
#define OMAP3430_REV_ES2_1 0x34302000
-#define OMAP3430_REV_ES2_2 0x34303000
+#define OMAP3430_REV_ES3_0 0x34303000
/*
* omap_chip bits
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Use pmd_table() MACRO for unmap_area_sections()
Hi,
> > The usage in TI kernels has varied a bit. Some times they are just
> > load and lock TLB's, for others table walking can be enabled. In
> > all cases if a table walk miss happens it is fatal and the IP block
> > device will have to be reset.
>
> In *theory*, from this IOMMU hardware perspective, it's feasible to
> load something on memory dynamically("on-demand loading") when a table
> walk miss happens by notifying it to some memory manager through
> its assigned interrupt. Practically this latency may be a problem in
> some cases;)
I've been told explicitly by a few people that a table miss is fatal and the
block needs to be reset to recover state.
I've not personally dug into TRM and underlying functional specs to validate
this. It might be different per IP. Extreme case some kind of checkpoint
would work ;)
In some discussions some people have even taken in table walk time as a
consideration if certain camera streaming cases will work. So, your comment
about latency seems on.
Regards,
Richard W.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: powering up the mmc controller on 3430
On Mon, Sep 8, 2008 at 4:49 AM, Woodruff, Richard <[EMAIL PROTECTED]> wrote: > I believe the driver now calls this via its platform data in > arch/arm/mach-omap2/. Same sequence but now a bit more generalized from the > external driver point of view. Thank you, I will look into it Budhee > > Regards, > Richard W. > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
3430: can't find mmc debounce clock
Hello, I read that the mmc has 3 clocks: fixed functional clock (MMCi_FCLK), interface clock (MMCi_ICLK) and debounce clock (MMCi_32). But, when I look in clock34xx.h, I can only see two of those - there is the "mmchs_fck" and "mmchs_ick". There is no struct clk for the debounce clock. Only when I look in older kernels I can see also the "mmchsdb2_fck". So where is the debounce clock struct ? (I want to 'get' and 'enable' it...) Thank you in advance Budhee -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2EVM: Fix for omapfb irq error messages
On Sat, Sep 6, 2008 at 6:01 AM, arun c <[EMAIL PROTECTED]> wrote:
> This patch fixes the irq error warnings from omapfb which
> was stalling the console.
>
> Only the below 2 errors are coming now
>
> omapfb omapfb: irq error status 00e2
> omapfb omapfb: irq error status 00c0
>
> Signed-off-by: Arun C <[EMAIL PROTECTED]>
> ---
> drivers/video/omap/lcd_omap2evm.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/omap/lcd_omap2evm.c
> b/drivers/video/omap/lcd_omap2evm.c
> index 8a0105e..c58f2d0 100644
> --- a/drivers/video/omap/lcd_omap2evm.c
> +++ b/drivers/video/omap/lcd_omap2evm.c
> @@ -130,11 +130,11 @@ struct lcd_panel omap2evm_panel = {
>.x_res = LCD_XRES,
>.y_res = LCD_YRES,
>.hsw= 3,
> - .hfp= 0,
> + .hfp= 10,
>.hbp= 28,
>.vsw= 2,
> - .vfp= 1,
> - .vbp= 0,
> + .vfp= 3,
> + .vbp= 1,
>
>.pixel_clock= LCD_PIXCLOCK_MAX,
>
> --
> 1.5.3.4
>
Please ignore this patch as of now.
The problem is whenever I add support for new device the
error(omapfb irq errors) is coming again. There was no issues
until we added support for nand. After nand support error
messages began to appear and this patch solved it.
Today I added support for touch screen and the errors
came again. I had to adjust the above values(hbp, hfp, vbp, vfp)
again to resolve the issues.
I am thinking that I will send the final stable values after
adding full support for OMAP2EVM.
Do anybody know how to optimize (hsw, hfp, hbp, vsw, vbp,
vfp) values?
Regards,
Arun C
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 32/33] add omap 1-wire interface driver
- Original Message - From: "Tony Lindgren" <[EMAIL PROTECTED]> To: "Madhusudhan Chikkature" <[EMAIL PROTECTED]> Cc: "Felipe Balbi" <[EMAIL PROTECTED]>; ; "Felipe Balbi" <[EMAIL PROTECTED]> Sent: Friday, September 05, 2008 11:29 PM Subject: Re: [PATCH 32/33] add omap 1-wire interface driver >* Madhusudhan Chikkature <[EMAIL PROTECTED]> [080901 06:16]: >> Hi, >> >> The HDQ patchset that I posted to Tony were given ACK by Evgeniy Polyakov on >> the omap list. I hope that helps. > > Madhu, can you post your 1-wire driver to LKML and Cc Evgeniy Polyakov > so we can get that integrated? Also Cc l-o list. I have a question regarding this. In fact it can be a generic question which might apply for other drivers as well. How do we post the OMAP3 related driver patches to LKML or any other driver specific lists if OMAP3 base support is not already present there? Regards, Madhu > > Thanks, > > Tony > >> >> Regards, >> Madhu >> >> - Original Message - >> From: "Felipe Balbi" <[EMAIL PROTECTED]> >> To: >> Cc: "Felipe Balbi" <[EMAIL PROTECTED]> >> Sent: Saturday, August 30, 2008 10:46 PM >> Subject: [PATCH 32/33] add omap 1-wire interface driver >> >> >> > From: Felipe Balbi <[EMAIL PROTECTED]> >> > >> > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> >> > --- >> > arch/arm/plat-omap/include/mach/irqs.h |2 + >> > drivers/w1/masters/Kconfig |7 + >> > drivers/w1/masters/Makefile|1 + >> > drivers/w1/masters/omap_hdq.c | 704 >> > >> > 4 files changed, 714 insertions(+), 0 deletions(-) >> > create mode 100644 drivers/w1/masters/omap_hdq.c >> > >> > diff --git a/arch/arm/plat-omap/include/mach/irqs.h >> > b/arch/arm/plat-omap/include/mach/irqs.h >> > index 17248bb..c9e95a6 100644 >> > --- a/arch/arm/plat-omap/include/mach/irqs.h >> > +++ b/arch/arm/plat-omap/include/mach/irqs.h >> > @@ -54,6 +54,8 @@ >> > #define INT_TIMER2 30 >> > #define INT_LCD_CTRL 31 >> > >> > +#define INT_24XX_HDQ_IRQ 58 /* Temporarily here for driver to build */ >> > + >> > /* >> > * OMAP-1510 specific IRQ numbers for interrupt handler 1 >> > */ >> > diff --git a/drivers/w1/masters/Kconfig b/drivers/w1/masters/Kconfig >> > index c449309..636d4f7 100644 >> > --- a/drivers/w1/masters/Kconfig >> > +++ b/drivers/w1/masters/Kconfig >> > @@ -42,6 +42,13 @@ config W1_MASTER_DS1WM >> >in HP iPAQ devices like h5xxx, h2200, and ASIC3-based like >> >hx4700. >> > >> > +config HDQ_MASTER_OMAP >> > + tristate "OMAP HDQ driver" >> > + depends on ARCH_OMAP2430 || ARCH_OMAP34XX >> > + help >> > + Say Y here if you want support for the 1-wire or HDQ Interface >> > + on an OMAP processor. >> > + >> > config W1_MASTER_GPIO >> > tristate "GPIO 1-wire busmaster" >> > depends on GENERIC_GPIO >> > diff --git a/drivers/w1/masters/Makefile b/drivers/w1/masters/Makefile >> > index 1420b5b..1daeb6e 100644 >> > --- a/drivers/w1/masters/Makefile >> > +++ b/drivers/w1/masters/Makefile >> > @@ -6,4 +6,5 @@ obj-$(CONFIG_W1_MASTER_MATROX) += matrox_w1.o >> > obj-$(CONFIG_W1_MASTER_DS2490) += ds2490.o >> > obj-$(CONFIG_W1_MASTER_DS2482) += ds2482.o >> > obj-$(CONFIG_W1_MASTER_DS1WM) += ds1wm.o >> > +obj-$(CONFIG_HDQ_MASTER_OMAP) += omap_hdq.o >> > obj-$(CONFIG_W1_MASTER_GPIO) += w1-gpio.o >> > diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c >> > new file mode 100644 >> > index 000..880e282 >> > --- /dev/null >> > +++ b/drivers/w1/masters/omap_hdq.c >> > @@ -0,0 +1,704 @@ >> > +/* >> > + * drivers/w1/masters/omap_hdq.c >> > + * >> > + * Copyright (C) 2007 Texas Instruments, Inc. >> > + * >> > + * This file is licensed under the terms of the GNU General Public License >> > + * version 2. This program is licensed "as is" without any warranty of any >> > + * kind, whether express or implied. >> > + * >> > + */ >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > + >> > +#include "../w1.h" >> > +#include "../w1_int.h" >> > + >> > +#define MOD_NAME "OMAP_HDQ:" >> > + >> > +#define OMAP_HDQ_REVISION 0x00 >> > +#define OMAP_HDQ_TX_DATA 0x04 >> > +#define OMAP_HDQ_RX_DATA 0x08 >> > +#define OMAP_HDQ_CTRL_STATUS 0x0c >> > +#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK (1<<6) >> > +#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE (1<<5) >> > +#define OMAP_HDQ_CTRL_STATUS_GO (1<<4) >> > +#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION (1<<2) >> > +#define OMAP_HDQ_CTRL_STATUS_DIR (1<<1) >> > +#define OMAP_HDQ_CTRL_STATUS_MODE (1<<0) >> > +#define OMAP_HDQ_INT_STATUS 0x10 >> > +#define OMAP_HDQ_INT_STATUS_TXCOMPLETE (1<<2) >> > +#define OMAP_HDQ_INT_STATUS_RXCOMPLETE (1<<1) >> > +#define OMAP_HDQ_INT_STATUS_TIMEOUT (1<<0) >> > +#define OMAP_HDQ_SYSCONFIG 0x14 >> > +#define OMAP_HDQ_SYSCONFIG_SOFTRESET (1<<1) >> > +#define OMAP_HDQ_SYSCONFIG_AUTOIDLE (1<<0) >> > +#define OMAP_HDQ_SYSSTATUS 0x18 >> > +#define OMAP_HDQ_SYSSTATUS_RESETDONE (1<<0) >> > + >>
Re: [PATCH 1/4] ARM: OMAP: IOMMU driver: Core part
Hi Russell,
From: "ext Russell King - ARM Linux" <[EMAIL PROTECTED]>
Subject: Re: [PATCH 1/4] ARM: OMAP: IOMMU driver: Core part
Date: Mon, 8 Sep 2008 11:46:50 +0100
> On Mon, Sep 08, 2008 at 08:56:30AM +0300, Hiroshi DOYU wrote:
> > +/* MMU object handler */
> > +struct iommu {
> > + /* MMU */
> > + int type;
> > + char*name;
> > + struct clk *clk;
> > + void __iomem*regbase;
> > + unsigned long regsize;
> > + unsigned long flag;
> > + struct device *dev;
> > +
> > + /* TWL */
> > + struct mm_struct*twl_mm;
>
> mm_struct is a non-trivial size - why do you need it?
This is because I thought that "mm_struct" can manage VMAs as well as
pagetable. What I wanted to do is to do the same thing which linux VM
module does, then on-demand loading and others can be implemented here
too in the same manner, instead of introducing the home-brewed bitmap
management of IOMMU's virtual address area.
Anyway, I will consider if own struct can do the same thing again;)
> > + void (*isr)(struct iommu *obj);
> > +
> > + /* TLB */
> > + int nr_tlb_entries;
> > + int irq;
> > +};
> > +
> > +struct cr_regs {
> > + union {
> > + struct {
> > + u16 cam_l;
> > + u16 cam_h;
> > + };
> > + u32 cam;
> > + };
> > + union {
> > + struct {
> > + u16 ram_l;
> > + u16 ram_h;
> > + };
> > + u32 ram;
> > + };
>
> Making assumptions about the endianness - is OMAP guaranteed to always be
> little endian?
Not but this order doesn't matter actually. "*_l" and "*_h" is for
OMAP1 case just because its register access width is 16 bit wide.
> > +};
> > +
> > +/*
> > + *
> > + * TWL operations (H/W pagetable)
> > + *
> > + */
> > +static inline void twl_alloc_section(struct mm_struct *mm, unsigned long
> > va,
> > +unsigned long pa, int prot)
> > +{
> > + pmd_t *pmdp = pmd_offset(pgd_offset(mm, va), va);
> > + if (va & (1 << SECTION_SHIFT))
> > + pmdp++;
> > + *pmdp = __pmd((pa & SECTION_MASK) | prot | PMD_TYPE_SECT);
> > + flush_pmd_entry(pmdp);
>
> Using own accessor macros rather than the kernel's page table accessors
> would be better, and insulate you from changes made there. I'd also
> suggest replacing 'va' with something else (maybe 'da') to make it
> obvious that we're not talking about the host CPU's virtual address space.
Agreed. Thank you for your proposal code. It looks quite cool!.
> > +}
> > +
> > + return err;
> > +}
>
> So, this all becomes something like (untested):
Thanks, the following gets much cooler, expecially nice flushing
functions.
>
> #define IOPGD_SHIFT 20
> #define IOPTE_SHIFT 12
> #define IOPTE_SIZE(1 << (IOPGD_SHIFT - IOPTE_SHIFT))
> #define IOSECTION_MASK(~((1 << IOPGD_SHIFT) - 1))
> Freeing the page table, leaving a reference to it inside the page
> table structure. So when the page gets re-used, the IOMMU ends up
> trying to walk whatever new data is in that page. Not nice.
The above stored usecount concept is also cool to be efficient.
>
> u32 *iopgd = iopgd_offset(obj, va);
>
> if (!*iopgd)
> return;
>
> if ((u32)*iopgd & IOPGD_TABLE) {
> u32 *iopte = iopte_offset(iopgd, va);
> *iopte = 0;
> flush_iopte_range(iopte, iopte);
>
> iopte = iopte_offset(iopgd, 0);
> for (i = 0; i < IOPTE_SIZE; i++)
> if (iopte[i])
> return;
> iopte_free(iopte);
> }
> *iopgd = NULL;
> flush_iopgd_range(iopgd, iopgd);
>
> However, how often is a single entry cleared? Would it be better not to
> free the page table, but to have a function which walks the entire page
> table tree freeing all the tables?
It may be better, but honestly no idea for now. I will consider this
later.
> > +}
> > +
> > +void iotwl_pte_clear(struct iommu *obj, unsigned long va)
> > +{
> > + struct mm_struct *mm = obj->twl_mm;
> > +
> > + spin_lock(&mm->page_table_lock);
> > +
> > + twl_pte_clear(obj, va);
Thank you for your detail reviewing and some nice code. I will update
this patch and post them again with others.
Hiroshi DOYU
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/06] scratchpad populate
"ext Rajendra Nayak" <[EMAIL PROTECTED]> writes: > This patch populates the scratchpad contents > as expected by the bootROM code. Who should take care of restoring DPLL5 and IVA DPLL? CM_CLKEN_PLL_IVA2, CM_CLKSEL1_PLL_IVA2, CM_CLKEN2_PLL and CM_CLKSEL4_PLL seems to be on their reset values after OFF mode. Also some fields in CM_CLKEN_PLL are in their reset value (i.e. all the pwrdn bits). Should these be restored separately in prcm_restore_ctx? -- Jouni Högander -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP: IOMMU driver: Core part
On Mon, Sep 08, 2008 at 08:56:30AM +0300, Hiroshi DOYU wrote:
> +/* MMU object handler */
> +struct iommu {
> + /* MMU */
> + int type;
> + char*name;
> + struct clk *clk;
> + void __iomem*regbase;
> + unsigned long regsize;
> + unsigned long flag;
> + struct device *dev;
> +
> + /* TWL */
> + struct mm_struct*twl_mm;
mm_struct is a non-trivial size - why do you need it?
> + void (*isr)(struct iommu *obj);
> +
> + /* TLB */
> + int nr_tlb_entries;
> + int irq;
> +};
> +
> +struct cr_regs {
> + union {
> + struct {
> + u16 cam_l;
> + u16 cam_h;
> + };
> + u32 cam;
> + };
> + union {
> + struct {
> + u16 ram_l;
> + u16 ram_h;
> + };
> + u32 ram;
> + };
Making assumptions about the endianness - is OMAP guaranteed to always be
little endian?
> +};
> +
> +struct iotlb_lock {
> + int base;
> + int victim;
> +};
> +
> +struct iotlb_entry;
> +
> +/* Absorb the differences amang MMU versions */
> +struct iommu_functions {
> + /* MMU common */
> + int (*startup)(struct iommu *obj);
> + void (*shutdown)(struct iommu *obj);
> + int (*enable)(struct iommu *obj);
> + void (*disable)(struct iommu *obj);
> + void (*isr)(struct iommu *obj);
> +
> + /* TLB operations */
> + void (*tlb_cr_read)(struct iommu *obj, struct cr_regs *cr);
> + void (*tlb_cr_load)(struct iommu *obj, struct cr_regs *cr);
> +
> + /* CAM / RAM operations */
> + struct cr_regs *(*cr_alloc)(struct iommu *obj, struct iotlb_entry *e);
> + int (*cr_valid)(struct cr_regs *cr);
> + unsigned long (*cr_to_virt)(struct cr_regs *cr);
> +
> + /* PTE attribute operations */
> + pgprot_t (*pte_attr_get)(struct iotlb_entry *e);
> +
> + /* debug */
> + void (*regs_show)(struct iommu *obj);
> + ssize_t (*tlb_show)(struct iommu *obj, char *, struct iotlb_lock *lock);
> +};
> +
> +struct iommu_pdata {
> + const char *name;
> + int nr_tlb_entries;
> + struct clk *clk;
> + char*clk_name;
> + struct resource *res;
> + int n_res;
> +};
> +
> +/* Generic */
> +struct iommu *iommu_get(const char *name);
> +int iommu_put(struct iommu *obj);
> +int iommu_enable(struct iommu *obj);
> +void iommu_disable(struct iommu *obj);
> +int iommu_arch_init(struct iommu_functions *ops);
> +
> +/* TLB */
> +void iotlb_cr_read(struct iommu *obj, struct iotlb_lock *l, struct cr_regs
> *cr);
> +void iotlb_cr_load(struct iommu *obj, struct cr_regs *cr);
> +void iotlb_flush_all(struct iommu *obj);
> +int iotlb_entry_load(struct iommu *obj, struct iotlb_entry *e);
> +void iotlb_entry_flush(struct iommu *obj, unsigned long vadr);
> +
> +/* TWL */
> +int iotwl_pte_set(struct iommu *obj, struct iotlb_entry *e);
> +void iotwl_pte_clear(struct iommu *obj, unsigned long virt);
> +int iotwl_mm_alloc(struct iommu *obj);
> +void iotwl_mm_free(struct iommu *obj);
> +
> +/* VMA */
> +unsigned long ioget_unmapped_area(struct iommu *obj, unsigned long len);
> +dma_addr_t iomap_region(struct iommu *obj, struct iotlb_entry *e);
> +void iounmap_region(struct iommu *obj, unsigned long iova, size_t len);
> +
> +/* omap mmu version of cpu_set_pte_ext() */
> +void ioset_pte_ext(pte_t *ptep, pte_t pte, unsigned int ext);
> +
> +#include "iommu2.h" /* REVISIT */
> +
> +#endif /* __IOMMU_H */
> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> new file mode 100644
> index 000..1b25f65
> --- /dev/null
> +++ b/arch/arm/plat-omap/iommu.c
> @@ -0,0 +1,510 @@
> +/*
> + * OMAP peripheral device common IOMMU driver
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + * Written by Hiroshi DOYU <[EMAIL PROTECTED]>,
> + * Paul Mundt and Toshihiro Kobayashi
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +
> +static struct iommu_functions *arch_iommu;
> +static struct platform_driver iommu_driver;
> +
> +/*
> + * TLB helper functions
> + */
> +static inline void tlb_lock_get(struct iommu *obj, struct iotlb_lock *l)
> +{
> + unsigned long val;
> + val = iommu_read_reg(obj, MMU_LOCK);
> + l->base = MMU_LOCK_BASE(val);
> + l->victim = MMU_LOCK_VICTIM(val);
> +}
> +
> +static inline void tlb_lock_set(struct iommu *obj, struct iotlb_lock *l)
> +{
> + u32 val;
> + val = (l->base << MMU_LOCK_BASE_SHIFT) |
> + (l->victim << MMU_LOCK_VICTIM_SHIFT);
> + iommu_write_reg(obj, val, MMU_LOCK);
> +}
> +
> +static inline void tlb_entr
[RFC rev2] ARM: OMAP: Add support for OMAP2430 in McBSP
Signed-off-by: Jarkko Nikula <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/mcbsp.c | 73 ++
arch/arm/plat-omap/include/mach/mcbsp.h |3 +
2 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 7addc5a..afbe1e6 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -145,8 +145,8 @@ static struct omap_mcbsp_ops omap2_mcbsp_ops = {
.request= omap2_mcbsp_request,
};
-#ifdef CONFIG_ARCH_OMAP24XX
-static struct omap_mcbsp_platform_data omap24xx_mcbsp_pdata[] = {
+#ifdef CONFIG_ARCH_OMAP2420
+static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
{
.phys_base = OMAP24XX_MCBSP1_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP1_RX,
@@ -166,10 +166,58 @@ static struct omap_mcbsp_platform_data
omap24xx_mcbsp_pdata[] = {
.clk_name = "mcbsp_clk",
},
};
-#define OMAP24XX_MCBSP_PDATA_SZARRAY_SIZE(omap24xx_mcbsp_pdata)
+#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
#else
-#define omap24xx_mcbsp_pdata NULL
-#define OMAP24XX_MCBSP_PDATA_SZ0
+#define omap2420_mcbsp_pdata NULL
+#define OMAP2420_MCBSP_PDATA_SZ0
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2430
+static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
+ {
+ .phys_base = OMAP24XX_MCBSP1_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP1_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
+ .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
+ .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
+ .ops= &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .phys_base = OMAP24XX_MCBSP2_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
+ .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
+ .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
+ .ops= &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .phys_base = OMAP2430_MCBSP3_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
+ .ops= &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .phys_base = OMAP2430_MCBSP4_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP4_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP4_TX,
+ .ops= &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .phys_base = OMAP2430_MCBSP5_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP5_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP5_TX,
+ .ops= &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+};
+#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
+#else
+#define omap2430_mcbsp_pdata NULL
+#define OMAP2430_MCBSP_PDATA_SZ0
#endif
#ifdef CONFIG_ARCH_OMAP34XX
@@ -230,8 +278,10 @@ static int __init omap2_mcbsp_init(void)
clk_register(&omap_mcbsp_clks[i].clk);
}
- if (cpu_is_omap24xx())
- omap_mcbsp_count = OMAP24XX_MCBSP_PDATA_SZ;
+ if (cpu_is_omap2420())
+ omap_mcbsp_count = OMAP2420_MCBSP_PDATA_SZ;
+ if (cpu_is_omap2430())
+ omap_mcbsp_count = OMAP2430_MCBSP_PDATA_SZ;
if (cpu_is_omap34xx())
omap_mcbsp_count = OMAP34XX_MCBSP_PDATA_SZ;
@@ -240,9 +290,12 @@ static int __init omap2_mcbsp_init(void)
if (!mcbsp_ptr)
return -ENOMEM;
- if (cpu_is_omap24xx())
- omap_mcbsp_register_board_cfg(omap24xx_mcbsp_pdata,
- OMAP24XX_MCBSP_PDATA_SZ);
+ if (cpu_is_omap2420())
+ omap_mcbsp_register_board_cfg(omap2420_mcbsp_pdata,
+ OMAP2420_MCBSP_PDATA_SZ);
+ if (cpu_is_omap2430())
+ omap_mcbsp_register_board_cfg(omap2430_mcbsp_pdata,
+ OMAP2430_MCBSP_PDATA_SZ);
if (cpu_is_omap34xx())
omap_mcbsp_register_board_cfg(omap34xx_mcbsp_pdata,
OMAP34XX_MCBSP_PDATA_SZ);
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index f4e7980..6a0d1a0 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -43,6 +43,9 @@
#define OMAP24XX_MCBSP1_BASE 0x48074000
#define OMAP24XX_MCBSP2_BASE 0x4
[RFC 0/2 rev2] McBSP and ASoC OMAP update patches for 2430 and 34xx
Here is second version of patch adding support for 2430 in McBSP driver. Updated version uses phys_base instead of virt_base. See following commits from Russell King: ecec3b3e080464cc1b4e792cf4d8e7e89d50b011 2cfd6fcda3b8c6ee7a5fa9a4573e3246532a0716 Second patch is the same than first version. It's for testing ASoC OMAP and eventually it will go through the alsa-devel. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC rev2] ASoC: OMAP: Add support for OMAP2430 and OMAP34xx in McBSP DAI driver
Signed-off-by: Jarkko Nikula <[EMAIL PROTECTED]>
---
sound/soc/omap/omap-mcbsp.c | 95 ++
1 files changed, 77 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 35310e1..a217cf2 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -84,11 +84,22 @@ static const unsigned long omap1_mcbsp_port[][2] = {
static const int omap1_dma_reqs[][2] = {};
static const unsigned long omap1_mcbsp_port[][2] = {};
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
-static const int omap2420_dma_reqs[][2] = {
+
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+static const int omap24xx_dma_reqs[][2] = {
{ OMAP24XX_DMA_MCBSP1_TX, OMAP24XX_DMA_MCBSP1_RX },
{ OMAP24XX_DMA_MCBSP2_TX, OMAP24XX_DMA_MCBSP2_RX },
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
+ { OMAP24XX_DMA_MCBSP3_TX, OMAP24XX_DMA_MCBSP3_RX },
+ { OMAP24XX_DMA_MCBSP4_TX, OMAP24XX_DMA_MCBSP4_RX },
+ { OMAP24XX_DMA_MCBSP5_TX, OMAP24XX_DMA_MCBSP5_RX },
+#endif
};
+#else
+static const int omap2420_dma_reqs[][2] = {};
+#endif
+
+#if defined(CONFIG_ARCH_OMAP2420)
static const unsigned long omap2420_mcbsp_port[][2] = {
{ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
@@ -96,10 +107,43 @@ static const unsigned long omap2420_mcbsp_port[][2] = {
OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1 },
};
#else
-static const int omap2420_dma_reqs[][2] = {};
static const unsigned long omap2420_mcbsp_port[][2] = {};
#endif
+#if defined(CONFIG_ARCH_OMAP2430)
+static const unsigned long omap2430_mcbsp_port[][2] = {
+ { OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
+};
+#else
+static const unsigned long omap2430_mcbsp_port[][2] = {};
+#endif
+
+#if defined(CONFIG_ARCH_OMAP34XX)
+static const unsigned long omap34xx_mcbsp_port[][2] = {
+ { OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
+};
+#else
+static const unsigned long omap34xx_mcbsp_port[][2] = {};
+#endif
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
@@ -167,12 +211,15 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
dma = omap1_dma_reqs[bus_id][substream->stream];
port = omap1_mcbsp_port[bus_id][substream->stream];
} else if (cpu_is_omap2420()) {
- dma = omap2420_dma_reqs[bus_id][substream->stream];
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
port = omap2420_mcbsp_port[bus_id][substream->stream];
+ } else if (cpu_is_omap2430()) {
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
+ port = omap2430_mcbsp_port[bus_id][substream->stream];
+ } else if (cpu_is_omap343x()) {
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
+ port = omap34xx_mcbsp_port[bus_id][substream->stream];
} else {
- /*
-* TODO: Add support for 2430 and 3430
-*/
return -ENODEV;
}
omap_mcbsp_dai_dma_params[id][substream->stream].dma_req = dma;
@@ -310,7 +357,7 @@ static int omap_mcbsp_dai_set_clks_src(struct
omap_mcbsp_data *mcbsp_data,
int clk_id)
{
int sel_bit;
- u16 reg;
+ u16 reg, reg_devconf1 = OMAP243X_CONTROL_DEVCONF1;
if (cpu_class_is_omap1()) {
/* OMAP1's can use only external source clock */
@@ -320,6 +367,12 @@ static int omap_mcbsp_dai_set_clks_src(struct
omap_mcbsp_data *mcbsp_data,
return 0;
}
+ if (cpu_is_omap2420() && mcbsp_data->bus_id > 1)
+ return -EINVAL;
+
+ if (cpu_is_omap343x())
+ reg_devconf1 = OMAP343X_CONTROL_DEVCONF1;
+
switch (mcbsp_data->bus_id) {
case 0:
Re: [alsa-devel] [PATCH 3/5] ALSA: ASoC: Add support for TWL4030 audio codec (rev 3)
On Sat, Sep 06, 2008 at 11:41:42PM -0700, [EMAIL PROTECTED] wrote: > + > +config SND_SOC_TWL4030 > + tristate > + depends on SND_SOC && I2C > + Sorry, didn't notice earlier: this should depend on whatever the config option is for the TWL4030 core driver rather than on I2C since it doesn't actually interact with I2C directly. Although in most applications this won't make much odds since the machine driver will select the codec driver and select ignores the dependencies anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omapfb: setting GOLCD bit for shadow registers to make effect
A shadow register change has no direct effect on the display configuration until the GOLCD (DISPC_CONTROL[5]) is set. Signed-off-by: Arun C <[EMAIL PROTECTED]> --- drivers/video/omap/dispc.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c index 82ba030..2e7af85 100644 --- a/drivers/video/omap/dispc.c +++ b/drivers/video/omap/dispc.c @@ -436,6 +436,11 @@ static inline int _setup_plane(int plane, int channel_out, dispc_write_reg(ri_reg[plane], (screen_width - width) * bpp / 8 + 1); + /* Wait untill GOLCD bit is cleared and set it */ + while (dispc_read_reg(DISPC_CONTROL) & (1 << 5)) + continue; + MOD_REG_FLD(DISPC_CONTROL, 1 << 5, 1 << 5); + return height * screen_width * bpp / 8; } -- 1.5.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
