[PATCH resend 2/3] musb: add musb support for AM35x
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode. DMA support can be
added later once basic CPPI4.1 DMA patch is accepted.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/Kconfig |4 +-
drivers/usb/musb/Makefile |4 +
drivers/usb/musb/am35x.c | 519 +
3 files changed, 525 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/musb/am35x.c
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index cfd38ed..87d73fa 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -10,7 +10,7 @@ comment "Enable Host or Gadget support to see Inventra
options"
config USB_MUSB_HDRC
depends on (USB || USB_GADGET)
depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523))
- select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN)
+ select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN ||
ARCH_AM35x)
select TWL4030_USB if MACH_OMAP_3430SDP
select USB_OTG_UTILS
tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
@@ -144,7 +144,7 @@ config USB_MUSB_HDRC_HCD
config MUSB_PIO_ONLY
bool 'Disable DMA (always use PIO)'
depends on USB_MUSB_HDRC
- default y if USB_TUSB6010
+ default USB_TUSB6010 || ARCH_AM35x
help
All data is copied between memory and FIFO by the CPU.
DMA controllers are ignored.
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 9705f71..f99f675 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -19,7 +19,11 @@ ifeq ($(CONFIG_ARCH_OMAP2430),y)
endif
ifeq ($(CONFIG_ARCH_OMAP3430),y)
+ ifeq ($(CONFIG_ARCH_AM35x),y)
+ musb_hdrc-objs += am35x.o
+ else
musb_hdrc-objs += omap2430.o
+ endif
endif
ifeq ($(CONFIG_ARCH_OMAP4),y)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
new file mode 100644
index 000..0cdc6bf
--- /dev/null
+++ b/drivers/usb/musb/am35x.c
@@ -0,0 +1,519 @@
+/*
+ * Texas Instruments AM35x "glue layer"
+ *
+ * Copyright (c) 2010, by Texas Instruments
+ *
+ * Based on the DA8xx "glue layer" code.
+ * Copyright (C) 2005-2006 by Texas Instruments
+ * Copyright (c) 2008, MontaVista Software, Inc.
+ *
+ * This file is part of the Inventra Controller Driver for Linux.
+ *
+ * The Inventra Controller Driver for Linux 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.
+ *
+ * The Inventra Controller Driver for Linux 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 The Inventra Controller Driver for Linux ; if not,
+ * write to the Free Software Foundation, Inc., 59 Temple Place,
+ * Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include "musb_core.h"
+
+/*
+ * AM35x specific definitions
+ */
+/* USB 2.0 OTG module registers */
+#define USB_REVISION_REG 0x00
+#define USB_CTRL_REG 0x04
+#define USB_STAT_REG 0x08
+#define USB_EMULATION_REG 0x0c
+/* 0x10 Reserved */
+#define USB_AUTOREQ_REG0x14
+#define USB_SRP_FIX_TIME_REG 0x18
+#define USB_TEARDOWN_REG 0x1c
+#define EP_INTR_SRC_REG0x20
+#define EP_INTR_SRC_SET_REG0x24
+#define EP_INTR_SRC_CLEAR_REG 0x28
+#define EP_INTR_MASK_REG 0x2c
+#define EP_INTR_MASK_SET_REG 0x30
+#define EP_INTR_MASK_CLEAR_REG 0x34
+#define EP_INTR_SRC_MASKED_REG 0x38
+#define CORE_INTR_SRC_REG 0x40
+#define CORE_INTR_SRC_SET_REG 0x44
+#define CORE_INTR_SRC_CLEAR_REG0x48
+#define CORE_INTR_MASK_REG 0x4c
+#define CORE_INTR_MASK_SET_REG 0x50
+#define CORE_INTR_MASK_CLEAR_REG 0x54
+#define CORE_INTR_SRC_MASKED_REG 0x58
+/* 0x5c Reserved */
+#define USB_END_OF_INTR_REG0x60
+
+/* Control register bits */
+#define USB_SOFT_RESET_MASK1
+#define A_WAIT_BCON_TIMEOUT1100/* in ms */
+
+/* USB interrupt register bits */
+#define USB_INTR_USB_SHIFT 16
+#define USB_INTR_USB_MASK (0x1ff << USB_INTR_USB_SHIFT)
+#define USB_INTR_DRVVBUS 0x100
+#define USB_INTR_RX_SHIFT 16
+#define USB_INTR_TX_SHIFT 0
+#define AM35X_TX_EP_MASK 0x /* EP0 + 15 Tx EPs */
+#define AM35X_RX_EP_MASK 0xfffe /* 15 Rx EPs */
+#define AM35X_TX_INTR_MASK (AM35X_TX_EP_MASK << USB_INTR_TX_SHIFT)
+#define AM35X_RX_INTR_MASK (AM35X_RX_EP_MASK << USB_INTR_RX_SHIFT)
+
+#define USB_MENTOR_CORE_OFFSET 0x400
+
+static inline void phy_on(void)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+
[PATCH resend 3/3] musb: AM35x: Workaround for fifo read issue
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/am35x.c | 30 ++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 0cdc6bf..cdcd6f3 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -517,3 +517,33 @@ void musb_platform_restore_context(struct musb *musb,
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep->fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 & (unsigned long) dst) == 0) && len >= 4) {
+ readsl(fifo, dst, len >> 2);
+ dst += len & ~0x03;
+ len &= 0x03;
+ }
+ /*
+* Now read the rest 1 to 3 bytes or complete length if
+* unaligned address.
+*/
+ if (len > 4) {
+ for (i = 0; i < (len >> 2); i++) {
+ *(u32 *) dst = musb_readl(fifo, 0);
+ dst += 4;
+ }
+ len %= 4;
+ }
+ if (len > 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, &val, len);
+ }
+}
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3b795c5..e22e98b 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -272,6 +272,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
const u8 *src)
}
}
+#if !defined(CONFIG_ARCH_AM35x)
/*
* Unload an endpoint's FIFO
*/
@@ -309,6 +310,7 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8
*dst)
readsb(fifo, dst, len);
}
}
+#endif
#endif /* normal PIO */
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH resend 1/3] AM35x: Add musb support
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
It has USB phy built inside the IP itself.
Also added ARCH_AM35x which is required to differentiate musb ips
between OMAP3x and AM35x. This config would be used for below purposes,
- Select am35x.c instead of omap2430.c for compilation
at drivers/usb/musb directory. Please note there are
significant differneces in these two files as musb ip
in quite different on AM35x.
- Select workaround codes applicable for AM35x musb issues.
one such workaround is for bytewise read issue on AM35x.
Signed-off-by: Ajay Kumar Gupta
---
Patches created against recent linus's tree.
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/board-am3517evm.c | 30 ++
arch/arm/mach-omap2/usb-musb.c|4
arch/arm/plat-omap/Kconfig|8
arch/arm/plat-omap/include/plat/usb.h | 21 +
5 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b31b6f1..52a6752 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -84,6 +84,7 @@ config MACH_OMAP3517EVM
bool "OMAP3517/ AM3517 EVM board"
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
+ select ARCH_AM35x
config MACH_OMAP3_PANDORA
bool "OMAP3 Pandora"
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index af383a8..7f42a1b 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "mux.h"
@@ -375,6 +376,30 @@ static void __init am3517_evm_init_irq(void)
omap_gpio_init();
}
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
+
+static __init void am3517_evm_musb_init(void)
+{
+ u32 devconf2;
+
+ /*
+* Set up USB clock/mode in the DEVCONF2 register.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ /* USB2.0 PHY reference clock is 13 MHz */
+ devconf2 &= ~(CONF2_REFFREQ | CONF2_OTGMODE);
+ devconf2 |= CONF2_REFFREQ_13MHZ | CONF2_SESENDEN | CONF2_VBDTCTEN;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ usb_musb_init(&musb_board_data);
+}
+
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
@@ -393,6 +418,8 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* USB OTG DRVVBUS offset = 0x212 */
+ OMAP3_MUX(SAD2D_MCAD23, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
@@ -459,6 +486,9 @@ static void __init am3517_evm_init(void)
ARRAY_SIZE(am3517evm_i2c1_boardinfo));
/*Ethernet*/
am3517_evm_ethernet_init(&am3517_evm_emac_pdata);
+
+ /* MUSB */
+ am3517_evm_musb_init();
}
static void __init am3517_evm_map_io(void)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 96f6787..a54f360 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_USB_MUSB_SOC
@@ -90,6 +91,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
{
if (cpu_is_omap243x()) {
musb_resources[0].start = OMAP243X_HS_BASE;
+ } else if (cpu_is_omap3517() || cpu_is_omap3505()) {
+ musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
+ musb_resources[1].start = INT_35XX_USBOTG_IRQ;
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 78b49a6..3f33d75 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,14 @@ menu "TI OMAP Implementations"
config ARCH_OMAP_OTG
bool
+config ARCH_AM35x
+ bool
+ help
+ Select this option if your platform is based on AM35x. As
+ AM35x has an updated MUSB with CPPI4.1 DMA so this config
+ is introduced to differentiate musb ip between OMAP3x and
+ AM35x platforms.
+
choice
prompt "OMAP System Type"
default ARCH_OMAP2PLUS
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 98eef53..76d2e29 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/
Re: [PATCH 0/2] pandora updates for .36
* Gadiyar, Anand [100701 23:25]: > Grazvydas Ignotas wrote: > > > > Hi Tony, > > > > here are some updates for Pandora, which we have now around 700 units > > shipped (finally!) after years of developemt hell. More are being > > made at the moment. > > > > Neat! Hope you sell a zillion. I'll try and buy one someday. Yeah congrats! I'll be buying one too at some point :) Looking at all the patches for the merge window now, will queue up the pandora changes too. 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: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
From: Hiroshi DOYU Subject: Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Tue, 29 Jun 2010 07:57:44 +0300 (EEST) > Hi Tony, > > From: Hiroshi DOYU > Subject: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 > Date: Wed, 02 Jun 2010 10:50:54 +0300 (EEST) > >> Hi Tony, >> >> Patches for for-next for omap iommu module. >> >> The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: >> >> Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) >> >> are available in the git repository at: >> git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu >> >> Hiroshi DOYU (3): >> omap iommu: Introduce iopgd_is_table MACRO >> omap iommu: Rename iopte_[p,v]addr -> iopte_page_[p,v]addr >> omap iommu: move iommu_disable at fault to the above layer >> >> Kanigeri, Hari (2): >> omap iommu: update irq mask to be specific about twl and tlb >> omap iommu: add functionality to get TLB miss interrupt >> >> arch/arm/mach-omap2/iommu2.c| 44 >> -- >> arch/arm/plat-omap/include/plat/iommu.h |2 + >> arch/arm/plat-omap/iommu.c | 27 --- >> arch/arm/plat-omap/iopgtable.h |8 +++-- >> 4 files changed, 65 insertions(+), 16 deletions(-) > > Any chance to merge? > > I have added 2 patches which were dropped from omap iommu fix as > below. Please pull the following branch. Hi Tony, Do you have any plan for pulling for-next patches? I have some "omap iommu" and "omap mailbox" patches for for-next. Now the merge window seems so small and I don't want to miss it. > The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: > > Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) > > are available in the git repository at: > git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-iommu-for-next > > Hiroshi DOYU (4): > omap iommu: Introduce iopgd_is_table MACRO > omap iommu: Rename iopte_[p,v]addr -> iopte_page_[p,v]addr > omap iommu: move iommu_disable at fault to the above layer > omap iommu: Make omap-iommu.o built-in > > Kanigeri, Hari (3): > omap iommu: update irq mask to be specific about twl and tlb > omap iommu: add functionality to get TLB miss interrupt > omap iommu: update ducati mmu irq define name > > arch/arm/mach-omap2/Makefile|5 +++- > arch/arm/mach-omap2/iommu2.c| 44 -- > arch/arm/mach-omap2/omap-iommu.c|2 +- > arch/arm/plat-omap/include/plat/iommu.h |2 + > arch/arm/plat-omap/iommu.c | 27 --- > arch/arm/plat-omap/iopgtable.h |8 +++-- > 6 files changed, 70 insertions(+), 18 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: [PATCH 1/9] dspbridge: replace iommu custom for opensource implementation
Hi Fernando,
From: ext Fernando Guzman Lugo
Subject: [PATCH 1/9] dspbridge: replace iommu custom for opensource
implementation
Date: Thu, 1 Jul 2010 02:20:52 +0200
> This patch replace the call to custom dsp mmu implemenation
> for the once on iommu module.
>
> Signed-off-by: Fernando Guzman Lugo
> ---
> drivers/dsp/bridge/core/_tiomap.h| 16 +
> drivers/dsp/bridge/core/io_sm.c | 114 ++--
> drivers/dsp/bridge/core/tiomap3430.c | 501
> +-
> drivers/dsp/bridge/core/ue_deh.c | 10 -
> 4 files changed, 118 insertions(+), 523 deletions(-)
>
> diff --git a/drivers/dsp/bridge/core/_tiomap.h
> b/drivers/dsp/bridge/core/_tiomap.h
> index bf0164e..d13677a 100644
> --- a/drivers/dsp/bridge/core/_tiomap.h
> +++ b/drivers/dsp/bridge/core/_tiomap.h
> @@ -23,6 +23,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include /* for bridge_ioctl_extproc defn */
> @@ -330,6 +332,7 @@ struct bridge_dev_context {
> u32 dw_internal_size; /* Internal memory size */
>
> struct omap_mbox *mbox; /* Mail box handle */
> + struct iommu *dsp_mmu; /* iommu for iva2 handler */
>
> struct cfg_hostres *resources; /* Host Resources */
>
> @@ -374,4 +377,17 @@ extern s32 dsp_debug;
> */
> int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val);
>
> +static inline void dsp_iotlb_init(struct iotlb_entry *e, u32 da, u32 pa,
> + u32 pgsz)
> +{
> + e->da = da;
> + e->pa = pa;
> + e->valid = 1;
> + e->prsvd = 1;
> + e->pgsz = pgsz & MMU_CAM_PGSZ_MASK;
> + e->endian = MMU_RAM_ENDIAN_LITTLE;
> + e->elsz = MMU_RAM_ELSZ_32;
> + e->mixed = 0;
> +}
> +
> #endif /* _TIOMAP_ */
> diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c
> index 7fb840d..1f47f8b 100644
> --- a/drivers/dsp/bridge/core/io_sm.c
> +++ b/drivers/dsp/bridge/core/io_sm.c
> @@ -290,6 +290,8 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
> struct cod_manager *cod_man;
> struct chnl_mgr *hchnl_mgr;
> struct msg_mgr *hmsg_mgr;
> + struct iommu *mmu;
> + struct iotlb_entry e;
> u32 ul_shm_base;
> u32 ul_shm_base_offset;
> u32 ul_shm_limit;
> @@ -312,7 +314,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
> struct bridge_ioctl_extproc ae_proc[BRDIOCTL_NUMOFMMUTLB];
> struct cfg_hostres *host_res;
> struct bridge_dev_context *pbridge_context;
> - u32 map_attrs;
> u32 shm0_end;
> u32 ul_dyn_ext_base;
> u32 ul_seg1_size = 0;
> @@ -336,6 +337,21 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
> status = -EFAULT;
> goto func_end;
> }
> +
> + mmu = pbridge_context->dsp_mmu;
> +
> + if (mmu)
> + iommu_put(mmu);
> + mmu = iommu_get("iva2");
+ mmu = iommu_get("iva2", mmu_fault_isr);
I'm considering that it might be better to pass a mmu fault callback
at this iommu_get.
What do you think?
--
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: add mmufault support
Hi Fernando,
From: ext Fernando Guzman Lugo
Subject: [PATCH 5/9] dspbridge: add mmufault support
Date: Thu, 1 Jul 2010 02:20:56 +0200
> With changes for iommu migration mmu fault report and dsp track
> dump is broken, this patch fixes that.
>
> Signed-off-by: Fernando Guzman Lugo
> ---
> drivers/dsp/bridge/core/mmu_fault.c | 93 ++---
> drivers/dsp/bridge/core/mmu_fault.h |5 +-
> drivers/dsp/bridge/core/tiomap3430.c |2 +
> drivers/dsp/bridge/core/ue_deh.c | 31 +---
> 4 files changed, 34 insertions(+), 97 deletions(-)
>
> diff --git a/drivers/dsp/bridge/core/mmu_fault.c
> b/drivers/dsp/bridge/core/mmu_fault.c
> index 5c0124f..d991c6a 100644
> --- a/drivers/dsp/bridge/core/mmu_fault.c
> +++ b/drivers/dsp/bridge/core/mmu_fault.c
> @@ -23,9 +23,12 @@
> /* --- Trace & Debug */
> #include
> #include
> +#include
>
> /* --- OS Adaptation Layer */
> #include
> +#include
> +
>
> /* --- Link Driver */
> #include
> @@ -40,11 +43,6 @@
> #include "_tiomap.h"
> #include "mmu_fault.h"
>
> -static u32 dmmu_event_mask;
> -u32 fault_addr;
> -
> -static bool mmu_check_if_fault(struct bridge_dev_context *dev_context);
> -
> /*
> * mmu_fault_dpc
> * Deferred procedure call to handle DSP MMU fault.
> @@ -62,78 +60,21 @@ void mmu_fault_dpc(IN unsigned long pRefData)
> * mmu_fault_isr
> * ISR to be triggered by a DSP MMU fault interrupt.
> */
> -irqreturn_t mmu_fault_isr(int irq, IN void *pRefData)
> -{
> - struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)pRefData;
> - struct bridge_dev_context *dev_context;
> - struct cfg_hostres *resources;
> -
> - DBC_REQUIRE(irq == INT_DSP_MMU_IRQ);
> - DBC_REQUIRE(deh_mgr_obj);
> -
> - if (deh_mgr_obj) {
> -
> - dev_context =
> - (struct bridge_dev_context *)deh_mgr_obj->hbridge_context;
> -
> - resources = dev_context->resources;
> -
> - if (!resources) {
> - dev_dbg(bridge, "%s: Failed to get Host Resources\n",
> - __func__);
> - return IRQ_HANDLED;
> - }
> - if (mmu_check_if_fault(dev_context)) {
> - printk(KERN_INFO "* DSPMMU FAULT * IRQStatus "
> -"0x%x\n", dmmu_event_mask);
> - printk(KERN_INFO "* DSPMMU FAULT * fault_addr "
> -"0x%x\n", fault_addr);
> - /*
> - * Schedule a DPC directly. In the future, it may be
> - * necessary to check if DSP MMU fault is intended for
> - * Bridge.
> - */
> - tasklet_schedule(&deh_mgr_obj->dpc_tasklet);
> -
> - /* Reset err_info structure before use. */
> - deh_mgr_obj->err_info.dw_err_mask = DSP_MMUFAULT;
> - deh_mgr_obj->err_info.dw_val1 = fault_addr >> 16;
> - deh_mgr_obj->err_info.dw_val2 = fault_addr & 0x;
> - deh_mgr_obj->err_info.dw_val3 = 0L;
> - /* Disable the MMU events, else once we clear it will
> - * start to raise INTs again */
> - hw_mmu_event_disable(resources->dw_dmmu_base,
> - HW_MMU_TRANSLATION_FAULT);
> - } else {
> - hw_mmu_event_disable(resources->dw_dmmu_base,
> - HW_MMU_ALL_INTERRUPTS);
> - }
> - }
> - return IRQ_HANDLED;
> -}
> +int mmu_fault_isr(struct iommu *mmu)
>
> -/*
> - * mmu_check_if_fault
> - * Check to see if MMU Fault is valid TLB miss from DSP
> - * Note: This function is called from an ISR
> - */
> -static bool mmu_check_if_fault(struct bridge_dev_context *dev_context)
> {
> + struct deh_mgr *dm;
> + u32 da;
> +
> + dev_get_deh_mgr(dev_get_first(), &dm);
> +
> + if (!dm)
> + return -EPERM;
> +
> + da = iommu_read_reg(mmu, MMU_FAULT_AD);
> + iommu_write_reg(mmu, 0, MMU_IRQENABLE);
> + dm->err_info.dw_val1 = da;
> + tasklet_schedule(&dm->dpc_tasklet);
I think that the following "iommu_disable()" does disabling MMU.
Modified arch/arm/plat-omap/iommu.c
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index a202a2c..17407f1 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -800,7 +800,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
if (!stat)
return IRQ_HANDLED;
- iommu_disable(obj);
+ iommu_disable(obj); <- HERE!
iopgd = iopgd_offset(obj, da);
You can find the latest omap iommu code from:
git://gi
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Andi Kleen wrote: >> The VCMM provides a more abstract, global view with finer-grained >> control of each mapping a user wants to create. For instance, the >> semantics of iommu_map preclude its use in setting up just the IOMMU >> side of a mapping. With a one-sided map, two IOMMU devices can be > > Hmm? dma_map_* does not change any CPU mappings. It only sets up > DMA mapping(s). Sure, but I was saying that iommu_map() doesn't just set up the IOMMU mappings, its sets up both the iommu and kernel buffer mappings. > >> Additionally, the current IOMMU interface does not allow users to >> associate one page table with multiple IOMMUs unless the user explicitly > > That assumes that all the IOMMUs on the system support the same page table > format, right? Actually no. Since the VCMM abstracts a page-table as a Virtual Contiguous Region (VCM) a VCM can be associated with any device, regardless of their individual page table format. > > As I understand your approach would help if you have different > IOMMus with an different low level interface, which just > happen to have the same pte format. Is that very likely? > > I would assume if you have lots of copies of the same IOMMU > in the system then you could just use a single driver with multiple > instances that share some state for all of them. That model > would fit in the current interfaces. There's no reason multiple > instances couldn't share the same allocation data structure. > > And if you have lots of truly different IOMMUs then they likely > won't be able to share PTEs at the hardware level anyways, because > the formats are too different. See VCM's above. > >> The VCMM takes the long view. Its designed for a future in which the >> number of IOMMUs will go up and the ways in which these IOMMUs are >> composed will vary from system to system, and may vary at >> runtime. Already, there are ~20 different IOMMU map implementations in >> the kernel. Had the Linux kernel had the VCMM, many of those >> implementations could have leveraged the mapping and topology management >> of a VCMM, while focusing on a few key hardware specific functions (map >> this physical address, program the page table base register). > > The standard Linux approach to such a problem is to write > a library that drivers can use for common functionality, not put a middle > layer in between. Libraries are much more flexible than layers. That's true up to the, "is this middle layer so useful that its worth it" point. The VM is a middle layer, you could make the same argument about it, "the mapping code isn't too hard, just map in the memory that you need and be done with it". But the VM middle layer provides a clean separation between page frames and pages which turns out to be infinitely useful. The VCMM is built in the same spirit, It says things like, "mapping is a global problem, I'm going to abstract entire virtual spaces and allow people arbitrary chuck size allocation, I'm not going to care that my device is physically mapping this buffer and this other device is a virtual, virtual device." > > That said I'm not sure there's all that much duplicated code anyways. > A lot of the code is always IOMMU specific. The only piece > which might be shareable is the mapping allocation, but I don't > think that's very much of a typical driver > > In my old pci-gart driver the allocation was all only a few lines of code, > although given it was somewhat dumb in this regard because it only managed a > small remapping window. I agree that its not a lot of code, and that this layer may be a bit heavy, but I'd like to focus on is a global mapping view useful and if so is something like the graph management that the VCMM provides generally useful. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 1/6] omap: add iva2 hwmod support to omap3
On 7/2/2010 12:23 AM, Ohad Ben-Cohen wrote:
From: Ohad Ben-Cohen
Add preliminary iva2 hwmod support to omap3.
We do not include iva2_clk; that will be part of a separate
hwmod, which will be controlled by iommu.
I think Kevin already sent a hwmod for IVA2... one week ago:
[PATCH 13/13] OMAP3: hwmod data: add data for OMAP3 IVA2
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Hari Kanigeri
---
arch/arm/mach-omap2/omap_hwmod_34xx.h| 23 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
b/arch/arm/mach-omap2/omap_hwmod_34xx.h
index b6076b9..d363a95 100644
--- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
+++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
@@ -22,6 +22,7 @@
#include "prm-regbits-34xx.h"
static struct omap_hwmod omap34xx_mpu_hwmod;
+static struct omap_hwmod omap34xx_iva2_hwmod;
static struct omap_hwmod omap34xx_l3_hwmod;
static struct omap_hwmod omap34xx_l4_core_hwmod;
static struct omap_hwmod omap34xx_l4_per_hwmod;
@@ -47,9 +48,17 @@ static struct omap_hwmod_ocp_if omap34xx_mpu__l3 = {
.user = OCP_USER_MPU,
};
+/* IVA2 -> L3 interface */
+static struct omap_hwmod_ocp_if omap34xx_iva2__l3 = {
+ .master =&omap34xx_iva2_hwmod,
+ .slave =&omap34xx_l3_hwmod,
+ .user = OCP_USER_IVA2,
+};
+
/* Slave interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap34xx_l3_slaves[] = {
&omap34xx_mpu__l3,
+ &omap34xx_iva2__l3,
};
/* Master interfaces on the L3 interconnect */
@@ -150,12 +159,26 @@ static struct omap_hwmod omap34xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* Master interfaces on the IVA2 device */
+static struct omap_hwmod_ocp_if *omap34xx_iva2_masters[] = {
+ &omap34xx_iva2__l3,
+};
+
+/* IVA2 */
+static struct omap_hwmod omap34xx_iva2_hwmod = {
+ .name = "iva2_hwmod",
Should be "iva" only.
+ .masters= omap34xx_iva2_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_iva2_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
&omap34xx_l3_hwmod,
&omap34xx_l4_core_hwmod,
&omap34xx_l4_per_hwmod,
&omap34xx_l4_wkup_hwmod,
&omap34xx_mpu_hwmod,
+ &omap34xx_iva2_hwmod,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 3393325..5e64992 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -160,6 +160,7 @@ struct omap_hwmod_addr_space {
*/
#define OCP_USER_MPU (1<< 0)
#define OCP_USER_SDMA (1<< 1)
+#define OCP_USER_IVA2 (1<< 2)
Are you going to use that information somewhere?
In that case, you should populate the address space view from the DSP.
Benoit
/* omap_hwmod_ocp_if.flags bits */
#define OCPIF_HAS_IDLEST (1<< 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections
Hi,
> On Thu, 2010-07-01 at 14:28 +0200, ext Taneja, Archit wrote:
> > > On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote:
> > > > From: Sumit Semwal
> > > >
> > > > The addition of the new 2lcd manager requires
> modifications in the
> > > > dss_recheck_connections patch, this function behaves the
> > > same if the
> > > > 2lcd manager doesn't exist
> > >
> > > Here (and also in the previous patch) you talk about
> 2lcd, but the
> > > code uses lcd2.
> >
> > Archit: The new manager's name defined in manager.c is 2lcd, The
> > channel's name in the enum is OMAP_DSS_CHANNEL_LCD2, and
> the overlay
> > manager enum is OMAP_DSS_OVL_MGR_LCD2.
> >
> > 2lcd as the manager name was taken so that no one makes
> mistakes while
> > reading/writing sysfs entries.
> >
> > Also, in the dss2 code we use strncmp() to compare the
> manager names
> > in overlay_manager_store(). Now, if we name the new manager
> as "lcd2",
> > consider the following scenario:
> >
> > Suppose an overlay has its manager presently set as "lcd2". Now
> > someone does a sysfs entry to make the manager as "lcd". So in this
> > case the variable buf is "lcd" and and mgr->name is "lcd2". The
> > variable len is calculated on the basis of buf ("lcd") as 3.
> >
> > So strncmp just compares the first 3 chars, and in that case "lcd"
> > and "lcd2" are the same, luckily this doesn't cause an issue as the
> > first manager fetched by omap_dss_get_overlay_manager() is
> "lcd". If
> > the manager_list was filled in some other way then this would have
> > resulted an issue.
>
> If the DSS sysfs code if broken, let's rather fix it than
> name the manager with a rather strange name, just to circumvent a bug.
>
> >
> > In my opinion, len should be calculated as:
> >
> > len = max(len, strlen(mgr->name));
> >
> > This way strncmp would work correctly in all the cases.
>
> sysfs_streq() could be used there.
I agree, I will make this change.
Archit--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
On Thu, 1 Jul 2010, Jamie Lokier wrote:
> Tony Lindgren wrote:
> > +static void __init kuser_get_tls_init(unsigned long vectors)
> > +{
> > + /*
> > +* vectors + 0xfe0 = __kuser_get_tls
> > +* vectors + 0xfe8 = hardware TLS instruction at 0x0fe8
> > +*/
> > + if (tls_emu || has_tls)
> > + memcpy((void *)vectors + 0xfe0, (void *)vectors + 0xfe8, 4);
> > +}
>
> Just a little opinion: Perhaps has_tls_reg would be a clearer name.
> All variants "have TLS" after all.
Good point.
> Also - and this isn't directly related to your change so feel free to
> ignore it - wouldn't it make more sense for the tls_emu case to use
> the memory version (and update the memory location), so that even on
> tls_emu systems, user programs which call the kuser code will run faster?
> With that change, there would be no real penalty to enabling tls_emu
> for any system that finds it useful.
No, that's not possible.
The tls_emu case was created to allow SMP system without the actual
TLS register to still work. With SMP you cannot rely on a global memory
location to hold the TLS value. And because such systems are so
"unusual" it was simpler to just do as if the TLS register was there and
then emulate it within the instruction exception handler.
Nicolas
--
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 8/9] dspbridge: add map support for big buffers
Fernando, > - for_each_sg(sgt->sgl, sg, sgt->nents, i) > - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); > + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | > + IOVMF_ELSZ_32); -- iommu_vmap does the Kernel mapping to the buffers you are mapping to DSP MMU. Why do you need Kernel mappings ? If there is no benefit in maintaining Kernel mapping I would rather call iopgtable_store_entry directly to map the entries. Thank you, Best regards, Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
> The VCMM provides a more abstract, global view with finer-grained > control of each mapping a user wants to create. For instance, the > symantics of iommu_map preclude its use in setting up just the IOMMU > side of a mapping. With a one-sided map, two IOMMU devices can be Hmm? dma_map_* does not change any CPU mappings. It only sets up DMA mapping(s). > Additionally, the current IOMMU interface does not allow users to > associate one page table with multiple IOMMUs unless the user explicitly That assumes that all the IOMMUs on the system support the same page table format, right? As I understand your approach would help if you have different IOMMus with an different low level interface, which just happen to have the same pte format. Is that very likely? I would assume if you have lots of copies of the same IOMMU in the system then you could just use a single driver with multiple instances that share some state for all of them. That model would fit in the current interfaces. There's no reason multiple instances couldn't share the same allocation data structure. And if you have lots of truly different IOMMUs then they likely won't be able to share PTEs at the hardware level anyways, because the formats are too different. > The VCMM takes the long view. Its designed for a future in which the > number of IOMMUs will go up and the ways in which these IOMMUs are > composed will vary from system to system, and may vary at > runtime. Already, there are ~20 different IOMMU map implementations in > the kernel. Had the Linux kernel had the VCMM, many of those > implementations could have leveraged the mapping and topology management > of a VCMM, while focusing on a few key hardware specific functions (map > this physical address, program the page table base register). The standard Linux approach to such a problem is to write a library that drivers can use for common functionality, not put a middle layer inbetween. Libraries are much more flexible than layers. That said I'm not sure there's all that much duplicated code anyways. A lot of the code is always IOMMU specific. The only piece which might be shareable is the mapping allocation, but I don't think that's very much of a typical driver In my old pci-gart driver the allocation was all only a few lines of code, although given it was somewhat dumb in this regard because it only managed a small remapping window. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
> The VCMM takes the long view. Its designed for a future in which the > number of IOMMUs will go up and the ways in which these IOMMUs are > composed will vary from system to system, and may vary at > runtime. Already, there are ~20 different IOMMU map implementations in > the kernel. Had the Linux kernel had the VCMM, many of those > implementations could have leveraged the mapping and topology management > of a VCMM, while focusing on a few key hardware specific functions (map > this physical address, program the page table base register). > -- Sounds good. Did you think of a way to handle the cases where one of the Device that is using the mapped address crashed ? How is the physical address unbacked in this case ? Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 6/6] omap: enable remoteproc building
From: Ohad Ben-Cohen Make it possible to build omap's remoteproc module Signed-off-by: Ohad Ben-Cohen Signed-off-by: Hari Kanigeri --- arch/arm/mach-omap2/Makefile |6 ++ arch/arm/plat-omap/Kconfig |7 +++ arch/arm/plat-omap/Makefile |1 + 3 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 307f8b0..edb65b3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -59,6 +59,12 @@ obj-$(CONFIG_OMAP3_EMU) += emu.o obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o mailbox_mach-objs := mailbox.o +ifneq ($(CONFIG_OMAP_REMOTE_PROC),) +obj-$(CONFIG_ARCH_OMAP2) += remoteproc24xx.o +obj-$(CONFIG_ARCH_OMAP3) += remoteproc3xxx.o +obj-$(CONFIG_ARCH_OMAP4) += remoteproc44xx.o +endif + iommu-y+= iommu2.o iommu-$(CONFIG_ARCH_OMAP3) += omap3-iommu.o diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e2ea04a..e7d7372 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -96,6 +96,13 @@ config OMAP_MBOX_FWK Say Y here if you want to use OMAP Mailbox framework support for DSP, IVA1.0 and IVA2 in OMAP1/2/3. +config OMAP_REMOTE_PROC + bool "Remote Processor framework support" + depends on ARCH_OMAP + help + Say Y here if you want to use OMAP Remote Processor framework + support for DSP, Tesla and/or Ducati (OMAP3/4). + config OMAP_IOMMU tristate diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 98f0191..bacb5c3 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -29,5 +29,6 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) # OMAP mailbox framework obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o +obj-$(CONFIG_OMAP_REMOTE_PROC) += remoteproc.o obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o \ No newline at end of file -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/6] omap: add remoteproc device(s)
From: Ohad Ben-Cohen
Add an omap_device for each remote processor on the system
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Hari Kanigeri
---
arch/arm/mach-omap2/devices.c | 86 +
1 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 18ad931..d365db6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -26,9 +27,13 @@
#include
#include
#include
+#include
#include "mux.h"
+#include
+#include
+
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
static struct resource cam_resources[] = {
@@ -136,6 +141,86 @@ static inline void omap_init_camera(void)
}
#endif
+#if defined(CONFIG_OMAP_REMOTE_PROC) || defined(CONFIG_OMAP_REMOTE_PROC_MODULE)
+static struct omap_device_pm_latency omap_rproc_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .deactivate_lat = 1,
+ .activate_lat = 1,
+ },
+};
+
+static struct omap_rproc_platform_data *omap_get_remoteproc_data(void)
+{
+ struct omap_rproc_platform_data *rproc_data = NULL;
+
+ if (cpu_is_omap3430() || cpu_is_omap3630())
+ rproc_data = omap3_get_rproc_data();
+ else if (cpu_is_omap44xx())
+ rproc_data = omap4_get_rproc_data();
+ else
+ pr_err("%s: platform not supported\n", __func__);
+
+ return rproc_data;
+}
+
+int omap_get_num_of_remoteproc(void)
+{
+ int num = -1;
+
+ if (cpu_is_omap3430() || cpu_is_omap3630())
+ num = omap3_get_rproc_data_size();
+ else if (cpu_is_omap44xx())
+ num = omap4_get_rproc_data_size();
+ else
+ pr_err("%s: platform not supported\n", __func__);
+
+ return num;
+}
+EXPORT_SYMBOL(omap_get_num_of_remoteproc);
+
+static inline void omap_init_rproc(void)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ struct omap_device_pm_latency *ohl;
+ char *oh_name, *pdev_name;
+ int ohl_cnt = 0, i;
+ int rproc_data_size;
+ struct omap_rproc_platform_data *rproc_data;
+
+ pdev_name = "omap-rproc";
+ ohl = omap_rproc_latency;
+ ohl_cnt = ARRAY_SIZE(omap_rproc_latency);
+
+ rproc_data = omap_get_remoteproc_data();
+ rproc_data_size = omap_get_num_of_remoteproc();
+ if (rproc_data == NULL || rproc_data_size <= 0) {
+ pr_err("%s: platform not supported\n", __func__);
+ return;
+ }
+
+ for (i = 0; i < rproc_data_size; i++) {
+ oh_name = rproc_data[i].oh_name;
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("%s: could not look up %s\n", __func__, oh_name);
+ continue;
+ }
+
+ od = omap_device_build(pdev_name, i, oh,
+ &rproc_data[i],
+ sizeof(struct omap_rproc_platform_data),
+ ohl, ohl_cnt);
+ WARN(IS_ERR(od), "Could not build omap_device for %s %s\n",
+ pdev_name, oh_name);
+ }
+}
+#else
+static inline void omap_init_rproc(void) { }
+#endif /* CONFIG_OMAP_REMOTE_PROC */
+
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
#define MBOX_REG_SIZE 0x120
@@ -773,6 +858,7 @@ static int __init omap2_init_devices(void)
omap_hsmmc_reset();
omap_init_camera();
omap_init_mbox();
+ omap_init_rproc();
omap_init_mcspi();
omap_hdq_init();
omap_init_sti();
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/6] omap: introduce common remoteproc module
From: Ohad Ben-Cohen
The OMAP remote processor module decouples
machine-specific code from TI's IPC
drivers (e.g. dspbridge and syslink).
While dspbridge calls the remoteproc handlers
from the kernel, syslink calls them from
user space. Hence remoteproc supports both
interfaces.
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Hari Kanigeri
---
arch/arm/plat-omap/include/plat/remoteproc.h | 75 ++
arch/arm/plat-omap/remoteproc.c | 316 ++
2 files changed, 391 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h
create mode 100644 arch/arm/plat-omap/remoteproc.c
diff --git a/arch/arm/plat-omap/include/plat/remoteproc.h
b/arch/arm/plat-omap/include/plat/remoteproc.h
new file mode 100644
index 000..1cedd08
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/remoteproc.h
@@ -0,0 +1,75 @@
+/*
+ * OMAP Remote Processor driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * Written by Ohad Ben-Cohen
+ *
+ * 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
+ *
+ */
+
+#ifndef REMOTEPROC_H
+#define REMOTEPROC_H
+
+#include
+#include
+
+#define RPROC_IOC_MAGIC'P'
+
+#define RPROC_IOCSTART _IOW(RPROC_IOC_MAGIC, 1, int)
+#define RPROC_IOCSTOP _IO(RPROC_IOC_MAGIC, 2)
+#define RPROC_IOCGETSTATE _IOR(RPROC_IOC_MAGIC, 3, int)
+
+#define RPROC_IOC_MAXNR(3)
+
+struct omap_rproc;
+
+struct omap_rproc_ops {
+ int (*start)(struct device *dev, u32 start_addr);
+ int (*stop)(struct device *dev);
+ int (*get_state)(struct device *dev);
+};
+
+struct omap_rproc_clk_t {
+ void *clk_handle;
+ const char *dev_id;
+ const char *con_id;
+};
+
+struct omap_rproc_platform_data {
+ struct omap_rproc_ops *ops;
+ char *name;
+ char *oh_name;
+};
+
+struct omap_rproc {
+ struct device *dev;
+ struct cdev cdev;
+ atomic_t count;
+ int minor;
+};
+
+struct omap_rproc_start_args {
+ u32 start_addr;
+};
+
+struct omap_rproc_platform_data *omap3_get_rproc_data(void);
+int omap3_get_rproc_data_size(void);
+struct omap_rproc_platform_data *omap4_get_rproc_data(void);
+int omap4_get_rproc_data_size(void);
+int omap_get_num_of_remoteproc(void);
+
+#endif /* REMOTEPROC_H */
diff --git a/arch/arm/plat-omap/remoteproc.c b/arch/arm/plat-omap/remoteproc.c
new file mode 100644
index 000..7a9862e
--- /dev/null
+++ b/arch/arm/plat-omap/remoteproc.c
@@ -0,0 +1,316 @@
+/*
+ * OMAP Remote Processor driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * Authors:
+ * Ohad Ben-Cohen
+ * Hari Kanigeri
+ *
+ * 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
+
+#define OMAP_RPROC_NAME "omap-rproc"
+
+static struct class *omap_rproc_class;
+static dev_t omap_rproc_dev;
+static atomic_t num_of_rprocs;
+
+static inline int rproc_start(struct omap_rproc *rproc, const void __user *arg)
+{
+ struct omap_rproc_platform_data *pdata;
+ struct omap_rproc_start_args start_args;
+
+ if (!rproc->dev)
+ return -EINVAL;
+
+ pdata = rproc->dev->platform_data;
+ if (!pdata->ops)
+ return -EINVAL;
+
+ if (copy_from_user(&start_args, arg, sizeof(start_args)))
+ return -EFAULT;
+
+ return pdata->ops->start(rproc->dev, start_args.start_addr);
+}
+
+static inline int rproc_stop(struct omap_rproc *rproc)
+{
+ struct omap_rproc_platform_data *pdata;
+ if (!rproc->dev)
+ return -EINVAL;
+
+ pdata = rproc->dev->platform_data;
+ if (!pdata->ops)
+ return -EINVAL;
+
+ return pdat
[RFC 3/6] omap: introduce OMAP4 remoteproc module
From: Hari Kanigeri
Introduce OMAP4 machine-dependent module required
for starting and stopping the OMAP3 remote processors.
Signed-off-by: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/remoteproc44xx.c | 196 ++
1 files changed, 196 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c
diff --git a/arch/arm/mach-omap2/remoteproc44xx.c
b/arch/arm/mach-omap2/remoteproc44xx.c
new file mode 100644
index 000..e240595
--- /dev/null
+++ b/arch/arm/mach-omap2/remoteproc44xx.c
@@ -0,0 +1,196 @@
+/*
+ * Remote Processor machine-specific module for OMAP4
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * 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
+ *
+ */
+/* this is needed for multi-omap support */
+#ifdef CONFIG_ARCH_OMAP4
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cm.h"
+#include "prm.h"
+
+#define RM_M3_RST1ST 0x1
+#define RM_M3_RST2ST 0x2
+#define RM_M3_RST3ST 0x4
+#define RM_M3_REL_RST1_MASK0x2
+#define RM_M3_REL_RST2_MASK0x0
+#define RM_M3_AST_RST1_MASK0x3
+#define RM_M3_AST_RST2_MASK0x2
+
+#define M3_CLK_MOD_MODE_HW_AUTO0x1
+#define M3_CLKTRCTRL_SW_WKUP 0x2
+#define M3_CLKTRCTRL_SW_SLEEP 0x1
+#define M3_CLKACTIVITY_MPU_M3_CLK 0x100
+
+static inline int omap4_rproc_get_state(struct omap_rproc *rproc)
+{
+ return rproc->state;
+}
+
+static inline int proc44x_sysm3_start(struct device *dev, u32 start_addr)
+{
+ u32 reg;
+ int counter = 10;
+
+ /* Module is managed automatically by HW */
+ cm_write_mod_reg(M3_CLK_MOD_MODE_HW_AUTO, OMAP4430_CM2_CORE_MOD,
+ OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET);
+
+ /* Enable the M3 clock */
+ cm_write_mod_reg(M3_CLKTRCTRL_SW_WKUP, OMAP4430_CM2_CORE_MOD,
+ OMAP4_CM_DUCATI_CLKSTCTRL_OFFSET);
+ do {
+ reg = cm_read_mod_reg(OMAP4430_CM2_CORE_MOD,
+ OMAP4_CM_DUCATI_CLKSTCTRL_OFFSET);
+ if (reg & M3_CLKACTIVITY_MPU_M3_CLK) {
+ dev_info(dev, "M3 clock enabled:"
+ "OMAP4430_CM_DUCATI_CLKSTCTRL = 0x%x\n", reg);
+ break;
+ }
+ msleep(1);
+ } while (--counter);
+ if (counter == 0) {
+ dev_info(dev, "FAILED TO ENABLE DUCATI M3 CLOCK !%x\n", reg);
+ return -EFAULT;
+ }
+
+ /* De-assert RST1, and clear the Reset status */
+ dev_info(dev, "De-assert RST1\n");
+ prm_write_mod_reg(RM_M3_REL_RST1_MASK, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTCTRL_OFFSET);
+ while (!(prm_read_mod_reg(OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTST_OFFSET) & RM_M3_RST1ST))
+ ;
+ dev_info(dev, "RST1 released!");
+
+ prm_write_mod_reg(RM_M3_RST1ST, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTST_OFFSET);
+
+ return 0;
+}
+
+static inline int proc44x_appm3_start(struct device *dev, u32 start_addr)
+{
+ /* De-assert RST2, and clear the Reset status */
+ dev_info(dev, "De-assert RST2\n");
+ prm_write_mod_reg(RM_M3_REL_RST2_MASK, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTCTRL_OFFSET);
+
+ while (!(prm_read_mod_reg(OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTST_OFFSET) & RM_M3_RST2ST))
+ ;
+ dev_info(dev, "RST2 released!");
+
+ prm_write_mod_reg(RM_M3_RST2ST, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTST_OFFSET);
+
+ return 0;
+}
+
+static inline int proc44x_sysm3_stop(struct device *dev)
+{
+ dev_info(dev, "assert RST1\n");
+ prm_write_mod_reg(RM_M3_AST_RST1_MASK, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTCTRL_OFFSET);
+ /* Disable the M3 clock */
+ cm_write_mod_reg(M3_CLKTRCTRL_SW_SLEEP, OMAP4430_CM2_CORE_MOD,
+ OMAP4_CM_DUCATI_CLK
[RFC 2/6] omap: introduce OMAP3 remoteproc module
From: Ohad Ben-Cohen
Introduce OMAP3 remoteproc module which takes care of
machine-specific code required to start and stop
the DSP remote processor.
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Hari Kanigeri
---
arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++
1 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c
diff --git a/arch/arm/mach-omap2/remoteproc3xxx.c
b/arch/arm/mach-omap2/remoteproc3xxx.c
new file mode 100644
index 000..f86a333
--- /dev/null
+++ b/arch/arm/mach-omap2/remoteproc3xxx.c
@@ -0,0 +1,226 @@
+/*
+ * Remote Processor machine-specific module for OMAP3
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * 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
+ *
+ */
+
+/* this is needed for multi-omap support */
+#ifdef CONFIG_ARCH_OMAP3
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cm-regbits-34xx.h"
+#include "prm-regbits-34xx.h"
+
+#define OMAP3_IVA2_BOOTADDR_MASK 0xFC00
+
+#define PRCM_PM_PWSTCTRL_IVA2_POWER_STATE_MASK (u32)(3)
+#define PRCM_PM_PWSTCTRL_IVA2_POWER_STATE_OFFSET (u32)(0)
+
+#define PRCM_PM_PWSTST_IVA2_InTransition_MASK (u32)(0x10)
+#define PRCM_PM_PWSTST_IVA2_InTransition_OFFSET(u32)(20)
+
+#define CM_CLKSTCTRL_IVA2_OFFSET (0)
+#define CM_CLKSTCTRL_IVA2_MASK (3)
+
+#define DSP_SYSC_DIRECTBOOT(0)
+#define DSP_SYSC_IDLEBOOT (1)
+#define DSP_SYSC_SELFLOOPBOOT (2)
+#define DSP_SYSC_USRBOOTSTRAP (3)
+#define DSP_SYSC_DEFAULTRESTORE(4)
+
+#ifdef CONFIG_BRIDGE_DEBUG
+static void omap3_rproc_dump_regs(struct device *dev)
+{
+ u32 temp;
+
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_FCLKEN);
+ dev_info(dev, "CM_FCLKEN_IVA2 = 0x%x \n", temp);
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_ICLKEN1);
+ dev_info(dev, "CM_ICLKEN1_IVA2 = 0x%x \n", temp);
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_IDLEST);
+ dev_info(dev, "CM_IDLEST_IVA2 = 0x%x \n", temp);
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
+ dev_info(dev, "CM_CLKSTCTRL_IVA2 = 0x%x \n", temp);
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, OMAP3430_CM_CLKSTST);
+ dev_info(dev, "CM_CLKSTST_IVA2 = 0x%x \n", temp);
+ temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, RM_RSTCTRL);
+ dev_info(dev, "RM_RSTCTRL_IVA2 = 0x%x \n", temp);
+ temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, RM_RSTST);
+ dev_info(dev, "RM_RSTST_IVA2 = 0x%x \n", temp);
+ temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTCTRL);
+ dev_info(dev, "PM_PWSTCTRL_IVA2 = 0x%x \n", temp);
+ temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTST);
+ dev_info(dev, "PM_PWSTST_IVA2 = 0x%x \n", temp);
+ temp = cm_read_mod_reg(CORE_MOD, CM_ICLKEN1);
+ dev_info(dev, "CM_ICLKEN1_CORE = 0x%x \n", temp);
+}
+#else
+static void omap3_rproc_dump_regs(struct device *dev) { }
+#endif
+
+static int omap3_rproc_get_state(struct device *dev)
+{
+ u32 dsp_pwr_state;
+
+ dsp_pwr_state = prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTST);
+
+ return dsp_pwr_state & OMAP_POWERSTATEST_MASK;
+}
+
+static int omap3_rproc_start(struct device *dev, u32 start_addr)
+{
+ dev_info(dev, "%s: set boot mode, addr: 0x%x\n", __func__, start_addr);
+
+ omap3_rproc_dump_regs(dev);
+
+ if (PWRDM_POWER_ON != omap3_rproc_get_state(dev)) {
+ /* IVA2 is not in ON state */
+ /* Read and set PM_PWSTCTRL_IVA2 to ON */
+ prm_rmw_mod_reg_bits(OMAP_POWERSTATEST_MASK, PWRDM_POWER_ON,
+ OMAP3430_IVA2_MOD, PM_PWSTCTRL);
+
+ /* Set the SW supervised state transition */
+ cm_write_mod_reg(OMAP34XX_CLKSTCTRL_FORCE_WAKEUP,
+ OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
+
+ /* Wait until the state has moved to ON */
+ while (prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTST)
+ & OMAP_INTRANSITION)
+ ;
+
+ /* Disable Automatic transition */
+ cm_write_mod_reg(OMAP34XX_CLKSTCT
[RFC 1/6] omap: add iva2 hwmod support to omap3
From: Ohad Ben-Cohen
Add preliminary iva2 hwmod support to omap3.
We do not include iva2_clk; that will be part of a separate
hwmod, which will be controlled by iommu.
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Hari Kanigeri
---
arch/arm/mach-omap2/omap_hwmod_34xx.h| 23 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
b/arch/arm/mach-omap2/omap_hwmod_34xx.h
index b6076b9..d363a95 100644
--- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
+++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
@@ -22,6 +22,7 @@
#include "prm-regbits-34xx.h"
static struct omap_hwmod omap34xx_mpu_hwmod;
+static struct omap_hwmod omap34xx_iva2_hwmod;
static struct omap_hwmod omap34xx_l3_hwmod;
static struct omap_hwmod omap34xx_l4_core_hwmod;
static struct omap_hwmod omap34xx_l4_per_hwmod;
@@ -47,9 +48,17 @@ static struct omap_hwmod_ocp_if omap34xx_mpu__l3 = {
.user = OCP_USER_MPU,
};
+/* IVA2 -> L3 interface */
+static struct omap_hwmod_ocp_if omap34xx_iva2__l3 = {
+ .master = &omap34xx_iva2_hwmod,
+ .slave = &omap34xx_l3_hwmod,
+ .user = OCP_USER_IVA2,
+};
+
/* Slave interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap34xx_l3_slaves[] = {
&omap34xx_mpu__l3,
+ &omap34xx_iva2__l3,
};
/* Master interfaces on the L3 interconnect */
@@ -150,12 +159,26 @@ static struct omap_hwmod omap34xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* Master interfaces on the IVA2 device */
+static struct omap_hwmod_ocp_if *omap34xx_iva2_masters[] = {
+ &omap34xx_iva2__l3,
+};
+
+/* IVA2 */
+static struct omap_hwmod omap34xx_iva2_hwmod = {
+ .name = "iva2_hwmod",
+ .masters= omap34xx_iva2_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_iva2_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
&omap34xx_l3_hwmod,
&omap34xx_l4_core_hwmod,
&omap34xx_l4_per_hwmod,
&omap34xx_l4_wkup_hwmod,
&omap34xx_mpu_hwmod,
+ &omap34xx_iva2_hwmod,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 3393325..5e64992 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -160,6 +160,7 @@ struct omap_hwmod_addr_space {
*/
#define OCP_USER_MPU (1 << 0)
#define OCP_USER_SDMA (1 << 1)
+#define OCP_USER_IVA2 (1 << 2)
/* omap_hwmod_ocp_if.flags bits */
#define OCPIF_HAS_IDLEST (1 << 0)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/6] Introducing OMAP Remote Processor module
From: Ohad Ben-Cohen This is a preliminary version of OMAP's remoteproc module, submitted for RFC purposes. The purpose of the remoteproc module is to decouple hw-specific code from generic IPC drivers (such as dspbridge and syslink), in order to eventually make those IPC drivers platform-independent. Currently the supported operations are starting and stopping the remote processor, but in the future additional functionality might be added. Both OMAP3 and OMAP4 are supported; OMAP3 supports the dsp remote processor, and OMAP4 supports ducati (tesla support is planned as well). The code was tested on both OMAP3 (using dspbridge) and OMAP4 (using syslink). The code is preliminary: we plan to add much more extensive hwmod support, ideally squashing as much hw-specific code as possible (including RST and PRCM manipulations). In addition, a rebase to recent code bases is needed. While dspbridge accesses remoteproc's interface via pdata pointers, syslink accesses it from user space, via character device interface, so both kernel and user space interfaces are supported. A few words on the char device interface: * Each remote processor is represented by a different character device: /dev/omap-rproc0, /dev/omap-rproc1, ... * A rproc character device can only be opened by a single user (e.g. the syslink daemon) * The start/stop/get_state functionality is exposed via ioctl's * We plan to add automatic stop() invokation in case the user closes the device after starting a remote processor (for resource cleanup purposes. Thus the user will be required to hold the device open as long as it lives). Thanks, Hari Kanigeri (1): omap: introduce OMAP4 remoteproc module Ohad Ben-Cohen (5): omap: add iva2 hwmod support to omap3 omap: introduce OMAP3 remoteproc module omap: introduce common remoteproc module omap: add remoteproc device(s) omap: enable remoteproc building arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/devices.c| 86 +++ arch/arm/mach-omap2/omap_hwmod_34xx.h| 23 ++ arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++ arch/arm/mach-omap2/remoteproc44xx.c | 196 arch/arm/plat-omap/Kconfig |7 + arch/arm/plat-omap/Makefile |1 + arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/include/plat/remoteproc.h | 75 ++ arch/arm/plat-omap/remoteproc.c | 316 ++ 10 files changed, 937 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h create mode 100644 arch/arm/plat-omap/remoteproc.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
> > He demonstrated the usage of his code in one of the emails he sent out > initially. Did you go over that, and what (or how many) step would you > use with the current code to do the same thing? -- So is this patch set adding layers and abstractions to help the User ? If the idea is to share some memory across multiple devices, I guess you can achieve the same by calling the map function provided by iommu module and sharing the mapped address to the 10's or 100's of devices to access the buffers. You would only need a dedicated virtual pool per IOMMU device to manage its virtual memory allocations. Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, 2010-07-01 at 15:00 -0700, Zach Pfeffer wrote: > Additionally, the current IOMMU interface does not allow users to > associate one page table with multiple IOMMUs unless the user explicitly > wrote a muxed device underneith the IOMMU interface. This also could be > done, but would have to be done for every such use case. Since the > particular topology is run-time configurable all of these use-cases and > more can be expressed without pushing the topology into the low-level > IOMMU driver. > > The VCMM takes the long view. Its designed for a future in which the > number of IOMMUs will go up and the ways in which these IOMMUs are > composed will vary from system to system, and may vary at > runtime. Already, there are ~20 different IOMMU map implementations in > the kernel. Had the Linux kernel had the VCMM, many of those > implementations could have leveraged the mapping and topology management > of a VCMM, while focusing on a few key hardware specific functions (map > this physical address, program the page table base register). So if we include this code which "map implementations" could you collapse into this implementations ? Generally , what currently existing code can VCMM help to eliminate? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Andi Kleen wrote: >>> Also for me it's still quite unclear why we would want this code at all... >>> It doesn't seem to do anything you couldn't do with the existing interfaces. >> I don't know all that much about what Zach's done here, but from what >> he's said so far it looks like this help to manage lots of IOMMUs on a >> single system.. On x86 it seems like there's not all that many IOMMUs in >> comparison .. Zach mentioned 10 to 100 IOMMUs .. > > The current code can manage multiple IOMMUs fine. That's fair. The current code does manage multiple IOMMUs without issue for a static map topology. Its core function 'map' maps a physical chunk of some size into a IOMMU's address space and the kernel's address space for some domain. The VCMM provides a more abstract, global view with finer-grained control of each mapping a user wants to create. For instance, the symantics of iommu_map preclude its use in setting up just the IOMMU side of a mapping. With a one-sided map, two IOMMU devices can be pointed to the same physical memory without mapping that same memory into the kernel's address space. Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs unless the user explicitly wrote a muxed device underneith the IOMMU interface. This also could be done, but would have to be done for every such use case. Since the particular topology is run-time configurable all of these use-cases and more can be expressed without pushing the topology into the low-level IOMMU driver. The VCMM takes the long view. Its designed for a future in which the number of IOMMUs will go up and the ways in which these IOMMUs are composed will vary from system to system, and may vary at runtime. Already, there are ~20 different IOMMU map implementations in the kernel. Had the Linux kernel had the VCMM, many of those implementations could have leveraged the mapping and topology management of a VCMM, while focusing on a few key hardware specific functions (map this physical address, program the page table base register). -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On 07/01/10 13:59, Paul Walmsley wrote: > Randy, > > On Thu, 1 Jul 2010, Randy Dunlap wrote: > >>> + * @start_addr The starting address of the VCM region. >>> + * @lenThe len of the VCM region. This must be at least >>> + * vcm_min() bytes. >> >> and missing lots of struct members here. >> If some of them are private, you can use: >> >> /* private: */ >> ... >> /* public: */ >> comments in the struct below and then don't add the private ones to the >> kernel-doc notation above. > > To avoid wasting space in structures, it makes sense to place fields > smaller than the alignment width together in the structure definition. > If one were to do this and follow your proposal, some structures may need > multiple "private" and "public" comments, which seems undesirable. The > alternative, wasting memory, also seems undesirable. Perhaps you might > have a proposal for a way to resolve this? I don't know of a really good way. There are a few structs that have multiple private/public entries, and that is OK. Or you can describe all of the entries with kernel-doc notation. Or you can choose not to use kernel-doc notation on some structs. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Randy, On Thu, 1 Jul 2010, Randy Dunlap wrote: > > + * @start_addr The starting address of the VCM region. > > + * @lenThe len of the VCM region. This must be at least > > + * vcm_min() bytes. > > and missing lots of struct members here. > If some of them are private, you can use: > > /* private: */ > ... > /* public: */ > comments in the struct below and then don't add the private ones to the > kernel-doc notation above. To avoid wasting space in structures, it makes sense to place fields smaller than the alignment width together in the structure definition. If one were to do this and follow your proposal, some structures may need multiple "private" and "public" comments, which seems undesirable. The alternative, wasting memory, also seems undesirable. Perhaps you might have a proposal for a way to resolve this? - 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 0/2] pandora updates for .36
Grazvydas Ignotas wrote: > > Hi Tony, > > here are some updates for Pandora, which we have now around 700 units > shipped (finally!) after years of developemt hell. More are being > made at the moment. > Neat! Hope you sell a zillion. I'll try and buy one someday. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] pandora updates for .36
On Thu, 1 Jul 2010, Grazvydas Ignotas wrote: > here are some updates for Pandora, which we have now around 700 units > shipped (finally!) after years of developemt hell. More are being > made at the moment. Woohoo! Congratulations to you and the rest of the team :-) - 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
[PATCH 2/2] omap3: pandora: add NAND and wifi support
Add platform data for NAND and wifi, also setup all GPIOs
needed to use the wifi chip.
Signed-off-by: Grazvydas Ignotas
---
arch/arm/mach-omap2/board-omap3pandora.c | 121 ++
1 files changed, 121 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 6131d98..690e0a7 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -29,7 +29,10 @@
#include
#include
#include
+#include
#include
+#include
+#include
#include
#include
@@ -42,13 +45,50 @@
#include
#include
#include
+#include
#include "mux.h"
#include "sdram-micron-mt46h32m32lf-6.h"
#include "hsmmc.h"
+#define PANDORA_WIFI_IRQ_GPIO 21
+#define PANDORA_WIFI_NRESET_GPIO 23
#define OMAP3_PANDORA_TS_GPIO 94
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition omap3pandora_nand_partitions[] = {
+ {
+ .name = "xloader",
+ .offset = 0,
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE
+ }, {
+ .name = "uboot",
+ .offset = MTDPART_OFS_APPEND,
+ .size = 15 * NAND_BLOCK_SIZE,
+ }, {
+ .name = "uboot-env",
+ .offset = MTDPART_OFS_APPEND,
+ .size = 1 * NAND_BLOCK_SIZE,
+ }, {
+ .name = "boot",
+ .offset = MTDPART_OFS_APPEND,
+ .size = 80 * NAND_BLOCK_SIZE,
+ }, {
+ .name = "rootfs",
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data pandora_nand_data = {
+ .cs = 0,
+ .devsize= 1,/* '0' for 8-bit, '1' for 16-bit device */
+ .parts = omap3pandora_nand_partitions,
+ .nr_parts = ARRAY_SIZE(omap3pandora_nand_partitions),
+};
+
static struct gpio_led pandora_gpio_leds[] = {
{
.name = "pandora::sd1",
@@ -254,6 +294,7 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .ocr_mask = 0x80, /* MMC_VDD_165_195 */
.init_card = pandora_wl1251_init_card,
},
{} /* Terminator */
@@ -262,12 +303,33 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
static int omap3pandora_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int ret, gpio_32khz;
+
/* gpio + {0,1} is "mmc{0,1}_cd" (input/IRQ) */
omap3pandora_mmc[0].gpio_cd = gpio + 0;
omap3pandora_mmc[1].gpio_cd = gpio + 1;
omap2_hsmmc_init(omap3pandora_mmc);
+ /* gpio + 13 drives 32kHz buffer for wifi module */
+ gpio_32khz = gpio + 13;
+ ret = gpio_request(gpio_32khz, "wifi 32kHz");
+ if (ret < 0) {
+ pr_err("Cannot get GPIO line %d, ret=%d\n", gpio_32khz, ret);
+ goto fail;
+ }
+
+ ret = gpio_direction_output(gpio_32khz, 1);
+ if (ret < 0) {
+ pr_err("Cannot set GPIO line %d, ret=%d\n", gpio_32khz, ret);
+ goto fail_direction;
+ }
+
return 0;
+
+fail_direction:
+ gpio_free(gpio_32khz);
+fail:
+ return -ENODEV;
}
static struct twl4030_gpio_platform_data omap3pandora_gpio_data = {
@@ -546,10 +608,67 @@ static void __init omap3pandora_init_irq(void)
omap_gpio_init();
}
+static void pandora_wl1251_set_power(bool enable)
+{
+ /*
+* Keep power always on until wl1251_sdio driver learns to re-init
+* the chip after powering it down and back up.
+*/
+}
+
+static struct wl12xx_platform_data pandora_wl1251_pdata = {
+ .set_power = pandora_wl1251_set_power,
+ .use_eeprom = true,
+};
+
+static struct platform_device pandora_wl1251_data = {
+ .name = "wl1251_data",
+ .id = -1,
+ .dev= {
+ .platform_data = &pandora_wl1251_pdata,
+ },
+};
+
+static void pandora_wl1251_init(void)
+{
+ int ret;
+
+ ret = gpio_request(PANDORA_WIFI_IRQ_GPIO, "wl1251 irq");
+ if (ret < 0)
+ goto fail;
+
+ ret = gpio_direction_input(PANDORA_WIFI_IRQ_GPIO);
+ if (ret < 0)
+ goto fail_irq;
+
+ pandora_wl1251_pdata.irq = gpio_to_irq(PANDORA_WIFI_IRQ_GPIO);
+ if (pandora_wl1251_pdata.irq < 0)
+ goto fail_irq;
+
+ ret = gpio_request(PANDORA_WIFI_NRESET_GPIO, "wl1251 nreset");
+ if (ret < 0)
+ goto fail_irq;
+
+ /* start pow
[PATCH 1/2] omap3: pandora: update gpio-keys data
Update gpio-keys setup so it matches what is on default firmware.
Also make use of debounce feature in gpio-keys instead of setting it
explicitly, as gpio-keys is now capable of using hardware debounce on
OMAPs thanks to recent gpiolib changes.
Also fix a sparce warning along the way.
Signed-off-by: Grazvydas Ignotas
---
arch/arm/mach-omap2/board-omap3pandora.c | 30 ++
1 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index ebbfb49..6131d98 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -49,9 +49,6 @@
#define OMAP3_PANDORA_TS_GPIO 94
-/* hardware debounce: (value + 1) * 31us */
-#define GPIO_DEBOUNCE_TIME 127
-
static struct gpio_led pandora_gpio_leds[] = {
{
.name = "pandora::sd1",
@@ -89,6 +86,7 @@ static struct platform_device pandora_leds_gpio = {
.type = ev_type, \
.code = ev_code, \
.active_low = act_low, \
+ .debounce_interval = 4, \
.desc = "btn " descr, \
}
@@ -100,14 +98,14 @@ static struct gpio_keys_button pandora_gpio_keys[] = {
GPIO_BUTTON_LOW(103,KEY_DOWN, "down"),
GPIO_BUTTON_LOW(96, KEY_LEFT, "left"),
GPIO_BUTTON_LOW(98, KEY_RIGHT, "right"),
- GPIO_BUTTON_LOW(109,KEY_KP1,"game 1"),
- GPIO_BUTTON_LOW(111,KEY_KP2,"game 2"),
- GPIO_BUTTON_LOW(106,KEY_KP3,"game 3"),
- GPIO_BUTTON_LOW(101,KEY_KP4,"game 4"),
- GPIO_BUTTON_LOW(102,BTN_TL, "l"),
- GPIO_BUTTON_LOW(97, BTN_TL2,"l2"),
- GPIO_BUTTON_LOW(105,BTN_TR, "r"),
- GPIO_BUTTON_LOW(107,BTN_TR2,"r2"),
+ GPIO_BUTTON_LOW(109,KEY_PAGEUP, "game 1"),
+ GPIO_BUTTON_LOW(111,KEY_END,"game 2"),
+ GPIO_BUTTON_LOW(106,KEY_PAGEDOWN, "game 3"),
+ GPIO_BUTTON_LOW(101,KEY_HOME, "game 4"),
+ GPIO_BUTTON_LOW(102,KEY_RIGHTSHIFT, "l"),
+ GPIO_BUTTON_LOW(97, KEY_KPPLUS, "l2"),
+ GPIO_BUTTON_LOW(105,KEY_RIGHTCTRL, "r"),
+ GPIO_BUTTON_LOW(107,KEY_KPMINUS,"r2"),
GPIO_BUTTON_LOW(104,KEY_LEFTCTRL, "ctrl"),
GPIO_BUTTON_LOW(99, KEY_MENU, "menu"),
GPIO_BUTTON_LOW(176,KEY_COFFEE, "hold"),
@@ -128,14 +126,7 @@ static struct platform_device pandora_keys_gpio = {
},
};
-static void __init pandora_keys_gpio_init(void)
-{
- /* set debounce time for GPIO banks 4 and 6 */
- gpio_set_debounce(32 * 3, GPIO_DEBOUNCE_TIME);
- gpio_set_debounce(32 * 5, GPIO_DEBOUNCE_TIME);
-}
-
-static int board_keymap[] = {
+static const uint32_t board_keymap[] = {
/* row, col, code */
KEY(0, 0, KEY_9),
KEY(0, 1, KEY_8),
@@ -598,7 +589,6 @@ static void __init omap3pandora_init(void)
ARRAY_SIZE(omap3pandora_spi_board_info));
omap3pandora_ads7846_init();
usb_ehci_init(&ehci_pdata);
- pandora_keys_gpio_init();
usb_musb_init(&musb_board_data);
/* Ensure SDRC pins are mux'd for self-refresh */
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] pandora updates for .36
Hi Tony, here are some updates for Pandora, which we have now around 700 units shipped (finally!) after years of developemt hell. More are being made at the moment. Patch 2/2 has incorporated my last patch that missed the last merge window, and depends on "pass wl1251 information to SDIO core" [1], will rebase if that one does not get through. The NAND portion assumes Sukumar's NAND/GMPC cleanup patches are incorporated as it doesn't set up those gpmc*_baseaddr variables. 1: http://marc.info/?l=linux-omap&m=127781938327423&w=2 Grazvydas Ignotas (2): omap3: pandora: update gpio-keys data omap3: pandora: add NAND and wifi support arch/arm/mach-omap2/board-omap3pandora.c | 149 ++ 1 files changed, 130 insertions(+), 19 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: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, 2010-07-01 at 21:38 +0200, Andi Kleen wrote: > > > > > Also for me it's still quite unclear why we would want this code at all... > > > It doesn't seem to do anything you couldn't do with the existing > > > interfaces. > > > > I don't know all that much about what Zach's done here, but from what > > he's said so far it looks like this help to manage lots of IOMMUs on a > > single system.. On x86 it seems like there's not all that many IOMMUs in > > comparison .. Zach mentioned 10 to 100 IOMMUs .. > > The current code can manage multiple IOMMUs fine. He demonstrated the usage of his code in one of the emails he sent out initially. Did you go over that, and what (or how many) step would you use with the current code to do the same thing? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, Jul 01, 2010 at 12:28:23PM -0700, Daniel Walker wrote: > On Thu, 2010-07-01 at 20:02 +0200, Andi Kleen wrote: > > > What license (name/type) is this? > > > > IANAL, but AFAIK standard wisdom is that "disclaimer in the documentation > > and/or other materials provided" is generally not acceptable for Linux > > because it's an excessive burden for all distributors. > > It's the BSD license .. It's the old version of the BSD license that noone uses anymore because of its ] problems: it's really a unreasonable burden to include hundreds or thousands of attributions for every contributor in every printed manual you ship. The BSDs have all switched to the "Clause 2" (without this one) because of this. > > > Also for me it's still quite unclear why we would want this code at all... > > It doesn't seem to do anything you couldn't do with the existing interfaces. > > I don't know all that much about what Zach's done here, but from what > he's said so far it looks like this help to manage lots of IOMMUs on a > single system.. On x86 it seems like there's not all that many IOMMUs in > comparison .. Zach mentioned 10 to 100 IOMMUs .. The current code can manage multiple IOMMUs fine. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, 2010-07-01 at 20:02 +0200, Andi Kleen wrote: > > What license (name/type) is this? > > IANAL, but AFAIK standard wisdom is that "disclaimer in the documentation > and/or other materials provided" is generally not acceptable for Linux > because it's an excessive burden for all distributors. It's the BSD license .. > Also for me it's still quite unclear why we would want this code at all... > It doesn't seem to do anything you couldn't do with the existing interfaces. I don't know all that much about what Zach's done here, but from what he's said so far it looks like this help to manage lots of IOMMUs on a single system.. On x86 it seems like there's not all that many IOMMUs in comparison .. Zach mentioned 10 to 100 IOMMUs .. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
Pramod, Teerth, On Mon, 7 Jun 2010, Gurav , Pramod wrote: > Can you please push these patches if you don't you are OK with them? As we discussed in Bangalore, these patches need some changes: 1. The delay needs to be precisely characterized in terms of what the hardware actually needs. It should not be necessary to add any extra timing slop, due to unknown sources, in the code. Unknown sources of delay can cause problems if, for example, a customer changes some board characteristics (such as sys_clk frequency, or DPLL multipliers/dividers) that the delay depends on. Also, my understanding is that RX-51 shipped without unknown timing factors in this code. Please work with the hardware people to precisely characterize the delay, assuming that it does not match what is documented in the TRM. 2. Please split out the individual components of the delay calculation to the code that handles those clocks. For example, HSDIVIDER change delay should be calculated by code that handles the HSDIVIDER. DPLL relock delay should be calculated by code in the dpll*.c files. etc. regards - Paul > - > Thanks and Best Regards > Pramod Gurav > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Gurav , Pramod > > Sent: Friday, April 23, 2010 7:53 PM > > To: linux-omap@vger.kernel.org; Paul Walmsley; Kevin Hilman > > Cc: Sripathy, Vishwanath; K, Ambresh > > Subject: RE: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall > > latency during DVFS > > > > Hi Paul, > > > > Please let me know if you have any comments on the patches below. > > The comments from Kevin, Ambresh and Sergio have been addressed in the > > last version of the patches and few in these patches. > > > > > -Original Message- > > > From: Gurav , Pramod > > > Sent: Thursday, April 01, 2010 10:47 PM > > > To: linux-omap@vger.kernel.org > > > Cc: Gurav , Pramod > > > Subject: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency > > > during DVFS > > > > > > From: Pramod Gurav > > > > > > The patch has the changes to calculate the dpll3 clock stabilization > > > delay dynamically. The SRAM delay is calibrated during bootup using the > > > gptimers and used while calculating the stabilization delay. By using > > > the dynamic method the dependency on the type of cache being used is > > > removed. > > > > > > Formula to calculate the DVFS latency for 3430 and 3630 are different. > > > The second patch implements the formula for later. > > > > > > This Version of patches adds optimisation to the formula implementation. > > > > > > Teerth Reddy (1): > > > OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS > > > Pramod Gurav (1): > > > OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630 > > > > > > arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 71 > > > +++- > > > arch/arm/mach-omap2/clock34xx.h|2 + > > > arch/arm/mach-omap2/clock3xxx.c|2 +- > > > arch/arm/mach-omap2/clock3xxx.h|1 + > > > arch/arm/mach-omap2/clock3xxx_data.c | 13 ++ > > > arch/arm/mach-omap2/sram34xx.S |8 > > > arch/arm/plat-omap/include/plat/sram.h |4 ++ > > > arch/arm/plat-omap/sram.c | 51 +++ > > > 8 files changed, 140 insertions(+), 12 deletions(-) > > > > > > > > - > > Thanks and Best Regards > > Pramod Gurav > > > > -- > > 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: [PATCHv3 5/9] dspbridge: add mmufault support
> -Original Message- > From: Kanigeri, Hari > Sent: Thursday, July 01, 2010 1:04 PM > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: o...@wizery.com; Hiroshi DOYU; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: RE: [PATCHv3 5/9] dspbridge: add mmufault support > > > > > + da = iommu_read_reg(mmu, MMU_FAULT_AD); > > > > + iommu_write_reg(mmu, 0, MMU_IRQENABLE); > > > > > > -- Isn't the MMU already enabled at this point when the function > > callback > > > is called by iommu ? > > > > This line is actually disabling the interrupts. I am writing "0x0" in > the > > MMU_IRQENABLE. > > -- oops ! sorry about that. Didn't pay attention to 0x0. Yes, this should > work. Not problem :). Could you please comment in the second set of patches I sent? The previous ones have version 3 which is not correct, that was a version I was using internally, but the patches shouldn't have sent to mailing list with that version. Because it is the first version posted. Thanks and regards, Fernando. > > Best regards, > Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 5/9] dspbridge: add mmufault support
> > > + da = iommu_read_reg(mmu, MMU_FAULT_AD); > > > + iommu_write_reg(mmu, 0, MMU_IRQENABLE); > > > > -- Isn't the MMU already enabled at this point when the function > callback > > is called by iommu ? > > This line is actually disabling the interrupts. I am writing "0x0" in the > MMU_IRQENABLE. -- oops ! sorry about that. Didn't pay attention to 0x0. Yes, this should work. Best regards, Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
> What license (name/type) is this? IANAL, but AFAIK standard wisdom is that "disclaimer in the documentation and/or other materials provided" is generally not acceptable for Linux because it's an excessive burden for all distributors. Also for me it's still quite unclear why we would want this code at all... It doesn't seem to do anything you couldn't do with the existing interfaces. -Andi -- 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 5/9] dspbridge: add mmufault support
Hi Hari,
> -Original Message-
> From: Kanigeri, Hari
> Sent: Thursday, July 01, 2010 12:17 PM
> To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com;
> felipe.contre...@nokia.com; Guzman Lugo, Fernando
> Subject: RE: [PATCHv3 5/9] dspbridge: add mmufault support
>
> Hi Fernando,
>
> > +int mmu_fault_isr(struct iommu *mmu)
> >
> > -/*
> > - * mmu_check_if_fault ===
> > - * Check to see if MMU Fault is valid TLB miss from DSP
> > - * Note: This function is called from an ISR
> > - */
> > -static bool mmu_check_if_fault(struct bridge_dev_context *dev_context)
> > {
> > + struct deh_mgr *dm;
> > + u32 da;
> > +
> > + dev_get_deh_mgr(dev_get_first(), &dm);
> > +
> > + if (!dm)
> > + return -EPERM;
> > +
> > + da = iommu_read_reg(mmu, MMU_FAULT_AD);
> > + iommu_write_reg(mmu, 0, MMU_IRQENABLE);
>
> -- Isn't the MMU already enabled at this point when the function callback
> is called by iommu ?
This line is actually disabling the interrupts. I am writing "0x0" in the
MMU_IRQENABLE.
>
> > + dm->err_info.dw_val1 = da;
> > + tasklet_schedule(&dm->dpc_tasklet);
>
> -- The iommu fault isr disables the IOMMU at the end of the fault handler,
> so by the time your tasklet is scheduled you might have the MMU in a
> disabled state. Looks to me either this requires change in iommu to remove
> the disable part or enable the MMU in the tasklet instead of doing it
> early in mmu_fault_isr.
I am returning 0 in the callback function, that means the callback function has
managed the fault and the mmu_fault_isr does not do anything else
if (obj->isr)
err = obj->isr(obj);
if (!err)
return IRQ_HANDLED;
it is working for me without not modifications in the iommu_fault_handler
function.
Thanks for the comments,
Fernando.
>
> Thank you,
> Best regards,
> Hari
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Tony Lindgren wrote:
> +static void __init kuser_get_tls_init(unsigned long vectors)
> +{
> + /*
> + * vectors + 0xfe0 = __kuser_get_tls
> + * vectors + 0xfe8 = hardware TLS instruction at 0x0fe8
> + */
> + if (tls_emu || has_tls)
> + memcpy((void *)vectors + 0xfe0, (void *)vectors + 0xfe8, 4);
> +}
Just a little opinion: Perhaps has_tls_reg would be a clearer name.
All variants "have TLS" after all.
Also - and this isn't directly related to your change so feel free to
ignore it - wouldn't it make more sense for the tls_emu case to use
the memory version (and update the memory location), so that even on
tls_emu systems, user programs which call the kuser code will run faster?
With that change, there would be no real penalty to enabling tls_emu
for any system that finds it useful.
-- Jamie
--
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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Tue, 29 Jun 2010 22:55:50 -0700 Zach Pfeffer wrote:
> arch/arm/mm/vcm.c | 1901
> +
> include/linux/vcm.h | 701 +
> include/linux/vcm_types.h | 318
> 3 files changed, 2920 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mm/vcm.c
> create mode 100644 include/linux/vcm.h
> create mode 100644 include/linux/vcm_types.h
> diff --git a/include/linux/vcm.h b/include/linux/vcm.h
> new file mode 100644
> index 000..d2a1cd1
> --- /dev/null
> +++ b/include/linux/vcm.h
> @@ -0,0 +1,701 @@
> +/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> + * met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above
> + * copyright notice, this list of conditions and the following
> + * disclaimer in the documentation and/or other materials provided
> + * with the distribution.
> + * * Neither the name of Code Aurora Forum, Inc. nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
> + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
> + * IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + */
What license (name/type) is this?
> +
> +#ifndef _VCM_H_
> +#define _VCM_H_
> +
> +/* All undefined types must be defined using platform specific headers */
> +
> +#include
> +
> +/*
> + * Creating, freeing and managing VCMs.
> + *
> + * A VCM region is a virtual space that can be reserved from and
> + * associated with one or more devices. At creation the user can
> + * specify an offset to start addresses and a length of the entire VCM
> + * region. Reservations out of a VCM region are always contiguous.
> + */
> +
> +/**
> + * vcm_create() - Create a VCM region
> + * @start_addr The starting address of the VCM region.
* @start_addr: text
* @len:text
I.e., need a colon (':') after each param name. (in multiple places)
> + * @len The len of the VCM region. This must be at least
> + * vcm_get_min_page_size() bytes.
> + *
> + * A VCM typically abstracts a page table.
> + *
> + * All functions in this API are passed and return opaque things
> + * because the underlying implementations will vary. The goal
> + * is really graph management. vcm_create() creates the "device end"
> + * of an edge in the mapping graph.
> + *
> + * The return value is non-zero if a VCM has successfully been
> + * created. It will return zero if a VCM region cannot be created or
> + * len is invalid.
> + */
> +struct vcm *vcm_create(size_t start_addr, size_t len);
> +/**
> + * vcm_get_physmem_from_res() - Return a reservation's physmem_id
> + * @ res_id An existing reservation of interest.
* @res_id:
No space between @ and res_id.
> + *
> + * The return value will be non-zero on success, otherwise it will be:
> + * -EINVAL res is invalid
> + * -ENOMEM res is unbacked
> + */
> +struct physmem *vcm_get_physmem_from_res(struct res *res_id);
> diff --git a/include/linux/vcm_types.h b/include/linux/vcm_types.h
> new file mode 100644
> index 000..2cc4770
> --- /dev/null
> +++ b/include/linux/vcm_types.h
> @@ -0,0 +1,318 @@
> +/**
> + * enum memtarget_t - A logical location in a VCM.
> + *
> + * VCM_START Indicates the start of a VCM_REGION.
This is not quite kernel-doc notation (as indicated by the beginning /**).
Please see Documentation/kernel-doc-nano-HOWTO.txt for details, or ask me
if you need help with it.
> + */
> +enum memtarget_t {
> + VCM_START
> +};
> +
> +
> +/**
> + * enum memtype_t - A logical location in a VCM.
not quite kernel-doc notation...
> + *
> + * VCM_MEMTYPE_0 Generic memory type 0
> + * VCM_MEMTYPE_1 Generic memory type 1
> + * VCM_MEMTYPE_2 Generic memory type 2
> + *
> + * A memtype encapsulates a platform specific memory arrangement. The
> + * memtype needn't refer to a single typ
RE: [PATCHv3 5/9] dspbridge: add mmufault support
Hi Fernando,
> +int mmu_fault_isr(struct iommu *mmu)
>
> -/*
> - * mmu_check_if_fault ===
> - * Check to see if MMU Fault is valid TLB miss from DSP
> - * Note: This function is called from an ISR
> - */
> -static bool mmu_check_if_fault(struct bridge_dev_context *dev_context)
> {
> + struct deh_mgr *dm;
> + u32 da;
> +
> + dev_get_deh_mgr(dev_get_first(), &dm);
> +
> + if (!dm)
> + return -EPERM;
> +
> + da = iommu_read_reg(mmu, MMU_FAULT_AD);
> + iommu_write_reg(mmu, 0, MMU_IRQENABLE);
-- Isn't the MMU already enabled at this point when the function callback is
called by iommu ?
> + dm->err_info.dw_val1 = da;
> + tasklet_schedule(&dm->dpc_tasklet);
-- The iommu fault isr disables the IOMMU at the end of the fault handler, so
by the time your tasklet is scheduled you might have the MMU in a disabled
state. Looks to me either this requires change in iommu to remove the disable
part or enable the MMU in the tasklet instead of doing it early in
mmu_fault_isr.
Thank you,
Best regards,
Hari
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
On Thu, 1 Jul 2010, Tony Lindgren wrote: > * Paul Walmsley [100624 09:22]: > > Hi Tony, > > > > what do you think on this one? -rc or .36? > > If we want to try to get it into the -rc cycle, the description > should mention what it fixes and show the error. Otherwise it might > be hard to argue this is a real fix or a regression. Thanks, I'll queue it for .36. - 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: [RFC][PATCH 4/8] OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers
On Thu, 1 Jul 2010, Archit Taneja wrote: > From: Semwal, Sumit > > Introduce OMAP4 DISPC base address and Secondary LCD Channel registers, use > them > in register dumps. > > Signed-off-by: Sumit Semwal > Signed-off-by: Senthilvadivu Guruswamy > Signed-off-by: Mukund Mittal > Signed-off-by: Archit Taneja > Signed-off-by: Samreen > --- > drivers/video/omap2/dss/dispc.c | 42 > ++- > 1 files changed, 41 insertions(+), 1 deletions(-) > > diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c > index 5ecdc00..08b36d6 > --- a/drivers/video/omap2/dss/dispc.c > +++ b/drivers/video/omap2/dss/dispc.c > @@ -41,9 +41,13 @@ > #include "dss.h" > > /* DISPC */ > +#ifdef CONFIG_ARCH_OMAP4 > +#define DISPC_BASE 0x58001000 > +#define DISPC_SZ_REGSSZ_16K > +#else > #define DISPC_BASE 0x48050400 > - > #define DISPC_SZ_REGSSZ_1K > +#endif This will break multi-OMAP builds. Instead, get the DISPC_BASE at runtime through platform_get_resource*(). - 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 03/33] Removing dead OMAP_MUX_ERRORS
On Thu, Jul 01, 2010 at 03:22:55PM +0200, Christoph Egger wrote: > On Wed, Jun 30, 2010 at 10:54:09PM +0300, Kirill A. Shutemov wrote: > > On Wed, Jun 30, 2010 at 05:54:42PM +0200, Christoph Egger wrote: > > > OMAP_MUX_ERRORS doesn't exist in Kconfig, therefore removing all > > > references for it from the source code. > > > > IIUC, CONFIG_OMAP_MUX_WARNINGS should be used here instead of it. > > Something like the patch below? Acked-by: Kirill A. Shutemov > > > From: Christoph Egger > Date: Wed, 30 Jun 2010 12:30:36 +0200 > Subject: [PATCH 03/33] Replace dead OMAP_MUX_ERRORS with OMAP_MUX_WARNINGS > > OMAP_MUX_ERRORS doesn't exist in Kconfig, therefore replacing all > references for it with OMAP_MUX_WARNINGS in the source code. > > Signed-off-by: Christoph Egger > --- > arch/arm/mach-omap1/mux.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c > index 8434137..3e98835 100644 > --- a/arch/arm/mach-omap1/mux.c > +++ b/arch/arm/mach-omap1/mux.c > @@ -440,7 +440,7 @@ int __init_or_module omap1_cfg_reg(const struct > pin_config *cfg) > } > #endif > > -#ifdef CONFIG_OMAP_MUX_ERRORS > +#ifdef CONFIG_OMAP_MUX_WARNINGS > return warn ? -ETXTBSY : 0; > #else > return 0; > -- > 1.7.0.4 > > -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP:DSS2:OMAPFB: Fix probe error path
On Thu, 2010-07-01 at 15:40 +0200, ext Afzal Mohammed wrote: > Move sysfs entry creation to omapfb_probe() from omapfb_create_framebuffers(). > This will make sure that sysfs entry is not left behind in case of > unsuccessful > probe due to failure in enabling fb0 of omapfb_create_framebuffers(). Yes, I think this version is ok. Thanks! Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP:DSS2:OMAPFB: Fix probe error path
Hi Tomi, Is this change ok instead of having sysfs entry removal in omapfb_free_resources() ? Hope this change makes probe look more of a remove mirror. Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP:DSS2:OMAPFB: Fix probe error path
Move sysfs entry creation to omapfb_probe() from omapfb_create_framebuffers().
This will make sure that sysfs entry is not left behind in case of unsuccessful
probe due to failure in enabling fb0 of omapfb_create_framebuffers().
Signed-off-by: Afzal Mohammed
---
drivers/video/omap2/omapfb/omapfb-main.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..710e117 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1928,13 +1928,6 @@ static int omapfb_create_framebuffers(struct
omapfb2_device *fbdev)
}
}
- DBG("create sysfs for fbs\n");
- r = omapfb_create_sysfs(fbdev);
- if (r) {
- dev_err(fbdev->dev, "failed to create sysfs entries\n");
- return r;
- }
-
/* Enable fb0 */
if (fbdev->num_fbs > 0) {
struct omapfb_info *ofbi = FB2OFB(fbdev->fbs[0]);
@@ -2220,6 +2213,13 @@ static int omapfb_probe(struct platform_device *pdev)
}
}
+ DBG("create sysfs for fbs\n");
+ r = omapfb_create_sysfs(fbdev);
+ if (r) {
+ dev_err(fbdev->dev, "failed to create sysfs entries\n");
+ goto cleanup;
+ }
+
return 0;
cleanup:
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/33] Removing dead OMAP_MUX_ERRORS
On Wed, Jun 30, 2010 at 10:54:09PM +0300, Kirill A. Shutemov wrote: > On Wed, Jun 30, 2010 at 05:54:42PM +0200, Christoph Egger wrote: > > OMAP_MUX_ERRORS doesn't exist in Kconfig, therefore removing all > > references for it from the source code. > > IIUC, CONFIG_OMAP_MUX_WARNINGS should be used here instead of it. Something like the patch below? From: Christoph Egger Date: Wed, 30 Jun 2010 12:30:36 +0200 Subject: [PATCH 03/33] Replace dead OMAP_MUX_ERRORS with OMAP_MUX_WARNINGS OMAP_MUX_ERRORS doesn't exist in Kconfig, therefore replacing all references for it with OMAP_MUX_WARNINGS in the source code. Signed-off-by: Christoph Egger --- arch/arm/mach-omap1/mux.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c index 8434137..3e98835 100644 --- a/arch/arm/mach-omap1/mux.c +++ b/arch/arm/mach-omap1/mux.c @@ -440,7 +440,7 @@ int __init_or_module omap1_cfg_reg(const struct pin_config *cfg) } #endif -#ifdef CONFIG_OMAP_MUX_ERRORS +#ifdef CONFIG_OMAP_MUX_WARNINGS return warn ? -ETXTBSY : 0; #else return 0; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections
On Thu, 2010-07-01 at 14:28 +0200, ext Taneja, Archit wrote:
> > On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote:
> > > From: Sumit Semwal
> > >
> > > The addition of the new 2lcd manager requires modifications in the
> > > dss_recheck_connections patch, this function behaves the
> > same if the
> > > 2lcd manager doesn't exist
> >
> > Here (and also in the previous patch) you talk about 2lcd,
> > but the code uses lcd2.
>
> Archit: The new manager's name defined in manager.c is 2lcd,
> The channel's name in the enum is OMAP_DSS_CHANNEL_LCD2, and
> the overlay manager enum is OMAP_DSS_OVL_MGR_LCD2.
>
> 2lcd as the manager name was taken so that no one makes mistakes
> while reading/writing sysfs entries.
>
> Also, in the dss2 code we use strncmp() to compare the manager
> names in overlay_manager_store(). Now, if we name the new manager
> as "lcd2", consider the following scenario:
>
> Suppose an overlay has its manager presently set as "lcd2". Now
> someone does a sysfs entry to make the manager as "lcd". So in this
> case the variable buf is "lcd" and and mgr->name is "lcd2". The
> variable len is calculated on the basis of buf ("lcd") as 3.
>
> So strncmp just compares the first 3 chars, and in that case "lcd"
> and "lcd2" are the same, luckily this doesn't cause an issue as the
> first manager fetched by omap_dss_get_overlay_manager() is "lcd". If
> the manager_list was filled in some other way then this would have
> resulted an issue.
If the DSS sysfs code if broken, let's rather fix it than name the
manager with a rather strange name, just to circumvent a bug.
>
> In my opinion, len should be calculated as:
>
> len = max(len, strlen(mgr->name));
>
> This way strncmp would work correctly in all the cases.
sysfs_streq() could be used there.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH] Board changes for tmp105 temperature sensor
Adding board configuration for the tmp105
temperature sensor. The interface to the sensor
is I2C.
-Removing unwanted file mode change
Signed-off-by: Shubhrajyoti D
---
arch/arm/mach-omap2/board-4430sdp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 4bb2c5d..3e3b222 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -353,6 +353,11 @@ static struct i2c_board_info __initdata
sdp4430_i2c_boardinfo[] = {
.platform_data = &sdp4430_twldata,
},
};
+static struct i2c_board_info __initdata sdp4430_i2c_3_boardinfo[] = {
+ {
+ I2C_BOARD_INFO("tmp105", 0x48),
+ },
+};
static int __init omap4_i2c_init(void)
{
/*
@@ -362,7 +367,8 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(1, 400, sdp4430_i2c_boardinfo,
ARRAY_SIZE(sdp4430_i2c_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
- omap_register_i2c_bus(3, 400, NULL, 0);
+ omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
--
1.5.4.7
--
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] arm: Make VFPv3 usable on ARMv6
* Catalin Marinas [100625 16:44]: > On Wed, 2010-06-23 at 08:57 +0100, Tony Lindgren wrote: > > MVFR0 and MVFR1 are only available starting with ARM1136 r1p0 release > > according to "B.5 VFP changes" in DDI0211F_arm1136_r1p0_trm.pdf. This is > > also when TLS register got added, so we can use HAS_TLS also to test for > > MVFR0 and MVFR1. > > > > Otherwise VFPFMRX and VFPFMXR access fails and we get: > > > > Internal error: Oops - undefined instruction: 0 [#1] > > PC is at no_old_VFP_process+0x8/0x3c > > LR is at __und_svc+0x48/0x80 > > ... > > > > Signed-off-by: Tony Lindgren > > The new version looks fine to me. > > Acked-by: Catalin Marinas Thanks. Added your ack and posted to Russell's patch system: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6203/1 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: [PATCH v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
* Andrew Morton [100617 23:09]: > On Thu, 17 Jun 2010 20:57:19 +0530 (IST) > "kishore kadiyala" wrote: > > > Adding card detect callback function which gives the status of > > the card .For MMC1 Controller, Card detect interrupt source is > > twl6030 and card present/absent status is provided by MMCCTRL > > register of twl6030. > > > > Signed-off-by: Kishore Kadiyala > > --- > > arch/arm/mach-omap2/board-4430sdp.c | 11 +-- > > arch/arm/mach-omap2/hsmmc.c |1 + > > arch/arm/plat-omap/include/plat/mmc.h |1 + > > drivers/mfd/twl6030-irq.c | 23 > > drivers/mmc/host/omap_hsmmc.c | 30 ++--- > > include/linux/i2c/twl.h | 46 > > + > > 6 files changed, 104 insertions(+), 8 deletions(-) > > I assume this depends on "[PATCH v5 1/2] OMAP HSMMC: Adding a Flag to > determine the type of Card detect"? > > It's all a bit too remote from my (ever-expanding) work area, so I'll > assume that Tony or someone will look after these. Yeah we'll queue these via the omap patches once everybody is happy with them. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [PATCH] Board changes for tmp105 temperature sensor
Hi Tony, > -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Thursday, July 01, 2010 5:47 PM > To: Datta, Shubhrajyoti > Cc: linux-omap@vger.kernel.org; LM Sensors > Subject: Re: [RFC] [PATCH] Board changes for tmp105 temperature sensor > > * Datta, Shubhrajyoti [100615 17:40]: > > Adding board configuration for the tmp105 > > temperature sensor. The interface to the sensor > > is I2C. > > > > Signed-off-by: Shubhrajyoti D > > --- > > arch/arm/mach-omap2/board-4430sdp.c |8 +++- > > 1 files changed, 7 insertions(+), 1 deletions(-) > > mode change 100644 => 100755 arch/arm/mach-omap2/board-4430sdp.c > > Please be careful with the mode changes. Will send a corrected patch > > Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] OMAP HSMMC: Adding a Flag to determine the type of Card detect
* kishore kadiyala [100621 09:49]:
> On Fri, Jun 18, 2010 at 1:49 AM, Andrew Morton
> wrote:
> > On Thu, 17 Jun 2010 20:56:58 +0530 (IST)
> > "kishore kadiyala" wrote:
> >
> >> --- a/arch/arm/plat-omap/include/plat/mmc.h
> >> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> >> @@ -43,6 +43,9 @@
> >>
> >> Â #define OMAP_MMC_MAX_SLOTS Â 2
> >>
> >> +#define NON_GPIO Â Â Â Â Â Â 0
> >> +#define GPIO Â Â Â Â Â Â Â Â 1
> >
> > I'm counting about seven different definitions of "GPIO" in the kernel
> > already.
> >
> > drivers/hwmon/it87.c:
> > #define GPIO Â Â 0x07
> >
> > drivers/media/dvb/dvb-usb/ec168.h:
> > Â Â Â Â GPIO Â Â Â Â Â Â Â Â = 0x04,
> >
> > drivers/net/hamachi.c:
> > Â Â Â Â GPIO=0x6E
> >
> > drivers/staging/rtl8187se/r8180_hw.h:
> > #define GPIO 0x91
> >
> > etcetera. Â It's a crazy identifier to use in a header file, and
> > the chances of a miscompile-causing collision are increasing.
> >
> >
> > enum cd_type {
> > Â Â Â Â CD_TYPE_NON_GPIO = 0,
> > Â Â Â Â CD_TYPE_GPIO = 1,
> > };
>
> OK , Will repost with above changes
Please also do it the other way around where you pass CD_TYPE_NON_GPIO
in the flags in the platform data. Then there's no need to patch
all the existing boards.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections
> On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote:
> > From: Sumit Semwal
> >
> > The addition of the new 2lcd manager requires modifications in the
> > dss_recheck_connections patch, this function behaves the
> same if the
> > 2lcd manager doesn't exist
>
> Here (and also in the previous patch) you talk about 2lcd,
> but the code uses lcd2.
Archit: The new manager's name defined in manager.c is 2lcd,
The channel's name in the enum is OMAP_DSS_CHANNEL_LCD2, and
the overlay manager enum is OMAP_DSS_OVL_MGR_LCD2.
2lcd as the manager name was taken so that no one makes mistakes
while reading/writing sysfs entries.
Also, in the dss2 code we use strncmp() to compare the manager
names in overlay_manager_store(). Now, if we name the new manager
as "lcd2", consider the following scenario:
Suppose an overlay has its manager presently set as "lcd2". Now
someone does a sysfs entry to make the manager as "lcd". So in this
case the variable buf is "lcd" and and mgr->name is "lcd2". The
variable len is calculated on the basis of buf ("lcd") as 3.
So strncmp just compares the first 3 chars, and in that case "lcd"
and "lcd2" are the same, luckily this doesn't cause an issue as the
first manager fetched by omap_dss_get_overlay_manager() is "lcd". If
the manager_list was filled in some other way then this would have
resulted an issue.
In my opinion, len should be calculated as:
len = max(len, strlen(mgr->name));
This way strncmp would work correctly in all the cases.
In order to take no risks, we named it as "2lcd".
Thanks,
Archit
--
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] Enable lm75 and hwmon in OMAP4
* Datta, Shubhrajyoti [100617 09:14]: > Enabling hwmon and lm75 in the omap4 defconfig > > Signed-off-by: Shubhrajyoti D > --- > arch/arm/configs/omap_4430sdp_defconfig |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > mode change 100644 => 100755 arch/arm/configs/omap_4430sdp_defconfig Again a bad mode change for a while. Sorry no more defconfig patches until the situation clears out on what they will be replaced with. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP4: Add support for PWM LED
* Hemanth V [100701 15:11]: > - Original Message - From: "Tony Lindgren" > > To: "Hemanth V" > Cc: > Sent: Thursday, July 01, 2010 4:07 PM > Subject: Re: [PATCH 2/2] OMAP4: Add support for PWM LED > > > >* Hemanth V [100630 17:12]: > >>From 713727188b99465341767eedaa42004862261211 Mon Sep 17 00:00:00 2001 > >>From: Hemanth V > >>Date: Wed, 30 Jun 2010 18:16:33 +0530 > >>Subject: [PATCH] OMAP4: Add support for PWM LED > >> > >>TWL6030 supports PWM (Pulse Width Modulator) which is used > >>to control charging LED. This allows for controlling brightness > >>This patch implements the APIs needed by leds-pwm driver. > > > > > > > >>--- /dev/null > >>+++ b/arch/arm/mach-omap2/twl6030_pwm.c > >>@@ -0,0 +1,168 @@ > >>+/* > >>+ * twl6030_pwm.c > >>+ * Driver for PHOENIX (TWL6030) Pulse Width Modulator > > > >This should go to somewhere under drivers instead of > >arch/arm/mach-omap2. > > Tony, since PWM is specific to each platform, they are typically > under platform folder. Some examples below > > arch/arm/plat-mxc/pwm.c > arch/arm/plat-pxa/pwm.c > arch/arm/plat-samsung/pwm.c But this is related to an external PM chip that can be potentially used for other chips than omaps. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP4: Add support for PWM LED
- Original Message - From: "Tony Lindgren" To: "Hemanth V" Cc: Sent: Thursday, July 01, 2010 4:07 PM Subject: Re: [PATCH 2/2] OMAP4: Add support for PWM LED * Hemanth V [100630 17:12]: From 713727188b99465341767eedaa42004862261211 Mon Sep 17 00:00:00 2001 From: Hemanth V Date: Wed, 30 Jun 2010 18:16:33 +0530 Subject: [PATCH] OMAP4: Add support for PWM LED TWL6030 supports PWM (Pulse Width Modulator) which is used to control charging LED. This allows for controlling brightness This patch implements the APIs needed by leds-pwm driver. --- /dev/null +++ b/arch/arm/mach-omap2/twl6030_pwm.c @@ -0,0 +1,168 @@ +/* + * twl6030_pwm.c + * Driver for PHOENIX (TWL6030) Pulse Width Modulator This should go to somewhere under drivers instead of arch/arm/mach-omap2. Tony, since PWM is specific to each platform, they are typically under platform folder. Some examples below arch/arm/plat-mxc/pwm.c arch/arm/plat-pxa/pwm.c arch/arm/plat-samsung/pwm.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] Board changes for tmp105 temperature sensor
* Datta, Shubhrajyoti [100615 17:40]: > Adding board configuration for the tmp105 > temperature sensor. The interface to the sensor > is I2C. > > Signed-off-by: Shubhrajyoti D > --- > arch/arm/mach-omap2/board-4430sdp.c |8 +++- > 1 files changed, 7 insertions(+), 1 deletions(-) > mode change 100644 => 100755 arch/arm/mach-omap2/board-4430sdp.c Please be careful with the mode changes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: mux: Add api to retrieve padconf offset based on muxname
* Govindraj.R [100614 17:07]:
> Adds a padconf offset retrieval api which will
> get us the padconf offset based on muxname provided
> which can be later used with omap_ctrl_writew,
> omap_ctrl_readw calls for remuxing signals.
>
> Cc: Tony Lindgren
> Signed-off-by: Govindraj.R
> ---
> Patch is based on earlier discussion with Tony
> http://marc.info/?l=linux-omap&m=127609369220618&w=2
>
> arch/arm/mach-omap2/mux.c | 17 +
> arch/arm/mach-omap2/mux.h |6 ++
> 2 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 8b3d269..afe45ce 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -882,6 +882,23 @@ free:
>
> #endif /* CONFIG_OMAP_MUX */
>
> +u16 omap_mux_request_signal(char *muxname)
> +{
> + struct omap_mux_entry *e;
> + u16 offset = -EINVAL;
> +
> + list_for_each_entry(e, &muxmodes, node) {
> + struct omap_mux *m = &e->mux;
> + char *m0_entry = m->muxnames[0];
> +
> + if (!strcmp(muxname, m0_entry)) {
> + offset = m->reg_offset + OMAP_MUX_BASE_OFFSET;
> + break;
> + }
> + }
> + return offset;
> +}
You need to consider few more things..
Note that omap_mux_late_init frees the memory for all pins except
for GPIO pins unless CONFIG_DEBUG_FS is set.
This means that omap_mux_request_signal needs to be __init function
and accessible only in the board-*.c files. Then the board-*.c file
can then implement it's pin muxing functions and pass the function
pointers along to a driver via platform data as needed. Then the
driver can call the board specific function if implemented.
Then you need to also consider full pin names such as
mcbsp2_clkx.gpio_12. Relying on the mode0 name is not enough
as there can be multiple pinouts. Also from user point of view
it is confusing to have to look up the mode0 name when
omap_mux_request_signal can do the work.
Then you probably want to add a comment about using omap_mux_read/write
on the returned offset to avoid accidentally modifying other
registers :)
Anyways, please also make sure you code does the right thing
with CONFIG_OMAP_MUX set and not set, and CONFIG_DEBUG_FS
set and not set.
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
FW: [RFC][PATCH 4/8] OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers
Hi, > On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > > From: Semwal, Sumit > > > > Introduce OMAP4 DISPC base address and Secondary LCD Channel > > registers, use them in register dumps. > > #define DISPC_DIVISOR DISPC_REG(0x0070) > > +#define DISPC_DIVISOR1 DISPC_REG(0x0804) > > What is this? On OMAP4 there are 3 divisor registers, DIVISOR, DIVISOR1, DIVISOR2. The first one can divide the DSS_CLK coming from the PRCM for DISPC_FCLK, the last 2 provide pcd and lcd divisors for the 2 channels respectively. The addresses and the naming are a bit confusing: OMAP3: DISPC_DIVISOR - 0x0070 OMAP4: DISPC_DIVISOR - 0x0804 DISPC_DIVISOR1 - 0x0070 DISPC_DIVISOR2 - 0x040C We really don't need this common divisor thing, so in order to make minimal changes in the code we swapped the names of DIVISOR and DIVISOR1, this also makes it fit well with the OMAP3 code. You will see that DIPC_DIVISOR1 is not used at all, I just added it for completeness, I will remove when I resubmit this series. > > > #define DISPC_GLOBAL_ALPHA DISPC_REG(0x0074) > > +#define DISPC_DIVISOR2 DISPC_REG(0x040C) > > +#define DISPC_CONFIG2 DISPC_REG(0x0620) > > + > > #define DISPC_MAX_NR_ISRS 8 > > Would it be possible to have similar system to these registers as with > for example the VID registers: > > DISPC_SIZE_LCD(n) where n is 0 or 1, or possibly the channel. > > This would reduce ifs quite a bit in the following patches. Unfortunately, there is no linear mapping for the channel registers as it is in the video plane. But I agree it is still worth it to explicitly mention the addresses in the definitions. It would make the later patches much cleaner. > > Tomi > Thanks, Archit-- 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] [RFC][PATCH 2/8] OMAP: DSS2: Add new Overlay Manager
> On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > > From: Sumit Semwal > > > > Add new Overlay Manager in manager.c, make secondary > channel changes > > and update supported displays for the managers in OMAP4 > > > > @@ -1471,15 +1471,25 @@ int > dss_init_overlay_managers(struct platform_device *pdev) > > case 0: > > mgr->name = "lcd"; > > mgr->id = OMAP_DSS_CHANNEL_LCD; > > - mgr->supported_displays = > > - OMAP_DISPLAY_TYPE_DPI | > OMAP_DISPLAY_TYPE_DBI | > > - OMAP_DISPLAY_TYPE_SDI | > OMAP_DISPLAY_TYPE_DSI; > > + mgr->supported_displays = > OMAP_DISPLAY_TYPE_DBI | > > + OMAP_DISPLAY_TYPE_DSI; > > + if (cpu_is_omap34xx()) > > + mgr->supported_displays |= > > + OMAP_DISPLAY_TYPE_DPI | > > + OMAP_DISPLAY_TYPE_SDI; > > How about OMAP2? My bad, will fix this. Haven't tested it on omap2 yet. > > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC][PATCH 2/8] OMAP: DSS2: Add new Overlay Manager
On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > From: Sumit Semwal > > Add new Overlay Manager in manager.c, make secondary channel changes > and update supported displays for the managers in OMAP4 > > Signed-off-by: Sumit Semwal > Signed-off-by: Senthilvadivu Guruswamy > Signed-off-by: Mukund Mittal > Signed-off-by: Archit Taneja > Signed-off-by: Samreen > --- > @@ -1471,15 +1471,25 @@ int dss_init_overlay_managers(struct platform_device > *pdev) > case 0: > mgr->name = "lcd"; > mgr->id = OMAP_DSS_CHANNEL_LCD; > - mgr->supported_displays = > - OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI | > - OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI; > + mgr->supported_displays = OMAP_DISPLAY_TYPE_DBI | > + OMAP_DISPLAY_TYPE_DSI; > + if (cpu_is_omap34xx()) > + mgr->supported_displays |= > + OMAP_DISPLAY_TYPE_DPI | > + OMAP_DISPLAY_TYPE_SDI; How about OMAP2? Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections
On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > From: Sumit Semwal > > The addition of the new 2lcd manager requires modifications in the > dss_recheck_connections patch, this function behaves the same if > the 2lcd manager doesn't exist Here (and also in the previous patch) you talk about 2lcd, but the code uses lcd2. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/8] OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers
On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote:
> From: Semwal, Sumit
>
> Introduce OMAP4 DISPC base address and Secondary LCD Channel registers, use
> them
> in register dumps.
>
> Signed-off-by: Sumit Semwal
> Signed-off-by: Senthilvadivu Guruswamy
> Signed-off-by: Mukund Mittal
> Signed-off-by: Archit Taneja
> Signed-off-by: Samreen
> ---
> drivers/video/omap2/dss/dispc.c | 42
> ++-
> 1 files changed, 41 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 5ecdc00..08b36d6
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -41,9 +41,13 @@
> #include "dss.h"
>
> /* DISPC */
> +#ifdef CONFIG_ARCH_OMAP4
> +#define DISPC_BASE 0x58001000
> +#define DISPC_SZ_REGSSZ_16K
> +#else
> #define DISPC_BASE 0x48050400
> -
> #define DISPC_SZ_REGSSZ_1K
> +#endif
>
> struct dispc_reg { u16 idx; };
>
> @@ -68,6 +72,7 @@ struct dispc_reg { u16 idx; };
> #define DISPC_TIMING_V DISPC_REG(0x0068)
> #define DISPC_POL_FREQ DISPC_REG(0x006C)
> #define DISPC_DIVISORDISPC_REG(0x0070)
> +#define DISPC_DIVISOR1 DISPC_REG(0x0804)
What is this?
> #define DISPC_GLOBAL_ALPHA DISPC_REG(0x0074)
> #define DISPC_SIZE_DIG DISPC_REG(0x0078)
> #define DISPC_SIZE_LCD DISPC_REG(0x007C)
> @@ -131,6 +136,23 @@ struct dispc_reg { u16 idx; };
>DISPC_IRQ_SYNC_LOST | \
>DISPC_IRQ_SYNC_LOST_DIGIT)
>
> +/* OMAP4 new global registers */
> +#define DISPC_CONTROL2 DISPC_REG(0x0238)
> +#define DISPC_DEFAULT_COLOR2 DISPC_REG(0x03AC)
> +#define DISPC_TRANS_COLOR2 DISPC_REG(0x03B0)
> +#define DISPC_CPR2_COEF_BDISPC_REG(0x03B4)
> +#define DISPC_CPR2_COEF_GDISPC_REG(0x03B8)
> +#define DISPC_CPR2_COEF_RDISPC_REG(0x03BC)
> +#define DISPC_DATA2_CYCLE1 DISPC_REG(0x03C0)
> +#define DISPC_DATA2_CYCLE2 DISPC_REG(0x03C4)
> +#define DISPC_DATA2_CYCLE3 DISPC_REG(0x03C8)
> +#define DISPC_SIZE_LCD2 DISPC_REG(0x03CC)
> +#define DISPC_TIMING_H2 DISPC_REG(0x0400)
> +#define DISPC_TIMING_V2 DISPC_REG(0x0404)
> +#define DISPC_POL_FREQ2 DISPC_REG(0x0408)
> +#define DISPC_DIVISOR2 DISPC_REG(0x040C)
> +#define DISPC_CONFIG2DISPC_REG(0x0620)
> +
> #define DISPC_MAX_NR_ISRS8
Would it be possible to have similar system to these registers as with
for example the VID registers:
DISPC_SIZE_LCD(n) where n is 0 or 1, or possibly the channel.
This would reduce ifs quite a bit in the following patches.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
* Paul Walmsley [100624 09:22]: > Hi Tony, > > what do you think on this one? -rc or .36? If we want to try to get it into the -rc cycle, the description should mention what it fixes and show the error. Otherwise it might be hard to argue this is a real fix or a regression. Regards, Tony > > - Paul > > On Thu, 24 Jun 2010, Gadiyar, Anand wrote: > > > Paul Walmsley wrote: > > > On Mon, 21 Jun 2010, Paul Walmsley wrote: > > > > On Sat, 19 Jun 2010, Gadiyar, Anand wrote: > > > > > Gadiyar, Anand wrote: > > > > > > We need to wait on the IDLEST bit after the clocks are enabled > > > > > > before attempting to access any register. > > > > > > > > > > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait, > > > > > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the > > > > > > i-clock is enabled first, the clkops_omap2_dflt_wait is > > > > > > short-circuited as the companion f-clock is not enabled. > > > > > > This can cause a data abort if the IDLEST has not transitioned, > > > > > > and we try to access a USBTLL register. > > > > > > > > > > > > Since the USBTLL i-clock and f-clock could be enabled in any order, > > > > > > this is a bug. Fix it by changing the clkops for the f-clock. > > > > > > > > > > > > Signed-off-by: Anand Gadiyar > > > > > > > > It looks fine to me. I will queue it for a -rc branch. > > > > > > Will requeue this for 2.6.36 merge window since it is not a regression, > > > and it seems that Linus wants regression fixes for the -rc series... > > > > > > > I received a bug-report last Friday from some user of the recently-merged > > ohci-omap3 driver about a data-abort caused at driver load. This patch > > fixes that issue. > > > > This wasn't known to me when I originally submitted the patch, but looks > > like this is a problem caused in a driver that went in in the last merge > > window. So maybe this patch can go in in the -rc series. ;) > > > > It's your call. I'm not particular. > > > > - 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
[PATCH v2 4/4] omap: nand: making ecc layout as compatible with romcode ecc
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-laod, u-boot and kernel.
This patch also enables to use romcode ecc for spd and zoom, by default.
This enables to flash x-load, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.
Signed-off-by: Sukumar Ghorai
Signed-off-by: Vimal Singh
---
arch/arm/mach-omap2/board-flash.c |2 +-
drivers/mtd/nand/omap2.c | 34 ++
2 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index ab31e7f..a15aab6
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -144,7 +144,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
- board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_HW;
gpmc_nand_init(&board_nand_data);
}
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d696026..4b777f0
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -128,6 +128,20 @@ const int use_dma;
const int use_interrupt;
#endif
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+ .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
+
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -959,6 +973,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_info *info;
struct omap_nand_platform_data *pdata;
int err;
+ int i, offset;
pdata = pdev->dev.platform_data;
if (pdata == NULL) {
@@ -1093,6 +1108,25 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
}
+ /* rom code layout */
+ if (pdata->ecc_opt != OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) {
+ offset = (info->nand.options & NAND_BUSWIDTH_16) ? 2 : 1;
+ if (info->mtd.oobsize == 16) {
+ info->nand.badblock_pattern = &bb_descrip_flashbased;
+ omap_oobinfo.eccbytes = 3;
+ } else
+ omap_oobinfo.eccbytes = 3 * 4;
+
+ for (i = 0; i < omap_oobinfo.eccbytes; i++)
+ omap_oobinfo.eccpos[i] = i+offset;
+
+ omap_oobinfo.oobfree->offset = offset + omap_oobinfo.eccbytes;
+ omap_oobinfo.oobfree->length = info->mtd.oobsize -
+ (offset + omap_oobinfo.eccbytes);
+
+ info->nand.ecc.layout = &omap_oobinfo;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0);
if (err > 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] omap3: nand: prefetch in irq mode support
This patch enable prefetch-irq mode for NAND.
Signed-off-by: Vimal Singh
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/board-flash.c |1 +
arch/arm/mach-omap2/gpmc.c |7 +
arch/arm/mach-omap2/include/mach/board-flash.h |3 +
arch/arm/plat-omap/include/plat/gpmc.h |3 +
arch/arm/plat-omap/include/plat/nand.h |1 +
drivers/mtd/nand/Kconfig | 14 ++-
drivers/mtd/nand/omap2.c | 199 +++-
7 files changed, 222 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index ac834aa..c6a07dd 100755
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -133,6 +133,7 @@ static struct omap_nand_platform_data board_nand_data = {
.nand_setup = NULL,
.gpmc_t = &nand_timings,
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .gpmc_irq = GPMC_IRQ_NUMBER,
.dev_ready = NULL,
.devsize= 0,/* '0' for 8-bit, '1' for 16-bit device */
};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index b8077c6..4e12a9f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -465,6 +465,13 @@ int gpmc_hwcontrol(int cs, int cmd, int write, int wval,
int *rval)
*rval = gpmc_read_reg(GPMC_IRQSTATUS);
break;
+ case GPMC_ENABLE_IRQ:
+ if (write)
+ gpmc_write_reg(GPMC_IRQENABLE, wval);
+ else
+ *rval = gpmc_read_reg(GPMC_IRQENABLE);
+ break;
+
case GPMC_PREFETCH_FIFO_CNT:
regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
*rval = GPMC_PREFETCH_STATUS_FIFO_CNT(regval);
diff --git a/arch/arm/mach-omap2/include/mach/board-flash.h
b/arch/arm/mach-omap2/include/mach/board-flash.h
index b2242ae..37567a7 100644
--- a/arch/arm/mach-omap2/include/mach/board-flash.h
+++ b/arch/arm/mach-omap2/include/mach/board-flash.h
@@ -19,6 +19,9 @@
#define PDC_ONENAND3
#define DBG_MPDB 4
+/* Interrupt number to the MPU Subsystem for GPMC */
+#define GPMC_IRQ_NUMBER20
+
struct flash_partitions {
struct mtd_partition *parts;
int nr_parts;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index ccbc530..4bdd851 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -37,6 +37,7 @@
#define GPMC_PREFETCH_FIFO_CNT 0x0009 /* bytes available in FIFO for r/w */
#define GPMC_PREFETCH_COUNT0x000A /* remaining bytes to be read/write*/
#define GPMC_GET_SET_IRQ_STATUS0x000B
+#define GPMC_ENABLE_IRQ0x000C
/* ECC commands */
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
@@ -75,6 +76,8 @@
#define WR_RD_PIN_MONITORING 0x0060
#define GPMC_PREFETCH_STATUS_FIFO_CNT(val) ((val >> 24) & 0x7F)
#define GPMC_PREFETCH_STATUS_COUNT(val)(val & 0x3fff)
+#define GPMC_IRQ_FIFOEVENTENABLE 0x01
+#define GPMC_IRQ_COUNT_EVENT 0x02
/*
* Note that all values in this struct are in nanoseconds, while
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..5e69463 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -20,6 +20,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ int gpmc_irq;
unsigned long phys_base;
int devsize;
};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 98a04b3..d0e934b 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -111,6 +111,9 @@ config MTD_NAND_OMAP_PREFETCH
help
The NAND device can be accessed for Read/Write using GPMC PREFETCH
engine
to improve the performance.
+GPMC PREFETCH can be configured eigther in MPU interrupt mode or in DMA
+interrupt mode. If not selected any of them prefetch will be used in
+polling mode.
config MTD_NAND_OMAP_PREFETCH_DMA
depends on MTD_NAND_OMAP_PREFETCH
@@ -119,7 +122,16 @@ config MTD_NAND_OMAP_PREFETCH_DMA
help
The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
+Say y for DMA mode
+
+config MTD_NAND_OMAP_PREFETCH_IRQ
+ depends on MTD_NAND_OMAP_PREFETCH && !MTD_NAND_OMAP_PREFETCH_DMA
+ bool "IRQ mode"
+ default n
+ help
+The GPMC PREFETCH engine can be config
[PATCH v2 2/4] omap3: nand: configurable fifo threshold to gain the throughput
Configure the FIFO THREASHOLD value different for read and write to keep busy
both
filling and to drain out of FIFO at reading and writing.
Signed-off-by: Sukumar Ghorai
Signed-off-by: Vimal Singh
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
drivers/mtd/nand/omap2.c | 24 +++-
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4e12a9f..cb38cff
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -58,7 +58,6 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
-#define PREFETCH_FIFOTHRESHOLD (0x40 << 8)
#define CS_NUM_SHIFT 24
#define ENABLE_PREFETCH(0x1 << 7)
#define DMA_MPU_MODE 2
@@ -538,15 +537,19 @@ EXPORT_SYMBOL(gpmc_hwcontrol);
/**
* gpmc_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
* @dma_mode: dma mode enable (1) or disable (0)
* @u32_count: number of bytes to be transferred
* @is_write: prefetch read(0) or write post(1) mode
*/
-int gpmc_prefetch_enable(int cs, int dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
{
- if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ if (fifo_th > PREFETCH_FIFOTHRESHOLD_MAX) {
+ printk(KERN_ERR "PREFETCH Fifo Threshold is not supported\n");
+ return -1;
+ } else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
/* Set the amount of bytes to be prefetched */
gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
@@ -554,7 +557,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
* enable the engine. Set which cs is has requested for.
*/
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs << CS_NUM_SHIFT) |
- PREFETCH_FIFOTHRESHOLD |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode << DMA_MPU_MODE) |
(0x1 & is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 4bdd851..40ce1db
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -79,6 +79,9 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)(val << 8)
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
@@ -129,7 +132,7 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 2fbdd66..f136fb5
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -280,7 +280,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info->gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info->nand.options & NAND_BUSWIDTH_16)
@@ -325,7 +326,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info->gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info->nand.options & NAND_BUSWIDTH_16)
@@ -381,10 +383,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
dma_addr_t dma_addr;
int ret;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+* and frame length is 32 bytes.
[PATCH v2 3/4] omap: nand: ecc layout select from board file
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver. And hw ecc layout selected for
sdp and zoom boards, by default.
Signed-off-by: Sukumar Ghorai
Signed-off-by: Vimal Singh
---
arch/arm/mach-omap2/board-flash.c |3 ++-
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 29 +
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index c6a07dd..ab31e7f 100755
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -143,7 +143,8 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
- board_nand_data.nr_parts= nr_parts;
+ board_nand_data.nr_parts= nr_parts;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
gpmc_nand_init(&board_nand_data);
}
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 5e69463..2e026e4 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -23,6 +23,12 @@ struct omap_nand_platform_data {
int gpmc_irq;
unsigned long phys_base;
int devsize;
+ enum {
+ OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT = 0,
+ /* 1-bit s/w ecc and layout different from romcode */
+ OMAP_ECC_HAMMING_CODE_HW,/* 1-bit ecc, romcode layout */
+ OMAP_ECC_HAMMING_CODE_SW,/* 1-bit ecc, romcode layout */
+ } ecc_opt;
};
/* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 00f88d6..d696026 100755
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -7,7 +7,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#define CONFIG_MTD_NAND_OMAP_HWECC
#include
#include
@@ -670,8 +669,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
return 0;
}
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
/**
* gen_true_ecc - This function will generate true ECC value
* @ecc_buf: buffer to store ecc code
@@ -891,8 +888,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
gpmc_enable_hwecc(info->gpmc_cs, mode, dev_width, info->nand.ecc.size);
}
-#endif
-
/**
* omap_wait - wait until the command is done
* @mtd: MTD device structure
@@ -1073,17 +1068,19 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
info->nand.verify_buf = omap_verify_buf;
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
- info->nand.ecc.bytes= 3;
- info->nand.ecc.size = 512;
- info->nand.ecc.calculate= omap_calculate_ecc;
- info->nand.ecc.hwctl= omap_enable_hwecc;
- info->nand.ecc.correct = omap_correct_data;
- info->nand.ecc.mode = NAND_ECC_HW;
-
-#else
- info->nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+ /* selsect the ecc type */
+ if ((pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) ||
+ (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW)) {
+ info->nand.ecc.bytes= 3;
+ info->nand.ecc.size = 512;
+ info->nand.ecc.calculate= omap_calculate_ecc;
+ info->nand.ecc.hwctl= omap_enable_hwecc;
+ info->nand.ecc.correct = omap_correct_data;
+ info->nand.ecc.mode = NAND_ECC_HW;
+
+ } else if (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_SW) {
+ info->nand.ecc.mode = NAND_ECC_SOFT;
+ }
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
--
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 0/4] nand prefetch-irq support and ecc layout chanage
The following set of patches applies on top of for-next branch. And is dependent on the following patches not yet applied onto this branch. 1. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30305.html 2. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30735.html v2: Rebase on latest codebase and previous patch(posted). v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (4): omap3: nand: prefetch in irq mode support omap: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-flash.c |4 +- arch/arm/mach-omap2/gpmc.c | 18 ++- arch/arm/mach-omap2/include/mach/board-flash.h |3 + arch/arm/plat-omap/include/plat/gpmc.h |8 +- arch/arm/plat-omap/include/plat/nand.h |7 + drivers/mtd/nand/Kconfig | 14 +- drivers/mtd/nand/omap2.c | 280 +--- 7 files changed, 300 insertions(+), 34 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: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c
On Thu, Jul 1, 2010 at 7:33 PM, Tony Lindgren wrote: > * Kyungmin Park [100701 11:12]: >> Hi, >> >> This value is set from bootloader, and kernel side only change the mode. >> Right it runs by luck. > > So should we just drop the omap_cfg_reg for now, then add it back > later with proper gpio_request etc? I mean the original patch is okay. Now that's find. I'll send a patch if require. Thank you, Kyungmin Park -- 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] OMAP4: Add support for PWM LED
* Hemanth V [100630 17:12]: > From 713727188b99465341767eedaa42004862261211 Mon Sep 17 00:00:00 2001 > From: Hemanth V > Date: Wed, 30 Jun 2010 18:16:33 +0530 > Subject: [PATCH] OMAP4: Add support for PWM LED > > TWL6030 supports PWM (Pulse Width Modulator) which is used > to control charging LED. This allows for controlling brightness > This patch implements the APIs needed by leds-pwm driver. > --- /dev/null > +++ b/arch/arm/mach-omap2/twl6030_pwm.c > @@ -0,0 +1,168 @@ > +/* > + * twl6030_pwm.c > + * Driver for PHOENIX (TWL6030) Pulse Width Modulator This should go to somewhere under drivers instead of arch/arm/mach-omap2. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] omap2/3/4: Add Kconfig option to compile in typical omap features
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Wednesday, June 30, 2010 12:55 PM > To: Shilimkar, Santosh > Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH 6/6] omap2/3/4: Add Kconfig option to compile in > typical omap features > > * Shilimkar, Santosh [100630 09:41]: > > > -Original Message- > > > From: Tony Lindgren [mailto:t...@atomide.com] > > > Sent: Wednesday, June 30, 2010 11:47 AM > > > To: Shilimkar, Santosh > > > Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org > > > Subject: Re: [PATCH 6/6] omap2/3/4: Add Kconfig option to compile in > > > typical omap features > > > > > > * Shilimkar, Santosh [100629 17:40]: > > > > > > > > > > > With your series OMAP4 build breaks because of PM and SMP > > > dependencies. > > > > > To ensure that build doesn't break on OMAP4, I needed below > change. > > > With > > > > > This change I tried your series and it boots OK on OMAP4430 SDP > > > > > > Hmm the build does not break for me? > > > > > Looks like I am missing something here. How do you build OMAP4 alone > with > > these new changes ?? > > Use your old config file, or just unselect CONFIG_ARCH_OMAP2 > and CONFIG_ARCH_OMAP3. Note that if you now do: > > $ yes "" | ARCH=arm make oldconfig > > with your old omap4 only config file, then by default the > typical features get added by default. So what you probably > want to do is (untested): > > $ echo "# CONFIG_ARCH_OMAP2PLUS_TYPICAL is not set" >> .config > $ yes "" | ARCH=arm make oldconfig > > Then it should not change your old config file. > The above method works Tony. The series boot tested with 4430 SDP Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c
* Kyungmin Park [100701 11:12]: > Hi, > > This value is set from bootloader, and kernel side only change the mode. > Right it runs by luck. So should we just drop the omap_cfg_reg for now, then add it back later with proper gpio_request etc? 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] [PATCH] [RFC][PATCH 8/8] OMAP: DSS2: Interface driver changes for Secondary LCD Channel
From: Sumit Semwal
Make necessary changes in the interface drivers for the dispc
functions which have the new enum channel added to them
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Mukund Mittal
Signed-off-by: Archit Taneja
Signed-off-by: Samreen
---
drivers/video/omap2/dss/core.c |2 +-
drivers/video/omap2/dss/dpi.c | 38 +-
drivers/video/omap2/dss/dsi.c | 22 --
drivers/video/omap2/dss/dss.h |8 +---
drivers/video/omap2/dss/rfbi.c | 21 -
drivers/video/omap2/dss/sdi.c | 22 --
6 files changed, 63 insertions(+), 50 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index b3a498f..e4909ad
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -411,7 +411,7 @@ static void dss_debug_dump_clocks(struct seq_file *s)
dss_dump_clocks(s);
dispc_dump_clocks(s);
#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_dump_clocks(s);
+ dsi_dump_clocks(OMAP_DSS_CHANNEL_LCD, s);
#endif
}
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 960e977..592c0c0
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -40,8 +40,9 @@ static struct {
} dpi;
#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
-static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
- unsigned long *fck, int *lck_div, int *pck_div)
+static int dpi_set_dsi_clk(enum omap_channel channel, bool is_tft,
+ unsigned long pck_req, unsigned long *fck, int *lck_div,
+ int *pck_div)
{
struct dsi_clock_info dsi_cinfo;
struct dispc_clock_info dispc_cinfo;
@@ -58,7 +59,7 @@ static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
dss_select_dispc_clk_source(DSS_SRC_DSI1_PLL_FCLK);
- r = dispc_set_clock_div(&dispc_cinfo);
+ r = dispc_set_clock_div(channel, &dispc_cinfo);
if (r)
return r;
@@ -69,8 +70,9 @@ static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
return 0;
}
#else
-static int dpi_set_dispc_clk(bool is_tft, unsigned long pck_req,
- unsigned long *fck, int *lck_div, int *pck_div)
+static int dpi_set_dispc_clk(enum omap_channel channel, bool is_tft,
+ unsigned long pck_req, unsigned long *fck, int *lck_div,
+ int *pck_div)
{
struct dss_clock_info dss_cinfo;
struct dispc_clock_info dispc_cinfo;
@@ -84,7 +86,7 @@ static int dpi_set_dispc_clk(bool is_tft, unsigned long
pck_req,
if (r)
return r;
- r = dispc_set_clock_div(&dispc_cinfo);
+ r = dispc_set_clock_div(channel, &dispc_cinfo);
if (r)
return r;
@@ -107,17 +109,17 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
- dispc_set_pol_freq(dssdev->panel.config, dssdev->panel.acbi,
- dssdev->panel.acb);
+ dispc_set_pol_freq(dssdev->channel, dssdev->panel.config,
+ dssdev->panel.acbi, dssdev->panel.acb);
is_tft = (dssdev->panel.config & OMAP_DSS_LCD_TFT) != 0;
#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
- r = dpi_set_dsi_clk(is_tft, t->pixel_clock * 1000,
- &fck, &lck_div, &pck_div);
+ r = dpi_set_dsi_clk(dssdev->channel, is_tft,
+ t->pixel_clock * 1000, &fck, &lck_div, &pck_div);
#else
- r = dpi_set_dispc_clk(is_tft, t->pixel_clock * 1000,
- &fck, &lck_div, &pck_div);
+ r = dpi_set_dispc_clk(dssdev->channel, is_tft,
+ t->pixel_clock * 1000, &fck, &lck_div, &pck_div);
#endif
if (r)
goto err0;
@@ -132,7 +134,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
t->pixel_clock = pck;
}
- dispc_set_lcd_timings(t);
+ dispc_set_lcd_timings(dssdev->channel, t);
err0:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
@@ -145,10 +147,12 @@ static int dpi_basic_init(struct omap_dss_device *dssdev)
is_tft = (dssdev->panel.config & OMAP_DSS_LCD_TFT) != 0;
- dispc_set_parallel_interface_mode(OMAP_DSS_PARALLELMODE_BYPASS);
- dispc_set_lcd_display_type(is_tft ? OMAP_DSS_LCD_DISPLAY_TFT :
- OMAP_DSS_LCD_DISPLAY_STN);
- dispc_set_tft_data_lines(dssdev->phy.dpi.data_lines);
+ dispc_set_parallel_interface_mode(dssdev->channel,
+ OMAP_DSS_PARALLELMODE_BYPASS);
+ dispc_set_lcd_display_type(dssdev->channel,
+ is_tft ? OMAP_DSS_LCD_DISPLAY_TFT : OMAP_DSS_LCD_DISPLAY_STN);
+ dispc_set_tft_data_lines(dssdev->channel,
+ dssdev->phy.dpi.data_lines);
return 0;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
[RFC][PATCH 7/8] OMAP: DSS2: Context Save and Restore of DISPC registers for Secondary LCD
From: Mayuresh Janorkar
Context Save and Restore of DISPC registers for Secondary LCD
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Mukund Mittal
Signed-off-by: Archit Taneja
Signed-off-by: Samreen
---
drivers/video/omap2/dss/dispc.c | 48 ++-
1 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 3dcd3fe..ca90593
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -237,6 +237,17 @@ void dispc_save_context(void)
SR(SIZE_DIG);
SR(SIZE_LCD);
+ if (cpu_is_omap44xx()) {
+ SR(CONTROL2);
+ SR(DEFAULT_COLOR2);
+ SR(TRANS_COLOR2);
+ SR(SIZE_LCD2);
+ SR(TIMING_H2);
+ SR(TIMING_V2);
+ SR(POL_FREQ2);
+ SR(DIVISOR2);
+ SR(CONFIG2);
+ }
SR(GFX_BA0);
SR(GFX_BA1);
SR(GFX_POSITION);
@@ -256,6 +267,15 @@ void dispc_save_context(void)
SR(CPR_COEF_G);
SR(CPR_COEF_B);
+ if (cpu_is_omap44xx()) {
+ SR(CPR2_COEF_B);
+ SR(CPR2_COEF_G);
+ SR(CPR2_COEF_R);
+
+ SR(DATA2_CYCLE1);
+ SR(DATA2_CYCLE2);
+ SR(DATA2_CYCLE3);
+ }
SR(GFX_PRELOAD);
/* VID1 */
@@ -376,6 +396,22 @@ void dispc_restore_context(void)
RR(SIZE_DIG);
RR(SIZE_LCD);
+ if (cpu_is_omap44xx()) {
+ RR(DEFAULT_COLOR2);
+ RR(TRANS_COLOR2);
+ RR(CPR2_COEF_B);
+ RR(CPR2_COEF_G);
+ RR(CPR2_COEF_R);
+ RR(DATA2_CYCLE1);
+ RR(DATA2_CYCLE2);
+ RR(DATA2_CYCLE3);
+ RR(SIZE_LCD2);
+ RR(TIMING_H2);
+ RR(TIMING_V2);
+ RR(POL_FREQ2);
+ RR(DIVISOR2);
+ RR(CONFIG2);
+ }
RR(GFX_BA0);
RR(GFX_BA1);
RR(GFX_POSITION);
@@ -395,6 +431,15 @@ void dispc_restore_context(void)
RR(CPR_COEF_G);
RR(CPR_COEF_B);
+ if (cpu_is_omap44xx()) {
+ RR(CPR2_COEF_B);
+ RR(CPR2_COEF_G);
+ RR(CPR2_COEF_R);
+
+ RR(DATA2_CYCLE1);
+ RR(DATA2_CYCLE2);
+ RR(DATA2_CYCLE3);
+ }
RR(GFX_PRELOAD);
/* VID1 */
@@ -497,7 +542,8 @@ void dispc_restore_context(void)
/* enable last, because LCD & DIGIT enable are here */
RR(CONTROL);
-
+ if (cpu_is_omap44xx())
+ RR(CONTROL2);
/* clear spurious SYNC_LOST_DIGIT interrupts */
dispc_write_reg(DISPC_IRQSTATUS, DISPC_IRQ_SYNC_LOST_DIGIT);
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RFC][PATCH 6/8] OMAP: DSS2: Secondary LCD Channel DISPC IRQs
From: Sumit Semwal
Introduce Secondary Channel IRQS for dumps and error handling
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Mukund Mittal
Signed-off-by: Archit Taneja
Signed-off-by: Samreen
---
arch/arm/plat-omap/include/plat/display.h |4 ++
drivers/video/omap2/dss/dispc.c | 62 +++--
drivers/video/omap2/dss/manager.c | 33 +++-
3 files changed, 85 insertions(+), 14 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index c3643f5..cfcde7d
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -42,6 +42,10 @@
#define DISPC_IRQ_SYNC_LOST(1 << 14)
#define DISPC_IRQ_SYNC_LOST_DIGIT (1 << 15)
#define DISPC_IRQ_WAKEUP (1 << 16)
+#define DISPC_IRQ_SYNC_LOST_2 (1 << 17)
+#define DISPC_IRQ_VSYNC2 (1 << 18)
+#define DISPC_IRQ_ACBIAS_COUNT_STAT2 (1 << 21)
+#define DISPC_IRQ_FRAMEDONE2 (1 << 22)
struct omap_dss_device;
struct omap_overlay_manager;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 22fd2c2..785b8c1
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -134,7 +134,9 @@ struct dispc_reg { u16 idx; };
DISPC_IRQ_VID1_FIFO_UNDERFLOW | \
DISPC_IRQ_VID2_FIFO_UNDERFLOW | \
DISPC_IRQ_SYNC_LOST | \
-DISPC_IRQ_SYNC_LOST_DIGIT)
+ DISPC_IRQ_SYNC_LOST_DIGIT | \
+ (cpu_is_omap44xx() ? \
+ DISPC_IRQ_SYNC_LOST_2 : 0))
/* OMAP4 new global registers */
#define DISPC_CONTROL2 DISPC_REG(0x0238)
@@ -1819,20 +1821,27 @@ static void dispc_enable_lcd_out(enum omap_channel
channel, bool enable)
struct completion frame_done_completion;
bool is_on;
int r;
+ int irq;
enable_clocks(1);
/* When we disable LCD output, we need to wait until frame is done.
* Otherwise the DSS is still working, and turning off the clocks
* prevents DSS from going to OFF mode */
- is_on = REG_GET(DISPC_CONTROL, 0, 0);
+ if (OMAP_DSS_CHANNEL_LCD2 == channel) {
+ is_on = REG_GET(DISPC_CONTROL2, 0, 0);
+ irq = DISPC_IRQ_FRAMEDONE2;
+ } else {
+ is_on = REG_GET(DISPC_CONTROL, 0, 0);
+ irq = DISPC_IRQ_FRAMEDONE;
+ }
if (!enable && is_on) {
init_completion(&frame_done_completion);
r = omap_dispc_register_isr(dispc_disable_isr,
&frame_done_completion,
- DISPC_IRQ_FRAMEDONE);
+ irq);
if (r)
DSSERR("failed to register FRAMEDONE isr\n");
@@ -1847,7 +1856,7 @@ static void dispc_enable_lcd_out(enum omap_channel
channel, bool enable)
r = omap_dispc_unregister_isr(dispc_disable_isr,
&frame_done_completion,
- DISPC_IRQ_FRAMEDONE);
+ irq);
if (r)
DSSERR("failed to unregister FRAMEDONE isr\n");
@@ -2482,6 +2491,12 @@ void dispc_dump_irqs(struct seq_file *s)
PIS(SYNC_LOST);
PIS(SYNC_LOST_DIGIT);
PIS(WAKEUP);
+ if (cpu_is_omap44xx()) {
+ PIS(FRAMEDONE2);
+ PIS(VSYNC2);
+ PIS(ACBIAS_COUNT_STAT2);
+ PIS(SYNC_LOST_2);
+ }
#undef PIS
}
#endif
@@ -3089,6 +3104,45 @@ static void dispc_error_worker(struct work_struct *work)
}
}
+ if (errors & DISPC_IRQ_SYNC_LOST_2) {
+ struct omap_overlay_manager *manager = NULL;
+ bool enable = false;
+
+ DSSERR("SYNC_LOST for LCD2, disabling LCD2\n");
+
+ for (i = 0; i < omap_dss_get_num_overlay_managers(); ++i) {
+ struct omap_overlay_manager *mgr;
+ mgr = omap_dss_get_overlay_manager(i);
+
+ if (mgr->id == OMAP_DSS_CHANNEL_LCD2) {
+ manager = mgr;
+ enable = mgr->device->state ==
+ OMAP_DSS_DISPLAY_ACTIVE;
+ mgr->device->driver->disable(mgr->device);
+ break;
+ }
+ }
+
+ if (manager) {
+ for (i = 0; i < omap_dss_get_num_overlays(); ++i) {
+ struct omap_overlay *ovl;
+ ovl = omap_dss_get_overlay(i);
+
+
[RFC][PATCH 5/8] OMAP: DSS2: Secondary LCD Channel in DISPC functions
From: Sumit Semwal
Introduce the new enum channel as a parameter in all dispc functions
used by interface drivers(dsi, sdi etc) in order to differentiate
between the 2 channels
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Mukund Mittal
Signed-off-by: Archit Taneja
Signed-off-by: Samreen
---
drivers/video/omap2/dss/dispc.c | 326 ---
drivers/video/omap2/dss/dss.h | 29 ++--
2 files changed, 253 insertions(+), 102 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 08b36d6..22fd2c2
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -521,12 +521,17 @@ bool dispc_go_busy(enum omap_channel channel)
{
int bit;
- if (channel == OMAP_DSS_CHANNEL_LCD)
+ if ((!cpu_is_omap44xx()) && (channel == OMAP_DSS_CHANNEL_LCD))
+ bit = 5; /* GOLCD */
+ else if (cpu_is_omap44xx() && (channel != OMAP_DSS_CHANNEL_DIGIT))
bit = 5; /* GOLCD */
else
bit = 6; /* GODIGIT */
- return REG_GET(DISPC_CONTROL, bit, bit) == 1;
+ if (cpu_is_omap44xx() && (channel == OMAP_DSS_CHANNEL_LCD2))
+ return REG_GET(DISPC_CONTROL2, bit, bit) == 1;
+ else
+ return REG_GET(DISPC_CONTROL, bit, bit) == 1;
}
void dispc_go(enum omap_channel channel)
@@ -535,28 +540,47 @@ void dispc_go(enum omap_channel channel)
enable_clocks(1);
- if (channel == OMAP_DSS_CHANNEL_LCD)
+ if ((channel == OMAP_DSS_CHANNEL_LCD) ||
+ (channel == OMAP_DSS_CHANNEL_LCD2))
bit = 0; /* LCDENABLE */
else
bit = 1; /* DIGITALENABLE */
/* if the channel is not enabled, we don't need GO */
- if (REG_GET(DISPC_CONTROL, bit, bit) == 0)
- goto end;
+ if (cpu_is_omap44xx() && (channel == OMAP_DSS_CHANNEL_LCD2)) {
+ if (REG_GET(DISPC_CONTROL2, bit, bit) == 0)
+ goto end;
+ } else {
+ if (REG_GET(DISPC_CONTROL, bit, bit) == 0)
+ goto end;
+ }
- if (channel == OMAP_DSS_CHANNEL_LCD)
+ if ((channel == OMAP_DSS_CHANNEL_LCD) ||
+ (channel == OMAP_DSS_CHANNEL_LCD2))
bit = 5; /* GOLCD */
else
bit = 6; /* GODIGIT */
- if (REG_GET(DISPC_CONTROL, bit, bit) == 1) {
- DSSERR("GO bit not down for channel %d\n", channel);
- goto end;
+ if (cpu_is_omap44xx() && (channel == OMAP_DSS_CHANNEL_LCD2)) {
+ if (REG_GET(DISPC_CONTROL2, bit, bit) == 1) {
+ DSSERR("GO bit not down for channel %d\n", channel);
+ goto end;
+ }
+ } else {
+ if (REG_GET(DISPC_CONTROL, bit, bit) == 1) {
+ DSSERR("GO bit not down for channel %d\n", channel);
+ goto end;
+ }
}
- DSSDBG("GO %s\n", channel == OMAP_DSS_CHANNEL_LCD ? "LCD" : "DIGIT");
+ DSSDBG("GO %s\n", channel == OMAP_DSS_CHANNEL_LCD ? "LCD" :
+ channel == OMAP_DSS_CHANNEL_LCD2 ? "LCD2" : "DIGIT");
+
+ if (cpu_is_omap44xx() && (channel == OMAP_DSS_CHANNEL_LCD2))
+ REG_FLD_MOD(DISPC_CONTROL2, 1, bit, bit);
+ else
+ REG_FLD_MOD(DISPC_CONTROL, 1, bit, bit);
- REG_FLD_MOD(DISPC_CONTROL, 1, bit, bit);
end:
enable_clocks(0);
}
@@ -898,6 +922,7 @@ static void _dispc_set_channel_out(enum omap_plane plane,
{
int shift;
u32 val;
+ int chan = 0, chan2 = 0;
switch (plane) {
case OMAP_DSS_GFX:
@@ -913,7 +938,30 @@ static void _dispc_set_channel_out(enum omap_plane plane,
}
val = dispc_read_reg(dispc_reg_att[plane]);
- val = FLD_MOD(val, channel, shift, shift);
+ if (cpu_is_omap44xx()) {
+ switch (channel) {
+
+ case OMAP_DSS_CHANNEL_LCD:
+ chan = 0;
+ chan2 = 0;
+ break;
+ case OMAP_DSS_CHANNEL_DIGIT:
+ chan = 1;
+ chan2 = 0;
+ break;
+ case OMAP_DSS_CHANNEL_LCD2:
+ chan = 0;
+ chan2 = 1;
+ break;
+ default:
+ BUG();
+ }
+
+ val = FLD_MOD(val, chan, shift, shift);
+ val = FLD_MOD(val, chan2, 31, 30);
+ } else {
+ val = FLD_MOD(val, channel, shift, shift);
+ }
dispc_write_reg(dispc_reg_att[plane], val);
}
@@ -970,13 +1018,16 @@ void dispc_enable_replication(enum omap_plane plane,
bool enable)
enable_clocks(0);
}
-void dispc_set_lcd_size(u16 width, u16 height)
+void dispc_set_lcd_size(enum omap_channel
[RFC][PATCH 4/8] OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers
From: Semwal, Sumit
Introduce OMAP4 DISPC base address and Secondary LCD Channel registers, use them
in register dumps.
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Mukund Mittal
Signed-off-by: Archit Taneja
Signed-off-by: Samreen
---
drivers/video/omap2/dss/dispc.c | 42 ++-
1 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5ecdc00..08b36d6
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -41,9 +41,13 @@
#include "dss.h"
/* DISPC */
+#ifdef CONFIG_ARCH_OMAP4
+#define DISPC_BASE 0x58001000
+#define DISPC_SZ_REGS SZ_16K
+#else
#define DISPC_BASE 0x48050400
-
#define DISPC_SZ_REGS SZ_1K
+#endif
struct dispc_reg { u16 idx; };
@@ -68,6 +72,7 @@ struct dispc_reg { u16 idx; };
#define DISPC_TIMING_V DISPC_REG(0x0068)
#define DISPC_POL_FREQ DISPC_REG(0x006C)
#define DISPC_DIVISOR DISPC_REG(0x0070)
+#define DISPC_DIVISOR1 DISPC_REG(0x0804)
#define DISPC_GLOBAL_ALPHA DISPC_REG(0x0074)
#define DISPC_SIZE_DIG DISPC_REG(0x0078)
#define DISPC_SIZE_LCD DISPC_REG(0x007C)
@@ -131,6 +136,23 @@ struct dispc_reg { u16 idx; };
DISPC_IRQ_SYNC_LOST | \
DISPC_IRQ_SYNC_LOST_DIGIT)
+/* OMAP4 new global registers */
+#define DISPC_CONTROL2 DISPC_REG(0x0238)
+#define DISPC_DEFAULT_COLOR2 DISPC_REG(0x03AC)
+#define DISPC_TRANS_COLOR2 DISPC_REG(0x03B0)
+#define DISPC_CPR2_COEF_B DISPC_REG(0x03B4)
+#define DISPC_CPR2_COEF_G DISPC_REG(0x03B8)
+#define DISPC_CPR2_COEF_R DISPC_REG(0x03BC)
+#define DISPC_DATA2_CYCLE1 DISPC_REG(0x03C0)
+#define DISPC_DATA2_CYCLE2 DISPC_REG(0x03C4)
+#define DISPC_DATA2_CYCLE3 DISPC_REG(0x03C8)
+#define DISPC_SIZE_LCD2DISPC_REG(0x03CC)
+#define DISPC_TIMING_H2DISPC_REG(0x0400)
+#define DISPC_TIMING_V2DISPC_REG(0x0404)
+#define DISPC_POL_FREQ2DISPC_REG(0x0408)
+#define DISPC_DIVISOR2 DISPC_REG(0x040C)
+#define DISPC_CONFIG2 DISPC_REG(0x0620)
+
#define DISPC_MAX_NR_ISRS 8
struct omap_dispc_isr_data {
@@ -2361,6 +2383,24 @@ void dispc_dump_regs(struct seq_file *s)
DUMPREG(DISPC_SIZE_DIG);
DUMPREG(DISPC_SIZE_LCD);
+ /* OMAP4 LCD2 channel registers*/
+ if (cpu_is_omap44xx()) {
+ DUMPREG(DISPC_CONTROL2);
+ DUMPREG(DISPC_DEFAULT_COLOR2);
+ DUMPREG(DISPC_TRANS_COLOR2);
+ DUMPREG(DISPC_CPR2_COEF_B);
+ DUMPREG(DISPC_CPR2_COEF_G);
+ DUMPREG(DISPC_CPR2_COEF_R);
+ DUMPREG(DISPC_DATA2_CYCLE1);
+ DUMPREG(DISPC_DATA2_CYCLE2);
+ DUMPREG(DISPC_DATA2_CYCLE3);
+ DUMPREG(DISPC_SIZE_LCD2);
+ DUMPREG(DISPC_TIMING_H2);
+ DUMPREG(DISPC_TIMING_V2);
+ DUMPREG(DISPC_POL_FREQ2);
+ DUMPREG(DISPC_DIVISOR2);
+ DUMPREG(DISPC_CONFIG2);
+ }
DUMPREG(DISPC_GFX_BA0);
DUMPREG(DISPC_GFX_BA1);
DUMPREG(DISPC_GFX_POSITION);
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections
From: Sumit Semwal
The addition of the new 2lcd manager requires modifications in the
dss_recheck_connections patch, this function behaves the same if
the 2lcd manager doesn't exist
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Mukund Mittal
Signed-off-by: Archit Taneja
Signed-off-by: Samreen
---
drivers/video/omap2/dss/overlay.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 8233658..c7ad1d1
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -627,12 +627,22 @@ void dss_recheck_connections(struct omap_dss_device
*dssdev, bool force)
int i;
struct omap_overlay_manager *lcd_mgr;
struct omap_overlay_manager *tv_mgr;
+ struct omap_overlay_manager *lcd2_mgr = NULL;
struct omap_overlay_manager *mgr = NULL;
lcd_mgr = omap_dss_get_overlay_manager(OMAP_DSS_OVL_MGR_LCD);
tv_mgr = omap_dss_get_overlay_manager(OMAP_DSS_OVL_MGR_TV);
-
- if (dssdev->type != OMAP_DISPLAY_TYPE_VENC) {
+ if (cpu_is_omap44xx())
+ lcd2_mgr = omap_dss_get_overlay_manager(OMAP_DSS_OVL_MGR_LCD2);
+
+ if (dssdev->channel == OMAP_DSS_CHANNEL_LCD2) {
+ if (!lcd2_mgr->device || force) {
+ if (lcd2_mgr->device)
+ lcd2_mgr->unset_device(lcd2_mgr);
+ lcd2_mgr->set_device(lcd2_mgr, dssdev);
+ mgr = lcd2_mgr;
+ }
+ } else if (dssdev->type != OMAP_DISPLAY_TYPE_VENC) {
if (!lcd_mgr->device || force) {
if (lcd_mgr->device)
lcd_mgr->unset_device(lcd_mgr);
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RFC][PATCH 2/8] OMAP: DSS2: Add new Overlay Manager
From: Sumit Semwal
Add new Overlay Manager in manager.c, make secondary channel changes
and update supported displays for the managers in OMAP4
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Mukund Mittal
Signed-off-by: Archit Taneja
Signed-off-by: Samreen
---
drivers/video/omap2/dss/manager.c | 54 ++---
1 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 6a649ab..2636b7f
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -34,6 +34,8 @@
#include "dss.h"
+#define MAX_DSS_MANAGERS (cpu_is_omap44xx() ? 3 : 2)
+
static int num_managers;
static struct list_head manager_list;
@@ -449,7 +451,7 @@ struct manager_cache_data {
static struct {
spinlock_t lock;
struct overlay_cache_data overlay_cache[3];
- struct manager_cache_data manager_cache[2];
+ struct manager_cache_data manager_cache[3];
bool irq_enabled;
} dss_cache;
@@ -531,10 +533,9 @@ static int dss_mgr_wait_for_go(struct omap_overlay_manager
*mgr)
if (!dssdev || dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return 0;
-
+ channel = mgr->device->channel;
if (dssdev->type == OMAP_DISPLAY_TYPE_VENC) {
irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN;
- channel = OMAP_DSS_CHANNEL_DIGIT;
} else {
if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
enum omap_dss_update_mode mode;
@@ -546,7 +547,6 @@ static int dss_mgr_wait_for_go(struct omap_overlay_manager
*mgr)
} else {
irq = DISPC_IRQ_VSYNC;
}
- channel = OMAP_DSS_CHANNEL_LCD;
}
mc = &dss_cache.manager_cache[mgr->id];
@@ -604,13 +604,13 @@ int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl)
return 0;
dssdev = ovl->manager->device;
+ channel = dssdev->channel;
if (!dssdev || dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return 0;
if (dssdev->type == OMAP_DISPLAY_TYPE_VENC) {
irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN;
- channel = OMAP_DSS_CHANNEL_DIGIT;
} else {
if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
enum omap_dss_update_mode mode;
@@ -622,7 +622,6 @@ int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl)
} else {
irq = DISPC_IRQ_VSYNC;
}
- channel = OMAP_DSS_CHANNEL_LCD;
}
oc = &dss_cache.overlay_cache[ovl->id];
@@ -841,7 +840,8 @@ static int configure_overlay(enum omap_plane plane)
c->rotation_type,
c->rotation,
c->mirror,
- c->global_alpha);
+ c->global_alpha,
+ c->channel);
if (r) {
/* this shouldn't happen */
@@ -883,20 +883,20 @@ static int configure_dispc(void)
struct overlay_cache_data *oc;
struct manager_cache_data *mc;
const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
- const int num_mgrs = ARRAY_SIZE(dss_cache.manager_cache);
+ const int num_mgrs = MAX_DSS_MANAGERS;
int i;
int r;
- bool mgr_busy[2];
- bool mgr_go[2];
+ bool mgr_busy[MAX_DSS_MANAGERS];
+ bool mgr_go[MAX_DSS_MANAGERS];
bool busy;
r = 0;
busy = false;
- mgr_busy[0] = dispc_go_busy(0);
- mgr_busy[1] = dispc_go_busy(1);
- mgr_go[0] = false;
- mgr_go[1] = false;
+ for (i = 0; i < num_mgrs; i++) {
+ mgr_busy[i] = dispc_go_busy(i);
+ mgr_go[i] = false;
+ }
/* Commit overlay settings */
for (i = 0; i < num_ovls; ++i) {
@@ -1122,7 +1122,7 @@ void dss_start_update(struct omap_dss_device *dssdev)
struct manager_cache_data *mc;
struct overlay_cache_data *oc;
const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
- const int num_mgrs = ARRAY_SIZE(dss_cache.manager_cache);
+ const int num_mgrs = MAX_DSS_MANAGERS;
struct omap_overlay_manager *mgr;
int i;
@@ -1154,10 +1154,10 @@ static void dss_apply_irq_handler(void *data, u32 mask)
const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
const int num_mgrs = ARRAY_SIZE(dss_cache.manager_cache);
int i, r;
- bool mgr_busy[2];
+ bool mgr_busy[MAX_DSS_MANAGERS];
- mgr_busy[0] = dispc_go_busy(0);
- mgr_busy[1] = dispc_go_busy(1);
+ for (i = 0; i < num_mgrs; i++)
+ mgr_busy[i] = dispc_go_busy(i);
spin_lock(&dss_cache.lock);
@@ -1461,7 +1461,7 @@ int dss_init_overlay_managers(struct platform_device
*pdev)
[RFC][PATCH 1/8] OMAP: DSS2: Overlay Manager LCD2 changes in dispay.h
From: Sumit Semwal
Overlay Manager LCD2 changes in dispay.h
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Mukund Mittal
Signed-off-by: Archit Taneja
Signed-off-by: Samreen
---
arch/arm/plat-omap/include/plat/display.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 8bd15bd..c3643f5
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -64,6 +64,7 @@ enum omap_plane {
enum omap_channel {
OMAP_DSS_CHANNEL_LCD= 0,
OMAP_DSS_CHANNEL_DIGIT = 1,
+ OMAP_DSS_CHANNEL_LCD2 = 2,
};
enum omap_color_mode {
@@ -173,6 +174,7 @@ enum omap_dss_display_state {
enum omap_dss_overlay_managers {
OMAP_DSS_OVL_MGR_LCD,
OMAP_DSS_OVL_MGR_TV,
+ OMAP_DSS_OVL_MGR_LCD2,
};
enum omap_dss_rotation_type {
@@ -462,6 +464,7 @@ struct omap_dss_device {
struct omap_overlay_manager *manager;
enum omap_dss_display_state state;
+ enum omap_channel channel;
/* platform specific */
int (*platform_enable)(struct omap_dss_device *dssdev);
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/8] OMAP: DSS2: Overlay Manager LCD2 support in DISPC
From: Semwal, Sumit This patch series incorporates changes in DSS2 to enable omap_dss_device instances to use the new Overlay Manager LCD2 in DISPC. On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. This channel's video port is a source port for RFBI, DSI2 and DPI. The Primary channel's video port is connected to RFBI and DSI1. There is a set of regsiters for LCD2 channel similar to the existing LCD channel, like DISPC_CONTROL2, DISPC_DIVISOR2, DISPC_CONFIG2 and so on. In order to decide which LCD Overlay Manager to configure(LCD/LCD2), there is a need for the omap_dss_device instances to tell the interface drivers(DSI, DPI, RFBI etc) which LCD channel they want to connect to, so that the corresponding registers get configured. Therefore, a new enum omap_channel member is introduced to omap_dss_device. This design was made keeping in mind the possible addition of more Overlay Managers in future OMAPs, this code is also backward compatible with OMAP3 as omap_dss_device instances in OMAP3 will stick only with OMAP_DSS_CHANNEL_LCD. Sumit Semwal (7): OMAP: DSS2: Overlay Manager LCD2 changes in dispay.h OMAP: DSS2: Add new Overlay Manager OMAP: DSS2: Modify dss_recheck_connections OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers OMAP: DSS2: Secondary LCD Channel in DISPC functions OMAP: DSS2: Secondary LCD Channel DISPC IRQs OMAP: DSS2: Interface driver changes for Secondary LCD Channel Mayuresh Janorkar (1) OMAP: DSS2: Context Save and Restore of DISPC registers for Secondary LCD arch/arm/plat-omap/include/plat/display.h |7 + drivers/video/omap2/dss/core.c|2 +- drivers/video/omap2/dss/dispc.c | 478 +++-- drivers/video/omap2/dss/dpi.c | 38 ++- drivers/video/omap2/dss/dsi.c | 22 +- drivers/video/omap2/dss/dss.h | 37 ++- drivers/video/omap2/dss/manager.c | 87 -- drivers/video/omap2/dss/overlay.c | 14 +- drivers/video/omap2/dss/rfbi.c| 21 +- drivers/video/omap2/dss/sdi.c | 22 +- 10 files changed, 536 insertions(+), 192 deletions(-) -- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 7/8] omap3: pm: Use generic TRITON power scripts for 3430SDP board
This patch has the changes to remove the sleep/wakeup/warm_rest sequence &
resource configuration from the 3430SDP board file and use the generic script.
Updating the sleep/wakeup/warm_rest sequence & resource configuration in the
board file from generic script file.
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-3430sdp.c | 92 +-
include/linux/i2c/twl.h |4 ++
3 files changed, 9 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 184badd..f60dca3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -127,7 +127,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)+= board-omap3pandora.o
\
hsmmc.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
hsmmc.o \
- board-sdp-flash.o
+ board-sdp-flash.o \
+ twl4030.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index c7f0fa8..b5786e2 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -46,6 +46,7 @@
#include "mux.h"
#include "sdram-qimonda-hyb18m512160af-6.h"
#include "hsmmc.h"
+#include "twl4030.h"
#include "pm.h"
#include "omap3-opp.h"
#include "smartreflex-class3.h"
@@ -424,95 +425,7 @@ static struct twl4030_madc_platform_data sdp3430_madc_data
= {
.irq_line = 1,
};
-
-static struct twl4030_ins __initdata sleep_on_seq[] = {
- /* Turn off HFCLKOUT */
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_OFF), 2},
- /* Turn OFF VDD1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 2},
- /* Turn OFF VDD2 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_OFF), 2},
- /* Turn OFF VPLL1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 2},
-};
-
-static struct twl4030_script sleep_on_script __initdata = {
- .script = sleep_on_seq,
- .size = ARRAY_SIZE(sleep_on_seq),
- .flags = TWL4030_SLEEP_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p12_seq[] __initdata = {
- /* Turn on HFCLKOUT */
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- /* Turn ON VDD1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 2},
- /* Turn ON VDD2 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 2},
- /* Turn ON VPLL1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p12_script __initdata = {
- .script = wakeup_p12_seq,
- .size = ARRAY_SIZE(wakeup_p12_seq),
- .flags = TWL4030_WAKEUP12_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p3_seq[] __initdata = {
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p3_script __initdata = {
- .script = wakeup_p3_seq,
- .size = ARRAY_SIZE(wakeup_p3_seq),
- .flags = TWL4030_WAKEUP3_SCRIPT,
-};
-
-static struct twl4030_ins wrst_seq[] __initdata = {
-/*
- * Reset twl4030.
- * Reset VDD1 regulator.
- * Reset VDD2 regulator.
- * Reset VPLL1 regulator.
- * Enable sysclk output.
- * Reenable twl4030.
- */
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
-};
-static struct twl4030_script wrst_script __initdata = {
- .script = wrst_seq,
- .size = ARRAY_SIZE(wrst_seq),
- .flags = TWL4030_WRST_SCRIPT,
-};
-
-static struct twl4030_script *twl4030_scripts[] __initdata = {
- &sleep_on_script,
- &wakeup_p12_script,
- &wakeup_p3_script,
- &wrst_script,
-};
-
-static struct twl4030_resconfig twl4030_rconfig[] = {
- { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
- .type2 = -1 },
- { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
- .type2 = -1 },
- { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
- .type2 = -1 },
- { 0, 0},
-};
-
-static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
- .scripts= twl4030_scripts,
- .num= ARRAY_SIZE(twl4030_scripts),
- .resource_config = twl4030_rconfig,
-};
+static struct __initdata twl4030_power_data sdp
[PATCH v7 8/8] omap3: pm: Use generic TRITON power scripts for ZOOM[2,3], 3630SDP board
Adding the power script data for zoom board to TWL4030 platform data.
Updating the sleep/wakeup/warm_reset sequence & resource configuration
from generic script file.
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
arch/arm/mach-omap2/Makefile |9 ++---
arch/arm/mach-omap2/board-zoom-peripherals.c |6 ++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f60dca3..ba3de05 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -137,14 +137,17 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
hsmmc.o \
- board-zoom-debugboard.o
+ board-zoom-debugboard.o \
+ twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
hsmmc.o \
- board-zoom-debugboard.o
+ board-zoom-debugboard.o \
+ twl4030.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
- hsmmc.o
+ hsmmc.o \
+ twl4030.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..ea9b921 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -26,6 +26,7 @@
#include "mux.h"
#include "hsmmc.h"
+#include "twl4030.h"
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -94,6 +95,8 @@ static struct twl4030_keypad_data zoom_kp_twl4030_data = {
.rep= 1,
};
+static struct __initdata twl4030_power_data zoom_t2scripts_data;
+
static struct regulator_consumer_supply zoom_vmmc1_supply = {
.supply = "vmmc",
};
@@ -239,6 +242,7 @@ static struct twl4030_platform_data zoom_twldata = {
.usb= &zoom_usb_data,
.gpio = &zoom_gpio_data,
.keypad = &zoom_kp_twl4030_data,
+ .power = &zoom_t2scripts_data,
.codec = &zoom_codec_data,
.vmmc1 = &zoom_vmmc1,
.vmmc2 = &zoom_vmmc2,
@@ -279,6 +283,8 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
+ twl4030_get_scripts(&zoom_t2scripts_data);
+
omap_i2c_init();
usb_musb_init(&musb_board_data);
enable_board_wakeup_source();
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 6/8] omap3: pm: Generic TRITON power scripts for OMAP3 based boards
This patch will create the generic TRITON power scripts which can be used
by different OMAP3 boards with the same power companion chip (TWL4030 series).
Added the api(twl4030_get_scripts/twl4030_get_vc_timings) to update the
sleep/wakeup/warm_reset sequence, resource configuration & voltsetup_time
in the board file.
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
arch/arm/mach-omap2/twl4030.c | 185 +
arch/arm/mach-omap2/twl4030.h | 23 +
arch/arm/mach-omap2/voltage.c |5 +-
3 files changed, 210 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/twl4030.c
create mode 100644 arch/arm/mach-omap2/twl4030.h
diff --git a/arch/arm/mach-omap2/twl4030.c b/arch/arm/mach-omap2/twl4030.c
new file mode 100644
index 000..c493e5f
--- /dev/null
+++ b/arch/arm/mach-omap2/twl4030.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Lesly A M
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifdef CONFIG_TWL4030_POWER
+
+#include "twl4030.h"
+
+static struct prm_setup_vc twl4030_voltsetup_time = {
+ /* VOLT SETUPTIME for RET */
+ .ret = {
+ .voltsetup1_vdd1 = 0x005B,
+ .voltsetup1_vdd2 = 0x0055,
+ .voltsetup2 = 0x0,
+ .voltoffset = 0x0,
+ },
+ /* VOLT SETUPTIME for OFF */
+ .off = {
+ .voltsetup1_vdd1 = 0x00B3,
+ .voltsetup1_vdd2 = 0x00A0,
+ .voltsetup2 = 0x118,
+ .voltoffset = 0x32,
+ },
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system goes into sleep.
+ * Executed upon P1_P2/P3 transition for sleep.
+ */
+static struct twl4030_ins __initdata sleep_on_seq[] = {
+ /* Broadcast message to put res to sleep */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_SLEEP), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_SLEEP), 2},
+};
+
+static struct twl4030_script sleep_on_script __initdata = {
+ .script = sleep_on_seq,
+ .size = ARRAY_SIZE(sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system wakeup from sleep.
+ * Executed upon P1_P2 transition for wakeup.
+ */
+static struct twl4030_ins wakeup_p12_seq[] __initdata = {
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p12_script __initdata = {
+ .script = wakeup_p12_seq,
+ .size = ARRAY_SIZE(wakeup_p12_seq),
+ .flags = TWL4030_WAKEUP12_SCRIPT,
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system wakeup from sleep.
+ * Executed upon P3 transition for wakeup.
+ */
+static struct twl4030_ins wakeup_p3_seq[] __initdata = {
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p3_script __initdata = {
+ .script = wakeup_p3_seq,
+ .size = ARRAY_SIZE(wakeup_p3_seq),
+ .flags = TWL4030_WAKEUP3_SCRIPT,
+};
+
+/*
+ * Sequence to reset the TRITON Power resources,
+ * when the system gets warm reset.
+ * Executed upon warm reset signal.
+ */
+static struct twl4030_ins wrst_seq[] __initdata = {
+/*
+ * Reset twl4030.
+ * Reset Main_Ref.
+ * Reset All type2_group2.
+ * Reset VUSB_3v1.
+ * Reset All type2_group1.
+ * Reset RC.
+ * Reenable twl4030.
+ */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_Main_Ref, RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_WRST), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VUSB_3V1, RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_RC, RES_TYPE_ALL, RES_TYPE2_R0,
+ RES_STATE_WRST), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+/* TRITON script for s
[PATCH v7 4/8] omap3: pm: re-programing the setup time based on CORE_DOMAIN target state
This patch will add a new function omap_voltage_vc_update() to re-program
the VC parameters while entering low power mode, based on CORE_DOMAIN target
state.
The voltsetup2 is used only when the device exits sys_off mode
(with PRM_VOLTCTRL[3]SEL_OFF set to 1).
Also removed the clearing of PRM_VOLTCTRL register bits
(SEL_OFF, AUTO_OFF, AUTO_RET, ...) after wakeup from wfi,
because this will be used by the voltage FSM only when
it goes to low power mode next time. So it is not necessary
to clear these bits, if we are reconfiguring it each time before
entering the low power modes.
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
arch/arm/mach-omap2/pm34xx.c | 26 +++---
arch/arm/mach-omap2/voltage.c | 40
arch/arm/mach-omap2/voltage.h |1 +
3 files changed, 44 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 5039b35..1ff6293 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -439,20 +439,12 @@ void omap_sram_idle(void)
if (core_next_state < PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
- if (core_next_state == PWRDM_POWER_OFF) {
- u32 voltctrl = OMAP3430_AUTO_OFF;
+ /* Update the voltsetup time for RET/OFF */
+ omap_voltage_vc_update(core_next_state);
- if (voltage_off_while_idle)
- voltctrl |= OMAP3430_SEL_OFF;
- prm_set_mod_reg_bits(voltctrl,
-OMAP3430_GR_MOD,
-OMAP3_PRM_VOLTCTRL_OFFSET);
+ if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
- } else if (core_next_state == PWRDM_POWER_RET) {
- prm_set_mod_reg_bits(OMAP3430_AUTO_RET,
- OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTCTRL_OFFSET);
}
}
@@ -510,18 +502,6 @@ void omap_sram_idle(void)
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
- if (core_next_state == PWRDM_POWER_OFF) {
- u32 voltctrl = OMAP3430_AUTO_OFF;
-
- if (voltage_off_while_idle)
- voltctrl |= OMAP3430_SEL_OFF;
- prm_clear_mod_reg_bits(voltctrl,
- OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTCTRL_OFFSET);
- } else if (core_next_state == PWRDM_POWER_RET)
- prm_clear_mod_reg_bits(OMAP3430_AUTO_RET,
- OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTCTRL_OFFSET);
}
omap3_intc_resume_idle();
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index efa16d4..1be1ccf 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -943,6 +943,46 @@ void __init omap_voltage_init_vc(struct prm_setup_vc
*setup_vc)
vc_config.off.clksetup = setup_vc->off.clksetup;
}
+void omap_voltage_vc_update(int core_next_state)
+{
+ u32 voltctrl = 0;
+
+ /* update voltsetup time */
+ if (core_next_state == PWRDM_POWER_OFF) {
+ voltctrl = OMAP3430_AUTO_OFF;
+ prm_write_mod_reg(vc_config.off.clksetup, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ prm_write_mod_reg((vc_config.off.voltsetup1_vdd2 <<
+ OMAP3430_SETUP_TIME2_SHIFT) |
+ (vc_config.off.voltsetup1_vdd1 <<
+ OMAP3430_SETUP_TIME1_SHIFT),
+ OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
+
+ if (voltage_off_while_idle) {
+ voltctrl |= OMAP3430_SEL_OFF;
+ prm_write_mod_reg(vc_config.off.voltsetup2,
+ OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ }
+
+ } else if (core_next_state == PWRDM_POWER_RET) {
+ voltctrl = OMAP3430_AUTO_RET;
+ prm_write_mod_reg(vc_config.ret.clksetup, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ prm_write_mod_reg((vc_config.ret.voltsetup1_vdd2 <<
+ OMAP3430_SETUP_TIME2_SHIFT) |
+ (vc_config.ret.voltsetup1_vdd1 <<
+ OMAP3430_SETUP_TIME1_SHIFT),
+
[PATCH v7 5/8] omap3: pm: changing vdd0_/vdd1_ to vdd1_/vdd2_ in VC param structure
Renaming vdd0_/vdd1_ to vdd1_/vdd2_ in VC param structure,
since there is no VDD0. It's VDD1 voltage domain with processor voltage &
VDD2 voltage domain with CORE voltage.
VDD1 voltage specific values are stored in PRM_VC_CMD_VAL_0 register &
VDD2 voltage specific values are stored in PRM_VC_CMD_VAL_1 register.
PRM_VC_CMD_VAL_n (n = 0/1 for VDD1/VDD2):
ON_voltage[31:24], ONLP_voltage[23:16], RET_voltage[15:8], OFF_voltage[14:0]
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
arch/arm/mach-omap2/voltage.c | 34 +-
arch/arm/mach-omap2/voltage.h | 10 +-
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 1be1ccf..a496d19 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -147,14 +147,14 @@ struct __initdata prm_setup_vc omap3430_vc_config = {
.voltoffset = 0x32,
},
/* VC COMMAND VALUES for VDD1/VDD2 */
- .vdd0_on = 0x30,/* 1.2v */
- .vdd0_onlp = 0x20, /* 1.0v */
- .vdd0_ret = 0x1e, /* 0.975v */
- .vdd0_off = 0x00, /* 0.6v */
- .vdd1_on = 0x2c,/* 1.15v */
+ .vdd1_on = 0x30,/* 1.2v */
.vdd1_onlp = 0x20, /* 1.0v */
- .vdd1_ret = 0x1e, /* .975v */
+ .vdd1_ret = 0x1e, /* 0.975v */
.vdd1_off = 0x00, /* 0.6v */
+ .vdd2_on = 0x2c,/* 1.15v */
+ .vdd2_onlp = 0x20, /* 1.0v */
+ .vdd2_ret = 0x1e, /* 0.975v */
+ .vdd2_off = 0x00, /* 0.6v */
};
/*
@@ -178,14 +178,14 @@ struct __initdata prm_setup_vc omap3630_vc_config = {
.voltoffset = 0x32,
},
/* VC COMMAND VALUES for VDD1/VDD2 */
- .vdd0_on = 0x28,/* 1.1v */
- .vdd0_onlp = 0x20, /* 1.0v */
- .vdd0_ret = 0x13, /* 0.83v */
- .vdd0_off = 0x00, /* 0.6v */
- .vdd1_on = 0x2B,/* 1.1375v */
+ .vdd1_on = 0x28,/* 1.1v */
.vdd1_onlp = 0x20, /* 1.0v */
.vdd1_ret = 0x13, /* 0.83v */
.vdd1_off = 0x00, /* 0.6v */
+ .vdd2_on = 0x2B,/* 1.1375v */
+ .vdd2_onlp = 0x20, /* 1.0v */
+ .vdd2_ret = 0x13, /* 0.83v */
+ .vdd2_off = 0x00, /* 0.6v */
};
static struct prm_setup_vc vc_config;
@@ -279,17 +279,17 @@ static void __init init_voltagecontroller(void)
VC_VOLRA0_SHIFT));
voltage_write_reg(vc_reg.cmdval0_reg,
- (vc_config.vdd0_on << VC_CMD_ON_SHIFT) |
- (vc_config.vdd0_onlp << VC_CMD_ONLP_SHIFT) |
- (vc_config.vdd0_ret << VC_CMD_RET_SHIFT) |
- (vc_config.vdd0_off << VC_CMD_OFF_SHIFT));
-
- voltage_write_reg(vc_reg.cmdval1_reg,
(vc_config.vdd1_on << VC_CMD_ON_SHIFT) |
(vc_config.vdd1_onlp << VC_CMD_ONLP_SHIFT) |
(vc_config.vdd1_ret << VC_CMD_RET_SHIFT) |
(vc_config.vdd1_off << VC_CMD_OFF_SHIFT));
+ voltage_write_reg(vc_reg.cmdval1_reg,
+ (vc_config.vdd2_on << VC_CMD_ON_SHIFT) |
+ (vc_config.vdd2_onlp << VC_CMD_ONLP_SHIFT) |
+ (vc_config.vdd2_ret << VC_CMD_RET_SHIFT) |
+ (vc_config.vdd2_off << VC_CMD_OFF_SHIFT));
+
voltage_write_reg(vc_ch_conf_reg, VC_CMD1 | VC_RAV1);
voltage_write_reg(vc_i2c_cfg_reg, VC_MCODE_SHIFT | VC_HSEN);
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 9ca20e5..bfd5048 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -28,15 +28,15 @@ struct prm_setup_vc {
/* CLK & VOLT SETUPTIME for OFF */
struct setuptime_vc off;
/* PRM_VC_CMD_VAL_0 specific bits */
- u16 vdd0_on;
- u16 vdd0_onlp;
- u16 vdd0_ret;
- u16 vdd0_off;
- /* PRM_VC_CMD_VAL_1 specific bits */
u16 vdd1_on;
u16 vdd1_onlp;
u16 vdd1_ret;
u16 vdd1_off;
+ /* PRM_VC_CMD_VAL_1 specific bits */
+ u16 vdd2_on;
+ u16 vdd2_onlp;
+ u16 vdd2_ret;
+ u16 vdd2_off;
};
#define VOLTSCALE_VPFORCEUPDATE1
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/8] omap3: pm: Using separate clk/volt setup_time for RET and OFF states
This patch has the changes to use separate clk/volt setup_time
for RET and OFF state. Because the clocksetup voltsetup time1
used for RET & OFF is different.
Create separate copies of VC parameters for each Si in voltage.c.
Since the voltage vales for each state is different in different OMAP Si.
Updates the VC setuptime struct during init based on the OMAP Si.
Removes the VC setuptime struct from board files.
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
arch/arm/mach-omap2/board-3430sdp.c | 19 ---
arch/arm/mach-omap2/pm.h| 18 ---
arch/arm/mach-omap2/voltage.c | 93 +-
arch/arm/mach-omap2/voltage.h | 25 +
4 files changed, 93 insertions(+), 62 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 75c66dd..c7f0fa8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -47,7 +47,6 @@
#include "sdram-qimonda-hyb18m512160af-6.h"
#include "hsmmc.h"
#include "pm.h"
-#include "voltage.h"
#include "omap3-opp.h"
#include "smartreflex-class3.h"
@@ -77,23 +76,6 @@ static struct cpuidle_params omap3_cpuidle_params_table[] = {
{1, 1, 3, 30},
};
-/* FIXME: These are not the optimal setup values to be used on 3430sdp*/
-static struct prm_setup_vc omap3_setuptime_table = {
- .clksetup = 0xff,
- .voltsetup_time1 = 0xfff,
- .voltsetup_time2 = 0xfff,
- .voltoffset = 0xff,
- .voltsetup2 = 0xff,
- .vdd0_on = 0x30,
- .vdd0_onlp = 0x20,
- .vdd0_ret = 0x1e,
- .vdd0_off = 0x00,
- .vdd1_on = 0x2c,
- .vdd1_onlp = 0x20,
- .vdd1_ret = 0x1e,
- .vdd1_off = 0x00,
-};
-
static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -347,7 +329,6 @@ static void __init omap_3430sdp_init_irq(void)
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap3_pm_init_opp_table();
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
- omap_voltage_init_vc(&omap3_setuptime_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
omap_gpio_init();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b608490..bad9058 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -40,24 +40,6 @@ inline void omap3_pm_init_cpuidle(struct cpuidle_params
*cpuidle_board_params)
}
#endif
-struct prm_setup_vc {
- u16 clksetup;
- u16 voltsetup_time1;
- u16 voltsetup_time2;
- u16 voltoffset;
- u16 voltsetup2;
-/* PRM_VC_CMD_VAL_0 specific bits */
- u16 vdd0_on;
- u16 vdd0_onlp;
- u16 vdd0_ret;
- u16 vdd0_off;
-/* PRM_VC_CMD_VAL_1 specific bits */
- u16 vdd1_on;
- u16 vdd1_onlp;
- u16 vdd1_ret;
- u16 vdd1_off;
-};
-
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index c5e9c42..efa16d4 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -127,14 +127,26 @@ struct vc_reg_info {
} vc_reg;
/*
- * Default voltage controller settings for OMAP3
+ * Default voltage controller settings for OMAP3430
*/
-static struct prm_setup_vc vc_config = {
- .clksetup = 0xff,
- .voltsetup_time1 = 0xfff,
- .voltsetup_time2 = 0xfff,
- .voltoffset = 0xff,
- .voltsetup2 = 0xff,
+struct __initdata prm_setup_vc omap3430_vc_config = {
+ /* CLK & VOLT SETUPTIME for RET */
+ .ret = {
+ .clksetup = 0x1,
+ .voltsetup1_vdd1 = 0x005B,
+ .voltsetup1_vdd2 = 0x0055,
+ .voltsetup2 = 0x0,
+ .voltoffset = 0x0,
+ },
+ /* CLK & VOLT SETUPTIME for OFF */
+ .off = {
+ .clksetup = 0x14A,
+ .voltsetup1_vdd1 = 0x00B3,
+ .voltsetup1_vdd2 = 0x00A0,
+ .voltsetup2 = 0x118,
+ .voltoffset = 0x32,
+ },
+ /* VC COMMAND VALUES for VDD1/VDD2 */
.vdd0_on = 0x30,/* 1.2v */
.vdd0_onlp = 0x20, /* 1.0v */
.vdd0_ret = 0x1e, /* 0.975v */
@@ -146,6 +158,39 @@ static struct prm_setup_vc vc_config = {
};
/*
+ * Default voltage controller settings for OMAP3630
+ */
+struct __initdata prm_setup_vc omap3630_vc_config = {
+ /* CLK & VOLT SETUPTIME for RET */
+ .ret = {
+ .clksetup = 0x1,
+ .voltsetup1_vdd1 = 0x005B,
+ .voltsetup1_vdd2 = 0x0055,
+ .voltsetup2 = 0x0,
+ .voltoffset = 0x0,
+ },
+ /* CLK & VOLT SETUPTIME for OFF */
+ .off = {
+ .clksetup = 0x14A,
+ .voltsetup1_vdd1 = 0x00B3,
+ .voltset
[PATCH v7 2/8] omap3: pm: correct the warning print during script loading
Correcting the if condition check for printing the warning,
if wakeup script is not updated before updating the sleep script.
Since the flag 'order' is set to '1' while updating the wakeup script for P1P2,
the condition checking for printing the warning should be if(!order)
(ie: print the warning if wakeup script is not updated before updating the
sleep script)
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
drivers/mfd/twl4030-power.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9ab5a20..b4fc190 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -452,7 +452,7 @@ static int __init load_twl4030_script(struct twl4030_script
*tscript,
goto out;
}
if (tscript->flags & TWL4030_SLEEP_SCRIPT) {
- if (order)
+ if (!order)
pr_warning("TWL4030: Bad order of scripts (sleep "\
"script before wakeup) Leads to boot"\
"failure on some boards\n");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/8] omap3: pm: fix for twl4030 script load
This patch will fix the TRITON sleep/wakeup sequence.
Since the function to populate the sleep script is getting called always
irrespective of the flag "TWL4030_SLEEP_SCRIPT", other scripts data
is getting over written by the sleep script.
Signed-off-by: Lesly A M
Cc: Nishanth Menon
Cc: David Derrick
Cc: Samuel Ortiz
---
drivers/mfd/twl4030-power.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..9ab5a20 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -451,12 +451,13 @@ static int __init load_twl4030_script(struct
twl4030_script *tscript,
if (err)
goto out;
}
- if (tscript->flags & TWL4030_SLEEP_SCRIPT)
+ if (tscript->flags & TWL4030_SLEEP_SCRIPT) {
if (order)
pr_warning("TWL4030: Bad order of scripts (sleep "\
"script before wakeup) Leads to boot"\
"failure on some boards\n");
err = twl4030_config_sleep_sequence(address);
+ }
out:
return err;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/8] omap3: pm: Update TRITON power scripts and making it generic
T2 script changes rebased on top of Thara's SmartReflex patches. This series of patch implements a updated TRITON power scripts. Also moving the sleep, wakeup & warm_reset sequence to a generic script file, which can be used by different OMAP3 board with the power companion chip TWL4030. This patch series is based off Kevin's tree remotes/origin/pm-wip-sr branch, which have the SmartReflex changes done by Thara Gopinath. Changes in v7: split the first patch in v6 i) fix for twl4030 script load ii) correct the warning print during script loading Updated the change logs This changes are tested on OMAP3430, OMAP3630 SDP & ZOOM3 board with: enable_off_mode voltage_off_while_idle sleep_while_idle (VDD1/VDD2 voltage scaling to 0v) enabled in cpuidle and suspned path. Lesly A M (8): omap3: pm: fix for twl4030 script load omap3: pm: correct the warning print during script loading omap3: pm: Using separate clk/volt setup_time for RET and OFF states omap3: pm: re-programing the setup time based on CORE_DOMAIN target state omap3: pm: changing vdd0_/vdd1_ to vdd1_/vdd2_ in VC param structure omap3: pm: Generic TRITON power scripts for OMAP3 based boards omap3: pm: Use generic TRITON power scripts for 3430SDP board omap3: pm: Use generic TRITON power scripts for ZOOM[2,3], 3630SDP board arch/arm/mach-omap2/Makefile | 12 +- arch/arm/mach-omap2/board-3430sdp.c | 111 +--- arch/arm/mach-omap2/board-zoom-peripherals.c |6 + arch/arm/mach-omap2/pm.h | 18 --- arch/arm/mach-omap2/pm34xx.c | 26 +--- arch/arm/mach-omap2/twl4030.c| 185 ++ arch/arm/mach-omap2/twl4030.h| 23 +++ arch/arm/mach-omap2/voltage.c| 156 +- arch/arm/mach-omap2/voltage.h| 26 drivers/mfd/twl4030-power.c |5 +- include/linux/i2c/twl.h |4 + 11 files changed, 380 insertions(+), 192 deletions(-) create mode 100644 arch/arm/mach-omap2/twl4030.c create mode 100644 arch/arm/mach-omap2/twl4030.h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP:DSS2:OMAPFB: Fix probe error path
Hi, On Wed, 2010-06-30 at 16:15 +0200, ext Afzal Mohammed wrote: > If enabling fb0 fails in omapfb_create_framebuffers(), remove > sysfs file before returning to probe. This is required to complete > the cleanup in the above mentioned error case. omapfb frees the resources in omapfb_free_resources(). I believe removing sysfs should also be put into omapfb_free_resources() to be consistent, and not as an explicit call like in this patch. However, I'm not sure if some sysfs-allocated flag is needed for this to work in all cases. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
* Nicolas Pitre [100630 17:36]: > On Wed, 30 Jun 2010, Tony Lindgren wrote: > > > * Tony Lindgren [100630 14:02]: > > > * Nicolas Pitre [100629 22:14]: > > > > > > Updated patch below. > > > > And a bug crept in.. > > > > > + .macro set_tls_v6, tp, tmp1, tmp2 > > > + ldr \tmp1, =elf_hwcap > > > + ldr \tmp1, [\tmp1, #0] > > > + mov \tmp2, #0x0fff > > > + tst \tmp2, #HWCAP_TLS @ hardware TLS available? > > > + mcrne p15, 0, \tp, c13, c0, 3 @ yes, set TLS register > > > + streq \tp, [\tmp2, #-15] @ set TLS value at 0x0ff0 > > > + .endm > > > > The tst \tmp2, #HWCAP_TLS should of course use \tmp1. > > > > Also fixed a warning about adding parentheses around comparison > > if (id & 0x410f) != 0x4107). > > Here you probably want (id & 0xff0f) and not (id & 0x410f). Thanks, fixed. > > Again, updated patch below. > > I like it. However, in proc-v6.S, you don't need to add a reference to > feat_v6_fixup() to the __pj4_v6_proc_info block. Simply adding > HWCAP_TLS in that case should be fine as PJ4 always has the TLS reg. Fixed that too. > With the above fixes, you can add > > Reviewed-by: Nicolas Pitre Thanks, updated patch below. Tony From: Tony Lindgren Date: Tue, 29 Jun 2010 13:34:53 +0300 Subject: [PATCH] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6 The TLS register is only available on ARM1136 r1p0 and later. Set HWCAP_TLS flags if hardware TLS is available and test for it if CONFIG_CPU_32v6K is not set for V6. Note that we set the TLS instruction in __kuser_get_tls dynamically as suggested by Jamie Lokier . Also the __switch_to code is optimized out in most cases as suggested by Nicolas Pitre . Signed-off-by: Tony Lindgren Reviewed-by: Nicolas Pitre diff --git a/arch/arm/include/asm/hwcap.h b/arch/arm/include/asm/hwcap.h index f7bd52b..c1062c3 100644 --- a/arch/arm/include/asm/hwcap.h +++ b/arch/arm/include/asm/hwcap.h @@ -19,6 +19,7 @@ #define HWCAP_NEON 4096 #define HWCAP_VFPv3 8192 #define HWCAP_VFPv3D16 16384 +#define HWCAP_TLS 32768 #if defined(__KERNEL__) && !defined(__ASSEMBLY__) /* diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h new file mode 100644 index 000..e565f33 --- /dev/null +++ b/arch/arm/include/asm/tls.h @@ -0,0 +1,46 @@ +#ifndef __ASMARM_TLS_H +#define __ASMARM_TLS_H + +#ifdef __ASSEMBLY__ + .macro set_tls_none, tp, tmp1, tmp2 + .endm + + .macro set_tls_v6k, tp, tmp1, tmp2 + mcr p15, 0, \tp, c13, c0, 3 @ set TLS register + .endm + + .macro set_tls_v6, tp, tmp1, tmp2 + ldr \tmp1, =elf_hwcap + ldr \tmp1, [\tmp1, #0] + mov \tmp2, #0x0fff + tst \tmp1, #HWCAP_TLS @ hardware TLS available? + mcrne p15, 0, \tp, c13, c0, 3 @ yes, set TLS register + streq \tp, [\tmp2, #-15] @ set TLS value at 0x0ff0 + .endm + + .macro set_tls_software, tp, tmp1, tmp2 + mov \tmp1, #0x0fff + str \tp, [\tmp1, #-15] @ set TLS value at 0x0ff0 + .endm +#endif + +#ifdef CONFIG_TLS_REG_EMUL +#define tls_emu 1 +#define has_tls 1 +#define set_tls set_tls_none +#elif __LINUX_ARM_ARCH__ >= 7 || \ + (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K)) +#define tls_emu 0 +#define has_tls 1 +#define set_tls set_tls_v6k +#elif __LINUX_ARM_ARCH__ == 6 +#define tls_emu 0 +#define has_tls (elf_hwcap & HWCAP_TLS) +#define set_tls set_tls_v6 +#else +#define tls_emu 0 +#define has_tls 0 +#define set_tls set_tls_software +#endif + +#endif /* __ASMARM_TLS_H */ diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 7ee48e7..a6cfb17 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -22,6 +22,7 @@ #include #include #include +#include #include "entry-header.S" @@ -739,12 +740,7 @@ ENTRY(__switch_to) #ifdef CONFIG_MMU ldr r6, [r2, #TI_CPU_DOMAIN] #endif -#if defined(CONFIG_HAS_TLS_REG) - mcr p15, 0, r3, c13, c0, 3 @ set TLS register -#elif !defined(CONFIG_TLS_REG_EMUL) - mov r4, #0x0fff - str r3, [r4, #-15] @ TLS val at 0x0ff0 -#endif + set_tls r3, r4, r5 #ifdef CONFIG_MMU mcr p15, 0, r6, c3, c0, 0 @ Set domain register #endif @@ -1009,17 +1005,12 @@ kuser_cmpxchg_fixup: */ __kuser_get_tls:@ 0x0fe0 - -#if !defined(CONFIG_HAS_TLS_REG) && !defined(CONFIG_TLS_REG_EMUL) - ldr r0, [pc, #(16 - 8)] @ TLS stored at 0x0ff0 -#else - mrc p15, 0, r0, c13, c0, 3 @ read TLS register -#endif + ldr r0, [pc, #(16 - 8)] @ read TLS, set in kuser_get_tls_init usr_ret lr - - .rep 5 - .word 0 @ pad up to __kuser_helper_version - .endr + mrc p15, 0, r0, c13, c0, 3 @ 0x0fe8 hardware TLS code + .rep 4 + .word 0 @ 0x0ff0 software TLS value, then + .endr@ pad up to __kuser_helper_version /* * Reference declaration: diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 122d999..73921f1 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -269,6 +269,21 @@ static void __init cacheid_init(void) extern struct
RE: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c
Hi,
This value is set from bootloader, and kernel side only change the mode.
Right it runs by luck.
Thank you,
Kyungmin Park
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: Thursday, July 01, 2010 4:06 PM
> To: ext Tony Lindgren
> Cc: linux-arm-ker...@lists.infradead.org; Kyungmin Park; linux-
> o...@vger.kernel.org
> Subject: Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-
> apollon.c
>
> On Wed, 2010-06-30 at 14:07 +0200, ext Tony Lindgren wrote:
> > Use the new mux function for that.
> >
> > Cc: Kyungmin Park
> > Cc: Tomi Valkeinen
> > Signed-off-by: Tony Lindgren
> > ---
> > arch/arm/mach-omap2/board-apollon.c |3 +++
> > drivers/video/omap/lcd_apollon.c|3 ---
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-
> omap2/board-apollon.c
> > index b86a879..bc67026 100644
> > --- a/arch/arm/mach-omap2/board-apollon.c
> > +++ b/arch/arm/mach-omap2/board-apollon.c
> > @@ -332,6 +332,9 @@ static void __init omap_apollon_init(void)
> > /* REVISIT: where's the correct place */
> > omap_cfg_reg(W19_24XX_SYS_NIRQ);
> >
> > + /* LCD PWR_EN */
> > + omap_mux_init_signal("mcbsp2_dr.gpio_11", OMAP_PULL_ENA |
> OMAP_PULL_UP);
>
> LCD_PWR_EN sounds like output pin. However, I don't see lcd_apollon.c
> nor board-apollon.c set the gpio.
>
> I don't know what omap_cfg_reg(M21_242X_GPIO11) does, but if it does the
> same thing as the line above, then does the apollon LCD work by luck?
> OMAP pulling the line up, and by chance the pull is stronger than the
> LCDs (possible) pull down, and thus the LCD is powered up...
>
> Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1v2/3] mm: iommu: An API to unify IOMMU, CPU and device memory management
This patch contains the documentation for the API, termed the Virtual Contiguous Memory Manager. Its use would allow all of the IOMMU to VM, VM to device and device to IOMMU interoperation code to be refactored into platform independent code. Comments, suggestions and criticisms are welcome and wanted. Signed-off-by: Zach Pfeffer --- Documentation/vcm.txt | 587 + 1 files changed, 587 insertions(+), 0 deletions(-) create mode 100644 Documentation/vcm.txt diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt new file mode 100644 index 000..b9029db --- /dev/null +++ b/Documentation/vcm.txt @@ -0,0 +1,587 @@ +What is this document about? + + +This document covers how to use the Virtual Contiguous Memory Manager +(VCMM), how the first implementation works with a specific low-level +Input/Output Memory Management Unit (IOMMU) and the way the VCMM is used +from user-space. It also contains a section that describes why something +like the VCMM is needed in the kernel. + +If anything in this document is wrong, please send patches to the +maintainer of this file, listed at the bottom of the document. + + +The Virtual Contiguous Memory Manager += + +The VCMM was built to solve the system-wide memory mapping issues that +occur when many bus-masters have IOMMUs. + +An IOMMU maps device addresses to physical addresses. It also insulates +the system from spurious or malicious device bus transactions and allows +fine-grained mapping attribute control. The Linux kernel core does not +contain a generic API to handle IOMMU mapped memory; device driver writers +must implement device specific code to interoperate with the Linux kernel +core. As the number of IOMMUs increases, coordinating the many address +spaces mapped by all discrete IOMMUs becomes difficult without in-kernel +support. + +The VCMM API enables device independent IOMMU control, virtual memory +manager (VMM) interoperation and non-IOMMU enabled device interoperation +by treating devices with or without IOMMUs and all CPUs with or without +MMUs, their mapping contexts and their mappings using common +abstractions. Physical hardware is given a generic device type and mapping +contexts are abstracted into Virtual Contiguous Memory (VCM) +regions. Users "reserve" memory from VCMs and "back" their reservations +with physical memory. + +Why the VCMM is Needed +-- + +Driver writers who control devices with IOMMUs must contend with device +control and memory management. Driver writers have a large device driver +API that they can leverage to control their devices, but they are lacking +a unified API to help them program mappings into IOMMUs and share those +mappings with other devices and CPUs in the system. + +Sharing is complicated by Linux's CPU-centric VMM. The CPU-centric model +generally makes sense because average hardware only contains a MMU for the +CPU and possibly a graphics MMU. If every device in the system has one or +more MMUs the CPU-centric memory management (MM) programming model breaks +down. + +Abstracting IOMMU device programming into a common API has already begun +in the Linux kernel. It was built to abstract the difference between AMD +and Intel IOMMUs to support x86 virtualization on both platforms. The +interface is listed in include/linux/iommu.h. It contains +interfaces for mapping and unmapping as well as domain management. This +interface has not gained widespread use outside the x86; PA-RISC, Alpha +and SPARC architectures and ARM and PowerPC platforms all use their own +mapping modules to control their IOMMUs. The VCMM contains an IOMMU +programming layer, but since its abstraction supports map management +independent of device control, the layer is not used directly. This +higher-level view enables a new kernel service, not just an IOMMU +interoperation layer. + +The General Idea: Map Management using Graphs +- + +Looking at mapping from a system-wide perspective reveals a general graph +problem. The VCMM's API is built to manage the general mapping graph. Each +node that talks to memory, either through an MMU or directly (physically +mapped) can be thought of as the device-end of a mapping edge. The other +edge is the physical memory (or intermediate virtual space) that is +mapped. + +In the direct-mapped case the device is assigned a one-to-one MMU. This +scheme allows direct mapped devices to participate in general graph +management. + +The CPU nodes can also be brought under the same mapping abstraction with +the use of a light overlay on the existing VMM. This light overlay allows +VMM-managed mappings to interoperate with the common API. The light +overlay enables this without substantial modifications to the existing +VMM. + +In addition to CPU nodes that are running Linux (and the VMM), remote CPU +nodes that may be running other operating
Re: [PATCH 20/33] Removing dead MACH_OMAP2_H4_USB1
On Wed, Jun 30, 2010 at 06:00:23PM +0200, ext Christoph Egger wrote: MACH_OMAP2_H4_USB1 doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger Does this apply on top of Tony's recent patches ?? -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management
Thank you for the corrections. I'm correcting them now. Some responses: Randy Dunlap wrote: >> +struct vcm *vcm_create(size_t start_addr, size_t len); > > Seems odd to use size_t for start_addr. I used size_t because I wanted to allow the start_addr the same range as len. Is there a better type to use? I see 'unsigned long' used throughout the mm code. Perhaps that's better for both the start_addr and len. >> +A Reservation is created and destroyed with: >> + >> +struct res *vcm_reserve(struct vcm *vcm, size_t len, uint32_t attr); > > s/uint32_t/u32/ ? Sure. >> +Associate and activate all three to their respective devices: >> + >> +avcm_iommu = vcm_assoc(vcm_iommu, dev_iommu, attr0); >> +avcm_onetoone = vcm_assoc(vcm_onetoone, dev_onetoone, attr1); >> +avcm_vmm = vcm_assoc(vcm_vmm, dev_cpu, attr2); > > error handling on vcm_assoc() failures? I'll add the deassociate call to the example. >> +res_iommu = vcm_reserve(vcm_iommu, SZ_2MB + SZ_4K, attr); >> +res_onetoone = vcm_reserve(vcm_onetoone, SZ_2MB + SZ_4K, attr); >> +res_vmm = vcm_reserve(vcm_vmm, SZ_2MB + SZ_4K, attr); > > error handling? I'll add it here too. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
