On 04/15/2014 12:59 AM, Alexandre Belloni wrote:
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
On Tue, Apr 15, 2014 at 10:01:44AM +0300, Peter Ujfalusi wrote:
On 04/15/2014 12:59 AM, Alexandre Belloni wrote:
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
1 file changed, 2 insertions(+), 8
On 04/15/2014 10:14 AM, Simon Horman wrote:
On Tue, Apr 15, 2014 at 10:01:44AM +0300, Peter Ujfalusi wrote:
On 04/15/2014 12:59 AM, Alexandre Belloni wrote:
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
1
On Sat, Apr 05, 2014 at 11:35:50PM +0200, Sebastian Reichel wrote:
This patch adds support for specifying auxiliary codecs and
codec configuration via device tree phandles.
This change adds new fields to snd_soc_aux_dev and snd_soc_codec_conf
and adds support for the changes to SoC core
On Sat, Apr 05, 2014 at 11:35:49PM +0200, Sebastian Reichel wrote:
From: Pali Rohár pali.ro...@gmail.com
This patch converts the rx51 ASoC module to use
devm_snd_soc_register_card. It also adds module alias
to support driver autoloading.
This doesn't apply against current code and since it
On Sat, Apr 05, 2014 at 11:35:52PM +0200, Sebastian Reichel wrote:
Use table based setup to register the DAPM widgets and routes. This on one
hand
makes the code a bit cleaner and on the other hand the board level DAPM
elements get registered in the card's DAPM context rather than in the
On Sat, Apr 05, 2014 at 11:35:53PM +0200, Sebastian Reichel wrote:
Currently the second tlv320aic3x instance fails to
be probed from DT if the reset pin is shared with
the first one.
Applied, thanks.
signature.asc
Description: Digital signature
On Sat, Apr 05, 2014 at 11:35:51PM +0200, Sebastian Reichel wrote:
This patch adds device tree support to the Nokia N900 audio driver.
It also removes GPIO defines and gets them from platform data /
device tree, since some GPIO numbers may be different with DT boot.
This binding looks mostly
Hi Heikki,
On Tue, Dec 10, 2013 at 7:25 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com wrote:
Giving life to this thread after long time.
Hi,
On Tue, Dec 10, 2013 at 04:25:25PM +0530, Vivek Gautam wrote:
@@ -170,6 +189,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
On 4/6/2014 3:05 AM, Sebastian Reichel wrote:
From: Pali Rohár pali.ro...@gmail.com
This patch converts the rx51 ASoC module to use
devm_snd_soc_register_card. It also adds module alias
to support driver autoloading.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
Signed-off-by: Sebastian
On 22:36-20140414, Joachim Eastwood wrote:
On 14 April 2014 21:19, Nishanth Menon n...@ti.com wrote:
On 04/14/2014 02:15 PM, Joachim Eastwood wrote:
On 14 April 2014 15:38, Santosh Shilimkar santosh.shilim...@ti.com wrote:
On Saturday 12 April 2014 05:06 PM, Joachim Eastwood wrote:
Hi,
--
Hallo liebe,
Mein Name ist Michela, ich bin 26yrs alt, ich ein freier minded,
offenherzige Mädchen bin, i, das Leben so einfach wie ich nehmen könnte
gefallen, ich bin einer der wenigen, die immer noch glaubt, in
Freundschaft, Liebe, Vertrauen und Zeichen , bin sehr Einzel-und bereit zu
BeagleBoard xM A/B has an inverted usb hub enable line vs the xM C
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-beagle-xm-ab.dts | 15 +++
2 files changed, 16 insertions(+)
create mode 100644
On Tue, Apr 15, 2014 at 10:09 AM, Robert Nelson robertcnel...@gmail.com wrote:
BeagleBoard xM A/B has an inverted usb hub enable line vs the xM C
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
arch/arm/boot/dts/Makefile | 1 +
pm_runtime_get_sync may not always succeed depending on SoC involved. So
handle the error appropriately.
Reported-by: Joachim Eastwood manab...@gmail.com
Signed-off-by: Nishanth Menon n...@ti.com
---
based on v3.15-rc1
Report-thread: http://marc.info/?t=13975033042r=1w=2
On 04/15/2014 10:12 AM, Robert Nelson wrote:
On Tue, Apr 15, 2014 at 10:09 AM, Robert Nelson robertcnel...@gmail.com
wrote:
BeagleBoard xM A/B has an inverted usb hub enable line vs the xM C
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
arch/arm/boot/dts/Makefile
On Tue, Apr 15, 2014 at 10:35 AM, Nishanth Menon n...@ti.com wrote:
On 04/15/2014 10:12 AM, Robert Nelson wrote:
On Tue, Apr 15, 2014 at 10:09 AM, Robert Nelson robertcnel...@gmail.com
wrote:
BeagleBoard xM A/B has an inverted usb hub enable line vs the xM C
Signed-off-by: Robert Nelson
Hi,
On Tue, Apr 15, 2014 at 10:33:02AM -0500, Nishanth Menon wrote:
pm_runtime_get_sync may not always succeed depending on SoC involved. So
handle the error appropriately.
Reported-by: Joachim Eastwood manab...@gmail.com
Signed-off-by: Nishanth Menon n...@ti.com
---
based on v3.15-rc1
On 15 April 2014 16:01, Nishanth Menon n...@ti.com wrote:
On 22:36-20140414, Joachim Eastwood wrote:
On 14 April 2014 21:19, Nishanth Menon n...@ti.com wrote:
On 04/14/2014 02:15 PM, Joachim Eastwood wrote:
On 14 April 2014 15:38, Santosh Shilimkar santosh.shilim...@ti.com
wrote:
On
On 04/15/2014 10:50 AM, Felipe Balbi wrote:
Hi,
On Tue, Apr 15, 2014 at 10:33:02AM -0500, Nishanth Menon wrote:
pm_runtime_get_sync may not always succeed depending on SoC involved. So
handle the error appropriately.
Reported-by: Joachim Eastwood manab...@gmail.com
Signed-off-by: Nishanth
pm_runtime_get_sync may not always succeed depending on SoC involved.
So handle the error appropriately ensuring usage_count is accurate in
case of failure.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2:
- review fixes, print function names in error log as well.
V1:
On 15 April 2014 18:58, Nishanth Menon n...@ti.com wrote:
pm_runtime_get_sync may not always succeed depending on SoC involved.
So handle the error appropriately ensuring usage_count is accurate in
case of failure.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2:
- review fixes,
On Tue, Apr 15, 2014 at 11:58:31AM -0500, Nishanth Menon wrote:
pm_runtime_get_sync may not always succeed depending on SoC involved.
So handle the error appropriately ensuring usage_count is accurate in
case of failure.
Signed-off-by: Nishanth Menon n...@ti.com
Reviewed-by: Felipe Balbi
Nishanth,
On 04/14/2014 02:19 PM, Nishanth Menon wrote:
On 04/14/2014 02:15 PM, Joachim Eastwood wrote:
On 14 April 2014 15:38, Santosh Shilimkar santosh.shilim...@ti.com wrote:
On Saturday 12 April 2014 05:06 PM, Joachim Eastwood wrote:
Hi,
I getting the following error on Linus master
On 04/15/2014 12:06 PM, Joachim Eastwood wrote:
On 15 April 2014 18:58, Nishanth Menon n...@ti.com wrote:
pm_runtime_get_sync may not always succeed depending on SoC involved.
So handle the error appropriately ensuring usage_count is accurate in
case of failure.
Signed-off-by: Nishanth Menon
On 04/15/2014 12:15 PM, Joel Fernandes wrote:
[...]
Joel, are you planning on posting OMAP4 hwmod data for AES/DES?
I was out sick yesterday, sorry for the late reply.
Yes, sure. I believe it wasn't posted due to another kernel problem
which I don't remember. I'll post it this week after
Hello,
I am trying to get HDMI work with DT on my VAR-STK-OM44 (4460) board.
But during kernel boot I get the following message:
[ 0.953796] [ cut here ]
[ 0.953826] WARNING: CPU: 0 PID: 1 at
drivers/video/omap2/dss/dss.c:483 dss_set_fck_rate+0x7c/0x8c()
[ 0.953826] clk
This series does trivial replacement of __raw_xxx functions with xxx_relaxed
endian-neutral variants in 'mach-omap2' and 'plat-omap' directories.
Some code here most probably won't be used in BE mode (like debug-leds for
OMAP1 boards), but changes are made anyway to remove __raw_xxx() functions
From: Victor Kamensky victor.kamen...@linaro.org
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed
From: Victor Kamensky victor.kamen...@linaro.org
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed
From: Victor Kamensky victor.kamen...@linaro.org
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed
From: Victor Kamensky victor.kamen...@linaro.org
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed
On 04/15/2014 12:18 PM, Nishanth Menon wrote:
On 04/15/2014 12:06 PM, Joachim Eastwood wrote:
On 15 April 2014 18:58, Nishanth Menon n...@ti.com wrote:
pm_runtime_get_sync may not always succeed depending on SoC involved.
So handle the error appropriately ensuring usage_count is accurate in
* Grazvydas Ignotas nota...@gmail.com [140414 15:51]:
On Fri, Apr 11, 2014 at 2:47 AM, Tony Lindgren t...@atomide.com wrote:
@@ -282,6 +283,7 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
+
WDT1 module can take one of the below clocks as input functional
clock -
- On-Chip 32K RC Osc [default/reset]
- 32K from PRCM
The On-Chip 32K RC Osc clock is not an accurate clock-source as per
the design/spec, so as a result, for example, timer which supposed
to get expired
On 15/04/14 20:36, Joachim Eastwood wrote:
Hello,
I am trying to get HDMI work with DT on my VAR-STK-OM44 (4460) board.
But during kernel boot I get the following message:
[ 0.953796] [ cut here ]
[ 0.953826] WARNING: CPU: 0 PID: 1 at
36 matches
Mail list logo