On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote:
* Eliad Peller el...@wizery.com [150309 14:03]:
On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 09 March 2015 17:36:42 Eliad Peller wrote:
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
On Fri, Mar 06, 2015 at 11:47:48PM +0200, grygorii.stras...@linaro.org wrote:
Hi Russell,
On 03/05/2015 10:17 PM, Russell King - ARM Linux wrote:
On Thu, Mar 05, 2015 at 08:55:07PM +0200, grygorii.stras...@linaro.org
wrote:
The dma_coerce_mask_and_coherent() will fail in case 'Example
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon n...@ti.com wrote:
+Configuration definition follows similar model as the pinctrl-single:
+The groups of pin configuration are defined under pinctrl-single,pins
+
+dra7_iodelay_core {
+ mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
+
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon n...@ti.com wrote:
SoC family such as DRA7 family of processors have, in addition
to the regular muxing of pins (as done by pinctrl-single), an
additional hardware module called IODelay which is also expected to be
configured. This IODelay module
On 06/03/15 17:36, Jyri Sarha wrote:
If I read Documentation/kbuild/makefiles.txt section 3.6 right, this
patch should not be needed. However, without this patch the objects
needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is
built as module.
Signed-off-by: Jyri Sarha
* Arnd Bergmann a...@arndb.de [150310 07:11]:
On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote:
On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote:
* Eliad Peller el...@wizery.com [150309 14:03]:
On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de wrote:
On Mon, Mar 9, 2015 at 4:41 PM, Tony Lindgren t...@atomide.com wrote:
* Bin Liu binml...@gmail.com [150309 14:35]:
On Mon, Mar 9, 2015 at 4:26 PM, Tony Lindgren t...@atomide.com wrote:
* Felipe Balbi ba...@ti.com [150309 14:21]:
On Mon, Mar 09, 2015 at 04:17:29PM -0500, Bin Liu wrote:
On
On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote:
On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote:
I was expecting you to remove all calls to legacy_init_wl12xx from this
file,
including the
On Tuesday 10 March 2015 07:41 PM, Arnd Bergmann wrote:
On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote:
On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote:
* Eliad Peller el...@wizery.com [150309 14:03]:
On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de
On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote:
On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote:
* Eliad Peller el...@wizery.com [150309 14:03]:
On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 09 March 2015 17:36:42 Eliad Peller
On Mon, Mar 09, 2015 at 11:39:17AM -0500, Felipe Balbi wrote:
On Thu, Feb 19, 2015 at 12:06:49PM -0600, Felipe Balbi wrote:
If either SCL or SDA are stuck low, we need to
recover the bus using the procedure described
on section 3.1.16 of the I2C specification.
Note that we're trying to
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing y2038 problem for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64.
Since S390 is a 64bit architecture, also rename some timespec
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing y2038 problem for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64 by converting clock_access_fn to use timespec64.
Signed-off-by:
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing y2038 problem for in-kernel uses, this
patch adds the y2038-safe tegra_read_persistent_clock64() using
timespec64.
Because we rely on some subsequent changes to convert arm multiarch
support, tegra_read_persistent_clock() will be
From: Xunlei Pang pang.xun...@linaro.org
read_boot_clock(), read_persistent_clock() and update_persistent_clock()
all use timespec which may have y2038 problem, thus we are planning on
converting all of them to use timespec64.
The approach we're using is:
1) First of all, add the __weak
From: Xunlei Pang pang.xun...@linaro.org
Now we have all the read_boot_clock64() for all implementations,
it's time to remove read_boot_clock() completely from the kernel.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
read_persistent_clock() and update_persistent_clock() are way more
Grygorii,
On 03/10/2015 12:36 PM, Grygorii Strashko wrote:
Hi Dave,
On 03/06/2015 07:45 PM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [150306 09:28]:
On 03/05/2015 06:41 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [150305 12:24]:
* Dave Gerlach d-gerl...@ti.com
On 03/10/2015 10:33 AM, Tony Lindgren wrote:
* Linus Walleij linus.wall...@linaro.org [150310 03:39]:
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon n...@ti.com wrote:
+Configuration definition follows similar model as the pinctrl-single:
+The groups of pin configuration are defined under
* Nishanth Menon n...@ti.com [150310 10:25]:
On 03/10/2015 10:33 AM, Tony Lindgren wrote:
* Linus Walleij linus.wall...@linaro.org [150310 03:39]:
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon n...@ti.com wrote:
+Configuration definition follows similar model as the pinctrl-single:
Hi Arnd,
On 03/09/2015 11:33 PM, Arnd Bergmann wrote:
On Thursday 05 March 2015 20:55:07 grygorii.stras...@linaro.org wrote:
Hi All,
Now I can see very interesting behavior related to
dma_coerce_mask_and_coherent()
and friends which I'd like to explain and clarify.
Below is set of
On 03/10/2015 05:39 AM, Linus Walleij wrote:
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon n...@ti.com wrote:
+Configuration definition follows similar model as the pinctrl-single:
+The groups of pin configuration are defined under pinctrl-single,pins
+
+dra7_iodelay_core {
+
Hi Russell,
On 03/10/2015 01:05 PM, Russell King - ARM Linux wrote:
On Fri, Mar 06, 2015 at 11:47:48PM +0200, grygorii.stras...@linaro.org wrote:
On 03/05/2015 10:17 PM, Russell King - ARM Linux wrote:
On Thu, Mar 05, 2015 at 08:55:07PM +0200, grygorii.stras...@linaro.org
wrote:
The
On Tue, Mar 10, 2015 at 6:18 PM, Tony Lindgren t...@atomide.com wrote:
* Eliad Peller el...@wizery.com [150310 09:11]:
On Tue, Mar 10, 2015 at 5:52 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 10 March 2015 16:31:33 Eliad Peller wrote:
On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann
Hello Tony,
On Tue, Mar 10, 2015 at 6:35 PM, Tony Lindgren t...@atomide.com wrote:
we do have to make sure these wl18xx bindings are future-compatible
with the wl12xx ones, but i think the current bindings are pretty much
standard (and are actually a subset of the bindings needed by wl12xx),
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing in-kernel y2038 issues, this patch adds
read_boot_clock64() and replaces all the call sites of read_boot_clock()
with this function. This is a __weak implementation, which simply
calls the existing y2038 unsafe read_boot_clock().
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing in-kernel y2038 issues, this patch adds
read_persistent_clock64() and replaces all the call sites of
read_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing in-kernel y2038 issues, this patch adds
update_persistent_clock64() and replaces all the call sites of
update_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing y2038 problem for in-kernel uses, this
patch adds the y2038-safe omap_read_persistent_clock64() using
timespec64.
Because we rely on some subsequent changes to convert arm multiarch
support, omap_read_persistent_clock() will be
Hello Eliad,
On Wed, Mar 11, 2015 at 1:28 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
On Mon, Mar 9, 2015 at 4:36 PM, Eliad Peller el...@wizery.com wrote:
--- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
+++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
@@ -42,4 +42,13 @@
On Tue, Mar 10, 2015 at 5:52 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 10 March 2015 16:31:33 Eliad Peller wrote:
On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote:
On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren
* Suman Anna s-a...@ti.com [150309 16:59]:
On 03/05/2015 10:57 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [150305 08:47]:
On 03/05/2015 09:40 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [150304 20:14]:
Dave,
Looks like the commit message disappeared during your
On Mon, 09 Mar 2015, Dmitry Torokhov wrote:
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically
On Tuesday 10 March 2015 07:28:05 Tony Lindgren wrote:
Oops I forgot about the omap3-sbc-t3730, so yes we have to keep the
platform data a little bit longer. But nothing stopping us moving
all the other ones to use a proper device tree based configuration.
For all I can tell, the t3730
* Eliad Peller el...@wizery.com [150310 09:11]:
On Tue, Mar 10, 2015 at 5:52 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 10 March 2015 16:31:33 Eliad Peller wrote:
On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 10 March 2015 13:00:19 Eliad Peller
Tony,
On 03/06/2015 11:45 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [150306 09:28]:
On 03/05/2015 06:41 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [150305 12:24]:
* Dave Gerlach d-gerl...@ti.com [150305 11:53]:
On 03/05/2015 12:49 PM, Tony Lindgren wrote:
* Paul
On 03/10/2015 12:31 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [150310 10:25]:
On 03/10/2015 10:33 AM, Tony Lindgren wrote:
* Linus Walleij linus.wall...@linaro.org [150310 03:39]:
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon n...@ti.com wrote:
+Configuration definition follows
On 03/10/2015 01:33 PM, Nishanth Menon wrote:
On 03/10/2015 12:31 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [150310 10:25]:
On 03/10/2015 10:33 AM, Tony Lindgren wrote:
* Linus Walleij linus.wall...@linaro.org [150310 03:39]:
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon
Tony,
On 03/10/2015 11:09 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [150309 16:59]:
On 03/05/2015 10:57 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [150305 08:47]:
On 03/05/2015 09:40 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [150304 20:14]:
Dave,
Looks
On Tuesday 10 March 2015 10:35:50 Tony Lindgren wrote:
* Eliad Peller el...@wizery.com [150310 10:01]:
i'm really not familiar with the common clock framework, but there
still doesn't seem to be a way to determine whether a clock is XTAL or
not (which is what Luca's patch was about). should
Without MODULE_ALIAS twl4030_madc_battery won't get loaded automatically.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
drivers/power/twl4030_madc_battery.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/twl4030_madc_battery.c
b/drivers/power/twl4030_madc_battery.c
When twl_4030_madc_battery is build as module, MODULE_DEVICE_TABLE allow
the module to be auto-loaded since the module will match the devices
instantiated from device tree.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
drivers/power/twl4030_madc_battery.c | 2 ++
1 file changed, 2
Signed-off-by: Marek Belisko ma...@goldelico.com
---
drivers/power/twl4030_madc_battery.c | 81
1 file changed, 81 insertions(+)
diff --git a/drivers/power/twl4030_madc_battery.c
b/drivers/power/twl4030_madc_battery.c
index 6af28b5..4bcb4a9 100644
---
Because of added iio error handling private data allocation was converted
to managed to simplify code.
Signed-off-by: Marek Belisko ma...@goldelico.com
Reviewed-By: Sebastian Reichel s...@debian.org
---
drivers/power/twl4030_madc_battery.c | 99 +++-
1 file
Signed-off-by: Marek Belisko ma...@goldelico.com
---
.../bindings/power_supply/twl4030_madc_battery.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
diff --git
Added battery support for gta04 devices.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index
This patches adding support for twl4030_madc_battery to use twl4030_madc iio
framework + DT support.
Patches was tested on gta04 board. twl4030_madc_battery driver is converted in
first patch to iio consumer and in next patches is added support for devicetree
+ some small fixes for module
On Mon 2015-03-09 11:50:56, Måns Rullgård wrote:
Geert Uytterhoeven ge...@linux-m68k.org writes:
Hi Pavel,
On Sun, Mar 8, 2015 at 9:57 PM, Pavel Machek pa...@ucw.cz wrote:
Ok, so I played with RGB LED a bit, and we have quite a gap in
documentation: what 50% brightness means is
Hello Eliad,
On Mon, Mar 9, 2015 at 4:36 PM, Eliad Peller el...@wizery.com wrote:
Add wl18xx (wilink8) bindings to omap3-igep0030-rev-g and
omap3-igep0020-rev-f dts files, instead of defining the
platform data through the pdata-quirks.
The patch was compile-tested only.
You should look at
Hello Eliad,
On Mon, Mar 9, 2015 at 4:36 PM, Eliad Peller el...@wizery.com wrote:
When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.
For now, parse only the irq used. Other (optional) properties
49 matches
Mail list logo
