Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework
On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote: +menuconfig GENERIC_PHY + tristate PHY Subsystem + help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. Shouldn't this be something that other drivers select? How will anyone know if they need this or not? --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,544 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2013 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. You really mean any later version (I have to ask)? + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. Are these two paragraphs needed? This isn't a program, and they got a copy of the GPL already with the kernel. +static struct class *phy_class; Why do you need a class? When modifying/adding new sysfs stuff, you need a Documentation/ABI/ entry as well. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
* Grygorii Strashko grygorii.stras...@ti.com [130716 07:32]:
Hi Tony,
On 07/16/2013 04:41 PM, Tony Lindgren wrote:
* Grygorii Strashko grygorii.stras...@ti.com [130716 06:22]:
Hi Tony,
This patch causes boot failure when I've applied my patch
[RFC] ARM: OMAP2+: omap_device: add pinctrl handling
https://lkml.org/lkml/2013/6/21/309
on top of it:
Hmm this patch alone removes duplicate code and if it causes
issues I must have made a typo somewhere.
No typo :) You've removed the check for !dev-pins.
Oh OK, sorry that was not intentional.
And the failure place is:
int pinctrl_pm_select_active_state(struct device *dev)
{
return pinctrl_pm_select_state(dev, dev-pins-active_state);
here
}
If I understand everything right, the pinctrl support in Device core
assumed to be optional - so, It's valid case, when there are no
definition for device's pinctrl in DT at all.
And in this case dev-pins == NULL and pinctrl_pm_select_*() API
should return 0 always.
Care to post your patch as it sounds like you have it fixed
and tested?
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: Boot hang regression 3.10.0-rc4 - 3.10.0
On Tuesday 16 July 2013 03:57 PM, Grygorii Strashko wrote:
Hi Rajendra,
On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first pm_runtime_get*() done
during probe.
This is similar to what PCI bus does (if you look at pci_pm_init()).
I tried something similar [1] but what I found is that the serial
runtime resume was called despite it being marked as active using
pm_runtime_set_active().
That seems to be because of the pm_runtime_set_autosuspend_delay()
because we have the autosuspend_delay = -1
-
static void update_autosuspend(struct device *dev, int old_delay, int
old_use)
{
int delay = dev-power.autosuspend_delay;
/* Should runtime suspend be prevented now? */
if (dev-power.use_autosuspend delay 0) {
/* If it used to be allowed then prevent it. */
if (!old_use || old_delay = 0) {
atomic_inc(dev-power.usage_count);
rpm_resume(dev, 0);
--- calls serial runtime resume.
}
}
-
So we end up with the same issue with serial resume being called before
set_termios()
[1]
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..c71d47d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
struct device_node *node = pdev-dev.of_node;
const char *oh_name;
int oh_cnt, i, ret = 0;
+ bool device_active = false;
oh_cnt = of_property_count_strings(node, ti,hwmods);
if (oh_cnt = 0) {
@@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
goto odbfd_exit1;
}
hwmods[i] = oh;
+ if (oh-flags HWMOD_INIT_NO_IDLE)
+ device_active = true;
+
}
od = omap_device_alloc(pdev, hwmods, oh_cnt);
@@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
pdev-dev.pm_domain = omap_device_pm_domain;
+ if (device_active) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
odbfd_exit1:
kfree(hwmods);
odbfd_exit:
This solution works good for me in combination with
serial: omap: enable PM runtime only when its fully configured
http://www.spinics.net/lists/linux-serial/msg10317.html
(earlyprintk use case)
And I think the best way would be to move forward with yours solution.
- it will affect only on needed IPs drivers - not on all, so no issues with
iommu and etc.
Ok, good to know that this solution works. Anyone has any other thoughts on
whats the best
way to fix this for the -rcs? (Note that we have bootup broken on all OMAPs
with DEBUG_LL
for now, atleast for all DT only platforms)
The other option of course is to use the patch posted by Felipe [1], thought
that had issues
handling processor IPs as pointed out by Grygorii and Suman [2], the fix I
posted [3] to make
omap_device aware of hwmod bypassing these IPs might fix some of those, but
this solution in
general would need more testing as it affects all modules on the bus.
[1] http://www.spinics.net/lists/arm-kernel/msg258062.html
[2] http://www.spinics.net/lists/arm-kernel/msg258061.html
[3] http://www.spinics.net/lists/arm-kernel/msg258465.html
But issue with *non console UARTs will still be here and, I think,
there are no way ti solve it from OMAP device/hwmod frameworks side,
because only driver can know when his context is ready.
To test do: #echo 0xDEAD dev/ttyO3
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
Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework
Hi, On Wednesday 17 July 2013 11:59 AM, Greg KH wrote: On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote: +menuconfig GENERIC_PHY +tristate PHY Subsystem +help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. Shouldn't this be something that other drivers select? How will anyone know if they need this or not? All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those PHY drivers can be selected like in [1]. The PHY consumer driver should ideally use *depends on* in their Kconfig. [1] - http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,544 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2013 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. You really mean any later version (I have to ask)? That was copied from somewhere :-s + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. Are these two paragraphs needed? This isn't a program, and they got a copy of the GPL already with the kernel. hmm.. I can remove that. +static struct class *phy_class; Why do you need a class? Wanted to group all the PHY drivers to be used by different subsystems (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my initial version [3] on using a bus_type instead of class but then it was decided to go with class itself. [3] - http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html When modifying/adding new sysfs stuff, you need a Documentation/ABI/ entry as well. I'm not actually adding any new sysfs entry other than what a *class_create* must have created. Do I need to add one for that? Thanks 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 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hello Jonathan, Two very quick comments based on quick glance as it may be a while before I can do a full review. We still have channels that are only usable for temperature being output to user space as voltage channels? Is the conversion so very hard? Can you please clarify what should return temperature channel for in_tempX_input (processed)? Is it voltage or Celsius degree? in_tempX_raw should return ADC code? Right? Regards, OK. -- To unsubscribe from this list: send the line unsubscribe 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 0/2] regulator: palmas-pmic: doc: update device tree bindings
On Tue, Jul 16, 2013 at 11:41:08AM -0500, Nishanth Menon wrote: We seem to have a few missing updates to device tree bindings with the latest set of changes getting merged in. Applied both, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
Hi Stephen, On Monday 15 July 2013 21:39:31 Stephen Warren wrote: On 07/15/2013 07:10 PM, Laurent Pinchart wrote: On Friday 12 July 2013 08:42:41 Stephen Warren wrote: ... 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. I wasn't referring to HW-specific flags, but rather to system-wide flags that might not be supported by all drivers. If we later add new system-wide flags I think the individual DT bindings should explicitly document which flags they support. Shouldn't all system-wide flags be supported by all HW, perhaps being implemented by the core subsystem rather than individual drivers to ensure that? Consider the case of the GPIO active-low flag which is actually implemented in SW, hence can work with any GPIO controller. Perhaps that's not possible in all cases, in which case, yes, it does make sense to define which of the common flags a particular HW module supports. It largely depends on what we consider as system flags. We should probably be talking about common flags instead of system flags. I usually try to standardize DT properties that are common to multiple devices. Some of those properties can apply to all devices of the same class (possibly implemented/emulated in software when the hardware doesn't support them), but others are just commonly seen properties that don't make sense for all the devices. One example I'm familiar with can be found in V4L2 DT bindings. We've standardized properties to specify what kind of video synchronization signals devices support/use. Not all synchronization signals are supported by a given video transmitter, so DT bindings for such chips list (or at least should list) the common properties supported by a given device. The definitions of the properties should of course not be duplicated to all individual DT bindings. But then there's a problem where people assume that the common flags are always available, and somewhere they aren't... Care is needed in the choice of which common flags to define and/or how they're used. Exactly. That's why I think listing the supported common flags in individual bindings makes sense when some of the flags are not supported by all devices. As the only PWM flags currently used are common to all PWM devices I can leave this out now. I have no strong preference, I'll follow your opinion on this. -- 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 v5 0/2] TWL6030, TWL6032 GPADC driver
Hello, v5 - gpadc DT node renamed from gpadc to generic adc, added temperature channels; raw code is corracted with calibration data. v4 - addressed comments: fixed style violation, bug in freeing memory, added comments explaining calibration method, removed test network channels from exposing to userspace, error handling for wait_for_complition 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 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 | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1026 +++ 4 files changed, 1047 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 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. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K balaj...@ti.com Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1026 +++ 3 files changed, 1041 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..3172461 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -150,6 +150,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate TWL6030 GPADC (General Purpose A/D Converter) Support + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate Viperboard ADC support depends on MFD_VIPERBOARD USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..996ba09 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..97fad5b --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1026 @@ +/* + * 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 TWL6030_GPADC_CTRL_P1 0x05 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) + +#define TWL6030_GPADC_GPCH0_LSB(0x29) + +#define TWL6030_GPADC_RT_SW1_EOC_MASK
[PATCH v5 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..322aa8e 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;
};
+
+ adc: twl6030_gpadc {
+ compatible = ti,twl6030_gpadc;
+ interrupts = 3;
+ #io-channel-cells = 1;
+ };
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling
Hi Tony, Kevin This patch series introduces dynamic pinctrl handling in OMAP device framework in the same way as it was before switching to DT. This allow OMAP devices driver's developers to simply add dynamic pinctrl handling for default, active, idle, sleep PIN states in their drivers by modifying DT definitions only - no modifications in drivers code are not needed. Tested on OMAP4 SDP(Tablet2) board using omap4-sdp.dts - UART3/4 autoidle - suspend, by adding some fake sleep pin state - wake up (PRCM) IRQ generation by ading call to omap44xx_prm_reconfigure_io_chain() right after each call to pinctrl_pm_select_xx() API. UART3(console) reg dumps: - active 0x4A100140(RTS/CTS) - 0x0118 0x4A100140(TX/RX) - 0x0100 - idle 0x4A100140(RTS/CTS) - 0x0118 0x4A100144(TX/RX) - 0x4100 UART4 reg dumps: - active 0x4A10015C(TX/RX) - 0x0100 - idle 0x4A10015C(TX/RX) - 0x4100 Debugfs: # cat sys/kernel/debug/pinctrl/4a100040.pinmux/pinmux-pins [snip] pin 128 (4a100140.0): 4802.serial (GPIO UNCLAIMED) function pinmux_uart3_pins group pinmux_uart3_pins pin 129 (4a100142.0): 4802.serial (GPIO UNCLAIMED) function pinmux_uart3_pins group pinmux_uart3_pins pin 130 (4a100144.0): 4802.serial (GPIO UNCLAIMED) function pinmux_uart3_pins_active group pinmux_uart3_pins_active pin 131 (4a100146.0): 4802.serial (GPIO UNCLAIMED) function pinmux_uart3_pins group pinmux_uart3_pins [snip] pin 142 (4a10015c.0): 4806e000.serial (GPIO UNCLAIMED) function pinmux_uart4_pins_idle group pinmux_uart4_pins_idle pin 143 (4a10015e.0): 4806e000.serial (GPIO UNCLAIMED) function pinmux_uart4_pins group pinmux_uart4_pins Changes since RFC: - _od_resume_noirq() fixed - idle state was not selected on resume - description updated RFC: https://lkml.org/lkml/2013/6/21/309 Based on v3.11-rc1 plus patch series from Tony Lindgren [PATCH 0/4] improved support for runtime muxing for pinctrl http://www.spinics.net/lists/arm-kernel/msg258827.html: fd7937b drivers: Add pinctrl handling for dynamic pin states 479246b pinctrl: Add support for additional dynamic states c9f37e8 pinctrl: Allow pinctrl to have multiple active states 756f10b pinctrl: Remove duplicate code in pinctrl_pm_select_state functions ad81f05 Linux 3.11-rc1 Related discussions: - drivers: pinctrl sleep and idle states in the core http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html - [PATCH] drivers: pinctrl: add active state to core http://marc.info/?l=linux-kernelm=137094012703340w=2 - [PATCH] pinctrl: document the pinctrl PM states https://lkml.org/lkml/2013/6/11/501 - [3/3] i2c: nomadik: use pinctrl PM helpers https://patchwork.kernel.org/patch/2670291/ - mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime https://patchwork.kernel.org/patch/2690191/ - [PATCH 00/11] drivers: Add Pinctrl PM support https://lkml.org/lkml/2013/5/31/210 Grygorii Strashko (3): pinctrl: rollback check for !dev-pins in pinctrl_pm_select*() APIs ARM: OMAP2+: omap_device: add pinctrl handling ARM: dts: omap4-sdp: add dynamic pin states for uart3/4 arch/arm/boot/dts/omap4-sdp.dts | 34 +++ arch/arm/mach-omap2/omap_device.c | 40 +++-- drivers/pinctrl/core.c| 12 +++ 3 files changed, 76 insertions(+), 10 deletions(-) Regards, -grygorii CC: Linus Walleij linus.wall...@linaro.org CC: Stephen Warren swar...@wwwdotorg.org CC: Roger Quadros rog...@ti.com -- 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 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
Add dynamic active/idle pin states for uart3/4 which will be applied
when uart3/4 state is switched from active to idle and back by Runtime
PM or during system suspend.
CC: Benoit Cousson benoit.cous...@linaro.org
CC: Linus Walleij linus.wall...@linaro.org
CC: Stephen Warren swar...@wwwdotorg.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 34 ++
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..2624504 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -181,18 +181,40 @@
pinctrl-single,pins =
0x100 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart3_cts_rctx.uart3_cts_rctx */
0x102 (PIN_OUTPUT | MUX_MODE0) /*
uart3_rts_sd.uart3_rts_sd */
- 0x104 (PIN_INPUT | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
0x106 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx */
;
};
+ uart3_pins_active: pinmux_uart3_pins_active {
+ pinctrl-single,pins =
+ 0x104 (PIN_INPUT | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ ;
+ };
+
+ uart3_pins_idle: pinmux_uart3_pins_idle {
+ pinctrl-single,pins =
+ 0x104 (WAKEUP_EN | PIN_INPUT | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ ;
+ };
+
uart4_pins: pinmux_uart4_pins {
pinctrl-single,pins =
- 0x11c (PIN_INPUT | MUX_MODE0) /*
uart4_rx.uart4_rx */
0x11e (PIN_OUTPUT | MUX_MODE0) /*
uart4_tx.uart4_tx */
;
};
+ uart4_pins_active: pinmux_uart4_pins_active {
+ pinctrl-single,pins =
+ 0x11c (PIN_INPUT | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ ;
+ };
+
+ uart4_pins_idle: pinmux_uart4_pins_idle {
+ pinctrl-single,pins =
+ 0x11c (WAKEUP_EN | PIN_INPUT | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ ;
+ };
+
twl6030_pins: pinmux_twl6030_pins {
pinctrl-single,pins =
0x15e (WAKEUP_EN | PIN_INPUT_PULLUP | MUX_MODE0)
/* sys_nirq1.sys_nirq1 */
@@ -510,13 +532,17 @@
};
uart3 {
- pinctrl-names = default;
+ pinctrl-names = default, active, idle;
pinctrl-0 = uart3_pins;
+ pinctrl-1 = uart3_pins_active;
+ pinctrl-2 = uart3_pins_idle;
};
uart4 {
- pinctrl-names = default;
+ pinctrl-names = default, active, idle;
pinctrl-0 = uart4_pins;
+ pinctrl-1 = uart4_pins_active;
+ pinctrl-2 = uart4_pins_idle;
};
mcbsp3 {
--
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/3] pinctrl: rollback check for !dev-pins in pinctrl_pm_select*() APIs
The pinctrl support in Device core assumed to be optional - so, It's
valid case, when there are no definition for default device's pinctrl
states in DT at all (default, active, idle, sleep).
And in this case dev-pins == NULL and pinctrl_pm_select*() API
should return 0 always.
Now the checks for !dev-pins have been removed from
pinctrl_pm_select*() API mistakenly by the patch
pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
http://www.spinics.net/lists/arm-kernel/msg258829.html
Hence, rollback these checks in in pinctrl_pm_select*() APIs.
CC: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
Seems this one can be squashed in series
[PATCH 0/4] improved support for runtime muxing for pinctrl
http://www.spinics.net/lists/arm-kernel/msg258827.html
drivers/pinctrl/core.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 4f58a97..ace4eb8 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1390,6 +1390,9 @@ static int pinctrl_pm_select_state(struct device *dev,
struct pinctrl_state *sta
*/
int pinctrl_pm_select_default_state(struct device *dev)
{
+ if (!dev-pins)
+ return 0;
+
return pinctrl_pm_select_state(dev, dev-pins-default_state);
}
EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
@@ -1400,6 +1403,9 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
*/
int pinctrl_pm_select_active_state(struct device *dev)
{
+ if (!dev-pins)
+ return 0;
+
return pinctrl_pm_select_state(dev, dev-pins-active_state);
}
EXPORT_SYMBOL_GPL(pinctrl_pm_select_active_state);
@@ -1410,6 +1416,9 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_active_state);
*/
int pinctrl_pm_select_sleep_state(struct device *dev)
{
+ if (!dev-pins)
+ return 0;
+
return pinctrl_pm_select_state(dev, dev-pins-sleep_state);
}
EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
@@ -1420,6 +1429,9 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
*/
int pinctrl_pm_select_idle_state(struct device *dev)
{
+ if (!dev-pins)
+ return 0;
+
return pinctrl_pm_select_state(dev, dev-pins-idle_state);
}
EXPORT_SYMBOL_GPL(pinctrl_pm_select_idle_state);
--
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 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod framework. After switching to DT-boot the pinctrl handling was dropped from hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html) But this is not right for OMAP2+ SoC where real IPs state is controlled by omap_device core which enables/disables modules clocks actually. For example, if OMAP I2C driver will handle pinctrl state during system wide suspend the following issue may occure: - suspend_noirq - I2C device can be still active because of PM auto-suspend |-_od_suspend_noirq |- omap_i2c_suspend_noirq |- PINs state set to SLEEP |- pm_generic_runtime_suspend |- omap_i2c_runtime_suspend() |- PINs state set to IDLE --- *oops* PINs state is IDLE and not SLEEP |- omap_device_idle() |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) - resume_noirq - I2C was active before suspend |-_od_resume_noirq |- omap_hwmod_enable() |- _enable() |- enable module (syscclocks) |- pm_generic_runtime_resume |- omap_i2c_runtime_resume() |- PINs state set to DEFAULT --- |- omap_i2c_resume_noirq |- PINs state set to DEFAULT |- PINs state set to IDLE --- *big oops* we have active module and its PINs state is IDLE (see https://patchwork.kernel.org/patch/2642101/) Of course, everything can be handled by adding a tons of code in ecah driver to check PM state of device and override default behavior of omap_device core, but this not good. Hence, add pinctrl handling in omap_device core as shown below: + | | .probe() | +-v+ | | | default | | | ++--+--+ | | pm_runtime_get()| | pm_runtime_put() ++ ++ || +--v--+ pm_runtime_put()+---v-+ | +- | +--- Active |pm_runtime_get() | Idle --+ | | -+ | | | +---+-+ +---+-+ | | |.suspend_noirq() |.suspend_noirq()| | | || | | || | | || | | || | +---v-+ +---v-+ | | | | | | | +---+ Sleep --+ | Sleep +--+ .resume_noirq() | | | | |.resume_noirq() +---|-+ | +-+ | Idle | +---+ 1) on PM runtime resume - switch pinctrl state to active 2) on PM runtime suspend - switch pinctrl state to idle 3) during system wide suspend - switch pinctrl state to sleep or idle if omap_device core disables device - switch pinctrl state to sleep if device has been disabled already 4) during system wide resume - switch pinctrl state to active if omap_device core has disabled device during suspend - switch pinctrl state to idle if device was already disabled before suspend This will enable pinctrl for all OMAP2+ IP's drivers by default - no changes in code is needed and only DT data will need to be updated (add default, active, idle, sleep states). Related discussions: - [3/3] i2c: nomadik: use pinctrl PM helpers https://patchwork.kernel.org/patch/2670291/ - mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime https://patchwork.kernel.org/patch/2690191/ - [PATCH 00/11] drivers: Add Pinctrl PM support https://lkml.org/lkml/2013/5/31/210 CC: Linus Walleij linus.wall...@linaro.org Cc: Stephen Warren swar...@wwwdotorg.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- arch/arm/mach-omap2/omap_device.c | 40 +++-- 1 file changed, 34 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/omap_device.c
Re: [PATCH 0/4] improved support for runtime muxing for pinctrl
Hi Tony, On 07/16/2013 12:05 PM, Tony Lindgren wrote: Hi all, As discussed earlier, the pinctrl support for changing some of the consumer device pins during runtime needs some improvment. Here are the patches to do that, I'll also post a minimal sample patch as a reply to this thread on how to do the muxing for runtime PM. I've posted my patch and tested this patch series. Seems everything is ok (except patch pinctrl: Remove duplicate code in pinctrl_pm_select_state functions). See http://www.spinics.net/lists/arm-kernel/msg259180.html So, Tested-By: Grygorii Strashko grygorii.stras...@ti.com Regards, Tony --- Tony Lindgren (4): pinctrl: Remove duplicate code in pinctrl_pm_select_state functions pinctrl: Allow pinctrl to have multiple active states pinctrl: Add support for additional dynamic states drivers: Add pinctrl handling for dynamic pin states drivers/base/pinctrl.c| 39 + drivers/pinctrl/core.c| 250 - drivers/pinctrl/core.h| 10 + include/linux/pinctrl/consumer.h | 46 ++ include/linux/pinctrl/devinfo.h |4 + include/linux/pinctrl/pinctrl-state.h | 15 ++ 6 files changed, 321 insertions(+), 43 deletions(-) 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
Re: [PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling
Hi Grygorii, On 07/17/2013 02:41 PM, Grygorii Strashko wrote: Hi Tony, Kevin This patch series introduces dynamic pinctrl handling in OMAP device framework in the same way as it was before switching to DT. This allow OMAP devices driver's developers to simply add dynamic pinctrl handling for default, active, idle, sleep PIN states in their drivers by modifying DT definitions only - no modifications in drivers code are not needed. Overall I like the idea but can we make a provision for device drivers to override this default pin state handling? The OMAP EHCI driver is one such special case where the wakeup mechanism is tied to pinctrl states as it uses IO daisy chaining to implement wakeup. So depending on whether wakeup needs to be enabled or not I must be able to chose whether I put the pin in just sleep state or sleep with wakeup state. 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 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling
On 07/17/2013 02:57 PM, Roger Quadros wrote: Hi Grygorii, On 07/17/2013 02:41 PM, Grygorii Strashko wrote: Hi Tony, Kevin This patch series introduces dynamic pinctrl handling in OMAP device framework in the same way as it was before switching to DT. This allow OMAP devices driver's developers to simply add dynamic pinctrl handling for default, active, idle, sleep PIN states in their drivers by modifying DT definitions only - no modifications in drivers code are not needed. Overall I like the idea but can we make a provision for device drivers to override this default pin state handling? The OMAP EHCI driver is one such special case where the wakeup mechanism is tied to pinctrl states as it uses IO daisy chaining to implement wakeup. So depending on whether wakeup needs to be enabled or not I must be able to chose whether I put the pin in just sleep state or sleep with wakeup state. I think, in this case you can't use default behavior and need to define custom pins states like sleep_wakeup/sleep_no_wakeup and do not define pins state with name sleep', so Device core and OMAP device framework will not touch your pins. cheers, -roger 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
Re: [PATCH v2] ARM: dts: add AM33XX MMC support
On 27/06/13 04:32, Joel Fernandes wrote: From: Matt Porter mpor...@ti.com Adds AM33XX MMC support for am335x-bone, am335x-evm, and am335x-evmsk. Also added is the DMA binding definitions based on the generic DMA request binding. The HWMOD data removal was breaking MMC so some new properties like reg, interrupt etc were added. Changes to DTS: Interrupt and reg added by: Joel Fernandes jo...@ti.com Compatible added by Balaji TK balaj...@ti.com ti,needs-special-hs-handling added by Gururaja Hebbar gururaja.heb...@ti.com Signed-off-by: Matt Porter mpor...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com --- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +- arch/arm/boot/dts/am335x-bone.dts |7 arch/arm/boot/dts/am335x-evm.dts |7 arch/arm/boot/dts/am335x-evmsk.dts |7 arch/arm/boot/dts/am33xx.dtsi | 38 5 files changed, 84 insertions(+), 1 deletion(-) Excuse my ignorance, but which git repository is this against ? -- To unsubscribe from this list: send the line unsubscribe 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 Mon, Jul 15, 2013 at 01:33:53PM +0200, Lars-Peter Clausen wrote:
On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote:
[...]
+ 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.
Thanks for pointing this. devm_* will free memory for irq after the
driver
is removed and memory for the device is freed. I took me awhile to
understand
this. Is there going to be something like devm_iio_device_alloc?
whould it be helpfull?
Yes, I think it certainly makes sense to add a
devm_iio_device_alloc(), care
to send a patch?
Anything like this? (of course it's not a patch)
struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
{
struct iio_dev *indio_dev;
size_t alloc_size;
alloc_size = sizeof(struct iio_dev);
if (sizeof_priv) {
alloc_size = ALIGN(alloc_size, IIO_ALIGN);
alloc_size += sizeof_priv;
}
/* ensure 32-byte alignment of whole construct ? */
alloc_size += IIO_ALIGN - 1;
indio_dev = devm_kzalloc(dev, alloc_size, GFP_KERNEL);
if (indio_dev) {
indio_dev-dev.groups = indio_dev-groups;
indio_dev-dev.type = iio_device_type;
indio_dev-dev.bus = iio_bus_type;
device_initialize(indio_dev-dev);
dev_set_drvdata(indio_dev-dev, (void *)indio_dev);
mutex_init(indio_dev-mlock);
mutex_init(indio_dev-info_exist_lock);
INIT_LIST_HEAD(indio_dev-channel_attr_list);
indio_dev-id = ida_simple_get(iio_ida, 0, 0, GFP_KERNEL);
if (indio_dev-id 0) {
/* cannot use a dev_err as the name isn't available */
printk(KERN_ERR Failed to get id\n);
kfree(dev);
return NULL;
}
dev_set_name(indio_dev-dev, iio:device%d, indio_dev-id);
INIT_LIST_HEAD(indio_dev-buffer_list);
}
return indio_dev;
}
EXPORT_SYMBOL(devm_iio_device_alloc);
Regards,
OK
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] ARM: dts: twl: Add GPADC data to device tree
Hello.
On 17-07-2013 15:12, Oleksandr Kozaruk wrote:
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..322aa8e 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;
};
+
+ adc: twl6030_gpadc {
I was talking about the device name, not label. The twl6030_gpadc part.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe 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 7/9] arm: dts: add omap4430 thermal data
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 4a4dcc3..27f0e0f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
* kind, whether express or implied.
*/
+#include dt-bindings/thermal/thermal.h
#include omap4.dtsi
/ {
@@ -27,8 +28,34 @@
};
bandgap {
- reg = 0x4a002260 0x4
- 0x4a00232C 0x4;
+ reg = 0x4a002260 0x4 0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+ thermal_zone {
+ type = CPU;
+ mask = 0x03; /* trips writability */
+ passive_delay = 250; /* milliseconds */
+ polling_delay = 1000; /* milliseconds */
+ governor = step_wise;
+ trips {
+ alert@10{
+ temperature = 10; /* milliCelsius
*/
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_PASSIVE;
+ };
+ crit@125000{
+ temperature = 125000; /* milliCelsius
*/
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+ bind_params {
+ action@0{
+ cooling_device = thermal-cpufreq;
+ weight = 100; /* percentage */
+ mask = 0x01;
+ /* no limits, using defaults */
+ };
+ };
+ };
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe 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 5/8] arm: dts: add omap4430 thermal data
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..c9a1c89 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
* kind, whether express or implied.
*/
+#include dt-bindings/thermal/thermal.h
#include omap4.dtsi
/ {
@@ -26,8 +27,34 @@
};
bandgap {
- reg = 0x4a002260 0x4
- 0x4a00232C 0x4;
+ reg = 0x4a002260 0x4 0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+ thermal_zone {
+ type = CPU;
+ mask = 0x03; /* trips writability */
+ passive_delay = 250; /* milliseconds */
+ polling_delay = 1000; /* milliseconds */
+ governor = step_wise;
+ trips {
+ alert@10{
+ temperature = 10; /* milliCelsius
*/
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_PASSIVE;
+ };
+ crit@125000{
+ temperature = 125000; /* milliCelsius
*/
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+ bind_params {
+ action@0{
+ cooling_device = thermal-cpufreq;
+ weight = 100; /* percentage */
+ mask = 0x01;
+ /* no limits, using defaults */
+ };
+ };
+ };
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe 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 6/8] arm: dts: flag omap4430 with needs-cooling for cpu node
OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the flag so that cpufreq-cpu0 driver loads the cooling device to use cpufreq on OMAP4430. Cc: Benoît Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/boot/dts/omap443x.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index c9a1c89..27f0e0f 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -23,6 +23,7 @@ 1008000 1375000 ; clock-latency = 30; /* From legacy driver */ + needs-cooling; /* make sure we have cpufreq-cooling */ }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] ARM: dts: twl: Add GPADC data to device tree
On 07/17/2013 04:33 PM, Sergei Shtylyov wrote:
Hello.
On 17-07-2013 15:12, Oleksandr Kozaruk wrote:
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..322aa8e 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;
};
+
+adc: twl6030_gpadc {
I was talking about the device name, not label. The twl6030_gpadc part.
The compatible property should also be: 'twl6030-gpadc' instead of
'twl6030_gpadc' and you need to add documentation for it.
- Lars
--
To unsubscribe from this list: send the line unsubscribe 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/17/2013 03:45 PM, Oleksandr Kozaruk wrote:
On Mon, Jul 15, 2013 at 01:33:53PM +0200, Lars-Peter Clausen wrote:
On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote:
[...]
+ 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.
Thanks for pointing this. devm_* will free memory for irq after the driver
is removed and memory for the device is freed. I took me awhile to
understand
this. Is there going to be something like devm_iio_device_alloc? whould
it be helpfull?
Yes, I think it certainly makes sense to add a devm_iio_device_alloc(), care
to send a patch?
Anything like this? (of course it's not a patch)
No. I think you can for example use devm_regulator_get() as a template. But
instead of regulator_get() and regulator_put() use iio_device_alloc() and
iio_device_free().
struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
{
struct iio_dev *indio_dev;
size_t alloc_size;
alloc_size = sizeof(struct iio_dev);
if (sizeof_priv) {
alloc_size = ALIGN(alloc_size, IIO_ALIGN);
alloc_size += sizeof_priv;
}
/* ensure 32-byte alignment of whole construct ? */
alloc_size += IIO_ALIGN - 1;
indio_dev = devm_kzalloc(dev, alloc_size, GFP_KERNEL);
if (indio_dev) {
indio_dev-dev.groups = indio_dev-groups;
indio_dev-dev.type = iio_device_type;
indio_dev-dev.bus = iio_bus_type;
device_initialize(indio_dev-dev);
dev_set_drvdata(indio_dev-dev, (void *)indio_dev);
mutex_init(indio_dev-mlock);
mutex_init(indio_dev-info_exist_lock);
INIT_LIST_HEAD(indio_dev-channel_attr_list);
indio_dev-id = ida_simple_get(iio_ida, 0, 0, GFP_KERNEL);
if (indio_dev-id 0) {
/* cannot use a dev_err as the name isn't available */
printk(KERN_ERR Failed to get id\n);
kfree(dev);
return NULL;
}
dev_set_name(indio_dev-dev, iio:device%d, indio_dev-id);
INIT_LIST_HEAD(indio_dev-buffer_list);
}
return indio_dev;
}
EXPORT_SYMBOL(devm_iio_device_alloc);
Regards,
OK
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] arm: dts: flag omap4430 with needs-cooling for cpu node
OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the flag so that cpufreq-cpu0 driver loads the cooling device to use cpufreq on OMAP4430. Cc: Benoît Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/boot/dts/omap443x.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index bcf455e..4a4dcc3 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,7 @@ 1008000 1375000 ; clock-latency = 30; /* From legacy driver */ + needs-cooling; /* make sure we have cpufreq-cooling */ }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH V1 7/9] arm: dts: add omap4430 thermal data
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 4a4dcc3..27f0e0f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
* kind, whether express or implied.
*/
+#include dt-bindings/thermal/thermal.h
#include omap4.dtsi
/ {
@@ -27,8 +28,34 @@
};
bandgap {
- reg = 0x4a002260 0x4
- 0x4a00232C 0x4;
+ reg = 0x4a002260 0x4 0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+ thermal_zone {
+ type = CPU;
+ mask = 0x03; /* trips writability */
+ passive_delay = 250; /* milliseconds */
+ polling_delay = 1000; /* milliseconds */
+ governor = step_wise;
+ trips {
+ alert@10{
+ temperature = 10; /* milliCelsius
*/
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_PASSIVE;
+ };
+ crit@125000{
+ temperature = 125000; /* milliCelsius
*/
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+ bind_params {
+ action@0{
+ cooling_device = thermal-cpufreq;
+ weight = 100; /* percentage */
+ mask = 0x01;
+ /* no limits, using defaults */
+ };
+ };
+ };
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH V1 4/9] arm: dts: flag omap4430 with needs-cooling for cpu node
OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the flag so that cpufreq-cpu0 driver loads the cooling device to use cpufreq on OMAP4430. Cc: Benoît Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/boot/dts/omap443x.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index bcf455e..4a4dcc3 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,7 @@ 1008000 1375000 ; clock-latency = 30; /* From legacy driver */ + needs-cooling; /* make sure we have cpufreq-cooling */ }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Add dynamic active/idle pin states for uart3/4 which will be applied when uart3/4 state is switched from active to idle and back by Runtime PM or during system suspend. This is good for testing code, but should not be merged because omap4 has the iopad wake-ups available for uarts. So those can be always enabled. --- a/arch/arm/boot/dts/omap4-sdp.dts +++ b/arch/arm/boot/dts/omap4-sdp.dts @@ -181,18 +181,40 @@ pinctrl-single,pins = 0x100 (PIN_INPUT_PULLUP | MUX_MODE0)/* uart3_cts_rctx.uart3_cts_rctx */ 0x102 (PIN_OUTPUT | MUX_MODE0) /* uart3_rts_sd.uart3_rts_sd */ - 0x104 (PIN_INPUT | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ 0x106 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx */ ; }; This just need to become: pinctrl-single,pins = ... 0x104 (WAKEUP_EN | PIN_INPUT_MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ ... ; interrupts = GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH; }; And so on. For am33xx you need to remux things to GPIO for the wake-up events, so you should maybe test on that instead. 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 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod framework. After switching to DT-boot the pinctrl handling was dropped from hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html) But this is not right for OMAP2+ SoC where real IPs state is controlled by omap_device core which enables/disables modules clocks actually. I'm not convinced we should try to handle this in a generic way as only some devices need dynamic remuxing of some pins. For example, if OMAP I2C driver will handle pinctrl state during system wide suspend the following issue may occure: - suspend_noirq - I2C device can be still active because of PM auto-suspend |-_od_suspend_noirq |- omap_i2c_suspend_noirq |- PINs state set to SLEEP |- pm_generic_runtime_suspend |- omap_i2c_runtime_suspend() |- PINs state set to IDLE --- *oops* PINs state is IDLE and not SLEEP |- omap_device_idle() |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) And in this example you are assuming that you need separate idle and sleep states, which is not true at least for most cases I've seen. It is possible that am33xx needs separate idle and sleep states, but most likely only for some pins. For omap[345] we can get away with just the default state for most cases. 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/3] pinctrl: rollback check for !dev-pins in pinctrl_pm_select*() APIs
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: The pinctrl support in Device core assumed to be optional - so, It's valid case, when there are no definition for default device's pinctrl states in DT at all (default, active, idle, sleep). And in this case dev-pins == NULL and pinctrl_pm_select*() API should return 0 always. Now the checks for !dev-pins have been removed from pinctrl_pm_select*() API mistakenly by the patch pinctrl: Remove duplicate code in pinctrl_pm_select_state functions http://www.spinics.net/lists/arm-kernel/msg258829.html Hence, rollback these checks in in pinctrl_pm_select*() APIs. Thanks, it's best that I fold this fix into my patch as it has not been committed yet. 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
ARM: AM335x: Kernel oops when using EDMA and MMC
I'm trying to get the MMC port working on our custom AM3352 CPU board. I have added MMC entries to out dts file (similar to [1]), and I've enabled CONFIG_TI_EDMA. Our board boots fine without an SD card inserted ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj@mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013 ... [2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12. [2.797268] devtmpfs: mounted [2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000) ... Welcome to Buildroot nanobone login: But when I boot with a card already inserted, I get the following oops ... ... [1.827343] Unable to handle kernel NULL pointer dereference at virtual address 000c [1.835868] pgd = c0004000 [1.838774] [000c] *pgd= [1.842556] Internal error: Oops: 5 [#1] ARM [1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.11.0-rc1-00025-g95b9b72 #309 [1.855511] Workqueue: kmmcd mmc_rescan [1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000 [1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4 [1.870761] LR is at omap_hsmmc_request+0xec/0x4dc [1.875806] pc : [c0305b70]lr : [c0306c64]psr: 6113 [1.875806] sp : cf073ca0 ip : fp : 0008 [1.887885] r10: cf073de8 r9 : 0001 r8 : cf11d918 [1.893382] r7 : 0003 r6 : cf33cc80 r5 : 0001 r4 : 0033 [1.900250] r3 : 0002 r2 : cf073db8 r1 : cf073d84 r0 : cf33cc80 [1.907122] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [1.914813] Control: 10c5387d Table: 80004019 DAC: 0015 [1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238) [1.927454] Stack: (0xcf073ca0 to 0xcf074000) [1.932048] 3ca0: cf33c800 cf073d40 0003 c0076a8c cf073d40 48060220 48060220 [1.940659] 3cc0: 0004 0004 0002 0002 cf073ec8 c0421a9c c051835c cf073d40 [1.949271] 3ce0: cf33c800 0001 0008 0008 0002 cf073db8 cf073ec8 c02f0f28 [1.957882] 3d00: 0200 0064 cf073db8 cf073ec8 cf073d40 cf073d50 [1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80 cf360880 0008 c02f9964 [1.975104] 3d40: cf073d84 cf073db8 0001 0001 dead4ead [1.983717] 3d60: c0af722c c06aa3e4 c04ddadc cf073d74 cf073d74 c02f0dc4 [1.992327] 3d80: 0033 00b5 [2.000938] 3da0: cf073db8 cf073d40 05f5e100 [2.009548] 3dc0: 0008 0001 0200 cf073d40 0001 [2.018159] 3de0: cf073de8 c0cf1c02 0880 0008 8f360880 cf369800 [2.026771] 3e00: cf33c800 cf369800 cf073e4c cf072000 c02f8740 0015 [2.035382] 3e20: 0003 cf33c800 cf369800 cf073e4c cf072000 c02f8b20 [2.043994] 3e40: 0002 c02f25cc 0002 02544d53 41303447 1026c914 2600bbbd c0ff8000 [2.052605] 3e60: c0455884 cf33c800 c0455884 c0455890 cf072000 c02f92bc [2.061217] 3e80: c0455890 00ff8000 0002 cf33cb14 cf33c800 c02f3a28 cf041ac0 cf33cb14 [2.069829] 3ea0: cf050c00 cf051c00 c00507ec 0002 c0050778 c0050f10 [2.078441] 3ec0: c0af7268 c06aa1c4 c0518cd0 cf06a080 cf041ac0 [2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 0089 c05d7b5c cf050c00 c0050e4c [2.095665] 3f00: cf072000 6113 cf04dda8 cf041ac0 c0050d08 [2.104276] 3f20: c0056c94 c0429a18 0001 cf041ac0 [2.112888] 3f40: 0001 dead4ead c05ec0a0 [2.121499] 3f60: c04ddadc cf073f64 cf073f64 0001 dead4ead [2.130112] 3f80: c05ec0a0 c04ddadc cf073f90 cf073f90 cf073fac cf04dda8 [2.138724] 3fa0: c0056bf0 c0013588 [2.147334] 3fc0: [2.155946] 3fe0: 0013 57e0c5db 5ffb7d3c [2.164565] [c0305b70] (omap_hsmmc_start_command+0x74/0xf4) from [0003] (0x3) [2.172814] Code: 13a03801 0a1b e590c008 e5914000 (e59cc00c) [2.179314] ---[ end trace 6ec9899a56aef6aa ]--- I have also noticed that when the kernel boots okay (without a card inserted), if I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y) ... including no kernel oops. Can anyone shed light on what's wrong ? Cheers Mark J. [1] https://lkml.org/lkml/2013/6/25/784 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org
Re: [PATCH 1/2] ARM: dts: Add SHAM data and documentation for AM33XX
On Wed, Jul 17, 2013 at 10:12:22AM +0530, Lokesh Vutla wrote:
Hi Mark,
Hi Lokesh.
On Wednesday 17 July 2013 04:59 AM, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..b04aea1 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -401,4 +401,7 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
phy-mode = rgmii-txid;
+
+sham {
+ status = okay;
}; is missing here.
};
Ugh, yeah, I somehow mess that out.
Thanks for pointing that out.
Mark
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: dts: Add SHAM data and documentation for AM33XX
From: Mark A. Greer mgr...@animalcreek.com
Add the generic AM33XX SHAM module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms. Also add Documentation file describing the data
for the SHAM module.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
.../devicetree/bindings/crypto/omap-sham.txt | 33 ++
arch/arm/boot/dts/am335x-bone.dts | 4 +++
arch/arm/boot/dts/am335x-evm.dts | 4 +++
arch/arm/boot/dts/am335x-evmsk.dts | 4 +++
arch/arm/boot/dts/am33xx.dtsi | 10 +++
5 files changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt
diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt
b/Documentation/devicetree/bindings/crypto/omap-sham.txt
new file mode 100644
index 000..c6d1202
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-sham.txt
@@ -0,0 +1,33 @@
+OMAP SoC SHA crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SHAM versions:
+ - ti,omap2-sham for OMAP2 OMAP3.
+ - ti,omap4-sham for OMAP4 and AM33XX.
+ Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the SHAM module
+- reg : Offset and length of the register set for the module
+- interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this module.
+- interrupts : the interrupt number for the SHAM module.
+
+Optional properties:
+- dmas: DMA controller phandle and DMA request ordered pair.
+ Only one rx pair is valid per SHAM module.
+- dma-names: DMA request name. This string corresponds 1:1 with
+ the ordered pair in dmas. The string naming is to be
+ rx for RX request.
+
+Example:
+ /* AM335x */
+ sham: sham@5310 {
+ compatible = ti,omap4-sham;
+ ti,hwmods = sham;
+ reg = 0x5310 0x200;
+ interrupt-parent = intc;
+ interrupts = 109;
+ dmas = edma 36;
+ dma-names = rx;
+ };
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 444b4ed..bc75b2c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -234,3 +234,7 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+sham {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..9b8c56d 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -488,3 +488,7 @@
ti,adc-channels = 4 5 6 7;
};
};
+
+sham {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..61dc5d4 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -402,3 +402,7 @@
phy_id = davinci_mdio, 1;
phy-mode = rgmii-txid;
};
+
+sham {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..63a5e95 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,5 +530,15 @@
#size-cells = 1;
status = disabled;
};
+
+ sham: sham@5310 {
+ compatible = ti,omap4-sham;
+ ti,hwmods = sham;
+ reg = 0x5310 0x200;
+ interrupt-parent = intc;
+ interrupts = 109;
+ dmas = edma 36;
+ dma-names = rx;
+ };
};
};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: Add AES data and documentation for AM33XX
From: Mark A. Greer mgr...@animalcreek.com
Add the generic AM33XX AES module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms. Also add Documentation file describing the data
for the AES module.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
.../devicetree/bindings/crypto/omap-aes.txt| 35 ++
arch/arm/boot/dts/am335x-bone.dts | 4 +++
arch/arm/boot/dts/am335x-evm.dts | 4 +++
arch/arm/boot/dts/am335x-evmsk.dts | 4 +++
arch/arm/boot/dts/am33xx.dtsi | 11 +++
5 files changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt
diff --git a/Documentation/devicetree/bindings/crypto/omap-aes.txt
b/Documentation/devicetree/bindings/crypto/omap-aes.txt
new file mode 100644
index 000..b51d12f
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-aes.txt
@@ -0,0 +1,35 @@
+OMAP SoC AES crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ AES versions:
+ - ti,omap2-aes for OMAP2.
+ - ti,omap3-aes for OMAP3.
+ - ti,omap4-aes for OMAP4 and AM33XX.
+ Note that the OMAP2 and 3 versions are compatible (OMAP3 supports
+ more algorithms) but they are incompatible with OMAP4.
+- ti,hwmods: Name of the hwmod associated with the AES odule
+- reg : Offset and length of the register set for the module
+- interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this module.
+- interrupts : the interrupt number for the AES odule.
+
+Optional properties:
+- dmas: DMA controller phandle and DMA request ordered pairs.
+- dma-names: DMA request names. This string corresponds 1:1 with
+ the ordered pairs in dmas. The string naming is to be
+ tx for TX request and rx for RX request.
+
+Example:
+ /* AM335x */
+ aes: aes@5350 {
+ compatible = ti,omap4-aes;
+ ti,hwmods = aes;
+ reg = 0x5350 0xa0;
+ interrupt-parent = intc;
+ interrupts = 102;
+ dmas = edma 6
+ edma 5;
+ dma-names = tx, rx;
+ };
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index bc75b2c..0cb454e 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -238,3 +238,7 @@
sham {
status = okay;
};
+
+aes {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9b8c56d..76ba004 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -492,3 +492,7 @@
sham {
status = okay;
};
+
+aes {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 61dc5d4..025a47e 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -406,3 +406,7 @@
sham {
status = okay;
};
+
+aes {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 63a5e95..2a7ff0f 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -540,5 +540,16 @@
dmas = edma 36;
dma-names = rx;
};
+
+ aes: aes@5350 {
+ compatible = ti,omap4-aes;
+ ti,hwmods = aes;
+ reg = 0x5350 0xa0;
+ interrupt-parent = intc;
+ interrupts = 102;
+ dmas = edma 6
+ edma 5;
+ dma-names = tx, rx;
+ };
};
};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] ARM: dts: Add SHAM and AES DT information
From: Mark A. Greer mgr...@animalcreek.com Long overdue patches to add the device tree updates and documentation for the SHAM and AES modules on the am33xx. The supporting code is already in the mainline kernel. This series is based on the current mainline kernel, c0d15cc (linked-list: Remove __list_for_each). Changes from v1: - Added missing '};' as pointed out by Lokesh Vutla lokeshvu...@ti.com Mark A. Greer (2): ARM: dts: Add SHAM data and documentation for AM33XX ARM: dts: Add AES data and documentation for AM33XX .../devicetree/bindings/crypto/omap-aes.txt| 35 ++ .../devicetree/bindings/crypto/omap-sham.txt | 33 arch/arm/boot/dts/am335x-bone.dts | 8 + arch/arm/boot/dts/am335x-evm.dts | 8 + arch/arm/boot/dts/am335x-evmsk.dts | 8 + arch/arm/boot/dts/am33xx.dtsi | 21 + 6 files changed, 113 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe 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: ARM: AM335x: Kernel oops when using EDMA and MMC
On 17/07/13 16:55, Mark Jackson wrote: I'm trying to get the MMC port working on our custom AM3352 CPU board. I have added MMC entries to out dts file (similar to [1]), and I've enabled CONFIG_TI_EDMA. Our board boots fine without an SD card inserted ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj@mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013 ... [2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12. [2.797268] devtmpfs: mounted [2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000) ... Welcome to Buildroot nanobone login: I have just noticed the following in the boot log:- ... [1.225698] omap_hsmmc 4806.mmc: unable to obtain RX DMA engine channel 3227000204 ... -- To unsubscribe from this list: send the line unsubscribe 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: ARM: AM335x: Kernel oops when using EDMA and MMC
On 07/17/2013 10:55 AM, Mark Jackson wrote: I'm trying to get the MMC port working on our custom AM3352 CPU board. I have added MMC entries to out dts file (similar to [1]), and I've enabled CONFIG_TI_EDMA. Our board boots fine without an SD card inserted ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj@mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013 ... [2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12. [2.797268] devtmpfs: mounted [2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000) ... Welcome to Buildroot nanobone login: But when I boot with a card already inserted, I get the following oops ... ... [1.827343] Unable to handle kernel NULL pointer dereference at virtual address 000c [1.835868] pgd = c0004000 [1.838774] [000c] *pgd= [1.842556] Internal error: Oops: 5 [#1] ARM [1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.11.0-rc1-00025-g95b9b72 #309 [1.855511] Workqueue: kmmcd mmc_rescan [1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000 [1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4 [1.870761] LR is at omap_hsmmc_request+0xec/0x4dc [1.875806] pc : [c0305b70]lr : [c0306c64]psr: 6113 [1.875806] sp : cf073ca0 ip : fp : 0008 [1.887885] r10: cf073de8 r9 : 0001 r8 : cf11d918 [1.893382] r7 : 0003 r6 : cf33cc80 r5 : 0001 r4 : 0033 [1.900250] r3 : 0002 r2 : cf073db8 r1 : cf073d84 r0 : cf33cc80 [1.907122] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [1.914813] Control: 10c5387d Table: 80004019 DAC: 0015 [1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238) [1.927454] Stack: (0xcf073ca0 to 0xcf074000) [1.932048] 3ca0: cf33c800 cf073d40 0003 c0076a8c cf073d40 48060220 48060220 [1.940659] 3cc0: 0004 0004 0002 0002 cf073ec8 c0421a9c c051835c cf073d40 [1.949271] 3ce0: cf33c800 0001 0008 0008 0002 cf073db8 cf073ec8 c02f0f28 [1.957882] 3d00: 0200 0064 cf073db8 cf073ec8 cf073d40 cf073d50 [1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80 cf360880 0008 c02f9964 [1.975104] 3d40: cf073d84 cf073db8 0001 0001 dead4ead [1.983717] 3d60: c0af722c c06aa3e4 c04ddadc cf073d74 cf073d74 c02f0dc4 [1.992327] 3d80: 0033 00b5 [2.000938] 3da0: cf073db8 cf073d40 05f5e100 [2.009548] 3dc0: 0008 0001 0200 cf073d40 0001 [2.018159] 3de0: cf073de8 c0cf1c02 0880 0008 8f360880 cf369800 [2.026771] 3e00: cf33c800 cf369800 cf073e4c cf072000 c02f8740 0015 [2.035382] 3e20: 0003 cf33c800 cf369800 cf073e4c cf072000 c02f8b20 [2.043994] 3e40: 0002 c02f25cc 0002 02544d53 41303447 1026c914 2600bbbd c0ff8000 [2.052605] 3e60: c0455884 cf33c800 c0455884 c0455890 cf072000 c02f92bc [2.061217] 3e80: c0455890 00ff8000 0002 cf33cb14 cf33c800 c02f3a28 cf041ac0 cf33cb14 [2.069829] 3ea0: cf050c00 cf051c00 c00507ec 0002 c0050778 c0050f10 [2.078441] 3ec0: c0af7268 c06aa1c4 c0518cd0 cf06a080 cf041ac0 [2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 0089 c05d7b5c cf050c00 c0050e4c [2.095665] 3f00: cf072000 6113 cf04dda8 cf041ac0 c0050d08 [2.104276] 3f20: c0056c94 c0429a18 0001 cf041ac0 [2.112888] 3f40: 0001 dead4ead c05ec0a0 [2.121499] 3f60: c04ddadc cf073f64 cf073f64 0001 dead4ead [2.130112] 3f80: c05ec0a0 c04ddadc cf073f90 cf073f90 cf073fac cf04dda8 [2.138724] 3fa0: c0056bf0 c0013588 [2.147334] 3fc0: [2.155946] 3fe0: 0013 57e0c5db 5ffb7d3c [2.164565] [c0305b70] (omap_hsmmc_start_command+0x74/0xf4) from [0003] (0x3) [2.172814] Code: 13a03801 0a1b e590c008 e5914000 (e59cc00c) [2.179314] ---[ end trace 6ec9899a56aef6aa ]--- I have also noticed that when the kernel boots okay (without a card inserted), if I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y) ... including no kernel oops. Can anyone shed light on what's wrong ? I see this issue too on
Re: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
Hi, On 07/17/2013 06:32 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Add dynamic active/idle pin states for uart3/4 which will be applied when uart3/4 state is switched from active to idle and back by Runtime PM or during system suspend. This is good for testing code, but should not be merged because omap4 has the iopad wake-ups available for uarts. So those can be always enabled. In this case, 2 IRQ will be received per each UART RX event - one from PRCM and from UART - and that's not good from PM perspective (It will affect on CPUIdle and CPUFreq at least). -- log when wake-up enabled always 106:729 0 GIC 106 OMAP UART2 115: 13 0 GIC 115 mmc0 118: 68 0 GIC 118 mmc1 151: 0 0 GIC 151 twl6040 361:322 0 PRCM hwmod_io -- log when wake-up enabled only when UART3 (console) is active 106: 1104 0 GIC 106 OMAP UART2 115: 13 0 GIC 115 mmc0 118: 68 0 GIC 118 mmc1 151: 0 0 GIC 151 twl6040 361: 7 0 PRCM hwmod_io The same is valid for all devices which will leave WAKEUP_EN set all the time ( --- a/arch/arm/boot/dts/omap4-sdp.dts +++ b/arch/arm/boot/dts/omap4-sdp.dts @@ -181,18 +181,40 @@ pinctrl-single,pins = 0x100 (PIN_INPUT_PULLUP | MUX_MODE0)/* uart3_cts_rctx.uart3_cts_rctx */ 0x102 (PIN_OUTPUT | MUX_MODE0) /* uart3_rts_sd.uart3_rts_sd */ - 0x104 (PIN_INPUT | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ 0x106 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx */ ; }; This just need to become: pinctrl-single,pins = ... 0x104 (WAKEUP_EN | PIN_INPUT_MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ ... ; interrupts = GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH; }; And so on. For am33xx you need to remux things to GPIO for the wake-up events, so you should maybe test on that instead. Regards, Tony 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 9/9] ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO9 supplies the board specified vdds_sdcard supply going within SoC
specification of 1.8V or 3.0V. Further the supply is controlled by
switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
on need basis.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index ef05676..65d7b60 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -235,7 +235,7 @@
};
mmc1 {
- vmmc-supply = vmmcsd_fixed;
+ vmmc-supply = ldo9_reg;
bus-width = 4;
};
@@ -417,8 +417,7 @@
/* VCC_DV_SDIO: vdds_sdcard */
regulator-name = ldo9;
regulator-min-microvolt = 180;
- regulator-max-microvolt = 330;
- regulator-always-on;
+ regulator-max-microvolt = 300;
regulator-boot-on;
};
@@ -439,6 +438,13 @@
regulator-always-on;
regulator-boot-on;
};
+
+ regen3_reg: regen3 {
+ /* REGEN3 controls LDO9 supply to card
*/
+ regulator-name = regen3;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
};
};
--
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 4/9] ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.
To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.
Remove 'always-on' and 'boot-on' settings here as it is
a 'on need' supply to SoC IP and is not enabled by PMIC by
default at boot.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 87b3e9e..a55f4d8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -346,10 +346,8 @@
ldo1_reg: ldo1 {
/* VDDAPHY_CAM: vdda_csiport */
regulator-name = ldo1;
- regulator-min-microvolt = 280;
- regulator-max-microvolt = 280;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 180;
};
ldo2_reg: ldo2 {
--
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 8/9] ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO4 supplies VDD_VPP which is vpp1. This is currently configured for
1.5V which as per data manual A pulse width of 1000 ns and an amplitude
of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
be supplied.
So, fix the voltage to 2V. and disable the supply since we have no plans
of programming efuse bits - it can only be done once - in factory.
Further it is not enabled by default by PMIC so, 'boot-on' must be
removed, and the 'always-on' needs to be removed to achieve pulsing
if efuse needs to be programmed.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3ff5874..ef05676 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -397,10 +397,10 @@
ldo7_reg: ldo7 {
/* VDD_VPP: vpp1 */
regulator-name = ldo7;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 200;
+ regulator-max-microvolt = 200;
+ /* Only for efuse reprograming! */
+ status = disabled;
};
ldo8_reg: ldo8 {
--
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/9] ARM: dts: omap5-uevm: document regulator signals used on the actual board
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards - which is meant to be supported by this dts.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b430b8f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -282,6 +282,7 @@
regulators {
smps123_reg: smps123 {
+ /* VDD_OPP_MPU */
regulator-name = smps123;
regulator-min-microvolt = 60;
regulator-max-microvolt = 150;
@@ -290,6 +291,7 @@
};
smps45_reg: smps45 {
+ /* VDD_OPP_MM */
regulator-name = smps45;
regulator-min-microvolt = 60;
regulator-max-microvolt = 131;
@@ -298,6 +300,7 @@
};
smps6_reg: smps6 {
+ /* VDD_DDR3 - over VDD_SMPS6 */
regulator-name = smps6;
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
@@ -306,6 +309,7 @@
};
smps7_reg: smps7 {
+ /* VDDS_1v8_OMAP over VDDS_1v8_MAIN */
regulator-name = smps7;
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
@@ -314,6 +318,7 @@
};
smps8_reg: smps8 {
+ /* VDD_OPP_CORE */
regulator-name = smps8;
regulator-min-microvolt = 60;
regulator-max-microvolt = 131;
@@ -322,6 +327,7 @@
};
smps9_reg: smps9 {
+ /* VDDA_2v1_AUD over VDD_2v1 */
regulator-name = smps9;
regulator-min-microvolt = 210;
regulator-max-microvolt = 210;
@@ -331,6 +337,7 @@
};
smps10_reg: smps10 {
+ /* VBUS_5V_OTG */
regulator-name = smps10;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
@@ -339,6 +346,7 @@
};
ldo1_reg: ldo1 {
+ /* VDDAPHY_CAM: vdda_csiport */
regulator-name = ldo1;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
@@ -347,6 +355,7 @@
};
ldo2_reg: ldo2 {
+ /* VCC_2V8_DISP: Does not go anywhere */
regulator-name = ldo2;
regulator-min-microvolt = 290;
regulator-max-microvolt = 290;
@@ -355,6 +364,7 @@
};
ldo3_reg: ldo3 {
+ /* VDDAPHY_MDM: vdda_lli */
regulator-name = ldo3;
regulator-min-microvolt = 300;
regulator-max-microvolt = 300;
@@ -363,6 +373,7 @@
};
ldo4_reg: ldo4 {
+ /* VDDAPHY_DISP: vdda_dsiport/hdmi */
regulator-name = ldo4;
regulator-min-microvolt = 220;
[PATCH 2/9] ARM: dts: omap5-uevm: update SMPS9 settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7 (ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes) introduced regulator entries for OMAP5uEVM. However, The regulator information is based on an older temporary pre-production board variant and does not reflect production board 750-2628-XXX boards. SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be enabled only when audio is active. Since it does not come active by default, it does not require always-on or boot-on. Reported-by: Marc Jüttner m-juett...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/boot/dts/omap5-uevm.dts |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index b430b8f..6709f1e 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++ b/arch/arm/boot/dts/omap5-uevm.dts @@ -331,8 +331,6 @@ regulator-name = smps9; regulator-min-microvolt = 210; regulator-max-microvolt = 210; - regulator-always-on; - regulator-boot-on; ti,smps-range = 0x80; }; -- 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 7/9] ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
1.2V instead of 1.5V.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 1550d6a..3ff5874 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -388,8 +388,8 @@
ldo6_reg: ldo6 {
/* VDDS_1V2_WKUP: hsic/ldo_emu_wkup */
regulator-name = ldo6;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
regulator-always-on;
regulator-boot-on;
};
--
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 0/9] ARM: dts: omap5-uevm: fixup wrong regulator configuration
Due to wrong older revision of documentation used as reference, we seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This series is based power tree on production board 750-2628-XXX platform. Unfortunately, the wrong voltages may be detrimental to OMAP5 as they supply hardware blocks at voltages that are out of specification. Also available at: based on v3.11-rc1 tag http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes git link: git://github.com/nmenon/linux-2.6-playground.git branch: push/omap5-palmas-fixes Tested with https://patchwork.kernel.org/patch/2545061/ + https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data Test result: http://pastebin.com/YqASYkXG Relevant documentation: - OMAP5 uEVM documentation: https://www.svtronics.com/omap/omap54xx?product_id=33 - OMAP5432 Data Manual: http://www.ti.com/product/OMAP5432 - TWL6037 / OTP information: Currently available only under NDA Nishanth Menon (9): ARM: dts: omap5-uevm: document regulator signals used on the actual board ARM: dts: omap5-uevm: update SMPS9 settings ARM: dts: omap5-uevm: update and disable unused regulators LDO[28] ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3 arch/arm/boot/dts/omap5-uevm.dts | 78 -- 1 file changed, 49 insertions(+), 29 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO3 supplies Low Latency Interface(LLI) hardware module which is a
special hardware to communicate with Modem. However since uEVM is
not setup by default for this communication, this should be disabled
by default.
Further, vdda_lli is supposed to be 1.5V and not 3V.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a55f4d8..c6d560b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -362,10 +362,11 @@
ldo3_reg: ldo3 {
/* VDDAPHY_MDM: vdda_lli */
regulator-name = ldo3;
- regulator-min-microvolt = 300;
- regulator-max-microvolt = 300;
- regulator-always-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
regulator-boot-on;
+ /* Only if Modem is used */
+ status = disabled;
};
ldo4_reg: ldo4 {
--
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 3/9] ARM: dts: omap5-uevm: update and disable unused regulators LDO[28]
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards - On production boards, LDO2 and 8 are unused.
LDO2 and LDO8 do not go to any peripheral or connector on the board.
Further, these unused regulators should have been 2.8V for LDO2 and
3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 6709f1e..87b3e9e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -355,10 +355,10 @@
ldo2_reg: ldo2 {
/* VCC_2V8_DISP: Does not go anywhere */
regulator-name = ldo2;
- regulator-min-microvolt = 290;
- regulator-max-microvolt = 290;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ /* Unused */
+ status = disabled;
};
ldo3_reg: ldo3 {
@@ -409,10 +409,11 @@
ldo8_reg: ldo8 {
/* VDD_3v0: Does not go anywhere */
regulator-name = ldo8;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
- regulator-always-on;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
regulator-boot-on;
+ /* Unused */
+ status = disabled;
};
ldo9_reg: ldo9 {
--
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 6/9] ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi
This can only be supplied at 1.5V or 1.8V and we currently
supply 2.2V.
To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.
Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
supply to SoC IP and is not enabled by PMIC by default at boot.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index c6d560b..1550d6a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -372,10 +372,8 @@
ldo4_reg: ldo4 {
/* VDDAPHY_DISP: vdda_dsiport/hdmi */
regulator-name = ldo4;
- regulator-min-microvolt = 220;
- regulator-max-microvolt = 220;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 180;
};
ldo5_reg: ldo5 {
--
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 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
On 07/17/2013 06:38 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod framework. After switching to DT-boot the pinctrl handling was dropped from hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html) But this is not right for OMAP2+ SoC where real IPs state is controlled by omap_device core which enables/disables modules clocks actually. I'm not convinced we should try to handle this in a generic way as only some devices need dynamic remuxing of some pins. For example, if OMAP I2C driver will handle pinctrl state during system wide suspend the following issue may occure: - suspend_noirq - I2C device can be still active because of PM auto-suspend |-_od_suspend_noirq |- omap_i2c_suspend_noirq |- PINs state set to SLEEP |- pm_generic_runtime_suspend |- omap_i2c_runtime_suspend() |- PINs state set to IDLE --- *oops* PINs state is IDLE and not SLEEP |- omap_device_idle() |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) And in this example you are assuming that you need separate idle and sleep states, which is not true at least for most cases I've seen. I don't need both states (at least right now) :), but - if any OMAP2+ driver will have two states defined: idle and sleep - and if it will try to manage them from drivers callbacks only using pure calls to pinctrl_pm_select_xx() helpers the idle state will be selected during suspend and *not* sleep. It is possible that am33xx needs separate idle and sleep states, but most likely only for some pins. For omap[345] we can get away with just the default state for most cases. In case, if only default state is defined for device - nothing will be done by OMAP device framework for it (I mean any call to pinctrl_pm_select_xx() will do nothing - it just checks that there is no state and returns 0). Regards, Tony 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
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On 07/17/2013 05:00 AM, Laurent Pinchart wrote: On Monday 15 July 2013 21:39:31 Stephen Warren wrote: ... But then there's a problem where people assume that the common flags are always available, and somewhere they aren't... Care is needed in the choice of which common flags to define and/or how they're used. Exactly. That's why I think listing the supported common flags in individual bindings makes sense when some of the flags are not supported by all devices. As the only PWM flags currently used are common to all PWM devices I can leave this out now. I have no strong preference, I'll follow your opinion on this. Yes, I guess separating the concept of defining common flags and which devices use them is good. And then indeed individual devices need to define which of the common flags they support. I'd still like to see the *definition* of those common flags in some central place (i.e. pwm.txt or a header that defines constants for it), and the other device bindings simply reference that for the actual definitions. -- To unsubscribe from this list: send the line unsubscribe 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: musb: dsps: make it work with two instances
* Ezequiel Garcia | 2013-07-06 18:39:50 [-0300]: Hi Sebastian, Hi Ezequiel, After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. Beaglebone black, that one has a different device tree which is not mainline, right? However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. I figured out why my Host is not recognized on the second plug: At module load time, musb_start() is executed and it sets the MUSB_DEVCTL_SESSION in devctl. After the device is unplugged dsps_musb_try_idle() schedules a timer which executes the local otg_timer() function. Since the phy is in OTG_STATE_A_WAIT_BCON state, the MUSB_DEVCTL_SESSION bit gets removed. If the removal of the bit is ignored, the device is recognized after a re-plug. Now a question: I see that am35x and anothers also remove that flag in thsi case. How is the flag supposed to come back? I see that blackfin removes that bit and stuffs it back in. Any idea what should be done here? Also, FWIW, I think that having a separate USB phy for am35xx would be much better. So you would prefer a new file with 90% copy of what we already have in the nop_phy? Sebastian -- To unsubscribe from this list: send the line unsubscribe 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 v9 1/8] drivers: phy: add generic PHY framework
On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote: Hi, On Wednesday 17 July 2013 11:59 AM, Greg KH wrote: On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote: +menuconfig GENERIC_PHY + tristate PHY Subsystem + help +Generic PHY support. + +This framework is designed to provide a generic interface for PHY +devices present in the kernel. This layer will have the generic +API by which phy drivers can create PHY using the phy framework and +phy users can obtain reference to the PHY. Shouldn't this be something that other drivers select? How will anyone know if they need this or not? All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those PHY drivers can be selected like in [1]. The PHY consumer driver should ideally use *depends on* in their Kconfig. [1] - http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html No, switch it around the other way. How would I even _know_ that I need to enable the generic PHY subsystem in the first place? How can I determine that I need this for my hardware? You need to give hints to someone who doesn't even know what a PHY is, otherwise they will always disable it and move on. --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,544 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2013 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. You really mean any later version (I have to ask)? That was copied from somewhere :-s So, is that what you really mean to have for this code? + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. Are these two paragraphs needed? This isn't a program, and they got a copy of the GPL already with the kernel. hmm.. I can remove that. +static struct class *phy_class; Why do you need a class? Wanted to group all the PHY drivers to be used by different subsystems (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my initial version [3] on using a bus_type instead of class but then it was decided to go with class itself. [3] - http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html Ok, but what does the class usage get you? When modifying/adding new sysfs stuff, you need a Documentation/ABI/ entry as well. I'm not actually adding any new sysfs entry other than what a *class_create* must have created. Do I need to add one for that? If you are not creating anything in sysfs at all, why use the driver model? (hint, I think you need to do something here to justify it...) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb: dsps: make it work with two instances
Hi Sebastian, On Wed, Jul 17, 2013 at 07:12:29PM +0200, Sebastian Andrzej Siewior wrote: After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. Beaglebone black, that one has a different device tree which is not mainline, right? Beaglebone black it is. But I'm almost sure I just used the ambone.dts file that's mainlined. I just changed the mode or something like that, very minor tweaking indeed, altough right now I don't remember exactly which changes. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. I figured out why my Host is not recognized on the second plug: At module load time, musb_start() is executed and it sets the MUSB_DEVCTL_SESSION in devctl. After the device is unplugged dsps_musb_try_idle() schedules a timer which executes the local otg_timer() function. Since the phy is in OTG_STATE_A_WAIT_BCON state, the MUSB_DEVCTL_SESSION bit gets removed. If the removal of the bit is ignored, the device is recognized after a re-plug. Mmmm... okey. Interesting insight, thanks! Also, FWIW, I think that having a separate USB phy for am35xx would be much better. So you would prefer a new file with 90% copy of what we already have in the nop_phy? No, of course not. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 07/17/2013 01:12 PM, 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.
Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
Almost there (I hope). But please run scripts/checkpatch, make C=2 and make
coccicheck on your driver and fix all errors those tools give you before
submitting the driver upstream.
[...]
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+ int channel, int *res)
+{
+ u8 reg = gpadc-pdata-channel_to_reg(channel);
+ __le16 val;
+ int raw_code;
+ int ret;
+
+ ret = twl6030_gpadc_read(reg, (u8 *)val);
+ if (ret) {
+ dev_dbg(gpadc-dev, unable to read register 0x%X\n, reg);
+ return ret;
+ }
+
+ raw_code = le16_to_cpup(val);
raw_code = le16_to_cpu(val)
+ dev_dbg(gpadc-dev, GPADC raw code: %d, raw_code);
+
+ if (twl6030_channel_calibrated(gpadc-pdata, channel))
+ *res = twl6030_gpadc_make_correction(gpadc, channel, raw_code);
+ else
+ *res = raw_code;
+
+ return ret;
+}
+
[...]
+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;
+ long timeout;
+
+ 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 */
+ timeout = wait_for_completion_interruptible_timeout(
+ gpadc-irq_complete, msecs_to_jiffies(5000));
+ if (!timeout)
+ return -ETIMEDOUT;
+ else if (timeout 0)
+ return EINTR;
You still hold the mutex, try this instead:
ret = wait_for_
if (ret == 0)
ret = -ETIMEDOUT;
if (ret 0)
goto err;
+
+ 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 twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+ int chn, d1 = 0, d2 = 0, temp;
+ u8 trim_regs[17];
+ int ret;
+
+ ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+ TWL6030_GPADC_TRIM1, 16);
+ if (ret 0) {
+ dev_err(gpadc-dev, calibration failed\n);
+ return ret;
+ }
+
+ /*
+ * Loop to calculate the value needed for returning voltages from
+ * GPADC not values.
+ *
+ * gain is calculated to 3 decimal places fixed point.
+ */
+ for (chn = 0; chn TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+ switch (chn) {
+ case 0:
+ case 1:
+ case 2:
+ case 3:
+ case 4:
+ case 5:
+ case 6:
+ case 11:
+ case 12:
+ case 13:
+ case 14:
+ /* D1 */
+ d1 = (trim_regs[3] 0x1F) 2;
+ d1 |= (trim_regs[1] 0x06) 1;
+ if (trim_regs[1] 0x01)
+ d1 = -d1;
+
+ /* D2 */
+ d2 = (trim_regs[4] 0x3F) 2;
+ d2 |= (trim_regs[2] 0x06) 1;
+ if
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On Wed, Jul 17, 2013 at 11:11:19AM -0600, Stephen Warren wrote: On 07/17/2013 05:00 AM, Laurent Pinchart wrote: On Monday 15 July 2013 21:39:31 Stephen Warren wrote: ... But then there's a problem where people assume that the common flags are always available, and somewhere they aren't... Care is needed in the choice of which common flags to define and/or how they're used. Exactly. That's why I think listing the supported common flags in individual bindings makes sense when some of the flags are not supported by all devices. As the only PWM flags currently used are common to all PWM devices I can leave this out now. I have no strong preference, I'll follow your opinion on this. Yes, I guess separating the concept of defining common flags and which devices use them is good. And then indeed individual devices need to define which of the common flags they support. I'd still like to see the *definition* of those common flags in some central place (i.e. pwm.txt or a header that defines constants for it), and the other device bindings simply reference that for the actual definitions. That sounds reasonable to me. Thierry signature.asc Description: Digital signature
Re: [PATCH 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Oleksandr Kozaruk oleksandr.koza...@ti.com wrote: Hello Jonathan, Two very quick comments based on quick glance as it may be a while before I can do a full review. We still have channels that are only usable for temperature being output to user space as voltage channels? Is the conversion so very hard? Can you please clarify what should return temperature channel for in_tempX_input (processed)? Is it voltage or Celsius degree? Milli degrees centigrade. in_tempX_raw should return ADC code? Right? Yes See Documentation/ABI/testing/sysfs-bus-iio Regards, OK. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line unsubscribe 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/4] mtd: nand: omap: add support for BCH16_ECC - DT updates
With increase in NAND flash densities occurence of bit-flips has increased.
Thus stronger ECC schemes are required for detecting and correcting multiple
simultaneous bit-flips in same NAND page. But stronger ECC schemes have large
ECC syndrome which require more space in OOB/Spare.
This patch add support for BCH16_ECC:
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page = 26 * (page-size / 512)
Signed-off-by: Pekon Gupta pe...@ti.com
---
Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 7 +++
include/linux/platform_data/mtd-nand-omap2.h| 7 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index d307c67..017d818 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -66,6 +66,13 @@ Optional properties:
* depends on CONFIG_MTD_NAND_OMAP_BCH
* requires elm_id to be specified
+ bch16_code_hw 16-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in hardware
+ - ECC layout compatible with ROM code
+ * depends on CONFIG_MTD_NAND_OMAP_BCH
+ * requires elm_id to be specified
+
- elm_id: Specifies elm device node. This is required to
support some BCH ECC schemes mentioned above.
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 9fcee61..50a6413 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -37,7 +37,9 @@ enum omap_ecc {
/* 8-bit ECC calculation by GPMC, Error detection by Software */
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW,
/* 8-bit ECC calculation by GPMC, Error detection by ELM */
- OMAP_ECC_BCH8_CODE_HW
+ OMAP_ECC_BCH8_CODE_HW,
+ /* 16-bit ECC calculation by GPMC, Error detection by ELM */
+ OMAP_ECC_BCH16_CODE_HW
};
struct gpmc_nand_regs {
@@ -57,6 +59,9 @@ struct gpmc_nand_regs {
void __iomem*gpmc_bch_result1[GPMC_BCH_NUM_REMAINDER];
void __iomem*gpmc_bch_result2[GPMC_BCH_NUM_REMAINDER];
void __iomem*gpmc_bch_result3[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result4[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result5[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result6[GPMC_BCH_NUM_REMAINDER];
};
struct omap_nand_platform_data {
--
1.8.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
[PATCH v1 2/4] mtd: nand: omap: add support for BCH16_ECC - ELM driver updates
With increase in NAND flash densities occurence of bit-flips has increased.
Thus stronger ECC schemes are required for detecting and correcting multiple
simultaneous bit-flips in same NAND page. But stronger ECC schemes have large
ECC syndrome which require more space in OOB/Spare.
This patch add support for BCH16_ECC:
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page = 26 * (page-size / 512)
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/devices/elm.c | 29 +
include/linux/platform_data/elm.h | 8 +---
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index fca436e..f50f36b 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -217,6 +217,35 @@ static void elm_load_syndrome(struct elm_info *info,
elm_write_reg(info, (ELM_SYNDROME_FRAGMENT_3 +
offset), cpu_to_le32(val));
break;
+ case BCH16_ECC:
+ val = *(ecc + 25) 0 | *(ecc + 24) 8 |
+ *(ecc + 23) 16 | *(ecc + 22) 24;
+ elm_write_reg(info, (ELM_SYNDROME_FRAGMENT_0 +
+offset), cpu_to_le32(val));
+ val = *(ecc + 21) 0 | *(ecc + 20) 8 |
+ *(ecc + 19) 16 | *(ecc + 18) 24;
+ elm_write_reg(info, (ELM_SYNDROME_FRAGMENT_1 +
+offset), cpu_to_le32(val));
+ val = *(ecc + 17) 0 | *(ecc + 16) 8 |
+ *(ecc + 15) 16 | *(ecc + 14) 24;
+ elm_write_reg(info, (ELM_SYNDROME_FRAGMENT_2 +
+offset), cpu_to_le32(val));
+ val = *(ecc + 13) 0 | *(ecc + 12) 8 |
+ *(ecc + 11) 16 | *(ecc + 10) 24;
+ elm_write_reg(info, (ELM_SYNDROME_FRAGMENT_3 +
+offset), cpu_to_le32(val));
+ val = *(ecc + 9) 0 | *(ecc + 8) 8 |
+ *(ecc + 7) 16 | *(ecc + 6) 24;
+ elm_write_reg(info, (ELM_SYNDROME_FRAGMENT_4 +
+offset), cpu_to_le32(val));
+ val = *(ecc + 5) 0 | *(ecc + 4) 8 |
+ *(ecc + 3) 16 | *(ecc + 2) 24;
+ elm_write_reg(info, (ELM_SYNDROME_FRAGMENT_5 +
+offset), cpu_to_le32(val));
+ val = *(ecc + 1) 0 | *(ecc + 0) 8;
+ elm_write_reg(info, (ELM_SYNDROME_FRAGMENT_6 +
+offset), cpu_to_le32(val));
+ break;
}
}
}
diff --git a/include/linux/platform_data/elm.h
b/include/linux/platform_data/elm.h
index d16465b..18b37d8 100644
--- a/include/linux/platform_data/elm.h
+++ b/include/linux/platform_data/elm.h
@@ -21,19 +21,13 @@
enum bch_ecc {
BCH4_ECC = 0,
BCH8_ECC,
+ BCH16_ECC
};
/* ELM support 8 error syndrome process */
#define ERROR_VECTOR_MAX 8
#define ELM_MAX_DETECTABLE_ERRORS 16
-#define BCH8_ECC_OOB_BYTES 13
-#define BCH4_ECC_OOB_BYTES 7
-/* RBL requires 14 byte even though BCH8 uses only 13 byte */
-#define BCH8_SIZE (BCH8_ECC_OOB_BYTES + 1)
-/* Uses 1 extra byte to handle erased pages */
-#define BCH4_SIZE (BCH4_ECC_OOB_BYTES + 1)
-
/**
* struct elm_errorvec - error vector for elm
* @error_reported:set true for vectors error is reported
--
1.8.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
[PATCH v1 0/4] mtd: nand: omap: add support for BCH16_ECC
This patch series add support of BCH16_ECC scheme. As BCH16_ECC scheme generates 26bytes of ECC syndrome per 512B data, hence this scheme is usable only for NAND devices having 4K or above page-size, as their OOB/spare area has enough space to accomodate ECC. This patch series is applicable over an above following series: [1] [Patch] mtd:nand:omap2: clean-up of supported ECC schemes http://lists.infradead.org/pipermail/linux-mtd/2013-July/047530.html [2] [Patch] optimize and clean-up of OMAP NAND and ELM driver http://lists.infradead.org/pipermail/linux-mtd/2013-July/047538.html Also this BCH16_ECC patch series is sparsely tested, due to limited availability of boards with 4K/224NAND, so request the users to test the mentioned series, and provide Tested-by. Pekon Gupta (4): mtd: nand: omap: add support for BCH16_ECC - DT updates mtd: nand: omap: add support for BCH16_ECC - ELM driver updates mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates mtd: nand: omap: add support for BCH16_ECC - NAND driver updates .../devicetree/bindings/mtd/gpmc-nand.txt | 7 ++ arch/arm/mach-omap2/gpmc.c | 22 +++-- drivers/mtd/devices/elm.c | 29 ++ drivers/mtd/nand/omap2.c | 104 +++-- include/linux/platform_data/elm.h | 8 +- include/linux/platform_data/mtd-nand-omap2.h | 7 +- 6 files changed, 155 insertions(+), 22 deletions(-) -- 1.8.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
[PATCH v1 4/4] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
With increase in NAND flash densities occurence of bit-flips has increased.
Thus stronger ECC schemes are required for detecting and correcting multiple
simultaneous bit-flips in same NAND page. But stronger ECC schemes have large
ECC syndrome which require more space in OOB/Spare.
This patch add support for BCH16_ECC:
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page = 26 * (page-size / 512)
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 104 +++
1 file changed, 96 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c2c3c6bb..a0cf487 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -130,9 +130,13 @@
#define BADBLOCK_MARKER_LENGTH 0x2
#ifdef CONFIG_MTD_NAND_OMAP_BCH
-static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
- 0xac, 0x6b, 0xff, 0x99, 0x7b};
-static u_char bch4_vector[] = {0x00, 0x6b, 0x31, 0xdd, 0x41, 0xbc, 0x10};
+static u_char bch4_vector[] = {0x00, 0x6b, 0x31, 0xdd, 0x41, 0xbc, 0x10};
+static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
+ 0xac, 0x6b, 0xff, 0x99, 0x7b};
+static u_char bch16_vector[] = {0xf5, 0x24, 0x1c, 0xd0, 0x61, 0xb3, 0xf1, 0x55,
+ 0x2e, 0x2c, 0x86, 0xa3, 0xed, 0x36, 0x1b, 0x78,
+ 0x48, 0x76, 0xa9, 0x3b, 0x97, 0xd1, 0x7a, 0x93,
+ 0x07, 0x0e};
#endif
static u8 bch4_polynomial[] = {0x28, 0x13, 0xcc, 0x39, 0x96, 0xac, 0x7f};
static u8 bch8_polynomial[] = {0xef, 0x51, 0x2e, 0x09, 0xed, 0x93, 0x9a, 0xc2,
@@ -1066,6 +1070,19 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
eccsize1 = 28; /* OOB bits in nibbles per sector */
}
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ ecc_algo = 0x1;
+ bch_type = 0x2;
+ if (mode == GPMC_ECC_READ) {
+ bch_wrapmode = 0x01;
+ eccsize0 = 52; /* ECC bits in nibbles per sector */
+ eccsize1 = 0; /* non-ECC bits in nibbles per sector */
+ } else if (mode == GPMC_ECC_WRITE) {
+ bch_wrapmode = 0x01;
+ eccsize0 = 0; /* extra bits in nibbles per sector */
+ eccsize1 = 52; /* OOB bits in nibbles per sector */
+ }
+ break;
default:
pr_err(selected ECC scheme not supported or not enabled\n);
}
@@ -1159,6 +1176,41 @@ static int omap_calculate_ecc_bch(struct mtd_info *mtd,
const u_char *dat,
*(ecc_ptr++) = ((val 8) 0xFF);
*(ecc_ptr++) = ((val 0) 0xFF);
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ val = readl(gpmc_regs-gpmc_bch_result6[i]);
+ *(ecc_ptr++) = ((val 8) 0xFF);
+ *(ecc_ptr++) = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result5[i]);
+ *(ecc_ptr++) = ((val 24) 0xFF);
+ *(ecc_ptr++) = ((val 16) 0xFF);
+ *(ecc_ptr++) = ((val 8) 0xFF);
+ *(ecc_ptr++) = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result4[i]);
+ *(ecc_ptr++) = ((val 24) 0xFF);
+ *(ecc_ptr++) = ((val 16) 0xFF);
+ *(ecc_ptr++) = ((val 8) 0xFF);
+ *(ecc_ptr++) = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result3[i]);
+ *(ecc_ptr++) = ((val 24) 0xFF);
+ *(ecc_ptr++) = ((val 16) 0xFF);
+ *(ecc_ptr++) = ((val 8) 0xFF);
+ *(ecc_ptr++) = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result2[i]);
+ *(ecc_ptr++) = ((val 24) 0xFF);
+ *(ecc_ptr++) = ((val 16) 0xFF);
+ *(ecc_ptr++) = ((val 8) 0xFF);
+ *(ecc_ptr++) = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result1[i]);
+ *(ecc_ptr++) = ((val 24) 0xFF);
+ *(ecc_ptr++) = ((val 16) 0xFF);
+ *(ecc_ptr++) = ((val 8) 0xFF);
+ *(ecc_ptr++) = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result0[i]);
+ *(ecc_ptr++) = ((val 24) 0xFF);
+ *(ecc_ptr++) = ((val 16) 0xFF);
+
[PATCH v1 3/4] mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates
With increase in NAND flash densities occurence of bit-flips has increased.
Thus stronger ECC schemes are required for detecting and correcting multiple
simultaneous bit-flips in same NAND page. But stronger ECC schemes have large
ECC syndrome which require more space in OOB/Spare.
This patch add support for BCH16_ECC:
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page = 26 * (page-size / 512)
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index e19de21..0d5639e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -68,6 +68,9 @@
#defineGPMC_ECC_BCH_RESULT_1 0x244 /* not available on OMAP2 */
#defineGPMC_ECC_BCH_RESULT_2 0x248 /* not available on OMAP2 */
#defineGPMC_ECC_BCH_RESULT_3 0x24c /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_4 0x300 /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_5 0x304 /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_6 0x308 /* not available on OMAP2 */
/* GPMC ECC control settings */
#define GPMC_ECC_CTRL_ECCCLEAR 0x100
@@ -659,13 +662,19 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int
cs)
for (i = 0; i GPMC_BCH_NUM_REMAINDER; i++) {
reg-gpmc_bch_result0[i] = gpmc_base + GPMC_ECC_BCH_RESULT_0 +
- GPMC_BCH_SIZE * i;
+ (GPMC_BCH_SIZE * i);
reg-gpmc_bch_result1[i] = gpmc_base + GPMC_ECC_BCH_RESULT_1 +
- GPMC_BCH_SIZE * i;
+ (GPMC_BCH_SIZE * i);
reg-gpmc_bch_result2[i] = gpmc_base + GPMC_ECC_BCH_RESULT_2 +
- GPMC_BCH_SIZE * i;
+ (GPMC_BCH_SIZE * i);
reg-gpmc_bch_result3[i] = gpmc_base + GPMC_ECC_BCH_RESULT_3 +
- GPMC_BCH_SIZE * i;
+ (GPMC_BCH_SIZE * i);
+ reg-gpmc_bch_result4[i] = gpmc_base + GPMC_ECC_BCH_RESULT_4 +
+ (GPMC_BCH_SIZE * i);
+ reg-gpmc_bch_result5[i] = gpmc_base + GPMC_ECC_BCH_RESULT_5 +
+ (GPMC_BCH_SIZE * i);
+ reg-gpmc_bch_result6[i] = gpmc_base + GPMC_ECC_BCH_RESULT_6 +
+ (GPMC_BCH_SIZE * i);
}
}
@@ -1348,7 +1357,8 @@ static const char * const nand_ecc_opts[] = {
[OMAP_ECC_BCH4_CODE_HW] = bch4_code_hw,
[OMAP_ECC_BCH4_CODE_HW_DETECTION_SW]= bch4_code_hw_detection_sw,
[OMAP_ECC_BCH8_CODE_HW] = bch8_code_hw,
- [OMAP_ECC_BCH8_CODE_HW_DETECTION_SW]= bch8_code_hw_detection_sw
+ [OMAP_ECC_BCH8_CODE_HW_DETECTION_SW]= bch8_code_hw_detection_sw,
+ [OMAP_ECC_BCH16_CODE_HW]= bch16_code_hw
};
static const char * const nand_xfer_types[] = {
@@ -1389,7 +1399,7 @@ static int gpmc_probe_nand_child(struct platform_device
*pdev,
if (!of_property_read_string(child, ti,nand-xfer-type, s))
for (val = 0; val ARRAY_SIZE(nand_xfer_types); val++)
- if (!strcasecmp(s, nand_xfer_types[val])) {
+ if (!strcmp(s, nand_xfer_types[val])) {
gpmc_nand_data-xfer_type = val;
break;
}
--
1.8.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/4] pinctrl: Allow pinctrl to have multiple active states
On 07/16/2013 03:05 AM, Tony Lindgren wrote:
It's quite common that we need to dynamically change some pins for a
device for runtime PM, or toggle a pin between rx and tx. Changing all
the pins for a device is not efficient way of doing it.
So let's allow setting up multiple active states for pinctrl. Currently
we only need PINCTRL_STATIC and PINCTRL_DYNAMIC, where PINCTRL_STATIC
covers the current default pins, and PINCTRL_DYNAMIC holds the dynamic
pins that need to be toggled.
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
+enum pinctr_states {
s/pinctr/pinctrl/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] pinctrl: Add support for additional dynamic states
On 07/16/2013 03:05 AM, Tony Lindgren wrote:
To toggle dynamic states, let's add the optional active state in
addition to the static default state. Then if the optional active
state is defined, we can require that idle and sleep states cover
the same pingroups as the active state.
Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
to use instead of pinctrl_select() to avoid breaking existing users.
With pinctrl_check_dynamic() we can check that idle and sleep states
match the active state for pingroups during init, and don't need to
do it during runtime.
Then with the states pre-validated, pinctrl_select_dynamic() can
just toggle between the dynamic states without extra checks.
Note that pinctr_select_state() still has valid use cases, such as
changing states when the pins can be shared between two drivers
and don't necessarily cover the same pingroups. For dynamic runtime
toggling of pin states, we should eventually always use just
pinctrl_select_dynamic().
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
@@ -887,6 +887,8 @@ static void pinctrl_free(struct pinctrl *p, bool inlist)
list_for_each_entry_safe(setting, n2, state-settings, node) {
pinctrl_free_setting(state == p-state[PINCTRL_STATIC],
setting);
+ pinctrl_free_setting(state == p-state[PINCTRL_DYNAMIC],
+ setting);
This will cause pinmux_free_setting() or pinconf_free_setting() to be
called twice on the setting object. Right now they don't do anything,
but if they start to kfree() some dynamically-allocated data that's
stored within the setting, that'll cause problems. I would suggest a
loop body something more like:
bool disable_setting = state == XXX || state == YYY;
pinctrl_free_setting(disable_setting, setting);
+int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
+ struct pinctrl_state *st2)
+{
+ struct pinctrl_setting *s1, *s2;
+
+ list_for_each_entry(s1, st1-settings, node) {
...
+ list_for_each_entry(s2, st2-settings, node) {
...
+ if (pctldev1 != pctldev2) {
+ dev_dbg(dev, pctldev must be the same for
states\n);
+ return -EINVAL;
+ }
I don't think we should require that; it's perfectly legal at the moment
for some device's pinctrl configuration to include settings from
multiple different pin controllers.
+ for (i = 0; i num_pins1; i++) {
+ int pin1 = pins1[i];
+
+ for (j = 0; j num_pins2; j++) {
+ int pin2 = pins2[j];
+
+ if (pin1 == pin2) {
+ found++;
+ break;
+ }
+ }
+ }
+
+ if (found != num_pins1) {
I guess this make sure that every entry in the dynamic state is in the
state state, but not vice-versa; the static state can affect more stuff
than the dynamic state?
If so, shouldn't that check be if (found != num_pins2)?
+int pinctrl_select_dynamic(struct pinctrl *p, struct pinctrl_state *state)
The body of this function is rather duplicated with pinctrl_select().
@@ -1241,7 +1371,13 @@ static int pinctrl_pm_select_state(struct device *dev,
struct pinctrl_state *sta
return 0;
if (IS_ERR(state))
return 0; /* No such state */
- ret = pinctrl_select_state(pins-p, state);
+
+ /* Configured for proper dynamic muxing? */
I don't think proper is correct here; it's just fine not to have any
dynamic configuration.
+ if (!IS_ERR(dev-pins-active_state))
+ ret = pinctrl_select_dynamic(pins-p, state);
+ else
+ ret = pinctrl_select_state(pins-p, state);
Hmmm. I'm not quite sure this is right... Surely this function should
just do nothing if the dynamic states aren't defined? The system should
just, and only, be in the default state and never do anything else.
Looking back at patch 1, I see the are
pinctrl_pm_select_{default,sleep,idle}_state(). Shouldn't that list be
active/sleep/idle, since I assume default is that static state, and
the other three are the dynamic states?
+static int pinctrl_pm_check_state(struct device *dev,
+ struct pinctrl_state *state)
Naming this pinctrl_pm_is_state_error() or pinctrl_pm_is_state_ok()
might give more clue what its return value is expected to be.
--
To unsubscribe from this list: send the line unsubscribe 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 4/4] drivers: Add pinctrl handling for dynamic pin states
On 07/16/2013 03:05 AM, Tony Lindgren wrote:
We want to have static pin states handled separately from
dynamic pin states, so let's add optional state_active.
Then if state_active is defined, let's check and make sure
state_idle and state_sleep match state_active for the
pin groups to avoid checking them during runtime as the
active and idle pins may need to be toggled for many
devices every time we enter and exit idle.
+ * Note that if active state is defined, sleep and idle states must
+ * cover the same pin groups as active state.
*/
dev-pins-sleep_state = pinctrl_lookup_state(dev-pins-p,
PINCTRL_STATE_SLEEP);
- if (IS_ERR(dev-pins-sleep_state))
+ if (IS_ERR(dev-pins-sleep_state)) {
/* Not supplying this state is perfectly legal */
dev_dbg(dev, no sleep pinctrl state\n);
+ } else if (!IS_ERR(dev-pins-active_state)) {
+ ret = pinctrl_check_dynamic(dev, dev-pins-active_state,
+ dev-pins-sleep_state);
Oh, I see you're trying to check that the set of pins in the active,
sleep, and idle states are identical.
But I think that pinctrl_check_dynamic() only checks that one state is a
subset of the other, not that the two states are equal. Instead, I think
you want to comparison coded in pinctrl_check_dynamic() to be:
gen_group_list_of_pinctrl_state(s1, array1);
gen_group_list_of_pinctrl_state(s2, array2);
mismatch = memcmp(array1, array2, length);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] pinctrl: Add support for additional dynamic states
On 07/16/2013 03:05 AM, Tony Lindgren wrote: To toggle dynamic states, let's add the optional active state in addition to the static default state. Then if the optional active state is defined, we can require that idle and sleep states cover the same pingroups as the active state. Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic() to use instead of pinctrl_select() to avoid breaking existing users. With pinctrl_check_dynamic() we can check that idle and sleep states match the active state for pingroups during init, and don't need to do it during runtime. Then with the states pre-validated, pinctrl_select_dynamic() can just toggle between the dynamic states without extra checks. Note that pinctr_select_state() still has valid use cases, such as changing states when the pins can be shared between two drivers and don't necessarily cover the same pingroups. For dynamic runtime toggling of pin states, we should eventually always use just pinctrl_select_dynamic(). Something in this series should edit Documentation/pinctrl.txt to explain the philosophy behind the static/dynamic state split. That philosophy and/or semantics are more important to review than the code... Related to that, I'm worried that using pinctrl_select_state() and pinctrl_select_dynamic() appear to be mutually-exclusive options here. Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime PM? Does the mux setting select which states are used for runtime PM, or does runtime PM override the basic mux setting, or must the pincrl-I2C mux manually implement custom runtime-PM/pinctrl interaction since there's no generic answer to those questions? How many more custom exceptions will there be? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: dts: Use the PWM polarity flags
Replace the numerical polarity flags with the PWM_POLARITY_INVERTED
symbolic constant.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 3 ++-
arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..62124c7 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include am33xx.dtsi
+#include dt-bindings/pwm/pwm.h
/ {
model = TI AM335x EVM-SK;
@@ -298,7 +299,7 @@
backlight {
compatible = pwm-backlight;
- pwms = ecap2 0 5 1;
+ pwms = ecap2 0 5 PWM_POLARITY_INVERTED;
brightness-levels = 0 58 61 66 75 90 125 170 255;
default-brightness-level = 8;
};
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts
b/arch/arm/boot/dts/wm8850-w70v2.dts
index 90e913f..7a563d2 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -11,13 +11,14 @@
/dts-v1/;
/include/ wm8850.dtsi
+#include dt-bindings/pwm/pwm.h
/ {
model = Wondermedia WM8850-W70v2 Tablet;
backlight {
compatible = pwm-backlight;
- pwms = pwm 0 5 1;/* duty inverted */
+ pwms = pwm 0 5 PWM_POLARITY_INVERTED;
brightness-levels = 0 40 60 80 100 130 190 255;
default-brightness-level = 5;
--
1.8.1.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 v2 0/4] Add PWM polarity flag macro for DT
Hello, Here's a small patch set that replaces PWM polarity numerical constants with macros in DT. The series is the result of splitting the original patch into four patches that - add the flag macro (both in a header file and in the PWM DT binding core documentation) - use the macro in the PWM core code - update existing DT bindings to refer to the PWM DT bindings core documentation - update existing DT sources to use the new macro I believe I've taken all comments received so far into account. Most notable changes include - splitting the original patch - removing the PWM_POLARITY_NORMAL flag, which wasn't a flag but was defined as 0 - renaming the PWM_POLARITY_INVERSED DT flag to PWM_POLARITY_INVERTED - not relying on DT flags and PWM C flags having identical names and values Laurent Pinchart (4): pwm: Add PWM polarity flag macro for DT pwm: Use the DT macro directly when parsing PWM DT flags pwm: Update DT bindings to reference pwm.txt for cells documentation ARM: dts: Use the PWM polarity flags Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt| 8 +++- Documentation/devicetree/bindings/pwm/imx-pwm.txt | 4 ++-- Documentation/devicetree/bindings/pwm/mxs-pwm.txt | 4 ++-- .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 5 ++--- Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt | 4 ++-- Documentation/devicetree/bindings/pwm/pwm-samsung.txt | 10 +++--- Documentation/devicetree/bindings/pwm/pwm-tiecap.txt | 8 +++- Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 8 +++- Documentation/devicetree/bindings/pwm/pwm.txt | 7 --- Documentation/devicetree/bindings/pwm/spear-pwm.txt| 5 ++--- Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt | 4 ++-- Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt| 4 ++-- Documentation/devicetree/bindings/pwm/vt8500-pwm.txt | 8 +++- arch/arm/boot/dts/am335x-evmsk.dts | 3 ++- arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++- drivers/pwm/core.c | 7 +++ include/dt-bindings/pwm/pwm.h | 14 ++ 17 files changed, 54 insertions(+), 52 deletions(-) create mode 100644 include/dt-bindings/pwm/pwm.h -- 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 v2 2/4] pwm: Use the DT macro directly when parsing PWM DT flags
Don't redefine a PWM_SPEC_POLARITY macro with a value identical to PWM_POLARITY_INVERTED, use the PWM DT macro directly. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- drivers/pwm/core.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index dfbfbc5..2ca9504 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -30,10 +30,9 @@ #include linux/debugfs.h #include linux/seq_file.h -#define MAX_PWMS 1024 +#include dt-bindings/pwm/pwm.h -/* flags in the third cell of the DT PWM specifier */ -#define PWM_SPEC_POLARITY (1 0) +#define MAX_PWMS 1024 static DEFINE_MUTEX(pwm_lookup_lock); static LIST_HEAD(pwm_lookup_list); @@ -149,7 +148,7 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args) pwm_set_period(pwm, args-args[1]); - if (args-args[2] PWM_SPEC_POLARITY) + if (args-args[2] PWM_POLARITY_INVERTED) pwm_set_polarity(pwm, PWM_POLARITY_INVERSED); else pwm_set_polarity(pwm, PWM_POLARITY_NORMAL); -- 1.8.1.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 v2 3/4] pwm: Update DT bindings to reference pwm.txt for cells documentation
The PWM client cells format is documented in the generic pwm.txt documentation and duplicated in all PWM driver bindings. Remove duplicate information and reference pwm.txt instead. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 8 +++- Documentation/devicetree/bindings/pwm/imx-pwm.txt| 4 ++-- Documentation/devicetree/bindings/pwm/mxs-pwm.txt| 4 ++-- Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 5 ++--- Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt| 4 ++-- Documentation/devicetree/bindings/pwm/pwm-samsung.txt| 10 +++--- Documentation/devicetree/bindings/pwm/pwm-tiecap.txt | 8 +++- Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 8 +++- Documentation/devicetree/bindings/pwm/spear-pwm.txt | 5 ++--- Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt | 4 ++-- Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt | 4 ++-- Documentation/devicetree/bindings/pwm/vt8500-pwm.txt | 8 +++- 12 files changed, 29 insertions(+), 43 deletions(-) diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index de0eaed..8031148 100644 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -2,11 +2,9 @@ Atmel TCB PWM controller 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. +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. The only third cell flag supported by this binding is + PWM_POLARITY_INVERTED. - tc-block: The Timer Counter block to use as a PWM chip. Example: diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt index 8522bfb..b50d7a6d 100644 --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt @@ -3,8 +3,8 @@ Freescale i.MX PWM controller Required properties: - compatible: should be fsl,soc-pwm - reg: physical base address and length of the controller's registers -- #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. - interrupts: The interrupt for the pwm controller Example: diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt index 9e3f8f1..96cdde5 100644 --- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt @@ -3,8 +3,8 @@ Freescale MXS PWM controller Required properties: - compatible: should be fsl,imx23-pwm - reg: physical base address and length of the controller's registers -- #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. - fsl,pwm-number: the number of PWM devices Example: diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt index 01438ec..c3fc57a 100644 --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt @@ -5,9 +5,8 @@ Required properties: - nvidia,tegra20-pwm - nvidia,tegra30-pwm - reg: physical base address and length of the controller's registers -- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The - first cell specifies the per-chip index of the PWM to use and the second - cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. Example: diff --git a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt index 1e3dfe7..f84ec9d 100644 --- a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt @@ -3,8 +3,8 @@ NXP PCA9685 16-channel 12-bit PWM LED controller Required properties: - compatible: nxp,pca9685-pwm - - #pwm-cells: should be 2. The first cell specifies the per-chip index -of the PWM to use and the second cell is the period in nanoseconds. + - #pwm-cells: Should be 2.
[PATCH v2 1/4] pwm: Add PWM polarity flag macro for DT
Define a PWM_POLARITY_INVERTED macro in include/dt-bindings/pwm/pwm.h to
be used by device tree sources.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
Documentation/devicetree/bindings/pwm/pwm.txt | 7 ---
include/dt-bindings/pwm/pwm.h | 14 ++
2 files changed, 18 insertions(+), 3 deletions(-)
create mode 100644 include/dt-bindings/pwm/pwm.h
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt
b/Documentation/devicetree/bindings/pwm/pwm.txt
index 06e6724..8556263 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -43,13 +43,14 @@ 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/pwm/pwm.h) in a third cell:
+- PWM_POLARITY_INVERTED: invert the PWM signal polarity
Example with optional PWM specifier for inverse polarity
bl: backlight {
- pwms = pwm 0 500 1;
+ pwms = pwm 0 500 PWM_POLARITY_INVERTED;
pwm-names = backlight;
};
diff --git a/include/dt-bindings/pwm/pwm.h b/include/dt-bindings/pwm/pwm.h
new file mode 100644
index 000..96f49e8
--- /dev/null
+++ b/include/dt-bindings/pwm/pwm.h
@@ -0,0 +1,14 @@
+/*
+ * 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_INVERTED (1 0)
+
+#endif
--
1.8.1.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] Documentation: dt: bindings: TI WiLink modules
Hi Luciano,
On Monday 01 July 2013 15:39:30 Luciano Coelho wrote:
On Fri, 2013-06-28 at 16:21 +0300, Luciano Coelho wrote:
On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
(fixed Mike's address)
On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho
wrote:
On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho
wrote:
+Optional properties:
+
+
+- refclock: the internal WLAN reference clock frequency
(required for
+ WiLink6 and WiLink7; not used for WiLink8). Must be
one of the
+ following:
+ 0 = 19.2 MHz
+ 1 = 26.0 MHz
+ 2 = 38.4 MHz
+ 3 = 52.0 MHz
+ 4 = 38.4 MHz, XTAL
+ 5 = 26.0 MHz, XTAL
+
+- tcxoclock: the internal WLAN TCXO clock frequency
(required for
+ WiLink7 not used for WiLink6 and WiLink8). Must be
one of the
+ following:
+ 0 = 19.200 MHz
+ 1 = 26.000 MHz
+ 2 = 38.400 MHz
+ 3 = 52.000 MHz
+ 4 = 16.368 MHz
+ 5 = 32.736 MHz
+ 6 = 16.800 MHz
+ 7 = 33.600 MHz
This looks suspiciously like what we have the common clock
bindings for:
refclk {
compatible = fixed-clock;
#clock-cells = 0;
clock-frequency = 1920;
}
wilink {
compatible = ti,wilink7;
interrupt-parent = some_interrupt_controller;
interrupts = 0 1 1;
clocks = refclk, refclk;
clock-names = refclk, txoclk;
};
Could you not use them?
Hmmm... this actually does look good. But these are
internal clocks in the modules, they cannot be accessed from
outside. Does it make sense to register them with the clock
framework?
Given we already have a common way of describing clocks, I
think it makes sense to use it -- people already understand
the common bindings, and it's less code to add add to the
kernel. I don't think the fact these clocks are internal
should prevent us from describing them as we would an external
clock.
Yes, I agree with you. Thanks for the suggestion! I think it
will look much better. And now that I dug a bit more into the
code, I can see that there are only structs being populated, so
there shouldn't be any other side-effects.
Hmmm, one thing that escaped me. Besides the frequency, I also
need a boolean that tells if the clock is XTAL or not. I can't
figure out how to pass this if I use the generic clock framework.
Any suggestions?
Could you use clock-output-names for that ?
XTAL clock:
refclk {
compatible = fixed-clock;
#clock cells = 0;
clock-frequency = 1920;
clock-output-names = xtal;
};
non-XTAL clock:
refclk {
compatible = fixed-clock;
#clock cells = 0;
clock-frequency = 1920;
clock-output-names = osc; /* any better name ? */
};
This starts looking a bit hacky. Using the output name as a flag is
not very pretty.
I think it would be better to have a separate flag for it in the wlan
node. Like an optional refclock-xtal boolean or something. The
downside of this is that we would be adding information about the
clock details in the wilink node. :(
OTOH, we could add a flag to the generic clock binding? A new optional
boolean that tells whether the clock is XTAL or not:
refclk {
compatible = fixed-clock;
#clock cells = 0;
clock-frequency = 1920;
clock-xtal;
};
Do you think that would make sense?
sure, that looks alright to me. Surely there are other devices out there
who want to know if the clock comes from a crystal or not ?!?
Mike, what do you think about this idea? If it sounds okay to you, I can
cook up a patch adding this flag.
Hmmm... I started implementing this whole thing, but using these clocks
as fixed-clocks is not so straightforward. The problem is that I
would need to register my driver as a
About omap2 mmc host close too long irq in irqaction.
Hi all,
Now i worked on omp2 and met a probelm which someplace close_irq for
3.6second.
The kernel version is 2.6.37. I used trace to find in irq_action:omap_hsmmc_irq.
This problem occured by removed the sdcard when there are io operations.
I found the read problem is in omap_hsmmc_reset_controller_fsm.
In omap_hsmmc_reset_controller_fsm:
static inline void omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host
*host,
unsigned long bit)
{
unsigned long i = 0;
unsigned long limit = (loops_per_jiffy *
msecs_to_jiffies(MMC_TIMEOUT_MS));
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | bit);
/*
* OMAP4 ES2 and greater has an updated reset logic.
* Monitor a 0-1 transition first
*/
if (mmc_slot(host).features HSMMC_HAS_UPDATED_RESET) {
while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
(i++ limit))
cpu_relax();
}
In func, it used loops_per_jiffy in order to avoid do many time exceed
MMC_TIMEOUT_MS.
In face oops_per_jiify is like:
while(i++ loops_per_jiffy)
cpu_relax();
But actually, it used as follow:
while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
(i++ limit))
it add some operations like: read regisger, , .
So the time may exceed MMC_TIMEOUT_MS.
I used those code to test and found it's ok:
for (i = 0 ; i 10; i++){
if (!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
break;
j = limit/10;
while(j--)
cpu_relax();
}
Using this the problom can't occur.
Am i missing something?
Thanks!
Jianpeng Ma
