Sekhar Nori wrote at Tuesday, July 01, 2014 3:52 AM:
Nick,
I have been using your for-next branch to base my development of
touchscreen support on TI's DRA7x EVM. With the recent updates,
it has worked out great and once I got the configuration right,
it was just a question of adding DT
, with the exception of
the movs instruction and the kprobes code. This allows us to detect
the mov pc, lr case and fix it up - and also gives us the possibility
of deploying this for other registers depending on the CPU selection.
Tested-by: Stephen Warren swar...@nvidia.com
(On an NVIDIA
:
https://github.com/nmenon/linux-2.6-playground/commits/broonie-topic-palmas-fixes
The series,
Tested-by: Stephen Warren swar...@nvidia.com
(An NVIDIA Dalmore board boots and shuts down OK with these applied on
top of next-20140630, and various peripherals such as LCD panel, audio,
USB, and SPI
On 06/20/2014 11:26 AM, Nishanth Menon wrote:
We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.
Currently we do not populate these for SMPS other
On 06/23/2014 02:11 PM, Nishanth Menon wrote:
On Mon, Jun 23, 2014 at 2:50 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/20/2014 11:26 AM, Nishanth Menon wrote:
We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend
From: Stephen Warren swar...@nvidia.com
When setting up .enable_reg for an SMPS regulator, presumably we should
call PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE, ...) rather than using
LDO_BASE. This change makes the LCD panel and HDMI work again on the
NVIDIA Dalmore board anyway.
Cc: Alex Courbot gnu
On 06/23/2014 02:20 PM, Stephen Warren wrote:
On 06/23/2014 02:11 PM, Nishanth Menon wrote:
On Mon, Jun 23, 2014 at 2:50 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 06/20/2014 11:26 AM, Nishanth Menon wrote:
We use regmap regulator ops to enable/disable and check if regulator
On 06/10/2014 05:48 PM, Brian Norris wrote:
On Wed, Jun 11, 2014 at 01:34:39AM +0200, Thomas Gleixner wrote:
On Tue, 10 Jun 2014, Brian Norris wrote:
Other random thought: it seems like any irqchip driver which does lazy IRQ
masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core
From: Stephen Warren swar...@nvidia.com
This is the same change as commit fb6b8e71448a ASoC: tegra: free jack
GPIOs before the sound card is freed, but applied to all other ASoC
machine drivers where code inspection indicates the same problem exists.
That commit's description
On 04/28/2014 06:02 PM, Simon Horman wrote:
On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote:
Since we now automatically enable early BRESP in core L2C-310 code when
we detect a Cortex-A9, we don't need platforms/SoCs to set this bit
explicitly. Instead, they should seek to
.
Acked-by: Stephen Warren swar...@nvidia.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
control register definitions.
Acked-by: Stephen Warren swar...@nvidia.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
On 04/09/2014 07:57 AM, Sergei Shtylyov wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY
On 04/09/2014 10:27 AM, Sergei Shtylyov wrote:
Hello.
On 04/09/2014 07:31 PM, Stephen Warren wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we
On 04/09/2014 10:53 AM, Sergei Shtylyov wrote:
On 04/09/2014 08:48 PM, Stephen Warren wrote:
Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should
On 04/09/2014 12:16 PM, Sergei Shtylyov wrote:
Hello.
On 04/09/2014 09:56 PM, Alan Stern wrote:
Ok, the existing field is being replaced by something? I didn't get
that
No, not replaced. I'm adding the support for generic PHY to the
existing
USB PHY support. I thought that was
On 01/27/2014 08:12 PM, Manish Badarkhe wrote:
Update the code to use devm_* API so that driver core will manage
resources.
I'm not sure why this patch is sent to linux-te...@vger.kernel.org; it
seems nothing to do with Tegra (or Samsung or OMAP for that matter).
--
To unsubscribe from this
On 11/21/2013 11:36 AM, Mark Brown wrote:
On Thu, Nov 21, 2013 at 09:43:03AM -0700, Stephen Warren wrote:
FYI, the way I deal with this is that my preferred email account
subscribes to the mailing list, and I have a filter such that
anything that's to/cc either *that* email address *or* any
On 11/21/2013 03:49 AM, Mark Brown wrote:
On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote:
actually, I didn't miss you at all. your broo...@linaro.org was
in Cc of original email thread. The same email which was used to
sign-off on original commit.
It's not what's advertised
On 11/08/2013 11:00 AM, Felipe Balbi wrote:
From: Luciano Coelho l...@coelho.fi
Add a flag that indicate whether the clock is a crystal or not.
Additionally, parse a new device tree binding in clk-fixed-rate to set
this flag.
If clock-xtal isn't set, the clock framework will assume
On 10/20/2013 01:41 PM, Laurent Pinchart wrote:
Hi Grant,
On Tuesday 17 September 2013 17:36:32 Grant Likely wrote:
On Thu, 12 Sep 2013 17:57:00 +0200, Alexander Holler wrote:
Am 12.09.2013 17:19, schrieb Stephen Warren:
IRQs, DMA channels, and GPIOs are all different things. Their bindings
On 09/23/2013 03:40 PM, Thierry Reding wrote:
In preparation for adding an optional regulator and enable GPIO to the
driver, split the power on and power off sequences into separate
functions to reduce code duplication at the multiple call sites.
diff --git a/drivers/video/backlight/pwm_bl.c
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
static void __init smdkv210_map_io(void)
@@ -70,6 +70,7 @@ static struct samsung_bl_drvdata samsung_dfl_bl_data
__initdata = {
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Make use of the new enable_gpio field and allow it to be set from DT as
well. Now that all legacy users of platform data have been converted to
initialize this field to an invalid value, it is safe to use the field
from the driver.
diff --git
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This commit
uses a power-supply regulator, if available, to power up and power down
the panel.
I think that all backlights require a power supply, albeit the supply
may not be
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The default for backlight devices is to be enabled immediately when
registering with the backlight core. This can be useful for setups that
use a simple framebuffer device and where the backlight cannot otherwise
be hooked up to the panel.
On 10/01/2013 02:43 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:31:04PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this
field needs to be initialized explicitly.
static void __init
On 10/01/2013 02:53 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:43:57PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This
commit uses a power-supply regulator, if available, to power up
and power
On 09/24/2013 10:52 AM, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device
to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
FWIW, the concept of this patch,
Acked-by: Stephen Warren swar...@nvidia.com
I didn't review the code; just skimmed it to see where the new
On 09/23/2013 05:46 PM, Sebastian Reichel wrote:
Hi,
On Mon, Sep 23, 2013 at 02:35:35PM -0600, Stephen Warren wrote:
On 09/15/2013 02:44 PM, Sebastian Reichel wrote:
Add SSI device tree data for OMAP34xx and Nokia N900.
...
+- ti,hwmods: Name of the hwmod associated
On 09/22/2013 08:40 AM, Javier Martinez Canillas wrote:
To use a GPIO pin as an interrupt line, two previous configurations
have to be made:
a) Map the GPIO pin as an interrupt line into the Linux irq space
b) Enable the GPIO bank and configure the GPIO direction as input
Most GPIO/IRQ
On 09/15/2013 02:44 PM, Sebastian Reichel wrote:
Add SSI device tree data for OMAP34xx and Nokia N900.
What is an SSI device, ...
diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt
b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
... and what is the HSI subsystem?
+OMAP
with it?
Aside from that, the binding,
Acked-by: Stephen Warren swar...@nvidia.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
On 09/12/2013 05:37 AM, Alexander Holler wrote:
Am 12.09.2013 13:26, schrieb Alexander Holler:
Am 12.09.2013 13:09, schrieb Alexander Holler:
Am 12.09.2013 12:28, schrieb Alexander Holler:
Am 12.09.2013 12:11, schrieb Javier Martinez Canillas:
On 09/12/2013 10:55 AM, Alexander Holler wrote:
On 08/29/2013 05:48 AM, George Cherian wrote:
On 8/29/2013 4:07 PM, Chanwoo Choi wrote:
...
I tested various development board based on Samsung Exynos series SoC.
Although some gpio of Exynos series SoC set high state(non zero, 1) as
default value,
this gpio state could mean off state,
On 08/28/2013 11:33 AM, George Cherian wrote:
Add a generic USB VBUS/ID detection EXTCON driver. This driver expects
the ID/VBUS pin are connected via GPIOs. This driver is tested on
DRA7x board were the ID pin is routed via GPIOs. The driver supports
both VBUS and ID pin configuration and ID
On 08/28/2013 11:33 AM, George Cherian wrote:
Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
dwc3_1 {
- dr_mode = otg;
+ dr_mode =
On 08/22/2013 07:17 PM, Richard Zhao wrote:
On Fri, Aug 23, 2013 at 04:36:53AM +0800, Stephen Warren wrote:
On 08/22/2013 12:43 AM, Richard Zhao wrote:
DMA client device driver usually needs to know at probe time whether
dma controller has been registered to deffer probe. So add a help
On 08/22/2013 07:29 PM, Richard Zhao wrote:
On Fri, Aug 23, 2013 at 04:18:27AM +0800, Stephen Warren wrote:
On 08/21/2013 11:19 PM, Richard Zhao wrote:
On Fri, Aug 02, 2013 at 10:00:00AM +0800, Richard Zhao wrote:
pass of_phandle_args dma_spec to dma_request_channel in
of_dma_simple_xlate
On 08/23/2013 05:28 AM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 23 August 2013 02:20 AM, Stephen Warren wrote:
On 08/22/2013 02:31 AM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VBUS-ID detector, so added a
compatible type *ti,palmas-usb-vid*. Didn't remove
On 08/21/2013 11:19 PM, Richard Zhao wrote:
On Fri, Aug 02, 2013 at 10:00:00AM +0800, Richard Zhao wrote:
pass of_phandle_args dma_spec to dma_request_channel in of_dma_simple_xlate,
so the filter function could access of_node in of_phandle_args.
It also remove restriction of #dma-cells has
On 08/22/2013 12:43 AM, Richard Zhao wrote:
DMA client device driver usually needs to know at probe time whether
dma controller has been registered to deffer probe. So add a help
function of_dma_check_controller.
DMA request channel functions can also used to check it, but they
are usually
On 08/22/2013 02:31 AM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VBUS-ID detector, so added a
compatible type *ti,palmas-usb-vid*. Didn't remove the existing compatible
types for backward compatibility.
diff --git
On 08/21/2013 07:06 AM, George Cherian wrote:
Hi Stephen,
On 8/20/2013 10:23 PM, Stephen Warren wrote:
ID pins are connected to pcf8575, and the pcf8575's interrupt line is
inturn connected to
gpio bank6 pin 11, we use this gpio interrupt to detect the ID pin
change.
In that case
On 08/20/2013 12:55 AM, George Cherian wrote:
Hi Stephen,
Thanks for your review.
On 8/20/2013 1:01 AM, Stephen Warren wrote:
On 08/16/2013 04:13 AM, George Cherian wrote:
Adding extcon driver for USB ID detection to dynamically
configure USB Host/Peripheral mode.
diff --git
On 08/18/2013 11:05 PM, Kishon Vijay Abraham I wrote:
Hi,
On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote:
On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VID detector, so modified the
compatible type to *ti,palmas-usb-vid*.
diff --git
On 08/19/2013 06:27 AM, Ivan T. Ivanov wrote:
Hi,
On Fri, 2013-08-16 at 16:44 -0600, Stephen Warren wrote:
On 08/14/2013 06:59 AM, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control
On 08/16/2013 04:13 AM, George Cherian wrote:
Adding extcon driver for USB ID detection to dynamically
configure USB Host/Peripheral mode.
diff --git a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
+EXTCON FOR DRA7xx
On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VID detector, so modified the
compatible type to *ti,palmas-usb-vid*.
diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
On 08/16/2013 04:17 AM, Benoit Cousson wrote:
Hi Afzal,
On 12/08/2013 08:48, Afzal Mohammed wrote:
Hi Mark,
On Saturday 10 August 2013 07:53 PM, Mark Rutland wrote:
+mac: ethernet@4a10 {
+compatible = ti,am4372-cpsw,ti,cpsw;
One point worth mentioning is that
On 08/13/2013 11:24 PM, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 14 August 2013 12:43 AM, Stephen Warren wrote:
On 08/12/2013 11:37 PM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VID detector, so added a
compatible type *ti,palmas-usb-vid*. Dint remove
On 08/12/2013 11:37 PM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VID detector, so added a
compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible
s/Dint/Didn't/
diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
On 08/09/2013 03:53 AM, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS)
and HS, SS PHY's controll and configuration registers.
s/controll/control/
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
On 08/12/2013 04:17 AM, Kishon Vijay Abraham I wrote:
From: Felipe Balbi ba...@ti.com
Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
On 08/02/2013 06:06 AM, Santosh Shilimkar wrote:
On Thursday 01 August 2013 10:00 PM, Richard Zhao wrote:
pass of_phandle_args dma_spec to dma_request_channel in of_dma_simple_xlate,
so the filter function could access of_node in of_phandle_args.
Am just curious the reasoning behind doing so.
On 07/31/2013 12:46 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130730 16:08]:
On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote:
On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
DEBUG_UNCOMPRESS was previously
From: Stephen Warren swar...@nvidia.com
DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
omap2plus.S's use of .data, which is not allowed in the decompressor.
Solve this by placing that data into .text when building the file into
the decompressor. This relies on .text actually
On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote:
On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
omap2plus.S's use of .data, which is not allowed in the decompressor
into the core with a flag to enable the behaviour.
Patch 1, 9, 10, 11,
Reviewed-by: Stephen Warren swar...@nvidia.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
On 07/29/2013 03:05 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130719 11:59]:
On 07/19/2013 01:29 AM, Tony Lindgren wrote:
I'd vote for keeping the existing behaviour with pinctrl_select_state()
when no active state is defined.
Yes, I think that will work, since
On 07/29/2013 03:21 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130719 12:05]:
On 07/19/2013 01:39 AM, Tony Lindgren wrote:
I think the only sane way to deal with this is to make the I2C controller
to show up as two separate I2C controller instances. Then use runtime
PM
On 07/19/2013 12:36 AM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 19 July 2013 11:59 AM, Greg KH wrote:
On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Friday 19 July 2013 11:13 AM, Greg KH wrote:
On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay
On 07/19/2013 10:24 AM, Sourav Poddar wrote:
This patch disabled I2C/SPI/UART device initially(status = disabled).
This devices will only be probed, if the devices are
present in the dts file(status = okay).
interrupts = 0 72 0x4;
ti,hwmods =
On 07/19/2013 04:29 AM, Grygorii Strashko wrote:
Hi Tony, Stephen
On 07/19/2013 10:39 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130718 12:33]:
On 07/18/2013 01:36 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130717 14:30]:
On 07/16/2013 03:05 AM
On 07/19/2013 01:39 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130718 12:33]:
On 07/18/2013 01:36 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130717 14:30]:
On 07/16/2013 03:05 AM, Tony Lindgren wrote:
...
Why shouldn't e.g. a pinctrl-based I2C mux
On 07/19/2013 01:29 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130718 12:27]:
On 07/18/2013 01:25 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130717 14:21]:
On 07/16/2013 03:05 AM, Tony Lindgren wrote:
To toggle dynamic states, let's add the optional
On 07/17/2013 04:54 PM, Laurent Pinchart wrote:
Hello,
Here's a small patch set that replaces PWM polarity numerical constants with
macros in DT.
The series,
Reviewed-by: Stephen Warren swar...@nvidia.com
I'm (very very) slightly hesitant about patch 3/4, since it's moving
towards all PWMs
On 07/18/2013 01:25 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130717 14:21]:
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
On 07/18/2013 01:36 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [130717 14:30]:
On 07/16/2013 03:05 AM, Tony Lindgren wrote:
...
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
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
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
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
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
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
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
On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
Hi Stephen,
On Thursday 11 July 2013 11:40:37 Stephen Warren wrote:
On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources
On 07/12/2013 05:01 AM, Laurent Pinchart wrote:
Hi,
On Thursday 11 July 2013 14:06:44 Stephen Warren wrote:
On 07/11/2013 01:32 PM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04
On 07/12/2013 11:24 AM, Thierry Reding wrote:
On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
Hi Stephen,
[...]
What about splitting it in three patches that
- add the include/dt-bindings/pwm/pwm.h header, and update
include
On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++---
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
[...]
diff --git
a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index
de0eaed..be09be4 100644 ---
On 07/11/2013 01:32 PM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
On 07/11/2013 09:36 AM, Thierry Reding wrote:
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart
wrote: [...]
diff --git
a/Documentation/devicetree/bindings/pwm/atmel-tcb
On 06/18/2013 11:57 PM, Keerthy wrote:
From: J Keerthy j-keer...@ti.com
Check if irq value obtained is valid. If it is not valid
then skip the irq request step and go ahead with the probe.
Reviewed-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe from this list: send the line
On 06/18/2013 04:01 AM, J Keerthy wrote:
Check if interrupts property exists and then only request irq.
On some boards INT line might not be connected to a valid
irq line on the application processor. Hence keeping a check
before requesting irq.
When there is no interrupts property, surely
On 06/18/2013 04:03 AM, J Keerthy wrote:
The SMPS10 regulator is not presesnt in all the variants
of the PALMAS PMIC family. Hence adding a feature to distingush
between them.
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
+ match =
On 06/18/2013 10:54 AM, J, KEERTHY wrote:
Hi Stephen,
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Tuesday, June 18, 2013 9:22 PM
To: J, KEERTHY
Cc: linux-omap@vger.kernel.org; broo...@kernel.org;
ldewan...@nvidia.com; sa...@linux.intel.com
On 06/18/2013 11:19 AM, J, KEERTHY wrote:
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Tuesday, June 18, 2013 10:38 PM
To: J, KEERTHY
Cc: linux-omap@vger.kernel.org; broo...@kernel.org;
ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik
On 06/18/2013 11:33 AM, J, KEERTHY wrote:
Stephen Warren wrote at Tuesday, June 18, 2013 10:53 PM:
... No, you should just check the IRQ number.
Hmmm...so something like (!i2c-irq)
Yes.
Consider this:
If the device was instantiated from a board file *or* a device tree,
i2c-irq
On 06/12/2013 02:19 AM, J Keerthy wrote:
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Reviewed-by: Stephen Warren swar...@nvidia.com
diff --git a/arch/arm/boot/dts
On 06/10/2013 11:30 PM, J Keerthy wrote:
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
On 06/11/2013 08:48 AM, Florian Vaussard wrote:
These constants can be used to easily declare MTD partitions inside
DTS.
The constants MTDPART_OFS_* are purposely not included. Indeed,
parse_ofpart_partitions() is expecting u64, but a DT cell is u32.
Negative constants, as defined by
On 06/11/2013 08:48 AM, Florian Vaussard wrote:
Use the MTD constants for NAND and OneNAND nodes used in OMAP3
DTS.
I don't quite understand the split between patches 2/3 and 3/3; isn't
the edit to omap3-overo.dtsi (part of) a board file, and hence logically
part of this patch? I'd be tempted
On 06/10/2013 03:29 AM, Benoit Cousson wrote:
Hi Keerthy,
On 06/10/2013 06:03 AM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc
On 06/09/2013 10:03 PM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
Cam you please fix your email client to quote the messages you're
replyiing to correctly? In the message you sent, there's no
differentiation between what I originally wrote and you quoted, vs. the
new text
On 06/10/2013 03:04 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes.
Nits:
Well, you're really adding files that provide the nodes, not the nodes
themselves.
Palmas and MFD should be correctly capitalized.
diff --git a/arch/arm/boot/dts/palmas.dtsi
On 06/07/2013 06:27 AM, Benoit Cousson wrote:
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git
On 05/29/2013 02:39 AM, Benoit Cousson wrote:
Hi Afzal,
On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
Hi Jon,
On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
On 05/28/2013 03:25 PM, Jon Hunter wrote:
ti,am335x-timer (applicable to AM335x devices
On 05/23/2013 09:36 AM, Florian Vaussard wrote:
Hello,
Following a similar proposal by Stephen Warren for tegra [1], this series
makes use of the C preprocessor when compiling OMAP DT files, and
accomplishes some improvements to improve overall readability.
Patch 1 is a preparation
On 05/28/2013 03:25 PM, Jon Hunter wrote:
On 27/05/13 15:37, Afzal Mohammed wrote:
AM43x timer bindings.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
1 - 100 of 236 matches
Mail list logo
