Re: Hang on boot
Hi, On Mon, 2010-10-11 at 14:09 +1100, John Garland wrote: Hi, Both the dspbridge and master branch of linux-omap seem to hang when trying to boot (i.e. no output) on a beagleboard C2. This is with the new omap2plus_defconfig (as opposed to the old omap3_defconfig). Is anybody else experiencing this or does anyone have any idea what could be causing this? Make sure you update your u-boot environment so that you have console=ttyO2,115200 in your kernel command line (btw, it's ttyO2, not tty02). It's been recently changed in the linux-omap tree (commit d6e284d). You'll probably also need to update your /etc/inittab. Cheers, Ionut. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database
Benoit and Manju,
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Saturday, October 09, 2010 9:10 PM
To: Cousson, Benoit; Basak, Partha
Cc: Kevin Hilman; G, Manjunath Kondaiah; linux-omap@vger.kernel.org;
Shilimkar, Santosh; Paul Walmsley; Tony Lindgren
Subject: RE: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod
database
Benoit,
-Original Message-
From: Cousson, Benoit
Sent: Thursday, September 23, 2010 10:15 PM
To: Basak, Partha
Cc: Kevin Hilman; G, Manjunath Kondaiah; DebBarma, Tarun Kanti; linux-
o...@vger.kernel.org; Shilimkar, Santosh; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod
database
On 9/23/2010 11:34 AM, Basak, Partha wrote:
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 23, 2010 3:10 AM
G, Manjunath Kondaiahmanj...@ti.com writes:
Hi Tarun,
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
...
+static u32 omap_timer_reg_map_v1[] = {
+ [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_SYS_STAT_REG] = (0x14 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_STAT_REG] = (0x18 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_INT_EN_REG] = (0x1c | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_WAKEUP_EN_REG] = (0x20 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_CTRL_REG] = (0x24 | (WP_TCLR WPSHIFT)),
+ [OMAP_TIMER_COUNTER_REG]= (0x28 | (WP_TCRR WPSHIFT)),
+ [OMAP_TIMER_LOAD_REG] = (0x2c | (WP_TLDR WPSHIFT)),
+ [OMAP_TIMER_TRIGGER_REG]= (0x30 | (WP_TTGR WPSHIFT)),
+ [OMAP_TIMER_WRITE_PEND_REG] = (0x34 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_MATCH_REG] = (0x38 | (WP_TMAR WPSHIFT)),
+ [OMAP_TIMER_CAPTURE_REG]= (0x3c | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_IF_CTRL_REG]= (0x40 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_CAPTURE2_REG] = (0x44 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_TICK_POS_REG] = (0x48 | (WP_TPIR WPSHIFT)),
+ [OMAP_TIMER_TICK_NEG_REG] = (0x4c | (WP_TNIR WPSHIFT)),
+ [OMAP_TIMER_TICK_COUNT_REG] = (0x50 | (WP_TCVR WPSHIFT)),
+ [OMAP_TIMER_TICK_INT_MASK_SET_REG] = (0x54 |
(WP_TOCR WPSHIFT)),
+ [OMAP_TIMER_TICK_INT_MASK_COUNT_REG]= (0x58 |
(WP_TOWR WPSHIFT)),
+};
+
+/* OMAP4 timers register map */
+static u32 omap_timer_reg_map_v2[] = {
+ [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_SYS_STAT_REG] = (0x14 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_STAT_REG] = (0x28 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_INT_EN_REG] = (0x2c | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_WAKEUP_EN_REG] = (0x34 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_CTRL_REG] = (0x38 | (WP_TCLR WPSHIFT)),
+ [OMAP_TIMER_COUNTER_REG]= (0x3c | (WP_TCRR WPSHIFT)),
+ [OMAP_TIMER_LOAD_REG] = (0x40 | (WP_TLDR WPSHIFT)),
+ [OMAP_TIMER_TRIGGER_REG]= (0x44 | (WP_TTGR WPSHIFT)),
+ [OMAP_TIMER_WRITE_PEND_REG] = (0x48 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_MATCH_REG] = (0x4c | (WP_TMAR WPSHIFT)),
+ [OMAP_TIMER_CAPTURE_REG]= (0x50 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_IF_CTRL_REG]= (0x54 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_CAPTURE2_REG] = (0x58 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_INT_CLR_REG]= (0x30 | (WP_NONE WPSHIFT)),
+};
+
Why not these defines in mach-omap2/dmtimer.c? since
register offsets are
same for omap2plus except omap4 which has additional
register offsets. Same
register offsets are getting repeated in all the omap2plus
hwmod database.
I agree with Manjunath.
Manju, the number of tables needed to manage the information are same
really.
Its only where they are located changes from the mach layer to the
hwmod
database. So, thats not the point. dev_attrs are pointing to the reg-
map
tables, they are not duplicating them.
The offset differences are stemming from the IP differences.
To my understanding, only IP-integration specific idiosyncrasies into
a
given
SOC qualifiy as dev_attrs.
IP specific details like reg-map information should be maintained
within
the driver.
So, this approach will break this paradigm also not follow existing
implementation
of drivers which support this. A given driver may support a set of IPs
but still
may cater to even non-OMAP platforms not supporting hwmod.
However, if we see the general usage of dev_attrs, there is no clear
line of demarcation
really what should make it and what should not, as is used to plug
this
sort of
small
Re: [PATCH] Revert OMAP: mach-omap2: Fix incorrect assignment warnings
On Sat, Oct 9, 2010 at 8:55 AM, Jean Pihet jean.pi...@newoldbits.com wrote: Kevin, On Sat, Oct 9, 2010 at 12:47 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Kevin Hilman khil...@deeprootsystems.com writes: ... Since only one part of the original patch introduced a bug, I decided to just fix that bug and keep the fixes for the sparse warnings. I just posted a patch[1] for the fix. Please test. Thanks, Thanks for the follow-up on the patch. I will test asap. Tested OK on OMAP3EVM with RET OFF mode in idle path. Tested-by: Jean Pihet jean.pi...@newoldbits.com Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv3 0/7] HSI framework and drivers
Hi ! Here you have the third round of the HSI framework patches. The patch series introduces the HSI framework, an SSI driver for OMAP and a generic character device for HSI/SSI devices. SSI, which is a legacy version of HSI, is used to connect the application engine with the cellular modem on the Nokia N900. In this round we have fixed: - Locking issues in the HSI framework. - Fixes on removal of controller's modules. - Error path handling in the omap_ssi driver. - Increase the robustness of hsi_char. - Typos and cosmetics. - Some unused parameters warnings. I would very glad to continue getting feedback about this proposal. This patch series is based on 2.6.36-rc6. Version 2 of the patch set: http://lkml.org/lkml/2010/5/7/233 Br, Carlos Chinea Andras Domokos (3): HSI CHAR: Add HSI char device driver HSI CHAR: Add HSI char device kernel configuration HSI CHAR: Update ioctl-number.txt Carlos Chinea (4): HSI: Introducing HSI framework OMAP SSI: Introducing OMAP SSI driver OMAP SSI: Add OMAP SSI to the kernel configuration HSI: Add HSI API documentation Documentation/DocBook/device-drivers.tmpl | 17 + Documentation/ioctl/ioctl-number.txt |1 + arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/ssi.c | 139 +++ arch/arm/plat-omap/include/plat/ssi.h | 204 drivers/Kconfig |2 + drivers/Makefile |1 + drivers/hsi/Kconfig | 16 + drivers/hsi/Makefile |5 + drivers/hsi/clients/Kconfig | 13 + drivers/hsi/clients/Makefile |5 + drivers/hsi/clients/hsi_char.c| 1090 + drivers/hsi/controllers/Kconfig | 21 + drivers/hsi/controllers/Makefile |5 + drivers/hsi/controllers/omap_ssi.c| 1836 + drivers/hsi/hsi.c | 516 include/linux/Kbuild |1 + include/linux/hsi/Kbuild |1 + include/linux/hsi/hsi.h | 376 ++ include/linux/hsi/hsi_char.h | 66 + 20 files changed, 4318 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/ssi.c create mode 100644 arch/arm/plat-omap/include/plat/ssi.h create mode 100644 drivers/hsi/Kconfig create mode 100644 drivers/hsi/Makefile create mode 100644 drivers/hsi/clients/Kconfig create mode 100644 drivers/hsi/clients/Makefile create mode 100644 drivers/hsi/clients/hsi_char.c create mode 100644 drivers/hsi/controllers/Kconfig create mode 100644 drivers/hsi/controllers/Makefile create mode 100644 drivers/hsi/controllers/omap_ssi.c create mode 100644 drivers/hsi/hsi.c create mode 100644 include/linux/hsi/Kbuild create mode 100644 include/linux/hsi/hsi.h create mode 100644 include/linux/hsi/hsi_char.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv3 6/7] HSI: Add HSI API documentation
Add an entry for HSI in the device-drivers section of the kernel documentation. Signed-off-by: Carlos Chinea carlos.chi...@nokia.com --- Documentation/DocBook/device-drivers.tmpl | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index feca075..28ab783 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -428,4 +428,21 @@ X!Idrivers/video/console/fonts.c !Edrivers/i2c/i2c-core.c /chapter + chapter id=hsi + titleHigh Speed Synchronous Serial Interface (HSI)/title + + para + High Speed Synchronous Serial Interface (HSI) is a + serial interface mainly used for connecting application + engines (APE) with cellular modem engines (CMT) in cellular + handsets. + + HSI provides multiplexing for up to 16 logical channels, + low-latency and full duplex communication. + /para + +!Iinclude/linux/hsi/hsi.h +!Edrivers/hsi/hsi.c + /chapter + /book -- 1.5.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv3 1/7] HSI: Introducing HSI framework
Adds HSI framework in to the linux kernel.
High Speed Synchronous Serial Interface (HSI) is a
serial interface mainly used for connecting application
engines (APE) with cellular modem engines (CMT) in cellular
handsets.
HSI provides multiplexing for up to 16 logical channels,
low-latency and full duplex communication.
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
---
drivers/Kconfig |2 +
drivers/Makefile|1 +
drivers/hsi/Kconfig | 13 ++
drivers/hsi/Makefile|4 +
drivers/hsi/hsi.c | 516 +++
include/linux/hsi/hsi.h | 376 ++
6 files changed, 912 insertions(+), 0 deletions(-)
create mode 100644 drivers/hsi/Kconfig
create mode 100644 drivers/hsi/Makefile
create mode 100644 drivers/hsi/hsi.c
create mode 100644 include/linux/hsi/hsi.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index a2b902f..4fe39f9 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -50,6 +50,8 @@ source drivers/i2c/Kconfig
source drivers/spi/Kconfig
+source drivers/hsi/Kconfig
+
source drivers/pps/Kconfig
source drivers/gpio/Kconfig
diff --git a/drivers/Makefile b/drivers/Makefile
index 63e3aa9..6c6922a 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_SCSI)+= scsi/
obj-$(CONFIG_ATA) += ata/
obj-$(CONFIG_MTD) += mtd/
obj-$(CONFIG_SPI) += spi/
+obj-$(CONFIG_HSI) += hsi/
obj-y += net/
obj-$(CONFIG_ATM) += atm/
obj-$(CONFIG_FUSION) += message/
diff --git a/drivers/hsi/Kconfig b/drivers/hsi/Kconfig
new file mode 100644
index 000..5af62ce
--- /dev/null
+++ b/drivers/hsi/Kconfig
@@ -0,0 +1,13 @@
+#
+# HSI driver configuration
+#
+menuconfig HSI
+ bool HSI support
+ ---help---
+ The High speed synchronous Serial Interface is
+ synchronous serial interface used mainly to connect
+ application engines and cellular modems.
+
+if HSI
+
+endif # HSI
diff --git a/drivers/hsi/Makefile b/drivers/hsi/Makefile
new file mode 100644
index 000..b42b6cf
--- /dev/null
+++ b/drivers/hsi/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for HSI
+#
+obj-$(CONFIG_HSI) += hsi.o
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
new file mode 100644
index 000..78f1df4
--- /dev/null
+++ b/drivers/hsi/hsi.c
@@ -0,0 +1,516 @@
+/*
+ * hsi.c
+ *
+ * HSI core.
+ *
+ * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.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/hsi/hsi.h
+#include linux/compiler.h
+#include linux/rwsem.h
+#include linux/list.h
+#include linux/spinlock.h
+#include linux/kobject.h
+#include linux/slab.h
+#include linux/string.h
+
+struct hsi_cl_info {
+ struct list_headlist;
+ struct hsi_board_info info;
+};
+
+static LIST_HEAD(hsi_board_list);
+
+static struct device_type hsi_ctrl = {
+ .name = hsi_controller,
+};
+
+static struct device_type hsi_cl = {
+ .name = hsi_client,
+};
+
+static struct device_type hsi_port = {
+ .name = hsi_port,
+};
+
+static ssize_t modalias_show(struct device *dev,
+ struct device_attribute *a __maybe_unused, char *buf)
+{
+ return sprintf(buf, hsi:%s\n, dev_name(dev));
+}
+
+static struct device_attribute hsi_bus_dev_attrs[] = {
+ __ATTR_RO(modalias),
+ __ATTR_NULL,
+};
+
+static int hsi_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ add_uevent_var(env, MODALIAS=hsi:%s, dev_name(dev));
+
+ return 0;
+}
+
+static int hsi_bus_match(struct device *dev, struct device_driver *driver)
+{
+ return strcmp(dev_name(dev), driver-name) == 0;
+}
+
+static struct bus_type hsi_bus_type = {
+ .name = hsi,
+ .dev_attrs = hsi_bus_dev_attrs,
+ .match = hsi_bus_match,
+ .uevent = hsi_bus_uevent,
+};
+
+static void hsi_client_release(struct device *dev)
+{
+ kfree(to_hsi_client(dev));
+}
+
+static void hsi_new_client(struct hsi_port *port, struct hsi_board_info *info)
+{
+ struct hsi_client *cl;
+ unsigned long flags;
+
+ cl = kzalloc(sizeof(*cl), GFP_KERNEL);
+ if (!cl)
+ return;
+
[RFC PATCHv3 3/7] OMAP SSI: Add OMAP SSI to the kernel configuration
Add OMAP SSI device and driver to the kernel configuration Signed-off-by: Carlos Chinea carlos.chi...@nokia.com --- arch/arm/mach-omap2/Makefile |3 +++ drivers/hsi/Kconfig |2 ++ drivers/hsi/Makefile |1 + drivers/hsi/controllers/Kconfig | 21 + drivers/hsi/controllers/Makefile |5 + 5 files changed, 32 insertions(+), 0 deletions(-) create mode 100644 drivers/hsi/controllers/Kconfig create mode 100644 drivers/hsi/controllers/Makefile diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 7352412..0e5e8eb 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -108,6 +108,9 @@ obj-y += $(iommu-m) $(iommu-y) i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o obj-y += $(i2c-omap-m) $(i2c-omap-y) +omap-ssi-$(CONFIG_OMAP_SSI):= ssi.o +obj-y += $(omap-ssi-m) $(omap-ssi-y) + # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o diff --git a/drivers/hsi/Kconfig b/drivers/hsi/Kconfig index 5af62ce..07987b6 100644 --- a/drivers/hsi/Kconfig +++ b/drivers/hsi/Kconfig @@ -10,4 +10,6 @@ menuconfig HSI if HSI +source drivers/hsi/controllers/Kconfig + endif # HSI diff --git a/drivers/hsi/Makefile b/drivers/hsi/Makefile index b42b6cf..d020ae1 100644 --- a/drivers/hsi/Makefile +++ b/drivers/hsi/Makefile @@ -2,3 +2,4 @@ # Makefile for HSI # obj-$(CONFIG_HSI) += hsi.o +obj-y += controllers/ diff --git a/drivers/hsi/controllers/Kconfig b/drivers/hsi/controllers/Kconfig new file mode 100644 index 000..37a2568 --- /dev/null +++ b/drivers/hsi/controllers/Kconfig @@ -0,0 +1,21 @@ +# +# HSI controllers configuration +# +comment HSI controllers + +config OMAP_SSI + tristate OMAP SSI hardware driver + depends on ARCH_OMAP HSI + default n + ---help--- + If you say Y here, you will enable the OMAP SSI hardware driver. + + If unsure, say N. + +if OMAP_SSI + +config OMAP_SSI_CONFIG + boolean + default y + +endif # OMAP_SSI diff --git a/drivers/hsi/controllers/Makefile b/drivers/hsi/controllers/Makefile new file mode 100644 index 000..c4ba2c2 --- /dev/null +++ b/drivers/hsi/controllers/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for HSI controllers drivers +# + +obj-$(CONFIG_OMAP_SSI) += omap_ssi.o -- 1.5.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv3 7/7] HSI CHAR: Update ioctl-number.txt
From: Andras Domokos andras.domo...@nokia.com Added ioctl range for HSI char devices to the documentation Signed-off-by: Andras Domokos andras.domo...@nokia.com Signed-off-by: Carlos Chinea carlos.chi...@nokia.com --- Documentation/ioctl/ioctl-number.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 33223ff..d2dc737 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -225,6 +225,7 @@ Code Seq#(hex) Include FileComments 'j'00-3F linux/joystick.h 'k'00-0F linux/spi/spidev.h conflict! 'k'00-05 video/kyro.hconflict! +'k'10-17 linux/hsi/hsi_char.hHSI character device 'l'00-3F linux/tcfs_fs.h transparent cryptographic file system http://web.archive.org/web/*/http://mikonos.dia.unisa.it/tcfs 'l'40-7F linux/udf_fs_i.hin development: -- 1.5.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv3 4/7] HSI CHAR: Add HSI char device driver
From: Andras Domokos andras.domo...@nokia.com
Add HSI char device driver to the kernel.
Signed-off-by: Andras Domokos andras.domo...@nokia.com
Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
---
drivers/hsi/clients/hsi_char.c | 1090
include/linux/hsi/hsi_char.h | 66 +++
2 files changed, 1156 insertions(+), 0 deletions(-)
create mode 100644 drivers/hsi/clients/hsi_char.c
create mode 100644 include/linux/hsi/hsi_char.h
diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
new file mode 100644
index 000..2d376a1
--- /dev/null
+++ b/drivers/hsi/clients/hsi_char.c
@@ -0,0 +1,1090 @@
+/*
+ * hsi-char.c
+ *
+ * HSI character device driver, implements the character device
+ * interface.
+ *
+ * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ *
+ * Contact: Andras Domokos andras.domo...@nokia.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/errno.h
+#include linux/types.h
+#include asm/atomic.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/poll.h
+#include linux/ioctl.h
+#include linux/wait.h
+#include linux/fs.h
+#include linux/sched.h
+#include linux/device.h
+#include linux/cdev.h
+#include linux/uaccess.h
+#include linux/scatterlist.h
+#include linux/hsi/hsi.h
+#include linux/hsi/hsi_char.h
+
+#define HSI_CHAR_CHANNELS 8
+#define HSI_CHAR_DEVS 8
+#define HSI_CHAR_MSGS 4
+
+#define HSI_CHST_UNAVAIL 0 /* SBZ! */
+#define HSI_CHST_AVAIL 1
+
+#define HSI_CHST_CLOSED(0 4)
+#define HSI_CHST_CLOSING (1 4)
+#define HSI_CHST_OPENING (2 4)
+#define HSI_CHST_OPENED(3 4)
+
+#define HSI_CHST_READOFF (0 8)
+#define HSI_CHST_READON(1 8)
+#define HSI_CHST_READING (2 8)
+
+#define HSI_CHST_WRITEOFF (0 12)
+#define HSI_CHST_WRITEON (1 12)
+#define HSI_CHST_WRITING (2 12)
+
+#define HSI_CHST_OC_MASK 0xf0
+#define HSI_CHST_RD_MASK 0xf00
+#define HSI_CHST_WR_MASK 0xf000
+
+#define HSI_CHST_OC(c) ((c)-state HSI_CHST_OC_MASK)
+#define HSI_CHST_RD(c) ((c)-state HSI_CHST_RD_MASK)
+#define HSI_CHST_WR(c) ((c)-state HSI_CHST_WR_MASK)
+
+#define HSI_CHST_OC_SET(c, v) \
+ do { \
+ (c)-state = ~HSI_CHST_OC_MASK; \
+ (c)-state |= v; \
+ } while (0);
+
+#define HSI_CHST_RD_SET(c, v) \
+ do { \
+ (c)-state = ~HSI_CHST_RD_MASK; \
+ (c)-state |= v; \
+ } while (0);
+
+#define HSI_CHST_WR_SET(c, v) \
+ do { \
+ (c)-state = ~HSI_CHST_WR_MASK; \
+ (c)-state |= v; \
+ } while (0);
+
+#define HSI_CHAR_POLL_RST (-1)
+#define HSI_CHAR_POLL_OFF 0
+#define HSI_CHAR_POLL_ON 1
+
+#define HSI_CHAR_RX0
+#define HSI_CHAR_TX1
+
+struct hsi_char_channel {
+ unsigned intch;
+ unsigned intstate;
+ int wlrefcnt;
+ int rxpoll;
+ struct hsi_client *cl;
+ struct list_headfree_msgs_list;
+ struct list_headrx_msgs_queue;
+ struct list_headtx_msgs_queue;
+ int poll_event;
+ spinlock_t lock;
+ struct fasync_struct*async_queue;
+ wait_queue_head_t rx_wait;
+ wait_queue_head_t tx_wait;
+};
+
+struct hsi_char_client_data {
+ atomic_trefcnt;
+ int attached;
+ atomic_tbreq;
+ struct hsi_char_channel channels[HSI_CHAR_DEVS];
+};
+
+static unsigned int max_data_size = 0x1000;
+module_param(max_data_size, uint, 1);
+MODULE_PARM_DESC(max_data_size, max read/write data size [4,8..65536] (^2));
+
+static int channels_map[HSI_CHAR_DEVS] = {0, -1, -1 , -1, -1, -1, -1, -1};
+module_param_array(channels_map, int, NULL, 0);
+MODULE_PARM_DESC(channels_map, Array of HSI channels ([0...7]) to be probed);
+
+static dev_t hsi_char_dev;
+static struct hsi_char_client_data hsi_char_cl_data;
+
+static inline void hsi_char_msg_free(struct hsi_msg *msg)
+{
+ msg-complete = NULL;
+ msg-destructor = NULL;
+ kfree(sg_virt(msg-sgt.sgl));
+
[RFC PATCHv3 5/7] HSI CHAR: Add HSI char device kernel configuration
From: Andras Domokos andras.domo...@nokia.com Add HSI character device kernel configuration Signed-off-by: Andras Domokos andras.domo...@nokia.com Signed-off-by: Carlos Chinea carlos.chi...@nokia.com --- drivers/hsi/Kconfig |1 + drivers/hsi/Makefile |2 +- drivers/hsi/clients/Kconfig | 13 + drivers/hsi/clients/Makefile |5 + include/linux/Kbuild |1 + include/linux/hsi/Kbuild |1 + 6 files changed, 22 insertions(+), 1 deletions(-) create mode 100644 drivers/hsi/clients/Kconfig create mode 100644 drivers/hsi/clients/Makefile create mode 100644 include/linux/hsi/Kbuild diff --git a/drivers/hsi/Kconfig b/drivers/hsi/Kconfig index 07987b6..94fc793 100644 --- a/drivers/hsi/Kconfig +++ b/drivers/hsi/Kconfig @@ -11,5 +11,6 @@ menuconfig HSI if HSI source drivers/hsi/controllers/Kconfig +source drivers/hsi/clients/Kconfig endif # HSI diff --git a/drivers/hsi/Makefile b/drivers/hsi/Makefile index d020ae1..ebc91b3 100644 --- a/drivers/hsi/Makefile +++ b/drivers/hsi/Makefile @@ -2,4 +2,4 @@ # Makefile for HSI # obj-$(CONFIG_HSI) += hsi.o -obj-y += controllers/ +obj-y += controllers/ clients/ diff --git a/drivers/hsi/clients/Kconfig b/drivers/hsi/clients/Kconfig new file mode 100644 index 000..3bacd27 --- /dev/null +++ b/drivers/hsi/clients/Kconfig @@ -0,0 +1,13 @@ +# +# HSI clients configuration +# + +comment HSI clients + +config HSI_CHAR + tristate HSI/SSI character driver + depends on HSI + ---help--- + If you say Y here, you will enable the HSI/SSI character driver. + This driver provides a simple character device interface for + serial communication with the cellular modem over HSI/SSI bus. diff --git a/drivers/hsi/clients/Makefile b/drivers/hsi/clients/Makefile new file mode 100644 index 000..327c0e2 --- /dev/null +++ b/drivers/hsi/clients/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for HSI clients +# + +obj-$(CONFIG_HSI_CHAR) += hsi_char.o diff --git a/include/linux/Kbuild b/include/linux/Kbuild index 626b629..24c35fc 100644 --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -2,6 +2,7 @@ header-y += byteorder/ header-y += can/ header-y += dvb/ header-y += hdlc/ +header-y += hsi/ header-y += isdn/ header-y += nfsd/ header-y += raid/ diff --git a/include/linux/hsi/Kbuild b/include/linux/hsi/Kbuild new file mode 100644 index 000..271a770 --- /dev/null +++ b/include/linux/hsi/Kbuild @@ -0,0 +1 @@ +header-y += hsi_char.h -- 1.5.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 17/17] dmtimer: remove OCP config code from plat-omap
Benoit,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti
Sent: Monday, October 11, 2010 2:58 PM
To: Cousson, Benoit
Cc: linux-omap@vger.kernel.org; Basak, Partha; Paul Walmsley; Kevin
Hilman; Tony Lindgren
Subject: RE: [PATCHv3 17/17] dmtimer: remove OCP config code from plat-
omap
Benoit,
-Original Message-
From: Cousson, Benoit
Sent: Monday, October 04, 2010 7:57 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Basak, Partha; Paul Walmsley; Kevin
Hilman; Tony Lindgren
Subject: Re: [PATCHv3 17/17] dmtimer: remove OCP config code from plat-
omap
On 9/21/2010 10:56 AM, DebBarma, Tarun Kanti wrote:
This patch removes the ocp config code from omap-plat
because they are supposed to be taken care of by the
hwmod framework. Specifically, following changes are
incorporated:
(1) setting of smart-idle and wakeup-enable is already
taken care in existing code and so they are simply removed
from plat-omap
(2) clockactivity configuration is not present in the present
hwmod database. Therefore this filed is initialized to '1' in
Typo.
Will take care!
respective database.
Could you explain why, the default setting is not working for the
timers?
Ok, I just moved the existing implementation from plat-omap to hwmod
database. I have not tested without this change.
Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com
Signed-off-by: Partha Basakp-bas...@ti.com
Cc: Cousson, Benoitb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
arch/arm/plat-omap/dmtimer.c | 11 ---
5 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-
omap2/omap_hwmod_2420_data.c
index fc761a5..25111bf 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -168,6 +168,7 @@ static struct omap_hwmod_class_sysconfig
omap2420_timer_sysc = {
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
SYSC_HAS_AUTOIDLE),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = 1, /* preserve fclk on idle */
In theory, this field is useless unless you add a flag:
SYSC_HAS_CLOCKACTIVITY.
So how is it working in your case?
I guess my testing with power was not done properly. I will check and
verify.
.sysc_fields=omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-
omap2/omap_hwmod_2430_data.c
index 2ac463f..93d5c3d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -174,6 +174,7 @@ static struct omap_hwmod_class_sysconfig
omap2430_timer_sysc = {
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
SYSC_HAS_AUTOIDLE),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = 1, /* preserve fclk on idle */
.sysc_fields=omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-
omap2/omap_hwmod_3xxx_data.c
index 1ce40e0..c64c95b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -147,6 +147,7 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_1ms_sysc = {
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET
|
SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = 1, /* preserve fclk on idle */
.sysc_fields=omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 9edc518..a816d30 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -538,6 +538,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_timer_1ms_sysc = {
SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
SYSS_MISSING),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = 1, /* preserve fclk on idle */
.sysc_fields=omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-
[PATCH 0/2] omap: enable iva2 iommu
Hi, It seems the migration to iommu is already merged (perhaps prematurely... can't get it working). So iva2 iommu needs to be enabled. Felipe Contreras (2): omap: iommu: make iva2 iommu selectable staging: tidspbridge: enable iva2 iommu arch/arm/mach-omap2/omap-iommu.c|2 +- arch/arm/plat-omap/Kconfig |3 +++ drivers/staging/tidspbridge/Kconfig |1 + 3 files changed, 5 insertions(+), 1 deletions(-) -- 1.7.3.1.2.g7fe2b -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap: iommu: make iva2 iommu selectable
From: Felipe Contreras felipe.contre...@nokia.com
It seems dsp-link will do this, and tidspbridge too at some point, but
right now it's not possible to select CONFIG_MPU_BRIDGE_IOMMU.
Cc: Fernando Guzman Lugo fernando.l...@ti.com
Cc: Yogesh Marathe yogesh_mara...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
arch/arm/plat-omap/Kconfig |3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..adc0904 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -35,7 +35,7 @@ static struct iommu_device omap3_devices[] = {
.clk_name = cam_ick,
},
},
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
+#if defined(CONFIG_OMAP_IOMMU_IVA2)
{
.base = 0x5d00,
.irq = 28,
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index e39a417..e0b41b6 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -109,6 +109,9 @@ config OMAP_IOMMU_DEBUG
Say N unless you know you need this.
+config OMAP_IOMMU_IVA2
+ bool
+
choice
prompt System timer
default OMAP_32K_TIMER if !ARCH_OMAP15XX
--
1.7.3.1.2.g7fe2b
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] staging: tidspbridge: enable iva2 iommu
Needed now that the migration to iommu is done. Cc: Fernando Guzman Lugo fernando.l...@ti.com Cc: Yogesh Marathe yogesh_mara...@ti.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/staging/tidspbridge/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig index ff64d46..05716ad 100644 --- a/drivers/staging/tidspbridge/Kconfig +++ b/drivers/staging/tidspbridge/Kconfig @@ -7,6 +7,7 @@ menuconfig TIDSPBRIDGE depends on ARCH_OMAP3 select OMAP_MBOX_FWK select OMAP_IOMMU + select OMAP_IOMMU_IVA2 help DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more attached DSPs. The GPP is considered the master or -- 1.7.3.1.2.g7fe2b -- To unsubscribe from this list: send the line unsubscribe 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: g_ether broken on musb
Hi, 2010/10/11 Grazvydas Ignotas nota...@gmail.com: hello, Reproduce the test with your setup script, no your 'ping' issue happened on my beagle B5. ok I've updated to next-20101008 (from next-20101006) and the network no longer works at all on fresh boot, it starts working only after replugging the cable. I think it's because patch usb: musb: gadget: Unmapping the dma buffer when switching to PIO mode was dropped, If the patch is not dropped, DMA will not be used to unload fifo for out ep, otherwise DMA will be used for out ep. which effectively disables DMA due to a bug in it, so it's probably DMA problems on my board. Here is my log: Yes, your issue may be related with ep1out Rx DMA, but I am not sure since the very important message between timestamp 39.256011 and 85.210693 is not provided by you, why not post all messages? So we can't know if there are any rx interrupts after requests are queued into ep1out queue, then don't know anything about the dma handling after rx interrupt comes. If possible, please provide all the debug message instead of just selecting part of them. Except for above, no other abnormal things wrt. musb are found from your log. http://notaz.gp2x.de/misc/pnd/linux_next_20101008_musb There is some lock backtrace in the log, but I don't think it's It is lockdep warning, which touches me too, nothing to do with your issue. related, as with Unmapping the dma buffer when switching to PIO mode patch network works, but I guess I lose DMA. I'm using omap2plus_defconfig with OMAP2 and OMAP4 disabled (otherwise did not boot for some reason), and musb, g_ether and earlyprintk enabled. 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: g_ether broken on musb
which effectively disables DMA due to a bug in it, so it's probably DMA problems on my board. Here is my log: Yes, your issue may be related with ep1out Rx DMA, but I am not sure since the very important message between timestamp 39.256011 and 85.210693 is not provided by you, why not post all messages? I did not remove any messages (only added annotation), there was simply no output. I suppose something wrong happens after [ 29.816711] txstate 286: ep2in old packet still ready , txcsr 2003 There should be an interrupt? If possible, please provide all the debug message instead of just selecting part of them. The log I posted is full, I do not get any more output. -- To unsubscribe from this list: send the line unsubscribe 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 3/3] staging: tidspbridge: remove memory consistency from TODO list
On Sunday 10 October 2010, Felipe Contreras wrote: The mempool area is not handled by the kernel any more. But tidspbridge still uses ioremap to set up the mapping for RAM, even though it now is outside of the kernel linar mapping. You should really only use ioremap on MMIO registers, nothing else. These registers are marked as __iomem pointers and can only be passed into functions that talk to the hardware like iowrite32 or writel, but not used like memory. Please have a look at sparse, which will warn about address space violations among other things. The tidspbridge driver is full of them, and you should fix the code that sparse warns about, which will also show you all the places where ioremap is used incorrectly. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: g_ether broken on musb
2010/10/11 Grazvydas Ignotas nota...@gmail.com: which effectively disables DMA due to a bug in it, so it's probably DMA problems on my board. Here is my log: Yes, your issue may be related with ep1out Rx DMA, but I am not sure since the very important message between timestamp 39.256011 and 85.210693 is not provided by you, why not post all messages? I did not remove any messages (only added annotation), there was simply no output. I suppose something wrong happens after If so, no any rx interrupt for ep1out comes after request is queued since musb_g_rx is not called from your log. There is two possibilities: - usb host does not send any packets to ep1out - packets has been sent from usb host to musb gadget, but omap3 is not notified by musb rx interrupt, or there is no musb rx interrupt. You can trace usb traffic in usb host to see if there are packets sent to ep1out, usbmon can do it for you, please see Documentation/usb/usbmon.txt for reference. If no packets are traced for ep1out, your problem is nothing to do with musb, and may should be related with usb host driver(usbnet?). [ 29.816711] txstate 286: ep2in old packet still ready , txcsr 2003 There should be an interrupt? No, the irq is for ep2in, but the problem is in ep1out now. And the only means old packet has not been sent out from ep2in. If possible, please provide all the debug message instead of just selecting part of them. The log I posted is full, I do not get any more output. If you are sure, it is OK. 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: [PATCH 3/3] staging: tidspbridge: remove memory consistency from TODO list
On Mon, Oct 11, 2010 at 1:40 PM, Arnd Bergmann a...@arndb.de wrote: On Sunday 10 October 2010, Felipe Contreras wrote: The mempool area is not handled by the kernel any more. But tidspbridge still uses ioremap to set up the mapping for RAM, even though it now is outside of the kernel linar mapping. Which is what ioremap() complained about, and how Russell King suggested to solve the issue. You should really only use ioremap on MMIO registers, nothing else. These registers are marked as __iomem pointers and can only be passed into functions that talk to the hardware like iowrite32 or writel, but not used like memory. From what I can see parts of this memory are also used for readl/writel. Please have a look at sparse, which will warn about address space violations among other things. The tidspbridge driver is full of them, and you should fix the code that sparse warns about, which will also show you all the places where ioremap is used incorrectly. In one of my branches I moved ioremap() to arch/arm/mach-omap2/dsp.c and if I use sparse there, it gives no warning. I would prefer to map the memory some other way and make it non-cacheable, but I don't know any other way. Then, if readl/writel are still needed, only ioremap() that area. And finally, and hopefully, do cache flushes instead of requiring consistent memory. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe 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: Hang on boot
On 11 October 2010 17:55, Ionut Nicu ionut.n...@mindbit.ro wrote: Hi, On Mon, 2010-10-11 at 14:09 +1100, John Garland wrote: Hi, Both the dspbridge and master branch of linux-omap seem to hang when trying to boot (i.e. no output) on a beagleboard C2. This is with the new omap2plus_defconfig (as opposed to the old omap3_defconfig). Is anybody else experiencing this or does anyone have any idea what could be causing this? Make sure you update your u-boot environment so that you have console=ttyO2,115200 in your kernel command line (btw, it's ttyO2, not tty02). It's been recently changed in the linux-omap tree (commit d6e284d). You'll probably also need to update your /etc/inittab. Cheers, Ionut. You're a champ, that was the problem. Cheers, John. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap: iommu: make iva2 iommu selectable
From: ext Felipe Contreras felipe.contre...@gmail.com
Subject: [PATCH 1/2] omap: iommu: make iva2 iommu selectable
Date: Mon, 11 Oct 2010 11:53:49 +0200
From: Felipe Contreras felipe.contre...@nokia.com
It seems dsp-link will do this, and tidspbridge too at some point, but
right now it's not possible to select CONFIG_MPU_BRIDGE_IOMMU.
Why does it have to be selectable?
Please Cc: linux-arm-ker...@lists.infradead.org too.
Cc: Fernando Guzman Lugo fernando.l...@ti.com
Cc: Yogesh Marathe yogesh_mara...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
arch/arm/plat-omap/Kconfig |3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c
b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..adc0904 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -35,7 +35,7 @@ static struct iommu_device omap3_devices[] = {
.clk_name = cam_ick,
},
},
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
+#if defined(CONFIG_OMAP_IOMMU_IVA2)
{
.base = 0x5d00,
.irq = 28,
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index e39a417..e0b41b6 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -109,6 +109,9 @@ config OMAP_IOMMU_DEBUG
Say N unless you know you need this.
+config OMAP_IOMMU_IVA2
+ bool
+
choice
prompt System timer
default OMAP_32K_TIMER if !ARCH_OMAP15XX
--
1.7.3.1.2.g7fe2b
--
To unsubscribe from this list: send the line unsubscribe 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: g_ether broken on musb
On Mon, Oct 11, 2010 at 1:53 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/10/11 Grazvydas Ignotas nota...@gmail.com: which effectively disables DMA due to a bug in it, so it's probably DMA problems on my board. Here is my log: Yes, your issue may be related with ep1out Rx DMA, but I am not sure since the very important message between timestamp 39.256011 and 85.210693 is not provided by you, why not post all messages? I did not remove any messages (only added annotation), there was simply no output. I suppose something wrong happens after If so, no any rx interrupt for ep1out comes after request is queued since musb_g_rx is not called from your log. There is two possibilities: - usb host does not send any packets to ep1out - packets has been sent from usb host to musb gadget, but omap3 is not notified by musb rx interrupt, or there is no musb rx interrupt. You can trace usb traffic in usb host to see if there are packets sent to ep1out, usbmon can do it for you, please see Documentation/usb/usbmon.txt for reference. If no packets are traced for ep1out, your problem is nothing to do with musb, and may should be related with usb host driver(usbnet?). ok here are usbmon logs, taken using same scenario: http://notaz.gp2x.de/misc/pnd/linux_next_20101008_usbmon and here is usbmon log when musb runs in PIO mode and ping works: http://notaz.gp2x.de/misc/pnd/linux_next_20101008_usbmon_nodma So maybe it's ep2in issue after all? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap: iommu: make iva2 iommu selectable
On Mon, Oct 11, 2010 at 3:28 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Felipe Contreras felipe.contre...@gmail.com Subject: [PATCH 1/2] omap: iommu: make iva2 iommu selectable Date: Mon, 11 Oct 2010 11:53:49 +0200 From: Felipe Contreras felipe.contre...@nokia.com It seems dsp-link will do this, and tidspbridge too at some point, but right now it's not possible to select CONFIG_MPU_BRIDGE_IOMMU. Why does it have to be selectable? You mean why is it desirable to turn it off? Right now there's a mess of tidspbridge branches, some work, some don't, some have migrated to iommu, some don't. In mainline all this, plus the status on dsp-link, should be irrelevant, a configuration solves all the issues. Once the iommu migration works (haven't managed to get it working myself), and it has been merged into mainline, then we can think about enabling it unconditionally. In the meantime, enabling unconditionally would break the tidspbridge that is in staging (mainline). Please Cc: linux-arm-ker...@lists.infradead.org too. Will do, after you reply the above. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe 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 3/3] staging: tidspbridge: remove memory consistency from TODO list
On Monday 11 October 2010, Felipe Contreras wrote:
On Mon, Oct 11, 2010 at 1:40 PM, Arnd Bergmann a...@arndb.de wrote:
On Sunday 10 October 2010, Felipe Contreras wrote:
The mempool area is not handled by the kernel any more.
But tidspbridge still uses ioremap to set up the mapping for RAM,
even though it now is outside of the kernel linar mapping.
Which is what ioremap() complained about, and how Russell King
suggested to solve the issue.
You are right that this is what Russell asked about, having a single
mapping for memory means that you avoid the problems that the warning
was put there for and you no longer risk memory corruption. That
is good and the changes you did are the important ones.
What I'm arguing is that you still don't use the interface in the
way it's designed and things might break again in the future.
For instance, I've seen platforms where readl/writel is not a pointer
dereference but a hypercall or goes through an indirect index/data
register pair. I hope we don't ever get something like this on ARM,
but it would still be good to write the code in a more robust way
that doesn't mix __iomem tokens with kernel pointers.
You should really only use ioremap on MMIO registers, nothing
else. These registers are marked as __iomem pointers and can only
be passed into functions that talk to the hardware like iowrite32
or writel, but not used like memory.
From what I can see parts of this memory are also used for readl/writel.
In that case, it's worse than I thought ;-)
If you use readl(), it needs to be an __iomem pointer, if you use it
by direct dereferences, it must not be __iomem.
Obviously, you need to use ioremap to target the device registers,
but I don't see how it could make sense for a communication area
in memory.
Please have a look at sparse, which will warn about address space
violations among other things. The tidspbridge driver is full of them,
and you should fix the code that sparse warns about, which will
also show you all the places where ioremap is used incorrectly.
In one of my branches I moved ioremap() to arch/arm/mach-omap2/dsp.c
and if I use sparse there, it gives no warning.
I don't see how moving the code around would get rid of an address
space warning, unless you play dirty tricks like using __force
casts or passing pointers around as integers.
I would prefer to map the memory some other way and make it
non-cacheable, but I don't know any other way. Then, if readl/writel
are still needed, only ioremap() that area. And finally, and
hopefully, do cache flushes instead of requiring consistent memory.
Yes, that sounds reasonable. Can you use a chunk of regular kernel
memory with dma_map_single/dma_sync_single_for_{cpu,device} for this,
like normal drivers do?
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 3/17] dmtimer: add omap2420 hwmod database
Benoit, Paul, Kevin,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti
Sent: Saturday, October 09, 2010 8:29 PM
To: Cousson, Benoit; Paul Walmsley
Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha; Kevin
Hilman; Tony Lindgren
Subject: RE: [PATCHv3 3/17] dmtimer: add omap2420 hwmod database
Benoit, Paul,
-Original Message-
From: Cousson, Benoit
Sent: Monday, October 04, 2010 1:20 PM
To: Paul Walmsley
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; Gopinath, Thara;
Basak, Partha; Kevin Hilman; Tony Lindgren
Subject: Re: [PATCHv3 3/17] dmtimer: add omap2420 hwmod database
Hi Paul,
On 10/2/2010 12:25 AM, Paul Walmsley wrote:
On Thu, 30 Sep 2010, Cousson, Benoit wrote:
On 9/21/2010 10:51 AM, DebBarma, Tarun Kanti wrote:
#include omap_hwmod_common_data.h
#include prm-regbits-24xx.h
@@ -121,6 +123,614 @@ static struct omap_hwmod
omap2420_l4_wkup_hwmod
= {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
.flags = HWMOD_NO_IDLEST,
};
+/* Timer Common */
+static char *timer_clk_src_names[] = {
+ sys_ck,
+ func_32k_ck,
+ alt_ck,
+ NULL,
+};
I have an issue with that, because this is a pure duplication of the
clock_sel
information already contained in the clock data:
static const struct clksel omap24xx_gpt_clksel[] = {
{ .parent =func_32k_ck, .rates = gpt_32k_rates },
{ .parent =sys_ck, .rates = gpt_sys_rates },
{ .parent =alt_ck, .rates = gpt_alt_rates },
{ .parent = NULL },
};
And duplicating the same information somewhere else is most of the
time
a bad
idea.
Yep, there's no way that info should be in the hwmod data, in the
current
setup. It belongs in the clkdev tables. Example below.
That being said... I don't really know how to handle that properly :-
)
We have to find a better way to select the proper source clock in a
soc
independent way.
Maybe Paul will have some idea?
Here's how it's done:
http://marc.info/?l=linux-omapm=128596931017785w=2
and
http://marc.info/?l=linux-omapm=128596931417805w=2
The famous clock alias... I don't know why but I always forgot that
solution each time I have such concern:-(
This is indeed the very clean and cool way to do that clock selection.
We can even remove this #define to identified them and use the clock
string name directly.
I will incorporate the suggestions. Thanks!!
In the present implementation there is inconsistency in the clock source names
for the different platforms, viz. OMAP2, OMAP3 and OMAP4 as shown below.
Therefore, I will have to modify the names so that they all have common name
across the platforms for the same type of clock. In this regard I am proposing
to modify the clock source names similar to OMAP4. Of course we also have to
look around to see if there are other modules who are using the clock and make
the necessary changes.
I would like to hear from you and get your inputs! Thanks.
-tarun
OMAP2430
static char *timer_clk_src_names[] = {
sys_ck,
func_32k_ck,
alt_ck,
NULL
};
OMAP3xxx
static char *timer_clk_src_names[] = {
sys_ck,
omap_32k_fck,
NULL,
};
OMAP4
static char *timer_clk_src_names[] = {
sys_clkin_ck,
sys_32k_ck,
NULL,
};
static char *timer_clk_src_names_abe[] = {
syc_clk_div_ck,
sys_32k_ck,
NULL,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 3/17] dmtimer: add omap2420 hwmod database
On Mon, 11 Oct 2010, DebBarma, Tarun Kanti wrote: In the present implementation there is inconsistency in the clock source names for the different platforms, viz. OMAP2, OMAP3 and OMAP4 as shown below. Therefore, I will have to modify the names so that they all have common name across the platforms for the same type of clock. In this regard I am proposing to modify the clock source names similar to OMAP4. Of course we also have to look around to see if there are other modules who are using the clock and make the necessary changes. Please look again at the links that I sent you. All you need to change are the clkdev alias names for those clocks for that particular platform device name, timer or whatever it will be called. That won't affect any other modules, since they will have different platform device names. The struct clk.name fields will stay the same. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7] power: introduce library for device-specific OPPs
Rafael J. Wysocki r...@sisk.pl writes:
On Friday, October 08, 2010, Nishanth Menon wrote:
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J Wysocki, Paul E McKenney for valuable
improvements.
Discussions and comments from:
http://marc.info/?l=linux-omapm=126033945313269w=2
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
http://marc.info/?l=linux-omapm=126025973426007w=2
http://marc.info/?t=128152609200064r=1w=2
http://marc.info/?t=12846872302r=1w=2
incorporated.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
Cc: Roberto Granados Dorado x0095...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Nishanth Menon n...@ti.com
OK
Your error messages are a bit inconsistent (e.g. some of them print the
error code while others don't), but I guess I can fix that up.
Still, to apply the patch I need a copyright notice for the doc too.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Kevin, your sign-off here means you endorse the patch as the maintainer.
Is that correct?
Correct.
Thanks,
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
Re: [PATCH] omap: serial: Fix the boot-up crash/reboot without CONFIG_PM
Santosh Shilimkar santosh.shilim...@ti.com writes: The omap2plus_defconfig doesn't boot up when built with CONFIG_PM disabled on the latest linux-omap master. Below are the observations 1. OMAP3 reboots in the middle of boot -- [0.00] Calibrating delay loop... 494.72 BogoMIPS (lpj=1933312) [0.00] pid_max: default: 32768 minimum: 301 [0.00] Security Framework initialized [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] Brought up 1 CPUs [0.00] SMP: Total of 1 processors activated (494.72 BogoMIPS). [0.00] regulator: core version 0.5 [0.00] NET: Registered protocol family 16 U-Boot 1.1.4 (Feb 11 2009 - 16:10:23) OMAP3430-GP rev 2, CPU-OPP2 L3-165MHz TI 3430SDP 1.0 Version + mDDR (Boot NOR) DRAM: 128 MB Flash: 128 MB NAND:128 MiB -- 2. OMAP4 does a kernel PANIC - [0.00] Calibrating delay loop... 1195.29 BogoMIPS (lpj=4669440) [0.00] pid_max: default: 32768 minimum: 301 [0.00] Security Framework initialized [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] L310 cache controller enabled [0.00] l2x0: 16 ways, CACHE_ID 0x41c2, AUX_CTRL 0x0e05 [0.00] CPU1: Booted secondary processor [0.00] Brought up 2 CPUs [0.00] SMP: Total of 2 processors activated (2395.78 BogoMIPS). [0.00] regulator: core version 0.5 [0.00] NET: Registered protocol family 16 [0.00] mux: Could not set signal i2c2_scl.i2c2_scl [0.00] mux: Could not set signal i2c2_sda.i2c2_sda [0.00] mux: Could not set signal i2c3_scl.i2c3_scl [0.00] mux: Could not set signal i2c3_sda.i2c3_sda [0.00] mux: Could not set signal i2c4_scl.i2c4_scl [0.00] mux: Could not set signal i2c4_sda.i2c4_sda - This is happening because 'omap_serial_init()' is hanging in the boot. On OMAP3 the watchdog is generating reboot because devices_init doesn't happens where as on OMAP4 it just hangs without reboot. The uart clock is not getting enabled after omap_device_idle as part of omap_serial_init. The omap_device_idle(will disable the clock) then omap_uart_block_sleep() should enable clock back disabled during the boot up phase. But omap_uart_block_sleep() stuffed version is binded only under CONFIG_PM and other version is just empty. Hence it is not enabling clock back as expected This patch adds uart clock enable code to omap_uart_block_sleep() function built with CONFIG_PM disabled. Thanks to Charulatha and Govindraj for their help on this debug. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com This is a regression fix, so we should queue this for 2.6.37. Thanks, 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
RE: [PATCH] tidspbridge: select OMAP_IOMMU dependency
Hi Ionut, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ionut Nicu Sent: Saturday, October 09, 2010 6:42 AM To: linux-omap@vger.kernel.org Cc: Ionut Nicu Subject: [PATCH] tidspbridge: select OMAP_IOMMU dependency Since the iommu migration patches tidspbridge depends on the OMAP specific IOMMU implementation. We need to add this dependency, otherwise we'll have link time errors. Patch already sent: http://marc.info/?l=linux-omapm=128632367005506w=2 Regards, Fernando Guzman. Signed-off-by: Ionut Nicu ionut.n...@mindbit.ro --- drivers/staging/tidspbridge/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig index 93de4f2..ff64d46 100644 --- a/drivers/staging/tidspbridge/Kconfig +++ b/drivers/staging/tidspbridge/Kconfig @@ -6,6 +6,7 @@ menuconfig TIDSPBRIDGE tristate DSP Bridge driver depends on ARCH_OMAP3 select OMAP_MBOX_FWK + select OMAP_IOMMU help DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more attached DSPs. The GPP is considered the master or -- 1.7.2.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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: tidspbridge compilation broken
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ionut Nicu Sent: Saturday, October 09, 2010 5:50 AM To: linux-omap@vger.kernel.org Subject: tidspbridge compilation broken Hi, I'm trying to compile the tidspbridge driver from the dspbridge branch of the linux-omap git tree and I stumbled upon a few compilation problems: 1. First is related to the missing header plat/dsp.h added by the following patch which was not applied to this branch: http://marc.info/?l=linux-omapm=128620861805925w=2 2. The second one is related to the missing header plat/control.h which was moved by a recent commit (81bb9b6) from plat to mach-omap2. The dspbridge driver requires a few defines from that header but as far as I understand, that header file is no longer supposed to be accessible by drivers. Any suggestion on how to fix that in dspbridge? This will be fixed soon, we are looking for the best solution. Regards, Fernando Guzman. 3. There's a link error triggered by the new iommu dependency. It's fairly trivial to fix. I will submit a patch for this. Thanks, Ionut. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7] power: introduce library for device-specific OPPs
Rafael J. Wysocki had written, on 10/09/2010 05:59 PM, the following: [...] Signed-off-by: Nishanth Menon n...@ti.com OK Your error messages are a bit inconsistent (e.g. some of them print the error code while others don't), but I guess I can fix that up. Thanks a bunch. Still, to apply the patch I need a copyright notice for the doc too. oops.. (C) 2009-2010 Nishanth Menon n...@ti.com, Texas Instruments Incorporated Does this help? or would you like me to post a v8 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: [PATCHv3 17/17] dmtimer: remove OCP config code from plat-omap
On 10/11/2010 11:41 AM, DebBarma, Tarun Kanti wrote: ... In summary, I will make following updates: .clockact = 0x2 SYSC_HAS_CLOCKACTIVITY flag should be included. After going through the code I realized that this flag is already there. I am not sure where you observed this flag missing? You're right, it was missing from the patch, but in fact already there in the code. Sorry on that one. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 00/11] staging tidspbridge: iommu migration
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Sunday, October 10, 2010 12:33 PM To: Guzman Lugo, Fernando Cc: gre...@suse.de; felipe.contre...@nokia.com; ameya.pala...@nokia.com; Menon, Nishanth; hiroshi.d...@nokia.com; o...@wizery.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCHv3 00/11] staging tidspbridge: iommu migration On Tue, Oct 5, 2010 at 11:35 PM, Fernando Guzman Lugo x0095...@ti.com wrote: This set of patches remove the dspbridge custom mmu implementation and use iommu module instead. I have tried this, it works for simple tests, but not real use-cases. I applied all your iommu patches. How did you test this? Have you applied: - scatterlist: define SG chain for arm architecture - iovmm: replace __iounmap with omap_iounmap - iovmm: add superpages support to fixed da address - iovmm: IVA2 MMU range is from 0x1100 to 0x - iovmm: no gap checking for fixed address Also make sure your baseline have this patch: - omap:iommu-load cam register before flushing the entry What kind of error are you getting? I don't have a complete framework to test MM testcases at this moment I did not stress test but a bridge level, and they were good, just some Mailbox issues beucase of the lack of some patches. So I was waiting All missing patches are merge in order to do more stressing testing because I think there is some race conditions in iommu module that need to be fixed. You can email me the case and erros you are facing privately and I will Check them, maybe it is because of missing patches. Regards, Fernando. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe 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/3] omap: dsp: fix ioremap() usage
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe
Contreras
Sent: Sunday, October 10, 2010 12:41 PM
To: linux-arm; linux-omap; Greg KH
Cc: Ramirez Luna, Omar; Russell King; Felipe Contreras
Subject: [PATCH 2/3] omap: dsp: fix ioremap() usage
On commit 309caa9 doing ioremap() became forbidden due tue
architectural limitations. Only a single mapping is allowed
now, so the mempool must not be part of the memory managed by
the kernel.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/common.c | 43
+++--
arch/arm/plat-omap/devices.c | 30 -
arch/arm/plat-omap/include/plat/common.h |3 +-
arch/arm/plat-omap/include/plat/dsp.h|6
4 files changed, 42 insertions(+), 40 deletions(-)
diff --git a/arch/arm/plat-omap/common.c
b/arch/arm/plat-omap/common.c index 57205a4..3fee3ca 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -37,7 +37,6 @@
#include plat/fpga.h
#include plat/serial.h
#include plat/vram.h
-#include plat/dsp.h
#include plat/clock.h
@@ -84,11 +83,49 @@ const void *omap_get_var_config(u16 tag,
size_t *len) } EXPORT_SYMBOL(omap_get_var_config);
-void __init omap_reserve(void)
+#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
+
+static phys_addr_t omap_dsp_mempool_base;
+
+static void __init omap_dsp_reserve_mem(struct meminfo *mi) {
+ phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
+ phys_addr_t addr = ~0;
+ int i;
+
+ if (!size)
+ return;
+
+ for (i = mi-nr_banks - 1; i = 0; i--)
+ if (mi-bank[i].size = size) {
+ mi-bank[i].size -= size;
+ addr = mi-bank[i].start + mi-bank[i].size;
+ break;
+ }
Missing {} in for lopp. Even tough you are checking for success inside
For loop why check again outside? And also not need to define addr.
What do you think about this:
static void __init omap_dsp_reserve_mem(struct meminfo *mi) {
phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
int i;
if (!size)
return;
for (i = mi-nr_banks - 1; i = 0; i--) {
if (mi-bank[i].size = size) {
mi-bank[i].size -= size;
omap_dsp_mempool_base =
mi-bank[i].start + mi-bank[i].size;
return;
}
}
pr_err(%s: failed to reserve 0x%x bytes\n, __func__, size);
}
Regards,
Fernando.
+
+ if (addr == ~0) {
+ pr_err(%s: failed to reserve 0x%x bytes\n,
+ __func__, size);
+ return;
+ }
+
+ omap_dsp_mempool_base = addr;
+}
+
+phys_addr_t omap_dsp_get_mempool_base(void) {
+ return omap_dsp_mempool_base;
+}
+EXPORT_SYMBOL(omap_dsp_get_mempool_base);
+#else
+static inline void omap_dsp_reserve_mem(struct meminfo *mi)
{ } #endif
+
+void __init omap_reserve(struct meminfo *mi)
{
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
- omap_dsp_reserve_sdram_memblock();
+ omap_dsp_reserve_mem(mi);
}
/*
diff --git a/arch/arm/plat-omap/devices.c
b/arch/arm/plat-omap/devices.c index 4c8f9b9..d1920be 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -15,7 +15,6 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
-#include linux/memblock.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -273,35 +272,6 @@ static void omap_init_wdt(void) static
inline void omap_init_wdt(void) {} #endif
-#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
-
-static phys_addr_t omap_dsp_phys_mempool_base;
-
-void __init omap_dsp_reserve_sdram_memblock(void)
-{
- phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
- phys_addr_t paddr;
-
- if (!size)
- return;
-
- paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_REAL_LIMIT);
- if (!paddr) {
- pr_err(%s: failed to reserve %x bytes\n,
- __func__, size);
- return;
- }
-
- omap_dsp_phys_mempool_base = paddr;
-}
-
-phys_addr_t omap_dsp_get_mempool_base(void) -{
- return omap_dsp_phys_mempool_base;
-}
-EXPORT_SYMBOL(omap_dsp_get_mempool_base);
-#endif
-
/*
* This gets called after board-specific INIT_MACHINE, and
initializes most
* on-chip peripherals accessible on this board (except for
few like USB):
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..3675492 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++
Re: g_ether broken on musb
2010/10/11 Grazvydas Ignotas nota...@gmail.com: On Mon, Oct 11, 2010 at 1:53 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/10/11 Grazvydas Ignotas nota...@gmail.com: which effectively disables DMA due to a bug in it, so it's probably DMA problems on my board. Here is my log: Yes, your issue may be related with ep1out Rx DMA, but I am not sure since the very important message between timestamp 39.256011 and 85.210693 is not provided by you, why not post all messages? I did not remove any messages (only added annotation), there was simply no output. I suppose something wrong happens after If so, no any rx interrupt for ep1out comes after request is queued since musb_g_rx is not called from your log. There is two possibilities: - usb host does not send any packets to ep1out - packets has been sent from usb host to musb gadget, but omap3 is not notified by musb rx interrupt, or there is no musb rx interrupt. You can trace usb traffic in usb host to see if there are packets sent to ep1out, usbmon can do it for you, please see Documentation/usb/usbmon.txt for reference. If no packets are traced for ep1out, your problem is nothing to do with musb, and may should be related with usb host driver(usbnet?). ok here are usbmon logs, taken using same scenario: http://notaz.gp2x.de/misc/pnd/linux_next_20101008_usbmon and here is usbmon log when musb runs in PIO mode and ping works: http://notaz.gp2x.de/misc/pnd/linux_next_20101008_usbmon_nodma So maybe it's ep2in issue after all? Yes, it is really with ep2in, and musb ep2in always return more data to host so cause overflow in host. I see what triggered your issue, please try the patch in the link below: http://marc.info/?l=linux-usbm=128576496614332w=2 -- 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: [PATCHv2 2/3] iovmm: add superpages support to fixed da address
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, October 10, 2010 10:22 AM
To: Guzman Lugo, Fernando
Cc: hiroshi.d...@nokia.com; david.co...@nokia.com;
felipe.contre...@nokia.com; ameya.pala...@nokia.com;
linux-ker...@vger.kernel.org; andy.shevche...@gmail.com;
linux-omap@vger.kernel.org
Subject: Re: [PATCHv2 2/3] iovmm: add superpages support to
fixed da address
On Tue, Oct 5, 2010 at 12:02 AM, Fernando Guzman Lugo
x0095...@ti.com wrote:
This patch adds superpages support to fixed ad address inside
iommu_kmap function.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/iovmm.c | 61
++-
1 files changed, 37 insertions(+), 24 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c
b/arch/arm/plat-omap/iovmm.c
index 34f0012..8006a19 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -87,27 +87,37 @@ static size_t sgtable_len(const struct sg_table
*sgt)
}
#define sgtable_ok(x) (!!sgtable_len(x))
+
+static unsigned max_alignment(u32 addr) {
+ int i;
+ unsigned pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
+ for (i = 0; i ARRAY_SIZE(pagesize) addr
(pagesize[i] -
+1); i++)
+ ;
+ return (i ARRAY_SIZE(pagesize)) ? pagesize[i] : 0; }
+
+
I don't think those extra spaces make sense.
Ok, it will be fixed.
/*
* calculate the optimal number sg elements from total
bytes based on
* iommu superpages
*/
-static unsigned int sgtable_nents(size_t bytes)
+static unsigned int sgtable_nents(size_t bytes, u32 da, u32 pa)
{
- int i;
- unsigned int nr_entries;
- const unsigned long pagesize[] = { SZ_16M, SZ_1M, SZ_64K,
SZ_4K, };
+ unsigned int nr_entries = 0, ent_sz;
How about s/unsigned int/unsigned/?
It is exactly the same, but not problem for me.
if (!IS_ALIGNED(bytes, PAGE_SIZE)) {
pr_err(%s: wrong size %08x\n, __func__, bytes);
return 0;
}
- nr_entries = 0;
- for (i = 0; i ARRAY_SIZE(pagesize); i++) {
- if (bytes = pagesize[i]) {
- nr_entries += (bytes / pagesize[i]);
- bytes %= pagesize[i];
- }
+ while (bytes) {
+ ent_sz = max_alignment(da | pa);
+ ent_sz = min(ent_sz, (unsigned)iopgsz_max(bytes));
+ nr_entries++;
+ da += ent_sz;
+ pa += ent_sz;
+ bytes -= ent_sz;
}
BUG_ON(bytes);
@@ -115,7 +125,8 @@ static unsigned int sgtable_nents(size_t bytes)
}
/* allocate and initialize sg_table header(a kind of
'superblock') */
-static struct sg_table *sgtable_alloc(const size_t bytes,
u32 flags)
+static struct sg_table *sgtable_alloc(const size_t bytes,
u32 flags,
+ u32 da, u32
+pa)
{
unsigned int nr_entries;
int err;
@@ -127,9 +138,8 @@ static struct sg_table
*sgtable_alloc(const size_t
bytes, u32 flags)
if (!IS_ALIGNED(bytes, PAGE_SIZE))
return ERR_PTR(-EINVAL);
- /* FIXME: IOVMF_DA_FIXED should support 'superpages' */
- if ((flags IOVMF_LINEAR) (flags IOVMF_DA_ANON)) {
- nr_entries = sgtable_nents(bytes);
+ if (flags IOVMF_LINEAR) {
+ nr_entries = sgtable_nents(bytes, da, pa);
if (!nr_entries)
return ERR_PTR(-EINVAL);
} else
@@ -409,7 +419,8 @@ static inline void sgtable_drain_vmalloc(struct
sg_table *sgt)
BUG_ON(!sgt);
}
-static void sgtable_fill_kmalloc(struct sg_table *sgt, u32
pa, size_t
len)
+static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, u32
+da,
+
size_t
+len)
{
unsigned int i;
struct scatterlist *sg;
@@ -420,7 +431,8 @@ static void sgtable_fill_kmalloc(struct
sg_table
*sgt, u32 pa, size_t len)
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
size_t bytes;
- bytes = iopgsz_max(len);
+ bytes = max_alignment(da | pa);
+ bytes = min(bytes, (size_t)iopgsz_max(len));
Why the size_t casting?
To void this warning:
arch/arm/plat-omap/iovmm.c:440: warning: comparison of distinct pointer types
lacks a cast
I will update with minor changes and resend.
Thanks and regards,
Fernando.
Otherwise:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/17] dmtimer: add omap2420 hwmod database
Hi Tarun, On 10/11/2010 4:19 PM, Paul Walmsley wrote: On Mon, 11 Oct 2010, DebBarma, Tarun Kanti wrote: In the present implementation there is inconsistency in the clock source names for the different platforms, viz. OMAP2, OMAP3 and OMAP4 as shown below. Therefore, I will have to modify the names so that they all have common name across the platforms for the same type of clock. In this regard I am proposing to modify the clock source names similar to OMAP4. Of course we also have to look around to see if there are other modules who are using the clock and make the necessary changes. Please look again at the links that I sent you. All you need to change are the clkdev alias names for those clocks for that particular platform device name, timer or whatever it will be called. That won't affect any other modules, since they will have different platform device names. The struct clk.name fields will stay the same. Otherwise using the clock source names similar to OMAP4 is the right thing to do. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] omap: iommu: make iva2 iommu selectable
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Monday, October 11, 2010 8:00 AM To: Hiroshi DOYU Cc: linux-omap@vger.kernel.org; g...@kroah.com; felipe.contre...@nokia.com; Guzman Lugo, Fernando; Marathe, Yogesh; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/2] omap: iommu: make iva2 iommu selectable On Mon, Oct 11, 2010 at 3:28 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Felipe Contreras felipe.contre...@gmail.com Subject: [PATCH 1/2] omap: iommu: make iva2 iommu selectable Date: Mon, 11 Oct 2010 11:53:49 +0200 From: Felipe Contreras felipe.contre...@nokia.com It seems dsp-link will do this, and tidspbridge too at some point, but right now it's not possible to select CONFIG_MPU_BRIDGE_IOMMU. Why does it have to be selectable? You mean why is it desirable to turn it off? Right now there's a mess of tidspbridge branches, some work, some don't, some have migrated to iommu, some don't. In mainline all this, plus the status on dsp-link, should be irrelevant, a configuration solves all the issues. Once the iommu migration works (haven't managed to get it working myself), and it has been merged into mainline, then we can think about enabling it unconditionally. In the meantime, enabling unconditionally would break the tidspbridge that is in staging (mainline). What is the problem enabling unconditionally? The iva2 iommu does not start working until you call iommu_get. So if for some reason you are using the dspbridge with custom Iommu implementation it should not cause any collision with Iommu module. Regards, Fernando. Please Cc: linux-arm-ker...@lists.infradead.org too. Will do, after you reply the above. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe 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] regulator: fix build when CONFIG_REGULATOR_DUMMY=n
Commit f03f91826 (regulator: Add option for machine drivers
to enable the dummy regulator) in the regulators tree
seems to have introduced the following build break when
CONFIG_REGULATOR_DUMMY is disabled. Fix this.
CC drivers/regulator/dummy.o
drivers/regulator/dummy.c:41: error: redefinition of 'regulator_dummy_init'
drivers/regulator/dummy.h:28: note: previous definition of
'regulator_dummy_init' was here
make[2]: *** [drivers/regulator/dummy.o] Error 1
make[1]: *** [drivers/regulator] Error 2
make: *** [drivers] Error 2
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
---
The commit referenced above is in linux next as of 20101011
and breaks builds of the omap2plus_defconfig at least.
drivers/regulator/dummy.h |4
1 file changed, 4 deletions(-)
Index: mainline/drivers/regulator/dummy.h
===
--- mainline.orig/drivers/regulator/dummy.h
+++ mainline/drivers/regulator/dummy.h
@@ -22,10 +22,6 @@ struct regulator_dev;
extern struct regulator_dev *dummy_regulator_rdev;
-#ifdef CONFIG_REGULATOR_DUMMY
void __init regulator_dummy_init(void);
-#else
-static inline void regulator_dummy_init(void) { }
-#endif
#endif
--
To unsubscribe from this list: send the line unsubscribe 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] regulator: fix build when CONFIG_REGULATOR_DUMMY=n
On Mon, 11 Oct 2010 22:05:55 +0530 Anand Gadiyar wrote:
Commit f03f91826 (regulator: Add option for machine drivers
to enable the dummy regulator) in the regulators tree
seems to have introduced the following build break when
CONFIG_REGULATOR_DUMMY is disabled. Fix this.
CC drivers/regulator/dummy.o
drivers/regulator/dummy.c:41: error: redefinition of 'regulator_dummy_init'
drivers/regulator/dummy.h:28: note: previous definition of
'regulator_dummy_init' was here
make[2]: *** [drivers/regulator/dummy.o] Error 1
make[1]: *** [drivers/regulator] Error 2
make: *** [drivers] Error 2
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
---
The commit referenced above is in linux next as of 20101011
and breaks builds of the omap2plus_defconfig at least.
drivers/regulator/dummy.h |4
1 file changed, 4 deletions(-)
Index: mainline/drivers/regulator/dummy.h
===
--- mainline.orig/drivers/regulator/dummy.h
+++ mainline/drivers/regulator/dummy.h
@@ -22,10 +22,6 @@ struct regulator_dev;
extern struct regulator_dev *dummy_regulator_rdev;
-#ifdef CONFIG_REGULATOR_DUMMY
void __init regulator_dummy_init(void);
-#else
-static inline void regulator_dummy_init(void) { }
-#endif
#endif
--
Acked-by: Randy Dunlap randy.dun...@oracle.com
Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH] PM: add synchronous runtime interface for interrupt handlers
On Sat, 9 Oct 2010, Rafael J. Wysocki wrote: I wonder if we can do the fast suspend and fast resume under the power.lock spinlock. That would allow us to avoid some complications related to RPM_RESUMING and RPM_SUSPENDING. Namely, if the device is flagged as power.irq_safe, it will always suspend and resume atomically under its power.lock spinlock. Then, the status will always be either RPM_ACTIVE or RPM_SUSPENDED (or RPM_ERROR, which is uninteresting). We could do this. It has some disadvantages but they aren't terrible. Also, if fast suspend doesn't change the device parent's power.child_count, we won't need to worry about parents any more. I don't know about that. If the parent's child_count doesn't change then the parent can never suspend. Of course, if there is no parent or the parent is disabled for runtime PM then this doesn't matter. I'm still not sure what to do with _idle() in that case. Clearly we should not hold the spinlock while running the runtime_idle callback. That would make it impossible for the callback to ask for a suspend. Alan Stern -- To unsubscribe from this list: send the line unsubscribe 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: PM: fix scratchpad memory accesses for off-mode
* Kevin Hilman khil...@deeprootsystems.com [101008 15:35]: Commit 914bab936fe0388a529079679e2f137aa4ff548d (OMAP: mach-omap2: Fix incorrect assignment warnings) changed a pointer from 'u32 *' to 'void *' without also fixing up the pointer arithmetic. Fix the scratchpad offsets so they are byte offsets instead of word offsets and thus work correctly with a void pointer base. Special thanks to Jean Pihet for taking the time track down this problem and propose an initial solution. Tested with off-idle and off-suspend on 36xx/Zoom3 and 34xx/omap3evm. Cc: G, Manjunath Kondaiah manj...@ti.com Reported-by: Jean Pihet jean.pi...@newoldbits.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- Tony, we need this queued for 2.6.37 as this is a regression fix. Thanks, adding to omap-for-linus. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ftrace - add ftrace function_graph support on ARM
On Mon, Oct 11, 2010 at 1:55 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: And now to go back to the original question I asked: What is __irq_entry used for? It's used to identify when we're inside the interrupt handling path. Depending upon the tracing options (funcgraph-irqs), this can be excluded from the trace output. If it's to identify those functions which can't be traced through because of the stack layout, that's true of all __exception marked functions - so we might as well make the linker symbols for irqentry alias the exception text symbols. I see nothing special of just the three functions you mention that warrant them being handled separately by ftrace. See above. The funcgraph-irqs option is supposed to only affect the interrupt handling path, not all exception handling. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo
* Tim Nordell tim.nord...@logicpd.com [101008 17:20]: Hi Stephan, I do indeed work for LogicPD. I was asked to take over the patch submission process from Jacob Tanenbaum from early August (I don't know if you saw those patches), and hence I was the last one to submit patches off to the community. On 10/08/10 18:55, Stephan Linz wrote: nice to see my patches here on the Linux mailinglists. I have not been working on it for a long time. Uhh, so whose patches are these originally? We have them now queued with Tim Nordell as the author. Please let me know ASAP if you want me to change that. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo
On 10/11/10 12:30, Tony Lindgren wrote: * Tim Nordell tim.nord...@logicpd.com [101008 17:20]: Hi Stephan, I do indeed work for LogicPD. I was asked to take over the patch submission process from Jacob Tanenbaum from early August (I don't know if you saw those patches), and hence I was the last one to submit patches off to the community. On 10/08/10 18:55, Stephan Linz wrote: nice to see my patches here on the Linux mailinglists. I have not been working on it for a long time. Uhh, so whose patches are these originally? We have them now queued with Tim Nordell as the author. Please let me know ASAP if you want me to change that. Regards, Tony The history for those patches, for me, originated with Jacob Tanenbaum's patchset. I was taking over for him as he was going back to school. I did some misc. changes for further submission, but I was not the original author. I don't know Stephan's involvement - however, in the source files he's attributed credit in the header, as well as one of my coworkers so presumably there was some involvement on both ends. I recognize some of the code as coming from our kernel release, so likely it was a hybrid originally between Stephan, Peter, and Jacob. That's about the extent that I know. - Tim -- To unsubscribe from this list: send the line unsubscribe 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: serial: Fix the boot-up crash/reboot without CONFIG_PM
* Kevin Hilman khil...@deeprootsystems.com [101011 07:37]: Santosh Shilimkar santosh.shilim...@ti.com writes: This is happening because 'omap_serial_init()' is hanging in the boot. On OMAP3 the watchdog is generating reboot because devices_init doesn't happens where as on OMAP4 it just hangs without reboot. The uart clock is not getting enabled after omap_device_idle as part of omap_serial_init. The omap_device_idle(will disable the clock) then omap_uart_block_sleep() should enable clock back disabled during the boot up phase. But omap_uart_block_sleep() stuffed version is binded only under CONFIG_PM and other version is just empty. Hence it is not enabling clock back as expected This patch adds uart clock enable code to omap_uart_block_sleep() function built with CONFIG_PM disabled. Thanks to Charulatha and Govindraj for their help on this debug. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com This is a regression fix, so we should queue this for 2.6.37. Thanks, adding to omap-for-linus. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo
On Mon, Oct 11, 2010 at 1:45 PM, Tim Nordell tim.nord...@logicpd.com wrote: On 10/11/10 12:30, Tony Lindgren wrote: Uhh, so whose patches are these originally? We have them now queued with Tim Nordell as the author. Please let me know ASAP if you want me to change that. Regards, Tony The history for those patches, for me, originated with Jacob Tanenbaum's patchset. I was taking over for him as he was going back to school. I did some misc. changes for further submission, but I was not the original author. I don't know Stephan's involvement - however, in the source files he's attributed credit in the header, as well as one of my coworkers so presumably there was some involvement on both ends. I recognize some of the code as coming from our kernel release, so likely it was a hybrid originally between Stephan, Peter, and Jacob. That's about the extent that I know. - Tim Tony, LogicPD engineers did the initial porting and then Stephan Linz re-started the work on the, then recent, 2.6.32 Kernel using our BSP as a starting point. He was kind enough to send those LogicPD and we began putting it together against the latest Linux Kernel for inclusion and that was done by Jacob over the summer and finished off by Tim. Stephan Linz is credited in the patch and Peter Barada (another LogicPD employee) is listed as the maintainer though his part (along with me) in getting these specific patches out have been more behind the scenes. So having the names listed as they are now is OK. In the upcoming months we will be pushing out additional support for the LogicPD's boards and it will most likely come up a variety of LogicPD engineers depending on our workload.. Thanks -- Ashwin -- To unsubscribe from this list: send the line unsubscribe 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: g_ether broken on musb
So maybe it's ep2in issue after all? Yes, it is really with ep2in, and musb ep2in always return more data to host so cause overflow in host. I see what triggered your issue, please try the patch in the link below: http://marc.info/?l=linux-usbm=128576496614332w=2 This has fixed my problem, thank you! -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: NAND: Fix static declaration warning
On Wed, 2010-10-06 at 03:26 +0530, G, Manjunath Kondaiah wrote: This patch fixes sparse warning for static declaration of variable use_dma drivers/mtd/nand/omap2.c:114:11: warning: symbol 'use_dma' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@lists.infradead.org Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com I've pushed this patch to my l2-mtd-2.6.git. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP2/3: NAND: Convert write/read functions to raw read/write
On Wed, 2010-10-06 at 03:26 +0530, G, Manjunath Kondaiah wrote: Following sparse warnings exists due to use of writel/w and readl/w functions. This patch fixes the sparse warnings by converting readl/w functions usage into __raw_readl/__raw_readw functions. drivers/mtd/nand/omap2.c:484:15: warning: symbol '__v' shadows an earlier one drivers/mtd/nand/omap2.c:484:15: originally declared here drivers/mtd/onenand/omap2.c:86:9: warning: symbol '__v' shadows an earlier one drivers/mtd/onenand/omap2.c:86:9: originally declared here Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@lists.infradead.org I've pushed this patch to my l2-mtd-2.6.git. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] omap: dsp: fix ioremap() usage
On Mon, Oct 11, 2010 at 6:15 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
+#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
+
+static phys_addr_t omap_dsp_mempool_base;
+
+static void __init omap_dsp_reserve_mem(struct meminfo *mi) {
+ phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
+ phys_addr_t addr = ~0;
+ int i;
+
+ if (!size)
+ return;
+
+ for (i = mi-nr_banks - 1; i = 0; i--)
+ if (mi-bank[i].size = size) {
+ mi-bank[i].size -= size;
+ addr = mi-bank[i].start + mi-bank[i].size;
+ break;
+ }
Missing {} in for lopp. Even tough you are checking for success inside
For loop why check again outside? And also not need to define addr.
What do you think about this:
It comes directly from Russell's code:
http://article.gmane.org/gmane.linux.kernel/1046606
But I do prefer to add the braces. Your proposed patch is ok, although
I prefer to have the important code at the end of the function, and
the error check before that.
Anyway, Russell has come with a different approach, so I have to try
that instead.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap: iommu: make iva2 iommu selectable
On Mon, Oct 11, 2010 at 6:54 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: Once the iommu migration works (haven't managed to get it working myself), and it has been merged into mainline, then we can think about enabling it unconditionally. In the meantime, enabling unconditionally would break the tidspbridge that is in staging (mainline). What is the problem enabling unconditionally? The iva2 iommu does not start working until you call iommu_get. So if for some reason you are using the dspbridge with custom Iommu implementation it should not cause any collision with Iommu module. Read the code below (omap_iommu_init), the resources are registered so nobody else can use them. This caused problems multiple times inside Nokia, which is what motivated to write the patch in the first place[1]. [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/58302/focus=58305 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: tidspbridge compilation broken
On Mon, 11 Oct 2010, Guzman Lugo, Fernando wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ionut Nicu Sent: Saturday, October 09, 2010 5:50 AM 2. The second one is related to the missing header plat/control.h which was moved by a recent commit (81bb9b6) from plat to mach-omap2. The dspbridge driver requires a few defines from that header but as far as I understand, that header file is no longer supposed to be accessible by drivers. Any suggestion on how to fix that in dspbridge? This will be fixed soon, we are looking for the best solution. Tony mentioned that you all needed some help with this. I would have converted DSPBridge as part of the original SCM patch, but since DSPBridge used __raw_writel() to write to the SCM rather than omap_ctrl_writel(), it didn't show up on my original grep. Anyway, following is a patch series to help you deal with this problem in the short term. It is unlikely to work as-is, since there doesn't appear to be any code in arch/arm/mach-omap2/* to populate the function pointers. You guys need to fix this - this is a defect in the original code. I suggest that you move your OMAP3430 hardware adaptation layer out of your core/tiomap3430.c into arch/arm/mach-omap2/, after rewriting it appropriately. For example, there shouldn't be any need to do any CM or PRM accesses. That should all be doable with clock/clockdomain/powerdomain/omap_device/omap_hwmod functions. Also, I hope you all are planning to do whatever it takes to move that driver out of staging as soon as possible. If further resources aren't invested on this driver to get it mainline-ready, then it's likely that someone will kick it out of staging at some point. Staging isn't really mainline. - Paul Paul Walmsley (3): OMAP: control: add functions for DSP boot address/mode control OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions DSPBridge: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns arch/arm/mach-omap2/control.c | 51 ++ arch/arm/mach-omap2/control.h | 16 +++--- arch/arm/mach-omap2/pm34xx.c |6 +- arch/arm/plat-omap/include/plat/iva2_dsp.h | 56 drivers/staging/tidspbridge/core/tiomap3430.c | 13 ++--- .../tidspbridge/include/dspbridge/host_os.h|4 ++ 6 files changed, 129 insertions(+), 17 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These
registers wound up in the System Control Module. Other kernel code
that wishes to control the DSP's boot process should now use these
functions to do so; subsequent patches implement this in the two
in-tree users of these functions.
This patch is functionally untested; that is for the DSP/Bridge
programmers to do.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/control.c | 51 ++
arch/arm/mach-omap2/control.h | 16 +---
arch/arm/plat-omap/include/plat/iva2_dsp.h | 56
3 files changed, 116 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..90fae36 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -209,6 +209,57 @@ void omap4_ctrl_pad_writel(u32 val, u16 offset)
__raw_writel(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+/*
+ * OMAP3 DSP control functions
+ */
+
+/**
+ * omap2430_ctrl_set_dsp_bootaddr - set the DSP's boot address
+ * @pa: DSP boot address (in physical memory)
+ *
+ * Set the DSP's boot address. This is an address in physical memory.
+ * No return value. XXX The TRM claims that this is an index to a
+ * 4kByte page. If so, why is the bitfield 21 bits wide, rather than
+ * 20?
+ */
+void omap2430_ctrl_set_dsp_bootaddr(u32 pa)
+{
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+ WARN(1, control: %s: not supported on this SoC\n, __func__);
+ return;
+ }
+
+ WARN(pa ~OMAP_CTRL_DSP_BOOTADDR_MASK,
+control: %s: invalid DSP boot address %08x\n, __func__, pa);
+
+ omap_ctrl_writel(pa, OMAP243X_CONTROL_IVA2_BOOTADDR);
+}
+
+/**
+ * omap2430_ctrl_set_dsp_bootmode - set the DSP's boot mode
+ * @mode: DSP boot mode (described below)
+ *
+ * Sets the DSP boot mode - see OMAP3 TRM revision ZH section 7.4.7.4
+ * IVA2.2 Boot Registers. Known values of @mode include 0, to boot
+ * directly to the address supplied by omap2_ctrl_set_dsp_bootaddr();
+ * 1, to boot to the DSP's ROM code and idle, waiting for interrupts;
+ * 2, to boot to the DSP's ROM code and spin in an idle loop; 3, to
+ * copy the user's bootstrap code from the DSP's internal memory and
+ * execute it (XXX how does the DSP know where to copy from?); and 4,
+ * to execute the DSP ROM code's context restore code. No return
+ * value.
+ */
+void omap2430_ctrl_set_dsp_bootmode(u8 mode)
+{
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+ WARN(1, control: %s: not supported on this SoC\n, __func__);
+ return;
+ }
+
+ omap_ctrl_writel(mode, OMAP243X_CONTROL_IVA2_BOOTMOD);
+}
+
+
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
/*
* Clears the scratchpad contents in case of cold boot-
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..ac14e0a 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -258,11 +258,6 @@
/* CONTROL_PROG_IO1 bits */
#define OMAP3630_PRG_SDMMC1_SPEEDCTRL (1 20)
-/* CONTROL_IVA2_BOOTMOD bits */
-#define OMAP3_IVA2_BOOTMOD_SHIFT 0
-#define OMAP3_IVA2_BOOTMOD_MASK(0xf 0)
-#define OMAP3_IVA2_BOOTMOD_IDLE(0x1 0)
-
/* CONTROL_PADCONF_X bits */
#define OMAP3_PADCONF_WAKEUPEVENT0 (1 15)
#define OMAP3_PADCONF_WAKEUPENABLE0(1 14)
@@ -280,7 +275,7 @@
#define AM35XX_CPGMAC_FCLK_SHIFT9
#define AM35XX_VPFE_FCLK_SHIFT 10
-/*AM35XX CONTROL_LVL_INTR_CLEAR bits*/
+/* AM35XX CONTROL_LVL_INTR_CLEAR bits */
#define AM35XX_CPGMAC_C0_MISC_PULSE_CLRBIT(0)
#define AM35XX_CPGMAC_C0_RX_PULSE_CLR BIT(1)
#define AM35XX_CPGMAC_C0_RX_THRESH_CLR BIT(2)
@@ -290,7 +285,7 @@
#define AM35XX_VPFE_CCDC_VD1_INT_CLR BIT(6)
#define AM35XX_VPFE_CCDC_VD2_INT_CLR BIT(7)
-/*AM35XX CONTROL_IP_SW_RESET bits*/
+/* AM35XX CONTROL_IP_SW_RESET bits */
#define AM35XX_USBOTGSS_SW_RST BIT(0)
#define AM35XX_CPGMACSS_SW_RST BIT(1)
#define AM35XX_VPFE_VBUSP_SW_RST BIT(2)
@@ -330,6 +325,10 @@
#defineFEAT_NEON 0
#defineFEAT_NEON_NONE 1
+/*
+ * DSP booting-related constants
+ */
+#define OMAP_CTRL_DSP_BOOTADDR_MASK0xfc00
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
@@ -351,6 +350,9 @@ extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control_restore_context(void);
+extern void omap2430_ctrl_set_dsp_bootaddr(u32 pa);
+extern void omap2430_ctrl_set_dsp_bootmode(u8 mode);
+
#else
#define omap_ctrl_base_get() 0
#define omap_ctrl_readb(x) 0
diff --git a/arch/arm/plat-omap/include/plat/iva2_dsp.h
b/arch/arm/plat-omap/include/plat/iva2_dsp.h
new file mode 100644
index
[PATCH 2/3] OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions
Update the DSP reset code in pm34xx.c to use one of the new SCM DSP
boot control functions, omap2430_ctrl_set_dsp_bootmode().
This reset code should be moved out to a separate function to be
called by the hwmod reset process at some point. Also, 2430
should be initializing the DSP in a similar fashion.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8c8f1ac..b90b1fb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -37,6 +37,7 @@
#include plat/prcm.h
#include plat/gpmc.h
#include plat/dma.h
+#include plat/iva2_dsp.h
#include asm/tlbflush.h
@@ -614,6 +615,7 @@ static struct platform_suspend_ops omap_pm_ops = {
* function forces the IVA2 into idle state so it can go
* into retention/off and thus allow full-chip retention/off.
*
+ * XXX This should be handled by the hwmod.
**/
static void __init omap3_iva_idle(void)
{
@@ -635,9 +637,7 @@ static void __init omap3_iva_idle(void)
cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK,
OMAP3430_IVA2_MOD, CM_FCLKEN);
- /* Set IVA2 boot mode to 'idle' */
- omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
-OMAP343X_CONTROL_IVA2_BOOTMOD);
+ omap2430_ctrl_set_dsp_bootmode(OMAP_IVA2_DSP_BOOTMODE_IDLE);
/* Un-reset IVA2 */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
--
To unsubscribe from this list: send the line unsubscribe 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 3/3] DSPBridge: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns
DSPBridge currently tries to __raw_writel() to the System Control
Module to control the DSP boot process. This is a layering violation;
this is SoC-specific code, and belongs in a file in
arch/arm/mach-omap2/*. None of those CM and PRM register accesses
through struct platform_data belong under drivers/. (Nor would they
belong in DSP platform init code in arch/arm/mach-omap2/* - such code
must use the clock, clockdomain, powerdomain, omap_device, and
omap_hwmod layers that are provided for this purpose.)
The immediate problem, however, is that after commit
346a5c890a55495c718394b74214be1de9303cf6, this code can no longer compile.
So to fix this immediate problem, convert the DSP boot control code to
use platform_data function pointers.
The DSPBridge-on-OMAP3 people also need to implement a file in
arch/arm/mach-omap2/ to populate the platform_data function pointers.
Such a file does not yet exist in the mainline tree, so it's unlikely
that DSPBridge is usable in the mainline until this is done.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: fernando.l...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 13 ++---
.../tidspbridge/include/dspbridge/host_os.h|4
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index f914829..3fd9551 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -21,7 +21,7 @@
#include dspbridge/host_os.h
#include linux/mm.h
#include linux/mmzone.h
-#include plat/control.h
+#include plat/iva2_dsp.h
/* --- DSP/BIOS Bridge */
#include dspbridge/dbdefs.h
@@ -374,6 +374,7 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
u32 clk_cmd;
struct io_mgr *hio_mgr;
u32 ul_load_monitor_timer;
+ u8 bootmode;
struct dspbridge_platform_data *pdata =
omap_dspbridge_dev-dev.platform_data;
@@ -415,15 +416,13 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
OMAP3430_RST1_IVA2_MASK,
OMAP3430_IVA2_MOD,
OMAP2_RM_RSTCTRL);
/* Mask address with 1K for compatibility */
- __raw_writel(dsp_addr OMAP3_IVA2_BOOTADDR_MASK,
- OMAP343X_CTRL_REGADDR(
- OMAP343X_CONTROL_IVA2_BOOTADDR));
+ dsp_addr = OMAP3_IVA2_BOOTADDR_MASK;
+ (*pdata-set_dsp_bootaddr)(dsp_addr);
/*
* Set bootmode to self loop if dsp_debug flag is true
*/
- __raw_writel((dsp_debug) ? OMAP3_IVA2_BOOTMOD_IDLE : 0,
- OMAP343X_CTRL_REGADDR(
- OMAP343X_CONTROL_IVA2_BOOTMOD));
+ bootmode = dsp_debug ? OMAP_IVA2_DSP_BOOTMODE_IDLE : 0;
+ (*pdata-set_dsp_bootmode)(bootmode);
}
}
if (!status) {
diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index 6b4feb4..a251fe4 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
@@ -59,7 +59,11 @@ struct dspbridge_platform_data {
unsigned long (*cpu_get_freq) (void);
unsigned long mpu_speed[6];
+ void (*set_dsp_bootaddr)(u32 pa);
+ void (*set_dsp_bootmode)(u8 mode);
+
/* functions to write and read PRCM registers */
+ /* XXX None of this should be here */
void (*dsp_prm_write)(u32, s16 , u16);
u32 (*dsp_prm_read)(s16 , u16);
u32 (*dsp_prm_rmw_bits)(u32, u32, s16, s16);
--
To unsubscribe from this list: send the line unsubscribe 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/3] OMAP: control: add functions for DSP boot address/mode control
On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley p...@pwsan.com wrote: Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These registers wound up in the System Control Module. Other kernel code that wishes to control the DSP's boot process should now use these functions to do so; subsequent patches implement this in the two in-tree users of these functions. This patch is functionally untested; that is for the DSP/Bridge programmers to do. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/control.c | 51 ++ arch/arm/mach-omap2/control.h | 16 +--- arch/arm/plat-omap/include/plat/iva2_dsp.h | 56 3 files changed, 116 insertions(+), 7 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h This doesn't seem to be aligned with staging-next, that's where tidspbridge is supposed to reside. I proposed this patch to be applied to linux-omap, but I guess it didn't seem necessary at the time: http://article.gmane.org/gmane.linux.kernel/1044209 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe 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/3] OMAP: control: add functions for DSP boot address/mode control
(adding Tony) On Mon, 11 Oct 2010, Felipe Contreras wrote: On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley p...@pwsan.com wrote: Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These registers wound up in the System Control Module. Other kernel code that wishes to control the DSP's boot process should now use these functions to do so; subsequent patches implement this in the two in-tree users of these functions. This patch is functionally untested; that is for the DSP/Bridge programmers to do. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/control.c | 51 ++ arch/arm/mach-omap2/control.h | 16 +--- arch/arm/plat-omap/include/plat/iva2_dsp.h | 56 3 files changed, 116 insertions(+), 7 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h This doesn't seem to be aligned with staging-next, that's where tidspbridge is supposed to reside. The patch series is based on Tony's current tree. It is not intended to be applied as-is. The series is meant for people working on DSPBridge to know what the expectations are of the OMAP maintainers, and also to give them a quick way forward to getting their code to compile again. I proposed this patch to be applied to linux-omap, but I guess it didn't seem necessary at the time: http://article.gmane.org/gmane.linux.kernel/1044209 I doubt that that's the reason, but you'd have to ask Tony about the details. But I'd NACK it due to the PRM/CM function pointers. As I mentioned in the previous messages, no driver should be touching PRM/CM bits directly. - Paul
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
* Paul Walmsley p...@pwsan.com [101011 13:45]: (adding Tony) On Mon, 11 Oct 2010, Felipe Contreras wrote: On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley p...@pwsan.com wrote: Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These registers wound up in the System Control Module. Other kernel code that wishes to control the DSP's boot process should now use these functions to do so; subsequent patches implement this in the two in-tree users of these functions. This patch is functionally untested; that is for the DSP/Bridge programmers to do. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/control.c | 51 ++ arch/arm/mach-omap2/control.h | 16 +--- arch/arm/plat-omap/include/plat/iva2_dsp.h | 56 3 files changed, 116 insertions(+), 7 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h This doesn't seem to be aligned with staging-next, that's where tidspbridge is supposed to reside. The patch series is based on Tony's current tree. It is not intended to be applied as-is. The series is meant for people working on DSPBridge to know what the expectations are of the OMAP maintainers, and also to give them a quick way forward to getting their code to compile again. This series seems like a sane way to sort out the dspbridge control register tinkering. I proposed this patch to be applied to linux-omap, but I guess it didn't seem necessary at the time: http://article.gmane.org/gmane.linux.kernel/1044209 I doubt that that's the reason, but you'd have to ask Tony about the details. But I'd NACK it due to the PRM/CM function pointers. As I mentioned in the previous messages, no driver should be touching PRM/CM bits directly. Hmm I acked that patch, but considering the above it should be updated according to Paul's comments. Would be nice to get the dspbridge into working shape. Sounds we still need the following: - memblock fixes - this series to fix the control module related issues - platform data for the boards Is that all, or are we also missing something else? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: fix build when CONFIG_REGULATOR_DUMMY=n
On Mon, 2010-10-11 at 22:05 +0530, Anand Gadiyar wrote:
Commit f03f91826 (regulator: Add option for machine drivers
to enable the dummy regulator) in the regulators tree
seems to have introduced the following build break when
CONFIG_REGULATOR_DUMMY is disabled. Fix this.
CC drivers/regulator/dummy.o
drivers/regulator/dummy.c:41: error: redefinition of 'regulator_dummy_init'
drivers/regulator/dummy.h:28: note: previous definition of
'regulator_dummy_init' was here
make[2]: *** [drivers/regulator/dummy.o] Error 1
make[1]: *** [drivers/regulator] Error 2
make: *** [drivers] Error 2
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
---
The commit referenced above is in linux next as of 20101011
and breaks builds of the omap2plus_defconfig at least.
drivers/regulator/dummy.h |4
1 file changed, 4 deletions(-)
Index: mainline/drivers/regulator/dummy.h
===
--- mainline.orig/drivers/regulator/dummy.h
+++ mainline/drivers/regulator/dummy.h
@@ -22,10 +22,6 @@ struct regulator_dev;
extern struct regulator_dev *dummy_regulator_rdev;
-#ifdef CONFIG_REGULATOR_DUMMY
void __init regulator_dummy_init(void);
-#else
-static inline void regulator_dummy_init(void) { }
-#endif
#endif
Applied.
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
To unsubscribe from this list: send the line unsubscribe 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/3] OMAP: control: add functions for DSP boot address/mode control
On Mon, 11 Oct 2010, Tony Lindgren wrote: Would be nice to get the dspbridge into working shape. Sounds we still need the following: - memblock fixes - this series to fix the control module related issues - platform data for the boards Is that all, or are we also missing something else? A few other things should be done also. 1. Most of the code in drivers/staging/tidspbridge/code/tiomap3430.c in the bridge_brd_monitor(), bridge_brd_start(), and bridge_brd_stop() should be moved into a file in arch/arm/mach-omap2. The DSPBridge driver should call those functions (to reset the DSP, start it, etc.) through platform_data function pointers. Once that happens, patch 3 of the control module-related series would not be needed, since that code would be in arch/arm/mach-omap2 anyway. 2. The direct CM/PRM/RM register access should be removed from that arch/arm/mach-omap2 code. That should be handled directly by the clock/hwmod/whatever code. 3. DSPBridge should be converted to use PM runtime, and the arch/arm/mach-omap2 portion should use omap_device, omap_hwmod, etc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7] power: introduce library for device-specific OPPs
On Monday, October 11, 2010, Nishanth Menon wrote: Rafael J. Wysocki had written, on 10/09/2010 05:59 PM, the following: [...] Signed-off-by: Nishanth Menon n...@ti.com OK Your error messages are a bit inconsistent (e.g. some of them print the error code while others don't), but I guess I can fix that up. Thanks a bunch. Still, to apply the patch I need a copyright notice for the doc too. oops.. (C) 2009-2010 Nishanth Menon n...@ti.com, Texas Instruments Incorporated Does this help? Yes, it does. or would you like me to post a v8 as well? That shouldn't be necessary. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe 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/3] OMAP: control: add functions for DSP boot address/mode control
On 10/11/2010 4:35 PM, Paul Walmsley wrote: On Mon, 11 Oct 2010, Tony Lindgren wrote: Would be nice to get the dspbridge into working shape. Sounds we still need the following: - memblock fixes - this series to fix the control module related issues - platform data for the boards Is that all, or are we also missing something else? A few other things should be done also. 1. Most of the code in drivers/staging/tidspbridge/code/tiomap3430.c in the bridge_brd_monitor(), bridge_brd_start(), and bridge_brd_stop() should be moved into a file in arch/arm/mach-omap2. The DSPBridge driver should call those functions (to reset the DSP, start it, etc.) through platform_data function pointers. Once that happens, patch 3 of the control module-related series would not be needed, since that code would be in arch/arm/mach-omap2 anyway. 2. The direct CM/PRM/RM register access should be removed from that arch/arm/mach-omap2 code. That should be handled directly by the clock/hwmod/whatever code. 3. DSPBridge should be converted to use PM runtime, and the arch/arm/mach-omap2 portion should use omap_device, omap_hwmod, etc. I was working on the 3rd point, but wanted to populate hmods for iommu and reuse the patches for hwmod mailbox too, before sending. Also some stuff needed: - iommu patches[2], this is under discussion, to get iommu + tidspbridge working. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
A few other items: On Mon, 11 Oct 2010, Paul Walmsley wrote: A few other things should be done also. 1. Most of the code in drivers/staging/tidspbridge/code/tiomap3430.c in the bridge_brd_monitor(), bridge_brd_start(), and bridge_brd_stop() should be moved into a file in arch/arm/mach-omap2. The DSPBridge driver should call those functions (to reset the DSP, start it, etc.) through platform_data function pointers. Once that happens, patch 3 of the control module-related series would not be needed, since that code would be in arch/arm/mach-omap2 anyway. This also includes some of the code from core/tiomap3430_pwr.c, such as handle_hibernation_from_dsp() and dsp_clk_wakeup_event_ctrl(). Basically, all of the other code that directly reads or writes registers outside the IVA2 directly needs to be moved into arch/arm/mach-omap2. 2. The direct CM/PRM/RM register access should be removed from that arch/arm/mach-omap2 code. That should be handled directly by the clock/hwmod/whatever code. 3. DSPBridge should be converted to use PM runtime, and the arch/arm/mach-omap2 portion should use omap_device, omap_hwmod, etc. 4. If the DSP uses a peripheral, such as a GPTIMER or a McBSP, DSPBridge needs to reserve that device with the rest of Linux so some other Linux code isn't using it or doesn't try to use it, causing conflicts with DSPBridge. I guess the list that we need to worry about is in _tiomap.h as l4_peripheral_table[]. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH] PM: add synchronous runtime interface for interrupt handlers
On Monday, October 11, 2010, Alan Stern wrote: On Sat, 9 Oct 2010, Rafael J. Wysocki wrote: I wonder if we can do the fast suspend and fast resume under the power.lock spinlock. That would allow us to avoid some complications related to RPM_RESUMING and RPM_SUSPENDING. Namely, if the device is flagged as power.irq_safe, it will always suspend and resume atomically under its power.lock spinlock. Then, the status will always be either RPM_ACTIVE or RPM_SUSPENDED (or RPM_ERROR, which is uninteresting). We could do this. It has some disadvantages but they aren't terrible. Also, if fast suspend doesn't change the device parent's power.child_count, we won't need to worry about parents any more. I don't know about that. If the parent's child_count doesn't change then the parent can never suspend. Of course, if there is no parent or the parent is disabled for runtime PM then this doesn't matter. I think the recursive resuming of the parents is inherently nonatomic and it shouldn't be done in the fast suspend/resume case. So, I think it might make sense to prevent the parent from ever suspending if children are supposed to use the fast ops. I'm still not sure what to do with _idle() in that case. Clearly we should not hold the spinlock while running the runtime_idle callback. That would make it impossible for the callback to ask for a suspend. That's correct. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe 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/3] OMAP: control: add functions for DSP boot address/mode control
On 10/11/2010 5:16 PM, Paul Walmsley wrote: 4. If the DSP uses a peripheral, such as a GPTIMER or a McBSP, DSPBridge needs to reserve that device with the rest of Linux so some other Linux code isn't using it or doesn't try to use it, causing conflicts with DSPBridge. I guess the list that we need to worry about is in _tiomap.h as l4_peripheral_table[]. this is done by using dmtimer fwk, mcbsp are also requested using mcbsp code (however I think functions to enable/disable mcbsp clocks should be added to mcbsp fwk)... There is no code (that I'm aware of) to control wdt3 nor ssi so this is still there. I still have to review the code to find any place were the registers are written directly though. The other peripherals, at the moment, doesn't have a direct interaction with bridge, although they might be interconnected to iva. I guess we can remove some of the mapped peripherals (like dsi, gpio, uart) and add them back on request and by implementing the code to request them on arm side. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database
Hi Tarun,
On 10/9/2010 5:40 PM, DebBarma, Tarun Kanti wrote:
Benoit,
From: Cousson, Benoit
Sent: Thursday, September 23, 2010 10:15 PM
To: Basak, Partha
Cc: Kevin Hilman; G, Manjunath Kondaiah; DebBarma, Tarun Kanti; linux-
o...@vger.kernel.org; Shilimkar, Santosh; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod
database
On 9/23/2010 11:34 AM, Basak, Partha wrote:
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 23, 2010 3:10 AM
G, Manjunath Kondaiahmanj...@ti.com writes:
Hi Tarun,
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
...
+static u32 omap_timer_reg_map_v1[] = {
+ [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_SYS_STAT_REG] = (0x14 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_STAT_REG] = (0x18 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_INT_EN_REG] = (0x1c | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_WAKEUP_EN_REG] = (0x20 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_CTRL_REG] = (0x24 | (WP_TCLR WPSHIFT)),
+ [OMAP_TIMER_COUNTER_REG]= (0x28 | (WP_TCRR WPSHIFT)),
+ [OMAP_TIMER_LOAD_REG] = (0x2c | (WP_TLDR WPSHIFT)),
+ [OMAP_TIMER_TRIGGER_REG]= (0x30 | (WP_TTGR WPSHIFT)),
+ [OMAP_TIMER_WRITE_PEND_REG] = (0x34 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_MATCH_REG] = (0x38 | (WP_TMAR WPSHIFT)),
+ [OMAP_TIMER_CAPTURE_REG]= (0x3c | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_IF_CTRL_REG]= (0x40 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_CAPTURE2_REG] = (0x44 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_TICK_POS_REG] = (0x48 | (WP_TPIR WPSHIFT)),
+ [OMAP_TIMER_TICK_NEG_REG] = (0x4c | (WP_TNIR WPSHIFT)),
+ [OMAP_TIMER_TICK_COUNT_REG] = (0x50 | (WP_TCVR WPSHIFT)),
+ [OMAP_TIMER_TICK_INT_MASK_SET_REG] = (0x54 |
(WP_TOCR WPSHIFT)),
+ [OMAP_TIMER_TICK_INT_MASK_COUNT_REG]= (0x58 |
(WP_TOWR WPSHIFT)),
+};
+
+/* OMAP4 timers register map */
+static u32 omap_timer_reg_map_v2[] = {
+ [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_SYS_STAT_REG] = (0x14 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_STAT_REG] = (0x28 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_INT_EN_REG] = (0x2c | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_WAKEUP_EN_REG] = (0x34 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_CTRL_REG] = (0x38 | (WP_TCLR WPSHIFT)),
+ [OMAP_TIMER_COUNTER_REG]= (0x3c | (WP_TCRR WPSHIFT)),
+ [OMAP_TIMER_LOAD_REG] = (0x40 | (WP_TLDR WPSHIFT)),
+ [OMAP_TIMER_TRIGGER_REG]= (0x44 | (WP_TTGR WPSHIFT)),
+ [OMAP_TIMER_WRITE_PEND_REG] = (0x48 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_MATCH_REG] = (0x4c | (WP_TMAR WPSHIFT)),
+ [OMAP_TIMER_CAPTURE_REG]= (0x50 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_IF_CTRL_REG]= (0x54 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_CAPTURE2_REG] = (0x58 | (WP_NONE WPSHIFT)),
+ [OMAP_TIMER_INT_CLR_REG]= (0x30 | (WP_NONE WPSHIFT)),
+};
+
Why not these defines in mach-omap2/dmtimer.c? since
register offsets are
same for omap2plus except omap4 which has additional
register offsets. Same
register offsets are getting repeated in all the omap2plus
hwmod database.
I agree with Manjunath.
Manju, the number of tables needed to manage the information are same
really.
Its only where they are located changes from the mach layer to the hwmod
database. So, thats not the point. dev_attrs are pointing to the reg-map
tables, they are not duplicating them.
The offset differences are stemming from the IP differences.
To my understanding, only IP-integration specific idiosyncrasies into a
given
SOC qualifiy as dev_attrs.
IP specific details like reg-map information should be maintained within
the driver.
So, this approach will break this paradigm also not follow existing
implementation
of drivers which support this. A given driver may support a set of IPs
but still
may cater to even non-OMAP platforms not supporting hwmod.
However, if we see the general usage of dev_attrs, there is no clear
line of demarcation
really what should make it and what should not, as is used to plug this
sort of
small gotchas and reduce CPU checks in the code.
You do not really need that to reduce the CPU check in the code.
In that case, only the IP version should be stored in the dev_attr.
Based on that IP version, you know exactly what register map you have to
handle. For the moment you just have 2 layouts to handle + the extra
register for the 1ms timers.
Also, I'm not sure that you have to handle each register separately
considering that you have one offset to handle for the functional
register.
The change in sysconfig and interrupt register
RE: [PATCH v3] TWL IRQ: Fix fucntion declaration warnings
Hi Samuel, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah Sent: Wednesday, October 06, 2010 3:27 AM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; Samuel Ortiz; Tony Lindgren; Menon, Nishanth Subject: [PATCH v3] TWL IRQ: Fix fucntion declaration warnings Fixes following sparse warnings for twl4030 and twl6030 irq files. If there are no further comments, can you please push this patch? -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database
Benoit,
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, October 12, 2010 4:42 AM
To: DebBarma, Tarun Kanti
Cc: Basak, Partha; Kevin Hilman; G, Manjunath Kondaiah; linux-
o...@vger.kernel.org; Shilimkar, Santosh; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod
database
Hi Tarun,
On 10/9/2010 5:40 PM, DebBarma, Tarun Kanti wrote:
Benoit,
From: Cousson, Benoit
Sent: Thursday, September 23, 2010 10:15 PM
To: Basak, Partha
Cc: Kevin Hilman; G, Manjunath Kondaiah; DebBarma, Tarun Kanti; linux-
o...@vger.kernel.org; Shilimkar, Santosh; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod
database
On 9/23/2010 11:34 AM, Basak, Partha wrote:
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 23, 2010 3:10 AM
G, Manjunath Kondaiahmanj...@ti.com writes:
Hi Tarun,
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
...
+static u32 omap_timer_reg_map_v1[] = {
+ [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_SYS_STAT_REG] = (0x14 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_STAT_REG] = (0x18 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_INT_EN_REG] = (0x1c | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_WAKEUP_EN_REG] = (0x20 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_CTRL_REG] = (0x24 | (WP_TCLR
WPSHIFT)),
+ [OMAP_TIMER_COUNTER_REG]= (0x28 | (WP_TCRR
WPSHIFT)),
+ [OMAP_TIMER_LOAD_REG] = (0x2c | (WP_TLDR
WPSHIFT)),
+ [OMAP_TIMER_TRIGGER_REG]= (0x30 | (WP_TTGR
WPSHIFT)),
+ [OMAP_TIMER_WRITE_PEND_REG] = (0x34 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_MATCH_REG] = (0x38 | (WP_TMAR
WPSHIFT)),
+ [OMAP_TIMER_CAPTURE_REG]= (0x3c | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_IF_CTRL_REG]= (0x40 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_CAPTURE2_REG] = (0x44 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_TICK_POS_REG] = (0x48 | (WP_TPIR
WPSHIFT)),
+ [OMAP_TIMER_TICK_NEG_REG] = (0x4c | (WP_TNIR
WPSHIFT)),
+ [OMAP_TIMER_TICK_COUNT_REG] = (0x50 | (WP_TCVR
WPSHIFT)),
+ [OMAP_TIMER_TICK_INT_MASK_SET_REG] = (0x54 |
(WP_TOCR WPSHIFT)),
+ [OMAP_TIMER_TICK_INT_MASK_COUNT_REG]= (0x58 |
(WP_TOWR WPSHIFT)),
+};
+
+/* OMAP4 timers register map */
+static u32 omap_timer_reg_map_v2[] = {
+ [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_SYS_STAT_REG] = (0x14 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_STAT_REG] = (0x28 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_INT_EN_REG] = (0x2c | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_WAKEUP_EN_REG] = (0x34 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_CTRL_REG] = (0x38 | (WP_TCLR
WPSHIFT)),
+ [OMAP_TIMER_COUNTER_REG]= (0x3c | (WP_TCRR
WPSHIFT)),
+ [OMAP_TIMER_LOAD_REG] = (0x40 | (WP_TLDR
WPSHIFT)),
+ [OMAP_TIMER_TRIGGER_REG]= (0x44 | (WP_TTGR
WPSHIFT)),
+ [OMAP_TIMER_WRITE_PEND_REG] = (0x48 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_MATCH_REG] = (0x4c | (WP_TMAR
WPSHIFT)),
+ [OMAP_TIMER_CAPTURE_REG]= (0x50 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_IF_CTRL_REG]= (0x54 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_CAPTURE2_REG] = (0x58 | (WP_NONE
WPSHIFT)),
+ [OMAP_TIMER_INT_CLR_REG]= (0x30 | (WP_NONE
WPSHIFT)),
+};
+
Why not these defines in mach-omap2/dmtimer.c? since
register offsets are
same for omap2plus except omap4 which has additional
register offsets. Same
register offsets are getting repeated in all the omap2plus
hwmod database.
I agree with Manjunath.
Manju, the number of tables needed to manage the information are same
really.
Its only where they are located changes from the mach layer to the
hwmod
database. So, thats not the point. dev_attrs are pointing to the reg-
map
tables, they are not duplicating them.
The offset differences are stemming from the IP differences.
To my understanding, only IP-integration specific idiosyncrasies into
a
given
SOC qualifiy as dev_attrs.
IP specific details like reg-map information should be maintained
within
the driver.
So, this approach will break this paradigm also not follow existing
implementation
of drivers which support this. A given driver may support a set of IPs
but still
may cater to even non-OMAP platforms not supporting hwmod.
However, if we see the general usage of dev_attrs, there is no clear
line of demarcation
really what should make it and what should not, as is used to plug
this
sort of
small gotchas and reduce CPU checks in the code.
You do
