Re: [PATCH 5/6] OMAPDSS: DISPC: move fifo threhold calc to dispc.c
On Sat, 2012-01-14 at 01:30 +0530, Archit wrote:
Hi,
On Friday 13 January 2012 05:16 PM, Tomi Valkeinen wrote:
Move fifo threshold calculation into dispc.c, as the thresholds are
really dispc internal thing.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
snip
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 511ae2a..1cbb7a5 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4524,14 +4524,6 @@ int omapdss_dsi_enable_te(struct omap_dss_device
*dssdev, bool enable)
}
EXPORT_SYMBOL(omapdss_dsi_enable_te);
-void dsi_get_overlay_fifo_thresholds(enum omap_plane plane,
- u32 fifo_size, u32 burst_size,
- u32 *fifo_low, u32 *fifo_high)
-{
- *fifo_high = fifo_size - burst_size;
- *fifo_low = fifo_size - burst_size * 2;
-}
We are removing the special treatment for overlays connected to DSI done
before. Won't this cause the issues you saw with DSI in OMAP3?
I added a FEAT_OMAP3_DSI_FIFO_BUG flag for OMAP3s, and changed the
dispc's fifo config function to:
void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
u32 *fifo_low, u32 *fifo_high, bool use_fifomerge)
{
/*
* All sizes are in bytes. Both the buffer and burst are made of
* buffer_units, and the fifo thresholds must be buffer_unit aligned.
*/
unsigned buf_unit = dss_feat_get_buffer_size_unit();
unsigned ovl_fifo_size, total_fifo_size, burst_size;
int i;
burst_size = dispc_ovl_get_burst_size(plane);
ovl_fifo_size = dispc_ovl_get_fifo_size(plane);
if (use_fifomerge) {
total_fifo_size = 0;
for (i = 0; i omap_dss_get_num_overlays(); ++i)
total_fifo_size += dispc_ovl_get_fifo_size(i);
} else {
total_fifo_size = ovl_fifo_size;
}
/*
* We use the same low threshold for both fifomerge and non-fifomerge
* cases, but for fifomerge we calculate the high threshold using the
* combined fifo size
*/
if (dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
*fifo_low = ovl_fifo_size - burst_size * 2;
*fifo_high = total_fifo_size - burst_size;
} else {
*fifo_low = ovl_fifo_size - burst_size;
*fifo_high = total_fifo_size - buf_unit;
}
}
Tomi
signature.asc
Description: This is a digitally signed message part
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 10:02 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. I was not convinced by those reasons. Just push harder on the bootloader side. There is _no_ reason for the bootloader not to take care of this very platform specific issue. You can even do it into a standalone uImage that returns to u-Boot after it is done with its magic. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? I don't care if this is OMAP, UX500 or i.MX. There is a line to be drawn and this is just too bad if you are trying to cross it. Well I was trying to get a solution for a genuine problem. Let's take an example. #ifdef CONFIG_ARM_ERRATA_742230 cmp r6, #0x22 @ only present up to r2p2 mrcle p15, 0, r10, c15, c0, 1 @ read diagnostic register orrle r10, r10, #1 4 @ set bit #4 mcrle p15, 0, r10, c15, c0, 1 @ write diagnostic register #endif The SoC's which doesn't have security restriction and the kernel is in secure mode, above errata is applied in it's right place. Before MMU is enabled. There are many bits like this which are patched in kernel. On OMAP, all these can't be set-up in kernel since kernel is in non-secure mode. To set such bit's we need to call some pre-defined security calls. Absolutely. Just don't do it in the early kernel boot code where it is not convenient to do so. Got it. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
On Thu, Dec 08, 2011 at 02:40:29, Tony Lindgren wrote: * Kevin Hilman khil...@ti.com [111206 15:52]: hvaib...@ti.com writes: From: Vaibhav Hiremath hvaib...@ti.com This patch set adds support for AM335x device having Cortex-A8 MPU. Official website - http://www.ti.com/product/am3359 AM335X is treated as another OMAP3 variant, where, along with existing cpu class OMAP34XX, new cpu class AM33XX is created and the respective type is AM335X, which is newly added device in the family. This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x() checks return success for AM335X. Also, I have validated OMAP3 boot test with this patch-series on OMAP3EVM. Tony, this series looks good to me. I've also tested it on a BeagleBone, so feel free to also add: Tested-by: Kevin Hilman khil...@ti.com Thanks looks good to me. We still need the machine_id update to apply patches 2 and 3 in this series, so applying only the first patch into soc branch for now. Tony, Can you also merge this patch, as machine_id for am335x-evm is already updated in linus/master? Thanks, Vaibhav 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: oprofile and ARM A9 hardware counter
Hi Will and stephane,
On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei ming@canonical.com wrote:
Hi stephane Will,
On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
eran...@googlemail.com wrote:
See the dmesg from my 3.2 kernel:
[ 0.00] Booting Linux on physical CPU 0[ 0.00]
But if you test omap4 perf against -next kernel, pmu won't work because
the commit[1] may put 'emu_sys_clkdm' clock domain into HW_AUTO mode,
so writing pmu register may not take effect.
I have found the similar problem on cam clock domain before[2].
CD_EMU is very simliar with CD_CAM in the point below:
CD_EMU has no static or module wake-up dependency with any other clock
domain of the device.[3]
So the patch[4] can make omap4 pmu work on -next tree.
Shilimkar, care to comment on the patch[4]?
thanks,
--
Ming Lei
[1], commit 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
Author: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed Jan 5 22:03:17 2011 +0530
ARM: OMAP4: PM: Initialise all the clockdomains to supported states
Initialise hardware supervised mode for all clockdomains if it's
supported. Initiate sleep transition for other clockdomains,
if they are not being used.
[2], http://www.spinics.net/lists/linux-omap/msg61911.html
[3], 3.6.12.3 of OMAP4 TRM
[4],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
static struct clockdomain l3_dma_44xx_clkdm = {
--
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: oprofile and ARM A9 hardware counter
On Wed, Jan 18, 2012 at 5:18 AM, Ming Lei ming@canonical.com wrote: Hi stephane Will, On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian eran...@googlemail.com wrote: See the dmesg from my 3.2 kernel: [ 0.00] Booting Linux on physical CPU 0[ 0.00] Looks no obvious failure can be found from your 'dmesg'. I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and found perf can work well on my panda board. 0001-arm-introduce-cross-trigger-interface-helpers.patch 0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch 0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2] 0004-arm-omap4-create-pmu-device-via-hwmod.patch[3] 0005-arm-omap4-support-pmu.patch[4] 0006-arm-omap4-pmu-support-runtime-pm.patch[5] Could you verify the above patches on 3.2 to see if perf can work well? If it doesn't, I may share my u-boot and mlo for your test if you'd like to do. BTW: #1 and #2 have been in Will's -next tree. Should I use Will's -next tree as the base instead of Linus'? Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf Thanks. thanks, -- Ming Lei [1], uname -a cat /proc/interrupts [root@root]#uname -a Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012 armv7l GNU/Linux [root@root]#cat /proc/interrupts CPU0 CPU1 29: 29014 17353 GIC twd 33: 56231 0 GIC arm-pmu 34: 0 25778 GIC arm-pmu [2], http://marc.info/?l=linux-omapm=132162118104901w=2 [3],http://marc.info/?t=13222762152r=1w=2 [4],http://marc.info/?t=13222762172r=1w=2 [5],http://marc.info/?t=13222762173r=1w=2 -- 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: oprofile and ARM A9 hardware counter
Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian eran...@googlemail.com Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f omap4_pmu.tar.gz Description: GNU Zip compressed data
Re: oprofile and ARM A9 hardware counter
On Wed, Jan 18, 2012 at 10:54:46AM +0100, stephane eranian wrote: Should I use Will's -next tree as the base instead of Linus'? Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? Other archive sites are available. There's my lurker-based archive on the old list server, and there's pipermail on the current list server to name two. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2/PM on 3.2 broken?
On Wed, 18 Jan 2012 09:13:59 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote: Having CPUIDLE makes the DSS2 problem worse: lots of [ 21.085113] omapdss DISPC error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled messages whenever the CPU isn't busy. I'm not sure if it is the case here, but DSS has restrictions about the max DSS clocks on different OPPs. For example, on OMAP4430 LCD clock maximum is 186MHz at OPP100, and 93MHz at OPP50. So it's a quite big drop, causing problems with all but the rather small displays. And the DSS driver doesn't have any support to handle this at the moment, as there isn't support in the PM framework to do this. I think the only way to handle this at the moment is for the DSS driver to set an arbitrarily high constraint on, say, mem throughput, and hope that it keeps the OMAP in the required OPP. Tomi This LCD panel on this device sets: .pixel_clock = 22000, in the struct omap_video_timings so I'm guessing that is 22MHz? I'll try building without SMARTREFLEX and see if that makes a difference - presumably that should keep it at OPP100 (??). Thanks, NeilBrown signature.asc Description: PGP signature
[RFC PATCH 0/5] arm:omap1/2/3/4: 32k sync timer cleanup
This patch series is built on top of older version submitted earlier during 2010 timeframe by 'Felipe Balbi' - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37403.html Changes from earlier submitted version: - hwmod cleanup: Since 2010 there has been some changes happened in hwmod interface, migrated to the latest version. - wrong hwmod info: the previous version had some issues with newly added 32k-counter hwmod data, like, base_addr, idle_st bit position. So corrected these errors. - In omap-32k platform driver, replaced clocksource_register = clocksource_register_hz - Merged patches into more logical grouping NOTE: Patch series has been tested on AM37xEVM, AM3517EVM, AM335xEVM, with/without kernel parameter clocksource=. The reason why I am submitting this patch-series as a RFC version is, I am struggling to convince myself and find answers for - - Do we really required platform_driver approach here? - Can we simply cleaup the existing plat-omap/counter_32k.c file and add hwmod lookup to make decesion whether the module is present or not on the current device? - what about existing mmio driver/api? we can avoid some code duplication here. So I decided to start with RFC with the existing (already submitted) approach and get the expert peoples view on this. Based on feedback I will submit next version. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Vaibhav Hiremath (5): arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver arm:omap2/3: Add idle_st bits for ST_32KSYNC timer arm:omap1/2/3/4: Add 32k counter data to hwmod database arm:omap1/2/3/4: Add platform hookup code for counter-32k driver arm:omap1/2/3: Change dev name for sync_32k_ick clk to omap-counter-32k arch/arm/mach-omap1/devices.c | 24 +++ arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/devices.c | 25 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 53 +++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/mach-omap2/prcm-common.h |4 + arch/arm/mach-omap2/timer.c| 17 --- arch/arm/plat-omap/Makefile|2 +- arch/arm/plat-omap/counter_32k.c | 154 drivers/clocksource/Makefile |1 + drivers/clocksource/omap-32k.c | 210 include/linux/clocksource.h|1 + 16 files changed, 426 insertions(+), 176 deletions(-) delete mode 100644 arch/arm/plat-omap/counter_32k.c create mode 100644 drivers/clocksource/omap-32k.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/5] arm:omap1/2/3: Change dev name for sync_32k_ick clk to omap-counter-32k
Device name for the sync_32k_ick clock has been set to
omap-counter-32k. This change is required, since 32k counter
clocksource driver has been migrated to standard platform_driver.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 61ad385..1cb8803 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1861,7 +1861,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gpios_fck,gpios_fck, CK_242X),
CLK(omap_wdt, ick, mpu_wdt_ick, CK_242X),
CLK(NULL, mpu_wdt_fck, mpu_wdt_fck, CK_242X),
- CLK(NULL, sync_32k_ick, sync_32k_ick, CK_242X),
+ CLK(omap-counter-32k, ick, sync_32k_ick, CK_242X),
CLK(NULL, wdt1_ick, wdt1_ick, CK_242X),
CLK(NULL, omapctrl_ick, omapctrl_ick, CK_242X),
CLK(omap24xxcam, fck, cam_fck, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 0cc1287..353a97c 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1959,7 +1959,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, gpios_fck,gpios_fck, CK_243X),
CLK(omap_wdt, ick, mpu_wdt_ick, CK_243X),
CLK(NULL, mpu_wdt_fck, mpu_wdt_fck, CK_243X),
- CLK(NULL, sync_32k_ick, sync_32k_ick, CK_243X),
+ CLK(omap-counter-32k, ick, sync_32k_ick, CK_243X),
CLK(NULL, wdt1_ick, wdt1_ick, CK_243X),
CLK(NULL, omapctrl_ick, omapctrl_ick, CK_243X),
CLK(NULL, icr_ick, icr_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 7dbb218..8e255e8 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3402,7 +3402,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_wdt, ick, wdt2_ick, CK_3XXX),
CLK(NULL, wdt1_ick, wdt1_ick, CK_3XXX),
CLK(NULL, gpio1_ick,gpio1_ick, CK_3XXX),
- CLK(NULL, omap_32ksync_ick, omap_32ksync_ick, CK_3XXX),
+ CLK(omap-counter-32k, ick, omap_32ksync_ick, CK_3XXX),
CLK(NULL, gpt12_ick,gpt12_ick, CK_3XXX),
CLK(NULL, gpt1_ick, gpt1_ick, CK_3XXX),
CLK(omap-mcbsp.2, prcm_fck, per_96m_fck, CK_3XXX),
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/5] arm:omap1/2/3/4: Add platform hookup code for counter-32k driver
omap 32k counter/timer driver has been migrated to the
standard platform_driver, so platform hookup is required
to bind the driver,
- omap1: Register platform_device for cpu_is_omap16xx()
- omap2/3/4: Use hwmod database lookup mechanism to build the
platform_device
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap1/devices.c | 24
arch/arm/mach-omap2/devices.c | 25 +
2 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 1d76a63..c7e99b3 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -34,6 +34,29 @@
/*-*/
+#define OMAP16XX_TIMER_32K_BASE0xfffbc400
+
+static struct resource omap_32k_resources[] = {
+ {
+ .start = OMAP16XX_TIMER_32K_BASE,
+ .end= SZ_4K,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-counter-32k,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap_32k_resources),
+ .resource = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+ if (cpu_is_omap16xx())
+ (void) platform_device_register(omap_32k_device);
+};
+
#if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
#defineOMAP_RTC_BASE 0xfffb4800
@@ -301,6 +324,7 @@ static int __init omap1_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
+ omap_init_32k();
omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 35d5dff..fee14d6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -105,6 +105,30 @@ static int __init omap4_l3_init(void)
}
postcore_initcall(omap4_l3_init);
+static int __init omap_init_32k(void)
+{
+ int id = -1;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ const char *oh_name = counter_32k;
+ const char *dev_name = omap-counter-32k;
+
+ if (!cpu_class_is_omap2())
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not lookup %s hwmod\n, oh_name);
+ return -ENODEV;
+ }
+
+ od = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(od), Can't build omap device for %s:%s.\n,
+ dev_name, oh-name);
+
+ return 0;
+};
+
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
static struct resource omap2cam_resources[] = {
@@ -700,6 +724,7 @@ static int __init omap2_init_devices(void)
* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
+ omap_init_32k();
omap_init_audio();
omap_init_mcpdm();
omap_init_dmic();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
Convert counter_32k clocksource driver to standard platform_driver
and move it drivers/clocksource/ directory.
Also, rename it to more generic name omap-32k.c.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/timer.c | 17 ---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/counter_32k.c | 154
drivers/clocksource/Makefile |1 +
drivers/clocksource/omap-32k.c | 210 ++
include/linux/clocksource.h |1 +
6 files changed, 213 insertions(+), 172 deletions(-)
delete mode 100644 arch/arm/plat-omap/counter_32k.c
create mode 100644 drivers/clocksource/omap-32k.c
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index bfae81b..46b81df 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -233,22 +233,6 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
gptimer_id, clkev.rate);
}
-/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -307,7 +291,6 @@ static void __init omap2_gp_clocksource_init(int gptimer_id,
pr_err(Could not register clocksource %s\n,
clocksource_gpt.name);
}
-#endif
#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, \
clksrc_nr, clksrc_src) \
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b35bb93 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
-usb.o fb.o counter_32k.o
+usb.o fb.o
obj-m :=
obj-n :=
obj- :=
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
deleted file mode 100644
index a6cbb71..000
--- a/arch/arm/plat-omap/counter_32k.c
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * OMAP 32ksynctimer/counter_32k-related code
- *
- * Copyright (C) 2009 Texas Instruments
- * Copyright (C) 2010 Nokia Corporation
- * Tony Lindgren t...@atomide.com
- * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * NOTE: This timer is not the same timer as the old OMAP1 MPU timer.
- */
-#include linux/kernel.h
-#include linux/init.h
-#include linux/clk.h
-#include linux/err.h
-#include linux/io.h
-#include linux/sched.h
-#include linux/clocksource.h
-
-#include asm/sched_clock.h
-
-#include plat/common.h
-#include plat/board.h
-
-#include plat/clock.h
-
-/*
- * 32KHz clocksource ... always available, on pretty most chips except
- * OMAP 730 and 1510. Other timers could be used as clocksources, with
- * higher resolution in free-running counter modes (e.g. 12 MHz xtal),
- * but systems won't necessarily want to spend resources that way.
- */
-static void __iomem *timer_32k_base;
-
-#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
-
-/*
- * Returns current time from boot in nsecs. It's OK for this to wrap
- * around for now, as it's just a relative time stamp.
- */
-static DEFINE_CLOCK_DATA(cd);
-
-/*
- * Constants generated by clocks_calc_mult_shift(m, s, 32768, NSEC_PER_SEC,
60).
- * This gives a resolution of about 30us and a wrap period of about 36hrs.
- */
-#define SC_MULT40u
-#define SC_SHIFT 17
-
-static inline unsigned long long notrace _omap_32k_sched_clock(void)
-{
- u32 cyc = timer_32k_base ? __raw_readl(timer_32k_base) : 0;
- return cyc_to_fixed_sched_clock(cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
-}
-
-#if defined(CONFIG_OMAP_32K_TIMER) !defined(CONFIG_OMAP_MPU_TIMER)
-unsigned long long notrace sched_clock(void)
-{
- return _omap_32k_sched_clock();
-}
-#else
-unsigned long long notrace omap_32k_sched_clock(void)
-{
- return _omap_32k_sched_clock();
-}
-#endif
-
-static void notrace omap_update_sched_clock(void)
-{
- u32 cyc = timer_32k_base ? __raw_readl(timer_32k_base) : 0;
- update_sched_clock(cd, cyc, (u32)~0);
-}
-
-/**
- * read_persistent_clock - Return time from a persistent clock.
- *
- * Reads the time from a source which isn't disabled during PM, the
- * 32k sync timer. Convert the
[RFC PATCH 2/5] arm:omap2/3: Add idle_st bits for ST_32KSYNC timer
32k counter/timer driver has been migrated to use hwmod database now, so add missing idle_st bit for 32K Sync timer. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com --- arch/arm/mach-omap2/prcm-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 5aa5435..29955d5 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -177,6 +177,8 @@ /* PM_WKST_WKUP, CM_IDLEST_WKUP shared bits */ #define OMAP24XX_ST_GPIOS_SHIFT2 #define OMAP24XX_ST_GPIOS_MASK (1 2) +#define OMAP24XX_ST_32KSYNC_SHIFT 1 +#define OMAP24XX_ST_32KSYNC_MASK (1 1) #define OMAP24XX_ST_GPT1_SHIFT 0 #define OMAP24XX_ST_GPT1_MASK (1 0) @@ -307,6 +309,8 @@ #define OMAP3430_ST_SR1_MASK (1 6) #define OMAP3430_ST_GPIO1_SHIFT3 #define OMAP3430_ST_GPIO1_MASK (1 3) +#define OMAP3430_ST_32KSYNC_SHIFT 2 +#define OMAP3430_ST_32KSYNC_MASK (1 2) #define OMAP3430_ST_GPT12_SHIFT1 #define OMAP3430_ST_GPT12_MASK (1 1) #define OMAP3430_ST_GPT1_SHIFT 0 -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei ming@canonical.com wrote:
Hi Will and stephane,
On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei ming@canonical.com wrote:
Hi stephane Will,
On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
eran...@googlemail.com wrote:
See the dmesg from my 3.2 kernel:
[ 0.00] Booting Linux on physical CPU 0[ 0.00]
But if you test omap4 perf against -next kernel, pmu won't work because
the commit[1] may put 'emu_sys_clkdm' clock domain into HW_AUTO mode,
so writing pmu register may not take effect.
I have found the similar problem on cam clock domain before[2].
CD_EMU is very simliar with CD_CAM in the point below:
CD_EMU has no static or module wake-up dependency with any other clock
domain of the device.[3]
So the patch[4] can make omap4 pmu work on -next tree.
Shilimkar, care to comment on the patch[4]?
thanks,
--
Ming Lei
[1], commit 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
Author: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed Jan 5 22:03:17 2011 +0530
ARM: OMAP4: PM: Initialise all the clockdomains to supported states
Initialise hardware supervised mode for all clockdomains if it's
supported. Initiate sleep transition for other clockdomains,
if they are not being used.
[2], http://www.spinics.net/lists/linux-omap/msg61911.html
[3], 3.6.12.3 of OMAP4 TRM
[4],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
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: DSS2/PM on 3.2 broken?
On Wed, 2012-01-18 at 22:15 +1100, NeilBrown wrote: On Wed, 18 Jan 2012 09:13:59 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote: Having CPUIDLE makes the DSS2 problem worse: lots of [ 21.085113] omapdss DISPC error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled messages whenever the CPU isn't busy. I'm not sure if it is the case here, but DSS has restrictions about the max DSS clocks on different OPPs. For example, on OMAP4430 LCD clock maximum is 186MHz at OPP100, and 93MHz at OPP50. So it's a quite big drop, causing problems with all but the rather small displays. And the DSS driver doesn't have any support to handle this at the moment, as there isn't support in the PM framework to do this. I think the only way to handle this at the moment is for the DSS driver to set an arbitrarily high constraint on, say, mem throughput, and hope that it keeps the OMAP in the required OPP. Tomi This LCD panel on this device sets: .pixel_clock = 22000, in the struct omap_video_timings so I'm guessing that is 22MHz? No, that's the pixel clock. There are probably limitations on the pix clock also, but usually the problem is the functional clocks, which need to be n x pck, where n depends on the needs for scaling. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: Convert counter_32k clocksource driver to standard platform_driver and move it drivers/clocksource/ directory. Also, rename it to more generic name omap-32k.c. NAK. sched_clock is supposed to be available early. Platform device driver initialization is FAR too late. Note that some of the code you're moving has changed in current kernels. -- 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: oprofile and ARM A9 hardware counter
On Wed, Jan 18, 2012 at 7:39 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei ming@canonical.com wrote:
Hi Will and stephane,
On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei ming@canonical.com wrote:
Hi stephane Will,
On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
eran...@googlemail.com wrote:
See the dmesg from my 3.2 kernel:
[ 0.00] Booting Linux on physical CPU 0[ 0.00]
But if you test omap4 perf against -next kernel, pmu won't work because
the commit[1] may put 'emu_sys_clkdm' clock domain into HW_AUTO mode,
so writing pmu register may not take effect.
I have found the similar problem on cam clock domain before[2].
CD_EMU is very simliar with CD_CAM in the point below:
CD_EMU has no static or module wake-up dependency with any other clock
domain of the device.[3]
So the patch[4] can make omap4 pmu work on -next tree.
Shilimkar, care to comment on the patch[4]?
thanks,
--
Ming Lei
[1], commit 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
Author: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed Jan 5 22:03:17 2011 +0530
ARM: OMAP4: PM: Initialise all the clockdomains to supported states
Initialise hardware supervised mode for all clockdomains if it's
supported. Initiate sleep transition for other clockdomains,
if they are not being used.
[2], http://www.spinics.net/lists/linux-omap/msg61911.html
[3], 3.6.12.3 of OMAP4 TRM
[4],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
But why can this patch make omap4 pmu work? Without the patch,
there are no CTI interrupts generated for pmu irq.
thanks
--
Ming Lei
--
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: oprofile and ARM A9 hardware counter
On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei ming@canonical.com wrote:
On Wed, Jan 18, 2012 at 7:39 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei ming@canonical.com wrote:
Hi Will and stephane,
On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei ming@canonical.com wrote:
Hi stephane Will,
On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
eran...@googlemail.com wrote:
See the dmesg from my 3.2 kernel:
[ 0.00] Booting Linux on physical CPU 0[ 0.00]
But if you test omap4 perf against -next kernel, pmu won't work because
the commit[1] may put 'emu_sys_clkdm' clock domain into HW_AUTO mode,
so writing pmu register may not take effect.
I have found the similar problem on cam clock domain before[2].
CD_EMU is very simliar with CD_CAM in the point below:
CD_EMU has no static or module wake-up dependency with any other
clock
domain of the device.[3]
So the patch[4] can make omap4 pmu work on -next tree.
Shilimkar, care to comment on the patch[4]?
thanks,
--
Ming Lei
[1], commit 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
Author: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed Jan 5 22:03:17 2011 +0530
ARM: OMAP4: PM: Initialise all the clockdomains to supported states
Initialise hardware supervised mode for all clockdomains if it's
supported. Initiate sleep transition for other clockdomains,
if they are not being used.
[2], http://www.spinics.net/lists/linux-omap/msg61911.html
[3], 3.6.12.3 of OMAP4 TRM
[4],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
But why can this patch make omap4 pmu work? Without the patch,
there are no CTI interrupts generated for pmu irq.
Interesting. For me debugger works which also relies on Emulation domain.
Need to see why CTI is behaving like this.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: Convert counter_32k clocksource driver to standard platform_driver and move it drivers/clocksource/ directory. Also, rename it to more generic name omap-32k.c. NAK. sched_clock is supposed to be available early. Platform device driver initialization is FAR too late. Russell, Sched_clock is available very early during boot sequence. Initially gp-timer (dmtimer) will get registered as a clocksource. Please refer to the file mach-omap2/timer.c 32k_sync timer (omap-32k.c) will come get registered during arch_init. Just FYI, the way I tested it is, I used kernel parameter clocksourse=counter-32k, the switch from gp-timer to 32k timer will happen once it gets registered. Thanks, Vaibhav Note that some of the code you're moving has changed in current kernels. -- 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] lis3lv02d: Add STMicroelectronics lis33ldlh digital
On Tuesday 17 January 2012, AnilKumar, Chimata wrote:
Hi All,
Recalling the patch, provide the comments if there are any if not please
include
this patch to v3.3 kernel.
As Mark and Greg said, 3.4 would be appropriate.
+static ssize_t lis3lv02d_range_set(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t count)
+{
+ unsigned long range;
+
+ if (strict_strtoul(buf, 0, range))
+ return -EINVAL;
+
+ lis3_dev.g_range = range;
+ lis3lv02d_update_g_range(lis3_dev);
+
+ return count;
+}
+
static DEVICE_ATTR(selftest, S_IRUSR, lis3lv02d_selftest_show, NULL);
static DEVICE_ATTR(position, S_IRUGO, lis3lv02d_position_show, NULL);
static DEVICE_ATTR(rate, S_IRUGO | S_IWUSR, lis3lv02d_rate_show,
lis3lv02d_rate_set);
+static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, lis3lv02d_range_show,
+ lis3lv02d_range_set);
I think you need to document this new attribute in the Documentation
directory, unless I missed the other patch doing this.
On a more general topic, do we have a kernel-wide policy for accelerometer
drivers? AFAICT, we currently have three subsystems that contain
accelerometer drivers, plus a few ad-hoc ones like this, which is a
rather unpleasant situation. What I found are these:
$ git grep -l accelerometer drivers/ | manual_grep
drivers/hwmon/applesmc.c
(one hwmon sysfs attribute for x/y/z)
drivers/input/misc/adxl34x.c
(lots of sysfs attributes, input_report_key)
drivers/input/misc/cma3000_d0x.c
(input_report_abs)
drivers/input/misc/kxtj9.c
(input_report_abs, plus one aux sysfs attribute)
drivers/macintosh/ams/ams-core.c
(one sysfs attribute for x/y/z)
drivers/misc/lis3lv02d/
(multiple sysfs attributes)
drivers/platform/x86/hdaps.c
(multiple sysfs attributes, only x/y)
drivers/platform/x86/hp_accel.c
(hooks into drivers/misc/lis3lv02d/)
drivers/staging/iio/accel/kxsd9.c
(iio)
drivers/staging/iio/accel/sca3000_core.c
(iio plus extra attributes)
While I'm not blaming you for the current situation, but I think the
situation is no longer sustainable and we need to decide on one place
and interface for these to go in the long run so we don't grow even
more nonstandard interfaces.
Any opinions where they should live? input, iio or a new subsystem?
Arnd
--
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 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote: On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: Convert counter_32k clocksource driver to standard platform_driver and move it drivers/clocksource/ directory. Also, rename it to more generic name omap-32k.c. NAK. sched_clock is supposed to be available early. Platform device driver initialization is FAR too late. Russell, Sched_clock is available very early during boot sequence. Initially gp-timer (dmtimer) will get registered as a clocksource. Please refer to the file mach-omap2/timer.c 32k_sync timer (omap-32k.c) will come get registered during arch_init. Just FYI, the way I tested it is, I used kernel parameter clocksourse=counter-32k, the switch from gp-timer to 32k timer will happen once it gets registered. So please delete the sched_clock code from the 32k timer stuff you've moved to a platform driver. It will cause sched_clock to reset to zero, and that's bad news. Only one sched_clock() should ever be registered, and that should only be registered very early at boot time. -- 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 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 19:41:47, Russell King - ARM Linux wrote: On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote: On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: Convert counter_32k clocksource driver to standard platform_driver and move it drivers/clocksource/ directory. Also, rename it to more generic name omap-32k.c. NAK. sched_clock is supposed to be available early. Platform device driver initialization is FAR too late. Russell, Sched_clock is available very early during boot sequence. Initially gp-timer (dmtimer) will get registered as a clocksource. Please refer to the file mach-omap2/timer.c 32k_sync timer (omap-32k.c) will come get registered during arch_init. Just FYI, the way I tested it is, I used kernel parameter clocksourse=counter-32k, the switch from gp-timer to 32k timer will happen once it gets registered. So please delete the sched_clock code from the 32k timer stuff you've moved to a platform driver. It will cause sched_clock to reset to zero, and that's bad news. Oops...you are right, yes it may get reset to zero. Missed this point. Only one sched_clock() should ever be registered, and that should only be registered very early at boot time. I think this whole platform_driver approach will not work here, I have to cleanup existing plat-omap/counter-32k.c code only and add hwmod (eventually DT) support in it. I was also not fully convinced with this approach, just followed legacy code here; and that was the reason I have submitted patch-series as a RFC to initiate discussion and get some community opinion. Thanks Russell... Thanks, Vaibhav -- 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 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On 18/01/12 14:11, Russell King - ARM Linux wrote: On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote: On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: Convert counter_32k clocksource driver to standard platform_driver and move it drivers/clocksource/ directory. Also, rename it to more generic name omap-32k.c. NAK. sched_clock is supposed to be available early. Platform device driver initialization is FAR too late. Russell, Sched_clock is available very early during boot sequence. Initially gp-timer (dmtimer) will get registered as a clocksource. Please refer to the file mach-omap2/timer.c 32k_sync timer (omap-32k.c) will come get registered during arch_init. Just FYI, the way I tested it is, I used kernel parameter clocksourse=counter-32k, the switch from gp-timer to 32k timer will happen once it gets registered. So please delete the sched_clock code from the 32k timer stuff you've moved to a platform driver. It will cause sched_clock to reset to zero, and that's bad news. Only one sched_clock() should ever be registered, and that should only be registered very early at boot time. The kernel will WARN if two sched_clock() are registered. I hope this will be enough for people not to persist with such a thing... M. -- Jazz is not dead. It just smells funny... -- 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 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 19:55:51, Marc Zyngier wrote:
On 18/01/12 14:11, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote:
On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote:
Convert counter_32k clocksource driver to standard platform_driver
and move it drivers/clocksource/ directory.
Also, rename it to more generic name omap-32k.c.
NAK. sched_clock is supposed to be available early. Platform device
driver initialization is FAR too late.
Russell,
Sched_clock is available very early during boot sequence. Initially
gp-timer
(dmtimer) will get registered as a clocksource. Please refer to the file
mach-omap2/timer.c
32k_sync timer (omap-32k.c) will come get registered during arch_init.
Just FYI, the way I tested it is, I used kernel parameter
clocksourse=counter-32k, the switch from gp-timer to 32k timer
will happen once it gets registered.
So please delete the sched_clock code from the 32k timer stuff you've
moved to a platform driver. It will cause sched_clock to reset to zero,
and that's bad news.
Only one sched_clock() should ever be registered, and that should only be
registered very early at boot time.
The kernel will WARN if two sched_clock() are registered. I hope this
will be enough for people not to persist with such a thing...
Marc,
This code-snippet is not registering multiple sched_clock() functions,
Here we have 2 timers
- gp-timer (available on all devices)
- 32k-sync timer (may not available on all devices, like AM33xx)
So we are registering both the timers as a clocksource and kernel
Chooses one based on kernel-parameter or rating.
From sched_clock perspective, we have only one function exported in
mach-omap2/timer.c, which in-turn calls omap-32k.c timer api.
Something like this,
unsigned long long notrace sched_clock(void)
{
U32 cyc;
/* First call 32k-sync timer sched_clock() */
/* return 0 means, the device doesn't have 32k-sync timer available */
cyc = sched_clock_32k();
if (cyc)
return cyc;
/* Fall back to gp-timer approach */
}
So there is and will not be any warning from kernel here.
Thanks,
Vaibhav
M.
--
Jazz is not dead. It just smells funny...
--
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] lis3lv02d: Add STMicroelectronics lis33ldlh digital
Hi Arnd and all, The lis3lv02d driver was moved outside of drivers/hwmon to make it clear that we (hwmon/lm-sensors people) are not involved in maintaining this driver in any way. So please remove the lm-sensors list (and myself) from this discussion. Thanks, -- Jean Delvare -- 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 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On 18/01/12 14:38, Hiremath, Vaibhav wrote:
On Wed, Jan 18, 2012 at 19:55:51, Marc Zyngier wrote:
On 18/01/12 14:11, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote:
On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote:
Convert counter_32k clocksource driver to standard platform_driver
and move it drivers/clocksource/ directory.
Also, rename it to more generic name omap-32k.c.
NAK. sched_clock is supposed to be available early. Platform device
driver initialization is FAR too late.
Russell,
Sched_clock is available very early during boot sequence. Initially
gp-timer
(dmtimer) will get registered as a clocksource. Please refer to the file
mach-omap2/timer.c
32k_sync timer (omap-32k.c) will come get registered during arch_init.
Just FYI, the way I tested it is, I used kernel parameter
clocksourse=counter-32k, the switch from gp-timer to 32k timer
will happen once it gets registered.
So please delete the sched_clock code from the 32k timer stuff you've
moved to a platform driver. It will cause sched_clock to reset to zero,
and that's bad news.
Only one sched_clock() should ever be registered, and that should only be
registered very early at boot time.
The kernel will WARN if two sched_clock() are registered. I hope this
will be enough for people not to persist with such a thing...
Marc,
This code-snippet is not registering multiple sched_clock() functions,
Here we have 2 timers
- gp-timer (available on all devices)
- 32k-sync timer (may not available on all devices, like AM33xx)
So we are registering both the timers as a clocksource and kernel
Chooses one based on kernel-parameter or rating.
From sched_clock perspective, we have only one function exported in
mach-omap2/timer.c, which in-turn calls omap-32k.c timer api.
Something like this,
unsigned long long notrace sched_clock(void)
{
U32 cyc;
/* First call 32k-sync timer sched_clock() */
/* return 0 means, the device doesn't have 32k-sync timer available */
cyc = sched_clock_32k();
if (cyc)
return cyc;
/* Fall back to gp-timer approach */
}
So there is and will not be any warning from kernel here.
Can't you instead use the ARM sched_clock framework? Please have a look
at what's currently in mainline (we basically register a read() function
with the sched_clock framework).
A per-platform sched_clock() is a step backward for the single zImage
work, and I really want to avoid this.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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: OMAP4: Add support for Variscite OMAP4460 System-On-Module
From: Uri Yosef u...@embedox.com
Add support for Variscite OMAP4460 System-On-Module and development kit board.
Working: LCD, HDMI, USB, UART, Ethernet.
Signed-off-by: Uri Yosef ur...@variscite.com
---
arch/arm/mach-omap2/Kconfig |8 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-var-som-om44.c | 490 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
drivers/usb/musb/Kconfig |2 +-
5 files changed, 501 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-var-som-om44.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a8ba7b9..894b284 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -345,6 +345,14 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE
+config MACH_VAR_SOM_OM44
+ bool Variscite OMAP4 SOM
+ default y
+ depends on ARCH_OMAP4
+ select OMAP_PACKAGE_CBL
+ select OMAP_PACKAGE_CBS
+ select REGULATOR_FIXED_VOLTAGE
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fc9b238..3a38830 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -228,6 +228,7 @@ obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o
obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o
+obj-$(CONFIG_MACH_VAR_SOM_OM44)+= board-var-som-om44.o
obj-$(CONFIG_MACH_PCM049) += board-omap4pcm049.o
diff --git a/arch/arm/mach-omap2/board-var-som-om44.c
b/arch/arm/mach-omap2/board-var-som-om44.c
new file mode 100644
index 000..34aa7ca
--- /dev/null
+++ b/arch/arm/mach-omap2/board-var-som-om44.c
@@ -0,0 +1,490 @@
+/*
+ * Board support file for Variscite OMAP4 System-On-Module.
+ *
+ * Copyright (C) 2011 Variscite
+ *
+ * Author: Uri Yosef ur...@variscite.com
+ *
+ * Based on mach-omap2/board-omap4panda.c
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Based on mach-omap2/board-4430sdp.c
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Based on mach-omap2/board-3430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+#include linux/spi/spi.h
+#include linux/i2c/twl.h
+#include linux/gpio_keys.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+
+#include mach/hardware.h
+#include asm/hardware/gic.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include video/omapdss.h
+
+#include plat/board.h
+#include common.h
+#include plat/usb.h
+#include plat/mmc.h
+#include video/omap-panel-generic-dpi.h
+
+#include hsmmc.h
+#include control.h
+#include mux.h
+#include common-board-devices.h
+
+#define GPIO_HUB_NRESET177
+#define GPIO_LCD_POWER_DOWN122
+#define GPIO_KEY_BACK 184
+#define HDMI_GPIO_HPD 63 /* Hot plug pin for HDMI */
+#define ETH_KS8851_IRQ 171
+
+/* GPIO key */
+static struct gpio_keys_button var_som_gpio_keys[] = {
+ {
+ .desc = Back,
+ .code = KEY_BACK,
+ .gpio = GPIO_KEY_BACK,
+ .active_low = 1,
+ }
+};
+
+static struct gpio_keys_platform_data var_som_gpio_keys_data = {
+ .buttons= var_som_gpio_keys,
+ .nbuttons = ARRAY_SIZE(var_som_gpio_keys),
+};
+
+static struct platform_device var_som_gpio_keys_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = var_som_gpio_keys_data,
+ },
+};
+
+/* USB */
+static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+ .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
+ .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
+ .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+ .phy_reset = false,
+ .reset_gpio_port[0] = -EINVAL,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
+
+static struct gpio var_som_ehci_gpios[] __initdata = {
+ { GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, hub_nreset },
+};
+
+static void __init omap4_ehci_init(void)
+{
+ int ret;
+ struct clk *phy_ref_clk;
+
+ /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+ phy_ref_clk = clk_get(NULL, auxclk3_ck);
+ if (IS_ERR(phy_ref_clk)) {
+ pr_err(Cannot
Re: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
On Wednesday 18 January 2012, Jean Delvare wrote: Hi Arnd and all, The lis3lv02d driver was moved outside of drivers/hwmon to make it clear that we (hwmon/lm-sensors people) are not involved in maintaining this driver in any way. So please remove the lm-sensors list (and myself) from this discussion. Ok, I see. What about the applesmc driver then? If we come up with a solution that works for the other drivers, should the accelerometer part of that be converted to use that interface? Arnd -- 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 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 02:45:36PM +, Marc Zyngier wrote: Can't you instead use the ARM sched_clock framework? OMAP does, and has done for quite some time. The problem is these patches are against an old 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] lis3lv02d: Add STMicroelectronics lis33ldlh digital
On Wed, 18 Jan 2012 14:49:35 +, Arnd Bergmann wrote: On Wednesday 18 January 2012, Jean Delvare wrote: Hi Arnd and all, The lis3lv02d driver was moved outside of drivers/hwmon to make it clear that we (hwmon/lm-sensors people) are not involved in maintaining this driver in any way. So please remove the lm-sensors list (and myself) from this discussion. Ok, I see. What about the applesmc driver then? If we come up with a solution that works for the other drivers, should the accelerometer part of that be converted to use that interface? Yes of course. -- Jean Delvare -- 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] lis3lv02d: Add STMicroelectronics lis33ldlh digital
Arnd Bergmann a...@arndb.de wrote:
On Tuesday 17 January 2012, AnilKumar, Chimata wrote:
Hi All,
Recalling the patch, provide the comments if there are any if not
please include
this patch to v3.3 kernel.
As Mark and Greg said, 3.4 would be appropriate.
+static ssize_t lis3lv02d_range_set(struct device *dev,
+struct device_attribute *attr, const char *buf,
+size_t count)
+{
+unsigned long range;
+
+if (strict_strtoul(buf, 0, range))
+return -EINVAL;
+
+lis3_dev.g_range = range;
+lis3lv02d_update_g_range(lis3_dev);
+
+return count;
+}
+
static DEVICE_ATTR(selftest, S_IRUSR, lis3lv02d_selftest_show,
NULL);
static DEVICE_ATTR(position, S_IRUGO, lis3lv02d_position_show,
NULL);
static DEVICE_ATTR(rate, S_IRUGO | S_IWUSR, lis3lv02d_rate_show,
lis3lv02d_rate_set);
+static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, lis3lv02d_range_show,
+lis3lv02d_range_set);
I think you need to document this new attribute in the Documentation
directory, unless I missed the other patch doing this.
On a more general topic, do we have a kernel-wide policy for
accelerometer
drivers? AFAICT, we currently have three subsystems that contain
accelerometer drivers, plus a few ad-hoc ones like this, which is a
rather unpleasant situation. What I found are these:
$ git grep -l accelerometer drivers/ | manual_grep
drivers/hwmon/applesmc.c
(one hwmon sysfs attribute for x/y/z)
drivers/input/misc/adxl34x.c
(lots of sysfs attributes, input_report_key)
drivers/input/misc/cma3000_d0x.c
(input_report_abs)
drivers/input/misc/kxtj9.c
(input_report_abs, plus one aux sysfs attribute)
drivers/macintosh/ams/ams-core.c
(one sysfs attribute for x/y/z)
drivers/misc/lis3lv02d/
(multiple sysfs attributes)
drivers/platform/x86/hdaps.c
(multiple sysfs attributes, only x/y)
drivers/platform/x86/hp_accel.c
(hooks into drivers/misc/lis3lv02d/)
drivers/staging/iio/accel/kxsd9.c
(iio)
drivers/staging/iio/accel/sca3000_core.c
(iio plus extra attributes)
For what it is worth there are a total of nine iio acceleration drivers. Some
are special purpose though.
While I'm not blaming you for the current situation, but I think the
situation is no longer sustainable and we need to decide on one place
and interface for these to go in the long run so we don't grow even
more nonstandard interfaces.
Any opinions where they should live? input, iio or a new subsystem?
Personal thought is that straight 3d devices very directed at input should go
there. Iio has a few wrinkles left for the in kernel interfaces needed for a
bridge to input. For starters the pull and push data interfaces have not merged
yet (in staging) and we have not started on in kernel acess to non data events
yet(thresholds). Still happy to take them when we can support usecases fully.
Of course any help getting there would be most welcome!
Jonathan
Arnd
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
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] lis3lv02d: Add STMicroelectronics lis33ldlh digital
On Wednesday 18 January 2012, Jonathan Cameron wrote: Arnd Bergmann a...@arndb.de wrote: Any opinions where they should live? input, iio or a new subsystem? Personal thought is that straight 3d devices very directed at input should go there. Iio has a few wrinkles left for the in kernel interfaces needed for a bridge to input. For starters the pull and push data interfaces have not merged yet (in staging) and we have not started on in kernel acess to non data events yet(thresholds). Still happy to take them when we can support usecases fully. Ok, thanks for the information, sounds all reasonable. I think we can definitely say no to new accelerometer drivers in drivers/misc then and refer them to iio and input. In case of lis33ldlh, I would like to see it move out at some point once the necessary parts of iio have graduated out of staging. Hopefully it won't be a large amount of work to convert it to a different internal API. AnilKumar, what are the existing users of the driver? Is it still possible to convert them to use iio without causing problems for people that rely on this driver, or do we have to keep supporting the current interface? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2/PM on 3.2 broken?
On Wed, 18 Jan 2012 13:42:20 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-01-18 at 22:15 +1100, NeilBrown wrote: On Wed, 18 Jan 2012 09:13:59 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote: Having CPUIDLE makes the DSS2 problem worse: lots of [ 21.085113] omapdss DISPC error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled messages whenever the CPU isn't busy. I'm not sure if it is the case here, but DSS has restrictions about the max DSS clocks on different OPPs. For example, on OMAP4430 LCD clock maximum is 186MHz at OPP100, and 93MHz at OPP50. So it's a quite big drop, causing problems with all but the rather small displays. And the DSS driver doesn't have any support to handle this at the moment, as there isn't support in the PM framework to do this. I think the only way to handle this at the moment is for the DSS driver to set an arbitrarily high constraint on, say, mem throughput, and hope that it keeps the OMAP in the required OPP. Tomi This LCD panel on this device sets: .pixel_clock = 22000, in the struct omap_video_timings so I'm guessing that is 22MHz? No, that's the pixel clock. There are probably limitations on the pix clock also, but usually the problem is the functional clocks, which need to be n x pck, where n depends on the needs for scaling. Ahh.. cat /sys/kernel/debug/omapdss/clk is below and reports 66461538 for fck, so 66MHz? Still safe for OPP50. And disabling SMART REFLEX had no obvious effect. If you can think of anything else I could try to explore to narrow down the source of this, I am very happy to test or examine anything you suggest. Thanks, NeilBrown - DSS - dpll4_ck 86400 DSS_FCK (DSS1_ALWON_FCLK) = 86400 / 13 = 66461538 - DISPC - dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) fck 66461538 - LCD1 - lcd1_clk source = DSS_FCK (DSS1_ALWON_FCLK) lck 66461538lck div 1 pck 22153846pck div 3 - DSI1 PLL - dsi pll source = pclkfree Fint0 regn 0 CLKIN4DDR 0 regm 0 DSS_FCK (DSS1_ALWON_FCLK) 0 regm_dispc 0(off) DSS_FCK (DSS1_ALWON_FCLK) 0 regm_dsi 0 (off) - DSI1 - dsi fclk source = DSS_FCK (DSS1_ALWON_FCLK) DSI_FCLK66461538 DDR_CLK 0 TxByteClkHS 0 LP_CLK 0 signature.asc Description: PGP signature
Re: [PATCH 1/2] arm:omap2:board-generic: Add DT support for AM33xx devices
On Wed, Jan 18, 2012 at 12:43:58PM +0530, Vaibhav Hiremath wrote:
Although we consider am33xx device under omap34xx family of devices,
there is indeed difference between them, for example,
- Initial required mapping (-map_io)
- Early init (-init_early)
Here, the whole sequence/data is different than omap3,
For example, clock/hwmod/power/voltage data.
- clock event/source timer (name and instances)
So, this patch adds seperate machine descriptor for AM33XX family
of devices in board-generic.c file.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
CC: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tony Lindgren t...@atomide.com
---
Tested it on AM335x-EVM, AM37xEVM and AM3517EVM.
arch/arm/mach-omap2/board-generic.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index f7b4b24..2faecc8 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -106,6 +106,25 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
MACHINE_END
#endif
+#if defined(CONFIG_SOC_OMAPAM33XX)
+static const char *am33xx_boards_compat[] __initdata = {
+ ti,am33xx,
Don't forget to add the new compatible values to
Documentation/device-tree/bindings.
+ NULL,
+};
+
+DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree))
+ .atag_offset= 0x100,
Unneeded for DT booting.
Otherwise, you can add:
Acked-by: Grant Likely grant.lik...@secretlab.ca
+ .reserve= omap_reserve,
+ .map_io = am33xx_map_io,
+ .init_early = am33xx_init_early,
+ .init_irq = omap_init_irq,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .timer = omap3_am33xx_timer,
+ .dt_compat = am33xx_boards_compat,
+MACHINE_END
+#endif
+
#if defined(CONFIG_ARCH_OMAP4)
static const char *omap4_boards_compat[] __initdata = {
ti,omap4,
--
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] lis3lv02d: Add STMicroelectronics lis33ldlh digital
Hi Arnd,
What do you mean with kernel-wide policy for accelerometer drivers?
As far as I know, accelerometer drivers are written between the i2c driver and
the
input driver.
The input driver provides already some accelerometer specific event types,
ABS_X, ABS_Y, ABS_Z,
in your opinion isn't it enough?
If you mean something like collecting common properties like g range or
frequency or whatever in a
standard interface, then I think that accelerometers are quite different as
devices and sometimes
it could be difficult to arrange a common interface.
Andi
On Wed, Jan 18, 2012 at 02:03:47PM +, Arnd Bergmann wrote:
On Tuesday 17 January 2012, AnilKumar, Chimata wrote:
Hi All,
Recalling the patch, provide the comments if there are any if not please
include
this patch to v3.3 kernel.
As Mark and Greg said, 3.4 would be appropriate.
+static ssize_t lis3lv02d_range_set(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t count)
+{
+ unsigned long range;
+
+ if (strict_strtoul(buf, 0, range))
+ return -EINVAL;
+
+ lis3_dev.g_range = range;
+ lis3lv02d_update_g_range(lis3_dev);
+
+ return count;
+}
+
static DEVICE_ATTR(selftest, S_IRUSR, lis3lv02d_selftest_show, NULL);
static DEVICE_ATTR(position, S_IRUGO, lis3lv02d_position_show, NULL);
static DEVICE_ATTR(rate, S_IRUGO | S_IWUSR, lis3lv02d_rate_show,
lis3lv02d_rate_set);
+static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, lis3lv02d_range_show,
+ lis3lv02d_range_set);
I think you need to document this new attribute in the Documentation
directory, unless I missed the other patch doing this.
On a more general topic, do we have a kernel-wide policy for accelerometer
drivers? AFAICT, we currently have three subsystems that contain
accelerometer drivers, plus a few ad-hoc ones like this, which is a
rather unpleasant situation. What I found are these:
$ git grep -l accelerometer drivers/ | manual_grep
drivers/hwmon/applesmc.c
(one hwmon sysfs attribute for x/y/z)
drivers/input/misc/adxl34x.c
(lots of sysfs attributes, input_report_key)
drivers/input/misc/cma3000_d0x.c
(input_report_abs)
drivers/input/misc/kxtj9.c
(input_report_abs, plus one aux sysfs attribute)
drivers/macintosh/ams/ams-core.c
(one sysfs attribute for x/y/z)
drivers/misc/lis3lv02d/
(multiple sysfs attributes)
drivers/platform/x86/hdaps.c
(multiple sysfs attributes, only x/y)
drivers/platform/x86/hp_accel.c
(hooks into drivers/misc/lis3lv02d/)
drivers/staging/iio/accel/kxsd9.c
(iio)
drivers/staging/iio/accel/sca3000_core.c
(iio plus extra attributes)
While I'm not blaming you for the current situation, but I think the
situation is no longer sustainable and we need to decide on one place
and interface for these to go in the long run so we don't grow even
more nonstandard interfaces.
Any opinions where they should live? input, iio or a new subsystem?
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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: oprofile and ARM A9 hardware counter
Ming, Ok, so I used Linus' tree @ It already includes patches #1 and #2. I applied 4-6. Recompiled but my kernel does not boot, I don't see anything on the serial console. Could be a broken .config file. Could you send me your .config for Panda? Thanks. On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei ming@canonical.com wrote: Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian eran...@googlemail.com Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f -- 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: OMAP4: clock: fix mult and div mask for USB_DPLL
Signed-off-by: Ameya Palande ameya.pala...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..053cc15 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -953,8 +953,8 @@ static struct dpll_data dpll_usb_dd = {
.modes = (1 DPLL_LOW_POWER_BYPASS) | (1 DPLL_LOCKED),
.autoidle_reg = OMAP4430_CM_AUTOIDLE_DPLL_USB,
.idlest_reg = OMAP4430_CM_IDLEST_DPLL_USB,
- .mult_mask = OMAP4430_DPLL_MULT_MASK,
- .div1_mask = OMAP4430_DPLL_DIV_MASK,
+ .mult_mask = OMAP4430_DPLL_MULT_USB_MASK,
+ .div1_mask = OMAP4430_DPLL_DIV_0_7_MASK,
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
--
1.7.4.1
--
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: oprofile and ARM A9 hardware counter
Hi, On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian eran...@googlemail.com wrote: Ming, Ok, so I used Linus' tree @ It already includes patches #1 and #2. I applied 4-6. The patch #3 is missed? Recompiled but my kernel does not boot, I don't see anything on the serial console. Could be a broken I don't think that the patches can cause your non boot, you can try the linus tree kernel first, then try the patches. .config file. Could you send me your .config for Panda? See the attachment. Thanks. On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei ming@canonical.com wrote: Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian eran...@googlemail.com Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f -- 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 conf.tar.gz Description: GNU Zip compressed data
RE: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
Hi Arnd, On Wed, Jan 18, 2012 at 22:41:15, Arnd Bergmann wrote: On Wednesday 18 January 2012, Jonathan Cameron wrote: Arnd Bergmann a...@arndb.de wrote: Any opinions where they should live? input, iio or a new subsystem? Personal thought is that straight 3d devices very directed at input should go there. Iio has a few wrinkles left for the in kernel interfaces needed for a bridge to input. For starters the pull and push data interfaces have not merged yet (in staging) and we have not started on in kernel acess to non data events yet(thresholds). Still happy to take them when we can support usecases fully. Ok, thanks for the information, sounds all reasonable. I think we can definitely say no to new accelerometer drivers in drivers/misc then and refer them to iio and input. In case of lis33ldlh, I would like to see it move out at some point once the necessary parts of iio have graduated out of staging. Hopefully it won't be a large amount of work to convert it to a different internal API. AnilKumar, what are the existing users of the driver? Is it still possible to convert them to use iio without causing problems for people that rely on this driver, or do we have to keep supporting the current interface? Android userspace running on TI AM335x EVM is using the interface provided by lis3lv02d. They were asking some more interfaces from lis3lvo2d driver. There are multiple ways we can interface accelerometer to Android layers, which is implemented on hardware abstraction layer (HAL) in Andriod. 1) Interrupt mode 2) Polling mode 2a) Kernel polling 2b) Timer polling Based on the interfaces provided by the lis3lv02d as well as lis331dlh (H/W not supporting the interrupts) they were implementing the kernel polling mechanism. So implementation on HAL is like this if accelerometer interface is opened then kernel will start polling this driver periodically and pass events to input subsystem. (It's a little bit over head) Generally the device should be open but kernel should only poll when an app that uses accelerometer is started. The biggest requirement for them (Andriod people) is to allow user to enable / disable accelerometer from user space and to configure the accelerometer polling frequency. Today there is no option in lis3lvo2d driver to provide this kind of functionalities Arnd Regards AnilKumar
