Re: [PATCH] arm: fix compilation warning during compilation
2010/11/8 Gadiyar, Anand gadi...@ti.com: 2010/11/8 Marco Stornelli marco.storne...@gmail.com: 2010/11/8 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Hello, On Sat, Nov 06, 2010 at 10:06:35AM +0100, Marco Stornelli wrote: From: Marco Stornelli marco.storne...@gmail.com During compilation of 2.6.36 for Beagle board, there a are a couple of warnings. This patch fix them. Please break lines for commit logs at around 76 chars and mention the exact compiler warning being fixed. My compiler version is gcc 4.4.1. Two warning: variable gpio_mux may be used not initialized (false positive, I agree); second: compiler fix the void lack in the inline function with an int. Obviously there is a lack of return type that it must be void. Marco, Both of these are fixed in 2.6.37-rc1. Commits afc28bc0ec and ca828760f9 respectively. - Anand Very good. Thanks. Marco -- To unsubscribe from this list: send the line unsubscribe 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] hwmon: twl4030: Driver for twl4030 madc module
Introducing a driver for MADC on TWL4030 powerIC. MADC stands for monitoring
ADC. This driver monitors the real time conversion of analog signals like
battery temperature, battery type, battery level etc. User can also ask for
the conversion on a particular channel using the sysfs nodes.
Signed-off-by: Keerthy j-keer...@ti.com
---
Several people have contributed to this driver on the linux-omap list.
V2:
Error path correction in probe function.
Return checks added.
the_madc pointer could not be removed. The external drivers will not be knowing
device information of the madc.
Added another function which takes the channel number alone and returns
the channel reading if the caller wants TWL4030_MADC_SW2 method for ADC
conversion.
IOCTL function is removed.
Work struct is completely removed since request_threaded_irq is used.
drivers/hwmon/Kconfig|6 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/twl4030-madc.c | 573 ++
include/linux/i2c/twl4030-madc.h | 118
4 files changed, 698 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwmon/twl4030-madc.c
create mode 100644 include/linux/i2c/twl4030-madc.h
V1:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34947.html
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index a56f6ad..fef75f2 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1171,6 +1171,12 @@ config SENSORS_MC13783_ADC
help
Support for the A/D converter on MC13783 PMIC.
+config SENSORS_TWL4030_MADC
+ tristate
+ depends on TWL4030_CORE
+ help
+ This driver provides support for TWL4030-MADC.
+
if ACPI
comment ACPI drivers
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 2479b3d..a54af22 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_SENSORS_THMC50)+= thmc50.o
obj-$(CONFIG_SENSORS_TMP102) += tmp102.o
obj-$(CONFIG_SENSORS_TMP401) += tmp401.o
obj-$(CONFIG_SENSORS_TMP421) += tmp421.o
+obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc.o
obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
obj-$(CONFIG_SENSORS_VIA686A) += via686a.o
obj-$(CONFIG_SENSORS_VT1211) += vt1211.o
diff --git a/drivers/hwmon/twl4030-madc.c b/drivers/hwmon/twl4030-madc.c
new file mode 100644
index 000..42f7d4a
--- /dev/null
+++ b/drivers/hwmon/twl4030-madc.c
@@ -0,0 +1,573 @@
+/*
+ *
+ * TWL4030 MADC module driver-This driver monitors the real time
+ * conversion of analog signals like battery temperature,
+ * battery type, battery level etc. User can also ask for the conversion on a
+ * particular channel using the sysfs nodes.
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ * J Keerthy j-keer...@ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen mikko.k.yli...@nokia.com
+ *
+ * Amit Kucheria amit.kuche...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/types.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/i2c/twl.h
+#include linux/i2c/twl4030-madc.h
+#include linux/sysfs.h
+#include linux/hwmon.h
+#include linux/hwmon-sysfs.h
+#include linux/uaccess.h
+
+struct twl4030_madc_data {
+ struct device *hwmon_dev;
+ struct mutex lock;
+ struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+ int imr;
+ int isr;
+};
+
+static struct twl4030_madc_data *the_madc;
+
+static ssize_t madc_read(struct device *dev,
+struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct twl4030_madc_request req;
+ int status;
+ long val;
+
+ req.channels = (1 attr-index);
+ req.method = TWL4030_MADC_SW2;
+ req.func_cb = NULL;
+
+ val = twl4030_madc_conversion(req);
+ if (likely(val = 0))
+ val = req.rbuf[attr-index];
+ else
+ return val;
+ status = sprintf(buf, %ld\n, val);
+ return status;
+}
+
+static
+const struct twl4030_madc_conversion_method twl4030_conversion_methods[] = {
+
Re: DSS2 Query: Use of FIFO preload values
On Tue, 2010-11-09 at 05:20 +0100, ext Taneja, Archit wrote: Hi, I was going through the DSS2 code and was unable to find a place where we set the 11th bit in DISPC_GFX_ATTRIBUTES or the 19th bit in DISPC_VIDn_ATTRIBUTES. Setting these bits ensures that the DISPC FIFO's fill up to the high threshold value specified by us instead of the preload values. Is this done on purpose or it got missed out? A bit both. The TRM is quite unclear about fifo threshold and preload configuration, and I've never understood how to configure them for different interfaces. The current setup is mostly configured in such a way that things seem to work =). And if I recall right, even if the bits say that preload values are used, changing the threshold values still broke things. So, as I said, I never quite understood how they work. 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 1/3] OMAP: use generic panel data in board files
On Mon, 2010-11-08 at 20:43 +0100, ext Bryan Wu wrote:
On Mon, Nov 8, 2010 at 7:26 AM, Tomi Valkeinen tomi.valkei...@nokia.com
wrote:
Hi,
On Fri, 2010-11-05 at 20:43 +0100, ext Bryan Wu wrote:
static struct omap_dss_device sdp3430_dvi_device = {
.name = dvi,
- .driver_name= generic_panel,
- .type = OMAP_DISPLAY_TYPE_DPI,
- .phy.dpi.data_lines = 24,
Why do you remove type and datalines configuration? You do this for the
other panels also.
I found this is common in all the generic dpi panel, but the value
depends on the specific panel. I move this to the panel configuration
data and will set this value in panel-dpi driver. Do you think need I
keep them here? Actually I found all of them are 24 for generic one.
16 or 18 for others.
Both type and .phy.dpi.data_lines tell about the connection to the
panel, not about the panel itself. Thus I think it's more consistent to
have them defined in the board file.
Also, it's really up to the board HW design how many lines are connected
from OMAP to the panel. You could connect only 16, for example, so it's
something that has to be defined in the board file.
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 1/3] OMAP: DSS2: Add generic DPI panel display driver
Hi,
On Mon, 2010-11-08 at 22:44 +0100, ext Bryan Wu wrote:
Generic DPI panel driver includes the driver and 4 similar panel
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 31 ++
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 314
4 files changed, 354 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
diff --git a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..da50756
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,31 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_GENERIC_DPI_PANEL_H
+#define __ARCH_ARM_PLAT_OMAP_GENERIC_DPI_PANEL_H
Should be __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+/**
+ * struct panel_data - panel driver configuration
+ * @name: panel name
+ */
+struct generic_dpi_panel_data {
I think the struct name should be panel_generic_dpi_data.
+ const char *name;
+};
Please add here also the fields platform_enable/disable and use them
instead of the ones in dssdev.
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 V2] hwmon: twl4030: Driver for twl4030 madc module
Introducing a driver for MADC on TWL4030 powerIC. MADC stands for monitoring ADC. This driver monitors the real time conversion of analog signals like battery temperature, battery type, battery level etc. User can also ask for the conversion on a particular channel using the sysfs nodes. Signed-off-by: Keerthy j-keer...@ti.com ... diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index a56f6ad..fef75f2 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1171,6 +1171,12 @@ config SENSORS_MC13783_ADC help Support for the A/D converter on MC13783 PMIC. +config SENSORS_TWL4030_MADC + tristate You need to provide some label text here, otherwise this option will not show up in the kernel configuration tools, and hence cannot be turned on or off from there. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2] hwmon: twl4030: Driver for twl4030 madc module
Hello Anand, -Original Message- From: Gadiyar, Anand Sent: Tuesday, November 09, 2010 7:10 PM To: J, KEERTHY; lm-sens...@lm-sensors.org; guenter.ro...@ericsson.com; sa...@linux.intel.com; kh...@linux-fr.org Cc: mikko.k.yli...@nokia.com; Balbi, Felipe; amit.kuche...@canonical.com; linux-omap@vger.kernel.org; Krishnamoorthy, Balaji T Subject: RE: [PATCH V2] hwmon: twl4030: Driver for twl4030 madc module Introducing a driver for MADC on TWL4030 powerIC. MADC stands for monitoring ADC. This driver monitors the real time conversion of analog signals like battery temperature, battery type, battery level etc. User can also ask for the conversion on a particular channel using the sysfs nodes. Signed-off-by: Keerthy j-keer...@ti.com ... diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index a56f6ad..fef75f2 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1171,6 +1171,12 @@ config SENSORS_MC13783_ADC help Support for the A/D converter on MC13783 PMIC. +config SENSORS_TWL4030_MADC + tristate You need to provide some label text here, otherwise this option will not show up in the kernel configuration tools, and hence cannot be turned on or off from there. Ok. I get it. I will add a label. - Anand Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v5] OMAP: AM3517/05: Add craneboard support
From: Srinath srin...@mistralsolutions.com
Craneboard is a hardware development platform based on the
Sitara AM3517 ARM Cortex - A8 microprocessor device. This is a
low cost reference design.
This patch adds basic board file. Detailed support will follow in
subsequent patches.
[1] http://www.ti.com/arm
[2] http://www.mistralsolutions.com/products/craneboard.php
Signed-off-by: Srinath srin...@mistralsolutions.com
---
arch/arm/mach-omap2/Kconfig |5 ++
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-am3517crane.c | 69 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
4 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-am3517crane.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..3688515 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -174,6 +174,11 @@ config MACH_OMAP3517EVM
default y
select OMAP_PACKAGE_CBB
+config MACH_CRANEBOARD
+ bool AM3517/05 CRANE board
+ depends on ARCH_OMAP3
+ select OMAP_PACKAGE_CBB
+
config MACH_OMAP3_PANDORA
bool OMAP3 Pandora
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b0810b9..d43bd33 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -174,6 +174,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) +=
board-omap4panda.o \
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
+obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
+
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
hsmmc.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
new file mode 100644
index 000..13ead33
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -0,0 +1,69 @@
+/*
+ * Support for AM3517/05 Craneboard
+ * http://www.mistralsolutions.com/products/craneboard.php
+ *
+ * Copyright (C) 2010 Mistral Solutions Pvt Ltd. www.mistralsolutions.com
+ * Author: R.Srinath srin...@mistralsolutions.com
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/gpio.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+
+#include mux.h
+
+/* Board initialization */
+static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
+};
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
+static void __init am3517_crane_init_irq(void)
+{
+ omap_board_config = am3517_crane_config;
+ omap_board_config_size = ARRAY_SIZE(am3517_crane_config);
+
+ omap2_init_common_hw(NULL, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static void __init am3517_crane_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_serial_init();
+}
+
+MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD)
+ .boot_params= 0x8100,
+ .map_io = omap3_map_io,
+ .reserve= omap_reserve,
+ .init_irq = am3517_crane_init_irq,
+ .init_machine = am3517_crane_init,
+ .timer = omap_timer,
+MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
b/arch/arm/plat-omap/include/plat/uncompress.h
index 9036e37..229fbf2 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -145,6 +145,7 @@ static inline void __arch_decomp_setup(unsigned long
arch_id)
/* omap3 based boards using UART3 */
DEBUG_LL_OMAP3(3, cm_t35);
DEBUG_LL_OMAP3(3, cm_t3517);
+ DEBUG_LL_OMAP3(3, craneboard);
DEBUG_LL_OMAP3(3, igep0020);
DEBUG_LL_OMAP3(3, igep0030);
DEBUG_LL_OMAP3(3, nokia_rx51);
--
1.7.1.226.g770c5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tuesday 09 November 2010, Felipe Contreras wrote: Felipe Contreras (14): Revert staging: tidspbridge - update Kconfig to select IOMMU module Revert staging: tidspbridge - remove dmm custom module Revert staging: tidspbridge - deprecate reserve/unreserve_memory funtions Revert staging: tidspbridge - remove reserved memory clean up Revert staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct Revert staging: tidspbridge - move all iommu related code to a new file Revert staging: tidspbridge - remove hw directory Revert staging: tidspbridge - fix mmufault support Revert staging: tidspbridge - remove custom mmu code from tiomap3430.c Revert staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name Revert staging: tidspbridge - move shared memory iommu maps to tiomap3430.c Revert staging: tidspbridge: replace iommu custom for opensource implementation That adds quite a lot of crap back in that was removed by Fernando earlier: 44 files changed, 3733 insertions(+), 847 deletions(-) It may have been premature to merge the patches as you say, but now that they are in, I'd vote for giving Fernando a chance to fix up any damage that was done in the process rather than just reverting all the useful changes. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 9, 2010 at 10:29 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 09 November 2010, Felipe Contreras wrote: Felipe Contreras (14): Revert staging: tidspbridge - update Kconfig to select IOMMU module Revert staging: tidspbridge - remove dmm custom module Revert staging: tidspbridge - deprecate reserve/unreserve_memory funtions Revert staging: tidspbridge - remove reserved memory clean up Revert staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct Revert staging: tidspbridge - move all iommu related code to a new file Revert staging: tidspbridge - remove hw directory Revert staging: tidspbridge - fix mmufault support Revert staging: tidspbridge - remove custom mmu code from tiomap3430.c Revert staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name Revert staging: tidspbridge - move shared memory iommu maps to tiomap3430.c Revert staging: tidspbridge: replace iommu custom for opensource implementation That adds quite a lot of crap back in that was removed by Fernando earlier: 44 files changed, 3733 insertions(+), 847 deletions(-) It may have been premature to merge the patches as you say, but now that they are in, I'd vote for giving Fernando a chance to fix up any damage that was done in the process rather than just reverting all the useful changes. Arnd tidspbridge iommu change are working fine all the patches and few fixes after that are alredy sent. what breaks tidspbridge, is the unmerged dependencies in linux omap tree, specifically the iommu module patches and the SG patch. if the dependencies are merged tidspbridge work perfectly I don't need to fix anything. As the dependencies are not merge yet it is ok to revert and once push once all the dependencies are merge. I am not familiar with that so I don't know how much time can it take. Regards, Fernando. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote: On Tuesday 09 November 2010, Felipe Contreras wrote: Felipe Contreras (14): Revert staging: tidspbridge - update Kconfig to select IOMMU module Revert staging: tidspbridge - remove dmm custom module Revert staging: tidspbridge - deprecate reserve/unreserve_memory funtions Revert staging: tidspbridge - remove reserved memory clean up Revert staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct Revert staging: tidspbridge - move all iommu related code to a new file Revert staging: tidspbridge - remove hw directory Revert staging: tidspbridge - fix mmufault support Revert staging: tidspbridge - remove custom mmu code from tiomap3430.c Revert staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name Revert staging: tidspbridge - move shared memory iommu maps to tiomap3430.c Revert staging: tidspbridge: replace iommu custom for opensource implementation That adds quite a lot of crap back in that was removed by Fernando earlier: 44 files changed, 3733 insertions(+), 847 deletions(-) It may have been premature to merge the patches as you say, but now that they are in, I'd vote for giving Fernando a chance to fix up any damage that was done in the process rather than just reverting all the useful changes. In looking at this further, I agree. Felipe, are all of these really needing to be reverted? How about picking out the functional changes that need to be resolved instead of just rolling back everything that has been done here. Surely not all of these are wrong, right? 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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 9, 2010 at 10:55 AM, Greg KH g...@kroah.com wrote: On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote: On Tuesday 09 November 2010, Felipe Contreras wrote: Felipe Contreras (14): Revert staging: tidspbridge - update Kconfig to select IOMMU module Revert staging: tidspbridge - remove dmm custom module Revert staging: tidspbridge - deprecate reserve/unreserve_memory funtions Revert staging: tidspbridge - remove reserved memory clean up Revert staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct Revert staging: tidspbridge - move all iommu related code to a new file Revert staging: tidspbridge - remove hw directory Revert staging: tidspbridge - fix mmufault support Revert staging: tidspbridge - remove custom mmu code from tiomap3430.c Revert staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name Revert staging: tidspbridge - move shared memory iommu maps to tiomap3430.c Revert staging: tidspbridge: replace iommu custom for opensource implementation That adds quite a lot of crap back in that was removed by Fernando earlier: 44 files changed, 3733 insertions(+), 847 deletions(-) It may have been premature to merge the patches as you say, but now that they are in, I'd vote for giving Fernando a chance to fix up any damage that was done in the process rather than just reverting all the useful changes. In looking at this further, I agree. Felipe, are all of these really needing to be reverted? How about picking out the functional changes that need to be resolved instead of just rolling back everything that has been done here. Surely not all of these are wrong, right? Patches are _NOT_ wrong, missing dependencies break the bridge. Without that dependencies the first patch of the set won't work and all other patches have dependency on the first one, so all of them need to be reverted. Regards, Fernando. 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
[PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #5)
There are 4 duplicated DPI panel drivers in DSS2 display driver. They are similar and a generic DPI panel driver can support all them with specific panel configuration. And new DPI panel driver can be easily supported by adding panel configurations into generic panel DPI driver. This patchset introduces a generic panel DPI driver, remove 3 panel drivers and enable generic panel DPI driver in board files. And it is based on 2.6.37-rc1. Building with omap2plus_defconfig is successful. Keep sharp_ls_panel, since it contains blacklight control code which will be moved out later. Bryan Wu (3): OMAP: DSS2: Add generic DPI panel display driver OMAP: use generic DPI panel driver in board files OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers arch/arm/mach-omap2/board-3430sdp.c| 13 +- arch/arm/mach-omap2/board-am3517evm.c | 25 +- arch/arm/mach-omap2/board-cm-t35.c | 25 +- arch/arm/mach-omap2/board-devkit8000.c | 28 ++- arch/arm/mach-omap2/board-igep0020.c | 13 +- arch/arm/mach-omap2/board-omap3beagle.c| 13 +- arch/arm/mach-omap2/board-omap3evm.c | 13 +- arch/arm/mach-omap2/board-omap3stalker.c | 25 +- .../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 +++ drivers/video/omap2/displays/Kconfig | 22 +- drivers/video/omap2/displays/Makefile |4 +- drivers/video/omap2/displays/panel-generic-dpi.c | 309 drivers/video/omap2/displays/panel-generic.c | 174 --- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 --- .../video/omap2/displays/panel-toppoly-tdo35s.c| 164 --- 15 files changed, 458 insertions(+), 572 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c delete mode 100644 drivers/video/omap2/displays/panel-generic.c delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
Generic DPI panel driver includes the driver and 4 similar panel
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 +++
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 309
4 files changed, 355 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
diff --git a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..7906197
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,37 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+#define __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+#include display.h
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+#endif /* __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H */
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..cb3e339 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,6 +1,14 @@
menu OMAP2/3 Display Device Drivers
depends on OMAP2_DSS
+config PANEL_GENERIC_DPI
+tristate Generic DPI Panel
+help
+ Generic DPI panel driver.
+ Supports DVI output for Beagle and OMAP3 SDP.
+ Supports LCD Panel used in TI SDP3430 and EVM boards,
+ OMAP3517 EVM boards and CM-T35.
+
config PANEL_GENERIC
tristate Generic Panel
help
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..022058c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
new file mode 100644
index 000..7ddd631
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -0,0 +1,309 @@
+/*
+ * Generic DPI Panels support
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include plat/panel-generic-dpi.h
+
+struct panel_config {
+ struct omap_video_timings timings;
+
+ int acbi; /* ac-bias pin transitions per interrupt */
+ /* Unit: line clocks */
+ int acb;/* ac-bias pin frequency */
+
+ enum omap_panel_config
[PATCH 2/3] OMAP: use generic DPI panel driver in board files
Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight
control driver code which will be moved out later. Then we can use generic DPI
driver for sharp_ls_panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-omap2/board-3430sdp.c | 13 +
arch/arm/mach-omap2/board-am3517evm.c| 25 +
arch/arm/mach-omap2/board-cm-t35.c | 25 +
arch/arm/mach-omap2/board-devkit8000.c | 28 ++--
arch/arm/mach-omap2/board-igep0020.c | 13 +
arch/arm/mach-omap2/board-omap3beagle.c | 13 +
arch/arm/mach-omap2/board-omap3evm.c | 13 +
arch/arm/mach-omap2/board-omap3stalker.c | 25 +
8 files changed, 105 insertions(+), 50 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..4bafdd7 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -38,6 +38,7 @@
#include plat/dma.h
#include plat/gpmc.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include plat/gpmc-smc91x.h
@@ -270,13 +271,17 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable = sdp3430_panel_disable_lcd,
};
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= sdp3430_panel_enable_dvi,
+ .platform_disable = sdp3430_panel_disable_dvi,
+};
+
static struct omap_dss_device sdp3430_dvi_device = {
.name = dvi,
- .driver_name= generic_panel,
- .type = OMAP_DISPLAY_TYPE_DPI,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
.phy.dpi.data_lines = 24,
- .platform_enable= sdp3430_panel_enable_dvi,
- .platform_disable = sdp3430_panel_disable_dvi,
};
static struct omap_dss_device sdp3430_tv_device = {
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..3534a23 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
#include plat/common.h
#include plat/usb.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include mux.h
#include control.h
@@ -303,13 +304,17 @@ static void am3517_evm_panel_disable_lcd(struct
omap_dss_device *dssdev)
lcd_enabled = 0;
}
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = sharp_lq,
+ .platform_enable= am3517_evm_panel_enable_lcd,
+ .platform_disable = am3517_evm_panel_disable_lcd,
+};
+
static struct omap_dss_device am3517_evm_lcd_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
.name = lcd,
- .driver_name= sharp_lq_panel,
+ .driver_name= generic_dpi_panel,
+ .data = lcd_panel,
.phy.dpi.data_lines = 16,
- .platform_enable= am3517_evm_panel_enable_lcd,
- .platform_disable = am3517_evm_panel_disable_lcd,
};
static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -346,13 +351,17 @@ static void am3517_evm_panel_disable_dvi(struct
omap_dss_device *dssdev)
dvi_enabled = 0;
}
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= am3517_evm_panel_enable_dvi,
+ .platform_disable = am3517_evm_panel_disable_dvi,
+};
+
static struct omap_dss_device am3517_evm_dvi_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
- .driver_name= generic_panel,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
.phy.dpi.data_lines = 24,
- .platform_enable= am3517_evm_panel_enable_dvi,
- .platform_disable = am3517_evm_panel_disable_dvi,
};
static struct omap_dss_device *am3517_evm_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..1a69d32 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -46,6 +46,7 @@
#include plat/gpmc.h
#include plat/usb.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include plat/mcspi.h
#include mach/hardware.h
@@ -351,22 +352,30 @@ static void cm_t35_panel_disable_tv(struct
omap_dss_device *dssdev)
{
}
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = toppoly_tdo35s,
+ .platform_enable= cm_t35_panel_enable_lcd,
+ .platform_disable = cm_t35_panel_disable_lcd,
+};
+
static struct omap_dss_device cm_t35_lcd_device = {
.name
[PATCH 3/3] OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
Still keep sharp_ls_panel driver, because it contains blacklight control driver.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/omap2/displays/Kconfig | 18 --
drivers/video/omap2/displays/Makefile |3 -
drivers/video/omap2/displays/panel-generic.c | 174
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 ---
.../video/omap2/displays/panel-toppoly-tdo35s.c| 164 --
5 files changed, 0 insertions(+), 524 deletions(-)
delete mode 100644 drivers/video/omap2/displays/panel-generic.c
delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index cb3e339..9c09afd 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -9,12 +9,6 @@ config PANEL_GENERIC_DPI
Supports LCD Panel used in TI SDP3430 and EVM boards,
OMAP3517 EVM boards and CM-T35.
-config PANEL_GENERIC
-tristate Generic Panel
-help
- Generic panel driver.
- Used for DVI output for Beagle and OMAP3 SDP.
-
config PANEL_SHARP_LS037V7DW01
tristate Sharp LS037V7DW01 LCD Panel
depends on OMAP2_DSS
@@ -22,24 +16,12 @@ config PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
-config PANEL_SHARP_LQ043T1DG01
-tristate Sharp LQ043T1DG01 LCD Panel
-depends on OMAP2_DSS
-help
- LCD Panel used in TI's OMAP3517 EVM boards
-
config PANEL_TAAL
tristate Taal DSI Panel
depends on OMAP2_DSS_DSI
help
Taal DSI command mode panel from TPO.
-config PANEL_TOPPOLY_TDO35S
-tristate Toppoly TDO35S LCD Panel support
-depends on OMAP2_DSS
-help
- LCD Panel used in CM-T35
-
config PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on OMAP2_DSS SPI
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 022058c..3bebe4d 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,9 +1,6 @@
obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
-obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
-obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
-obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
deleted file mode 100644
index 395a68d..000
--- a/drivers/video/omap2/displays/panel-generic.c
+++ /dev/null
@@ -1,174 +0,0 @@
-/*
- * Generic panel support
- *
- * Copyright (C) 2008 Nokia Corporation
- * Author: Tomi Valkeinen tomi.valkei...@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, see http://www.gnu.org/licenses/.
- */
-
-#include linux/module.h
-#include linux/delay.h
-
-#include plat/display.h
-
-static struct omap_video_timings generic_panel_timings = {
- /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
- .x_res = 640,
- .y_res = 480,
- .pixel_clock= 23500,
- .hfp= 48,
- .hsw= 32,
- .hbp= 80,
- .vfp= 3,
- .vsw= 4,
- .vbp= 7,
-};
-
-static int generic_panel_power_on(struct omap_dss_device *dssdev)
-{
- int r;
-
- if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
- return 0;
-
- r = omapdss_dpi_display_enable(dssdev);
- if (r)
- goto err0;
-
- if (dssdev-platform_enable) {
- r = dssdev-platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
- return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
-err0:
- return r;
-}
-
-static void generic_panel_power_off(struct omap_dss_device *dssdev)
-{
- if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
- return;
-
- if (dssdev-platform_disable)
- dssdev-platform_disable(dssdev);
-
-
Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 09, 2010 at 11:04:18AM -0600, Guzman Lugo, Fernando wrote: On Tue, Nov 9, 2010 at 10:55 AM, Greg KH g...@kroah.com wrote: On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote: On Tuesday 09 November 2010, Felipe Contreras wrote: Felipe Contreras (14): Revert staging: tidspbridge - update Kconfig to select IOMMU module Revert staging: tidspbridge - remove dmm custom module Revert staging: tidspbridge - deprecate reserve/unreserve_memory funtions Revert staging: tidspbridge - remove reserved memory clean up Revert staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct Revert staging: tidspbridge - move all iommu related code to a new file Revert staging: tidspbridge - remove hw directory Revert staging: tidspbridge - fix mmufault support Revert staging: tidspbridge - remove custom mmu code from tiomap3430.c Revert staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name Revert staging: tidspbridge - move shared memory iommu maps to tiomap3430.c Revert staging: tidspbridge: replace iommu custom for opensource implementation That adds quite a lot of crap back in that was removed by Fernando earlier: 44 files changed, 3733 insertions(+), 847 deletions(-) It may have been premature to merge the patches as you say, but now that they are in, I'd vote for giving Fernando a chance to fix up any damage that was done in the process rather than just reverting all the useful changes. In looking at this further, I agree. Felipe, are all of these really needing to be reverted? How about picking out the functional changes that need to be resolved instead of just rolling back everything that has been done here. Surely not all of these are wrong, right? Patches are _NOT_ wrong, missing dependencies break the bridge. Without that dependencies the first patch of the set won't work and all other patches have dependency on the first one, so all of them need to be reverted. How about hand-reverting only the wrong patch, so the other work isn't lost? I'd much prefer that. 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: [PATCH] OMAP3: I2C: hwmod: Fix PRCM module offset
G, Manjunath Kondaiah manj...@ti.com writes:
The commit '311225e6' is missing '.module_offs' in prcm
structure in omap3 hwmod data base which results in accessing
wrong register for I2Cx IDLEST bit monitoring.
Added module offsets for accessing register CM_IDLEST1_CORE.
Patch tested on Zoom3 using omap2plus_defconfig
Thanks, will fold this into original series.
Kevin
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index d0d8030..22831e9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -642,6 +642,7 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {
.main_clk = i2c1_fck,
.prcm = {
.omap2 = {
+ .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_I2C1_SHIFT,
.idlest_reg_id = 1,
@@ -683,6 +684,7 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {
.main_clk = i2c2_fck,
.prcm = {
.omap2 = {
+ .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_I2C2_SHIFT,
.idlest_reg_id = 1,
@@ -724,6 +726,7 @@ static struct omap_hwmod omap3xxx_i2c3_hwmod = {
.main_clk = i2c3_fck,
.prcm = {
.omap2 = {
+ .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_I2C3_SHIFT,
.idlest_reg_id = 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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
* Guzman Lugo, Fernando fernando.l...@ti.com [101109 08:36]: tidspbridge iommu change are working fine all the patches and few fixes after that are alredy sent. what breaks tidspbridge, is the unmerged dependencies in linux omap tree, specifically the iommu module patches and the SG patch. Care to post a series of the missing patches listed above? That way we can at least start merging those into linux-omap for testing while waiting for the next merge window. 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 v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
Ben Dooks ben-...@fluff.org writes: On Thu, Oct 07, 2010 at 10:37:03AM -0700, Kevin Hilman wrote: Ben Dooks ben-...@fluff.org writes: [...] As such, I should really go and read up all about this new runtime-pm and hwmod stuff before further commentign on the changes. ping From the drivers perspective, you don't neet to know anything about omap_hwmod. You can think of this change as simply using the runtime PM API instead of the clock API for enabling and idling the device. With your ack (on this patch only) we'd like to merge this along with the rest of the series for 2.6.37. Acked-by: Ben Dooks ben-li...@fluff.org please post via your tree. Thanks Ben, Will queue up for 2.6.38. 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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 9, 2010 at 11:25 AM, Greg KH g...@kroah.com wrote: On Tue, Nov 09, 2010 at 11:04:18AM -0600, Guzman Lugo, Fernando wrote: On Tue, Nov 9, 2010 at 10:55 AM, Greg KH g...@kroah.com wrote: On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote: On Tuesday 09 November 2010, Felipe Contreras wrote: Felipe Contreras (14): Revert staging: tidspbridge - update Kconfig to select IOMMU module Revert staging: tidspbridge - remove dmm custom module Revert staging: tidspbridge - deprecate reserve/unreserve_memory funtions Revert staging: tidspbridge - remove reserved memory clean up Revert staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct Revert staging: tidspbridge - move all iommu related code to a new file Revert staging: tidspbridge - remove hw directory Revert staging: tidspbridge - fix mmufault support Revert staging: tidspbridge - remove custom mmu code from tiomap3430.c Revert staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name Revert staging: tidspbridge - move shared memory iommu maps to tiomap3430.c Revert staging: tidspbridge: replace iommu custom for opensource implementation That adds quite a lot of crap back in that was removed by Fernando earlier: 44 files changed, 3733 insertions(+), 847 deletions(-) It may have been premature to merge the patches as you say, but now that they are in, I'd vote for giving Fernando a chance to fix up any damage that was done in the process rather than just reverting all the useful changes. In looking at this further, I agree. Felipe, are all of these really needing to be reverted? How about picking out the functional changes that need to be resolved instead of just rolling back everything that has been done here. Surely not all of these are wrong, right? Patches are _NOT_ wrong, missing dependencies break the bridge. Without that dependencies the first patch of the set won't work and all other patches have dependency on the first one, so all of them need to be reverted. How about hand-reverting only the wrong patch, so the other work isn't lost? I'd much prefer that. Unfortunately any of the iommu migration patches will work correctly without the dependencies on iommu module patches. There are some patches which cleanup the code, but thanks to the iommu migrations the files can disappear complete other wise I need to check and only clean what is not needed and leave what the old custom implementation is using, which will need a lot of rework in the patches. According with Felipe Contreras it is very easy reverting and pushing after. I don't like the idea of reverting all iommu patches, however looks the easiest solution. Unless the dependencies patches can be merged the would be the best solution. Regards, Fernando. 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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 9, 2010 at 11:35 AM, Tony Lindgren t...@atomide.com wrote: * Guzman Lugo, Fernando fernando.l...@ti.com [101109 08:36]: tidspbridge iommu change are working fine all the patches and few fixes after that are alredy sent. what breaks tidspbridge, is the unmerged dependencies in linux omap tree, specifically the iommu module patches and the SG patch. Care to post a series of the missing patches listed above? Here are the missing patches: Fernando Guzman Lugo (4): iovmm: no gap checking for fixed address iovmm: add superpages support to fixed da address iovmm: replace __iounmap with omap_iounmap iommu: create new api to set valid da range and scatterlist: define SG chain for arm architecture Regards, Fernando. That way we can at least start merging those into linux-omap for testing while waiting for the next merge window. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 09, 2010 at 11:49:30AM -0600, Guzman Lugo, Fernando wrote: On Tue, Nov 9, 2010 at 11:25 AM, Greg KH g...@kroah.com wrote: On Tue, Nov 09, 2010 at 11:04:18AM -0600, Guzman Lugo, Fernando wrote: On Tue, Nov 9, 2010 at 10:55 AM, Greg KH g...@kroah.com wrote: On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote: On Tuesday 09 November 2010, Felipe Contreras wrote: Felipe Contreras (14): Revert staging: tidspbridge - update Kconfig to select IOMMU module Revert staging: tidspbridge - remove dmm custom module Revert staging: tidspbridge - deprecate reserve/unreserve_memory funtions Revert staging: tidspbridge - remove reserved memory clean up Revert staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct Revert staging: tidspbridge - move all iommu related code to a new file Revert staging: tidspbridge - remove hw directory Revert staging: tidspbridge - fix mmufault support Revert staging: tidspbridge - remove custom mmu code from tiomap3430.c Revert staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name Revert staging: tidspbridge - move shared memory iommu maps to tiomap3430.c Revert staging: tidspbridge: replace iommu custom for opensource implementation That adds quite a lot of crap back in that was removed by Fernando earlier: 44 files changed, 3733 insertions(+), 847 deletions(-) It may have been premature to merge the patches as you say, but now that they are in, I'd vote for giving Fernando a chance to fix up any damage that was done in the process rather than just reverting all the useful changes. In looking at this further, I agree. Felipe, are all of these really needing to be reverted? How about picking out the functional changes that need to be resolved instead of just rolling back everything that has been done here. Surely not all of these are wrong, right? Patches are _NOT_ wrong, missing dependencies break the bridge. Without that dependencies the first patch of the set won't work and all other patches have dependency on the first one, so all of them need to be reverted. How about hand-reverting only the wrong patch, so the other work isn't lost? I'd much prefer that. Unfortunately any of the iommu migration patches will work correctly without the dependencies on iommu module patches. There are some patches which cleanup the code, but thanks to the iommu migrations the files can disappear complete other wise I need to check and only clean what is not needed and leave what the old custom implementation is using, which will need a lot of rework in the patches. According with Felipe Contreras it is very easy reverting and pushing after. If it is easy to revert and push later, then the revert just this piece should be done now. Seriously, I'm getting very confused here, and am very annoyed by the whole thing. Here's what I don't like: - the original driver didn't even seem to work properly - people sent me patches they never tested and broke things even worse - some people have no respect for the omap maintainers and what they think about things, or even basic knowledge of the kernel development cycle. - I do not have this hardware so I can't test anything. So, from now on, I'm not taking ANYONES patches for this driver unless it gets an ack from the driver maintainer, Omar Luna. Actually, no, I'm not going to take any patch unless it _comes from_ Omar. Omar, please work to queue up patches and test them, and then send them to me for merging. Any questions? If anyone doesn't like this because they feel that the current driver is broken, well, I can easily solve that by just deleting the whole thing from the tree right now. Would that be a better idea? Ugh, what a mess... 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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
Hi, Seriously, I'm getting very confused here, and am very annoyed by the whole thing. Here's what I don't like: - the original driver didn't even seem to work properly - people sent me patches they never tested and broke things even worse - some people have no respect for the omap maintainers and what they think about things, or even basic knowledge of the kernel development cycle. - I do not have this hardware so I can't test anything. So, from now on, I'm not taking ANYONES patches for this driver unless it gets an ack from the driver maintainer, Omar Luna. Actually, no, I'm not going to take any patch unless it _comes from_ Omar. Omar, please work to queue up patches and test them, and then send them to me for merging. Any questions? If anyone doesn't like this because they feel that the current driver is broken, well, I can easily solve that by just deleting the whole thing from the tree right now. Would that be a better idea? I'm fine to queue the patches. For now, yes, the driver is/has-been broken, and everybody has been trying for the last two cycles to fix some dependencies (and unfortunately we do it at the last minute or even after it can't be done anymore, *sometimes*)... I have been kindly educated by both LO and staging tree maintainers that it is just a bad practice to hurry things up and not comply with the development standards. If 2.6.36 or .37 tidspbridge is needed I'll keep each branch with their dependent patches in d.o-z (TI's git server), if anybody (Felipe) wants to keep their own branches I'm fine with that I can sync with them privately to hear any concerns or something else. I'll create the branches and sent an announce to both lists. All dependencies need to be acked long before 2.6.38-rc1 and it is the responsibility of the senders to track their acceptance. Thanks for your suggestions and bearing with this situation, I'll follow them and solve your dislikes about it (the hardware part it might not be possible :/). BTW, the testing environment for tidspbridge will be gst-dsp, any stress testsuites will be run in addition, I'll detail more of it in the upcoming mail. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: hwmod: Update the sysc_cache in case module context is lost
Rajendra Nayak rna...@ti.com writes:
Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).
Identifying if a module has lost context requires atleast one
register read, and since a register read has more latency than
a write, it makes sense to do a blind write always.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..aadd6dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -209,10 +209,9 @@ static void _write_sysconfig(u32 v, struct omap_hwmod
*oh)
/* XXX ensure module interface clock is up */
- if (oh-_sysc_cache != v) {
- oh-_sysc_cache = v;
- omap_hwmod_write(v, oh, oh-class-sysc-sysc_offs);
- }
+ /* Module might have lost context, always update cache and register */
+ oh-_sysc_cache = v;
+ omap_hwmod_write(v, oh, oh-class-sysc-sysc_offs);
}
/**
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 9, 2010 at 7:52 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Tue, Nov 9, 2010 at 11:35 AM, Tony Lindgren t...@atomide.com wrote: * Guzman Lugo, Fernando fernando.l...@ti.com [101109 08:36]: tidspbridge iommu change are working fine all the patches and few fixes after that are alredy sent. what breaks tidspbridge, is the unmerged dependencies in linux omap tree, specifically the iommu module patches and the SG patch. Care to post a series of the missing patches listed above? Here are the missing patches: Fernando Guzman Lugo (4): iovmm: no gap checking for fixed address iovmm: add superpages support to fixed da address iovmm: replace __iounmap with omap_iounmap iommu: create new api to set valid da range and scatterlist: define SG chain for arm architecture Those are not the only patches needed, you would also need: omap: iommu: make iva2 iommu selectable staging: tidspbridge: enable iva2 iommu And the one that actually uses the new API for the da range which hasn't even been submitted to the mailing list. Personally, I haven't seen the new iommu code working correctly. -- 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 v3 01/13] OMAP: DMA: Replace read/write macros with functions
G, Manjunath Kondaiah manj...@ti.com writes:
The low level read/write macros are replaced with static inline functions
and register offsets are handled through static register offset tables
mapped through enumeration constants.
The objective of this patch is to prepare for omap dma driver cleanup
and dma hwmod implementation. The code optimization and moving machine
specific code to respective mach-omapx dma file will be handled in the
rest of this patch series.
[...]
-#define dma_write(val, reg) \
-({ \
- if (cpu_class_is_omap1()) \
- __raw_writew((u16)(val), omap_dma_base + OMAP1_DMA_##reg); \
- else\
- __raw_writel((val), omap_dma_base + OMAP_DMA4_##reg); \
-})
+static inline void dma_write(u32 val, int reg, int lch)
+{
+ if (cpu_class_is_omap1()) {
Reminder: any use of cpu_is_* checks outside of init code will be NAK'd.
cpu_is_* check do not belong at runtime, especially in a crucial path
like this.
+ if (reg OMAP1_CH_COMMON_START)
+ __raw_writew(val, dma_base +
+ (reg_map_omap1[reg] + 0x40 * lch));
+ else
+ __raw_writew(val, dma_base + reg_map_omap1[reg]);
+ } else {
+ if (reg OMAP2_CH_COMMON_START)
+ __raw_writel(val, dma_base +
+ (reg_map_omap2[reg] + 0x60 * lch));
+ else
+ __raw_writel(val, dma_base + reg_map_omap2[reg]);
+ }
+}
The register base offset, register array and the stride (offset between
instances: 0x40 or 0x60) are detectable at init time, and there's no
reason to have conditional code for them. IOW, they should be init time
constants. Doing so would greatly simply these functions. In fact the
CH_COMMON_START could also be an init time constant as well. So, given
the following init_time constants: dma_ch_common_start, dma_stride,
reg_map, the above would be reduced to something actually worth
inlining, for example (not actually tested):
static inline void dma_write(u32 val, int reg, int lch)
{
u8 stride = (reg dma_ch_common_start) ? dma_stride : 0;
__raw_writel(val, dma_base + (reg_map[reg] + stride * lch));
}
Same applies to dma_read().
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 v3 03/13] OMAP: DMA: Introduce DMA device attributes
G, Manjunath Kondaiah manj...@ti.com writes:
This patch introduces OMAP DMA device attributes for using the same in
DMA platform driver for all OMAP's and HWMOD database(OMAP2PLUS onwards)
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/include/plat/dma.h | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 5e28d26..9757b22 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -296,6 +296,22 @@
#define DMA_ERRATA_i88 (1 4)
#define DMA_ERRATA_3_3 (1 5)
+/* Attributes for OMAP DMA Contrllers */
+#define ENABLE_1510_MODE (1 0x0)
+#define DMA_LINKED_LCH (1 0x1)
+#define GLOBAL_PRIORITY (1 0x2)
+#define RESERVE_CHANNEL (1 0x3)
+#define SRC_PORT (1 0x4)
+#define DST_PORT (1 0x5)
+#define IS_CSSA_32 (1 0x6)
+#define IS_CDSA_32 (1 0x7)
+#define SRC_INDEX(1 0x8)
+#define DST_INDEX(1 0x9)
+#define IS_BURST_ONLY4 (1 0xA)
+#define CLEAR_CSR_ON_READ(1 0xB)
+#define IS_WORD_16 (1 0xC)
+#define IS_RW_PRIORITY (1 0xD)
Please use BIT() for these.
enum omap_dma_burst_mode {
OMAP_DMA_DATA_BURST_DIS = 0,
OMAP_DMA_DATA_BURST_4,
@@ -361,6 +377,10 @@ struct omap_dma_channel_params {
#endif
};
+struct omap_dma_dev_attr {
+ u32 dev_caps;
+ u16 lch_count;
+};
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
extern int omap_request_dma(int dev_id, const char *dev_name,
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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 9, 2010 at 7:58 PM, Greg KH g...@kroah.com wrote: If it is easy to revert and push later, then the revert just this piece should be done now. Seriously, I'm getting very confused here, and am very annoyed by the whole thing. With good reason. Here's what I don't like: - the original driver didn't even seem to work properly It _was_ working properly, when it was a separate branch, but the merge to staging wasn't done correctly, so it has never worked there. - people sent me patches they never tested and broke things even worse Part of the blame goes to TI. Even if you have the hardware, it's not straightforward to test this. I have struggled to improve the situation on user-space with the gst-dsp and dsp-tools projects, which btw have not received support from TI, but apparently they were not used to test this (neither was the official solution from TI which is much harder to set up). - some people have no respect for the omap maintainers and what they think about things, or even basic knowledge of the kernel development cycle. I don't think this is the case. The opinion of the OMAP maintainers is valuable in order to cleanup the mess that is this driver. But _first_ it has to work. Most people are not developers, they just want to use this driver. - I do not have this hardware so I can't test anything. So, from now on, I'm not taking ANYONES patches for this driver unless it gets an ack from the driver maintainer, Omar Luna. Actually, no, I'm not going to take any patch unless it _comes from_ Omar. Omar, please work to queue up patches and test them, and then send them to me for merging. Any questions? You mean after this pull, or should Omar re-send this pull request? -- 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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 9, 2010 at 6:29 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 09 November 2010, Felipe Contreras wrote: Felipe Contreras (14): Revert staging: tidspbridge - update Kconfig to select IOMMU module Revert staging: tidspbridge - remove dmm custom module Revert staging: tidspbridge - deprecate reserve/unreserve_memory funtions Revert staging: tidspbridge - remove reserved memory clean up Revert staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct Revert staging: tidspbridge - move all iommu related code to a new file Revert staging: tidspbridge - remove hw directory Revert staging: tidspbridge - fix mmufault support Revert staging: tidspbridge - remove custom mmu code from tiomap3430.c Revert staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name Revert staging: tidspbridge - move shared memory iommu maps to tiomap3430.c Revert staging: tidspbridge: replace iommu custom for opensource implementation That adds quite a lot of crap back in that was removed by Fernando earlier: 44 files changed, 3733 insertions(+), 847 deletions(-) It may have been premature to merge the patches as you say, but now that they are in, I'd vote for giving Fernando a chance to fix up any damage that was done in the process rather than just reverting all the useful changes. The changes from Fernando require changes in other trees: arm, omap. These cannot get into 2.6.37, and I have my doubts they would get into 2.6.38, as I haven't seen those ack'ed yet. Moreover, I have applied all the patches Fernando has sent, and I still haven't seen this driver working with the new iommu code. So, sure, these patches are good, we (Nokia), requested them years ago, but right now there's no way to get this driver working with them on 2.6.37. I would rather have a working driver for once on a vanilla kernel. It is really tiring to point people to different places to get working code depending on which week they ask. -- 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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 09, 2010 at 11:53:29PM +0200, Felipe Contreras wrote: On Tue, Nov 9, 2010 at 7:58 PM, Greg KH g...@kroah.com wrote: If it is easy to revert and push later, then the revert just this piece should be done now. Seriously, I'm getting very confused here, and am very annoyed by the whole thing. With good reason. Here's what I don't like: - the original driver didn't even seem to work properly It _was_ working properly, when it was a separate branch, but the merge to staging wasn't done correctly, so it has never worked there. Well, blame the people who sent it to me then :) - people sent me patches they never tested and broke things even worse Part of the blame goes to TI. Even if you have the hardware, it's not straightforward to test this. I have struggled to improve the situation on user-space with the gst-dsp and dsp-tools projects, which btw have not received support from TI, but apparently they were not used to test this (neither was the official solution from TI which is much harder to set up). - some people have no respect for the omap maintainers and what they think about things, or even basic knowledge of the kernel development cycle. I don't think this is the case. The opinion of the OMAP maintainers is valuable in order to cleanup the mess that is this driver. But _first_ it has to work. Most people are not developers, they just want to use this driver. - I do not have this hardware so I can't test anything. So, from now on, I'm not taking ANYONES patches for this driver unless it gets an ack from the driver maintainer, Omar Luna. Actually, no, I'm not going to take any patch unless it _comes from_ Omar. Omar, please work to queue up patches and test them, and then send them to me for merging. Any questions? You mean after this pull, or should Omar re-send this pull request? I'm not pulling _anything_ at the moment for this driver. I want to see patches, not a pull request please, as these need to be reviewed very closely. 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: [PATCH v3 02/13] OMAP: DMA: Introduce errata handling feature
G, Manjunath Kondaiah manj...@ti.com writes:
Implement errata handling to use flags instead of cpu_is_*
and cpu_class_* in the code.
The errata flags are initialized at init time and during runtime
we are using the errata variable (via the IS_DMA_ERRATA macro)
to execute the required errata workaround.
Reused errata handling patch from Peter Ujfalusi peter.ujfal...@nokia.com
https://patchwork.kernel.org/patch/231191/
When starting from someone else's work, would be very helpful to
reviewers (and original authors) if you summarized what you
changed/fixed/updated etc.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dma.c | 134 ++--
arch/arm/plat-omap/include/plat/dma.h | 11 +++
2 files changed, 103 insertions(+), 42 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 77241e2..0ff82d0 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -195,6 +195,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
#define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
static int enable_1510_mode;
+static u32 errata;
static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
@@ -1216,12 +1217,8 @@ void omap_start_dma(int lch)
cur_lch = next_lch;
} while (next_lch != -1);
- } else if (cpu_is_omap242x() ||
- (cpu_is_omap243x() omap_type() = OMAP2430_REV_ES1_0)) {
-
- /* Errata: Need to write lch even if not using chaining */
+ } else if (IS_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS))
dma_write(lch, CLNK_CTRL2, lch);
- }
omap_enable_channel_irq(lch);
@@ -1231,17 +1228,8 @@ void omap_start_dma(int lch)
dma_write(l, CCR1, lch);
} else {
l = dma_read(CCR2, lch);
- /*
- * Errata: Inter Frame DMA buffering issue (All OMAP2420 and
- * OMAP2430ES1.0): DMA will wrongly buffer elements if packing
- * and bursting is enabled. This might result in data gets
- * stalled in FIFO at the end of the block.
- * Workaround: DMA channels must have BUFFERING_DISABLED bit
- * set to guarantee no data will stay in the DMA FIFO in case
- * inter frame buffering occurs.
- */
- if (cpu_is_omap2420() || (cpu_is_omap2430()
- (omap_type() == OMAP2430_REV_ES1_0)))
+
+ if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
l |= OMAP_DMA_CCR_EN;
@@ -1253,14 +1241,14 @@ EXPORT_SYMBOL(omap_start_dma);
void omap_stop_dma(int lch)
{
- u32 l;
+ u32 l = 0;
/* Disable all interrupts on the channel */
if (cpu_class_is_omap1())
dma_write(0, CICR1, lch);
- /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
- if (cpu_is_omap34xx() (l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+ if (IS_DMA_ERRATA(DMA_ERRATA_i541)
+ (l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
int i = 0;
u32 sys_cf;
@@ -1367,11 +1355,7 @@ dma_addr_t omap_get_dma_src_pos(int lch)
else
offset = dma_read(CSAC2, lch);
- /*
- * omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
- * read before the DMA controller finished disabling the channel.
- */
- if (!cpu_is_omap15xx() offset == 0) {
+ if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0) {
if (cpu_class_is_omap1())
offset = dma_read(CSAC1, lch);
else
@@ -1966,7 +1950,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
{
int *channels;
u32 l, i;
- u32 sys_cf;
+ u32 sys_cf = 0;
/* Check for input params */
if (unlikely((chain_id 0 || chain_id = dma_lch_count))) {
@@ -1981,15 +1965,13 @@ int omap_stop_dma_chain_transfers(int chain_id)
}
channels = dma_linked_lch[chain_id].linked_dmach_q;
- /*
- * DMA Errata:
- * Special programming model needed to disable DMA before end of block
- */
- sys_cf = dma_read(OCP_SYSCONFIG, 0);
- l = sys_cf;
- /* Middle mode reg set no Standby */
- l = ~((1 12)|(1 13));
- dma_write(l, OCP_SYSCONFIG, 0);
+ if (IS_DMA_ERRATA(DMA_ERRATA_i88)) {
+ sys_cf = dma_read(OCP_SYSCONFIG, 0);
+ l = sys_cf;
+ /* Middle mode reg set no Standby */
+ l = ~((1 12)|(1 13));
+ dma_write(l, OCP_SYSCONFIG, 0);
+ }
for (i = 0; i
Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Tue, Nov 9, 2010 at 8:32 PM, Tony Lindgren t...@atomide.com wrote: * Guzman Lugo, Fernando fernando.l...@ti.com [101109 09:43]: On Tue, Nov 9, 2010 at 11:35 AM, Tony Lindgren t...@atomide.com wrote: * Guzman Lugo, Fernando fernando.l...@ti.com [101109 08:36]: tidspbridge iommu change are working fine all the patches and few fixes after that are alredy sent. what breaks tidspbridge, is the unmerged dependencies in linux omap tree, specifically the iommu module patches and the SG patch. Care to post a series of the missing patches listed above? Here are the missing patches: Fernando Guzman Lugo (4): iovmm: no gap checking for fixed address iovmm: add superpages support to fixed da address iovmm: replace __iounmap with omap_iounmap iommu: create new api to set valid da range Yeah this is stuff for Hiroshi to look at and queue for 2.6.28. No way we can merge these now. Right, and he hasn't ack'ed them yet. So there's a chance they don't get into 2.6.38 either. and scatterlist: define SG chain for arm architecture And this we need to test carefully it's not something we can just merge. Has this been tested to work with omap MMC drivers? I'm not at all convinced the drivers can deal with chained SG lists.. This may not show up with light testing, the SG lists can be very small in most cases. So this would have to be tested to make sure the the chained SG list handled properly. The same goes for other omap drivers that may be using SG. And the change doesn't affect OMAP only, it's for all ARM platforms. The proposal from Russell was to do it only on OMAP, but I haven't seen a patch that does that yet. Hopefully this would go into 2.6.38, but again, it might not. -- 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 v3 08/13] OMAP1: DMA: Introduce DMA driver as platform device
G, Manjunath Kondaiah manj...@ti.com writes:
Register OMAP1 DMA driver as platform device and add support
for registering through platform device layer using resource
structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/dma.c | 182
arch/arm/mach-omap1/include/mach/dma.h | 29 +
2 files changed, 211 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/dma.c
create mode 100644 arch/arm/mach-omap1/include/mach/dma.h
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
new file mode 100644
index 000..e756069
--- /dev/null
+++ b/arch/arm/mach-omap1/dma.c
@@ -0,0 +1,182 @@
+/*
+ * dma.c - OMAP1/OMAP7xx-specific DMA code
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun,
Inc.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah manj...@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.
+ */
+
+#include linux/err.h
+#include linux/slab.h
+#include linux/pm_runtime.h
no pm_runtime API usage in this patch.Please add only when needed.
+#include linux/io.h
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
why is sched.h needed?
+#include linux/spinlock.h
ditto
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/device.h
When creating a new file like this, it's important to only include
headers that are actually used/needed.
+#include plat/dma.h
+#include plat/tc.h
+
+#define OMAP1_DMA_BASE (0xfffed800)
+
+static struct resource res[] __initdata = {
+ [0] = {
+ .start = OMAP1_DMA_BASE,
+ .end= OMAP1_DMA_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .name = 0,
+ .start = INT_DMA_CH0_6,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .name = 1,
+ .start = INT_DMA_CH1_7,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .name = 2,
+ .start = INT_DMA_CH2_8,
+ .flags = IORESOURCE_IRQ,
+ },
+ [4] = {
+ .name = 3,
+ .start = INT_DMA_CH3,
+ .flags = IORESOURCE_IRQ,
+ },
+ [5] = {
+ .name = 4,
+ .start = INT_DMA_CH4,
+ .flags = IORESOURCE_IRQ,
+ },
+ [6] = {
+ .name = 5,
+ .start = INT_DMA_CH5,
+ .flags = IORESOURCE_IRQ,
+ },
+ [7] = {
+ .name = 6,
+ .start = INT_DMA_LCD,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* irq's for omap16xx and omap7xx */
+ [8] = {
+ .name = 7,
+ .start = 53 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [9] = {
+ .name = 8,
+ .start = 54 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [10] = {
+ .name = 9,
+ .start = 55 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [11] = {
+ .name = 10,
+ .start = 56 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [12] = {
+ .name = 11,
+ .start = 57 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [13] = {
+ .name = 12,
+ .start = 58 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [14] = {
+ .name = 13,
+ .start = 59 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [15] = {
+ .name = 14,
+ .start = 60 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [16] = {
+ .name = 15,
+ .start = 61 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [17] = {
+ .name = 16,
+ .start = 62 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static int __init omap1_system_dma_init(void)
+{
+ struct omap_system_dma_plat_info*p;
+ struct platform_device *pdev;
+
Re: [PATCH v3 10/13] OMAP: DMA: Convert DMA library into DMA platform Driver
G, Manjunath Kondaiah manj...@ti.com writes: Convert DMA library into DMA platform driver and make use of platform data provided by HWMOD data base for OMAP2PLUS onwards. For OMAP1 processors, the DMA driver in mach-omap uses resource structures for getting platform data. Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.com [...] diff --git a/arch/arm/mach-omap2/include/mach/dma.h b/arch/arm/mach-omap2/include/mach/dma.h index d0a7d5b..d13c5c0 100644 --- a/arch/arm/mach-omap2/include/mach/dma.h +++ b/arch/arm/mach-omap2/include/mach/dma.h @@ -29,4 +29,7 @@ #ifndef __ASM_ARCH_OMAP2_DMA_H #define __ASM_ARCH_OMAP2_DMA_H +/* Should be part of hwmod data base ? */ +#define OMAP_DMA4_LOGICAL_DMA_CH_COUNT 32 /* REVISIT: Is this 32 + 2? */ + There are no users of this in this patch, all users are removed. 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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1
On Wed, Nov 10, 2010 at 12:10 AM, Greg KH g...@kroah.com wrote: On Tue, Nov 09, 2010 at 11:53:29PM +0200, Felipe Contreras wrote: You mean after this pull, or should Omar re-send this pull request? I'm not pulling _anything_ at the moment for this driver. I want to see patches, not a pull request please, as these need to be reviewed very closely. It's a revert from a non-working state to a working state, there's not much to review there. So if Omar sends the patches with my and his s-o-b, would you apply the patches? Getting these patches in one way or the other seems to be the only way we can get this driver to work on 2.6.37. -- 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 v3 13/13] OMAP: PM: DMA: Enable runtime pm
G, Manjunath Kondaiah manj...@ti.com writes:
Enable runtime pm and use pm_runtime_get and pm_runtime_put
for OMAP DMA driver.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dma.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 41b14b0..feac7ee 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -35,6 +35,7 @@
#include linux/io.h
#include linux/slab.h
#include linux/delay.h
+#include linux/pm_runtime.h
#include asm/system.h
#include mach/hardware.h
@@ -367,6 +368,8 @@ int omap_request_dma(int dev_id, const char *dev_name,
chan = dma_chan + free_ch;
chan-dev_id = dev_id;
+ pm_runtime_get(pd-dev);
The _get() call is asynchronous. So if the device was actually
idled/disabled, immediately after this call it may still be
idle/disabled. When using the asynchronous versions of the API, the
device should not be touched until the driver's -runtime_resume()
callback is called.
if (d-dev_caps IS_WORD_16)
p-clear_lch_regs(free_ch);
else
@@ -452,6 +455,7 @@ void omap_free_dma(int lch)
omap_clear_dma(lch);
p-clear_dma_sglist_mode(lch);
}
+ pm_runtime_put(pd-dev);
spin_lock_irqsave(dma_chan_lock, flags);
dma_chan[lch].dev_id = -1;
dma_chan[lch].next_lch = -1;
@@ -819,6 +823,11 @@ static int __devinit omap_system_dma_probe(struct
platform_device *pdev)
dma_chan_count = d-chan_count;
dma_chan= d-chan;
+ /* Enable run time PM */
comment is redundant
+ pm_runtime_enable(pd-dev);
+
+ /* Accessing hw registers, get clock */
comment is wrong, driver doesn't know anything about clocks.
Just drop comment as it doesn't tell you anything that the following
'get' doesn't.
+ pm_runtime_get(pd-dev);
see above Re: async calls.
for (ch = 0; ch dma_chan_count; ch++) {
unsigned long flags;
omap_clear_dma(ch);
@@ -846,6 +855,10 @@ static int __devinit omap_system_dma_probe(struct
platform_device *pdev)
dma_chan[0].dev_id = 0;
dma_chan[1].dev_id = 1;
}
+
+ if (!omap_dma_reserve_channels)
+ pm_runtime_put(pd-dev);
+
So if the reserve channels feature is used, PM is essentially disabled
for sDMA. You should add a warning here to that effect as well.
return 0;
exit_release_region:
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 v3 00/13] OMAP: DMA: hwmod and DMA as platform device
G, Manjunath Kondaiah manj...@ti.com writes: This patch series converts DMA library into platform device and hwmod adaptation is done for omap2+ processors. It also replaces cpu_*is* checks by moving omap1 and omap2+ processor code into repsective mach-omapx directories. The common code in plat-omap will use device attributes for differentiating omap1 and omap2 code. This summary, and the various changelogs need to be updated to be more descriptive, particularily in the usage of the words 'device' and 'driver'. The changelog terminology used is confusing, and sometimes wrong. What is actually being done is splitting up the current DMA library into 3 parts: a common platform_driver (plat-omap/dma.c), OMAP1 device code (mach-omap1/dma.c) and OMAP2+ device code (mach-omap2/dma.c) Build Report: omap1: Success for omap_h2_1610_defconfig omap2+: Success for omap2plus_defconfig Test Report: omap2+:(multiboot defconfig boots on all the omap2+ boards listed below): OMAP4BLAZE: http://pastebin.com/HVnim30G OMAP3630ZOOM3: http://pastebin.com/JJwrtP4F OMAP243SDP: http://pastebin.com/mz7cVQL3 omap1 : Not tested Test cases executed: 1. All applicable TI DMA tests which are located at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=dma/test_code;h=0d00de3c0fe6933b405c62da63f694883f3e4b8f;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253 2. Use case tests : TI MMC tests are executed with differenct types of files systems such as DOS, ext2, ext3 etc on omap4 blaze and omap3630 zoom3. More information can be found at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=mmc/test_code;h=d0bc1984eef46ac45719efb02b5c1f4193422a1b;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253 Dependencies: This patch series has dependency on omap_device patch: https://patchwork.kernel.org/patch/282212/ Thanks for the thorough build and test report. Very nice. Kevin This patch series applies on: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Branch: master commit a83d12a47c9a8c78a184910150797045d69a1570 Merge: f9f47f5 c1fb8df Author: Tony Lindgren t...@atomide.com Date: Fri Oct 22 11:21:08 2010 -0700 Linux-omap rebuilt: Updated to v2.6.36, add 24xx uart fix Changelist summary: v3: Review comments fixed: http://www.listware.net/201008/linux-omap/89002-patch-v2-0011-omap-dma-hwmod-and-dma-as-platform-driver.html - created and tested on latest linux-omap master branch(2.6.36 kernel) v2: The review comments which are fixed can be found at: http://www.spinics.net/lists/linux-omap/msg34291.html http://www.spinics.net/lists/linux-omap/msg34292.html http://www.spinics.net/lists/linux-omap/msg34078.html http://www.spinics.net/lists/linux-omap/msg34083.html v1: These changes are based on comments received during internal discussions which has changes(compared to previous version) such as: - Code optimization - Patches are rearranged in more meaningful way so that git bisect works at any intermediate patch in the series. - Build tested for all omap's(OMAP1 and OMAP2PLUS) - Boot tested for OMAP3 and OMAP4(appreciate if some one tests on OMAP1/2) - Applicalbe tests are executed on OMAP3 and OMAP4 boards - Rebased and added descriptor autoloading feature(only for omap3630 and omap4) Benoit Cousson (1): OMAP4: DMA: hwmod: add system DMA G, Manjunath Kondaiah (12): OMAP: DMA: Replace read/write macros with functions OMAP: DMA: Introduce errata handling feature OMAP: DMA: Introduce DMA device attributes OMAP2420: DMA: hwmod: add system DMA OMAP2430: DMA: hwmod: add system DMA OMAP3: DMA: hwmod: add system DMA OMAP1: DMA: Introduce DMA driver as platform device OMAP2+: DMA: hwmod: Device registration OMAP: DMA: Convert DMA library into DMA platform Driver OMAP: DMA: Use DMA device attributes sDMA: descriptor autoloading feature OMAP: PM: DMA: Enable runtime pm arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/dma.c | 665 ++ arch/arm/mach-omap1/include/mach/dma.h | 51 + arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dma.c | 1579 arch/arm/mach-omap2/include/mach/dma.h | 86 ++ arch/arm/mach-omap2/omap_hwmod_2420_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 93 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 ++ arch/arm/plat-omap/dma.c | 1850 arch/arm/plat-omap/include/plat/dma.h | 387 --- 12 files changed, 3207 insertions(+), 1777 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.c create mode 100644 arch/arm/mach-omap1/include/mach/dma.h create mode 100644 arch/arm/mach-omap2/dma.c create mode 100644 arch/arm/mach-omap2/include/mach/dma.h Cc: Benoit Cousson b-cous...@ti.com
Re: [PATCH v3 04/13] OMAP2420: DMA: hwmod: add system DMA
G, Manjunath Kondaiah manj...@ti.com writes:
Add OMAP2420 DMA hwmod structures.
s/structures/data/
Also, as pointed out in many other hwmod reviews, when adding hwmod
data, subject should be something like:
OMAP2420: hwmod_data: add system DMA
Kevin
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 85
1 files changed, 85 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 a1a3dd6..3a51392 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -38,6 +38,7 @@ static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -557,6 +558,89 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/* system dma */
+static struct omap_hwmod_class_sysconfig omap2420_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap2420_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32,
+ .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
+ { .name = 0, .irq = INT_24XX_SDMA_IRQ0 },
+ { .name = 1, .irq = INT_24XX_SDMA_IRQ1 },
+ { .name = 2, .irq = INT_24XX_SDMA_IRQ2 },
+ { .name = 3, .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
+ .master = omap2420_dma_system_hwmod,
+ .slave = omap2420_l3_main_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_masters[] = {
+ omap2420_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap2420_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_slaves[] = {
+ omap2420_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2420_dma_system_hwmod = {
+ .name = dma,
+ .class = omap2420_dma_hwmod_class,
+ .mpu_irqs = omap2420_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .slaves = omap2420_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_dma_system_slaves),
+ .masters= omap2420_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -569,6 +653,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_uart3_hwmod,
omap2420_i2c1_hwmod,
omap2420_i2c2_hwmod,
+ omap2420_dma_system_hwmod,
NULL,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/13] OMAP: DMA: Convert DMA library into DMA platform Driver
G, Manjunath Kondaiah manj...@ti.com writes:
Convert DMA library into DMA platform driver and make use
of platform data provided by HWMOD data base for OMAP2PLUS onwards.
For OMAP1 processors, the DMA driver in mach-omap uses resource
structures for getting platform data.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/dma.c | 180 ++-
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/dma.c | 209 +-
arch/arm/mach-omap2/include/mach/dma.h |3 +
arch/arm/plat-omap/dma.c | 321
+++-
arch/arm/plat-omap/include/plat/dma.h | 50 --
7 files changed, 538 insertions(+), 229 deletions(-)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9a304d8..b7dfc54 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
+obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o dma.o
obj-y += clock.o clock_data.o opp_data.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index e756069..38a7294 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -35,6 +35,81 @@
#include plat/tc.h
#define OMAP1_DMA_BASE (0xfffed800)
+#define OMAP1_LOGICAL_DMA_CH_COUNT 17
+
+static u32 errata;
+static u32 enable_1510_mode;
+
+enum {
+ GCR1 = 0, GSCR, GRST, HW_ID,
+ PCH2_ID,PCH0_ID,PCH1_ID,PCHG_ID,
+ PCHD_ID,CAPS_0_U, CAPS_0_L, CAPS_1_U,
+ CAPS_1_L, CAPS_2, CAPS_3, CAPS_4,
+ PCH2_SR,PCH0_SR,PCH1_SR,PCHD_SR,
+
+ CH_COMMON_START,
+
+ /* Common Registers */
+ CSDP1, CCR1, CICR1, CSR1,
+ CEN1, CFN1, CSFI1, CSEI1,
+ CPC,CSAC1, CDAC1, CDEI1,
+ CDFI1, CLNK_CTRL1,
+
+ /* Channel specific register offsets */
+ CSSA_L, CSSA_U, CDSA_L, CDSA_U,
+ COLOR_L,COLOR_U,CCR1_2, LCH_CTRL,
+
+ CH_COMMON_END,
+};
These reg_map enums are added here, then promptly moved in the following
patch. Please just put them in the right place earlier in the series.
Also, at this point, similar versions also still exist in
plat-omap/dma.c
This may be a good technique for inflating the number of lines changed
in the git history, but it is not review friendly.
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 1/5] omap: mailbox: initial hwmod support for omap3
Omar Ramirez Luna omar.rami...@ti.com writes: From: Felipe Contreras felipe.contre...@gmail.com HWMOD support for omap3. -ENO_DESCRIPTIVE_CHANGELOG Please describe in more detail what is happening here, starting with a better subject: omap: mailbox: build device using omap_device/omap_hwmod and the changelog should describe that what is being changed is that there is no longer a need for static platform_device and resources since all of this data is contained in the omap_hwmod for the mailbox. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- arch/arm/mach-omap2/devices.c | 100 --- arch/arm/mach-omap2/mailbox.c |1 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 +++ please separate out the addition of hwmod_data into it's own patch that comes before this. As mentioned by Charu, all the hwmod data could be added early in the series, before this conversion is done. 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 3/5] omap: mailbox: add omap_device latency information
Omar Ramirez Luna omar.rami...@ti.com writes:
From: Felipe Contreras felipe.contre...@gmail.com
So that we can enable the main clock.
-ENO_DESCRIPTIVE_CHANGELOG
omap_device_enable/disable do more than just manage the clocks
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/devices.c | 19 +--
arch/arm/mach-omap2/mailbox.c | 21 +
arch/arm/plat-omap/include/plat/mailbox.h |6 ++
3 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d977572..337fd7a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,7 @@
#include plat/dma.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
+#include plat/mailbox.h
#include mux.h
#include control.h
@@ -141,10 +142,20 @@ static inline void omap_init_camera(void)
#endif
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
+static struct omap_device_pm_latency mbox_latencies[] = {
+ [0] = {
+ .activate_func = omap_device_enable_clocks,
+ .activate_lat = 5, /* FIXME random value */
+ .deactivate_func = omap_device_enable_clocks,
+ .deactivate_lat = 5, /* FIXME random value */
+ },
+};
hmm, I'm hoping you're not expecting this to merge when using random values.
static inline void omap_init_mbox(void)
{
struct omap_hwmod *oh;
struct omap_device *od;
+ struct omap_mbox_platform_data pdata;
oh = omap_hwmod_lookup(mailbox);
if (!oh) {
@@ -152,10 +163,14 @@ static inline void omap_init_mbox(void)
return;
}
+ pdata.device_enable = omap_device_enable;
+ pdata.device_disable = omap_device_idle;
If the driver want's to use the hooks, just use the runtime PM API.
More on this below.
od = omap_device_build(omap-mailbox, -1, oh,
- NULL, 0,
- NULL, 0,
+ pdata, sizeof(pdata),
+ mbox_latencies, ARRAY_SIZE(mbox_latencies),
0);
+
if (!od) {
pr_err(%s: could not build device\n, __func__);
return;
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 1ddb82d..61f2149 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -53,6 +53,7 @@
#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32))
static void __iomem *mbox_base;
+static struct platform_device *mbox_pdev;
struct omap_mbox2_fifo {
unsigned long msg;
@@ -71,8 +72,6 @@ struct omap_mbox2_priv {
unsigned long irqdisable;
};
-static struct clk *mbox_ick_handle;
-
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq);
@@ -91,14 +90,10 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
{
u32 l;
unsigned long timeout;
+ struct omap_mbox_platform_data *pdata = mbox_pdev-dev.platform_data;
- mbox_ick_handle = clk_get(NULL, mailboxes_ick);
- if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR Could not get mailboxes_ick: %ld\n,
- PTR_ERR(mbox_ick_handle));
- return PTR_ERR(mbox_ick_handle);
- }
- clk_enable(mbox_ick_handle);
+ if (pdata-device_enable)
+ pdata-device_enable(mbox_pdev);
pm_runtime_get_sync(dev)
if (cpu_is_omap44xx()) {
mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
@@ -144,9 +139,9 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
static void omap2_mbox_shutdown(struct omap_mbox *mbox)
{
- clk_disable(mbox_ick_handle);
- clk_put(mbox_ick_handle);
- mbox_ick_handle = NULL;
+ struct omap_mbox_platform_data *pdata = mbox_pdev-dev.platform_data;
+ if (pdata-device_disable)
+ pdata-device_disable(mbox_pdev);
pm_runtime_put(dev)
}
/* Mailbox FIFO handle functions */
@@ -428,6 +423,8 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
+ mbox_pdev = pdev;
please don't use a global for this. What if a future SoC has more than
one mailbox?
How about adding a field to struct omap_mbox?
ret = omap_mbox_register(pdev-dev, list);
if (ret) {
iounmap(mbox_base);
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..59443b1 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -11,6 +11,7 @@
typedef u32 mbox_msg_t;
struct omap_mbox;
+struct platform_device;
typedef int __bitwise
Re: [PATCH v2] OMAP4: Extend clock database.
Thara Gopinath th...@ti.com writes: This patch extends the OMAP4 clock data to include various x2 clock nodes as the clock framework skips a *2 whie calculating the dpll locked frequency. The clock databse extensions are autogenerated using the scripts maintained by Benoit Cousson. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Thara Gopinath th...@ti.com The subject could be a bit more descriptive here, something like: OMAP4: clock: add various DPLL x2 clock nodes or something similar. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap: mailbox: add omap_device latency information
On Wed, Nov 10, 2010 at 1:48 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
+static struct omap_device_pm_latency mbox_latencies[] = {
+ [0] = {
+ .activate_func = omap_device_enable_clocks,
+ .activate_lat = 5, /* FIXME random value */
+ .deactivate_func = omap_device_enable_clocks,
+ .deactivate_lat = 5, /* FIXME random value */
+ },
+};
hmm, I'm hoping you're not expecting this to merge when using random values.
No, I was hoping you would comment in the RFC I sent clearly
mentioning this was an experiment 6 months ago:
http://thread.gmane.org/gmane.linux.ports.arm.omap/36745
AFAICR this was one of the first patches for hwmod, so there was not
much reference. I did see more proper ways to set those latencies
after sending that patch (automatic calculation IIRC), but I didn't
manage to work on that code again. There are more important things to
do, like getting the only user of the mailbox to actually work.
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -53,6 +53,7 @@
#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32))
static void __iomem *mbox_base;
+static struct platform_device *mbox_pdev;
+ mbox_pdev = pdev;
please don't use a global for this. What if a future SoC has more than
one mailbox?
How about adding a field to struct omap_mbox?
If you see above, there can be only one (mbox_base is already global).
So support for multiple mailboxes would be the subject of a separate
patch.
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 3/5] omap: mailbox: add omap_device latency information
On Tue, Nov 9, 2010 at 5:48 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
+static struct omap_device_pm_latency mbox_latencies[] = {
+ [0] = {
+ .activate_func = omap_device_enable_clocks,
+ .activate_lat = 5, /* FIXME random value */
+ .deactivate_func = omap_device_enable_clocks,
+ .deactivate_lat = 5, /* FIXME random value */
+ },
+};
hmm, I'm hoping you're not expecting this to merge when using random values.
This was changed on the second iteration of the patch [1], and is
still a WIP as some more comments have been made. I'll keep your
current comments though.
Regards,
Omar
---
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38169.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 1/5] omap: mailbox: initial hwmod support for omap3
On Tue, Nov 9, 2010 at 5:38 PM, Kevin Hilman khil...@deeprootsystems.com wrote: --- arch/arm/mach-omap2/devices.c | 100 --- arch/arm/mach-omap2/mailbox.c | 1 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 +++ please separate out the addition of hwmod_data into it's own patch that comes before this. As mentioned by Charu, all the hwmod data could be added early in the series, before this conversion is done. Yes, this was changed in v2 [1], thanks for your comments, they will be addressed in the next version. Regards, Omar --- [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38171.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
