Re: [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
On Friday 16 September 2011 10:53 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
When MPUSS hits off-mode e, L2 cache is lost. This patch adds L2X0
^^^
extra 'e' ?
necessary maintenance operations and context restoration in the
low power code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
[...]
@@ -135,6 +138,33 @@ static void scu_pwrst_prepare(unsigned int cpu_id,
unsigned int cpu_state)
__raw_writel(scu_pwr_st, pm_info-scu_sar_addr);
}
+/*
+ * Store the CPU cluster state for L2X0 low power operations.
+ */
+static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
+{
+struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu_id);
+
+__raw_writel(save_state, pm_info-l2x0_sar_addr);
+}
+
+/*
+ * Save the L2X0 AUXCTRL and POR value to SAR memory. Its used to
+ * in every restore MPUSS OFF path.
+ */
+static void save_l2x0_context(void)
+{
+#ifdef CONFIG_CACHE_L2X0
+u32 val;
+void __iomem *l2x0_base = omap4_get_l2cache_base();
+
+val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
+__raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
+val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
+__raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+#endif
nit: (c.f. '#ifdefs are ugly' in Documentatin/SubmittingPatches)
This should probably be more like
#ifdef CONFIG_CACHE_L2X0
static void save_l2x0_context(void)
{
/* real function */
}
#else
static void save_l2x0_context(void) {}
#endif
Ok. Will fix this.
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 23/25] OMAP4: PM: Add CPUidle support
On Friday 16 September 2011 11:15 PM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: Add OMAP4 CPUIDLE support. CPU1 is left with defualt idle and the low power state for it is managed via cpu-hotplug. This patch adds MPUSS low power states in cpuidle. C1 - CPU0 ON + CPU1 ON + MPU ON C2 - CPU0 OFF + CPU1 OFF + MPU CSWR C3 - CPU0 OFF + CPU1 OFF + MPU OSWR OMAP4460 onwards, MPUSS power domain doesn't support OFF state any more anymore just like CORE power domain. The deepest state supported is OSWr. Ofcourse when MPUSS and CORE PD transitions to OSWR along with device off mode, even the memory contemts are lost which is as good as the PD off state. On OMAP4 because of hardware constraints, no low power states are targeted when both CPUs are online and in SMP mode. The low power states are attempted only when secondary CPU gets offline to OFF through hotplug infrastructure. Thanks to Nicole Chalhoub n-chalh...@ti.com for doing exhaustive C-state latency profiling. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com A handful of minor comments below... Will take care of them. 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 24/25] OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.
On Friday 16 September 2011 11:21 PM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: CPU local timer(TWD) stops when the CPU is transitioning into deeper C-States. Since these timers are not wakeup capable, we need the wakeup capable global timer to program the wakeup time depending on the next timer expiry. It can be handled by registering a global wakeup capable timer along with local timers marked with (mis)feature flag CLOCK_EVT_FEAT_C3STOP. nit: this comment makes is sound like this patch adds the registration of this timer, when all this patch does is add the notification. Changelog should be updated to make it clear that the global timer exists already, and is already marked with the C3STOP flag. Will add couple of lines in the change log to make it clear. Then notify the clock events layer from idle code using CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT). Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Other than that Acked-by: Kevin Hilman khil...@ti.com Thanks. 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 v2 1/8] OMAP: hwmod: Fix the addr spaces, irq, dma count APIs.
On Friday 16 September 2011 09:10 PM, Cousson, Benoit wrote: Hi Sricharan, On 9/9/2011 6:02 PM, R, Sricharan wrote: The address spaces, irqs and dma reqs count API returns the number of corresponding entries in a hwmod including a additional null value or a -1 terminator in the structure introduced recently. More information here: 212738a4 (omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays) 78183f3f (omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays) bc614958 (omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays) The devices which have multiple hwmods and use device_build_ss are broken with this, as their resources are populated with a extra null value, subsequently the probe fails. So fix the API not to include the array terminator in the count. Signed-off-by: sricharanr.sricha...@ti.com Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Benoit Coussonb-cous...@ti.com Cc: Paul Walmsleyp...@pwsan.com Cc: Kevin Hilmankhil...@ti.com It would have been nice to give me the credit for the bug report on the other functions, but otherwise: Sure. Will add reported-by of yours. Acked-by: Benoit Cousson b-cous...@ti.com Thanks And I still prefer the return i - 1 :-) Let's do i-1 as you prefer. Maintainer always have final say !! 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] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
[...]
Well here's what I came up with to deal with the different timer
registers. We can't use the context registers as those are for
the value naturally..
But we can map the interrupt registers separately and then have
the rest start from func_base that is different based on the timer
version. Rebasing the rest of the dmtimer hwmod patches on this
should be fairly easy, mostly just need to pass timer instead of
timer-io_base and use __raw_read/write for the interrupt registers.
I went through the patch. It definitely looks much more simplified now.
I will rebase on top of this change.
Also, I ended up checking the timer revision with if (!(tidr 16))
as it seems that those bits are zero for v1 timers? If that works,
then we don't need patch 02/12 for the revision number.
Right.
--
Tarun
Afzal, care to check if that works for AM335X/TI816X/TI814X?
It tried it briefly with omap4 gptimer3 as the clockevent and
CONFIG_LOCAL_TIMER disabled.
The patch is against the current cleanup branch in linux-omap
tree.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 16 Sep 2011 15:44:20 -0700
Subject: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip
The registers are slightly different between v1 and v2 ip that
is available in omap4 and later for some timers.
Add support for v2 ip by mapping the interrupt related registers
separately and adding func_base for the functional registers.
Also disable dmtimer driver features on omap4 for now as
those need the hwmod conversion series to deal with enabling
the timers properly in omap_dm_timer_init.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index cf1de7d..21d34fb 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -78,7 +78,7 @@ static irqreturn_t omap2_gp_timer_interrupt(int irq, void
*dev_id)
{
struct clock_event_device *evt = clockevent_gpt;
- __omap_dm_timer_write_status(clkev.io_base, OMAP_TIMER_INT_OVERFLOW);
+ __omap_dm_timer_write_status(clkev, OMAP_TIMER_INT_OVERFLOW);
evt-event_handler(evt);
return IRQ_HANDLED;
@@ -93,7 +93,7 @@ static struct irqaction omap2_gp_timer_irq = {
static int omap2_gp_timer_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
- __omap_dm_timer_load_start(clkev.io_base, OMAP_TIMER_CTRL_ST,
+ __omap_dm_timer_load_start(clkev, OMAP_TIMER_CTRL_ST,
0x - cycles, 1);
return 0;
@@ -104,16 +104,16 @@ static void omap2_gp_timer_set_mode(enum
clock_event_mode mode,
{
u32 period;
- __omap_dm_timer_stop(clkev.io_base, 1, clkev.rate);
+ __omap_dm_timer_stop(clkev, 1, clkev.rate);
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
period = clkev.rate / HZ;
period -= 1;
/* Looks like we need to first set the load value separately */
- __omap_dm_timer_write(clkev.io_base, OMAP_TIMER_LOAD_REG,
+ __omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG,
0x - period, 1);
- __omap_dm_timer_load_start(clkev.io_base,
+ __omap_dm_timer_load_start(clkev,
OMAP_TIMER_CTRL_AR |
OMAP_TIMER_CTRL_ST,
0x - period, 1);
break;
@@ -172,6 +172,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
}
omap_hwmod_enable(oh);
+ __omap_dm_timer_init_regs(timer);
sys_timer_reserved |= (1 (gptimer_id - 1));
@@ -189,7 +190,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
clk_put(src);
}
}
- __omap_dm_timer_reset(timer-io_base, 1, 1);
+ __omap_dm_timer_reset(timer, 1, 1);
timer-posted = 1;
timer-rate = clk_get_rate(timer-fclk);
@@ -210,7 +211,7 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
omap2_gp_timer_irq.dev_id = (void *)clkev;
setup_irq(clkev.irq, omap2_gp_timer_irq);
- __omap_dm_timer_int_enable(clkev.io_base, OMAP_TIMER_INT_OVERFLOW);
+ __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
clockevent_gpt.mult = div_sc(clkev.rate, NSEC_PER_SEC,
clockevent_gpt.shift);
@@ -251,7 +252,7 @@ static struct omap_dm_timer clksrc;
static DEFINE_CLOCK_DATA(cd);
static cycle_t clocksource_read_cycles(struct clocksource *cs)
{
- return (cycle_t)__omap_dm_timer_read_counter(clksrc.io_base, 1);
+ return (cycle_t)__omap_dm_timer_read_counter(clksrc, 1);
}
static struct clocksource clocksource_gpt = {
@@ -266,7 +267,7 @@ static void notrace
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On 09/05/2011 07:19 AM, Arnd Bergmann wrote: I think it would simply be more consistent to have it enabled all the time. Well, even better would be to move the bulk of the misc drivers to a proper location sorted by their subsystems. A lot of them should never have been merged in their current state IMHO. If it's clear where they belong, then sure, they should be somewhere other than drivers/misc/, but I don't see that it's clear for several of them. I think I should finally do what has been talked about a few times and formally become the maintainer of drivers/char and drivers/misc ;-) The problem is that I'm not actually a good maintainer, but maybe it's better to just have someone instead of falling back to Andrew or some random subsystem maintainer to send any patches for drivers/misc. We have fallbacks to Andrew and/or GregKH currently, but GregKH is not consistent or timely with applying drivers/misc/ patches. It deserves better. [added him to Cc: list] So yes, I think that drivers/misc/ (and probably drivers/char/) deserves a maintainer, but you are not making a good case for you being that person. -- ~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: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Sun, Sep 18, 2011 at 08:11:45AM -0700, Randy Dunlap wrote: On 09/05/2011 07:19 AM, Arnd Bergmann wrote: I think it would simply be more consistent to have it enabled all the time. Well, even better would be to move the bulk of the misc drivers to a proper location sorted by their subsystems. A lot of them should never have been merged in their current state IMHO. If it's clear where they belong, then sure, they should be somewhere other than drivers/misc/, but I don't see that it's clear for several of them. I think I should finally do what has been talked about a few times and formally become the maintainer of drivers/char and drivers/misc ;-) The problem is that I'm not actually a good maintainer, but maybe it's better to just have someone instead of falling back to Andrew or some random subsystem maintainer to send any patches for drivers/misc. We have fallbacks to Andrew and/or GregKH currently, but GregKH is not consistent or timely with applying drivers/misc/ patches. It deserves better. [added him to Cc: list] I do try to handle patches sent to me for misc/ in time for the different merge windows as that directory contains drivers that have moved out of the staging/ directory. But yes, I'm not the overall drivers/misc/ maintainer, do we really need one? If so, I can easily start maintaining a development tree for it to keep it separate for the different driver authors to send me stuff and start tracking it more for real if Arnd doesn't want to do it. thanks, greg k-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 1/2] misc: remove CONFIG_MISC_DEVICES
On 09/18/2011 08:28 AM, Greg KH wrote: On Sun, Sep 18, 2011 at 08:11:45AM -0700, Randy Dunlap wrote: On 09/05/2011 07:19 AM, Arnd Bergmann wrote: I think it would simply be more consistent to have it enabled all the time. Well, even better would be to move the bulk of the misc drivers to a proper location sorted by their subsystems. A lot of them should never have been merged in their current state IMHO. If it's clear where they belong, then sure, they should be somewhere other than drivers/misc/, but I don't see that it's clear for several of them. I think I should finally do what has been talked about a few times and formally become the maintainer of drivers/char and drivers/misc ;-) The problem is that I'm not actually a good maintainer, but maybe it's better to just have someone instead of falling back to Andrew or some random subsystem maintainer to send any patches for drivers/misc. We have fallbacks to Andrew and/or GregKH currently, but GregKH is not consistent or timely with applying drivers/misc/ patches. It deserves better. [added him to Cc: list] I do try to handle patches sent to me for misc/ in time for the different merge windows as that directory contains drivers that have moved out of the staging/ directory. But yes, I'm not the overall drivers/misc/ maintainer, do we really need one? If so, I can easily start maintaining a development tree for it to keep it separate for the different driver authors to send me stuff and start tracking it more for real if Arnd doesn't want to do it. We need for the patches to be applied in a timely manner. Sometimes when there is no real maintainer, that does not happen. -- ~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: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Sat, Sep 17, 2011 at 01:24:29PM -0700, Joe Perches wrote:
On Sat, 2011-09-17 at 11:34 +0200, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
All of the logging messages could be
prefixed by the printk subsystem if you
add #define pr_fmt before any #include
Ah, i didn't really knew about that feature yet. I really have to keep
that in mind when grepping for error messages in the future.
But i don't think it would help much, as i now reducted the total number
of pr_err calls to 2 in this patch.
Thanks for the idea anyway.
- Martin Hostettler
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
[]
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
[]
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
[]
+ switch (mux_id) {
[]
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
pr_err(Invalid mux id #%d\n, mux_id);
[]
+static int __init camera_init(void)
[]
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+ nCAM_VD_SEL);
pr_err(Failed to get GPIO nCAM_VD_SEL(%d)\n,
nCAM_VD_SEL);
etc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Sun, Sep 18, 2011 at 12:08:20AM +0200, Laurent Pinchart wrote:
On Sunday 18 September 2011 00:00:16 Sylwester Nawrocki wrote:
On 09/17/2011 11:34 AM, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
...
+
+static int __init camera_init(void)
+{
+ int ret = -EINVAL;
+
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+nCAM_VD_SEL);
+ goto err;
+ }
+ if (gpio_direction_output(nCAM_VD_SEL, 1) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
direction\n, + nCAM_VD_SEL);
+ goto err_vdsel;
+ }
How about replacing gpio_request + gpio_direction_output with:
gpio_request_one(nCAM_VD_SEL, GPIOF_OUT_INIT_HIGH, nCAM_VD_SEL);
I'd even propose gpio_request_array().
Nice interface. Apart from a bit less detailed error reporting it nicely
simplifies the code. I'll make a new patch using that soon.
- Martin Hostettler
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi Martin,
On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 183
+++ 2 files changed, 184 insertions(+), 0
deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..8ae3d25 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+=
board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
+board-omap3evm-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
index 000..be987d9
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C
Bus 2 + *
+ * 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 linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL 157
+
+#define MT9M032_I2C_BUS_NUM 2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM
board + * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 1350,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+ .invert_pixclock = 1,
+};
+
+static struct i2c_board_info camera_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO(MT9M032_NAME, MT9M032_I2C_ADDR),
+ .platform_data = mt9m032_platform_data,
+ },
+};
+
+static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
+ {
+ .board_info = camera_i2c_devices[0],
+ .i2c_adapter_id = MT9M032_I2C_BUS_NUM,
+ },
+ {},
+};
+
+static struct isp_v4l2_subdevs_group camera_subdevs[] = {
+ {
+ .subdevs = camera_i2c_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 1,
+ .clk_pol = 0,
+ .bridge =
RE: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
Tony Lindgren wrote on Saturday, September 17, 2011 7:06 AM: device driver) * DebBarma, Tarun Kanti tarun.ka...@ti.com [110916 01:56]: [...] Afzal, care to check if that works for AM335X/TI816X/TI814X? It tried it briefly with omap4 gptimer3 as the clockevent and CONFIG_LOCAL_TIMER disabled. The patch is against the current cleanup branch in linux-omap tree. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Fri, 16 Sep 2011 15:44:20 -0700 Subject: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip [...] Tony, Kernel boots fine on TI816X (should also boot on TI814X) with your patch and patches (including OSC clock fix) from series http://www.spinics.net/lists/linux-omap/msg57011.html Thanks. Hemant
Re: [PATCH] ti816x: add support for nand on ti8168 evm
On Thu, 2011-09-08 at 18:33 +0530, Saxena, Parth wrote: Add partition table for NAND device on TI8168 EVM and initialise the NAND module. Signed-off-by: Saxena, Parth parth.sax...@ti.com Signed-off-by: Basheer, Mansoor Ahamed mansoor.aha...@ti.com --- This patch is tested on top of linux-omap/master and Hemant's patches submitted recently. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53457.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg54296.html arch/arm/mach-omap2/board-ti8168evm.c | 39 + 1 files changed, 39 insertions(+), 0 deletions(-) Please, send this patch to Tony, I think it should go in via the omap tree, not via the MTD tree. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
Hi Tony, On Sat, Sep 17, 2011 at 07:05:31, Tony Lindgren wrote: Afzal, care to check if that works for AM335X/TI816X/TI814X? With following patch over yours, AM335X (the only board with me) boots up fine. Regards Afzal From ff64a239e60f9b517860eb2fe9c4f88a188ca51d Mon Sep 17 00:00:00 2001 From: Afzal Mohammed af...@ti.com Date: Mon, 19 Sep 2011 10:06:59 +0530 Subject: [PATCH] ARM: OMAP: dmtimer register safe access Access dmtimer registers after setting it's parent clock. If default parent is not physically present, accessing register causes abort, so access registers after proper parent is set. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 1746c69..ababc4d 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -172,7 +172,6 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer, } omap_hwmod_enable(oh); - __omap_dm_timer_init_regs(timer); sys_timer_reserved |= (1 (gptimer_id - 1)); @@ -190,6 +189,7 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer, clk_put(src); } } + __omap_dm_timer_init_regs(timer); __omap_dm_timer_reset(timer, 1, 1); timer-posted = 1; -- 1.6.2.4
