[PATCH v3 0/2] TWL6030, TWL6032 GPADC driver
Hello, v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Sysfs entries are added to start and read conversion result in millivolts for chosen channel. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of if (device == X) code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi |6 + drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 4 files changed, 1034 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
arch/arm/boot/dts/twl6030.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = ti,twl6030-pwmled;
#pwm-cells = 2;
};
+
+ gpadc: twl6030_gpadc {
+ compatible = ti,twl6030_gpadc;
+ interrupts = 3;
+ #io-channel-cells = 1;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K balaj...@ti.com Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com --- drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 3 files changed, 1028 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..87d699e 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -157,4 +157,12 @@ config VIPERBOARD_ADC Say yes here to access the ADC part of the Nano River Technologies Viperboard. +config TWL6030_GPADC + tristate TWL6030 GPADC (General Purpose A/D Convertor) Support + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030 General Purpose + A/D Convertor. + endmenu diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..8b05633 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..6ceb789 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1019 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat nska...@ti.com + * Balaji T K balaj...@ti.com + * Graeme Gregory g...@slimlogic.co.uk + * Girish S Ghongdemath giris...@ti.com + * Ambresh K ambr...@ti.com + * Oleksandr Kozaruk oleksandr.koza...@ti.com + * + * Based on twl4030-madc.c + * Copyright (C) 2008 Nokia Corporation + * Mikko Ylinen mikko.k.yli...@nokia.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include linux/init.h +#include linux/interrupt.h +#include linux/kernel.h +#include linux/module.h +#include linux/platform_device.h +#include linux/of_platform.h +#include linux/i2c/twl.h +#include linux/iio/iio.h +#include linux/iio/sysfs.h + +#define DRIVER_NAMEtwl6030_gpadc + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 +/* Define this as the biggest of all chips using this driver */ +#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS + +#define TWL6030_GPADC_CTRL 0x00/* 0x2e */ +#define TWL6030_GPADC_CTRL20x01/* 0x2f */ + +#define TWL6030_GPADC_CTRL_P1 0x05 +#define TWL6030_GPADC_CTRL_P2 0x06 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_RTCH0_LSB0x09 +#define TWL6032_GPADC_RTCH0_MSB0x0a +#define TWL6032_GPADC_RTCH1_LSB0x0b +#define TWL6032_GPADC_RTCH1_MSB0x0c +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define
Re: [PATCH 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
* Rajendra Nayak rna...@ti.com [130711 03:59]:
This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
The above commit stubbed out omap_serial_early_init() in case of
DT build thinking it was doing the serial port initializations.
Well not really. It was done to cut dependency between device
tree initialized drivers and pdata initialized drivers.
omap_serial_early_init() however does not do the serial port
inits (its instead done by omap_serial_init_port()) instead
it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
for the console uart which causes hwmod to avoid doing a reset
followed by the idling of the console uart.
This is still needed even in the DT case.
This fix is going the wrong way.
The console is working fine with DT based booting for me,
except for the earlyprintk fix needed.
And there should not be any need to parse cmdline for console
as omap-serial.c sets it up and already knows about it.
Care to state what exactly this attempts to fix and for which
omaps? If this is only needed for am33xx, then why?
Regards,
Tony
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Mark Jackson mpfj-l...@newflow.co.uk
Reported-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/serial.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3a674de..58d5b56 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -175,9 +175,6 @@ static char *cmdline_find_option(char *str)
static int __init omap_serial_early_init(void)
{
- if (of_have_populated_dt())
- return -ENODEV;
-
do {
char oh_name[MAX_UART_HWMOD_NAME_LEN];
struct omap_hwmod *oh;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
* Rajendra Nayak rna...@ti.com [130711 03:59]: This series should fix the issue with the early serial crash seen during hwmod _setup() as reported by [1] The issue was reported on a am33xx device and was not seen on omap4 or omap5 devices as the hwmod data for both omap4 and omap5 had statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for uart3 which happens to be the debug console used on omap4 panda and omap5 uevm boards. The serial driver should be capable of setting this on it's own as it sets up the console. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
* Peter Ujfalusi peter.ujfal...@ti.com [130711 07:30]:
OMAP4 no longer boots in legacy mode so the code here is no longer used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 332
++-
arch/arm/mach-omap2/twl-common.h | 8 -
2 files changed, 12 insertions(+), 328 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index c05898f..932dea7 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -38,20 +38,6 @@ static struct i2c_board_info __initdata
pmic_i2c_board_info = {
.flags = I2C_CLIENT_WAKE,
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-static int twl_set_voltage(void *data, int target_uV)
-{
- struct voltagedomain *voltdm = (struct voltagedomain *)data;
- return voltdm_scale(voltdm, target_uV);
-}
-
-static int twl_get_voltage(void *data)
-{
- struct voltagedomain *voltdm = (struct voltagedomain *)data;
- return voltdm_get_voltage(voltdm);
-}
-#endif
Looks like the code above is also needed for omap3 based on the
if defined?
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 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
On Friday 12 July 2013 12:50 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130711 03:59]:
This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
The above commit stubbed out omap_serial_early_init() in case of
DT build thinking it was doing the serial port initializations.
Well not really. It was done to cut dependency between device
tree initialized drivers and pdata initialized drivers.
omap_serial_early_init() however does not do the serial port
inits (its instead done by omap_serial_init_port()) instead
it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
for the console uart which causes hwmod to avoid doing a reset
followed by the idling of the console uart.
This is still needed even in the DT case.
This fix is going the wrong way.
The console is working fine with DT based booting for me,
except for the earlyprintk fix needed.
It works on omap4 and omap5. It won't work on any
am33xx devices.
And there should not be any need to parse cmdline for console
as omap-serial.c sets it up and already knows about it.
Care to state what exactly this attempts to fix and for which
omaps? If this is only needed for am33xx, then why?
Yes, this is needed only for am33xx because am33xx hwmod rightly
had the hwmod flags for NO_IDLE and NO_RESET removed and omap4
and omap5 wrongly still carry them around.
Just try applying PATCH 2/2 of this series and it won't work on the
omap4 sdp anymore.
regards,
Rajendra
Regards,
Tony
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Mark Jackson mpfj-l...@newflow.co.uk
Reported-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/serial.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3a674de..58d5b56 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -175,9 +175,6 @@ static char *cmdline_find_option(char *str)
static int __init omap_serial_early_init(void)
{
-if (of_have_populated_dt())
-return -ENODEV;
-
do {
char oh_name[MAX_UART_HWMOD_NAME_LEN];
struct omap_hwmod *oh;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
On Friday 12 July 2013 12:52 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130711 03:59]: This series should fix the issue with the early serial crash seen during hwmod _setup() as reported by [1] The issue was reported on a am33xx device and was not seen on omap4 or omap5 devices as the hwmod data for both omap4 and omap5 had statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for uart3 which happens to be the debug console used on omap4 panda and omap5 uevm boards. The serial driver should be capable of setting this on it's own as it sets up the console. These flags are used to avoid an early reset that hwmod does to all devices on the SoC and is done much before serial driver is initialized. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM i.MX53: mba53: Fix PWM backlight DT node
On Thu, Jul 11, 2013 at 04:37:47PM +0200, Laurent Pinchart wrote: The i.MX53 PWM controller uses two cells to describe the PWM specifier. Remove the extra unused values from the backlight DT node pwms property. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
* Rajendra Nayak rna...@ti.com [130712 00:38]: On Friday 12 July 2013 12:50 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130711 03:59]: This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916. The above commit stubbed out omap_serial_early_init() in case of DT build thinking it was doing the serial port initializations. Well not really. It was done to cut dependency between device tree initialized drivers and pdata initialized drivers. omap_serial_early_init() however does not do the serial port inits (its instead done by omap_serial_init_port()) instead it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags for the console uart which causes hwmod to avoid doing a reset followed by the idling of the console uart. This is still needed even in the DT case. This fix is going the wrong way. The console is working fine with DT based booting for me, except for the earlyprintk fix needed. It works on omap4 and omap5. It won't work on any am33xx devices. OK. I assume the regular serial onsole works just fine, what does not work is the earlyprintk for am33xx? And there should not be any need to parse cmdline for console as omap-serial.c sets it up and already knows about it. Care to state what exactly this attempts to fix and for which omaps? If this is only needed for am33xx, then why? Yes, this is needed only for am33xx because am33xx hwmod rightly had the hwmod flags for NO_IDLE and NO_RESET removed and omap4 and omap5 wrongly still carry them around. OK. Just try applying PATCH 2/2 of this series and it won't work on the omap4 sdp anymore. OK, so that's only for earlyprintk then? If so, it seems the right fix is to set the NO_IDLE and NO_RESET flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected in the Kconfig now. The current code in mach-omap2/serial.c is wrong, and is a hack needed for the pdata based booting. What's broken is that omap_serial_early_init() parses the cmdline for console, which itself is pretty nasty, and it won't work the right way as there's nothing stopping from having the earlycon in a different UART from the serial console. So we just want to get rid of the whole mach-omap2/serial.c once we're all DT. So to summarize, we have two bugs: 1. Omap hwmod code can reset UART while earlycon may be using it. The fix to this is to use NO_IDLE and NO_RESET flags in the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified. 2. A bug in drivers/tty/serial/omap-serial.c where the missing context loss count can cause NULL context to be initialized during driver probe causing port to hang for earlycon. The fix for that is what Felipe has suggested or fix it in the driver by removing the context loss count usage and detect the need for context restore based on the UART state. Or am I still missing something? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
* Rajendra Nayak rna...@ti.com [130712 00:39]: On Friday 12 July 2013 12:52 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130711 03:59]: This series should fix the issue with the early serial crash seen during hwmod _setup() as reported by [1] The issue was reported on a am33xx device and was not seen on omap4 or omap5 devices as the hwmod data for both omap4 and omap5 had statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for uart3 which happens to be the debug console used on omap4 panda and omap5 uevm boards. The serial driver should be capable of setting this on it's own as it sets up the console. These flags are used to avoid an early reset that hwmod does to all devices on the SoC and is done much before serial driver is initialized. OK so that's only needed for earlycon then it seems. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
On 07/12/2013 09:26 AM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [130711 07:30]:
OMAP4 no longer boots in legacy mode so the code here is no longer used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 332
++-
arch/arm/mach-omap2/twl-common.h | 8 -
2 files changed, 12 insertions(+), 328 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index c05898f..932dea7 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -38,20 +38,6 @@ static struct i2c_board_info __initdata
pmic_i2c_board_info = {
.flags = I2C_CLIENT_WAKE,
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-static int twl_set_voltage(void *data, int target_uV)
-{
-struct voltagedomain *voltdm = (struct voltagedomain *)data;
-return voltdm_scale(voltdm, target_uV);
-}
-
-static int twl_get_voltage(void *data)
-{
-struct voltagedomain *voltdm = (struct voltagedomain *)data;
-return voltdm_get_voltage(voltdm);
-}
-#endif
Looks like the code above is also needed for omap3 based on the
if defined?
Yes it is still needed for OMAP3 when booting in legacy. I have moved these
two function down within the #if defined(CONFIG_ARCH_OMAP3) :
#if defined(CONFIG_ARCH_OMAP3)
@@ -189,6 +160,18 @@ static struct regulator_init_data omap3_vdd2 = {
.consumer_supplies = omap3_vdd2_supply,
};
+static int twl_set_voltage(void *data, int target_uV)
+{
+ struct voltagedomain *voltdm = (struct voltagedomain *)data;
+ return voltdm_scale(voltdm, target_uV);
+}
+
+static int twl_get_voltage(void *data)
+{
+ struct voltagedomain *voltdm = (struct voltagedomain *)data;
+ return voltdm_get_voltage(voltdm);
+}
+
static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
.get_voltage = twl_get_voltage,
.set_voltage = twl_set_voltage,
@@ -235,297 +218,6 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
#endif /* CONFIG_ARCH_OMAP3 */
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
* Peter Ujfalusi peter.ujfal...@ti.com [130712 01:20]:
On 07/12/2013 09:26 AM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [130711 07:30]:
OMAP4 no longer boots in legacy mode so the code here is no longer used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 332
++-
arch/arm/mach-omap2/twl-common.h | 8 -
2 files changed, 12 insertions(+), 328 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index c05898f..932dea7 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -38,20 +38,6 @@ static struct i2c_board_info __initdata
pmic_i2c_board_info = {
.flags = I2C_CLIENT_WAKE,
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-static int twl_set_voltage(void *data, int target_uV)
-{
- struct voltagedomain *voltdm = (struct voltagedomain *)data;
- return voltdm_scale(voltdm, target_uV);
-}
-
-static int twl_get_voltage(void *data)
-{
- struct voltagedomain *voltdm = (struct voltagedomain *)data;
- return voltdm_get_voltage(voltdm);
-}
-#endif
Looks like the code above is also needed for omap3 based on the
if defined?
Yes it is still needed for OMAP3 when booting in legacy. I have moved these
two function down within the #if defined(CONFIG_ARCH_OMAP3) :
#if defined(CONFIG_ARCH_OMAP3)
@@ -189,6 +160,18 @@ static struct regulator_init_data omap3_vdd2 = {
.consumer_supplies = omap3_vdd2_supply,
};
+static int twl_set_voltage(void *data, int target_uV)
+{
+ struct voltagedomain *voltdm = (struct voltagedomain *)data;
+ return voltdm_scale(voltdm, target_uV);
+}
+
+static int twl_get_voltage(void *data)
+{
+ struct voltagedomain *voltdm = (struct voltagedomain *)data;
+ return voltdm_get_voltage(voltdm);
+}
+
static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
.get_voltage = twl_get_voltage,
.set_voltage = twl_set_voltage,
@@ -235,297 +218,6 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
#endif /* CONFIG_ARCH_OMAP3 */
Oh OK sorry I missed that while glancing over it.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130712 00:38]:
On Friday 12 July 2013 12:50 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130711 03:59]:
This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
The above commit stubbed out omap_serial_early_init() in case of
DT build thinking it was doing the serial port initializations.
Well not really. It was done to cut dependency between device
tree initialized drivers and pdata initialized drivers.
omap_serial_early_init() however does not do the serial port
inits (its instead done by omap_serial_init_port()) instead
it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
for the console uart which causes hwmod to avoid doing a reset
followed by the idling of the console uart.
This is still needed even in the DT case.
This fix is going the wrong way.
The console is working fine with DT based booting for me,
except for the earlyprintk fix needed.
It works on omap4 and omap5. It won't work on any
am33xx devices.
OK. I assume the regular serial onsole works just fine, what does
not work is the earlyprintk for am33xx?
Yes, thats right.
And there should not be any need to parse cmdline for console
as omap-serial.c sets it up and already knows about it.
Care to state what exactly this attempts to fix and for which
omaps? If this is only needed for am33xx, then why?
Yes, this is needed only for am33xx because am33xx hwmod rightly
had the hwmod flags for NO_IDLE and NO_RESET removed and omap4
and omap5 wrongly still carry them around.
OK.
Just try applying PATCH 2/2 of this series and it won't work on the
omap4 sdp anymore.
OK, so that's only for earlyprintk then?
yes,
If so, it seems the right fix is to set the NO_IDLE and NO_RESET
flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
in the Kconfig now.
ok makes sense. It seems like the static data in hwmod can be populated
based on these defines? something like
/* uart3 */
static struct omap_hwmod omap44xx_uart3_hwmod = {
.name = uart3,
.class = omap44xx_uart_hwmod_class,
.clkdm_name = l4_per_clkdm,
#ifdef CONFIG_DEBUG_OMAP4UART3
.flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
HWMOD_SWSUP_SIDLE_ACT,
#else
.flags = HWMOD_SWSUP_SIDLE_ACT,
#endif
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
And same way for others? That way the cmdline parsing can be done away
with even for the non-DT case.
The current code in mach-omap2/serial.c is wrong, and is a hack
needed for the pdata based booting. What's broken is that
omap_serial_early_init() parses the cmdline for console, which
itself is pretty nasty, and it won't work the right way as
there's nothing stopping from having the earlycon in a different
UART from the serial console. So we just want to get rid of the
whole mach-omap2/serial.c once we're all DT.
So to summarize, we have two bugs:
1. Omap hwmod code can reset UART while earlycon may be using
it. The fix to this is to use NO_IDLE and NO_RESET flags in
the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
2. A bug in drivers/tty/serial/omap-serial.c where the
missing context loss count can cause NULL context to be
initialized during driver probe causing port to hang for
earlycon. The fix for that is what Felipe has suggested or
fix it in the driver by removing the context loss count usage
and detect the need for context restore based on the UART
state.
Or am I still missing something?
No, thats pretty much the 2 issues we have.
regards,
Rajendra
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
On 07/11/2013 06:35 PM, Nishanth Menon wrote: right - now that we removed the set_voltage/get_voltage custom code, there are no longer any way the code introduced in the commit can be exercised. If we boot with DT (which is the case with OMAP4/5) this part was not even executed, so the custom callbacks were not added from here for OMAP4. I might be wrong here... -- Péter -- To unsubscribe from this list: send the line unsubscribe 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/6] ARM: OMAP2+: Remove board-4430sdp.c
On 07/09/2013 10:23 AM, Tony Lindgren wrote: ASoC looks dead too: omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517 Peter, I think you've had audio working with devicetree for at least a year or something? Yes it has been working and going to work soon again: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-July/063909.html With the DMA devicetree bindings platform_get_resource_byname() stopped working for DMA (it works for MEM resources) - dai drivers were not probing. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
Stefan, On 07/11/2013 08:52 PM, Stefan Roese wrote: On 07/11/2013 05:34 PM, Stefan Roese wrote: On 07/11/2013 04:35 PM, Roger Quadros wrote: BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify. Do you have any patches locally applied to the kernel.org version that might be helpful with this USB issue I'm seeing? Yes I had tested it on a more recent kernel with some local patches applied that I've recently sent for review. But to cross check with your setup I've retested it with commit d2b4a646 with the 2 below patches on top https://lkml.org/lkml/2013/6/20/327 https://lkml.org/lkml/2013/6/20/339 Thanks. I have exactly those 2 patches applies as well. But on a different git commit. And with some local (unrelated) patches as well. I'll revert to exactly your version tomorrow and test again. Okay. I changed to exactly this version: d2b4a646 with those 2 patches on top. I've tried it again with the ELDK 5.3 root but still can't get it to fail. I think we should match our u-boot as well. Could you please let me know your u-boot commit and uEnv.txt? Good idea. I'm currently using a dirty local version. I'll try to switch to an officially available version tomorrow. And send you the version/git id. I updated my U-Boot to the following version: Based on mainline git commit ID 225fd8c. Only this patch added: http://patchwork.ozlabs.org/patch/256702/ This is needed for USB to work in U-Boot. Otherwise my external USB SMSC95xx will not be detected in U-Boot. I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip as I don't have an external USB-ethernet adapter. The above commit doesn't work well for beagle-xm, so my u-boot is on tag v2013.04 and you don't need that additional patch. Can you please retest on it? Thanks. You will need to set usbethaddr before starting USB else SMSC will not work. e.g. setenv usbethaddr A6:66:4D:B0:69:04 Also could you please increase the Linux console message verbosity to debug (8), so that all kernel messages are visible in the log? If it spits out something more than what you sent last time then do send it to me. Let's first sort out the beagle-xm problem, then we can see about old beagle. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
* Rajendra Nayak rna...@ti.com [130712 02:06]:
On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
OK, so that's only for earlyprintk then?
yes,
If so, it seems the right fix is to set the NO_IDLE and NO_RESET
flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
in the Kconfig now.
ok makes sense. It seems like the static data in hwmod can be populated
based on these defines? something like
/* uart3 */
static struct omap_hwmod omap44xx_uart3_hwmod = {
.name = uart3,
.class = omap44xx_uart_hwmod_class,
.clkdm_name = l4_per_clkdm,
#ifdef CONFIG_DEBUG_OMAP4UART3
.flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
HWMOD_SWSUP_SIDLE_ACT,
#else
.flags = HWMOD_SWSUP_SIDLE_ACT,
#endif
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
And same way for others? That way the cmdline parsing can be done away
with even for the non-DT case.
Yes we can do it that way. How about add a common macro for it if
it's always the same? Then the .flags line would be just:
#define HWMOD_OMAP_UART_FLAGS(soc, port)
...
.flags = HWMOD_OMAP_UART_FLAGS(4, 3),
The current code in mach-omap2/serial.c is wrong, and is a hack
needed for the pdata based booting. What's broken is that
omap_serial_early_init() parses the cmdline for console, which
itself is pretty nasty, and it won't work the right way as
there's nothing stopping from having the earlycon in a different
UART from the serial console. So we just want to get rid of the
whole mach-omap2/serial.c once we're all DT.
So to summarize, we have two bugs:
1. Omap hwmod code can reset UART while earlycon may be using
it. The fix to this is to use NO_IDLE and NO_RESET flags in
the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
2. A bug in drivers/tty/serial/omap-serial.c where the
missing context loss count can cause NULL context to be
initialized during driver probe causing port to hang for
earlycon. The fix for that is what Felipe has suggested or
fix it in the driver by removing the context loss count usage
and detect the need for context restore based on the UART
state.
Or am I still missing something?
No, thats pretty much the 2 issues we have.
OK thanks good to hear it's limited to earlycon issues.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
On Friday 12 July 2013 02:48 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130712 02:06]:
On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
OK, so that's only for earlyprintk then?
yes,
If so, it seems the right fix is to set the NO_IDLE and NO_RESET
flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
in the Kconfig now.
ok makes sense. It seems like the static data in hwmod can be populated
based on these defines? something like
/* uart3 */
static struct omap_hwmod omap44xx_uart3_hwmod = {
.name = uart3,
.class = omap44xx_uart_hwmod_class,
.clkdm_name = l4_per_clkdm,
#ifdef CONFIG_DEBUG_OMAP4UART3
.flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
HWMOD_SWSUP_SIDLE_ACT,
#else
.flags = HWMOD_SWSUP_SIDLE_ACT,
#endif
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
And same way for others? That way the cmdline parsing can be done away
with even for the non-DT case.
Yes we can do it that way. How about add a common macro for it if
it's always the same? Then the .flags line would be just:
#define HWMOD_OMAP_UART_FLAGS(soc, port)
...
.flags = HWMOD_OMAP_UART_FLAGS(4, 3),
Right, that seems much cleaner. I will send a patch out for it and get rid
of all the cmdline parsing in serial.c
regards
Rajendra
The current code in mach-omap2/serial.c is wrong, and is a hack
needed for the pdata based booting. What's broken is that
omap_serial_early_init() parses the cmdline for console, which
itself is pretty nasty, and it won't work the right way as
there's nothing stopping from having the earlycon in a different
UART from the serial console. So we just want to get rid of the
whole mach-omap2/serial.c once we're all DT.
So to summarize, we have two bugs:
1. Omap hwmod code can reset UART while earlycon may be using
it. The fix to this is to use NO_IDLE and NO_RESET flags in
the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
2. A bug in drivers/tty/serial/omap-serial.c where the
missing context loss count can cause NULL context to be
initialized during driver probe causing port to hang for
earlycon. The fix for that is what Felipe has suggested or
fix it in the driver by removing the context loss count usage
and detect the need for context restore based on the UART
state.
Or am I still missing something?
No, thats pretty much the 2 issues we have.
OK thanks good to hear it's limited to earlycon issues.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
On 07/11/2013 05:45 PM, Peter Ujfalusi wrote: We could get rid of all the #ifdef from the code that way. OMAP3 is the only platform that still depends on this - Further, with this change, Yep, I can do that. I'll send a separate patch to do this. Now that I have looked at this: we might need to wait a bit and clean up other files first: if we compile twl-common only if OMAP3 is selected, a build for OMAP4/5 only will break due to missing symbol in pm.c (omap_pmic_late_init is missing). I could add another set of #ifdef there, but it defeats the point IMHO. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
* Rajendra Nayak rna...@ti.com [130712 02:29]: Right, that seems much cleaner. I will send a patch out for it and get rid of all the cmdline parsing in serial.c Oh that's right, then it should not be needed for legacy pdata based booting either :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Thu, Jul 11, 2013 at 03:54:34PM -0400, Santosh Shilimkar wrote:
On Thursday 11 July 2013 03:43 PM, Ивайло Димитров wrote:
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3()
which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Сряда, 2013, Юли 10 20:45:26 EEST
On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Rohár wrote:
Other secure functions omap_smc1() and omap_smc2() calling instruction
smc #0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/omap-secure.h |1 +
arch/arm/mach-omap2/omap-smc.S| 22 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S
b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..5c02b8d 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* 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
@@ -54,6 +56,24 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r12, lr}
You don't need to save/restore r12. The ABI allows it to be clobbered
across function calls.
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb
+ dmb
dsb synchronises a superset of what dmb synchronises, so the dmb here is
not useful.
In any case, any code calling this must flush the region addressed by
r3 beforehand anyway, which will include a dsb as part of its semantics
-- this is how you call it from rx51_secure_dispatcher().
So I think the dsb may not be needed here (?)
Cheers
---Dave
Could be, but I wonder why almost all the kernel code(I am aware of) that
uses SMC and is written by TI, is storing r12 and is using both DSB and
DMB. See arch/arm/mach-omap2/sleep34xx.S or arch/arm/mach-omap2/omap-smc.S
for examples. I'd rather play it safe and leave it that way, unless someone
confirms the other code using SMC has extra DSB/DMB instructions too. I
wouldn't risk passing invalid/stale data to the Secure Monitor to just save
8 bytes and barriers in a performance non-critical code which will be
called only a couple of times during the boot-up process. r12 save/restore
is a legacy from omap_smc2 in omap-smc.S, so I guess it can go away without
much of a trouble.
Dave pointed out about the dsb and r12 to me in another thread. R12 can be
easily removed
but the DSB's were needed on OMAP for power sequencing. Without those, we
have seen
many issues. So you can leave the dsb's to be consistent with rest of the
code.
Consistency is a perfectly good reason, especially in code like this
where a certain code sequence has been proven, but it's preferable to
include brief comments to explain nonetheless.
Difficulty in explaining precisely why something is needed should be a
warning flag that a comment is needed.
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
Hi Stephen,
On Thursday 11 July 2013 11:40:37 Stephen Warren wrote:
On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++---
Documentation/devicetree/bindings/pwm/pwm-samsung.txt | 5 +++--
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 5 +++--
Documentation/devicetree/bindings/pwm/pwm.txt | 8 +---
Documentation/devicetree/bindings/pwm/vt8500-pwm.txt| 5 +++--
arch/arm/boot/dts/am335x-evm.dts| 3 ++-
arch/arm/boot/dts/am335x-evmsk.dts | 3 ++-
arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++-
include/dt-bindings/pwm/pwm.h | 15
include/linux/pwm.h | 4 ++--
I think this needs to be separate patches; at least the new pwm.h should
be introduced separately to the board-specific *.dts edits, and perhaps
further split up?
What about splitting it in three patches that
- add the include/dt-bindings/pwm/pwm.h header, and update include/linux/pwm.h
and Documentation/devicetree/bindings/pwm/pwm.txt
- update the rest of the documentation
- update the .dts files
That way, the one patch that introduces dt-bindings/pwm.h would be
available to be merged into any other tree that wanted to take patches
to use the new defines.
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
enum pwm_polarity {
- PWM_POLARITY_NORMAL,
- PWM_POLARITY_INVERSED,
+ PWM_POLARITY_NORMAL = 0,
+ PWM_POLARITY_INVERSED = 1,
};
Rather than manually editing that to ensure the enum matches the DT bindings
header, the whole point of making a separate dt-bindings/... directory was
that drivers could include the binding header files directly to avoid having
to duplicate the constant definitions. Can't linux/pwm.h include dt-
bindings/pwm.h and remove that enum?
We could do that, but we would then need to modify all drivers to replace
enum_pwm_polarity with unsigned int. Thierry, what's your opinion on this ?
Replying to a comment from another e-mail, I know that the above change to
include/linux/pwm.h is not strictly needed as the enum values are already
correct. The point of specifying the enum values explicitly was to hint that
the values matter and should not be changed. A comment in the source would
probably be more appropriate though.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
Hi Thierry,
On Thursday 11 July 2013 08:36:00 Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
[...]
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index
de0eaed..be09be4 100644
--- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
@@ -4,9 +4,9 @@ Required properties:
- compatible: should be atmel,tcb-pwm
- #pwm-cells: Should be 3. The first cell specifies the per-chip index
of the PWM to use, the second cell is the period in nanoseconds and
- bit 0 in the third cell is used to encode the polarity of PWM output.
- Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity
- set to 0 for normal polarity.
+ the third cell is used to encode the polarity of PWM output. Set the
+ PWM_POLARITY_NORMAL flag for normal polarity or the
PWM_POLARITY_INVERSED
+ flag for inverted polarity. PWM flags are defined in dt-
bindings/pwm/pwm.h.
- tc-block: The Timer Counter block to use as a PWM chip.
Example:
I'd prefer for the original text to stay in place and the reference to the
dt-bindings/pwm/pwm.h file to go below that block. The reason is that
perhaps somebody will look at an older version of a given DT (with the
numerical value) and not have access to the include and therefore not know
which flag was being set by just looking at the documentation. I'm also not
sure about what the plans are with respect to shipping device trees in a
separate repository and if they are, whether that repository would ship the
includes as well.
Another issue might be that people without access to recent versions of
DTC won't be able to use the new #include feature, so keeping the
documentation backwards compatible seems like a good idea.
Perhaps the include file should even only be mentioned in the general
PWM binding documentation.
Perhaps Grant and Rob (Cc'ed) can comment on how they want to handle
this.
I'll comment on this in a reply to Stephen.
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt index
ac67c68..bece18b 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -24,8 +24,9 @@ Required properties:
- phandle to PWM controller node
- index of PWM channel (from 0 to 4)
- PWM signal period in nanoseconds
- - bitmask of optional PWM flags:
-0x1 - invert PWM signal
+ - bitmask of optional PWM flags as defined in
dt-bindings/pwm/pwm.h: +PWM_POLARITY_NORMAL - normal polarity
+ PWM_POLARITY_INVERSED - inverted polarity
This part mixes spaces and tabs for indentation. Please stick to spaces.
OK.
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt
b/Documentation/devicetree/bindings/pwm/pwm.txt index 06e6724..38c357a
100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -43,13 +43,15 @@ because the name backlight would be used as fallback
anyway.
pwm-specifier typically encodes the chip-relative PWM number and the PWM
period in nanoseconds.
-Optionally, the pwm-specifier can encode a number of flags in a third
cell:
-- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
+Optionally, the pwm-specifier can encode a number of flags (defined in
+dt-bindings/gpio/gpio.h) in a third cell:
+- PWM_POLARITY_NORMAL: use the normal PWM signal polarity
+- PWM_POLARITY_INVERSED: invert the PWM signal polarity
You'd have a hard time finding those in the GPIO header. =)
Oops :-)
Will fix.
diff --git a/include/dt-bindings/pwm/pwm.h b/include/dt-bindings/pwm/pwm.h
new file mode 100644
index 000..f82be30
--- /dev/null
+++ b/include/dt-bindings/pwm/pwm.h
@@ -0,0 +1,15 @@
+/*
+ * This header provides constants for most PWM bindings.
+ *
+ * Most PWM bindings can include a flags cell as part of the PWM
specifier.
+ * In most cases, the format of the flags cell uses the standard values
+ * defined in this header.
+ */
+
+#ifndef _DT_BINDINGS_PWM_PWM_H
+#define _DT_BINDINGS_PWM_PWM_H
+
+#define PWM_POLARITY_NORMAL(0 0)
+#define PWM_POLARITY_INVERSED (1 0)
+
+#endif
I think this should go into a patch separate from the DT changes above
because they'll likely go in via different trees. Or maybe they won't,
but it'd still be good to introduce the header first and only then
change the DTS files.
I'll fix that as well. Please see my reply to Stephen for details.
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
[...]
enum pwm_polarity {
- PWM_POLARITY_NORMAL,
- PWM_POLARITY_INVERSED,
+
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
Roger, On 07/12/2013 11:15 AM, Roger Quadros wrote: Good idea. I'm currently using a dirty local version. I'll try to switch to an officially available version tomorrow. And send you the version/git id. I updated my U-Boot to the following version: Based on mainline git commit ID 225fd8c. Only this patch added: http://patchwork.ozlabs.org/patch/256702/ This is needed for USB to work in U-Boot. Otherwise my external USB SMSC95xx will not be detected in U-Boot. I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip as I don't have an external USB-ethernet adapter. Too bad. This difference in boards makes the tests a bit less meaningful. Is there really no USB-ethernet adapter somewhere in your department (perhaps a non-SMSC95xx might serve as well?)? I might send/order you one if necessary. ;) The above commit doesn't work well for beagle-xm, Why is this? What does happen? Does U-Boot not boot up to the prompt? Please send me a log. so my u-boot is on tag v2013.04 and you don't need that additional patch. Can you please retest on it? Thanks. Done, please see below. You will need to set usbethaddr before starting USB else SMSC will not work. e.g. setenv usbethaddr A6:66:4D:B0:69:04 I don't have a beagle-xm, only my beable. And my U-Boot network setup is already working, thanks. Also could you please increase the Linux console message verbosity to debug (8), so that all kernel messages are visible in the log? If it spits out something more than what you sent last time then do send it to me. I added ignore_loglevel to the cmdline. But I cannot see anything interesting that has not been there before with debug as well. Let's first sort out the beagle-xm problem, then we can see about old beagle. Okay, I tested again with U-Boot v2013.01 plus my SMSC patch. Same problem. NFS booting/mounting hangs at some time. Thanks, Stefan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
Hi, On Thursday 11 July 2013 14:06:44 Stephen Warren wrote: On 07/11/2013 01:32 PM, Thierry Reding wrote: On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote: On 07/11/2013 09:36 AM, Thierry Reding wrote: On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote: [...] diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index de0eaed..be09be4 100644 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -4,9 +4,9 @@ Required properties: - compatible: should be atmel,tcb-pwm - #pwm-cells: Should be 3. The first cell specifies the per-chip index of the PWM to use, the second cell is the period in nanoseconds and - bit 0 in the third cell is used to encode the polarity of PWM output. - Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity - set to 0 for normal polarity. + the third cell is used to encode the polarity of PWM output. Set the + PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED + flag for inverted polarity. PWM flags are defined in dt-bindings/pwm/pwm.h. - tc-block: The Timer Counter block to use as a PWM chip. Example: I'd prefer for the original text to stay in place and the reference to the dt-bindings/pwm/pwm.h file to go below that block. I disagree here. The whole point of creating header files for the constants in binding definitions was so that you wouldn't have to duplicate all the values into the binding definitions. Rather, you'd simply say see dt-bindings/xxx.h. But that's not something that this patch solves. Well, if the comments I made on the patch re: that linux/pwm.h should simply #include dt-bindings/pwm/pwm.h instead of duplicating the constants, then yet this patch will solve that. There will be a single place where the constants are defined. As explained in another reply, this would require replacing the enum with an unsigned int. I can write a patch if we agree on this. And it could be solved even in the absence of the header file defining the symbolic constants. If all the standard flags that dt-bindings/pwm/pwm.txt now specifies were to be listed in pwm.txt (they actually are) then referring to that document as the canonical source works equally well. If that's all the happens, then there will still be duplication between pwm.txt and linux/pwm.h. I've explicitly mentioned the flags in individual DT bindings to ease adding new flags in the future. At the moment the defined flags are either all supported or not used at all by drivers. If we later add a new flag supported by a subset of drivers only the driver bindings should list supported flags for each driver. I'm fine with removing the explicit mentions of individual flags right now and adding it back when needed if you think that's better. If we can take both of the above for granted, then sure, let's refer to the header from within the generic pwm.txt file and add a reference to that in bindings for drivers that use the standard flags. Another issue might be that people without access to recent versions of DTC won't be able to use the new #include feature, so keeping the documentation backwards compatible seems like a good idea. The dtc source tree is duplicated into the kernel source tree, so that isn't an issue for now. Besides, the dtc version is an entirely unrelated issue to how the documentation is written. Well, not really. If the documentation specifies the binding in a way that the DTC can't handle that's still a problem. People will end up with a DTS that their DTC can't compile. I guess that can be resolved by adding a note to the upstream device tree repository about the minimum required version of DTC. Yes, the separate repository would obviously require a version of dtc that's able to compile the files there; i.e. a version equivalent to what's already in the kernel tree (upstream 1.4.0 specifically). Again, right now, all of the binding docs, the *.dts files, and the dtc required to use them are part of the kernel; a single package, so there's no scope for issues re: using dtc features that aren't supported. If those components get separated later, obviously there will be a requirement to install a specific version of dtc to use with the separated *.dts and binding files. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] serial: omap: fix wrong context restoration on init
Since commit a630fbf serial: omap: Fix device tree based PM runtime
the OMAP serial driver will always try to restore its context in
serial_omap_runtime_resume(). But the problem is that during driver
initialization the UART context is not ready yet and, as result, first
call to pm_runtime_get*() will cause UART register overwriting by all
zeros. This causes Kernel boot hang in case if earlyprintk feature is
enabled at least [1].
Unfortunately, there is no exact place in driver now where we can
determine that UART context is ready - most of registers configured in
serial_omap_set_termios(), but some of them in other places.
More over, even if PM runtime will be disabled (blocked) during OMAP
serial driver probe() execution [2],[3] it will fix only console UART,
but context of other UARTs will be overwriting by all zeros during first
access to the corresponding UART.
To fix this issue:
- introduce additional initialized flag and update PM runtime callback
to do nothing if its not set. Set initialized at the end of probe().
- read current UART registers configuration in probe and use it by
default.
[1] http://www.spinics.net/lists/arm-kernel/msg256828.html
[2] http://www.spinics.net/lists/arm-kernel/msg258062.html
[3] http://www.spinics.net/lists/arm-kernel/msg258040.html
CC: Tony Lindgren t...@atomide.com
CC: Rajendra Nayak rna...@ti.com
CC: Felipe Balbi ba...@ti.com
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
tested on OMAP4 SDP with and without earlyprintk enabled.
drivers/tty/serial/omap-serial.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f39bf0c..e1e9667 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -162,6 +162,7 @@ struct uart_omap_port {
struct work_struct qos_work;
struct pinctrl *pins;
boolis_suspending;
+ boolinitialized;
};
#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
@@ -1395,6 +1396,19 @@ static struct omap_uart_port_info
*of_get_uart_port_info(struct device *dev)
return omap_up_info;
}
+static void serial_omap_save_context_def(struct uart_omap_port *up)
+{
+ up-dll = serial_in(up, UART_DLL);
+ up-dlh = serial_in(up, UART_DLM);
+ up-ier = serial_in(up, UART_IER);
+ up-fcr = serial_in(up, UART_FCR);
+ up-mcr = serial_in(up, UART_MCR);
+ up-scr = serial_in(up, UART_OMAP_SCR);
+ up-efr = serial_in(up, UART_EFR);
+ up-lcr = serial_in(up, UART_LCR);
+ up-mdr1 = serial_in(up, UART_OMAP_MDR1);
+}
+
static int serial_omap_probe(struct platform_device *pdev)
{
struct uart_omap_port *up;
@@ -1518,10 +1532,14 @@ static int serial_omap_probe(struct platform_device
*pdev)
ui[up-port.line] = up;
serial_omap_add_console_port(up);
+ serial_omap_save_context_def(up);
+
ret = uart_add_one_port(serial_omap_reg, up-port);
if (ret != 0)
goto err_add_port;
+ up-initialized = true;
+
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
return 0;
@@ -1619,6 +1637,9 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;
+ if (!up-initialized)
+ return 0;
+
/*
* When using 'no_console_suspend', the console UART must not be
* suspended. Since driver suspend is managed by runtime suspend,
@@ -1652,8 +1673,12 @@ static int serial_omap_runtime_suspend(struct device
*dev)
static int serial_omap_runtime_resume(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
+ int loss_cnt;
+
+ if (!up-initialized)
+ return 0;
- int loss_cnt = serial_omap_get_context_loss_count(up);
+ loss_cnt = serial_omap_get_context_loss_count(up);
if (loss_cnt 0) {
dev_dbg(dev, serial_omap_get_context_loss_count failed : %d\n,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] serial: omap: enable PM runtime only when its fully configured
If earlyprintk is enabled and current UART is console port the platform code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and avoid resuming of already active device, but now, driver initialization will be performed in the wrong way: pm_runtime_enable(pdev-dev); -- PM runtime alowed (device state RPM_ACTIVE) if (omap_up_info-autosuspend_timeout == 0) omap_up_info-autosuspend_timeout = -1; device_init_wakeup(up-dev, true); pm_runtime_use_autosuspend(pdev-dev); -- update_autosuspend() will be called and it will disable device (device state RPM_SUSPENDED) pm_runtime_set_autosuspend_delay(pdev-dev, omap_up_info-autosuspend_timeout); -- update_autosuspend() will be called which will re-enable device (device state RPM_ACTIVE), because autosuspend_timeout 0 pm_runtime_irq_safe(pdev-dev); pm_runtime_get_sync(pdev-dev); -- will do nothing Such behavior isn't expected by OMAP serial drivers and causes unpredictable calls of serial_omap_runtime_suspend() and serial_omap_runtime_resume(). Hence, fix it by allowing PM runtime only after all its parameters are configured. CC: Tony Lindgren t...@atomide.com CC: Rajendra Nayak rna...@ti.com CC: Felipe Balbi ba...@ti.com CC: Kevin Hilman khil...@linaro.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- tested on OMAP4 SDP with and without earlyprintk enabled. drivers/tty/serial/omap-serial.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index b6d1728..f39bf0c 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1501,7 +1501,6 @@ static int serial_omap_probe(struct platform_device *pdev) INIT_WORK(up-qos_work, serial_omap_uart_qos_work); platform_set_drvdata(pdev, up); - pm_runtime_enable(pdev-dev); if (omap_up_info-autosuspend_timeout == 0) omap_up_info-autosuspend_timeout = -1; device_init_wakeup(up-dev, true); @@ -1510,6 +1509,8 @@ static int serial_omap_probe(struct platform_device *pdev) omap_up_info-autosuspend_timeout); pm_runtime_irq_safe(pdev-dev); + pm_runtime_enable(pdev-dev); + pm_runtime_get_sync(pdev-dev); omap_serial_fill_features_erratas(up); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap5: dts: fix reg property size
USB3 block has a 64KiB space, another 64KiB is
used for the wrapper.
Without this change, resource_size() will get
confused and driver won't probe because size
will be negative.
Signed-off-by: Felipe Balbi ba...@ti.com
---
does anybody know Benoit's knew email address ?
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..5c99f19 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -637,7 +637,7 @@
omap_dwc3@4a02 {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss;
- reg = 0x4a02 0x1000;
+ reg = 0x4a02 0x1;
interrupts = GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH;
#address-cells = 1;
#size-cells = 1;
@@ -645,7 +645,7 @@
ranges;
dwc3@4a03 {
compatible = synopsys,dwc3;
- reg = 0x4a03 0x1000;
+ reg = 0x4a03 0x1;
interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
usb-phy = usb2_phy, usb3_phy;
tx-fifo-resize;
--
1.8.2.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: [PATCH] arm: omap2plus: unidle devices which are about to probe
On 07/11/2013 01:16 PM, Felipe Balbi wrote:
in order to make HWMOD and pm_runtime agree on the
initial state of the device, we will unidle the device
and call pm_runtime_set_active() to tell pm_runtime
that the device is really active.
By the time driver's probe() is reached, a call to
pm_runtime_get_sync() will not cause driver's
-runtime_resume() method to be called at first, only
after a successful -runtime_suspend().
Note that we must prevent pm_runtime transitions while
driver is probing otherwise drivers would be suspended
as soon as they call pm_runtime_use_autosuspend(). By
calling pm_runtime_forbid() before probe() and
pm_runtime_allow() after probe() we 'fix' that detail.
Note that this patch was inspired by PCI's pci_pm_init().
NAK. This is a hack.
In addition to what I've mentioned in
http://www.spinics.net/lists/arm-kernel/msg258061.html there are
following issues:
1) this patch disables call to PM runtime callbacks for all
OMAP drivers which is wrong - I've found, for example, that
omap-usb-host.c driver enables TLL in some configurations in its
.runtime_resume():
usbhs_runtime_resume()
|-omap_tll_enable()
2) even with this fix the restore context issue will not be fixed for
*non* console UARTs. Just try:
#echo 0xDEAD dev/ttyO3 // checked on OMAP4 SDP
3) I've checked most of OMAP drivers and all of them solve such kind of
problem internally (SPI, MMC, I2C, etc.)
4) See inline
Signed-off-by: Felipe Balbi ba...@ti.com
---
boot tested on top of today's Linus master
6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
panda. Reached console prompt and, after setting a
proper autosuspend delay, consoles autosuspend just
fine.
It needs to be tested on other platforms.
ps: note that we also call pm_runtime_set_suspended(dev)
from our late_initcall() to disable devices so that pm_runtime
and HWMOD continue to aggree on device's state.
arch/arm/mach-omap2/omap_device.c | 44 +++
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..cb1fc1d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -178,6 +178,26 @@ odbfd_exit:
return ret;
}
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+ omap_device_enable(pdev);
+ pm_runtime_forbid(pdev-dev);
It's wrong to use pm_runtime_forbid() - pm_runtime_get_noresume() should
be used instead.
pm_runtime_forbid()
|-rpm_resume()
+ pm_runtime_set_active(pdev-dev);
+ device_enable_async_suspend(pdev-dev);
why did you use device_enable_async_suspend() - it would enable async
suspend for devices - this is not related to the current issue and topic
for discussion (currently is used by usb/scsi/pci/ata drivers only).
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+ pm_runtime_allow(pdev-dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+ device_disable_async_suspend(pdev-dev);
+ pm_runtime_set_suspended(pdev-dev);
+ omap_device_idle(pdev);
+}
+
static int _omap_device_notifier_call(struct notifier_block *nb,
unsigned long event, void *dev)
{
@@ -189,16 +209,31 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
if (pdev-archdata.od)
omap_device_delete(pdev-archdata.od);
break;
+ case BUS_NOTIFY_BIND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_init(pdev);
+ break;
+ case BUS_NOTIFY_BOUND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_allow(pdev);
+ break;
+ case BUS_NOTIFY_UNBOUND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_exit(pdev);
+ break;
case BUS_NOTIFY_ADD_DEVICE:
if (pdev-dev.of_node)
omap_device_build_from_dt(pdev);
- /* fall through */
+ break;
default:
- od = to_omap_device(pdev);
- if (od)
- od-_driver_status = event;
+ /* nothing */
+ break;
}
+ od = to_omap_device(pdev);
+ if (od)
+ od-_driver_status = event;
+
return NOTIFY_DONE;
}
@@ -855,6 +890,7 @@ static int __init omap_device_late_idle(struct device *dev,
void *data)
dev_warn(dev, %s: enabled but no driver. Idling\n,
__func__);
omap_device_idle(pdev);
+ pm_runtime_set_suspended(dev);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH] arm: omap2plus: unidle devices which are about to probe
On Fri, Jul 12, 2013 at 02:58:17PM +0300, Grygorii Strashko wrote:
On 07/11/2013 01:16 PM, Felipe Balbi wrote:
in order to make HWMOD and pm_runtime agree on the
initial state of the device, we will unidle the device
and call pm_runtime_set_active() to tell pm_runtime
that the device is really active.
By the time driver's probe() is reached, a call to
pm_runtime_get_sync() will not cause driver's
-runtime_resume() method to be called at first, only
after a successful -runtime_suspend().
Note that we must prevent pm_runtime transitions while
driver is probing otherwise drivers would be suspended
as soon as they call pm_runtime_use_autosuspend(). By
calling pm_runtime_forbid() before probe() and
pm_runtime_allow() after probe() we 'fix' that detail.
Note that this patch was inspired by PCI's pci_pm_init().
NAK. This is a hack.
hack is your flag to check if the driver is initialized. pff
In addition to what I've mentioned in
http://www.spinics.net/lists/arm-kernel/msg258061.html there are
following issues:
1) this patch disables call to PM runtime callbacks for all
no, it does not. It forbids pm runtime transitions during probe.
OMAP drivers which is wrong - I've found, for example, that
omap-usb-host.c driver enables TLL in some configurations in its
.runtime_resume():
usbhs_runtime_resume()
|-omap_tll_enable()
which is wrong. PM runtime callbacks are supposed to be use for,
surprise, PM!
2) even with this fix the restore context issue will not be fixed for
*non* console UARTs. Just try:
#echo 0xDEAD dev/ttyO3 // checked on OMAP4 SDP
that I have not checked, but then again, with that you're not calling
set_termios() anyway.
3) I've checked most of OMAP drivers and all of them solve such kind
of problem internally (SPI, MMC, I2C, etc.)
and you see no problem with that ? Repeating the same thing over and
over again ?
4) See inline
Signed-off-by: Felipe Balbi ba...@ti.com
---
boot tested on top of today's Linus master
6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
panda. Reached console prompt and, after setting a
proper autosuspend delay, consoles autosuspend just
fine.
It needs to be tested on other platforms.
ps: note that we also call pm_runtime_set_suspended(dev)
from our late_initcall() to disable devices so that pm_runtime
and HWMOD continue to aggree on device's state.
arch/arm/mach-omap2/omap_device.c | 44
+++
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..cb1fc1d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -178,6 +178,26 @@ odbfd_exit:
return ret;
}
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+omap_device_enable(pdev);
+pm_runtime_forbid(pdev-dev);
It's wrong to use pm_runtime_forbid() - pm_runtime_get_noresume()
should be used instead.
how come ? What makes you think pm_runtime_get_noresume() is the right
thing here ?
pm_runtime_forbid()
|-rpm_resume()
so what ? flags is zero.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/2] serial: omap: fix wrong context restoration on init
hi,
On Fri, Jul 12, 2013 at 02:55:42PM +0300, Grygorii Strashko wrote:
Since commit a630fbf serial: omap: Fix device tree based PM runtime
the OMAP serial driver will always try to restore its context in
serial_omap_runtime_resume(). But the problem is that during driver
initialization the UART context is not ready yet and, as result, first
call to pm_runtime_get*() will cause UART register overwriting by all
zeros. This causes Kernel boot hang in case if earlyprintk feature is
enabled at least [1].
Unfortunately, there is no exact place in driver now where we can
determine that UART context is ready - most of registers configured in
serial_omap_set_termios(), but some of them in other places.
More over, even if PM runtime will be disabled (blocked) during OMAP
serial driver probe() execution [2],[3] it will fix only console UART,
but context of other UARTs will be overwriting by all zeros during first
access to the corresponding UART.
To fix this issue:
- introduce additional initialized flag and update PM runtime callback
to do nothing if its not set. Set initialized at the end of probe().
- read current UART registers configuration in probe and use it by
default.
[1] http://www.spinics.net/lists/arm-kernel/msg256828.html
[2] http://www.spinics.net/lists/arm-kernel/msg258062.html
[3] http://www.spinics.net/lists/arm-kernel/msg258040.html
CC: Tony Lindgren t...@atomide.com
CC: Rajendra Nayak rna...@ti.com
CC: Felipe Balbi ba...@ti.com
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
tested on OMAP4 SDP with and without earlyprintk enabled.
drivers/tty/serial/omap-serial.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index f39bf0c..e1e9667 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -162,6 +162,7 @@ struct uart_omap_port {
struct work_struct qos_work;
struct pinctrl *pins;
boolis_suspending;
+ boolinitialized;
you really think adding this sort of bool flag is the best thing we can
do ? Something which will, quite likely, spread through every single
driver ?
oh well...
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
On Friday 12 July 2013 02:48 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130712 02:06]:
On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
OK, so that's only for earlyprintk then?
yes,
If so, it seems the right fix is to set the NO_IDLE and NO_RESET
flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
in the Kconfig now.
ok makes sense. It seems like the static data in hwmod can be populated
based on these defines? something like
/* uart3 */
static struct omap_hwmod omap44xx_uart3_hwmod = {
.name = uart3,
.class = omap44xx_uart_hwmod_class,
.clkdm_name = l4_per_clkdm,
#ifdef CONFIG_DEBUG_OMAP4UART3
.flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
HWMOD_SWSUP_SIDLE_ACT,
#else
.flags = HWMOD_SWSUP_SIDLE_ACT,
#endif
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
And same way for others? That way the cmdline parsing can be done away
with even for the non-DT case.
Yes we can do it that way. How about add a common macro for it if
it's always the same? Then the .flags line would be just:
#define HWMOD_OMAP_UART_FLAGS(soc, port)
...
.flags = HWMOD_OMAP_UART_FLAGS(4, 3),
I started doing this and ended up with equal number of #ifdefs in the
header :( Was the intention of doing this to reduce the #ifdefs? in which
case maybe I am doing something wrong.
The current code in mach-omap2/serial.c is wrong, and is a hack
needed for the pdata based booting. What's broken is that
omap_serial_early_init() parses the cmdline for console, which
itself is pretty nasty, and it won't work the right way as
there's nothing stopping from having the earlycon in a different
UART from the serial console. So we just want to get rid of the
whole mach-omap2/serial.c once we're all DT.
So to summarize, we have two bugs:
1. Omap hwmod code can reset UART while earlycon may be using
it. The fix to this is to use NO_IDLE and NO_RESET flags in
the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
2. A bug in drivers/tty/serial/omap-serial.c where the
missing context loss count can cause NULL context to be
initialized during driver probe causing port to hang for
earlycon. The fix for that is what Felipe has suggested or
fix it in the driver by removing the context loss count usage
and detect the need for context restore based on the UART
state.
Or am I still missing something?
No, thats pretty much the 2 issues we have.
OK thanks good to hear it's limited to earlycon issues.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2plus: unidle devices which are about to probe
On Friday 12 July 2013 05:40 PM, Felipe Balbi wrote: 3) I've checked most of OMAP drivers and all of them solve such kind of problem internally (SPI, MMC, I2C, etc.) and you see no problem with that ? Repeating the same thing over and over again ? I agree with Felipe that this is best handled at the bus/omap-device level to avoid all drivers having to repeat the same thing over. Having said that I dont know whats the best way to do this for OMAP and the patch we have currently does seem to have atleast issues handling processor IPs as Suman mentioned. regards, Rajendra -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
* Rajendra Nayak rna...@ti.com [130712 05:18]:
On Friday 12 July 2013 02:48 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130712 02:06]:
On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
OK, so that's only for earlyprintk then?
yes,
If so, it seems the right fix is to set the NO_IDLE and NO_RESET
flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
in the Kconfig now.
ok makes sense. It seems like the static data in hwmod can be populated
based on these defines? something like
/* uart3 */
static struct omap_hwmod omap44xx_uart3_hwmod = {
.name = uart3,
.class = omap44xx_uart_hwmod_class,
.clkdm_name = l4_per_clkdm,
#ifdef CONFIG_DEBUG_OMAP4UART3
.flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
HWMOD_SWSUP_SIDLE_ACT,
#else
.flags = HWMOD_SWSUP_SIDLE_ACT,
#endif
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
.clkctrl_offs =
OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
.context_offs =
OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
And same way for others? That way the cmdline parsing can be done away
with even for the non-DT case.
Yes we can do it that way. How about add a common macro for it if
it's always the same? Then the .flags line would be just:
#define HWMOD_OMAP_UART_FLAGS(soc, port)
...
.flags = HWMOD_OMAP_UART_FLAGS(4, 3),
I started doing this and ended up with equal number of #ifdefs in the
header :( Was the intention of doing this to reduce the #ifdefs? in which
case maybe I am doing something wrong.
Hmm can't you use ## for substition in the macro to reduce the ifdefs
and have just one macro instead one for every debug port?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap5: dts: fix reg property size
On Friday 12 July 2013 05:28 PM, Felipe Balbi wrote: USB3 block has a 64KiB space, another 64KiB is used for the wrapper. Without this change, resource_size() will get confused and driver won't probe because size will be negative. Signed-off-by: Felipe Balbi ba...@ti.com --- does anybody know Benoit's knew email address ? benoit.cous...@linaro.org -Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap5: dts: fix reg property size
+ Benoit
On Fri, Jul 12, 2013 at 02:58:05PM +0300, Felipe Balbi wrote:
USB3 block has a 64KiB space, another 64KiB is
used for the wrapper.
Without this change, resource_size() will get
confused and driver won't probe because size
will be negative.
Signed-off-by: Felipe Balbi ba...@ti.com
---
does anybody know Benoit's knew email address ?
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..5c99f19 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -637,7 +637,7 @@
omap_dwc3@4a02 {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss;
- reg = 0x4a02 0x1000;
+ reg = 0x4a02 0x1;
interrupts = GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH;
#address-cells = 1;
#size-cells = 1;
@@ -645,7 +645,7 @@
ranges;
dwc3@4a03 {
compatible = synopsys,dwc3;
- reg = 0x4a03 0x1000;
+ reg = 0x4a03 0x1;
interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
usb-phy = usb2_phy, usb3_phy;
tx-fifo-resize;
--
1.8.2.1
--
balbi
signature.asc
Description: Digital signature
[PATCH v1 0/2] PM / AVS: interrupt handling fixes
Hi Kevin, Could you please take a look to the following patch series. It consists of two patches, which are needed for proper SmartReflex Interrupt handling. Based on Linux v3.10. Verified on OMAP4430. Thank you in advance. Regards, Andrii Nishanth Menon (2): PM / AVS: SmartReflex: fix interrupt disable sequence PM / AVS: SmartReflex: disable spamming interrupts drivers/power/avs/smartreflex.c | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 2/2] PM / AVS: SmartReflex: disable spamming interrupts
From: Nishanth Menon n...@ti.com
At times with bad SR configurations, especially during silicon bring-ups,
we could get continuous spurious interrupts which end up hanging the
platform in the form of an ISR call for status bits that are
automatically enabled by the hardware without any software clearing
option.
If we detect scenarios where ISR was called without the corresponding
notification bit being set, instead of hanging up the system,
we will disable interrupt after noting the event in the system log
to try and keep system sanity and allow developer to debug and fix
the condition.
The same condition applies when a notifier does not exist OR is unable
to handle the interrupt as well.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com
---
drivers/power/avs/smartreflex.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 5b2b703..185098f 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -120,8 +120,27 @@ static irqreturn_t sr_interrupt(int irq, void *data)
return IRQ_NONE;
}
- if (sr_class-notify)
- sr_class-notify(sr_info, status);
+ /* Attempt some resemblance of recovery! */
+ if (!status) {
+ dev_err(sr_info-pdev-dev,
+ %s: Spurious interrupt!status = 0x%08x.
+ Disabling to prevent spamming!!\n,
+ __func__, status);
+ disable_irq_nosync(sr_info-irq);
+ } else {
+ /*
+* If the notifier does not exist OR reports inability to
+* handle, disable as well
+*/
+ if (!sr_class-notify ||
+ sr_class-notify(sr_info, status)) {
+ dev_err(sr_info-pdev-dev,
+ %s: Callback cant handle int status=0x%08x.
+ Disabling to prevent spam!!\n,
+ __func__, status);
+ disable_irq_nosync(sr_info-irq);
+ }
+ }
return IRQ_HANDLED;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 1/2] PM / AVS: SmartReflex: fix interrupt disable sequence
From: Nishanth Menon n...@ti.com With the current interrupt disable sequence, we disable IRQENABLE followed by clearing of IRQSTATUS. With this sequence, we see, at times CORE domain does not hit OFF mode during cold boot because SR modules(Core/IVA/MPU domains) are stuck 'in transition'. This is due to IP Generic behavior around how swakeup is controlled towards PRCM. The right sequence we have is write to IRQSTATUS register to clear the interrupt, then write to IRQENABLE_CLR register to disable the interrupt to ensure that no pending interrupts exist in the system on disable of SmartReflex AVS block. Reported-by: Honda Kenji x0092...@ti.com Reported-by: Maki Tanaka m-tana...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com --- drivers/power/avs/smartreflex.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c index 6b2238b..5b2b703 100644 --- a/drivers/power/avs/smartreflex.c +++ b/drivers/power/avs/smartreflex.c @@ -295,12 +295,12 @@ static void sr_v2_disable(struct omap_sr *sr) else sr_modify_reg(sr, ERRCONFIG_V2, ERRCONFIG_VPBOUNDINTEN_V2, 0x0); - sr_write_reg(sr, IRQENABLE_CLR, (IRQENABLE_MCUACCUMINT | - IRQENABLE_MCUVALIDINT | - IRQENABLE_MCUBOUNDSINT)); sr_write_reg(sr, IRQSTATUS, (IRQSTATUS_MCUACCUMINT | IRQSTATUS_MCVALIDINT | IRQSTATUS_MCBOUNDSINT)); + sr_write_reg(sr, IRQENABLE_CLR, (IRQENABLE_MCUACCUMINT | + IRQENABLE_MCUVALIDINT | + IRQENABLE_MCUBOUNDSINT)); /* * Wait for SR to be disabled. @@ -315,8 +315,8 @@ static void sr_v2_disable(struct omap_sr *sr) __func__); /* Disable MCUDisableAcknowledge interrupt clear pending interrupt */ - sr_write_reg(sr, IRQENABLE_CLR, IRQENABLE_MCUDISABLEACKINT); sr_write_reg(sr, IRQSTATUS, IRQSTATUS_MCUDISABLEACKINT); + sr_write_reg(sr, IRQENABLE_CLR, IRQENABLE_MCUDISABLEACKINT); } static struct omap_sr_nvalue_table *sr_retrieve_nvalue_row( -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remove vlan tags in CPSW dual emac mode
On 23/04/13 18:29, Mugunthan V N wrote:
On 4/23/2013 9:48 PM, Markus Brunner wrote:
If operating in dual emac mode all packets sent by the CPSW contain vlan
headers with the reserved VID 0,
which gets stripped away by all somewhat recent Linux versions. Operating
systems without that behaviour will fail to communicate.
This patch fixes that behaviour by disabling the VLAN_AWARE mode as already
described by the comment above.
Signed-off-by: Markus Brunner systemprogrammierung.brun...@gmail.com
Tested-by: Mark Jackson m...@newflow.co.uk
---
--- linux-3.9-rc8.orig/drivers/net/ethernet/ti/cpsw.c2013-04-23
17:26:11.0 +0200
+++ linux-3.9-rc8/drivers/net/ethernet/ti/cpsw.c2013-04-23
17:36:25.0 +0200
@@ -751,9 +751,9 @@ static void cpsw_init_host_port(struct c
/* switch to vlan unaware mode */
cpsw_ale_control_set(priv-ale, priv-host_port, ALE_VLAN_AWARE,
CPSW_ALE_VLAN_AWARE);
control_reg = readl(priv-regs-control);
-control_reg |= CPSW_VLAN_AWARE;
+control_reg = ~CPSW_VLAN_AWARE;
writel(control_reg, priv-regs-control);
fifo_mode = (priv-data.dual_emac) ? CPSW_FIFO_DUAL_MAC_MODE :
CPSW_FIFO_NORMAL_MODE;
writel(fifo_mode, priv-host_port_regs-tx_in_ctl);
Disabling VLAN aware mode will enable switching mode and the feature of
separating the two down stream port is lost with this patch
Please check TRM for more info in *14.3.2.10.2 Dual Mac Mode* chapter
Just to update this (old) thread ...
I can still confirm that *without* the above patch, I am *unable* to use both
network
ports on our AM335x board.
My .dts file contains:-
mac: ethernet@4a10 {
dual_emac = 1;
cpsw_emac0: slave@4a100200 {
dual_emac_res_vlan = 1;
};
cpsw_emac1: slave@4a100300 {
dual_emac_res_vlan = 2;
};
};
cpsw_emac0 {
phy_id = davinci_mdio, 0;
};
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
My /etc/network/interfaces file is:-
auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 10.0.101.3
netmask 255.255.0.0
gateway 10.0.0.1
iface eth1 inet static
address 10.1.101.3
netmask 255.255.0.0
So I'm not sure what's wrong, but it's *definitely* not correct.
Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
On 08/07/13 13:42, Mark Jackson wrote: On 18/01/13 05:14, Mugunthan V N wrote: On 1/18/2013 3:48 AM, Peter Korsgaard wrote: When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot mode in U-Boot), nothing updates the ethernet hwaddr specified for the CPSW slaves, causing the driver to use a random hwaddr, which is some times troublesome. The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes more sense to default to these rather than random ones. Add a fixup step which adds mac-address dt properties using the efuse addresses if the DTB didn't contain valid ones. Signed-off-by: Peter Korsgaard jac...@sunsite.dk This implementation looks fine. Acked-by: Mugunthan V N mugunthan...@ti.com Tested-by: Mark Jackson mpfj-l...@newflow.co.uk Is this ever going to be put into the mainline code ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
Hi Stephen,
On Thursday 11 July 2013 11:40:37 Stephen Warren wrote:
On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++---
Documentation/devicetree/bindings/pwm/pwm-samsung.txt | 5 +++--
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 5 +++--
Documentation/devicetree/bindings/pwm/pwm.txt | 8 +---
Documentation/devicetree/bindings/pwm/vt8500-pwm.txt| 5 +++--
arch/arm/boot/dts/am335x-evm.dts| 3 ++-
arch/arm/boot/dts/am335x-evmsk.dts | 3 ++-
arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++-
include/dt-bindings/pwm/pwm.h | 15
include/linux/pwm.h | 4 ++--
I think this needs to be separate patches; at least the new pwm.h should
be introduced separately to the board-specific *.dts edits, and perhaps
further split up?
What about splitting it in three patches that
- add the include/dt-bindings/pwm/pwm.h header, and update
include/linux/pwm.h
and Documentation/devicetree/bindings/pwm/pwm.txt
- update the rest of the documentation
- update the .dts files
I think that sounds reasonable.
That way, the one patch that introduces dt-bindings/pwm.h would be
available to be merged into any other tree that wanted to take patches
to use the new defines.
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
enum pwm_polarity {
- PWM_POLARITY_NORMAL,
- PWM_POLARITY_INVERSED,
+ PWM_POLARITY_NORMAL = 0,
+ PWM_POLARITY_INVERSED = 1,
};
Rather than manually editing that to ensure the enum matches the DT bindings
header, the whole point of making a separate dt-bindings/... directory was
that drivers could include the binding header files directly to avoid having
to duplicate the constant definitions. Can't linux/pwm.h include dt-
bindings/pwm.h and remove that enum?
We could do that, but we would then need to modify all drivers to replace
enum_pwm_polarity with unsigned int. Thierry, what's your opinion on this ?
Or perhaps we could keep the enums around, but force the values to match
the DT constants:
enum pwm_polarity {
PWM_POLARITY_NORMAL = PWM_POLARITY_NORMAL,
PWM_POLARITY_INVERTED = PWM_POLARITY_INVERTED,
};
(although obviously you'd need to avoid the enum and DT constants having
the same name).
Although this brings up one point: let's say we support ACPI/.. bindings
in the future. The enum possibly can't match the binding values from
every different kind of binding definition (DT, ACPI, ...) so perhaps
rather than changing the enum definition in linux/pwm.h, what we
should be doing is mapping between the different name-spaces in whatever
of_xlate function exists for the PWM flags cell. That would be more
flexible.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On 07/12/2013 05:01 AM, Laurent Pinchart wrote: Hi, On Thursday 11 July 2013 14:06:44 Stephen Warren wrote: On 07/11/2013 01:32 PM, Thierry Reding wrote: On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote: On 07/11/2013 09:36 AM, Thierry Reding wrote: On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote: [...] diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index de0eaed..be09be4 100644 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -4,9 +4,9 @@ Required properties: - compatible: should be atmel,tcb-pwm - #pwm-cells: Should be 3. The first cell specifies the per-chip index of the PWM to use, the second cell is the period in nanoseconds and - bit 0 in the third cell is used to encode the polarity of PWM output. - Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity - set to 0 for normal polarity. + the third cell is used to encode the polarity of PWM output. Set the + PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED + flag for inverted polarity. PWM flags are defined in dt-bindings/pwm/pwm.h. - tc-block: The Timer Counter block to use as a PWM chip. Example: I'd prefer for the original text to stay in place and the reference to the dt-bindings/pwm/pwm.h file to go below that block. I disagree here. The whole point of creating header files for the constants in binding definitions was so that you wouldn't have to duplicate all the values into the binding definitions. Rather, you'd simply say see dt-bindings/xxx.h. But that's not something that this patch solves. Well, if the comments I made on the patch re: that linux/pwm.h should simply #include dt-bindings/pwm/pwm.h instead of duplicating the constants, then yet this patch will solve that. There will be a single place where the constants are defined. As explained in another reply, this would require replacing the enum with an unsigned int. I can write a patch if we agree on this. And it could be solved even in the absence of the header file defining the symbolic constants. If all the standard flags that dt-bindings/pwm/pwm.txt now specifies were to be listed in pwm.txt (they actually are) then referring to that document as the canonical source works equally well. If that's all the happens, then there will still be duplication between pwm.txt and linux/pwm.h. I've explicitly mentioned the flags in individual DT bindings to ease adding new flags in the future. At the moment the defined flags are either all supported or not used at all by drivers. If we later add a new flag supported by a subset of drivers only the driver bindings should list supported flags for each driver. I'm fine with removing the explicit mentions of individual flags right now and adding it back when needed if you think that's better. I think the values for any common system-wide flags should be defined once in some system-wide place, and the values for any HW-specific values should be defined only in the documentation for that specific HW. You could try and avoid conflicts by either: a) Allocating system-wide flags from bit 0 up, and HW-specific flags from bit 31 down. or: b) Using 1 cell for standard flags, and a separate cell for any HW-specific flags. Drivers can quite easily adapt to adding extra cells to #pwm-cells, thus making adding a HW-specific cell later backwards-compatible. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap5: hwmod: add missing ocp2scp hwmod data
From: Benoit Cousson benoit.cous...@linaro.org
without that hwmod data, USB3 will not in OMAP5 boards.
While at that, also fix DTS data to pass reg property,
otherwise driver won't probe.
Signed-off-by: Benoit Cousson benoit.cous...@linaro.org
Signed-off-by: Felipe Balbi ba...@ti.com
---
tested on OMAP5 uEVM. Gets rid of a data abort when USB3
is enabled. There still some other patches missing to get
USB3 working out of the box, but that's on Palmas and will
come as soon as I get those ready.
This is already on step forward.
arch/arm/boot/dts/omap5.dtsi | 3 +-
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index da41d70..a0de586 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -654,10 +654,11 @@
};
};
- ocp2scp {
+ ocp2scp@4a08 {
compatible = ti,omap-ocp2scp;
#address-cells = 1;
#size-cells = 1;
+ reg = 0x4a08 0x20;
ranges;
ti,hwmods = ocp2scp1;
usb2_phy: usb2phy@4a084000 {
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 2435109..d9118a1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1105,6 +1105,42 @@ static struct omap_hwmod omap54xx_mpu_hwmod = {
};
/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_ocp2scp_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_ocp2scp_hwmod_class = {
+ .name = ocp2scp,
+ .sysc = omap54xx_ocp2scp_sysc,
+};
+
+/* ocp2scp1 */
+static struct omap_hwmod omap54xx_ocp2scp1_hwmod = {
+ .name = ocp2scp1,
+ .class = omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP1_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
* 'timer' class
* general purpose timer module with accurate 1ms tick
* This class contains several variants: ['timer_1ms', 'timer']
@@ -1900,6 +1936,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mpu = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - ocp2scp1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp1 = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_ocp2scp1_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_wkup - timer1 */
static struct omap_hwmod_ocp_if omap54xx_l4_wkup__timer1 = {
.master = omap54xx_l4_wkup_hwmod,
@@ -2102,6 +2146,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
omap54xx_l4_per__mmc4,
omap54xx_l4_per__mmc5,
omap54xx_l4_cfg__mpu,
+ omap54xx_l4_cfg__ocp2scp1,
omap54xx_l4_wkup__timer1,
omap54xx_l4_per__timer2,
omap54xx_l4_per__timer3,
--
1.8.2.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: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
Hi Linus, On 07/10/2013 11:36 PM, Linus Walleij wrote: On Thu, Jun 27, 2013 at 4:01 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: I think, In the future the OMAP pinctrl configurations would be manged in more flexible way then now (thanks to pinctrl PM helpers and you;)) - Idle state will be splitted to Idle/sleep - default state will be splitted to default/active OK so the first ones we already have so the discussion is now down to adding the active state (and pinctrl_pm* helper function). I guess we need a patch set prepared which adds the active state and helper function as the first patch, i.e. this: http://marc.info/?l=linux-kernelm=137094012703340w=2 Can I have your ACK on this patch? I've verified combination of [PATCH] drivers: pinctrl: add active state to core [RFC] ARM: OMAP2+: omap_device: add pinctrl handling on OMAP4 SDP board+UARTs and going to send patches on Monday. So, Acked/Tested-by: Grygorii Strashko grygorii.stras...@ti.com (I can't reply directly to thread - not signed to those lists :)) What is the best branch to base my patches on? I do not want to add the state unless there is a clear consumer, so it needs to go in with the first patch to a device driver that uses pinctrl_pm_select_active_state() which will be a good demonstration on its use and utility. (And a point to object and suggest other ways to do the same thing...) Yours, Linus Walleij Regards, -grygorii -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap5: dts: add palmas-usb node
Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.
Signed-off-by: Felipe Balbi ba...@ti.com
---
after this, all we need is wait EXTCON merge
which contains the final changes necessary
to get USB3 working out of the box.
I'd suggest waiting on this patch until EXTCON
reaches mainline, just to make sure we don't
end up with DTS data for devices which don't
exist.
cheers
arch/arm/boot/dts/omap5-uevm.dts | 9 +
arch/arm/boot/dts/omap5.dtsi | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..7fe0e2b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -280,6 +280,11 @@
ti,ldo6-vibrator;
+ extcon_usb3: palmas_usb {
+ compatible = ti,palmas-usb;
+ ti,wakeup;
+ };
+
regulators {
smps123_reg: smps123 {
regulator-name = smps123;
@@ -450,6 +455,10 @@
phys = 0 hsusb2_phy hsusb3_phy;
};
+usb3 {
+ extcon = extcon_usb3;
+};
+
mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4e41409..1659246 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -634,7 +634,7 @@
ti,type = 2;
};
- omap_dwc3@4a02 {
+ usb3: omap_dwc3@4a02 {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss;
reg = 0x4a02 0x1;
--
1.8.2.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: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
Hi Stephen,
[...]
What about splitting it in three patches that
- add the include/dt-bindings/pwm/pwm.h header, and update
include/linux/pwm.h
and Documentation/devicetree/bindings/pwm/pwm.txt
- update the rest of the documentation
- update the .dts files
I think that sounds reasonable.
Shouldn't the addition of include/dt-bindings/pwm/pwm.h be separate from
its inclusion in include/linux/pwm.h so that it can be moved more easily
(cherry-picked) to a separate repository?
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
enum pwm_polarity {
- PWM_POLARITY_NORMAL,
- PWM_POLARITY_INVERSED,
+ PWM_POLARITY_NORMAL = 0,
+ PWM_POLARITY_INVERSED = 1,
};
Rather than manually editing that to ensure the enum matches the DT
bindings
header, the whole point of making a separate dt-bindings/... directory
was
that drivers could include the binding header files directly to avoid
having
to duplicate the constant definitions. Can't linux/pwm.h include dt-
bindings/pwm.h and remove that enum?
We could do that, but we would then need to modify all drivers to replace
enum_pwm_polarity with unsigned int. Thierry, what's your opinion on this ?
Or perhaps we could keep the enums around, but force the values to match
the DT constants:
enum pwm_polarity {
PWM_POLARITY_NORMAL = PWM_POLARITY_NORMAL,
PWM_POLARITY_INVERTED = PWM_POLARITY_INVERTED,
};
(although obviously you'd need to avoid the enum and DT constants having
the same name).
I think I've seen stuff like the following done in a few header files to
keep compatibility between enums and defines.
enum foo {
BAR,
#define BAR BAR
BAZ,
#define BAZ BAZ
};
Which, as I understand it, won't work in this case because DTC can only
cope with plain cpp files?
Although this brings up one point: let's say we support ACPI/.. bindings
in the future. The enum possibly can't match the binding values from
every different kind of binding definition (DT, ACPI, ...) so perhaps
rather than changing the enum definition in linux/pwm.h, what we
should be doing is mapping between the different name-spaces in whatever
of_xlate function exists for the PWM flags cell. That would be more
flexible.
I'm not quite sure what exactly you are suggesting here. Can you
elaborate?
Thierry
signature.asc
Description: Digital signature
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On 07/12/2013 11:24 AM, Thierry Reding wrote:
On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
Hi Stephen,
[...]
What about splitting it in three patches that
- add the include/dt-bindings/pwm/pwm.h header, and update
include/linux/pwm.h and
Documentation/devicetree/bindings/pwm/pwm.txt
- update the rest of the documentation
- update the .dts files
I think that sounds reasonable.
Shouldn't the addition of include/dt-bindings/pwm/pwm.h be separate
from its inclusion in include/linux/pwm.h so that it can be moved
more easily (cherry-picked) to a separate repository?
I'm fine with that being another separate patch. However, I doubt
cherry-picking is an issue here; when the separate DT repo is created,
it seems likely that someone will simply copy the latest files from
the latest Linux kernel in order to populate the tree. cherry-picking
probably won't work because:
a) I doubt that the DT binding/header additions have always been kept
separate from kernel code changes in all of Linux's history.
b) I wouldn't be remotely surprised if the layout of the new repo was
entirely different to the kernel source tree layout, so direct
cherry-pick wouldn't work.
c) Not having a common git history would make adding a kernel remote
into the DT repo rather odd.
(b) and (c) would at leat require some kind of git filter operation
rather than cherry-pick, and this issue could be solve in that filter
definition.
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
enum pwm_polarity {
- PWM_POLARITY_NORMAL, - PWM_POLARITY_INVERSED, +
PWM_POLARITY_NORMAL = 0, +PWM_POLARITY_INVERSED = 1,
};
Rather than manually editing that to ensure the enum matches
the DT bindings header, the whole point of making a separate
dt-bindings/... directory was that drivers could include
the binding header files directly to avoid having to
duplicate the constant definitions. Can't linux/pwm.h
include dt- bindings/pwm.h and remove that enum?
We could do that, but we would then need to modify all drivers
to replace enum_pwm_polarity with unsigned int. Thierry, what's
your opinion on this ?
Or perhaps we could keep the enums around, but force the values
to match the DT constants:
enum pwm_polarity { PWM_POLARITY_NORMAL = PWM_POLARITY_NORMAL,
PWM_POLARITY_INVERTED = PWM_POLARITY_INVERTED, };
(although obviously you'd need to avoid the enum and DT constants
having the same name).
I think I've seen stuff like the following done in a few header
files to keep compatibility between enums and defines.
enum foo { BAR, #define BAR BAR BAZ, #define BAZ BAZ };
Which, as I understand it, won't work in this case because DTC can
only cope with plain cpp files?
Yeah, dtc doesn't understand enum, so you can't include an enum
definition in a DT file. You have to share simple #define headers
between DT and kernel code.
Although this brings up one point: let's say we support ACPI/..
bindings in the future. The enum possibly can't match the binding
values from every different kind of binding definition (DT, ACPI,
...) so perhaps rather than changing the enum definition in
linux/pwm.h, what we should be doing is mapping between the
different name-spaces in whatever of_xlate function exists for
the PWM flags cell. That would be more flexible.
I'm not quite sure what exactly you are suggesting here. Can you
elaborate?
Suppose ACPI (or whatever else) starts representing PWM devices.
Suppose the author isn't aware that DT exists, represents PWM devices
and/or has already defined some PWM-related flags. So, ACPI picks bit
5 in some data value to represent inverted, rather than bit 0. Then,
there is no way that all of [ (a) DT binding PWM flags (b) ACPI PWM
flags (c) Linux's enum foo ] can use the same values. Hence, some
mapping is required between them.
The typical way to do this is to define an of_xlate function which
converts from DT cell values to Linux-internal representation.
Presumably if we added an ACPI parser, there'd be some equivalent for
that.
So, what I'm arguing for is that of_pwm_simple_xlate() (or any other
custom xlate function) should include both dt-bindings/pwm/pwm.h and
linux/pwm.h, and contain explicit code to convert between the two
name-spaces of flags definitions. Since those two name-spaces
currently are 100% identical, presumably if the code is written in the
right way, the compiler will actually just optimize it all away...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v3.11 merge window
On Wed, Jul 10, 2013 at 01:02:41AM -0700, Tony Lindgren wrote: The following changes since commit ddcf6600b133697adbafd96e080818bdc0dfd028: Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2013-07-03 19:56:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/fixes-for-merge-window Thanks, merged. There was a quite verbose merge conflict due to the changes of the Kconfig in our fixes branch, so please double-check my resolution. -Olof -- To unsubscribe from this list: send the line unsubscribe 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] remove vlan tags in CPSW dual emac mode
On 7/12/2013 7:27 PM, Mark Jackson wrote:
On 23/04/13 18:29, Mugunthan V N wrote:
On 4/23/2013 9:48 PM, Markus Brunner wrote:
If operating in dual emac mode all packets sent by the CPSW contain vlan
headers with the reserved VID 0,
which gets stripped away by all somewhat recent Linux versions. Operating
systems without that behaviour will fail to communicate.
This patch fixes that behaviour by disabling the VLAN_AWARE mode as already
described by the comment above.
Signed-off-by: Markus Brunner systemprogrammierung.brun...@gmail.com
Tested-by: Mark Jackson m...@newflow.co.uk
---
--- linux-3.9-rc8.orig/drivers/net/ethernet/ti/cpsw.c2013-04-23
17:26:11.0 +0200
+++ linux-3.9-rc8/drivers/net/ethernet/ti/cpsw.c2013-04-23
17:36:25.0 +0200
@@ -751,9 +751,9 @@ static void cpsw_init_host_port(struct c
/* switch to vlan unaware mode */
cpsw_ale_control_set(priv-ale, priv-host_port, ALE_VLAN_AWARE,
CPSW_ALE_VLAN_AWARE);
control_reg = readl(priv-regs-control);
-control_reg |= CPSW_VLAN_AWARE;
+control_reg = ~CPSW_VLAN_AWARE;
writel(control_reg, priv-regs-control);
fifo_mode = (priv-data.dual_emac) ? CPSW_FIFO_DUAL_MAC_MODE :
CPSW_FIFO_NORMAL_MODE;
writel(fifo_mode, priv-host_port_regs-tx_in_ctl);
Disabling VLAN aware mode will enable switching mode and the feature of
separating the two down stream port is lost with this patch
Please check TRM for more info in *14.3.2.10.2 Dual Mac Mode* chapter
Just to update this (old) thread ...
I can still confirm that *without* the above patch, I am *unable* to use both
network
ports on our AM335x board.
My .dts file contains:-
mac: ethernet@4a10 {
dual_emac = 1;
cpsw_emac0: slave@4a100200 {
dual_emac_res_vlan = 1;
};
cpsw_emac1: slave@4a100300 {
dual_emac_res_vlan = 2;
};
};
cpsw_emac0 {
phy_id = davinci_mdio, 0;
};
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
My /etc/network/interfaces file is:-
auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 10.0.101.3
netmask 255.255.0.0
gateway 10.0.0.1
iface eth1 inet static
address 10.1.101.3
netmask 255.255.0.0
So I'm not sure what's wrong, but it's *definitely* not correct.
I am sure that current code in mainline works for Dual EMAC. I can test it
again and share the images with you if are interested. But had tested with DHCP
on both the interfaces.
Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe 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] remove vlan tags in CPSW dual emac mode
On 12/07/13 19:35, Mugunthan V N wrote: On 7/12/2013 7:27 PM, Mark Jackson wrote: [snip] Just to update this (old) thread ... I can still confirm that *without* the above patch, I am *unable* to use both network ports on our AM335x board. [snip] So I'm not sure what's wrong, but it's *definitely* not correct. I am sure that current code in mainline works for Dual EMAC. I can test it again and share the images with you if are interested. But had tested with DHCP on both the interfaces. Hmmm ... well it's not working for me. What hardware are you testing it on ? I tried DHCP to start with, and switched to static IP when that failed. Then I recalled this patch and re-applied it ... hey presto !! Markus, are you still using this patch ? -- To unsubscribe from this list: send the line unsubscribe 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 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 07/12/2013 08:18 AM, Oleksandr Kozaruk wrote: The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Couple of things: 1) It looks from the driver that a lot of the channels are not measuring voltages but rather temperature or currents etc. If so then their types in the channel mask should be appropriately set. Also if some of the channels are entirely internal test networks, what is the benefit of exposing them to userspace as readable channels? If channels are merely 'suggested' as being used for temperatures etc then it is fine to keep them as voltages. 2) You have my sympathy when it comes to the way those trim values are packed into the registers. That is truely hideous ;) Various trivial little bits but all in all a nice clean driver. Thanks, Jonathan Signed-off-by: Balaji T K balaj...@ti.com Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com --- drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 3 files changed, 1028 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..87d699e 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -157,4 +157,12 @@ config VIPERBOARD_ADC Say yes here to access the ADC part of the Nano River Technologies Viperboard. +config TWL6030_GPADC + tristate TWL6030 GPADC (General Purpose A/D Convertor) Support + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030 General Purpose + A/D Convertor. Perhaps a little more detail for such a complex device? + endmenu diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..8b05633 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..6ceb789 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1019 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat nska...@ti.com + * Balaji T K balaj...@ti.com + * Graeme Gregory g...@slimlogic.co.uk + * Girish S Ghongdemath giris...@ti.com + * Ambresh K ambr...@ti.com + * Oleksandr Kozaruk oleksandr.koza...@ti.com + * + * Based on twl4030-madc.c + * Copyright (C) 2008 Nokia Corporation + * Mikko Ylinen mikko.k.yli...@nokia.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include linux/init.h +#include linux/interrupt.h +#include linux/kernel.h +#include linux/module.h +#include linux/platform_device.h +#include linux/of_platform.h +#include linux/i2c/twl.h +#include linux/iio/iio.h +#include linux/iio/sysfs.h + +#define DRIVER_NAME twl6030_gpadc + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define
Re: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
A couple of comments inline.
On 07/12/2013 09:18 AM, Oleksandr Kozaruk wrote:
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..87d699e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -157,4 +157,12 @@ config VIPERBOARD_ADC
Say yes here to access the ADC part of the Nano River
Technologies Viperboard.
+config TWL6030_GPADC
+ tristate TWL6030 GPADC (General Purpose A/D Convertor) Support
+ depends on TWL4030_CORE
+ default n
+ help
+ Say yes here if you want support for the TWL6030 General Purpose
+ A/D Convertor.
+
Keep it in alphabetical order
endmenu
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..8b05633 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
Same here.
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 000..6ceb789
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1019 @@
[...]
+static u8 twl6032_channel_to_reg(int channel)
+{
+ return TWL6032_GPADC_GPCH0_LSB;
There is more than one channel, isn't there?
[...]
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+ int ret = -EINVAL;
+
+ mutex_lock(gpadc-lock);
+
+ ret = gpadc-pdata-start_conversion(chan-channel);
+ if (ret) {
+ dev_err(gpadc-dev, failed to start conversion\n);
+ goto err;
+ }
+ /* wait for conversion to complete */
+ wait_for_completion_interruptible_timeout(gpadc-irq_complete,
+ msecs_to_jiffies(5000));
wait_for_completion_interruptible_timeout() can return either a negative error
code if it was interrupted, 0 if it timed out, or a positive value if it was
successfully completed. You need to handle all three cases. Have a look at
other existing drivers to see how to do this properly.
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = twl6030_gpadc_get_raw(gpadc, chan-channel, val);
+ ret = ret ? -EIO : IIO_VAL_INT;
+ break;
+
+ case IIO_CHAN_INFO_PROCESSED:
+ ret = twl6030_gpadc_get_processed(gpadc, chan-channel, val);
+ ret = ret ? -EIO : IIO_VAL_INT;
+ break;
+
+ default:
+ break;
+ }
+err:
+ mutex_unlock(gpadc-lock);
+
+ return ret;
+}
+}
+
[...]
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct twl6030_gpadc_data *gpadc;
+ const struct twl6030_gpadc_platform_data *pdata;
+ const struct of_device_id *match;
+ struct iio_dev *indio_dev;
+ int irq;
+ int ret = 0;
+
+ match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+ pdata = match ? match-data : dev-platform_data;
+
+ if (!pdata)
+ return -EINVAL;
+
+ indio_dev = iio_device_alloc(sizeof(struct twl6030_gpadc_data));
sizeof(*gpadc)
+ if (!indio_dev) {
+ dev_err(dev, failed allocating iio device\n);
+ ret = -ENOMEM;
+ }
+
+ gpadc = iio_priv(indio_dev);
+
+ gpadc-twl6030_cal_tbl = devm_kzalloc(dev,
+ sizeof(struct twl6030_chnl_calib) *
+ pdata-nchannels, GFP_KERNEL);
+ if (!gpadc-twl6030_cal_tbl)
+ goto err;
+
+ gpadc-dev = dev;
+ gpadc-pdata = pdata;
+
+ platform_set_drvdata(pdev, indio_dev);
+ mutex_init(gpadc-lock);
+ init_completion(gpadc-irq_complete);
+
+ ret = pdata-calibrate(gpadc);
+ if (ret 0) {
+ dev_err(pdev-dev, failed to read calibration registers\n);
+ goto err;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(pdev-dev, failed to get irq\n);
+ goto err;
+ }
+
+ ret = devm_request_threaded_irq(dev, irq, NULL,
+ twl6030_gpadc_irq_handler,
+ IRQF_ONESHOT, twl6030_gpadc, gpadc);
You access memory in the interrupt handler which is freed before the interrupt
handler is freed.
+ if (ret) {
+ dev_dbg(pdev-dev, could not request irq\n);
+ goto err;
+ }
+
+ ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+ if (ret 0) {
+ dev_err(pdev-dev, failed to enable GPADC interrupt\n);
+ goto err;
+
Re: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
Hi, On Sat, Jul 6, 2013 at 6:36 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: With that worked out, throwing my standard printascii() hack into the kernel results in boot messages... up to the point where the timer is calibrated. So, it looks like either interrupts, clocks, or the OMAP timers are non-functional with DT based kernels on the SDP board. Any ideas? I'm a bit late to the party due to travel and other things going on, but I have the exact same thing happening with multi_v7_defconfig on my Panda ES right now -- it gets stuck on calibrating delay loop. I needed to enable DEBUG_LL and early printk to not just get a dead system though. What happened in my case was that MACH_OMAP4 was no longer enabled so clocks weren't registered. I wonder if we can improve debugability of that somehow. Before Arnd's patch to flip the MACH_OMAP2PLUS option around, they got enabled by default I think. So now I needed: -CONFIG_ARCH_OMAP2PLUS=y +CONFIG_ARCH_OMAP3=y +CONFIG_ARCH_OMAP4=y CONFIG_SOC_OMAP5=y +CONFIG_SOC_AM33XX=y ...in the defconfig. This is pretty painful, and I don't know if we want to rethink Arnd's patch since it will break existing defconfigs out there that rely on OMAP2PLUS enabling the socs instead of the other way around. Opinions? -Olof -- To unsubscribe from this list: send the line unsubscribe 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/6] ARM: OMAP2+: Remove board-4430sdp.c
On Fri, Jul 12, 2013 at 7:31 PM, Olof Johansson o...@lixom.net wrote:
This is pretty painful, and I don't know if we want to rethink Arnd's
patch since it will break existing defconfigs out there that rely on
OMAP2PLUS enabling the socs instead of the other way around. Opinions?
(replying to myself, I know, I know...)
I think it's probably easiest to just select the OMAP{2,3,4} and
AM33XX options in multi_v7_defconfig just like Arnd did in the commit
that changed the dependencies for now. I've added a patch on top of
our current fixes branch to do so.
Note that you need to make corresponding changes to your seeds for
your build tests, Russell.
-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
