Re: [REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
2010/12/13 Tony Lindgren t...@atomide.com: * Enric Balletbò i Serra eballe...@gmail.com [101213 08:47]: Tony, please can this patch be included before 2.6.37 ? Without this patch the wifi module on IGEP v2 board not works. Sorry it's too much for the -rc series. For the -rc series the fixes should be major bugs. This is in the category it never worked before. I will add it to omap-boards branch for the next merge window over the next few days while going through all the pending patches in patchwork. Ok, I'll wait :-) thanks Cheers, Enric -- 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: clean up ASM idle code
Kevin,
On Tue, Dec 14, 2010 at 5:12 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Clean up of the ASM code:
- reorganized the code in logical sections: defines, API
functions, internal functions and variables,
- reworked and simplified the execution paths, for better
readability and to avoid duplication of code,
- added comments on the entry and exit points,
- reworked the existing comments for better readability,
- reworked the code formating, alignment and white spaces,
- added comments for the i443 erratum workarounds,
- changed the hardcoded values in favor of existing macros
from include files,
- clean up of non used symbols.
The 'lock_scratchpad_sem' code is also unused. IIRC, you removed that
in an earlier version of the series. Are you still planning to remove
that? maybe in a subsequent patch?
I asked previously about it and the reply was that this code is
needed: (quoting Vishwa's reply) This is indeed used during DVFS when
Core DPLL configuration is changed. Note: the DVFS code is not
upstreamed yet.
Vishwa, can you confirm?
That being said, pure whitespace changes and unused code removal should
probably be a separate patch. It's a great help to reviewers if
functional changes are separated from whitespace changes. It's a bit
tricky in this series as there's lots of code moving as well, so I'll
leave it up to your judgement on how/if to separate these out.
There is no functional change at all. The code has been reorganized
for better readability.
I agree the patch is not easy to read but that is the way diff reports
the changes.
I do not see the point to provide separate patches for code move,
white space clean-up, alignment fixes etc.
Tested on OMAP3EVM and Beagleboard with full RET and OFF modes.
In idle? in suspend? both? was CPUidle enabled?
FWIW, I tested on 3430-ES3.1/n900 with retention idle suspend and off
idle suspend with CPUidle enabled.
Tested with cpuidle and suspend. I will update the description.
Heavily reworked from Vishwa's original patch.
Here, it's more customary to say Based on original patch from Vishwa
and ensure the original author is CC'd (which you've done.)
Other than that, this is a great cleanup, and makes this much more
readable. Thanks.
Some other minor comments below.
OK thanks for the review. I will post a new version asap.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
---
Applies on top of Nishant's latest idle path errata fixes step 2,
cf. http://marc.info/?l=linux-omapm=129139584919242w=2
[...]
@@ -208,36 +172,153 @@ api_params:
ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
+
+/* ==
+ * == Idle entry point ==
+ * ==
+ */
Let's keep C multi-line coding style even for assembly. Same goes for
several other places below.
Ok
/*
* Forces OMAP into idle state
*
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
+ * omap34xx_suspend() - This bit of code saves the CPU context if needed
+ * and executes the WFI instruction
+ *
+ * Note: This code get's copied to internal SRAM at boot.
*
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- * wakes up it continues execution at the point it went to sleep.
+ * Note: When the OMAP wakes up it continues at different execution points,
+ * depending on the low power mode (non-OFF vs OFF modes),
+ * cf. 'Resume path for xxx mode' comments.
*/
ENTRY(omap34xx_cpu_suspend)
stmfd sp!, {r0-r12, lr} @ save registers on stack
loop:
/*b loop*/ �...@enable to debug by stepping through code
While here, let's get rid of these infinite loop hacks for debugging as
anyone debugging this code can add these back as needed. Otherwise,
they clutter the code. There are a few of theses throughout the
original code.
Ok. Agree those are not used at all (even when doing heavy debugging).
[...]
@@ -250,9 +331,28 @@ loop:
nop
bl wait_sdrc_ok
- ldmfd sp!, {r0-r12, pc} @ restore regs and return
+/* ===
+ * == Exit point from non-OFF modes ==
+ * ===
+ */
+ ldmfd sp!, {r0-r12, pc} @ restore regs and return
+
+
+/* ==
+ * == Resume path for OFF mode ==
+ * ==
+ */
I don't think this is quite correct. I don't believe it starts
immediately here. Doesn't it resume from DDR first, and then jump
here. A brief description of that process would help clarify that process.
This is the restore point from OFF mode. The ROM code calls this
directly, cf. the get_pointer* functions that are used to get the
resume pointer.
I will update the comment.
+/*
+ * The restore_* functions
[RFC PATCHv4 0/7] HSI framework and drivers
Hi ! Here you have the fourth 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 added/fixed: - Address some comments from Tony Lindgren and Peter Henn. - Add module support to the HSI framework. - Fix sparse warnings in OMAP SSI driver. - Fix module license. - Remove spurious udev events generated by the HSI framework. - Avoid removal of a controller claimed by a client. - Fix hsi_char client device removal. TODO: - Move OMAP SSI to use omap hwmod I would very glad to continue getting feedback about this proposal. This patch series is based on 2.6.37-rc1. Version 3 of the patch set: https://lkml.org/lkml/2010/10/11/60 Note: checkpatch reports a false positive on patch 1/7. Andras Domokos (3): HSI: hsi_char: Add HSI char device driver HSI: hsi_char: Add HSI char device kernel configuration HSI: hsi_char: Update ioctl-number.txt Carlos Chinea (4): HSI: hsi: Introducing HSI framework HSI: omap_ssi: Introducing OMAP SSI driver HSI: 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 |2 + arch/arm/mach-omap2/ssi.c | 134 +++ arch/arm/plat-omap/include/plat/ssi.h | 204 drivers/Kconfig |2 + drivers/Makefile |1 + drivers/hsi/Kconfig | 20 + drivers/hsi/Makefile |6 + drivers/hsi/clients/Kconfig | 13 + drivers/hsi/clients/Makefile |5 + drivers/hsi/clients/hsi_char.c| 1094 + drivers/hsi/controllers/Kconfig | 23 + drivers/hsi/controllers/Makefile |5 + drivers/hsi/controllers/omap_ssi.c| 1853 + drivers/hsi/hsi.c | 496 drivers/hsi/hsi_boardinfo.c | 64 + drivers/hsi/hsi_core.h| 37 + include/linux/Kbuild |1 + include/linux/hsi/Kbuild |1 + include/linux/hsi/hsi.h | 389 ++ include/linux/hsi/hsi_char.h | 65 + 22 files changed, 4433 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 drivers/hsi/hsi_boardinfo.c create mode 100644 drivers/hsi/hsi_core.h 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 PATCHv4 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 22edcbb..877028a 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -433,4 +433,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.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv4 7/7] HSI: 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 63ffd78..955bf5e 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.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv4 4/7] HSI: 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 | 1094
include/linux/hsi/hsi_char.h | 65 +++
2 files changed, 1159 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..19aeb24
--- /dev/null
+++ b/drivers/hsi/clients/hsi_char.c
@@ -0,0 +1,1094 @@
+/*
+ * 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 PATCHv4 5/7] HSI: 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 bba73ea..2c76de4 100644 --- a/drivers/hsi/Kconfig +++ b/drivers/hsi/Kconfig @@ -15,5 +15,6 @@ config HSI_BOARDINFO default y source drivers/hsi/controllers/Kconfig +source drivers/hsi/clients/Kconfig endif # HSI diff --git a/drivers/hsi/Makefile b/drivers/hsi/Makefile index 0de87bd..d47ca5d 100644 --- a/drivers/hsi/Makefile +++ b/drivers/hsi/Makefile @@ -3,4 +3,4 @@ # obj-$(CONFIG_HSI_BOARDINFO)+= hsi_boardinfo.o 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 97319a8..b1eafe6 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.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv4 3/7] HSI: 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 |2 ++ drivers/hsi/Kconfig |2 ++ drivers/hsi/Makefile |1 + drivers/hsi/controllers/Kconfig | 23 +++ drivers/hsi/controllers/Makefile |5 + 5 files changed, 33 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 b0810b9..1a1c0d9 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -111,6 +111,8 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) ifneq ($(CONFIG_TIDSPBRIDGE),) obj-y += dsp.o endif +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 diff --git a/drivers/hsi/Kconfig b/drivers/hsi/Kconfig index 937062e..bba73ea 100644 --- a/drivers/hsi/Kconfig +++ b/drivers/hsi/Kconfig @@ -14,4 +14,6 @@ config HSI_BOARDINFO bool default y +source drivers/hsi/controllers/Kconfig + endif # HSI diff --git a/drivers/hsi/Makefile b/drivers/hsi/Makefile index ed94a3a..0de87bd 100644 --- a/drivers/hsi/Makefile +++ b/drivers/hsi/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_HSI_BOARDINFO)+= hsi_boardinfo.o 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..3efe0f0 --- /dev/null +++ b/drivers/hsi/controllers/Kconfig @@ -0,0 +1,23 @@ +# +# HSI controllers configuration +# +comment HSI controllers + +config OMAP_SSI + tristate OMAP SSI hardware driver + depends on ARCH_OMAP HSI + default n + ---help--- + SSI is a legacy version of HSI. It is usually used to connect + an application engine with a cellular modem. + 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.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv4 1/7] HSI: 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 | 17 ++
drivers/hsi/Makefile|5 +
drivers/hsi/hsi.c | 496 +++
drivers/hsi/hsi_boardinfo.c | 64 ++
drivers/hsi/hsi_core.h | 37
include/linux/hsi/hsi.h | 389 +
8 files changed, 1011 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 drivers/hsi/hsi_boardinfo.c
create mode 100644 drivers/hsi/hsi_core.h
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 dabaabc..5f9d0da 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-y += 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..937062e
--- /dev/null
+++ b/drivers/hsi/Kconfig
@@ -0,0 +1,17 @@
+#
+# HSI driver configuration
+#
+menuconfig HSI
+ tristate HSI support
+ ---help---
+ The High speed synchronous Serial Interface is
+ synchronous serial interface used mainly to connect
+ application engines and cellular modems.
+
+if HSI
+
+config HSI_BOARDINFO
+ bool
+ default y
+
+endif # HSI
diff --git a/drivers/hsi/Makefile b/drivers/hsi/Makefile
new file mode 100644
index 000..ed94a3a
--- /dev/null
+++ b/drivers/hsi/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for HSI
+#
+obj-$(CONFIG_HSI_BOARDINFO)+= hsi_boardinfo.o
+obj-$(CONFIG_HSI) += hsi.o
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
new file mode 100644
index 000..06b5743
--- /dev/null
+++ b/drivers/hsi/hsi.c
@@ -0,0 +1,496 @@
+/*
+ * 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
+#include hsi_core.h
+
+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)
+{
+ if (dev-type == hsi_cl)
+ 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
Re: Fwd: possible errors in linux omap display headers - who would be a good person to contact?
Hi, On Mon, 2010-12-13 at 15:26 -0500, ext Chethan Pandarinath wrote: Hi Tomi, I sent the below email to the angstrom linux development listserv. Based on the Maintainers list from git.kernel.org, you seem like the right person to contact about this. Would you be able to discuss this with me? Thanks. Chethan -- Forwarded message -- From: Chethan Pandarinath chethan.pandarin...@gmail.com Date: Mon, Dec 13, 2010 at 2:34 PM Subject: possible errors in linux omap display headers - who would be a good person to contact? To: angstrom-distro-devel angstrom-distro-de...@linuxtogo.org Hi everybody, this may not be the right place to ask this question, but I don't really know who to address it to, so maybe someone here can point me in the right direction. I have been working on setting up a video framebuffer and writing to it on an OMAP 3530 device (TI beagleboard). It appears that the definitions in drivers/video/omap/omapfb.h are incorrect (possibly out of date?), which caused a lot of confusion while trying to set up my framebuffer. Specifically, I'm trying to set the properties of my framebuffer, using the ioctl command, FBIOPUT_VSCREENINFO, and a fb_var_screeninfo struct. The fb_var_screeninfo struct has a parameter nonstd that sets the color properties of the buffer (e.g. RGB 565, RGB 24U, YUV 422, etc). The acceptable values for nonstd are defined in the omapfb.h file, but they appear to be incorrect - at least they don't seem to set the parameters of the buffer the way one would expect. For example, using OMAPFB_COLOR_RGB565 appears to give me a buffer with parameters that look like OMAPFB_COLOR_RGB24U. nonstd field is only used for OMAPFB_COLOR_YUV422 and OMAPFB_COLOR_YUY422. For other modes leave it to zero. If you want to use YUV modes, set the nonstd to the yuv mode, and bits_per_pixel to 16. For other modes, set bits_per_pixel and red/green/blue/transp fields. You can look at drivers/video/omap2/omapfb/omapfb-main.c omapfb_colormodes[] array for examples how the driver parses the modes. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: clean up ASM idle code
Jean,
-Original Message-
From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
Sent: Tuesday, December 14, 2010 2:53 PM
To: Kevin Hilman; Vishwanath BS
Cc: linux-omap@vger.kernel.org; Jean Pihet
Subject: Re: [PATCH] OMAP3: clean up ASM idle code
Kevin,
On Tue, Dec 14, 2010 at 5:12 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Clean up of the ASM code:
- reorganized the code in logical sections: defines, API
á áfunctions, internal functions and variables,
- reworked and simplified the execution paths, for better
á áreadability and to avoid duplication of code,
- added comments on the entry and exit points,
- reworked the existing comments for better readability,
- reworked the code formating, alignment and white spaces,
- added comments for the i443 erratum workarounds,
- changed the hardcoded values in favor of existing macros
á áfrom include files,
- clean up of non used symbols.
The 'lock_scratchpad_sem' code is also unused. áIIRC, you removed
that
in an earlier version of the series. áAre you still planning to remove
that? maybe in a subsequent patch?
I asked previously about it and the reply was that this code is
needed: (quoting Vishwa's reply) This is indeed used during DVFS when
Core DPLL configuration is changed. Note: the DVFS code is not
upstreamed yet.
Vishwa, can you confirm?
lock_scratchpad_sem is needed when DVFS feature is supported. If you want
to add this implementation as part of DVFS feature, then also it's fine.
Vishwa
That being said, pure whitespace changes and unused code removal
should
probably be a separate patch. áIt's a great help to reviewers if
functional changes are separated from whitespace changes. áIt's a bit
tricky in this series as there's lots of code moving as well, so I'll
leave it up to your judgement on how/if to separate these out.
There is no functional change at all. The code has been reorganized
for better readability.
I agree the patch is not easy to read but that is the way diff reports
the changes.
I do not see the point to provide separate patches for code move,
white space clean-up, alignment fixes etc.
Tested on OMAP3EVM and Beagleboard with full RET and OFF modes.
In idle? áin suspend? áboth? áwas CPUidle enabled?
FWIW, I tested on 3430-ES3.1/n900 with retention idle suspend and
off
idle suspend with CPUidle enabled.
Tested with cpuidle and suspend. I will update the description.
Heavily reworked from Vishwa's original patch.
Here, it's more customary to ásay Based on original patch from
Vishwa
and ensure the original author is CC'd (which you've done.)
Other than that, this is a great cleanup, and makes this much more
readable. áThanks.
Some other minor comments below.
OK thanks for the review. I will post a new version asap.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
---
Applies on top of Nishant's latest idle path errata fixes step 2,
cf. http://marc.info/?l=linux-omapm=129139584919242w=2
[...]
@@ -208,36 +172,153 @@ api_params:
áENTRY(save_secure_ram_context_sz)
á á á .word á . - save_secure_ram_context
+
+/* ==
+ * == Idle entry point ==
+ * ==
+ */
Let's keep C multi-line coding style even for assembly. á Same goes
for
several other places below.
Ok
á/*
á * Forces OMAP into idle state
á *
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
+ * omap34xx_suspend() - This bit of code saves the CPU context if
needed
+ * and executes the WFI instruction
+ *
+ * Note: This code get's copied to internal SRAM at boot.
á *
- * Note: This code get's copied to internal SRAM at boot. When the
OMAP
- * á áwakes up it continues execution at the point it went to sleep.
+ * Note: When the OMAP wakes up it continues at different
execution points,
+ * ádepending on the low power mode (non-OFF vs OFF modes),
+ * ácf. 'Resume path for xxx mode' comments.
á */
áENTRY(omap34xx_cpu_suspend)
á á á stmfd á sp!, {r0-r12, lr} á á á á á á á @ save registers on
stack
áloop:
á á á /*b á á loop*/ �...@enable to debug by stepping through code
While here, let's get rid of these infinite loop hacks for debugging
as
anyone debugging this code can add these back as needed.
áOtherwise,
they clutter the code. á There are a few of theses throughout the
original code.
Ok. Agree those are not used at all (even when doing heavy debugging).
[...]
@@ -250,9 +331,28 @@ loop:
á á á nop
á á á bl wait_sdrc_ok
- á á ldmfd á sp!, {r0-r12, pc} á á á á á á á @ restore regs and
return
+/* ===
+ * == Exit point from non-OFF modes ==
+ * ===
+ */
+ á á ldmfd á sp!, {r0-r12, pc} á á á @ restore regs and return
Re: [RFC PATCHv4 4/7] HSI: hsi_char: Add HSI char device driver
+#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);
These sort of macros just hide detail - eg the lack of internal locking,
which can lead to problems later, plus they reference their arguments
multiple times so may have weird side effects.
They should probably be inline functions so they at least type check and
behave sanely, and their locking rules defintiely need documenting
+static long hsi_char_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct hsi_char_channel *channel = file-private_data;
+ unsigned int state;
+ struct hsi_config cfg;
+ struct hsc_rx_config rx_cfg;
+ struct hsc_tx_config tx_cfg;
+ long ret = 0;
+
+ if (HSI_CHST_OC(channel) != HSI_CHST_OPENED)
+ return -ENODEV;
-EIO is the traditional response in this case if the channel has been
closed by the other end - ENODEV indicates there is no physical device
present - not sure which is right here from the code.
+ } else if ((state == HSC_PM_ENABLE)
+ (channel-wlrefcnt 0)) {
+ ret = hsi_stop_tx(channel-cl);
+ if (!ret)
+ channel-wlrefcnt--;
What locks this lot against races (ditto some of the other ioctl code)
+ refcnt = atomic_inc_return(cl_data-refcnt);
+ if (refcnt == 1) {
You seem to construct a lot of clever stuff using atomic_inc_return and
friends where it looks like test_and_set_bit - or even a mutex over
open/close would be far easier to understand ?
+ ret = hsi_char_msgs_alloc(channel);
+
+ if (ret 0) {
+ refcnt = atomic_dec_return(cl_data-refcnt);
+ if (!refcnt)
+ hsi_release_port(channel-cl);
+ spin_lock_bh(channel-lock);
+ HSI_CHST_OC_SET(channel, HSI_CHST_CLOSED);
+ goto out;
+ }
+ if (refcnt == 1)
+ cl_data-attached = 1;
What happens here if a second open passes the first, the attached will
stay zero and other stuff will be in strange states but the open flag
will be set ?
+ for (i = 0; i HSI_CHAR_DEVS channels_map[i] = 0; i++) {
+ if (channels_map[i] = HSI_CHAR_DEVS) {
+ pr_err(Invalid HSI/SSI channel specified);
+ return -EINVAL;
+ }
+ set_bit(channels_map[i], ch_mask);
How will this integrate with hot discovery of SSI supporting devices ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens,
On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote:
I wrote:
I'll see if I can draw up the ALSA-specific media stuff over the weekend.
Sorry, wrong weekend.
Anyway, below are some remarks and a patch.
Thank you. Please see my comments inline.
* Entity types
TYPE_NODE was renamed to TYPE_DEVICE because node sounds like a node
in a graph, which does not distinguish it from other entity types
because all entities are part of the topology graph. I chose device
as this type describes entities that are visible as some device node to
other software.
What this type describes is a device node. Both NODE and DEVICE can be
confusing in my opinion, but DEVICE_NODE is a bit long.
TYPE_EXT describes entities that represent some interface to the
external world, TYPE_INT those that are internal to the entire device.
(I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems
to be an even more meaningless name.)
SUBDEV comes from the V4L2 world, and I agree that it might not be a very good
name.
I'm not sure I would split entities in internal/external categories. I would
create a category for connectors though.
ALSA mixer controls are not directly represented; a better fit for the
architecture of actual devices is that one or more mixer controls can be
associated with an entity. (This can be done with a field of the mixer
control.)
Agreed.
* Entity properties
There needs to be a mechanism to associate meta-information (properties)
with entities. This information should be optional and extensible, but,
when being handled inside the kernel, doesn't need to be more than
a read-only blob. I think that something like ALSA's TLV format (used
for mixer controls) can be used here. (I'm not mentioning the X-word
here, except to note that the M stands for markup.)
I've been thinking of adding a new ioctl for that. It's something we need to
draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers
would find it useful as well.
* Entity subtypes
EXT_JACK_ANALOG represents any analog audio and/or video connector.
Properties for audio jacks would be jack type (TRS/RCA), color code,
line level, position, etc.
EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/
TOSLINK), ADAT, TDIF, or MADI.
EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio
spec. (I doubt that any devices with this entitiy will ever exist.)
EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI
controller. (Instrument entities are typically audio sources and MIDI
sources and sinks, but can also be audio sinks.)
EXT_SPEAKER also includes headphones; there might be made a case for
having those as a separate subtype.
Shouldn't headphones be represented by an EXT_JACK_ANALOG ?
EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can
also write to that device, so player might not be an ideal name.
EXT_BROADCAST represents devices like TV tuners, satellite receivers,
cable tuners, or radios.
There's clearly an overlap with V4L here. Hopefully someone from the linux-
media list can comment on this.
INT_SYNTHESIZER converts MIDI to audio.
INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt
to describe the characteristics of consumer-grade devices :-) , but
represents an internal noise source for level calibration or measurements.
INT_CONTROLS may have multiple independent controls (this is USB's
Feature Unit); INT_EFFECT may have multiple controls that affect one
single algorithm.
I'd describe this as a feature unit/processing unit then.
INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology
information has only stereo links.
Some of those INT entities could also be implemented in dedicated chips, so I
really think the EXT/INT split doesn't make too much sense. Should we have an
AUDIO category ?
* Entity specifications
While TYPE_DEVICE entities can be identified by their device node, other
entities typcially have just a numeric ID.
In V4L2 sub-devices have (or rather will have once the media controller
patches will be integrated) device nodes as well, so exposing that information
is required.
For that, it would be useful to make do without separate identification and
let the driver choose the entity ID.
How would drivers do that ? What if you have two instances of the same chip (a
video sensor, audio mixer, ...) on the same board ?
Signed-off-by: Clemens Ladisch clem...@ladisch.de
--- linux/include/linux/media.h
+++ linux/include/linux/media.h
@@ -46,16 +46,36 @@ struct media_device_info {
#define MEDIA_ENTITY_TYPE_MASK 0x00ff
#define MEDIA_ENTITY_SUBTYPE_MASK0x
-#define MEDIA_ENTITY_TYPE_NODE (1
MEDIA_ENTITY_TYPE_SHIFT)
-#define MEDIA_ENTITY_TYPE_NODE_V4L (MEDIA_ENTITY_TYPE_NODE + 1)
-#define
Re: Mainline OMAP3 breakage (and other OMAP?)
Hi,
On Fri, 2010-12-03 at 13:07 +, ext Russell King - ARM Linux wrote:
So please, 2MB, or if you object, at the _very_ _least_ 1MB. But
definitely not PAGE_SIZE.
Here's a patch for this. Works for me on OMAP3430SDP. If the patch is
ok, I'll send a pull request to Paul.
From 6c54704730626e2683e05574b3cbba966980c956 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@nokia.com
Date: Tue, 14 Dec 2010 14:16:59 +0200
Subject: [PATCH] OMAP: DSS: VRAM: Align start size of vram to 2M
Align the start address and size of VRAM area to 2M as per comments from
Russell King:
So, why SZ_2M?
Firstly, that's the granularity which we allocate page tables - one
Linux page table covers 2MB of memory. We want to avoid creating page
tables for the main memory mapping as that increases TLB pressure through
the use of additional TLB entries, and more page table walks.
Plus, we never used to allow the kernel's direct memory mapping to be
mapped at anything less than section size - this restriction has since
been lifted due to OMAP SRAM problems, but I'd rather we stuck with it
to ensure that we have proper behaviour from all parts of the system.
Secondly, we don't want to end up with lots of fragmentation at the end
of the memory mapping as that'll reduce performance, not only by making
the pfn_valid() search more expensive.
Emsuring a minimum allocation size and alignment makes sure that the
regions can be coalesced together into one block, and minimises run-time
expenses.
So please, 2MB, or if you object, at the _very_ _least_ 1MB. But
definitely not PAGE_SIZE.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/vram.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index 2fd7e52..9441e2e 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -551,7 +551,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
if (!size)
return;
- size = PAGE_ALIGN(size);
+ size = ALIGN(size, SZ_2M);
if (paddr) {
if (paddr ~PAGE_MASK) {
@@ -576,7 +576,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
return;
}
} else {
- paddr = memblock_alloc(size, PAGE_SIZE);
+ paddr = memblock_alloc(size, SZ_2M);
}
memblock_free(paddr, size);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens, On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: I wrote: I'll see if I can draw up the ALSA-specific media stuff over the weekend. Sorry, wrong weekend. Anyway, below are some remarks and a patch. Thank you. Please see my comments inline. * Entity types TYPE_NODE was renamed to TYPE_DEVICE because node sounds like a node in a graph, which does not distinguish it from other entity types because all entities are part of the topology graph. I chose device as this type describes entities that are visible as some device node to other software. What this type describes is a device node. Both NODE and DEVICE can be confusing in my opinion, but DEVICE_NODE is a bit long. What about DEVNODE? I think that would be a good alternative. TYPE_EXT describes entities that represent some interface to the external world, TYPE_INT those that are internal to the entire device. (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems to be an even more meaningless name.) SUBDEV comes from the V4L2 world, and I agree that it might not be a very good name. SUBDEV refers to a specific type of driver. Within the v4l world it is well defined. So I prefer to keep this. Perhaps some additional comments or documentation can be added to clarify this. I'm not sure I would split entities in internal/external categories. I would create a category for connectors though. I agree. It was always the plan to eventually add connectors, but v4l didn't really need it (it already has an API to enumerate connectors). ALSA mixer controls are not directly represented; a better fit for the architecture of actual devices is that one or more mixer controls can be associated with an entity. (This can be done with a field of the mixer control.) Agreed. * Entity properties There needs to be a mechanism to associate meta-information (properties) with entities. This information should be optional and extensible, but, when being handled inside the kernel, doesn't need to be more than a read-only blob. I think that something like ALSA's TLV format (used for mixer controls) can be used here. (I'm not mentioning the X-word here, except to note that the M stands for markup.) I've been thinking of adding a new ioctl for that. It's something we need to draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers would find it useful as well. * Entity subtypes EXT_JACK_ANALOG represents any analog audio and/or video connector. Properties for audio jacks would be jack type (TRS/RCA), color code, line level, position, etc. EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/ TOSLINK), ADAT, TDIF, or MADI. EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio spec. (I doubt that any devices with this entitiy will ever exist.) EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI controller. (Instrument entities are typically audio sources and MIDI sources and sinks, but can also be audio sinks.) EXT_SPEAKER also includes headphones; there might be made a case for having those as a separate subtype. Shouldn't headphones be represented by an EXT_JACK_ANALOG ? EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can also write to that device, so player might not be an ideal name. EXT_BROADCAST represents devices like TV tuners, satellite receivers, cable tuners, or radios. I don't think it is right to talk about 'represents devices'. I'd rephrase it to 'connects to devices'. There's clearly an overlap with V4L here. Hopefully someone from the linux- media list can comment on this. I don't think this will be a problem. Initially we probably won't be enumerating connectors for V4L since it already has its own API for that. INT_SYNTHESIZER converts MIDI to audio. INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt to describe the characteristics of consumer-grade devices :-) , but represents an internal noise source for level calibration or measurements. INT_CONTROLS may have multiple independent controls (this is USB's Feature Unit); INT_EFFECT may have multiple controls that affect one single algorithm. I'd describe this as a feature unit/processing unit then. INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology information has only stereo links. Some of those INT entities could also be implemented in dedicated chips, so I really think the EXT/INT split doesn't make too much sense. Should we have an AUDIO category ? * Entity specifications While TYPE_DEVICE entities can be identified by their device node, other entities typcially have just a numeric ID. In V4L2 sub-devices have (or rather will have once the media controller patches will be integrated) device nodes as well, so exposing that information is required. For that, it would be useful to make do without separate identification
Re: OMAP4 build error - omapfb
On Thu, 2010-12-02 at 14:00 -0800, ext Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [101202 13:15]: drivers/built-in.o: In function `omapfb_do_probe': drivers/video/omap/omapfb_main.c:1773: undefined reference to `omap2_int_ctrl' Looks like there's a missing dependency for CONFIG_FB_OMAP. As the only place omap2_int_ctrl is defined is in drivers/video/omap/dispc.c, and this isn't built for OMAP4, maybe FB_OMAP is missing a dependency such that it's only available for OMAP1, OMAP2 and OMAP3 ? This is something for Tomi, adding fbdev and Tomi to Cc. Looks correct. The old omapfb will never work with OMAP4, so a dependency to OMAP1/2/3 fixes the build problem. I'll add this fix to my tree. Tomi Tony diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig index 455c605..083c8fe 100644 --- a/drivers/video/omap/Kconfig +++ b/drivers/video/omap/Kconfig @@ -1,7 +1,7 @@ config FB_OMAP tristate OMAP frame buffer support (EXPERIMENTAL) - depends on FB ARCH_OMAP (OMAP2_DSS = n) - + depends on FB (OMAP2_DSS = n) + depends on ARCH_OMAP1 || ARCH_OMAP2 || ARCH_OMAP3 select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Hans, On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote: On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: * Entity types TYPE_NODE was renamed to TYPE_DEVICE because node sounds like a node in a graph, which does not distinguish it from other entity types because all entities are part of the topology graph. I chose device as this type describes entities that are visible as some device node to other software. What this type describes is a device node. Both NODE and DEVICE can be confusing in my opinion, but DEVICE_NODE is a bit long. What about DEVNODE? I think that would be a good alternative. Fine with me. Clemens, any opinion on that ? TYPE_EXT describes entities that represent some interface to the external world, TYPE_INT those that are internal to the entire device. (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems to be an even more meaningless name.) SUBDEV comes from the V4L2 world, and I agree that it might not be a very good name. SUBDEV refers to a specific type of driver. Within the v4l world it is well defined. So I prefer to keep this. Perhaps some additional comments or documentation can be added to clarify this. Should this be clarified by using V4L2_SUBDEV instead then ? What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ? I'm not sure I would split entities in internal/external categories. I would create a category for connectors though. I agree. It was always the plan to eventually add connectors, but v4l didn't really need it (it already has an API to enumerate connectors). ALSA mixer controls are not directly represented; a better fit for the architecture of actual devices is that one or more mixer controls can be associated with an entity. (This can be done with a field of the mixer control.) Agreed. * Entity properties There needs to be a mechanism to associate meta-information (properties) with entities. This information should be optional and extensible, but, when being handled inside the kernel, doesn't need to be more than a read-only blob. I think that something like ALSA's TLV format (used for mixer controls) can be used here. (I'm not mentioning the X-word here, except to note that the M stands for markup.) I've been thinking of adding a new ioctl for that. It's something we need to draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers would find it useful as well. * Entity subtypes EXT_JACK_ANALOG represents any analog audio and/or video connector. Properties for audio jacks would be jack type (TRS/RCA), color code, line level, position, etc. EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/ TOSLINK), ADAT, TDIF, or MADI. EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio spec. (I doubt that any devices with this entitiy will ever exist.) EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI controller. (Instrument entities are typically audio sources and MIDI sources and sinks, but can also be audio sinks.) EXT_SPEAKER also includes headphones; there might be made a case for having those as a separate subtype. Shouldn't headphones be represented by an EXT_JACK_ANALOG ? EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can also write to that device, so player might not be an ideal name. EXT_BROADCAST represents devices like TV tuners, satellite receivers, cable tuners, or radios. I don't think it is right to talk about 'represents devices'. I'd rephrase it to 'connects to devices'. There's clearly an overlap with V4L here. Hopefully someone from the linux-media list can comment on this. I don't think this will be a problem. Initially we probably won't be enumerating connectors for V4L since it already has its own API for that. My understanding is that EXT_BROADCAST really represents the TV tuners, ..., not the connector they connect to. Some (all ?) of them are definitely V4L2 subdevs. INT_SYNTHESIZER converts MIDI to audio. INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt to describe the characteristics of consumer-grade devices :-) , but represents an internal noise source for level calibration or measurements. INT_CONTROLS may have multiple independent controls (this is USB's Feature Unit); INT_EFFECT may have multiple controls that affect one single algorithm. I'd describe this as a feature unit/processing unit then. INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology information has only stereo links. Some of those INT entities could also be implemented in dedicated chips, so I really think the EXT/INT split doesn't make too much sense. Should we have an AUDIO category ? * Entity specifications While TYPE_DEVICE entities can be
[PATCH 0/4] omap: iovmm - fixes for iovmm module
Version 6: * Rebase on Russell King branch. - for details see: http://marc.info/?l=linux-omapm=129228495723001w=2 Version 5: * Changes in iommu: create new api to set valid da range - Change range variables to platform data structure. Version 4: * Changes in iommu: create new api to set valid da range - Validate range for fixed address. - Change way of change boundaries to avoid possible overflow instead of style : start + bytes = end which start + end can overflow use style: end - start bytes Version 3: * change patch 2 base on Felipe Contreras' comments, now it uses min_t and I deleted some blank lines. * patch create new api to set valid da range is base on iovmm: IVA2 MMU range is from 0x1100 to 0x patch and on Hiroshi's comments and now it is added to this set. Version 2: * Removed iovmm: fixes for iovmm module that patch was already sent. * Modified iovmm: fix roundup for next area and end check for the last area patch, base on Davin Cohen's comments and rename it to a proper name that describes what it is doing now. Guzman Lugo, Fernando (4): omap: iovmm - no gap checking for fixed address omap: iovmm - add superpages support to fixed da address omap: iovmm - replace __iounmap with iounmap omap: iommu - create new api to set valid da range arch/arm/plat-omap/include/plat/iommu.h |3 + arch/arm/plat-omap/iommu.c | 33 arch/arm/plat-omap/iovmm.c | 84 ++- 3 files changed, 85 insertions(+), 35 deletions(-) -- 1.7.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 1/4] omap: iovmm - no gap checking for fixed address
From: Guzman Lugo, Fernando x0095...@ti.com
If some fixed da address is wanted to be mapped and the page
is freed but it is used as gap, the mapping will fail.
This patch is fixing that and olny keeps the gap for
not fixed address.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 8ce0de2..34f0012 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -289,10 +289,10 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
prev_end = 0;
list_for_each_entry(tmp, obj-mmap, list) {
- if (prev_end = start)
+ if (prev_end start)
break;
- if (start + bytes tmp-da_start)
+ if (start + bytes = tmp-da_start)
goto found;
if (flags IOVMF_DA_ANON)
@@ -301,7 +301,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
prev_end = tmp-da_end;
}
- if ((start prev_end) (ULONG_MAX - start = bytes))
+ if ((start = prev_end) (ULONG_MAX - start + 1 = bytes))
goto found;
dev_dbg(obj-dev, %s: no space to fit %08x(%x) flags: %08x\n,
--
1.7.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 2/4] omap: iovmm - add superpages support to fixed da address
From: Guzman Lugo, Fernando x0095...@ti.com
This patch adds superpages support to fixed ad address
inside iommu_kmap function.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c | 62 +--
1 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 34f0012..93a34d9 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -87,35 +87,43 @@ 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;
+}
+
/*
* calculate the optimal number sg elements from total bytes based on
* iommu superpages
*/
-static unsigned int sgtable_nents(size_t bytes)
+static unsigned 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 nr_entries = 0, ent_sz;
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_t(unsigned, ent_sz, iopgsz_max(bytes));
+ nr_entries++;
+ da += ent_sz;
+ pa += ent_sz;
+ bytes -= ent_sz;
}
- BUG_ON(bytes);
return nr_entries;
}
/* 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 +135,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 +416,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;
@@ -418,9 +426,10 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32
pa, size_t len)
va = phys_to_virt(pa);
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
- size_t bytes;
+ unsigned bytes;
- bytes = iopgsz_max(len);
+ bytes = max_alignment(da | pa);
+ bytes = min_t(unsigned, bytes, iopgsz_max(len));
BUG_ON(!iopgsz_ok(bytes));
@@ -429,6 +438,7 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32
pa, size_t len)
* 'pa' is cotinuous(linear).
*/
pa += bytes;
+ da += bytes;
len -= bytes;
}
BUG_ON(len);
@@ -695,18 +705,18 @@ u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t
bytes, u32 flags)
if (!va)
return -ENOMEM;
- sgt = sgtable_alloc(bytes, flags);
+ flags = IOVMF_HW_MASK;
+ flags |= IOVMF_DISCONT;
+ flags |= IOVMF_ALLOC;
+ flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
+
+ sgt = sgtable_alloc(bytes, flags, da, 0);
if (IS_ERR(sgt)) {
da = PTR_ERR(sgt);
goto err_sgt_alloc;
}
sgtable_fill_vmalloc(sgt, va);
- flags = IOVMF_HW_MASK;
- flags |= IOVMF_DISCONT;
- flags |= IOVMF_ALLOC;
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
-
da = __iommu_vmap(obj, da, sgt, va, bytes, flags);
if (IS_ERR_VALUE(da))
goto err_iommu_vmap;
@@ -746,11 +756,11 @@ static u32 __iommu_kmap(struct iommu *obj, u32 da, u32
pa, void *va,
{
struct sg_table *sgt;
- sgt =
[PATCHv6 3/4] omap: iovmm - replace __iounmap with iounmap
From: Guzman Lugo, Fernando x0095...@ti.com __iounmap function is wrong for OMAP architecture, instead use iounmap which will call to the correct function. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 93a34d9..fa6e643 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)iounmap, IOVMF_LINEAR | IOVMF_MMIO); if (!sgt) dev_dbg(obj-dev, %s: No sgt\n, __func__); -- 1.7.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 4/4] omap: iommu - create new api to set valid da range
From: Guzman Lugo, Fernando x0095...@ti.com
Some IOMMUs cannot use the whole 0x0 - 0x rage.
With this new API the valid range can be set.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/include/plat/iommu.h |3 ++
arch/arm/plat-omap/iommu.c | 33 +++
arch/arm/plat-omap/iovmm.c | 18 ++--
3 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 33c7d41..2ea8ea3 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -103,6 +103,8 @@ struct iommu_platform_data {
const char *name;
const char *clk_name;
const int nr_tlb_entries;
+ u32 da_start;
+ u32 da_end;
};
#if defined(CONFIG_ARCH_OMAP1)
@@ -152,6 +154,7 @@ extern void flush_iotlb_all(struct iommu *obj);
extern int iopgtable_store_entry(struct iommu *obj, struct iotlb_entry *e);
extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova);
+extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
extern struct iommu *iommu_get(const char *name);
extern void iommu_put(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 6cd151b..b3846bd 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -25,6 +25,12 @@
#include iopgtable.h
+/* Reserve the first page for NULL */
+#define IOMMU_DEFAULT_DA_START PAGE_SIZE
+/* 0x not allowed because it is not page aligned */
+#define IOMMU_DEFAULT_DA_END 0xF000
+
+
#define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0; \
(__i (n)) (cr = __iotlb_read_cr((obj), __i), true); \
@@ -830,6 +836,31 @@ static int device_match_by_alias(struct device *dev, void
*data)
}
/**
+ * iommu_set_da_range - Set a valid device address range
+ * @obj: target iommu
+ * @start Start of valid range
+ * @endEnd of valid range
+ **/
+int iommu_set_da_range(struct iommu *obj, u32 start, u32 end)
+{
+ struct iommu_platform_data *pdata;
+
+ if (!obj)
+ return -EFAULT;
+
+ if (end start || !PAGE_ALIGN(start | end))
+ return -EINVAL;
+
+ pdata = obj-dev-platform_data;
+
+ pdata-da_start = start;
+ pdata-da_end = end;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_set_da_range);
+
+/**
* iommu_get - Get iommu handler
* @name: target iommu name
**/
@@ -853,6 +884,8 @@ struct iommu *iommu_get(const char *name)
if (err)
goto err_enable;
flush_iotlb_all(obj);
+ iommu_set_da_range(obj, IOMMU_DEFAULT_DA_START,
+ IOMMU_DEFAULT_DA_END);
}
if (!try_module_get(obj-owner))
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index fa6e643..ee3ca20 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -272,21 +272,25 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
{
struct iovm_struct *new, *tmp;
u32 start, prev_end, alignement;
+ struct iommu_platform_data *pdata;
if (!obj || !bytes)
return ERR_PTR(-EINVAL);
+ pdata = obj-dev-platform_data;
+
start = da;
alignement = PAGE_SIZE;
if (flags IOVMF_DA_ANON) {
- /*
-* Reserve the first page for NULL
-*/
- start = PAGE_SIZE;
+ start = pdata-da_start;
+
if (flags IOVMF_LINEAR)
alignement = iopgsz_max(bytes);
start = roundup(start, alignement);
+ } else if (start pdata-da_start || start pdata-da_end ||
+ pdata-da_end - start bytes) {
+ return ERR_PTR(-EINVAL);
}
tmp = NULL;
@@ -299,16 +303,16 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
if (prev_end start)
break;
- if (start + bytes = tmp-da_start)
+ if (tmp-da_start start (tmp-da_start - start) = bytes)
goto found;
- if (flags IOVMF_DA_ANON)
+ if (tmp-da_end = start flags IOVMF_DA_ANON)
start = roundup(tmp-da_end + 1, alignement);
prev_end = tmp-da_end;
}
- if ((start = prev_end) (ULONG_MAX - start + 1 = bytes))
+ if ((start = prev_end) (pdata-da_end - start = bytes))
goto found;
dev_dbg(obj-dev, %s: no space to fit %08x(%x) flags: %08x\n,
--
1.7.3.2
--
To unsubscribe from
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Laurent Pinchart wrote: On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: TYPE_EXT describes entities that represent some interface to the external world, TYPE_INT those that are internal to the entire device. (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems to be an even more meaningless name.) SUBDEV comes from the V4L2 world, and I agree that it might not be a very good name. I'm not sure I would split entities in internal/external categories. I would create a category for connectors though. I'm not disagreeing, but what is actually the distinction between types and subtypes? ;-) * Entity properties There needs to be a mechanism to associate meta-information (properties) with entities. This information should be optional and extensible, but, when being handled inside the kernel, doesn't need to be more than a read-only blob. I think that something like ALSA's TLV format (used for mixer controls) can be used here. (I'm not mentioning the X-word here, except to note that the M stands for markup.) I've been thinking of adding a new ioctl for that. It's something we need to draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers would find it useful as well. I'm imagining a read-the-properties ioctl that just returns the entity's blob. EXT_SPEAKER also includes headphones; there might be made a case for having those as a separate subtype. Shouldn't headphones be represented by an EXT_JACK_ANALOG ? Headphone jacks are jacks; there are also USB headphones. EXT_BROADCAST represents devices like TV tuners, satellite receivers, cable tuners, or radios. There's clearly an overlap with V4L here. These come from the USB audio spec. Video devices are indeed likely to be more detailed than just a single audio source. :) INT_CONTROLS may have multiple independent controls (this is USB's Feature Unit); INT_EFFECT may have multiple controls that affect one single algorithm. I'd describe this as a feature unit/processing unit then. I was aiming for more descriptive names, but I agree that the original names might be more useful. Should we have an AUDIO category ? Probably not, because there are combined audio/video jacks, any maybe other entities. * Entity specifications While TYPE_DEVICE entities can be identified by their device node, other entities typcially have just a numeric ID. In V4L2 sub-devices have (or rather will have once the media controller patches will be integrated) device nodes as well, so exposing that information is required. USB and HDA entities already have numeric IDs. For that, it would be useful to make do without separate identification and let the driver choose the entity ID. How would drivers do that ? What if you have two instances of the same chip (a video sensor, audio mixer, ...) on the same board ? Then those would get different IDs; USB descriptors always describe the entire device. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Laurent Pinchart wrote: On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote: On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: * Entity types TYPE_NODE was renamed to TYPE_DEVICE because node sounds like a node in a graph, which does not distinguish it from other entity types because all entities are part of the topology graph. I chose device as this type describes entities that are visible as some device node to other software. What this type describes is a device node. Both NODE and DEVICE can be confusing in my opinion, but DEVICE_NODE is a bit long. What about DEVNODE? I think that would be a good alternative. Fine with me. Clemens, any opinion on that ? Fine with me too. TYPE_EXT describes entities that represent some interface to the external world, TYPE_INT those that are internal to the entire device. (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems to be an even more meaningless name.) SUBDEV comes from the V4L2 world, and I agree that it might not be a very good name. SUBDEV refers to a specific type of driver. Within the v4l world it is well defined. So I prefer to keep this. Perhaps some additional comments or documentation can be added to clarify this. Should this be clarified by using V4L2_SUBDEV instead then ? If the SUBDEV concept doesn't exist outside V4L, that would indeed be better. I don't want to rename things that come out of existing frameworks; this naming discussion makes sense only for those entity (sub)types that can be shared between them. Are there any, besides jacks? What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ? The entity types representing ALSA devices are already named ALSA. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
At Tue, 14 Dec 2010 14:31:55 +0100, Clemens Ladisch wrote: Should we have an AUDIO category ? Probably not, because there are combined audio/video jacks, any maybe other entities. Yes, nowadays HDMI / DP are pretty common, for example. Takashi -- 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 05/12] OMAP4: PRCM: Add SCRM header file
Hi Paul, This patch will conflict with your power prcm series, because you are creating an empty scrm44xx.h in it. So I did rebased this series on top on your prcm to fix that. Don't you want to use the already rebased version instead? Regards, Benoit On 12/14/2010 7:34 AM, Paul Walmsley wrote: From: Benoit Coussonb-cous...@ti.com Add the header file with scrm registers absolute address, offset and bitfields. Signed-off-by: Benoit Coussonb-cous...@ti.com Signed-off-by: Rajendra Nayakrna...@ti.com Signed-off-by: Paul Walmsleyp...@pwsan.com --- arch/arm/mach-omap2/scrm44xx.h | 176 1 files changed, 176 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/scrm44xx.h diff --git a/arch/arm/mach-omap2/scrm44xx.h b/arch/arm/mach-omap2/scrm44xx.h new file mode 100644 index 000..d29bf27 --- /dev/null +++ b/arch/arm/mach-omap2/scrm44xx.h @@ -0,0 +1,176 @@ +/* + * OMAP44xx SCRM registers and bitfields + * + * Copyright (C) 2010 Texas Instruments, Inc. + * + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * 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. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_SCRM_44XX_H +#define __ARCH_ARM_MACH_OMAP2_SCRM_44XX_H + +/* Base address */ +#define OMAP4_SCRM 0x4a30a000 + +#define OMAP44XX_SCRM_REGADDR(reg) \ + OMAP2_L4_IO_ADDRESS(OMAP4_SCRM + (reg)) + +/* Registers offset */ +#define OMAP4_SCRM_REVISION_SCRM_OFFSET0x +#define OMAP4_SCRM_REVISION_SCRM OMAP44XX_SCRM_REGADDR(0x) +#define OMAP4_SCRM_CLKSETUPTIME_OFFSET 0x0100 +#define OMAP4_SCRM_CLKSETUPTIME OMAP44XX_SCRM_REGADDR(0x0100) +#define OMAP4_SCRM_PMICSETUPTIME_OFFSET0x0104 +#define OMAP4_SCRM_PMICSETUPTIME OMAP44XX_SCRM_REGADDR(0x0104) +#define OMAP4_SCRM_ALTCLKSRC_OFFSET0x0110 +#define OMAP4_SCRM_ALTCLKSRC OMAP44XX_SCRM_REGADDR(0x0110) +#define OMAP4_SCRM_MODEMCLKM_OFFSET0x0118 +#define OMAP4_SCRM_MODEMCLKM OMAP44XX_SCRM_REGADDR(0x0118) +#define OMAP4_SCRM_D2DCLKM_OFFSET 0x011c +#define OMAP4_SCRM_D2DCLKM OMAP44XX_SCRM_REGADDR(0x011c) +#define OMAP4_SCRM_EXTCLKREQ_OFFSET0x0200 +#define OMAP4_SCRM_EXTCLKREQ OMAP44XX_SCRM_REGADDR(0x0200) +#define OMAP4_SCRM_ACCCLKREQ_OFFSET0x0204 +#define OMAP4_SCRM_ACCCLKREQ OMAP44XX_SCRM_REGADDR(0x0204) +#define OMAP4_SCRM_PWRREQ_OFFSET 0x0208 +#define OMAP4_SCRM_PWRREQ OMAP44XX_SCRM_REGADDR(0x0208) +#define OMAP4_SCRM_AUXCLKREQ0_OFFSET 0x0210 +#define OMAP4_SCRM_AUXCLKREQ0 OMAP44XX_SCRM_REGADDR(0x0210) +#define OMAP4_SCRM_AUXCLKREQ1_OFFSET 0x0214 +#define OMAP4_SCRM_AUXCLKREQ1 OMAP44XX_SCRM_REGADDR(0x0214) +#define OMAP4_SCRM_AUXCLKREQ2_OFFSET 0x0218 +#define OMAP4_SCRM_AUXCLKREQ2 OMAP44XX_SCRM_REGADDR(0x0218) +#define OMAP4_SCRM_AUXCLKREQ3_OFFSET 0x021c +#define OMAP4_SCRM_AUXCLKREQ3 OMAP44XX_SCRM_REGADDR(0x021c) +#define OMAP4_SCRM_AUXCLKREQ4_OFFSET 0x0220 +#define OMAP4_SCRM_AUXCLKREQ4 OMAP44XX_SCRM_REGADDR(0x0220) +#define OMAP4_SCRM_AUXCLKREQ5_OFFSET 0x0224 +#define OMAP4_SCRM_AUXCLKREQ5 OMAP44XX_SCRM_REGADDR(0x0224) +#define OMAP4_SCRM_D2DCLKREQ_OFFSET0x0234 +#define OMAP4_SCRM_D2DCLKREQ OMAP44XX_SCRM_REGADDR(0x0234) +#define OMAP4_SCRM_AUXCLK0_OFFSET 0x0310 +#define OMAP4_SCRM_AUXCLK0 OMAP44XX_SCRM_REGADDR(0x0310) +#define OMAP4_SCRM_AUXCLK1_OFFSET 0x0314 +#define OMAP4_SCRM_AUXCLK1 OMAP44XX_SCRM_REGADDR(0x0314) +#define OMAP4_SCRM_AUXCLK2_OFFSET 0x0318 +#define OMAP4_SCRM_AUXCLK2 OMAP44XX_SCRM_REGADDR(0x0318) +#define OMAP4_SCRM_AUXCLK3_OFFSET 0x031c +#define OMAP4_SCRM_AUXCLK3 OMAP44XX_SCRM_REGADDR(0x031c) +#define OMAP4_SCRM_AUXCLK4_OFFSET 0x0320 +#define OMAP4_SCRM_AUXCLK4 OMAP44XX_SCRM_REGADDR(0x0320) +#define OMAP4_SCRM_AUXCLK5_OFFSET 0x0324 +#define OMAP4_SCRM_AUXCLK5 OMAP44XX_SCRM_REGADDR(0x0324) +#define OMAP4_SCRM_RSTTIME_OFFSET 0x0400 +#define OMAP4_SCRM_RSTTIME OMAP44XX_SCRM_REGADDR(0x0400) +#define
Re: [PATCH] ARM: OMAP: Power on EHCI, serial, camera and DVI on beagleboard-xM
Any comments on this?
Op 7 dec 2010, om 13:40 heeft Koen Kooi het volgende geschreven:
From: Koen Kooi k...@dominion.thruhere.net
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f1a8ede..9c9bd96 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,12 +297,31 @@ static int beagle_twl_gpio_setup(struct device *dev,
gpio_request(gpio + 1, EHCI_nOC);
gpio_direction_input(gpio + 1);
- /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */
+ /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
+ * high / others active low) */
gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR);
- gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+ else
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+
+ /* DVI reset GPIO is different between revisions */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ beagle_dvi_device.reset_gpio = 129;
+ else
+ beagle_dvi_device.reset_gpio = 170;
+
+ /* Power on DVI, Serial and PWR led */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, nDVI_PWR_EN);
+ gpio_direction_output(gpio + 1, 0);
+ }
- /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
- gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ /* Power on camera interface on P7/P8 or DVI on A2 and beyond */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
return 0;
}
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 01/17] OMAP2420: hwmod data: add DSS DISPC RFBI VENC
Hi, On Tue, 2010-12-14 at 11:37 +0530, ext Guruswamy, Senthilvadivu wrote: Tomi, [Senthil] I see in patch work that the whole of this series is delegated to you. Could you please act on this and let me know if there is anything pending from my side ? I'll try to find time to look through the patch set this week. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens, On Tuesday 14 December 2010 14:31:55 Clemens Ladisch wrote: Laurent Pinchart wrote: On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: TYPE_EXT describes entities that represent some interface to the external world, TYPE_INT those that are internal to the entire device. (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems to be an even more meaningless name.) SUBDEV comes from the V4L2 world, and I agree that it might not be a very good name. I'm not sure I would split entities in internal/external categories. I would create a category for connectors though. I'm not disagreeing, but what is actually the distinction between types and subtypes? ;-) The type is currently used to distinguish between entities that stream media data from/to memory and other entities. They need to be handled differently in the kernel for power management purposes for instance. I'm not sure if we should create new types, or just remove the type/subtype distinction and add a flag somewhere. * Entity properties There needs to be a mechanism to associate meta-information (properties) with entities. This information should be optional and extensible, but, when being handled inside the kernel, doesn't need to be more than a read-only blob. I think that something like ALSA's TLV format (used for mixer controls) can be used here. (I'm not mentioning the X-word here, except to note that the M stands for markup.) I've been thinking of adding a new ioctl for that. It's something we need to draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers would find it useful as well. I'm imagining a read-the-properties ioctl that just returns the entity's blob. Martin Rubli has already proposed something similar a while ago on the linux- media mailing list. His proposal didn't use TLV though. EXT_SPEAKER also includes headphones; there might be made a case for having those as a separate subtype. Shouldn't headphones be represented by an EXT_JACK_ANALOG ? Headphone jacks are jacks; there are also USB headphones. So EXT_SPEAKER are speakers not connected through a jack (USB, internal analog, ...) ? EXT_BROADCAST represents devices like TV tuners, satellite receivers, cable tuners, or radios. There's clearly an overlap with V4L here. These come from the USB audio spec. Video devices are indeed likely to be more detailed than just a single audio source. :) Does EXT_BROADCAST represent the TV tuner (or satellite receiver, cable tuner, radio tuner, ...) itself, or the connection between the tuner and the rest of the device ? Most TV tuner are currently handled by V4L2 and would thus turn up as V4L2 subdevs (I'm not sure if that's what we want in the long term, but it's at least the current situation). INT_CONTROLS may have multiple independent controls (this is USB's Feature Unit); INT_EFFECT may have multiple controls that affect one single algorithm. I'd describe this as a feature unit/processing unit then. I was aiming for more descriptive names, but I agree that the original names might be more useful. Should we have an AUDIO category ? Probably not, because there are combined audio/video jacks, any maybe other entities. * Entity specifications While TYPE_DEVICE entities can be identified by their device node, other entities typcially have just a numeric ID. In V4L2 sub-devices have (or rather will have once the media controller patches will be integrated) device nodes as well, so exposing that information is required. USB and HDA entities already have numeric IDs. Right. Same for USB Video Class. We could let drivers set the entity ID, and have the core fill it if the value is 0. Non-zero values would have to be checked for uniqueness though. Hans, a comment on that ? For that, it would be useful to make do without separate identification and let the driver choose the entity ID. How would drivers do that ? What if you have two instances of the same chip (a video sensor, audio mixer, ...) on the same board ? Then those would get different IDs; USB descriptors always describe the entire device. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Power on EHCI, serial, camera and DVI on beagleboard-xM
On 12/14/2010 7:41 PM, Koen Kooi wrote:
Any comments on this?
Op 7 dec 2010, om 13:40 heeft Koen Kooi het volgende geschreven:
From: Koen Kooi k...@dominion.thruhere.net
You may want to add a description here. For instance you're
making the PMU STAT led disappear - and I'm not sure it's
deliberate.
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f1a8ede..9c9bd96 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,12 +297,31 @@ static int beagle_twl_gpio_setup(struct device *dev,
gpio_request(gpio + 1, EHCI_nOC);
gpio_direction_input(gpio + 1);
-/* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */
+/* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
+ * high / others active low) */
Just nitpicking. The multi-line comments are not as per
Documentation/CodingStyle.
gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR);
-gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+else
+gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+
+/* DVI reset GPIO is different between revisions */
+if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+beagle_dvi_device.reset_gpio = 129;
+else
+beagle_dvi_device.reset_gpio = 170;
+
+ /* Power on DVI, Serial and PWR led */
+if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+gpio_request(gpio + 1, nDVI_PWR_EN);
+gpio_direction_output(gpio + 1, 0);
+}
-/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
-gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
This disappeared. So no more PMU STAT led?
+/* Power on camera interface on P7/P8 or DVI on A2 and beyond */
+if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+gpio_request(gpio + 2, CAM_EN);
+gpio_direction_output(gpio + 2, 1);
+}
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Introduce hardware spinlock framework
Hi Greg, Tony, On Sat, Dec 4, 2010 at 1:50 AM, Ohad Ben-Cohen o...@wizery.com wrote: OMAP4 introduces a Hardware Spinlock device, which provides hardware assistance for synchronization and mutual exclusion between heterogeneous processors and those not operating under a single, shared operating system (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP). The intention of this hardware device is to allow remote processors, that have no alternative mechanism to accomplish synchronization and mutual exclusion operations, to share resources (such as memory and/or any other hardware resource). This patchset adds hwspinlock framework that makes it possible for drivers to use those hwspinlock devices and stay platform-independent. ... Documentation/hwspinlock.txt | 299 +++ arch/arm/mach-omap2/Makefile | 1 + arch/arm/mach-omap2/hwspinlock.c | 63 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 64 drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/hwspinlock/Kconfig | 22 ++ drivers/hwspinlock/Makefile | 6 + drivers/hwspinlock/hwspinlock.h | 61 +++ drivers/hwspinlock/hwspinlock_core.c | 557 drivers/hwspinlock/omap_hwspinlock.c | 231 include/linux/hwspinlock.h | 298 +++ 12 files changed, 1605 insertions(+), 0 deletions(-) Can you please have a look and say if this looks OK ? If it does, where would you prefer this to go through ? Thanks, Ohad. -- 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 00/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38,part two
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, December 08, 2010 11:48 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Mark Brown; Benoît Cousson; Kevin Hilman; Rajendra Nayak; Peter
Ujfalusi; Santosh Shilimkar; Jarkko Nikula; Liam
Girdwood
Subject: [PATCH 00/11] OMAP: PRCM/powerdomain/clockdomain patches for
2.6.38,part two
This patch series, intended for 2.6.38:
- adds OMAP4-specific PRM and CM instance functions, which are capable
of writing to PRM/CM instances, no matter what PRCM partition they
appear in;
- renames the old OMAP2/3 PRM and CM functions to prefix them with
'omap2_';
- adds OMAP4 clockdomain offset addressing to the OMAP4 clockdomain
definitions;
- removes the (now unused) OMAP clockdomain .clkstctrl_reg field;
- moves plat-omap/include/plat/{clock,power}domain.h to mach-omap2/,
since
these are OMAP2-specific;
- moves the OMAP3 SCM padconf save code from pm34xx.c into the SCM
common
code.
This series is available via git from git://git.pwsan.com/linux-2.6 in
the branch 'pwrdm_prcm_b_2.6.38'. It applies on top of the OMAP:
PRCM/powerdomain/clockdomain patches for 2.6.38, part one series,
sent earlier.
Kevin and OMAP ASoC-hackers, I'd appreciate review and acks, if
appropriate, on the patches that touch code that you maintain. TI
OMAP4 PM people, I would appreciate any testing assistance that you
may be able to provide. Benoît, I've tried to keep the kernel data
files and the output of the scripts relatively similar, but we might
need to do some tweaking of the scripts or data files to align them
in the way that makes the most sense.
Boot-tested on N800, OMAP35xx Beagle, and OMAP4430ES2 Panda.
Boot tested on 2430/3430/4430SDP. Tested RET/OFF mode in suspend
on 3430SDP with minimal config (omap3_pm_defconfig).
- Paul
---
pwrdm_prcm_b_2.6.38
text data bss dec hex filename
5709988473952 5608800 11792740 b3f164 vmlinux.orig
5712868474496 5608800 11796164 b3fec4 vmlinux.patched
Paul Walmsley (11):
OMAP4: PRCM: add OMAP4-specific accessor/mutator functions
OMAP4: PRCM: move global reset function for OMAP4 to an
OMAP4-specific file
OMAP2/3: PRM/CM: prefix OMAP2 PRM/CM functions with omap2_
OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM
functions
OMAP2+: clockdomains: split the clkdm hwsup enable/disable
function
OMAP4: CM instances: add clockdomain register offsets
OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support
OMAP2/3: clockdomain: remove unneeded .clkstctrl_reg, remove some
direct CM register accesses
OMAP2+: clockdomain: move header file from plat-omap to mach-omap2
OMAP2+: powerdomain: move header file from plat-omap to mach-omap2
OMAP3: control/PM: move padconf save code to mach-omap2/control.c
arch/arm/mach-omap2/Makefile |4
arch/arm/mach-omap2/clkt2xxx_apll.c | 10 -
arch/arm/mach-omap2/clkt2xxx_dpllcore.c |8
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 12 -
arch/arm/mach-omap2/clock.c |2
arch/arm/mach-omap2/clockdomain.c| 209 ++-
arch/arm/mach-omap2/clockdomain.h| 33 +-
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 42 --
arch/arm/mach-omap2/clockdomains44xx_data.c | 123 --
arch/arm/mach-omap2/cm-regbits-24xx.h|5
arch/arm/mach-omap2/cm-regbits-34xx.h| 11 +
arch/arm/mach-omap2/cm1_44xx.h | 10 +
arch/arm/mach-omap2/cm2_44xx.h | 25 +
arch/arm/mach-omap2/cm2xxx_3xxx.c| 420
+-
arch/arm/mach-omap2/cm2xxx_3xxx.h| 19 +
arch/arm/mach-omap2/cm44xx.c | 52 +++
arch/arm/mach-omap2/cm4xxx.c | 62 ---
arch/arm/mach-omap2/cminst44xx.c | 223
arch/arm/mach-omap2/control.c| 72 +++-
arch/arm/mach-omap2/control.h|1
arch/arm/mach-omap2/cpuidle34xx.c|4
arch/arm/mach-omap2/io.c |4
arch/arm/mach-omap2/omap_hwmod.c |4
arch/arm/mach-omap2/pm-debug.c | 12 -
arch/arm/mach-omap2/pm.c |4
arch/arm/mach-omap2/pm.h |2
arch/arm/mach-omap2/pm24xx.c | 200 +-
arch/arm/mach-omap2/pm34xx.c | 162
arch/arm/mach-omap2/pm44xx.c |2
arch/arm/mach-omap2/powerdomain-common.c |1
arch/arm/mach-omap2/powerdomain.c| 14 +
arch/arm/mach-omap2/powerdomain.h| 30 +-
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 68 ++--
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens, Laurent, Hans others! Clemens Ladisch wrote: I wrote: I'll see if I can draw up the ALSA-specific media stuff over the weekend. Sorry, wrong weekend. Anyway, below are some remarks and a patch. * Entity types TYPE_NODE was renamed to TYPE_DEVICE because node sounds like a node in a graph, which does not distinguish it from other entity types because all entities are part of the topology graph. I chose device as this type describes entities that are visible as some device node to other software. TYPE_EXT describes entities that represent some interface to the external world, TYPE_INT those that are internal to the entire device. (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems to be an even more meaningless name.) ALSA mixer controls are not directly represented; a better fit for the architecture of actual devices is that one or more mixer controls can be associated with an entity. (This can be done with a field of the mixer control.) * Entity properties There needs to be a mechanism to associate meta-information (properties) with entities. This information should be optional and extensible, but, when being handled inside the kernel, doesn't need to be more than a read-only blob. I think that something like ALSA's TLV format (used for mixer controls) can be used here. (I'm not mentioning the X-word here, except to note that the M stands for markup.) * Entity subtypes EXT_JACK_ANALOG represents any analog audio and/or video connector. Properties for audio jacks would be jack type (TRS/RCA), color code, line level, position, etc. EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/ TOSLINK), ADAT, TDIF, or MADI. EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio spec. (I doubt that any devices with this entitiy will ever exist.) EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI controller. (Instrument entities are typically audio sources and MIDI sources and sinks, but can also be audio sinks.) EXT_SPEAKER also includes headphones; there might be made a case for having those as a separate subtype. EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can also write to that device, so player might not be an ideal name. EXT_BROADCAST represents devices like TV tuners, satellite receivers, cable tuners, or radios. INT_SYNTHESIZER converts MIDI to audio. INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt to describe the characteristics of consumer-grade devices :-) , but represents an internal noise source for level calibration or measurements. INT_CONTROLS may have multiple independent controls (this is USB's Feature Unit); INT_EFFECT may have multiple controls that affect one single algorithm. INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology information has only stereo links. This naming already has been commented, but what do you think: should the type explicitly tell what kind of interface, if any, is exported to user space? Only MEDIA_ENTITY_NODE_* types do this currently, and MEDIA_ENTITY_TYPE_SUBDEV_* to some extent, but the way is not consistent at the moment. MEDIA_ENTITY_NODE_* range has lost of different interfaces whereas MEDIA_ENTITY_TYPE_SUBDEV_* are basically offering v4l2_subdev and beyond that, suggesting what kind of controls might be found from the nodes. I would expect that the interfaces offered by the character devices would be somewhat standardised in the end like v4l2_subdev user space interface. The types above are mostly describing the role of an entity, which might be interesting as well. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Hans, On Tuesday 14 December 2010 15:51:08 Hans Verkuil wrote: Laurent Pinchart wrote: On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: TYPE_EXT describes entities that represent some interface to the external world, TYPE_INT those that are internal to the entire device. (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems to be an even more meaningless name.) SUBDEV comes from the V4L2 world, and I agree that it might not be a very good name. I'm not sure I would split entities in internal/external categories. I would create a category for connectors though. I'm not disagreeing, but what is actually the distinction between types and subtypes? ;-) The type tells what the behavior is of an entity. E.g., type DEVNODE represents device node(s) in userspace, V4L2_SUBDEV represents a v4l2 sub-device, etc. The subtype tells whether a V4L2_SUBDEV is a sensor or a receiver or whatever. Nice to know, but it doesn't change the way sub-devices work. In the case of connectors you would create a CONNECTOR type and have a bunch of subtypes for all the variations of connectors. That said, I'm not sure whether the distinction is useful for DEVNODEs. You do need to know the subtype in order to interpret the union correctly. Laurent, does the MC code test against the DEVNODE type? I.e., does the MC code ignore the subtype of a DEVNODE, or does it always use it? The MC code uses the DEVNODE type, ignoring the subtype, for power management. When a device node is opened all entities in the chain need to be powered up. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 4/4] omap: iommu - create new api to set valid da range
On Tue, Dec 14, 2010 at 3:07 PM, Fernando Guzman Lugo fernando.l...@ti.com wrote: From: Guzman Lugo, Fernando x0095...@ti.com Some IOMMUs cannot use the whole 0x0 - 0x rage. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com I still don't see where this API is being used. Also, the point of using platform data was to add it to omap3_devices in omap-iommu.c, see[1]. I thought the platform data start/end would move to struct iommu, and iommu_set_da_range would change the start/end on struct iommu, but that would only be necessary if the platform data doesn't match that. If there's no sensible platform data default, then there's no point in using platform data, as the platform is not the limiting factor, but the DSP SW. [1] http://article.gmane.org/gmane.linux.kernel/1051268 -- 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 v7] Enable Runtime PM functionality in OMAP4 driver based on the following assumptions:
From: Abraham Arce x0066...@ti.com - Runtime PM selected by ARCH_OMAP2PLUS_TYPICAL ARCH_OMAP2PLUS, which is the default OMAP2+ defconfig including OMAP4 - Runtime PM APIs handles Clock Framework APIs - Do not do the keypadconfig if the irq request fails A minimal pm runtime get/put approach is implemented in probe/remove calls respectively based on: - Keyboard controller in wakeup domain so it is always on and power impact may be minimal - Cutting of clocks will prevent interrupts Signed-off-by: Abraham Arce x0066...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- Updating the changelogs as per Kevin's suggestion drivers/input/keyboard/omap4-keypad.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 45bd097..36239e2 100644 --- a/drivers/input/keyboard/omap4-keypad.c +++ b/drivers/input/keyboard/omap4-keypad.c @@ -29,6 +29,7 @@ #include linux/io.h #include linux/input.h #include linux/slab.h +#include linux/pm_runtime.h #include plat/omap4-keypad.h @@ -239,7 +240,8 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev) matrix_keypad_build_keymap(pdata-keymap_data, row_shift, input_dev-keycode, input_dev-keybit); - omap4_keypad_config(keypad_data); + pm_runtime_enable(pdev-dev); + pm_runtime_get_sync(pdev-dev); error = request_irq(keypad_data-irq, omap4_keypad_interrupt, IRQF_TRIGGER_RISING, @@ -255,8 +257,9 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev) goto err_free_irq; } - + omap4_keypad_config(keypad_data); platform_set_drvdata(pdev, keypad_data); + return 0; err_free_irq: @@ -278,6 +281,10 @@ static int __devexit omap4_keypad_remove(struct platform_device *pdev) struct resource *res; free_irq(keypad_data-irq, keypad_data); + + pm_runtime_put_sync(pdev-dev); + pm_runtime_disable(pdev-dev); + input_unregister_device(keypad_data-input); iounmap(keypad_data-base); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Laurent Pinchart wrote: On Tuesday 14 December 2010 14:31:55 Clemens Ladisch wrote: Laurent Pinchart wrote: On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: EXT_SPEAKER also includes headphones; there might be made a case for having those as a separate subtype. Shouldn't headphones be represented by an EXT_JACK_ANALOG ? Headphone jacks are jacks; there are also USB headphones. So EXT_SPEAKER are speakers not connected through a jack (USB, internal analog, ...) ? Yes. When there is jack, the driver often does not know what is connected. EXT_BROADCAST represents devices like TV tuners, satellite receivers, cable tuners, or radios. There's clearly an overlap with V4L here. These come from the USB audio spec. Video devices are indeed likely to be more detailed than just a single audio source. :) Does EXT_BROADCAST represent the TV tuner (or satellite receiver, cable tuner, radio tuner, ...) itself, or the connection between the tuner and the rest of the device ? Most TV tuner are currently handled by V4L2 and would thus turn up as V4L2 subdevs (I'm not sure if that's what we want in the long term, but it's at least the current situation). From the point of view of an audio device, this would be just some audio source, much like a connector. We don't need this if there is some better V4L entitity that the USB audio entity can be mapped to. Regards, Clemens -- 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 v7] OMAP4:keypad: PM runtime
From: Abraham Arce x0066...@ti.com Enable Runtime PM functionality in OMAP4 driver based on the following assumptions - Runtime PM selected by ARCH_OMAP2PLUS_TYPICAL ARCH_OMAP2PLUS, which is the default OMAP2+ defconfig including OMAP4 - Runtime PM APIs handles Clock Framework APIs - Do not do the keypadconfig if the irq request fails A minimal pm runtime get/put approach is implemented in probe/remove calls respectively based on: - Keyboard controller in wakeup domain so it is always on and power impact may be minimal - Cutting of clocks will prevent interrupts Signed-off-by: Abraham Arce x0066...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- Updating the changelogs as per Kevin's suggestion drivers/input/keyboard/omap4-keypad.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 45bd097..36239e2 100644 --- a/drivers/input/keyboard/omap4-keypad.c +++ b/drivers/input/keyboard/omap4-keypad.c @@ -29,6 +29,7 @@ #include linux/io.h #include linux/input.h #include linux/slab.h +#include linux/pm_runtime.h #include plat/omap4-keypad.h @@ -239,7 +240,8 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev) matrix_keypad_build_keymap(pdata-keymap_data, row_shift, input_dev-keycode, input_dev-keybit); - omap4_keypad_config(keypad_data); + pm_runtime_enable(pdev-dev); + pm_runtime_get_sync(pdev-dev); error = request_irq(keypad_data-irq, omap4_keypad_interrupt, IRQF_TRIGGER_RISING, @@ -255,8 +257,9 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev) goto err_free_irq; } - + omap4_keypad_config(keypad_data); platform_set_drvdata(pdev, keypad_data); + return 0; err_free_irq: @@ -278,6 +281,10 @@ static int __devexit omap4_keypad_remove(struct platform_device *pdev) struct resource *res; free_irq(keypad_data-irq, keypad_data); + + pm_runtime_put_sync(pdev-dev); + pm_runtime_disable(pdev-dev); + input_unregister_device(keypad_data-input); iounmap(keypad_data-base); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/12] dmtimer adaptation to platform_driver
dmtimer adaptation to platform_driver.
This patch series is adaptation of dmtimer code to platform driver
using omap_device and omap_hwmod abstraction.
Tested on following platforms:
OMAP4430, OMAP3430, OMAP3630, OMAP2430
OMAP2420, OMAP1710(in-progress)
Baseline:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
v6:
(1) Removed reset functions to mach-omap1/dmtimer.c.
Access to reset function from plat-omap/dmtimer.c is provided by means
of function pointer.
(2) Remove multiple calls to omap_device_build() for registering timer devices
during early and regular initialization. Regular device registration is now done
by reading data from temporary list. This list is populated during early init
where timer data is read from hwmod database and corresponding memory allocated.
(3) kfree(pdata) under error condition since platform_device_unregister does
not free its pdata.
(4) Removed extra header inclusion in mach-omap2 and plat-omap
NOTE: omap_dm_timer.id field could not be removed because during regular boot
there is no mechanism to match the current pdev with corresponding entry in the
timer list which was partially initialized during early boot.
TODO:
(1) OFF Mode support
(2) Upgrade timeout implementation in low-level read/write access to return
error condition to EXPORT APIs. This is re-frained in the present implementation
because that would involve change to EXPORTED APIs. Besides, there is no clear
design as yet which is agreed upon by the community.
v4:
(1) clock aliases are renamed as 32k_ck, sys_ck and alt_ck
(2) incorporate missing clk_put() for corresponding clk_get()
(3) modified clk_get()/clk_put() to be called once once in platform driver.
(4) consistent header for new files
(5) check return value of omap_hwmod_for_each_by_class() in device init
routines.
(6) remove is_abe_timer field in dmtimer_platform_data structure. this is
no longer needed with new input clock source aliasing.
(7) proper splitting of patch series
(8) remove register map from hwmod database.
(9) remove clock source strings array from hwmod database and associated
structure declaration from plat/dmtimer.h. this is no longer needed.
(10) remove dev_attr from hwmod database. this is no longer needed.
(11) use register offsets to identify OMAP 4 registers instead of register map.
(12) remove clock source name strings from hwmod database.
(13) introduce new mechanism for getting struct clk associated with clock source
names. this is achieved by adding clock alisases for all supported clock
sources.
(14) remove clock setup functions in mach-omap2 for populating struct clk
associated with all input clock sources because this is no longer needed with
above implementation.
(15) device names changed from dmtimer to omap-timer
(16) device index starts from 1 instead of 0
(17) remove .init_name from hwmod database. this is not needed.
(18) introduce separate functions for reading/writing interrupt registers
instead of
doing all operations within a single function.
v3:
(1) multi-line comment error correction
(2) provision to allow any of the available dmtimers as early timers
instead of restricting them to millisecond timers only.
(3) in 'struct omap_dmtimer{}' is_initialized flag is redundant and
so must be removed. if the element is found in the list it is already
initialized.
(4) remove 'found' flag in omap_dm_timer_request() and
omap_dm_timer_request_specific() functions.
this is not needed with alternate implementation.
(5) use .init_name to initialize device names so that it can be identified
during early boot as well. This is to avoid duplicate functions for clock
manipulations during early boot and later.
(6) remove redundant functions from mach-omap2 which are created just to
call pm functions like: pm_runtime_get_sync(),pm_runtime_put_sync(),..
and instead call them directly from plat-omap function api's.
(7) timer clock source names made part of hwmod database. source_clock[]
of type 'struct clk' is made part of platform data.
(8) clockactivity field initialized in hwmod database to preserve fclk
during idle. code which manipulate OCP config removed since they are
already taken care by hwmod framework.
(9) omap2_dm_timer_set_src() is optimized. Clock enable/disbale routines
moved to plat-omap layer and simplfied to the level so as not to sacrifice
intended functionality.
NOTE: During early boot clock management was requested to be placed upon
client drivers responsibility. this has not been done keeping in mind
that it would entail (i) multiple modifications of client drivers (ii) it
would violate the purpose of having a framework (open to debate).
(10) dmtimer register maps moved to hwmod database
v2:
(1) removed dedicated functions for early timer clock access.
instead, now we have common functions for early and normal timers.
(2) removed usage of clock source strings for reading corresponding
struct clks. this is now achieved through clock aliases introduced
for each input clock sources.
[PATCH v6 2/12] OMAP2420: hwmod data: add dmtimer
From: Thara Gopinath th...@ti.com
Add dmtimer data.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 634
arch/arm/plat-omap/include/plat/dmtimer.h | 11 +
2 files changed, 645 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index adf6e36..0ce3f7f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,6 +16,7 @@
#include plat/cpu.h
#include plat/dma.h
#include plat/serial.h
+#include plat/dmtimer.h
#include omap_hwmod_common_data.h
@@ -228,6 +229,625 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
+/* Timer Common */
+static struct omap_hwmod_class_sysconfig omap2420_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_timer_hwmod_class = {
+ .name = timer,
+ .sysc = omap2420_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+/* timer1 */
+static struct omap_hwmod omap2420_timer1_hwmod;
+static struct omap_hwmod_irq_info omap2420_timer1_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIMER1, },
+};
+
+static struct omap_hwmod_addr_space omap2420_timer1_addrs[] = {
+ {
+ .pa_start = 0x48028000,
+ .pa_end = 0x48028000 + SZ_1K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup - timer1 */
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__timer1 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_timer1_hwmod,
+ .clk= gpt1_ick,
+ .addr = omap2420_timer1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_timer1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave port */
+static struct omap_hwmod_ocp_if *omap2420_timer1_slaves[] = {
+ omap2420_l4_wkup__timer1,
+};
+
+/* timer1 hwmod */
+static struct omap_hwmod omap2420_timer1_hwmod = {
+ .name = timer1,
+ .mpu_irqs = omap2420_timer1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_timer1_mpu_irqs),
+ .main_clk = gpt1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+ },
+ },
+ .slaves = omap2420_timer1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_timer1_slaves),
+ .class = omap2420_timer_hwmod_class,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+};
+
+/* timer2 */
+static struct omap_hwmod omap2420_timer2_hwmod;
+static struct omap_hwmod_irq_info omap2420_timer2_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIMER2, },
+};
+
+static struct omap_hwmod_addr_space omap2420_timer2_addrs[] = {
+ {
+ .pa_start = 0x4802a000,
+ .pa_end = 0x4802a000 + SZ_1K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - timer2 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__timer2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_timer2_hwmod,
+ .clk= gpt2_ick,
+ .addr = omap2420_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer2 slave port */
+static struct omap_hwmod_ocp_if *omap2420_timer2_slaves[] = {
+ omap2420_l4_core__timer2,
+};
+
+/* timer2 hwmod */
+static struct omap_hwmod omap2420_timer2_hwmod = {
+ .name = timer2,
+ .mpu_irqs = omap2420_timer2_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_timer2_mpu_irqs),
+ .main_clk = gpt2_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT2_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT2_SHIFT,
+ },
+ },
+ .slaves = omap2420_timer2_slaves,
+
[PATCH v6 12/12] OMAP2: dmtimer: set wakeup enable explicitly in plat
For some reason the wakeup enable bit is not getting set on OMAP2430,
OMAP2420. This is inspite of the fact that SYSC_HAS_ENAWAKEUP flag is
present in the hwmod database. Until the reason is found we need this
patch to boot on the above platforms.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 4ef25de..2ea0a7b 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -227,6 +227,7 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
+ u32 l;
struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
timer-fclk = clk_get(timer-pdev-dev, fck);
@@ -240,6 +241,18 @@ static void omap_dm_timer_prepare(struct omap_dm_timer
*timer)
if (cpu_is_omap16xx())
pdata-dm_timer_reset(timer);
+ /*
+* Enable wake-up on OMAP2420, OMAP2430 CPUs.
+* FIXME: SYSC_HAS_ENAWAKEUP flag is already set in hwmod database.
+* But the setting does not seem to work. Need to investigate why
+* this is happening.
+*/
+ if (is_omap2430() || is_omap2420()) {
+ l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG);
+ l |= 1 2;
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_REG, l);
+ }
+
omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
/* Match hardware reset default of posted mode */
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 9/12] OMAP: dmtimer: switch-over to platform device driver
switch-over to platform device driver through following changes:
(a) call to dmtimer initialization routine from timer-gp.c is
removed (b) initiate dmtimer early initialization from omap2_init_common_hw
in io.c (c) modify plat-omap/dmtimer routines to use new register map and
platform data.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/clock44xx_data.c |2 +-
arch/arm/mach-omap2/dmtimer.c | 60 ++
arch/arm/mach-omap2/dmtimer.h | 30 +++
arch/arm/mach-omap2/io.c |2 +
arch/arm/mach-omap2/timer-gp.c|1 -
arch/arm/plat-omap/dmtimer.c | 328 +++-
arch/arm/plat-omap/include/plat/dmtimer.h |6 +-
10 files changed, 179 insertions(+), 256 deletions(-)
create mode 100644 arch/arm/mach-omap2/dmtimer.h
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index d140807..d4ad8ce 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1801,7 +1801,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, virt_prcm_set, virt_prcm_set, CK_242X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL, gpt1_ick, gpt1_ick, CK_242X),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_242X),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_242X),
CLK(NULL, gpt2_ick, gpt2_ick, CK_242X),
CLK(omap_timer.2, fck, gpt2_fck, CK_242X),
CLK(NULL, gpt3_ick, gpt3_ick, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index a29b042..0514514 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1905,7 +1905,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, virt_prcm_set, virt_prcm_set, CK_243X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL, gpt1_ick, gpt1_ick, CK_243X),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_243X),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_243X),
CLK(NULL, gpt2_ick, gpt2_ick, CK_243X),
CLK(omap_timer.2, fck, gpt2_fck, CK_243X),
CLK(NULL, gpt3_ick, gpt3_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 3d9c4ef..ec5997b 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3361,7 +3361,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2 |
CK_AM35XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2 | CK_AM35XX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2),
- CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
+ CLK(omap_timer.1, fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
CLK(NULL, gpio1_dbck, gpio1_dbck,CK_3XXX),
CLK(omap_wdt, fck, wdt2_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index be0737c..a62743e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2921,7 +2921,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, smartreflex_core_fck, smartreflex_core_fck,
CK_443X),
CLK(NULL, smartreflex_iva_fck, smartreflex_iva_fck,
CK_443X),
CLK(NULL, smartreflex_mpu_fck, smartreflex_mpu_fck,
CK_443X),
- CLK(NULL, gpt1_fck, timer1_fck,
CK_443X),
+ CLK(omap_timer.1, fck, timer1_fck,CK_443X),
CLK(omap_timer.10,fck, timer10_fck, CK_443X),
CLK(omap_timer.11,fck, timer11_fck, CK_443X),
CLK(omap_timer.2, fck, timer2_fck,CK_443X),
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
index f251ad0..6bfedde 100644
--- a/arch/arm/mach-omap2/dmtimer.c
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -192,3 +192,63 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
return ret;
}
+
+/**
+ * omap2_dm_timer_early_init - top level early timer initialization
+ * called in the last part of omap2_init_common_hw
+ *
+ * Uses dedicated hwmod api to parse through hwmod database for
+ * given class name and then build and register the timer device.
+ * At the end driver is registered and early probe initiated.
+ */
+void
[PATCH v6 11/12] OMAP: dmtimer: add timeout to low-level routines
The low-level read and write access routines wait on
write-pending register in posted mode to make sure that
previous write is complete on respective registers.
This waiting is done in an infinite while loop. Now it
is being modified to use timeout instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index e4849b7..4ef25de 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -41,6 +41,7 @@
#include linux/slab.h
#include linux/pm_runtime.h
#include linux/err.h
+#include plat/common.h
#include plat/dmtimer.h
/* register offsets */
@@ -152,6 +153,7 @@
#define OMAP_TIMER_TICK_INT_MASK_COUNT_REG \
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR WPSHIFT))
+#define MAX_WRITE_PEND_WAIT1 /* 10ms timeout delay */
static LIST_HEAD(omap_timer_list);
static DEFINE_SPINLOCK(dm_timer_lock);
@@ -168,16 +170,23 @@ static DEFINE_SPINLOCK(dm_timer_lock);
static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer, u32 reg)
{
struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+ int i = 0;
if (reg = OMAP_TIMER_WAKEUP_EN_REG)
reg += pdata-func_offset;
else if (reg = OMAP_TIMER_STAT_REG)
reg += pdata-intr_offset;
- if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
-(reg WPSHIFT))
- cpu_relax();
+ if (timer-posted) {
+ omap_test_timeout(!(readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG +
+ pdata-func_offset) 0xff)) (reg WPSHIFT)),
+ MAX_WRITE_PEND_WAIT, i);
+
+ if (WARN_ON_ONCE(i == MAX_WRITE_PEND_WAIT))
+ pr_err(: read timeout\n);
+ }
+
return readl(timer-io_base + (reg 0xff));
}
@@ -195,16 +204,23 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
u32 value)
{
struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+ int i = 0;
if (reg = OMAP_TIMER_WAKEUP_EN_REG)
reg += pdata-func_offset;
else if (reg = OMAP_TIMER_STAT_REG)
reg += pdata-intr_offset;
- if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
-(reg WPSHIFT))
- cpu_relax();
+ if (timer-posted) {
+ omap_test_timeout(!(readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG +
+ pdata-func_offset) 0xff)) (reg WPSHIFT)),
+ MAX_WRITE_PEND_WAIT, i);
+
+ if (WARN_ON(i == MAX_WRITE_PEND_WAIT))
+ pr_err(: write timeout\n);
+ }
+
writel(value, timer-io_base + (reg 0xff));
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/12] OMAP4: hwmod data: add dmtimer
From: Cousson, Benoit b-cous...@ti.com
Add dmtimer data.
Signed-off-by: Cousson, Benoit b-cous...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 623
arch/arm/plat-omap/include/plat/dmtimer.h |1 +
2 files changed, 624 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7274db4..6da3ae3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#include plat/omap_hwmod.h
#include plat/cpu.h
+#include plat/dmtimer.h
#include omap_hwmod_common_data.h
@@ -453,6 +454,614 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'timer' class
+ * general purpose timer module with accurate 1ms tick
+ * This class contains several variants: ['timer_1ms', 'timer']
+ */
+static struct omap_hwmod_class_sysconfig omap44xx_timer_1ms_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_timer_1ms_hwmod_class = {
+ .name = timer,
+ .sysc = omap44xx_timer_1ms_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_timer_hwmod_class = {
+ .name = timer,
+ .sysc = omap44xx_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_2,
+};
+
+/* timer1 */
+static struct omap_hwmod omap44xx_timer1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_timer1_irqs[] = {
+ { .irq = 37 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_timer1_addrs[] = {
+ {
+ .pa_start = 0x4a318000,
+ .pa_end = 0x4a31807f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup - timer1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__timer1 = {
+ .master = omap44xx_l4_wkup_hwmod,
+ .slave = omap44xx_timer1_hwmod,
+ .clk= l4_wkup_clk_mux_ck,
+ .addr = omap44xx_timer1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_timer1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {
+ omap44xx_l4_wkup__timer1,
+};
+
+static struct omap_hwmod omap44xx_timer1_hwmod = {
+ .name = timer1,
+ .class = omap44xx_timer_1ms_hwmod_class,
+ .mpu_irqs = omap44xx_timer1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
+ .main_clk = timer1_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_TIMER1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_timer1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_timer1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* timer2 */
+static struct omap_hwmod omap44xx_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_timer2_irqs[] = {
+ { .irq = 38 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_timer2_addrs[] = {
+ {
+ .pa_start = 0x48032000,
+ .pa_end = 0x4803207f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__timer2 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_timer2_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_timer2_slaves[] = {
+ omap44xx_l4_per__timer2,
+};
+
+static struct omap_hwmod omap44xx_timer2_hwmod = {
+ .name = timer2,
+ .class = omap44xx_timer_1ms_hwmod_class,
+ .mpu_irqs = omap44xx_timer2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer2_irqs),
+
[PATCH v6 10/12] OMAP: dmtimer: pm_runtime support
Add pm_runtime support to dmtimer. Since dmtimer is used during
early boot before pm_runtime is initialized completely there are
provisions to enable/disable clocks directly in the code during
early boot.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
[p-bas...@ti.com: added pm_runtime logic in probe()]
Signed-off-by: Partha Basak p-bas...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 38 --
1 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 3bae4b5..e4849b7 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -39,6 +39,7 @@
#include linux/delay.h
#include linux/io.h
#include linux/slab.h
+#include linux/pm_runtime.h
#include linux/err.h
#include plat/dmtimer.h
@@ -293,10 +294,22 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_free);
void omap_dm_timer_enable(struct omap_dm_timer *timer)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+
if (timer-enabled)
return;
- clk_enable(timer-fclk);
+ if (unlikely(pdata-is_early_init)) {
+ clk_enable(timer-fclk);
+ timer-enabled = 1;
+ return;
+ }
+
+ if (pm_runtime_get_sync(timer-pdev-dev)) {
+ dev_err(timer-pdev-dev, %s: pm_runtime_get_sync() FAILED\n,
+ __func__);
+ return;
+ }
timer-enabled = 1;
}
@@ -304,11 +317,22 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
void omap_dm_timer_disable(struct omap_dm_timer *timer)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+
if (!timer-enabled)
return;
- clk_disable(timer-fclk);
+ if (unlikely(pdata-is_early_init)) {
+ clk_disable(timer-fclk);
+ timer-enabled = 0;
+ return;
+ }
+ if (pm_runtime_put_sync(timer-pdev-dev)) {
+ dev_err(timer-pdev-dev, %s: pm_runtime_put_sync() FAILED\n,
+ __func__);
+ return;
+ }
timer-enabled = 0;
}
@@ -603,11 +627,21 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
return -ENODEV;
}
+ /*
+* Early timers are already registered and in list.
+* What we need to do during second phase of probe
+* is to assign the newly allocated/configured pdev
+* to timer-pdev. We also call pm_runtime_enable()
+* for each device because it could not be called
+* during early boot because pm_runtime framework
+* was not yet up and running.
+*/
spin_lock_irqsave(dm_timer_lock, flags);
list_for_each_entry(timer, omap_timer_list, node)
if (!pdata-is_early_init timer-id == pdev-id) {
timer-pdev = pdev;
spin_unlock_irqrestore(dm_timer_lock, flags);
+ pm_runtime_enable(pdev-dev);
dev_dbg(pdev-dev, Regular Probed\n);
return 0;
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 8/12] OMAP: dmtimer: platform driver
Add dmtimer platform driver functions which include:
(1) platform driver initialization
(2) driver probe function
(3) driver remove function
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 169 -
arch/arm/plat-omap/include/plat/dmtimer.h |4 +
2 files changed, 170 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 1bfaf09..f3eb032 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -43,6 +43,8 @@
#include linux/delay.h
#include linux/io.h
#include linux/module.h
+#include linux/slab.h
+#include linux/err.h
#include mach/hardware.h
#include plat/dmtimer.h
#include mach/irqs.h
@@ -257,7 +259,8 @@ static struct omap_dm_timer *dm_timers;
static const char **dm_source_names;
static struct clk **dm_source_clocks;
-static spinlock_t dm_timer_lock;
+static LIST_HEAD(omap_timer_list);
+static DEFINE_SPINLOCK(dm_timer_lock);
/*
* Reads timer registers in posted and non-posted mode. The posted mode bit
@@ -689,6 +692,168 @@ int omap_dm_timers_active(void)
}
EXPORT_SYMBOL_GPL(omap_dm_timers_active);
+/**
+ * omap_dm_timer_probe - probe function called for every registered device
+ * @pdev: pointer to current timer platform device
+ *
+ * Called by driver framework at the end of device registration for all
+ * timer devices.
+ */
+static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
+{
+ int ret;
+ unsigned long flags;
+ struct omap_dm_timer *timer;
+ struct resource *mem, *irq, *ioarea;
+ struct dmtimer_platform_data *pdata = pdev-dev.platform_data;
+
+ dev_dbg(pdev-dev, %s: +\n, __func__);
+
+ if (!pdata) {
+ dev_err(pdev-dev, %s: no platform data\n, __func__);
+ return -ENODEV;
+ }
+
+ spin_lock_irqsave(dm_timer_lock, flags);
+ list_for_each_entry(timer, omap_timer_list, node)
+ if (!pdata-is_early_init timer-id == pdev-id) {
+ timer-pdev = pdev;
+ spin_unlock_irqrestore(dm_timer_lock, flags);
+ dev_dbg(pdev-dev, Regular Probed\n);
+ return 0;
+ }
+ spin_unlock_irqrestore(dm_timer_lock, flags);
+
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (unlikely(!irq)) {
+ dev_err(pdev-dev, %s: no IRQ resource\n, __func__);
+ ret = -ENODEV;
+ goto err_free_pdev;
+ }
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (unlikely(!mem)) {
+ dev_err(pdev-dev, %s: no memory resource\n, __func__);
+ ret = -ENODEV;
+ goto err_free_pdev;
+ }
+
+ ioarea = request_mem_region(mem-start, resource_size(mem),
+ pdev-name);
+ if (!ioarea) {
+ dev_err(pdev-dev, %s: region already claimed\n, __func__);
+ ret = -EBUSY;
+ goto err_free_pdev;
+ }
+
+ timer = kzalloc(sizeof(struct omap_dm_timer), GFP_KERNEL);
+ if (!timer) {
+ dev_err(pdev-dev, %s: no memory for omap_dm_timer\n,
+ __func__);
+ ret = -ENOMEM;
+ goto err_release_ioregion;
+ }
+
+ timer-io_base = ioremap(mem-start, resource_size(mem));
+ if (!timer-io_base) {
+ dev_err(pdev-dev, %s: ioremap failed\n, __func__);
+ ret = -ENOMEM;
+ goto err_free_mem;
+ }
+
+ /*
+* Following func pointers are required by OMAP1's reset code
+* in mach-omap1/dmtimer.c to access to low level read/write.
+*/
+ if (cpu_is_omap16xx()) {
+ pdata-dm_timer_read_reg = omap_dm_timer_read_reg;
+ pdata-dm_timer_write_reg = omap_dm_timer_write_reg;
+ }
+
+ timer-id = pdev-id;
+ timer-irq = irq-start;
+ timer-pdev = pdev;
+ timer-reserved = 0;
+
+ /* add the timer element to the list */
+ spin_lock_irqsave(dm_timer_lock, flags);
+ list_add_tail(timer-node, omap_timer_list);
+ spin_unlock_irqrestore(dm_timer_lock, flags);
+
+ dev_dbg(pdev-dev, Early Probed\n);
+
+ return 0;
+
+err_free_mem:
+ kfree(timer);
+
+err_release_ioregion:
+ release_mem_region(mem-start, resource_size(mem));
+
+err_free_pdev:
+ kfree(pdata);
+ platform_device_unregister(pdev);
+
+ return ret;
+}
+
+/**
+ * omap_dm_timer_remove - cleanup a registered timer device
+ * @pdev: pointer to current timer platform device
+ *
+ * Called by driver framework whenever a timer device is unregistered.
+ * In addition to freeing platform resources it also deletes the timer
+ *
[PATCH v6 7/12] OMAP2+: dmtimer: convert to platform devices
Add routines to converts dmtimers to platform devices. The device data
is obtained from hwmod database of respective platform and is registered
to device model after successful binding to driver. It also provides
provision to access timers during early boot when pm_runtime framework
is not completely up and running.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/dmtimer.c | 194 +
2 files changed, 195 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/dmtimer.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..7700ccd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \
-common.o
+common.o dmtimer.o
omap-2-3-common= irq.o sdrc.o prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
new file mode 100644
index 000..f251ad0
--- /dev/null
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -0,0 +1,194 @@
+/**
+ * OMAP2PLUS Dual-Mode Timers - platform device registration
+ *
+ * Contains first level initialization routines which extracts timers
+ * information from hwmod database and registers with linux device model.
+ * It also has low level function to change the timer input clock source.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/dmtimer.h
+#include plat/omap_device.h
+
+/*
+ * OMAP4 IP revision has different register offsets
+ * for interrupt registers and functional registers.
+ */
+#define VERSION2_TIMER_WAKEUP_EN_REG_OFFSET0x14
+#define VERSION2_TIMER_STAT_REG_OFFSET 0x10
+
+static int early_timer_count __initdata = 1;
+
+struct dm_timer_data {
+ struct omap_device *od;
+ struct dmtimer_platform_data *pdata;
+ struct list_head node;
+};
+
+static __initdata LIST_HEAD(dm_timer_data_list);
+
+/**
+ * omap2_dm_timer_set_src - change the timer input clock source
+ * @pdev: timer platform device pointer
+ * @timer_clk: current clock source
+ * @source:array index of parent clock source
+ */
+static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
+{
+ int ret;
+ struct dmtimer_platform_data *pdata = pdev-dev.platform_data;
+ struct clk *fclk = clk_get(pdev-dev, fck);
+ struct clk *new_fclk;
+ char *fclk_name = 32k_ck; /* default name */
+
+ switch (source) {
+ case OMAP_TIMER_SRC_SYS_CLK:
+ fclk_name = sys_ck;
+ break;
+
+ case OMAP_TIMER_SRC_32_KHZ:
+ fclk_name = 32k_ck;
+ break;
+
+ case OMAP_TIMER_SRC_EXT_CLK:
+ if (pdata-timer_ip_type == OMAP_TIMER_IP_VERSION_1) {
+ fclk_name = alt_ck;
+ break;
+ }
+ dev_dbg(pdev-dev, %s: %d: invalid clk src.\n,
+ __func__, __LINE__);
+ return -EINVAL;
+ }
+
+ if (IS_ERR_OR_NULL(fclk)) {
+ dev_dbg(pdev-dev, %s: %d: clk_get() FAILED\n,
+ __func__, __LINE__);
+ return -EINVAL;
+ }
+
+ new_fclk = clk_get(pdev-dev, fclk_name);
+ if (IS_ERR_OR_NULL(new_fclk)) {
+ dev_dbg(pdev-dev, %s: %d: clk_get() %s FAILED\n,
+ __func__, __LINE__, fclk_name);
+ clk_put(fclk);
+ return -EINVAL;
+ }
+
+ ret = clk_set_parent(fclk, new_fclk);
+ if (IS_ERR_VALUE(ret)) {
+ dev_dbg(pdev-dev, %s: clk_set_parent() to %s FAILED\n,
+ __func__, fclk_name);
+ ret = -EINVAL;
+ }
+
+ clk_put(new_fclk);
+ clk_put(fclk);
+
+ return ret;
+}
+
+struct omap_device_pm_latency omap2_dmtimer_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags =
[PATCH v6 6/12] OMAP1: dmtimer: conversion to platform devices
From: Thara Gopinath th...@ti.com
Convert OMAP1 dmtimers into a platform devices and then registers with
device model framework so that it can be bound to corresponding driver.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/dmtimer.c | 209 +
arch/arm/mach-omap1/timer32k.c|4 -
arch/arm/plat-omap/dmtimer.c | 64 +
arch/arm/plat-omap/include/plat/dmtimer.h | 26 -
5 files changed, 243 insertions(+), 62 deletions(-)
create mode 100644 arch/arm/mach-omap1/dmtimer.c
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9a304d8..0001659 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
-obj-y += clock.o clock_data.o opp_data.o
+obj-y += clock.o clock_data.o opp_data.o dmtimer.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/dmtimer.c b/arch/arm/mach-omap1/dmtimer.c
new file mode 100644
index 000..b4c00e9
--- /dev/null
+++ b/arch/arm/mach-omap1/dmtimer.c
@@ -0,0 +1,209 @@
+/**
+ * OMAP1 Dual-Mode Timers - platform device registration
+ *
+ * Contains first level initialization routines which internally
+ * generates timer device information and registers with linux
+ * device model. It also has low level function to chnage the timer
+ * input clock source.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma tarun.ka...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include linux/slab.h
+#include mach/irqs.h
+#include plat/dmtimer.h
+#include plat/omap_device.h
+
+#define OMAP1610_GPTIMER1_BASE 0xfffb1400
+#define OMAP1610_GPTIMER2_BASE 0xfffb1c00
+#define OMAP1610_GPTIMER3_BASE 0xfffb2400
+#define OMAP1610_GPTIMER4_BASE 0xfffb2c00
+#define OMAP1610_GPTIMER5_BASE 0xfffb3400
+#define OMAP1610_GPTIMER6_BASE 0xfffb3c00
+#define OMAP1610_GPTIMER7_BASE 0xfffb7400
+#define OMAP1610_GPTIMER8_BASE 0xfffbd400
+
+#define OMAP1_DM_TIMER_COUNT 8
+
+#define OMAP_TIMER_OCP_CFG_REG 0x10
+#define OMAP_TIMER_SYS_STAT_REG0x14
+#define OMAP_TIMER_IF_CTRL_REG 0x40
+
+static int omap1_dm_timer_set_src(struct platform_device *pdev,
+ int source)
+{
+ int n = (pdev-id) 1;
+ u32 l;
+
+ l = omap_readl(MOD_CONF_CTRL_1) ~(0x03 n);
+ l |= source n;
+ omap_writel(l, MOD_CONF_CTRL_1);
+
+ return 0;
+}
+
+static void omap1_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
+{
+ int c;
+ struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+
+ c = 0;
+ while (!(pdata-dm_timer_read_reg(timer, OMAP_TIMER_SYS_STAT_REG) 1))
{
+ c++;
+ if (c 10) {
+ printk(KERN_ERR Timer failed to reset.\n);
+ return;
+ }
+ }
+}
+
+static void omap1_dm_timer_reset(struct omap_dm_timer *timer)
+{
+ u32 l;
+ struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
+
+ if (timer-pdev-id != 1) {
+ pdata-dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
+ omap1_dm_timer_wait_for_reset(timer);
+ }
+
+ l = pdata-dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG);
+ l |= 0x02 3; /* Set to smart-idle mode */
+ l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */
+ pdata-dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_REG, l);
+}
+
+int __init omap1_dm_timer_device_init(void)
+{
+ int i;
+ int ret;
+ struct dmtimer_platform_data *pdata;
+ struct platform_device *pdev;
+
+ pr_debug(%s: +\n, __func__);
+
+ if (!cpu_is_omap16xx())
+ return 0;
+
+ for (i = 1; i = OMAP1_DM_TIMER_COUNT; i++) {
+ struct resource res[2];
+ u32 base, irq;
+
+ switch (i) {
+ case 1:
+ base = OMAP1610_GPTIMER1_BASE;
+ irq = INT_1610_GPTIMER1;
+ break;
+ case
[PATCH v6 3/12] OMAP2430: hwmod data: add dmtimer
From: Thara Gopinath th...@ti.com
Add dmtimer data.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 633
1 files changed, 633 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 12d939e..d7dc3ef 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -16,6 +16,7 @@
#include plat/cpu.h
#include plat/dma.h
#include plat/serial.h
+#include plat/dmtimer.h
#include omap_hwmod_common_data.h
@@ -228,6 +229,624 @@ static struct omap_hwmod omap2430_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
};
+/* Timer Common */
+static struct omap_hwmod_class_sysconfig omap2430_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_timer_hwmod_class = {
+ .name = timer,
+ .sysc = omap2430_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+/* timer1 */
+static struct omap_hwmod omap2430_timer1_hwmod;
+static struct omap_hwmod_irq_info omap2430_timer1_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIMER1, },
+};
+
+static struct omap_hwmod_addr_space omap2430_timer1_addrs[] = {
+ {
+ .pa_start = 0x49018000,
+ .pa_end = 0x49018000 + SZ_1K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup - timer1 */
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__timer1 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_timer1_hwmod,
+ .clk= gpt1_ick,
+ .addr = omap2430_timer1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_timer1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave port */
+static struct omap_hwmod_ocp_if *omap2430_timer1_slaves[] = {
+ omap2430_l4_wkup__timer1,
+};
+
+/* timer1 hwmod */
+static struct omap_hwmod omap2430_timer1_hwmod = {
+ .name = timer1,
+ .mpu_irqs = omap2430_timer1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_timer1_mpu_irqs),
+ .main_clk = gpt1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+ },
+ },
+ .slaves = omap2430_timer1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_timer1_slaves),
+ .class = omap2430_timer_hwmod_class,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+};
+
+/* timer2 */
+static struct omap_hwmod omap2430_timer2_hwmod;
+static struct omap_hwmod_irq_info omap2430_timer2_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIMER2, },
+};
+
+static struct omap_hwmod_addr_space omap2430_timer2_addrs[] = {
+ {
+ .pa_start = 0x4802a000,
+ .pa_end = 0x4802a000 + SZ_1K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - timer2 */
+static struct omap_hwmod_ocp_if omap2430_l4_core__timer2 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_timer2_hwmod,
+ .clk= gpt2_ick,
+ .addr = omap2430_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer2 slave port */
+static struct omap_hwmod_ocp_if *omap2430_timer2_slaves[] = {
+ omap2430_l4_core__timer2,
+};
+
+/* timer2 hwmod */
+static struct omap_hwmod omap2430_timer2_hwmod = {
+ .name = timer2,
+ .mpu_irqs = omap2430_timer2_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_timer2_mpu_irqs),
+ .main_clk = gpt2_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT2_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT2_SHIFT,
+ },
+ },
+ .slaves = omap2430_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_timer2_slaves),
+
[PATCH v6 1/12] OMAP2+: dmtimer: add device names to flck nodes
From: Thara Gopinath th...@ti.com
Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be
retrieved by doing a clk_get with the corresponding device pointers or
device names.
NOTE: gpt1_fck is modified in patch-9 when we switch to platform device
driver. This is to make sure that each patch compiles and boots.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Reviewed-by: Varadarajan, Charulatha ch...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 58 +++--
arch/arm/mach-omap2/clock2430_data.c | 58 +++--
arch/arm/mach-omap2/clock3xxx_data.c | 46 --
arch/arm/mach-omap2/clock44xx_data.c | 42 ++--
4 files changed, 161 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 21f8562..d140807 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1803,27 +1803,27 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gpt1_ick, gpt1_ick, CK_242X),
CLK(NULL, gpt1_fck, gpt1_fck, CK_242X),
CLK(NULL, gpt2_ick, gpt2_ick, CK_242X),
- CLK(NULL, gpt2_fck, gpt2_fck, CK_242X),
+ CLK(omap_timer.2, fck, gpt2_fck, CK_242X),
CLK(NULL, gpt3_ick, gpt3_ick, CK_242X),
- CLK(NULL, gpt3_fck, gpt3_fck, CK_242X),
+ CLK(omap_timer.3, fck, gpt3_fck, CK_242X),
CLK(NULL, gpt4_ick, gpt4_ick, CK_242X),
- CLK(NULL, gpt4_fck, gpt4_fck, CK_242X),
+ CLK(omap_timer.4, fck, gpt4_fck, CK_242X),
CLK(NULL, gpt5_ick, gpt5_ick, CK_242X),
- CLK(NULL, gpt5_fck, gpt5_fck, CK_242X),
+ CLK(omap_timer.5, fck, gpt5_fck, CK_242X),
CLK(NULL, gpt6_ick, gpt6_ick, CK_242X),
- CLK(NULL, gpt6_fck, gpt6_fck, CK_242X),
+ CLK(omap_timer.6, fck, gpt6_fck, CK_242X),
CLK(NULL, gpt7_ick, gpt7_ick, CK_242X),
- CLK(NULL, gpt7_fck, gpt7_fck, CK_242X),
+ CLK(omap_timer.7, fck, gpt7_fck, CK_242X),
CLK(NULL, gpt8_ick, gpt8_ick, CK_242X),
- CLK(NULL, gpt8_fck, gpt8_fck, CK_242X),
+ CLK(omap_timer.8, fck, gpt8_fck, CK_242X),
CLK(NULL, gpt9_ick, gpt9_ick, CK_242X),
- CLK(NULL, gpt9_fck, gpt9_fck, CK_242X),
+ CLK(omap_timer.9, fck, gpt9_fck, CK_242X),
CLK(NULL, gpt10_ick,gpt10_ick, CK_242X),
- CLK(NULL, gpt10_fck,gpt10_fck, CK_242X),
+ CLK(omap_timer.10,fck, gpt10_fck, CK_242X),
CLK(NULL, gpt11_ick,gpt11_ick, CK_242X),
- CLK(NULL, gpt11_fck,gpt11_fck, CK_242X),
+ CLK(omap_timer.11,fck, gpt11_fck, CK_242X),
CLK(NULL, gpt12_ick,gpt12_ick, CK_242X),
- CLK(NULL, gpt12_fck,gpt12_fck, CK_242X),
+ CLK(omap_timer.12,fck, gpt12_fck, CK_242X),
CLK(omap-mcbsp.1, ick, mcbsp1_ick,CK_242X),
CLK(omap-mcbsp.1, fck, mcbsp1_fck,CK_242X),
CLK(omap-mcbsp.2, ick, mcbsp2_ick,CK_242X),
@@ -1878,6 +1878,42 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_242X),
CLK(NULL, usb_fck, usb_fck, CK_242X),
CLK(musb_hdrc,fck, osc_ck,CK_242X),
+ CLK(omap_timer.1, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.2, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.3, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.4, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.5, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.6, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.7, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.8, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.9, 32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.10,32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.11,32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.12,32k_ck, func_32k_ck, CK_243X),
+ CLK(omap_timer.1, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.2, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.3, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.4, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.5, sys_ck, sys_ck,CK_243X),
+ CLK(omap_timer.6, sys_ck, sys_ck,
[PATCH v2] OMAP3: clean up ASM idle code
This patch only contains clean-ups and cosmetic changes, no functional change. Clean up of the ASM code: - reorganized the code in logical sections: defines, API functions, internal functions and variables, - reworked and simplified the execution paths, for better readability and to avoid duplication of code, - added comments on the entry and exit points and the interaction with the ROM code for OFF mode restore, - reworked the existing comments for better readability, - reworked the code formating, alignment and white spaces, - added comments for the i443 erratum workarounds, - changed the hardcoded values in favor of existing macros from include files, - clean up of non used symbols. Tested on OMAP3EVM and Beagleboard with full RET and OFF modes, using cpuidle and suspend. Based on original patch from Vishwa. Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/control.c | 10 +- arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/pm.h|1 - arch/arm/mach-omap2/pm34xx.c|4 +- arch/arm/mach-omap2/sleep34xx.S | 581 +-- 5 files changed, 329 insertions(+), 269 deletions(-) diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 728f268..5cb7276 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -239,7 +239,15 @@ void omap3_save_scratchpad_contents(void) struct omap3_scratchpad_prcm_block prcm_block_contents; struct omap3_scratchpad_sdrc_block sdrc_block_contents; - /* Populate the Scratchpad contents */ + /* +* Populate the Scratchpad contents +* +* The get_*restore_pointer functions are used to get the resume +* function pointer to be called by the ROM code when back from WFI +* in OFF mode. +* The restore pointer is stored into the scratchpad for later access +* by the ROM code. +*/ scratchpad_contents.boot_config_ptr = 0x0; if (cpu_is_omap3630()) scratchpad_contents.public_restore_ptr = diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index d7911c5..72efefb 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -274,6 +274,8 @@ #define OMAP343X_SCRATCHPAD_ROM(OMAP343X_CTRL_BASE + 0x860) #define OMAP343X_SCRATCHPAD(OMAP343X_CTRL_BASE + 0x910) #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C +#define OMAP343X_SCRATCHPAD_REGADDR(reg) OMAP2_L4_IO_ADDRESS(\ + OMAP343X_SCRATCHPAD + reg) /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index aff39d0..e458b2a 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -80,7 +80,6 @@ extern void save_secure_ram_context(u32 *addr); extern void omap3_save_scratchpad_contents(void); extern unsigned int omap24xx_idle_loop_suspend_sz; -extern unsigned int omap34xx_suspend_sz; extern unsigned int save_secure_ram_context_sz; extern unsigned int omap24xx_cpu_suspend_sz; extern unsigned int omap34xx_cpu_suspend_sz; diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index ba3c0d6..0e3cc35 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -135,7 +135,7 @@ static void omap3_core_save_context(void) /* * Force write last pad into memory, as this can fail in some -* cases according to erratas 1.157, 1.185 +* cases according to errata 1.157 1.185 */ omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14), OMAP343X_CONTROL_MEM_WKUP + 0x2a0); @@ -432,7 +432,7 @@ void omap_sram_idle(void) /* * On EMU/HS devices ROM code restores a SRDC value * from scratchpad which has automatic self refresh on timeout - * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. + * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443. * Hence store/restore the SDRC_POWER register here. */ if (omap_rev() = OMAP3430_REV_ES3_0 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index d2eda01..ccf661e 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -33,24 +33,27 @@ #include sdrc.h #include control.h -#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c - -#define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \ - OMAP3430_PM_PREPWSTST) -#define PM_PREPWSTST_CORE_P0x48306AE8 -#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \ - OMAP3430_PM_PREPWSTST) +/* + * Registers access definitions + */ +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc +#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR\ +
Re: [PATCH v3 0/4] Introduce hardware spinlock framework
On Tue, Dec 14, 2010 at 04:31:36PM +0200, Ohad Ben-Cohen wrote: Hi Greg, Tony, On Sat, Dec 4, 2010 at 1:50 AM, Ohad Ben-Cohen o...@wizery.com wrote: OMAP4 introduces a Hardware Spinlock device, which provides hardware assistance for synchronization and mutual exclusion between heterogeneous processors and those not operating under a single, shared operating system (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP). The intention of this hardware device is to allow remote processors, that have no alternative mechanism to accomplish synchronization and mutual exclusion operations, to share resources (such as memory and/or any other hardware resource). This patchset adds hwspinlock framework that makes it possible for drivers to use those hwspinlock devices and stay platform-independent. ... Documentation/hwspinlock.txt | 299 +++ arch/arm/mach-omap2/Makefile | 1 + arch/arm/mach-omap2/hwspinlock.c | 63 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 64 drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/hwspinlock/Kconfig | 22 ++ drivers/hwspinlock/Makefile | 6 + drivers/hwspinlock/hwspinlock.h | 61 +++ drivers/hwspinlock/hwspinlock_core.c | 557 drivers/hwspinlock/omap_hwspinlock.c | 231 include/linux/hwspinlock.h | 298 +++ 12 files changed, 1605 insertions(+), 0 deletions(-) Can you please have a look and say if this looks OK ? Look at what, I don't see a patch here. I've seen a lot of discussion about this, are all of the review comments now addressed? Like the most important one, why is this generic code if it's only for one specific platform? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv4 4/7] HSI: hsi_char: Add HSI char device driver
On Tue, 2010-12-14 at 11:56 +, ext Alan Cox wrote:
+#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);
These sort of macros just hide detail - eg the lack of internal locking,
which can lead to problems later, plus they reference their arguments
multiple times so may have weird side effects.
They should probably be inline functions so they at least type check and
behave sanely, and their locking rules defintiely need documenting
Agree. We would change that.
+static long hsi_char_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct hsi_char_channel *channel = file-private_data;
+ unsigned int state;
+ struct hsi_config cfg;
+ struct hsc_rx_config rx_cfg;
+ struct hsc_tx_config tx_cfg;
+ long ret = 0;
+
+ if (HSI_CHST_OC(channel) != HSI_CHST_OPENED)
+ return -ENODEV;
-EIO is the traditional response in this case if the channel has been
closed by the other end - ENODEV indicates there is no physical device
present - not sure which is right here from the code.
The initial idea of this code was to guard against underneath removal of
the device. That was the reason for the -ENODEV.
Now after, rechecking the code I think that we need also to lock the
device to avoid that the removal happening in the middle of the
function.
+ } else if ((state == HSC_PM_ENABLE)
+(channel-wlrefcnt 0)) {
+ ret = hsi_stop_tx(channel-cl);
+ if (!ret)
+ channel-wlrefcnt--;
What locks this lot against races (ditto some of the other ioctl code)
Right. We will fix this also.
+ refcnt = atomic_inc_return(cl_data-refcnt);
+ if (refcnt == 1) {
You seem to construct a lot of clever stuff using atomic_inc_return and
friends where it looks like test_and_set_bit - or even a mutex over
open/close would be far easier to understand ?
Yep a mutex will be a better option here. It would also take care of the
next comment.
+ ret = hsi_char_msgs_alloc(channel);
+
+ if (ret 0) {
+ refcnt = atomic_dec_return(cl_data-refcnt);
+ if (!refcnt)
+ hsi_release_port(channel-cl);
+ spin_lock_bh(channel-lock);
+ HSI_CHST_OC_SET(channel, HSI_CHST_CLOSED);
+ goto out;
+ }
+ if (refcnt == 1)
+ cl_data-attached = 1;
What happens here if a second open passes the first, the attached will
stay zero and other stuff will be in strange states but the open flag
will be set ?
+ for (i = 0; i HSI_CHAR_DEVS channels_map[i] = 0; i++) {
+ if (channels_map[i] = HSI_CHAR_DEVS) {
+ pr_err(Invalid HSI/SSI channel specified);
+ return -EINVAL;
+ }
+ set_bit(channels_map[i], ch_mask);
How will this integrate with hot discovery of SSI supporting devices ?
For every SSI port there is an HSI char client device, which is the
device received through probe. The driver will export for every HSI char
client device, HSI_CHAR_DEVS char devices, one char device per channel.
The intention of this piece of code is to allow the user to configure
which channels the user wants to be available to userspace.
Thanks for the comments,
Carlos
--
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] OMAP4:keypad: PM runtime
Shubhrajyoti D a0393...@india.ti.com writes: From: Abraham Arce x0066...@ti.com Enable Runtime PM functionality in OMAP4 driver based on the following assumptions - Runtime PM selected by ARCH_OMAP2PLUS_TYPICAL ARCH_OMAP2PLUS, which is the default OMAP2+ defconfig including OMAP4 this does not need to be stated in the changelog - Runtime PM APIs handles Clock Framework APIs OMAP Runtime PM does much more than handle clocks. - Do not do the keypadconfig if the irq request fails This is a separate fix, unrelated to enabling runtime PM. A minimal pm runtime get/put approach is implemented in probe/remove calls respectively based on: - Keyboard controller in wakeup domain so it is always on and power impact may be minimal - Cutting of clocks will prevent interrupts Again, please describe in more detail why preventing interrupts causes a problem.I understand it may seem obvious right now, but these changelogs need to be understandable many months/years down the road. Kevin Signed-off-by: Abraham Arce x0066...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- Updating the changelogs as per Kevin's suggestion drivers/input/keyboard/omap4-keypad.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 45bd097..36239e2 100644 --- a/drivers/input/keyboard/omap4-keypad.c +++ b/drivers/input/keyboard/omap4-keypad.c @@ -29,6 +29,7 @@ #include linux/io.h #include linux/input.h #include linux/slab.h +#include linux/pm_runtime.h #include plat/omap4-keypad.h @@ -239,7 +240,8 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev) matrix_keypad_build_keymap(pdata-keymap_data, row_shift, input_dev-keycode, input_dev-keybit); - omap4_keypad_config(keypad_data); + pm_runtime_enable(pdev-dev); + pm_runtime_get_sync(pdev-dev); error = request_irq(keypad_data-irq, omap4_keypad_interrupt, IRQF_TRIGGER_RISING, @@ -255,8 +257,9 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev) goto err_free_irq; } - + omap4_keypad_config(keypad_data); platform_set_drvdata(pdev, keypad_data); + return 0; err_free_irq: @@ -278,6 +281,10 @@ static int __devexit omap4_keypad_remove(struct platform_device *pdev) struct resource *res; free_irq(keypad_data-irq, keypad_data); + + pm_runtime_put_sync(pdev-dev); + pm_runtime_disable(pdev-dev); + input_unregister_device(keypad_data-input); iounmap(keypad_data-base); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] OMAP3: clean up ASM idle code
From: Jean Pihet j-pi...@ti.com This patch only contains clean-ups and cosmetic changes, no functional change. Clean up of the ASM code: - reorganized the code in logical sections: defines, API functions, internal functions and variables, - reworked and simplified the execution paths, for better readability and to avoid duplication of code, - added comments on the entry and exit points and the interaction with the ROM code for OFF mode restore, - reworked the existing comments for better readability, - reworked the code formating, alignment and white spaces, - added comments for the i443 erratum workarounds, - changed the hardcoded values in favor of existing macros from include files, - clean up of non used symbols. Tested on OMAP3EVM and Beagleboard with full RET and OFF modes, using cpuidle and suspend. Based on original patch from Vishwa. Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/control.c | 10 +- arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/pm.h|1 - arch/arm/mach-omap2/pm34xx.c|4 +- arch/arm/mach-omap2/sleep34xx.S | 581 +-- 5 files changed, 329 insertions(+), 269 deletions(-) diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 728f268..5cb7276 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -239,7 +239,15 @@ void omap3_save_scratchpad_contents(void) struct omap3_scratchpad_prcm_block prcm_block_contents; struct omap3_scratchpad_sdrc_block sdrc_block_contents; - /* Populate the Scratchpad contents */ + /* +* Populate the Scratchpad contents +* +* The get_*restore_pointer functions are used to get the resume +* function pointer to be called by the ROM code when back from WFI +* in OFF mode. +* The restore pointer is stored into the scratchpad for later access +* by the ROM code. +*/ scratchpad_contents.boot_config_ptr = 0x0; if (cpu_is_omap3630()) scratchpad_contents.public_restore_ptr = diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index d7911c5..72efefb 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -274,6 +274,8 @@ #define OMAP343X_SCRATCHPAD_ROM(OMAP343X_CTRL_BASE + 0x860) #define OMAP343X_SCRATCHPAD(OMAP343X_CTRL_BASE + 0x910) #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C +#define OMAP343X_SCRATCHPAD_REGADDR(reg) OMAP2_L4_IO_ADDRESS(\ + OMAP343X_SCRATCHPAD + reg) /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index aff39d0..e458b2a 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -80,7 +80,6 @@ extern void save_secure_ram_context(u32 *addr); extern void omap3_save_scratchpad_contents(void); extern unsigned int omap24xx_idle_loop_suspend_sz; -extern unsigned int omap34xx_suspend_sz; extern unsigned int save_secure_ram_context_sz; extern unsigned int omap24xx_cpu_suspend_sz; extern unsigned int omap34xx_cpu_suspend_sz; diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index ba3c0d6..0e3cc35 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -135,7 +135,7 @@ static void omap3_core_save_context(void) /* * Force write last pad into memory, as this can fail in some -* cases according to erratas 1.157, 1.185 +* cases according to errata 1.157 1.185 */ omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14), OMAP343X_CONTROL_MEM_WKUP + 0x2a0); @@ -432,7 +432,7 @@ void omap_sram_idle(void) /* * On EMU/HS devices ROM code restores a SRDC value * from scratchpad which has automatic self refresh on timeout - * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. + * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443. * Hence store/restore the SDRC_POWER register here. */ if (omap_rev() = OMAP3430_REV_ES3_0 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index d2eda01..ccf661e 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -33,24 +33,27 @@ #include sdrc.h #include control.h -#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c - -#define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \ - OMAP3430_PM_PREPWSTST) -#define PM_PREPWSTST_CORE_P0x48306AE8 -#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \ - OMAP3430_PM_PREPWSTST) +/* + * Registers access definitions + */ +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc +#define SDRC_SCRATCHPAD_SEM_V
Re: [PATCH] OMAP3: clean up ASM idle code
Kevin,
The reworked version has been resent. Please use '[PATCH v3] OMAP3:
clean up ASM idle code' which has the correct e-mail addresses for the
sign-offs.
Thanks,
Jean
On Tue, Dec 14, 2010 at 12:34 PM, Vishwanath Sripathy
vishwanath...@ti.com wrote:
Jean,
-Original Message-
From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
Sent: Tuesday, December 14, 2010 2:53 PM
To: Kevin Hilman; Vishwanath BS
Cc: linux-omap@vger.kernel.org; Jean Pihet
Subject: Re: [PATCH] OMAP3: clean up ASM idle code
Kevin,
On Tue, Dec 14, 2010 at 5:12 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Clean up of the ASM code:
- reorganized the code in logical sections: defines, API
á áfunctions, internal functions and variables,
- reworked and simplified the execution paths, for better
á áreadability and to avoid duplication of code,
- added comments on the entry and exit points,
- reworked the existing comments for better readability,
- reworked the code formating, alignment and white spaces,
- added comments for the i443 erratum workarounds,
- changed the hardcoded values in favor of existing macros
á áfrom include files,
- clean up of non used symbols.
The 'lock_scratchpad_sem' code is also unused. áIIRC, you removed
that
in an earlier version of the series. áAre you still planning to remove
that? maybe in a subsequent patch?
I asked previously about it and the reply was that this code is
needed: (quoting Vishwa's reply) This is indeed used during DVFS when
Core DPLL configuration is changed. Note: the DVFS code is not
upstreamed yet.
Vishwa, can you confirm?
lock_scratchpad_sem is needed when DVFS feature is supported. If you want
to add this implementation as part of DVFS feature, then also it's fine.
Vishwa
That being said, pure whitespace changes and unused code removal
should
probably be a separate patch. áIt's a great help to reviewers if
functional changes are separated from whitespace changes. áIt's a bit
tricky in this series as there's lots of code moving as well, so I'll
leave it up to your judgement on how/if to separate these out.
There is no functional change at all. The code has been reorganized
for better readability.
I agree the patch is not easy to read but that is the way diff reports
the changes.
I do not see the point to provide separate patches for code move,
white space clean-up, alignment fixes etc.
Tested on OMAP3EVM and Beagleboard with full RET and OFF modes.
In idle? áin suspend? áboth? áwas CPUidle enabled?
FWIW, I tested on 3430-ES3.1/n900 with retention idle suspend and
off
idle suspend with CPUidle enabled.
Tested with cpuidle and suspend. I will update the description.
Heavily reworked from Vishwa's original patch.
Here, it's more customary to ásay Based on original patch from
Vishwa
and ensure the original author is CC'd (which you've done.)
Other than that, this is a great cleanup, and makes this much more
readable. áThanks.
Some other minor comments below.
OK thanks for the review. I will post a new version asap.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
---
Applies on top of Nishant's latest idle path errata fixes step 2,
cf. http://marc.info/?l=linux-omapm=129139584919242w=2
[...]
@@ -208,36 +172,153 @@ api_params:
áENTRY(save_secure_ram_context_sz)
á á á .word á . - save_secure_ram_context
+
+/* ==
+ * == Idle entry point ==
+ * ==
+ */
Let's keep C multi-line coding style even for assembly. á Same goes
for
several other places below.
Ok
á/*
á * Forces OMAP into idle state
á *
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
+ * omap34xx_suspend() - This bit of code saves the CPU context if
needed
+ * and executes the WFI instruction
+ *
+ * Note: This code get's copied to internal SRAM at boot.
á *
- * Note: This code get's copied to internal SRAM at boot. When the
OMAP
- * á áwakes up it continues execution at the point it went to sleep.
+ * Note: When the OMAP wakes up it continues at different
execution points,
+ * ádepending on the low power mode (non-OFF vs OFF modes),
+ * ácf. 'Resume path for xxx mode' comments.
á */
áENTRY(omap34xx_cpu_suspend)
á á á stmfd á sp!, {r0-r12, lr} á á á á á á á @ save registers on
stack
áloop:
á á á /*b á á loop*/ �...@enable to debug by stepping through code
While here, let's get rid of these infinite loop hacks for debugging
as
anyone debugging this code can add these back as needed.
áOtherwise,
they clutter the code. á There are a few of theses throughout the
original code.
Ok. Agree those are not used at all (even when doing heavy debugging).
[...]
@@ -250,9 +331,28 @@ loop:
á á á nop
á á á bl wait_sdrc_ok
- á á
Re: [PATCH 0/4] omap: iovmm - fixes for iovmm module
On Tue, Dec 14, 2010 at 9:10 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Dec 14, 2010 at 3:07 PM, Fernando Guzman Lugo fernando.l...@ti.com wrote: You are missing a description here. Yes, I forget the description but it is pretty much the same than the subject. Version 6: * Rebase on Russell King branch. - for details see: http://marc.info/?l=linux-omapm=129228495723001w=2 Even if these patches are applied, iommu would still not be usable form tidspbridge, you need at least this patch: http://article.gmane.org/gmane.linux.ports.arm.omap/44753 I think Hari can take that patch too. Regards, Fernando. 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 0/5] ARM: GIC: cleanup
Russell King - ARM Linux wrote: On Mon, Dec 13, 2010 at 09:23:29AM -0800, Abhijeet Dharmapurikar wrote: Sorry for being late on testing this out. The patch series and works on the msm 8660. Acked-By: Abhijeet Dharmapurikar adhar...@codeaurora.org Would you prefer a Tested-by: ? Yes, Tested-by is more appropriate. Tested-by: Abhijeet Dharmapurikar adhar...@codeaurora.org -- 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 05/12] OMAP4: PRCM: Add SCRM header file
On Tue, 14 Dec 2010, Cousson, Benoit wrote: This patch will conflict with your power prcm series, because you are creating an empty scrm44xx.h in it. So I did rebased this series on top on your prcm to fix that. Don't you want to use the already rebased version instead? I would rather have patches and branches based on mainline commits where possible. If a series has some explicit dependency on a non-mainline patch or branch then I'd like to know about it in the messages if possible. As far as the empty scrm44xx.h goes, I will probably go back and rebuild that branch with your patch that creates SCRM from my patch set inserted earlier, so I can drop the part of my patch that creates the empty file. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Introduce hardware spinlock framework
On Tue, Dec 14, 2010 at 7:06 PM, Greg KH g...@kroah.com wrote: Can you please have a look and say if this looks OK ? Look at what, I don't see a patch here. Here's the complete patchset: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39833.html If you prefer, I can resubmit. I've seen a lot of discussion about this, are all of the review comments now addressed? Yes, all comments were addressed in this v3 iteration, and this thread has been idle for about 10 days. Like the most important one, why is this generic code if it's only for one specific platform? We started out with an omap-specific driver, but Tony preferred that we make this a platform-agnostic framework, in order to keep the IPC drivers that will use it generic, and assuming that more users will show up for such framework. To me it sounds reasonable, but both ways (framework / omap-specific driver) will work for us just fine, and I can switch back to a misc driver if this is preferred. The complete discussion of v1 is at: http://comments.gmane.org/gmane.linux.kernel/1049802 We also discussed this at v2 of the patches with David, see the complete discussion at: http://comments.gmane.org/gmane.linux.kernel/1067016 Thanks, Ohad. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mainline OMAP3 breakage (and other OMAP?)
* Tomi Valkeinen tomi.valkei...@nokia.com [101214 04:23]:
So please, 2MB, or if you object, at the _very_ _least_ 1MB. But
definitely not PAGE_SIZE.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
drivers/video/omap2/vram.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index 2fd7e52..9441e2e 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -551,7 +551,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
if (!size)
return;
- size = PAGE_ALIGN(size);
+ size = ALIGN(size, SZ_2M);
if (paddr) {
if (paddr ~PAGE_MASK) {
@@ -576,7 +576,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
return;
}
} else {
- paddr = memblock_alloc(size, PAGE_SIZE);
+ paddr = memblock_alloc(size, SZ_2M);
}
memblock_free(paddr, size);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 4/4] omap: iommu - create new api to set valid da range
On Tue, Dec 14, 2010 at 9:08 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Dec 14, 2010 at 3:07 PM, Fernando Guzman Lugo fernando.l...@ti.com wrote: From: Guzman Lugo, Fernando x0095...@ti.com Some IOMMUs cannot use the whole 0x0 - 0x rage. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com I still don't see where this API is being used. you can find it here: http://marc.info/?l=linux-kernelm=128805403014740w=2 I will add it to the iommu migration set once all the dependencies are merged. Also, the point of using platform data was to add it to omap3_devices in omap-iommu.c, see[1]. I thought the platform data start/end would move to struct iommu, and iommu_set_da_range would change the start/end on struct iommu, but that would only be necessary if the platform data doesn't match that. it is not clear for me. do you mean having default start/end in platform data then when iommu_get is call pass them to start/end in struct iommu and the new api change start/end in struct iommu? Please let me know if that is correct. Regards, Fernando. If there's no sensible platform data default, then there's no point in using platform data, as the platform is not the limiting factor, but the DSP SW. [1] http://article.gmane.org/gmane.linux.kernel/1051268 -- 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/5] OMAP4: PM: Use the lowpwrstatechange feature on OMAP4
Benoit Cousson b-cous...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
For pwrdm's which support lowperstatechange, do not try waking
up the domain to put it back to deeper sleep state.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
Re: $SUBJECT, the rather than using the cryptic lowpwrstchange name from the
pwrdm API, just use the more readable low-power state change
Also, readability/flow, I have some questions/comments...
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index cf1c4c9..dc68044 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -114,6 +114,14 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
return ret;
if (pwrdm_read_pwrst(pwrdm) PWRDM_POWER_ON) {
+ if ((pwrdm_read_pwrst(pwrdm) state)
+ (pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE)) {
+ ret = pwrdm_set_next_pwrst(pwrdm, state);
+ pwrdm_set_lowpwrstchange(pwrdm);
+ pwrdm_wait_transition(pwrdm);
+ pwrdm_state_switch(pwrdm);
+ return ret;
Personally, I'd prefer if this function flowed through better instead of
the early return in order to emphasize the common code.
Rather than the return here, can you just set the low-power state change
bit here (and put the clkdm_wakeup + sleep_switch = 1 into the else
clause?
Or, does the next state have to be set before the low-power state change
bit?
Basically, what I'm getting at is this should be a single function with
common flow. The conditional code based on low-power state change
should be isolated instead of having a special path.
Kevin
+ }
omap2_clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
sleep_switch = 1;
pwrdm_wait_transition(pwrdm);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP34: Fixes in setup/suspend/powerdomain
Paul Walmsley p...@pwsan.com writes: Hi Benoît, Kevin, On Mon, 13 Dec 2010, Benoit Cousson wrote: This is a series of fixes on OMAP3/4 in setup apis, in the suspend framework and in powerdomain modelling for OMAP4. ... Rajendra Nayak (3): OMAP4: PM: Use the lowpwrstatechange feature on OMAP4 OMAP4: PM: Do not assume clkdm supports hw transitions The above two patches should be run by Kevin for his ack (cc'ed on this message). Kevin, care to ack these? I had some comments on the first, and ack'd the second. 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 00/12] OMAP: clock/SRAM: patches for 2.6.38, part one
Paul Walmsley p...@pwsan.com writes: This clock/SRAM patch series, based on v2.6.37-rc5: - fixes some problems and missing data with OMAP4 clocks, - adds SCRM IP block data (part of the OMAP4 PRCM collection of modules), - cleans up the way that OMAP3 clock data CK_* and RATE_IN_* flags are used, - adds some comments to the SRAM code, - prepares part of the OMAP1 clock code for a combined OMAP1 defconfig (although more work is left to be done before a combined OMAP1 defconfig is safe, from a clock framework perspective), - and fixes a few minor bugs in the OMAP2/3 clock code. Boot-tested on OSK 5912, N800, OMAP35xx Beagle, and OMAP37xx Beagle-XM. Tested-by: Kevin Hilman khil...@deeprootsystems.com Also boot tesed on omap4/panda and PM tested on 3430/n900 with retention idle suspend and off idle suspend. Kevin This series is also available from git://git.pwsan.com/linux-2.6 branch 'clk_a_2.6.38'. - Paul --- clk_a_2.6.38 text data bss dec hex filename 5733349471616 5608768 11813733 b44365 vmlinux.orig 5734273473728 5608768 11816769 b44f41 vmlinux.patched Benoit Cousson (3): OMAP4: clock data: Add control for pad_clks_ck and slimbus_clk OMAP3: clock data: Add wkup_clkdm in sr1_fck and sr2_fck OMAP4: PRCM: Add SCRM header file Janusz Krzysztofik (1): OMAP1: clock_data: use runtime cpu / machine checks Jonathan Bergsagel (1): OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck Paul Walmsley (4): OMAP2xxx clock: fix dss2_fck recalc to use clksel OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpu OMAP3: clock: fix incorrect rate display when switching MPU rate at boot OMAP2/3: SRAM: add comment about crashes during a TLB miss Rajendra Nayak (2): OMAP4: clock data: Add SCRM auxiliary clock nodes OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocks Thara Gopinath (1): OMAP4: clock data: Add missing DPLL x2 clock nodes arch/arm/mach-omap1/clock_data.c | 17 - arch/arm/mach-omap2/clock2420_data.c |2 arch/arm/mach-omap2/clock2430_data.c |2 arch/arm/mach-omap2/clock3xxx.c |2 arch/arm/mach-omap2/clock3xxx_data.c | 218 - arch/arm/mach-omap2/clock44xx_data.c | 620 ++--- arch/arm/mach-omap2/scrm44xx.h| 176 +++ arch/arm/mach-omap2/sram242x.S|6 arch/arm/mach-omap2/sram243x.S|6 arch/arm/mach-omap2/sram34xx.S|6 arch/arm/plat-omap/include/plat/clkdev_omap.h | 20 - arch/arm/plat-omap/include/plat/clock.h | 11 12 files changed, 772 insertions(+), 314 deletions(-) create mode 100644 arch/arm/mach-omap2/scrm44xx.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 -- 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 05/12] OMAP4: PRCM: Add SCRM header file
On 12/14/2010 7:13 PM, Paul Walmsley wrote: On Tue, 14 Dec 2010, Cousson, Benoit wrote: This patch will conflict with your power prcm series, because you are creating an empty scrm44xx.h in it. So I did rebased this series on top on your prcm to fix that. Don't you want to use the already rebased version instead? I would rather have patches and branches based on mainline commits where possible. If a series has some explicit dependency on a non-mainline patch or branch then I'd like to know about it in the messages if possible. Well, I sent this series before you sent your prcm one, so at the time the dependency didn't exist ;-) As far as the empty scrm44xx.h goes, I will probably go back and rebuild that branch with your patch that creates SCRM from my patch set inserted earlier, so I can drop the part of my patch that creates the empty file. OK good for me. Thanks, 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
[PATCH v2] MTD: NAND: ams-delta: convert to platform driver
In its current form, the driver may interfere with different hardware on
different boards if built into the kernel, hence is not suitable for
inclusion into a defconfig, inteded to be usable with multiple OMAP1 cpu and
machine types.
Convert it to a platform driver, that should be free from this issue.
Created and tested against linux-2.6.37-rc5 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Tuesday 14 December 2010 18:00:23 Artem Bityutskiy wrote:
Sorry, but would it please be possible to split this few small patches -
this one is too difficult to review, at least for me.
v1 - v2 changes:
- remove any changes that were not essential for actually converting the
driver to a platform driver and modifying its user, ie. the Amstrad Delta
board, to register a corresponding platform device on startup,
- re-word the commit message a little bit.
arch/arm/mach-omap1/board-ams-delta.c |6 ++
drivers/mtd/nand/ams-delta.c | 31 ++-
2 files changed, 32 insertions(+), 5 deletions(-)
--- linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c.orig 2010-12-14
20:25:58.0 +0100
+++ linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c 2010-12-14
20:26:40.0 +0100
@@ -4,6 +4,7 @@
* Copyright (C) 2006 Jonathan McDowell nood...@earth.li
*
* Derived from drivers/mtd/toto.c
+ * Converted to platform driver by Janusz Krzysztofik jkrzy...@tis.icnet.pl
*
* 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
@@ -151,7 +152,7 @@ static int ams_delta_nand_ready(struct m
/*
* Main initialization routine
*/
-static int __init ams_delta_init(void)
+static int __devinit ams_delta_init(struct platform_device *pdev)
{
struct nand_chip *this;
int err = 0;
@@ -219,20 +222,40 @@ static int __init ams_delta_init(void)
return err;
}
-module_init(ams_delta_init);
-
/*
* Clean up routine
*/
-static void __exit ams_delta_cleanup(void)
+static int __devexit ams_delta_cleanup(struct platform_device *pdev)
{
/* Release resources, unregister device */
nand_release(ams_delta_mtd);
/* Free the MTD device structure */
kfree(ams_delta_mtd);
+
+ return 0;
+}
+
+static struct platform_driver ams_delta_nand_driver = {
+ .probe = ams_delta_init,
+ .remove = __devexit_p(ams_delta_cleanup),
+ .driver = {
+ .name = ams-delta-nand,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init ams_delta_nand_init(void)
+{
+ return platform_driver_register(ams_delta_nand_driver);
+}
+module_init(ams_delta_nand_init);
+
+static void __exit ams_delta_nand_exit(void)
+{
+ platform_driver_unregister(ams_delta_nand_driver);
}
-module_exit(ams_delta_cleanup);
+module_exit(ams_delta_nand_exit);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Jonathan McDowell nood...@earth.li);
--- linux-2.6.37-rc5/arch/arm/mach-omap1/board-ams-delta.c.orig 2010-12-09
23:13:04.0 +0100
+++ linux-2.6.37-rc5/arch/arm/mach-omap1/board-ams-delta.c 2010-12-14
20:26:40.0 +0100
@@ -181,6 +181,11 @@ static struct omap_board_config_kernel a
{ OMAP_TAG_LCD, ams_delta_lcd_config },
};
+static struct platform_device ams_delta_nand_device = {
+ .name = ams-delta-nand,
+ .id = -1
+};
+
static struct resource ams_delta_kp_resources[] = {
[0] = {
.start = INT_KEYBOARD,
@@ -273,6 +278,7 @@ void __init amsdelta_reserve(void)
}
static struct platform_device *ams_delta_devices[] __initdata = {
+ ams_delta_nand_device,
ams_delta_kp_device,
ams_delta_lcd_device,
ams_delta_led_device,
--
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 00/12]staging:tidspbridge - Remove hungarian notation from structures
This series of patches remove the hungarian notation from the structure's elements. The words to be renamed are: OriginalReplacement: dw_api_reg_base api_reg_base dw_brd_state brd_state dw_chnl_buf_size chnl_buf_size dw_chnl_offset chnl_offset dw_cmd cmd dw_core_pm_base core_pm_base dw_dsp_base dsp_base dw_dsp_base_va dsp_base_va dw_dsp_bufs dsp_bufs dw_dsp_buf_size dsp_buf_size dw_dsp_clk_m2_base dsp_clk_m2_base dw_dsp_ext_base_addr dsp_ext_base_addr dw_dsp_phys_addr_offset dsp_phys_addr_offset dw_dsp_start_add dsp_start_add dw_err_mask err_mask dw_gpp_base_pa gpp_base_pa dw_api_clk_base api_clk_base dw_api_reg_base api_reg_base dw_arg arg dw_arg1 arg1 dw_arg2 arg2 dw_chnl_buf_size chnl_buf_size dw_dsp_base_addr dsp_base_addr dw_dmmu_base dmmu_base dw_index index dw_int_addr int_addr dw_internal_size internal_size dw_last_output last_output dw_mem_base mem_base dw_mem_lengthmem_length dw_mem_phys mem_phys dw_mode mode dw_num_chnls num_chnls dw_offset_for_monitoroffset_for_monitor dw_output_mask output_mask dw_page_size page_size dw_papa dw_per_base per_base dw_per_pm_base per_pm_base dw_public_rhea public_rhea dw_seg_base_pa seg_base_pa dw_seg_base_va seg_base_va dw_self_loop self_loop dw_state state dw_tc_endianism tc_endianism dw_test_base test_base dw_type type dw_val1 val1 dw_val2 val2 dw_val3 val3 dw_vava dw_virt_base virt_base dw_vm_base vm_base dw_vm_size vm_size pfn_allocate allocate pfn_brd_mem_copy brd_mem_copy pfn_brd_mem_map brd_mem_map pfn_brd_mem_un_map brd_mem_un_map pfn_brd_mem_writebrd_mem_write pfn_brd_monitor brd_monitor pfn_brd_read brd_read pfn_brd_set_statebrd_set_state pfn_brd_startbrd_start pfn_brd_status brd_status pfn_brd_stop brd_stop pfn_brd_writebrd_write pfn_chnl_add_io_req chnl_add_io_req pfn_chnl_cancel_io chnl_cancel_io pfn_chnl_close chnl_close pfn_chnl_create chnl_create pfn_chnl_destroy chnl_destroy pfn_chnl_flush_iochnl_flush_io pfn_chnl_get_infochnl_get_info pfn_chnl_get_ioc chnl_get_ioc pfn_chnl_get_mgr_infochnl_get_mgr_info pfn_chnl_idlechnl_idle pfn_chnl_openchnl_open pfn_chnl_register_notify chnl_register_notify pfn_create create pfn_delete delete pfn_dev_cntrldev_cntrl pfn_dev_create by dev_create pfn_dev_destroy dev_destroy pfn_exit exit pfn_get_fxn_addr get_fxn_addr pfn_init init pfn_io_createio_create pfn_io_destroy io_destroy pfn_io_get_proc_load io_get_proc_load pfn_io_on_loaded io_on_loaded pfn_load load pfn_msg_create msg_create pfn_msg_create_queue msg_create_queue pfn_msg_delete msg_delete pfn_msg_delete_queue msg_delete_queue pfn_msg_get msg_get pfn_msg_put msg_put pfn_msg_register_notify msg_register_notify pfn_msg_set_queue_id msg_set_queue_id pfn_ovly ovly pfn_unload unload pfn_writewrite pf_phase_split phase_split ul_alignment alignment ul_bufsize bufsize ul_bufsize_rms bufsize_rms ul_chnl_buf_size chnl_buf_size ul_chnl_offset chnl_offset ul_code_mem_seg_mask code_mem_seg_mask ul_dais_arg dais_arg ul_data1 data1 ul_data_mem_seg_mask data_mem_seg_mask ul_dsp_addr dsp_addr ul_dsp_res_addr dsp_res_addr ul_dsp_size dsp_size ul_dsp_vadsp_va ul_dsp_virt dsp_virt ul_entry entry ul_external_mem_size external_mem_size ul_fxn_addrs fxn_addrs ul_gpp_pagpp_pa ul_gpp_phys gpp_phys ul_gpp_read_pointer gpp_read_pointer ul_gpp_size gpp_size ul_gpp_vagpp_va ul_heap_size heap_size ul_internal_mem_size internal_mem_size ul_in_use_cntin_use_cnt ul_len_max_free_blocklen_max_free_block ul_max max ul_min_block_sizemin_block_size ul_min min ul_mpu_addr mpu_addr ul_n_bytes
[PATCH 04/12] staging:tidspbridge - set4 remove hungarian from structs
hungarian notation will be removed from the elements inside
structures, the next variables will be renamed:
Original:Replacement:
pfn_brd_set_statebrd_set_state
pfn_brd_startbrd_start
pfn_brd_status brd_status
pfn_brd_stop brd_stop
pfn_brd_writebrd_write
pfn_chnl_add_io_req chnl_add_io_req
pfn_chnl_cancel_io chnl_cancel_io
pfn_chnl_close chnl_close
pfn_chnl_create chnl_create
pfn_chnl_destroy chnl_destroy
pfn_chnl_flush_iochnl_flush_io
pfn_chnl_get_infochnl_get_info
pfn_chnl_get_ioc chnl_get_ioc
pfn_chnl_get_mgr_infochnl_get_mgr_info
pfn_chnl_idlechnl_idle
pfn_chnl_openchnl_open
pfn_chnl_register_notify chnl_register_notify
pfn_create create
pfn_delete delete
pfn_dev_cntrldev_cntrl
Signed-off-by: Rene Sapiens rene.sapi...@ti.com
---
drivers/staging/tidspbridge/core/io_sm.c |8 +-
.../tidspbridge/include/dspbridge/dspdefs.h| 36 +-
.../tidspbridge/include/dspbridge/nldrdefs.h |4 +-
drivers/staging/tidspbridge/pmgr/chnl.c|4 +-
drivers/staging/tidspbridge/pmgr/dev.c | 72 ++--
drivers/staging/tidspbridge/rmgr/disp.c| 16 ++--
drivers/staging/tidspbridge/rmgr/node.c|4 +-
drivers/staging/tidspbridge/rmgr/proc.c| 20 +++---
drivers/staging/tidspbridge/rmgr/pwr.c |8 +-
drivers/staging/tidspbridge/rmgr/strm.c| 20 +++---
10 files changed, 96 insertions(+), 96 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index b734c42..2a741a0 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -683,7 +683,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
*/
status =
- hio_mgr-intf_fxns-pfn_dev_cntrl(hio_mgr-hbridge_context,
+ hio_mgr-intf_fxns-dev_cntrl(hio_mgr-hbridge_context,
BRDIOCTL_SETMMUCONFIG,
ae_proc);
if (status)
@@ -829,7 +829,7 @@ static void io_dispatch_pm(struct io_mgr *pio_mgr)
if (parg[0] == MBX_PM_HIBERNATE_EN) {
dev_dbg(bridge, PM: Hibernate command\n);
status = pio_mgr-intf_fxns-
- pfn_dev_cntrl(pio_mgr-hbridge_context,
+ dev_cntrl(pio_mgr-hbridge_context,
BRDIOCTL_PWR_HIBERNATE, parg);
if (status)
pr_err(%s: hibernate cmd failed 0x%x\n,
@@ -838,7 +838,7 @@ static void io_dispatch_pm(struct io_mgr *pio_mgr)
parg[1] = pio_mgr-shared_mem-opp_request.rqst_opp_pt;
dev_dbg(bridge, PM: Requested OPP = 0x%x\n, parg[1]);
status = pio_mgr-intf_fxns-
- pfn_dev_cntrl(pio_mgr-hbridge_context,
+ dev_cntrl(pio_mgr-hbridge_context,
BRDIOCTL_CONSTRAINT_REQUEST, parg);
if (status)
dev_dbg(bridge, PM: Failed to set constraint
@@ -847,7 +847,7 @@ static void io_dispatch_pm(struct io_mgr *pio_mgr)
dev_dbg(bridge, PM: clk control value of msg = 0x%x\n,
parg[0]);
status = pio_mgr-intf_fxns-
- pfn_dev_cntrl(pio_mgr-hbridge_context,
+ dev_cntrl(pio_mgr-hbridge_context,
BRDIOCTL_CLK_CTRL, parg);
if (status)
dev_dbg(bridge, PM: Failed to ctrl the DSP clk
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
b/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
index 8432cf9..bed46ca 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
@@ -983,32 +983,32 @@ struct bridge_drv_interface {
u32 brd_api_minor_version; /* Set to BRD_API_MINOR_VERSION. */
fxn_dev_create pfn_dev_create; /* Create device context */
fxn_dev_destroy pfn_dev_destroy;/* Destroy device context */
- fxn_dev_ctrl pfn_dev_cntrl; /* Optional vendor interface */
+ fxn_dev_ctrl dev_cntrl; /* Optional vendor interface */
fxn_brd_monitor brd_monitor;/* Load and/or start monitor */
- fxn_brd_start pfn_brd_start;/* Start DSP program. */
- fxn_brd_stop pfn_brd_stop; /* Stop/reset board. */
- fxn_brd_status pfn_brd_status; /* Get current board status. */
+ fxn_brd_start brd_start;/* Start DSP program. */
+ fxn_brd_stop brd_stop; /*
[PATCH 05/12] staging:tidspbridge - set5 remove hungarian from structs
hungarian notation will be removed from the elements inside
structures, the next variables will be renamed:
Original:Replacement:
pfn_dev_create by dev_create
pfn_dev_destroy dev_destroy
pfn_exit exit
pfn_get_fxn_addr get_fxn_addr
pfn_init init
pfn_io_createio_create
pfn_io_destroy io_destroy
pfn_io_get_proc_load io_get_proc_load
pfn_io_on_loaded io_on_loaded
pfn_load load
pfn_msg_create msg_create
pfn_msg_create_queue msg_create_queue
pfn_msg_delete msg_delete
pfn_msg_delete_queue msg_delete_queue
pfn_msg_get msg_get
pfn_msg_put msg_put
pfn_msg_register_notify msg_register_notify
pfn_msg_set_queue_id msg_set_queue_id
pfn_ovly ovly
pfn_unload unload
Signed-off-by: Rene Sapiens rene.sapi...@ti.com
---
.../tidspbridge/include/dspbridge/dspdefs.h| 28 ++--
.../tidspbridge/include/dspbridge/nldrdefs.h | 12 +++---
drivers/staging/tidspbridge/pmgr/dev.c | 46 ++--
drivers/staging/tidspbridge/pmgr/io.c |4 +-
drivers/staging/tidspbridge/pmgr/msg.c |4 +-
drivers/staging/tidspbridge/rmgr/nldr.c|4 +-
drivers/staging/tidspbridge/rmgr/node.c| 46 ++--
drivers/staging/tidspbridge/rmgr/proc.c|4 +-
8 files changed, 74 insertions(+), 74 deletions(-)
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
b/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
index bed46ca..fc0c008 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
@@ -981,8 +981,8 @@ typedef void (*fxn_msg_setqueueid) (struct msg_queue
*msg_queue_obj,
struct bridge_drv_interface {
u32 brd_api_major_version; /* Set to BRD_API_MAJOR_VERSION. */
u32 brd_api_minor_version; /* Set to BRD_API_MINOR_VERSION. */
- fxn_dev_create pfn_dev_create; /* Create device context */
- fxn_dev_destroy pfn_dev_destroy;/* Destroy device context */
+ fxn_dev_create dev_create; /* Create device context */
+ fxn_dev_destroy dev_destroy;/* Destroy device context */
fxn_dev_ctrl dev_cntrl; /* Optional vendor interface */
fxn_brd_monitor brd_monitor;/* Load and/or start monitor */
fxn_brd_start brd_start;/* Start DSP program. */
@@ -1009,23 +1009,23 @@ struct bridge_drv_interface {
fxn_chnl_idle chnl_idle;/* Idle the channel */
/* Register for notif. */
fxn_chnl_registernotify chnl_register_notify;
- fxn_io_create pfn_io_create;/* Create IO manager */
- fxn_io_destroy pfn_io_destroy; /* Destroy IO manager */
- fxn_io_onloaded pfn_io_on_loaded; /* Notify of program loaded */
+ fxn_io_create io_create;/* Create IO manager */
+ fxn_io_destroy io_destroy; /* Destroy IO manager */
+ fxn_io_onloaded io_on_loaded; /* Notify of program loaded */
/* Get Processor's current and predicted load */
- fxn_io_getprocload pfn_io_get_proc_load;
- fxn_msg_create pfn_msg_create; /* Create message manager */
+ fxn_io_getprocload io_get_proc_load;
+ fxn_msg_create msg_create; /* Create message manager */
/* Create message queue */
- fxn_msg_createqueue pfn_msg_create_queue;
- fxn_msg_delete pfn_msg_delete; /* Delete message manager */
+ fxn_msg_createqueue msg_create_queue;
+ fxn_msg_delete msg_delete; /* Delete message manager */
/* Delete message queue */
- fxn_msg_deletequeue pfn_msg_delete_queue;
- fxn_msg_get pfn_msg_get;/* Get a message */
- fxn_msg_put pfn_msg_put;/* Send a message */
+ fxn_msg_deletequeue msg_delete_queue;
+ fxn_msg_get msg_get;/* Get a message */
+ fxn_msg_put msg_put;/* Send a message */
/* Register for notif. */
- fxn_msg_registernotify pfn_msg_register_notify;
+ fxn_msg_registernotify msg_register_notify;
/* Set message queue id */
- fxn_msg_setqueueid pfn_msg_set_queue_id;
+ fxn_msg_setqueueid msg_set_queue_id;
};
/*
diff --git a/drivers/staging/tidspbridge/include/dspbridge/nldrdefs.h
b/drivers/staging/tidspbridge/include/dspbridge/nldrdefs.h
index b4610af..b1cd1a4 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/nldrdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/nldrdefs.h
@@ -82,7 +82,7 @@ typedef u32(*nldr_writefxn) (void *priv_ref,
* Attributes passed to nldr_create function.
*/
struct nldr_attrs {
- nldr_ovlyfxn pfn_ovly;
+ nldr_ovlyfxn ovly;
nldr_writefxn pfn_write;
u16 us_dsp_word_size;
u16 us_dsp_mau_size;
@@ -283,11 +283,11 @@ struct node_ldr_fxns {
[PATCH 10/12] staging:tidspbridge - set10 remove hungarian from structs
hungarian notation will be removed from the elements inside
structures, the next variables will be renamed:
Original: Replacement:
hnext next
hnode node
hprev prev
hroot root
hstream stream
pbufbuf
pcb_arg cb_arg
pdspheap_list dspheap_list
pmsgmsg
ps_name name
pstr_create_phase_fxn str_create_phase_fxn
pstr_delete_phase_fxn str_delete_phase_fxn
pstr_dev_name str_dev_name
pstr_event_name str_event_name
pstr_execute_phase_fxn str_execute_phase_fxn
pstr_i_alg_name str_i_alg_name
udma_chnl_iddma_chnl_id
un_bufs_in_strm bufs_in_strm
usm_buf_sizesm_buf_size
Signed-off-by: Rene Sapiens rene.sapi...@ti.com
---
drivers/staging/tidspbridge/core/chnl_sm.c | 12 +-
drivers/staging/tidspbridge/core/io_sm.c | 32 +++---
drivers/staging/tidspbridge/dynload/cload.c| 42
.../staging/tidspbridge/dynload/dload_internal.h |6 +-
.../tidspbridge/include/dspbridge/_chnl_sm.h |2 +-
.../tidspbridge/include/dspbridge/chnldefs.h |6 +-
.../tidspbridge/include/dspbridge/dbdcddef.h |8 +-
.../staging/tidspbridge/include/dspbridge/dbdefs.h |6 +-
.../staging/tidspbridge/include/dspbridge/drv.h|6 +-
.../tidspbridge/include/dspbridge/dspapi-ioctl.h | 54 +-
.../tidspbridge/include/dspbridge/strmdefs.h |2 +-
drivers/staging/tidspbridge/pmgr/dspapi.c | 108 ++--
drivers/staging/tidspbridge/rmgr/dbdcd.c | 32 +++---
drivers/staging/tidspbridge/rmgr/disp.c| 24 ++--
drivers/staging/tidspbridge/rmgr/drv.c | 12 +-
drivers/staging/tidspbridge/rmgr/nldr.c|8 +-
drivers/staging/tidspbridge/rmgr/node.c| 58 +-
drivers/staging/tidspbridge/rmgr/strm.c| 24 ++--
18 files changed, 221 insertions(+), 221 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c
b/drivers/staging/tidspbridge/core/chnl_sm.c
index c9470d3..0986d87 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -604,7 +604,7 @@ int bridge_chnl_get_ioc(struct chnl_object *chnl_obj, u32
timeout,
* translated to user's virtual addr later.
*/
host_sys_buf = chnl_packet_obj-host_sys_buf;
- ioc.pbuf = chnl_packet_obj-host_user_buf;
+ ioc.buf = chnl_packet_obj-host_user_buf;
ioc.byte_size = chnl_packet_obj-byte_size;
ioc.buf_size = chnl_packet_obj-buf_size;
ioc.arg = chnl_packet_obj-arg;
@@ -613,7 +613,7 @@ int bridge_chnl_get_ioc(struct chnl_object *chnl_obj, u32
timeout,
list_add_tail(chnl_packet_obj-link,
pchnl-free_packets_list);
} else {
- ioc.pbuf = NULL;
+ ioc.buf = NULL;
ioc.byte_size = 0;
ioc.arg = 0;
ioc.buf_size = 0;
@@ -640,11 +640,11 @@ int bridge_chnl_get_ioc(struct chnl_object *chnl_obj, u32
timeout,
spin_unlock_bh(pchnl-chnl_mgr_obj-chnl_mgr_lock);
if (dequeue_ioc
(pchnl-chnl_type == CHNL_PCPY pchnl-chnl_id 1)) {
- if (!(ioc.pbuf (void *)USERMODE_ADDR))
+ if (!(ioc.buf (void *)USERMODE_ADDR))
goto func_cont;
/* If the addr is in user mode, then copy it */
- if (!host_sys_buf || !ioc.pbuf) {
+ if (!host_sys_buf || !ioc.buf) {
status = -EFAULT;
goto func_cont;
}
@@ -652,7 +652,7 @@ int bridge_chnl_get_ioc(struct chnl_object *chnl_obj, u32
timeout,
goto func_cont1;
/*host_user_buf */
- status = copy_to_user(ioc.pbuf, host_sys_buf, ioc.byte_size);
+ status = copy_to_user(ioc.buf, host_sys_buf, ioc.byte_size);
if (status) {
if (current-flags PF_EXITING)
status = 0;
@@ -806,7 +806,7 @@ int bridge_chnl_open(struct chnl_object **chnl,
pchnl-sync_event = sync_event;
/* Get the process handle */
pchnl-process = current-tgid;
- pchnl-pcb_arg = 0;
+ pchnl-cb_arg = 0;
pchnl-bytes_moved = 0;
/* Default to proc-copy */
pchnl-chnl_type = CHNL_PCPY;
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index fdfb2d4..b5ad410 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -106,7 +106,7 @@ struct io_mgr {
struct msg_ctrl *msg_output_ctrl;
u8 *msg_input; /* Address of input
[PATCH 09/12] staging:tidspbridge - set9 remove hungarian from structs
hungarian notation will be removed from the elements inside
structures, the next variables will be renamed:
Original: Replacement:
hprocessor processor
udma_priority dma_priority
udsp_data_mau_size dsp_data_mau_size
udsp_heap_addr dsp_heap_addr
udsp_heap_res_addr dsp_heap_res_addr
udsp_heap_virt_addr dsp_heap_virt_addr
udsp_mau_size dsp_mau_size
udsp_word_size dsp_word_size
ugpp_heap_addr gpp_heap_addr
ugpp_heap_virt_addr gpp_heap_virt_addr
us_data2data2
us_data3data3
uc_data4data4
uc_data5data5
uc_data6data6
us_load_typeload_type
usm_length sm_length
utimeouttimeout
uwc_deadlinewc_deadline
uwc_execution_time wc_execution_time
uwc_period wc_period
Signed-off-by: Rene Sapiens rene.sapi...@ti.com
---
drivers/staging/tidspbridge/gen/uuidutil.c | 20 ++--
.../tidspbridge/include/dspbridge/dbdcddef.h |2 +-
.../staging/tidspbridge/include/dspbridge/dbdefs.h | 30 ++--
.../staging/tidspbridge/include/dspbridge/drv.h|4 +-
.../tidspbridge/include/dspbridge/dspapi-ioctl.h | 48
.../tidspbridge/include/dspbridge/dspdefs.h|2 +-
.../staging/tidspbridge/include/dspbridge/iodefs.h |2 +-
.../tidspbridge/include/dspbridge/nodepriv.h |8 +-
drivers/staging/tidspbridge/pmgr/dev.c |4 +-
drivers/staging/tidspbridge/pmgr/dspapi.c | 44 +++---
drivers/staging/tidspbridge/pmgr/io.c |2 +-
drivers/staging/tidspbridge/rmgr/dbdcd.c | 12 +-
drivers/staging/tidspbridge/rmgr/disp.c|8 +-
drivers/staging/tidspbridge/rmgr/drv.c |4 +-
drivers/staging/tidspbridge/rmgr/nldr.c|6 +-
drivers/staging/tidspbridge/rmgr/node.c| 138 ++--
drivers/staging/tidspbridge/rmgr/proc.c| 16 +-
drivers/staging/tidspbridge/rmgr/strm.c| 22 ++--
18 files changed, 186 insertions(+), 186 deletions(-)
diff --git a/drivers/staging/tidspbridge/gen/uuidutil.c
b/drivers/staging/tidspbridge/gen/uuidutil.c
index 2aa9b64..ff6ebad 100644
--- a/drivers/staging/tidspbridge/gen/uuidutil.c
+++ b/drivers/staging/tidspbridge/gen/uuidutil.c
@@ -45,11 +45,11 @@ void uuid_uuid_to_string(struct dsp_uuid *uuid_obj, char
*sz_uuid,
i = snprintf(sz_uuid, size,
%.8X_%.4X_%.4X_%.2X%.2X_%.2X%.2X%.2X%.2X%.2X%.2X,
-uuid_obj-data1, uuid_obj-us_data2, uuid_obj-us_data3,
-uuid_obj-uc_data4, uuid_obj-uc_data5,
-uuid_obj-uc_data6[0], uuid_obj-uc_data6[1],
-uuid_obj-uc_data6[2], uuid_obj-uc_data6[3],
-uuid_obj-uc_data6[4], uuid_obj-uc_data6[5]);
+uuid_obj-data1, uuid_obj-data2, uuid_obj-data3,
+uuid_obj-data4, uuid_obj-data5,
+uuid_obj-data6[0], uuid_obj-data6[1],
+uuid_obj-data6[2], uuid_obj-data6[3],
+uuid_obj-data6[4], uuid_obj-data6[5]);
DBC_ENSURE(i != -1);
}
@@ -85,29 +85,29 @@ void uuid_uuid_from_string(char *sz_uuid, struct dsp_uuid
*uuid_obj)
/* Step over underscore */
sz_uuid++;
- uuid_obj-us_data2 = (u16) uuid_hex_to_bin(sz_uuid, 4);
+ uuid_obj-data2 = (u16) uuid_hex_to_bin(sz_uuid, 4);
sz_uuid += 4;
/* Step over underscore */
sz_uuid++;
- uuid_obj-us_data3 = (u16) uuid_hex_to_bin(sz_uuid, 4);
+ uuid_obj-data3 = (u16) uuid_hex_to_bin(sz_uuid, 4);
sz_uuid += 4;
/* Step over underscore */
sz_uuid++;
- uuid_obj-uc_data4 = (u8) uuid_hex_to_bin(sz_uuid, 2);
+ uuid_obj-data4 = (u8) uuid_hex_to_bin(sz_uuid, 2);
sz_uuid += 2;
- uuid_obj-uc_data5 = (u8) uuid_hex_to_bin(sz_uuid, 2);
+ uuid_obj-data5 = (u8) uuid_hex_to_bin(sz_uuid, 2);
sz_uuid += 2;
/* Step over underscore */
sz_uuid++;
for (j = 0; j 6; j++) {
- uuid_obj-uc_data6[j] = (u8) uuid_hex_to_bin(sz_uuid, 2);
+ uuid_obj-data6[j] = (u8) uuid_hex_to_bin(sz_uuid, 2);
sz_uuid += 2;
}
}
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbdcddef.h
b/drivers/staging/tidspbridge/include/dspbridge/dbdcddef.h
index fc2a736..f97266c 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dbdcddef.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dbdcddef.h
@@ -54,7 +54,7 @@ struct dcd_nodeprops {
char *pstr_i_alg_name;
/* Dynamic load properties */
- u16 us_load_type; /* Static, dynamic, overlay */
+ u16 load_type; /* Static, dynamic, overlay */
u32 data_mem_seg_mask; /* Data memory requirements */
u32 code_mem_seg_mask; /*
[PATCH 03/12] staging:tidspbridge - set3 remove hungarian from structs
hungarian notation will be removed from the elements inside
structures, the next variables will be renamed:
Original: Replacement:
dw_seg_base_va seg_base_va
dw_self_loopself_loop
dw_statestate
dw_tc_endianism tc_endianism
dw_test_basetest_base
dw_type type
dw_val1 val1
dw_val2 val2
dw_val3 val3
dw_va va
dw_virt_basevirt_base
dw_vm_base vm_base
dw_vm_size vm_size
pfn_allocateallocate
pfn_brd_mem_copybrd_mem_copy
pfn_brd_mem_map brd_mem_map
pfn_brd_mem_un_map brd_mem_un_map
pfn_brd_mem_write brd_mem_write
pfn_brd_monitor brd_monitor
pfn_brd_readbrd_read
Signed-off-by: Rene Sapiens rene.sapi...@ti.com
---
drivers/staging/tidspbridge/core/_tiomap.h |6 +-
drivers/staging/tidspbridge/core/chnl_sm.c | 22 +-
drivers/staging/tidspbridge/core/io_sm.c | 34
drivers/staging/tidspbridge/core/tiomap3430.c |2 +-
.../tidspbridge/include/dspbridge/_chnl_sm.h |4 +-
.../tidspbridge/include/dspbridge/chnlpriv.h |4 +-
.../tidspbridge/include/dspbridge/cmmdefs.h|6 +-
.../staging/tidspbridge/include/dspbridge/dbdefs.h |6 +-
.../tidspbridge/include/dspbridge/dspdefs.h| 12 +++---
.../tidspbridge/include/dspbridge/nldrdefs.h |2 +-
drivers/staging/tidspbridge/pmgr/cmm.c | 44 ++--
drivers/staging/tidspbridge/pmgr/dev.c | 16
drivers/staging/tidspbridge/rmgr/node.c|6 +-
drivers/staging/tidspbridge/rmgr/proc.c|6 +-
drivers/staging/tidspbridge/rmgr/strm.c|2 +-
15 files changed, 86 insertions(+), 86 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index 919e22c..1cd3282 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -321,9 +321,9 @@ struct bridge_dev_context {
u32 dsp_clk_m2_base;/* DSP Clock Module m2 */
u32 public_rhea;/* Pub Rhea */
u32 int_addr; /* MB INTR reg */
- u32 dw_tc_endianism;/* TC Endianism register */
- u32 dw_test_base; /* DSP MMU Mapped registers */
- u32 dw_self_loop; /* Pointer to the selfloop */
+ u32 tc_endianism; /* TC Endianism register */
+ u32 test_base; /* DSP MMU Mapped registers */
+ u32 self_loop; /* Pointer to the selfloop */
u32 dsp_start_add; /* API Boot vector */
u32 internal_size; /* Internal memory size */
diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c
b/drivers/staging/tidspbridge/core/chnl_sm.c
index 59b8d55..c204315 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -115,7 +115,7 @@ int bridge_chnl_add_io_req(struct chnl_object *chnl_obj,
void *host_buf,
* Check the channel state: only queue chirp if channel state
* allows it.
*/
- dw_state = pchnl-dw_state;
+ dw_state = pchnl-state;
if (dw_state != CHNL_STATEREADY) {
if (dw_state CHNL_STATECANCEL)
return -ECANCELED;
@@ -207,7 +207,7 @@ func_cont:
* more IOR's.
*/
if (is_eos)
- pchnl-dw_state |= CHNL_STATEEOS;
+ pchnl-state |= CHNL_STATEEOS;
/* Legacy DSM Processor-Copy */
DBC_ASSERT(pchnl-chnl_type == CHNL_PCPY);
@@ -258,7 +258,7 @@ int bridge_chnl_cancel_io(struct chnl_object *chnl_obj)
* IORequests or dispatching. */
spin_lock_bh(chnl_mgr_obj-chnl_mgr_lock);
- pchnl-dw_state |= CHNL_STATECANCEL;
+ pchnl-state |= CHNL_STATECANCEL;
if (list_empty(pchnl-pio_requests)) {
spin_unlock_bh(chnl_mgr_obj-chnl_mgr_lock);
@@ -312,7 +312,7 @@ int bridge_chnl_close(struct chnl_object *chnl_obj)
if (status)
return status;
/* Assert I/O on this channel is now cancelled: Protects from io_dpc */
- DBC_ASSERT((pchnl-dw_state CHNL_STATECANCEL));
+ DBC_ASSERT((pchnl-state CHNL_STATECANCEL));
/* Invalidate channel object: Protects from CHNL_GetIOCompletion() */
/* Free the slot in the channel manager: */
pchnl-chnl_mgr_obj-ap_channel[pchnl-chnl_id] = NULL;
@@ -381,7 +381,7 @@ int bridge_chnl_create(struct chnl_mgr **channel_mgr,
* max_channels, GFP_KERNEL);
if (chnl_mgr_obj-ap_channel) {
/* Initialize chnl_mgr object */
- chnl_mgr_obj-dw_type = CHNL_TYPESM;
+ chnl_mgr_obj-type = CHNL_TYPESM;
[PATCH 07/12] staging:tidspbridge - set7 remove hungarian from structs
hungarian notation will be removed from the elements inside
structures, the next variables will be renamed:
Original: Replacement:
ul_gpp_phys gpp_phys
ul_gpp_read_pointer gpp_read_pointer
ul_gpp_size gpp_size
ul_gpp_va gpp_va
ul_heap_sizeheap_size
ul_internal_mem_sizeinternal_mem_size
ul_in_use_cnt in_use_cnt
ul_len_max_free_block len_max_free_block
ul_max max
ul_min_block_size min_block_size
ul_min min
ul_mpu_addr mpu_addr
ul_n_bytes bytes
ul_num_alloc_blocks num_alloc_blocks
ul_number_bytes number_bytes
ul_num_chnlsnum_chnls
ul_num_free_blocks num_free_blocks
ul_num_gppsm_segs num_gppsm_segs
ul_pos pos
ul_reserved reserved
Signed-off-by: Rene Sapiens rene.sapi...@ti.com
---
drivers/staging/tidspbridge/core/io_sm.c | 62 ++--
drivers/staging/tidspbridge/core/tiomap3430.c |2 +-
drivers/staging/tidspbridge/core/tiomap_io.c |4 +-
.../tidspbridge/include/dspbridge/cfgdefs.h|4 +-
.../staging/tidspbridge/include/dspbridge/cmm.h|2 +-
.../tidspbridge/include/dspbridge/cmmdefs.h| 12 ++--
.../staging/tidspbridge/include/dspbridge/cod.h|2 +-
.../staging/tidspbridge/include/dspbridge/dbdefs.h | 12 ++--
.../staging/tidspbridge/include/dspbridge/drv.h|2 +-
.../tidspbridge/include/dspbridge/dspioctl.h |2 +-
.../tidspbridge/include/dspbridge/mgrpriv.h|2 +-
drivers/staging/tidspbridge/pmgr/cmm.c | 30 +-
drivers/staging/tidspbridge/pmgr/dbll.c| 12 ++--
drivers/staging/tidspbridge/rmgr/dbdcd.c |6 +-
drivers/staging/tidspbridge/rmgr/node.c| 22
drivers/staging/tidspbridge/rmgr/rmm.c | 12 ++--
drivers/staging/tidspbridge/rmgr/strm.c|4 +-
17 files changed, 96 insertions(+), 96 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index a36ad23..299621d 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -118,9 +118,9 @@ struct io_mgr {
u32 ul_trace_buffer_begin; /* Trace message start address */
u32 ul_trace_buffer_end;/* Trace message end address */
u32 ul_trace_buffer_current;/* Trace message current address */
- u32 ul_gpp_read_pointer;/* GPP Read pointer to Trace buffer */
+ u32 gpp_read_pointer; /* GPP Read pointer to Trace buffer */
u8 *pmsg;
- u32 ul_gpp_va;
+ u32 gpp_va;
u32 dsp_va;
#endif
/* IO Dpc */
@@ -532,7 +532,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
* This is the virtual uncached ioremapped
* address!!!
*/
- ae_proc[ndx].ul_gpp_va = gpp_va_curr;
+ ae_proc[ndx].gpp_va = gpp_va_curr;
ae_proc[ndx].dsp_va =
va_curr / hio_mgr-word_size;
ae_proc[ndx].ul_size = page_size[i];
@@ -542,7 +542,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
dev_dbg(bridge, shm MMU TLB entry PA %x
VA %x DSP_VA %x Size %x\n,
ae_proc[ndx].gpp_pa,
- ae_proc[ndx].ul_gpp_va,
+ ae_proc[ndx].gpp_va,
ae_proc[ndx].dsp_va *
hio_mgr-word_size, page_size[i]);
ndx++;
@@ -557,7 +557,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
shm MMU PTE entry PA %x
VA %x DSP_VA %x Size %x\n,
ae_proc[ndx].gpp_pa,
- ae_proc[ndx].ul_gpp_va,
+ ae_proc[ndx].gpp_va,
ae_proc[ndx].dsp_va *
hio_mgr-word_size, page_size[i]);
if (status)
@@ -580,12 +580,12 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
* should not conflict with shm entries on MPU or DSP side.
*/
for (i = 3; i 7 ndx BRDIOCTL_NUMOFMMUTLB; i++) {
- if (hio_mgr-ext_proc_info.ty_tlb[i].ul_gpp_phys == 0)
+ if (hio_mgr-ext_proc_info.ty_tlb[i].gpp_phys == 0)
continue;
- if ((hio_mgr-ext_proc_info.ty_tlb[i].ul_gpp_phys
+ if ((hio_mgr-ext_proc_info.ty_tlb[i].gpp_phys
Re: [PATCHv6 4/4] omap: iommu - create new api to set valid da range
On Tue, Dec 14, 2010 at 8:59 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Tue, Dec 14, 2010 at 9:08 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Dec 14, 2010 at 3:07 PM, Fernando Guzman Lugo fernando.l...@ti.com wrote: From: Guzman Lugo, Fernando x0095...@ti.com Some IOMMUs cannot use the whole 0x0 - 0x rage. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com I still don't see where this API is being used. you can find it here: http://marc.info/?l=linux-kernelm=128805403014740w=2 Oh, ok, thanks. somehow I missed it. Also, the point of using platform data was to add it to omap3_devices in omap-iommu.c, see[1]. I thought the platform data start/end would move to struct iommu, and iommu_set_da_range would change the start/end on struct iommu, but that would only be necessary if the platform data doesn't match that. it is not clear for me. do you mean having default start/end in platform data then when iommu_get is call pass them to start/end in struct iommu and the new api change start/end in struct iommu? Please let me know if that is correct. Yeah, if you are not going to add it in the platform data (mach-omap2/omap-iommu.c), then it doesn't make sense to use platform data for that. 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 v2] MTD: NAND: ams-delta: convert to platform driver
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [101214 12:31]: In its current form, the driver may interfere with different hardware on different boards if built into the kernel, hence is not suitable for inclusion into a defconfig, inteded to be usable with multiple OMAP1 cpu and machine types. Convert it to a platform driver, that should be free from this issue. Created and tested against linux-2.6.37-rc5 on Amstrad Delta. Good to see this happen, I assume this is for MTD. If not and you want me to merge it instead, let me know. Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/9] OMAP: DMA: hwmod and DMA as platform device
* G, Manjunath Kondaiah manj...@ti.com [101203 19:33]: * Test Report: Build: omap2plus_defconfig: Success omap_osk_5912_defconfig: Success Boot: OMAP3530Beagle : Success OMAP4430Blaze(ES2.1) : Success Can you please make sure that memory to memory DMA test runs OK on OSK5912?x AFAIK, Kevin tried it a few days ago and it hung. To me that sounds like the only remaining issue merging these in for testing. 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens, On Tuesday 14 December 2010 14:49:15 Clemens Ladisch wrote: Laurent Pinchart wrote: On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote: On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: * Entity types TYPE_NODE was renamed to TYPE_DEVICE because node sounds like a node in a graph, which does not distinguish it from other entity types because all entities are part of the topology graph. I chose device as this type describes entities that are visible as some device node to other software. What this type describes is a device node. Both NODE and DEVICE can be confusing in my opinion, but DEVICE_NODE is a bit long. What about DEVNODE? I think that would be a good alternative. Fine with me. Clemens, any opinion on that ? Fine with me too. OK I'll use that name. TYPE_EXT describes entities that represent some interface to the external world, TYPE_INT those that are internal to the entire device. (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems to be an even more meaningless name.) SUBDEV comes from the V4L2 world, and I agree that it might not be a very good name. SUBDEV refers to a specific type of driver. Within the v4l world it is well defined. So I prefer to keep this. Perhaps some additional comments or documentation can be added to clarify this. Should this be clarified by using V4L2_SUBDEV instead then ? If the SUBDEV concept doesn't exist outside V4L, that would indeed be better. I don't want to rename things that come out of existing frameworks; this naming discussion makes sense only for those entity (sub)types that can be shared between them. Are there any, besides jacks? Some entities like TV tuners play a dual audio/video role. I'm not sure how to handle them, I lack experience in that field. What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ? The entity types representing ALSA devices are already named ALSA. I was talking about the INT_* types. They're ALSA-specific, but have no ALSA in the type name. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap_device: use pdev as parameter to get rt_va
Hello Omar On Mon, 13 Dec 2010, Ramirez Luna, Omar wrote: On Mon, Dec 13, 2010 at 2:12 AM, Cousson, Benoit b-cous...@ti.com wrote: On 12/11/2010 12:45 AM, Ramirez Luna, Omar wrote: Make the parameter received by omap_device_get_mpu_rt_va consistent with the functions meant to be called by drivers. Also move its header declaration to appear in the set of functions to be used by drivers, as per the comment there. Please note that even if Paul submitted this API upon request from Santosh, we do not want driver to us it most of the time. Oh, ok. Yes, I was under the impression that this ioremap was internal to hwmod, and drivers should do their own one but then I noticed that API and since it was under the public functions through struct platform data, I thought it was easier to pass pdev than od. All drivers should us the generic Linux way to get physical mem resource and then ioremap it. Then I guess this function belongs to the public for core code and not for drivers along with the omap_device_get_pwrdm. I assume that if you want to update this API, you are probably already using it. Why cannot you use the generic way? I can leave the generic way along with ioremap, the purpose was to use omap_device APIs as much as possible. The above isn't quite it. What I'd suggest you do in your code is this: - In your driver-to-core-OMAP integration code in arch/arm/*omap*, call omap_hwmod_get_mpu_rt_va(), and pass that to the driver via an entry in the struct platform_data. - In your driver code in drivers/*, test to see if that struct platform_data entry is NULL. If it is, only then should your driver ioremap(). Otherwise, it should use the address from the struct platform_data. This is because it's not guaranteed that ioremap() on OMAP will continue to reuse the current static mapping in the future. We've heard from some mobile OS vendors that they are under significant address space constraints, so on those distributions it might make sense to only map devices that are actually in use, and take the additional TLB entry cost. Does this make sense? - 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 v1 0/9] OMAP: DMA: hwmod and DMA as platform device
Tony Lindgren t...@atomide.com writes: * G, Manjunath Kondaiah manj...@ti.com [101203 19:33]: * Test Report: Build: omap2plus_defconfig: Success omap_osk_5912_defconfig: Success Boot: OMAP3530Beagle : Success OMAP4430Blaze(ES2.1) : Success Can you please make sure that memory to memory DMA test runs OK on OSK5912?x AFAIK, Kevin tried it a few days ago and it hung. Yes, it hung, but I didn't have time to debug the root cause until today. The reason is that the OMAP1 DMA IRQ numbers used in mach-omap1/dma.c have no basis in reality. So doing a memory-to-memory transfer using *all* channels results in spurious interrupts, then hangs. Will post details in reply to the OMAP1 patch (7/9). 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
[PATCHv7 0/4] omap: iovmm - fixes for iovmm module
Misc fixes found while working with iovmm module. They are needed in order to tidspbridge can work properly along with iovmm module. Version 7: * Change 4/4 patch base on Felipe Contreras comments about having start/end in platform data and struct iommu. Version 6: * Rebase on Russell King branch. - for details see: http://marc.info/?l=linux-omapm=129228495723001w=2 Version 5: * Changes in iommu: create new api to set valid da range - Change range variables to platform data structure. Version 4: * Changes in iommu: create new api to set valid da range - Validate range for fixed address. - Change way of change boundaries to avoid possible overflow instead of style : start + bytes = end which start + end can overflow use style: end - start bytes Version 3: * change patch 2 base on Felipe Contreras' comments, now it uses min_t and I deleted some blank lines. * patch create new api to set valid da range is base on iovmm: IVA2 MMU range is from 0x1100 to 0x patch and on Hiroshi's comments and now it is added to this set. Version 2: * Removed iovmm: fixes for iovmm module that patch was already sent. * Modified iovmm: fix roundup for next area and end check for the last area patch, base on Davin Cohen's comments and rename it to a proper name that describes what it is doing now. Guzman Lugo, Fernando (4): omap: iovmm - no gap checking for fixed address omap: iovmm - add superpages support to fixed da address omap: iovmm - replace __iounmap with iounmap omap: iommu - create new api to set valid da range arch/arm/mach-omap2/omap-iommu.c|8 +++ arch/arm/plat-omap/include/plat/iommu.h |5 ++ arch/arm/plat-omap/iommu.c | 24 + arch/arm/plat-omap/iovmm.c | 81 +- 4 files changed, 83 insertions(+), 35 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 2/4] omap: iovmm - add superpages support to fixed da address
From: Guzman Lugo, Fernando x0095...@ti.com
This patch adds superpages support to fixed ad address
inside iommu_kmap function.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c | 62 +--
1 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 34f0012..93a34d9 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -87,35 +87,43 @@ 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;
+}
+
/*
* calculate the optimal number sg elements from total bytes based on
* iommu superpages
*/
-static unsigned int sgtable_nents(size_t bytes)
+static unsigned 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 nr_entries = 0, ent_sz;
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_t(unsigned, ent_sz, iopgsz_max(bytes));
+ nr_entries++;
+ da += ent_sz;
+ pa += ent_sz;
+ bytes -= ent_sz;
}
- BUG_ON(bytes);
return nr_entries;
}
/* 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 +135,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 +416,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;
@@ -418,9 +426,10 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32
pa, size_t len)
va = phys_to_virt(pa);
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
- size_t bytes;
+ unsigned bytes;
- bytes = iopgsz_max(len);
+ bytes = max_alignment(da | pa);
+ bytes = min_t(unsigned, bytes, iopgsz_max(len));
BUG_ON(!iopgsz_ok(bytes));
@@ -429,6 +438,7 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32
pa, size_t len)
* 'pa' is cotinuous(linear).
*/
pa += bytes;
+ da += bytes;
len -= bytes;
}
BUG_ON(len);
@@ -695,18 +705,18 @@ u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t
bytes, u32 flags)
if (!va)
return -ENOMEM;
- sgt = sgtable_alloc(bytes, flags);
+ flags = IOVMF_HW_MASK;
+ flags |= IOVMF_DISCONT;
+ flags |= IOVMF_ALLOC;
+ flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
+
+ sgt = sgtable_alloc(bytes, flags, da, 0);
if (IS_ERR(sgt)) {
da = PTR_ERR(sgt);
goto err_sgt_alloc;
}
sgtable_fill_vmalloc(sgt, va);
- flags = IOVMF_HW_MASK;
- flags |= IOVMF_DISCONT;
- flags |= IOVMF_ALLOC;
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
-
da = __iommu_vmap(obj, da, sgt, va, bytes, flags);
if (IS_ERR_VALUE(da))
goto err_iommu_vmap;
@@ -746,11 +756,11 @@ static u32 __iommu_kmap(struct iommu *obj, u32 da, u32
pa, void *va,
{
struct sg_table *sgt;
- sgt =
[PATCHv7 4/4] omap: iommu - create new api to set valid da range
From: Guzman Lugo, Fernando x0095...@ti.com
Some IOMMUs cannot use the whole 0x0 - 0x range.
With this new API the valid range can be set.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/omap-iommu.c|8
arch/arm/plat-omap/include/plat/iommu.h |5 +
arch/arm/plat-omap/iommu.c | 24
arch/arm/plat-omap/iovmm.c | 15 ---
4 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..6be548c 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -33,6 +33,8 @@ static struct iommu_device omap3_devices[] = {
.name = isp,
.nr_tlb_entries = 8,
.clk_name = cam_ick,
+ .da_start = 0x0,
+ .da_end = 0xF000,
},
},
#if defined(CONFIG_MPU_BRIDGE_IOMMU)
@@ -43,6 +45,8 @@ static struct iommu_device omap3_devices[] = {
.name = iva2,
.nr_tlb_entries = 32,
.clk_name = iva2_ck,
+ .da_start = 0x1100,
+ .da_end = 0xF000,
},
},
#endif
@@ -64,6 +68,8 @@ static struct iommu_device omap4_devices[] = {
.name = ducati,
.nr_tlb_entries = 32,
.clk_name = ducati_ick,
+ .da_start = 0x0,
+ .da_end = 0xF000,
},
},
#if defined(CONFIG_MPU_TESLA_IOMMU)
@@ -74,6 +80,8 @@ static struct iommu_device omap4_devices[] = {
.name = tesla,
.nr_tlb_entries = 32,
.clk_name = tesla_ick,
+ .da_start = 0x0,
+ .da_end = 0xF000,
},
},
#endif
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 33c7d41..69230d6 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -50,6 +50,8 @@ struct iommu {
int (*isr)(struct iommu *obj);
void *ctx; /* iommu context: registres saved area */
+ u32 da_start;
+ u32 da_end;
};
struct cr_regs {
@@ -103,6 +105,8 @@ struct iommu_platform_data {
const char *name;
const char *clk_name;
const int nr_tlb_entries;
+ u32 da_start;
+ u32 da_end;
};
#if defined(CONFIG_ARCH_OMAP1)
@@ -152,6 +156,7 @@ extern void flush_iotlb_all(struct iommu *obj);
extern int iopgtable_store_entry(struct iommu *obj, struct iotlb_entry *e);
extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova);
+extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
extern struct iommu *iommu_get(const char *name);
extern void iommu_put(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 6cd151b..b1107c0 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -830,6 +830,28 @@ static int device_match_by_alias(struct device *dev, void
*data)
}
/**
+ * iommu_set_da_range - Set a valid device address range
+ * @obj: target iommu
+ * @start Start of valid range
+ * @endEnd of valid range
+ **/
+int iommu_set_da_range(struct iommu *obj, u32 start, u32 end)
+{
+
+ if (!obj)
+ return -EFAULT;
+
+ if (end start || !PAGE_ALIGN(start | end))
+ return -EINVAL;
+
+ obj-da_start = start;
+ obj-da_end = end;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_set_da_range);
+
+/**
* iommu_get - Get iommu handler
* @name: target iommu name
**/
@@ -922,6 +944,8 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
obj-name = pdata-name;
obj-dev = pdev-dev;
obj-ctx = (void *)obj + sizeof(*obj);
+ obj-da_start = pdata-da_start;
+ obj-da_end = pdata-da_end;
mutex_init(obj-iommu_lock);
mutex_init(obj-mmap_lock);
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index fa6e643..6dc1296 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -280,13 +280,14 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
alignement = PAGE_SIZE;
if (flags IOVMF_DA_ANON) {
- /*
-* Reserve the first page for NULL
-*/
- start = PAGE_SIZE;
+ start = obj-da_start;
+
if (flags IOVMF_LINEAR)
alignement = iopgsz_max(bytes);
start = roundup(start, alignement);
+ } else if (start obj-da_start ||
[PATCHv7 3/4] omap: iovmm - replace __iounmap with iounmap
From: Guzman Lugo, Fernando x0095...@ti.com __iounmap function is wrong for OMAP architecture, instead use iounmap which will call to the correct function. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 93a34d9..fa6e643 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)iounmap, IOVMF_LINEAR | IOVMF_MMIO); if (!sgt) dev_dbg(obj-dev, %s: No sgt\n, __func__); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 1/4] omap: iovmm - no gap checking for fixed address
From: Guzman Lugo, Fernando x0095...@ti.com
If some fixed da address is wanted to be mapped and the page
is freed but it is used as gap, the mapping will fail.
This patch is fixing that and olny keeps the gap for
not fixed address.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 8ce0de2..34f0012 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -289,10 +289,10 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
prev_end = 0;
list_for_each_entry(tmp, obj-mmap, list) {
- if (prev_end = start)
+ if (prev_end start)
break;
- if (start + bytes tmp-da_start)
+ if (start + bytes = tmp-da_start)
goto found;
if (flags IOVMF_DA_ANON)
@@ -301,7 +301,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
prev_end = tmp-da_end;
}
- if ((start prev_end) (ULONG_MAX - start = bytes))
+ if ((start = prev_end) (ULONG_MAX - start + 1 = bytes))
goto found;
dev_dbg(obj-dev, %s: no space to fit %08x(%x) flags: %08x\n,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 7/9] OMAP1: DMA: Implement in platform device model
Kevin Hilman khil...@deeprootsystems.com writes:
[...]
Using the patch below which fixes up the interrupt numbers to match the
original code, the memory-to-memory test is now working on OSK.
Tony, if you prefer just to fold this into the original, feel free to
add
[khil...@deeprootsystems.com]: fixed IRQ numbers to match original code
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 17814e0..d855934 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -121,58 +121,58 @@ static struct resource res[] __initdata = {
/* Handled in lcd_dma.c */
[7] = {
.name = 6,
- .start = INT_DMA_LCD,
+ .start = INT_1610_DMA_CH6,
.flags = IORESOURCE_IRQ,
},
/* irq's for omap16xx and omap7xx */
[8] = {
.name = 7,
- .start = 53 + IH2_BASE,
+ .start = INT_1610_DMA_CH7,
.flags = IORESOURCE_IRQ,
},
[9] = {
.name = 8,
- .start = 54 + IH2_BASE,
+ .start = INT_1610_DMA_CH8,
.flags = IORESOURCE_IRQ,
},
[10] = {
.name = 9,
- .start = 55 + IH2_BASE,
+ .start = INT_1610_DMA_CH9,
.flags = IORESOURCE_IRQ,
},
[11] = {
.name = 10,
- .start = 56 + IH2_BASE,
+ .start = INT_1610_DMA_CH10,
.flags = IORESOURCE_IRQ,
},
[12] = {
.name = 11,
- .start = 57 + IH2_BASE,
+ .start = INT_1610_DMA_CH11,
.flags = IORESOURCE_IRQ,
},
[13] = {
.name = 12,
- .start = 58 + IH2_BASE,
+ .start = INT_1610_DMA_CH12,
.flags = IORESOURCE_IRQ,
},
[14] = {
.name = 13,
- .start = 59 + IH2_BASE,
+ .start = INT_1610_DMA_CH13,
.flags = IORESOURCE_IRQ,
},
[15] = {
.name = 14,
- .start = 60 + IH2_BASE,
+ .start = INT_1610_DMA_CH14,
.flags = IORESOURCE_IRQ,
},
[16] = {
.name = 15,
- .start = 61 + IH2_BASE,
+ .start = INT_1610_DMA_CH15,
.flags = IORESOURCE_IRQ,
},
[17] = {
.name = 16,
- .start = 62 + IH2_BASE,
+ .start = INT_DMA_LCD,
.flags = IORESOURCE_IRQ,
},
};
--
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 v1 7/9] OMAP1: DMA: Implement in platform device model
* Kevin Hilman khil...@deeprootsystems.com [101214 16:55]: Kevin Hilman khil...@deeprootsystems.com writes: [...] Using the patch below which fixes up the interrupt numbers to match the original code, the memory-to-memory test is now working on OSK. Tony, if you prefer just to fold this into the original, feel free to add [khil...@deeprootsystems.com]: fixed IRQ numbers to match original code Signed-off-by: Kevin Hilman khil...@deeprootsystems.com OK thanks, will fold it in and let's merge them into linux-omap master branch for few days for testing. Then if everything looks good, I'll queue these for the 2.6.38 next merge window. 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 0/5] OMAP4: hwmod data fixes and update
On Fri, 10 Dec 2010, Benoit Cousson wrote: Here is a small set of OMAP4 hwmod data updates. Re-order properly the data that were a little bit shuffled during the previous merge window. Add the new reset flags introduced in 2.6.37 and that were not used in the hwmod data. The OMAP2 and OMAP3 fixes should come soon. Fix some missing field in the GPIO OMAP4 hwmod data that I missed during the review. IVA and DSP are added just to allow the processors device creation at boot time and avoid the warnings. Thanks to Charu for testing the GPIO / WD_TIMER changes. Thanks to Govindraj for testing the UART changes. The series is based on lo/for-next (v2.6.37-rc5-66-ga2814df) and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod_data Please note that there is a slight dependency with the following patch due to the name change of the iva fclk: OMAP4: clock data: Add missing DPLL x2 clock node https://patchwork.kernel.org/patch/396612/ Tested on sdp4430 + ES2.0/ES2.1. Regards, Benoit Benoit Cousson (5): OMAP4: hwmod data: Fix hwmod entries order OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flag OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW OMAP4: hwmod data: Add IVA and DSP OMAP4: hwmod clock data: Fix GPIO opt_clks and ocp_if iclk Thanks, queued for 2.6.38 with some tweaks. I've replied to the original patches with the details. The current integration tag that contains these patches is 'integration-2.6.38-20101214-010' available from git://git.pwsan.com/linux-integration - 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 5/5] OMAP4: hwmod clock data: Fix GPIO opt_clks and ocp_if iclk
On Fri, 10 Dec 2010, Benoit Cousson wrote: Fix opt clocks name in clock framework and hwmod. Add the missing iclk in the ocp_if structure. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to ensure the the GPIO optional clock is enable during reset. Signed-off-by: Benoit Cousson b-cous...@ti.com Tested-by: Charulatha V ch...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com This one I just tweaked the commit message slightly on. Revised message is below. - Paul OMAP4: hwmod clock data: Fix GPIO opt_clks and ocp_if iclk Fix opt clocks name in clock framework and hwmod. Add the missing iclk in the ocp_if structure. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to ensure that the GPIO optional clock is enabled during reset, since it must be enabled for the IP block to reset successfully. Signed-off-by: Benoit Cousson b-cous...@ti.com Tested-by: Charulatha V ch...@ti.com [p...@pwsan.com: fix the commit message] Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] OMAP4: PRCM: Add SCRM header file
Salut Benoît On Tue, 14 Dec 2010, Cousson, Benoit wrote: Well, I sent this series before you sent your prcm one, so at the time the dependency didn't exist ;-) No worries, it was just meant to be a general suggestion, not a specific one to this case. As far as the empty scrm44xx.h goes, I will probably go back and rebuild that branch with your patch that creates SCRM from my patch set inserted earlier, so I can drop the part of my patch that creates the empty file. I went ahead and moved the SCRM patch earlier in the branch sets. I did make one change in it - I'll reply to it with the update details. The current integration tag that contains the revised patch is 'integration-2.6.38-20101214-010' available from git://git.pwsan.com/linux-integration - Paul
Re: [PATCH v1 0/9] OMAP: DMA: hwmod and DMA as platform device
G, Manjunath Kondaiah manj...@ti.com writes: Patch series to convert DMA library into platform driver using platform device model and adapting hwmod for omap2+. After the OMAP1 fixup for PATCH 7/9, Acked-by: Kevin Hilman khil...@deeprootsystems.com and Tested-by: Kevin Hilman khil...@deeprootsystems.com on omap1611/OSK, omap3430/n900 and omap4430/panda Tested using a memory-to-memory DMA test which tests all available channels, and tests linking all the channels together. I resurected an older DMA test that I wrote sometime around 2004, and lost somehow (thankfully, Tony still had a copy.) I've updated it slightly and created a git repo for it now that it is known working on OMAP1, 2, 3 and 4. git://gitorious.org/omap-test/dmatest.git It's a bit hacky as you have to manually edit the Makefile to build an out of tree module, but it does work. Kevin The original patch series : http://comments.gmane.org/gmane.linux.ports.arm.omap/46953 has been split into two patch series based on suggestion from Tony. (https://patchwork.kernel.org/patch/375831/) The first series will prepare existing DMA library for DMA hwmod and converting the same into platform driver. The second series will have: arch/arm/mach-omap1/dma.c omap1 specific platform init arch/arm/mach-omap2/dma.c omap2+ specific platform init drivers/dma/omap-dma.c driver using dmaengine.c Patch series1 Design: 1. The low level read/write macros are converted into static inline functions so that, these functions can be moved to respective mach-omap driver files later. (Thanks to Tony and Kevin for their suggestions on handling all omap register offset without adding extra enums) 2. Implements generic errata handling for all OMAP DMA errata. 3. DMA hwmod data is updated for respective hwmod db files. 4. The DMA library is split into two layers. a. The generic code is retained in plat-omap/dma.c b. The machine specific init code is moved to respective mach-omap dma files. Minimal machine specific code is moved to respective mach-omap dma files with this series. Rest of code movement and API cleanup's are handled in second series. Patch series applies on top of latest linux omap master branch: * git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Branch: master commit a04fd22204b13ce34a3f8a8157f83c44d64f8da9 Merge: e941bb0 afd2d11 Author: Tony Lindgren t...@atomide.com Linux-omap rebuilt: Merged in usb patches for testing * Test Report: Build: omap2plus_defconfig: Success omap_osk_5912_defconfig: Success Boot: OMAP3530Beagle : Success OMAP4430Blaze(ES2.1) : Success OMAP1(OSK5912) : Success Test cases executed: 1. All applicable TI DMA tests which are located at: git://dev.omapzoom.org/pub/scm/richo/device_driver_test.git Branch: master Report can be accessed at: Beagle board: http://pastebin.com/sDUChNLr The original patch series and change history can be found at: http://permalink.gmane.org/gmane.linux.ports.arm.omap/46953# Benoit Cousson (1): OMAP4: hwmod data: add system DMA G, Manjunath Kondaiah (8): OMAP: DMA: Replace read/write macros with functions OMAP: DMA: Introduce errata handling feature OMAP2420: hwmod data: add system DMA OMAP2430: hwmod data: add system DMA OMAP3: hwmod data: add system DMA OMAP1: DMA: Implement in platform device model OMAP2+: DMA: hwmod: Device registration OMAP: DMA: Convert DMA library into platform driver arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/dma.c | 390 arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dma.c | 297 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 87 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 87 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 97 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 101 arch/arm/plat-omap/dma.c | 697 arch/arm/plat-omap/include/plat/dma.h | 232 -- 10 files changed, 1452 insertions(+), 540 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.c create mode 100644 arch/arm/mach-omap2/dma.c Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 0/4] omap: iovmm - fixes for iovmm module
Fernando, For omap patches, follow the convention OMAP: iommu: subject OMAP: iovmm: subject Ref: http://www.spinics.net/lists/linux-omap/msg39956.html On Tue, Dec 14, 2010 at 6:53 PM, Fernando Guzman Lugo fernando.l...@ti.com wrote: Misc fixes found while working with iovmm module. They are needed in order to tidspbridge can work properly along with iovmm module. Version 7: * Change 4/4 patch base on Felipe Contreras comments about having start/end in platform data and struct iommu. Version 6: * Rebase on Russell King branch. - for details see: http://marc.info/?l=linux-omapm=129228495723001w=2 Version 5: * Changes in iommu: create new api to set valid da range - Change range variables to platform data structure. Version 4: * Changes in iommu: create new api to set valid da range - Validate range for fixed address. - Change way of change boundaries to avoid possible overflow instead of style : start + bytes = end which start + end can overflow use style: end - start bytes Version 3: * change patch 2 base on Felipe Contreras' comments, now it uses min_t and I deleted some blank lines. * patch create new api to set valid da range is base on iovmm: IVA2 MMU range is from 0x1100 to 0x patch and on Hiroshi's comments and now it is added to this set. Version 2: * Removed iovmm: fixes for iovmm module that patch was already sent. * Modified iovmm: fix roundup for next area and end check for the last area patch, base on Davin Cohen's comments and rename it to a proper name that describes what it is doing now. Guzman Lugo, Fernando (4): omap: iovmm - no gap checking for fixed address omap: iovmm - add superpages support to fixed da address omap: iovmm - replace __iounmap with iounmap omap: iommu - create new api to set valid da range arch/arm/mach-omap2/omap-iommu.c | 8 +++ arch/arm/plat-omap/include/plat/iommu.h | 5 ++ arch/arm/plat-omap/iommu.c | 24 + arch/arm/plat-omap/iovmm.c | 81 +- 4 files changed, 83 insertions(+), 35 deletions(-) -- Thank you, Best regards, Hari Kanigeri -- 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 v1 0/9] OMAP: DMA: hwmod and DMA as platform device
* Kevin Hilman khil...@deeprootsystems.com [101214 17:37]: G, Manjunath Kondaiah manj...@ti.com writes: Patch series to convert DMA library into platform driver using platform device model and adapting hwmod for omap2+. After the OMAP1 fixup for PATCH 7/9, Acked-by: Kevin Hilman khil...@deeprootsystems.com I guess here you mean Signed-off-by for this patch since you wrote some code? Assuming Signed-off-by, let me know if you want to change that. and Tested-by: Kevin Hilman khil...@deeprootsystems.com Adding this to the others in the series. 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 v1 7/9] OMAP1: DMA: Implement in platform device model
On Tue, Dec 14, 2010 at 05:04:00PM -0800, Tony Lindgren wrote: * Kevin Hilman khil...@deeprootsystems.com [101214 16:55]: Kevin Hilman khil...@deeprootsystems.com writes: [...] Using the patch below which fixes up the interrupt numbers to match the original code, the memory-to-memory test is now working on OSK. Tony, if you prefer just to fold this into the original, feel free to add [khil...@deeprootsystems.com]: fixed IRQ numbers to match original code Signed-off-by: Kevin Hilman khil...@deeprootsystems.com OK thanks, will fold it in and let's merge them into linux-omap master branch for few days for testing. Then if everything looks good, I'll queue these for the 2.6.38 next merge window. Thanks Tony. -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: [PATCH v1 0/9] OMAP: DMA: hwmod and DMA as platform device
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@deeprootsystems.com [101214 17:37]: G, Manjunath Kondaiah manj...@ti.com writes: Patch series to convert DMA library into platform driver using platform device model and adapting hwmod for omap2+. After the OMAP1 fixup for PATCH 7/9, Acked-by: Kevin Hilman khil...@deeprootsystems.com I guess here you mean Signed-off-by for this patch since you wrote some code? Assuming Signed-off-by, let me know if you want to change that. I only added my s-o-b to PATCH 7/9 since that's the only one I added code to. Kevin and Tested-by: Kevin Hilman khil...@deeprootsystems.com Adding this to the others in the series. 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 v1 0/9] OMAP: DMA: hwmod and DMA as platform device
* Kevin Hilman khil...@deeprootsystems.com [101214 18:02]: Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@deeprootsystems.com [101214 17:37]: G, Manjunath Kondaiah manj...@ti.com writes: Patch series to convert DMA library into platform driver using platform device model and adapting hwmod for omap2+. After the OMAP1 fixup for PATCH 7/9, Acked-by: Kevin Hilman khil...@deeprootsystems.com I guess here you mean Signed-off-by for this patch since you wrote some code? Assuming Signed-off-by, let me know if you want to change that. I only added my s-o-b to PATCH 7/9 since that's the only one I added code to. Sorry I misunderstood. Adding your Signed-off-by for 7/9, and Acked-by and Tested-by for others. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 4/9] OMAP2430: hwmod data: add system DMA
On Sat, 4 Dec 2010, G, Manjunath Kondaiah wrote:
Add OMAP2430 DMA hwmod data and also add required
DMA device attributes.
...
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
+ .master = omap2430_dma_system_hwmod,
+ .slave = omap2430_l3_main_hwmod,
+ .clk= l3_div_ck,
This clock does not exist on OMAP2430. Did you test this on OMAP2430?
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dma_system = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_dma_system_hwmod,
+ .clk= l4_div_ck,
This clock also does not exist on OMAP2430.
+static struct omap_hwmod omap2430_dma_system_hwmod = {
+ .name = dma,
+ .class = omap2430_dma_hwmod_class,
+ .mpu_irqs = omap2430_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_dma_system_irqs),
+ .main_clk = l3_div_ck,
Nor does this one.
Please fix these and test on OMAP2430 before resending.
- 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 v1 7/9] OMAP1: DMA: Implement in platform device model
* G, Manjunath Kondaiah manj...@ti.com [101214 18:01]: On Tue, Dec 14, 2010 at 05:04:00PM -0800, Tony Lindgren wrote: OK thanks, will fold it in and let's merge them into linux-omap master branch for few days for testing. Then if everything looks good, I'll queue these for the 2.6.38 next merge window. Oops, not quite ready yet, see the mail from Paul. Waiting for those fixes. 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/RFC 1/2] OMAP2+: powerdomain: add API to get context loss count
Hi Kevin,
working my way through these...
On Thu, 9 Dec 2010, Kevin Hilman wrote:
Add new powerdomain API
int pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
for checking how many times the powerdomain has lost context. The
loss count is the sum sum of the powerdomain off-mode counter, the
logic off counter and the per-bank memory off counter.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomain.c | 23 +++
arch/arm/mach-omap2/powerdomain.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 06ef60e..78e7d22 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -909,3 +909,26 @@ int pwrdm_post_transition(void)
pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
return 0;
}
+
+/**
+ * pwrdm_get_context_loss_count - get powerdomain's context loss count
+ * @pwrdm: struct powerdomain * to wait for
+ *
+ * Context loss count is a sum of powerdomain off-mode counter,
+ * the logic off counter and the per-bank memory off counter.
+ */
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
+{
+ int i, count;
There should be a test here to prevent a null pointer deref if pwrdm is
NULL.
+
+ count = pwrdm-state_counter[PWRDM_POWER_OFF];
+ count += pwrdm-ret_logic_off_counter;
+
+ for (i = 0; i pwrdm-banks; i++)
+ count += pwrdm-ret_mem_off_counter[i];
Looks like these state counters are unsigned ints. So they could easily
overflow count when they are summed. This is probably not a major problem
as far as this function is concerned, but the next patch can return
-ENODEV upon error, which, if this function were really unlucky, it could
effectively return -ENODEV.
It would be good to constrain the minimum successful return value of this
function to 0. This will require some creativity since the function
shouldn't just return 0 for all sums that wrap around and wind up
negative; the return value should still continue to differ from the value
when it was called previously. Otherwise devices might not restore their
context when they should.
+
+ pr_debug(powerdomain: %s: context loss count = %u\n,
+ pwrdm-name, count);
+
+ return count;
+}
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 35b5b48..d269eff 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -211,6 +211,7 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
int pwrdm_pre_transition(void);
int pwrdm_post_transition(void);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
extern void omap2xxx_powerdomains_init(void);
extern void omap3xxx_powerdomains_init(void);
Also, as we discussed privately, there is at least one bug in the counters
where the logic-off and membank-off counters don't increment correctly
when the entire powerdomain is off. But that problem does not have to be
dealt with as part of this series...
- 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 3/3] omap2+: Initialize omap_irq_base for entry-macro.Sfrom platform code
* Rajendra Nayak rna...@ti.com [101213 03:57]:
+static inline void omap_irq_base_init(void)
+{
+ extern void __iomem *omap_irq_base;
+
+#ifdef MULTI_OMAP2
+ if (cpu_is_omap242x())
Looks like this should be a cpu_is_omap24xx(). The
current master is broken on a 2430sdp and a git-bisect
pointed me to this patch.
Thanks, just noticed that too. Here's a fix for that.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Tue, 14 Dec 2010 19:17:31 -0800
Subject: [PATCH] omap: Fix setting omap_irq_base for 2430
We need to test for 24xx not 242x. Otherwise interrupts won't work.
Reported-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -320,7 +320,7 @@ static inline void omap_irq_base_init(void)
extern void __iomem *omap_irq_base;
#ifdef MULTI_OMAP2
- if (cpu_is_omap242x())
+ if (cpu_is_omap24xx())
omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP24XX_IC_BASE);
else if (cpu_is_omap34xx())
omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP34XX_IC_BASE);
--
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
