Re: [RFC][PATCH v2] OMAP: McBSP: Use register cache
Hi
On Tue, 24 Nov 2009 12:31:16 +0100
Janusz Krzysztofik wrote:
> -#define OMAP_MCBSP_READ(base, reg) \
> - omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
> -#define OMAP_MCBSP_WRITE(base, reg, val) \
> - omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
> +#define OMAP_MCBSP_READ(mcbsp, reg) \
> + omap_mcbsp_read(mcbsp->io_base, OMAP_MCBSP_REG_##reg)
> +#define OMAP_MCBSP_WRITE(mcbsp, reg, val) \
> + omap_mcbsp_write(mcbsp->io_base, OMAP_MCBSP_REG_##reg, val)
> +
> +#define OMAP_MCBSP_CREAD(mcbsp, reg) \
> + (mcbsp->reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1])
> +#define OMAP_MCBSP_CWRITE(mcbsp, reg, val) \
> + omap_mcbsp_write(mcbsp->io_base, OMAP_MCBSP_REG_##reg, \
> + mcbsp->reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
> + = val)
> +
Have rather single write writing both the cache and actual register.
I.e. keep the OMAP_MCBSP_WRITE since writes should always go to hw and
makes the patch smaller. I also found the OMAP_MCBSP_CREAD a little
unclear so I suggest to name is as OMAP_MCBSP_READ_CACHE.
> +#define OMAP_MCBSP_BREAD(mcbsp, reg) \
> + (mcbsp->reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
> + = OMAP_MCBSP_READ(mcbsp->io_base, reg))
>
Why is this? There is nothing eating this :-)
> dev_dbg(mcbsp->dev, "DRR2: 0x%04x\n",
> - OMAP_MCBSP_READ(mcbsp->io_base, DRR2));
> + OMAP_MCBSP_READ(mcbsp, DRR2));
These changes are worth to send as a separate cleanup patch. Will make
the actual cache patch smaller and easier to follow.
> @@ -93,15 +104,15 @@ static irqreturn_t omap_mcbsp_tx_irq_han
> struct omap_mcbsp *mcbsp_tx = dev_id;
> u16 irqst_spcr2;
>
> - irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx->io_base, SPCR2);
> + irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx, SPCR2);
> dev_dbg(mcbsp_tx->dev, "TX IRQ callback : 0x%x\n", irqst_spcr2);
>
> if (irqst_spcr2 & XSYNC_ERR) {
> dev_err(mcbsp_tx->dev, "TX Frame Sync Error! : 0x%x\n",
> irqst_spcr2);
> /* Writing zero to XSYNC_ERR clears the IRQ */
> - OMAP_MCBSP_WRITE(mcbsp_tx->io_base, SPCR2,
> - irqst_spcr2 & ~(XSYNC_ERR));
> + OMAP_MCBSP_CWRITE(mcbsp_tx, SPCR2,
> + OMAP_MCBSP_CREAD(mcbsp_tx, SPCR2) & ~(XSYNC_ERR));
I was thinking that should these read+read_cache changes be a separate
patch for fixing the 1510 issues since no other OMAPs are known to
corrupt registers and plain hw read is enough for them.
> @@ -612,7 +612,6 @@ EXPORT_SYMBOL(omap_mcbsp_stop);
> int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
> {
> struct omap_mcbsp *mcbsp;
> - void __iomem *base;
>
> if (!omap_mcbsp_check_valid_id(id)) {
> printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
> @@ -620,28 +619,27 @@ int omap_mcbsp_pollwrite(unsigned int id
> }
>
> mcbsp = id_to_mcbsp_ptr(id);
> - base = mcbsp->io_base;
>
> - writew(buf, base + OMAP_MCBSP_REG_DXR1);
> + OMAP_MCBSP_WRITE(mcbsp, DXR1, buf);
> /* if frame sync error - clear the error */
> - if (readw(base + OMAP_MCBSP_REG_SPCR2) & XSYNC_ERR) {
> + if (OMAP_MCBSP_READ(mcbsp, SPCR2) & XSYNC_ERR) {
These looks also that these are better to cover with its own separate
cleanup patch.
---
I'm not completely sure are there any code path expecting to read reset
default values from the cache or are there always explicit write or
read before it? I was thinking would it be necessary to initialize the
cache by issuing dummy reads for all registers. IRCC the OMAP2420 has
fewer registers than 2430 or OMAP3 so that should be took into account
if there is a need to do so.
--
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 2/9] DSPBRIDGE: trivial checkpatch fixes
Hi Omar, From: ext Nishanth Menon Subject: Re: [PATCH 2/9] DSPBRIDGE: trivial checkpatch fixes Date: Wed, 25 Nov 2009 22:37:24 +0100 > Ramirez Luna, Omar had written, on 11/23/2009 06:50 PM, the following: > > Quick fixes like: > General comment: please do white space changes as a separate patch. this > massive patch is pretty difficult to review otherwise.. might have been > as simple as doing scripts/Lindent on all files and refixing with > scripts/checkpatch.pl .. In addition to the above two scripts, - make C=1 for sparse - scripts/cleanpatch - scripts/cleanfile or - "whitespace-cleanup" in emacs Automatic checkings with the those scripts may be useful too. They could save most of trivial coding style discussions here. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Series short description
- Original Message -
From: "Tony Lindgren"
To:
Cc:
Sent: Thursday, November 26, 2009 5:48 AM
Subject: [PATCH 0/8] Series short description
Hi all,
Here are some omap mux updates for review. These
are intended for the v2.6.33 merge window.
Initially this series changes the omap34xx mux
code, I'm planning on adding 3630, 2420, and 2430
code later on.
There are several reasons why we need better mux
code:
- We want to make the mux code more generic and this
will allow us to use the internal signal names and
gpio numbers instead of mux register offsets. The
internal signal names stay the same across omap
generations for some devices.
- We need to map mux registers to GPIO registers for
dynamic muxing of the GPIO pins during off-idle.
- We want to be able to override the bootloader mux
values for the modded boards, such as the Beagle.
- We want to have the mux signals and balls available
under debugfs for debugging new drivers.
Does it also detect conflicts when two drivers try
to step on each other and overwrite the mux settings of
other. SPI and EHCI was one of the problems I faced.
Some of these might eventually work for other archs
too, so let me know if you have any comments on that.
Regards,
Tony
Here are some instructions on how to use:
To see what got muxed during init, edit the kernel
CMDLINE to have debug in it:
# dmesg | grep mux
mux: Setting signal i2c2_scl.i2c2_scl 0x0100 -> 0x0100
mux: Setting signal i2c2_sda.i2c2_sda 0x0100 -> 0x0100
mux: Setting signal i2c3_scl.i2c3_scl 0x0100 -> 0x0100
mux: Setting signal i2c3_sda.i2c3_sda 0x0100 -> 0x0100
mux: Setting signal gpmc_ncs3.gpio54 0x410c -> 0x010c
...
Looks like the gpmc_ncs3.gpio54 muxing in the kernel
has a bug where we should have OMAP_WAKEUP_EN set for
board_smc91x_init for board-rx51? :)
To override bootloader mux settings, edit the kernel CMDLINE:
omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
Note that this only changes the bootloader settings, not
what might be muxed from the board-*.c files.
With CONFIG_DEBUG_FS set:
# mount -t sysfs sys /sys
# mount -t debugfs debug /sys/kernel/debug
# ls /sys/kernel/debug/omap_mux/i2c
i2c2_scl i2c2_sda i2c3_scl i2c3_sda i2c4_scl i2c4_sda
# cat /sys/kernel/debug/omap_mux/i2c2_scl
name: i2c2_scl.i2c2_scl (0x480021be/0x18e = 0x0100), b af15, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: i2c2_scl | NA | NA | NA | gpio_168 | NA | NA | safe_mode
---
Mike Rapoport (1):
omap2: mux: intoduce omap_mux_{read,write}
Tony Lindgren (7):
omap: mux: Add new style pin multiplexing code for omap3
omap: mux: Add new style pin multiplexing data for 34xx
omap: mux: Add new style init functions to omap3 board-*.c files
omap: mux: Add debugfs support for new mux code
omap: Split i2c platform init for mach-omap1 and mach-omap2
omap: mux: Replace omap_cfg_reg() with new style signal or gpio
functions
omap: mux: Remove old mux code for 34xx
arch/arm/mach-omap2/Makefile |4
arch/arm/mach-omap2/board-3430sdp.c | 13
arch/arm/mach-omap2/board-3630sdp.c |3
arch/arm/mach-omap2/board-am3517evm.c| 11
arch/arm/mach-omap2/board-cm-t35.c | 13
arch/arm/mach-omap2/board-igep0020.c | 11
arch/arm/mach-omap2/board-ldp.c | 10
arch/arm/mach-omap2/board-omap3beagle.c | 21
arch/arm/mach-omap2/board-omap3evm.c | 21
arch/arm/mach-omap2/board-omap3pandora.c | 15
arch/arm/mach-omap2/board-overo.c| 14
arch/arm/mach-omap2/board-rx51-peripherals.c |7
arch/arm/mach-omap2/board-rx51.c | 16
arch/arm/mach-omap2/board-zoom2.c| 11
arch/arm/mach-omap2/devices.c| 62 +
arch/arm/mach-omap2/mux.c| 961 ++--
arch/arm/mach-omap2/mux.h| 150 +++
arch/arm/mach-omap2/mux34xx.c| 1558
++
arch/arm/mach-omap2/mux34xx.h| 351 ++
arch/arm/mach-omap2/usb-ehci.c | 122 +-
arch/arm/plat-omap/i2c.c | 24
arch/arm/plat-omap/include/plat/common.h |1
arch/arm/plat-omap/include/plat/mux.h| 222
arch/arm/plat-omap/mux.c |8
24 files changed, 2932 insertions(+), 697 deletions(-)
create mode 100644 arch/arm/mach-omap2/mux.h
create mode 100644 arch/arm/mach-omap2/mux34xx.c
create mode 100644 arch/arm/mach-omap2/mux34xx.h
--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] musb: Add context save and restore support
Adding support for MUSB register save and restore during system
suspend and resume.
Changes:
- Added musb_save/restore_context() functions
- Added platform specific musb_platform_save/restore_context()
to handle platform specific jobs.
- Maintaining BlackFin compatibility by adding read/write
functions for registers which are not available in BlackFin
Tested system suspend and resume on OMAP3EVM board.
Signed-off-by: Anand Gadiyar
Signed-off-by: Ajay Kumar Gupta
---
Changes from previous version:
- Cleanups as Felipe suggested
- Removed save/restore of interrupt status registers
intr[r/t]x and intrusb
drivers/usb/musb/musb_core.c | 148 +-
drivers/usb/musb/musb_core.h | 39 +++
drivers/usb/musb/musb_regs.h | 90 +
drivers/usb/musb/omap2430.c | 16 +
4 files changed, 291 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3a61ddb..0fd4105 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2167,21 +2167,163 @@ static int __devexit musb_remove(struct
platform_device *pdev)
#ifdef CONFIG_PM
+static struct musb_context_registers musb_context;
+
+void musb_save_context(void __iomem *musb_base)
+{
+ int i;
+
+ musb_context.faddr = musb_readb(musb_base, MUSB_FADDR);
+ musb_context.power = musb_readb(musb_base, MUSB_POWER);
+ musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE);
+ musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE);
+ musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE);
+ musb_context.frame = musb_readw(musb_base, MUSB_FRAME);
+ musb_context.index = musb_readb(musb_base, MUSB_INDEX);
+ musb_context.testmode = musb_readb(musb_base, MUSB_TESTMODE);
+ musb_context.devctl = musb_readb(musb_base, MUSB_DEVCTL);
+
+ for (i = 0; i < MUSB_C_NUM_EPS; ++i) {
+ musb_writeb(musb_base, MUSB_INDEX, i);
+ musb_context.index_regs[i].txmaxp =
+ musb_readw(musb_base, 0x10 + MUSB_TXMAXP);
+ musb_context.index_regs[i].txcsr =
+ musb_readw(musb_base, 0x10 + MUSB_TXCSR);
+ musb_context.index_regs[i].rxmaxp =
+ musb_readw(musb_base, 0x10 + MUSB_RXMAXP);
+ musb_context.index_regs[i].rxcsr =
+ musb_readw(musb_base, 0x10 + MUSB_RXCSR);
+ musb_context.index_regs[i].rxcount =
+ musb_readw(musb_base, 0x10 + MUSB_RXCOUNT);
+ musb_context.index_regs[i].txtype =
+ musb_readb(musb_base, 0x10 + MUSB_TXTYPE);
+ musb_context.index_regs[i].txinterval =
+ musb_readb(musb_base, 0x10 + MUSB_TXINTERVAL);
+ musb_context.index_regs[i].rxtype =
+ musb_readb(musb_base, 0x10 + MUSB_RXTYPE);
+ musb_context.index_regs[i].rxinterval =
+ musb_readb(musb_base, 0x10 + MUSB_RXINTERVAL);
+
+ musb_context.index_regs[i].txfifoadd =
+ musb_read_txfifoadd(musb_base);
+ musb_context.index_regs[i].rxfifoadd =
+ musb_read_rxfifoadd(musb_base);
+ musb_context.index_regs[i].txfifosz =
+ musb_read_txfifosz(musb_base);
+ musb_context.index_regs[i].rxfifosz =
+ musb_read_rxfifosz(musb_base);
+
+ musb_context.index_regs[i].txfunaddr =
+ musb_read_txfunaddr(musb_base, i);
+ musb_context.index_regs[i].txhubaddr =
+ musb_read_txhubaddr(musb_base, i);
+ musb_context.index_regs[i].txhubport =
+ musb_read_txhubport(musb_base, i);
+
+ musb_context.index_regs[i].rxfunaddr =
+ musb_read_rxfunaddr(musb_base, i);
+ musb_context.index_regs[i].rxhubaddr =
+ musb_read_rxhubaddr(musb_base, i);
+ musb_context.index_regs[i].rxhubport =
+ musb_read_rxhubport(musb_base, i);
+ }
+
+ musb_writeb(musb_base, MUSB_INDEX, musb_context.index);
+
+ musb_platform_save_context(&musb_context);
+}
+
+void musb_restore_context(void __iomem *musb_base)
+{
+ int i;
+ void __iomem *ep_target_regs;
+
+ musb_platform_restore_context(&musb_context);
+
+ musb_writeb(musb_base, MUSB_FADDR, musb_context.faddr);
+ musb_writeb(musb_base, MUSB_POWER, musb_context.power);
+ musb_writew(musb_base, MUSB_INTRTXE, musb_context.intrtxe);
+ musb_writew(musb_base, MUSB_INTRRXE, musb_context.intrrxe);
+ musb_writeb(musb_base, MUSB_INTRUSBE, musb_context.intrusbe);
+ musb_writew(musb_base, MUSB_F
Re: [PATCH 5/9] DSPBRIDGE: trivial cleanup and indentation for io_sm
On Wed, 2009-11-25 at 21:15 +0200, Felipe Balbi wrote:
> On Tue, Nov 24, 2009 at 01:50:26AM +0100, ext Omar Ramirez Luna wrote:
> >Remove duplicate set of braces from if statement and reduce
> >indentation.
> >
> >Signed-off-by: Omar Ramirez Luna
> >---
> > drivers/dsp/bridge/wmd/io_sm.c | 96
> > +---
> > 1 files changed, 40 insertions(+), 56 deletions(-)
> >
> >diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
> >index af31831..96a5aa6 100644
> >--- a/drivers/dsp/bridge/wmd/io_sm.c
> >+++ b/drivers/dsp/bridge/wmd/io_sm.c
> >@@ -115,7 +115,7 @@ struct IO_MGR {
> > /* private extnd proc info; mmu setup */
> > struct MGR_PROCESSOREXTINFO extProcInfo;
> > struct CMM_OBJECT *hCmmMgr; /* Shared Mem Mngr*/
> >- struct work_struct io_workq; /*workqueue */
> >+struct work_struct io_workq; /*workqueue */
>
> while at that: /* workqueue */
>
> add the missing space.
>
> > u32 dQuePowerMbxVal[MAX_PM_REQS];
> > u32 iQuePowerHead;
> > u32 iQuePowerTail;
> >@@ -185,7 +185,7 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
> > struct CFG_HOSTRES hostRes;
> > struct CFG_DEVNODE *hDevNode;
> > struct CHNL_MGR *hChnlMgr;
> >- static int ref_count;
> >+static int ref_count;
> > u32 devType;
> > /* Check requirements: */
> > if (!phIOMgr || !pMgrAttrs || pMgrAttrs->uWordSize == 0) {
> >@@ -197,9 +197,10 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
> > status = DSP_EHANDLE;
> > goto func_end;
> > }
> >- /* Message manager will be created when a file is loaded, since
> >+/* Message manager will be created when a file is loaded, since
> > * size of message buffer in shared memory is configurable in
> >- * the base image. */
> >+ * the base image.
> >+ */
>
> same here... it should be:
>
> /* multi-line comment start here and has only one
> * space after the * character.
> * If you could remove the extra space above would
> * be nice.
> */
Then strictly speaking it should be
/*
* Mulit-line comment start here.
*/
Grep for "The preferred style for long (multi-line) comments is" in
Documentation/CodingStyle.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2] AM3517: Add support for TSC2004 driver
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Thursday, November 26, 2009 10:41 AM
> To: linux-omap@vger.kernel.org
> Cc: t...@atomide.com; Hiremath, Vaibhav
> Subject: [PATCH V2] AM3517: Add support for TSC2004 driver
>
> From: Vaibhav Hiremath
>
> Changes:
> - Removed omap_cfg_reg()
>
> Reviewed-by: Tony Lindgren
> Signed-off-by: Vaibhav Hiremath
> ---
> arch/arm/mach-omap2/board-am3517evm.c | 61
> +
> 1 files changed, 61 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
> omap2/board-am3517evm.c
> index 415a13d..b183d93 100644
> --- a/arch/arm/mach-omap2/board-am3517evm.c
> +++ b/arch/arm/mach-omap2/board-am3517evm.c
> @@ -20,6 +20,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -27,10 +29,64 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> /*
> + * TSC 2004 Support
> + */
> +#define GPIO_TSC2004_IRQ65
> +
> +static int tsc2004_init_irq(void)
> +{
> + int ret = 0;
> +
> + ret = gpio_request(GPIO_TSC2004_IRQ, "tsc2004-irq");
> + if (ret < 0) {
> + printk(KERN_WARNING "failed to request GPIO#%d: %d\n",
> + GPIO_TSC2004_IRQ, ret);
> + return ret;
> + }
> +
> + if (gpio_direction_input(GPIO_TSC2004_IRQ)) {
> + printk(KERN_WARNING "GPIO#%d cannot be configured as "
> + "input\n", GPIO_TSC2004_IRQ);
> + return -ENXIO;
> + }
> +
> + omap_set_gpio_debounce(GPIO_TSC2004_IRQ, 1);
> + omap_set_gpio_debounce_time(GPIO_TSC2004_IRQ, 0xa);
> + return ret;
> +}
> +
> +static void tsc2004_exit_irq(void)
> +{
> + gpio_free(GPIO_TSC2004_IRQ);
> +}
> +
> +static int tsc2004_get_irq_level(void)
> +{
> + return gpio_get_value(GPIO_TSC2004_IRQ) ? 0 : 1;
> +}
> +
> +struct tsc2004_platform_data am3517evm_tsc2004data = {
> + .model = 2004,
> + .x_plate_ohms = 180,
> + .get_pendown_state = tsc2004_get_irq_level,
> + .init_platform_hw = tsc2004_init_irq,
> + .exit_platform_hw = tsc2004_exit_irq,
> +};
> +
> +static struct i2c_board_info __initdata
> am3517evm_tsc_i2c_boardinfo[] = {
> + {
> + I2C_BOARD_INFO("tsc2004", 0x4B),
> + .type = "tsc2004",
> + .platform_data = &am3517evm_tsc2004data,
> + },
> +};
> +
> +/*
> * Board initialization
> */
> static struct omap_board_config_kernel am3517_evm_config[]
> __initdata = {
> @@ -67,6 +123,11 @@ static void __init am3517_evm_init(void)
>
> omap_serial_init();
> usb_ehci_init(&ehci_pdata);
> +
> + /* TSC 2004 */
> + am3517evm_tsc_i2c_boardinfo[0].irq =
> gpio_to_irq(GPIO_TSC2004_IRQ);
> + i2c_register_board_info(1, am3517evm_tsc_i2c_boardinfo,
> + ARRAY_SIZE(am3517evm_tsc_i2c_boardinfo));
> }
>
> static void __init am3517_evm_map_io(void)
[Hiremath, Vaibhav] Hi Tony,
Since I haven't received any comments on driver code it should get merged. But
I am not sure what the procedure is for input subsystem drivers? Is it happens
through linux-omap or linux-input?
Thanks,
Vaibhav
> --
> 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 V2] AM3517: Add support for TSC2004 driver
From: Vaibhav Hiremath
Changes:
- Removed omap_cfg_reg()
Reviewed-by: Tony Lindgren
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-am3517evm.c | 61 +
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 415a13d..b183d93 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -27,10 +29,64 @@
#include
#include
+#include
#include
#include
/*
+ * TSC 2004 Support
+ */
+#defineGPIO_TSC2004_IRQ65
+
+static int tsc2004_init_irq(void)
+{
+ int ret = 0;
+
+ ret = gpio_request(GPIO_TSC2004_IRQ, "tsc2004-irq");
+ if (ret < 0) {
+ printk(KERN_WARNING "failed to request GPIO#%d: %d\n",
+ GPIO_TSC2004_IRQ, ret);
+ return ret;
+ }
+
+ if (gpio_direction_input(GPIO_TSC2004_IRQ)) {
+ printk(KERN_WARNING "GPIO#%d cannot be configured as "
+ "input\n", GPIO_TSC2004_IRQ);
+ return -ENXIO;
+ }
+
+ omap_set_gpio_debounce(GPIO_TSC2004_IRQ, 1);
+ omap_set_gpio_debounce_time(GPIO_TSC2004_IRQ, 0xa);
+ return ret;
+}
+
+static void tsc2004_exit_irq(void)
+{
+ gpio_free(GPIO_TSC2004_IRQ);
+}
+
+static int tsc2004_get_irq_level(void)
+{
+ return gpio_get_value(GPIO_TSC2004_IRQ) ? 0 : 1;
+}
+
+struct tsc2004_platform_data am3517evm_tsc2004data = {
+ .model = 2004,
+ .x_plate_ohms = 180,
+ .get_pendown_state = tsc2004_get_irq_level,
+ .init_platform_hw = tsc2004_init_irq,
+ .exit_platform_hw = tsc2004_exit_irq,
+};
+
+static struct i2c_board_info __initdata am3517evm_tsc_i2c_boardinfo[] = {
+ {
+ I2C_BOARD_INFO("tsc2004", 0x4B),
+ .type = "tsc2004",
+ .platform_data = &am3517evm_tsc2004data,
+ },
+};
+
+/*
* Board initialization
*/
static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
@@ -67,6 +123,11 @@ static void __init am3517_evm_init(void)
omap_serial_init();
usb_ehci_init(&ehci_pdata);
+
+ /* TSC 2004 */
+ am3517evm_tsc_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_TSC2004_IRQ);
+ i2c_register_board_info(1, am3517evm_tsc_i2c_boardinfo,
+ ARRAY_SIZE(am3517evm_tsc_i2c_boardinfo));
}
static void __init am3517_evm_map_io(void)
--
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
[PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype
From: Richard Woodruff
DPLL4 for 3630 introduces a changed block requiring special divisor bits and
additional reg fields. To allow for silicons to use this, this is introduced
as a omap3_has_jtype_dpll4() and is enabled for 3630 silicon
Tested with 3630 ZOOM3
Cc: Paul Walmsley
Signed-off-by: Richard Woodruff
Signed-off-by: Nishanth Menon
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/clock34xx.c | 51 ++-
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/id.c|4 ++-
arch/arm/plat-omap/include/plat/clock.h |3 ++
arch/arm/plat-omap/include/plat/cpu.h |3 +-
5 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index da5bc1f..832ed0b 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -679,6 +679,41 @@ static void omap3_noncore_dpll_disable(struct clk *clk)
_omap3_noncore_dpll_stop(clk);
}
+/**
+ * lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16
+ m, u8 n)
+ {
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ clkinp = clk->parent->rate;
+ fint = (clkinp / n) * m;
+
+ if (fint < 10)
+ *dco = 2;
+ else
+ *dco = 4;
+ /*
+* target sigma-delta to near 250MHz
+* sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)]
+*/
+ clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/
+ mod1 = (clkinp * m) % (250 * n);
+ sd = (clkinp * m) / (250 * n);
+ mod2 = sd % 10;
+ sd /= 10;
+
+ if (mod1 + mod2)
+ sd++;
+ *sd_div = sd;
+}
/* Non-CORE DPLL rate set code */
@@ -711,6 +746,13 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16
m, u8 n, u16 freqsel)
v &= ~(dd->mult_mask | dd->div1_mask);
v |= m << __ffs(dd->mult_mask);
v |= (n - 1) << __ffs(dd->div1_mask);
+ if (dd->jtype) {
+ u8 dco, sd_div;
+ lookup_dco_sddiv(clk, &dco, &sd_div, m, n);
+ v &= ~(dd->dco_sel_mask | dd->sd_div_mask);
+ v |= dco << __ffs(dd->dco_sel_mask);
+ v |= sd_div << __ffs(dd->sd_div_mask);
+ }
__raw_writel(v, dd->mult_div1_reg);
/* We let the clock framework set the other output dividers later */
@@ -1026,7 +1068,7 @@ static unsigned long omap3_clkoutx2_recalc(struct clk
*clk)
v = __raw_readl(dd->control_reg) & dd->enable_mask;
v >>= __ffs(dd->enable_mask);
- if (v != OMAP3XXX_EN_DPLL_LOCKED)
+ if (v != OMAP3XXX_EN_DPLL_LOCKED && (!dd->jtype))
rate = clk->parent->rate;
else
rate = clk->parent->rate * 2;
@@ -1174,6 +1216,13 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+ if (omap3_has_jtype_dpll4()) {
+ dpll4_ck.dpll_data->jtype = 1;
+ dpll4_ck.dpll_data->dco_sel_mask =
+ OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
+ dpll4_ck.dpll_data->sd_div_mask =
+ OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
+ }
}
clk_init(&omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff << 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff << 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK (0x7f << 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK (0x7 << 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT 24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff << 24)
/* CM_CLKSEL3_PLL */
#define OMAP3430_DIV_96M_SHIFT 0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..3c1194c 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -176,6 +176,8 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP
[PATCHV3 4/4] OMAP3: add support for 192Mhz sgx clock
SGX can run at 192MHz on 3630 and this patch has changes to support this
feature. Basically DPLL4 M2 will be 192Mhz which will be used as SGX
Clock. 192Mhz clock is divided by 2 (using CM_CLKSEL_CORE) to generate
96Mhz clock
Cc: Paul Walmsley
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/clock34xx.c | 13 +
arch/arm/mach-omap2/clock34xx.h | 33 +
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
arch/arm/mach-omap2/id.c |4
arch/arm/plat-omap/include/plat/cpu.h |2 ++
5 files changed, 54 insertions(+), 0 deletions(-)
mode change 100644 => 100755 arch/arm/mach-omap2/id.c
mode change 100644 => 100755 arch/arm/plat-omap/include/plat/cpu.h
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index f7bc74c..99344e6 100755
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "emu_core_alwon_ck", &emu_core_alwon_ck, CK_3XXX),
CLK(NULL, "dpll4_ck", &dpll4_ck, CK_3XXX),
CLK(NULL, "dpll4_x2_ck", &dpll4_x2_ck, CK_3XXX),
+ CLK(NULL, "omap_192m_alwon_ck", &omap_192m_alwon_ck, CK_363X),
CLK(NULL, "omap_96m_alwon_fck", &omap_96m_alwon_fck, CK_3XXX),
CLK(NULL, "omap_96m_fck", &omap_96m_fck, CK_3XXX),
CLK(NULL, "cm_96m_fck", &cm_96m_fck,CK_3XXX),
@@ -1227,6 +1228,18 @@ int __init omap2_clk_init(void)
dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
cpu_mask |= RATE_IN_363X;
}
+
+ if (omap3_has_192mhz_clk()) {
+ omap_96m_alwon_fck.parent = &omap_192m_alwon_ck;
+ omap_96m_alwon_fck.init = &omap2_init_clksel_parent;
+ omap_96m_alwon_fck.clksel_reg =
+ OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
+ omap_96m_alwon_fck.clksel_mask =
+ OMAP3630_CLKSEL_96M_MASK;
+ omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel;
+ omap_96m_alwon_fck.recalc = &omap2_clksel_recalc;
+ }
+
if (cpu_is_omap3630())
cpu_clkflg |= CK_363X;
}
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 93c92e5..6fe89df 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = {
.recalc = &omap3_clkoutx2_recalc,
};
+/* Adding 192MHz Clock node needed by SGX */
+static struct clk omap_192m_alwon_ck = {
+ .name = "omap_192m_alwon_ck",
+ .ops= &clkops_null,
+ .parent = &dpll4_m2x2_ck,
+ .recalc = &followparent_recalc,
+};
+
/*
* DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as
* PRM_96M_ALWON_(F)CLK. Two clocks then emerge from the PRM:
* 96M_ALWON_FCLK (called "omap_96m_alwon_fck" below) and
* CM_96K_(F)CLK.
*/
+static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_363X },
+ { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 0 }
+};
+
+static const struct clksel omap_96m_alwon_fck_clksel[] = {
+ { .parent = &omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates },
+ { .parent = NULL }
+};
+
static struct clk omap_96m_alwon_fck = {
.name = "omap_96m_alwon_fck",
.ops= &clkops_null,
@@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = {
{ .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE },
{ .div = 4, .val = 1, .flags = RATE_IN_3XXX },
{ .div = 6, .val = 2, .flags = RATE_IN_3XXX },
+ { .div = 2, .val = 5, .flags = RATE_IN_363X },
+ { .div = 0 },
+};
+
+static const struct clksel_rate sgx_192m_rates[] = {
+ { .div = 1, .val = 4, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 0 },
+};
+
+static const struct clksel_rate sgx_corex2_rates[] = {
+ { .div = 3, .val = 6, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 5, .val = 7, .flags = RATE_IN_363X },
{ .div = 0 },
};
@@ -1234,6 +1265,8 @@ static const struct clksel_rate sgx_96m_rates[] = {
static const struct clksel sgx_clksel[] = {
{ .parent = &core_ck,.rates = sgx_core_rates },
{ .parent = &cm_96m_fck, .rates = sgx_96m_rates },
+ { .parent = &omap_192m_alwon_ck, .rates = sgx_192m_rates },
+ { .parent = &corex2_fck, .rates = sgx_corex2_rates },
{ .parent = NULL },
};
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index a6383f9..39b3399 100644
--- a/arch/arm/
[PATCHV3 2/4] OMAP3: Clock Type change for OMAP3 Clocks
In omap34xx_clks, CK_343X type is used by all OMAP3 family of
processors. It makes more sense to name clock type as CK_3XXX since it
is common to all OMAP3 processors.
Cc: Paul Walmsley
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/clock.h | 15 +-
arch/arm/mach-omap2/clock34xx.c | 370 +++---
arch/arm/mach-omap2/clock34xx.h | 158 +++---
arch/arm/plat-omap/include/plat/clock.h |2 +-
4 files changed, 274 insertions(+), 271 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 43b6bed..8ceefcc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -79,20 +79,23 @@ extern u8 cpu_mask;
/* clksel_rate data common to 24xx/343x */
static const struct clksel_rate gpt_32k_rates[] = {
-{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
+{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
{ .div = 0 }
};
static const struct clksel_rate gpt_sys_rates[] = {
-{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
+{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
{ .div = 0 }
};
static const struct clksel_rate gfx_l3_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X },
- { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
- { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_343X },
- { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_343X },
+ { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX },
+ { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
+ { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_3XXX },
+ { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_3XXX },
{ .div = 0 }
};
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 832ed0b..167f075 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -94,69 +94,69 @@ struct omap_clk {
}, \
}
-#define CK_343X(1 << 0)
+#define CK_3XXX(1 << 0)
#define CK_3430ES1 (1 << 1)
#define CK_3430ES2 (1 << 2)
static struct omap_clk omap34xx_clks[] = {
- CLK(NULL, "omap_32k_fck", &omap_32k_fck, CK_343X),
- CLK(NULL, "virt_12m_ck", &virt_12m_ck, CK_343X),
- CLK(NULL, "virt_13m_ck", &virt_13m_ck, CK_343X),
+ CLK(NULL, "omap_32k_fck", &omap_32k_fck, CK_3XXX),
+ CLK(NULL, "virt_12m_ck", &virt_12m_ck, CK_3XXX),
+ CLK(NULL, "virt_13m_ck", &virt_13m_ck, CK_3XXX),
CLK(NULL, "virt_16_8m_ck", &virt_16_8m_ck, CK_3430ES2),
- CLK(NULL, "virt_19_2m_ck", &virt_19_2m_ck, CK_343X),
- CLK(NULL, "virt_26m_ck", &virt_26m_ck, CK_343X),
- CLK(NULL, "virt_38_4m_ck", &virt_38_4m_ck, CK_343X),
- CLK(NULL, "osc_sys_ck", &osc_sys_ck,CK_343X),
- CLK(NULL, "sys_ck", &sys_ck,CK_343X),
- CLK(NULL, "sys_altclk", &sys_altclk,CK_343X),
- CLK(NULL, "mcbsp_clks", &mcbsp_clks,CK_343X),
- CLK(NULL, "sys_clkout1", &sys_clkout1, CK_343X),
- CLK(NULL, "dpll1_ck", &dpll1_ck, CK_343X),
- CLK(NULL, "dpll1_x2_ck", &dpll1_x2_ck, CK_343X),
- CLK(NULL, "dpll1_x2m2_ck", &dpll1_x2m2_ck, CK_343X),
- CLK(NULL, "dpll2_ck", &dpll2_ck, CK_343X),
- CLK(NULL, "dpll2_m2_ck", &dpll2_m2_ck, CK_343X),
- CLK(NULL, "dpll3_ck", &dpll3_ck, CK_343X),
- CLK(NULL, "core_ck", &core_ck, CK_343X),
- CLK(NULL, "dpll3_x2_ck", &dpll3_x2_ck, CK_343X),
- CLK(NULL, "dpll3_m2_ck", &dpll3_m2_ck, CK_343X),
- CLK(NULL, "dpll3_m2x2_ck", &dpll3_m2x2_ck, CK_343X),
- CLK(NULL, "dpll3_m3_ck", &dpll3_m3_ck, CK_343X),
- CLK(NULL, "dpll3_m3x2_ck", &dpll3_m3x2_ck, CK_343X),
- CLK(NULL, "emu_core_alwon_ck", &emu_core_alwon_ck, CK_343X),
- CLK(NULL, "dpll4_ck", &dpll4_ck, CK_343X),
- CLK(NULL, "dpll4_x2_ck", &dpll4_x2_ck, CK_343X),
- CLK(NULL, "omap_96m_alwon_fck", &omap_96m_alwon_fck, CK_343X),
- CLK(NULL, "omap_96m_fck", &omap_96m_fck, CK_343X),
- CLK(NULL, "cm_96m_fck", &cm_96m_fck,CK_343X),
- CLK(NULL, "omap_54m_fck", &omap_54m_fck, CK_343X),
- CLK(NULL, "omap_48m_fck", &omap_48m_fck, CK_343X),
- CLK(NULL, "omap_12m_fck", &omap_12m_fck, CK_343X),
[PATCHV3 3/4] OMAP3: Correct width for CLKSEL Fields
DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in
3630.This patch has changes to accommodate this in CM dynamically based
on chip version. Primary changes are
1. Added clksel_mask_3630 to take care clksel width changes
2. CLock nodes which are newly added for 3630 are marked under CK_363X
3. Clock nodes which have changes for 3630 are marked as CK_3XXX | CK_363X
4. Clock nodes which are unchanged for 3630 are retained as CK_3XXX
5. 3630 specific Clock rates are marked as RATE_IN_363X
Cc: Paul Walmsley
Signed-off-by: Vishwanath BS
---
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 167f075..c304da5
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -43,6 +43,7 @@
#include "prm-regbits-34xx.h"
#include "cm.h"
#include "cm-regbits-34xx.h"
+#include
static const struct clkops clkops_noncore_dpll_ops;
@@ -97,6 +98,7 @@ struct omap_clk {
#define CK_3XXX(1 << 0)
#define CK_3430ES1 (1 << 1)
#define CK_3430ES2 (1 << 2)
+#define CK_363X(1 << 3)
static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "omap_32k_fck", &omap_32k_fck, CK_3XXX),
@@ -134,13 +136,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "omap_12m_fck", &omap_12m_fck, CK_3XXX),
CLK(NULL, "dpll4_m2_ck", &dpll4_m2_ck, CK_3XXX),
CLK(NULL, "dpll4_m2x2_ck", &dpll4_m2x2_ck, CK_3XXX),
- CLK(NULL, "dpll4_m3_ck", &dpll4_m3_ck, CK_3XXX),
+ CLK(NULL, "dpll4_m3_ck", &dpll4_m3_ck, CK_3XXX | CK_363X),
CLK(NULL, "dpll4_m3x2_ck", &dpll4_m3x2_ck, CK_3XXX),
- CLK(NULL, "dpll4_m4_ck", &dpll4_m4_ck, CK_3XXX),
+ CLK(NULL, "dpll4_m4_ck", &dpll4_m4_ck, CK_3XXX | CK_363X),
CLK(NULL, "dpll4_m4x2_ck", &dpll4_m4x2_ck, CK_3XXX),
- CLK(NULL, "dpll4_m5_ck", &dpll4_m5_ck, CK_3XXX),
+ CLK(NULL, "dpll4_m5_ck", &dpll4_m5_ck, CK_3XXX | CK_363X),
CLK(NULL, "dpll4_m5x2_ck", &dpll4_m5x2_ck, CK_3XXX),
- CLK(NULL, "dpll4_m6_ck", &dpll4_m6_ck, CK_3XXX),
+ CLK(NULL, "dpll4_m6_ck", &dpll4_m6_ck, CK_3XXX | CK_363X),
CLK(NULL, "dpll4_m6x2_ck", &dpll4_m6x2_ck, CK_3XXX),
CLK(NULL, "emu_per_alwon_ck", &emu_per_alwon_ck, CK_3XXX),
CLK(NULL, "dpll5_ck", &dpll5_ck, CK_3430ES2),
@@ -1222,7 +1224,11 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
dpll4_ck.dpll_data->sd_div_mask =
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
+ dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
+ cpu_mask |= RATE_IN_363X;
}
+ if (cpu_is_omap3630())
+ cpu_clkflg |= CK_363X;
}
clk_init(&omap2_clk_functions);
@@ -1232,6 +1238,12 @@ int __init omap2_clk_init(void)
for (c = omap34xx_clks; c < omap34xx_clks + ARRAY_SIZE(omap34xx_clks);
c++)
if (c->cpu & cpu_clkflg) {
+ /* for 3630, change the mask value for clocks which are
+ marked as CK_363X*/
+ if (cpu_is_omap3630() && (c->cpu & CK_363X)) {
+ c->lk.clk->clksel_mask =
+ c->lk.clk->clksel_mask_3630;
+ }
clkdev_add(&c->lk);
clk_register(c->lk.clk);
omap2_init_clk_clkdm(c->lk.clk);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 813a83e..93c92e5 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -243,6 +243,42 @@ static const struct clksel_rate div16_dpll_rates[] = {
{ .div = 0 }
};
+static const struct clksel_rate div32_dpll_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_3XXX | DEFAULT_RATE },
+ { .div = 2, .val = 2, .flags = RATE_IN_3XXX },
+ { .div = 3, .val = 3, .flags = RATE_IN_3XXX },
+ { .div = 4, .val = 4, .flags = RATE_IN_3XXX },
+ { .div = 5, .val = 5, .flags = RATE_IN_3XXX },
+ { .div = 6, .val = 6, .flags = RATE_IN_3XXX },
+ { .div = 7, .val = 7, .flags = RATE_IN_3XXX },
+ { .div = 8, .val = 8, .flags = RATE_IN_3XXX },
+ { .div = 9, .val = 9, .flags = RATE_IN_3XXX },
+ { .div = 10, .val = 10, .flags = RATE_IN_3XXX },
+ { .div = 11, .val = 11, .flags = RATE_IN_3XXX },
+ { .div = 12, .val = 12, .flags = RATE_IN_3XXX },
+ { .div = 13, .val = 13, .flags = RATE_IN_3XXX },
+ { .div = 14, .val = 14, .flags = RATE_IN_3XXX },
+ { .div = 15, .val = 15, .flags = RATE_IN_3XXX },
+ { .div = 16, .val = 16, .flags = RATE_IN_3XXX },
+ { .div = 17, .val = 17, .flags = RATE_IN_363X },
+ {
[PATCHV2 0/4] OMAP3: Clock changes for OMAP3630
This patch set introduces clock changes for OMAP3630. Major changes in OMAP3630 w.r.t clock are 1. Introduction of j type dpll4 2. CLKSEL filed width is increased by 1 bit for DPLL4M3, M4, M5 and M6 3. SGX can be run at 192Mhz Patch set has been created for linux-omap-pm tree V1: Initital Patch Series V2: Fixed Line wrap issue and incorporated comments for adding 192MHz Feature Richard Woodruff (1): OMAP3: introduce DPLL4 Jtype Vishwanath BS (3): OMAP3: Clock Type change for OMAP3 Clocks OMAP3: Correct width for CLKSEL Fields OMAP3: add support for 192Mhz sgx clock arch/arm/mach-omap2/clock.h | 15 +- arch/arm/mach-omap2/clock34xx.c | 445 ++- arch/arm/mach-omap2/clock34xx.h | 244 +++-- arch/arm/mach-omap2/cm-regbits-34xx.h | 11 + arch/arm/mach-omap2/id.c|7 +- arch/arm/plat-omap/include/plat/clock.h |9 +- arch/arm/plat-omap/include/plat/cpu.h |4 + 7 files changed, 456 insertions(+), 279 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/3] OMAP UART: Add omap-serial driver support.
On Mon, Nov 23, 2009 at 10:41 PM, Artem Bityutskiy wrote: > On Fri, 2009-11-13 at 12:23 +0530, Govindraj.R wrote: >> From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001 >> From: Govindraj R >> Date: Fri, 13 Nov 2009 12:01:54 +0530 >> Subject: [PATCH] OMAP UART: Add omap-serial driver support. >> >> This patch adds support for OMAP3430-HIGH SPEED UART Controller. >> >> It adds support for the following features: >> 1. It supports Interrupt mode and DMA mode of operation. >> 2. Supports Hardware flow control and sofware flow control. >> 3. Debug Console support on all UARTs. >> >> Signed-off-by: Govindraj R >> --- >> arch/arm/plat-omap/include/plat/omap-serial.h | 115 +++ >> drivers/serial/Kconfig | 23 + >> drivers/serial/Makefile | 1 + >> drivers/serial/omap-serial.c | 1330 >> + >> include/linux/serial_core.h | 3 + >> 5 files changed, 1472 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h >> create mode 100644 drivers/serial/omap-serial.c > > Did you address the irq storm problems pointed by Mika Westerberg? that issue has been resolved with this current patch series. --- Regards, Govindraj.R > > -- > Best Regards, > Artem Bityutskiy (Артём Битюцкий) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Thursday, November 26, 2009 1:10 AM
> To: Aggarwal, Anuj
> Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
> Subject: Re: [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
>
> On Thu, Nov 26, 2009 at 12:49:11AM +0530, Aggarwal, Anuj wrote:
>
> >
> > int i;
> > u16 reg;
> >
> > /* Sync reg_cache with the hardware */
> > for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); i++) {
> > u16 val = tlv320aic23_read_reg_cache(codec, reg);
> > tlv320aic23_write(codec, reg, val);
> > }
> >
>
> > I can see 'i' getting incremented, instead of 'reg'. Isn't this an
> > infinite loop?
>
> Yes, that does look entirely buggy - it seems fairly clear that suspend
> and resume have never worked with this driver. The fact that you were
> removing the loop entirely meant I didn't read the actual code for bugs.
>
> > > > This patch fixes the problem by correcting the resume path and
> > > > properly activating/deactivating the digital interface while
> > > > doing the suspend / off transitions.
>
> > > What do you mean by "properly activating/deactivating the digital
> > > interface"?
>
> > [Aggarwal, Anuj] The driver was only deactivating the digital
> > interface and not activating it. Hence added that part.
>
> So this is a separate issue, and should ideally be a separate patch - it
> looks like you've got three different changes here, one to fix the buggy
> register cache restore, one to manage the PWR bit on suspend and another
> to possibly fix the bias configuration. You certainly need to identify
> all three changes in the changelog, especially for things like this
> which look like they should go in as bug fixes (and bearing in mind that
> it's the end of the release cycle).
Fine with me, I will push individual patches for all the issues.
>
> Glancing at the code there's much more management required here -
> there's other places where it's managed and the code needs to be joined
> up with them. The setting should only be restored if the device was
> active when suspended, not unconditionally.
>
> > > > case SND_SOC_BIAS_STANDBY:
> > > > - /* everything off except vref/vmid, */
> > > > - tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
> > > > + /* Activate the digital interface */
> > > > + tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
> > > > break;
> > > > case SND_SOC_BIAS_OFF:
> > > > - /* everything off, dac mute, inactive */
> > > > + /* Deactivate the digital interface */
> > > > tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
> > > > - tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
> > > > break;
> > >
> > > This looks wrong - the driver is now no longer managing bias levels at
> > > all.
> > [Aggarwal, Anuj] The bias levels were wrongly managed earlier. While
> doing
> > a suspend, it was powering off all the interfaces and while coming up,
> it
> > was not switching on the required interfaces. Hence no sound was coming
> > out if audio was played back.
>
> Note that this CODEC driver impelements DAPM and so all the bits in the
> power register which are controlled by DAPM will be managed by the ASoC
> core without any action by the driver.
>
> > On each bias level, which are the interfaces which need to be switched
> > on / off?
>
> The biases and any other device-wide settings, everything else should be
> managed via DAPM if it's in use.
--
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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
> -Original Message-
> From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
> Sent: Thursday, November 26, 2009 1:53 AM
> To: Aggarwal, Anuj
> Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; Mark Brown;
> Arun KS
> Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
> hang
>
> Anuj Aggarwal wrote:
> > System hang is observed While trying to do suspend. It was because
> > of an infinite loop in the AIC23 resume path which was trying to
> > restore AIC23 register values from the register cache.
> >
> > This patch fixes the problem by correcting the resume path and
> > properly activating/deactivating the digital interface while
> > doing the suspend / off transitions.
> >
> > Signed-off-by: Anuj Aggarwal
> > ---
> > sound/soc/codecs/tlv320aic23.c | 16 +++-
> > 1 files changed, 3 insertions(+), 13 deletions(-)
> >
> > diff --git a/sound/soc/codecs/tlv320aic23.c
> b/sound/soc/codecs/tlv320aic23.c
> > index 6b24d8b..cabe60c 100644
> > --- a/sound/soc/codecs/tlv320aic23.c
> > +++ b/sound/soc/codecs/tlv320aic23.c
> > @@ -565,13 +565,12 @@ static int tlv320aic23_set_bias_level(struct
> snd_soc_codec *codec,
> > case SND_SOC_BIAS_PREPARE:
> > break;
> > case SND_SOC_BIAS_STANDBY:
> > - /* everything off except vref/vmid, */
> > - tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
> > + /* Activate the digital interface */
> > + tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
> > break;
> > case SND_SOC_BIAS_OFF:
> > - /* everything off, dac mute, inactive */
> > + /* Deactivate the digital interface */
> > tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
> > - tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
> > break;
> > }
> > codec->bias_level = level;
> > @@ -615,7 +614,6 @@ static int tlv320aic23_suspend(struct
> platform_device *pdev,
> > struct snd_soc_device *socdev = platform_get_drvdata(pdev);
> > struct snd_soc_codec *codec = socdev->card->codec;
> >
> > - tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
> > tlv320aic23_set_bias_level(codec, SND_SOC_BIAS_OFF);
> >
> > return 0;
> > @@ -625,14 +623,6 @@ static int tlv320aic23_resume(struct
> platform_device *pdev)
> > {
> > struct snd_soc_device *socdev = platform_get_drvdata(pdev);
> > struct snd_soc_codec *codec = socdev->card->codec;
> > - int i;
> > - u16 reg;
> > -
> > - /* Sync reg_cache with the hardware */
> > - for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); i++) {
> > - u16 val = tlv320aic23_read_reg_cache(codec, reg);
> > - tlv320aic23_write(codec, reg, val);
> > - }
>
> Changing to
> for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); reg++) {
>
> should be enough to fix the infinite loop.
> Could you try this without the rest of the patch?
I have already tried that but it doesn't fix the problem entirely.
Still, I was not able to playback properly because the bias settings
were not handled correctly and as you can see, it writes to some
invalid registers too (all registers don't exist between 0 and ARRAY_SIZE).
>
> >
> > tlv320aic23_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
> > tlv320aic23_set_bias_level(codec, codec->suspend_bias_level);
>
> Adding Arun to cc list
--
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] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)
Hello Janusz,
On Wed, 25 Nov 2009, Janusz Krzysztofik wrote:
> It turned out not that simple. Since arch/arm/mach-omap1/lcd_dma.c
> exports several functions that are called unconditionaly from
> drivers/video/omap/lcdc.c AND the latter is linked into the omapfb
> driver based on CONFIG_ARCH_OMAP1=y, linking in the former can't be
> limited to selected OMAP1 subarchs unless at least
> drivers/video/omap/{Kconfig,Makefile}, if not drivers/video/omap/lcdc.c
> itself either, are modified for that as well. Am I missing something?
>
> If not, I can see two options:
> 1. Keep arch/arm/mach-omap1/lcd_dma.c linked in for any OMAP1 subarch unless
> CONFIG_FB_OMAP is not set. That can be cleaned up further after the
> drivers/video/omap/* stuff is ever modified.
> 2. Include drivers/video/omap/* modifications into this series.
>
> What do you suggest?
Let's take option 1 for right now. Maybe one of the htcwizard people
might take that project up after the LCD DMA split is merged.
- 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 02/10 V3] omap3: pm: introduce opp accessor functions
Kevin Hilman had written, on 11/25/2009 05:46 PM, the following: [...] >>> something like this instead: >>> >>> /** >>> * opp_find_freq() >>> * @oppl:OPP list >>> * @freq:Frequency to look for in OPP table >>> * >>> * Look for an enabled OPP with a frequency value matching @freq. >>> * >>> * Returns pointer to OPP entry if match is found, or NULL if no match >>> * found. >>> */ >>> struct omap_opp *opp_find_freq(const struct omap_opp *oppl, u32 freq); >> I did think about it(single function doing multiple things), the >> intention is as follows in reality: >> opp_is_valid : Search only for enabled frequencies >> opp_has_freq : Searches for enabled/disabled frequencies >> >> This is useful for some logic which wants to enable a frequency which >> may have been disabled in the table. now, to retain that >> functionality, >> A) >> /** >> * opp_find_freq() - Find a opp corresponding to frequency >> * @oppl: opp list to search >> * @freq: frequency to loopup in OPP table >> * @enabled:search only enabled frequencies >> * >> * return opp handle corresponding to the frequency found, else >> * return NULL. Search for enabled frequencies if enabled flag >> * is true, else search for disabled frequencies also >> */ >> struct omap_opp *opp_find_freq(const struct omap_opp *oppl, >> unsigned long freq, bool enabled); >> >> This will handle the functionalities that are supported in rev 3. >> >> B) I rename existing functions: >> opp_has_freq ==> opp_is_disabled() >> opp_is_valid ==> opp_is_enabled() >> >> I would still prefer to go with explicit function search APIs.. > > I like (A) here. Ack. I can see it useful if we go to a list iterator at a later point of time. [...] >>> /** >>> * opp_find_freq_rounded() >>> * @oppl:OPP list >>> * @freq:Frequency to look for in OPP table >>> * @rounding:Rounding option: NONE, UP, DOWN >>> * >>> * Look for an OPP with a frequency value matching @freq. If >>> * @rounding != ROUND_NONE, find closest match using rounding. >>> * >>> * Can be used to find exact OPP, or match using given rounding: >>> >>> * @rounding == UP: find next highest frequency >>> * @rounding == DOWN:find next lowest frequency >>> * @rounding == CLOSEST: find closest frequency >>> * >>> * Returns pointer to OPP entry if match is found, or NULL if no match >>> * found (only possible when no rounding is used) >>> */ >>> struct omap_opp *opp_find_freq_rounded(struct omap_opp *oppl, u32 freq, u32 >>> rounding); >>> >>> Looking at the users of the 'higher' and 'lower' OPPs in the current >>> code, I see that SRF tries to use all three one after the other. >>> First it checks for exact match, then for higher, then for lower. >>> This could be replaced simply by doing a 'closest' match. >> hmmm.. I think we are going a full circle here. >> >> /* Search exact frequency */ >> #define OPP_ROUND_NONE (0 << 0) >> /* Search approx frequency */ >> #define OPP_ROUND_CLOSEST (1 << 0) >> /* Search up */ >> #define OPP_ROUND_HIGH (0 << 1) >> /* Search down */ >> #define OPP_ROUND_LOW(1 << 1) >> >> struct omap_opp *opp_find_freq_rounded(struct omap_opp *oppl, >> unsigned long freq, u8 rounding_flag); >> >> Note: the only difference b/w this and opp_find_freq is that >> opp_find_freq will also search for enabled/disabled. >> If I add that here, this is exactly the #1 implementation I did in >> http://marc.info/?l=linux-omap&m=125800489123496&w=2 >> ok, I used bool instead of a #define and added the complexity of using >> enabled flag also: >> >> bool search_higher, bool search_enabled_only, bool exact_search >> >> what you are proposing is that I go back to my implementation #1 and >> remove my bools instead by adding #defines: >> /* Search up */ >> #define OPP_ROUND_ENABLED (0 << 2) >> /* Search down */ >> #define OPP_ROUND_ANY(1 << 2) >> >> would even make the find_freq redundant.. >> >> Now, in your comment in >> http://marc.info/?l=linux-omap&m=125816031406704&w=2 quote:"I think >> all the options to this function make it not terribly >> readable." >> >> Does it become any different now? >> > > Yeah, I still think multiple bools to a function is a readability > problem. Every time you look at a call, you have to look at the > prototype to remember what all the options are. A single bool or flag > is better IMHO. > >> without taking this in, exact searches can be done by specific >> functions and approximate searches by another function.. we go >> generic functions or we go specific functions.. generic comments I >> have been getting is to go specific, hence the v2 and v3 series. > > OK, you're right. I am causing us to go around in circles now, but > we're going around in increasingly smaller circles and hopefully > converging on the target. ;) Yep :) > > So what I propose is having two functions. One for exact matches > (your proposal A above) and one for approxi
[PATCH 8/8] omap: mux: Remove old mux code for 34xx
Remove old mux code for 34xx
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-3430sdp.c |1
arch/arm/mach-omap2/board-cm-t35.c |1
arch/arm/mach-omap2/board-igep0020.c |1
arch/arm/mach-omap2/board-omap3beagle.c |1
arch/arm/mach-omap2/board-omap3evm.c |1
arch/arm/mach-omap2/board-omap3pandora.c |1
arch/arm/mach-omap2/board-overo.c|1
arch/arm/mach-omap2/board-rx51.c |1
arch/arm/mach-omap2/mux.c| 363 +-
arch/arm/plat-omap/include/plat/mux.h| 222 --
10 files changed, 9 insertions(+), 584 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index db24bbf..3018a12 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -31,7 +31,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 0110b64..e5f3039 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -38,7 +38,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 7e3217a..44239e3 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 9e606b1..6ada802 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 0457f61..18913e9 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -38,7 +38,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index bca5ad9..c1cc99c 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -40,7 +40,6 @@
#include
#include
#include
-#include
#include "mux.h"
#include "sdram-micron-mt46h32m32lf-6.h"
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 1ebde4c..5b78a87 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -44,7 +44,6 @@
#include
#include
#include
-#include
#include
#include "mux.h"
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index fd71c00..67bb347 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -23,7 +23,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 85e633d..28404db 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -282,333 +282,8 @@ MUX_CFG_24XX("AF19_2430_GPIO_85", 0x0113, 3, 0,
0, 1)
#define OMAP24XX_PINS_SZ ARRAY_SIZE(omap24xx_pins)
-#else
-#define omap24xx_pins NULL
-#define OMAP24XX_PINS_SZ 0
-#endif /* CONFIG_ARCH_OMAP24XX */
-
-#ifdef CONFIG_ARCH_OMAP34XX
-static struct pin_config __initdata_or_module omap34xx_pins[] = {
-/*
- * Name, reg-offset,
- * mux-mode | [active-mode | off-mode]
- */
-
-/* 34xx I2C */
-MUX_CFG_34XX("K21_34XX_I2C1_SCL", 0x1ba,
- OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
-MUX_CFG_34XX("J21_34XX_I2C1_SDA", 0x1bc,
- OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
-MUX_CFG_34XX("AF15_34XX_I2C2_SCL", 0x1be,
- OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
-MUX_CFG_34XX("AE15_34XX_I2C2_SDA", 0x1c0,
- OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
-MUX_CFG_34XX("AF14_34XX_I2C3_SCL", 0x1c2,
- OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
-MUX_CFG_34XX("AG14_34XX_I2C3_SDA", 0x1c4,
- OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
-MUX_CFG_34XX("AD26_34XX_I2C4_SCL", 0xa00,
- OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
-MUX_CFG_34XX("AE26_34XX_I2C4_SDA", 0xa02,
- OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
-
-/* PHY - HSUSB: 12-pin ULPI PHY: Port 1*/
-MUX_CFG_34XX("Y8_3430_USB1HS_PHY_CLK", 0x5da,
- OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_OUTPUT)
-MUX_CFG_34XX("Y9_3430_USB1HS_PHY_STP", 0x5d8,
- OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_OUTPUT)
-MUX_CFG_34XX("AA14_3430_USB1HS_PHY_DIR", 0x5ec,
- OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
-MUX_CFG_34XX("AA11_3430_USB1HS_PHY_NXT", 0x5ee,
- OMAP34XX_MUX_MODE3 | OMAP34XX_
Re: [PATCH 0/8] Omap mux changes for v2.6.33 merge window (Series short description)
* Tony Lindgren [091125 16:17]: > Hi all, > > Here are some omap mux updates for review. These > are intended for the v2.6.33 merge window. Forgot to edit the subject :) Also, these patches are available in the mux branch of the linux-omap tree for easy testing. 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
[PATCH 7/8] omap: mux: Replace omap_cfg_reg() with new style signal or gpio functions
Replace omap_cfg_reg() with new style signal or gpio functions
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-3430sdp.c |2
arch/arm/mach-omap2/board-3630sdp.c |3 -
arch/arm/mach-omap2/board-cm-t35.c |2
arch/arm/mach-omap2/board-omap3beagle.c | 10 +-
arch/arm/mach-omap2/board-omap3evm.c | 10 +-
arch/arm/mach-omap2/board-omap3pandora.c |4 -
arch/arm/mach-omap2/board-overo.c|4 -
arch/arm/mach-omap2/board-rx51-peripherals.c |7 +
arch/arm/mach-omap2/board-rx51.c |4 -
arch/arm/mach-omap2/devices.c| 42 +
arch/arm/mach-omap2/usb-ehci.c | 122 +-
11 files changed, 108 insertions(+), 102 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index d627471..db24bbf 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -492,7 +492,7 @@ static inline void board_smc91x_init(void)
static void enable_board_wakeup_source(void)
{
- omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
+ omap_mux_init_signal("sys_nirq", OMAP_WAKEUP_EN |
OMAP_PIN_INPUT_PULLUP); /* T2 interrupt line (keypad) */
}
static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 348b70b..0647e6f 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -23,6 +23,7 @@
#include
+#include "mux.h"
#include "sdram-hynix-h8mbx00u0mer-0em.h"
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
@@ -48,7 +49,7 @@ static inline void board_smc91x_init(void)
static void enable_board_wakeup_source(void)
{
- omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
+ omap_mux_init_signal("sys_nirq", OMAP_WAKEUP_EN |
OMAP_PIN_INPUT_PULLUP); /* T2 interrupt line (keypad) */
}
static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 84321f6..0110b64 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -503,7 +503,7 @@ static void __init cm_t35_init(void)
usb_musb_init();
- omap_cfg_reg(AF26_34XX_SYS_NIRQ);
+ omap_mux_init_signal("sys_nirq", OMAP_WAKEUP_EN |
OMAP_PIN_INPUT_PULLUP);
}
MACHINE_START(CM_T35, "Compulab CM-T35")
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index e669dbb..9e606b1 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -141,10 +141,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
if (system_rev >= 0x20 && system_rev <= 0x34301000) {
- omap_cfg_reg(AG9_34XX_GPIO23);
+ omap_mux_init_gpio(23, OMAP_PIN_INPUT);
mmc[0].gpio_wp = 23;
} else {
- omap_cfg_reg(AH8_34XX_GPIO29);
+ omap_mux_init_gpio(29, OMAP_PIN_INPUT);
}
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
@@ -439,7 +439,7 @@ static void __init omap3_beagle_init(void)
ARRAY_SIZE(omap3_beagle_devices));
omap_serial_init();
- omap_cfg_reg(J25_34XX_GPIO170);
+ omap_mux_init_gpio(170, OMAP_PIN_INPUT);
gpio_request(170, "DVI_nPD");
/* REVISIT leave DVI powered down until it's needed ... */
gpio_direction_output(170, true);
@@ -449,8 +449,8 @@ static void __init omap3_beagle_init(void)
omap3beagle_flash_init();
/* Ensure SDRC pins are mux'd for self-refresh */
- omap_cfg_reg(H16_34XX_SDRC_CKE0);
- omap_cfg_reg(H17_34XX_SDRC_CKE1);
+ omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
+ omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
}
static void __init omap3_beagle_map_io(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ad174ae..0457f61 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -224,7 +224,7 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
- omap_cfg_reg(L8_34XX_GPIO63);
+ omap_mux_init_gpio(63, OMAP_PIN_INPUT);
mmc[0].gpio_cd = gpio + 0;
twl4030_mmc_init(mmc);
@@ -450,24 +450,24 @@ static void __init omap3_evm_init(void)
#endif
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
- omap_cfg_reg(AF9_34XX_GPIO22);
+ omap_mux_init_gpio(22, OMAP_PIN_INPUT_PULLUP);
gpio_request(OMAP3_EVM_EHCI_VBUS,
[PATCH 6/8] omap: Split i2c platform init for mach-omap1 and mach-omap2
Otherwise we cannot limit new mux code to mach-omap2.
The same signal names should eventually work for other
omaps under mach-omap2.
Note that these pins don't need to be OMAP_PIN_INPUT_PULLUP,
just OMAP_PIN_INPUT is enough.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/devices.c| 20
arch/arm/plat-omap/i2c.c | 24 +---
arch/arm/plat-omap/include/plat/common.h |1 +
3 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 733d3dc..000f304 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -743,6 +743,26 @@ static inline void omap_hdq_init(void) {}
/*-*/
+#if defined(CONFIG_I2C_OMAP) || defined(CONFIG_I2C_OMAP_MODULE)
+
+/* Called from omap_i2c_mux_pins. The first i2c bus is non-muxable */
+void omap_i2c_mach_mux(int bus_id)
+{
+ char mux_name[sizeof("i2c2_scl.i2c2_scl")];
+
+ if (cpu_is_omap34xx() && bus_id == 1)
+ return;
+
+ sprintf(mux_name, "i2c%i_scl.i2c%i_scl", bus_id, bus_id);
+ omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
+ sprintf(mux_name, "i2c%i_sda.i2c%i_sda", bus_id, bus_id);
+ omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
+}
+
+#endif
+
+/*-*/
+
static int __init omap2_init_devices(void)
{
/* please keep these calls, and their implementations above,
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index c08362d..ba2306a 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#define OMAP_I2C_SIZE 0x3f
@@ -88,15 +89,6 @@ static const int omap24xx_pins[][2] = {
#else
static const int omap24xx_pins[][2] = {};
#endif
-#if defined(CONFIG_ARCH_OMAP34XX)
-static const int omap34xx_pins[][2] = {
- { K21_34XX_I2C1_SCL, J21_34XX_I2C1_SDA},
- { AF15_34XX_I2C2_SCL, AE15_34XX_I2C2_SDA},
- { AF14_34XX_I2C3_SCL, AG14_34XX_I2C3_SDA},
-};
-#else
-static const int omap34xx_pins[][2] = {};
-#endif
#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
@@ -104,15 +96,17 @@ static void __init omap_i2c_mux_pins(int bus)
{
int scl, sda;
+ if (cpu_is_omap34xx()) {
+ omap_i2c_mach_mux(bus);
+ return;
+ }
+
if (cpu_class_is_omap1()) {
scl = I2C_SCL;
sda = I2C_SDA;
} else if (cpu_is_omap24xx()) {
- scl = omap24xx_pins[bus][0];
- sda = omap24xx_pins[bus][1];
- } else if (cpu_is_omap34xx()) {
- scl = omap34xx_pins[bus][0];
- sda = omap34xx_pins[bus][1];
+ scl = omap24xx_pins[bus - 1][0];
+ sda = omap24xx_pins[bus - 1][1];
} else {
return;
}
@@ -156,7 +150,7 @@ static int __init omap_i2c_add_bus(int bus_id)
res[1].start = irq;
}
- omap_i2c_mux_pins(bus_id - 1);
+ omap_i2c_mux_pins(bus_id);
return platform_device_register(pdev);
}
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 064f173..e46aefe 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -40,6 +40,7 @@ extern struct sys_timer omap_timer;
extern int omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
unsigned len);
+extern void omap_i2c_mach_mux(int bus_id);
#else
static inline int omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
--
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/8] omap: mux: Add debugfs support for new mux code
Add debugfs support for new mux code
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux.c | 224 +
1 files changed, 224 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 9091029..85e633d 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -28,6 +28,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
@@ -47,6 +51,7 @@ struct omap_mux_entry {
};
static struct omap_mux_cfg arch_mux_cfg;
+static unsigned long mux_phys;
static void __iomem *mux_base;
static inline u16 omap_mux_read(u16 reg)
@@ -772,6 +777,222 @@ int __init omap_mux_init_signal(char *muxname, int val)
return -ENODEV;
}
+#ifdef CONFIG_DEBUG_FS
+
+#define OMAP_MUX_MAX_NR_FLAGS 10
+#define OMAP_MUX_TEST_FLAG(val, mask) \
+ if (((val) & (mask)) == (mask)) { \
+ i++;\
+ flags[i] = #mask; \
+ }
+
+/* REVISIT: Add checking for non-optimal mux settings */
+static inline void omap_mux_decode(struct seq_file *s, u16 val)
+{
+ char *flags[OMAP_MUX_MAX_NR_FLAGS];
+ char mode[14];
+ int i = -1;
+
+ sprintf(mode, "OMAP_MUX_MODE%d", val & 0x7);
+ i++;
+ flags[i] = mode;
+
+ OMAP_MUX_TEST_FLAG(val, OMAP_PIN_OFF_WAKEUPENABLE);
+ if (val & OMAP_OFF_EN) {
+ if (!(val & OMAP_OFFOUT_EN)) {
+ if (!(val & OMAP_OFF_PULL_UP)) {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_OFF_INPUT_PULLDOWN);
+ } else {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_OFF_INPUT_PULLUP);
+ }
+ } else {
+ if (!(val & OMAP_OFFOUT_VAL)) {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_OFF_OUTPUT_LOW);
+ } else {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_OFF_OUTPUT_HIGH);
+ }
+ }
+ }
+
+ if (val & OMAP_INPUT_EN) {
+ if (val & OMAP_PULL_ENA) {
+ if (!(val & OMAP_PULL_UP)) {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_INPUT_PULLDOWN);
+ } else {
+ OMAP_MUX_TEST_FLAG(val, OMAP_PIN_INPUT_PULLUP);
+ }
+ } else {
+ OMAP_MUX_TEST_FLAG(val, OMAP_PIN_INPUT);
+ }
+ } else {
+ i++;
+ flags[i] = "OMAP_PIN_OUTPUT";
+ }
+
+ do {
+ seq_printf(s, "%s", flags[i]);
+ if (i > 0)
+ seq_printf(s, " | ");
+ } while (i-- > 0);
+}
+
+#define OMAP_MUX_DEFNAME_LEN 16
+
+static int omap_mux_dbg_board_show(struct seq_file *s, void *unused)
+{
+ struct omap_mux_entry *e;
+
+ list_for_each_entry(e, &muxmodes, node) {
+ struct omap_mux *m = &e->mux;
+ char m0_def[OMAP_MUX_DEFNAME_LEN];
+ char *m0_name = m->muxnames[0];
+ u16 val;
+ int i, mode;
+
+ if (!m0_name)
+ continue;
+
+ for (i = 0; i < OMAP_MUX_DEFNAME_LEN; i++) {
+ if (m0_name[i] == '\0') {
+ m0_def[i] = m0_name[i];
+ break;
+ }
+ m0_def[i] = toupper(m0_name[i]);
+ }
+ val = omap_mux_read(m->reg_offset);
+ mode = val & OMAP_MUX_MODE7;
+
+ seq_printf(s, "OMAP%i_MUX(%s, ",
+ cpu_is_omap34xx() ? 3 : 0, m0_def);
+ omap_mux_decode(s, val);
+ seq_printf(s, "),\n");
+ }
+
+ return 0;
+}
+
+static int omap_mux_dbg_board_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, omap_mux_dbg_board_show, &inode->i_private);
+}
+
+static const struct file_operations omap_mux_dbg_board_fops = {
+ .open = omap_mux_dbg_board_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static int omap_mux_dbg_signal_show(struct seq_file *s, void *unused)
+{
+ struct omap_mux *m = s->private;
+ const char *none = "NA";
+ u16 val;
+ int mode;
+
+ val = omap_mux_read(m->reg_offset);
+ mode = val & OMAP_MUX_MODE7;
+
+ seq_printf(s, "name: %s.%s (0x%08lx/0x%03x = 0x%04x), b %s, t %s\n",
+ m->muxnames[0
[PATCH 4/8] omap: mux: Add new style init functions to omap3 board-*.c files
Add new style mux init functions to omap3 board-*.c files
So far Beagle has been confirmed to be a CBB package,
and CM-T35 a CUS package.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-3430sdp.c | 10 ++
arch/arm/mach-omap2/board-am3517evm.c| 11 +++
arch/arm/mach-omap2/board-cm-t35.c | 10 ++
arch/arm/mach-omap2/board-igep0020.c | 10 ++
arch/arm/mach-omap2/board-ldp.c | 10 ++
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
arch/arm/mach-omap2/board-omap3evm.c | 10 ++
arch/arm/mach-omap2/board-omap3pandora.c | 10 ++
arch/arm/mach-omap2/board-overo.c|9 +
arch/arm/mach-omap2/board-rx51.c | 11 +++
arch/arm/mach-omap2/board-zoom2.c| 11 +++
11 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 491364e..d627471 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -41,6 +41,7 @@
#include
#include
+#include "mux.h"
#include "sdram-qimonda-hyb18m512160af-6.h"
#include "mmc-twl4030.h"
@@ -506,8 +507,17 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.reset_gpio_port[2] = -EINVAL
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap_3430sdp_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
if (omap_rev() > OMAP3430_REV_ES1_0)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 415a13d..b4e6eca 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,6 +30,8 @@
#include
#include
+#include "mux.h"
+
/*
* Board initialization
*/
@@ -60,8 +62,17 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initdata = {
.reset_gpio_port[2] = -EINVAL
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init am3517_evm_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
platform_add_devices(am3517_evm_devices,
ARRAY_SIZE(am3517_evm_devices));
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 22c4529..84321f6 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -45,6 +45,7 @@
#include
+#include "mux.h"
#include "sdram-micron-mt46h32m32lf-6.h"
#include "mmc-twl4030.h"
@@ -482,8 +483,17 @@ static void __init cm_t35_map_io(void)
omap2_map_common_io();
}
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init cm_t35_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
omap_serial_init();
cm_t35_init_i2c();
cm_t35_init_nand();
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index fa62e80..7e3217a 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -30,6 +30,7 @@
#include
#include
+#include "mux.h"
#include "mmc-twl4030.h"
#define IGEP2_SMSC911X_CS 5
@@ -203,8 +204,17 @@ static int __init igep2_i2c_init(void)
return 0;
}
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init igep2_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
igep2_i2c_init();
omap_serial_init();
usb_musb_init();
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index c062238..3743173 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -43,6 +43,7 @@
#include
#include
+#include "mux.h"
#include "mmc-twl4030.h"
#define LDP_SMSC911X_CS1
@@ -374,8 +375,17 @@ static struct platform_device *ldp_devices[] __initdata = {
&ldp_gpio_keys_device,
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap_ldp_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_i2c_init();
platform_add_devices(ldp_devices, ARRAY_SIZE(ldp_devices));
ts_gpio = 54;
diff --git a/arch/arm/mac
[PATCH 2/8] omap: mux: Add new style pin multiplexing code for omap3
Initially only for 34xx. This code allows us to:
- Make the code more generic as the omap internal signal
names can stay the same across omap generations for some
devices
- Map mux registers to GPIO registers that is needed for
dynamic muxing of pins during off-idle
- Override bootloader mux values via kernel cmdline using
omap_mux=some.signa1=0x1234,some.signal2=0x1234
- View and set the mux registers via debugfs if
CONFIG_DEBUG_FS is enabled
Cc: Paul Walmsley
Cc: Benoit Cousson
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux.c | 358 +
arch/arm/mach-omap2/mux.h | 148 +++
arch/arm/plat-omap/mux.c |8 +
3 files changed, 510 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mach-omap2/mux.h
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 64250c5..9091029 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -27,17 +27,25 @@
#include
#include
#include
+#include
#include
#include
#include
+#include "mux.h"
+
#ifdef CONFIG_OMAP_MUX
#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
#define OMAP_MUX_BASE_SZ 0x5ca
+struct omap_mux_entry {
+ struct omap_mux mux;
+ struct list_headnode;
+};
+
static struct omap_mux_cfg arch_mux_cfg;
static void __iomem *mux_base;
@@ -659,6 +667,352 @@ static int __init_or_module omap34xx_cfg_reg(const struct
pin_config *cfg)
#define omap34xx_cfg_reg NULL
#endif
+/**/
+
+#ifdef CONFIG_ARCH_OMAP34XX
+
+static LIST_HEAD(muxmodes);
+static DEFINE_MUTEX(muxmode_mutex);
+
+static char *omap_mux_options;
+
+int __init omap_mux_init_gpio(int gpio, int val)
+{
+ struct omap_mux_entry *e;
+ int found = 0;
+
+ if (!gpio)
+ return -EINVAL;
+
+ list_for_each_entry(e, &muxmodes, node) {
+ struct omap_mux *m = &e->mux;
+ if (gpio == m->gpio) {
+ u16 old_mode;
+ u16 mux_mode;
+
+ old_mode = omap_mux_read(m->reg_offset);
+ mux_mode = val & ~(OMAP_MUX_NR_MODES - 1);
+ mux_mode |= OMAP_MUX_MODE4;
+ printk(KERN_DEBUG "mux: Setting signal "
+ "%s.gpio%i 0x%04x -> 0x%04x\n",
+ m->muxnames[0], gpio, old_mode, mux_mode);
+ omap_mux_write(mux_mode, m->reg_offset);
+ found++;
+ }
+ }
+
+ if (found == 1)
+ return 0;
+
+ if (found > 1) {
+ printk(KERN_ERR "mux: Multiple gpio paths for gpio%i\n", gpio);
+ return -EINVAL;
+ }
+
+ printk(KERN_ERR "mux: Could not set gpio%i\n", gpio);
+
+ return -ENODEV;
+}
+
+int __init omap_mux_init_signal(char *muxname, int val)
+{
+ struct omap_mux_entry *e;
+ char *m0_name = NULL, *mode_name = NULL;
+ int found = 0;
+
+ mode_name = strchr(muxname, '.');
+ if (mode_name) {
+ *mode_name = '\0';
+ mode_name++;
+ m0_name = muxname;
+ } else {
+ mode_name = muxname;
+ }
+
+ list_for_each_entry(e, &muxmodes, node) {
+ struct omap_mux *m = &e->mux;
+ char *m0_entry = m->muxnames[0];
+ int i;
+
+ if (m0_name && strcmp(m0_name, m0_entry))
+ continue;
+
+ for (i = 0; i < OMAP_MUX_NR_MODES; i++) {
+ char *mode_cur = m->muxnames[i];
+
+ if (!mode_cur)
+ continue;
+
+ if (!strcmp(mode_name, mode_cur)) {
+ u16 old_mode;
+ u16 mux_mode;
+
+ old_mode = omap_mux_read(m->reg_offset);
+ mux_mode = val | i;
+ printk(KERN_DEBUG "mux: Setting signal "
+ "%s.%s 0x%04x -> 0x%04x\n",
+ m0_entry, muxname, old_mode, mux_mode);
+ omap_mux_write(mux_mode, m->reg_offset);
+ found++;
+ }
+ }
+ }
+
+ if (found == 1)
+ return 0;
+
+ if (found > 1) {
+ printk(KERN_ERR "mux: Multiple signal paths (%i) for %s\n",
+ found, muxname);
+ return -EINVAL;
+ }
+
+ printk(KERN_ERR "mux: Could not set signal %s\n", muxname);
+
+ return -ENODEV;
+}
+
+static void __init omap_mux_free_names(struct omap_mux *m)
+{
+ int i;
+
+ for (i = 0; i < OMAP_MUX_NR_MODES; i++)
+ kfree
[PATCH 1/8] omap2: mux: intoduce omap_mux_{read,write}
From: Mike Rapoport
intoduce omap_mux_{read,write}
Signed-off-by: Mike Rapoport
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux.c | 44 ++--
1 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c18a94e..64250c5 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -35,7 +35,27 @@
#ifdef CONFIG_OMAP_MUX
+#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
+#define OMAP_MUX_BASE_SZ 0x5ca
+
static struct omap_mux_cfg arch_mux_cfg;
+static void __iomem *mux_base;
+
+static inline u16 omap_mux_read(u16 reg)
+{
+ if (cpu_is_omap24xx())
+ return __raw_readb(mux_base + reg);
+ else
+ return __raw_readw(mux_base + reg);
+}
+
+static inline void omap_mux_write(u16 val, u16 reg)
+{
+ if (cpu_is_omap24xx())
+ __raw_writeb(val, mux_base + reg);
+ else
+ __raw_writew(val, mux_base + reg);
+}
/* NOTE: See mux.h for the enumeration */
@@ -581,10 +601,7 @@ static void __init_or_module omap2_cfg_debug(const struct
pin_config *cfg, u16 r
u16 orig;
u8 warn = 0, debug = 0;
- if (cpu_is_omap24xx())
- orig = omap_ctrl_readb(cfg->mux_reg);
- else
- orig = omap_ctrl_readw(cfg->mux_reg);
+ orig = omap_mux_read(cfg->mux_reg - OMAP_MUX_BASE_OFFSET);
#ifdef CONFIG_OMAP_MUX_DEBUG
debug = cfg->debug;
@@ -614,7 +631,7 @@ static int __init_or_module omap24xx_cfg_reg(const struct
pin_config *cfg)
if (cfg->pu_pd_val)
reg |= OMAP2_PULL_UP;
omap2_cfg_debug(cfg, reg);
- omap_ctrl_writeb(reg, cfg->mux_reg);
+ omap_mux_write(reg, cfg->mux_reg - OMAP_MUX_BASE_OFFSET);
spin_unlock_irqrestore(&mux_spin_lock, flags);
return 0;
@@ -633,7 +650,7 @@ static int __init_or_module omap34xx_cfg_reg(const struct
pin_config *cfg)
spin_lock_irqsave(&mux_spin_lock, flags);
reg |= cfg->mux_val;
omap2_cfg_debug(cfg, reg);
- omap_ctrl_writew(reg, cfg->mux_reg);
+ omap_mux_write(reg, cfg->mux_reg - OMAP_MUX_BASE_OFFSET);
spin_unlock_irqrestore(&mux_spin_lock, flags);
return 0;
@@ -644,6 +661,21 @@ static int __init_or_module omap34xx_cfg_reg(const struct
pin_config *cfg)
int __init omap2_mux_init(void)
{
+ u32 mux_pbase;
+
+ if (cpu_is_omap2420())
+ mux_pbase = OMAP2420_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+ else if (cpu_is_omap2430())
+ mux_pbase = OMAP243X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+ else if (cpu_is_omap34xx())
+ mux_pbase = OMAP343X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+
+ mux_base = ioremap(mux_pbase, OMAP_MUX_BASE_SZ);
+ if (!mux_base) {
+ printk(KERN_ERR "mux: Could not ioremap\n");
+ return -ENODEV;
+ }
+
if (cpu_is_omap24xx()) {
arch_mux_cfg.pins = omap24xx_pins;
arch_mux_cfg.size = OMAP24XX_PINS_SZ;
--
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/8] Series short description
Hi all,
Here are some omap mux updates for review. These
are intended for the v2.6.33 merge window.
Initially this series changes the omap34xx mux
code, I'm planning on adding 3630, 2420, and 2430
code later on.
There are several reasons why we need better mux
code:
- We want to make the mux code more generic and this
will allow us to use the internal signal names and
gpio numbers instead of mux register offsets. The
internal signal names stay the same across omap
generations for some devices.
- We need to map mux registers to GPIO registers for
dynamic muxing of the GPIO pins during off-idle.
- We want to be able to override the bootloader mux
values for the modded boards, such as the Beagle.
- We want to have the mux signals and balls available
under debugfs for debugging new drivers.
Some of these might eventually work for other archs
too, so let me know if you have any comments on that.
Regards,
Tony
Here are some instructions on how to use:
To see what got muxed during init, edit the kernel
CMDLINE to have debug in it:
# dmesg | grep mux
mux: Setting signal i2c2_scl.i2c2_scl 0x0100 -> 0x0100
mux: Setting signal i2c2_sda.i2c2_sda 0x0100 -> 0x0100
mux: Setting signal i2c3_scl.i2c3_scl 0x0100 -> 0x0100
mux: Setting signal i2c3_sda.i2c3_sda 0x0100 -> 0x0100
mux: Setting signal gpmc_ncs3.gpio54 0x410c -> 0x010c
...
Looks like the gpmc_ncs3.gpio54 muxing in the kernel
has a bug where we should have OMAP_WAKEUP_EN set for
board_smc91x_init for board-rx51? :)
To override bootloader mux settings, edit the kernel CMDLINE:
omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
Note that this only changes the bootloader settings, not
what might be muxed from the board-*.c files.
With CONFIG_DEBUG_FS set:
# mount -t sysfs sys /sys
# mount -t debugfs debug /sys/kernel/debug
# ls /sys/kernel/debug/omap_mux/i2c
i2c2_scl i2c2_sda i2c3_scl i2c3_sda i2c4_scl i2c4_sda
# cat /sys/kernel/debug/omap_mux/i2c2_scl
name: i2c2_scl.i2c2_scl (0x480021be/0x18e = 0x0100), b af15, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: i2c2_scl | NA | NA | NA | gpio_168 | NA | NA | safe_mode
---
Mike Rapoport (1):
omap2: mux: intoduce omap_mux_{read,write}
Tony Lindgren (7):
omap: mux: Add new style pin multiplexing code for omap3
omap: mux: Add new style pin multiplexing data for 34xx
omap: mux: Add new style init functions to omap3 board-*.c files
omap: mux: Add debugfs support for new mux code
omap: Split i2c platform init for mach-omap1 and mach-omap2
omap: mux: Replace omap_cfg_reg() with new style signal or gpio functions
omap: mux: Remove old mux code for 34xx
arch/arm/mach-omap2/Makefile |4
arch/arm/mach-omap2/board-3430sdp.c | 13
arch/arm/mach-omap2/board-3630sdp.c |3
arch/arm/mach-omap2/board-am3517evm.c| 11
arch/arm/mach-omap2/board-cm-t35.c | 13
arch/arm/mach-omap2/board-igep0020.c | 11
arch/arm/mach-omap2/board-ldp.c | 10
arch/arm/mach-omap2/board-omap3beagle.c | 21
arch/arm/mach-omap2/board-omap3evm.c | 21
arch/arm/mach-omap2/board-omap3pandora.c | 15
arch/arm/mach-omap2/board-overo.c| 14
arch/arm/mach-omap2/board-rx51-peripherals.c |7
arch/arm/mach-omap2/board-rx51.c | 16
arch/arm/mach-omap2/board-zoom2.c| 11
arch/arm/mach-omap2/devices.c| 62 +
arch/arm/mach-omap2/mux.c| 961 ++--
arch/arm/mach-omap2/mux.h| 150 +++
arch/arm/mach-omap2/mux34xx.c| 1558 ++
arch/arm/mach-omap2/mux34xx.h| 351 ++
arch/arm/mach-omap2/usb-ehci.c | 122 +-
arch/arm/plat-omap/i2c.c | 24
arch/arm/plat-omap/include/plat/common.h |1
arch/arm/plat-omap/include/plat/mux.h| 222
arch/arm/plat-omap/mux.c |8
24 files changed, 2932 insertions(+), 697 deletions(-)
create mode 100644 arch/arm/mach-omap2/mux.h
create mode 100644 arch/arm/mach-omap2/mux34xx.c
create mode 100644 arch/arm/mach-omap2/mux34xx.h
--
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
Re: [PATCH 02/10 V3] omap3: pm: introduce opp accessor functions
Nishanth Menon writes: > Kevin Hilman had written, on 11/25/2009 10:30 AM, the following: > [..] > >>> Signed-off-by: Sanjeev Premi >>> Signed-off-by: Kevin Hilman >> >> Not yet. :) > :) Thanks a bunch for your detailed comments. have provided answers > below. I think we are not aligned on the search functions > unfortunately. And thanks for your lead on getting a better OPP layer in shape. We're getting very close now. >> >>> Signed-off-by: Nishanth Menon >> >> Some general comments. >> >> I think the forcing of an int return code for all the functions is a >> bit artificial, and is a loss in readability IMHO. I've never liked >> getting results values in function arguments, and find that style >> difficult to read. More comments on this for each function below. > Alright, will fix. > >> >>> --- >>> arch/arm/plat-omap/Makefile |3 + >>> arch/arm/plat-omap/include/plat/opp.h | 208 ++ >>> arch/arm/plat-omap/opp.c | 260 >>> + >> >> I think this should be mach-omap2/opp.c > OPP is a concept that is not limited to omap2. it can be implemented > for omap1 if desired (they had 2 OPPs - OPP50 and OPP100), it is hence > introduced as a common logic across OMAPs in plat-omap. > > [...] > >>> diff --git a/arch/arm/plat-omap/include/plat/opp.h >>> b/arch/arm/plat-omap/include/plat/opp.h >>> new file mode 100644 >>> index 000..d8ae2d3 >>> --- /dev/null >>> +++ b/arch/arm/plat-omap/include/plat/opp.h >>> @@ -0,0 +1,208 @@ > [...] > >>> +/** >>> + * opp_get_voltage - Gets the voltage corresponding to an opp >>> + * @u_volt: Voltage in microvolts corresponding to an opp >>> + * @opp: opp for which voltage has to be returned for >>> + * >>> + * Return 0 and the voltage in micro volt corresponding to the opp, >>> + * else return the corresponding error value. >>> + */ >>> +int opp_get_voltage(u32 *u_volt, const struct omap_opp *opp); >> >> Should just return voltage or -EINVAL >> >> int opp_get_voltage(const struct omap_opp *opp); > Ack. it cant be int as uVolt is unsigned long. ok > /** > * opp_get_voltage - Gets the voltage corresponding to an opp > * @opp:opp for which voltage has to be returned for > * > * Return voltage in micro volt corresponding to the opp, else > * return 0 > */ > unsigned long opp_get_voltage(const struct omap_opp *opp); > >> >>> + >>> +/** >>> + * opp_get_freq - Gets the frequency corresponding to an opp >>> + * @freq:Frequency in hertz corresponding to an opp >>> + * @opp: opp for which frequency has to be returned for >>> + * >>> + * Return 0 and the frequency in hertz corresponding to the opp, >>> + * else return the corresponding error value. >>> + */ >>> +int opp_get_freq(unsigned long *freq, const struct omap_opp *opp); >> >> ditto > Same as above: ok > /** > * opp_get_freq - Gets the frequency corresponding to an opp > * @opp:opp for which frequency has to be returned for > * > * Return frequency in hertz corresponding to the opp, else > * return 0 > */ > unsigned long opp_get_freq(const struct omap_opp *opp); > >> >>> + >>> +/** >>> + * opp_is_valid - Verifies if a given frequency is enabled in the opp list >>> + * @opp: Pointer to opp returned if opp match is achieved >>> + * @oppl:opp list >>> + * @freq:Frequency in hertz to check for >>> + * >>> + * Searches the OPP list to find if the provided frequency is an enabled >>> + * frequency. If a match is achieved, it returns 0 and the pointer to the >>> opp >>> + * is returned, else a corresponding error value is returned. >>> + */ >>> +int opp_is_valid(struct omap_opp **opp, const struct omap_opp *oppl, >>> + const unsigned long freq); >>> + >>> +/** >>> + * opp_has_freq - Checks if a frequency is exists(enabled/disabled) in opp >>> list >>> + * @opp: Pointer to opp returned if opp match is achieved >>> + * @oppl:opp list >>> + * @freq:Frequency in hertz to check for >>> + * >>> + * Searches the OPP list to find a frequency. This is a more generic >>> function >>> + * than the opp_is_valid since it searches for both enabled/disabled >>> + * frequencies. >>> + * >>> + * This function may be used by detection logic to enable a disabled OPP as >>> + * all other search functions work on enabled OPPs only. >>> + */ >>> +int opp_has_freq(struct omap_opp **opp, const struct omap_opp *oppl, >>> + const unsigned long freq); >> >> Don't see any users of this, and it looks like the same functionality >> as opp_is_valid(). >> >> Both of these are just a "find opp by freq". How about having >> something like this instead: >> >> /** >> * opp_find_freq() >> * @oppl:OPP list >> * @freq:Frequency to look for in OPP table >> * >> * Look for an enabled OPP with a frequency value matching @freq. >> * >> * Returns pointer to OPP entry if match is found, or NULL if no match >> * found. >> */ >> struct omap_opp *opp_find_freq(const struct om
RE: [PATCH 6/9] DSPBRIDGE: Remove DPC, create, destroy and schedule wrappers
>From: Menon, Nishanth
>
>> +/* The DPC object, passed to our priority event callback routine: */
>You may want to follow linux coding style. and not loose info from the
>comments.
>
>Documentation/kernel-doc-nano-HOWTO.txt
This file is removed anyway, I can keep that for later comment cleanups though.
>
>
>> +struct DPC_OBJECT {
>> + u32 dwSignature;/* Used for object validation. */
>> + void *pRefData; /* Argument for client's DPC.*/
>> + DPC_PROC pfnDPC;/* Client's DPC. */
>> + u32 numRequested; /* Number of requested DPC's. */
>> + u32 numScheduled; /* Number of executed DPC's. */
>> + struct tasklet_struct dpc_tasklet;
>[...]
Removed
>> diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
>> index 96a5aa6..60dbc62 100644
>> --- a/drivers/dsp/bridge/wmd/io_sm.c
>> +++ b/drivers/dsp/bridge/wmd/io_sm.c
>> @@ -251,7 +251,26 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
>>
>> if (devType == DSP_UNIT) {
>> /* Create a DPC object: */
>> - status = DPC_Create(&pIOMgr->hDPC, IO_DPC, (void *)pIOMgr);
>> + MEM_AllocObject(pIOMgr->hDPC, struct DPC_OBJECT,
>> + IO_MGRSIGNATURE);
>> + if (pIOMgr->hDPC) {
>> + tasklet_init(&pIOMgr->hDPC->dpc_tasklet,
>> + DPC_DeferredProcedure, (u32)pIOMgr->hDPC);
>> + /* Fill out our DPC Object: */
>> + pIOMgr->hDPC->pRefData = (void *)pIOMgr;
>> + pIOMgr->hDPC->pfnDPC = IO_DPC;
>> + pIOMgr->hDPC->numRequested = 0;
>> + pIOMgr->hDPC->numScheduled = 0;
>> +#ifdef DEBUG
>> + pIOMgr->hDPC->numRequestedMax = 0;
>> + pIOMgr->hDPC->cEntryCount = 0;
>> +#endif
>
>Do you want to do a memset with 0 instead and fill up the deltas?
This was an intermediate step before removing the dpc thing, in the last patch
this looks like
[snip]
+ /* Create an IO DPC */
+ tasklet_init(&pIOMgr->dpc_tasklet, IO_DPC, (u32)pIOMgr);
+
+ /* Initialize DPC counters */
+ pIOMgr->dpc_req = 0;
+ pIOMgr->dpc_sched = 0;
+
+ spin_lock_init(&pIOMgr->dpc_lock);
[snip]
>> +#ifdef DEBUG
>> + if (hIOMgr->hDPC->numRequested >
>> + hIOMgr->hDPC->numScheduled +
>> + hIOMgr->hDPC->numRequestedMax) {
>> + hIOMgr->hDPC->numRequestedMax =
>> + hIOMgr->hDPC->numRequested -
>> + hIOMgr->hDPC->numScheduled;
>a) is this safe?
>b) {} for a one liner ? mebbe the level of indentation is too much?
This was removed.
>
>> + }
>> +#endif
>[...]
>
>> --- a/drivers/dsp/bridge/wmd/ue_deh.c
>> +++ b/drivers/dsp/bridge/wmd/ue_deh.c
>> @@ -91,8 +91,27 @@ DSP_STATUS WMD_DEH_Create(OUT struct DEH_MGR **phDehMgr,
>> status = NTFY_Create(&pDehMgr->hNtfy);
>>
>> /* Create a DPC object. */
>> - status = DPC_Create(&pDehMgr->hMmuFaultDpc, MMU_FaultDpc,
>> - (void *)pDehMgr);
>> + MEM_AllocObject(pDehMgr->hMmuFaultDpc, struct DPC_OBJECT,
>> + SIGNATURE);
>> + if (pDehMgr->hMmuFaultDpc) {
>> + tasklet_init(&pDehMgr->hMmuFaultDpc->dpc_tasklet,
>> + DPC_DeferredProcedure,
>> + (u32)pDehMgr->hMmuFaultDpc);
>> + /* Fill out DPC Object */
>> + pDehMgr->hMmuFaultDpc->pRefData = (void *)pDehMgr;
>> + pDehMgr->hMmuFaultDpc->pfnDPC = MMU_FaultDpc;
>> + pDehMgr->hMmuFaultDpc->numRequested = 0;
>> + pDehMgr->hMmuFaultDpc->numScheduled = 0;
>> +#ifdef DEBUG
>> + pDehMgr->hMmuFaultDpc->numRequestedMax = 0;
>> + pDehMgr->hMmuFaultDpc->cEntryCount = 0;
>> +#endif
>> + spin_lock_init(&pDehMgr->hMmuFaultDpc->dpc_lock);
>> + } else {
>> + DBG_Trace(GT_6CLASS, "DEH DPC Create:
>> DSP_EMEMORY\n");
>> + status = DSP_EMEMORY;
>I think you give up at this point right? why continue the code? wont it
>be easier if your code did:
>if (!pDehMgr->hMmuFaultDpc) {
> DBG_Trace(GT_6CLASS, "DEH DPC Create: DSP_EMEMORY\n");
> return DSP_EMEMORY;
>}
> do rest of code..
>
In the end (patch 9) this looks like:
+ /* Create a MMUfault DPC */
+ tasklet_init(&pDehMgr->dpc_tasklet, MMU_FaultDpc, (u32)pDehMgr);
I tried to split the changes to be cut and paste versions, and then cleani
Re: [RFC] [PATCH] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)
Wednesday 25 November 2009 14:54:47 Janusz Krzysztofik napisał(a):
> Wednesday 25 November 2009 10:02:52 Paul Walmsley napisał(a):
> > On Sat, 21 Nov 2009, Janusz Krzysztofik wrote:
> > >
> > > diff -uprN git.orig/arch/arm/mach-omap1/Makefile
> > > git/arch/arm/mach-omap1/Makefile
> > > --- git.orig/arch/arm/mach-omap1/Makefile 2009-11-21 00:38:45.0
> > > +0100
> > > +++ git/arch/arm/mach-omap1/Makefile 2009-11-21 01:27:12.0
> > > +0100
> > > @@ -3,7 +3,7 @@
> > > #
> > >
> > > # Common support
> > > -obj-y := io.o id.o sram.o clock.o irq.o mux.o serial.o devices.o
> > > +obj-y := io.o id.o sram.o clock.o irq.o lcd_dma.o mux.o serial.o
> > > devices.o
> >
> > It seems that this LCD DMA controller is not present on OMAPs prior to
> > the 1510, given all the references in the LCD DMA code to 1510 and 1610,
> > etc. It might be good to add a Kconfig option so OMAP730/850 users can
> > skip compiling it and save some memory. The drivers that use these
> > routines can then include Kconfig dependencies on that option so it is
> > automatically included when those drivers are built.
>
> OK, will prepare that for next iteration.
Paul,
It turned out not that simple. Since arch/arm/mach-omap1/lcd_dma.c exports
several functions that are called unconditionaly from
drivers/video/omap/lcdc.c AND the latter is linked into the omapfb driver
based on CONFIG_ARCH_OMAP1=y, linking in the former can't be limited to
selected OMAP1 subarchs unless at least drivers/video/omap/{Kconfig,Makefile},
if not drivers/video/omap/lcdc.c itself either, are modified for that as well.
Am I missing something?
If not, I can see two options:
1. Keep arch/arm/mach-omap1/lcd_dma.c linked in for any OMAP1 subarch unless
CONFIG_FB_OMAP is not set. That can be cleaned up further after the
drivers/video/omap/* stuff is ever modified.
2. Include drivers/video/omap/* modifications into this series.
What do you suggest?
Thanks,
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 7/9] DSPBRIDGE: Remove main DPC wrapper for IO and MMUfault
Cosmetic comments follow:
Omar Ramirez Luna had written, on 11/23/2009 06:50 PM, the following:
Remove DeferredProcedure which is used as a wrapper to call
either IO or MMUfault DPCs. This also removes a custom typedef.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/dpc.h | 23
arch/arm/plat-omap/include/dspbridge/io_sm.h |2 +-
drivers/dsp/bridge/services/dpc.c| 36 --
drivers/dsp/bridge/wmd/io_sm.c | 50 -
drivers/dsp/bridge/wmd/mmu_fault.c |2 +-
drivers/dsp/bridge/wmd/mmu_fault.h |2 +-
drivers/dsp/bridge/wmd/ue_deh.c |5 +--
7 files changed, 36 insertions(+), 84 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dpc.h
b/arch/arm/plat-omap/include/dspbridge/dpc.h
index 0c60342..b22140f 100644
--- a/arch/arm/plat-omap/include/dspbridge/dpc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dpc.h
@@ -19,30 +19,10 @@
#ifndef DPC_
#define DPC_
-/*
- * DPC_PROC
- * Purpose:
- * Deferred processing routine. Typically scheduled from an ISR to
- * complete I/O processing.
- * Parameters:
- * pRefData: Ptr to user data: passed in via ISR_ScheduleDPC.
- * Returns:
- * Requires:
- * The DPC should not block, or otherwise acquire resources.
- * Interrupts to the processor are enabled.
- * DPC_PROC executes in a critical section.
- * Ensures:
- * This DPC will not be reenterred on the same thread.
- * However, the DPC may take hardware interrupts during execution.
- * Interrupts to the processor are enabled.
- */
- typedef void(*DPC_PROC) (void *pRefData);
-
/* The DPC object, passed to our priority event callback routine: */
Use kernel coding style
struct DPC_OBJECT {
u32 dwSignature;/* Used for object validation. */
void *pRefData; /* Argument for client's DPC.*/
- DPC_PROC pfnDPC;/* Client's DPC. */
u32 numRequested; /* Number of requested DPC's. */
u32 numScheduled; /* Number of executed DPC's. */
struct tasklet_struct dpc_tasklet;
@@ -81,7 +61,4 @@ struct DPC_OBJECT {
*/
extern bool DPC_Init(void);
-/* --- Function Prototypes */
- void DPC_DeferredProcedure(IN unsigned long pDeferredContext);
-
#endif /* DPC_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/io_sm.h
b/arch/arm/plat-omap/include/dspbridge/io_sm.h
index 77f9e25..67e3834 100644
--- a/arch/arm/plat-omap/include/dspbridge/io_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/io_sm.h
@@ -77,7 +77,7 @@
* Ensures:
* Non-preemptible (but interruptible).
*/
- extern void IO_DPC(IN OUT void *pRefData);
+ extern void IO_DPC(IN OUT unsigned long pRefData);
remove IN OUT
/*
* IO_ISR
diff --git a/drivers/dsp/bridge/services/dpc.c
b/drivers/dsp/bridge/services/dpc.c
index 10bd792..bbb2d47 100644
--- a/drivers/dsp/bridge/services/dpc.c
+++ b/drivers/dsp/bridge/services/dpc.c
@@ -66,39 +66,3 @@ bool DPC_Init(void)
return true;
}
-/*
- * DeferredProcedure
- * Purpose:
- * Main DPC routine. This is called by host OS DPC callback
- * mechanism with interrupts enabled.
- */
-void DPC_DeferredProcedure(IN unsigned long pDeferredContext)
-{
- struct DPC_OBJECT *pDPCObject = (struct DPC_OBJECT *)pDeferredContext;
- /* read numRequested in local variable */
- u32 requested;
- u32 serviced;
-
- DBC_Require(pDPCObject != NULL);
- requested = pDPCObject->numRequested;
- serviced = pDPCObject->numScheduled;
-
- GT_1trace(DPC_DebugMask, GT_ENTER, "> DPC_DeferredProcedure "
- "pDeferredContext=%x\n", pDeferredContext);
- /* Rollover taken care of using != instead of < */
- if (serviced != requested) {
- if (pDPCObject->pfnDPC != NULL) {
- /* Process pending DPC's: */
- do {
- /* Call client's DPC: */
- (*(pDPCObject->pfnDPC))(pDPCObject->pRefData);
- serviced++;
- } while (serviced != requested);
- }
- pDPCObject->numScheduled = requested;
- }
- GT_2trace(DPC_DebugMask, GT_ENTER,
- "< DPC_DeferredProcedure requested %d"
- " serviced %d\n", requested, serviced);
-}
-
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 60dbc62..1e855ce 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -255,10 +255,8 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
IO_MGRSIGNATURE);
if (pIOMgr->hDPC) {
Re: [PATCH 6/9] DSPBRIDGE: Remove DPC, create, destroy and schedule wrappers
Ramirez Luna, Omar had written, on 11/23/2009 06:50 PM, the following:
Remove DPC wrappers and replace with direct Linux calls.
These changes apply to IO DPC and MMUfault DPC
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/dpc.h | 90 +++--
drivers/dsp/bridge/services/dpc.c | 144 +---
drivers/dsp/bridge/wmd/io_sm.c | 73 +-
drivers/dsp/bridge/wmd/mmu_fault.c | 24 -
drivers/dsp/bridge/wmd/ue_deh.c| 31 ++-
5 files changed, 132 insertions(+), 230 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dpc.h
b/arch/arm/plat-omap/include/dspbridge/dpc.h
index 870a1b2..0c60342 100644
--- a/arch/arm/plat-omap/include/dspbridge/dpc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dpc.h
@@ -19,8 +19,6 @@
#ifndef DPC_
#define DPC_
- struct DPC_OBJECT;
-
/*
* DPC_PROC
* Purpose:
@@ -40,64 +38,22 @@
*/
typedef void(*DPC_PROC) (void *pRefData);
-/*
- * DPC_Cancel
- * Purpose:
- * Cancel a DPC previously scheduled by DPC_Schedule.
- * Parameters:
- * hDPC: A DPC object handle created in DPC_Create().
- * Returns:
- * DSP_SOK:Scheduled DPC, if any, is cancelled.
- * DSP_SFALSE: No DPC is currently scheduled for execution.
- * DSP_EHANDLE:Invalid hDPC.
- * Requires:
- * Ensures:
- * If the DPC has already executed, is executing, or was not yet
- * scheduled, this function will have no effect.
- */
- extern DSP_STATUS DPC_Cancel(IN struct DPC_OBJECT *hDPC);
+/* The DPC object, passed to our priority event callback routine: */
You may want to follow linux coding style. and not loose info from the
comments.
Documentation/kernel-doc-nano-HOWTO.txt
[...]
Example kernel-doc function comment:
/**
* foobar() - short function description of foobar
* @arg1: Describe the first argument to foobar.
* @arg2: Describe the second argument to foobar.
* One can provide multiple line descriptions
* for arguments.
*
* A longer description, with more discussion of the function foobar()
* that might be useful to those using or modifying it. Begins with
* empty comment line, and may include additional embedded empty
* comment lines.
*
* The longer description can have multiple paragraphs.
*/
[...]
Example kernel-doc data structure comment.
**
* struct blah - the basic blah structure
* @mem1: describe the first member of struct blah
* @mem2: describe the second member of struct blah,
* perhaps with more lines and words.
*
* Longer description of this structure.
*/
+struct DPC_OBJECT {
+ u32 dwSignature;/* Used for object validation. */
+ void *pRefData; /* Argument for client's DPC.*/
+ DPC_PROC pfnDPC;/* Client's DPC. */
+ u32 numRequested; /* Number of requested DPC's. */
+ u32 numScheduled; /* Number of executed DPC's. */
+ struct tasklet_struct dpc_tasklet;
[...]
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 96a5aa6..60dbc62 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -251,7 +251,26 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
if (devType == DSP_UNIT) {
/* Create a DPC object: */
- status = DPC_Create(&pIOMgr->hDPC, IO_DPC, (void *)pIOMgr);
+ MEM_AllocObject(pIOMgr->hDPC, struct DPC_OBJECT,
+ IO_MGRSIGNATURE);
+ if (pIOMgr->hDPC) {
+ tasklet_init(&pIOMgr->hDPC->dpc_tasklet,
+ DPC_DeferredProcedure, (u32)pIOMgr->hDPC);
+ /* Fill out our DPC Object: */
+ pIOMgr->hDPC->pRefData = (void *)pIOMgr;
+ pIOMgr->hDPC->pfnDPC = IO_DPC;
+ pIOMgr->hDPC->numRequested = 0;
+ pIOMgr->hDPC->numScheduled = 0;
+#ifdef DEBUG
+ pIOMgr->hDPC->numRequestedMax = 0;
+ pIOMgr->hDPC->cEntryCount = 0;
+#endif
Do you want to do a memset with 0 instead and fill up the deltas?
+ spin_lock_init(&pIOMgr->hDPC->dpc_lock);
+ } else {
+ DBG_Trace(GT_6CLASS, "IO DPC Create: DSP_EMEMORY\n");
+ status = DSP_EMEMORY;
+ }
+
if (DSP_SUCCEEDED(status))
status = DEV_GetDevNode(hDevObject, &hDevNode);
@@ -312,8 +331,13 @@ DSP_STATUS WMD_IO_Destroy(struct IO_MGR *hIOMgr)
destroy_workqueue(bridge_workqueue);
/* Linux function to uninstall ISR */
free_irq(INT_MAIL_MPU_IRQ, (void *)hIOMgr);
- if (hIOMgr->hDPC)
- (void)DP
Re: [PATCH 0/9] dspbridge cleanup patches
Ramirez Luna, Omar had written, on 11/25/2009 03:52 PM, the following: From: Menon, Nishanth Subject: Re: [PATCH 0/9] dspbridge cleanup patches 1. http://dev.omapzoom.org/?p=tidspbridge/kernel- dspbridge.git;a=commit;h=b6b7bc5b620596790b2ea26225908b3cf62c36be How about the discussion in http://marc.info/?l=linux-omap&m=123728293826758&w=2 ? same arguments seem valid now.. Opps, sorry about that, seems like I stole/redid your patch Felipe, I'll diff it (to see nothing is missing), fix author and add my signed off. Nishant, I actually removed the history because one of your comments: [snip] + * GPIO Module disable when not in use - Charulatha V + Please stop adding history here.. git commit is supposed to contain it. No stats are generated from looking at file history anymore and there is definitely the risk of getting as big as http://dev.omapzoom.org/?p=tidspbridge/kernel- dspbridge.git;a=blob;f=drivers/dsp/bridge/rmgr/mgr.c;h=943cf932a35b75f 709f 554deb3c51c47088d8b78;hb=refs/heads/dspbridge#l26 [snip] lets not mix things up. GPIO does not come with the legacy burden of 10 years that DSPBridge has. http://marc.info/?l=linux-omap&m=123729745613662&w=2 summarizes my views on DSPBridge. Personally, If any folk mentioned on the removed history disagrees, it is welcome to send a > mail to this mailing list detailing his contributions and I guess someone (me, most likely) >will check on it. For now a line thanking "vp", "rr", "sp" etc. for their initial work will be added to the patch. I doubt if many folks even are there on the linux-omap mailing list.. might be good for us to check OR at least note: Anonymous contributors (vp,vr etc..).. I think this was previously discussed in the chain. 3. http://dev.omapzoom.org/?p=tidspbridge/kernel- dspbridge.git;a=commit;h=b4d73d15bd2b1c7dd1cc89ca9e81a98946ddf241 printk(KERN_ERR ?? why not use the pr_err/warning/info family? My git: drivers/dsp/bridge/rmgr/dbdcd.c | 165 +++- drivers/dsp/bridge/rmgr/disp.c | 254 --- drivers/dsp/bridge/rmgr/drv.c | 399 +++-- drivers/dsp/bridge/rmgr/drv_interface.c | 92 ++--- drivers/dsp/bridge/rmgr/dspdrv.c| 34 +- drivers/dsp/bridge/rmgr/proc.c | 754 ++- drivers/dsp/bridge/rmgr/rmm.c | 46 +-- drivers/dsp/bridge/rmgr/strm.c | 144 +++ 8 files changed, 791 insertions(+), 1097 deletions(-) (now): Removing GT_Trace wrappers and replacing for pr_debug Throughout please.. no more printks.. thanks.. -- 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: [PATCH 2/9] DSPBRIDGE: trivial checkpatch fixes
>From: Menon, Nishanth >Subject: Re: [PATCH 2/9] DSPBRIDGE: trivial checkpatch fixes > >Ramirez Luna, Omar had written, on 11/23/2009 06:50 PM, the following: >> Quick fixes like: >General comment: please do white space changes as a separate patch. this >massive patch is pretty difficult to review otherwise.. might have been >as simple as doing scripts/Lindent on all files and refixing with >scripts/checkpatch.pl .. > >[...] > Will do that... I guess you won't like to read patch 3 ;) as I mixed spacing changes with do while for multiline macros (will split them and resend) - omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] DSPBRIDGE: trivial cleanup and indentation for io_sm
Ramirez Luna, Omar had written, on 11/23/2009 06:50 PM, the following:
Remove duplicate set of braces from if statement and reduce
indentation.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/wmd/io_sm.c | 96 +---
1 files changed, 40 insertions(+), 56 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index af31831..96a5aa6 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
[...]
@@ -1028,29 +1016,28 @@ irqreturn_t IO_ISR(int irq, IN void *pRefData)
/* Call WMD's CHNLSM_ISR() to see if interrupt is ours, and process. */
if (IO_CALLISR(hIOMgr->hWmdContext, &fSchedDPC, &hIOMgr->wIntrVal)) {
- {
- DBG_Trace(DBG_LEVEL3, "IO_ISR %x\n", hIOMgr->wIntrVal);
- if (hIOMgr->wIntrVal & MBX_PM_CLASS) {
- hIOMgr->dQuePowerMbxVal[hIOMgr->iQuePowerHead] =
- hIOMgr->wIntrVal;
- hIOMgr->iQuePowerHead++;
- if (hIOMgr->iQuePowerHead >= MAX_PM_REQS)
- hIOMgr->iQuePowerHead = 0;
-
- queue_work(bridge_workqueue, &hIOMgr->io_workq);
- }
- if (hIOMgr->wIntrVal == MBX_DEH_RESET) {
- DBG_Trace(DBG_LEVEL6, "*** DSP RESET ***\n");
- hIOMgr->wIntrVal = 0;
- } else if (fSchedDPC) {
- /* PROC-COPY defer i/o */
- DPC_Schedule(hIOMgr->hDPC);
- }
+ DBG_Trace(DBG_LEVEL3, "IO_ISR %x\n", hIOMgr->wIntrVal);
+ if (hIOMgr->wIntrVal & MBX_PM_CLASS) {
+ hIOMgr->dQuePowerMbxVal[hIOMgr->iQuePowerHead] =
+ hIOMgr->wIntrVal;
+ hIOMgr->iQuePowerHead++;
+ if (hIOMgr->iQuePowerHead >= MAX_PM_REQS)
+ hIOMgr->iQuePowerHead = 0;
+
+ queue_work(bridge_workqueue, &hIOMgr->io_workq);
+ }
+ if (hIOMgr->wIntrVal == MBX_DEH_RESET) {
+ DBG_Trace(DBG_LEVEL6, "*** DSP RESET ***\n");
+ hIOMgr->wIntrVal = 0;
+ } else if (fSchedDPC) {
+ /* PROC-COPY defer i/o */
+ DPC_Schedule(hIOMgr->hDPC);
}
- } else
+ } else
/* Ensure that, if WMD didn't claim it, the IRQ is shared. */
DBC_Ensure(hIOMgr->fSharedIRQ);
Style comment } else { needed.
--
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: [PATCH 0/9] dspbridge cleanup patches
>From: Menon, Nishanth >Subject: Re: [PATCH 0/9] dspbridge cleanup patches > >> 1. http://dev.omapzoom.org/?p=tidspbridge/kernel- >dspbridge.git;a=commit;h=b6b7bc5b620596790b2ea26225908b3cf62c36be > >How about the discussion in >http://marc.info/?l=linux-omap&m=123728293826758&w=2 ? >same arguments seem valid now.. > Opps, sorry about that, seems like I stole/redid your patch Felipe, I'll diff it (to see nothing is missing), fix author and add my signed off. Nishant, I actually removed the history because one of your comments: [snip] > > + * GPIO Module disable when not in use - Charulatha V > > + > Please stop adding history here.. git commit is supposed to contain > it. No stats are generated from looking at file history anymore and > there is definitely the risk of getting as big as > http://dev.omapzoom.org/?p=tidspbridge/kernel- > dspbridge.git;a=blob;f=drivers/dsp/bridge/rmgr/mgr.c;h=943cf932a35b75f > 709f > 554deb3c51c47088d8b78;hb=refs/heads/dspbridge#l26 [snip] Personally, If any folk mentioned on the removed history disagrees, it is welcome to send a mail to this mailing list detailing his contributions and I guess someone (me, most likely) will check on it. For now a line thanking "vp", "rr", "sp" etc. for their initial work will be added to the patch. >> >> 3. http://dev.omapzoom.org/?p=tidspbridge/kernel- >dspbridge.git;a=commit;h=b4d73d15bd2b1c7dd1cc89ca9e81a98946ddf241 >printk(KERN_ERR ?? why not use the pr_err/warning/info family? > My git: drivers/dsp/bridge/rmgr/dbdcd.c | 165 +++- drivers/dsp/bridge/rmgr/disp.c | 254 --- drivers/dsp/bridge/rmgr/drv.c | 399 +++-- drivers/dsp/bridge/rmgr/drv_interface.c | 92 ++--- drivers/dsp/bridge/rmgr/dspdrv.c| 34 +- drivers/dsp/bridge/rmgr/proc.c | 754 ++- drivers/dsp/bridge/rmgr/rmm.c | 46 +-- drivers/dsp/bridge/rmgr/strm.c | 144 +++ 8 files changed, 791 insertions(+), 1097 deletions(-) (now): Removing GT_Trace wrappers and replacing for pr_debug - omar -- 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 4/9] DSPBRIDGE: Use _IOxx macro to define ioctls
Ramirez Luna, Omar had written, on 11/23/2009 06:50 PM, the following:
Use standard convention to define ioctls.
Currently 'DB' is used as identifier for dspbridge.
*** NOTE: An update in api ioctl definitions is required. ***
Definitely YES ;)
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 142 ++-
drivers/dsp/bridge/pmgr/wcd.c | 116 +--
2 files changed, 117 insertions(+), 141 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
index 397361c..8aaa1ec 100644
--- a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
@@ -391,83 +391,67 @@ union Trapped_Args {
} ARGS_UTIL_TESTDLL;
} ;
-#define CMD_BASE 101
-
-/* MGR module offsets */
-#define CMD_MGR_BASE_OFFSET CMD_BASE
-#define CMD_MGR_ENUMNODE_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 0)
-#define CMD_MGR_ENUMPROC_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 1)
-#define CMD_MGR_REGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 2)
-#define CMD_MGR_UNREGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 3)
-#define CMD_MGR_WAIT_OFFSET (CMD_MGR_BASE_OFFSET + 4)
-
-#ifndef RES_CLEANUP_DISABLE
-#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)
-#define CMD_MGR_END_OFFSET CMD_MGR_RESOUCES_OFFSET
-#else
-#define CMD_MGR_END_OFFSET CMD_MGR_WAIT_OFFSET
-#endif
-
-#define CMD_PROC_BASE_OFFSET (CMD_MGR_END_OFFSET + 1)
-#define CMD_PROC_ATTACH_OFFSET (CMD_PROC_BASE_OFFSET + 0)
-#define CMD_PROC_CTRL_OFFSET (CMD_PROC_BASE_OFFSET + 1)
-#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2)
-#define CMD_PROC_ENUMNODE_OFFSET (CMD_PROC_BASE_OFFSET + 3)
-#define CMD_PROC_ENUMRESOURCES_OFFSET (CMD_PROC_BASE_OFFSET + 4)
-#define CMD_PROC_GETSTATE_OFFSET (CMD_PROC_BASE_OFFSET + 5)
-#define CMD_PROC_GETTRACE_OFFSET (CMD_PROC_BASE_OFFSET + 6)
-#define CMD_PROC_LOAD_OFFSET (CMD_PROC_BASE_OFFSET + 7)
-#define CMD_PROC_REGISTERNOTIFY_OFFSET (CMD_PROC_BASE_OFFSET + 8)
-#define CMD_PROC_START_OFFSET (CMD_PROC_BASE_OFFSET + 9)
-#define CMD_PROC_RSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 10)
-#define CMD_PROC_UNRSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 11)
-#define CMD_PROC_MAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 12)
-#define CMD_PROC_UNMAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 13)
-#define CMD_PROC_FLUSHMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 14)
-#define CMD_PROC_STOP_OFFSET (CMD_PROC_BASE_OFFSET + 15)
-#define CMD_PROC_INVALIDATEMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 16)
-#define CMD_PROC_END_OFFSET CMD_PROC_INVALIDATEMEMORY_OFFSET
-
-
-#define CMD_NODE_BASE_OFFSET (CMD_PROC_END_OFFSET + 1)
-#define CMD_NODE_ALLOCATE_OFFSET (CMD_NODE_BASE_OFFSET + 0)
-#define CMD_NODE_ALLOCMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 1)
-#define CMD_NODE_CHANGEPRIORITY_OFFSET (CMD_NODE_BASE_OFFSET + 2)
-#define CMD_NODE_CONNECT_OFFSET (CMD_NODE_BASE_OFFSET + 3)
-#define CMD_NODE_CREATE_OFFSET (CMD_NODE_BASE_OFFSET + 4)
-#define CMD_NODE_DELETE_OFFSET (CMD_NODE_BASE_OFFSET + 5)
-#define CMD_NODE_FREEMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 6)
-#define CMD_NODE_GETATTR_OFFSET (CMD_NODE_BASE_OFFSET + 7)
-#define CMD_NODE_GETMESSAGE_OFFSET (CMD_NODE_BASE_OFFSET + 8)
-#define CMD_NODE_PAUSE_OFFSET (CMD_NODE_BASE_OFFSET + 9)
-#define CMD_NODE_PUTMESSAGE_OFFSET (CMD_NODE_BASE_OFFSET + 10)
-#define CMD_NODE_REGISTERNOTIFY_OFFSET (CMD_NODE_BASE_OFFSET + 11)
-#define CMD_NODE_RUN_OFFSET (CMD_NODE_BASE_OFFSET + 12)
-#define CMD_NODE_TERMINATE_OFFSET (CMD_NODE_BASE_OFFSET + 13)
-#define CMD_NODE_GETUUIDPROPS_OFFSET(CMD_NODE_BASE_OFFSET + 14)
-#define CMD_NODE_END_OFFSET CMD_NODE_GETUUIDPROPS_OFFSET
-
-#define CMD_STRM_BASE_OFFSET (CMD_NODE_END_OFFSET + 1)
-#define CMD_STRM_ALLOCATEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 0)
-#define CMD_STRM_CLOSE_OFFSET (CMD_STRM_BASE_OFFSET + 1)
-#define CMD_STRM_FREEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 2)
-#define CMD_STRM_GETEVENTHANDLE_OFFSET (CMD_STRM_BASE_OFFSET + 3)
-#define CMD_STRM_GETINFO_OFFSET (CMD_STRM_BASE_OFFSET + 4)
-#define CMD_STRM_IDLE_OFFSET (CMD_STRM_BASE_OFFSET + 5)
-#define CMD_STRM_ISSUE_OFFSET (CMD_STRM_BASE_OFFSET + 6)
-#define CMD_STRM_OPEN_OFFSET (CMD_STRM_BASE_OFFSET + 7)
-#define CMD_STRM_RECLAIM_OFFSET (CMD_STRM_BASE_OFFSET + 8)
-#define CMD_STRM_REGISTERNOTIFY_OFFSET (CMD_STRM_BASE_OFFSET + 9)
-#define CMD_STRM_SELECT_OFFSET (CMD_STRM_BASE_OFFSET + 10)
-#define CMD_STRM_END_OFFSET CMD_STRM_SELECT_OFFSET
-
-/* Communication Memory Manager (UCMM) */
-#define CMD_CMM_BASE_OFFSET (CMD_STRM_END_OFFSET + 1)
-#define CMD_CMM_ALLOCBUF_OFFSET (CMD_CMM_BASE_OFFSET + 0)
-#define CMD_CMM_FREEBUF_OFFSET (CMD_CMM_BASE_OFFSET + 1)
-#define CMD_CMM_GETHANDLE_OFFSET
[PATCH] omap3: rx51: Use wl1251 in SPI mode 3
From: Kalle Valo
Otherwise Extreme Lower Power (ELP) wakeup doesn't work properly.
Signed-off-by: Kalle Valo
---
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4f347f8..e66d728 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -59,7 +59,7 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.bus_num= 4,
.chip_select= 0,
.max_speed_hz = 4800,
- .mode = SPI_MODE_2,
+ .mode = SPI_MODE_3,
.controller_data= &wl1251_mcspi_config,
.platform_data = &wl1251_pdata,
},
--
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/9] DSPBRIDGE: trivial checkpatch fixes
Ramirez Luna, Omar had written, on 11/23/2009 06:50 PM, the following:
Quick fixes like:
General comment: please do white space changes as a separate patch. this
massive patch is pretty difficult to review otherwise.. might have been
as simple as doing scripts/Lindent on all files and refixing with
scripts/checkpatch.pl ..
[...]
diff --git a/arch/arm/plat-omap/include/dspbridge/dbc.h
b/arch/arm/plat-omap/include/dspbridge/dbc.h
index e9cb548..13b1ff6 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbc.h
@@ -36,7 +36,7 @@
#define DBC_Assert(exp) \
if (!(exp)) \
- printk("%s, line %d: Assertion (" #exp ") failed.\n", \
+ printk(KERN_ERR "%s, line %d: Assertion (" #exp ") failed.\n", \
Not in the context of this patch, but we definitely need another series
killing these printks into pr_ family..
__FILE__, __LINE__)
#define DBC_Require DBC_Assert /* Function Precondition. */
#define DBC_Ensure DBC_Assert /* Function Postcondition. */
diff --git a/arch/arm/plat-omap/include/dspbridge/dbdefs.h
b/arch/arm/plat-omap/include/dspbridge/dbdefs.h
index bae19e7..1a7d5fa 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbdefs.h
@@ -21,9 +21,9 @@
#include
-#include /* GPP side type definitions
*/
-#include /* DSP/BIOS type definitions
*/
-#include /* Types shared between GPP and DSP
*/
+#include /* GPP side type definitions */
+#include /* DSP/BIOS type definitions */
+#include /* Types shared between GPP and DSP */
#define PG_SIZE_4K 4096
#define PG_MASK(pg_size) (~((pg_size)-1))
@@ -553,7 +553,7 @@ bit 6 - MMU element size = 64bit (valid only for non mixed
page entries)
#define AUTOSTART "AutoStart" /* Statically load flag */
#define CURRENTCONFIG "CurrentConfig" /* Current resources */
#define SHMSIZE"SHMSize" /* Size of SHM reservd
on MPU */
-#define TCWORDSWAP "TCWordSwap"/* Traffic Contoller Word Swap
*/
+#define TCWORDSWAP "TCWordSwap"/* Traffic Controller WordSwp */
#define DSPRESOURCES "DspTMSResources" /* C55 DSP resurces on OMAP */
#endif /* DBDEFS_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/gt.h
b/arch/arm/plat-omap/include/dspbridge/gt.h
index b43b1e7..c110234 100644
--- a/arch/arm/plat-omap/include/dspbridge/gt.h
+++ b/arch/arm/plat-omap/include/dspbridge/gt.h
@@ -232,7 +232,7 @@ extern struct GT_Config _GT_params;
#define GT_assert(mask, expr) \
(!(expr) ? \
- printk("assertion violation: %s, line %d\n", \
+ printk(KERN_ERR "assertion violation: %s, line %d\n", \
__FILE__, __LINE__), NULL : NULL)
#define GT_config(config) (_GT_params = *(config))
diff --git a/arch/arm/plat-omap/include/dspbridge/io_sm.h
b/arch/arm/plat-omap/include/dspbridge/io_sm.h
index b8f4fb7..77f9e25 100644
--- a/arch/arm/plat-omap/include/dspbridge/io_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/io_sm.h
@@ -291,13 +291,13 @@
extern void IO_IntrDSP2(IN struct IO_MGR *pIOMgr, IN u16 wMbVal);
- extern void IO_SM_init(void);
+ extern void IO_SM_init(void);
/*
* PrintDspTraceBuffer
* Print DSP tracebuffer.
*/
no comments ;)
- extern DSP_STATUS PrintDspTraceBuffer(struct WMD_DEV_CONTEXT
- *hWmdContext);
+ extern DSP_STATUS PrintDspTraceBuffer(struct WMD_DEV_CONTEXT
+ *hWmdContext);
#endif /* IOSM_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
index b213b82..397361c 100644
--- a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
@@ -54,7 +54,7 @@ union Trapped_Args {
} ARGS_MGR_UNREGISTEROBJECT;
struct {
- struct DSP_NOTIFICATION __user*__user *aNotifications;
+ struct DSP_NOTIFICATION __user *__user *aNotifications;
include/linux/compiler.h
# define __user __attribute__((noderef, address_space(1)))
Trying to understand this seemingly interesting double usage of __user
u32 uCount;
u32 __user *puIndex;
u32 uTimeout;
@@ -111,7 +111,7 @@ union Trapped_Args {
struct {
DSP_HPROCESSOR hProcessor;
s32 iArgc;
- char __user*__user *aArgv;
+ char __user *__user *aArgv;
char *__user *aEnvp;
} ARGS_PROC_LOAD;
diff --git a/drivers/dsp/bridge/dynload/reloc.c
b/drivers/dsp/bridge/dynload/reloc.c
index d4457c5..b9e2a9b 100644
--- a/drivers/dsp/bridge/dynload/reloc.c
+++ b/drivers/dsp/bridge/dynload/relo
[PATCH] omap: dss2: Reintroduce Overo display support (DVI/HDMI)
Refreshed version of previous patch from Tomi, so keeping his S-o-b.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Olof Johansson
---
I'm not 100% sure how to wire up the power supplies. I'm still missing
the one required for VENC to work.
Tomi, I also noticed that DSS2 seems a bit fragile; if one subsystem
doesn't initialize properly (VENC in this case), the console doesn't
come up at all. It would be nice if the rest of the console did come up
with what was available.
-Olof
arch/arm/mach-omap2/board-overo.c | 133 -
1 files changed, 117 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 52dfd51..b09dab2 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -40,6 +40,7 @@
#include
#include
+#include
#include
#include
#include
@@ -184,6 +185,120 @@ static inline void __init overo_init_smsc911x(void)
static inline void __init overo_init_smsc911x(void) { return; }
#endif
+/* DSS */
+static int lcd_enabled;
+static int dvi_enabled;
+
+#define OVERO_GPIO_LCD_EN 144
+
+static int overo_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;
+
+ gpio_set_value(OVERO_GPIO_LCD_EN, 1);
+
+ return 0;
+}
+
+static void overo_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(OVERO_GPIO_LCD_EN, 0);
+
+ dvi_enabled = 0;
+}
+
+static struct omap_dss_device overo_dvi_device = {
+ .name = "dvi",
+ .driver_name= "generic_panel",
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .platform_enable= overo_panel_enable_dvi,
+ .platform_disable = overo_panel_disable_dvi,
+};
+
+static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ if (dvi_enabled) {
+ printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+ return -EINVAL;
+ }
+
+ gpio_set_value(OVERO_GPIO_LCD_EN, 1);
+ lcd_enabled = 1;
+ return 0;
+}
+
+static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(OVERO_GPIO_LCD_EN, 0);
+ lcd_enabled = 0;
+}
+
+static struct omap_dss_device overo_lcd_device = {
+ .name = "lcd",
+ .driver_name= "samsung_lte_panel",
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .platform_enable= overo_panel_enable_lcd,
+ .platform_disable = overo_panel_disable_lcd,
+};
+
+static struct omap_dss_device *overo_dss_devices[] = {
+ &overo_dvi_device,
+ &overo_lcd_device,
+};
+
+static struct omap_dss_board_info overo_dss_data = {
+ .num_devices= ARRAY_SIZE(overo_dss_devices),
+ .devices= overo_dss_devices,
+ .default_device = &overo_dvi_device,
+};
+
+static struct platform_device overo_dss_device = {
+ .name = "omapdss",
+ .id = -1,
+ .dev= {
+ .platform_data = &overo_dss_data,
+ },
+};
+
+static struct regulator_consumer_supply overo_vdda_dac_supply = {
+ .supply = "vdda_dac",
+ .dev= &overo_dss_device.dev,
+};
+
+
+static struct regulator_consumer_supply overo_vpll2_supplies[] = {
+ {
+ .supply = "vdvi",
+ .dev= &overo_lcd_device.dev,
+ },
+ {
+ .supply = "vdds_dsi",
+ .dev= &overo_dss_device.dev,
+ }
+};
+
+static struct regulator_init_data overo_vpll2 = {
+ .constraints = {
+ .name = "VDVI",
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(overo_vpll2_supplies),
+ .consumer_supplies = overo_vpll2_supplies,
+};
+
+
static struct mtd_partition overo_nand_partitions[] = {
{
.name = "xloader",
@@ -347,6 +462,7 @@ static struct twl4030_platform_data overo_twldata = {
.usb= &overo_usb_data,
.codec = &overo_codec_data,
.vmmc1 = &overo_vmmc1,
+ .vpll2 = &overo_vpll2,
};
static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
@@ -367,23 +483,8 @@ static int __init overo_i2c_init(void)
return 0;
}
-static struct platform_device ove
Re: [PATCH 0/9] dspbridge cleanup patches
Ramirez Luna, Omar had written, on 11/25/2009 02:49 PM, the following: From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Subject: Re: [PATCH 0/9] dspbridge cleanup patches On Tue, Nov 24, 2009 at 8:54 AM, Artem Bityutskiy wrote: On Mon, 2009-11-23 at 18:50 -0600, Omar Ramirez Luna wrote: DSPBRIDGE: trivial file history cleanup It seems this patch (1/9) didn't reach linux-omap. But looks like it was about time for it :) Yes, it seems patch 1 and 3 were too big, I have them on dspbridge-next (while waiting for comments) 1. http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=b6b7bc5b620596790b2ea26225908b3cf62c36be How about the discussion in http://marc.info/?l=linux-omap&m=123728293826758&w=2 ? same arguments seem valid now.. 3. http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=b4d73d15bd2b1c7dd1cc89ca9e81a98946ddf241 printk(KERN_ERR ?? why not use the pr_err/warning/info family? - omar -- 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 -- 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: [PATCH 0/9] dspbridge cleanup patches
>From: Felipe Contreras [mailto:felipe.contre...@gmail.com] >Subject: Re: [PATCH 0/9] dspbridge cleanup patches > >On Tue, Nov 24, 2009 at 8:54 AM, Artem Bityutskiy wrote: >> On Mon, 2009-11-23 at 18:50 -0600, Omar Ramirez Luna wrote: >>> DSPBRIDGE: trivial file history cleanup > >It seems this patch (1/9) didn't reach linux-omap. But looks like it >was about time for it :) > Yes, it seems patch 1 and 3 were too big, I have them on dspbridge-next (while waiting for comments) 1. http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=b6b7bc5b620596790b2ea26225908b3cf62c36be 3. http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=b4d73d15bd2b1c7dd1cc89ca9e81a98946ddf241 - omar -- 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 02/10 V3] omap3: pm: introduce opp accessor functions
Kevin Hilman had written, on 11/25/2009 10:30 AM, the following: [..] Signed-off-by: Sanjeev Premi Signed-off-by: Kevin Hilman Not yet. :) :) Thanks a bunch for your detailed comments. have provided answers below. I think we are not aligned on the search functions unfortunately. Signed-off-by: Nishanth Menon Some general comments. I think the forcing of an int return code for all the functions is a bit artificial, and is a loss in readability IMHO. I've never liked getting results values in function arguments, and find that style difficult to read. More comments on this for each function below. Alright, will fix. --- arch/arm/plat-omap/Makefile |3 + arch/arm/plat-omap/include/plat/opp.h | 208 ++ arch/arm/plat-omap/opp.c | 260 + I think this should be mach-omap2/opp.c OPP is a concept that is not limited to omap2. it can be implemented for omap1 if desired (they had 2 OPPs - OPP50 and OPP100), it is hence introduced as a common logic across OMAPs in plat-omap. [...] diff --git a/arch/arm/plat-omap/include/plat/opp.h b/arch/arm/plat-omap/include/plat/opp.h new file mode 100644 index 000..d8ae2d3 --- /dev/null +++ b/arch/arm/plat-omap/include/plat/opp.h @@ -0,0 +1,208 @@ [...] +/** + * opp_get_voltage - Gets the voltage corresponding to an opp + * @u_volt: Voltage in microvolts corresponding to an opp + * @opp: opp for which voltage has to be returned for + * + * Return 0 and the voltage in micro volt corresponding to the opp, + * else return the corresponding error value. + */ +int opp_get_voltage(u32 *u_volt, const struct omap_opp *opp); Should just return voltage or -EINVAL int opp_get_voltage(const struct omap_opp *opp); Ack. it cant be int as uVolt is unsigned long. /** * opp_get_voltage - Gets the voltage corresponding to an opp * @opp:opp for which voltage has to be returned for * * Return voltage in micro volt corresponding to the opp, else * return 0 */ unsigned long opp_get_voltage(const struct omap_opp *opp); + +/** + * opp_get_freq - Gets the frequency corresponding to an opp + * @freq:Frequency in hertz corresponding to an opp + * @opp: opp for which frequency has to be returned for + * + * Return 0 and the frequency in hertz corresponding to the opp, + * else return the corresponding error value. + */ +int opp_get_freq(unsigned long *freq, const struct omap_opp *opp); ditto Same as above: /** * opp_get_freq - Gets the frequency corresponding to an opp * @opp:opp for which frequency has to be returned for * * Return frequency in hertz corresponding to the opp, else * return 0 */ unsigned long opp_get_freq(const struct omap_opp *opp); + +/** + * opp_is_valid - Verifies if a given frequency is enabled in the opp list + * @opp: Pointer to opp returned if opp match is achieved + * @oppl:opp list + * @freq:Frequency in hertz to check for + * + * Searches the OPP list to find if the provided frequency is an enabled + * frequency. If a match is achieved, it returns 0 and the pointer to the opp + * is returned, else a corresponding error value is returned. + */ +int opp_is_valid(struct omap_opp **opp, const struct omap_opp *oppl, + const unsigned long freq); + +/** + * opp_has_freq - Checks if a frequency is exists(enabled/disabled) in opp list + * @opp: Pointer to opp returned if opp match is achieved + * @oppl:opp list + * @freq:Frequency in hertz to check for + * + * Searches the OPP list to find a frequency. This is a more generic function + * than the opp_is_valid since it searches for both enabled/disabled + * frequencies. + * + * This function may be used by detection logic to enable a disabled OPP as + * all other search functions work on enabled OPPs only. + */ +int opp_has_freq(struct omap_opp **opp, const struct omap_opp *oppl, + const unsigned long freq); Don't see any users of this, and it looks like the same functionality as opp_is_valid(). Both of these are just a "find opp by freq". How about having something like this instead: /** * opp_find_freq() * @oppl:OPP list * @freq:Frequency to look for in OPP table * * Look for an enabled OPP with a frequency value matching @freq. * * Returns pointer to OPP entry if match is found, or NULL if no match * found. */ struct omap_opp *opp_find_freq(const struct omap_opp *oppl, u32 freq); I did think about it(single function doing multiple things), the intention is as follows in reality: opp_is_valid : Search only for enabled frequencies opp_has_freq : Searches for enabled/disabled frequencies This is useful for some logic which wants to enable a frequency which may have been disabled in the table. now, to retain that functionality, A) /** * opp_find_freq() - Find a opp corresponding to frequency * @oppl: opp list to search * @freq: frequency to loopup in OPP table * @en
Re: DSS2 panel question
On Wed, Nov 25, 2009 at 7:44 PM, TAO HU wrote:
> Hi, Grazvydas Ignotas
>
> What did you mean "Hm, omap_dss_register_device() takes omap_dss_driver"?
Whoops, I meant omap_dss_register_driver()
> Below is what I saw from the code
> int omap_dss_register_device(struct omap_dss_device *dssdev)
>
> I assume the code I have is for DSS. Does DSS2 change the API?
I was referring to version that is being submitted to mainline, and
panel drivers in particular, like:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=drivers/video/omap2/displays/panel-generic.c;h=eb48d1afd8008437458bb3fe87e351b5ce785c42;hb=HEAD
> BTW, what's the location for DSS2 code in linux-omap tree? Seems not
> see it anywhere
Tony is probably waiting for it to reach mainline and fall from there.
>
> - Hu Tao
>
>
> On Wed, Nov 25, 2009 at 6:53 PM, Grazvydas Ignotas wrote:
>> On Mon, Nov 23, 2009 at 7:41 PM, TAO HU wrote:
>>> Hi,
>>>
>>> One idea as below
>>>
>>> struct spi_dss_device {
>>> struct omap_dss_device dss_dev;
>>> struct spi_dss_dev_priv * spi_data;
>>> } spi_dss_dev;
>>
>> Hm, omap_dss_register_device() takes omap_dss_driver, not
>> omap_dss_device. Anyway that wouldn't work if there were 2 instances
>> of same panel in one system I guess, as 2 different spi_data instances
>> would probe, when there is only one omap_dss_driver.
>>
>> Instead I'm thinking to link omap_dss_device with spi in board file
>> itself by (ab)using platform_data:
>>
>> static struct omap_dss_device pandora_lcd_device = {
>> ...
>> };
>>
>> struct spi_board_info pandora_spi_board_info = {
>> .bus_num = 1,
>> ...
>> .platform_data = pandora_lcd_device,
>> };
>>
>> Then in panel driver:
>>
>> int spi_probe(struct spi_device *spi)
>> {
>> struct omap_dss_device *dssdev = spi->dev.platform_data;
>> dev_set_drvdata(&dssdev->dev, spi);
>> }
>>
>> static int lcd_probe(struct omap_dss_device *dssdev)
>> {
>> struct spi_device *spi = dev_get_drvdata(&dssdev->dev);
>> }
>>
>> Tomi, does that look reasonable to you?
>>
>
--
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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
Anuj Aggarwal wrote:
> System hang is observed While trying to do suspend. It was because
> of an infinite loop in the AIC23 resume path which was trying to
> restore AIC23 register values from the register cache.
>
> This patch fixes the problem by correcting the resume path and
> properly activating/deactivating the digital interface while
> doing the suspend / off transitions.
>
> Signed-off-by: Anuj Aggarwal
> ---
> sound/soc/codecs/tlv320aic23.c | 16 +++-
> 1 files changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/sound/soc/codecs/tlv320aic23.c b/sound/soc/codecs/tlv320aic23.c
> index 6b24d8b..cabe60c 100644
> --- a/sound/soc/codecs/tlv320aic23.c
> +++ b/sound/soc/codecs/tlv320aic23.c
> @@ -565,13 +565,12 @@ static int tlv320aic23_set_bias_level(struct
> snd_soc_codec *codec,
> case SND_SOC_BIAS_PREPARE:
> break;
> case SND_SOC_BIAS_STANDBY:
> - /* everything off except vref/vmid, */
> - tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
> + /* Activate the digital interface */
> + tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
> break;
> case SND_SOC_BIAS_OFF:
> - /* everything off, dac mute, inactive */
> + /* Deactivate the digital interface */
> tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
> - tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
> break;
> }
> codec->bias_level = level;
> @@ -615,7 +614,6 @@ static int tlv320aic23_suspend(struct platform_device
> *pdev,
> struct snd_soc_device *socdev = platform_get_drvdata(pdev);
> struct snd_soc_codec *codec = socdev->card->codec;
>
> - tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
> tlv320aic23_set_bias_level(codec, SND_SOC_BIAS_OFF);
>
> return 0;
> @@ -625,14 +623,6 @@ static int tlv320aic23_resume(struct platform_device
> *pdev)
> {
> struct snd_soc_device *socdev = platform_get_drvdata(pdev);
> struct snd_soc_codec *codec = socdev->card->codec;
> - int i;
> - u16 reg;
> -
> - /* Sync reg_cache with the hardware */
> - for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); i++) {
> - u16 val = tlv320aic23_read_reg_cache(codec, reg);
> - tlv320aic23_write(codec, reg, val);
> - }
Changing to
for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); reg++) {
should be enough to fix the infinite loop.
Could you try this without the rest of the patch?
>
> tlv320aic23_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
> tlv320aic23_set_bias_level(codec, codec->suspend_bias_level);
Adding Arun to cc list
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/9] DSPBRIDGE: trivial cleanup and indentation for io_sm
>From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
>Subject: Re: [PATCH 5/9] DSPBRIDGE: trivial cleanup and indentation for io_sm
>
>On Tue, Nov 24, 2009 at 01:50:26AM +0100, ext Omar Ramirez Luna wrote:
>>Remove duplicate set of braces from if statement and reduce
>>indentation.
>>
>>Signed-off-by: Omar Ramirez Luna
>>---
>> drivers/dsp/bridge/wmd/io_sm.c | 96
>> +---
>> 1 files changed, 40 insertions(+), 56 deletions(-)
>>
>>diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
>>index af31831..96a5aa6 100644
>>--- a/drivers/dsp/bridge/wmd/io_sm.c
>>+++ b/drivers/dsp/bridge/wmd/io_sm.c
>>@@ -115,7 +115,7 @@ struct IO_MGR {
>> /* private extnd proc info; mmu setup */
>> struct MGR_PROCESSOREXTINFO extProcInfo;
>> struct CMM_OBJECT *hCmmMgr; /* Shared Mem Mngr*/
>>- struct work_struct io_workq; /*workqueue */
>>+ struct work_struct io_workq; /*workqueue */
>
>while at that: /* workqueue */
>
>add the missing space.
Agree.
>
>> u32 dQuePowerMbxVal[MAX_PM_REQS];
>> u32 iQuePowerHead;
>> u32 iQuePowerTail;
>>@@ -185,7 +185,7 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
>> struct CFG_HOSTRES hostRes;
>> struct CFG_DEVNODE *hDevNode;
>> struct CHNL_MGR *hChnlMgr;
>>- static int ref_count;
>>+ static int ref_count;
>> u32 devType;
>> /* Check requirements: */
>> if (!phIOMgr || !pMgrAttrs || pMgrAttrs->uWordSize == 0) {
>>@@ -197,9 +197,10 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
>> status = DSP_EHANDLE;
>> goto func_end;
>> }
>>- /* Message manager will be created when a file is loaded, since
>>+ /* Message manager will be created when a file is loaded, since
>> * size of message buffer in shared memory is configurable in
>>- * the base image. */
>>+ * the base image.
>>+ */
>
>same here... it should be:
>
>/* multi-line comment start here and has only one
> * space after the * character.
> * If you could remove the extra space above would
> * be nice.
> */
>
Agree.
- omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/9] DSPBRIDGE: Remove DPC, create, destroy and schedule wrappers
>From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
>Subject: Re: [PATCH 6/9] DSPBRIDGE: Remove DPC, create, destroy and schedule
>wrappers
>
>Hi,
>
>On Tue, Nov 24, 2009 at 01:50:27AM +0100, ext Omar Ramirez Luna wrote:
>>+/* The DPC object, passed to our priority event callback routine: */
>>+struct DPC_OBJECT {
>>+ u32 dwSignature;/* Used for object validation. */
>>+ void *pRefData; /* Argument for client's DPC.*/
>>+ DPC_PROC pfnDPC;/* Client's DPC. */
>>+ u32 numRequested; /* Number of requested DPC's. */
>>+ u32 numScheduled; /* Number of executed DPC's. */
>>+ struct tasklet_struct dpc_tasklet;
>
>as a suggestion for upcoming patches... how about removing the variable
>types from its name and get rid of CaMeLcAsE ?
>
>I mean:
>
>- u32 dwSignature;
>+ u32 signature;
Done for patch DSPBRIDGE: Remove DPC object structure, I removed the structure
because it was used only for IO and MMUfault (in future for WDT too), besides
not every field were used anyway.
@@ -128,6 +126,12 @@ struct IO_MGR {
u32 ulGppVa;
u32 ulDspVa;
#endif
+ /* IO Dpc */
+ u32 dpc_req;/* Number of requested DPC's. */
+ u32 dpc_sched; /* Number of executed DPC's. */
+ struct tasklet_struct dpc_tasklet;
+ spinlock_t dpc_lock;
+
} ;
- omar
--
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] ASoC: AM3517: Fix AIC23 suspend/resume hang
On Thu, Nov 26, 2009 at 12:49:11AM +0530, Aggarwal, Anuj wrote:
>
> int i;
> u16 reg;
>
> /* Sync reg_cache with the hardware */
> for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); i++) {
> u16 val = tlv320aic23_read_reg_cache(codec, reg);
> tlv320aic23_write(codec, reg, val);
> }
>
> I can see 'i' getting incremented, instead of 'reg'. Isn't this an
> infinite loop?
Yes, that does look entirely buggy - it seems fairly clear that suspend
and resume have never worked with this driver. The fact that you were
removing the loop entirely meant I didn't read the actual code for bugs.
> > > This patch fixes the problem by correcting the resume path and
> > > properly activating/deactivating the digital interface while
> > > doing the suspend / off transitions.
> > What do you mean by "properly activating/deactivating the digital
> > interface"?
> [Aggarwal, Anuj] The driver was only deactivating the digital
> interface and not activating it. Hence added that part.
So this is a separate issue, and should ideally be a separate patch - it
looks like you've got three different changes here, one to fix the buggy
register cache restore, one to manage the PWR bit on suspend and another
to possibly fix the bias configuration. You certainly need to identify
all three changes in the changelog, especially for things like this
which look like they should go in as bug fixes (and bearing in mind that
it's the end of the release cycle).
Glancing at the code there's much more management required here -
there's other places where it's managed and the code needs to be joined
up with them. The setting should only be restored if the device was
active when suspended, not unconditionally.
> > > case SND_SOC_BIAS_STANDBY:
> > > - /* everything off except vref/vmid, */
> > > - tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
> > > + /* Activate the digital interface */
> > > + tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
> > > break;
> > > case SND_SOC_BIAS_OFF:
> > > - /* everything off, dac mute, inactive */
> > > + /* Deactivate the digital interface */
> > > tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
> > > - tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
> > > break;
> >
> > This looks wrong - the driver is now no longer managing bias levels at
> > all.
> [Aggarwal, Anuj] The bias levels were wrongly managed earlier. While doing
> a suspend, it was powering off all the interfaces and while coming up, it
> was not switching on the required interfaces. Hence no sound was coming
> out if audio was played back.
Note that this CODEC driver impelements DAPM and so all the bits in the
power register which are controlled by DAPM will be managed by the ASoC
core without any action by the driver.
> On each bias level, which are the interfaces which need to be switched
> on / off?
The biases and any other device-wide settings, everything else should be
managed via DAPM if it's in use.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] DSPBRIDGE: Remove DPC, create, destroy and schedule wrappers
Hi,
On Tue, Nov 24, 2009 at 01:50:27AM +0100, ext Omar Ramirez Luna wrote:
+/* The DPC object, passed to our priority event callback routine: */
+struct DPC_OBJECT {
+ u32 dwSignature;/* Used for object validation. */
+ void *pRefData; /* Argument for client's DPC.*/
+ DPC_PROC pfnDPC;/* Client's DPC. */
+ u32 numRequested; /* Number of requested DPC's. */
+ u32 numScheduled; /* Number of executed DPC's. */
+ struct tasklet_struct dpc_tasklet;
as a suggestion for upcoming patches... how about removing the variable
types from its name and get rid of CaMeLcAsE ?
I mean:
- u32 dwSignature;
+ u32 signature;
--
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: [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Wednesday, November 25, 2009 7:04 PM
> To: Aggarwal, Anuj
> Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
> Subject: Re: [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
>
> On Wed, Nov 25, 2009 at 06:40:31PM +0530, Anuj Aggarwal wrote:
>
> > System hang is observed While trying to do suspend. It was because
> > of an infinite loop in the AIC23 resume path which was trying to
> > restore AIC23 register values from the register cache.
>
> This doesn't appear to tie in with the actual patch - where's the
> infinite loop? The register cache restore loop has a constant bound and
> I can't see anything that would make it spin infinitely.
[Aggarwal, Anuj] Here is the original code:
int i;
u16 reg;
/* Sync reg_cache with the hardware */
for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); i++) {
u16 val = tlv320aic23_read_reg_cache(codec, reg);
tlv320aic23_write(codec, reg, val);
}
I can see 'i' getting incremented, instead of 'reg'. Isn't this an
infinite loop?
>
> > This patch fixes the problem by correcting the resume path and
> > properly activating/deactivating the digital interface while
> > doing the suspend / off transitions.
>
> What do you mean by "properly activating/deactivating the digital
> interface"?
[Aggarwal, Anuj] The driver was only deactivating the digital
interface and not activating it. Hence added that part.
>
> > case SND_SOC_BIAS_STANDBY:
> > - /* everything off except vref/vmid, */
> > - tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
> > + /* Activate the digital interface */
> > + tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
> > break;
> > case SND_SOC_BIAS_OFF:
> > - /* everything off, dac mute, inactive */
> > + /* Deactivate the digital interface */
> > tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
> > - tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
> > break;
>
> This looks wrong - the driver is now no longer managing bias levels at
> all.
[Aggarwal, Anuj] The bias levels were wrongly managed earlier. While doing
a suspend, it was powering off all the interfaces and while coming up, it
was not switching on the required interfaces. Hence no sound was coming
out if audio was played back.
Moreover, I referred twl4030 codec and there also the driver was only
handling the codec power control bit in _STANDBY. So based my patch
on that.
On each bias level, which are the interfaces which need to be switched
on / off?
>
> > - u16 reg;
> > -
> > - /* Sync reg_cache with the hardware */
> > - for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); i++) {
> > - u16 val = tlv320aic23_read_reg_cache(codec, reg);
> > - tlv320aic23_write(codec, reg, val);
> > - }
>
> This also looks wrong, the register cache restore has been completely
> removed so if the power to the device is cut during suspend then the
> device will go back to register defaults and no longer function
> correctly after resume.
[Aggarwal, Anuj] I can add that register cache restore again with the
necessary checks.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] DSPBRIDGE: trivial cleanup and indentation for io_sm
On Tue, Nov 24, 2009 at 01:50:26AM +0100, ext Omar Ramirez Luna wrote:
Remove duplicate set of braces from if statement and reduce
indentation.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/wmd/io_sm.c | 96 +---
1 files changed, 40 insertions(+), 56 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index af31831..96a5aa6 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -115,7 +115,7 @@ struct IO_MGR {
/* private extnd proc info; mmu setup */
struct MGR_PROCESSOREXTINFO extProcInfo;
struct CMM_OBJECT *hCmmMgr; /* Shared Mem Mngr*/
- struct work_struct io_workq; /*workqueue */
+ struct work_struct io_workq; /*workqueue */
while at that: /* workqueue */
add the missing space.
u32 dQuePowerMbxVal[MAX_PM_REQS];
u32 iQuePowerHead;
u32 iQuePowerTail;
@@ -185,7 +185,7 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
struct CFG_HOSTRES hostRes;
struct CFG_DEVNODE *hDevNode;
struct CHNL_MGR *hChnlMgr;
- static int ref_count;
+ static int ref_count;
u32 devType;
/* Check requirements: */
if (!phIOMgr || !pMgrAttrs || pMgrAttrs->uWordSize == 0) {
@@ -197,9 +197,10 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
status = DSP_EHANDLE;
goto func_end;
}
-/* Message manager will be created when a file is loaded, since
+ /* Message manager will be created when a file is loaded, since
* size of message buffer in shared memory is configurable in
-* the base image. */
+* the base image.
+*/
same here... it should be:
/* multi-line comment start here and has only one
* space after the * character.
* If you could remove the extra space above would
* be nice.
*/
--
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] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)
On Wed, 25 Nov 2009, Janusz Krzysztofik wrote: > Thanks for your review time. Thank you for doing this work :-) > Since I started with just duplicating files and then removing unnecessary > sections, I wondered how I could split that work into several subsequent > patches so it is more easy to verify how those chunks put into a new file > differ from those extracted from the old one, but didn't find a good solution > yet. Looking through the code, you've cleaned up several things that indicate that you've put some thought and care into doing it (e.g., all the cpu_class_is_omap1(), for example). Plus, you mention that you've tested the code on OMAP1 and compile-tested on OMAP2. So it seems fine to me after those two minor changes are made that I mentioned in the last E-mail. - 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] usb: ehci-omap: Update platform header file path
* Olof Johansson [091125 01:13]: > On Wed, Nov 25, 2009 at 02:35:56PM +0530, Gadiyar, Anand wrote: > > Olof Johansson wrote: > > > > > > The OMAP usb header file has moved, update the driver so it > > > will build. > > > > > > Signed-off-by: Olof Johansson > > > > > > --- > > > > > > Greg, any chance you can just ack this so Tony can merge it through his > > > tree for .33? The header files changes in question are going in through > > > that tree. > > > > > > > I believe it has already been taken care of in Tony's for-next? > > Oh, weird. Looking at the history of the file on git.kernel.org: > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=history;f=drivers/usb/host/ehci-omap.c;hb=HEAD > > It shows Tony making the change on Oct 30, and then 4 fresh merges of > the driver? That's odd. Yeah those duplicate commits happen when we rebuild the linux-omap tree on a new -rc. That's when all the development and testing branches get merged back in again. To keep the linux-omap tree pullable all the time, we rebuild the linux-omap tree periodically with something like this: $ git checkout -b tmp-rebuild-1258915893 linus $ git merge -m "Merge omap-testing" omap-testing $ git merge -m "Merge for-next" for-next $ git merge -m "Merge cbus" cbus $ git merge -s ours master $ git checkout master $ git merge tmp-rebuild-1258915893 What I've queued up is in for-next branch, omap-testing and cbus are just development branches that may get rebased as needed. And master branch is what people are using for omap to test things, and that stays pullable. As we currently carry the ehci-omap patch in omap-testing branch, it shows up as a merge every time we rebuild. These duplicate commits will disappear once the echi-omap gets merged to Linus' tree. 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: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
Tony Lindgren writes: > * Olof Johansson [091124 23:05]: >> G, Manjunath Kondaiah wrote: >> >>>You should allow both of them to be enabled at the same time, so the >> >>>same >> >>>kernel can for example be booted on a ZOOM2 with debug board >> >>>attached >> >>>(8250 on GPMC), or on a beagle/overo board. >> >>> >> >>>Making them exclusive would be a step backwards. >> >>More so, selecting both config option really shouldn't break the >> >>build. If one expect a build break because only one of the >> >>options can be enabled then clearly the dependency should be >> >>used so that user can select only one option at a time. >> > >> >Ack. There should be dependency in Kconfig so that user can select >> >either 8250 console(through Quad-uart for zoom2/zoom3) or OMAP-serial >> >Console(through OMAP UART's). >> >> No. The drivers MUST handle co-existing. You can have a bunch of >> drivers configured to be _potential_ consoles, which one will end up >> being used depends on, among other things, the bootargs. But it >> should be allowed to configure both 8250 and omap-serial at the same >> time. > > Exactly. Even the same board must be capable of using 8250 and > omap-serial. That's why it must be called ttyO instead of ttyS. I completely agree with the need for these drivers to co-exist and for a given board to use both drivers. For example, Zoom2 would want to use omap-serial for the on-chip UARTs, and 8250 for the external UART used for the console. In my review I complained about using ttyO instead of ttyS, but now I see more clearly the reason for that. 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] usb: ehci-omap: Update platform header file path
* Greg KH [091125 05:06]: > On Wed, Nov 25, 2009 at 03:02:59AM -0600, Olof Johansson wrote: > > The OMAP usb header file has moved, update the driver so it will build. > > > > Signed-off-by: Olof Johansson > > > > --- > > > > Greg, any chance you can just ack this so Tony can merge it through his > > tree for .33? The header files changes in question are going in through > > that tree. > > Sure, but for such a trivial change, I doubt you need my ack :) > > Acked-by: Greg Kroah-Hartman The ehci-omap.c driver should be in Greg's queue. I only have the the related platform init code and header changes in my for-next because of the omap header move from mach to plat. IMHO, this fix would be best added to Greg's queue as the ehci-omap.c driver is there [1]. Or just merged into the exisiting patch to keep git bisect working: Acked-by: Tony Lindgren Meanwhile, I'll also add this fix to omap-testing and master branches so people can use it until it gets merged. Regards, Tony [1] http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/usb/usb-host-ehci-introduce-omap-ehci-hcd-driver.patch -- 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 06/10 V3] omap3: pm: use opp accessor functions for omap-target
Nishanth Menon writes:
> The logic in omap-target can now be improved with the accessor
> functions. Dont scan through the list manually, instead use
> get_next_freq to do the scanning.
>
> Cc: Benoit Cousson
> Cc: Kevin Hilman
> Cc: Madhusudhan Chikkature Rajashekar
> Cc: Paul Walmsley
> Cc: Romit Dasgupta
> Cc: Sanjeev Premi
> Cc: Santosh Shilimkar
> Cc: Sergio Alberto Aguirre Rodriguez
> Cc: Thara Gopinath
> Cc: Vishwanath Sripathy
>
> Signed-off-by: Nishanth Menon
> ---
> arch/arm/plat-omap/cpu-omap.c | 19 +++
> 1 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
> index 449b6b6..7b3ca11 100644
> --- a/arch/arm/plat-omap/cpu-omap.c
> +++ b/arch/arm/plat-omap/cpu-omap.c
> @@ -111,14 +111,17 @@ static int omap_target(struct cpufreq_policy *policy,
> cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> #elif defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
> if (mpu_opps) {
> - int ind;
> - for (ind = 1; ind <= MAX_VDD1_OPP; ind++) {
> - if (mpu_opps[ind].rate/1000 >= target_freq) {
> - omap_pm_cpu_set_freq
> - (mpu_opps[ind].rate);
> - break;
> - }
> - }
> + unsigned long freq = target_freq * 1000;
> + struct omap_opp *opp = NULL;
> + int res;
> + /* see if we have exact freq match */
> + res = opp_is_valid(&opp, mpu_opps, freq);
> + /* Get next best if we cant find a exact match */
> + if (res)
> + res = opp_get_higher_opp(&opp, &freq, mpu_opps);
These two could just be replaced by a single call to
opp_find_freq_rounding()
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: DSS2 panel question
Hi, Grazvydas Ignotas
What did you mean "Hm, omap_dss_register_device() takes omap_dss_driver"?
Below is what I saw from the code
int omap_dss_register_device(struct omap_dss_device *dssdev)
I assume the code I have is for DSS. Does DSS2 change the API?
BTW, what's the location for DSS2 code in linux-omap tree? Seems not
see it anywhere
- Hu Tao
On Wed, Nov 25, 2009 at 6:53 PM, Grazvydas Ignotas wrote:
> On Mon, Nov 23, 2009 at 7:41 PM, TAO HU wrote:
>> Hi,
>>
>> One idea as below
>>
>> struct spi_dss_device {
>> struct omap_dss_device dss_dev;
>> struct spi_dss_dev_priv * spi_data;
>> } spi_dss_dev;
>
> Hm, omap_dss_register_device() takes omap_dss_driver, not
> omap_dss_device. Anyway that wouldn't work if there were 2 instances
> of same panel in one system I guess, as 2 different spi_data instances
> would probe, when there is only one omap_dss_driver.
>
> Instead I'm thinking to link omap_dss_device with spi in board file
> itself by (ab)using platform_data:
>
> static struct omap_dss_device pandora_lcd_device = {
> ...
> };
>
> struct spi_board_info pandora_spi_board_info = {
> .bus_num = 1,
> ...
> .platform_data = pandora_lcd_device,
> };
>
> Then in panel driver:
>
> int spi_probe(struct spi_device *spi)
> {
> struct omap_dss_device *dssdev = spi->dev.platform_data;
> dev_set_drvdata(&dssdev->dev, spi);
> }
>
> static int lcd_probe(struct omap_dss_device *dssdev)
> {
> struct spi_device *spi = dev_get_drvdata(&dssdev->dev);
> }
>
> Tomi, does that look reasonable to you?
>
--
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: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
* Olof Johansson [091124 23:05]: > G, Manjunath Kondaiah wrote: > >>>You should allow both of them to be enabled at the same time, so the > >>>same > >>>kernel can for example be booted on a ZOOM2 with debug board > >>>attached > >>>(8250 on GPMC), or on a beagle/overo board. > >>> > >>>Making them exclusive would be a step backwards. > >>More so, selecting both config option really shouldn't break the > >>build. If one expect a build break because only one of the > >>options can be enabled then clearly the dependency should be > >>used so that user can select only one option at a time. > > > >Ack. There should be dependency in Kconfig so that user can select > >either 8250 console(through Quad-uart for zoom2/zoom3) or OMAP-serial > >Console(through OMAP UART's). > > No. The drivers MUST handle co-existing. You can have a bunch of > drivers configured to be _potential_ consoles, which one will end up > being used depends on, among other things, the bootargs. But it > should be allowed to configure both 8250 and omap-serial at the same > time. Exactly. Even the same board must be capable of using 8250 and omap-serial. That's why it must be called ttyO instead of ttyS. The 8250 drivers are often needed for hotpluggable buses. 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: OMAP3: enabling CPU idle leads to panic
Sergey Lapin writes: > On Tue, Nov 24, 2009 at 11:21 PM, Premi, Sanjeev wrote: >> From: Kevin Hilman [khil...@deeprootsystems.com] >> Sent: Tuesday, November 24, 2009 11:57 PM >> To: Sergey Lapin; Premi, Sanjeev >> Cc: linux-omap@vger.kernel.org >> Subject: Re: OMAP3: enabling CPU idle leads to panic >> >> Sergey Lapin writes: >> >>> I use PM branch merged with linux-omap branch. >> >> Not sure what this means. PM branch is already based at linux-omap >> master branch. You'll need to be more specific, ideally with commit >> IDs. > > I do git branch tmp origin/master > git checkout -f tmp > git merge origin/pm The pm branch is already based on l-o master, but perhaps not the very latest. Instead of the above can you just do git branch tmp origin/pm git checkout -f tmp > git merge origin/mybranch It might if you base your 'mybranch' at the same merge point that the pm branch is based at. You can find the merge point using: git merge-base origin/master origin/pm 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 0/9] dspbridge cleanup patches
On Tue, Nov 24, 2009 at 8:54 AM, Artem Bityutskiy wrote: > On Mon, 2009-11-23 at 18:50 -0600, Omar Ramirez Luna wrote: >> DSPBRIDGE: trivial file history cleanup It seems this patch (1/9) didn't reach linux-omap. But looks like it was about time for it :) > Look like good clean-ups to me! Although I did not look at the patches > very carefully, just briefly walked through. > > I think if you keep doing this, we could add dspbrige to -staging even! Yay! -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10 V3] omap3: pm: use opp accessor functions for omap34xx
Kevin Hilman writes: [...] > I've attached a patch that applies on top of your series Forgot the patch. Here it is. Kevin commit 2979ad2ad596618e179f1292e6e7e37d55830096 Author: Kevin Hilman Date: Wed Nov 25 09:12:17 2009 -0800 OMAP3: PM: remove OPP interfaces from OMAP PM layer diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 91bcfbf..e2f44ec 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -319,7 +319,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0, /* The OPP tables have to be registered before a clk init */ omap_hwmod_init(hwmods); omap2_mux_init(); - omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps); + omap_pm_if_early_init(); pwrdm_init(powerdomains_omap); clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps); omap2_clk_init(); diff --git a/arch/arm/mach-omap2/resource34xx.h b/arch/arm/mach-omap2/resource34xx.h index b6f31a9..0b4e76e 100644 --- a/arch/arm/mach-omap2/resource34xx.h +++ b/arch/arm/mach-omap2/resource34xx.h @@ -27,7 +27,7 @@ #include #include #include -#include +#include #include extern int sr_voltagescale_vcbypass(u32 t_opp, u32 c_opp, u8 t_vsel, u8 c_vsel); diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 6f8b7cc..c399aea 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -30,7 +30,7 @@ #include #include #include -#include +#include #include "prm.h" #include "smartreflex.h" diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 7b3ca11..29e4826 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -32,6 +32,7 @@ #if defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE) #include +#include #endif #define VERY_HI_RATE 9 diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-omap/include/plat/omap-pm.h index aa36339..bdc11f2 100644 --- a/arch/arm/plat-omap/include/plat/omap-pm.h +++ b/arch/arm/plat-omap/include/plat/omap-pm.h @@ -20,10 +20,6 @@ #include "powerdomain.h" #include -extern struct omap_opp *mpu_opps; -extern struct omap_opp *dsp_opps; -extern struct omap_opp *l3_opps; - /* * agent_id values for use with omap_pm_set_min_bus_tput(): * @@ -46,11 +42,9 @@ extern struct omap_opp *l3_opps; * PM idle-loop code. */ #ifdef CONFIG_OMAP_PM_NONE -#define omap_pm_if_early_init(a, b, c) 0 +#define omap_pm_if_early_init() 0 #else -int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table, -struct omap_opp *dsp_opp_table, -struct omap_opp *l3_opp_table); +int __init omap_pm_if_early_init(void); #endif /** @@ -197,68 +191,6 @@ void omap_pm_set_max_dev_wakeup_lat(struct device *dev, long t); */ void omap_pm_set_max_sdma_lat(struct device *dev, long t); - -/* - * DSP Bridge-specific constraints - */ - -/** - * omap_pm_dsp_get_opp_table - get OPP->DSP clock frequency table - * - * Intended for use by DSPBridge. Returns an array of OPP->DSP clock - * frequency entries. The final item in the array should have .rate = - * .opp_id = 0. - */ -const struct omap_opp *omap_pm_dsp_get_opp_table(void); - -/** - * omap_pm_dsp_set_min_opp - receive desired OPP target ID from DSP Bridge - * @opp_id: target DSP OPP ID - * - * Set a minimum OPP ID for the DSP. This is intended to be called - * only from the DSP Bridge MPU-side driver. Unfortunately, the only - * information that code receives from the DSP/BIOS load estimator is the - * target OPP ID; hence, this interface. No return value. - */ -void omap_pm_dsp_set_min_opp(u8 opp_id); - -/** - * omap_pm_dsp_get_opp - report the current DSP OPP ID - * - * Report the current OPP for the DSP. Since on OMAP3, the DSP and - * MPU share a single voltage domain, the OPP ID returned back may - * represent a higher DSP speed than the OPP requested via - * omap_pm_dsp_set_min_opp(). - * - * Returns the current VDD1 OPP ID, or 0 upon error. - */ -u8 omap_pm_dsp_get_opp(void); - -/** - * omap_pm_vdd1_get_opp - report the current VDD1 OPP - * - * Report the current VDD1 OPP number. - * - * Returns the current VDD1 OPP ID, or 0 upon error. - */ -u8 omap_pm_vdd1_get_opp(void); - -/** - * omap_pm_vdd2_get_opp - report the current VDD2 OPP - * - * Report the current VDD2 OPP number. - * - * Returns the current VDD2 OPP ID, or 0 upon error. - */ -u8 omap_pm_vdd2_get_opp(void); - -/* - * CPUFreq-originated constraint - * - * In the future, this should be handled by custom OPP clocktype - * functions. - */ - /** * omap_pm_cpu_get_freq_table - return a cpufreq_frequency_table array ptr * diff --git a/arch/arm/plat-omap/include/plat/opp.h b/arch/arm/plat-omap/include/plat/opp.h index d8ae2d3..fedbf44 100644 --- a/arch/arm/plat-omap/include/plat/opp.h +++ b/arch/arm/plat-omap/include/plat/opp.h @@ -13,6 +13,10 @@ #ifndef __ASM_ARM_O
Re: [PATCH 03/10 V3] omap3: pm: use opp accessor functions for omap34xx
Nishanth Menon writes:
> Move the definitions from omap3-opp.h to pm34xx.c. The definitions
> are now based on omap_opp_def instead of omap_opp itself.
> Since the opp.h has the omap_opp definition, omap-pm.h conflicts and
> has been removed in favor of opp.h.
ok
> omap3_pm_init_opp_table is used to initialize the OPP table and
> relevant board files which have omap2_init_common_hw called with opp
> arrays have been updated with omap3_pm_init_opp_table.
>
> This change now allows us to dynamically register OPPs to the system
> based on silicon type we detect.
Nice.
With this patch, I would suggest a couple more cleanups in how we are handling
the master OPP lists for MPU, DSP and L3.
Namely, It's time we could remove the rate_table passing from the OMAP
PM layer all together and just keep them as pointers in opp.h.
The longer term goal is to remove OPP handling from OMAP PM all together,
so this will be a step in that direction.
I've attached a patch that applies on top of your series that drops
the OPPs from OMAP PM layer. After doing this, we now have some
duplicate global pointers to the various rate tables that could be
cleaned up. In addition, all the rate tables could be dropped from
init_common_hw.
If you follow my proposal for using opp_add() instead of opp_init()
the board files that want to just use default OPPs do not have to do
anyting with the rate tables. Only board files wanting to add OPPs
would have to include opp.h and use opp_add().
Also, dropping the rate tables from init_common_hw would mean you
shouldn't have init sequence issues anymore and you can do the OPP
init inside existing PM init.
Kevin
> NOTE: This introduces the following warnings highlighting areas we
> need to cleanup:
> arch/arm/mach-omap2/smartreflex.c: In function 'get_opp':
> arch/arm/mach-omap2/smartreflex.c:161: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/smartreflex.c:164: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/smartreflex.c:166: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/smartreflex.c:168: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/resource34xx.c: In function 'get_opp':
> arch/arm/mach-omap2/resource34xx.c:165: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/resource34xx.c:168: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/resource34xx.c:170: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/resource34xx.c:172: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/resource34xx.c: In function 'program_opp':
> arch/arm/mach-omap2/resource34xx.c:284: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
> arch/arm/mach-omap2/resource34xx.c:285: warning: 'opp_id' is deprecated
> (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>
> Signed-off-by: Nishanth Menon
> ---
> arch/arm/mach-omap2/board-3430sdp.c |1 +
> arch/arm/mach-omap2/board-omap3beagle.c |1 +
> arch/arm/mach-omap2/board-omap3evm.c |1 +
> arch/arm/mach-omap2/board-rx51.c |1 +
> arch/arm/mach-omap2/board-zoom2.c |2 +
> arch/arm/mach-omap2/omap3-opp.h | 58 +---
> arch/arm/mach-omap2/pm.h |6 +++
> arch/arm/mach-omap2/pm34xx.c | 68
> +
> arch/arm/plat-omap/include/plat/omap-pm.h | 17 +---
> 9 files changed, 84 insertions(+), 71 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> b/arch/arm/mach-omap2/board-3430sdp.c
> index eac529f..0ec8327 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -220,6 +220,7 @@ static void __init omap_3430sdp_init_irq(void)
> {
> omap_board_config = sdp3430_config;
> omap_board_config_size = ARRAY_SIZE(sdp3430_config);
> + omap3_pm_init_opp_table();
> omap3_pm_init_vc(&omap3_setuptime_table);
> omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
> omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
> omap3_mpu_rate_table,
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index 2ec3520..a937238 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -361,6 +361,7 @@ static void __init omap3_beagle_init_irq(void)
> {
> omap_board_config = omap3_beagle_config;
> omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
> + omap3_pm_init_opp_table();
> omap2_init_common_
Re: [PATCH 02/10 V3] omap3: pm: introduce opp accessor functions
Nishanth Menon writes:
> Modifies the initial patch From Sanjeev:
> http://patchwork.kernel.org/patch/50998/
> Discussions and comments from:
> http://marc.info/?l=linux-omap&m=125482970102327&w=2
> http://marc.info/?t=12580924752&r=1&w=2
> incorporated.
>
> OMAP SOCs have a standard set of tuples consisting of frequency and
> voltage pairs that the device will support per voltage domain. This
> is called Operating Points or OPP. The actual definitions of OMAP
> Operating Points varies over silicon within the same family of
> devices. For a specific domain, you can have a set of
> {frequency, voltage} pairs. As the kernel boots and more information
> is available, a set of these are activated based on the precise
> nature of device the kernel boots up on. It is interesting to
> remember that each IP which belongs to a voltage domain may define
> their own set of OPPs on top of this.
>
> This introduces a common handling OPP mechanism accross all OMAPs.
> As a start this is introduced for OMAP3 and intends to replace
> current OMAP3 opp handling mechanism.
>
> Note:
> fields of struct omap_opp is currently exposed due to the necessity
> that SRF and SR logic directly indexes the structure array fields.
> The goal however, is to make the direct usage of omap_opp deprecated
> and move to using these accessor functions. The usage in SRF and SR
> indexes based on opp_id and hence opp_id is marked deprecated to
> generate build warnings at least. Further, this usage necessitates
> need of terminator entries at the start and end of opp_* tables which
> are dynamically allocated.
Nice. I like the use of 'deprecated' here to be clear that this stuff
is going way.
> The accessor function definitions were collaborated with Kevin, and
> doing justice here, this implementation could not go with some of
> the better suggestions from kevin due to constraint imposed by SRF
> and SR. A better and more optimal implementation is definitely
> possible once SRF and SR are cleanedup/replaced.
>
> Cc: Benoit Cousson
> Cc: Madhusudhan Chikkature Rajashekar
> Cc: Paul Walmsley
> Cc: Romit Dasgupta
> Cc: Santosh Shilimkar
> Cc: Sergio Alberto Aguirre Rodriguez
> Cc: Thara Gopinath
> Cc: Vishwanath Sripathy
>
> Signed-off-by: Sanjeev Premi
> Signed-off-by: Kevin Hilman
Not yet. :)
> Signed-off-by: Nishanth Menon
Some general comments.
I think the forcing of an int return code for all the functions is a
bit artificial, and is a loss in readability IMHO. I've never liked
getting results values in function arguments, and find that style
difficult to read. More comments on this for each function below.
> ---
> arch/arm/plat-omap/Makefile |3 +
> arch/arm/plat-omap/include/plat/opp.h | 208 ++
> arch/arm/plat-omap/opp.c | 260
> +
I think this should be mach-omap2/opp.c
> 3 files changed, 471 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-omap/include/plat/opp.h
> create mode 100644 arch/arm/plat-omap/opp.c
>
> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
> index 95f8413..e9cf601 100644
> --- a/arch/arm/plat-omap/Makefile
> +++ b/arch/arm/plat-omap/Makefile
> @@ -12,6 +12,9 @@ obj- :=
> # OCPI interconnect support for 1710, 1610 and 5912
> obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
>
> +# OPP support in (OMAP3+ only at the moment)
> +obj-$(CONFIG_ARCH_OMAP3) += opp.o
> +
> # omap_device support (OMAP2+ only at the moment)
> obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
> obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
> diff --git a/arch/arm/plat-omap/include/plat/opp.h
> b/arch/arm/plat-omap/include/plat/opp.h
> new file mode 100644
> index 000..d8ae2d3
> --- /dev/null
> +++ b/arch/arm/plat-omap/include/plat/opp.h
> @@ -0,0 +1,208 @@
> +/*
> + * OMAP OPP Interface
> + *
> + * Copyright (C) 2009 Texas Instruments Incorporated.
> + * Nishanth Menon
> + * Copyright (C) 2009 Deep Root Systems, LLC.
> + * Kevin Hilman
> + *
> + * 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.
> + */
> +#ifndef __ASM_ARM_OMAP_OPP_H
> +#define __ASM_ARM_OMAP_OPP_H
> +
> +/**
> + * struct omap_opp - OMAP OPP description structure
> + * @enabled: true/false - marking this OPP as enabled/disabled
> + * @rate:Frequency in hertz
> + * @opp_id: (DEPRECATED) opp identifier
> + * @vsel:Voltage in volt processor level(this usage is
> + * DEPRECATED to use Voltage in microvolts in future)
> + * uV = ((vsel * 12.5) + 600) * 1000
> + *
> + * This structure stores the OPP information for a given domain.
> + * Due to legacy reasons, this structure is currently exposed and
> + * will soon be removed elsewhere and will only be used as a handle
> + * from the OPP internal referencing mechanism
> + */
> +struct omap_opp {
> + bool enabled;
> +
[PATCH] OMAP: I2C: Add mpu wake up latency constraint in i2c
From: ext Kalle Jokiniemi
While waiting for completion of the i2c transfer, the
MPU could hit OFF mode and cause several msecs of
delay that made i2c transfers fail more often. The
extra delays and subsequent re-trys cause i2c clocks
to be active more often. This has also an negative
effect on power consumption.
Created a mechanism for passing and using the
constraint setting function in driver code. The used
mpu wake up latency constraints are now set individually
per bus, and they are calculated based on clock rate
and fifo size.
Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley,
and Nishanth Menon for tuning out the details of
this patch.
Cc: Moiz Sonasath
Cc: Jarkko Nikula
Cc: Paul Walmsley
Cc: Nishanth Menon
Signed-off-by: Kalle Jokiniemi
---
arch/arm/plat-omap/i2c.c | 54 +++-
drivers/i2c/busses/i2c-omap.c | 25 ---
include/linux/i2c-omap.h |9 +++
3 files changed, 72 insertions(+), 16 deletions(-)
create mode 100644 include/linux/i2c-omap.h
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 8b84839..3c122cd 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,8 +26,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE 0xfffb3800
@@ -69,14 +71,14 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
- I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
+ I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
#ifdefined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
- I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
+ I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
#endif
#ifdefined(CONFIG_ARCH_OMAP34XX)
- I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
+ I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
#endif
};
@@ -100,6 +102,31 @@ static const int omap34xx_pins[][2] = {};
#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
+#ifdef CONFIG_ARCH_OMAP34XX
+/*
+ * omap_i2c_set_wfc_mpu_wkup_lat - sets mpu wake up constraint
+ * @dev: i2c bus device pointer
+ * @val: latency constraint to set, -1 to disable constraint
+ *
+ * When waiting for completion of a i2c transfer, we need to set a wake up
+ * latency constraint for the MPU. This is to ensure quick enough wakeup from
+ * idle, when transfer completes.
+ */
+static void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int val)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, val);
+}
+#endif
+
+static void __init omap_set_i2c_constraint_func(
+ struct omap_i2c_bus_platform_data *pd)
+{
+ if (cpu_is_omap34xx())
+ pd->set_mpu_wkup_lat = omap_i2c_set_wfc_mpu_wkup_lat;
+ else
+ pd->set_mpu_wkup_lat = NULL;
+}
+
static void __init omap_i2c_mux_pins(int bus)
{
int scl, sda;
@@ -180,8 +207,8 @@ static int __init omap_i2c_bus_setup(char *str)
get_options(str, 3, ints);
if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
return 0;
- i2c_rate[ints[1] - 1] = ints[2];
- i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
+ i2c_pdata[ints[1] - 1].clkrate = ints[2];
+ i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
return 1;
}
@@ -195,9 +222,10 @@ static int __init omap_register_i2c_bus_cmdline(void)
{
int i, err = 0;
- for (i = 0; i < ARRAY_SIZE(i2c_rate); i++)
- if (i2c_rate[i] & OMAP_I2C_CMDLINE_SETUP) {
- i2c_rate[i] &= ~OMAP_I2C_CMDLINE_SETUP;
+ for (i = 0; i < ARRAY_SIZE(i2c_pdata); i++)
+ if (i2c_pdata[i].clkrate & OMAP_I2C_CMDLINE_SETUP) {
+ i2c_pdata[i].clkrate &= ~OMAP_I2C_CMDLINE_SETUP;
+ omap_set_i2c_constraint_func(&i2c_pdata[i]);
err = omap_i2c_add_bus(i + 1);
if (err)
goto out;
@@ -231,9 +259,11 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
return err;
}
- if (!i2c_rate[bus_id - 1])
- i2c_rate[bus_id - 1] = clkrate;
- i2c_rate[bus_id - 1] &= ~OMAP_I2C_CMDLINE_SETUP;
+ if (!i2c_pdata[bus_id - 1].clkrate)
+ i2c_pdata[bus_id - 1].clkrate = clkrate;
+
+ omap_set_i2c_constraint_func(&i2c_pdata[bus_id - 1]);
+ i2c_pdata[bus_id - 1].clkrate &= ~OMAP_I2C_CMDLINE_SETUP;
return omap_i2c_add_bus(bus_id);
}
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 827da08..ac0bfd2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/
Re: OMAP3: enabling CPU idle leads to panic
On Tue, Nov 24, 2009 at 11:21 PM, Premi, Sanjeev wrote:
> From: Kevin Hilman [khil...@deeprootsystems.com]
> Sent: Tuesday, November 24, 2009 11:57 PM
> To: Sergey Lapin; Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: OMAP3: enabling CPU idle leads to panic
>
> Sergey Lapin writes:
>
>> I use PM branch merged with linux-omap branch.
>
> Not sure what this means. PM branch is already based at linux-omap
> master branch. You'll need to be more specific, ideally with commit
> IDs.
I do git branch tmp origin/master
git checkout -f tmp
git merge origin/pm
git merge origin/mybranch
git log origin/pm^..origin/pm
commit 596f2d2c8153fe24de5c3b6ad78658ce9fff7f28
Author: Kevin Hilman
Date: Wed Jun 17 14:42:22 2009 -0700
OMAP3: PM: default defconfig for PM kernel testing
Supports 3430SDP, OMAP3EVM and 3630SDP by default.
Also supports, Beagle, Overo, Zoom[23] and RX51 simply by changing
System Type-->TI OMAP implementations-->Low-level debug console UART
from UART1 to UART3.
Signed-off-by: Kevin Hilman
>
> [sp] I will also need the last commit from pm branch - if not the id; the
> commit header to start.
See above
>
> [snip]--[snip]
>
>>
>> addr2line -e vmlinux c003b5c0
>> /home/slapin/linux-omap-my-2.6.git/arch/arm/mach-omap2/powerdomain.c:452
>> It is in function
>> int pwrdm_for_each_clkdm(), where pwrdm is NULL.
>> farther investigations found that "core_pwrdm" is defined only for 24xx,
>> but I use 3525, and it is being searched.
>
> [sp] I am a little confused here. core_pwrdm is defined for 34xx as well.
> Other than sgx, there isn't any difference between 3530 and 3525.
Yes, I see that in source, but that function returns NULL for unknown reason.
How could I debug it farther?
> See the definition at:
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/powerdomains34xx.h;hb=867d320b6c30d2478358eafeca0e1a6c60cf06c3#l203
>
Yes, there is.
>>
>> This is where variable allocated. If I add BUG_ON(!core_pd), it crashes here.
>> arch/arm/mach-omap2/cpuidle34xx.c:348:core_pd =
>> pwrdm_lookup("core_pwrdm");
>> Otherwise it crashes the above way. Any ideas on how to fix this?
>
> [sp] Have you hand-picked the commits from pm branch and applied against
> master?
See above. I use git merge on fresh branch based on linux-omap master.
Thanks a lot,
S.
--
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 00/10 v3] omap3: pm: introduce support for 3630 OPPs
Nishanth Menon writes: > Hi, > Here is V3 of the patch series. What changed in V3: > * Major rewrite of OPP APIs. This includes changes from offline > discussions with lots of folks and taking in l-o comments - all > patches have changed as a result. > * rebased to latest lo-pm > > V2: http://marc.info/?l=linux-omap&m=125809232732700&w=2 > V1: http://marc.info/?l=linux-omap&m=125800488923479&w=2 > > NOTE: After a bunch of frustrating efforts, current OPP accessor > implementation is constrained by two files: > smartreflex.c and resource34xx.c. I agree that the current opp > accessor implementation leaves lot to be desired, but the nature of > struct omap_opp cannot change unless we essentially rewrite the > implementation of the mentioned files. > > Ref: http://elinux.org/OMAP_Power_Management#Future_directions > > I propose we could take this in in three stages: > Stage 1: Introduce this series in as starters if there are no major > issues > Stage 2: We cleanup/replace resource34xx and smartreflex.c > Stage 3: Go through a second round of optimization/cleanup of opp > accessors implementation (this time for good hopefully) I'm open to this 3-step approach assuming that stage 2 and 3 remain a priority. This "stage 1" series will not go upstream. I will only push upstream after getting to stage 3. After some review and discussion, I can pull Stage 1 into the PM branch for broader testing and as a base for more people to help on stage 2 and stage 3. Review comments on individual patches to follow. 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: [ANNOUNCE] PM branch updated to v2.6.32-rc8
"G, Manjunath Kondaiah" writes: > Hi Kevin, > I see multiple commits for some of the patches with 2.6.32-rc8 latest code. > > Ex: > #>gl | grep -i "Introduce zoom3 board support" > 5f35fbe omap3: zoom: Introduce zoom3 board support (3 days ago) > 163cde1 omap3: zoom: Introduce zoom3 board support (7 days ago) > 084bb37 omap: zoom3: introduce zoom3 board support (11 days ago) > 3af1083 omap: zoom3: introduce zoom3 board support (11 days ago) > 13ac7e7 omap: zoom3: introduce zoom3 board support (12 days ago) > 9de2968 omap: zoom3: introduce zoom3 board support (13 days ago) > #> > > There are some more patches like above. > > Is there any specific reason for having multiple commits? First, these commits are not from the PM branch, but from l-o master branch. That being said, the reason for the multiple commits is because of the new way Tony (re)builds the master branch from is various queues. I suggest you look at l-o master using a tool like gitk so you can see the various merge points. Kevin > > -Manjunath > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman >> Sent: Wednesday, November 25, 2009 12:37 AM >> To: linux-omap@vger.kernel.org >> Subject: [ANNOUNCE] PM branch updated to v2.6.32-rc8 >> >> FYI... >> >> PM branch was rebased to today's linux-omap master branch (currently >> v2.6.32-rc8) >> >> As usual, the PM wiki[1] has all the details on using the PM >> branch as well >> as some known issues. >> >> Also note that starting with the official v2.6.32 release, I >> will be moving >> from a continual rebase model to a "re-branch & rebuild" model similar >> to how Tony is now managing l-o master. >> >> Kevin >> >> [1] http://elinux.org/OMAP_Power_Management >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-omap" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)
Wednesday 25 November 2009 10:02:52 Paul Walmsley napisał(a): > Hello Janusz, > > On Sat, 21 Nov 2009, Janusz Krzysztofik wrote: > > (probably less interested persons and lists dropped) > > > > Tuesday 10 November 2009 11:50:52 Paul Walmsley wrote: > > > ... All of the LCD DMA code in plat-omap/dma.c appears to be > > > OMAP1-only (and apparently only is available on a subset of OMAP1 > > > chips). It would be great if this code could be moved to > > > mach-omap1/lcd_dma.c or a similar place. > > > > The patch just tries to implement this idea. > > > > Created against linux-omap for-next, > > commit 2963c21fab52bfa8227da7f22864db393ebbc858 > > > > Tested on OMAP1510 Amstrad Delta. > > Compile tested using omap_generic_2420_defconfig. > > > > Signed-off-by: Janusz Krzysztofik > > > > --- > > Hi Paul, > > > > I hope the patch meets your suggestion closely enough. > > Thanks, just scanned it quickly and it looks carefully done. Two > suggestions below, both minor: Paul, Thanks for your review time. Since I started with just duplicating files and then removing unnecessary sections, I wondered how I could split that work into several subsequent patches so it is more easy to verify how those chunks put into a new file differ from those extracted from the old one, but didn't find a good solution yet. > > diff -uprN git.orig/arch/arm/mach-omap1/Makefile > > git/arch/arm/mach-omap1/Makefile > > --- git.orig/arch/arm/mach-omap1/Makefile 2009-11-21 00:38:45.0 > > +0100 > > +++ git/arch/arm/mach-omap1/Makefile2009-11-21 01:27:12.0 > > +0100 > > @@ -3,7 +3,7 @@ > > # > > > > # Common support > > -obj-y := io.o id.o sram.o clock.o irq.o mux.o serial.o devices.o > > +obj-y := io.o id.o sram.o clock.o irq.o lcd_dma.o mux.o serial.o devices.o > > It seems that this LCD DMA controller is not present on OMAPs prior to the > 1510, given all the references in the LCD DMA code to 1510 and 1610, etc. > It might be good to add a Kconfig option so OMAP730/850 users can skip > compiling it and save some memory. The drivers that use these routines > can then include Kconfig dependencies on that option so it is > automatically included when those drivers are built. OK, will prepare that for next iteration. > > diff -uprN git.orig/arch/arm/mach-omap1/include/mach/lcd_dma.h > > git/arch/arm/mach-omap1/include/mach/lcd_dma.h > > --- git.orig/arch/arm/mach-omap1/include/mach/lcd_dma.h 1970-01-01 > > 01:00:00.0 +0100 > > +++ git/arch/arm/mach-omap1/include/mach/lcd_dma.h 2009-11-21 > > 03:22:25.0 +0100 > > @@ -0,0 +1,78 @@ [snip] > > +#ifndef __MACH_LCD_DMA_H__ > > Consider adding _OMAP1_ in this macro name. I doubt that name collisions > here will be a serious issue, but adding a few extra bytes here might > avoid some bug-hunting frustration in the long run... OK, will do that too. Thanks, 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] ASoC: AM3517: Fix AIC23 suspend/resume hang
On Wed, Nov 25, 2009 at 06:40:31PM +0530, Anuj Aggarwal wrote:
> System hang is observed While trying to do suspend. It was because
> of an infinite loop in the AIC23 resume path which was trying to
> restore AIC23 register values from the register cache.
This doesn't appear to tie in with the actual patch - where's the
infinite loop? The register cache restore loop has a constant bound and
I can't see anything that would make it spin infinitely.
> This patch fixes the problem by correcting the resume path and
> properly activating/deactivating the digital interface while
> doing the suspend / off transitions.
What do you mean by "properly activating/deactivating the digital
interface"?
> case SND_SOC_BIAS_STANDBY:
> - /* everything off except vref/vmid, */
> - tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
> + /* Activate the digital interface */
> + tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
> break;
> case SND_SOC_BIAS_OFF:
> - /* everything off, dac mute, inactive */
> + /* Deactivate the digital interface */
> tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
> - tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
> break;
This looks wrong - the driver is now no longer managing bias levels at
all.
> - u16 reg;
> -
> - /* Sync reg_cache with the hardware */
> - for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); i++) {
> - u16 val = tlv320aic23_read_reg_cache(codec, reg);
> - tlv320aic23_write(codec, reg, val);
> - }
This also looks wrong, the register cache restore has been completely
removed so if the power to the device is cut during suspend then the
device will go back to register defaults and no longer function
correctly after resume.
--
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] ASoC: AM3517: Fix AIC23 suspend/resume hang
System hang is observed While trying to do suspend. It was because
of an infinite loop in the AIC23 resume path which was trying to
restore AIC23 register values from the register cache.
This patch fixes the problem by correcting the resume path and
properly activating/deactivating the digital interface while
doing the suspend / off transitions.
Signed-off-by: Anuj Aggarwal
---
sound/soc/codecs/tlv320aic23.c | 16 +++-
1 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic23.c b/sound/soc/codecs/tlv320aic23.c
index 6b24d8b..cabe60c 100644
--- a/sound/soc/codecs/tlv320aic23.c
+++ b/sound/soc/codecs/tlv320aic23.c
@@ -565,13 +565,12 @@ static int tlv320aic23_set_bias_level(struct
snd_soc_codec *codec,
case SND_SOC_BIAS_PREPARE:
break;
case SND_SOC_BIAS_STANDBY:
- /* everything off except vref/vmid, */
- tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
+ /* Activate the digital interface */
+ tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
break;
case SND_SOC_BIAS_OFF:
- /* everything off, dac mute, inactive */
+ /* Deactivate the digital interface */
tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
- tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
break;
}
codec->bias_level = level;
@@ -615,7 +614,6 @@ static int tlv320aic23_suspend(struct platform_device *pdev,
struct snd_soc_device *socdev = platform_get_drvdata(pdev);
struct snd_soc_codec *codec = socdev->card->codec;
- tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
tlv320aic23_set_bias_level(codec, SND_SOC_BIAS_OFF);
return 0;
@@ -625,14 +623,6 @@ static int tlv320aic23_resume(struct platform_device *pdev)
{
struct snd_soc_device *socdev = platform_get_drvdata(pdev);
struct snd_soc_codec *codec = socdev->card->codec;
- int i;
- u16 reg;
-
- /* Sync reg_cache with the hardware */
- for (reg = 0; reg < ARRAY_SIZE(tlv320aic23_reg); i++) {
- u16 val = tlv320aic23_read_reg_cache(codec, reg);
- tlv320aic23_write(codec, reg, val);
- }
tlv320aic23_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
tlv320aic23_set_bias_level(codec, codec->suspend_bias_level);
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci-omap: Update platform header file path
On Wed, Nov 25, 2009 at 03:02:59AM -0600, Olof Johansson wrote: > The OMAP usb header file has moved, update the driver so it will build. > > Signed-off-by: Olof Johansson > > --- > > Greg, any chance you can just ack this so Tony can merge it through his > tree for .33? The header files changes in question are going in through > that tree. Sure, but for such a trivial change, I doubt you need my ack :) Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 panel question
On Mon, Nov 23, 2009 at 7:41 PM, TAO HU wrote:
> Hi,
>
> One idea as below
>
> struct spi_dss_device {
> struct omap_dss_device dss_dev;
> struct spi_dss_dev_priv * spi_data;
> } spi_dss_dev;
Hm, omap_dss_register_device() takes omap_dss_driver, not
omap_dss_device. Anyway that wouldn't work if there were 2 instances
of same panel in one system I guess, as 2 different spi_data instances
would probe, when there is only one omap_dss_driver.
Instead I'm thinking to link omap_dss_device with spi in board file
itself by (ab)using platform_data:
static struct omap_dss_device pandora_lcd_device = {
...
};
struct spi_board_info pandora_spi_board_info = {
.bus_num = 1,
...
.platform_data = pandora_lcd_device,
};
Then in panel driver:
int spi_probe(struct spi_device *spi)
{
struct omap_dss_device *dssdev = spi->dev.platform_data;
dev_set_drvdata(&dssdev->dev, spi);
}
static int lcd_probe(struct omap_dss_device *dssdev)
{
struct spi_device *spi = dev_get_drvdata(&dssdev->dev);
}
Tomi, does that look reasonable to you?
--
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] mfd: twl4030: Driver for twl4030 madc module
From: Mikko Ylinen
This ADC allows monitoring of analog signals such as battery levels,
temperatures, etc.
Several people have contributed to this driver on the linux-omap list.
Signed-off-by: Amit Kucheria
---
drivers/mfd/Kconfig | 21 ++
drivers/mfd/Makefile |3 +-
drivers/mfd/twl4030-madc.c | 548 ++
include/linux/i2c/twl4030-madc.h | 126 +
4 files changed, 697 insertions(+), 1 deletions(-)
create mode 100644 drivers/mfd/twl4030-madc.c
create mode 100644 include/linux/i2c/twl4030-madc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 08f2d07..fb1ba3a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -127,6 +127,27 @@ config TWL4030_CODEC
select MFD_CORE
default n
+config TWL4030_MADC
+ tristate "TWL4030 MADC Driver"
+ depends on TWL4030_CORE
+ help
+ The TWL4030 Monitoring ADC driver enables the host
+ processor to monitor analog signals using analog-to-digital
+ conversions on the input source. TWL4030 MADC provides the
+ following features:
+ - Single 10-bit ADC with successive approximation register (SAR)
conversion;
+ - Analog multiplexer for 16 inputs;
+ - Seven (of the 16) inputs are freely available;
+ - Battery voltage monitoring;
+ - Concurrent conversion request management;
+ - Interrupt signal to Primary Interrupt Handler;
+ - Averaging feature;
+ - Selective enable/disable of the averaging feature.
+
+ Say 'y' here to statically link this module into the kernel or 'm'
+ to build it as a dinamically loadable module. The module will be
+ called twl4030-madc.ko
+
config MFD_TMIO
bool
default n
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index af0fc90..df1897b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -25,8 +25,9 @@ obj-$(CONFIG_TPS65010)+= tps65010.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-irq.o
-obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
+obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
obj-$(CONFIG_TWL4030_CODEC)+= twl4030-codec.o
+obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_MFD_MC13783) += mc13783-core.o
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
new file mode 100644
index 000..90ce99a
--- /dev/null
+++ b/drivers/mfd/twl4030-madc.c
@@ -0,0 +1,548 @@
+/*
+ * drivers/i2c/chips/twl4030-madc.c
+ *
+ * TWL4030 MADC module driver
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen
+ *
+ * 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
+
+#define TWL4030_MADC_PFX "twl4030-madc: "
+
+struct twl4030_madc_data {
+ struct device *dev;
+ struct mutexlock;
+ struct work_struct ws;
+ struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+ int imr;
+ int isr;
+};
+
+static struct twl4030_madc_data *the_madc;
+static int twl4030_madc_set_current_generator(struct twl4030_madc_data *madc,
int chan, int on);
+
+static
+const struct twl4030_madc_conversion_method twl4030_conversion_methods[] = {
+ [TWL4030_MADC_RT] = {
+ .sel= TWL4030_MADC_RTSELECT_LSB,
+ .avg= TWL4030_MADC_RTAVERAGE_LSB,
+ .rbase = TWL4030_MADC_RTCH0_LSB,
+ },
+ [TWL4030_MADC_SW1] = {
+ .sel= TWL4030_MADC_SW1SELECT_LSB,
+ .avg= TWL4030_MADC_SW1AVERAGE_LSB,
+ .rbase = TWL4030_MADC_GPCH0_LSB,
+ .ctrl = TWL4030_MADC_CTRL_SW1,
+ },
+ [TWL4030_MADC_SW2] = {
+ .sel= TWL4030_MADC_SW2SELECT_LSB,
+ .avg= TWL4030_MADC_SW2AVERAGE_LSB,
+ .rbase = TWL4030_MADC_GPCH0_LSB,
+ .ctrl = TWL4030_MADC_CTRL_SW2,
+ },
+};
+
+static int twl4030_madc_read(struct twl4030_madc_data *madc, u8 reg)
+{
+ int ret;
+ u8 val;
+
+ ret = twl4030_i2c_read_u8(TWL4030_MODULE_MADC, &val, reg);
+ i
RE: [ANNOUNCE] PM branch updated to v2.6.32-rc8
Hi Kevin, I see multiple commits for some of the patches with 2.6.32-rc8 latest code. Ex: #>gl | grep -i "Introduce zoom3 board support" 5f35fbe omap3: zoom: Introduce zoom3 board support (3 days ago) 163cde1 omap3: zoom: Introduce zoom3 board support (7 days ago) 084bb37 omap: zoom3: introduce zoom3 board support (11 days ago) 3af1083 omap: zoom3: introduce zoom3 board support (11 days ago) 13ac7e7 omap: zoom3: introduce zoom3 board support (12 days ago) 9de2968 omap: zoom3: introduce zoom3 board support (13 days ago) #> There are some more patches like above. Is there any specific reason for having multiple commits? -Manjunath > -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman > Sent: Wednesday, November 25, 2009 12:37 AM > To: linux-omap@vger.kernel.org > Subject: [ANNOUNCE] PM branch updated to v2.6.32-rc8 > > FYI... > > PM branch was rebased to today's linux-omap master branch (currently > v2.6.32-rc8) > > As usual, the PM wiki[1] has all the details on using the PM > branch as well > as some known issues. > > Also note that starting with the official v2.6.32 release, I > will be moving > from a continual rebase model to a "re-branch & rebuild" model similar > to how Tony is now managing l-o master. > > Kevin > > [1] http://elinux.org/OMAP_Power_Management > -- > To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci-omap: Update platform header file path
On Wed, Nov 25, 2009 at 02:35:56PM +0530, Gadiyar, Anand wrote: > Olof Johansson wrote: > > > > The OMAP usb header file has moved, update the driver so it > > will build. > > > > Signed-off-by: Olof Johansson > > > > --- > > > > Greg, any chance you can just ack this so Tony can merge it through his > > tree for .33? The header files changes in question are going in through > > that tree. > > > > I believe it has already been taken care of in Tony's for-next? Oh, weird. Looking at the history of the file on git.kernel.org: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=history;f=drivers/usb/host/ehci-omap.c;hb=HEAD It shows Tony making the change on Oct 30, and then 4 fresh merges of the driver? That's odd. -Olof -- 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] usb: ehci-omap: Update platform header file path
On Wed, Nov 25, 2009 at 02:35:56PM +0530, Gadiyar, Anand wrote: > Olaf Johansson wrote: > > > > The OMAP usb header file has moved, update the driver so it > > will build. > > > > Signed-off-by: Olof Johansson > > > > --- > > > > Greg, any chance you can just ack this so Tony can merge it through his > > tree for .33? The header files changes in question are going in through > > that tree. > > > > I believe it has already been taken care of in Tony's for-next? > > - Anand Tony's master branch does not build due to this for me. Maybe it doesn't include for-next?! -Olof -- 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/2] usb: ehci: Allow EHCI to be built on OMAP3
Olof Johansson wrote: > > OMAP34XX has EHCI, so select USB_ARCH_HAS_EHCI. > > Signed-off-by: Olof Johansson Acked-by: Anand Gadiyar > > --- > > On Sat, Nov 07, 2009 at 01:16:32AM +0530, Anand Gadiyar wrote: > > usb: ehci: Allow EHCI to be built on OMAP3 > > > > OMAP3 chips have a built-in EHCI controller. > > The recently introduced omap ehci-hcd driver missed > > out on selecting USB_ARCH_HAS_EHCI in Kconfig. > > > > Without this, the driver cannot be built. > > This is a losing battle. It scales much better to select the option > from OMAP34XX, instead of starting to enumerate the various platforms > in drivers/usb. > Yes, I agree. Okay with me to drop my patch and use this one instead. - Anand > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 034d990..a913b05 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -18,6 +18,7 @@ config ARCH_OMAP2430 > config ARCH_OMAP34XX > bool "OMAP34xx Based System" > depends on ARCH_OMAP3 > + select USB_ARCH_HAS_EHCI > > config ARCH_OMAP3430 > bool "OMAP3430 support" > -- 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] usb: ehci-omap: Update platform header file path
Olaf Johansson wrote: > > The OMAP usb header file has moved, update the driver so it > will build. > > Signed-off-by: Olof Johansson > > --- > > Greg, any chance you can just ack this so Tony can merge it through his > tree for .33? The header files changes in question are going in through > that tree. > I believe it has already been taken care of in Tony's for-next? - Anand > > Thanks, > > -Olof > > diff --git a/drivers/usb/host/ehci-omap.c > b/drivers/usb/host/ehci-omap.c > index 7ba8df3..5cfed78 100644 > --- a/drivers/usb/host/ehci-omap.c > +++ b/drivers/usb/host/ehci-omap.c > @@ -37,7 +37,7 @@ > #include > #include > #include > -#include > +#include > > /* > * OMAP USBHOST Register addresses: VIRTUAL ADDRESSES -- 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] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)
Hello Janusz, On Sat, 21 Nov 2009, Janusz Krzysztofik wrote: > (probably less interested persons and lists dropped) > > Tuesday 10 November 2009 11:50:52 Paul Walmsley wrote: > > ... All of the LCD DMA code in plat-omap/dma.c appears to be > > OMAP1-only (and apparently only is available on a subset of OMAP1 chips). > > It would be great if this code could be moved to mach-omap1/lcd_dma.c or > > a similar place. > > The patch just tries to implement this idea. > > Created against linux-omap for-next, > commit 2963c21fab52bfa8227da7f22864db393ebbc858 > > Tested on OMAP1510 Amstrad Delta. > Compile tested using omap_generic_2420_defconfig. > > Signed-off-by: Janusz Krzysztofik > > --- > Hi Paul, > > I hope the patch meets your suggestion closely enough. Thanks, just scanned it quickly and it looks carefully done. Two suggestions below, both minor: > Thanks, > Janusz > > diff -uprN git.orig/arch/arm/mach-omap1/Makefile > git/arch/arm/mach-omap1/Makefile > --- git.orig/arch/arm/mach-omap1/Makefile 2009-11-21 00:38:45.0 > +0100 > +++ git/arch/arm/mach-omap1/Makefile 2009-11-21 01:27:12.0 +0100 > @@ -3,7 +3,7 @@ > # > > # Common support > -obj-y := io.o id.o sram.o clock.o irq.o mux.o serial.o devices.o > +obj-y := io.o id.o sram.o clock.o irq.o lcd_dma.o mux.o serial.o devices.o It seems that this LCD DMA controller is not present on OMAPs prior to the 1510, given all the references in the LCD DMA code to 1510 and 1610, etc. It might be good to add a Kconfig option so OMAP730/850 users can skip compiling it and save some memory. The drivers that use these routines can then include Kconfig dependencies on that option so it is automatically included when those drivers are built. > obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o > > diff -uprN git.orig/arch/arm/mach-omap1/include/mach/lcd_dma.h > git/arch/arm/mach-omap1/include/mach/lcd_dma.h > --- git.orig/arch/arm/mach-omap1/include/mach/lcd_dma.h 1970-01-01 > 01:00:00.0 +0100 > +++ git/arch/arm/mach-omap1/include/mach/lcd_dma.h2009-11-21 > 03:22:25.0 +0100 > @@ -0,0 +1,78 @@ > +/* > + * arch/arm/mach-omap1/include/mach/lcd_dma.h > + * > + * Extracted from arch/arm/plat-omap/include/plat/dma.h > + * Copyright (C) 2003 Nokia Corporation > + * Author: Juha Yrjölä > + * > + * 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 later version. > + * > + * 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 __MACH_LCD_DMA_H__ Consider adding _OMAP1_ in this macro name. I doubt that name collisions here will be a serious issue, but adding a few extra bytes here might avoid some bug-hunting frustration in the long run... > +#define __MACH_LCD_DMA_H__ > + > +/* Hardware registers for LCD DMA */ > +#define OMAP1510_DMA_LCD_BASE(0xfffedb00) > +#define OMAP1510_DMA_LCD_CTRL(OMAP1510_DMA_LCD_BASE + 0x00) > +#define OMAP1510_DMA_LCD_TOP_F1_L(OMAP1510_DMA_LCD_BASE + 0x02) > +#define OMAP1510_DMA_LCD_TOP_F1_U(OMAP1510_DMA_LCD_BASE + 0x04) > +#define OMAP1510_DMA_LCD_BOT_F1_L(OMAP1510_DMA_LCD_BASE + 0x06) > +#define OMAP1510_DMA_LCD_BOT_F1_U(OMAP1510_DMA_LCD_BASE + 0x08) > + > +#define OMAP1610_DMA_LCD_BASE(0xfffee300) > +#define OMAP1610_DMA_LCD_CSDP(OMAP1610_DMA_LCD_BASE + 0xc0) > +#define OMAP1610_DMA_LCD_CCR (OMAP1610_DMA_LCD_BASE + 0xc2) > +#define OMAP1610_DMA_LCD_CTRL(OMAP1610_DMA_LCD_BASE + 0xc4) > +#define OMAP1610_DMA_LCD_TOP_B1_L(OMAP1610_DMA_LCD_BASE + 0xc8) > +#define OMAP1610_DMA_LCD_TOP_B1_U(OMAP1610_DMA_LCD_BASE + 0xca) > +#define OMAP1610_DMA_LCD_BOT_B1_L(OMAP1610_DMA_LCD_BASE + 0xcc) > +#define OMAP1610_DMA_LCD_BOT_B1_U(OMAP1610_DMA_LCD_BASE + 0xce) > +#define OMAP1610_DMA_LCD_TOP_B2_L(OMAP1610_DMA_LCD_BASE + 0xd0) > +#define OMAP1610_DMA_LCD_TOP_B2_U(OMAP1610_DMA_LCD_BASE + 0xd2) > +#define OMAP1610_DMA_LCD_BOT_B2_L(OMAP1610_DMA_LCD_BASE + 0xd4) > +#define OMAP1610_DMA_LCD_BOT_B2_U(OMAP1610_DMA_LCD_BASE + 0xd6) > +#define OMAP1610_DMA_LCD_SRC_EI_B1 (OMAP1610_DMA_LCD_BASE + 0xd8) > +#define OMAP1610_DMA_LCD_SRC_FI_B1_L (OMAP1610_DMA_LCD_BASE + 0xda) > +#define OMAP1610_DMA_LCD_SRC_EN_B1 (OMAP1610_DMA_LCD_BASE + 0xe0) > +#define OMAP1610_DMA_LCD_SRC_FN_B1 (OMAP1610_DMA_LCD_BASE + 0xe4) > +#define OMAP1610_DMA_LCD_LCH_CTRL
[PATCH] usb: ehci-omap: Update platform header file path
The OMAP usb header file has moved, update the driver so it will build. Signed-off-by: Olof Johansson --- Greg, any chance you can just ack this so Tony can merge it through his tree for .33? The header files changes in question are going in through that tree. Thanks, -Olof diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 7ba8df3..5cfed78 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -37,7 +37,7 @@ #include #include #include -#include +#include /* * OMAP USBHOST Register addresses: VIRTUAL ADDRESSES -- 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/2] usb: ehci: Allow EHCI to be built on OMAP3
OMAP34XX has EHCI, so select USB_ARCH_HAS_EHCI. Signed-off-by: Olof Johansson --- On Sat, Nov 07, 2009 at 01:16:32AM +0530, Anand Gadiyar wrote: > usb: ehci: Allow EHCI to be built on OMAP3 > > OMAP3 chips have a built-in EHCI controller. > The recently introduced omap ehci-hcd driver missed > out on selecting USB_ARCH_HAS_EHCI in Kconfig. > > Without this, the driver cannot be built. This is a losing battle. It scales much better to select the option from OMAP34XX, instead of starting to enumerate the various platforms in drivers/usb. diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 034d990..a913b05 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -18,6 +18,7 @@ config ARCH_OMAP2430 config ARCH_OMAP34XX bool "OMAP34xx Based System" depends on ARCH_OMAP3 + select USB_ARCH_HAS_EHCI config ARCH_OMAP3430 bool "OMAP3430 support" -- 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
