[PATCH] OMAPDSS: DISPC: Add predecimation limit for TILER based rotations
In OMAP4 and OMAP5 when TILER 2D burst mode is used, a maximum of one line can
be skipped as per the respective TRMs. The MBlockStride OCP signal, which is
sum of ROWINC and image width in memory, is only 17 bits wide. In 2D mode TILER
supports 8192, 16384, 32768 and 65536 values of MBlockStride. In case when 2 or
more lines are skipped the ROWINC value exceeds 65536 resulting in OCP errors.
So, maximum vertical predecimation achievable is 2.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d512c38..61f8369 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2195,7 +2195,8 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
- int *x_predecim, int *y_predecim, u16 pos_x)
+ int *x_predecim, int *y_predecim, u16 pos_x,
+ enum omap_dss_rotation_type rotation_type)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
@@ -2210,7 +2211,8 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
return -EINVAL;
*x_predecim = max_decim_limit;
- *y_predecim = max_decim_limit;
+ *y_predecim = (rotation_type == OMAP_DSS_ROT_TILER
+ dss_has_feature(FEAT_BURST_2D)) ? 2 : max_decim_limit;
if (color_mode == OMAP_DSS_COLOR_CLUT1 ||
color_mode == OMAP_DSS_COLOR_CLUT2 ||
@@ -2306,7 +2308,8 @@ int dispc_ovl_setup(enum omap_plane plane, struct
omap_overlay_info *oi,
r = dispc_ovl_calc_scaling(plane, channel, mgr_timings, in_width,
in_height, out_width, out_height, oi-color_mode,
- five_taps, x_predecim, y_predecim, oi-pos_x);
+ five_taps, x_predecim, y_predecim, oi-pos_x,
+ oi-rotation_type);
if (r)
return r;
--
1.7.10
--
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/5] ARM: OMAP: HOST: TLL driver implementation
On Sat, Sep 22, 2012 at 3:37 AM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Paul, On Wed, Sep 19, 2012 at 08:39:40PM +, Paul Walmsley wrote: Hi Samuel, I've queued patch 1 of this series for 3.7, which should go upstream via the OMAP - arm-soc path. Also asked Keshava to re-send patch 5 to me once patches 2-4 have been merged. It's up to you how to handle patches 2-4. The series is a good step forward for us in terms of cleanup. But what is probably worthwhile at some point is for that USB TLL phy code (added in patch 2) to be moved into some place like drivers/usb/phy, since it's not MFD-related. That would be ideal, yes. I kept patches 2-4 as they're alreeady going in the right direction (I dropped patches 1 and 5). Thanks for the heads up. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ thanks paul and Samuel regards keshava regards keshava -- 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/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi, On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent ra...@rab.in wrote: 2012/9/6 Kishon Vijay Abraham I kis...@ti.com: All the PHY configuration other than VBUS, ID GND and OTG SRP are removed from twl6030. The phy configurations are taken care by the dedicated usb2 phy driver. So twl6030 is made as comparator driver for VBUS and ID detection. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com USB doesn't work on pandaboard on linux-next, and bisection shows this patch. Unfortunately, I can't provide a dmesg log because USB is the only way I currently have to get one out(!), but presumably it's because this omap-usb2 device is never registered? Looks like this breaks non-dt USB on pandaboard; is that intended? Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the old non-dt support). Some patches are queued only for 3.7. In case you want to use MUSB please use these patches on linux-next.. [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries (from Benoit) [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) Pls note all these patches are queued for 3.7 Thanks Kishon -- 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/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
2012/9/24 ABRAHAM, KISHON VIJAY kis...@ti.com: On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent ra...@rab.in wrote: USB doesn't work on pandaboard on linux-next, and bisection shows this patch. Unfortunately, I can't provide a dmesg log because USB is the only way I currently have to get one out(!), but presumably it's because this omap-usb2 device is never registered? Looks like this breaks non-dt USB on pandaboard; is that intended? Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the old non-dt support). Well, USB used to work fine on Pandaboard without DT before the introduction of omap-usb2, so one would expected it to continue working (until the board file is completely removed). Anyway, I've moved to DT now. Some patches are queued only for 3.7. In case you want to use MUSB please use these patches on linux-next.. [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries (from Benoit) [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) I got these by merging in Benoit's for_3.7/dts_part2 on top of next-20120921. Thanks. -- 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 v3] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it possible to add different set of additional devices to i2c1 bus on
OMAP4 boards.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Tony,
I have refreshed the patch on top of arm-soc/for-next branch. Would it be
possible to queue this patch via arm-soc so it will be in 3.7-rc1 already?
Originally this patch was sent for 3.6...
Regards,
Peter
arch/arm/mach-omap2/board-4430sdp.c| 12 +--
arch/arm/mach-omap2/board-omap4panda.c | 12 +--
arch/arm/mach-omap2/twl-common.c | 37 ++
arch/arm/mach-omap2/twl-common.h | 3 ++-
4 files changed, 33 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 6fe9079..7c1a662 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -545,6 +545,14 @@ static struct twl6040_platform_data twl6040_data = {
.audpwron_gpio = 127,
};
+static struct i2c_board_info __initdata sdp4430_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = OMAP44XX_IRQ_SYS_2N,
+ .platform_data = twl6040_data,
+ },
+};
+
static struct twl4030_platform_data sdp4430_twldata = {
/* Regulators */
.vusim = sdp4430_vusim,
@@ -578,8 +586,8 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, sdp4430_twldata,
- twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
+ omap4_pmic_init(twl6030, sdp4430_twldata, sdp4430_i2c_1_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_1_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 8ebb16c..eb7a9a8 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -264,6 +264,14 @@ static struct twl6040_platform_data twl6040_data = {
.audpwron_gpio = 127,
};
+static struct i2c_board_info __initdata panda_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = OMAP44XX_IRQ_SYS_2N,
+ .platform_data = twl6040_data,
+ },
+};
+
/* Panda board uses the common PMIC configuration */
static struct twl4030_platform_data omap4_panda_twldata;
@@ -291,8 +299,8 @@ static int __init omap4_panda_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, omap4_panda_twldata,
- twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
+ omap4_pmic_init(twl6030, omap4_panda_twldata, panda_i2c_1_boardinfo,
+ ARRAY_SIZE(panda_i2c_1_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
/*
* Bus 3 is attached to the DVI port where devices like the pico DLP
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 040f480..e279732 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -40,16 +40,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info
= {
.flags = I2C_CLIENT_WAKE,
};
-static struct i2c_board_info __initdata omap4_i2c1_board_info[] = {
- {
- .addr = 0x48,
- .flags = I2C_CLIENT_WAKE,
- },
- {
- I2C_BOARD_INFO(twl6040, 0x4b),
- },
-};
-
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static int twl_set_voltage(void *data, int target_uV)
{
@@ -79,30 +69,25 @@ void __init omap_pmic_init(int bus, u32 clkrate,
void __init omap4_pmic_init(const char *pmic_type,
struct twl4030_platform_data *pmic_data,
- struct twl6040_platform_data *twl6040_data, int twl6040_irq)
+ struct i2c_board_info *devices, int nr_devices)
{
/* PMIC part*/
omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
- strncpy(omap4_i2c1_board_info[0].type, pmic_type,
- sizeof(omap4_i2c1_board_info[0].type));
- omap4_i2c1_board_info[0].irq = 7 + OMAP44XX_IRQ_GIC_START;
- omap4_i2c1_board_info[0].platform_data = pmic_data;
-
- /* TWL6040 audio IC part */
- omap4_i2c1_board_info[1].irq = twl6040_irq;
-
Re: rcu self-detected stall messages on OMAP3, 4 boards
On Sun, Sep 23, 2012 at 3:29 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sat, Sep 22, 2012 at 01:10:43PM -0700, Paul E. McKenney wrote: On Sat, Sep 22, 2012 at 06:42:08PM +, Paul Walmsley wrote: On Fri, 21 Sep 2012, Paul E. McKenney wrote: [...] And here is a patch. I am still having trouble reproducing the problem, but figured that I should avoid serializing things. Thanx, Paul b/kernel/rcutree.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) rcu: Fix day-one dyntick-idle stall-warning bug Each grace period is supposed to have at least one callback waiting for that grace period to complete. However, if CONFIG_NO_HZ=n, an extra callback-free grace period is no big problem -- it will chew up a tiny bit of CPU time, but it will complete normally. In contrast, CONFIG_NO_HZ=y kernels have the potential for all the CPUs to go to sleep indefinitely, in turn indefinitely delaying completion of the callback-free grace period. Given that nothing is waiting on this grace period, this is also not a problem. Unless RCU CPU stall warnings are also enabled, as they are in recent kernels. In this case, if a CPU wakes up after at least one minute of inactivity, an RCU CPU stall warning will result. The reason that no one noticed until quite recently is that most systems have enough OS noise that they will never remain absolutely idle for a full minute. But there are some embedded systems with cut-down userspace configurations that get into this mode quite easily. All this begs the question of exactly how a callback-free grace period gets started in the first place. This can happen due to the fact that CPUs do not necessarily agree on which grace period is in progress. If a CPU still believes that the grace period that just completed is still ongoing, it will believe that it has callbacks that need to wait for another grace period, never mind the fact that the grace period that they were waiting for just completed. This CPU can therefore erroneously decide to start a new grace period. Once this CPU notices that the earlier grace period completed, it will invoke its callbacks. It then won't have any callbacks left. If no other CPU has any callbacks, we now have a callback-free grace period. This commit therefore makes CPUs check more carefully before starting a new grace period. This new check relies on an array of tail pointers into each CPU's list of callbacks. If the CPU is up to date on which grace periods have completed, it checks to see if any callbacks follow the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks follow the RCU_WAIT_TAIL segment. The reason that this works is that the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment as soon as the CPU figures out that the old grace period has ended. This change is to cpu_needs_another_gp(), which is called in a number of places. The only one that really matters is in rcu_start_gp(), where the root rcu_node structure's -lock is held, which prevents any other CPU from starting or completing a grace period, so that the comparison that determines whether the CPU is missing the completion of a grace period is stable. Signed-off-by: Paul E. McKenney paul.mcken...@linaro.org Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com As already confirmed by Paul W and others, I too no longer see the rcu dumps any more with above patch. Thanks a lot for the fix. 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: gpmc_cs_request() causes early boot hang
On 24/09/12 05:51, Mohammed, Afzal wrote:
It seems you are using PSP Kernel.
Invoking omap_init_gpmc before gpmc request should help.
Okay ... I'm now using earlyprintk and omap_init_gpmc(), but I still get boot
hangs.
My test code is as follows:-
diff --git a/arch/arm/mach-omap2/board-am335xevm.c
b/arch/arm/mach-omap2/board-am335xevm.c
index dc62ba2..be47e4f 100644
--- a/arch/arm/mach-omap2/board-am335xevm.c
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -4295,6 +4295,20 @@ static void __init am33xx_cpuidle_init(void)
}
+static void gpmc_test(void)
+{
+ unsigned long base = 0x12345678;
+
+ struct gpmc_devices_info gpmc_device[2] = {
+ { NULL, GPMC_DEVICE_NOR },
+ };
+
+ setup_pin_mux(gpmc_pin_mux);
+ omap_init_gpmc(gpmc_device, sizeof(gpmc_device));
+ gpmc_cs_request(0, SZ_16M, base);
+ printk(KERN_INFO gpmc base @ 0x%08lx\n, base);
+}
+
static void __init am335x_evm_init(void)
{
am33xx_cpuidle_init();
@@ -4313,6 +4327,8 @@ static void __init am335x_evm_init(void)
/* Create an alias for gfx/sgx clock */
if (clk_add_alias(sgx_ck, NULL, gfx_fclk, NULL))
pr_warn(failed to create an alias: gfx_fclk -- sgx_ck\n);
+
+ gpmc_test();
}
static void __init am335x_evm_map_io(void)
But this then fails with the following boot log:-
Uncompressing Linux... done, booting the kernel.
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.28+ (mpfj@mpfj-nanobone) (gcc version 4.5.4
(Buildroot
2012.08-git-00388-g7019407) ) #127 Mon Sep 24 11:27:18 BST 2012
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine: am335xevm
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65536
[0.00] free_area_init_node: node 0, pgdat c044ca14, node_mem_map
c04b1000
[0.00] Normal zone: 512 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 65024 pages, LIFO batch:15
[0.00] AM335X ES1.0 (sgx neon )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 65024
[0.00] Kernel command line: console=ttyO0,115200n8 earlyprintk debug
root=/dev/mmcblk0p2 ro
rootfstype=ext2 rootwait ip=none
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 256MB = 256MB total
[0.00] Memory: 255052k/255052k available, 7092k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] modules : 0xbf80 - 0xc000 ( 8 MB)
[0.00] .text : 0xc0008000 - 0xc03de0ec (3929 kB)
[0.00] .init : 0xc03df000 - 0xc0404000 ( 148 kB)
[0.00] .data : 0xc0404000 - 0xc044dd58 ( 296 kB)
[0.00].bss : 0xc044dd7c - 0xc04b0694 ( 395 kB)
[0.00] NR_IRQS:396 nr_irqs:396 396
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
interrupts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER2 at 2400 Hz
[0.00] OMAP clocksource: GPTIMER1 at 32768 Hz
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every
131071999ms
[0.00] Console: colour dummy device 80x30
[0.004943] Calibrating delay loop... 498.89 BogoMIPS (lpj=2494464)
[0.062072] pid_max: default: 32768 minimum: 301
[0.067047] Security Framework initialized
[0.071441] Mount-cache hash table entries: 512
[0.076599] Initializing cgroup subsys cpuacct
[0.081329] Initializing cgroup subsys devices
[0.085998] Initializing cgroup subsys freezer
[0.090728] CPU: Testing write buffer coherency: ok
[0.097045] devtmpfs: initialized
[0.102478] ttyO0 used as console in debug mode uart0 clocks will not be
gated
[0.128417] omap_hwmod: gfx: failed to hardreset
[0.150238] omap_hwmod: pruss: failed to hardreset
[0.155822] print_constraints: dummy:
[0.160064] NET: Registered protocol family 16
[0.165985] OMAP GPIO hardware version 0.1
[0.171600] omap_mux_init: Add partition: #1: core, flags: 0
[0.179107] omap_i2c.1: alias fck already exists
[0.185028] Unable to handle kernel NULL pointer dereference at virtual
RE: gpmc_cs_request() causes early boot hang
Hi Mark,
On Mon, Sep 24, 2012 at 16:21:40, Mark Jackson wrote:
On 24/09/12 05:51, Mohammed, Afzal wrote:
It seems you are using PSP Kernel.
Invoking omap_init_gpmc before gpmc request should help.
Okay ... I'm now using earlyprintk and omap_init_gpmc(), but I still get boot
hangs.
Surely omap-gpmc needs to be setup before any calls such as gpmc_cs_request()
?
Is there a method to delay my test code, or maybe get the omap-gpmc
registered earlier ?
Hope below patch helps you (untested)
Regards
Afzal
8---
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1c53c05..a4c6912 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -827,7 +827,19 @@ static struct platform_driver gpmc_driver = {
},
};
-module_platform_driver(gpmc_driver);
+static __init int gpmc_init(void)
+{
+return platform_driver_register(gpmc_driver);
+}
+
+static __exit void gpmc_exit(void)
+{
+platform_driver_unregister(gpmc_driver);
+
+}
+
+postcore_initcall(gpmc_init);
+module_exit(gpmc_exit);
int gpmc_suspend(void)
{
8
Re: gpmc_cs_request() causes early boot hang
On 24/09/12 12:13, Mohammed, Afzal wrote:
Hi Mark,
On Mon, Sep 24, 2012 at 16:21:40, Mark Jackson wrote:
On 24/09/12 05:51, Mohammed, Afzal wrote:
It seems you are using PSP Kernel.
Invoking omap_init_gpmc before gpmc request should help.
Okay ... I'm now using earlyprintk and omap_init_gpmc(), but I still get
boot hangs.
Surely omap-gpmc needs to be setup before any calls such as
gpmc_cs_request() ?
Is there a method to delay my test code, or maybe get the omap-gpmc
registered earlier ?
Hope below patch helps you (untested)
Regards
Afzal
8---
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1c53c05..a4c6912 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -827,7 +827,19 @@ static struct platform_driver gpmc_driver = {
},
};
-module_platform_driver(gpmc_driver);
+static __init int gpmc_init(void)
+{
+return platform_driver_register(gpmc_driver);
+}
+
+static __exit void gpmc_exit(void)
+{
+platform_driver_unregister(gpmc_driver);
+
+}
+
+postcore_initcall(gpmc_init);
+module_exit(gpmc_exit);
int gpmc_suspend(void)
{
8
Perfect !!
I also got it working by adding late_init() hooks into
arch/arm/kernel/setup.c, but your code is
much simpler.
Regards
Mark J.
--
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 00/13] DMA Engine support for AM33xx
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote: On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote: On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote: This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. There are a mind-boggling number of dependencies for this series: - Jon Hunter's OF DMA helpers series https://patchwork.kernel.org/patch/1461061/ https://patchwork.kernel.org/patch/1461051/ - Patch to address OF DMA helpers naming issues: https://patchwork.kernel.org/patch/1477921/ - EDMA DMA Engine wrapper driver in linux-next c2dde5f8f2095d7c623ff3565c1462e190272273 - EDMA DMA Engine wrapper driver bug fix: https://patchwork.kernel.org/patch/1474411/ - A huge number of patches in linux-next for AM33xx boot (too numerous to list) The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. What works? Well, with this series we now have MMC and SPI support on AM33xx. The only caveat for MMC is that the mmc3 controller has its events on the crossbar and is not usable right now. This is tested on BeagleBone with a SPI framebuffer driver and SD card. After this series, the plan is to convert the last in-tree user of the private EDMA API (davinci-pcm/mcasp) and then eliminate the private EDMA API by folding its functionality into drivers/dma/edma.c. TODO: add AM33xx crossbar support to the private EDMA API (any EDMA events on the crossbar are not supported) Can you please mention the base repo you have taken as starting point. (repo + extra patches ...). It's mainline 3.6-rc6 and you can see the complete set of patches at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1 after commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2 Thanks for the link. However, I was looking for the mainline kernel repo/branch That you first used as baseline. This will help us to test the code. This is because I looked at the patch 12/13 and I see that mmc device-node is modified. But in mainline I don’t see device node for mmc (yet). Oops. You'll need e62aae450bcdefbe9d7bc277ae0ef645 and fe97304557d2c6f7d0aaf1ea028ea48ffca366a9 which I forgot to include in this series. I'll have them in for v2. -Matt Matt Porter (13): ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add DT and runtime PM support for AM335x dmaengine: edma: enable build for AM335x dma: Add TI EDMA device tree binding ARM: omap: add hsmmc am33xx specific init mmc: omap_hsmmc: dma_request_slave_channel() support for DT platforms mmc: omap_hsmmc: limit max_segs with the EDMA DMAC mmc: omap_hsmmc: add generic DMA request support to the DT binding spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add am33xx EDMA support Documentation: add schedule for removing private EDMA API Documentation/devicetree/bindings/dma/ti-edma.txt | 49 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- Documentation/feature-removal-schedule.txt | 10 + arch/arm/Kconfig |1 + arch/arm/boot/dts/am33xx.dtsi | 46 + arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1779 arch/arm/include/asm/mach/edma.h | 267 +++ arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/devices.c|3 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- arch/arm/mach-davinci/dma.c| 1588 -
Re: [RFC PATCH 00/13] DMA Engine support for AM33xx
On Mon, Sep 24, 2012 at 11:26:55AM +, Hebbar, Gururaja wrote: On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote: On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote: On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote: This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. There are a mind-boggling number of dependencies for this series: - Jon Hunter's OF DMA helpers series https://patchwork.kernel.org/patch/1461061/ https://patchwork.kernel.org/patch/1461051/ - Patch to address OF DMA helpers naming issues: https://patchwork.kernel.org/patch/1477921/ - EDMA DMA Engine wrapper driver in linux-next c2dde5f8f2095d7c623ff3565c1462e190272273 - EDMA DMA Engine wrapper driver bug fix: https://patchwork.kernel.org/patch/1474411/ - A huge number of patches in linux-next for AM33xx boot (too numerous to list) The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. What works? Well, with this series we now have MMC and SPI support on AM33xx. The only caveat for MMC is that the mmc3 controller has its events on the crossbar and is not usable right now. This is tested on BeagleBone with a SPI framebuffer driver and SD card. After this series, the plan is to convert the last in-tree user of the private EDMA API (davinci-pcm/mcasp) and then eliminate the private EDMA API by folding its functionality into drivers/dma/edma.c. TODO: add AM33xx crossbar support to the private EDMA API (any EDMA events on the crossbar are not supported) Can you please mention the base repo you have taken as starting point. (repo + extra patches ...). It's mainline 3.6-rc6 and you can see the complete set of patches at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1 after commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2 Thanks for the link. However, I was looking for the mainline kernel repo/branch That you first used as baseline. Linus 3.6-rc6 is the baseline. This inital version was created before any of the am33xx base support patches got pulled to linux-next. v2 is being rebased against that to slim down the stack of patches necessary for testing. This will help us to test the code. This is because I looked at the patch 12/13 and I see that mmc device-node is modified. But in mainline I don’t see device node for mmc (yet). Oops. You'll need e62aae450bcdefbe9d7bc277ae0ef645 and fe97304557d2c6f7d0aaf1ea028ea48ffca366a9 which I forgot to include in this series. I'll have them in for v2. -Matt Matt Porter (13): ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add DT and runtime PM support for AM335x dmaengine: edma: enable build for AM335x dma: Add TI EDMA device tree binding ARM: omap: add hsmmc am33xx specific init mmc: omap_hsmmc: dma_request_slave_channel() support for DT platforms mmc: omap_hsmmc: limit max_segs with the EDMA DMAC mmc: omap_hsmmc: add generic DMA request support to the DT binding spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add am33xx EDMA support Documentation: add schedule for removing private EDMA API Documentation/devicetree/bindings/dma/ti-edma.txt | 49 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- Documentation/feature-removal-schedule.txt | 10 + arch/arm/Kconfig |1 + arch/arm/boot/dts/am33xx.dtsi | 46 + arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1779 arch/arm/include/asm/mach/edma.h | 267 +++
Re: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS
Hi, On Mon, Sep 24, 2012 at 02:53:24PM +0300, philippedesw...@gmail.com wrote: From: Philippe De Swert philippe.desw...@jollamobile.com Unless generic_interrupt is defined the irq setup in musb_init_controller fails for the omap2430 driver since that one does not set it's own interrupt handler. Which leaves usb non-functional. Tested on N950/N9. Signed-off-by: Philippe De Swert philippedesw...@gmail.com SoB's mail doesn't From mail. --- drivers/usb/musb/musb_core.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index db3dff8..ff9e482 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1499,7 +1499,8 @@ static int __devinit musb_core_init(u16 musb_type, struct musb *musb) /*-*/ #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \ - defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) + defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \ + defined(CONFIG_ARCH_OMAP2PLUS) Weird, how can you build OMAP2PLUS without SOC_OMAP ?? BTW, this is also wrong as OMAP2PLUS is also used to enable AM3xxx and TI8xxx, and those platforms don't use generic_interrupt(). -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS
On Mon, Sep 24, 2012 at 03:15:39PM +0300, Felipe Balbi wrote: Hi, On Mon, Sep 24, 2012 at 02:53:24PM +0300, philippedesw...@gmail.com wrote: From: Philippe De Swert philippe.desw...@jollamobile.com Unless generic_interrupt is defined the irq setup in musb_init_controller fails for the omap2430 driver since that one does not set it's own interrupt handler. Which leaves usb non-functional. Tested on N950/N9. Signed-off-by: Philippe De Swert philippedesw...@gmail.com SoB's mail doesn't From mail. doesn't 'match'. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS
Hi,
On 24/09/2012, Felipe Balbi ba...@ti.com wrote:
SoB's mail doesn't From mail.
Well still in the progress of migrating of my personal to work laptop.
Since the patch does not seem correct the replacement will have
matching addresses.
/*-*/
#if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \
-defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500)
+defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \
+defined(CONFIG_ARCH_OMAP2PLUS)
Weird, how can you build OMAP2PLUS without SOC_OMAP ??
It seems entirely possible. I quickly tried to look if it got defined
somewhere and it does not seem to be set anywhere. That is why I got
the impression it was replaced by CONFIG_ARCH_OMAP2PLUS. I'll dig
deeper to find out why SOC_OMAP is not set if it should be.
From the .config I got (used menuconfig)
#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_SOC_HAS_OMAP2_SDRC=y
# CONFIG_ARCH_OMAP2 is not set
CONFIG_ARCH_OMAP3=y
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
# CONFIG_SOC_OMAP3430 is not set
# CONFIG_SOC_TI81XX is not set
# CONFIG_SOC_AM33XX is not set
CONFIG_OMAP_PACKAGE_CBB=y
Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not
get set (while it is not a 3430 but a 3630 I am using). Maybe
CONFIG_ARCH_OMAP3 would have been a better choice then?
BTW, this is also wrong as OMAP2PLUS is also used to enable AM3xxx and
TI8xxx, and those platforms don't use generic_interrupt().
It would not break them from what I could see in musb_core.c
musb-isr = generic_interrupt;
status = musb_platform_init(musb); --- isr would be (re)set here
if (status 0)
goto fail1;
if (!musb-isr) {
status = -ENODEV;
goto fail2;
}
The two you mention set their own interrupt routines.
drivers/usb/musb/da8xx.c: musb-isr = da8xx_musb_interrupt;
drivers/usb/musb/am35x.c: musb-isr = am35x_musb_interrupt;
Regards,
Philippe
--
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/1] usb: Include generic_interrupt for OMAP2_PLUS
Hi, On Mon, Sep 24, 2012 at 03:54:22PM +0300, Philippe De Swert wrote: Hi, On 24/09/2012, Felipe Balbi ba...@ti.com wrote: SoB's mail doesn't From mail. Well still in the progress of migrating of my personal to work laptop. Since the patch does not seem correct the replacement will have matching addresses. /*-*/ #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \ - defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) + defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \ + defined(CONFIG_ARCH_OMAP2PLUS) Weird, how can you build OMAP2PLUS without SOC_OMAP ?? It seems entirely possible. I quickly tried to look if it got defined somewhere and it does not seem to be set anywhere. That is why I got the impression it was replaced by CONFIG_ARCH_OMAP2PLUS. I'll dig deeper to find out why SOC_OMAP is not set if it should be. From the .config I got (used menuconfig) # # TI OMAP2/3/4 Specific Features # CONFIG_ARCH_OMAP2PLUS_TYPICAL=y CONFIG_SOC_HAS_OMAP2_SDRC=y # CONFIG_ARCH_OMAP2 is not set CONFIG_ARCH_OMAP3=y # CONFIG_ARCH_OMAP4 is not set # CONFIG_SOC_OMAP5 is not set # CONFIG_SOC_OMAP3430 is not set # CONFIG_SOC_TI81XX is not set # CONFIG_SOC_AM33XX is not set CONFIG_OMAP_PACKAGE_CBB=y Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not get set (while it is not a 3430 but a 3630 I am using). Maybe CONFIG_ARCH_OMAP3 would have been a better choice then? that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all OMAP3 boards ? And another question: why don't we have a matching SOC_OMAP3530, SOC_OMAP3630 and so on ? BTW, this is also wrong as OMAP2PLUS is also used to enable AM3xxx and TI8xxx, and those platforms don't use generic_interrupt(). It would not break them from what I could see in musb_core.c musb-isr = generic_interrupt; status = musb_platform_init(musb); --- isr would be (re)set here good point. Still that code would be hanging there with no users... Fair enough, it's better to have extra code when it's not needed, then having no code when it's needed :-) That entire musb-isr crap is quite screwed up anyway and it's just because TI's non-OMAP processors (daxxx, amxxx, ti8xxx, etc) decided that the wrapper should read MUSB's address space (including IRQ registers) and since MUSB's IRQ registers are clear-on-read we need to handle the IRQ from wrapper drivers, which is pretty screwed up as well. Ideally, we wouldn't have all of these exposed symbols flying around :-s -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote:
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++
drivers/usb/phy/Kconfig |9 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-usb2.c | 271
+
include/linux/usb/omap_usb.h | 46
include/linux/usb/phy_companion.h | 34 +++
6 files changed, 378 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt
create mode 100644 drivers/usb/phy/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
new file mode 100644
index 000..80d4148
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
This is a very generic name...
@@ -0,0 +1,17 @@
+USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
...for a specific phy. However, I do think a generic binding to describe
host ctrlr to phy connections is needed.
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
The dts should describe the h/w, not what you need for the current
driver. The 2nd reg field does not belong here.
+
+This is usually a subnode of ocp2scp to which it is connected.
How is usb port to phy connection described?
Rob
+
+usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x4;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2838adb..63c339b 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -4,6 +4,15 @@
comment USB Physical Layer drivers
depends on USB || USB_GADGET
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index bb948fb..b069f29 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -4,6 +4,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
+obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
obj-$(CONFIG_USB_ISP1301)+= isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
new file mode 100644
index 000..15ab3d6
--- /dev/null
+++ b/drivers/usb/phy/omap-usb2.c
@@ -0,0 +1,271 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * 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.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+
+/**
+ * omap_usb2_set_comparator - links the comparator present in the sytem with
+ * this phy
+ * @comparator - the companion phy(comparator) for this phy
+ *
+ * The phy companion driver should call this API passing the phy_companion
+ * filled with set_vbus and start_srp to be used by usb phy.
+ *
+ * For use by phy
Re: rcu self-detected stall messages on OMAP3, 4 boards
On Mon, Sep 24, 2012 at 03:11:34PM +0530, Shilimkar, Santosh wrote: On Sun, Sep 23, 2012 at 3:29 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sat, Sep 22, 2012 at 01:10:43PM -0700, Paul E. McKenney wrote: On Sat, Sep 22, 2012 at 06:42:08PM +, Paul Walmsley wrote: On Fri, 21 Sep 2012, Paul E. McKenney wrote: [...] And here is a patch. I am still having trouble reproducing the problem, but figured that I should avoid serializing things. Thanx, Paul b/kernel/rcutree.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) rcu: Fix day-one dyntick-idle stall-warning bug Each grace period is supposed to have at least one callback waiting for that grace period to complete. However, if CONFIG_NO_HZ=n, an extra callback-free grace period is no big problem -- it will chew up a tiny bit of CPU time, but it will complete normally. In contrast, CONFIG_NO_HZ=y kernels have the potential for all the CPUs to go to sleep indefinitely, in turn indefinitely delaying completion of the callback-free grace period. Given that nothing is waiting on this grace period, this is also not a problem. Unless RCU CPU stall warnings are also enabled, as they are in recent kernels. In this case, if a CPU wakes up after at least one minute of inactivity, an RCU CPU stall warning will result. The reason that no one noticed until quite recently is that most systems have enough OS noise that they will never remain absolutely idle for a full minute. But there are some embedded systems with cut-down userspace configurations that get into this mode quite easily. All this begs the question of exactly how a callback-free grace period gets started in the first place. This can happen due to the fact that CPUs do not necessarily agree on which grace period is in progress. If a CPU still believes that the grace period that just completed is still ongoing, it will believe that it has callbacks that need to wait for another grace period, never mind the fact that the grace period that they were waiting for just completed. This CPU can therefore erroneously decide to start a new grace period. Once this CPU notices that the earlier grace period completed, it will invoke its callbacks. It then won't have any callbacks left. If no other CPU has any callbacks, we now have a callback-free grace period. This commit therefore makes CPUs check more carefully before starting a new grace period. This new check relies on an array of tail pointers into each CPU's list of callbacks. If the CPU is up to date on which grace periods have completed, it checks to see if any callbacks follow the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks follow the RCU_WAIT_TAIL segment. The reason that this works is that the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment as soon as the CPU figures out that the old grace period has ended. This change is to cpu_needs_another_gp(), which is called in a number of places. The only one that really matters is in rcu_start_gp(), where the root rcu_node structure's -lock is held, which prevents any other CPU from starting or completing a grace period, so that the comparison that determines whether the CPU is missing the completion of a grace period is stable. Signed-off-by: Paul E. McKenney paul.mcken...@linaro.org Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com As already confirmed by Paul W and others, I too no longer see the rcu dumps any more with above patch. Thanks a lot for the fix. Glad it finally works! Thanx, 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 0/9] OMAPDSS: OMAP5 related patches
Hi, This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI and DSI. Tomi Archit Taneja (1): OMAPDSS: Add basic omap5 features to dss and dispc Tomi Valkeinen (8): OMAPDSS: DSI: improve DSI clock calcs for DISPC OMAPDSS: move dss feats to the end of dss.c OMAPDSS: Add support for DPI source selection OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL OMAPDSS: DSI: Add new linebuffer size for OMAP5 OMAPDSS: DSI: Add code to disable PHY DCC OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5 drivers/video/omap2/dss/Kconfig|2 +- drivers/video/omap2/dss/dispc.c|2 + drivers/video/omap2/dss/dpi.c |5 + drivers/video/omap2/dss/dsi.c | 167 +--- drivers/video/omap2/dss/dss.c | 121 ++- drivers/video/omap2/dss/dss.h |1 + drivers/video/omap2/dss/dss_features.c | 96 ++ drivers/video/omap2/dss/dss_features.h |3 + 8 files changed, 337 insertions(+), 60 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] OMAPDSS: DSI: improve DSI clock calcs for DISPC
Commit ee144e645a081daad5de1ccac77f0a0e98e6a67b added
dsi_pll_calc_ddrfreq() which calculates PLL dividers based on given DSI
bus clock speed. The function works ok, but it can be improved for the
DISPC clock calc.
The current version calculates the clock going from the PLL to the DISPC
simply by setting the clock as close to DISPC maximum as possible, and
the pixel clock is calculated based on that.
This patch changes the function to calculate DISPC clock more
dynamically, iterating through different DISPC clocks and pixel clock
values, and thus we'll get more suitable pixel clocks.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 144 -
1 file changed, 113 insertions(+), 31 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8d815e3..8d47fb7 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1454,26 +1454,17 @@ found:
}
static int dsi_pll_calc_ddrfreq(struct platform_device *dsidev,
- unsigned long req_clk, struct dsi_clock_info *cinfo)
+ unsigned long req_clkin4ddr, struct dsi_clock_info *cinfo)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct dsi_clock_info cur, best;
- unsigned long dss_sys_clk, max_dss_fck, max_dsi_fck;
- unsigned long req_clkin4ddr;
DSSDBG(dsi_pll_calc_ddrfreq\n);
- dss_sys_clk = clk_get_rate(dsi-sys_clk);
-
- max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
- max_dsi_fck = dss_feat_get_param_max(FEAT_PARAM_DSI_FCK);
-
memset(best, 0, sizeof(best));
memset(cur, 0, sizeof(cur));
- cur.clkin = dss_sys_clk;
-
- req_clkin4ddr = req_clk * 4;
+ cur.clkin = clk_get_rate(dsi-sys_clk);
for (cur.regn = 1; cur.regn dsi-regn_max; ++cur.regn) {
cur.fint = cur.clkin / cur.regn;
@@ -1503,18 +1494,107 @@ static int dsi_pll_calc_ddrfreq(struct platform_device
*dsidev,
}
}
found:
- best.regm_dispc = DIV_ROUND_UP(best.clkin4ddr, max_dss_fck);
- best.dsi_pll_hsdiv_dispc_clk = best.clkin4ddr / best.regm_dispc;
-
- best.regm_dsi = DIV_ROUND_UP(best.clkin4ddr, max_dsi_fck);
- best.dsi_pll_hsdiv_dsi_clk = best.clkin4ddr / best.regm_dsi;
-
if (cinfo)
*cinfo = best;
return 0;
}
+static void dsi_pll_calc_dsi_fck(struct platform_device *dsidev,
+ struct dsi_clock_info *cinfo)
+{
+ unsigned long max_dsi_fck;
+
+ max_dsi_fck = dss_feat_get_param_max(FEAT_PARAM_DSI_FCK);
+
+ cinfo-regm_dsi = DIV_ROUND_UP(cinfo-clkin4ddr, max_dsi_fck);
+ cinfo-dsi_pll_hsdiv_dsi_clk = cinfo-clkin4ddr / cinfo-regm_dsi;
+}
+
+static int dsi_pll_calc_dispc_fck(struct platform_device *dsidev,
+ unsigned long req_pck, struct dsi_clock_info *cinfo,
+ struct dispc_clock_info *dispc_cinfo)
+{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ unsigned regm_dispc, best_regm_dispc;
+ unsigned long dispc_clk, best_dispc_clk;
+ int min_fck_per_pck;
+ unsigned long max_dss_fck;
+ struct dispc_clock_info best_dispc;
+ bool match;
+
+ max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+
+ min_fck_per_pck = CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK;
+
+ if (min_fck_per_pck
+ req_pck * min_fck_per_pck max_dss_fck) {
+ DSSERR(Requested pixel clock not possible with the current
+ OMAP2_DSS_MIN_FCK_PER_PCK setting. Turning
+ the constraint off.\n);
+ min_fck_per_pck = 0;
+ }
+
+retry:
+ best_regm_dispc = 0;
+ best_dispc_clk = 0;
+ memset(best_dispc, 0, sizeof(best_dispc));
+ match = false;
+
+ for (regm_dispc = 1; regm_dispc dsi-regm_dispc_max; ++regm_dispc) {
+ struct dispc_clock_info cur_dispc;
+
+ dispc_clk = cinfo-clkin4ddr / regm_dispc;
+
+ /* this will narrow down the search a bit,
+* but still give pixclocks below what was
+* requested */
+ if (dispc_clk req_pck)
+ break;
+
+ if (dispc_clk max_dss_fck)
+ continue;
+
+ if (min_fck_per_pck dispc_clk req_pck * min_fck_per_pck)
+ continue;
+
+ match = true;
+
+ dispc_find_clk_divs(req_pck, dispc_clk, cur_dispc);
+
+ if (abs(cur_dispc.pck - req_pck)
+ abs(best_dispc.pck - req_pck)) {
+ best_regm_dispc = regm_dispc;
+ best_dispc_clk = dispc_clk;
+ best_dispc = cur_dispc;
+
+ if (cur_dispc.pck == req_pck)
+ goto found;
+ }
+
[PATCH 3/9] OMAPDSS: move dss feats to the end of dss.c
Move dss_features to the end of dss.c the same way they are in dispc.c,
so that we don't have to declare prototypes for static feat-related
functions.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 60 -
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 4524c17..660813b 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -99,36 +99,6 @@ static const char * const dss_generic_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_FCK] = DSS_FCK,
};
-static const struct dss_features omap24xx_dss_feats __initconst = {
- .fck_div_max= 16,
- .dss_fck_multiplier = 2,
- .clk_name = NULL,
-};
-
-static const struct dss_features omap34xx_dss_feats __initconst = {
- .fck_div_max= 16,
- .dss_fck_multiplier = 2,
- .clk_name = dpll4_m4_ck,
-};
-
-static const struct dss_features omap3630_dss_feats __initconst = {
- .fck_div_max= 32,
- .dss_fck_multiplier = 1,
- .clk_name = dpll4_m4_ck,
-};
-
-static const struct dss_features omap44xx_dss_feats __initconst = {
- .fck_div_max= 32,
- .dss_fck_multiplier = 1,
- .clk_name = dpll_per_m5x2_ck,
-};
-
-static const struct dss_features omap54xx_dss_feats __initconst = {
- .fck_div_max= 64,
- .dss_fck_multiplier = 1,
- .clk_name = dpll_per_h12x2_ck,
-};
-
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
{
__raw_writel(val, dss.base + idx.idx);
@@ -727,6 +697,36 @@ void dss_debug_dump_clocks(struct seq_file *s)
}
#endif
+static const struct dss_features omap24xx_dss_feats __initconst = {
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
+ .clk_name = NULL,
+};
+
+static const struct dss_features omap34xx_dss_feats __initconst = {
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
+ .clk_name = dpll4_m4_ck,
+};
+
+static const struct dss_features omap3630_dss_feats __initconst = {
+ .fck_div_max= 32,
+ .dss_fck_multiplier = 1,
+ .clk_name = dpll4_m4_ck,
+};
+
+static const struct dss_features omap44xx_dss_feats __initconst = {
+ .fck_div_max= 32,
+ .dss_fck_multiplier = 1,
+ .clk_name = dpll_per_m5x2_ck,
+};
+
+static const struct dss_features omap54xx_dss_feats __initconst = {
+ .fck_div_max= 64,
+ .dss_fck_multiplier = 1,
+ .clk_name = dpll_per_h12x2_ck,
+};
+
static int __init dss_init_features(struct device *dev)
{
const struct dss_features *src;
--
1.7.9.5
--
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 4/9] OMAPDSS: Add support for DPI source selection
We can select the video source for DPI output as follows:
OMAP2/3: always LCD1
OMAP4: LCD2 or DIGIT
OMAP5: LCD1/LCD2/LCD3/DIGIT
This patch adds support to select the source, and makes dpi.c call the
function to set the source.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: David Anders x0132...@ti.com
---
drivers/video/omap2/dss/dpi.c |5
drivers/video/omap2/dss/dss.c | 65 +
drivers/video/omap2/dss/dss.h |1 +
3 files changed, 71 insertions(+)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 5ccce9b..b723388 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -203,6 +203,10 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_get_dispc;
+ r = dss_dpi_select_source(dssdev-channel);
+ if (r)
+ goto err_src_sel;
+
if (dpi_use_dsi_pll(dssdev)) {
r = dsi_runtime_get(dpi.dsidev);
if (r)
@@ -237,6 +241,7 @@ err_dsi_pll_init:
if (dpi_use_dsi_pll(dssdev))
dsi_runtime_put(dpi.dsidev);
err_get_dsi:
+err_src_sel:
dispc_runtime_put();
err_get_dispc:
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 660813b..2ab1c3e9 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -69,6 +69,7 @@ struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
const char *clk_name;
+ int (*dpi_select_source)(enum omap_channel channel);
};
static struct {
@@ -623,6 +624,65 @@ enum dss_hdmi_venc_clk_source_select
dss_get_hdmi_venc_clk_source(void)
return REG_GET(DSS_CONTROL, 15, 15);
}
+static int dss_dpi_select_source_omap2_omap3(enum omap_channel channel)
+{
+ if (channel != OMAP_DSS_CHANNEL_LCD)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int dss_dpi_select_source_omap4(enum omap_channel channel)
+{
+ int val;
+
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD2:
+ val = 0;
+ break;
+ case OMAP_DSS_CHANNEL_DIGIT:
+ val = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ REG_FLD_MOD(DSS_CONTROL, val, 17, 17);
+
+ return 0;
+}
+
+static int dss_dpi_select_source_omap5(enum omap_channel channel)
+{
+ int val;
+
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ val = 1;
+ break;
+ case OMAP_DSS_CHANNEL_LCD2:
+ val = 2;
+ break;
+ case OMAP_DSS_CHANNEL_LCD3:
+ val = 3;
+ break;
+ case OMAP_DSS_CHANNEL_DIGIT:
+ val = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ REG_FLD_MOD(DSS_CONTROL, val, 17, 16);
+
+ return 0;
+}
+
+int dss_dpi_select_source(enum omap_channel channel)
+{
+ return dss.feat-dpi_select_source(channel);
+}
+
static int dss_get_clocks(void)
{
struct clk *clk;
@@ -701,30 +761,35 @@ static const struct dss_features omap24xx_dss_feats
__initconst = {
.fck_div_max= 16,
.dss_fck_multiplier = 2,
.clk_name = NULL,
+ .dpi_select_source = dss_dpi_select_source_omap2_omap3,
};
static const struct dss_features omap34xx_dss_feats __initconst = {
.fck_div_max= 16,
.dss_fck_multiplier = 2,
.clk_name = dpll4_m4_ck,
+ .dpi_select_source = dss_dpi_select_source_omap2_omap3,
};
static const struct dss_features omap3630_dss_feats __initconst = {
.fck_div_max= 32,
.dss_fck_multiplier = 1,
.clk_name = dpll4_m4_ck,
+ .dpi_select_source = dss_dpi_select_source_omap2_omap3,
};
static const struct dss_features omap44xx_dss_feats __initconst = {
.fck_div_max= 32,
.dss_fck_multiplier = 1,
.clk_name = dpll_per_m5x2_ck,
+ .dpi_select_source = dss_dpi_select_source_omap4,
};
static const struct dss_features omap54xx_dss_feats __initconst = {
.fck_div_max= 64,
.dss_fck_multiplier = 1,
.clk_name = dpll_per_h12x2_ck,
+ .dpi_select_source = dss_dpi_select_source_omap5,
};
static int __init dss_init_features(struct device *dev)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 5e9fd769..2a51ae9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -277,6 +277,7 @@ void dss_overlay_kobj_uninit(struct omap_overlay *ovl);
int dss_init_platform_driver(void) __init;
[PATCH 2/9] OMAPDSS: Add basic omap5 features to dss and dispc
From: Archit Taneja arc...@ti.com
Add basic omap5 features for dss and dispc.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c|2 +
drivers/video/omap2/dss/dss.c |8 +++
drivers/video/omap2/dss/dss_features.c | 93
3 files changed, 103 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d512c38..e52c5778 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3829,6 +3829,8 @@ static int __init dispc_init_features(struct device *dev)
src = omap34xx_rev3_0_dispc_feats;
} else if (cpu_is_omap44xx()) {
src = omap44xx_dispc_feats;
+ } else if (soc_is_omap54xx()) {
+ src = omap44xx_dispc_feats;
} else {
return -ENODEV;
}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 759dbee..4524c17 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -123,6 +123,12 @@ static const struct dss_features omap44xx_dss_feats
__initconst = {
.clk_name = dpll_per_m5x2_ck,
};
+static const struct dss_features omap54xx_dss_feats __initconst = {
+ .fck_div_max= 64,
+ .dss_fck_multiplier = 1,
+ .clk_name = dpll_per_h12x2_ck,
+};
+
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
{
__raw_writel(val, dss.base + idx.idx);
@@ -740,6 +746,8 @@ static int __init dss_init_features(struct device *dev)
src = omap3630_dss_feats;
else if (cpu_is_omap44xx())
src = omap44xx_dss_feats;
+ else if (soc_is_omap54xx())
+ src = omap54xx_dss_feats;
else
return -ENODEV;
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index c26fc1f..af4775a 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -106,6 +106,21 @@ static const struct dss_reg_field omap4_dss_reg_fields[] =
{
[FEAT_REG_DSIPLL_REGM_DSI] = { 30, 26 },
};
+static const struct dss_reg_field omap5_dss_reg_fields[] = {
+ [FEAT_REG_FIRHINC] = { 12, 0 },
+ [FEAT_REG_FIRVINC] = { 28, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 15, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD]= { 31, 16 },
+ [FEAT_REG_FIFOSIZE] = { 15, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 10, 0 },
+ [FEAT_REG_VERTICALACCU] = { 26, 16 },
+ [FEAT_REG_DISPC_CLK_SWITCH] = { 9, 7 },
+ [FEAT_REG_DSIPLL_REGN] = { 8, 1 },
+ [FEAT_REG_DSIPLL_REGM] = { 20, 9 },
+ [FEAT_REG_DSIPLL_REGM_DISPC]= { 25, 21 },
+ [FEAT_REG_DSIPLL_REGM_DSI] = { 30, 26 },
+};
+
static const enum omap_display_type omap2_dss_supported_displays[] = {
/* OMAP_DSS_CHANNEL_LCD */
OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI,
@@ -144,6 +159,19 @@ static const enum omap_display_type
omap4_dss_supported_displays[] = {
OMAP_DISPLAY_TYPE_DSI,
};
+static const enum omap_display_type omap5_dss_supported_displays[] = {
+ /* OMAP_DSS_CHANNEL_LCD */
+ OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
+ OMAP_DISPLAY_TYPE_DSI,
+
+ /* OMAP_DSS_CHANNEL_DIGIT */
+ OMAP_DISPLAY_TYPE_HDMI | OMAP_DISPLAY_TYPE_DPI,
+
+ /* OMAP_DSS_CHANNEL_LCD2 */
+ OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
+ OMAP_DISPLAY_TYPE_DSI,
+};
+
static const enum omap_color_mode omap2_dss_supported_color_modes[] = {
/* OMAP_DSS_GFX */
OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
@@ -298,6 +326,14 @@ static const char * const omap4_dss_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI] = PLL2_CLK2,
};
+static const char * const omap5_dss_clk_source_names[] = {
+ [OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC] = DPLL_DSI1_A_CLK1,
+ [OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI]= DPLL_DSI1_A_CLK2,
+ [OMAP_DSS_CLK_SRC_FCK] = DSS_CLK,
+ [OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC] = DPLL_DSI1_C_CLK1,
+ [OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI] = DPLL_DSI1_C_CLK2,
+};
+
static const struct dss_param_range omap2_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK]= { 0, 17300 },
[FEAT_PARAM_DSS_PCD]= { 2, 255 },
@@ -349,6 +385,22 @@ static const struct dss_param_range
omap4_dss_param_range[] = {
[FEAT_PARAM_MGR_HEIGHT] = { 1, 2048 },
};
+static const struct dss_param_range omap5_dss_param_range[] = {
+ [FEAT_PARAM_DSS_FCK]= { 0, 2
[PATCH 6/9] OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL
Add FEAT_DSI_PLL_REFSEL. OMAP5's DSI PLL needs configuration to select
the reference clock to be used. We always use SYSCLK.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |2 ++
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/dss_features.h |1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 0c3afc2..a16c8b2 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1690,6 +1690,8 @@ int dsi_pll_set_clock_div(struct platform_device *dsidev,
l = FLD_MOD(l, 1, 13, 13); /* DSI_PLL_REFEN */
l = FLD_MOD(l, 0, 14, 14); /* DSIPHY_CLKINEN */
l = FLD_MOD(l, 1, 20, 20); /* DSI_HSDIVBYPASS */
+ if (dss_has_feature(FEAT_DSI_PLL_REFSEL))
+ l = FLD_MOD(l, 3, 22, 21); /* REF_SYSCLK = sysclk */
dsi_write_reg(dsidev, DSI_PLL_CONFIGURATION2, l);
REG_FLD_MOD(dsidev, DSI_PLL_GO, 1, 0, 0); /* DSI_PLL_GO */
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 177f6e8..4685531 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -520,6 +520,7 @@ static const enum dss_feat_id omap5_dss_feat_list[] = {
FEAT_FIFO_MERGE,
FEAT_BURST_2D,
FEAT_DSI_PLL_SELFREQDCO,
+ FEAT_DSI_PLL_REFSEL,
};
/* OMAP2 DSS Features */
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index f9b9d28..0020bf6 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -66,6 +66,7 @@ enum dss_feat_id {
FEAT_OMAP3_DSI_FIFO_BUG,
FEAT_BURST_2D,
FEAT_DSI_PLL_SELFREQDCO,
+ FEAT_DSI_PLL_REFSEL,
};
/* DSS register field id */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO
Add FEAT_DSI_PLL_SELFREQDCO. OMAP5's DSI PLL has a new configuration
option that needs to be programmed depending on the PLL's output clock
frequency.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 12
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/dss_features.h |1 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8d47fb7..0c3afc2 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1671,18 +1671,22 @@ int dsi_pll_set_clock_div(struct platform_device
*dsidev,
BUG_ON(cinfo-fint dsi-fint_min || cinfo-fint dsi-fint_max);
+ l = dsi_read_reg(dsidev, DSI_PLL_CONFIGURATION2);
+
if (dss_has_feature(FEAT_DSI_PLL_FREQSEL)) {
f = cinfo-fint 100 ? 0x3 :
cinfo-fint 125 ? 0x4 :
cinfo-fint 150 ? 0x5 :
cinfo-fint 175 ? 0x6 :
0x7;
- }
-
- l = dsi_read_reg(dsidev, DSI_PLL_CONFIGURATION2);
- if (dss_has_feature(FEAT_DSI_PLL_FREQSEL))
l = FLD_MOD(l, f, 4, 1);/* DSI_PLL_FREQSEL */
+ } else if (dss_has_feature(FEAT_DSI_PLL_SELFREQDCO)) {
+ f = cinfo-clkin4ddr 10 ? 0x2 : 0x4;
+
+ l = FLD_MOD(l, f, 4, 1);/* PLL_SELFREQDCO */
+ }
+
l = FLD_MOD(l, 1, 13, 13); /* DSI_PLL_REFEN */
l = FLD_MOD(l, 0, 14, 14); /* DSIPHY_CLKINEN */
l = FLD_MOD(l, 1, 20, 20); /* DSI_HSDIVBYPASS */
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index af4775a..177f6e8 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -519,6 +519,7 @@ static const enum dss_feat_id omap5_dss_feat_list[] = {
FEAT_ALPHA_FREE_ZORDER,
FEAT_FIFO_MERGE,
FEAT_BURST_2D,
+ FEAT_DSI_PLL_SELFREQDCO,
};
/* OMAP2 DSS Features */
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index b81d603..f9b9d28 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -65,6 +65,7 @@ enum dss_feat_id {
/* An unknown HW bug causing the normal FIFO thresholds not to work */
FEAT_OMAP3_DSI_FIFO_BUG,
FEAT_BURST_2D,
+ FEAT_DSI_PLL_SELFREQDCO,
};
/* DSS register field id */
--
1.7.9.5
--
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 9/9] OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5
Change omapdss Kconfig file to make OMAP2_DSS_DSI depend on ARCH_OMAP5. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig index b337a84..80f5390 100644 --- a/drivers/video/omap2/dss/Kconfig +++ b/drivers/video/omap2/dss/Kconfig @@ -84,7 +84,7 @@ config OMAP2_DSS_SDI config OMAP2_DSS_DSI bool DSI support - depends on ARCH_OMAP3 || ARCH_OMAP4 + depends on ARCH_OMAP3 || ARCH_OMAP4 || ARCH_OMAP5 default n help MIPI DSI (Display Serial Interface) support. -- 1.7.9.5 -- 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 8/9] OMAPDSS: DSI: Add code to disable PHY DCC
OMAP5 DSI PHY has DCC (Duty Cycle Corrector) block, and by default DCC
is enabled and thus the PLL clock is divided by 2 to get the DSI DDR
clk. This divider has been 4 for all previous OMAPs, and changing it
needs some reorganization of the code. The DCC can be disabled, and in
that case the divider is back to the old 4.
This patch adds dss feature for the DCC, and adds code to always disable
the DCC.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |7 +++
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/dss_features.h |1 +
3 files changed, 9 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 0dc24f2..497b219 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -2292,6 +2292,13 @@ static void dsi_cio_timings(struct platform_device
*dsidev)
r = FLD_MOD(r, tlpx_half, 22, 16);
r = FLD_MOD(r, tclk_trail, 15, 8);
r = FLD_MOD(r, tclk_zero, 7, 0);
+
+ if (dss_has_feature(FEAT_DSI_PHY_DCC)) {
+ r = FLD_MOD(r, 0, 21, 21); /* DCCEN = disable */
+ r = FLD_MOD(r, 1, 22, 22); /* CLKINP_DIVBY2EN = enable */
+ r = FLD_MOD(r, 1, 23, 23); /* CLKINP_SEL = enable */
+ }
+
dsi_write_reg(dsidev, DSI_DSIPHY_CFG1, r);
r = dsi_read_reg(dsidev, DSI_DSIPHY_CFG2);
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 4685531..e650a4a 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -521,6 +521,7 @@ static const enum dss_feat_id omap5_dss_feat_list[] = {
FEAT_BURST_2D,
FEAT_DSI_PLL_SELFREQDCO,
FEAT_DSI_PLL_REFSEL,
+ FEAT_DSI_PHY_DCC,
};
/* OMAP2 DSS Features */
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index 0020bf6..aacad86 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -67,6 +67,7 @@ enum dss_feat_id {
FEAT_BURST_2D,
FEAT_DSI_PLL_SELFREQDCO,
FEAT_DSI_PLL_REFSEL,
+ FEAT_DSI_PHY_DCC,
};
/* DSS register field id */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] OMAPDSS: DSI: Add new linebuffer size for OMAP5
OMAP5's DSI has a larger line buffer than earlier OMAPs. This patch adds support for this to the DSI driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dsi.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index a16c8b2..0dc24f2 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -2155,6 +2155,8 @@ static unsigned dsi_get_line_buf_size(struct platform_device *dsidev) return 1194 * 3;/* 1194x24 bits */ case 6: return 1365 * 3;/* 1365x24 bits */ + case 7: + return 1920 * 3;/* 1920x24 bits */ default: BUG(); return 0; -- 1.7.9.5 -- 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: OMAP: SmartReflex: pass device dependent data via platform data
Hi Tony, On Fri, Sep 21, 2012 at 9:07 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [120920 23:31]: On Fri, Sep 21, 2012 at 12:15 AM, Tony Lindgren t...@atomide.com wrote: You should be able to make this even simpler and not have to pass the clock name around at all. Just do: syc_ck = clk_get(NULL, fck); ... The problem is that the system has multiple instances of the smartreflex module, each having its own fck. On OMAP3/4 the fck's are derived from sys_clk via muxes and latches. The proposed code uses the fck's as defined in the .main_clk field of the hwmod entries, so that it takes the muxes and latches into account and also has a consistent clock naming. If the same system has multiple clocks, then you could have them matched by the smartreflex driver instance number. Or if you mean different source clocks for various omaps, then you just need to set multiple aliases for those clocks. In the driver, and add the necessary entries to the clock alias table. That way it's up to the SoC to set up the necessary clocks and the driver stays generic. Got it. The only solution would be to use an unique fck for all smartreflex modules in all configurations. Is that acceptable? Hmm maybe I don't follow you, but sounds like you just need to use the driver instance like we do for timers: $ grep omap_timer arch/arm/mach-omap2/clock*data*.c arch/arm/mach-omap2/clock44xx_data.c: CLK(omap_timer.1, timer_sys_ck, sys_clkin_ck, CK_443X), arch/arm/mach-omap2/clock44xx_data.c: CLK(omap_timer.2, timer_sys_ck, sys_clkin_ck, CK_443X), arch/arm/mach-omap2/clock44xx_data.c: CLK(omap_timer.3, timer_sys_ck, sys_clkin_ck, CK_443X), ... Ok. I have a new version that implements this, re-submitting in a bit. If you need multiple clocks for a driver instance, then they typically are just fck and ick. Regards, Tony Thanks, Jean -- 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] ARM: OMAP: SmartReflex: pass device dependent data via platform data
Remove the device dependent settings (cpu_is_xxx(), IP fck etc.) from the driver code and pass them instead via the platform data. This allows a clean separation of the driver code and the platform code, as required by the move of the platform header files to include/linux/platform_data. The patch also includes a fix of the error handling path in omap_sr_probe to correctly de-allocate resources in case of problems. $SUBJECT requires this change. Jean Pihet (2): ARM: OMAP: SmartReflex: fix error path in init function ARM: OMAP: SmartReflex: pass device dependent data via platform data arch/arm/mach-omap2/sr_device.c | 13 ++ drivers/power/avs/smartreflex.c | 48 +++- include/linux/power/smartreflex.h | 14 +- 3 files changed, 40 insertions(+), 35 deletions(-) -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: SmartReflex: fix error path in init function
Fix the error handling path in omap_sr_probe to correctly
de-allocate resources in case of problems.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
drivers/power/avs/smartreflex.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 44efc6e..92f6728 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -928,7 +928,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
if (!sr_info-base) {
dev_err(pdev-dev, %s: ioremap fail\n, __func__);
ret = -ENOMEM;
- goto err_release_region;
+ goto err_free_name;
}
if (irq)
@@ -967,7 +967,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
dev_err(pdev-dev, %s: Unable to create debugfs directory\n,
__func__);
ret = PTR_ERR(sr_info-dbg_dir);
- goto err_free_name;
+ goto err_debugfs;
}
(void) debugfs_create_file(autocomp, S_IRUGO | S_IWUSR,
@@ -1011,11 +1011,11 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
err_debugfs:
debugfs_remove_recursive(sr_info-dbg_dir);
-err_free_name:
- kfree(sr_info-name);
err_iounmap:
list_del(sr_info-node);
iounmap(sr_info-base);
+err_free_name:
+ kfree(sr_info-name);
err_release_region:
release_mem_region(mem-start, resource_size(mem));
err_free_devinfo:
--
1.7.7.6
--
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] ARM: OMAP: SmartReflex: pass device dependent data via platform data
Remove the device dependent settings (cpu_is_xxx(), IP fck etc.)
from the driver code and pass them instead via the platform
data.
This allows a clean separation of the driver code and the platform
code, as required by the move of the platform header files to
include/linux/platform_data.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/sr_device.c | 13
drivers/power/avs/smartreflex.c | 40 ++--
include/linux/power/smartreflex.h | 14 +++-
3 files changed, 36 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index d033a65..2885a77 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -122,6 +122,19 @@ static int __init sr_dev_init(struct omap_hwmod *oh, void
*user)
sr_data-senn_mod = 0x1;
sr_data-senp_mod = 0x1;
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
+ sr_data-err_weight = OMAP3430_SR_ERRWEIGHT;
+ sr_data-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
+ sr_data-accum_data = OMAP3430_SR_ACCUMDATA;
+ if (!(strcmp(sr_data-name, smartreflex_mpu))) {
+ sr_data-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
+ sr_data-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
+ } else {
+ sr_data-senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
+ sr_data-senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
+ }
+ }
+
sr_data-voltdm = voltdm_lookup(sr_dev_attr-sensor_voltdm_name);
if (IS_ERR(sr_data-voltdm)) {
pr_err(%s: Unable to get voltage domain pointer for VDD %s\n,
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 92f6728..7c03c90 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -128,17 +128,16 @@ static irqreturn_t sr_interrupt(int irq, void *data)
static void sr_set_clk_length(struct omap_sr *sr)
{
+ char fck_name[16]; /* smartreflex.0 fits in 16 chars */
struct clk *sys_ck;
u32 sys_clk_speed;
- if (cpu_is_omap34xx())
- sys_ck = clk_get(NULL, sys_ck);
- else
- sys_ck = clk_get(NULL, sys_clkin_ck);
+ sprintf(fck_name, smartreflex.%d, sr-srid);
+ sys_ck = clk_get(NULL, fck_name);
if (IS_ERR(sys_ck)) {
- dev_err(sr-pdev-dev, %s: unable to get sys clk\n,
- __func__);
+ dev_err(sr-pdev-dev, %s: unable to get smartreflex fck
%s\n,
+ __func__, fck_name);
return;
}
@@ -168,28 +167,6 @@ static void sr_set_clk_length(struct omap_sr *sr)
}
}
-static void sr_set_regfields(struct omap_sr *sr)
-{
- /*
-* For time being these values are defined in smartreflex.h
-* and populated during init. May be they can be moved to board
-* file or pmic specific data structure. In that case these structure
-* fields will have to be populated using the pdata or pmic structure.
-*/
- if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- sr-err_weight = OMAP3430_SR_ERRWEIGHT;
- sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
- sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
- sr-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
- sr-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
- } else {
- sr-senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
- sr-senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
- }
- }
-}
-
static void sr_start_vddautocomp(struct omap_sr *sr)
{
if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
@@ -922,8 +899,14 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
sr_info-nvalue_count = pdata-nvalue_count;
sr_info-senn_mod = pdata-senn_mod;
sr_info-senp_mod = pdata-senp_mod;
+ sr_info-err_weight = pdata-err_weight;
+ sr_info-err_maxlimit = pdata-err_maxlimit;
+ sr_info-accum_data = pdata-accum_data;
+ sr_info-senn_avgweight = pdata-senn_avgweight;
+ sr_info-senp_avgweight = pdata-senp_avgweight;
sr_info-autocomp_active = false;
sr_info-ip_type = pdata-ip_type;
+
sr_info-base = ioremap(mem-start, resource_size(mem));
if (!sr_info-base) {
dev_err(pdev-dev, %s: ioremap fail\n, __func__);
@@ -935,7 +918,6 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
sr_info-irq = irq-start;
sr_set_clk_length(sr_info);
- sr_set_regfields(sr_info);
list_add(sr_info-node, sr_list);
diff --git a/include/linux/power/smartreflex.h
Re: [PATCH] ARM: OMAP: hwmod: align the SmartReflex fck names
Hi Paul, Kevin, On Thu, Sep 20, 2012 at 11:48 AM, Jean Pihet jean.pi...@newoldbits.com wrote: Rename the smartreflex fck names: - for consistency and better readability, - for use by the SmartReflex driver, through the hwmod .main_clk field. Signed-off-by: Jean Pihet j-pi...@ti.com Please discard this version. I have a new version ready after Tony's comments on the SmartReflex patches [1] [1] http://marc.info/?l=linux-omapm=134825443710207w=2 Re-submitting in a bit. --- arch/arm/mach-omap2/clock3xxx_data.c | 12 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 2 files changed, 10 insertions(+), 10 deletions(-) Regards, Jean -- 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] ARM: OMAP: hwmod: align the SmartReflex fck names
Rename the smartreflex fck names for consistency and better readability;
rename the clock aliases for use by the SmartReflex driver, with the
smartreflex.%d format.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/clock33xx_data.c | 12 ++--
arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
arch/arm/mach-omap2/clock44xx_data.c |6 +++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
4 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 25bbcc7..a328f12 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -548,16 +548,16 @@ static struct clk mcasp1_fck = {
.recalc = followparent_recalc,
};
-static struct clk smartreflex0_fck = {
- .name = smartreflex0_fck,
+static struct clk smartreflex_mpu_fck = {
+ .name = smartreflex_mpu_fck,
.clkdm_name = l4_wkup_clkdm,
.parent = sys_clkin_ck,
.ops= clkops_null,
.recalc = followparent_recalc,
};
-static struct clk smartreflex1_fck = {
- .name = smartreflex1_fck,
+static struct clk smartreflex_core_fck = {
+ .name = smartreflex_core_fck,
.clkdm_name = l4_wkup_clkdm,
.parent = sys_clkin_ck,
.ops= clkops_null,
@@ -1034,8 +1034,8 @@ static struct omap_clk am33xx_clks[] = {
CLK(davinci-mcasp.1, NULL, mcasp1_fck,CK_AM33XX),
CLK(NULL, mmc2_fck, mmc2_fck, CK_AM33XX),
CLK(NULL, mmu_fck, mmu_fck, CK_AM33XX),
- CLK(NULL, smartreflex0_fck, smartreflex0_fck,
CK_AM33XX),
- CLK(NULL, smartreflex1_fck, smartreflex1_fck,
CK_AM33XX),
+ CLK(NULL, smartreflex.0,smartreflex_mpu_fck,
CK_AM33XX),
+ CLK(NULL, smartreflex.1,smartreflex_core_fck,
CK_AM33XX),
CLK(NULL, gpt1_fck, timer1_fck,CK_AM33XX),
CLK(NULL, gpt2_fck, timer2_fck,CK_AM33XX),
CLK(NULL, gpt3_fck, timer3_fck,CK_AM33XX),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 83bed9a..a197cf2 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3050,8 +3050,8 @@ static struct clk traceclk_fck = {
/* SR clocks */
/* SmartReflex fclk (VDD1) */
-static struct clk sr1_fck = {
- .name = sr1_fck,
+static struct clk smartreflex_mpu_iva_fck = {
+ .name = smartreflex_mpu_iva_fck,
.ops= clkops_omap2_dflt_wait,
.parent = sys_ck,
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
@@ -3061,8 +3061,8 @@ static struct clk sr1_fck = {
};
/* SmartReflex fclk (VDD2) */
-static struct clk sr2_fck = {
- .name = sr2_fck,
+static struct clk smartreflex_core_fck = {
+ .name = smartreflex_core_fck,
.ops= clkops_omap2_dflt_wait,
.parent = sys_ck,
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
@@ -3447,8 +3447,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, atclk_fck,atclk_fck, CK_3XXX),
CLK(NULL, traceclk_src_fck, traceclk_src_fck, CK_3XXX),
CLK(NULL, traceclk_fck, traceclk_fck, CK_3XXX),
- CLK(NULL, sr1_fck, sr1_fck, CK_34XX | CK_36XX),
- CLK(NULL, sr2_fck, sr2_fck, CK_34XX | CK_36XX),
+ CLK(NULL, smartreflex.0,smartreflex_mpu_iva_fck,
CK_34XX | CK_36XX),
+ CLK(NULL, smartreflex.1,smartreflex_core_fck, CK_34XX
| CK_36XX),
CLK(NULL, sr_l4_ick,sr_l4_ick, CK_34XX | CK_36XX),
CLK(NULL, secure_32k_fck, secure_32k_fck, CK_3XXX),
CLK(NULL, gpt12_fck,gpt12_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..9cc1112 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3224,9 +3224,9 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, slimbus2_fclk_0, slimbus2_fclk_0,
CK_443X),
CLK(NULL, slimbus2_slimbus_clk, slimbus2_slimbus_clk,
CK_443X),
CLK(NULL, slimbus2_fck, slimbus2_fck,
CK_443X),
- CLK(NULL, smartreflex_core_fck, smartreflex_core_fck,
CK_443X),
- CLK(NULL, smartreflex_iva_fck, smartreflex_iva_fck,
CK_443X),
- CLK(NULL, smartreflex_mpu_fck, smartreflex_mpu_fck,
CK_443X),
+ CLK(NULL, smartreflex.0,smartreflex_core_fck,
CK_443X),
+
Re: [PATCH v3] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus
* Peter Ujfalusi peter.ujfal...@ti.com [120924 02:24]:
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it possible to add different set of additional devices to i2c1 bus on
OMAP4 boards.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Tony,
I have refreshed the patch on top of arm-soc/for-next branch. Would it be
possible to queue this patch via arm-soc so it will be in 3.7-rc1 already?
Originally this patch was sent for 3.6...
Yes sorry the platform code has been been badly ignored
lately.. Let's see if we can still get it in now that there's
-rc7 tagged.
Regards,
Tony
arch/arm/mach-omap2/board-4430sdp.c| 12 +--
arch/arm/mach-omap2/board-omap4panda.c | 12 +--
arch/arm/mach-omap2/twl-common.c | 37
++
arch/arm/mach-omap2/twl-common.h | 3 ++-
4 files changed, 33 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 6fe9079..7c1a662 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -545,6 +545,14 @@ static struct twl6040_platform_data twl6040_data = {
.audpwron_gpio = 127,
};
+static struct i2c_board_info __initdata sdp4430_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = OMAP44XX_IRQ_SYS_2N,
+ .platform_data = twl6040_data,
+ },
+};
+
static struct twl4030_platform_data sdp4430_twldata = {
/* Regulators */
.vusim = sdp4430_vusim,
@@ -578,8 +586,8 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, sdp4430_twldata,
- twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
+ omap4_pmic_init(twl6030, sdp4430_twldata, sdp4430_i2c_1_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_1_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 8ebb16c..eb7a9a8 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -264,6 +264,14 @@ static struct twl6040_platform_data twl6040_data = {
.audpwron_gpio = 127,
};
+static struct i2c_board_info __initdata panda_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = OMAP44XX_IRQ_SYS_2N,
+ .platform_data = twl6040_data,
+ },
+};
+
/* Panda board uses the common PMIC configuration */
static struct twl4030_platform_data omap4_panda_twldata;
@@ -291,8 +299,8 @@ static int __init omap4_panda_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, omap4_panda_twldata,
- twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
+ omap4_pmic_init(twl6030, omap4_panda_twldata, panda_i2c_1_boardinfo,
+ ARRAY_SIZE(panda_i2c_1_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
/*
* Bus 3 is attached to the DVI port where devices like the pico DLP
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 040f480..e279732 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -40,16 +40,6 @@ static struct i2c_board_info __initdata
pmic_i2c_board_info = {
.flags = I2C_CLIENT_WAKE,
};
-static struct i2c_board_info __initdata omap4_i2c1_board_info[] = {
- {
- .addr = 0x48,
- .flags = I2C_CLIENT_WAKE,
- },
- {
- I2C_BOARD_INFO(twl6040, 0x4b),
- },
-};
-
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static int twl_set_voltage(void *data, int target_uV)
{
@@ -79,30 +69,25 @@ void __init omap_pmic_init(int bus, u32 clkrate,
void __init omap4_pmic_init(const char *pmic_type,
struct twl4030_platform_data *pmic_data,
- struct twl6040_platform_data *twl6040_data, int twl6040_irq)
+ struct i2c_board_info *devices, int nr_devices)
{
/* PMIC part*/
omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
- strncpy(omap4_i2c1_board_info[0].type, pmic_type,
- sizeof(omap4_i2c1_board_info[0].type));
-
Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
Hi Paul, On 09/20/2012 12:13 PM, Paul Walmsley wrote: On Wed, 19 Sep 2012, Paul Walmsley wrote: On Mon, 10 Sep 2012, Jon Hunter wrote: To enable PMU with runtime PM support on OMAP3 devices we need to be able to dynamically enable and disable the debug sub-system at runtime. By adding HWMOD data for the debug sub-system for OMAP3, we can build the PMU device using the debug sub-system HWMOD and control this power domain using runtime PM. Reviewed-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com Isn't this patch missing MPU address ranges? Looking at the OMAP4 TRM Table 2-2 L3_EMU Memory Space Mapping it should cover 0x5400-0x541f? Looks like Jon is out of the office at the moment. So this one has been updated locally to add the _OMAP3_ address space from the TRM (my earlier message referred incorrectly to the OMAP4 address space). Updated patch below. Thanks for catching that. Was not needed for PMU use-case but I should have added that for other use-cases. Cheers Jon -- 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 V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint
Hi Paul, On 09/20/2012 12:14 PM, Paul Walmsley wrote: Hi On Mon, 10 Sep 2012, Jon Hunter wrote: When CPU-idle is enabled, the MPU sub-system will transition to low power states during idle periods. If the PMU is active and the MPU sub-system transitions to a low power state, such as retention, then the PMU context will be lost and PMU events will stop. To prevent this from happening add a QoS constraint whenever PMU is active to prevent the MPU sub-system from transitioning to a low power state. By default the PMU QoS constraint is set to -1 so it will not prevent any low power states and when the PMU is enabled, it is set to 0, so that only C-state C0 is allowed. I plan to re-visit this and relax the constraint to allow some low power states, but for now I just wish to ensure PMU is working. Cc: Ming Lei ming@canonical.com Cc: Will Deacon will.dea...@arm.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com This one looks like 3.7-rc material, due to the dependency on Will's PMU runtime PM adaptation series, which is unfortunately not yet in the stable merge base that I need to use to send these upstream. Jon, care to update and re-send this one after Linus merges the other PMU patches? Yes no problem. Will send out during the 3.7-rc. Cheers Jon -- 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/1] usb: Include generic_interrupt for OMAP2_PLUS
* Felipe Balbi ba...@ti.com [120924 06:08]: Hi, On Mon, Sep 24, 2012 at 03:54:22PM +0300, Philippe De Swert wrote: Hi, On 24/09/2012, Felipe Balbi ba...@ti.com wrote: SoB's mail doesn't From mail. Well still in the progress of migrating of my personal to work laptop. Since the patch does not seem correct the replacement will have matching addresses. /*-*/ #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \ -defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) +defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \ +defined(CONFIG_ARCH_OMAP2PLUS) Weird, how can you build OMAP2PLUS without SOC_OMAP ?? It seems entirely possible. I quickly tried to look if it got defined somewhere and it does not seem to be set anywhere. That is why I got the impression it was replaced by CONFIG_ARCH_OMAP2PLUS. I'll dig deeper to find out why SOC_OMAP is not set if it should be. From the .config I got (used menuconfig) # # TI OMAP2/3/4 Specific Features # CONFIG_ARCH_OMAP2PLUS_TYPICAL=y CONFIG_SOC_HAS_OMAP2_SDRC=y # CONFIG_ARCH_OMAP2 is not set CONFIG_ARCH_OMAP3=y # CONFIG_ARCH_OMAP4 is not set # CONFIG_SOC_OMAP5 is not set # CONFIG_SOC_OMAP3430 is not set # CONFIG_SOC_TI81XX is not set # CONFIG_SOC_AM33XX is not set CONFIG_OMAP_PACKAGE_CBB=y Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not get set (while it is not a 3430 but a 3630 I am using). Maybe CONFIG_ARCH_OMAP3 would have been a better choice then? that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all OMAP3 boards ? And another question: why don't we have a matching SOC_OMAP3530, SOC_OMAP3630 and so on ? ARCH_OMAP3 will probably eventually just disappear and be replaced with ARCH_OMAP2PLUS + SOC_. But there's no need to do it right now as most of that should be internal to arch/arm/mach-omap2 anyways. I would just set the driver to depend on ARCH_OMAP2PLUS, and rely on the platform_data and DT to do something if specified. That means that on 2420 musb should not probe unless tusb6010 in specified. It seems that things like fifo_mode and generic_interrupt can all be set during the probe based on the platform_data or DT passed information? 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] ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
* Jean Pihet jean.pi...@newoldbits.com [120920 09:09]:
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
class of PM QoS. The resulting MPU constraints are used by cpuidle to
decide the next power state of the MPU subsystem.
The I2C device latency timing is derived from the FIFO size and the
clock speed and so is applicable to all OMAP SoCs.
Signed-off-by: Jean Pihet j-pi...@ti.com
Good to see this, probably should have an ack from
Kevin Hilman for this. Other than that it's best to
merge this via the i2c tree:
Acked-by: Tony Lindgren t...@atomide.com
---
Rebased on git://git.pengutronix.de/git/wsa/linux.git, branch
i2c-embedded/for-next
---
arch/arm/plat-omap/i2c.c | 21 -
drivers/i2c/busses/i2c-omap.c | 32 ++--
include/linux/i2c-omap.h |1 -
3 files changed, 18 insertions(+), 36 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 40bc06a..d29a2cc 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,7 +26,6 @@
#include linux/kernel.h
#include linux/platform_device.h
#include linux/i2c.h
-#include linux/i2c-omap.h
#include linux/slab.h
#include linux/err.h
#include linux/clk.h
@@ -34,7 +33,6 @@
#include mach/irqs.h
#include plat/mux.h
#include plat/i2c.h
-#include plat/omap-pm.h
#include plat/omap_device.h
#define OMAP_I2C_SIZE0x3f
@@ -130,16 +128,6 @@ static inline int omap1_i2c_add_bus(int bus_id)
#ifdef CONFIG_ARCH_OMAP2PLUS
-/*
- * XXX This function is a temporary compatibility wrapper - only
- * needed until the I2C driver can be converted to call
- * omap_pm_set_max_dev_wakeup_lat() and handle a return code.
- */
-static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
-{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
-}
-
static inline int omap2_i2c_add_bus(int bus_id)
{
int l;
@@ -171,15 +159,6 @@ static inline int omap2_i2c_add_bus(int bus_id)
dev_attr = (struct omap_i2c_dev_attr *)oh-dev_attr;
pdata-flags = dev_attr-flags;
- /*
- * When waiting for completion of a i2c transfer, we need to
- * set a wake up latency constraint for the MPU. This is to
- * ensure quick enough wakeup from idle, when transfer
- * completes.
- * Only omap3 has support for constraints
- */
- if (cpu_is_omap34xx())
- pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0b02543..db31eae 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include linux/pm_qos.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -186,9 +187,8 @@ struct omap_i2c_dev {
int reg_shift; /* bit shift for I2C register
addresses */
struct completion cmd_complete;
struct resource *ioarea;
- u32 latency;/* maximum mpu wkup latency */
- void(*set_mpu_wkup_lat)(struct device *dev,
- long latency);
+ u32 latency;/* maximum MPU wkup latency */
+ struct pm_qos_request pm_qos_request;
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -494,9 +494,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev
*dev, u8 size, bool is_rx)
dev-b_hw = 1; /* Enable hardware fixes */
/* calculate wakeup latency constraint for MPU */
- if (dev-set_mpu_wkup_lat != NULL)
- dev-latency = (100 * dev-threshold) /
- (1000 * dev-speed / 8);
+ dev-latency = (100 * dev-threshold) / (1000 * dev-speed / 8);
}
/*
@@ -631,8 +629,16 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (r 0)
goto out;
- if (dev-set_mpu_wkup_lat != NULL)
- dev-set_mpu_wkup_lat(dev-dev, dev-latency);
+ /*
+ * When waiting for completion of a i2c transfer, we need to
+ * set a wake up latency constraint for the MPU. This is to
+ * ensure quick enough wakeup from idle, when transfer
+ * completes.
+ */
+ if (dev-latency)
+ pm_qos_add_request(dev-pm_qos_request,
+
Re: tidspbridge build fails
Joni Lapilainen joni.lapilainen at gmail.com writes: Building tidspbridge fails: CC [M] drivers/staging/tidspbridge/core/tiomap3430.o drivers/staging/tidspbridge/core/tiomap3430.c: In function 'bridge_brd_start': drivers/staging/tidspbridge/core/tiomap3430.c:421:25: error: 'OMAP343X_CTRL_BASE' undeclared (first use in this function) drivers/staging/tidspbridge/core/tiomap3430.c:421:25: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This definition has moved to : arch/arm/mach-omap2/omap34xx.h I don't know if we can include directly this file in tiomap3430.c (I'm newbie) However there is still the symbole OMAP34XX_WDT3_BASE in 'drivers/staging/tidspbridge/core/wdt.c' that is not resolved. -- 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: tidspbridge build fails
* Selso LIBERADO s...@cioinfoindus.fr [120924 09:46]: Joni Lapilainen joni.lapilainen at gmail.com writes: Building tidspbridge fails: CC [M] drivers/staging/tidspbridge/core/tiomap3430.o drivers/staging/tidspbridge/core/tiomap3430.c: In function 'bridge_brd_start': drivers/staging/tidspbridge/core/tiomap3430.c:421:25: error: 'OMAP343X_CTRL_BASE' undeclared (first use in this function) drivers/staging/tidspbridge/core/tiomap3430.c:421:25: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This definition has moved to : arch/arm/mach-omap2/omap34xx.h I don't know if we can include directly this file in tiomap3430.c (I'm newbie) No we should not, that should be private to arch/arm/mach-omap2. However there is still the symbole OMAP34XX_WDT3_BASE in 'drivers/staging/tidspbridge/core/wdt.c' that is not resolved. OK it's probably best to define that locally there or in some drivers/staging/tidispbridge header whatever the code is doing with it.. Care to do a patch for it? 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] ARM: OMAP2+: serial: Change MAX_HSUART_PORTS to 6
* AnilKumar Ch anilku...@ti.com [120620 01:54]: Extends the maximum number of UART ports to 6 from 4 because AM335X device have six UART ports. Sorry for the delay, looks like this one is still valid. I'll apply this. Regards, Tony Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/plat-omap/include/plat/omap-serial.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index 1a52725..71eca9c 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -54,7 +54,7 @@ #define OMAP_UART_DMA_CH_FREE-1 -#define OMAP_MAX_HSUART_PORTS4 +#define OMAP_MAX_HSUART_PORTS6 #define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA -- 1.7.9.5 -- 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: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
* yegorsli...@googlemail.com yegorsli...@googlemail.com [120703 07:26]: From: Yegor Yefremov yegorsli...@googlemail.com FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB of consistent DMA memory (da8xx frame buffer driver). Sorry for the delay on this one, looks like this one is still valid. I'll apply it. Regards, Tony Signed-off-by: Dejan Gacnik dejan.gac...@gmail.com Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- arch/arm/Kconfig |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e876819..ff14c1e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1725,8 +1725,9 @@ config HW_PERF_EVENTS source mm/Kconfig config FORCE_MAX_ZONEORDER - int Maximum zone order if ARCH_SHMOBILE - range 11 64 if ARCH_SHMOBILE + int Maximum zone order + depends on ARCH_SHMOBILE || SOC_AM33XX + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX default 9 if SA default 11 help -- 1.7.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 -- 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 v3] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus
* Tony Lindgren t...@atomide.com [120924 08:44]:
* Peter Ujfalusi peter.ujfal...@ti.com [120924 02:24]:
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it possible to add different set of additional devices to i2c1 bus on
OMAP4 boards.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Tony,
I have refreshed the patch on top of arm-soc/for-next branch. Would it be
possible to queue this patch via arm-soc so it will be in 3.7-rc1 already?
Originally this patch was sent for 3.6...
Yes sorry the platform code has been been badly ignored
lately.. Let's see if we can still get it in now that there's
-rc7 tagged.
I've updated this for the sparse IRQ changes that remove irqs.h.
Updated patch below.
Tony
From: Peter Ujfalusi peter.ujfal...@ti.com
Date: Mon, 24 Sep 2012 12:24:48 +0300
Subject: [PATCH] ARM: OMAP4: twl-common: Support for additional devices on
i2c1 bus
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it possible to add different set of additional devices to i2c1 bus on
OMAP4 boards.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
[t...@atomide.com: updated for removal of irqs.h]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index e82098f..749ce96 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -545,6 +545,14 @@ static struct twl6040_platform_data twl6040_data = {
.audpwron_gpio = 127,
};
+static struct i2c_board_info __initdata sdp4430_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = 119 + OMAP44XX_IRQ_GIC_START,
+ .platform_data = twl6040_data,
+ },
+};
+
static struct twl4030_platform_data sdp4430_twldata = {
/* Regulators */
.vusim = sdp4430_vusim,
@@ -578,8 +586,8 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, sdp4430_twldata,
- twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
+ omap4_pmic_init(twl6030, sdp4430_twldata, sdp4430_i2c_1_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_1_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 45fe2d3..7b592d3 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -264,6 +264,14 @@ static struct twl6040_platform_data twl6040_data = {
.audpwron_gpio = 127,
};
+static struct i2c_board_info __initdata panda_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = 119 + OMAP44XX_IRQ_GIC_START,
+ .platform_data = twl6040_data,
+ },
+};
+
/* Panda board uses the common PMIC configuration */
static struct twl4030_platform_data omap4_panda_twldata;
@@ -291,8 +299,8 @@ static int __init omap4_panda_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, omap4_panda_twldata,
- twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
+ omap4_pmic_init(twl6030, omap4_panda_twldata, panda_i2c_1_boardinfo,
+ ARRAY_SIZE(panda_i2c_1_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
/*
* Bus 3 is attached to the DVI port where devices like the pico DLP
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 99be94e..af93acc 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -40,16 +40,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info
= {
.flags = I2C_CLIENT_WAKE,
};
-static struct i2c_board_info __initdata omap4_i2c1_board_info[] = {
- {
- .addr = 0x48,
- .flags = I2C_CLIENT_WAKE,
- },
- {
- I2C_BOARD_INFO(twl6040, 0x4b),
- },
-};
-
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static int twl_set_voltage(void *data, int target_uV)
{
@@ -79,30 +69,25 @@ void __init omap_pmic_init(int bus, u32 clkrate,
void __init
[PATCH] ARM: am33xx: clk: Update clkdev table to add mcasp alias
After Rajendra's common-clock preparation series,
commit (a1978ef4da1 - ARM: omap: hwmod: get rid of
all omap_clk_get_by_name usage) the clkdev table need to
update with an entry for clocks used by hwmod to have
clock name same as the alias.
Without this, the clk_get() in omap_hwmod would fail.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/clock33xx_data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b87b88c..114ab4b 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1035,6 +1035,8 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, pruss_ocp_gclk, pruss_ocp_gclk,
CK_AM33XX),
CLK(davinci-mcasp.0, NULL, mcasp0_fck,CK_AM33XX),
CLK(davinci-mcasp.1, NULL, mcasp1_fck,CK_AM33XX),
+ CLK(NULL, mcasp0_fck, mcasp0_fck,CK_AM33XX),
+ CLK(NULL, mcasp1_fck, mcasp1_fck,CK_AM33XX),
CLK(NULL, mmc2_fck, mmc2_fck, CK_AM33XX),
CLK(NULL, mmu_fck, mmu_fck, CK_AM33XX),
CLK(NULL, smartreflex0_fck, smartreflex0_fck,
CK_AM33XX),
--
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] ARM: am33xx: clk: Update clkdev table to add mcasp alias
On Mon, 24 Sep 2012, Vaibhav Hiremath wrote: After Rajendra's common-clock preparation series, commit (a1978ef4da1 - ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage) the clkdev table need to update with an entry for clocks used by hwmod to have clock name same as the alias. Without this, the clk_get() in omap_hwmod would fail. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Tony, if you want to take this, it's Acked-by: Paul Walmsley p...@pwsan.com otherwise we'll wait for -rc1. - 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] ARM: OMAP2+: Add am335x evm and bone targets to common Makefile
This adds am335x-evm and am335x-bone dtb targets to 'make dtbs', just like other platforms. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- Changes from V1: - Move target to common Makefile instead of the per-platform file. arch/arm/boot/dts/Makefile |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index d4ad2df..6f2dae8 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -75,7 +75,9 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ omap4-pandaES.dtb \ omap4-var_som.dtb \ omap4-sdp.dtb \ - omap5-evm.dtb + omap5-evm.dtb \ + am335x-evm.dtb \ + am335x-bone.dtb dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb dtb-$(CONFIG_ARCH_U8500) += snowball.dtb dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \ -- 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] ARM: am33xx: clk: Update clkdev table to add mcasp alias
* Paul Walmsley p...@pwsan.com [120924 11:34]: On Mon, 24 Sep 2012, Vaibhav Hiremath wrote: After Rajendra's common-clock preparation series, commit (a1978ef4da1 - ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage) the clkdev table need to update with an entry for clocks used by hwmod to have clock name same as the alias. Without this, the clk_get() in omap_hwmod would fail. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Tony, if you want to take this, it's Acked-by: Paul Walmsley p...@pwsan.com otherwise we'll wait for -rc1. Please just go ahead and queue it as a fix. We should get a fixes branch in before -rc1 is tagged so -rc1 works for us. 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: tidspbridge build fails
Tony Lindgren tony at atomide.com writes: ... OK. I sent it. -- 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: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
On Mon, Sep 24, 2012 at 7:18 PM, Tony Lindgren t...@atomide.com wrote: * yegorsli...@googlemail.com yegorsli...@googlemail.com [120703 07:26]: From: Yegor Yefremov yegorsli...@googlemail.com FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB of consistent DMA memory (da8xx frame buffer driver). Sorry for the delay on this one, looks like this one is still valid. I'll apply it. Thanks. Yegor Signed-off-by: Dejan Gacnik dejan.gac...@gmail.com Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- arch/arm/Kconfig |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e876819..ff14c1e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1725,8 +1725,9 @@ config HW_PERF_EVENTS source mm/Kconfig config FORCE_MAX_ZONEORDER - int Maximum zone order if ARCH_SHMOBILE - range 11 64 if ARCH_SHMOBILE + int Maximum zone order + depends on ARCH_SHMOBILE || SOC_AM33XX + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX default 9 if SA default 11 help -- 1.7.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 -- 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
OMAP baseline test results for v3.6-rc7
Here are some basic OMAP boot and power management test results for v3.6-rc6: http://www.pwsan.com/omap/testlogs/test_v3.6-rc6/20120918101040/ Some observations: Boot tests: * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs - Probably due to the use of NFS root; there are likely some Kconfig, board file, and PM issues with EMAC PM tests: * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown * 4430ES2 Panda: UART corruption during long transmit buffers - Presumably due to either a missing hardware workaround or a bug in the OMAP serial driver Other: * RCU stall messages appear if boards are booted into a minimal userspace and left to sit for a few minutes - Fixed by http://marc.info/?l=linux-arm-kernelm=134835120600590w=2 Changes from v3.6-rc6 (test 20120918101040): (see http://www.pwsan.com/omap/testlogs/test_v3.6-rc6/20120918101040/ ) - Added comments about RCU stalls, appearing since at least v3.6-rc3 - Updated CM-T3517 USB OTG (really IPSS) comment object size (delta in bytes from test_v3.6-rc6 (5698bd757d55b1bb87edd1a9744ab09c142abfc2)): textdata bss total kernel -328 +72 0-256 2430_testconfig -16 +16 0 0 5912osk_testconfig -376 +72 0-304 am33xx_testconfig +64 +32 0 +96 n800_b_testconfig +80 +64 0+144 n800_multi_omap2xxx +80 +32 0+112 n800_testconfig +72 +80 0+152 omap1510_defconfig +40 +16 0 +56 omap1_defconfig +80 +64 0+144 omap2_4_testconfig -376 +40 0-336 omap2plus_defconfig -376 +72 0-304 omap2plus_defconfig_cpupm +20 +72 0 +92 omap2plus_no_pm +20 +8 0 +28 omap3_4_testconfig +140 +72 0+212 omap3_testconfig +20 +40 0 +60 omap4_testconfig -40 +72 0 +32 rmk_omap3430_ldp_oldconfig -200 +8 0-192 rmk_omap4430_sdp_oldconfig - 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 V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
On 09/20/2012 11:59 AM, Paul Walmsley wrote: Hi On Mon, 10 Sep 2012, Jon Hunter wrote: From: Ming Lei ming@canonical.com For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to work on OMAP4430. The idea is from Woodruff Richard in the disscussion about Oprofile on Pandaboard / Omap4 on pandabo...@googlegroups.com. Ming's original patch was called arm: omap4: support pmu [1] and has been renamed and modified by Jon Hunter. There main differences from the original patch are ... 1. Instead of only configuring the CTI interrupt once during boot, the interrupts are configured everytime the the PMU is used. The reason for this is because during power transitions the CTI logic state will be lost and so we will need to configure the interrupts everytime they are used. This is accomplished by using the PM runtime callbacks which will be called whenever the PMU is used. 2. Assign the PMU events to different cross triggering channels. This prevents a single PMU event generating interrupts to both CPUs and hence can cause spurious interrupts to occur. Reported by Ming [2]. [1] http://marc.info/?l=linux-arm-kernelm=132227620816504w=2 [2] http://permalink.gmane.org/gmane.linux.linaro.devel/10532 Spent some time with this one here. At this point I don't think I can queue it. It's got hardcoded IRQ numbers and address information for the CTI, and mixes the CTI and PMU programming. A few months ago we might have gotten away with this, but now it seems best to do this one cleanly. Probably the CTI control should be moved off into mach-omap2/omap4-cti.c or somewhere into drivers/ if possible. So let's revisit this for 3.8. Ok, no problem, I can't say I was thrilled with the implementation so probably best to re-think some more. How about adding the cross-trigger interface as a hwmod for omap4 to store the base address and interrupt number? Cheers Jon -- 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] ARM: OMAP: hwmod/PMU/PRCM patches for 3.7
On Sun, 23 Sep 2012, Tony Lindgren wrote: OK thanks, that should work. The nasty merge conflicts seem to have been caused by mostly commit df3d17e0 (ARM: pmu: remove arm_pmu_type enumeration) that easily causes a nasty mis-merge of omap_init_pmu() and omap_init_rng() without removing omap_init_pmu() which your patches move to a different location. OK thanks. From now on, will make sure that merge window pull requests are based on any upstream cleanup series that affect the same code. - 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 v4 1/2] backlight: Add TPS65217 WLED driver
The TPS65217 chip contains a boost converter and current sinks which can be
used to drive LEDs for use as backlights. Expose this functionality via the
backlight API.
Tested on an AM335x based custom board with a single WLED string, using
different values for ISEL and FDIM (though it would be hard to tell the
difference except for the value in WLEDCTRL1). Both instantiation through the
device tree and by passing platform data have been tested. Testing has been
done with an Androidized 3.2 kernel from the rowboat project. Koen Kooi
reported the driver to be working on a Beaglebone board with LCD3 cape
This patch is based on the mfd branch (20120924)
Changes since v3:
* split in two patches, one for the driver another for adding the mfd
subdevice
* renamed variable on to is_enabled and changed type to boolean
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
drivers/video/backlight/Kconfig |7 +
drivers/video/backlight/Makefile |1 +
drivers/video/backlight/tps65217_bl.c | 352 +
include/linux/mfd/tps65217.h | 18 ++
4 files changed, 378 insertions(+)
create mode 100644 drivers/video/backlight/tps65217_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index cf28276..63cee2e 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -373,6 +373,13 @@ config BACKLIGHT_PANDORA
If you have a Pandora console, say Y to enable the
backlight driver.
+config BACKLIGHT_TPS65217
+ tristate TPS65217 Backlight
+ depends on BACKLIGHT_CLASS_DEVICE MFD_TPS65217
+ help
+ If you have a Texas Instruments TPS65217 say Y to enable the
+ backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index a2ac9cf..00223a6 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -43,3 +43,4 @@ obj-$(CONFIG_BACKLIGHT_88PM860X) += 88pm860x_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
obj-$(CONFIG_BACKLIGHT_AAT2870) += aat2870_bl.o
obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
+obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
diff --git a/drivers/video/backlight/tps65217_bl.c
b/drivers/video/backlight/tps65217_bl.c
new file mode 100644
index 000..29aae58
--- /dev/null
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -0,0 +1,352 @@
+/*
+ * tps65217_bl.c
+ *
+ * TPS65217 backlight driver
+ *
+ * Copyright (C) 2012 Matthias Kaehlcke
+ * Author: Matthias Kaehlcke matth...@kaehlcke.net
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/backlight.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/mfd/tps65217.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+struct tps65217_bl {
+ struct tps65217 *tps;
+ struct device *dev;
+ struct backlight_device *bl;
+ bool is_enabled;
+};
+
+static int tps65217_bl_enable(struct tps65217_bl *tps65217_bl)
+{
+ int rc;
+
+ rc = tps65217_set_bits(tps65217_bl-tps, TPS65217_REG_WLEDCTRL1,
+ TPS65217_WLEDCTRL1_ISINK_ENABLE,
+ TPS65217_WLEDCTRL1_ISINK_ENABLE, TPS65217_PROTECT_NONE);
+ if (rc) {
+ dev_err(tps65217_bl-dev,
+ failed to enable backlight: %d\n, rc);
+ return rc;
+ }
+
+ tps65217_bl-is_enabled = true;
+
+ dev_dbg(tps65217_bl-dev, backlight enabled\n);
+
+ return 0;
+}
+
+static int tps65217_bl_disable(struct tps65217_bl *tps65217_bl)
+{
+ int rc;
+
+ rc = tps65217_clear_bits(tps65217_bl-tps,
+ TPS65217_REG_WLEDCTRL1,
+ TPS65217_WLEDCTRL1_ISINK_ENABLE,
+ TPS65217_PROTECT_NONE);
+ if (rc) {
+ dev_err(tps65217_bl-dev,
+ failed to disable backlight: %d\n, rc);
+ return rc;
+ }
+
+ tps65217_bl-is_enabled = false;
+
+ dev_dbg(tps65217_bl-dev, backlight disabled\n);
+
+ return 0;
+}
+
+static int tps65217_bl_update_status(struct backlight_device *bl)
+{
+ struct tps65217_bl *tps65217_bl = bl_get_data(bl);
+ int rc;
+ int brightness = bl-props.brightness;
+
+ if (bl-props.state BL_CORE_SUSPENDED)
+ brightness = 0;
+
+ if ((bl-props.power != FB_BLANK_UNBLANK
[PATCH v4 2/2] mfd: Add backlight as subdevice to the tps65217
mfd: Add backlight as subdevice to the tps65217
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
drivers/mfd/tps65217.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index a95e942..3fb32e6 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -34,6 +34,9 @@ static struct mfd_cell tps65217s[] = {
{
.name = tps65217-pmic,
},
+ {
+ .name = tps65217-bl,
+ },
};
/**
--
1.7.10
--
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: am33xx: clk: Update clkdev table to add mcasp alias
On Mon, 24 Sep 2012, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [120924 11:34]: On Mon, 24 Sep 2012, Vaibhav Hiremath wrote: After Rajendra's common-clock preparation series, commit (a1978ef4da1 - ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage) the clkdev table need to update with an entry for clocks used by hwmod to have clock name same as the alias. Without this, the clk_get() in omap_hwmod would fail. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Tony, if you want to take this, it's Acked-by: Paul Walmsley p...@pwsan.com otherwise we'll wait for -rc1. Please just go ahead and queue it as a fix. We should get a fixes branch in before -rc1 is tagged so -rc1 works for us. OK, will send a pull request once devel-late goes upstream. - 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: tidspbridge build fails
* Selso LIBERADO s...@cioinfoindus.fr [120924 11:58]: Tony Lindgren tony at atomide.com writes: ... OK. I sent it. OK thanks! 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
[GIT PULL 1/3] omap clock late patches for v3.7 merge window
The following changes since commit 1e2ee2a60df5c3ab74dd1c9155fb01b5bc6f807d: Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7 (2012-09-23 17:16:04 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-devel-late-for-v3.7 for you to fetch changes up to 9cd68fa707cf6372f33eb51a5719dd7626efe5f6: Merge tag 'omap-devel-b-c-2-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-late (2012-09-23 19:31:35 -0700) These changes take us a step closer to merging the common clock framework for omap but unfortunately these patches were not ready for merging earlier. See also the notes below on the dependencies these patches have, they are based on a merge of sereral branches already merged. From Paul Walmsley p...@pwsan.com: OMAP patches intended for the 3.7 merge window: - Runtime PM conversions for the GPMC and RNG IP blocks - Preparation patches for the OMAP common clock framework conversion - clkdev alias additions required by other drivers - Performance Monitoring Unit (PMU) support for OMAP2, 3, and non-4430 OMAP4 - OMAP hwmod code and data improvements - Preparation patches for the IOMMU runtime PM conversion - Preparation patches for OMAP4 full-chip retention support Based on a merge of v3.6-rc6, the omap-cleanup-b-for-3.7 tag (7852ec0536ca39cefffc6301dc77f8ae55592926),the cleanup-fixes-for-v3.7 tag (de6ca33a96a6bf61fcb91d3d399703e19ead9d1e), and the omap-devel-am33xx-for-v3.7 tag (11964f53eb4d9ce59a058bed9cfcb1ced878), due to dependencies. Afzal Mohammed (3): ARM: OMAP2/3: hwmod data: add gpmc ARM: OMAP2+: gpmc: Adapt to HWMOD ARM: OMAP2+: gpmc: minimal driver support AnilKumar Ch (1): ARM: OMAP2+: AM33XX: clock data: Add clkdev alias for cpu0 Benoit Cousson (1): ARM: OMAP4: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries Igor Grinberg (1): ARM: OMAP: hwmod code: remove unused hwmod function prototypes Jon Hunter (7): ARM: OMAP2420: Cosmetic fix for timer clock aliases ARM: OMAP4: Add timer clock aliases for device-tree ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP ARM: OMAP3: hwmod data: Add debugss HWMOD data ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD ARM: OMAP2+: PMU: Add runtime PM support ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70 Kishon Vijay Abraham I (1): ARM: OMAP4: hwmod data: make *phy_48m* as the main_clk of ocp2scp Michael Jones (1): ARM: OMAP3: clock data: remove obsolete comment Mike Turquette (1): ARM: OMAP4: cm: add bitfield width values Ming Lei (1): ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD Omar Ramirez Luna (5): ARM: OMAP2+: omap_device: expose hwmod assert/deassert to omap devices ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled ARM: OMAP: hwmod: revise deassert sequence ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp Paul Walmsley (16): Merge tag 'cleanup-fixes-for-v3.7' into test_v3.6-rc6_cff3.7_odaf3.7 Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_cff3.7_odaf3.7 ARM: OMAP3: clock data: Add the USB TLL clocks device name ARM: OMAP2+: clock data: add some aliases for use by CPUFreq only SPI: OMAP: remove unnecessary includes of plat/clock.h Merge branch 'clock_devel_3.7' into hwmod_prcm_clock_a_3.7 ARM: OMAP4+: hwmod code: remove clkdm requirement in _omap4_wait_target_*() ARM: OMAP2+: hwmod code: convert missing clockdomain warnings to debug messages ARM: OMAP4: hwmod data: add missing HWMOD_NO_IDLEST flags to some PRCM IP blocks ARM: OMAP3: hwmod data: add mmu data for iva and isp ARM: OMAP2xxx: hwmod/CM: add RNG integration data hwrng: OMAP: store per-device data in per-device variables, not file statics hwrng: OMAP: convert to use runtime PM ARM: OMAP: split OMAP1, OMAP2+ RNG device registration hwrng: OMAP: remove SoC restrictions from driver registration ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems Rajendra Nayak (3): ARM: omap: clk: add clk_prepare and clk_unprepare ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage ARM: OMAP2+: clock: Remove all direct dereferencing of struct clk Tero Kristo (4): ARM: OMAP4: powerdomain: add support for reading prev logic and mem states ARM: OMAP4: hwmod data: add support for lostcontext_mask ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status ARM: OMAP3: hwmod data: add sad2d hwmod Tony Lindgren (1): Merge tag
Re: [GIT PULL 1/3] omap clock late patches for v3.7 merge window
* Tony Lindgren t...@atomide.com [120924 14:26]: These changes take us a step closer to merging the common clock framework for omap but unfortunately these patches were not ready for merging earlier. See also the notes below on the dependencies these patches have, they are based on a merge of sereral branches already merged. I am aware these three pull requests all are very late. Just let me know if you don't want to take them at this point and I'll resend updated pull reqs after -rc1 or so. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Fix PMU interrupt definitions
Commit 7d7e1eb (ARM: OMAP2+: Prepare for irqs.h removal) and commit ec2c082
(ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ) updated the way
interrupts for OMAP2/3 devices are defined in the HWMOD data structures to
being an index plus a fixed offset (defined by OMAP_INTC_START). The definition
of the PMU interrupts on OMAP2/3 devices is missing the OMAP_INTC_START offset
and so this is causing the allocation of PMU interrupts to fail on OMAP2/3
devices. So add the offset to fix this.
This is patch is based upon the Tony's master branch for OMAP.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 35dcdb6..bd9220e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -219,7 +219,7 @@ struct omap_hwmod omap2xxx_l4_wkup_hwmod = {
/* MPU */
static struct omap_hwmod_irq_info omap2xxx_mpu_irqs[] = {
- { .name = pmu, .irq = 3 },
+ { .name = pmu, .irq = 3 + OMAP_INTC_START },
{ .irq = -1 }
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 2857772..b4028fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -94,7 +94,7 @@ static struct omap_hwmod omap3xxx_l4_sec_hwmod = {
/* MPU */
static struct omap_hwmod_irq_info omap3xxx_mpu_irqs[] = {
- { .name = pmu, .irq = 3 },
+ { .name = pmu, .irq = 3 + OMAP_INTC_START },
{ .irq = -1 }
};
--
1.7.9.5
--
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: OMAP2+: Fix PMU interrupt definitions
On Mon, 24 Sep 2012, Jon Hunter wrote: Commit 7d7e1eb (ARM: OMAP2+: Prepare for irqs.h removal) and commit ec2c082 (ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ) updated the way interrupts for OMAP2/3 devices are defined in the HWMOD data structures to being an index plus a fixed offset (defined by OMAP_INTC_START). The definition of the PMU interrupts on OMAP2/3 devices is missing the OMAP_INTC_START offset and so this is causing the allocation of PMU interrupts to fail on OMAP2/3 devices. So add the offset to fix this. This is patch is based upon the Tony's master branch for OMAP. Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks, looks like I missed that when the patch was rebased. Queued into devel-late-fixes. - 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 V3 0/8] ARM: OMAP4: Add PMU Support
Hi Paul, On 09/20/2012 12:17 PM, Paul Walmsley wrote: Hi Jon, Will, Ming, et al., Have queued most of these for 3.7 with the exception of the OMAP4430 CTI-related patches (which look to me like 3.8 material) and the PM runtime suspend/resume patch (which looks to me like 3.7-rc material) -- assuming this series makes it in for 3.7 ... Apologies in advance if I broke something else in the process. Looks good. Nothing you broke, but I just posted one fix for PMU interrupts on OMAP2/3 [1]. With this PMU on Tony's master branch is working fine on OMAP2420 and OMAP3430. I have also verified that PMU is working on OMAP4460 too. Cheers Jon [1] http://article.gmane.org/gmane.linux.ports.arm.omap/85294 -- 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 V3 0/8] ARM: OMAP4: Add PMU Support
Hi Will, On 09/20/2012 04:09 PM, Will Deacon wrote: On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote: Hi Jon, Will, Ming, et al., Hi Paul, Have queued most of these for 3.7 with the exception of the OMAP4430 CTI-related patches (which look to me like 3.8 material) and the PM runtime suspend/resume patch (which looks to me like 3.7-rc material) -- assuming this series makes it in for 3.7 ... Ok, thanks for queueing what you did. Jon -- could you pick the pieces up from what's left please and shout if you need anything from me? Yes will do. Cheers Jon -- 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: rcu self-detected stall messages on OMAP3, 4 boards
On Sat, 22 Sep 2012, Paul E. McKenney wrote: On Sat, Sep 22, 2012 at 10:20:19PM +, Paul Walmsley wrote: On Sat, 22 Sep 2012, Paul E. McKenney wrote: This thing has been in the kernel since about 2004, not sure why you didn't hit it earlier. One other data point in that regard - noticed the warnings don't appear when the board is booted with: commit 4fa3b6cb1bc8c14b81b4c8ffdfd3f2500a7e9367 Author: Paul E. McKenney paul.mcken...@linaro.org Date: Tue Jun 5 15:53:53 2012 -0700 rcu: Fix qlen_lazy breakage You lost me on this one. This is already in mainline, so if you were using (say) 3.6-rc6, you would already have this commit applied. If I check out a kernel at this commit 4fa3b6cb1bc8c14b81b4c8ffdfd3f2500a7e9367 + the zero-callback-in-tickless-idle diagnostic patch, build and boot it, then the stall warnings don't appear (in 25 minutes of testing). Messages from the diagnostic patch indicate that the kernel is entering idle during a grace period with no RCU callbacks, though. This is not a big deal and does not need any further attention. Just wanted to place a time boundary on the point when these messages started appearing. (It is unlikely to be an optimal bound: i.e., there are probably later commits where the warnings also don't appear.) - 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 v4 2/2] mfd: Add backlight as subdevice to the tps65217
Hi Matthias, On Mon, Sep 24, 2012 at 10:25:34PM +0200, Matthias Kaehlcke wrote: mfd: Add backlight as subdevice to the tps65217 Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net --- drivers/mfd/tps65217.c |3 +++ 1 file changed, 3 insertions(+) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] backlight: Add TPS65217 WLED driver
Hi Matthias, On Mon, Sep 24, 2012 at 10:25:28PM +0200, Matthias Kaehlcke wrote: The TPS65217 chip contains a boost converter and current sinks which can be used to drive LEDs for use as backlights. Expose this functionality via the backlight API. Tested on an AM335x based custom board with a single WLED string, using different values for ISEL and FDIM (though it would be hard to tell the difference except for the value in WLEDCTRL1). Both instantiation through the device tree and by passing platform data have been tested. Testing has been done with an Androidized 3.2 kernel from the rowboat project. Koen Kooi reported the driver to be working on a Beaglebone board with LCD3 cape This patch is based on the mfd branch (20120924) Changes since v3: * split in two patches, one for the driver another for adding the mfd subdevice * renamed variable on to is_enabled and changed type to boolean Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net --- drivers/video/backlight/Kconfig |7 + drivers/video/backlight/Makefile |1 + drivers/video/backlight/tps65217_bl.c | 352 + include/linux/mfd/tps65217.h | 18 ++ 4 files changed, 378 insertions(+) create mode 100644 drivers/video/backlight/tps65217_bl.c Applied as well, although it could go through Richard's tree. Having his review would be nice anyway. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rcu self-detected stall messages on OMAP3, 4 boards
On Mon, Sep 24, 2012 at 09:54:00PM +, Paul Walmsley wrote: On Sat, 22 Sep 2012, Paul E. McKenney wrote: On Sat, Sep 22, 2012 at 10:20:19PM +, Paul Walmsley wrote: On Sat, 22 Sep 2012, Paul E. McKenney wrote: This thing has been in the kernel since about 2004, not sure why you didn't hit it earlier. One other data point in that regard - noticed the warnings don't appear when the board is booted with: commit 4fa3b6cb1bc8c14b81b4c8ffdfd3f2500a7e9367 Author: Paul E. McKenney paul.mcken...@linaro.org Date: Tue Jun 5 15:53:53 2012 -0700 rcu: Fix qlen_lazy breakage You lost me on this one. This is already in mainline, so if you were using (say) 3.6-rc6, you would already have this commit applied. If I check out a kernel at this commit 4fa3b6cb1bc8c14b81b4c8ffdfd3f2500a7e9367 + the zero-callback-in-tickless-idle diagnostic patch, build and boot it, then the stall warnings don't appear (in 25 minutes of testing). Messages from the diagnostic patch indicate that the kernel is entering idle during a grace period with no RCU callbacks, though. This is not a big deal and does not need any further attention. Just wanted to place a time boundary on the point when these messages started appearing. (It is unlikely to be an optimal bound: i.e., there are probably later commits where the warnings also don't appear.) Ah, got it, thank you! Thanx, 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: tidspbridge build fails
Hi, On Mon, Sep 24, 2012 at 11:37 AM, Selso LIBERADO s...@cioinfoindus.fr wrote: ... CC [M] drivers/staging/tidspbridge/core/tiomap3430.o drivers/staging/tidspbridge/core/tiomap3430.c: In function 'bridge_brd_start': drivers/staging/tidspbridge/core/tiomap3430.c:421:25: error: 'OMAP343X_CTRL_BASE' undeclared (first use in this function) drivers/staging/tidspbridge/core/tiomap3430.c:421:25: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1 ... This definition has moved to : arch/arm/mach-omap2/omap34xx.h I don't know if we can include directly this file in tiomap3430.c (I'm newbie) However there is still the symbole OMAP34XX_WDT3_BASE in 'drivers/staging/tidspbridge/core/wdt.c' that is not resolved. This should be solved by Tony's patch: https://patchwork.kernel.org/patch/1435311/ Right now it is on staging-next. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
Hi Vinod, On 09/17/2012 10:13 PM, Vinod Koul wrote: On Mon, 2012-09-17 at 23:36 +0100, Russell King - ARM Linux wrote: I believe that Jon is on vacation this week, so if this is the only issue holding up the merge, maybe you can change this in his patch directly, or I can send an updated version if you prefer. I worry that too much is going on here too quickly. We have some people working on changing the way DMA engine selects channels. Meanwhile we have other people trying to create an OF DMA engine API. It seems that Vinod's working on a way for platforms to specify bindings to the DMA engine code, and the DMA engine code itself selects the appropriate channel. This patch, on the other hand, introduces a set of translation functions which need to be provided by platform code, which returns the dma_chan pointer. This sounds like a recipe for a total abortion of interfaces. Only one of those two activities should be going on at any one time, or if they have to occur, they need coordination so that the we don't end up with two totally different schemes. In the mad rush to DTify everything, don't make hasty decisions, because it is very difficult to change it later - especially something like this which defines how DT encodes this information. We discussed this in KS and IMHO we need to merge these two approaches. For DT bindings, I think the binding itself shouldn't change based on my work but I would like these same bindings to help build the DMA engine code mappings. Now would it make sense to NOT merge these changes for 3.7 and postpone to 3.8. I can host these patches on a topic branch and merge them when we are ready. I plan to spend some good amount of time on my work this week so we should be ready pretty soon. One these changes are merged, users can start moving to this scheme. I just wanted to see how things are progressing your side. Did you create a topic branch for this? If so let me know where I can find it, I did not find a branch on your infradead git tree. I wanted to pull in the latest patches for some testing. Cheers Jon -- 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] of: dma: fix typos in generic dma binding definition
Hi Matt, On 09/19/2012 09:49 AM, Matt Porter wrote: Some semicolons were left out in the examples. The #dma-channels and #dma-requests properties have a prefix that is, by convention, reserved for cell size properties. Rename those properties to dma-channels and dma-requests. Signed-off-by: Matt Porter mpor...@ti.com Acked-by: Jon Hunter jon-hun...@ti.com Thanks for catching and fixing these! Cheers Jon -- 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
ARM: OMAP: fix new sparse warnings
Commit e54adb1e79762d3591459e5b0e9b9ff578e33fdb (ARM: OMAP: omap3evm:
cleanup revision bits) adds a new sparse[1] warning:
arch/arm/mach-omap2/board-omap3evm.c:90:4: warning: symbol 'get_omap3_evm_rev'
was not declared. Should it be static?
This symbol no longer appears to be used outside this file, so mark it
static and remove the export.
Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 (ARM: OMAP: move
debug_card_init() function) results in the following new sparse[1]
warning:
arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was
not declared. Should it be static?
Fix by including the proper header file.
...
1. https://sparse.wiki.kernel.org/index.php/Main_Page
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Tony Lindgren t...@atomide.com
---
Will queue this with devel-late-fixes.
arch/arm/mach-omap2/board-omap3evm.c |3 +--
arch/arm/plat-omap/debug-devices.c |2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index b94873d..f229aab 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -87,11 +87,10 @@ enum {
static u8 omap3_evm_version;
-u8 get_omap3_evm_rev(void)
+static u8 get_omap3_evm_rev(void)
{
return omap3_evm_version;
}
-EXPORT_SYMBOL(get_omap3_evm_rev);
static void __init omap3_evm_get_revision(void)
{
diff --git a/arch/arm/plat-omap/debug-devices.c
b/arch/arm/plat-omap/debug-devices.c
index c7a4c09..5e4f722 100644
--- a/arch/arm/plat-omap/debug-devices.c
+++ b/arch/arm/plat-omap/debug-devices.c
@@ -17,6 +17,8 @@
#include mach/hardware.h
+#include plat/debug-devices.h
+
/* Many OMAP development platforms reuse the same debug board; these
* platforms include H2, H3, H4, and Perseus2.
*/
--
1.7.10.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 v2 08/15] tidspbridge: Fix VM_PFNMAP mapping
Hi Felipe, On Friday 21 September 2012 20:37:40 Felipe Contreras wrote: On Wed, Sep 19, 2012 at 2:06 PM, Laurent Pinchart wrote: VMAs marked with the VM_PFNMAP flag have no struct page associated with the memory PFNs. Don't call get_page()/put_page() on the pages supposedly associated with the PFNs. I don't see anything wrong with the patch, but I think there's a lot of changes, and perhaps a bit more of explanation of how it's doing this might help. I'll make the commit message more explicit. Also, it seems to be reordering match_exact_map_obj(), which messes up the diff a bit. That's because match_exact_map_obj() logically belonged to remove_mapping_information(), but now belongs to find_dsp_mapping(). I've split the commit in two, I'll send the result in reply to this e-mail. Please let me know if you like that better. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] tidspbridge: Refactor mapping find/remove operations
Split the remove_mapping_information() function into find_dsp_mapping()
to locate the mapping and remove_mapping_information() to remove it.
Rename find_containing_mapping() to find_mpu_mapping() and share the
search code between find_dsp_mapping() and find_mpu_mapping().
This prepares the driver for VM_PFNMAP support.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/tidspbridge/rmgr/proc.c | 116 ---
1 files changed, 59 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/proc.c
b/drivers/staging/tidspbridge/rmgr/proc.c
index 7e4f12f..64b1bba 100644
--- a/drivers/staging/tidspbridge/rmgr/proc.c
+++ b/drivers/staging/tidspbridge/rmgr/proc.c
@@ -145,47 +145,67 @@ static struct dmm_map_object *add_mapping_info(struct
process_context *pr_ctxt,
return map_obj;
}
-static int match_exact_map_obj(struct dmm_map_object *map_obj,
- u32 dsp_addr, u32 size)
+static void remove_mapping_information(struct process_context *pr_ctxt,
+ struct dmm_map_object *map_obj)
{
- if (map_obj-dsp_addr == dsp_addr map_obj-size != size)
- pr_err(%s: addr match (0x%x), size don't (0x%x != 0x%x)\n,
- __func__, dsp_addr, map_obj-size, size);
+ if (map_obj == NULL)
+ return;
- return map_obj-dsp_addr == dsp_addr
- map_obj-size == size;
+ pr_debug(%s: match, deleting map info\n, __func__);
+
+ spin_lock(pr_ctxt-dmm_map_lock);
+ list_del(map_obj-link);
+ spin_unlock(pr_ctxt-dmm_map_lock);
+
+ kfree(map_obj-dma_info.sg);
+ kfree(map_obj-pages);
+ kfree(map_obj);
}
-static void remove_mapping_information(struct process_context *pr_ctxt,
- u32 dsp_addr, u32 size)
+static struct dmm_map_object *
+find_mapping(struct process_context *pr_ctxt, u32 addr, u32 size,
+int (*match)(struct dmm_map_object *, u32, u32))
{
struct dmm_map_object *map_obj;
- pr_debug(%s: looking for virt 0x%x size 0x%x\n, __func__,
- dsp_addr, size);
-
spin_lock(pr_ctxt-dmm_map_lock);
list_for_each_entry(map_obj, pr_ctxt-dmm_map_list, link) {
- pr_debug(%s: candidate: mpu_addr 0x%x virt 0x%x size 0x%x\n,
- __func__,
- map_obj-mpu_addr,
- map_obj-dsp_addr,
- map_obj-size);
-
- if (match_exact_map_obj(map_obj, dsp_addr, size)) {
- pr_debug(%s: match, deleting map info\n, __func__);
- list_del(map_obj-link);
- kfree(map_obj-dma_info.sg);
- kfree(map_obj-pages);
- kfree(map_obj);
+ pr_debug(%s: candidate: mpu_addr 0x%x dsp_addr 0x%x size
0x%x\n,
+__func__, map_obj-mpu_addr, map_obj-dsp_addr,
+map_obj-size);
+
+ if (match(map_obj, addr, size)) {
+ pr_debug(%s: match!\n, __func__);
goto out;
}
- pr_debug(%s: candidate didn't match\n, __func__);
+
+ pr_debug(%s: no match!\n, __func__);
}
- pr_err(%s: failed to find given map info\n, __func__);
+ map_obj = NULL;
out:
spin_unlock(pr_ctxt-dmm_map_lock);
+ return map_obj;
+}
+
+static int match_exact_map_obj(struct dmm_map_object *map_obj,
+ u32 dsp_addr, u32 size)
+{
+ if (map_obj-dsp_addr == dsp_addr map_obj-size != size)
+ pr_err(%s: addr match (0x%x), size don't (0x%x != 0x%x)\n,
+ __func__, dsp_addr, map_obj-size, size);
+
+ return map_obj-dsp_addr == dsp_addr
+ map_obj-size == size;
+}
+
+static struct dmm_map_object *
+find_dsp_mapping(struct process_context *pr_ctxt, u32 dsp_addr, u32 size)
+{
+ pr_debug(%s: looking for virt 0x%x size 0x%x\n, __func__,
+dsp_addr, size);
+
+ return find_mapping(pr_ctxt, dsp_addr, size, match_exact_map_obj);
}
static int match_containing_map_obj(struct dmm_map_object *map_obj,
@@ -197,33 +217,13 @@ static int match_containing_map_obj(struct dmm_map_object
*map_obj,
mpu_addr + size = map_obj_end;
}
-static struct dmm_map_object *find_containing_mapping(
- struct process_context *pr_ctxt,
- u32 mpu_addr, u32 size)
+static struct dmm_map_object *
+find_mpu_mapping(struct process_context *pr_ctxt, u32 mpu_addr, u32 size)
{
- struct dmm_map_object *map_obj;
[PATCH 2/2] tidspbridge: Fix VM_PFNMAP mapping
VMAs marked with the VM_PFNMAP flag have no struct page associated with
the memory PFNs. Don't call get_page()/put_page() on the pages
supposedly associated with the PFNs.
To check the VM flags at unmap time store them in the dmm_map_object
structure at map time, and pass the structure down to the tiomap3430.c
layer.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 30
.../staging/tidspbridge/include/dspbridge/drv.h|1 +
.../tidspbridge/include/dspbridge/dspdefs.h|9 +++--
drivers/staging/tidspbridge/rmgr/proc.c| 14
4 files changed, 31 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 2c5be89..cc538ea 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1262,7 +1262,8 @@ static void bad_page_dump(u32 pa, struct page *pg)
}
/* Release all pages associated with a physical addresses range. */
-static void bridge_release_pages(u32 paddr, u32 pte_size, u32 num_bytes)
+static void bridge_release_pages(u32 paddr, u32 pte_size, u32 num_bytes,
+struct dmm_map_object *map_obj)
{
struct page *pg;
u32 num_pages;
@@ -1270,7 +1271,8 @@ static void bridge_release_pages(u32 paddr, u32 pte_size,
u32 num_bytes)
num_pages = pte_size / PAGE_SIZE;
for (; num_pages 0; --num_pages, paddr += HW_PAGE_SIZE4KB) {
- if (!pfn_valid(__phys_to_pfn(paddr)))
+ if (!pfn_valid(__phys_to_pfn(paddr)) ||
+ (map_obj map_obj-vm_flags VM_PFNMAP))
continue;
pg = PHYS_TO_PAGE(paddr);
@@ -1295,7 +1297,8 @@ static void bridge_release_pages(u32 paddr, u32 pte_size,
u32 num_bytes)
* we clear consecutive PTEs until we unmap all the bytes
*/
static int bridge_brd_mem_un_map(struct bridge_dev_context *dev_ctxt,
-u32 virt_addr, u32 num_bytes)
+u32 virt_addr, u32 num_bytes,
+struct dmm_map_object *map_obj)
{
u32 l1_base_va;
u32 l2_base_va;
@@ -1369,7 +1372,7 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
}
bridge_release_pages(pte_val ~(pte_size - 1),
pte_size,
-num_bytes);
+num_bytes, map_obj);
if (hw_mmu_pte_clear(pte_addr_l2, virt_addr, pte_size))
{
status = -EPERM;
@@ -1413,7 +1416,7 @@ skip_coarse_page:
}
bridge_release_pages(pte_val ~(pte_size - 1), pte_size,
-num_bytes);
+num_bytes, map_obj);
if (!hw_mmu_pte_clear(l1_base_va, virt_addr, pte_size)) {
status = 0;
@@ -1448,7 +1451,7 @@ EXIT_LOOP:
*/
static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctxt,
u32 mpu_addr, u32 virt_addr, u32 num_bytes,
- u32 map_attr, struct page **mapped_pages)
+ u32 map_attr, struct dmm_map_object *map_obj)
{
u32 attrs;
int status = 0;
@@ -1559,6 +1562,9 @@ static int bridge_brd_mem_map(struct bridge_dev_context
*dev_ctxt,
goto func_cont;
}
+ if (map_obj)
+ map_obj-vm_flags = vma-vm_flags;
+
if (vma-vm_flags VM_IO) {
num_usr_pgs = num_bytes / PG_SIZE4K;
@@ -1571,7 +1577,8 @@ static int bridge_brd_mem_map(struct bridge_dev_context
*dev_ctxt,
address is invalid\n);
break;
}
- if (pfn_valid(__phys_to_pfn(pa))) {
+ if (!(vma-vm_flags VM_PFNMAP)
+ pfn_valid(__phys_to_pfn(pa))) {
pg = PHYS_TO_PAGE(pa);
get_page(pg);
if (page_count(pg) 1) {
@@ -1610,8 +1617,8 @@ static int bridge_brd_mem_map(struct bridge_dev_context
*dev_ctxt,
if (status)
break;
- if (mapped_pages)
- mapped_pages[pg_i] = pg;
+ if (map_obj)
+ map_obj-pages[pg_i] = pg;
virt_addr += HW_PAGE_SIZE4KB;
mpu_addr += HW_PAGE_SIZE4KB;
@@ -1635,10 +1642,9 @@ func_cont:
* Roll out the mapped pages incase it failed in middle of
Re: [PATCH v2 00/15] tidspbridge driver MMU-related cleanups
Hi Omar, On Friday 21 September 2012 11:18:56 Ramirez Luna, Omar wrote: On Wed, Sep 19, 2012 at 7:06 AM, Laurent Pinchart wrote: Hello, Here's the second version of my tidspbridge MMU-related cleanup patches. The first version has been sent privately only, don't try to search the mailing list archive for it :-) Replacing hw/hw_mmu.c and part of core/tiomap3430.c with generic IOMMU calls should be less difficult now. Anyone would like to give it a try? Laurent Pinchart (14): tidspbridge: hw_mmu: Reorder functions to avoid forward declarations tidspbridge: hw_mmu: Removed unused functions tidspbridge: tiomap3430: Reorder functions to avoid forward declarations tidspbridge: tiomap3430: Remove unneeded dev_context local variables tidspbridge: tiomap3430: Factor out common page release code tidspbridge: tiomap3430: Remove ul_ prefix tidspbridge: tiomap3430: Remove unneeded local variables tidspbridge: Fix VM_PFNMAP mapping tidspbridge: Remove unused hw_mmu_map_attrs_t::donotlockmpupage field arm: omap: iommu: Include required headers in iommu.h and iopgtable.h tidspbridge: Use constants defined in IOMMU platform headers tidspbridge: Simplify pte_update and mem_map_vmalloc functions tidspbridge: Use correct types to describe physical, MPU, DSP addresses tidspbridge: Replace hw_mmu_map_attrs_t structure with a prot bitfield Thanks, tested on beagle-xM, they look good! Can you submit them to Greg KH and de...@driverdev.osuosl.org, preferably with a 'staging:' prefix along with the current subject. I'll do that after getting Felipe's feedback (as well as yours if possible :-)) on the VM_PFNMAP patch split that I've posted today. The only thing of concern is that: ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected Might be taking a different path than these to mainline[1]. Cheers, Omar --- [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg76319.html -- Regards, Laurent Pinchart -- 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: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
On Mon, Sep 24, 2012 at 09:05:11PM +0200, Yegor Yefremov wrote: On Mon, Sep 24, 2012 at 7:18 PM, Tony Lindgren t...@atomide.com wrote: * yegorsli...@googlemail.com yegorsli...@googlemail.com [120703 07:26]: From: Yegor Yefremov yegorsli...@googlemail.com FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB of consistent DMA memory (da8xx frame buffer driver). Sorry for the delay on this one, looks like this one is still valid. I'll apply it. Thanks. Yegor Signed-off-by: Dejan Gacnik dejan.gac...@gmail.com Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- arch/arm/Kconfig |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e876819..ff14c1e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1725,8 +1725,9 @@ config HW_PERF_EVENTS source mm/Kconfig config FORCE_MAX_ZONEORDER - int Maximum zone order if ARCH_SHMOBILE - range 11 64 if ARCH_SHMOBILE + int Maximum zone order + depends on ARCH_SHMOBILE || SOC_AM33XX + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX default 9 if SA default 11 NAK. This patch breaks SA platforms. To see why, read the patch. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v3 00/15] ASoC: OMAP: Convert to use dmaengine
Hi Peter, Mark, On 09/14/2012 07:05 AM, Peter Ujfalusi wrote: Hello, Changes since v2: - As it has been discussed the no_wakeup parameter has been replaced with flags for the dmaengine APIs Changes since v1: - Support for pause/resume for OMAP audio via dmaengine - dmaengine: support for NO_PERIOD_WAKEUP in cyclic mode - OMAP to keep supporting NO_PERIOD_WAKEUP for audio - Other plaforms can also try to enable this mode since we have now generic interface to do so. This series will switch the OMAP audio to use dmaengine. The final patch which does the switch was based on Russell King's earlier patch. The first 10 patch is to prepare the OMAP audio drivers for a smooth change to dmaengine: - sDMA FRAME sync mode is removed and replaced with PACKET mode - dai drivers no longer need to configure sDMA sync mode - dai drivers does not need to specify the DMA word length - with the exception of the omap-hdmi driver which requires 32bit word length regardless of the audio format in use - the McPDM driver used (to my surprise) hackish way of getting the DMA channel and address - via defines from some header files After the conversion OMAP audio support should have the same features as before, no regressions expected. I have tested the series on: - BeagleBoard (audio via McBSP): - aplay/arecord. In element mode and in threshold mode with different period sizes - mplayer -ao alsa: for direct ALSA access - mplayer -ao pulse: via PulseAudio to test NO_PERIOD_WAKEUP feature - OMAP4 Blaze (audio via McPDM and DMIC) - aplay/arecord - mplayer -ao alsa: for direct ALSA access - mplayer -ao pulse: via PulseAudio to test NO_PERIOD_WAKEUP feature The patches has been generated against: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7 Janusz: Can you retest this series on OMAP1 to be sure I have not broken it? Ricardo: Can you test the omap-hmdi if it is still working? I tested these changes from Mark's for-3.7 branch. HDMI audio is working fine after applying patch 03. Such patch is missing in Mark's branch and this causes a build break with omap2plus_defconfig. Not sure if this is expected, Most likely not. Tested-by: Ricardo Neri ricardo.n...@ti.com Ricardo -- 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: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
* Russell King - ARM Linux li...@arm.linux.org.uk [120924 16:17]: On Mon, Sep 24, 2012 at 09:05:11PM +0200, Yegor Yefremov wrote: On Mon, Sep 24, 2012 at 7:18 PM, Tony Lindgren t...@atomide.com wrote: * yegorsli...@googlemail.com yegorsli...@googlemail.com [120703 07:26]: From: Yegor Yefremov yegorsli...@googlemail.com FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB of consistent DMA memory (da8xx frame buffer driver). Sorry for the delay on this one, looks like this one is still valid. I'll apply it. Thanks. Yegor Signed-off-by: Dejan Gacnik dejan.gac...@gmail.com Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- arch/arm/Kconfig |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e876819..ff14c1e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1725,8 +1725,9 @@ config HW_PERF_EVENTS source mm/Kconfig config FORCE_MAX_ZONEORDER - int Maximum zone order if ARCH_SHMOBILE - range 11 64 if ARCH_SHMOBILE + int Maximum zone order + depends on ARCH_SHMOBILE || SOC_AM33XX + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX default 9 if SA default 11 NAK. This patch breaks SA platforms. To see why, read the patch. OK let's drop this. 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 2/3] omap platform and board related late patches for v3.7 merge window
* Tony Lindgren t...@atomide.com [120924 14:30]: The following changes since commit 0e70156de4c8465bfb8cb45cdc1bbc2fa474ce14: ARM: OMAP2+: Make omap4-keypad.h local (2012-09-20 15:04:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-devel-board-late-v2-for-v3.7 for you to fetch changes up to ead53717d9ab28c942b9adf66f8c02442dbfbc8a: arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX (2012-09-24 10:32:39 -0700) These board and platform related patches have been posted quite a while ago but have somehow fallen though the cracks as most of the focus has been making things to work with device tree. As the first patch depends on sparse IRQ related removal of irqs.h and related header moves, these are based on omap-cleanup-local-headers-for-v3.7 tag. Let's scrap this pull request, Russell noted that Yegor's patch breaks sa. Regards, Tony AnilKumar Ch (1): ARM: OMAP2+: serial: Change MAX_HSUART_PORTS to 6 Peter Ujfalusi (1): ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus Yegor Yefremov (1): arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX arch/arm/Kconfig |5 ++-- arch/arm/mach-omap2/board-4430sdp.c | 12 ++-- arch/arm/mach-omap2/board-omap4panda.c| 12 ++-- arch/arm/mach-omap2/twl-common.c | 37 - arch/arm/mach-omap2/twl-common.h |3 +- arch/arm/plat-omap/include/plat/omap-serial.h |2 +- 6 files changed, 37 insertions(+), 34 deletions(-) ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: OMAP: counter: add locking to read_persistent_clock
R Sricharan r.sricha...@ti.com writes:
From: Colin Cross ccr...@android.com
read_persistent_clock uses a global variable, use a spinlock to
ensure non-atomic updates to the variable don't overlap and cause
time to move backwards.
Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
Tony, this should probably be queued up for v3.7-rc and flagged for stable.
Thanks,
Kevin
---
[V2] Added signed-off-by and looped in linux-arm-kernel list
arch/arm/plat-omap/counter_32k.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/counter_32k.c
b/arch/arm/plat-omap/counter_32k.c
index dbf1e03..2bc51fb 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
* nsecs and adds to a monotonically increasing timespec.
*/
static struct timespec persistent_ts;
-static cycles_t cycles, last_cycles;
+static cycles_t cycles;
static unsigned int persistent_mult, persistent_shift;
+static DEFINE_SPINLOCK(read_persistent_clock_lock);
+
static void omap_read_persistent_clock(struct timespec *ts)
{
unsigned long long nsecs;
- cycles_t delta;
- struct timespec *tsp = persistent_ts;
+ cycles_t last_cycles;
+ unsigned long flags;
+
+ spin_lock_irqsave(read_persistent_clock_lock, flags);
last_cycles = cycles;
cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
- delta = cycles - last_cycles;
- nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
+ nsecs = clocksource_cyc2ns(cycles - last_cycles,
+ persistent_mult, persistent_shift);
+
+ timespec_add_ns(persistent_ts, nsecs);
+
+ *ts = persistent_ts;
- timespec_add_ns(tsp, nsecs);
- *ts = *tsp;
+ spin_unlock_irqrestore(read_persistent_clock_lock, flags);
}
/**
--
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: convert I2C driver to PM QoS for MPU latency constraints
Jean Pihet jean.pi...@newoldbits.com writes: Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY class of PM QoS. The resulting MPU constraints are used by cpuidle to decide the next power state of the MPU subsystem. The I2C device latency timing is derived from the FIFO size and the clock speed and so is applicable to all OMAP SoCs. Signed-off-by: Jean Pihet j-pi...@ti.com Acked-by: Kevin Hilman khil...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock
* Kevin Hilman khil...@deeprootsystems.com [120924 17:44]:
R Sricharan r.sricha...@ti.com writes:
From: Colin Cross ccr...@android.com
read_persistent_clock uses a global variable, use a spinlock to
ensure non-atomic updates to the variable don't overlap and cause
time to move backwards.
Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
Tony, this should probably be queued up for v3.7-rc and flagged for stable.
Yes I can see that happening. But then in addition..
---
[V2] Added signed-off-by and looped in linux-arm-kernel list
arch/arm/plat-omap/counter_32k.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/counter_32k.c
b/arch/arm/plat-omap/counter_32k.c
index dbf1e03..2bc51fb 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
* nsecs and adds to a monotonically increasing timespec.
*/
static struct timespec persistent_ts;
-static cycles_t cycles, last_cycles;
+static cycles_t cycles;
static unsigned int persistent_mult, persistent_shift;
+static DEFINE_SPINLOCK(read_persistent_clock_lock);
+
static void omap_read_persistent_clock(struct timespec *ts)
{
unsigned long long nsecs;
- cycles_t delta;
- struct timespec *tsp = persistent_ts;
+ cycles_t last_cycles;
+ unsigned long flags;
+
+ spin_lock_irqsave(read_persistent_clock_lock, flags);
last_cycles = cycles;
cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
- delta = cycles - last_cycles;
- nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
+ nsecs = clocksource_cyc2ns(cycles - last_cycles,
+ persistent_mult, persistent_shift);
..I think there's another bug here where cycles - last_cycles
returns wrong value when the timer wraps around as cycles_t is
64 bits and the counter is 32 bits. It seems it's been there
since when the read_persistent_clock was added with commit
d92cfcbe (OMAP: timekeeping: time should not stop during suspend)?
It seems that after this patch cycles should not be cycles_t
but u32, and the result of cycles - last_cycles should also
be u32.
+ timespec_add_ns(persistent_ts, nsecs);
+
+ *ts = persistent_ts;
- timespec_add_ns(tsp, nsecs);
- *ts = *tsp;
+ spin_unlock_irqrestore(read_persistent_clock_lock, flags);
}
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: [GIT PULL 2/3] omap platform and board related late patches for v3.7 merge window
* Tony Lindgren t...@atomide.com [120924 17:41]: * Tony Lindgren t...@atomide.com [120924 14:30]: The following changes since commit 0e70156de4c8465bfb8cb45cdc1bbc2fa474ce14: ARM: OMAP2+: Make omap4-keypad.h local (2012-09-20 15:04:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-devel-board-late-v2-for-v3.7 for you to fetch changes up to ead53717d9ab28c942b9adf66f8c02442dbfbc8a: arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX (2012-09-24 10:32:39 -0700) These board and platform related patches have been posted quite a while ago but have somehow fallen though the cracks as most of the focus has been making things to work with device tree. As the first patch depends on sparse IRQ related removal of irqs.h and related header moves, these are based on omap-cleanup-local-headers-for-v3.7 tag. Let's scrap this pull request, Russell noted that Yegor's patch breaks sa. Here's the updated pull request with just the top patch dropped. Tony The following changes since commit 0e70156de4c8465bfb8cb45cdc1bbc2fa474ce14: ARM: OMAP2+: Make omap4-keypad.h local (2012-09-20 15:04:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-devel-board-late-v3-for-v3.7 for you to fetch changes up to cfc55bcc1f78395872d41c50f6a3129c4b42289e: ARM: OMAP2+: serial: Change MAX_HSUART_PORTS to 6 (2012-09-24 10:32:39 -0700) These board and platform related patches have been posted quite a while ago but have somehow fallen though the cracks as most of the focus has been making things to work with device tree. As the first patch depends on sparse IRQ related removal of irqs.h and related header moves, these are based on omap-cleanup-local-headers-for-v3.7 tag. AnilKumar Ch (1): ARM: OMAP2+: serial: Change MAX_HSUART_PORTS to 6 Peter Ujfalusi (1): ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus arch/arm/mach-omap2/board-4430sdp.c | 12 ++-- arch/arm/mach-omap2/board-omap4panda.c| 12 ++-- arch/arm/mach-omap2/twl-common.c | 37 - arch/arm/mach-omap2/twl-common.h |3 +- arch/arm/plat-omap/include/plat/omap-serial.h |2 +- 5 files changed, 34 insertions(+), 32 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 V6 2/2] dmaengine: add helper function to request a slave DMA channel
On Mon, 2012-09-24 at 17:25 -0500, Jon Hunter wrote: For DT bindings, I think the binding itself shouldn't change based on my work but I would like these same bindings to help build the DMA engine code mappings. Now would it make sense to NOT merge these changes for 3.7 and postpone to 3.8. I can host these patches on a topic branch and merge them when we are ready. I plan to spend some good amount of time on my work this week so we should be ready pretty soon. One these changes are merged, users can start moving to this scheme. I just wanted to see how things are progressing your side. Did you create a topic branch for this? If so let me know where I can find it, I did not find a branch on your infradead git tree. I wanted to pull in the latest patches for some testing. Sorry for delay, I had everything ready, but couldn't manage to commit and push. I have pushed to topic/dmaengine_dt, it is pushing out now... This has your two patches, my fix for build breakage, and Matt's typo patch. This is based on my next. -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] OMAPDSS: OMAP5 related patches
On Monday 24 September 2012 07:28 PM, Tomi Valkeinen wrote: Hi, This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI and DSI. Looks good to me. Archit Tomi Archit Taneja (1): OMAPDSS: Add basic omap5 features to dss and dispc Tomi Valkeinen (8): OMAPDSS: DSI: improve DSI clock calcs for DISPC OMAPDSS: move dss feats to the end of dss.c OMAPDSS: Add support for DPI source selection OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL OMAPDSS: DSI: Add new linebuffer size for OMAP5 OMAPDSS: DSI: Add code to disable PHY DCC OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5 drivers/video/omap2/dss/Kconfig|2 +- drivers/video/omap2/dss/dispc.c|2 + drivers/video/omap2/dss/dpi.c |5 + drivers/video/omap2/dss/dsi.c | 167 +--- drivers/video/omap2/dss/dss.c | 121 ++- drivers/video/omap2/dss/dss.h |1 + drivers/video/omap2/dss/dss_features.c | 96 ++ drivers/video/omap2/dss/dss_features.h |3 + 8 files changed, 337 insertions(+), 60 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
