Adds device node for HS USB Host module for AM437x
Signed-off-by: George Cherian george.cher...@ti.com
---
This patch is on top of
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.11/dts
arch/arm/boot/dts/am4372.dtsi | 19 +++
1 file changed, 19
I am facing one problem in one of the OMAP4430 based tab that I am using.
I try to remount the system partition as rw but it is not doing so .
as some other service is continuously remouting it to ro.
I am getting the following logs a lot of time
6[ 645.504150] C1 [ mount] EXT4-fs
On 25/06/13 14:32, Ruslan Bilovol wrote:
The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio, video, wireless
functions and user interfaces) and in addition
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms.
However, rtc wake support on OMAP1 is broken. Hence the
device_init_wakeup() was removed from rtc-omap driver and moved to
platform board files that supported it (DA850/OMAP-L138). [1]
However, recently [2] it was suggested
Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.
This is basically a partial revert of the prev commit
commit 75c99bb0006ee065b4e2995078d779418b0fab54
Author: Sekhar Nori nsek...@ti.com
davinci:
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms.
However, rtc wake support on OMAP1 is broken. Hence the
device_init_wakeup() was removed from rtc-omap driver and moved to
platform board files that supported it (DA850/OMAP-L138). [1]
However, recently [2] it was suggested
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly.
Platforms using such IP should set ti,am3352-rtc in rtc device dt
compatibility node.
Signed-off-by:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
Add device tree bindings documentation for the TI WiLink modules.
Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
modules is supported.
Signed-off-by: Luciano Coelho coe...@ti.com
---
I created a new
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).
On Wed, Jun 26, 2013 at 8:50 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
When a GPIO is defined as an interrupt line using Device
Tree, a call to irq_create_of_mapping() is made that calls
irq_create_mapping(). So, is not necessary to do the mapping
for all OMAP GPIO
On Wed, Jun 26, 2013 at 8:50 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
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
2013/6/28 Grant Likely grant.lik...@linaro.org:
On Wed, Jun 26, 2013 at 8:50 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ.
(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:
[resending with the correct address for Mike Turquette]
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:
+
+
2013/6/28 Grant Likely grant.lik...@linaro.org:
On Wed, Jun 26, 2013 at 8:50 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
When a GPIO is defined as an interrupt line using Device
Tree, a call to irq_create_of_mapping() is made that calls
irq_create_mapping(). So, is not
[resending again with the doubly corrected address for Mike Turquette,
apologies for the spam]
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
Hi,
On Mon, May 20, 2013 at 08:20:29PM +0200, Hiremath, Vaibhav wrote:
-Original Message-
From: Menon, Nishanth
Sent: Monday, May 20, 2013 11:34 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
o...@vger.kernel.org; Tony
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
Hi Roger
On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Hi
On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
Hello guys,
On Thu, Jun 27, 2013 at 8:56 PM, Michael
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
On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
Hi Roger
On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Do you have locks around this software workaround?
The patch I did against 3.4
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
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,
On 06/27/2013 06:40 PM, Alan Stern wrote:
On Wed, 26 Jun 2013, Roger Quadros wrote:
That race doesn't apply to your system anyway; it matters only on
systems where hcd-has_wakeup_irq isn't set. The only way to fix it
involves changing ehci_suspend() somewhat (and making the equivalent
Hi
On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
Hi Roger
On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Do
From: Amarinder Bindra a-bin...@ti.com
OMAP's hs_mmc driver is also used for OMAP5 MMC controller operation.
Considering that the device tree entries are already there for this,
allow the driver to be built when only OMAP5 is enabled.
This allows MMC root filesystems to be available in OMAP5 only
On 06/28/2013 03:26 PM, Michael Trimarchi wrote:
Hi
On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
Hi Roger
On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
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
On 06/28/2013 03:20 PM, Roger Quadros wrote:
On 06/27/2013 06:40 PM, Alan Stern wrote:
On Wed, 26 Jun 2013, Roger Quadros wrote:
I updated the ehci-omap.c driver to call ehci_suspend/resume during
runtime_suspend/resume.
After that, it stopped detecting the port status change event when a
Hi
On Fri, Jun 28, 2013 at 03:55:08PM +0300, Roger Quadros wrote:
On 06/28/2013 03:26 PM, Michael Trimarchi wrote:
Hi
On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
Hi Roger
On Thu, Jun 27, 2013 at 11:07:11PM +0300,
When a GPIO is defined as an interrupt line using Device
Tree, a call to irq_create_of_mapping() is made that calls
irq_create_mapping(). So, is not necessary to do the mapping
for all OMAP GPIO lines and explicitly call irq_create_mapping()
on the driver probe() when booting with Device Tree.
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drives should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just
On Friday 28 June 2013 11:27 AM, Javier Martinez Canillas wrote:
When a GPIO is defined as an interrupt line using Device
Tree, a call to irq_create_of_mapping() is made that calls
irq_create_mapping(). So, is not necessary to do the mapping
for all OMAP GPIO lines and explicitly call
On Friday 28 June 2013 11:27 AM, Javier Martinez Canillas wrote:
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drives should not be aware of this
On Thursday 27 June 2013 11:38 PM, Fernandes, Joel wrote:
Hi Balaji,
snip
Some patches were squashed and others dropped in the series resulting
in the single patch above. This patch should be good to apply
Hi Joel,
Before pushing mmc dts support for am335x, Can you please let me
know if
On Friday 28 June 2013 06:04 PM, a-bin...@ti.com wrote:
From: Amarinder Bindra a-bin...@ti.com
OMAP's hs_mmc driver is also used for OMAP5 MMC controller operation.
Considering that the device tree entries are already there for this,
allow the driver to be built when only OMAP5 is enabled.
This
Hi
On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
Hi Roger
On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Do
-Original Message-
From: Krishnamoorthy, Balaji T
Sent: Friday, June 28, 2013 10:49 AM
To: Fernandes, Joel
Cc: benoit.cous...@gmail.com; l...@metafoo.de; Tony Lindgren; Nori, Sekhar;
Matt Porter; Grant Likely; Rob Herring; Vinod Koul; Mark Brown; Russell King;
Rob Landley; Andrew
Hi,
On Thu, Jun 27, 2013 at 10:30:33AM +0300, Felipe Balbi wrote:
Hi,
On Thu, Jun 27, 2013 at 09:24:08AM +0200, Michael Grzeschik wrote:
right, but in DT you will define both instances and each instance
will
have a seaparate snps,maximum_speed attribute :-)
I'm
Hi Lokesh
On Thu, 27 Jun 2013, Lokesh Vutla wrote:
On Wednesday 26 June 2013 10:56 PM, Paul Walmsley wrote:
Here's how I do it:
ARCH=arm CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} nice make
-j$CORES zImage am335x-bone.dtb
cat arch/arm/boot/zImage
On Fri, 28 Jun 2013, Roger Quadros wrote:
That's not what I meant. Never mind the pinctrl; I was asking about
the EHCI controller itself. Under what circumstances does the
controller assert its wakeup signal? And how do you tell it to stop
asserting that signal?
I believe this would
On Fri, 28 Jun 2013, Roger Quadros wrote:
Just found the problem. It seems that enabling the ehci_irq _after_ the root
hub is resumed
is the root cause of the problem. Doing so will miss events from the root hub.
This sounds like a bug in the IRQ setup. It's the sort of thing you
see when
Hi
On 06/28/2013 01:46 PM, Roger Quadros wrote:
On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
Hi Roger
On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Do you have locks around this
On Fri, Jun 28, 2013 at 09:00:00PM +0300, Felipe Balbi wrote:
Hi,
On Thu, Jun 27, 2013 at 10:30:33AM +0300, Felipe Balbi wrote:
Hi,
On Thu, Jun 27, 2013 at 09:24:08AM +0200, Michael Grzeschik wrote:
right, but in DT you will define both instances and each instance
will
Quoting Tero Kristo (2013-06-27 01:38:17)
cclock54xx_data.c now contains only init function and the clkdev mapping
that is still needed by some drivers. Eventually most of this file can
be removed, once a common location for the clk init can be found, and
the clkdev mapping is no longer
Quoting Tero Kristo (2013-06-27 01:38:19)
cclock7xx_data.c now contains only init function and the clkdev mapping
that is still needed by some drivers. Eventually most of this file can
be removed, once a common location for the clk init can be found, and
the clkdev mapping is no longer needed.
48 matches
Mail list logo