Hey Tony,
On Fri, Mar 13, 2015 at 08:40:39AM -0700, Tony Lindgren wrote:
* Marc Zyngier marc.zyng...@arm.com [150311 08:44]:
This series is extracted from [4], which is trying to remove all
traces of gic_arch_extn from the tree. As some maintainers are more
responsive than others
On 13/03/15 17:38, Tony Lindgren wrote:
* Jason Cooper ja...@lakedaemon.net [150313 10:25]:
Hey Tony,
On Fri, Mar 13, 2015 at 08:40:39AM -0700, Tony Lindgren wrote:
* Marc Zyngier marc.zyng...@arm.com [150311 08:44]:
This series is extracted from [4], which is trying to remove all
traces of
* Jason Cooper ja...@lakedaemon.net [150313 10:25]:
Hey Tony,
On Fri, Mar 13, 2015 at 08:40:39AM -0700, Tony Lindgren wrote:
* Marc Zyngier marc.zyng...@arm.com [150311 08:44]:
This series is extracted from [4], which is trying to remove all
traces of gic_arch_extn from the tree. As
On 03/12/15 20:29, Shawn Guo wrote:
On Thu, Mar 12, 2015 at 12:43:40PM -0700, Stephen Boyd wrote:
On 03/12/15 10:20, Sebastian Andrzej Siewior wrote:
On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
diff =
--- arch/arm/mach-imx/mach-imx6q.c
+++ /tmp/cocci-output-11792-b62223-mach-imx6q.c
Given that the documentation mentions the actual phy used, it may be
worth mentioning this also in the driver? i.e. that it's not a
dm816x phy but a SR70LX Synopsys USB 2.0 OTG nanoPHY (in contrast
to the dm814x and am335x which use a phy TI made themselves)
USB is one of the few subsystems of
* Matthijs van Duin matthijsvand...@gmail.com [150313 11:39]:
Given that the documentation mentions the actual phy used, it may be
worth mentioning this also in the driver? i.e. that it's not a
dm816x phy but a SR70LX Synopsys USB 2.0 OTG nanoPHY (in contrast
to the dm814x and am335x which
ti,codec in not parsed in omap-twl4030 sound driver. It's not necessary
to specify this property in DT because ti,twl4030-audio which ti,codec
was pointing to by phandle is mfd driver and device for ASoC ic created w/o
any DT property (codec name is hardcoded in ASoC driver).
Please see reply [1]
ti,codec property is not used (parsed) in omap-twl4030 driver. The
ti,twl4030-audio
which ti,codec points by phandle is mfd driver and device for ASoC codec is
created
w/o DT compatible string. Removing all references in DT files.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
ti,codec property is not used in omap-twl4030 driver in linux kernel but
we keep it as optional property, so that the existing dtbs do not
become noncompliant after the change on other OS.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
Hi!
@@ -384,25 +385,10 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap
*bgp, int id, void *data);
void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id);
int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend);
-#ifdef CONFIG_OMAP4_THERMAL
+extern
The OMAP DMTimer API, omap_dm_timer_set_source(), uses the clock name
timer_sys_ck for setting a timer's clock source for the source index
OMAP_TIMER_SRC_SYS_CLK. There is currently no clock alias data for
the Timers 13 through 16 for this clock name, so add the same.
Signed-off-by: Suman Anna
The DT clock aliases for Timers use the legacy (non-DT) device
names and a source clock named sys_ck. OMAP5 is DT-boot only,
so correct the DT clock aliases to use the DT device names
instead. Also, the source clock name is corrected from 'sys_ck'
to 'timer_sys_ck', the name used by the OMAP
The OMAP DMTimer API, omap_dm_timer_set_source(), can set the parent
of a timer node using 3 different values that use fixed parent names
for the clocks. The parent name, timer_sys_ck, is used for setting the
parent when used with the source index OMAP_TIMER_SRC_SYS_CLK. This
should point to the
The DT clock aliases for timers using the legacy OMAP timer
device names have been cleaned up. These device names reflect
the names used in legacy boot, and are no longer applicable
as OMAP4 is DT boot only now.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/clk/ti/clk-44xx.c | 11
Hi Tero,
Please find couple of cleanup/fixes on the DT clock aliases
for the GPTimers. Patches are based on 4.0-rc1 and following
is the summary of the changes,
1. Patch 1 is a cleanup for OMAP4
2. Patch 2 fixes the failures for OMAP5 if omap_dm_timer_set_source() API is
called to set the
On 03/12/2015 04:04 AM, Ohad Ben-Cohen wrote:
On Fri, Jan 9, 2015 at 11:21 PM, Suman Anna s-a...@ti.com wrote:
The remoteproc driver core currently relies on iommu_present() on
the bus the device is on, to perform MMU management. However, this
logic doesn't scale for multi-arch, especially for
On 03/12/2015 11:14 PM, Marek Belisko wrote:
ti,codec in not parsed in omap-twl4030 sound driver. It's not necessary
to specify this property in DT because ti,twl4030-audio which ti,codec
was pointing to by phandle is mfd driver and device for ASoC ic created w/o
any DT property (codec name is
Hi,
Teresa replied me, but unfortunately I found that the answer not
reached the public maillists. Briefly, we don't need this patch,
PhyTec will send better one this year.
2015-03-07 15:59 GMT+03:00 Matwey V. Kornilov mat...@sai.msu.ru:
The following patch is to support Phytec
Hello Eliad,
On Thu, Mar 12, 2015 at 1:09 PM, Eliad Peller el...@wizery.com wrote:
Replace all the pdata-quirks for setting wl12xx/wl18xx
platform data with proper DT definitions.
The patch was compile-tested only.
Signed-off-by: Eliad Peller el...@wizery.com
---
I wanted to test your
On Thursday 12 March 2015 22:14:59 Marek Belisko wrote:
diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
index 1ab6bc8..656165f 100644
--- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
+++
Hi Shawn,
On Fri, Mar 13, 2015 at 11:29:32AM +0800, Shawn Guo wrote:
We did not add a DT property for it, because there was already enough
info (clock configuration) in DT for kernel to figure it out.
Correct. My understanding is whatever can be figured out without DT should
be done that way.
Hello,
2015-03-13 9:01 GMT+01:00 Javier Martinez Canillas jav...@dowhile0.org:
Hello Eliad,
On Thu, Mar 12, 2015 at 1:09 PM, Eliad Peller el...@wizery.com wrote:
Replace all the pdata-quirks for setting wl12xx/wl18xx
platform data with proper DT definitions.
The patch was compile-tested
On 03/13/2015 12:36 PM, Jyri Sarha wrote:
[...]
In theory this patch does exactly what it is supposed to. It only
allows a sample-rate and sample-format combination if the rate can be
produced with reasonable accuracy. Unfortunately the alsa-lib and
alsa-tools are not able use this information
Hi!
I checked 4.0-rc3 and linux-next as of today, and can not see omap3
thermal support. Can you apply the patches?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
On 03/13/2015 01:05 PM, Arnd Bergmann wrote:
On Thursday 12 March 2015 22:14:59 Marek Belisko wrote:
diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
index 1ab6bc8..656165f 100644
---
* Eliad Peller el...@wizery.com [150312 05:09]:
From: Luciano Coelho l...@coelho.fi
Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead. Also add a
boolean to specify whether the clock is XTAL or not.
Thanks for
Set a rule constraint to allow only sample-rate and sample-format
combinations that can be played/captured with reasonable accuracy.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
In theory this patch does exactly what it is supposed to. It only
allows a sample-rate and sample-format combination if
On Fri, Mar 13, 2015 at 12:48 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
On 03/13/2015 01:05 PM, Arnd Bergmann wrote:
On Thursday 12 March 2015 22:14:59 Marek Belisko wrote:
diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
* Eliad Peller el...@wizery.com [150312 05:10]:
Now that we have wlcore device-tree bindings in place
(for both wl12xx and wl18xx), remove the legacy
wl12xx_platform_data struct, and move its members
into the platform device data (that is passed to wlcore)
Davinci 850 is the only platform
* Eliad Peller el...@wizery.com [150312 05:09]:
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
-static void __init omap3_evm_legacy_init(void)
-{
- legacy_init_wl12xx(3840, 0, 149);
-}
FYI, at least this part conflicts with the fixes in the
On Fri, Mar 13, 2015 at 09:20:10AM +0100, Sebastian Andrzej Siewior wrote:
Hi Shawn,
On Fri, Mar 13, 2015 at 11:29:32AM +0800, Shawn Guo wrote:
We did not add a DT property for it, because there was already enough
info (clock configuration) in DT for kernel to figure it out.
Correct. My
On 03/13/15 13:56, Lars-Peter Clausen wrote:
On 03/13/2015 12:36 PM, Jyri Sarha wrote:
[...]
In theory this patch does exactly what it is supposed to. It only
allows a sample-rate and sample-format combination if the rate can be
produced with reasonable accuracy. Unfortunately the alsa-lib and
* Marc Zyngier marc.zyng...@arm.com [150311 08:44]:
This series is extracted from [4], which is trying to remove all
traces of gic_arch_extn from the tree. As some maintainers are more
responsive than others (understatement of the year...), I've decided
to split it per sub-arch, and get it
Hello,
On 03/12/2015 01:09 PM, Eliad Peller wrote:
NOTE: all the platform patches were compile-tested
only. I'm looking for some wl12xx card (that i should
have somewhere) to test the wl12xx changes (wrt. clocks),
but haven't found it yet.
I have tested this series on a APF6 board, i.MX6
On Sun, Jan 18, 2015 at 09:28:24PM +0100, Pavel Machek wrote:
Add support for omap3430 sensor. Tested on Nokia N900.
Fix help text to be closer to english.
Ifdefs in ti-bandgap.h are not neccessary, as users have #ifdefs,
already.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git
Hey Pavel,
On Fri, Mar 13, 2015 at 01:09:35PM +0100, Pavel Machek wrote:
Hi!
I checked 4.0-rc3 and linux-next as of today, and can not see omap3
thermal support. Can you apply the patches?
Yeah, it should be possible. Apologize, it really fell into the cracks.
There is a comment on it
36 matches
Mail list logo
