RE: 4430SDP boot failure
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Friday, January 07, 2011 5:22 AM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: 4430SDP boot failure [..] OMAP44XX SDP # fatls mmc 0 1935000 uimage 149104 u-boot.bin 18984 mlo 1836636 uimage-test 1130288 uimage-ss 19040 mlo.old Invalid FAT entry 6 file(s), 0 dir(s) Invalid FAT entry ? I don't think so. The thing actually contains: -rwxr-xr-x. 1 rmk rmk 1935000 Feb 4 2010 uImage -rwxr-xr-x. 1 rmk rmk 149104 Feb 4 2010 u-boot.bin -rwxr-xr-x. 1 rmk rmk 18984 Jan 1 2000 mlo -rwxr-xr-x. 1 rmk rmk 1836636 Jan 6 21:35 uImage-test -rwxr-xr-x. 1 rmk rmk 1130288 Jan 1 2000 uImage-ss -rwxr-xr-x. 1 rmk rmk 19040 Feb 4 2010 mlo.old -rwxr-xr-x. 1 rmk rmk 154904 Jan 1 2000 u-boot.new [..] So, uboot's FAT code can't deal with a directory larger than one sector that doesn't continue. While we're here, lets confirm by hand that there's nothing wrong with the uImage-test file and it's yet again uboot being idiotic. [..] Can we _please_ have a version of uboot for the SDP4430 platform which can be configured at runtime _and_ which is capable of DHCP/TFTP ? I really don't want to mess about anymore with buggy boot loaders. Just read this thread. Looks like you are not able to boot the kernel at all. 2.6.37 + Tony's queue booted for me without any issues. I can give a try on 2.6.37. TFTP is already supported on the latest bootloaders. http://dev.omapzoom.org/?p=bootloader/u-boot.git;a=shortlog;h=refs/heads/o map4_dev Will send you binaries in another email. 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 v3] hwmon: twl4030: Driver for twl4030 madc module
On Thu, Jan 6, 2011 at 11:28 AM, Kalliguddi, Hema hem...@ti.com wrote: Keerthy, Minor comments... Regards, Hema On Thu, Jan 6, 2011 at 9:47 AM, Keerthy j-keer...@ti.com wrote: Introducing a driver for MADC on TWL4030 powerIC. MADC stands for monitoring ADC. This driver monitors the real time conversion of analog signals like battery temperature, battery type, battery level etc. User can also ask for the conversion on a particular channel using the sysfs nodes. Tested the conversion through sysfs nodes. Tested with DEBUG_LOCKDEP enabled. Signed-off-by: Keerthy j-keer...@ti.com --- Several people have contributed to this driver on the linux-omap list. V3: Return check added to all the functions reading and writing via i2c. In probe function reverting all the steps succeded before a failure and not reverting the step which failed. Added the declaration of twl4030_get_madc_conversion function in the header file. Formatting the header file. Comments added. likely occurance removed since it is not in the hot path. Renamed the_madc to twl4030_madc. Added sleep command to avoid busy wait in conversion ready function. V2: Error path correction in probe function. Return checks added. the_madc pointer could not be removed. The external drivers will not be knowing device information of the madc. Added another function which takes the channel number alone and returns the channel reading if the caller wants TWL4030_MADC_SW2 method for ADC conversion. IOCTL function is removed. Work struct is completely removed since request_threaded_irq is used. drivers/hwmon/Kconfig | 11 + drivers/hwmon/Makefile | 1 + drivers/hwmon/twl4030-madc.c | 794 ++ include/linux/i2c/twl4030-madc.h | 118 ++ 4 files changed, 924 insertions(+), 0 deletions(-) create mode 100644 drivers/hwmon/twl4030-madc.c create mode 100644 include/linux/i2c/twl4030-madc.h V1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34947.html diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index a56f6ad..eec1258 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -920,6 +920,17 @@ config SENSORS_TMP421 This driver can also be built as a module. If so, the module will be called tmp421. +config SENSORS_TWL4030_MADC + tristate Texas Instrments TWL4030 MADC + depends on TWL4030_CORE + help + This driver provides support for triton TWL4030-MADC. The + driver supports both RT and SW conversion methods. + + This driver can be built as part of kernel or can be built + as a module. + + Only on new line is enough Ok config SENSORS_VIA_CPUTEMP tristate VIA CPU temperature sensor depends on X86 diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 2479b3d..a54af22 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -100,6 +100,7 @@ obj-$(CONFIG_SENSORS_THMC50) += thmc50.o obj-$(CONFIG_SENSORS_TMP102) += tmp102.o obj-$(CONFIG_SENSORS_TMP401) += tmp401.o obj-$(CONFIG_SENSORS_TMP421) += tmp421.o +obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc.o obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o obj-$(CONFIG_SENSORS_VIA686A) += via686a.o obj-$(CONFIG_SENSORS_VT1211) += vt1211.o diff --git a/drivers/hwmon/twl4030-madc.c b/drivers/hwmon/twl4030-madc.c new file mode 100644 index 000..523f19a --- /dev/null +++ b/drivers/hwmon/twl4030-madc.c @@ -0,0 +1,794 @@ +/* + * + * TWL4030 MADC module driver-This driver monitors the real time + * conversion of analog signals like battery temperature, + * battery type, battery level etc. User can also ask for the conversion on a + * particular channel using the sysfs nodes. + * + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ + * J Keerthy j-keer...@ti.com + * + * Based on twl4030-madc.c + * Copyright (C) 2008 Nokia Corporation + * Mikko Ylinen mikko.k.yli...@nokia.com + * + * Amit Kucheria amit.kuche...@canonical.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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/interrupt.h +#include linux/delay.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/i2c/twl.h +#include
RE: [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Thursday, January 06, 2011 11:58 PM
To: Paul Walmsley
Cc: Santosh Shilimkar; linux-omap@vger.kernel.org; t...@atomide.com;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for
build break because of clktrctrl_mask
Paul Walmsley p...@pwsan.com writes:
On Wed, 5 Jan 2011, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
struct clockdomain member clktrctrl_mask is available for only for
OMAP2
and OMAP3 architectures. Technially it is also used only for these
archs
but this breaks the build with custom OMAP4 configuration.
I'll queue patches 3-5 for the 2.6.38-rc fixes cycle.
With Paul's ack, I can queue the others too, or Paul can decide to
take
them via his tree. Paul can decide.
I've acked one and requested minor changes on the other, after which
it
can be acked by me. You're welcome to take them at that point. Just
a
request, maybe you can post a branch with just these patches in them;
that
way Rajendra and/or I can rebase his new clockdomain changes on it
until
-rc1 comes out.
Sure, will do.
Just another trivial fix.
From bb46b74d2b0ab3d35e72b760da7e123a891e6813 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Fri, 7 Jan 2011 14:07:25 +0530
Subject: [PATCH] OMAP: powerdomain: remove unused func declaration
Trivial fix to remove the unused function declaration
from the powerdomain header.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/powerdomain.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index c66431e..0b7a357 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -165,7 +165,6 @@ struct pwrdm_ops {
int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
};
-void pwrdm_fw_init(void);
void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_ops
*custom_funcs);
struct powerdomain *pwrdm_lookup(const char *name);
--
1.7.0.4
I currently have a 'fixes-for-tony' branch in my tree which has all the
fixes I've collected for the -rc cycle.
If you prefer something separate with only the prm and clockdomain
patches from this series, I can do that as well.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
0001-OMAP-powerdomain-remove-unused-func-declaration.patch
Description: Binary data
RE: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, January 06, 2011 11:28 PM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
for undefined reference to 'omap2_prm_read_mod_reg'
Hi Santosh
On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
omap2plus_defocnfig build breaks when customised with only
ARCH_OMAP4
selected. This is because common files make references to the
functions
which are defined only for omap2xxx and omap3xxx.
...
This patch adds stubs for these functions so that build continues
to work.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.h | 63
+++-
1 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h b/arch/arm/mach-
omap2/prm2xxx_3xxx.h
index 53d44f6..843f329 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -228,7 +228,67 @@
#ifndef __ASSEMBLER__
-
+/*
+ * Stub omap2xxx/omap3xxx functions so that common files
+ * continue to build when custom builds are used
+ */
+#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) ||
\
+ defined(CONFIG_ARCH_OMAP3))
+static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
+{
+ WARN_ONCE(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
I think it would be best to use WARN() on these, rather than
WARN_ONCE().
That's because these could be called from different parts of the
code
base, and the stack backtrace will help someone figure out all the
code
that needs to be fixed.
Ok.
Once you do that, this patch is
Acked-by: Paul Walmsley p...@pwsan.com
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
RE: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 06, 2011 11:56 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM Hi Santosh, On Wed, 5 Jan 2011, Santosh Shilimkar wrote: Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism' introduced watchdog timer state state management using postsetup_state. This was done to allow some board files to support watchdog coverage throughout kernel initialization and it work as intended when RUNTIME_PM is enabled. With !CONFIG_RUNTIME_PM and no board is specifically requests watchdog to remain enabled the omap_wdt_probe crashesh. This is because hwmod in absense of runtime PM unable to turn watchdog clocks because it's state is set to be disabled. For rest of the device, the state is set as enabled in absense of RUNTIME_PM [1.372558] Unhandled fault: imprecise external abort (0x1406) at 0xad733eeb [1.379913] Internal error: : 1406 [#1] SMP [1.384277] last sysfs file: [1.387359] Modules linked in: [1.390563] CPU: 0Tainted: GW(2.6.37-rc7-00265- g4298a4c-dirty #23) [1.398468] PC is at omap_wdt_disable+0x2c/0x3c [1.403198] LR is at omap_wdt_probe+0x124/0x1e0 [1.407928] pc : [c02f5bf4]lr : [c03be10c]psr: 6013 [1.407958] sp : df833f00 ip : fp : [1.419921] r10: c0ac57ac r9 : df959e00 r8 : [1.425384] r7 : df959e08 r6 : df8000c0 r5 : df95bebc r4 : df87dde0 [1.432189] r3 : fc314000 r2 : r1 : fc314034 r0 : df87dde0 This patch make the default watchdog state to be enabled in case of !CONFIG_RUNTIME_PM. This fixes the crash Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Paul, I am not too sure if it breaks your _shutdown idea of watchdog timer. Maybe. What happens in a case where the bootloader enables the watchdog, but the booting kernel is compiled with !CONFIG_OMAP_WATCHDOG and !CONFIG_PM_RUNTIME? Won't the watchdog reset the MPU unexpectedly in that case? Or am I missing something... I had a same doubght. But the test I did with and without CONFIG_OMAP_WATCHDOG just at kernel level. The TI bootloader have MPU watchdog being always disabled. Will do a test on this scenario by explicitly disabling the MPU WDT in bootloader. 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 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
o lazy-disable state This is an odd state, and confusion regularly comes up ... I've never been a fan of having the imperatively named disable_irq() act like a disable_irq_at a_random_later_time_ _but_nyet(). If one must have the latter function, clearer IMO to name it better and have disable_irq() do exactly that by the time it returns ... that is after all what folk expect given its name and conventional interpretation of disable. (ergo confusion when that's not what happens) lazy_disable_irq() would be accurate, butI'm not sure many folk would choose to use it. - Dave -- 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
[RFT/PATCH v2 00/12] Retu meets GENIRQ
Hi all, Second try of moving Retu to GENIRQ + Threaded IRQ. For convenience, patches are also available at [1]. Compile tested only with omap2plus_defconfig + enabled CBUS and RETU support. [1] git://gitorious.org/usb/usb.git cbus Changes from v1: . add CBUS_RETU_IRQ_BASE and CBUS_RETU_IRQ_END . add a platform_data for retu . pass irq_base and irq_end via platform_data . first remove retu-user.c before doing anything else Felipe Balbi (12): cbus: retu: get rid of retu-user.c cbus: retu: give it a context structure cbus: retu: move module_* close to the matching symbol cbus: retu: cleanup error path arm: omap: irqs: add CBUS_RETU_IRQ_BASE and CBUS_RETU_IRQ_END arm: omap: cbus: pass irq_base and irq_end via platform_data cbus: retu: move to threaded IRQ and GENIRQ cbus: retu: headset: convert to threaded_irq cbus: retu-pwrbutton: convert to threaded irq cbus: retu-rtc: move to threaded irq cbus: retu-rtc: drop the reset_occurred flag cbus: Makefile: re-enable retu-wdt arch/arm/mach-omap1/board-nokia770.c |8 + arch/arm/mach-omap2/board-n8x0.c |8 + arch/arm/plat-omap/include/plat/cbus.h |5 + arch/arm/plat-omap/include/plat/irqs.h | 10 +- drivers/cbus/Kconfig |7 - drivers/cbus/Makefile |4 +- drivers/cbus/retu-headset.c| 22 +- drivers/cbus/retu-pwrbutton.c | 37 +-- drivers/cbus/retu-rtc.c| 130 ++- drivers/cbus/retu-user.c | 424 drivers/cbus/retu.c| 394 ++ drivers/cbus/retu.h| 12 - 12 files changed, 259 insertions(+), 802 deletions(-) delete mode 100644 drivers/cbus/retu-user.c -- 1.7.3.4.598.g85356 -- 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
[RFT/PATCH v2 01/12] cbus: retu: get rid of retu-user.c
Drop that non-standard of accessing Retu
as it's bypassing all the correct layers.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/Kconfig |7 -
drivers/cbus/Makefile|1 -
drivers/cbus/retu-user.c | 424 --
drivers/cbus/retu.c | 19 --
drivers/cbus/retu.h |5 -
5 files changed, 0 insertions(+), 456 deletions(-)
delete mode 100644 drivers/cbus/retu-user.c
diff --git a/drivers/cbus/Kconfig b/drivers/cbus/Kconfig
index c6b39fb..9a827a2 100644
--- a/drivers/cbus/Kconfig
+++ b/drivers/cbus/Kconfig
@@ -49,13 +49,6 @@ config CBUS_RETU
If you want Retu support, you should say Y here.
-config CBUS_RETU_USER
- depends on CBUS_RETU
- bool Support for Retu user space functions
- ---help---
- If you want support for Retu's user space read/write etc. functions,
- you should say Y here.
-
config CBUS_RETU_POWERBUTTON
depends on CBUS_RETU
bool Support for Retu power button
diff --git a/drivers/cbus/Makefile b/drivers/cbus/Makefile
index 347c2a4..0ad112f 100644
--- a/drivers/cbus/Makefile
+++ b/drivers/cbus/Makefile
@@ -10,5 +10,4 @@ obj-$(CONFIG_CBUS_RETU_POWERBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_CBUS_RETU_RTC)+= retu-rtc.o
obj-$(CONFIG_CBUS_RETU_WDT)+= retu-wdt.o
obj-$(CONFIG_CBUS_TAHVO_USER) += tahvo-user.o
-obj-$(CONFIG_CBUS_RETU_USER) += retu-user.o
obj-$(CONFIG_CBUS_RETU_HEADSET)+= retu-headset.o
diff --git a/drivers/cbus/retu-user.c b/drivers/cbus/retu-user.c
deleted file mode 100644
index c36f356..000
--- a/drivers/cbus/retu-user.c
+++ /dev/null
@@ -1,424 +0,0 @@
-/**
- * drivers/cbus/retu-user.c
- *
- * Retu user space interface functions
- *
- * Copyright (C) 2004, 2005 Nokia Corporation
- *
- * Written by Mikko Ylinen mikko.k.yli...@nokia.com
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License. See the file COPYING in the main directory of this
- * archive for more details.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include linux/types.h
-#include linux/kernel.h
-#include linux/slab.h
-#include linux/interrupt.h
-#include linux/module.h
-#include linux/init.h
-#include linux/fs.h
-#include linux/miscdevice.h
-#include linux/poll.h
-#include linux/list.h
-#include linux/spinlock.h
-#include linux/sched.h
-#include linux/mutex.h
-
-#include asm/uaccess.h
-
-#include retu.h
-
-#include user_retu_tahvo.h
-
-/* Maximum size of IRQ node buffer/pool */
-#define RETU_MAX_IRQ_BUF_LEN 16
-
-#define PFXretu-user:
-
-/* Bitmap for marking the interrupt sources as having the handlers */
-static u32 retu_irq_bits;
-
-/* For allowing only one user process to subscribe to the retu interrupts */
-static struct file *retu_irq_subscr = NULL;
-
-/* For poll and IRQ passing */
-struct retu_irq {
- u32 id;
- struct list_head node;
-};
-
-static spinlock_t retu_irqs_lock;
-static struct retu_irq *retu_irq_block;
-static LIST_HEAD(retu_irqs);
-static LIST_HEAD(retu_irqs_reserve);
-
-/* Wait queue - used when user wants to read the device */
-DECLARE_WAIT_QUEUE_HEAD(retu_user_waitqueue);
-
-/* Semaphore to protect irq subscription sequence */
-static struct mutex retu_mutex;
-
-/* This array specifies RETU register types (read/write/toggle) */
-static const u8 retu_access_bits[] = {
- 1,
- 4,
- 3,
- 3,
- 1,
- 3,
- 3,
- 0,
- 3,
- 3,
- 3,
- 3,
- 3,
- 3,
- 3,
- 4,
- 4,
- 3,
- 0,
- 0,
- 0,
- 0,
- 1,
- 3,
- 3,
- 3,
- 3,
- 3,
- 3,
- 3,
- 3,
- 3
-};
-
-/*
- * The handler for all RETU interrupts.
- *
- * arg is the interrupt source in RETU.
- */
-static void retu_user_irq_handler(unsigned long arg)
-{
- struct retu_irq *irq;
-
- retu_ack_irq(arg);
-
- spin_lock(retu_irqs_lock);
- if (list_empty(retu_irqs_reserve)) {
- spin_unlock(retu_irqs_lock);
- return;
- }
- irq = list_entry((retu_irqs_reserve)-next, struct retu_irq, node);
- irq-id = arg;
- list_move_tail(irq-node, retu_irqs);
- spin_unlock(retu_irqs_lock);
-
- /* wake up waiting thread */
- wake_up(retu_user_waitqueue);
-}
-
-/*
- * This routine sets up the interrupt handler and marks an interrupt source
- * in RETU as a candidate for signal delivery to the user process.
- */
-static int retu_user_subscribe_to_irq(int
[RFT/PATCH v2 02/12] cbus: retu: give it a context structure
This is pretty much a cleanup patch just
adding a context structure for Retu, to avoid
all the globals it had.
Note that this breaks retu-user.c due to moving
the lock around, but that retu-user.c has to
go anyway as it's completely non-standard way
of accessing Retu children.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c | 123 ++-
drivers/cbus/retu.h |2 -
2 files changed, 82 insertions(+), 43 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index f44d770..39d4fa4 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -26,6 +26,7 @@
#include linux/module.h
#include linux/init.h
+#include linux/slab.h
#include linux/kernel.h
#include linux/errno.h
#include linux/device.h
@@ -49,11 +50,18 @@
#define RETU_ID0x01
#define PFXretu:
-static int retu_initialized;
-static int retu_is_vilma;
+struct retu {
+ /* Device lock */
+ spinlock_t lock;
+ struct tasklet_struct tasklet;
+ struct device *dev;
-static struct tasklet_struct retu_tasklet;
-spinlock_t retu_lock = SPIN_LOCK_UNLOCKED;
+ int irq;
+
+ boolis_vilma;
+};
+
+static struct retu *the_retu;
struct retu_irq_handler_desc {
int (*func)(unsigned long);
@@ -65,7 +73,7 @@ static struct retu_irq_handler_desc
retu_irq_handlers[MAX_RETU_IRQ_HANDLERS];
int retu_get_status(void)
{
- return retu_initialized;
+ return the_retu ? 1 : 0;
}
EXPORT_SYMBOL(retu_get_status);
@@ -77,7 +85,7 @@ EXPORT_SYMBOL(retu_get_status);
*/
int retu_read_reg(unsigned reg)
{
- BUG_ON(!retu_initialized);
+ BUG_ON(!the_retu);
return cbus_read_reg(RETU_ID, reg);
}
EXPORT_SYMBOL(retu_read_reg);
@@ -91,22 +99,23 @@ EXPORT_SYMBOL(retu_read_reg);
*/
void retu_write_reg(unsigned reg, u16 val)
{
- BUG_ON(!retu_initialized);
+ BUG_ON(!the_retu);
cbus_write_reg(RETU_ID, reg, val);
}
EXPORT_SYMBOL(retu_write_reg);
void retu_set_clear_reg_bits(unsigned reg, u16 set, u16 clear)
{
- unsigned long flags;
- u16 w;
+ struct retu *retu = the_retu;
+ unsigned long flags;
+ u16 w;
- spin_lock_irqsave(retu_lock, flags);
+ spin_lock_irqsave(retu-lock, flags);
w = retu_read_reg(reg);
w = ~clear;
w |= set;
retu_write_reg(reg, w);
- spin_unlock_irqrestore(retu_lock, flags);
+ spin_unlock_irqrestore(retu-lock, flags);
}
EXPORT_SYMBOL_GPL(retu_set_clear_reg_bits);
@@ -114,15 +123,19 @@ EXPORT_SYMBOL_GPL(retu_set_clear_reg_bits);
int retu_read_adc(int channel)
{
- unsigned long flags;
- int res;
+ struct retu *retu = the_retu;
+ unsigned long flags;
+ int res;
+
+ if (!retu)
+ return -ENODEV;
if (channel 0 || channel ADC_MAX_CHAN_NUMBER)
return -EINVAL;
- spin_lock_irqsave(retu_lock, flags);
+ spin_lock_irqsave(retu-lock, flags);
- if ((channel == 8) retu_is_vilma) {
+ if ((channel == 8) retu-is_vilma) {
int scr = retu_read_reg(RETU_REG_ADCSCR);
int ch = (retu_read_reg(RETU_REG_ADCR) 10) 0xf;
if (((scr 0xff) != 0) (ch != 8))
@@ -133,11 +146,11 @@ int retu_read_adc(int channel)
retu_write_reg(RETU_REG_ADCR, channel 10);
res = retu_read_reg(RETU_REG_ADCR) 0x3ff;
- if (retu_is_vilma)
+ if (retu-is_vilma)
retu_write_reg(RETU_REG_ADCR, (1 13));
/* Unlock retu */
- spin_unlock_irqrestore(retu_lock, flags);
+ spin_unlock_irqrestore(retu-lock, flags);
return res;
}
@@ -164,15 +177,16 @@ static u16 retu_disable_bogus_irqs(u16 mask)
*/
void retu_disable_irq(int id)
{
- unsigned long flags;
- u16 mask;
+ struct retu *retu = the_retu;
+ unsigned long flags;
+ u16 mask;
- spin_lock_irqsave(retu_lock, flags);
+ spin_lock_irqsave(retu-lock, flags);
mask = retu_read_reg(RETU_REG_IMR);
mask |= 1 id;
mask = retu_disable_bogus_irqs(mask);
retu_write_reg(RETU_REG_IMR, mask);
- spin_unlock_irqrestore(retu_lock, flags);
+ spin_unlock_irqrestore(retu-lock, flags);
}
EXPORT_SYMBOL(retu_disable_irq);
@@ -181,19 +195,21 @@ EXPORT_SYMBOL(retu_disable_irq);
*/
void retu_enable_irq(int id)
{
- unsigned long flags;
- u16 mask;
+ struct retu *retu = the_retu;
+ unsigned long flags;
+ u16 mask;
if (id == 3) {
printk(Enabling Retu IRQ %d\n, id);
dump_stack();
}
- spin_lock_irqsave(retu_lock, flags);
+
+
[RFT/PATCH v2 03/12] cbus: retu: move module_* close to the matching symbol
Just to make checkpatch.pl a bit happier, move
subsys_initcall() and module_exit() closer to
the init and exit functions of the driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 39d4fa4..0053d43 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -498,25 +498,16 @@ static struct platform_driver retu_driver = {
},
};
-/**
- * retu_init - initialise Retu driver
- *
- * Initialise the Retu driver and return 0 if everything worked ok
- */
static int __init retu_init(void)
{
return platform_driver_probe(retu_driver, retu_probe);
}
+subsys_initcall(retu_init);
-/*
- * Cleanup
- */
static void __exit retu_exit(void)
{
platform_driver_unregister(retu_driver);
}
-
-subsys_initcall(retu_init);
module_exit(retu_exit);
MODULE_DESCRIPTION(Retu ASIC control);
--
1.7.3.4.598.g85356
--
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
[RFT/PATCH v2 04/12] cbus: retu: cleanup error path
Trivial cleanup patch shuffling error path
around.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c | 29 +
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 0053d43..7e67e1a 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -413,14 +413,15 @@ static int retu_allocate_children(struct device *parent)
static int __init retu_probe(struct platform_device *pdev)
{
struct retu *retu;
+
+ int ret = -ENOMEM;
int rev;
- int ret;
int irq;
retu = kzalloc(sizeof(*retu), GFP_KERNEL);
if (!retu) {
dev_err(pdev-dev, not enough memory\n);
- return -ENOMEM;
+ goto err0;
}
platform_set_drvdata(pdev, retu);
@@ -449,10 +450,7 @@ static int __init retu_probe(struct platform_device *pdev)
retu, retu);
if (ret 0) {
dev_err(pdev-dev, Unable to register IRQ handler\n);
- tasklet_kill(retu-tasklet);
- kfree(retu);
- the_retu = NULL;
- return ret;
+ goto err1;
}
set_irq_wake(irq, 1);
@@ -463,15 +461,22 @@ static int __init retu_probe(struct platform_device *pdev)
ret = retu_allocate_children(pdev-dev);
if (ret 0) {
dev_err(pdev-dev, Unable to allocate Retu children\n);
- retu_write_reg(RETU_REG_IMR, 0x);
- free_irq(irq, 0);
- tasklet_kill(retu-tasklet);
- kfree(retu);
- the_retu = NULL;
- return ret;
+ goto err2;
}
return 0;
+
+err2:
+ retu_write_reg(RETU_REG_IMR, 0x);
+ free_irq(irq, retu);
+
+err1:
+ tasklet_kill(retu-tasklet);
+ kfree(retu);
+ the_retu = NULL;
+
+err0:
+ return ret;
}
static int __exit retu_remove(struct platform_device *pdev)
--
1.7.3.4.598.g85356
--
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
[RFT/PATCH v2 07/12] cbus: retu: move to threaded IRQ and GENIRQ
Start moving retu to threaded IRQ and while
at that also give retu an irq_chip so children
can use generic request_threaded_irq() calls.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/Makefile | 10 +-
drivers/cbus/retu.c | 270 +
drivers/cbus/retu.h |5 -
3 files changed, 123 insertions(+), 162 deletions(-)
diff --git a/drivers/cbus/Makefile b/drivers/cbus/Makefile
index 0ad112f..3375b82 100644
--- a/drivers/cbus/Makefile
+++ b/drivers/cbus/Makefile
@@ -6,8 +6,10 @@ obj-$(CONFIG_CBUS) += cbus.o
obj-$(CONFIG_CBUS_TAHVO) += tahvo.o
obj-$(CONFIG_CBUS_RETU)+= retu.o
obj-$(CONFIG_CBUS_TAHVO_USB) += tahvo-usb.o
-obj-$(CONFIG_CBUS_RETU_POWERBUTTON) += retu-pwrbutton.o
-obj-$(CONFIG_CBUS_RETU_RTC)+= retu-rtc.o
-obj-$(CONFIG_CBUS_RETU_WDT)+= retu-wdt.o
obj-$(CONFIG_CBUS_TAHVO_USER) += tahvo-user.o
-obj-$(CONFIG_CBUS_RETU_HEADSET)+= retu-headset.o
+
+## Disable Retu children until converted to threaded IRQ
+#obj-$(CONFIG_CBUS_RETU_POWERBUTTON) += retu-pwrbutton.o
+#obj-$(CONFIG_CBUS_RETU_RTC) += retu-rtc.o
+#obj-$(CONFIG_CBUS_RETU_WDT) += retu-wdt.o
+#obj-$(CONFIG_CBUS_RETU_HEADSET) += retu-headset.o
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 7e67e1a..fa666fe 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -33,6 +33,7 @@
#include linux/miscdevice.h
#include linux/poll.h
#include linux/fs.h
+#include linux/mutex.h
#include linux/irq.h
#include linux/interrupt.h
#include linux/platform_device.h
@@ -43,6 +44,7 @@
#include plat/mux.h
#include plat/board.h
+#include plat/cbus.h
#include cbus.h
#include retu.h
@@ -53,23 +55,24 @@
struct retu {
/* Device lock */
spinlock_t lock;
- struct tasklet_struct tasklet;
+ struct mutexirq_lock;
struct device *dev;
+ int irq_base;
+ int irq_end;
+
int irq;
- boolis_vilma;
-};
+ int ack;
+ boolack_pending;
-static struct retu *the_retu;
+ int mask;
+ boolmask_pending;
-struct retu_irq_handler_desc {
- int (*func)(unsigned long);
- unsigned long arg;
- char name[8];
+ boolis_vilma;
};
-static struct retu_irq_handler_desc retu_irq_handlers[MAX_RETU_IRQ_HANDLERS];
+static struct retu *the_retu;
int retu_get_status(void)
{
@@ -156,180 +159,137 @@ int retu_read_adc(int channel)
}
EXPORT_SYMBOL(retu_read_adc);
-static u16 retu_disable_bogus_irqs(u16 mask)
+static irqreturn_t retu_irq_handler(int irq, void *_retu)
{
- int i;
-
- for (i = 0; i MAX_RETU_IRQ_HANDLERS; i++) {
- if (mask (1 i))
- continue;
- if (retu_irq_handlers[i].func != NULL)
- continue;
- /* an IRQ was enabled but we don't have a handler for it */
- printk(KERN_INFO PFX disabling bogus IRQ %d\n, i);
- mask |= (1 i);
- }
- return mask;
-}
+ struct retu *retu = _retu;
-/*
- * Disable given RETU interrupt
- */
-void retu_disable_irq(int id)
-{
- struct retu *retu = the_retu;
- unsigned long flags;
- u16 mask;
+ int i;
- spin_lock_irqsave(retu-lock, flags);
- mask = retu_read_reg(RETU_REG_IMR);
- mask |= 1 id;
- mask = retu_disable_bogus_irqs(mask);
- retu_write_reg(RETU_REG_IMR, mask);
- spin_unlock_irqrestore(retu-lock, flags);
-}
-EXPORT_SYMBOL(retu_disable_irq);
+ u16 idr;
+ u16 imr;
-/*
- * Enable given RETU interrupt
- */
-void retu_enable_irq(int id)
-{
- struct retu *retu = the_retu;
- unsigned long flags;
- u16 mask;
+ idr = retu_read_reg(RETU_REG_IDR);
+ imr = retu_read_reg(RETU_REG_IMR);
+ idr = ~imr;
- if (id == 3) {
- printk(Enabling Retu IRQ %d\n, id);
- dump_stack();
+ if (!idr) {
+ dev_vdbg(retu-dev, No IRQ, spurious?\n);
+ return IRQ_NONE;
}
- spin_lock_irqsave(retu-lock, flags);
- mask = retu_read_reg(RETU_REG_IMR);
- mask = ~(1 id);
- mask = retu_disable_bogus_irqs(mask);
- retu_write_reg(RETU_REG_IMR, mask);
- spin_unlock_irqrestore(retu-lock, flags);
+ for (i = 0; idr != 0; i++, idr = 1) {
+ if (!(idr 1))
+ continue;
+
+ handle_nested_irq(i);
+ }
+
+ return IRQ_HANDLED;
}
-EXPORT_SYMBOL(retu_enable_irq);
-/*
- * Acknowledge given RETU interrupt
- */
-void retu_ack_irq(int id)
+/*
[RFT/PATCH v2 06/12] arm: omap: cbus: pass irq_base and irq_end via platform_data
Pass CBUS_RETU_IRQ_BASE and CBUS_RETU_IRQ_END via
platform_data to retu platform_driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/board-nokia770.c |8
arch/arm/mach-omap2/board-n8x0.c |8
arch/arm/plat-omap/include/plat/cbus.h |5 +
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 84797a7..d939370 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -123,11 +123,19 @@ static struct resource retu_resource[] = {
},
};
+static struct cbus_retu_platform_data nokia770_retu_data = {
+ .irq_base = CBUS_RETU_IRQ_BASE,
+ .irq_end= CBUS_RETU_IRQ_END,
+};
+
static struct platform_device retu_device = {
.name = retu,
.id = -1,
.resource = retu_resource,
.num_resources = ARRAY_SIZE(retu_resource),
+ .dev= {
+ .platform_data = nokia770_retu_data,
+ },
};
static struct resource tahvo_resource[] = {
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 9b52e2d..cd5091f 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -221,11 +221,19 @@ static struct resource retu_resource[] = {
},
};
+static struct cbus_retu_platform_data n8x0_retu_data = {
+ .irq_base = CBUS_RETU_IRQ_BASE,
+ .irq_end= CBUS_RETU_IRQ_END,
+};
+
static struct platform_device retu_device = {
.name = retu,
.id = -1,
.resource = retu_resource,
.num_resources = ARRAY_SIZE(retu_resource),
+ .dev= {
+ .platform_data = n8x0_retu_data,
+ },
};
static struct resource tahvo_resource[] = {
diff --git a/arch/arm/plat-omap/include/plat/cbus.h
b/arch/arm/plat-omap/include/plat/cbus.h
index d938e23..1f0e8be 100644
--- a/arch/arm/plat-omap/include/plat/cbus.h
+++ b/arch/arm/plat-omap/include/plat/cbus.h
@@ -28,4 +28,9 @@ struct cbus_host_platform_data {
int sel_gpio;
};
+struct cbus_retu_platform_data {
+ int irq_base;
+ int irq_end;
+};
+
#endif /* __PLAT_CBUS_H */
--
1.7.3.4.598.g85356
--
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
[RFT/PATCH v2 08/12] cbus: retu: headset: convert to threaded_irq
use the new irq_chip added to retu.c.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/Makefile |2 +-
drivers/cbus/retu-headset.c | 22 --
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/cbus/Makefile b/drivers/cbus/Makefile
index 3375b82..841bed5 100644
--- a/drivers/cbus/Makefile
+++ b/drivers/cbus/Makefile
@@ -12,4 +12,4 @@ obj-$(CONFIG_CBUS_TAHVO_USER) += tahvo-user.o
#obj-$(CONFIG_CBUS_RETU_POWERBUTTON) += retu-pwrbutton.o
#obj-$(CONFIG_CBUS_RETU_RTC) += retu-rtc.o
#obj-$(CONFIG_CBUS_RETU_WDT) += retu-wdt.o
-#obj-$(CONFIG_CBUS_RETU_HEADSET) += retu-headset.o
+obj-$(CONFIG_CBUS_RETU_HEADSET)+= retu-headset.o
diff --git a/drivers/cbus/retu-headset.c b/drivers/cbus/retu-headset.c
index f5fb50c..2aa4d30 100644
--- a/drivers/cbus/retu-headset.c
+++ b/drivers/cbus/retu-headset.c
@@ -22,6 +22,8 @@
#include linux/module.h
#include linux/init.h
#include linux/kernel.h
+#include linux/irq.h
+#include linux/interrupt.h
#include linux/slab.h
#include linux/delay.h
#include linux/input.h
@@ -84,7 +86,6 @@ static void retu_headset_det_enable(struct retu_headset *hs)
if (!hs-detection_enabled) {
hs-detection_enabled = 1;
retu_set_clear_reg_bits(RETU_REG_CC1, (1 10) | (1 8), 0);
- retu_enable_irq(RETU_INT_HOOK);
}
mutex_unlock(hs-mutex);
}
@@ -96,7 +97,6 @@ static void retu_headset_det_disable(struct retu_headset *hs)
mutex_lock(hs-mutex);
if (hs-detection_enabled) {
hs-detection_enabled = 0;
- retu_disable_irq(RETU_INT_HOOK);
del_timer_sync(hs-enable_timer);
del_timer_sync(hs-detect_timer);
spin_lock_irqsave(hs-lock, flags);
@@ -177,12 +177,11 @@ static DEVICE_ATTR(enable_det, S_IRUGO | S_IWUSR |
S_IWGRP,
retu_headset_enable_det_show,
retu_headset_enable_det_store);
-static void retu_headset_hook_interrupt(unsigned long arg)
+static irqreturn_t retu_headset_hook_interrupt(int irq, void *_hs)
{
- struct retu_headset *hs = (struct retu_headset *) arg;
- unsigned long flags;
+ struct retu_headset *hs = _hs;
+ unsigned long flags;
- retu_ack_irq(RETU_INT_HOOK);
spin_lock_irqsave(hs-lock, flags);
if (!hs-pressed) {
/* Headset button was just pressed down. */
@@ -192,6 +191,8 @@ static void retu_headset_hook_interrupt(unsigned long arg)
spin_unlock_irqrestore(hs-lock, flags);
retu_set_clear_reg_bits(RETU_REG_CC1, 0, (1 10) | (1 8));
mod_timer(hs-enable_timer, jiffies + msecs_to_jiffies(50));
+
+ return IRQ_HANDLED;
}
static void retu_headset_enable_timer(unsigned long arg)
@@ -257,13 +258,13 @@ static int __init retu_headset_probe(struct
platform_device *pdev)
setup_timer(hs-detect_timer, retu_headset_detect_timer,
(unsigned long) hs);
- r = retu_request_irq(RETU_INT_HOOK, retu_headset_hook_interrupt,
-(unsigned long) hs, hookdet);
+ r = request_threaded_irq(RETU_INT_HOOK, NULL,
+ retu_headset_hook_interrupt, 0, hookdet, hs);
if (r != 0) {
dev_err(pdev-dev, hookdet IRQ not available\n);
goto err6;
}
- retu_disable_irq(RETU_INT_HOOK);
+
return 0;
err6:
device_remove_file(pdev-dev, dev_attr_enable_det);
@@ -289,9 +290,10 @@ static int retu_headset_remove(struct platform_device
*pdev)
device_remove_file(pdev-dev, dev_attr_enable_det);
retu_headset_disable(hs);
retu_headset_det_disable(hs);
- retu_free_irq(RETU_INT_HOOK);
+ free_irq(RETU_INT_HOOK, hs);
input_unregister_device(hs-idev);
input_free_device(hs-idev);
+
return 0;
}
--
1.7.3.4.598.g85356
--
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
[RFT/PATCH v2 10/12] cbus: retu-rtc: move to threaded irq
Move to the generic threaded irq infrastructure
and drop all the retu-specific magic.
Unfortunately, due to the conversion and lack of
docs, retu_rtc_ioctl() had to be dropped, someone
else with access to docs is free to implement it
later considering the new style of the driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/Makefile |2 +-
drivers/cbus/retu-rtc.c | 120 ++
2 files changed, 17 insertions(+), 105 deletions(-)
diff --git a/drivers/cbus/Makefile b/drivers/cbus/Makefile
index 23f82b4..7bfd997 100644
--- a/drivers/cbus/Makefile
+++ b/drivers/cbus/Makefile
@@ -10,6 +10,6 @@ obj-$(CONFIG_CBUS_TAHVO_USER) += tahvo-user.o
## Disable Retu children until converted to threaded IRQ
obj-$(CONFIG_CBUS_RETU_POWERBUTTON) += retu-pwrbutton.o
-#obj-$(CONFIG_CBUS_RETU_RTC) += retu-rtc.o
+obj-$(CONFIG_CBUS_RETU_RTC)+= retu-rtc.o
#obj-$(CONFIG_CBUS_RETU_WDT) += retu-wdt.o
obj-$(CONFIG_CBUS_RETU_HEADSET)+= retu-headset.o
diff --git a/drivers/cbus/retu-rtc.c b/drivers/cbus/retu-rtc.c
index cc789ed..6e201aa 100644
--- a/drivers/cbus/retu-rtc.c
+++ b/drivers/cbus/retu-rtc.c
@@ -38,11 +38,9 @@
#include linux/kernel.h
#include linux/slab.h
#include linux/module.h
-#include linux/completion.h
#include linux/platform_device.h
#include linux/mutex.h
#include linux/rtc.h
-#include linux/workqueue.h
#include cbus.h
#include retu.h
@@ -50,8 +48,6 @@
struct retu_rtc {
/* device lock */
struct mutexmutex;
- struct completion sync;
- struct work_struct work;
struct device *dev;
struct rtc_device *rtc;
@@ -59,18 +55,6 @@ struct retu_rtc {
u16 reset_occurred;
};
-#define work_to_rtc(r) (container_of(r, struct retu_rtc, work))
-
-/* This function provides syncronization with the RTCS interrupt handler */
-static void retu_rtc_barrier(struct retu_rtc *rtc)
-{
- INIT_COMPLETION(rtc-sync);
- retu_ack_irq(RETU_INT_RTCS);
- retu_enable_irq(RETU_INT_RTCS);
- wait_for_completion(rtc-sync);
- retu_disable_irq(RETU_INT_RTCS);
-}
-
static void retu_rtc_do_reset(struct retu_rtc *rtc)
{
u16 ccr1;
@@ -81,7 +65,6 @@ static void retu_rtc_do_reset(struct retu_rtc *rtc)
/* RTC in normal operating mode */
retu_write_reg(RETU_REG_CC1, ccr1 ~0x0001);
- retu_rtc_barrier(rtc);
/* Disable alarm and RTC WD */
retu_write_reg(RETU_REG_RTCHMAR, 0x7f3f);
/* Set Calibration register to default value */
@@ -91,62 +74,33 @@ static void retu_rtc_do_reset(struct retu_rtc *rtc)
rtc-reset_occurred = 1;
}
-static void retu_rtca_disable(struct retu_rtc *rtc)
+static irqreturn_t retu_rtc_interrupt(int irq, void *_rtc)
{
- retu_disable_irq(RETU_INT_RTCA);
+ struct retu_rtc *rtc = _rtc;
+
+ mutex_lock(rtc-mutex);
rtc-alarm_expired = 1;
- retu_rtc_barrier(rtc);
retu_write_reg(RETU_REG_RTCHMAR, (24 8) | 60);
-}
-
-static void retu_rtca_expired(struct work_struct *work)
-{
- struct retu_rtc *rtc = work_to_rtc(work);
-
- retu_rtca_disable(rtc);
-}
-
-/*
- * RTCHMR RTCHMAR RTCCAL must be accessed within 0.9 s since the seconds
- * interrupt has been signaled in the IDR register
- */
-static void retu_rtcs_interrupt(unsigned long _rtc)
-{
- struct retu_rtc *rtc = (struct retu_rtc *) _rtc;
-
- retu_ack_irq(RETU_INT_RTCS);
- complete_all(rtc-sync);
-}
-
-static void retu_rtca_interrupt(unsigned long _rtc)
-{
- struct retu_rtc *rtc = (struct retu_rtc *) _rtc;
+ mutex_unlock(rtc-mutex);
- retu_ack_irq(RETU_INT_RTCA);
- schedule_work(rtc-work);
+ return IRQ_HANDLED;
}
static int retu_rtc_init_irq(struct retu_rtc *rtc)
{
int ret;
- ret = retu_request_irq(RETU_INT_RTCS, retu_rtcs_interrupt,
- (unsigned long) rtc, RTCS);
+ ret = request_threaded_irq(RETU_INT_RTCS, NULL, retu_rtc_interrupt,
+ 0, RTCS, rtc);
if (ret != 0)
return ret;
- /*
-* We will take care of enabling and disabling the interrupt
-* elsewhere, so leave it off by default..
-*/
- retu_disable_irq(RETU_INT_RTCS);
- ret = retu_request_irq(RETU_INT_RTCA, retu_rtca_interrupt,
- (unsigned long) rtc, RTCA);
+ ret = request_threaded_irq(RETU_INT_RTCA, NULL, retu_rtc_interrupt,
+ 0, RTCA, rtc);
if (ret != 0) {
- retu_free_irq(RETU_INT_RTCS);
+ free_irq(RETU_INT_RTCS, rtc);
return ret;
}
- retu_disable_irq(RETU_INT_RTCA);
return 0;
}
@@ -231,42 +185,7 @@ static int retu_rtc_read_time(struct device *dev, struct
rtc_time *tm)
return 0;
}
-#ifdef CONFIG_RTC_INTF_DEV
-
-static int retu_rtc_ioctl(struct device
[RFT/PATCH v2 05/12] arm: omap: irqs: add CBUS_RETU_IRQ_BASE and CBUS_RETU_IRQ_END
those two will be used to pass down irq_base and irq_end to retu platform_driver. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/plat-omap/include/plat/irqs.h | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h index 2910de9..d62e795 100644 --- a/arch/arm/plat-omap/include/plat/irqs.h +++ b/arch/arm/plat-omap/include/plat/irqs.h @@ -411,7 +411,15 @@ #define TWL_IRQ_ENDTWL6030_IRQ_END #endif -#define NR_IRQSTWL_IRQ_END +#define CBUS_RETU_IRQ_BASE TWL_IRQ_END +#ifdef CONFIG_CBUS_RETU +#define CBUS_RETU_NR_IRQS 16 +#else +#define CBUS_RETU_NR_IRQS 0 +#endif +#define CBUS_RETU_IRQ_END (CBUS_RETU_IRQ_BASE + CBUS_RETU_NR_IRQS) + +#define NR_IRQSCBUS_RETU_IRQ_END #define OMAP_IRQ_BIT(irq) (1 ((irq) % 32)) -- 1.7.3.4.598.g85356 -- 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
[RFT/PATCH v2 11/12] cbus: retu-rtc: drop the reset_occurred flag
that flag is never read anyway, only written,
so we can drop it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu-rtc.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/cbus/retu-rtc.c b/drivers/cbus/retu-rtc.c
index 6e201aa..b2b9472 100644
--- a/drivers/cbus/retu-rtc.c
+++ b/drivers/cbus/retu-rtc.c
@@ -52,7 +52,6 @@ struct retu_rtc {
struct rtc_device *rtc;
u16 alarm_expired;
- u16 reset_occurred;
};
static void retu_rtc_do_reset(struct retu_rtc *rtc)
@@ -71,7 +70,6 @@ static void retu_rtc_do_reset(struct retu_rtc *rtc)
retu_write_reg(RETU_REG_RTCCALR, 0x00c0);
rtc-alarm_expired = 0;
- rtc-reset_occurred = 1;
}
static irqreturn_t retu_rtc_interrupt(int irq, void *_rtc)
@@ -223,14 +221,10 @@ static int __init retu_rtc_probe(struct platform_device
*pdev)
goto err1;
}
- /* If the calibration register is zero, we've probably lost
-* power */
- if (retu_read_reg(RETU_REG_RTCCALR) 0x00ff)
- rtc-reset_occurred = 0;
- else
+ /* If the calibration register is zero, we've probably lost power */
+ if (!(retu_read_reg(RETU_REG_RTCCALR) 0x00ff))
retu_rtc_do_reset(rtc);
-
rtc-rtc = rtc_device_register(pdev-name, pdev-dev,
retu_rtc_ops, THIS_MODULE);
if (IS_ERR(rtc-rtc)) {
--
1.7.3.4.598.g85356
--
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
[RFT/PATCH v2 09/12] cbus: retu-pwrbutton: convert to threaded irq
Drop the timer function and move to threaded
irq infrastructure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/Makefile |2 +-
drivers/cbus/retu-pwrbutton.c | 37 +
2 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/cbus/Makefile b/drivers/cbus/Makefile
index 841bed5..23f82b4 100644
--- a/drivers/cbus/Makefile
+++ b/drivers/cbus/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_CBUS_TAHVO_USB)+= tahvo-usb.o
obj-$(CONFIG_CBUS_TAHVO_USER) += tahvo-user.o
## Disable Retu children until converted to threaded IRQ
-#obj-$(CONFIG_CBUS_RETU_POWERBUTTON) += retu-pwrbutton.o
+obj-$(CONFIG_CBUS_RETU_POWERBUTTON) += retu-pwrbutton.o
#obj-$(CONFIG_CBUS_RETU_RTC) += retu-rtc.o
#obj-$(CONFIG_CBUS_RETU_WDT) += retu-wdt.o
obj-$(CONFIG_CBUS_RETU_HEADSET)+= retu-headset.o
diff --git a/drivers/cbus/retu-pwrbutton.c b/drivers/cbus/retu-pwrbutton.c
index 6b8dfa9..2a5ccb0 100644
--- a/drivers/cbus/retu-pwrbutton.c
+++ b/drivers/cbus/retu-pwrbutton.c
@@ -30,9 +30,10 @@
#include linux/kernel.h
#include linux/errno.h
#include linux/input.h
-#include linux/timer.h
#include linux/jiffies.h
#include linux/bitops.h
+#include linux/irq.h
+#include linux/interrupt.h
#include linux/platform_device.h
#include linux/slab.h
@@ -46,15 +47,14 @@
struct retu_pwrbutton {
struct input_dev*idev;
- struct timer_list timer;
int state;
int irq;
};
-static void retubutton_timer_func(unsigned long arg)
+static irqreturn_t retubutton_irq(int irq, void *_pwr)
{
- struct retu_pwrbutton *pwr = (struct retu_pwrbutton *) arg;
+ struct retu_pwrbutton *pwr = _pwr;
int state;
if (retu_read_reg(RETU_REG_STATUS) RETU_STATUS_PWRONX)
@@ -67,24 +67,10 @@ static void retubutton_timer_func(unsigned long arg)
input_sync(pwr-idev);
pwr-state = state;
}
-}
-
-/**
- * Interrupt function is called whenever power button key is pressed
- * or released.
- */
-static void retubutton_irq(unsigned long arg)
-{
- struct retu_pwrbutton *pwr = (struct retu_pwrbutton *) arg;
- retu_ack_irq(RETU_INT_PWR);
- mod_timer(pwr-timer, jiffies + msecs_to_jiffies(PWRBTN_DELAY));
+ return IRQ_HANDLED;
}
-/**
- * Init function.
- * Allocates interrupt for power button and registers itself to input layer.
- */
static int __init retubutton_probe(struct platform_device *pdev)
{
struct retu_pwrbutton *pwr;
@@ -99,10 +85,9 @@ static int __init retubutton_probe(struct platform_device
*pdev)
pwr-irq = RETU_INT_PWR;
platform_set_drvdata(pdev, pwr);
- setup_timer(pwr-timer, retubutton_timer_func, (unsigned long) pwr);
- ret = retu_request_irq(pwr-irq, retubutton_irq, (unsigned long) pwr,
- PwrOnX);
+ ret = request_threaded_irq(pwr-irq, NULL, retubutton_irq, 0,
+ retu-pwrbutton, pwr);
if (ret 0) {
dev_err(pdev-dev, Cannot allocate irq\n);
goto err1;
@@ -131,7 +116,7 @@ err3:
input_free_device(pwr-idev);
err2:
- retu_free_irq(pwr-irq);
+ free_irq(pwr-irq, pwr);
err1:
kfree(pwr);
@@ -140,15 +125,11 @@ err0:
return ret;
}
-/**
- * Cleanup function which is called when driver is unloaded
- */
static int __exit retubutton_remove(struct platform_device *pdev)
{
struct retu_pwrbutton *pwr = platform_get_drvdata(pdev);
- retu_free_irq(pwr-irq);
- del_timer_sync(pwr-timer);
+ free_irq(pwr-irq, pwr);
input_unregister_device(pwr-idev);
input_free_device(pwr-idev);
kfree(pwr);
--
1.7.3.4.598.g85356
--
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
[RFT/PATCH v2 12/12] cbus: Makefile: re-enable retu-wdt
Now that all conversions have been made, reenable retu-wdt driver. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/cbus/Makefile |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/cbus/Makefile b/drivers/cbus/Makefile index 7bfd997..c5c3940 100644 --- a/drivers/cbus/Makefile +++ b/drivers/cbus/Makefile @@ -8,8 +8,7 @@ obj-$(CONFIG_CBUS_RETU) += retu.o obj-$(CONFIG_CBUS_TAHVO_USB) += tahvo-usb.o obj-$(CONFIG_CBUS_TAHVO_USER) += tahvo-user.o -## Disable Retu children until converted to threaded IRQ obj-$(CONFIG_CBUS_RETU_POWERBUTTON) += retu-pwrbutton.o obj-$(CONFIG_CBUS_RETU_RTC)+= retu-rtc.o -#obj-$(CONFIG_CBUS_RETU_WDT) += retu-wdt.o +obj-$(CONFIG_CBUS_RETU_WDT)+= retu-wdt.o obj-$(CONFIG_CBUS_RETU_HEADSET)+= retu-headset.o -- 1.7.3.4.598.g85356 -- 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: Beagle: detect new xM revision B
From: Robert Nelson robertcnel...@gmail.com
The xM B uses a DM3730 ES1.1 over the ES1.0 on xM A's, no other board changes.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7c82730..4fd73e7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -58,7 +58,8 @@
* AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
* C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
* C4 = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMB = GPIO173, GPIO172, GPIO171: 0 0 1
*/
enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -117,7 +118,11 @@ static void __init omap3_beagle_init_rev(void)
omap3_beagle_version = OMAP3BEAGLE_BOARD_C4;
break;
case 0:
- printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
+ printk(KERN_INFO OMAP3 Beagle Rev: xM A\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
+ break;
+ case 1:
+ printk(KERN_INFO OMAP3 Beagle Rev: xM B\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
default:
--
cgit v0.8.3.1-30-gff3a
--
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 09/17] OMAP2,3: DSS2: Move clocks from core driver to dss driver
On Thu, 2011-01-06 at 15:10 +0530, ext Semwal, Sumit wrote: Hi Tomi, On Wed, Jan 5, 2011 at 9:05 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: On Mon, 2011-01-03 at 18:21 +0530, ext Guruswamy Senthilvadivu wrote: From: Senthilvadivu Guruswamy svad...@ti.com clks are moved to dss platform driver. clk_get/put APIs use dss device instead of core platform device. So the device name is changed from omap_display to omap_dss in 2420, 2430, 3xxx clock database files. Now teh core driver omap_display only takes care of panel registration with the custom bus. dss driver would take care of the clocks needed by DISPC, RFBI, DSI, VENC. TODO: The clock content would be adapted to omap_hwmod in a seperate series. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com snip @@ -508,14 +192,7 @@ static int omap_dss_probe(struct platform_device *pdev) dss_init_overlay_managers(pdev); dss_init_overlays(pdev); - r = dss_get_clocks(); - if (r) - goto err_clocks; - - dss_clk_enable_all_no_ctx(); - - core.ctx_id = dss_get_ctx_id(); - DSSDBG(initial ctx id %u\n, core.ctx_id); + dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M); #ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT /* DISPC_CONTROL */ @@ -589,7 +266,7 @@ static int omap_dss_probe(struct platform_device *pdev) pdata-default_device = dssdev; } - dss_clk_disable_all(); + dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M); Why are the calls dss_clk_enable_all_no_ctx() and dss_clk_disable_all() changed? This came as an after-effect of moving all clk related stuff to dss.c; I think the idea is that all the new DSS IP platform drivers should use only the exposed clock mgmt APIs [dss_clk_enable() / dss_clk_disable()]. Ah, right. However, you are right; all the required clocks might not be getting enabled / disabled as required. I can (re)create the static dss_clk_disable_all() / dss_clk_enable_all_no_ctx() locally inside core.c - do you think that's ok, or should I export these functions too from dss.c? Well... I think all the xxx_init() functions should enable the clocks they require, so in that sense enabling the clocks is not needed at all. But there's the (hackish) code for CONFIG_FB_OMAP_BOOTLOADER_INIT, which requires normal dss clocks. Also if each xxx_init() call enables and disables the clocks, and dss_probe doesn't keep the clocks enabled, then we would get a ctx save/restore after every init, which would not be nice. So I think enabling just ICK and FCK1 would be enough, to get CONFIG_FB_OMAP_BOOTLOADER_INIT work and to prevent ctx save/restore. Perhaps there should be a comment above the dss_clk_enable, like keep clocks enabled to prevent context saves/restores during init. 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: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Thu, Jan 6, 2011 at 5:34 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Thu, Jan 06, 2011 at 09:26:40AM +0530, Keerthy wrote:
---
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/twl4030-madc.c | 794
++
include/linux/i2c/twl4030-madc.h | 118 ++
4 files changed, 924 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwmon/twl4030-madc.c
create mode 100644 include/linux/i2c/twl4030-madc.h
hwmon drivers are also expected to have a file under Documentation.
I will add a documentation file.
+struct twl4030_madc_data {
+ struct device *hwmon_dev;
+ struct mutex lock;/* mutex protecting this data structire */
+ struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+ int imr;
+ int isr;
+};
+static struct twl4030_madc_data *twl4030_madc;
I'd expect this to be per driver instance rather than global (I know
it's vanishingly unlikely that you'll get multiple twl4030s in a single
system but it's nicer).
+/*
+ * sysfs hook function
+ */
+static ssize_t madc_read(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct twl4030_madc_request req;
+ long val;
+
+ req.channels = (1 attr-index);
+ req.method = TWL4030_MADC_SW2;
+ req.func_cb = NULL;
+ val = twl4030_madc_conversion(req);
+ if (val = 0)
+ val = req.rbuf[attr-index];
+ else
+ return val;
+ return sprintf(buf, %ld\n, val);
Does this return data in the appropriate units - milivolts for voltages?
This function returns the raw channel values read and not in terms of the
units.
+/*
+ * Enables irq.
+ * @madc - pointer to twl4030_madc_data struct
+ * @id - irq number to be enabled
+ * can take one of TWL4030_MADC_RT, TWL4030_MADC_SW1, TWL4030_MADC_SW2
+ * corresponding to RT, SW1, SW2 conversion requests.
+ * If the i2c read fails it returns an error else returns 0.
+ */
+static int twl4030_madc_enable_irq(struct twl4030_madc_data *madc, int id)
It'd be good to clarify that this is interrupt sources within this
module rather than Linux interrupt numbers.
Ok.
+ dev_dbg(madc-hwmon_dev,
+ Disable interrupt failed%d\n, i);
+ }
+
+ madc-requests[i].result_pending = 1;
+ }
+ mutex_lock(madc-lock);
+ for (i = 0; i TWL4030_MADC_NUM_METHODS; i++) {
+
+ r = madc-requests[i];
In general through the driver your use of blank lines is really odd
which doesn't help readability.
Ok. I will correct it.
+ switch (conv_method) {
+ case TWL4030_MADC_SW1:
+ case TWL4030_MADC_SW2:
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC,
+ TWL4030_MADC_SW_START, method-ctrl);
+ if (ret) {
+ dev_err(madc-hwmon_dev,
+ unable to write ctrl register 0x%X\n, method-ctrl);
+ return ret;
+ }
+ break;
+ case TWL4030_MADC_RT:
+ default:
+ break;
This looks odd - the function won't actually do anything for non-SW
conversions but won't return an error?
Ok. In the case of RT conversion request no software setting is required
and it is signal driven. So the function does nothing in case of RT.
+/* sysfs nodes to read individual channels from user side */
+static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, madc_read, NULL, 0);
+static SENSOR_DEVICE_ATTR(in1_input, S_IRUGO, madc_read, NULL, 1);
+static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, madc_read, NULL, 2);
+static SENSOR_DEVICE_ATTR(in3_input, S_IRUGO, madc_read, NULL, 3);
+static SENSOR_DEVICE_ATTR(in4_input, S_IRUGO, madc_read, NULL, 4);
+static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, madc_read, NULL, 5);
+static SENSOR_DEVICE_ATTR(in6_input, S_IRUGO, madc_read, NULL, 6);
+static SENSOR_DEVICE_ATTR(in7_input, S_IRUGO, madc_read, NULL, 7);
+static SENSOR_DEVICE_ATTR(in8_input, S_IRUGO, madc_read, NULL, 8);
+static SENSOR_DEVICE_ATTR(in9_input, S_IRUGO, madc_read, NULL, 9);
+static SENSOR_DEVICE_ATTR(in10_input, S_IRUGO, madc_read, NULL, 10);
+static SENSOR_DEVICE_ATTR(in11_input, S_IRUGO, madc_read, NULL, 11);
+static SENSOR_DEVICE_ATTR(in12_input, S_IRUGO, madc_read, NULL, 12);
+static SENSOR_DEVICE_ATTR(in13_input, S_IRUGO, madc_read, NULL, 13);
+static SENSOR_DEVICE_ATTR(in14_input, S_IRUGO, madc_read, NULL, 14);
+static SENSOR_DEVICE_ATTR(in15_input, S_IRUGO, madc_read, NULL, 15);
I suspect some of these are temperatures, some are voltages and that
some are fixed to particular inputs? The temperatures should be temp_
and if the inputs are from known sources it'd be good to label them.
Yes some are voltages and some are fixed to particular inputs.
I will label them.
+
Re: 4430SDP boot failure
On Fri, Jan 07, 2011 at 02:09:17PM +0530, Santosh Shilimkar wrote: Can we _please_ have a version of uboot for the SDP4430 platform which can be configured at runtime _and_ which is capable of DHCP/TFTP ? I really don't want to mess about anymore with buggy boot loaders. Just read this thread. Looks like you are not able to boot the kernel at all. 2.6.37 + Tony's queue booted for me without any issues. I can only boot older kernels. I can't debug later kernels because as soon as I access the UART, I get this very bland 'X-loader hangs' message which is no help what so ever (for the amount of use it is, it might as well not even print that.) I don't know whether that's because I'm doing something wrong or what as there's no way to get any diagnostics out of the system. The u-boot SD card issues are just another layer of timewasting frustration which really doesn't help. I don't want to spend many hours debugging the boot loader because it also doesn't work properly. I want something which works every time without fail. BTW, if it makes any difference to the boot loader, please note that I'm still waiting for the upgrade for the SDP board. -- 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: 4430SDP boot failure
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Friday, January 07, 2011 2:58 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: 4430SDP boot failure On Fri, Jan 07, 2011 at 02:09:17PM +0530, Santosh Shilimkar wrote: Can we _please_ have a version of uboot for the SDP4430 platform which can be configured at runtime _and_ which is capable of DHCP/TFTP ? I really don't want to mess about anymore with buggy boot loaders. Just read this thread. Looks like you are not able to boot the kernel at all. 2.6.37 + Tony's queue booted for me without any issues. I can only boot older kernels. I can't debug later kernels because as soon as I access the UART, I get this very bland 'X-loader hangs' message which is no help what so ever (for the amount of use it is, it might as well not even print that.) I don't know whether that's because I'm doing something wrong or what as there's no way to get any diagnostics out of the system. Ok. Will try 2.6.37 major version. The u-boot SD card issues are just another layer of timewasting frustration which really doesn't help. I don't want to spend many hours debugging the boot loader because it also doesn't work properly. I want something which works every time without fail. BTW, if it makes any difference to the boot loader, please note that I'm still waiting for the upgrade for the SDP board. That means your board is with ES1.0. I shall try 2.6.37 on ES1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
Hello Kevin, On Thu, Jan 06, 2011 at 09:59:48AM -0800, ext Kevin Hilman wrote: Eduardo Valentin eduardo.valen...@nokia.com writes: On Wed, Jan 05, 2011 at 03:22:51PM -0800, ext Kevin Hilman wrote: Eduardo Valentin eduardo.valen...@nokia.com writes: Hello Russell, On Wed, Jan 05, 2011 at 06:19:18PM +, Russell King wrote: On Wed, Jan 05, 2011 at 07:58:03PM +0200, Eduardo Valentin wrote: Currently, if one calls disable_irq(gpio_irq), the irq won't get disabled. This is happening because the omap gpio code defines only a .mask callback. And the default_disable function is just a stub. The result is that, when someone calls disable_irq for an irq in a gpio line, it will be kept enabled. This patch solves this issue by setting the .disable callback to point to the same .mask callback. Amd this is a problem because? errr.. because the interrupt is enabled when it was supposed to be disabled? As Russell pointed out, it's not actually supposed to be. With lazy disable, what disable_irq() does is prevent the *handler* from ever being called. If another interrupt arrives, it will be caught by the genirq core, marked as IRQ_PENDING and then masked. This don't disable unless we really have to is the desired behavior of the lazy disable feature. Right. I'm convinced that the handler won't be called because of the lazy disable mechanism. The way this works is that although it isn't disabled at that point, if it never triggers, then everything remains happy. However, if it does trigger, the genirq code will then mask the interrupt and won't call the handler. Right.. I didn't see from this point. I will check how that gets unmasked. But even so, if I understood correctly what you described, it would still open a time window which the system would see at least 1 interrupt during the time it was not suppose to. And that can wakeup a system which is in deep sleep mode, either via dynamic idle or static suspend. It is unlikely, I know. But it can still happen. And can be avoided. If the GPIO is configured as a wakeup source, then wouldn't you want activity on that GPIO to wake up the system? Yes I would want it.. of course, if the interrupt is enabled though.. I'm still trying to find a valid situation where someone disables an irq but still wants its activity to be a wakeup source. I couldn't find so far.. If you don't want wakeups on that GPIO, then the driver should probably be using disable_irq_wake(). Yes. Let's take this situation. Let's assume a driver, at its suspend callback, explicitly reports to the system that its irq can be disabled and also should not be seen as a wakeup source, by calling disable_irq(gpio_irq) and disable_irq_wake(gpio_irq). What should be the expected system behavior when the user says echo mem /sys/power/state? From the point we are done with devices suspend, that gpio will still be marked as an irq, at the bank level. But its corresponding pad will have its wakeup bit disabled. Would that work? I think yes, in most cases. Now let's take the WFI instruction as a divisor for 2 situations: A - common / working case: an interrupt on that gpio still happens after the WFI instruction. Since the system is in sleep mode and the pad for that gpio is not wakeup capable, then nothing would happen and the system won't wakeup. Then, I think everyone is happy here. B - corner case: an interrupt on that gpio happens before the WFI instruction. Since the system is active, the gpio bank can still report this interrupt and will do it. The suspend won't happen due to a irq which has been explicitly marked as disabled and wakeup incapable. Then, would that be the expected behavior? Assuming that the driver has explicitly said to the system, you should not bother about this at all. Well, expected behaviour would be that GPIO bank should not be reporting the this interrupt at all since it has been disabled. However, since you're asking, I assume that you're not seeing this expected behavior. Yeah that's right. But it is rather difficult to reproduce. Ignoring wakeups for a second, if this corner case happens on a non-wakeup capable GPIO using lazy disable, I would not expect suspend to be prevented. The genirq core would see the IRQ, mark it as IRQ_PENDING, mask it and return. and suspend should continue. True. hmm... however, if the IRQ happens after interrupts are disabled, the genirq core won't handle it, and our PM core will see a pending interrupt and abort idle/suspend. True again. And that's what think it is happening. Are you seeing this corner case for a wakeup-enable GPIO or a non wakeup-enabled GPIO? It is in wakeup-enable gpio. But the driver removes the wakeup flag from the gpio on its suspend function right after
Re: [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
On Fri, Jan 07, 2011 at 11:56:09AM +0200, Eduardo Valentin wrote: It is in wakeup-enable gpio. But the driver removes the wakeup flag from the gpio on its suspend function right after disabling the irq. disable_irq(gpio_irq); disable_irq_wake(gpio_irq); In this case, the device uses gpio 61 as its irq line. I think the solution to this is to have genirq synchronize the hardware state with the lazy state on suspend transitions rather than trying to fix this on a case-by-case basis. -- 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] cpuidle: Introduce .abbr (abbrevation) for cpuidle states
and fill name, description and newly introduced abbrevation
consistently (always use snprintf) in all cpuidle drivers.
This is mainly for perf timechart. It draws vector graphics
pictures of sleep/idle state usage catching perf cpu_idle events.
The string used for the idle state must not exceed 3 chars or
you can't see much in these pictures.
The name could get used in the title, the introduced abbrevations
inside of the picture and the text must therefore be rather short.
Signed-off-by: Thomas Renninger tr...@suse.de
CC: l...@kernel.org
CC: linux-a...@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
CC: Frederic Weisbecker fweis...@gmail.com
CC: linux-ker...@vger.kernel.org
CC: linux-omap@vger.kernel.org
---
arch/arm/mach-at91/cpuidle.c | 12
arch/arm/mach-davinci/cpuidle.c | 13 +
arch/arm/mach-kirkwood/cpuidle.c | 12
arch/arm/mach-omap2/cpuidle34xx.c |3 ++-
arch/sh/kernel/cpu/shmobile/cpuidle.c | 19 +++
drivers/acpi/processor_idle.c |3 +++
drivers/cpuidle/cpuidle.c |1 +
drivers/cpuidle/sysfs.c |3 +++
drivers/idle/intel_idle.c | 11 +++
include/linux/cpuidle.h |2 ++
10 files changed, 58 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 1cfeac1..6cdeb42 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -73,16 +73,20 @@ static int at91_init_cpuidle(void)
device-states[0].exit_latency = 1;
device-states[0].target_residency = 1;
device-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[0].name, WFI);
- strcpy(device-states[0].desc, Wait for interrupt);
+ snprintf(device-states[0].name, CPUIDLE_NAME_LEN, WFI);
+ snprintf(device-states[0].desc, CPUIDLE_DESC_LEN,
+Wait for interrupt);
+ snprintf(device-states[0].abbr, CPUIDLE_ABBR_LEN, W);
/* Wait for interrupt and RAM self refresh state */
device-states[1].enter = at91_enter_idle;
device-states[1].exit_latency = 10;
device-states[1].target_residency = 1;
device-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[1].name, RAM_SR);
- strcpy(device-states[1].desc, WFI and RAM Self Refresh);
+ snprintf(device-states[1].name, CPUIDLE_NAME_LEN, RAM SR);
+ snprintf(device-states[1].desc, CPUIDLE_DESC_LEN,
+WFI and RAM Self Refresh);
+ snprintf(device-states[1].abbr, CPUIDLE_ABBR_LEN, WSR);
if (cpuidle_register_device(device)) {
printk(KERN_ERR at91_init_cpuidle: Failed registering\n);
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index bd59f31..42ad2d6 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -127,16 +127,21 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
device-states[0].exit_latency = 1;
device-states[0].target_residency = 1;
device-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[0].name, WFI);
- strcpy(device-states[0].desc, Wait for interrupt);
+ snprintf(device-states[0].name, CPUIDLE_NAME_LEN, WFI);
+ snprintf(device-states[0].desc, CPUIDLE_DESC_LEN,
+Wait for interrupt);
+ snprintf(device-states[0].abbr, CPUIDLE_ABBR_LEN, W);
/* Wait for interrupt and DDR self refresh state */
device-states[1].enter = davinci_enter_idle;
device-states[1].exit_latency = 10;
device-states[1].target_residency = 1;
device-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[1].name, DDR SR);
- strcpy(device-states[1].desc, WFI and DDR Self Refresh);
+ snprintf(device-states[1].name, CPUIDLE_NAME_LEN, RAM SR);
+ snprintf(device-states[1].desc, CPUIDLE_DESC_LEN,
+WFI and RAM Self Refresh);
+ snprintf(device-states[1].abbr, CPUIDLE_ABBR_LEN, WSR);
+
if (pdata-ddr2_pdown)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
cpuidle_set_statedata(device-states[1], davinci_states[1]);
diff --git a/arch/arm/mach-kirkwood/cpuidle.c b/arch/arm/mach-kirkwood/cpuidle.c
index f68d33f..48eaabb 100644
--- a/arch/arm/mach-kirkwood/cpuidle.c
+++ b/arch/arm/mach-kirkwood/cpuidle.c
@@ -75,16 +75,20 @@ static int kirkwood_init_cpuidle(void)
device-states[0].exit_latency = 1;
device-states[0].target_residency = 1;
device-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[0].name, WFI);
- strcpy(device-states[0].desc, Wait for interrupt);
+ snprintf(device-states[0].name, CPUIDLE_NAME_LEN, WFI);
+ snprintf(device-states[0].desc,
[PATCH 8/9] perf timechart: Map power:cpu_idle events to the corresponding cpuidle state
Before, power:cpu_idle events were very specific X86 Intel mwait events.
This got fixed with previous patches and cpu_idle events are now thrown by
all cpuidle drivers and can be mapped to the corresponding cpuidle state
in /sys.
This patch reads out the corresponding cpuidle name of a cpu_idle event
and uses it in the title line of the chart (c-states Cx in x86, omap2
- DDR self refresh states for various arm archs).
It also reads out the corresponding abbr(eviation) and uses the string
to draw the cpu idle occurences. This needs a short (3 letter) string
to keep the overview in the chart.
Signed-off-by: Thomas Renninger tr...@suse.de
CC: l...@kernel.org
CC: linux-a...@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
CC: linux-ker...@vger.kernel.org
CC: linux-perf-us...@vger.kernel.org
CC: linux-omap@vger.kernel.org
CC: Frederic Weisbecker fweis...@gmail.com
---
tools/perf/util/include/linux/cpuidle.h | 20
tools/perf/util/svghelper.c | 149 +++---
2 files changed, 154 insertions(+), 15 deletions(-)
create mode 100644 tools/perf/util/include/linux/cpuidle.h
diff --git a/tools/perf/util/include/linux/cpuidle.h
b/tools/perf/util/include/linux/cpuidle.h
new file mode 100644
index 000..7012f33
--- /dev/null
+++ b/tools/perf/util/include/linux/cpuidle.h
@@ -0,0 +1,20 @@
+#ifndef __PERF_CPUIDLE_H_
+#define __PERF_CPUIDLE_H_
+
+/* This comes from include/linux/cpuidle.h kernel header **/
+#define CPUIDLE_STATE_MAX 8
+#define CPUIDLE_NAME_LEN 16
+#define CPUIDLE_DESC_LEN 32
+#define CPUIDLE_ABBR_LEN 3
+/**/
+
+struct cpuidle_state {
+ char name[CPUIDLE_NAME_LEN + 1];
+ char abbr[CPUIDLE_ABBR_LEN + 1];
+};
+
+extern struct cpuidle_state cpuidle_states[CPUIDLE_STATE_MAX];
+
+extern unsigned int cpuidle_info_max;
+
+#endif
diff --git a/tools/perf/util/svghelper.c b/tools/perf/util/svghelper.c
index 38b9e40..5cf6c9e 100644
--- a/tools/perf/util/svghelper.c
+++ b/tools/perf/util/svghelper.c
@@ -16,8 +16,13 @@
#include stdlib.h
#include unistd.h
#include string.h
+#include sys/stat.h
+#include fcntl.h
+
+#include linux/cpuidle.h
#include svghelper.h
+#include debug.h
static u64 first_time, last_time;
static u64 turbo_frequency, max_freq;
@@ -108,12 +113,14 @@ void open_svg(const char *filename, int cpus, int rows,
u64 start, u64 end)
fprintf(svgfile, rect.WAITING { fill:rgb(255,214, 48);
fill-opacity:0.6; stroke-width:0; stroke:rgb( 0, 0, 0); } \n);
fprintf(svgfile, rect.cpu { fill:rgb(192,192,192);
fill-opacity:0.2; stroke-width:0.5; stroke:rgb(128,128,128); } \n);
fprintf(svgfile, rect.pstate { fill:rgb(128,128,128);
fill-opacity:0.8; stroke-width:0; } \n);
- fprintf(svgfile, rect.c1 { fill:rgb(255,214,214);
fill-opacity:0.5; stroke-width:0; } \n);
- fprintf(svgfile, rect.c2 { fill:rgb(255,172,172);
fill-opacity:0.5; stroke-width:0; } \n);
- fprintf(svgfile, rect.c3 { fill:rgb(255,130,130);
fill-opacity:0.5; stroke-width:0; } \n);
- fprintf(svgfile, rect.c4 { fill:rgb(255, 88, 88);
fill-opacity:0.5; stroke-width:0; } \n);
- fprintf(svgfile, rect.c5 { fill:rgb(255, 44, 44);
fill-opacity:0.5; stroke-width:0; } \n);
- fprintf(svgfile, rect.c6 { fill:rgb(255, 0, 0);
fill-opacity:0.5; stroke-width:0; } \n);
+ fprintf(svgfile, rect.c0 { fill:rgb(102,255,102);
fill-opacity:0.5; stroke-width:0; } \n);
+ fprintf(svgfile, rect.c1 { fill:rgb(102,255, 0);
fill-opacity:0.5; stroke-width:0; } \n);
+ fprintf(svgfile, rect.c2 { fill:rgb( 0,255,102);
fill-opacity:0.5; stroke-width:0; } \n);
+ fprintf(svgfile, rect.c3 { fill:rgb( 51,255, 51);
fill-opacity:0.5; stroke-width:0; } \n);
+ fprintf(svgfile, rect.c4 { fill:rgb( 51,255, 0);
fill-opacity:0.5; stroke-width:0; } \n);
+ fprintf(svgfile, rect.c5 { fill:rgb( 0,255, 51);
fill-opacity:0.5; stroke-width:0; } \n);
+ fprintf(svgfile, rect.c6 { fill:rgb( 0,204, 0);
fill-opacity:0.5; stroke-width:0; } \n);
+ fprintf(svgfile, rect.c7 { fill:rgb( 0,153, 0);
fill-opacity:0.5; stroke-width:0; } \n);
fprintf(svgfile, line.pstate { stroke:rgb(255,255, 0);
stroke-opacity:0.8; stroke-width:2; } \n);
fprintf(svgfile, ]]\n /style\n/defs\n);
@@ -200,6 +207,81 @@ void svg_waiting(int Yslot, u64 start, u64 end)
fprintf(svgfile, /g\n);
}
+/* Cpuidle info from sysfs ***/
+struct cpuidle_state cpuidle_states[CPUIDLE_STATE_MAX];
+unsigned int cpuidle_info_max;
+
+static void debug_dump_cpuidle_states(void)
+{
+ unsigned int state;
+
+ if
[PATCH 3/9] X86/perf: fix power:cpu_idle double end events and throw cpu_idle events from the cpuidle layer
Currently intel_idle and acpi_idle driver show double cpu_idle exit idle
events - this patch fixes it and makes cpu_idle events throwing less complex.
It also introduces cpu_idle events for all architectures which use
the cpuidle subsystem, namely:
- arch/arm/mach-at91/cpuidle.c
- arch/arm/mach-davinci/cpuidle.c
- arch/arm/mach-kirkwood/cpuidle.c
- arch/arm/mach-omap2/cpuidle34xx.c
- arch/drivers/acpi/processor_idle.c (for all cases, not only mwait)
- arch/x86/kernel/process.c (did throw events before, but was a mess)
- drivers/idle/intel_idle.c (did throw events before)
Convention should be:
Fire cpu_idle events inside the current pm_idle function (not somewhere
down the the callee tree) to keep things easy.
Current possible pm_idle functions in X86:
c1e_idle, poll_idle, cpuidle_idle_call, mwait_idle, default_idle
- this is really easy is now.
This affects userspace:
The type field of the cpu_idle power event can now direclty get
mapped to:
/sys/devices/system/cpu/cpuX/cpuidle/stateX/{name,desc,usage,time,...}
instead of throwing very CPU/mwait specific values.
This change is not visible for the intel_idle driver.
For the acpi_idle driver it should only be visible if the vendor
misses out C-states in his BIOS.
Another (perf timechart) patch reads out cpuidle info of cpu_idle
events from:
/sys/.../cpuidle/stateX/*, then the cpuidle events are mapped
to the correct C-/cpuidle state again, even if e.g. vendors miss
out C-states in their BIOS and for example only export C1 and C3.
- everything is fine.
Signed-off-by: Thomas Renninger tr...@suse.de
CC: Robert Schoene robert.scho...@tu-dresden.de
CC: Jean Pihet j-pi...@ti.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
CC: Len Brown l...@kernel.org
CC: Frederic Weisbecker fweis...@gmail.com
CC: linux...@lists.linux-foundation.org
CC: linux-a...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-perf-us...@vger.kernel.org
CC: linux-omap@vger.kernel.org
---
arch/x86/kernel/process.c|6 --
arch/x86/kernel/process_32.c |4
arch/x86/kernel/process_64.c |6 --
drivers/cpuidle/cpuidle.c| 10 --
drivers/idle/intel_idle.c|2 --
5 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 8b0ad65..b4f9ee7 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -385,6 +385,8 @@ void default_idle(void)
else
local_irq_enable();
current_thread_info()-status |= TS_POLLING;
+ trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
} else {
local_irq_enable();
/* loop is done by the caller */
@@ -442,8 +444,6 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
*/
void mwait_idle_with_hints(unsigned long ax, unsigned long cx)
{
- trace_power_start(POWER_CSTATE, (ax4)+1, smp_processor_id());
- trace_cpu_idle((ax4)+1, smp_processor_id());
if (!need_resched()) {
if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)current_thread_info()-flags);
@@ -470,6 +470,8 @@ static void mwait_idle(void)
__sti_mwait(0, 0);
else
local_irq_enable();
+ trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
} else
local_irq_enable();
}
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 4b9befa..8d12878 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -57,8 +57,6 @@
#include asm/syscalls.h
#include asm/debugreg.h
-#include trace/events/power.h
-
asmlinkage void ret_from_fork(void) __asm__(ret_from_fork);
/*
@@ -113,8 +111,6 @@ void cpu_idle(void)
stop_critical_timings();
pm_idle();
start_critical_timings();
- trace_power_end(smp_processor_id());
- trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 4c818a7..bd387e8 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -51,8 +51,6 @@
#include asm/syscalls.h
#include asm/debugreg.h
-#include trace/events/power.h
-
asmlinkage extern void ret_from_fork(void);
DEFINE_PER_CPU(unsigned long, old_rsp);
@@ -141,10 +139,6 @@ void cpu_idle(void)
pm_idle();
start_critical_timings();
- trace_power_end(smp_processor_id());
- trace_cpu_idle(PWR_EVENT_EXIT,
-
Re: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Fri, Jan 07, 2011 at 02:55:45PM +0530, J, KEERTHY wrote:
On Thu, Jan 6, 2011 at 5:34 PM, Mark Brown
On Thu, Jan 06, 2011 at 09:26:40AM +0530, Keerthy wrote:
+static ssize_t madc_read(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
...
+ return sprintf(buf, %ld\n, val);
Does this return data in the appropriate units - milivolts for voltages?
This function returns the raw channel values read and not in terms of the
units.
It needs to convert the values into real world units before they go to
userspace - look at what applications like sensors do with the values.
+ case TWL4030_MADC_RT:
+ default:
+ break;
This looks odd - the function won't actually do anything for non-SW
conversions but won't return an error?
Ok. In the case of RT conversion request no software setting is required
and it is signal driven. So the function does nothing in case of RT.
Again, the biggest problem is that the code isn't clear.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] perf timechart: Map power:cpu_idle events to the corresponding cpuidle state
Argh, forgot guilt refresh on this one. The changelog could be a bit more detailed by adding: On Friday 07 January 2011 11:29:49 Thomas Renninger wrote: Before, power:cpu_idle events were very specific X86 Intel mwait events. This got fixed with previous patches and cpu_idle events are now thrown by all cpuidle drivers and can be mapped to the corresponding cpuidle state in /sys. This patch reads out the corresponding cpuidle name of a cpu_idle event and uses it in the title line of the chart (c-states Cx in x86, omap2 - DDR self refresh states for various arm archs). It also reads out the corresponding abbr(eviation) and uses the string to draw the cpu idle occurences. This needs a short (3 letter) string to keep the overview in the chart. All features/fixes this patch includes: - Read up cpuidle events from sysfs if available and thus make them architecture independent - Use (free) green color to display idle events in the chart, red is also used by Blocked IO event(s) - Fix wrong class=rect.cX to class=cX idle box svg drawing definitions. This fixes up black idle drawings for eog (eye of gnome) and firefox (inkscape somehow could handle the broken case). Thomas -- 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 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, January 06, 2011 11:28 PM
Kevin,
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
for undefined reference to 'omap2_prm_read_mod_reg'
Hi Santosh
[.]
I think it would be best to use WARN() on these, rather than
WARN_ONCE().
That's because these could be called from different parts of the
code
base, and the stack backtrace will help someone figure out all the
code
that needs to be fixed.
Once you do that, this patch is
Acked-by: Paul Walmsley p...@pwsan.com
With WARN() instead of WARN_ONCE() and Paul's ack, here
is an updated patch.
From 3ccbab8517133c25ed2e470f9622639c98dcbd71 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 4 Jan 2011 20:40:27 +0530
Subject: [PATCH 2/5 v3] omap2plus: prm: Trvial build break fix for
undefined reference to 'omap2_prm_read_mod_reg'
omap2plus_defocnfig build breaks when customised with only ARCH_OMAP4
selected. This is because common files make references to the functions
which are defined only for omap2xxx and omap3xxx.
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `pm_dbg_regset_store':
arch/arm/mach-omap2/pm-debug.c:335: undefined reference to
`omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap2_pm_dump':
arch/arm/mach-omap2/pm-debug.c:121: undefined reference to
`omap2_prm_read_mod_reg'
arch/arm/mach-omap2/pm-debug.c:123: undefined reference to
`omap2_prm_read_mod_reg'
arch/arm/mach-omap2/pm-debug.c:124: undefined reference to
`omap2_prm_read_mod_reg'
arch/arm/mach-omap2/pm-debug.c:125: undefined reference to
`omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap_prcm_arch_reset':
arch/arm/mach-omap2/prcm.c:106: undefined reference to
`omap2_prm_set_mod_reg_bits'
arch/arm/mach-omap2/prcm.c:108: undefined reference to
`omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap_prcm_get_reset_sources':
arch/arm/mach-omap2/prcm.c:53: undefined reference to
`omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `clkdm_clear_all_wkdeps':
arch/arm/mach-omap2/clockdomain.c:545: undefined reference to
`omap2_prm_clear_mod_reg_bits'
arch/arm/mach-omap2/built-in.o: In function `clkdm_del_wkdep':
arch/arm/mach-omap2/clockdomain.c:475: undefined reference to
`omap2_prm_clear_mod_reg_bits'
arch/arm/mach-omap2/built-in.o: In function `clkdm_read_wkdep':
arch/arm/mach-omap2/clockdomain.c:511: undefined reference to
`omap2_prm_read_mod_bits_shift'
arch/arm/mach-omap2/built-in.o: In function `clkdm_add_wkdep':
arch/arm/mach-omap2/clockdomain.c:440: undefined reference to
`omap2_prm_set_mod_reg_bits'
make: *** [.tmp_vmlinux1] Error 1
This patch adds stubs for these functions so that build continues to work.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.h | 63
+++-
1 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 53d44f6..49654c8 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -228,7 +228,67 @@
#ifndef __ASSEMBLER__
-
+/*
+ * Stub omap2xxx/omap3xxx functions so that common files
+ * continue to build when custom builds are used
+ */
+#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
+ defined(CONFIG_ARCH_OMAP3))
+static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+static inline void omap2_prm_write_mod_reg(u32 val, s16 module, u16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+}
+static inline u32 omap2_prm_rmw_mod_reg_bits(u32 mask, u32 bits,
+ s16 module, s16 idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+static inline u32 omap2_prm_set_mod_reg_bits(u32 bits, s16 module, s16
idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+static inline u32 omap2_prm_clear_mod_reg_bits(u32 bits, s16 module, s16
idx)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+static inline u32 omap2_prm_read_mod_bits_shift(s16 domain, s16 idx, u32
mask)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+static
Re: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Fri, Jan 7, 2011 at 4:14 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Fri, Jan 07, 2011 at 02:55:45PM +0530, J, KEERTHY wrote:
On Thu, Jan 6, 2011 at 5:34 PM, Mark Brown
On Thu, Jan 06, 2011 at 09:26:40AM +0530, Keerthy wrote:
+static ssize_t madc_read(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
...
+ return sprintf(buf, %ld\n, val);
Does this return data in the appropriate units - milivolts for voltages?
This function returns the raw channel values read and not in terms of the
units.
It needs to convert the values into real world units before they go to
userspace - look at what applications like sensors do with the values.
Ok. Converting to the real world units will be added.
+ case TWL4030_MADC_RT:
+ default:
+ break;
This looks odd - the function won't actually do anything for non-SW
conversions but won't return an error?
Ok. In the case of RT conversion request no software setting is required
and it is signal driven. So the function does nothing in case of RT.
Again, the biggest problem is that the code isn't clear.
OK. I will add comments explaining the flow.
--
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 v5 00/17] OMAP2,3: hwmod DSS Adaptation
v4 of the DSS hwmod patch series focusses on fixing the review comments. OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design. This patch series decouples the Clocks for DSS in hwmod adaptation changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3. Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling. Summary of the hwmod DSS design: DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database. Each of these platform drivers' init / deinit are handled from core.c's omap_dss_probe() in the exact sequence as required. No Hardcoding of silicon data: hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series. Continue to have custom bus for display panels: omapdss driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver) For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o). Clocks: Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately. For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. Current dss driver: --- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Modified change: --- Platform driver for each DSS HW IP in addition to the software omapdss driver. Omapdss platform driver - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, venc, rfbi] and software libraries like dpi, sdi. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registered to the custom bus. DSS platform driver - initialises DSS IP alone - Handles the clocks related to the DSS and other DSSHW IPs like RFBI, DSI, VENC, DISPC. Previously this was a part of omapdss driver in core.c - Continues to handle the DSS IRQs. - No suspend/resume hooks. DISPC platform driver - initialises DISPC IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DISPC library functions. DSI platform driver - initialises DSI IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DSI library functions. RFBI, VENC platform drivers - initialises DSI,VENC IPs - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide RFBI and VENC library functions. Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp. For the rest of the mentioned platforms, kernel is built with OMAP2_DSS and bootup is tested so that base address and clk_get calls are successful. DSS was built successfully as module, though not tested yet. Changes since v4: 1) Following review comments incorporated: * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41970.html Corrected the clocks to be enabled in omap_dss_probe. Changes since v3: 1.) Following review comments incorporated: * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41705.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41683.html Created a new display.c file for dss driver registration related code. *
[PATCH v5 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for OMAP2420 Display Sub System,. Since DSS is also considered as an
IP as DISPC, RFBI, name it as dss_dss.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 283
1 files changed, 283 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b85c630..14ae4a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -38,6 +38,10 @@ static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_dss_dss_hwmod;
+static struct omap_hwmod omap2420_dss_dispc_hwmod;
+static struct omap_hwmod omap2420_dss_rfbi_hwmod;
+static struct omap_hwmod omap2420_dss_venc_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
static struct omap_hwmod omap2420_gpio1_hwmod;
static struct omap_hwmod omap2420_gpio2_hwmod;
@@ -64,6 +68,13 @@ static struct omap_hwmod_ocp_if *omap2420_l3_main_slaves[] =
{
omap2420_mpu__l3_main,
};
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap2420_dss__l3 = {
+ .master = omap2420_dss_dss_hwmod,
+ .slave = omap2420_l3_main_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap2420_l3_main_masters[] = {
omap2420_l3_main__l4_core,
@@ -470,6 +481,272 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap2420_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2420_dss_irqs[] = {
+ { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap2420_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_masters[] = {
+ omap2420_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2420_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dss = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_dss_dss_hwmod,
+ .clk= dss_ick,
+ .addr = omap2420_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_dss_addrs),
+ .user = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_slaves[] = {
+ omap2420_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = tv_clk, .clk = dss_54m_fck },
+ { .role = sys_clk, .clk = dss2_fck },
+};
+
+static struct omap_hwmod omap2420_dss_dss_hwmod = {
+ .name = dss_dss,
+ .class = omap2420_dss_hwmod_class,
+ .main_clk = dss1_fck, /* instead of dss_fck */
+ .mpu_irqs = omap2420_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_dss_irqs),
+ .sdma_reqs = omap2420_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_dss_sdma_chs),
+
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_DSS1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_DSS_SHIFT,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+ .slaves = omap2420_dss_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_dss_slaves),
+ .masters= omap2420_dss_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_dss_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags =
[PATCH v5 02/17] OMAP2430: hwmod data: add DSS DISPC RFBI VENC
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for OMAP2430 Display Sub System. Since DSS is also considered as an
IP as DISPC, RFBI, name it as dss_dss.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 282
1 files changed, 282 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8ecfbcd..b06eeea 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -38,6 +38,10 @@ static struct omap_hwmod omap2430_mpu_hwmod;
static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
+static struct omap_hwmod omap2430_dss_dss_hwmod;
+static struct omap_hwmod omap2430_dss_dispc_hwmod;
+static struct omap_hwmod omap2430_dss_rfbi_hwmod;
+static struct omap_hwmod omap2430_dss_venc_hwmod;
static struct omap_hwmod omap2430_wd_timer2_hwmod;
static struct omap_hwmod omap2430_gpio1_hwmod;
static struct omap_hwmod omap2430_gpio2_hwmod;
@@ -65,6 +69,13 @@ static struct omap_hwmod_ocp_if *omap2430_l3_main_slaves[] =
{
omap2430_mpu__l3_main,
};
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap2430_dss__l3 = {
+ .master = omap2430_dss_dss_hwmod,
+ .slave = omap2430_l3_main_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap2430_l3_main_masters[] = {
omap2430_l3_main__l4_core,
@@ -469,6 +480,271 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap2430_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2430_dss_irqs[] = {
+ { .irq = 25 },
+};
+static struct omap_hwmod_dma_info omap2430_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_masters[] = {
+ omap2430_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2430_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dss = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_dss_dss_hwmod,
+ .clk= dss_ick,
+ .addr = omap2430_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_dss_addrs),
+ .user = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_slaves[] = {
+ omap2430_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = tv_clk, .clk = dss_54m_fck },
+ { .role = sys_clk, .clk = dss2_fck },
+};
+
+static struct omap_hwmod omap2430_dss_dss_hwmod = {
+ .name = dss_dss,
+ .class = omap2430_dss_hwmod_class,
+ .main_clk = dss1_fck, /* instead of dss_fck */
+ .mpu_irqs = omap2430_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_dss_irqs),
+ .sdma_reqs = omap2430_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2430_dss_sdma_chs),
+
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_DSS1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_DSS_SHIFT,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+ .slaves = omap2430_dss_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_dss_slaves),
+ .masters= omap2430_dss_masters,
+ .masters_cnt= ARRAY_SIZE(omap2430_dss_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags =
[PATCH v5 03/17] OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for Display Sub System applicable for OMAP3430-ES2 onwards and
OMAP36xx. DSS is also considered as an IP as DISPC, RFBI and named as dss_dss.
For all the IP modules in DSS, same clock is needed for enabling. Hwmod sees
DSS IPs as independent IPs, so same clock has to be repeated for .main_clk in
each IP.
OMAP3430ES1 do not have IDLEST bit to poll on for dss IP. So this hwmod is
not applicable for 3430ES1.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 339
1 files changed, 339 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..5f5fbe8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -44,6 +44,11 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
+static struct omap_hwmod omap3xxx_dss_dss_hwmod;
+static struct omap_hwmod omap3xxx_dss_dispc_hwmod;
+static struct omap_hwmod omap3xxx_dss_dsi1_hwmod;
+static struct omap_hwmod omap3xxx_dss_rfbi_hwmod;
+static struct omap_hwmod omap3xxx_dss_venc_hwmod;
static struct omap_hwmod omap3xxx_i2c1_hwmod;
static struct omap_hwmod omap3xxx_i2c2_hwmod;
static struct omap_hwmod omap3xxx_i2c3_hwmod;
@@ -84,6 +89,13 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_main_slaves[] =
{
omap3xxx_mpu__l3_main,
};
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap3xxx_dss__l3 = {
+ .master = omap3xxx_dss_dss_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l3_main_masters[] = {
omap3xxx_l3_main__l4_core,
@@ -664,6 +676,326 @@ static struct omap_hwmod_class i2c_class = {
.sysc = i2c_sysc,
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap3xxx_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap3xxx_dss_irqs[] = {
+ { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+ { .name = dsi1, .dma_req = 74 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_masters[] = {
+ omap3xxx_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_dss_dss_hwmod,
+ .clk= dss_ick,
+ .addr = omap3xxx_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dss_addrs),
+ .user = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_slaves[] = {
+ omap3xxx_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = tv_clk, .clk = dss_tv_fck },
+ { .role = dssclk, .clk = dss_96m_fck },
+ { .role = sys_clk, .clk = dss2_alwon_fck },
+};
+
+static struct omap_hwmod omap3xxx_dss_dss_hwmod = {
+ .name = dss_dss,
+ .class = omap3xxx_dss_hwmod_class,
+ .main_clk = dss1_alwon_fck, /* instead of dss_fck */
+ .mpu_irqs = omap3xxx_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_dss_irqs),
+ .sdma_reqs = omap3xxx_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap3xxx_dss_sdma_chs),
+
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_DSS1_SHIFT,
+ .module_offs = OMAP3430_DSS_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430ES2_ST_DSS_IDLE_SHIFT,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+ .slaves = omap3xxx_dss_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_dss_slaves),
+ .masters= omap3xxx_dss_masters,
+ .masters_cnt=
[PATCH v5 04/17] OMAP2,3 DSS2 Change driver name to omap_display
From: Senthilvadivu Guruswamy svad...@ti.com
Change the driver name from omapdss to omap_display as the driver takes care of
the display devices ie number of panels, type of panels available in the
platform. Change the device name in the board files and 2420,2430,3xxx clock
files from omapdss to omap_display to match the driver name.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |6 +++---
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |6 +++---
arch/arm/mach-omap2/board-omap3evm.c |4 ++--
arch/arm/mach-omap2/board-omap3pandora.c |8
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++--
arch/arm/mach-omap2/board-rx51-video.c |2 +-
arch/arm/mach-omap2/clock2420_data.c |8
arch/arm/mach-omap2/clock2430_data.c |8
arch/arm/mach-omap2/clock3xxx_data.c | 14 +++---
drivers/video/omap2/dss/core.c |2 +-
15 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 3b39ef1..10a399e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -302,7 +302,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
};
static struct platform_device sdp3430_dss_device = {
- .name = omapdss,
+ .name = omap_display,
.id = -1,
.dev= {
.platform_data = sdp3430_dss_data,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index bc15626..2b37dcf 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -368,7 +368,7 @@ static struct omap_dss_board_info am3517_evm_dss_data = {
};
static struct platform_device am3517_evm_dss_device = {
- .name = omapdss,
+ .name = omap_display,
.id = -1,
.dev= {
.platform_data = am3517_evm_dss_data,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 486a3de..f0293a3 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -391,7 +391,7 @@ static struct omap_dss_board_info cm_t35_dss_data = {
};
static struct platform_device cm_t35_dss_device = {
- .name = omapdss,
+ .name = omap_display,
.id = -1,
.dev= {
.platform_data = cm_t35_dss_data,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 451e7ff..f948435 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -189,7 +189,7 @@ static struct omap_dss_board_info devkit8000_dss_data = {
};
static struct platform_device devkit8000_dss_device = {
- .name = omapdss,
+ .name = omap_display,
.id = -1,
.dev= {
.platform_data = devkit8000_dss_data,
@@ -197,7 +197,7 @@ static struct platform_device devkit8000_dss_device = {
};
static struct regulator_consumer_supply devkit8000_vdda_dac_supply =
- REGULATOR_SUPPLY(vdda_dac, omapdss);
+ REGULATOR_SUPPLY(vdda_dac, omap_display);
static uint32_t board_keymap[] = {
KEY(0, 0, KEY_1),
@@ -272,7 +272,7 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
};
static struct regulator_consumer_supply devkit8000_vpll1_supply =
- REGULATOR_SUPPLY(vdds_dsi, omapdss);
+ REGULATOR_SUPPLY(vdds_dsi, omap_display);
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data devkit8000_vmmc1 = {
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 0afa301..46985eb 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -479,7 +479,7 @@ static struct omap_dss_board_info igep2_dss_data = {
};
static struct platform_device igep2_dss_device = {
- .name = omapdss,
+ .name = omap_display,
.id = -1,
.dev= {
.platform_data = igep2_dss_data,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..ebfddb8 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -223,7 +223,7 @@ static struct omap_dss_board_info beagle_dss_data = {
};
static struct platform_device beagle_dss_device = {
-
[PATCH v5 05/17] OMAP2,3 DSS2 Use Regulator init with driver name
From: Senthilvadivu Guruswamy svad...@ti.com
Use driver name in regulator inits needed for display instead of using device
structure name.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 11 +++
arch/arm/mach-omap2/board-cm-t35.c | 12
arch/arm/mach-omap2/board-igep0020.c |6 ++
arch/arm/mach-omap2/board-omap3evm.c |6 ++
arch/arm/mach-omap2/board-omap3stalker.c |6 ++
5 files changed, 13 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 10a399e..29e56a2 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -309,10 +309,8 @@ static struct platform_device sdp3430_dss_device = {
},
};
-static struct regulator_consumer_supply sdp3430_vdda_dac_supply = {
- .supply = vdda_dac,
- .dev= sdp3430_dss_device.dev,
-};
+static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omap_display);
static struct platform_device *sdp3430_devices[] __initdata = {
sdp3430_dss_device,
@@ -540,10 +538,7 @@ static struct regulator_init_data sdp3430_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
- {
- .supply = vdds_dsi,
- .dev= sdp3430_dss_device.dev,
- }
+ REGULATOR_SUPPLY(vdds_dsi, omap_display),
};
static struct regulator_init_data sdp3430_vpll2 = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index f0293a3..307e93a 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -484,15 +484,11 @@ static struct regulator_consumer_supply
cm_t35_vsim_supply = {
.supply = vmmc_aux,
};
-static struct regulator_consumer_supply cm_t35_vdac_supply = {
- .supply = vdda_dac,
- .dev= cm_t35_dss_device.dev,
-};
+static struct regulator_consumer_supply cm_t35_vdac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omap_display);
-static struct regulator_consumer_supply cm_t35_vdvi_supply = {
- .supply = vdvi,
- .dev= cm_t35_dss_device.dev,
-};
+static struct regulator_consumer_supply cm_t35_vdvi_supply =
+ REGULATOR_SUPPLY(vdvi, omap_display);
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data cm_t35_vmmc1 = {
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 46985eb..3b8b0d0 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -486,10 +486,8 @@ static struct platform_device igep2_dss_device = {
},
};
-static struct regulator_consumer_supply igep2_vpll2_supply = {
- .supply = vdds_dsi,
- .dev= igep2_dss_device.dev,
-};
+static struct regulator_consumer_supply igep2_vpll2_supply =
+ REGULATOR_SUPPLY(vdds_dsi, omap_display);
static struct regulator_init_data igep2_vpll2 = {
.constraints = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 2851984..8f9dece 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -494,10 +494,8 @@ static struct twl4030_codec_data omap3evm_codec_data = {
.audio = omap3evm_audio_data,
};
-static struct regulator_consumer_supply omap3_evm_vdda_dac_supply = {
- .supply = vdda_dac,
- .dev= omap3_evm_dss_device.dev,
-};
+static struct regulator_consumer_supply omap3_evm_vdda_dac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omap_display);
/* VDAC for DSS driving S-Video */
static struct regulator_init_data omap3_evm_vdac = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 7f080d6..085ec27 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -437,10 +437,8 @@ static struct twl4030_codec_data omap3stalker_codec_data =
{
.audio = omap3stalker_audio_data,
};
-static struct regulator_consumer_supply omap3_stalker_vdda_dac_supply = {
- .supply = vdda_dac,
- .dev= omap3_stalker_dss_device.dev,
-};
+static struct regulator_consumer_supply omap3_stalker_vdda_dac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omap_display);
/* VDAC for DSS driving S-Video */
static struct regulator_init_data omap3_stalker_vdac = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 06/17] OMAP2,3: DSS2: Create new file display.c for central dss driver registration.
A new file display.c is introduced for display driver init, which adds a
function
omap_display_init to do the DSS driver registration. This is the first step in
moving
away registration of DSS from board files into a common place.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/display.c | 57 +
arch/arm/plat-omap/include/plat/display.h |4 ++
3 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/display.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4ab82f6..57b89e6 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -237,3 +237,5 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
+
+obj-y += display.o
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
new file mode 100644
index 000..26d3feb
--- /dev/null
+++ b/arch/arm/mach-omap2/display.c
@@ -0,0 +1,57 @@
+/*
+ * OMAP2plus display device setup / initialization.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Senthilvadivu Guruswamy
+ * Sumit Semwal
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed 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/init.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+
+#include plat/display.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+
+#ifdef CONFIG_OMAP2_DSS
+
+static struct platform_device omap_display_device = {
+ .name = omap_display,
+ .id= -1,
+ .dev= {
+ .platform_data = NULL,
+ },
+};
+
+int __init omap_display_init(struct omap_dss_board_info
+ *board_data)
+{
+ int r = 0;
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0)
+ printk(KERN_ERR Unable to register OMAP-Display device\n);
+
+ return r;
+}
+
+#else
+int __init omap_display_init(struct omap_dss_board_info *board_data)
+{
+ return 0;
+}
+#endif
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index c915a66..871bbae 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -23,6 +23,7 @@
#include linux/list.h
#include linux/kobject.h
#include linux/device.h
+#include linux/platform_device.h
#include asm/atomic.h
#define DISPC_IRQ_FRAMEDONE(1 0)
@@ -220,6 +221,9 @@ struct omap_dss_board_info {
struct omap_dss_device *default_device;
};
+/* Init with the board info */
+extern int omap_display_init(struct omap_dss_board_info *board_data);
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/17] OMAP2,3: DSS2: board files: replace platform_device_register with omap_display_init()
From: Senthilvadivu Guruswamy svad...@ti.com
This patch updated board files to replace platform_device_register or
platform_add_devices of DSS with omap_display_init(). This moves away
registration of DSS from board files into a common place.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 14 +-
arch/arm/mach-omap2/board-am3517evm.c| 16 +---
arch/arm/mach-omap2/board-cm-t35.c | 10 +-
arch/arm/mach-omap2/board-devkit8000.c | 10 +-
arch/arm/mach-omap2/board-igep0020.c | 10 +-
arch/arm/mach-omap2/board-omap3beagle.c | 10 +-
arch/arm/mach-omap2/board-omap3evm.c | 14 +-
arch/arm/mach-omap2/board-omap3pandora.c | 10 +-
arch/arm/mach-omap2/board-omap3stalker.c | 10 +-
arch/arm/mach-omap2/board-rx51-video.c | 15 +--
10 files changed, 10 insertions(+), 109 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 29e56a2..e1a3318 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -301,21 +301,9 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = sdp3430_lcd_device,
};
-static struct platform_device sdp3430_dss_device = {
- .name = omap_display,
- .id = -1,
- .dev= {
- .platform_data = sdp3430_dss_data,
- },
-};
-
static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
REGULATOR_SUPPLY(vdda_dac, omap_display);
-static struct platform_device *sdp3430_devices[] __initdata = {
- sdp3430_dss_device,
-};
-
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
@@ -790,7 +778,7 @@ static void __init omap_3430sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
- platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+ omap_display_init(sdp3430_dss_data);
if (omap_rev() OMAP3430_REV_ES1_0)
ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
else
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 2b37dcf..782d270 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -367,24 +367,12 @@ static struct omap_dss_board_info am3517_evm_dss_data = {
.default_device = am3517_evm_lcd_device,
};
-static struct platform_device am3517_evm_dss_device = {
- .name = omap_display,
- .id = -1,
- .dev= {
- .platform_data = am3517_evm_dss_data,
- },
-};
-
/*
* Board initialization
*/
static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
};
-static struct platform_device *am3517_evm_devices[] __initdata = {
- am3517_evm_dss_device,
-};
-
static void __init am3517_evm_init_irq(void)
{
omap_board_config = am3517_evm_config;
@@ -484,9 +472,7 @@ static void __init am3517_evm_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
am3517_evm_i2c_init();
- platform_add_devices(am3517_evm_devices,
- ARRAY_SIZE(am3517_evm_devices));
-
+ omap_display_init(am3517_evm_dss_data);
omap_serial_init();
/* Configure GPIO for EHCI port */
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 307e93a..c5e80ad 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -390,14 +390,6 @@ static struct omap_dss_board_info cm_t35_dss_data = {
.default_device = cm_t35_dvi_device,
};
-static struct platform_device cm_t35_dss_device = {
- .name = omap_display,
- .id = -1,
- .dev= {
- .platform_data = cm_t35_dss_data,
- },
-};
-
static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,/* 0: slave, 1: master */
@@ -457,7 +449,7 @@ static void __init cm_t35_init_display(void)
msleep(50);
gpio_set_value(lcd_en_gpio, 1);
- err = platform_device_register(cm_t35_dss_device);
+ err = omap_display_init(cm_t35_dss_data);
if (err) {
pr_err(CM-T35: failed to register DSS device\n);
goto err_dev_reg;
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index f948435..78f2951 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -188,14 +188,6 @@ static struct omap_dss_board_info devkit8000_dss_data = {
.default_device = devkit8000_lcd_device,
};
-static struct platform_device devkit8000_dss_device = {
- .name
[PATCH v5 08/17] OMAP2,3: DSS2: Build omap_device for each DSS HWIP
From: Senthilvadivu Guruswamy svad...@ti.com
Looks up the hwmod database for each of the given DSS HW IP and builds
omap_device which inturn does the platform device register for each of DSS HW IP
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/display.c | 44 +
arch/arm/plat-omap/include/plat/display.h |6
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 26d3feb..276b800 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -36,10 +36,54 @@ static struct platform_device omap_display_device = {
},
};
+static struct omap_device_pm_latency omap_dss_latency[] = {
+ [0] = {
+ .deactivate_func= omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ },
+};
+
int __init omap_display_init(struct omap_dss_board_info
*board_data)
{
int r = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ int i;
+ struct omap_display_platform_data pdata;
+ char *oh_name[] = { dss_dss, /* omap2,3 */
+ dss_dispc,/* omap2,3 */
+ dss_rfbi, /* omap2,3 */
+ dss_venc, /* omap2,3 */
+ dss_dsi1 }; /* omap3 */
+ char *dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc, omap_dsi1 };
+ int oh_count;
+
+ if (cpu_is_omap24xx()) {
+ oh_count = ARRAY_SIZE(oh_name) - 1;
+ /* last hwmod dev in oh_name is not available for omap2 */
+ } else {
+ oh_count = ARRAY_SIZE(oh_name);
+ }
+
+ pdata.board_data= board_data;
+ pdata.board_data-get_last_off_on_transaction_id = NULL;
+
+ for (i = 0; i oh_count; i++) {
+ oh = omap_hwmod_lookup(oh_name[i]);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name[i]);
+ return r;
+ }
+ od = omap_device_build(dev_name[i], -1, oh, pdata,
+ sizeof(struct omap_display_platform_data),
+ omap_dss_latency,
+ ARRAY_SIZE(omap_dss_latency), 0);
+
+ WARN((IS_ERR(od)), Could not build omap_device for %s\n,
+ oh_name[i]);
+ }
omap_display_device.dev.platform_data = board_data;
r = platform_device_register(omap_display_device);
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 871bbae..23afd6d 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -26,6 +26,7 @@
#include linux/platform_device.h
#include asm/atomic.h
+
#define DISPC_IRQ_FRAMEDONE(1 0)
#define DISPC_IRQ_VSYNC(1 1)
#define DISPC_IRQ_EVSYNC_EVEN (1 2)
@@ -224,6 +225,11 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+struct omap_display_platform_data {
+ struct omap_dss_board_info *board_data;
+ /* TODO: Additional members to be added when PM is considered */
+};
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 09/17] OMAP2,3: DSS2: DSS: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver of DSS is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
DSS platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/video/omap2/dss/core.c | 21 +++
drivers/video/omap2/dss/dss.c | 55 ++-
drivers/video/omap2/dss/dss.h |4 +-
3 files changed, 65 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 48d20d8..faca859 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -497,9 +497,9 @@ static inline void dss_uninitialize_debugfs(void)
static int omap_dss_probe(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev-dev.platform_data;
- int skip_init = 0;
int r;
int i;
+ int skip_init = 0;
core.pdev = pdev;
@@ -517,15 +517,9 @@ static int omap_dss_probe(struct platform_device *pdev)
core.ctx_id = dss_get_ctx_id();
DSSDBG(initial ctx id %u\n, core.ctx_id);
-#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
- /* DISPC_CONTROL */
- if (omap_readl(0x48050440) 1) /* LCD enabled? */
- skip_init = 1;
-#endif
-
- r = dss_init(skip_init);
+ r = dss_init_platform_driver();
if (r) {
- DSSERR(Failed to initialize DSS\n);
+ DSSERR(Failed to initialize DSS platform driver\n);
goto err_dss;
}
@@ -553,6 +547,11 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_venc;
}
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
@@ -610,7 +609,7 @@ err_dispc:
err_dpi:
rfbi_exit();
err_rfbi:
- dss_exit();
+ dss_deinit_platform_driver();
err_dss:
dss_clk_disable_all_no_ctx();
dss_put_clocks();
@@ -636,7 +635,7 @@ static int omap_dss_remove(struct platform_device *pdev)
sdi_exit();
}
- dss_exit();
+ dss_deinit_platform_driver();
/* these should be removed at some point */
c = core.dss_ick-usecount;
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..ebb294a 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -59,6 +59,7 @@ struct dss_reg {
dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
static struct {
+ struct platform_device *pdev;
void __iomem*base;
struct clk *dpll4_m4_ck;
@@ -549,7 +550,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
}
-int dss_init(bool skip_init)
+static int dss_init(bool skip_init)
{
int r;
u32 rev;
@@ -629,7 +630,7 @@ fail0:
return r;
}
-void dss_exit(void)
+static void dss_exit(void)
{
if (cpu_is_omap34xx())
clk_put(dss.dpll4_m4_ck);
@@ -639,3 +640,53 @@ void dss_exit(void)
iounmap(dss.base);
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ int r;
+ int skip_init = 0;
+
+ dss.pdev = pdev;
+
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
+
+ r = dss_init(skip_init);
+ if (r) {
+ DSSERR(Failed to initialize DSS\n);
+ goto err_dss;
+ }
+
+err_dss:
+
+ return r;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ dss_exit();
+
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .driver = {
+ .name = omap_dss,
+ .owner = THIS_MODULE,
+ },
+};
+
+int dss_init_platform_driver(void)
+{
+ return platform_driver_register(omap_dsshw_driver);
+}
+
+void dss_deinit_platform_driver(void)
+{
+ return platform_driver_unregister(omap_dsshw_driver);
+}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 5c7940d..50b4223 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -214,8 +214,8 @@ void dss_overlay_setup_l4_manager(struct
omap_overlay_manager *mgr);
void dss_recheck_connections(struct omap_dss_device *dssdev, bool force);
/* DSS */
[PATCH v5 10/17] OMAP2,3: DSS2: Move clocks from core driver to dss driver
From: Senthilvadivu Guruswamy svad...@ti.com
All clock management is moved to dss platform driver. clk_get/put APIs use
dss device instead of core platform device.
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So the device name is changed from omap_display to omap_dss in 2420, 2430,
3xxx clock database files. Now the core driver omap_display only takes care
of panel registration with the custom bus.
core driver also uses the clk_enable() / clk_disable() APIs exposed by DSS for
clock management.
DSS driver would do clock management of clocks needed by DISPC, RFBI, DSI, VENC
TODO: The clock content would be adapted to omap_hwmod in a seperate series.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c |8 +-
arch/arm/mach-omap2/clock2430_data.c |8 +-
arch/arm/mach-omap2/clock3xxx_data.c | 14 +-
drivers/video/omap2/dss/core.c | 375 +-
drivers/video/omap2/dss/dss.c| 366 +-
drivers/video/omap2/dss/dss.h| 13 +-
6 files changed, 392 insertions(+), 392 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index a220820..7a56c67 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1786,10 +1786,10 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gfx_2d_fck, gfx_2d_fck,CK_242X),
CLK(NULL, gfx_ick, gfx_ick, CK_242X),
/* DSS domain clocks */
- CLK(omap_display, ick, dss_ick, CK_242X),
- CLK(omap_display, dss1_fck, dss1_fck, CK_242X),
- CLK(omap_display, dss2_fck, dss2_fck, CK_242X),
- CLK(omap_display, tv_fck, dss_54m_fck, CK_242X),
+ CLK(omap_dss, ick, dss_ick, CK_242X),
+ CLK(omap_dss, dss1_fck, dss1_fck, CK_242X),
+ CLK(omap_dss, dss2_fck, dss2_fck, CK_242X),
+ CLK(omap_dss, tv_fck, dss_54m_fck, CK_242X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_242X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 78f7712..48d3437 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1890,10 +1890,10 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, mdm_ick, mdm_ick, CK_243X),
CLK(NULL, mdm_osc_ck, mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK(omap_display, ick, dss_ick, CK_243X),
- CLK(omap_display, dss1_fck, dss1_fck, CK_243X),
- CLK(omap_display, dss2_fck, dss2_fck, CK_243X),
- CLK(omap_display, tv_fck, dss_54m_fck, CK_243X),
+ CLK(omap_dss, ick, dss_ick, CK_243X),
+ CLK(omap_dss, dss1_fck, dss1_fck, CK_243X),
+ CLK(omap_dss, dss2_fck, dss2_fck, CK_243X),
+ CLK(omap_dss, tv_fck, dss_54m_fck, CK_243X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_243X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 8c9e4c4..be9077b 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3355,13 +3355,13 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_34XX | CK_36XX),
CLK(NULL, sha11_ick,sha11_ick, CK_34XX | CK_36XX),
CLK(NULL, des1_ick, des1_ick, CK_34XX | CK_36XX),
- CLK(omap_display, dss1_fck, dss1_alwon_fck_3430es1,
CK_3430ES1),
- CLK(omap_display, dss1_fck, dss1_alwon_fck_3430es2,
CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
- CLK(omap_display, tv_fck, dss_tv_fck,CK_3XXX),
- CLK(omap_display, video_fck,dss_96m_fck, CK_3XXX),
- CLK(omap_display, dss2_fck, dss2_alwon_fck, CK_3XXX),
- CLK(omap_display, ick, dss_ick_3430es1,
CK_3430ES1),
- CLK(omap_display, ick, dss_ick_3430es2,
CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+ CLK(omap_dss, dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
+ CLK(omap_dss, dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(omap_dss, tv_fck, dss_tv_fck,CK_3XXX),
+ CLK(omap_dss, video_fck,dss_96m_fck, CK_3XXX),
+ CLK(omap_dss, dss2_fck, dss2_alwon_fck, CK_3XXX),
+ CLK(omap_dss, ick, dss_ick_3430es1, CK_3430ES1),
+ CLK(omap_dss, ick, dss_ick_3430es2,
[PATCH v5 11/17] OMAP2,3: DSS2: RFBI: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for RFBI is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
RFBI platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/video/omap2/dss/core.c |8 ++--
drivers/video/omap2/dss/dss.h |8 ++--
drivers/video/omap2/dss/rfbi.c | 110
3 files changed, 74 insertions(+), 52 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 1ba4c81..2ad7351 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -201,9 +201,9 @@ static int omap_dss_probe(struct platform_device *pdev)
/* keep clocks enabled to prevent context saves/restores during init */
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
- r = rfbi_init();
+ r = rfbi_init_platform_driver();
if (r) {
- DSSERR(Failed to initialize rfbi\n);
+ DSSERR(Failed to initialize rfbi platform driver\n);
goto err_rfbi;
}
@@ -285,7 +285,7 @@ err_venc:
err_dispc:
dpi_exit();
err_dpi:
- rfbi_exit();
+ rfbi_deinit_platform_driver();
err_rfbi:
dss_deinit_platform_driver();
err_dss:
@@ -303,7 +303,7 @@ static int omap_dss_remove(struct platform_device *pdev)
venc_exit();
dispc_exit();
dpi_exit();
- rfbi_exit();
+ rfbi_deinit_platform_driver();
if (cpu_is_omap34xx()) {
dsi_exit();
sdi_exit();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 7c6bff5..665ad58 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -421,8 +421,8 @@ static inline void venc_exit(void)
/* RFBI */
#ifdef CONFIG_OMAP2_DSS_RFBI
-int rfbi_init(void);
-void rfbi_exit(void);
+int rfbi_init_platform_driver(void);
+void rfbi_deinit_platform_driver(void);
void rfbi_dump_regs(struct seq_file *s);
int rfbi_configure(int rfbi_module, int bpp, int lines);
@@ -433,11 +433,11 @@ void rfbi_set_timings(int rfbi_module, struct
rfbi_timings *t);
unsigned long rfbi_get_max_tx_rate(void);
int rfbi_init_display(struct omap_dss_device *display);
#else
-static inline int rfbi_init(void)
+static inline int rfbi_init_platform_driver(void)
{
return 0;
}
-static inline void rfbi_exit(void)
+static inline void rfbi_deinit_platform_driver(void)
{
}
#endif
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index bbe6246..52bfb1c 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -100,6 +100,7 @@ static int rfbi_convert_timings(struct rfbi_timings *t);
static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
static struct {
+ struct platform_device *pdev;
void __iomem*base;
unsigned long l4_khz;
@@ -957,50 +958,6 @@ void rfbi_dump_regs(struct seq_file *s)
#undef DUMPREG
}
-int rfbi_init(void)
-{
- u32 rev;
- u32 l;
-
- spin_lock_init(rfbi.cmd_lock);
-
- init_completion(rfbi.cmd_done);
- atomic_set(rfbi.cmd_fifo_full, 0);
- atomic_set(rfbi.cmd_pending, 0);
-
- rfbi.base = ioremap(RFBI_BASE, SZ_256);
- if (!rfbi.base) {
- DSSERR(can't ioremap RFBI\n);
- return -ENOMEM;
- }
-
- rfbi_enable_clocks(1);
-
- msleep(10);
-
- rfbi.l4_khz = dss_clk_get_rate(DSS_CLK_ICK) / 1000;
-
- /* Enable autoidle and smart-idle */
- l = rfbi_read_reg(RFBI_SYSCONFIG);
- l |= (1 0) | (2 3);
- rfbi_write_reg(RFBI_SYSCONFIG, l);
-
- rev = rfbi_read_reg(RFBI_REVISION);
- printk(KERN_INFO OMAP RFBI rev %d.%d\n,
- FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
-
- rfbi_enable_clocks(0);
-
- return 0;
-}
-
-void rfbi_exit(void)
-{
- DSSDBG(rfbi_exit\n);
-
- iounmap(rfbi.base);
-}
-
int omapdss_rfbi_display_enable(struct omap_dss_device *dssdev)
{
int r;
@@ -1054,3 +1011,68 @@ int rfbi_init_display(struct omap_dss_device *dssdev)
dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
return 0;
}
+
+/* RFBI HW IP initialisation */
+static int omap_rfbihw_probe(struct platform_device *pdev)
+{
+ u32 rev;
+ u32 l;
+
+ rfbi.pdev = pdev;
+
+ spin_lock_init(rfbi.cmd_lock);
+
+ init_completion(rfbi.cmd_done);
+ atomic_set(rfbi.cmd_fifo_full, 0);
+ atomic_set(rfbi.cmd_pending, 0);
+
+ rfbi.base = ioremap(RFBI_BASE, SZ_256);
+ if (!rfbi.base) {
+ DSSERR(can't ioremap RFBI\n);
+ return -ENOMEM;
+ }
+
+ rfbi_enable_clocks(1);
+
+
[PATCH v5 12/17] OMAP2,3: DSS2: DISPC: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DISPC is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
DISPC platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/video/omap2/dss/core.c |8 ++--
drivers/video/omap2/dss/dispc.c | 105 ---
drivers/video/omap2/dss/dss.h |4 +-
3 files changed, 70 insertions(+), 47 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 2ad7351..ace869e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -213,9 +213,9 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
- r = dispc_init();
+ r = dispc_init_platform_driver();
if (r) {
- DSSERR(Failed to initialize dispc\n);
+ DSSERR(Failed to initialize dispc platform driver\n);
goto err_dispc;
}
@@ -281,7 +281,7 @@ err_dsi:
err_sdi:
venc_exit();
err_venc:
- dispc_exit();
+ dispc_deinit_platform_driver();
err_dispc:
dpi_exit();
err_dpi:
@@ -301,7 +301,7 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
venc_exit();
- dispc_exit();
+ dispc_deinit_platform_driver();
dpi_exit();
rfbi_deinit_platform_driver();
if (cpu_is_omap34xx()) {
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fa40fa5..e19c4cd 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -173,6 +173,7 @@ struct dispc_irq_stats {
};
static struct {
+ struct platform_device *pdev;
void __iomem*base;
u32 fifo_size[3];
@@ -3079,47 +3080,6 @@ static void _omap_dispc_initial_config(void)
dispc_read_plane_fifo_sizes();
}
-int dispc_init(void)
-{
- u32 rev;
-
- spin_lock_init(dispc.irq_lock);
-
-#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
- spin_lock_init(dispc.irq_stats_lock);
- dispc.irq_stats.last_reset = jiffies;
-#endif
-
- INIT_WORK(dispc.error_work, dispc_error_worker);
-
- dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
- if (!dispc.base) {
- DSSERR(can't ioremap DISPC\n);
- return -ENOMEM;
- }
-
- enable_clocks(1);
-
- _omap_dispc_initial_config();
-
- _omap_dispc_initialize_irq();
-
- dispc_save_context();
-
- rev = dispc_read_reg(DISPC_REVISION);
- printk(KERN_INFO OMAP DISPC rev %d.%d\n,
- FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
-
- enable_clocks(0);
-
- return 0;
-}
-
-void dispc_exit(void)
-{
- iounmap(dispc.base);
-}
-
int dispc_enable_plane(enum omap_plane plane, bool enable)
{
DSSDBG(dispc_enable_plane %d, %d\n, plane, enable);
@@ -3167,3 +3127,66 @@ int dispc_setup_plane(enum omap_plane plane,
return r;
}
+
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ u32 rev;
+ dispc.pdev = pdev;
+
+ spin_lock_init(dispc.irq_lock);
+
+#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
+ spin_lock_init(dispc.irq_stats_lock);
+ dispc.irq_stats.last_reset = jiffies;
+#endif
+
+ INIT_WORK(dispc.error_work, dispc_error_worker);
+
+ dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+ if (!dispc.base) {
+ DSSERR(can't ioremap DISPC\n);
+ return -ENOMEM;
+ }
+
+ enable_clocks(1);
+
+ _omap_dispc_initial_config();
+
+ _omap_dispc_initialize_irq();
+
+ dispc_save_context();
+
+ rev = dispc_read_reg(DISPC_REVISION);
+ printk(KERN_INFO OMAP DISPC rev %d.%d\n,
+ FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
+
+ enable_clocks(0);
+
+ return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+ iounmap(dispc.base);
+ return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+ .probe = omap_dispchw_probe,
+ .remove = omap_dispchw_remove,
+ .driver = {
+ .name = omap_dispc,
+ .owner = THIS_MODULE,
+ },
+};
+
+int dispc_init_platform_driver(void)
+{
+ return platform_driver_register(omap_dispchw_driver);
+}
+
+void dispc_deinit_platform_driver(void)
+{
+ return platform_driver_unregister(omap_dispchw_driver);
+}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 665ad58..90048b9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -319,8 +319,8 @@ static
[PATCH v5 13/17] OMAP2,3: DSS2: VENC: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for VENC is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
Also, venc_vdda_dac reading is moved to venc.c.
VENC platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
drivers/video/omap2/dss/core.c | 28 +---
drivers/video/omap2/dss/dss.h |9 +--
drivers/video/omap2/dss/venc.c | 116 +++
4 files changed, 85 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index e1a3318..83baba7 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -302,7 +302,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
};
static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
- REGULATOR_SUPPLY(vdda_dac, omap_display);
+ REGULATOR_SUPPLY(vdda_dac, omap_venc);
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index ace869e..5314593 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -43,7 +43,6 @@ static struct {
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
- struct regulator *vdda_dac_reg;
} core;
static char *def_disp_name;
@@ -85,20 +84,6 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
}
-struct regulator *dss_get_vdda_dac(void)
-{
- struct regulator *reg;
-
- if (core.vdda_dac_reg != NULL)
- return core.vdda_dac_reg;
-
- reg = regulator_get(core.pdev-dev, vdda_dac);
- if (!IS_ERR(reg))
- core.vdda_dac_reg = reg;
-
- return reg;
-}
-
#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
static int dss_debug_show(struct seq_file *s, void *unused)
{
@@ -219,9 +204,9 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dispc;
}
- r = venc_init(pdev);
+ r = venc_init_platform_driver();
if (r) {
- DSSERR(Failed to initialize venc\n);
+ DSSERR(Failed to initialize venc platform driver\n);
goto err_venc;
}
@@ -279,7 +264,7 @@ err_dsi:
if (cpu_is_omap34xx())
sdi_exit();
err_sdi:
- venc_exit();
+ venc_deinit_platform_driver();
err_venc:
dispc_deinit_platform_driver();
err_dispc:
@@ -300,7 +285,7 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
- venc_exit();
+ venc_deinit_platform_driver();
dispc_deinit_platform_driver();
dpi_exit();
rfbi_deinit_platform_driver();
@@ -597,11 +582,6 @@ static void __exit omap_dss_exit(void)
core.vdds_sdi_reg = NULL;
}
- if (core.vdda_dac_reg != NULL) {
- regulator_put(core.vdda_dac_reg);
- core.vdda_dac_reg = NULL;
- }
-
platform_driver_unregister(omap_dss_driver);
omap_dss_bus_unregister();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 90048b9..c1ab6c6 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -172,7 +172,6 @@ struct platform_device;
struct bus_type *dss_get_bus(void);
struct regulator *dss_get_vdds_dsi(void);
struct regulator *dss_get_vdds_sdi(void);
-struct regulator *dss_get_vdda_dac(void);
/* display */
int dss_suspend_all_devices(void);
@@ -405,16 +404,16 @@ int dispc_get_clock_div(struct dispc_clock_info *cinfo);
/* VENC */
#ifdef CONFIG_OMAP2_DSS_VENC
-int venc_init(struct platform_device *pdev);
-void venc_exit(void);
+int venc_init_platform_driver(void);
+void venc_deinit_platform_driver(void);
void venc_dump_regs(struct seq_file *s);
int venc_init_display(struct omap_dss_device *display);
#else
-static inline int venc_init(struct platform_device *pdev)
+static inline int venc_init_platform_driver(void)
{
return 0;
}
-static inline void venc_exit(void)
+static inline void venc_deinit_platform_driver(void)
{
}
#endif
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index eff3505..029fbc3 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -289,6 +289,7 @@ const struct omap_video_timings omap_dss_ntsc_timings = {
EXPORT_SYMBOL(omap_dss_ntsc_timings);
static struct {
+ struct platform_device *pdev;
void __iomem *base;
struct mutex venc_lock;
u32 wss_data;
@@ -306,6 +307,17 @@ static inline u32
[PATCH v5 14/17] OMAP2,3: DSS2: DSI: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DSI is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
Also, vdds_dsi regulator handling is copied to dsi.c.
DSI platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
drivers/video/omap2/dss/core.c |8 ++--
drivers/video/omap2/dss/dsi.c | 64 +--
drivers/video/omap2/dss/dss.h |8 ++--
4 files changed, 70 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 83baba7..88f5b01 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -527,6 +527,7 @@ static struct regulator_init_data sdp3430_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omap_display),
+ REGULATOR_SUPPLY(vdds_dsi, omap_dsi1),
};
static struct regulator_init_data sdp3430_vpll2 = {
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 5314593..afc0f3b 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -222,9 +222,9 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_sdi;
}
- r = dsi_init(pdev);
+ r = dsi_init_platform_driver();
if (r) {
- DSSERR(Failed to initialize DSI\n);
+ DSSERR(Failed to initialize DSI platform driver\n);
goto err_dsi;
}
}
@@ -259,7 +259,7 @@ err_register:
dss_uninitialize_debugfs();
err_debugfs:
if (cpu_is_omap34xx())
- dsi_exit();
+ dsi_deinit_platform_driver();
err_dsi:
if (cpu_is_omap34xx())
sdi_exit();
@@ -290,7 +290,7 @@ static int omap_dss_remove(struct platform_device *pdev)
dpi_exit();
rfbi_deinit_platform_driver();
if (cpu_is_omap34xx()) {
- dsi_exit();
+ dsi_deinit_platform_driver();
sdi_exit();
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index aa4f7a5..411d0c6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -222,6 +222,7 @@ struct dsi_irq_stats {
static struct
{
+ struct platform_device *pdev;
void __iomem*base;
struct dsi_clock_info current_cinfo;
@@ -292,6 +293,20 @@ static inline u32 dsi_read_reg(const struct dsi_reg idx)
return __raw_readl(dsi.base + idx.idx);
}
+static struct regulator *dsi_get_vdds_dsi(void)
+{
+ struct regulator *reg;
+
+ if (dsi.vdds_dsi_reg != NULL)
+ return dsi.vdds_dsi_reg;
+
+ reg = regulator_get(dsi.pdev-dev, vdds_dsi);
+ if (!IS_ERR(reg))
+ dsi.vdds_dsi_reg = reg;
+
+ return reg;
+}
+
void dsi_save_context(void)
{
@@ -3235,7 +3250,7 @@ void dsi_wait_dsi2_pll_active(void)
DSSERR(DSI2 PLL clock not active\n);
}
-int dsi_init(struct platform_device *pdev)
+static int dsi_init(struct platform_device *pdev)
{
u32 rev;
int r;
@@ -3272,7 +3287,7 @@ int dsi_init(struct platform_device *pdev)
goto err1;
}
- dsi.vdds_dsi_reg = dss_get_vdds_dsi();
+ dsi.vdds_dsi_reg = dsi_get_vdds_dsi();
if (IS_ERR(dsi.vdds_dsi_reg)) {
DSSERR(can't get VDDS_DSI regulator\n);
r = PTR_ERR(dsi.vdds_dsi_reg);
@@ -3295,8 +3310,13 @@ err1:
return r;
}
-void dsi_exit(void)
+static void dsi_exit(void)
{
+ if (dsi.vdds_dsi_reg != NULL) {
+ regulator_put(dsi.vdds_dsi_reg);
+ dsi.vdds_dsi_reg = NULL;
+ }
+
iounmap(dsi.base);
destroy_workqueue(dsi.workqueue);
@@ -3304,3 +3324,41 @@ void dsi_exit(void)
DSSDBG(omap_dsi_exit\n);
}
+/* DSI1 HW IP initialisation */
+static int omap_dsi1hw_probe(struct platform_device *pdev)
+{
+ int r;
+ dsi.pdev = pdev;
+ r = dsi_init(pdev);
+ if (r) {
+ DSSERR(Failed to initialize DSI\n);
+ goto err_dsi;
+ }
+err_dsi:
+ return r;
+}
+
+static int omap_dsi1hw_remove(struct platform_device *pdev)
+{
+ dsi_exit();
+ return 0;
+}
+
+static struct platform_driver omap_dsi1hw_driver = {
+ .probe = omap_dsi1hw_probe,
+ .remove = omap_dsi1hw_remove,
+ .driver = {
+ .name = omap_dsi1,
+ .owner =
[PATCH v5 16/17] OMAP2,3: DSS2: Use platform device to get baseaddr
From: Senthilvadivu Guruswamy svad...@ti.com
DSS, DISPC, DSI, RFBI, VENC baseaddr can be obtained from
platform_get_resource().
This API in turn picks the right silicon baseaddr from the hwmod database.
So hardcoding of base addr could be removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dispc.c | 11 ---
drivers/video/omap2/dss/dsi.c | 12 +---
drivers/video/omap2/dss/dss.c | 11 ---
drivers/video/omap2/dss/rfbi.c | 10 +++---
drivers/video/omap2/dss/venc.c | 11 ---
5 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 97dfc84..9da59fe 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -42,8 +42,6 @@
#include dss_features.h
/* DISPC */
-#define DISPC_BASE 0x48050400
-
#define DISPC_SZ_REGS SZ_1K
struct dispc_reg { u16 idx; };
@@ -3132,6 +3130,8 @@ int dispc_setup_plane(enum omap_plane plane,
static int omap_dispchw_probe(struct platform_device *pdev)
{
u32 rev;
+ struct resource *dispc_mem;
+
dispc.pdev = pdev;
spin_lock_init(dispc.irq_lock);
@@ -3143,7 +3143,12 @@ static int omap_dispchw_probe(struct platform_device
*pdev)
INIT_WORK(dispc.error_work, dispc_error_worker);
- dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+ dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
+ if (!dispc_mem) {
+ DSSERR(can't get IORESOURCE_MEM DISPC\n);
+ return -EINVAL;
+ }
+ dispc.base = ioremap(dispc_mem-start, resource_size(dispc_mem));
if (!dispc.base) {
DSSERR(can't ioremap DISPC\n);
return -ENOMEM;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index cf1a2ad..74ee776 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -42,8 +42,6 @@
/*#define VERBOSE_IRQ*/
#define DSI_CATCH_MISSING_TE
-#define DSI_BASE 0x4804FC00
-
struct dsi_reg { u16 idx; };
#define DSI_REG(idx) ((const struct dsi_reg) { idx })
@@ -3254,6 +3252,7 @@ static int dsi_init(struct platform_device *pdev)
{
u32 rev;
int r;
+ struct resource *dsi_mem;
spin_lock_init(dsi.errors_lock);
dsi.errors = 0;
@@ -3280,7 +3279,13 @@ static int dsi_init(struct platform_device *pdev)
dsi.te_timer.function = dsi_te_timeout;
dsi.te_timer.data = 0;
#endif
- dsi.base = ioremap(DSI_BASE, DSI_SZ_REGS);
+ dsi_mem = platform_get_resource(dsi.pdev, IORESOURCE_MEM, 0);
+ if (!dsi_mem) {
+ DSSERR(can't get IORESOURCE_MEM DSI\n);
+ r = -EINVAL;
+ goto err0;
+ }
+ dsi.base = ioremap(dsi_mem-start, resource_size(dsi_mem));
if (!dsi.base) {
DSSERR(can't ioremap DSI\n);
r = -ENOMEM;
@@ -3307,6 +3312,7 @@ err2:
iounmap(dsi.base);
err1:
destroy_workqueue(dsi.workqueue);
+err0:
return r;
}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 02a2a3e..8ca21cd 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -34,8 +34,6 @@
#include plat/clock.h
#include dss.h
-#define DSS_BASE 0x4805
-
#define DSS_SZ_REGSSZ_512
struct dss_reg {
@@ -567,8 +565,15 @@ static int dss_init(bool skip_init)
{
int r;
u32 rev;
+ struct resource *dss_mem;
- dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+ dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
+ if (!dss_mem) {
+ DSSERR(can't get IORESOURCE_MEM DSS\n);
+ r = -EINVAL;
+ goto fail0;
+ }
+ dss.base = ioremap(dss_mem-start, resource_size(dss_mem));
if (!dss.base) {
DSSERR(can't ioremap DSS\n);
r = -ENOMEM;
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 24936f8..54f2279 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -36,8 +36,6 @@
#include plat/display.h
#include dss.h
-#define RFBI_BASE 0x48050800
-
struct rfbi_reg { u16 idx; };
#define RFBI_REG(idx) ((const struct rfbi_reg) { idx })
@@ -1017,6 +1015,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
{
u32 rev;
u32 l;
+ struct resource *rfbi_mem;
rfbi.pdev = pdev;
@@ -1026,7 +1025,12 @@ static int omap_rfbihw_probe(struct platform_device
*pdev)
atomic_set(rfbi.cmd_fifo_full, 0);
atomic_set(rfbi.cmd_pending, 0);
- rfbi.base = ioremap(RFBI_BASE, SZ_256);
+ rfbi_mem = platform_get_resource(rfbi.pdev, IORESOURCE_MEM, 0);
+ if (!rfbi_mem) {
+ DSSERR(can't get
[PATCH v5 17/17] OMAP2,3: DSS2: Get DSS IRQ from platform device
From: Senthilvadivu Guruswamy svad...@ti.com
DSS IRQ number can be obtained from platform_get_irq(). This API in turn
picks the right IRQ number belonging to HW IP from the hwmod database.
So hardcoding of IRQ number could be removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dss.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 8ca21cd..ebf6f76 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
static int dss_init(bool skip_init)
{
- int r;
+ int r, dss_irq;
u32 rev;
struct resource *dss_mem;
@@ -609,15 +609,18 @@ static int dss_init(bool skip_init)
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); /* venc clock mode = normal */
#endif
- r = request_irq(INT_24XX_DSS_IRQ,
+ dss_irq = platform_get_irq(dss.pdev, 0);
+ if (dss_irq != -ENXIO) {
+ r = request_irq(dss_irq,
cpu_is_omap24xx()
? dss_irq_handler_omap2
: dss_irq_handler_omap3,
0, OMAP DSS, NULL);
- if (r 0) {
- DSSERR(omap2 dss: request_irq failed\n);
- goto fail1;
+ if (r 0) {
+ DSSERR(omap2 dss: request_irq failed\n);
+ goto fail1;
+ }
}
if (cpu_is_omap34xx()) {
--
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
Latest config warning
warning: (ARCH_STMP3XXX choice || ARCH_OMAP3 ARCH_OMAP2PLUS) selects USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) This didn't happen with 2.6.37. Maybe a missing select USB_SUPPORT somewhere? -- 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
Latest regressions
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:37,
from arch/arm/mach-omap2/io.c:45:
arch/arm/plat-omap/include/plat/voltage.h: In function
■omap_voltage_register_pmic■:
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in
function returning non-void
which gets spammed out all through the build. voltage.h:137 says:
static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
struct omap_volt_pmic_info *pmic_info) {}
but no one checks the return value for this:
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm,
omap4_mpu_volt_info);
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm,
omap4_iva_volt_info);
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm,
omap4_core_volt_info);
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm,
omap3_mpu_volt_info);
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm,
omap3_core_volt_info);
so I don't see the point of it returning an 'int'.
There's also:
arch/arm/mach-omap2/io.c: In function ■omap_irq_base_init■:
arch/arm/mach-omap2/io.c:322: warning: unused variable ■omap_irq_base■
This has never been built with !MULTI_OMAP2:
+/*
+ * Initialize asm_irq_base for entry-macro.S
+ */
+static inline void omap_irq_base_init(void)
+{
+ extern void __iomem *omap_irq_base;
+
+#ifdef MULTI_OMAP2
+ if (cpu_is_omap242x())
+ omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP24XX_IC_BASE);
+ else if (cpu_is_omap34xx())
+ omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP34XX_IC_BASE);
+ else if (cpu_is_omap44xx())
+ omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE);
+ else
+ pr_err(Could not initialize omap_irq_base\n);
+#endif
+}
and given the code and comment in entry-macros.S, it would be far better
to define omap_irq_base in here, get rid of the ifdef and always
initialize it, thereby eliminating that variability from needing
multiple different configurations get proper build coverage.
arch/arm/mach-omap2/mux.c: In function ■_omap_mux_get_by_name■:
arch/arm/mach-omap2/mux.c:163: warning: ■found_mode■ may be used uninitialized
in this function
The build ends with:
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:37,
from arch/arm/mach-omap2/omap_hwmod_common_data.c:19:
arch/arm/plat-omap/include/plat/voltage.h: In function
■omap_voltage_register_pmic■:
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in
function returning non-void
arch/arm/plat-omap/include/plat/voltage.h: In function ■omap_voltage_late_init■:
arch/arm/plat-omap/include/plat/voltage.h:142: error: ■EINVAL■ undeclared
(first use in this function)
arch/arm/plat-omap/include/plat/voltage.h:142: error: (Each undeclared
identifier is reported only once
arch/arm/plat-omap/include/plat/voltage.h:142: error: for each function it
appears in.)
make[2]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1
make[1]: *** [arch/arm/mach-omap2] Error 2
make[1]: *** Waiting for unfinished jobs
Adding linux/errno.h to that header resolves that. That gets us down to
the final link, which fails:
arch/arm/mach-omap2/built-in.o: In function `omap2_set_init_voltage':
arch/arm/mach-omap2/pm.c:181: undefined reference to
`omap_voltage_domain_lookup'
arch/arm/mach-omap2/built-in.o: In function `omap3_twl_init':
arch/arm/mach-omap2/omap_twl.c:270: undefined reference to
`omap_voltage_domain_lookup'
arch/arm/mach-omap2/omap_twl.c:273: undefined reference to
`omap_voltage_domain_lookup'
So, this is what I currently have to get that far:
diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S
b/arch/arm/mach-omap2/include/mach/entry-macro.S
index befa321..81985a6 100644
--- a/arch/arm/mach-omap2/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap2/include/mach/entry-macro.S
@@ -38,20 +38,6 @@
*/
#ifdef MULTI_OMAP2
-
-/*
- * We use __glue to avoid errors with multiple definitions of
- * .globl omap_irq_base as it's included from entry-armv.S but not
- * from entry-common.S.
- */
-#ifdef __glue
- .pushsection .data
- .globl omap_irq_base
-omap_irq_base:
- .word 0
- .popsection
-#endif
-
/*
* Configure the interrupt base on the first interrupt.
* See also omap_irq_base_init for setting omap_irq_base.
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e66687b..c203204 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -314,14 +314,13 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod
*oh, void *data)
return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
}
+void __iomem *omap_irq_base;
+
/*
* Initialize asm_irq_base for entry-macro.S
*/
static inline void omap_irq_base_init(void)
{
- extern void __iomem
Re: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Fri, Jan 7, 2011 at 3:25 AM, Guenter Roeck guenter.ro...@ericsson.com wrote: On Thu, 2011-01-06 at 15:21 -0500, Mark Brown wrote: On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote: On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote: Why? It's not like hwmon has an unreasonably large core or similar. Because it creates an unnecessary dependency, and because it is not hwmon's responsibility to provide infrastructure for other subsystems or drivers. hwmon isn't really doing anything, though. The *driver* is doing something but it doesn't really impact the core that much. Not that I'm particularly sold on putting the ADC core in here, but total NACK based on that alone seems rather harsh. Possibly. However, I had suggested the following earlier (to the 1st version of the patch): I commented on this a couple of times below - the driver mixes generic ADC reading functions with hwmon functionality. Generic ADC reading functionality should be moved into another driver, possibly to mfd. Obviously that was ignored. Maybe someone is willing to listen this time around. I am sorry for not responding on the generic ADC handling part. Since many other ADC drivers are part of hwmon i thought hwmon was the appropriate place. However I can surely split the generic ADC handling part in mfd and only hardware monitoring part in hwmon as suggested. I won't let people break modularity just for convenience in a subsystem I am responsible for. And forcing the hwmon subsystem, and with it a specific hwmon driver, to exist just because the adc functionality it provides is needed by some other (most likely unrelated) subsystem / driver _does_ break modularity. Worse, it is completely unnecessary to do so. Other twl4030 functionality was extracted into generic code. twl-core.c, twl4030-codec.c, twl4030-irq.c, twl4030-power.c are all in mfd. I fail to see the problem with mfd/twl4030-adc.c. Guenter Hello Samuel, Is it ok to have the generic ADC functionality in mfd as a separate file? Regards, Keerthy -- 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: 4430SDP boot failure
-Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Friday, January 07, 2011 3:23 PM Ruessell, To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: RE: 4430SDP boot failure [] BTW, if it makes any difference to the boot loader, please note that I'm still waiting for the upgrade for the SDP board. That means your board is with ES1.0. I shall try 2.6.37 on ES1.0 ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an issue. The console is changed to OMAP serial driver from 8250 driver. Can you try console=ttyO2 instead of existing console=ttyS2 ?? Will send you the latest boot-loader after doing a boot test. ## Booting image at 8030 ... Image Name: Linux-2.6.37 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2898440 Bytes = 2.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.37 (a0393...@a0393909-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #6 SMP Fri Jan 7 17:12:26 IST 2011 [0.00] CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4430 4430SDP board [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES1.0 [0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 [0.00] FIXME: omap44xx_sram_init not implemented [0.00] PERCPU: Embedded 7 pages/cpu @c0f3d000 s6080 r8192 d14400 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyO2,115200n8 noinitrd root=/dev/nfs rw nfsroot=172.24.190.46:/ubuntu/nfs-share/omap4_next/,nolock,tcp,rsize=1024, wsize=1024 ip=dhcp [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 512MB = 512MB total [0.00] Memory: 508228k/508228k available, 16060k 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] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xe080 - 0xf800 ( 376 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc004a000 ( 264 kB) [0.00] .text : 0xc004a000 - 0xc056904c (5245 kB) [0.00] .data : 0xc056a000 - 0xc05dadc0 ( 452 kB) [0.00] Hierarchical RCU implementation. -- 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: 4430SDP boot failure
Sorry, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Friday, January 07, 2011 5:49 PM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: RE: 4430SDP boot failure -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Friday, January 07, 2011 3:23 PM Ruessell, To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: RE: 4430SDP boot failure [] BTW, if it makes any difference to the boot loader, please note that I'm still waiting for the upgrade for the SDP board. That means your board is with ES1.0. I shall try 2.6.37 on ES1.0 ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an issue. The console is changed to OMAP serial driver from 8250 driver. Can you try console=ttyO2 instead of existing console=ttyS2 ?? Ignore my last email. You have tried that already Will send you updated boot-loaders in next few mins. -- 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
Build breakage with omap2plus_defconfig
Hi all, Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to build with omap2plus_defconfig: $ crossmake CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/arm/kernel/swp_emulate.o /tmp/cc2V7p5j.s: Assembler messages: /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]' /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]' make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1 make: *** [arch/arm/kernel] Error 2 Compiler is: $ arm-linux-gcc --version arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to check if it's not a bug on the compiler. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP DSS changes for .38 merge window
Hello Paul, Here are some OMAP display changes for .38. I hope they are not too late, but the holidays messed up my schedules a bit. I made two branches, as I'm not sure which is better: for-paul-38 - This one is the original non-rebased branch. This causes a trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M is the right one), and also it contains a patch (memblock: fix memblock_is_region_memory()) which is not yet in mainline, but is in Andrew Morton's tree. for-paul-38-rebased - The above branch rebased on top of v2.6.37, and the memblock commit removed. Which one you prefer? Or is there some other way I should handle this? I could merge v2.6.37 to my branch, which would remove the conflict, but that would still leave the memblock patch. I guess the patch is going in soon, but as it's not in my area, I don't feel it's right to get it in via my patch set. Alternatively I could wait until the patch is in Linus' tree, but that could make it tight to be in time for the merge window. Tomi The following changes since commit c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4: Linux 2.6.37-rc1 (2010-11-01 07:54:12 -0400) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-paul-38 Archit Taneja (5): OMAP: DSS2: Fix: Read correct bit in dispc_enable_alpha_blending() OMAP: DSS2: Clean up DISPC color mode validation checks OMAP: DSS2: Add dss_features for omap4 and overlay manager related features OMAP: DSS2: Use dss_features to handle DISPC bits removed on OMAP4 OMAP: DSS2: Fix build breaks for rfbi.c and dsi.c Bryan Wu (4): OMAP: DSS2: Add generic DPI panel display driver OMAP: use generic DPI panel driver in board files OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers OMAP: DSS2: Add back authors of panel-generic.c based drivers Erik Gilling (1): OMAP: DSS2: Add NEC NL8048HL11-01B display panel Kishore Y (2): OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3 OMAP3: Enable display on ZOOM2/3/3630SDP Rajkumar N (1): OMAP3630: DSS2: Enable Pre-Multiplied Alpha Support Samreen (2): OMAP3: DSS2: Split OMAP3 has feature for 3430 3630 OMAP: DSS2: OMAPFB: Add null pointer check Sumit Semwal (5): OMAP: DSS2: Represent DISPC register defines with channel as parameter OMAP: DSS2: Introduce omap_channel argument to DISPC functions used by interface drivers OMAP: DSS2: Change remaining DISPC functions for new omap_channel argument OMAP: DSS2: LCD2 Channel Changes for DISPC OMAP: DSS2: Introduce omap_channel as an omap_dss_device parameter, add new overlay manager. Tomi Valkeinen (4): memblock: fix memblock_is_region_memory() OMAP: VRAM: improve VRAM error prints OMAP: VRAM: Fix boot-time memory allocation OMAP: DSS: Fix documentation regarding 'vram' kernel parameter Documentation/arm/OMAP/DSS |7 +- arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-3430sdp.c| 12 +- arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-am3517evm.c | 23 +- arch/arm/mach-omap2/board-cm-t35.c | 23 +- arch/arm/mach-omap2/board-devkit8000.c | 26 +- arch/arm/mach-omap2/board-igep0020.c | 12 +- arch/arm/mach-omap2/board-omap3beagle.c| 12 +- arch/arm/mach-omap2/board-omap3evm.c | 12 +- arch/arm/mach-omap2/board-omap3stalker.c | 23 +- arch/arm/mach-omap2/board-zoom-display.c | 168 + arch/arm/mach-omap2/board-zoom-peripherals.c | 49 ++- arch/arm/mach-omap2/board-zoom2.c |1 + arch/arm/mach-omap2/board-zoom3.c |1 + arch/arm/mach-omap2/include/mach/board-zoom.h |3 + arch/arm/plat-omap/include/plat/display.h |9 + .../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++ drivers/video/omap2/displays/Kconfig | 27 +- drivers/video/omap2/displays/Makefile |5 +- drivers/video/omap2/displays/panel-generic-dpi.c | 365 +++ drivers/video/omap2/displays/panel-generic.c | 174 -- .../omap2/displays/panel-nec-nl8048hl11-01b.c | 325 ++ .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 - .../video/omap2/displays/panel-toppoly-tdo35s.c| 164 - drivers/video/omap2/dss/dispc.c| 636 +--- drivers/video/omap2/dss/dpi.c | 40 +- drivers/video/omap2/dss/dsi.c | 27 +- drivers/video/omap2/dss/dss.h | 35 +- drivers/video/omap2/dss/dss_features.c | 66 ++- drivers/video/omap2/dss/dss_features.h | 10 +- drivers/video/omap2/dss/manager.c | 80 ++-
Re: Build breakage with omap2plus_defconfig
Hi, On Fri, Jan 07, 2011 at 02:38:59PM +0200, Felipe Balbi wrote: Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to build with omap2plus_defconfig: $ crossmake CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/arm/kernel/swp_emulate.o /tmp/cc2V7p5j.s: Assembler messages: /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]' /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]' make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1 make: *** [arch/arm/kernel] Error 2 Compiler is: $ arm-linux-gcc --version arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to check if it's not a bug on the compiler. Just tested with newer compiler and it also fails to compile. $ arm-linux-gcc --version arm-linux-gcc (Sourcery G++ Lite 2010.09-50) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Build breakage with omap2plus_defconfig
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Friday, January 07, 2011 6:09 PM To: Russell King; Tony Lindgren Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List Subject: Build breakage with omap2plus_defconfig Hi all, Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to build with omap2plus_defconfig: $ crossmake CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/arm/kernel/swp_emulate.o /tmp/cc2V7p5j.s: Assembler messages: /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]' /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]' Well it's not toolchain issue but the omap2plus_defconfig which selects ARMv6 and ARMV7 together. If you remove ARCH_OMAP2 from build, it will go through. make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1 make: *** [arch/arm/kernel] Error 2 Compiler is: $ arm-linux-gcc --version arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to check if it's not a bug on the compiler. 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: Build breakage with omap2plus_defconfig
Felipe Balbi wrote: Hi all, Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to build with omap2plus_defconfig: $ crossmake CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/arm/kernel/swp_emulate.o /tmp/cc2V7p5j.s: Assembler messages: /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]' /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]' make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1 make: *** [arch/arm/kernel] Error 2 I haven't found a way around this other than to turn off CONFIG_SWP_EMULATE. Here's a patch doing that [1]. The discussion thread is here [2]. - Anand [1] http://marc.info/?l=linux-omapm=129140165126953w=2 [2] http://marc.info/?t=12874841253r=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: 4430SDP boot failure
On Fri, Jan 07, 2011 at 05:48:41PM +0530, Santosh Shilimkar wrote: -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Friday, January 07, 2011 3:23 PM Ruessell, To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: RE: 4430SDP boot failure [] BTW, if it makes any difference to the boot loader, please note that I'm still waiting for the upgrade for the SDP board. That means your board is with ES1.0. I shall try 2.6.37 on ES1.0 ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an issue. The console is changed to OMAP serial driver from 8250 driver. Can you try console=ttyO2 instead of existing console=ttyS2 ?? This is the command line I've been giving it: setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' and in my .config, I have: CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y so the driver is also enabled. I found this on the 3430LDP, and so switched both OMAP3 and OMAP4 stuff over to the new driver. That wouldn't explain why I'm getting the X-loader hangs message which brings everything to a halt, and why the low level debug stuff doesn't work. -- 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 00/17] OMAP2,3: hwmod DSS Adaptation
Hi Tony, The patch set below is based on l-o tree, as it touches OMAP hwmod/clock/board stuff. It doesn't even apply to my mainline based tree. I'm still in the process of reviewing the latest changes, but is it ok for you to apply these to your tree after I've acked the DSS parts? Or do you have a stable branch (going to Linus soon) that I can use as a base? Tomi On Fri, 2011-01-07 at 16:55 +0530, ext Sumit Semwal wrote: v4 of the DSS hwmod patch series focusses on fixing the review comments. OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design. This patch series decouples the Clocks for DSS in hwmod adaptation changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3. Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling. Summary of the hwmod DSS design: DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database. Each of these platform drivers' init / deinit are handled from core.c's omap_dss_probe() in the exact sequence as required. No Hardcoding of silicon data: hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series. Continue to have custom bus for display panels: omapdss driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver) For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o). Clocks: Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately. For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. Current dss driver: --- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Modified change: --- Platform driver for each DSS HW IP in addition to the software omapdss driver. Omapdss platform driver - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, venc, rfbi] and software libraries like dpi, sdi. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registered to the custom bus. DSS platform driver - initialises DSS IP alone - Handles the clocks related to the DSS and other DSSHW IPs like RFBI, DSI, VENC, DISPC. Previously this was a part of omapdss driver in core.c - Continues to handle the DSS IRQs. - No suspend/resume hooks. DISPC platform driver - initialises DISPC IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DISPC library functions. DSI platform driver - initialises DSI IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DSI library functions. RFBI, VENC platform drivers - initialises DSI,VENC IPs - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide RFBI and VENC library functions. Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp. For the rest of the mentioned platforms, kernel is built with OMAP2_DSS and bootup is tested so that base address and clk_get calls are successful. DSS was built successfully as module, though not tested yet. Changes since v4: 1) Following review comments
Re: Build breakage with omap2plus_defconfig
On Fri, Jan 07, 2011 at 06:20:43PM +0530, Anand Gadiyar wrote: Felipe Balbi wrote: Hi all, Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to build with omap2plus_defconfig: $ crossmake CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/arm/kernel/swp_emulate.o /tmp/cc2V7p5j.s: Assembler messages: /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]' /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]' make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1 make: *** [arch/arm/kernel] Error 2 I haven't found a way around this other than to turn off CONFIG_SWP_EMULATE. Here's a patch doing that [1]. The discussion thread is here [2]. Thanks a lot Anand :-) -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest regressions
Russell King - ARM Linux wrote, on 01/07/2011 05:57 AM:
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:37,
from arch/arm/mach-omap2/io.c:45:
arch/arm/plat-omap/include/plat/voltage.h: In function
■omap_voltage_register_pmic■:
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in
function returning non-void
which gets spammed out all through the build. voltage.h:137 says:
static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
struct omap_volt_pmic_info *pmic_info) {}
but no one checks the return value for this:
arch/arm/mach-omap2/omap_twl.c:
omap_voltage_register_pmic(voltdm,omap4_mpu_volt_info);
arch/arm/mach-omap2/omap_twl.c:
omap_voltage_register_pmic(voltdm,omap4_iva_volt_info);
arch/arm/mach-omap2/omap_twl.c:
omap_voltage_register_pmic(voltdm,omap4_core_volt_info);
arch/arm/mach-omap2/omap_twl.c:
omap_voltage_register_pmic(voltdm,omap3_mpu_volt_info);
arch/arm/mach-omap2/omap_twl.c:
omap_voltage_register_pmic(voltdm,omap3_core_volt_info);
so I don't see the point of it returning an 'int'.
intent was that in the future the volt_info would be validated and users
will check as well.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build breakage with omap2plus_defconfig
On Fri, Jan 07, 2011 at 06:18:51PM +0530, Santosh Shilimkar wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Friday, January 07, 2011 6:09 PM To: Russell King; Tony Lindgren Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List Subject: Build breakage with omap2plus_defconfig Hi all, Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to build with omap2plus_defconfig: $ crossmake CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/arm/kernel/swp_emulate.o /tmp/cc2V7p5j.s: Assembler messages: /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]' /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]' Well it's not toolchain issue but the omap2plus_defconfig which selects ARMv6 and ARMV7 together. If you remove ARCH_OMAP2 from build, it will go through. I like Catalin's approach: diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 49db8b3..0fe2389 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -644,7 +644,7 @@ config ARM_THUMBEE config SWP_EMULATE bool Emulate SWP/SWPB instructions - depends on CPU_V7 + depends on CPU_V7 !CPU_V6 select HAVE_PROC_CPU if PROC_FS default y if SMP help Simple. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap: Beagle: detect new xM revision B
Koen Kooi wrote, on 01/07/2011 03:10 AM:
From: Robert Nelsonrobertcnel...@gmail.com
The xM B uses a DM3730 ES1.1 over the ES1.0 on xM A's, no other board changes.
unrelated to patch: funny why the GPIO version changed then!
related to patch: please add [PATCH] in $subject.. minor comment follows:
Signed-off-by: Robert Nelsonrobertcnel...@gmail.com
Signed-off-by: Koen Kooik...@beagleboard.org
---
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7c82730..4fd73e7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -58,7 +58,8 @@
*AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
*C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
*C4 = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMB = GPIO173, GPIO172, GPIO171: 0 0 1
*/
enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -117,7 +118,11 @@ static void __init omap3_beagle_init_rev(void)
omap3_beagle_version = OMAP3BEAGLE_BOARD_C4;
break;
case 0:
- printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
+ printk(KERN_INFO OMAP3 Beagle Rev: xM A\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
+ break;
+ case 1:
+ printk(KERN_INFO OMAP3 Beagle Rev: xM B\n);
could you replace printk(KERN_INFO with pr_info?
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
default:
--
cgit v0.8.3.1-30-gff3a
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Build breakage with omap2plus_defconfig
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Friday, January 07, 2011 6:30 PM To: Santosh Shilimkar Cc: ba...@ti.com; Russell King; Tony Lindgren; Linux OMAP Mailing List; Linux ARM Kernel Mailing List Subject: Re: Build breakage with omap2plus_defconfig On Fri, Jan 07, 2011 at 06:18:51PM +0530, Santosh Shilimkar wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Friday, January 07, 2011 6:09 PM To: Russell King; Tony Lindgren Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List Subject: Build breakage with omap2plus_defconfig Hi all, Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to build with omap2plus_defconfig: $ crossmake CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/arm/kernel/swp_emulate.o /tmp/cc2V7p5j.s: Assembler messages: /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode `ldrexb r3,[r4]' /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode `strexb r0,r2,[r4]' Well it's not toolchain issue but the omap2plus_defconfig which selects ARMv6 and ARMV7 together. If you remove ARCH_OMAP2 from build, it will go through. I like Catalin's approach: diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 49db8b3..0fe2389 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -644,7 +644,7 @@ config ARM_THUMBEE config SWP_EMULATE bool Emulate SWP/SWPB instructions - depends on CPU_V7 + depends on CPU_V7 !CPU_V6 select HAVE_PROC_CPU if PROC_FS default y if SMP help Simple. This patch is good but it does tell you that if you will V6 and v7 together, the feature can't be used. Like omap2plus_defconfig, and if booted on say omap3 or omap4(v7), swp emulation can't be used even though its supported. 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
[PATCH] omap3: Add basic support for 720MHz part
This patch adds support for new speed enhanced parts with ARM
and IVA running at 720MHz and 520MHz respectively. These parts
can be probed at run-time by reading PRODID.SKUID[3:0] at
0x4830A20C [1].
This patch specifically does following:
* Detect devices capable of 720MHz.
* Add new OPP
* Ensure that OPP is conditionally enabled.
The patch was tested on OMAP3EVM.
On 720MHz capable device:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
72
On other devices:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
60
[1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/control.h |7 +++
arch/arm/mach-omap2/id.c | 10 ++
arch/arm/mach-omap2/opp3xxx_data.c| 19 ++-
arch/arm/plat-omap/include/plat/cpu.h |2 ++
4 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f0629ae..eebc045 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -365,6 +365,13 @@
#defineFEAT_NEON 0
#defineFEAT_NEON_NONE 1
+/*
+ * Product ID register
+ */
+#define OMAP3_PRODID 0x020C
+
+#define OMAP3_SKUID_MASK 0x0f
+#defineOMAP3_SKUID_720MHZ 0x08
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..53fbe01 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -195,6 +195,15 @@ static void __init omap3_check_features(void)
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
+
+ /*
+* Does it support 720MHz?
+*/
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+
+ if (status OMAP3_SKUID_720MHZ) {
+ omap3_features |= OMAP3_HAS_720MHZ;
+ }
}
static void __init omap3_check_revision(void)
@@ -445,6 +454,7 @@ static void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
OMAP3_SHOW_FEATURE(192mhz_clk);
+ OMAP3_SHOW_FEATURE(720mhz);
printk()\n);
}
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index 0486fce..01582b7 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -22,6 +22,9 @@
#include omap_opp_data.h
+#define INDEX_MPU_720MHZ 5
+#define INDEX_IVA_720MHZ 14
+
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
/* MPU OPP1 */
OPP_INITIALIZER(mpu, true, 12500, 975000),
@@ -33,6 +36,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(mpu, true, 55000, 127),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, 135),
+ /* MPU OPP6 */
+ OPP_INITIALIZER(mpu, false, 72000, 135),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -58,6 +63,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(iva, true, 4, 127),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000, 135),
+ /* DSP OPP6 */
+ OPP_INITIALIZER(iva, false, 52000, 135),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
@@ -98,9 +105,19 @@ static int __init omap3_opp_init(void)
if (cpu_is_omap3630())
r = omap_init_opp_table(omap36xx_opp_def_list,
ARRAY_SIZE(omap36xx_opp_def_list));
- else
+ else {
+ if (omap3_has_720mhz()) {
+ pr_info(Enabled OPP corresponding to 720MHz\n);
+
+ omap34xx_opp_def_list[INDEX_MPU_720MHZ]
+ .default_available = true;
+ omap34xx_opp_def_list[INDEX_IVA_720MHZ]
+ .default_available = true;
+ }
+
r = omap_init_opp_table(omap34xx_opp_def_list,
ARRAY_SIZE(omap34xx_opp_def_list));
+ }
return r;
}
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 3fd8b40..5c77987 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -455,6 +455,7 @@ extern u32 omap3_features;
#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
#define OMAP3_HAS_IO_WAKEUPBIT(6)
+#define OMAP3_HAS_720MHZ BIT(7)
#define OMAP3_HAS_FEATURE(feat,flag) \
static inline unsigned int omap3_has_ ##feat(void) \
@@ -469,5 +470,6 @@ OMAP3_HAS_FEATURE(neon, NEON)
OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk,
RE: 4430SDP boot failure
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Friday, January 07, 2011 6:22 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: 4430SDP boot failure On Fri, Jan 07, 2011 at 05:48:41PM +0530, Santosh Shilimkar wrote: -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Friday, January 07, 2011 3:23 PM Ruessell, To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: RE: 4430SDP boot failure [] BTW, if it makes any difference to the boot loader, please note that I'm still waiting for the upgrade for the SDP board. That means your board is with ES1.0. I shall try 2.6.37 on ES1.0 ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an issue. The console is changed to OMAP serial driver from 8250 driver. Can you try console=ttyO2 instead of existing console=ttyS2 ?? This is the command line I've been giving it: setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' and in my .config, I have: CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y Yep. Noticed that after the post. so the driver is also enabled. I found this on the 3430LDP, and so switched both OMAP3 and OMAP4 stuff over to the new driver. That wouldn't explain why I'm getting the X-loader hangs message which brings everything to a halt, and why the low level debug stuff doesn't work. Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me. Low level debug as you reported seems to be broken though. 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: Build breakage with omap2plus_defconfig
Hi, On Fri, Jan 07, 2011 at 06:35:39PM +0530, Santosh Shilimkar wrote: This patch is good but it does tell you that if you will V6 and v7 together, the feature can't be used. Like omap2plus_defconfig, and if booted on say omap3 or omap4(v7), swp emulation can't be used even though its supported. Sure, I got that from the patch, but we don't have any other simpler solution currently. And it's indeed a shame we can't support multi-omap anymore :-( -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/17] OMAP2,3: hwmod DSS Adaptation
Hi, Ah, I just noticed (thanks Nishanth) that you've sent a pull request, and these patches apply fine on top of the omap-for-linus branch. I'll use that as a base. Tomi On Fri, 2011-01-07 at 14:56 +0200, Tomi Valkeinen wrote: Hi Tony, The patch set below is based on l-o tree, as it touches OMAP hwmod/clock/board stuff. It doesn't even apply to my mainline based tree. I'm still in the process of reviewing the latest changes, but is it ok for you to apply these to your tree after I've acked the DSS parts? Or do you have a stable branch (going to Linus soon) that I can use as a base? Tomi On Fri, 2011-01-07 at 16:55 +0530, ext Sumit Semwal wrote: v4 of the DSS hwmod patch series focusses on fixing the review comments. OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design. This patch series decouples the Clocks for DSS in hwmod adaptation changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3. Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling. Summary of the hwmod DSS design: DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database. Each of these platform drivers' init / deinit are handled from core.c's omap_dss_probe() in the exact sequence as required. No Hardcoding of silicon data: hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series. Continue to have custom bus for display panels: omapdss driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver) For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o). Clocks: Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately. For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. Current dss driver: --- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Modified change: --- Platform driver for each DSS HW IP in addition to the software omapdss driver. Omapdss platform driver - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, venc, rfbi] and software libraries like dpi, sdi. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registered to the custom bus. DSS platform driver - initialises DSS IP alone - Handles the clocks related to the DSS and other DSSHW IPs like RFBI, DSI, VENC, DISPC. Previously this was a part of omapdss driver in core.c - Continues to handle the DSS IRQs. - No suspend/resume hooks. DISPC platform driver - initialises DISPC IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DISPC library functions. DSI platform driver - initialises DSI IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DSI library functions. RFBI, VENC platform drivers - initialises DSI,VENC IPs - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide RFBI and VENC library functions. Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete
Re: [GIT PULL] OMAP DSS changes for .38 merge window
On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote: Hello Paul, Here are some OMAP display changes for .38. I hope they are not too late, but the holidays messed up my schedules a bit. No, no problem. I usually aim to do two merges per merge window on average, one at the beginning and one nearer the end. There are often many patches that have dependencies that are blocked while other trees merge that get sent off when their dependencies have been met. I made two branches, as I'm not sure which is better: for-paul-38 - This one is the original non-rebased branch. This causes a trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M is the right one), and also it contains a patch (memblock: fix memblock_is_region_memory()) which is not yet in mainline, but is in Andrew Morton's tree. for-paul-38-rebased - The above branch rebased on top of v2.6.37, and the memblock commit removed. Which one you prefer? Or is there some other way I should handle this? I could merge v2.6.37 to my branch, which would remove the conflict, but that would still leave the memblock patch. I guess the patch is going in soon, but as it's not in my area, I don't feel it's right to get it in via my patch set. Alternatively I could wait until the patch is in Linus' tree, but that could make it tight to be in time for the merge window. Andrew usually patch-bombs near the end of the window, so it's generally a good idea to have things settled before then. In this case if the patch is already destined for mainline then I can just pull the rebased branch, send that out, and then once -mm syncs up everything should be good to go for -rc1. Looking at the change in question, it's just a correctness fix and doesn't impact the API from the driver point of view, so at least there won't be build damage if they're out of sync for a couple of days (although it may trigger some nasty surprises for anyone unlucky enough to bisect in the middle). In any event, unless you absolutely need the change to be upstream first, I'll plan to pull the rebase branch. If you need it there earlier we can probably also just prod Andrew and get that one patch off earlier than the rest of the -mm bits. -- 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] OMAP3: beagle xm: enable upto 800MHz OPP
Aaro Koskinen wrote, on 01/07/2011 07:04 AM:
On Wed, 5 Jan 2011, Nishanth Menon wrote:
+static void __init beagle_opp_init(void)
+{
+ int r = 0;
+
+ /* Initialize the omap3 opp table */
+ if (omap3_opp_init()) {
+ pr_err(%s: opp default init failed\n, __func__);
+ return;
+ }
+
+ /* Custom OPP enabled for XM */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
+ struct omap_hwmod *dh = omap_hwmod_lookup(iva);
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
+ __func__, mh, dh);
+ r = -EINVAL;
+ } else {
+ /* Enable MPU 1GHz and lower opps */
+ dev = mh-od-pdev.dev;
+ r = opp_enable(dev, 8);
+ /* TODO: MPU 1GHz needs SR and ABB */
+
+ /* Enable IVA 800MHz and lower opps */
+ dev = dh-od-pdev.dev;
+ r |= opp_enable(dev, 66000);
+ /* TODO: DSP 800MHz needs SR and ABB */
+ }
+ if (r) {
+ pr_err(%s: failed to enable higher opp %d\n,
+ __func__, r);
+ /*
+ * Cleanup - disable the higher freqs - we dont care
+ * about the results
+ */
+ dev = mh-od-pdev.dev;
+ opp_disable(dev, 8);
+ dev = dh-od-pdev.dev;
This branch will be reached also when !mh || !dh, so it won't work.
arrgh.. thanks for catching it - will fix and repost.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Add basic support for 720MHz part
Sanjeev Premi wrote, on 01/07/2011 07:07 AM:
+ if (omap3_has_720mhz()) {
+ pr_info(Enabled OPP corresponding to 720MHz\n);
+
+ omap34xx_opp_def_list[INDEX_MPU_720MHZ]
+ .default_available = true;
+ omap34xx_opp_def_list[INDEX_IVA_720MHZ]
+ .default_available = true;
for many reasons, I dont like this indexing - I am ok with most part of
the patch otherwise - how about opp_enable(dev, freq) instead?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP DSS changes for .38 merge window
On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote: On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote: Hello Paul, Here are some OMAP display changes for .38. I hope they are not too late, but the holidays messed up my schedules a bit. No, no problem. I usually aim to do two merges per merge window on average, one at the beginning and one nearer the end. There are often many patches that have dependencies that are blocked while other trees merge that get sent off when their dependencies have been met. Ok, good. There are still some patches going around reviews that would be nice to get in .38, but time is running short so I decided to send the current patches. I guess it's not out-of-the-question to get driver changes in in early rcs, but I'd rather get everything pulled during the merge window. Also, some of the patches still out there touch OMAP's arch/ files, so they are not plain driver changes. I made two branches, as I'm not sure which is better: for-paul-38 - This one is the original non-rebased branch. This causes a trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M is the right one), and also it contains a patch (memblock: fix memblock_is_region_memory()) which is not yet in mainline, but is in Andrew Morton's tree. for-paul-38-rebased - The above branch rebased on top of v2.6.37, and the memblock commit removed. Which one you prefer? Or is there some other way I should handle this? I could merge v2.6.37 to my branch, which would remove the conflict, but that would still leave the memblock patch. I guess the patch is going in soon, but as it's not in my area, I don't feel it's right to get it in via my patch set. Alternatively I could wait until the patch is in Linus' tree, but that could make it tight to be in time for the merge window. Andrew usually patch-bombs near the end of the window, so it's generally a good idea to have things settled before then. In this case if the patch is already destined for mainline then I can just pull the rebased branch, send that out, and then once -mm syncs up everything should be good to go for -rc1. Looking at the change in question, it's just a correctness fix and doesn't impact the API from the driver point of view, so at least there won't be build damage if they're out of sync for a couple of days (although it may trigger some nasty surprises for anyone unlucky enough to bisect in the middle). In any event, unless you absolutely need the change to be upstream first, I'll plan to pull the rebase branch. If you need it there earlier we can probably also just prod Andrew and get that one patch off earlier than the rest of the -mm bits. No, the fix is not needed urgently. The memblock fix is only important for some rare use cases, which I don't think anyone is currently using (allocating video memory from SDRAM at a predefined address). 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: 4430SDP boot failure
Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende geschreven: This is the command line I've been giving it: setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' Why are people still using rootdelay? 'rootwait' is vastly superior and doesn't need tweaking for every card/controller combo. regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: Add basic support for 720MHz part
-Original Message-
From: Menon, Nishanth
Sent: Friday, January 07, 2011 7:04 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
Sanjeev Premi wrote, on 01/07/2011 07:07 AM:
+ if (omap3_has_720mhz()) {
+ pr_info(Enabled OPP corresponding to
720MHz\n);
+
+ omap34xx_opp_def_list[INDEX_MPU_720MHZ]
+ .default_available = true;
+ omap34xx_opp_def_list[INDEX_IVA_720MHZ]
+ .default_available = true;
for many reasons, I dont like this indexing - I am ok with
most part of
the patch otherwise - how about opp_enable(dev, freq) instead?
I had thought about it, but opp_enable would have to be done after
omap_init_opp_table(). Two factors led me to current implementation:
1) Numer of lines of code required to get same thing done one the
opp table has been initialized.
2) The index definition and usage are localized in same file.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP DSS changes for .38 merge window
On Fri, Jan 07, 2011 at 03:37:32PM +0200, Tomi Valkeinen wrote:
On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote:
I guess it's not out-of-the-question to get driver changes in in early
rcs, but I'd rather get everything pulled during the merge window. Also,
some of the patches still out there touch OMAP's arch/ files, so they
are not plain driver changes.
As long as all the new and big stuff goes in for -rc1 it's certainly fine
to take care of the rest over the next few rc releases. Things do
invariably break when multiple trees are being merged, so it's to be
expected.
Looking at the change in question, it's just a correctness fix and
doesn't impact the API from the driver point of view, so at least there
won't be build damage if they're out of sync for a couple of days
(although it may trigger some nasty surprises for anyone unlucky enough
to bisect in the middle).
In any event, unless you absolutely need the change to be upstream first,
I'll plan to pull the rebase branch. If you need it there earlier we can
probably also just prod Andrew and get that one patch off earlier than
the rest of the -mm bits.
No, the fix is not needed urgently. The memblock fix is only important
for some rare use cases, which I don't think anyone is currently using
(allocating video memory from SDRAM at a predefined address).
Hmm, I've just fast-forwarded to Linus's current tree and tried to pull
your rebase branch in, but it seems to have a board conflict with the
OMAP tree merge:
CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD and
modified in 122ffebf2191529153c079b457e38ca3829eac40. Version
122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c
left in tree.
Additionally there's a board-zoom.c conflict that looks like this:
diff --cc arch/arm/mach-omap2/board-zoom.c
index e041c53,1523369..000
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@@ -118,29 -113,17 +118,36 @@@ static const struct ehci_hcd_omap_platf
static void __init omap_zoom_init(void)
{
- omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
- zoom_peripherals_init();
+ if (machine_is_omap_zoom2()) {
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ } else if (machine_is_omap_zoom3()) {
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
+ omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
+ usb_ehci_init(ehci_pdata);
+ }
+
board_nand_init(zoom_nand_partitions,
- ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
+ ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
++ HEAD:arch/arm/mach-omap2/board-zoom.c
+ zoom_peripherals_init();
++===
+ zoom_display_init();
+
+ omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+ usb_ehci_init(ehci_pdata);
++
122ffebf2191529153c079b457e38ca3829eac40:arch/arm/mach-omap2/board-zoom3.c
}
+MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board)
+ .boot_params= 0x8100,
+ .map_io = omap3_map_io,
+ .reserve= omap_reserve,
+ .init_irq = omap_zoom_init_irq,
+ .init_machine = omap_zoom_init,
+ .timer = omap_timer,
+MACHINE_END
+
MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board)
.boot_params= 0x8100,
.map_io = omap3_map_io,
* Unmerged path arch/arm/mach-omap2/board-zoom2.c
It looks like there has been some consolidation work based on the last commit,
but I'll leave it to you to decide how to handle.
--
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: 4430SDP boot failure
On Fri, Jan 07, 2011 at 02:07:53PM +0100, Koen Kooi wrote: Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende geschreven: This is the command line I've been giving it: setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' Why are people still using rootdelay? 'rootwait' is vastly superior and doesn't need tweaking for every card/controller combo. Does it matter if the effect it produces works? -- 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 06/17] OMAP2,3: DSS2: Create new file display.c for central dss driver registration.
Hi, On Fri, 2011-01-07 at 16:55 +0530, ext Sumit Semwal wrote: A new file display.c is introduced for display driver init, which adds a function omap_display_init to do the DSS driver registration. This is the first step in moving away registration of DSS from board files into a common place. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/display.c | 57 + arch/arm/plat-omap/include/plat/display.h |4 ++ 3 files changed, 63 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/display.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 4ab82f6..57b89e6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -237,3 +237,5 @@ obj-y += $(smc91x-m) $(smc91x-y) smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o obj-y+= $(smsc911x-m) $(smsc911x-y) + +obj-y+= display.o diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c new file mode 100644 index 000..26d3feb --- /dev/null +++ b/arch/arm/mach-omap2/display.c @@ -0,0 +1,57 @@ +/* + * OMAP2plus display device setup / initialization. + * + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ + * Senthilvadivu Guruswamy + * Sumit Semwal + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed 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/init.h +#include linux/platform_device.h +#include linux/io.h +#include linux/clk.h +#include linux/err.h + +#include plat/display.h +#include plat/omap_hwmod.h +#include plat/omap_device.h + +#ifdef CONFIG_OMAP2_DSS This also needs to be built in when DSS is configured as module. The define above is only valid when DSS is configured as built-in. So you can either check for both CONFIG_OMAP2_DSS and CONFIG_OMAP2_DSS_MODULE here, or, I think a bit more cleanly: - Compile display.c only if CONFIG_OMAP2_DSS[_MODULE] is defined (see the Makefile, look for example how i2c-omap is handled). - Check for CONFIG_OMAP2_DSS[_MODULE] in the header file, and define an empty static inline function for omap_display_init() if DSS is disabled. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Add basic support for 720MHz part
Premi, Sanjeev wrote, on 01/07/2011 07:50 AM:
-Original Message-
From: Menon, Nishanth
Sent: Friday, January 07, 2011 7:04 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
Sanjeev Premi wrote, on 01/07/2011 07:07 AM:
+ if (omap3_has_720mhz()) {
+ pr_info(Enabled OPP corresponding to
720MHz\n);
+
+ omap34xx_opp_def_list[INDEX_MPU_720MHZ]
+ .default_available = true;
+ omap34xx_opp_def_list[INDEX_IVA_720MHZ]
+ .default_available = true;
for many reasons, I dont like this indexing - I am ok with
most part of
the patch otherwise - how about opp_enable(dev, freq) instead?
I had thought about it, but opp_enable would have to be done after
omap_init_opp_table(). Two factors led me to current implementation:
1) Numer of lines of code required to get same thing done one the
opp table has been initialized.
2) The index definition and usage are localized in same file.
right - i will leave it to kevin to comment - IMHO both will work,
though (1) might be a little more elgant and resistant to future changes
to the table (I am not sure if there would be any, but what the heck.)
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP DSS changes for .38 merge window
On Fri, 2011-01-07 at 22:52 +0900, ext Paul Mundt wrote: Hmm, I've just fast-forwarded to Linus's current tree and tried to pull your rebase branch in, but it seems to have a board conflict with the OMAP tree merge: CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD and modified in 122ffebf2191529153c079b457e38ca3829eac40. Version 122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c left in tree. Additionally there's a board-zoom.c conflict that looks like this: Ah. I'll have to fix that. Let's leave this until Monday, as I don't have a board here to test the fixes. 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: linux-next: manual merge of the usb tree with the omap tree
On 1/6/2011 9:20 PM, Ming Lei wrote: Hi, 2011/1/6 Ming Lei tom.leim...@gmail.com: Hi, 2011/1/6 Anand Gadiyar gadi...@ti.com: I'll take a look in a short while. I don't have an XM to test, so you'll have to help me out here. No problem for me, :-) I see why the beagle xM does not work, the attachment patch is needed to make it working. But the ehci on panda(omap4430) still does not work with 2.6.37-next-20110106+, and follows the failure messages: [ 46.572601] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 46.580017] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96 [ 46.580078] bus: 'platform': add driver ehci-omap [ 46.580139] bus: 'platform': driver_probe_device: matched device ehci-omap.0 with driver ehci-omap [ 46.580169] bus: 'platform': really_probe: probing driver ehci-omap with device ehci-omap.0 [ 46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator [ 46.580200] ehci-omap ehci-omap.0: starting TI EHCI USB Controller [ 46.580291] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x50700100 [ 46.580352] ehci-omap ehci-omap.0: TLL RESET DONE [ 46.580352] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=1c [ 46.580383] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3 [ 46.580383] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1 uframes 256/512/1024 park LPM [ 46.580383] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [ 46.588592] drivers/usb/core/inode.c: creating file 'devices' [ 46.588623] drivers/usb/core/inode.c: creating file '001' [ 46.588684] device: 'usbmon1': device_add [ 46.588867] PM: Adding info for No Bus:usbmon1 [ 46.590026] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [ 46.645721] ehci-omap ehci-omap.0: park 0 [ 46.645721] ehci-omap ehci-omap.0: support lpm [ 46.645751] ehci-omap ehci-omap.0: irq 109, io mem 0x4a064c00 [ 46.651763] ehci-omap ehci-omap.0: reset command 0080b02 park=3 ithresh=8 period=1024 Reset HALT [ 46.651763] ehci-omap ehci-omap.0: init command 0010005 (park)=0 ithresh=1 period=512 RUN [ 46.661254] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [ 46.667297] usb usb1: rpm_resume flags 0x0 [ 46.667297] usb usb1: rpm_resume returns 1 [ 46.667358] usb usb1: default language 0x0409 [ 46.667358] usb usb1: udev 1, busnum 1, minor = 0 [ 46.667388] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 46.675476] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 46.683288] usb usb1: Product: OMAP-EHCI Host Controller [ 46.689086] usb usb1: Manufacturer: Linux 2.6.37-next-20110106+ ehci_hcd [ 46.696350] usb usb1: SerialNumber: ehci-omap.0 [ 46.701354] device: 'usb1': device_add [ 46.701568] bus: 'usb': add device usb1 [ 46.701629] PM: Adding info for usb:usb1 [ 46.702758] bus: 'usb': driver_probe_device: matched device usb1 with driver usb [ 46.702758] bus: 'usb': really_probe: probing driver usb with device usb1 [ 46.702819] usb usb1: usb_probe_device [ 46.702819] usb usb1: configuration #1 chosen from 1 choice [ 46.702850] usb usb1: rpm_resume flags 0x4 [ 46.702850] usb usb1: rpm_resume returns 1 [ 46.702911] usb usb1: adding 1-0:1.0 (config #1, interface 0) [ 46.702911] device: '1-0:1.0': device_add [ 46.702941] bus: 'usb': add device 1-0:1.0 [ 46.703002] PM: Adding info for usb:1-0:1.0 [ 46.703430] bus: 'usb': driver_probe_device: matched device 1-0:1.0 with driver hub [ 46.703460] bus: 'usb': really_probe: probing driver hub with device 1-0:1.0 [ 46.703460] hub 1-0:1.0: usb_probe_interface [ 46.703491] hub 1-0:1.0: usb_probe_interface - got id [ 46.703491] usb usb1: rpm_resume flags 0x4 [ 46.703491] usb usb1: rpm_resume returns 1 [ 46.703521] hub 1-0:1.0: USB hub found [ 46.707427] hub 1-0:1.0: 3 ports detected [ 46.715698] hub 1-0:1.0: standalone hub [ 46.715698] hub 1-0:1.0: individual port power switching [ 46.715728] hub 1-0:1.0: individual port over-current protection [ 46.715728] hub 1-0:1.0: power on to power good time: 20ms [ 46.715759] hub 1-0:1.0: local power source is good [ 46.715759] hub 1-0:1.0: enabling power on all ports [ 46.715820] driver: '1-0:1.0': driver_bound: bound to device 'hub' [ 46.715820] bus: 'usb': really_probe: bound device 1-0:1.0 to driver hub [ 46.715850] device: 'ep_81': device_add [ 46.717468] PM: Adding info for No Bus:ep_81 [ 46.717498] device: 'usbdev1.1': device_add [ 46.717590] PM: Adding info for No Bus:usbdev1.1 [ 46.717773] drivers/usb/core/inode.c: creating file '001' [ 46.717803] driver: 'usb1': driver_bound: bound to device 'usb' [ 46.717803] bus: 'usb': really_probe: bound device usb1 to driver usb [ 46.717834] device: 'ep_00': device_add [ 46.717895] PM: Adding info for No Bus:ep_00 [ 46.717895] usb usb1: rpm_suspend flags 0xc [ 46.717926] usb
Re: linux-next: manual merge of the usb tree with the omap tree
Hi Anand, 2011/1/7 Anand Gadiyar gadi...@ti.com: Hi Ming Lei, I'm able to reproduce this on my panda, and I have it working as of linux-next-20101221 (the last version I tested last year) and failing on linux-next-20101227 (which was the very next linux-next release). Not sure why, but my Panda manages to get the VID:PID of the hub as well, while yours does not even get there. I may need a few more hours to debug this, unless someone beats me to it. ;) Is it caused by the below? [ 46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator thanks, -- Lei Ming -- 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: RFBI worked example
With further experimentation it appears that I can call the
omap_rfbi_update() from the call back, but as the callback is in interrupt
context this could be dangerous. I would love to see an example of this
elsewhere.
static void framedone_callback(void *data)
{
int r;
u16 dw, dh;
struct omap_dss_device *dssdev = (struct omap_dss_device *)data;
/* Start the next update, triggered on the external H/VSync signals */
dssdev-driver-get_resolution(dssdev, dw, dh);
r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
dssdev);
if (r 0)
printk(omap_rfbi_update FAILED);
}
static int generic_panel_power_on(struct omap_dss_device *dssdev)
{
int r;
u16 dw, dh;
r = omapdss_rfbi_display_enable(dssdev);
if (r 0)
goto err0;
/* Setup external HSYNC/VSYNC triggering */
r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2,
400, /* HSYNS pulse 4uS */
10, /* VSYNC pulse 1ms */
0, 0, /* H/VSYNC not inverted */
0);
if (r 0)
goto err1;
/* Enable external triggering */
r = omap_rfbi_enable_te(1, 0);
if (r 0)
goto err1;
#if 0
/* At a guess I do not think we need to do the prepare_update
* if we are updating the whole area
*/
r = omap_rfbi_prepare_update(dssdev, ???);
if (r 0)
goto err1;
#endif
/* Start the first update, triggered on the external H/VSync siganls.
* The callback (FRAMEDONE interrupt context) will re-arm this
* update once more.
*/
dssdev-driver-get_resolution(dssdev, dw, dh);
r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
dssdev);
if (r 0)
goto err1;
if (dssdev-platform_enable) {
r = dssdev-platform_enable(dssdev);
if (r)
goto err1;
}
return 0;
err1:
omap_rfbi_enable_te(0, 0);
omapdss_dpi_display_disable(dssdev);
err0:
return r;
}
-Original Message-
From: Ben Tucker [mailto:btuc...@mpcdata.com]
Sent: 06 January 2011 15:32
To: 'linux-omap@vger.kernel.org'
Cc: 'tomi.valkei...@nokia.com'
Subject: RFBI worked example
Hi,
I am trying to setup an OMAP3530 based system for RFBI video output using
external triggering. Looking at the omap dss2 source code (and also
searching around) I cannot find any worked example of how to use the rfbi
driver. I know that RFBI has worked in the past for a Nokia N800 device.
Can you dig out any source code that shows how to use the RFBI driver?
In particular I need to see how the omap_rfbi_prepare_update() and
omap_rfbi_update() calls operate with their callback. I am thinking that I
should simply call omap_rfbi_update() in a thread and wait for the
completion call back after each call. I want to confirm that this is the
correct way to run the driver.
Thanks,
Ben
Ben Tucker
Senior Software Engineer
MPC Data Limited
e-mail: btuc...@mpc-data.co.uk web: www.mpc-data.co.uk
tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601
ddi: +44 (0) 1225 710660
MPC Data Limited is a company registered in England and Wales with company
number 05507446
Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14
7FJ
VAT no: 850625238
The information in this email and in the attached documents is
confidential and may be
legally privileged. Any unauthorized review, copying, disclosure or
distribution is
prohibited and may be unlawful. It is intended solely for the addressee.
Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, please
contact the sender by reply email and destroy all copies of the original
message. When
addressed to our clients any opinions or advice contained in this email is
subject to
the terms and conditions expressed in the governing contract.
--
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: 4430SDP boot failure
On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote: Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me. Low level debug as you reported seems to be broken though. Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new 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: 4430SDP boot failure
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Friday, January 07, 2011 7:55 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: 4430SDP boot failure On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote: Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me. Low level debug as you reported seems to be broken though. Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel. Glad to hear that. 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: linux-next: manual merge of the usb tree with the omap tree
Ming Lei wrote: 2011/1/7 Anand Gadiyar gadi...@ti.com: Hi Ming Lei, I'm able to reproduce this on my panda, and I have it working as of linux-next-20101221 (the last version I tested last year) and failing on linux-next-20101227 (which was the very next linux-next release). Not sure why, but my Panda manages to get the VID:PID of the hub as well, while yours does not even get there. I may need a few more hours to debug this, unless someone beats me to it. ;) Is it caused by the below? [ 46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator Nope. We don't set up any regulators for the PHY on Panda (at least not yet). And the working case (next-20101221) has the same log. I suspect the PHY doesn't get reset for the proper duration; I'm looking for something in that area. (Another option is to bisect between the two versions, but I'm not sure if that's any easier). - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest regressions
While trying to build the latest kernel for the SDP4430 board: arch/arm/mach-omap2/clockdomain.c: In function ■_enable_hwsup■: arch/arm/mach-omap2/clockdomain.c:251: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c:254: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c: In function ■_disable_hwsup■: arch/arm/mach-omap2/clockdomain.c:277: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c:280: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c: In function ■omap2_clkdm_sleep■: arch/arm/mach-omap2/clockdomain.c:744: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c: In function ■omap2_clkdm_wakeup■: arch/arm/mach-omap2/clockdomain.c:789: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c: In function ■omap2_clkdm_clk_enable■: arch/arm/mach-omap2/clockdomain.c:922: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c:926: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c: In function ■omap2_clkdm_clk_disable■: arch/arm/mach-omap2/clockdomain.c:994: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ arch/arm/mach-omap2/clockdomain.c:998: error: ■struct clockdomain■ has no member named ■clktrctrl_mask■ Linus' tree prior to the OMAP merge is buildable for the same config. -- 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: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Fri, Jan 07, 2011 at 07:12:13AM -0500, J, KEERTHY wrote: On Fri, Jan 7, 2011 at 3:25 AM, Guenter Roeck guenter.ro...@ericsson.com wrote: On Thu, 2011-01-06 at 15:21 -0500, Mark Brown wrote: On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote: On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote: Why? It's not like hwmon has an unreasonably large core or similar. Because it creates an unnecessary dependency, and because it is not hwmon's responsibility to provide infrastructure for other subsystems or drivers. hwmon isn't really doing anything, though. The *driver* is doing something but it doesn't really impact the core that much. Not that I'm particularly sold on putting the ADC core in here, but total NACK based on that alone seems rather harsh. Possibly. However, I had suggested the following earlier (to the 1st version of the patch): I commented on this a couple of times below - the driver mixes generic ADC reading functions with hwmon functionality. Generic ADC reading functionality should be moved into another driver, possibly to mfd. Obviously that was ignored. Maybe someone is willing to listen this time around. I am sorry for not responding on the generic ADC handling part. Since many other ADC drivers are part of hwmon i thought hwmon was the appropriate place. However I can surely split the generic ADC handling part in mfd and only hardware monitoring part in hwmon as suggested. Other drivers don't _export_ that functionality. Key difference. Sure, the lis3 driver does, but that should not be in hwmon in the first place and is on the way out (if I ever get to do it), and max is just setting a bad example. Guenter -- 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: Latest regressions
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux Sent: Friday, January 07, 2011 8:11 PM To: linux-omap@vger.kernel.org Subject: Re: Latest regressions While trying to build the latest kernel for the SDP4430 board: arch/arm/mach-omap2/clockdomain.c: In function │_enable_hwsup│: arch/arm/mach-omap2/clockdomain.c:251: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c:254: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │_disable_hwsup│: arch/arm/mach-omap2/clockdomain.c:277: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c:280: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_sleep│: arch/arm/mach-omap2/clockdomain.c:744: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_wakeup│: arch/arm/mach-omap2/clockdomain.c:789: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_clk_enable│: arch/arm/mach-omap2/clockdomain.c:922: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c:926: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_clk_disable│: arch/arm/mach-omap2/clockdomain.c:994: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c:998: error: │struct clockdomain│ has no member named │clktrctrl_mask│ Linus' tree prior to the OMAP merge is buildable for the same config. :) This one is also fixed with the series but would get merged in rc1 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41712.html 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: Latest regressions
On Fri, Jan 07, 2011 at 08:24:26PM +0530, Santosh Shilimkar wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux Sent: Friday, January 07, 2011 8:11 PM To: linux-omap@vger.kernel.org Subject: Re: Latest regressions While trying to build the latest kernel for the SDP4430 board: arch/arm/mach-omap2/clockdomain.c: In function │_enable_hwsup│: arch/arm/mach-omap2/clockdomain.c:251: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c:254: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │_disable_hwsup│: arch/arm/mach-omap2/clockdomain.c:277: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c:280: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_sleep│: arch/arm/mach-omap2/clockdomain.c:744: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_wakeup│: arch/arm/mach-omap2/clockdomain.c:789: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_clk_enable│: arch/arm/mach-omap2/clockdomain.c:922: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c:926: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_clk_disable│: arch/arm/mach-omap2/clockdomain.c:994: error: │struct clockdomain│ has no member named │clktrctrl_mask│ arch/arm/mach-omap2/clockdomain.c:998: error: │struct clockdomain│ has no member named │clktrctrl_mask│ Linus' tree prior to the OMAP merge is buildable for the same config. :) This one is also fixed with the series but would get merged in rc1 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41712.html It's something that should be queued up to also go in during the merge window IMHO. Let's try to make rc1 a little less problematical than it currently is. -- 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: RFBI worked example
On Fri, 2011-01-07 at 14:18 +, ext Ben Tucker wrote:
With further experimentation it appears that I can call the
omap_rfbi_update() from the call back, but as the callback is in interrupt
context this could be dangerous. I would love to see an example of this
elsewhere.
Did you get it working enough to get an image on the panel?
It's been long since I've touched the rfbi code, and I honestly don't
know the state of it, but basically it should work similarly as DSI
command mode:
The panel driver issues an update when the user space has requested it
via OMAPFB_UPDATE_WINDOW. So it's not meant to be triggered
automatically.
If you really want to update the display automatically (which you
shouldn't, as the point with panels with their own framebuffer is to
update only when necessary), you can do it either directly as you do, or
via workqueue or thread.
I don't know right away if calling omap_rfbi_update() from interrupt
context is dangerous, but it might well be so you should check if
carefully.
Also, remember that you may need to stop updates somehow when the panel
is blanked or the driver is unloaded.
static void framedone_callback(void *data)
{
int r;
u16 dw, dh;
struct omap_dss_device *dssdev = (struct omap_dss_device *)data;
/* Start the next update, triggered on the external H/VSync signals */
dssdev-driver-get_resolution(dssdev, dw, dh);
r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
dssdev);
if (r 0)
printk(omap_rfbi_update FAILED);
}
static int generic_panel_power_on(struct omap_dss_device *dssdev)
{
int r;
u16 dw, dh;
r = omapdss_rfbi_display_enable(dssdev);
if (r 0)
goto err0;
/* Setup external HSYNC/VSYNC triggering */
r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2,
400, /* HSYNS pulse 4uS */
10, /* VSYNC pulse 1ms */
0, 0, /* H/VSYNC not inverted */
0);
if (r 0)
goto err1;
/* Enable external triggering */
r = omap_rfbi_enable_te(1, 0);
if (r 0)
goto err1;
#if 0
/* At a guess I do not think we need to do the prepare_update
* if we are updating the whole area
*/
I'm not sure if it's ok not to call it every time, but you should at
least call it once to be sure everything is configured properly.
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: linux-next: manual merge of the usb tree with the omap tree
Ming Lei wrote: Ming Lei wrote: 2011/1/7 Anand Gadiyar gadi...@ti.com: Hi Ming Lei, I'm able to reproduce this on my panda, and I have it working as of linux-next-20101221 (the last version I tested last year) and failing on linux-next-20101227 (which was the very next linux-next release). Not sure why, but my Panda manages to get the VID:PID of the hub as well, while yours does not even get there. I may need a few more hours to debug this, unless someone beats me to it. ;) Is it caused by the below? [ 46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator Nope. We don't set up any regulators for the PHY on Panda (at least not yet). And the working case (next-20101221) has the same log. I suspect the PHY doesn't get reset for the proper duration; I'm looking for something in that area. (Another option is to bisect between the two versions, but I'm not sure if that's any easier). Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other connected devices enumerate just fine. Could you try this out on your board as well? I'll look deeper and see if there are some required clocks that are accidentally getting turned off. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
OMP3630 silicon can enable higher frequencies only depending on the board
characteristics meeting the recommended standards, and has to be selectively
toggled.
Beagle XM uses 3730 variant and the board design allows enabling 800MHz and
1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz
safely. For the moment, we tweak the default table to allow for 800Mhz OPP
usage.
Reported-by: Koen Kooi k...@beagleboard.org
Tested-by: Koen Kooi k...@beagleboard.org
Signed-off-by: Nishanth Menon n...@ti.com
---
v2: fixed issue when !mh || !dh, updated commit message to point on rationale
for board specific tweaking
v1: http://marc.info/?t=12942606098r=1w=2
arch/arm/mach-omap2/board-omap3beagle.c | 50 +++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..7dc0397 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -23,6 +23,7 @@
#include linux/gpio.h
#include linux/input.h
#include linux/gpio_keys.h
+#include linux/opp.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
@@ -44,10 +45,12 @@
#include plat/gpmc.h
#include plat/nand.h
#include plat/usb.h
+#include plat/omap_device.h
#include mux.h
#include hsmmc.h
#include timer-gp.h
+#include pm.h
#define NAND_BLOCK_SIZESZ_128K
@@ -556,6 +559,52 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static void __init beagle_opp_init(void)
+{
+ int r = 0;
+
+ /* Initialize the omap3 opp table */
+ if (omap3_opp_init()) {
+ pr_err(%s: opp default init failed\n, __func__);
+ return;
+ }
+
+ /* Custom OPP enabled for XM */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
+ struct omap_hwmod *dh = omap_hwmod_lookup(iva);
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
+ __func__, mh, dh);
+ return;
+ }
+ /* Enable MPU 1GHz and lower opps */
+ dev = mh-od-pdev.dev;
+ r = opp_enable(dev, 8);
+ /* TODO: MPU 1GHz needs SR and ABB */
+
+ /* Enable IVA 800MHz and lower opps */
+ dev = dh-od-pdev.dev;
+ r |= opp_enable(dev, 66000);
+ /* TODO: DSP 800MHz needs SR and ABB */
+ if (r) {
+ pr_err(%s: failed to enable higher opp %d\n,
+ __func__, r);
+ /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+ dev = mh-od-pdev.dev;
+ opp_disable(dev, 8);
+ dev = dh-od-pdev.dev;
+ opp_disable(dev, 66000);
+ }
+ }
+ return;
+}
+
static void __init omap3_beagle_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -579,6 +628,7 @@ static void __init omap3_beagle_init(void)
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
beagle_display_init();
+ beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, January 07, 2011 7:55 PM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; Tony Lindgren
Subject: Re: 4430SDP boot failure
On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
Have sent you latest bootloaders and full bootlog on my ES1.0
OMAP4430SDP. 2.6.37 just boots fine for me.
Low level debug as you reported seems to be broken though.
Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
the board - which should ease the debugging problem as it no longer
requires anything but the reset button pressed to test a new kernel.
Glad to hear that.
And, with one ARM errata disabled, the kernel finally boots. So the
X-Loader hangs message means that we did something that non-secure
mode prevented us from doing.
It would be a good idea if X-loader could tell dump out the exception,
register dump, and for data/prefetch aborts, the relevent FSR and FAR
registers - that would make debugging this kind of failure a lot
easier.
=
Subject: Fix DMA API usage in OMAP MCSPI driver
Running the latest kernel on the 4430SDP board with DMA API debugging
enabled results in this:
WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated
[device address=0x8129901a] [size=260 bytes]
Modules linked in:
Backtrace:
[c003cbe0] (dump_backtrace+0x0/0x10c) from [c0278da8] (dump_stack+0x18/0x1c)
r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
[c0278d90] (dump_stack+0x0/0x1c) from [c005b158]
(warn_slowpath_common+0x58/0x70)
[c005b100] (warn_slowpath_common+0x0/0x70) from [c005b214]
(warn_slowpath_fmt+0x38/0x40)
r8:c1839e40 r7: r6:0104 r5: r4:8129901a
[c005b1dc] (warn_slowpath_fmt+0x0/0x40) from [c0198578]
(check_unmap+0x19c/0x6f0)
r3:c03110de r2:c0304e6b
[c01983dc] (check_unmap+0x0/0x6f0) from [c0198cd8]
(debug_dma_unmap_page+0x74/0x80)
[c0198c64] (debug_dma_unmap_page+0x0/0x80) from [c01d5ad8]
(omap2_mcspi_work+0x514/0xbf0)
[c01d55c4] (omap2_mcspi_work+0x0/0xbf0) from [c006dfb0]
(process_one_work+0x294/0x400)
[c006dd1c] (process_one_work+0x0/0x400) from [c006e50c]
(worker_thread+0x220/0x3f8)
[c006e2ec] (worker_thread+0x0/0x3f8) from [c00738d0] (kthread+0x88/0x90)
[c0073848] (kthread+0x0/0x90) from [c005e924] (do_exit+0x0/0x5fc)
r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
---[ end trace 1b75b31a2719ed20 ]---
I've no idea why this driver uses NULL for dma_unmap_single instead of
the spi-dev that is laying around just waiting to be used in that
function - but it's an easy fix.
Also replace this comment with a FIXME comment:
/* Do DMA mapping early for better error reporting and
* dcache use. Note that if dma_unmap_single() ever starts
* to do real work on ARM, we'd need to clean up mappings
* for previous transfers on *ALL* exits of this loop...
*/
as the comment is not true - we do work in dma_unmap() functions,
particularly on ARMv6 and above. I've corrected the existing unmap
functions but if any others are required they must be added ASAP.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
I'm surprised this driver got merged as it has such a comment, and is
abusing the DMA API... well, at least with the DMA API debugging we
can now catch this stuff.
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 951a160..abb1ffb 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (tx != NULL) {
wait_for_completion(mcspi_dma-dma_tx_completion);
- dma_unmap_single(NULL, xfer-tx_dma, count, DMA_TO_DEVICE);
+ dma_unmap_single(spi-dev, xfer-tx_dma, count, DMA_TO_DEVICE);
/* for TX_ONLY mode, be sure all words have shifted out */
if (rx == NULL) {
@@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (rx != NULL) {
wait_for_completion(mcspi_dma-dma_rx_completion);
- dma_unmap_single(NULL, xfer-rx_dma, count, DMA_FROM_DEVICE);
+ dma_unmap_single(spi-dev, xfer-rx_dma, count,
DMA_FROM_DEVICE);
omap2_mcspi_set_enable(spi, 0);
if (l OMAP2_MCSPI_CHCONF_TURBO) {
@@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device *spi,
struct spi_message *m)
if (m-is_dma_mapped || len DMA_MIN_BYTES)
continue;
- /* Do DMA mapping early for better error reporting and
-* dcache use. Note that if dma_unmap_single() ever starts
-* to do real
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote: Anyways, I can debug the DEBUG_LL booting issue further if the patch I posted does not help. This is what I ended up with earlier today to make the debug code work both in the decompressor and in the kernel - once I had it working I haven't bothered putting any more effort into it. diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S index 6a4d413..47df8a6 100644 --- a/arch/arm/mach-omap2/include/mach/debug-macro.S +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S @@ -13,6 +13,7 @@ #include linux/serial_reg.h +#if 0 #include asm/memory.h #include plat/serial.h @@ -139,6 +140,24 @@ omap_uart_lsr: .word 0 teq \rd, #(UART_LSR_TEMT | UART_LSR_THRE) bne 1001b .endm +#else + .macro addruart, rp, rv + mov \rp, #0x0002 + orr \rv, \rp, #0xfa00 + orr \rp, \rp, #0x4800 + .endm + + .macro senduart, ch, rb + strb\ch, [\rb] + .endm + + .macro busyuart, rb, tmp +1001: ldrb\tmp, [\rb, #UART_LSR 2] + and \tmp, \tmp, #UART_LSR_TEMT | UART_LSR_THRE + teq \tmp, #UART_LSR_TEMT | UART_LSR_THRE + bne 1001b + .endm +#endif .macro waituart,rd,rx .endm -- 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: 4430SDP boot failure
On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote: -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Friday, January 07, 2011 7:55 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: 4430SDP boot failure On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote: Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me. Low level debug as you reported seems to be broken though. Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel. Glad to hear that. Right, next couple of problems. udev isn't creating the ttyO* nodes for whatever reason on my fs - does anyone know what device major/minor numbers these end up with? It seems they're dynamically assigned. There's also something fishy going on with networking (if I configure PNP IP, I get an IP: ks8851 spi1.0: message enable is 0 ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194 IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144 IP-Config: Complete: device=eth0, addr=192.168.0.144, mask=255.255.255.0, gw=192.168.0.1, host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none), bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath= but the board doesn't respond to that IP address. Meanwhile the DHCP server shows: DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0 in its log, and the ethernet address appears to be random for each boot. Obviously, as I can't log into the board via any means, it's nigh on impossible to work out what's actually going on. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ASoC: DMIC: Adding the OMAP DMIC driver
On Thu, Jan 6, 2011 at 4:20 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Thu, Jan 06, 2011 at 08:00:36AM -0600, David Lambert wrote:
@@ -103,6 +106,7 @@ config SND_OMAP_SOC_SDP4430
depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP_4430SDP
select SND_OMAP_SOC_MCPDM
select SND_SOC_TWL6040
+ select SND_SOC_DMIC
help
Say Y if you want to add support for SoC audio on Texas Instruments
SDP4430.
Any tweaks to specific machines should be done separately to adding the
new drivers.
OK... I'll put that in to a separate patch.
+ struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
+ int ctrl, div_sel = -EINVAL;
+
+ if (div_id != OMAP_DMIC_CLKDIV)
+ return -ENODEV;
+
+ switch (dmic-clk_freq) {
+ case 1920:
+ if (div == 5)
+ div_sel = 0x1;
+ else if (div == 8)
+ div_sel = 0x0;
I suggested switch statements previously; you didn't comment on my
reply.
Sorry... my personal standard on when to go with a switch statement is
2 choices,
I'll change it over to a switch...
+static irqreturn_t omap_dmic_irq_handler(int irq, void *dev_id)
+{
+ struct omap_dmic *dmic = dev_id;
My comments on this function appear to have been mostly ignored also.
Being as with this hardware, the IRQ handler really does nothing, I
think it best
if I just take it out for now. It is useful in debugging cases to ensure you're
moving data. I'll just remove it.
+ switch (rate) {
+ case 192000:
+ div = 5;
+ break;
+ default:
+ div = 8;
Shouldn't the default case be a case 96000?
The default case IS 96000 (only options for rate here are 96000 and
192000), isn't it?
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ break;
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ break;
Remove the empty cases, they're handled by the default.
OK
+
+MODULE_AUTHOR(David Lambert dlamb...@ti.com);
+MODULE_DESCRIPTION(OMAP DMIC SoC Interface);
+MODULE_LICENSE(GPL);
As also previously noted you should have a MODULE_ALIAS.
The MODULE_ALIAS is in there... just following example of the other drivers
I looked at, it was placed above the platform_driver declaration.
+MODULE_ALIAS(platform:omap-dmic-dai);
+
+static struct platform_driver asoc_dmic_driver = {
+ .driver = {
+ .name = omap-dmic-dai,
+ .owner = THIS_MODULE,
+ },
+ .probe = asoc_dmic_probe,
+ .remove = __devexit_p(asoc_dmic_remove),
+};
--
David Lambert
OMAP™ Multimedia
214-567-5692
--
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: Latest config warning
* Russell King - ARM Linux li...@arm.linux.org.uk [110107 03:34]: warning: (ARCH_STMP3XXX choice || ARCH_OMAP3 ARCH_OMAP2PLUS) selects USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) This didn't happen with 2.6.37. Maybe a missing select USB_SUPPORT somewhere? Felipe, care to take a look at this one? 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
