On 29/11/14 13:59, Mark Brown wrote:
On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote:
The patches are based on:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next
The base, the patches, and couple of additional not-to-be-merged
omap2plus_defconfig patches can
Hi Sebastian,
On Monday 24 November 2014 05:21 PM, Sebastian Andrzej Siewior wrote:
* Vignesh R | 2014-11-14 10:37:25 [+0530]:
This series of patches fix TSC defects related to lag in touchscreen
performance and cursor jump at touch release. The lag was result of
udelay in TSC interrupt
On 12/01/2014 10:53 AM, Vignesh R wrote:
Hi Sebastian,
Hi Vignesh,
I fixed the issue that was triggering the WARN_ON(). I think it would be
better if you tested these patches, before I posted them on the
mainline. I don't want to clutter the list with too main versions. Here
is the link to
Hi,
On Monday 01 December 2014 03:29 PM, Sebastian Andrzej Siewior wrote:
On 12/01/2014 10:53 AM, Vignesh R wrote:
Hi Sebastian,
Hi Vignesh,
I fixed the issue that was triggering the WARN_ON(). I think it would be
better if you tested these patches, before I posted them on the
Well the nightmare userspace switch from ttyS to ttyO few years ago is
something we want to avoid.. I think the best solution would be to make
serial-omap.c transparently provide support for ttyO using the new 8250
code so both ttyS and ttyO devices would just work. Otherwise it will
be years
On Mon, Dec 01, 2014 at 08:57:14AM +0100, Yegor Yefremov wrote:
On Sat, Nov 29, 2014 at 4:35 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Nov 28, 2014 at 11:35:53AM +0100, Yegor Yefremov wrote:
On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren t...@atomide.com wrote:
* Enric Balletbo
On 11/27/2014 09:15 PM, Paul Walmsley wrote:
On Thu, 27 Nov 2014, Tero Kristo wrote:
Yet another PRCM cleanup set, towards making PRCM a separate driver.
This set is most likely too late for 3.19, but hopefully it can make
it to 3.20.
Yep too late for 3.19.
...
Testing done:
...
* One Thousand Gnomes gno...@lxorguk.ukuu.org.uk [141201 06:11]:
Well the nightmare userspace switch from ttyS to ttyO few years ago is
something we want to avoid.. I think the best solution would be to make
serial-omap.c transparently provide support for ttyO using the new 8250
code so
On 12/01/2014 05:38 PM, Tony Lindgren wrote:
* One Thousand Gnomes gno...@lxorguk.ukuu.org.uk [141201 06:11]:
Well the nightmare userspace switch from ttyS to ttyO few years ago is
something we want to avoid.. I think the best solution would be to make
serial-omap.c transparently provide
* Sebastian Andrzej Siewior bige...@linutronix.de [141201 09:27]:
On 12/01/2014 05:38 PM, Tony Lindgren wrote:
* One Thousand Gnomes gno...@lxorguk.ukuu.org.uk [141201 06:11]:
Well the nightmare userspace switch from ttyS to ttyO few years ago is
something we want to avoid.. I think the
Commit 82c02f58ba3a (usb: musb: Allow multiple glue layers to be
built in) enabled selecting multiple glue layers, which in turn
exposed things more for randconfig builds. If NOP_USB_XCEIV is
built-in and TUSB6010 is a loadable module, we will get:
drivers/built-in.o: In function `tusb_remove':
On Mon, Dec 01, 2014 at 11:10:15AM -0800, Tony Lindgren wrote:
Commit 82c02f58ba3a (usb: musb: Allow multiple glue layers to be
built in) enabled selecting multiple glue layers, which in turn
exposed things more for randconfig builds. If NOP_USB_XCEIV is
built-in and TUSB6010 is a loadable
On Mon, Dec 01, 2014 at 09:15:36AM +0200, Jyri Sarha wrote:
The only reason is that I have not encountered any other audio capable HDMI
device falling in this category (cpu-dai integrated within HDMI device
block). Without at least two devices utilizing this code it remains
questionable
On Mon, Dec 01, 2014 at 11:07:06AM +0200, Tomi Valkeinen wrote:
On 29/11/14 13:59, Mark Brown wrote:
Reviewed-by: Mark Brown broo...@kernel.org
Thanks. And just to be sure, that's ok, we can merge these in the next
merge window?
Yes.
but like I said in reply to the patch adding the new
* Alexander Kochetkov al.koc...@gmail.com [141129 13:02]:
commit dd74548ddece4b9d68e5528287a272fa552c81d0 (i2c: omap:
resize fifos before each message) dropped check for dev-buf_len.
As result, data processing loop cause dev-buf overruns for
devices with 16-bit data register (omap2420).
In
Alexander Kochetkov al.koc...@gmail.com writes:
The first patch fix i2c-omap driver for omap2420, found by code review and
later reported by Tony Lindgren t...@atomide.com here[1].
Candidate for stable?
The second patch unhide the reson of system lockup.
The patch is rebased on branch
Hi,
On Mon, Dec 01, 2014 at 02:09:14PM +, One Thousand Gnomes wrote:
Well the nightmare userspace switch from ttyS to ttyO few years ago is
something we want to avoid.. I think the best solution would be to make
serial-omap.c transparently provide support for ttyO using the new 8250
On Tue, Dec 02, 2014 at 01:13:38AM +0200, Aaro Koskinen wrote:
Hi,
On Mon, Dec 01, 2014 at 02:09:14PM +, One Thousand Gnomes wrote:
Well the nightmare userspace switch from ttyS to ttyO few years ago is
something we want to avoid.. I think the best solution would be to make
.
They are based on top of linux-next 20141201.
http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=per-user-clk-constraints-v7
Thanks,
Tomeu
Tomeu Vizoso (7):
clk: Remove unused function __clk_get_prepare_count
clk: Don't try to use a struct clk* after it could have been freed
clk
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller,
20 matches
Mail list logo
