The McPDM in OMAP4/5 is using the pdmclk from twl6040 as functional clock.
The twl6040-pdmclk driver provides a clock which can be used to make sure
that the pdmclk is active when the McPDM is in use.
Signed-off-by: Peter Ujfalusi
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/mfd/
From: Vlastimil Babka
In DEBUG_VM kernel, we can hit infinite loop for order == 0 in
buffered_rmqueue() when check_new_pcp() returns 1, because the bad page is
never removed from the pcp list. Fix this by removing the page before retrying.
Also we don't need to check if page is non-NULL, because
On 05/30/2016 03:33 AM, Minchan Kim wrote:
+ page->mapping = (void *)((unsigned long)page->mapping &
+ PAGE_MAPPING_MOVABLE);
This should be negated to clear... use ~PAGE_MAPPING_MOVABLE ?
No.
The intention is to clear only mapping value but PAGE_MAPPIN
++ Daniel
On 30-05-2016 09:44, Jose Abreu wrote:
> Hi Daniel,
>
> Thanks for your answer.
>
> On 26-05-2016 09:06, Daniel Vetter wrote:
>> On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote:
>>> Hi all,
>>>
>>> Currently I am trying to develop a DRM driver that will use
>>> Xilinx VDMA to
On Sun, May 29, 2016 at 05:40:49PM +0800, Rongrong Zou wrote:
> Add DRM master driver for Hisilicon Hibmc SoC which used for
> Out-of-band management. Blow is the general hardware connection,
> both the Hibmc and the host CPU are on the same mother board.
>
> +--+ +--+
> |
On 05/30/2016 10:52 AM, Axel Lin wrote:
> 2016-05-30 16:48 GMT+08:00 Krzysztof Kozlowski :
>> On 05/29/2016 01:16 PM, Axel Lin wrote:
>>> Current code can set ramp delay to a wrong setting that the return value
>>> from .set_voltage_time_sel is not enough for proper delay.
>>
>> I don't understand
Hi Franklin,
On Wed, 4 May 2016 13:34:42 -0500
Franklin S Cooper Jr wrote:
> This patchset includes the required patches to enable NAND DMA prefetch
> support when using the EDMA.
>
> This patchset depends on my previous patchset to enable NAND DMA prefetch
> using the SDMA and Roger's GPMC an
Current code for .set_ramp_delay() rounds down the value written to
register, while the implementation of .set_voltage_time_sel() works on
original constraints (not rounded down).
Fix the logic in .set_ramp_delay and also remove unused ret_val variable.
Signed-off-by: Axel Lin
---
v2: Update comm
On Sun, May 29, 2016 at 10:33 PM, Jani Nikula wrote:
> On Fri, 20 May 2016, Jani Nikula wrote:
>> At this time I've put most effort into the configuration and build side
>> of things, solving the problems described above, and handling missing
>> tools and packages gracefully. There are still issu
On Mon, May 30, 2016 at 09:43:53AM +0200, Maarten Lankhorst wrote:
> Op 26-05-16 om 22:08 schreef Chris Wilson:
> > Recursive locking for ww_mutexes was originally conceived as an
> > exception. However, it is heavily used by the DRM atomic modesetting
> > code. Currently, the recursive deadlock is
hi
在 2016/5/30 16:53, Jiri Olsa 写道:
On Sat, May 28, 2016 at 11:59:59AM +, He Kuang wrote:
Support x86(32-bit) cross platform callchain unwind.
Signed-off-by: He Kuang
---
tools/perf/arch/Build | 1 +
tools/perf/arch/x86/util/unwind-libunwind.c| 7
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
{pud,pmd}_alloc_one are allocating from {PGT,PUD}_CACHE initialized in
pgtable_cache_init which doesn't have larger than sizeof(void *) << 12
s
From: Michal Hocko
jbd2_alloc is explicit about its allocation preferences wrt. the
allocation size. Sub page allocations go to the slab allocator
and larger are using either the page allocator or vmalloc. This
is all good but the logic is unnecessarily complex.
1) as per Ted, the vmalloc fallbac
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
PGALLOC_GFP uses __GFP_REPEAT but {pgd,pmd}_alloc allocate from
{pgd,pmd}_cache but both caches are allocating up to PAGE_SIZE
objects. This me
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
page_table_alloc then uses the flag for a single page allocation. This
means that this flag has never been actually useful here because it has
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
pgtable_alloc_one uses __GFP_REPEAT flag for L2_USER_PGTABLE_ORDER but
the order is either 0 or 3 if L2_KERNEL_PGTABLE_SHIFT for HPAGE_SHIFT.
T
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
PGALLOC_GFP uses __GFP_REPEAT but it is only used in pte_alloc_one,
pte_alloc_one_kernel which does order-0 request. This means that this
flag
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
pte_alloc_one{_kernel} allocate PTE_ORDER which is 0. This means that
this flag has never been actually useful here because it has always been
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations. Yet we have
the full kernel tree with its usage for apparently order-0 allocations.
This is really confusing because __GFP_REPEAT is explicitly
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
{pud,pmd}_alloc_one is using __GFP_REPEAT but it always allocates from
pgtable_cache which is initialzed to PAGE_SIZE objects. This means that
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
PGALLOC_GFP uses __GFP_REPEAT but none of the allocation which uses this
flag is for more than order-0. This means that this flag has never
bee
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
pmd_alloc_one allocate PMD_ORDER which is 1. This means that this flag
has never been actually useful here because it has always been used only
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
pte_alloc_one{_kernel}, pmd_alloc_one allocate PTE_ORDER resp. PMD_ORDER
but both are not larger than 1. This means that this flag has never
be
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
pte_alloc_one_kernel uses __get_order_pte but this is obviously
always zero because BITS_FOR_PTE is not larger than 9 yet the page
size is alwa
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
pte_alloc_one{_kernel} allocate PTE_ORDER which is 0. This means that
this flag has never been actually useful here because it has always been
Hi,
On Thu, May 26, 2016 at 07:25:25PM -, Michal Suchanek wrote:
> The maximum speed of SPI master is used when maximum speed of SPI slave
> is not specified. Also the __spi_validate function should check that
> transfer speeds do not exceed the master limits.
>
> The user manual for A10 and
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
efi_alloc_page_tables uses __GFP_REPEAT but it allocates an order-0
page. This means that this flag has never been actually useful here
because
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
PGALLOC_GFP uses __GFP_REPEAT but none of the allocation which uses
this flag is for more than order-2. This means that this flag has never
bee
From: Michal Hocko
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
{pte,pmd,pud}_alloc_one{_kernel}, late_pgtable_alloc use PGALLOC_GFP for
__get_free_page (aka order-0).
pgd_alloc is slightly more complex bec
Hi,
this is the thrid version of the patchset previously sent [1]. I have
basically only rebased it on top of 4.7-rc1 tree and dropped "dm: get
rid of superfluous gfp flags" which went through dm tree. I am sending
it now because it is tree wide and chances for conflicts are reduced
considerably wh
On Mon, May 30, 2016 at 09:07:05AM +0200, Michal Hocko wrote:
> On Fri 27-05-16 19:18:21, Vladimir Davydov wrote:
> > On Fri, May 27, 2016 at 01:18:03PM +0200, Michal Hocko wrote:
> > ...
> > > @@ -1087,7 +1105,25 @@ static int __set_oom_adj(struct file *file, int
> > > oom_adj, bool legacy)
> > >
On 05/30/2016 11:09 AM, Axel Lin wrote:
> Current code for .set_ramp_delay() rounds down the value written to
> register, while the implementation of .set_voltage_time_sel() works on
> original constraints (not rounded down).
> Fix the logic in .set_ramp_delay and also remove unused ret_val variabl
On Fri, May 27, 2016 at 03:34:13PM -0400, Chris Metcalf wrote:
> >Does TILE never speculate reads? Because in that case the control
> >dependency already provides a full load->load,store barrier and you'd
> >want smp_acquire__after_ctrl_dep() to be a barrier() instead of
> >smp_rmb().
>
> Yes, th
I think explicit BUG_ON may make the debug easier, since it can point
out the wrong line.
2016-05-30 16:53 GMT+08:00 Michal Hocko :
> On Mon 30-05-16 16:45:51, Wenwei Tao wrote:
>> From: Wenwei Tao
>>
>> The mem_cgroup_tree_per_node allocation might fail,
>> check that before continue the memcg i
On Mon, May 30, 2016 at 05:11:35PM +0800, Hekuang wrote:
> hi
>
> 在 2016/5/30 16:53, Jiri Olsa 写道:
> > On Sat, May 28, 2016 at 11:59:59AM +, He Kuang wrote:
> > > Support x86(32-bit) cross platform callchain unwind.
> > >
> > > Signed-off-by: He Kuang
> > > ---
> > > tools/perf/arch/Build
Hi Vincent,
On Fri, May 27, 2016 at 03:37:11PM +0200, Vincent Guittot wrote:
> On 26 May 2016 at 21:44, Yuyang Du wrote:
> > Hi Vincent,
> >
> > On Thu, May 26, 2016 at 01:50:56PM +0200, Vincent Guittot wrote:
> >> On 26 May 2016 at 03:14, Yuyang Du wrote:
> >> > Vincent reported that the first
On Friday 27 May 2016 14:11:11 Gabriele Mazzotta wrote:
> On 22/05/2016 13:50, Pali Rohár wrote:
> > This patch exports standard hwmon pwmX_enable sysfs attribute for enabling
> > or disabling automatic fan control by BIOS. Standard value "1" is for
> > disabling automatic BIOS fan control and valu
On Fri, May 13, 2016 at 01:03:14PM +0300, Roger Quadros wrote:
> Hi,
>
> This series centralizes OTG/Dual-role functionality in the kernel.
> As of now I've got Dual-role functionality working pretty reliably on
> dra7-evm and am437x-gp-evm.
> NOTE: my am437x-gp-evm broke so I couldn't test v8 on
On 05/30/2016 03:39 AM, Minchan Kim wrote:
After isolation, VM calls migratepage of driver with isolated page.
The function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
clear PG_movable of oldpage via __ClearP
On Sunday 29 May 2016 20:27:15 Peter Saunderson wrote:
> I have just tested removing i8k_get_fan_type() function from the
> dell-smm-hwmon driver in the kernel on my Dell Inspiron 580 and the fan
> speed problem goes away. My patch simply replaced fan_type with fan_status
> in i8k_init_hwmon and u
On Mon, May 30, 2016 at 10:00:56AM +0100, Jose Abreu wrote:
> ++ Daniel
>
>
> On 30-05-2016 09:44, Jose Abreu wrote:
> > Hi Daniel,
> >
> > Thanks for your answer.
> >
> > On 26-05-2016 09:06, Daniel Vetter wrote:
> >> On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote:
> >>> Hi all,
> >>
Ping
On 2016/05/12 at 11:36, Xunlei Pang wrote:
> On 2016/05/11 at 14:49, Peter Zijlstra wrote:
>> On Tue, May 10, 2016 at 11:19:44AM -0700, bseg...@google.com wrote:
>>> Xunlei Pang writes:
>>>
Two minor fixes for cfs_rq_clock_task().
1) If cfs_rq is currently being throttled, we need
Hi CK,
Reply inline.
On Mon, 2016-05-30 at 14:49 +0800, CK Hu wrote:
> Hi, HS:
>
> Some comments inline.
>
> On Mon, 2016-05-30 at 11:19 +0800, HS Liao wrote:
...
> > +static void cmdq_thread_irq_handler(struct cmdq *cmdq, int tid)
> > +{
> > + struct cmdq_thread *thread = &cmdq->thread[tid];
On Mon 30-05-16 11:47:53, Vladimir Davydov wrote:
> On Mon, May 30, 2016 at 09:07:05AM +0200, Michal Hocko wrote:
> > On Fri 27-05-16 19:18:21, Vladimir Davydov wrote:
> > > On Fri, May 27, 2016 at 01:18:03PM +0200, Michal Hocko wrote:
> > > ...
> > > > @@ -1087,7 +1105,25 @@ static int __set_oom_a
Ping
Could someone have some comments on this bug?
On 2016/04/26 at 16:30, Xunlei Pang wrote:
> A crash happened while I was playing with deadline PI rtmutex.
>
> BUG: unable to handle kernel NULL pointer dereference at 0018
> IP: [] rt_mutex_get_top_task+0x1f/0x30
> PGD 23
Op 30-05-16 om 11:11 schreef Peter Zijlstra:
> On Mon, May 30, 2016 at 09:43:53AM +0200, Maarten Lankhorst wrote:
>> Op 26-05-16 om 22:08 schreef Chris Wilson:
>>> Recursive locking for ww_mutexes was originally conceived as an
>>> exception. However, it is heavily used by the DRM atomic modesettin
On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote:
> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
> 1MHz SPI bus takes way longer than that. Calculate the timeout from the
> actual time the transfer is supposed to take and multiply by 2 for good
> measure.
>
>
Hi Scott,
On 17 May 2016 at 01:41, Scott Wood wrote:
> On Wed, Apr 27, 2016 at 10:35:25AM +0200, Alessio Igor Bogani wrote:
>> + bcsr@4,0 {
>> + compatible = "artesyn,mvme7100-bcsr";
>> + reg = <4 0 0x1>;
>> + };
>> +
>> +
On 05/30/2016 11:01 AM, Mel Gorman wrote:
From: Vlastimil Babka
In DEBUG_VM kernel, we can hit infinite loop for order == 0 in
buffered_rmqueue() when check_new_pcp() returns 1, because the bad page is
never removed from the pcp list. Fix this by removing the page before retrying.
Also we don't
Hi,
在 2016/5/30 15:40, Jaehoon Chung 写道:
After applied "remove lots of IS_ERR_VALUE abuses", it shoold be
misoperation. (commit 287980e49)
If mmc_bus_test is successful, it returned the bus-witdh bit.
The below log is error log
[2.542260] mmc0: mmc_select_hs200 failed, error 3
[2.542275
Add support for the Artesyn MVME7100 Single Board Computer.
The MVME7100 is a 6U form factor VME64 computer with:
- A two e600 cores Freescale MPC8641D CPU
- 2 GB of DDR2 onboard memory
- Four Gigabit Ethernets
- Five 16550 compatible UARTs
- One USB 2.0 port
- Two PCI/PCI
On Mon 30-05-16 09:13:57, Michal Hocko wrote:
> On Fri 27-05-16 19:48:30, Vladimir Davydov wrote:
> > On Thu, May 26, 2016 at 02:40:13PM +0200, Michal Hocko wrote:
> [...]
> > > @@ -839,6 +841,13 @@ void oom_kill_process(struct oom_control *oc, struct
> > > task_struct *p,
> > > for_each_process
A PCM extension was added to I2S driver so that audio
samples are transferred using PIO mode.
The PCM supports two channels @ 16 or 32 bits with rates
32k, 44.1k and 48k.
Although the mainline I2S driver uses ALSA DMA engine the
I2S controller can be built without DMA support, therefore
this is t
ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.
This patch set adds I2S audio for the AXS10x platform.
NOTE:
Although the mainline I2S driver uses ALSA DMA engine, this controller
can be b
A parameter description for the interruptions of the
I2S controller was added.
Signed-off-by: Jose Abreu
Acked-by: Rob Herring
Cc: Carlos Palminha
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rob Herring
Cc: Alexey Brodkin
Cc: linux-snps-...@lists.infradead.or
Hi Javier,
2016-05-27 16:18 GMT+02:00 Javier Martinez Canillas :
> Hello,
>
> While booting a system with a mwifiex WiFi card, I noticed the following
> missleading error message:
>
> [ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available
>
> This error only applies to platforms
We use messagecount only once in vmbus_establish_gpadl() to check if
it is safe to iterate through the submsglist. We can just initialize
the list header in all cases in create_gpadl_header() instead.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/channel.c | 38 -
In some cases create_gpadl_header() allocates submessages but we never
free them.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/channel.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 2b109e8..a68830c 100644
--- a/driv
kmemleak helped me to identify a memory leak on GPADL establishment. Do
some minor refactoring and fix the issue.
Vitaly Kuznetsov (2):
Drivers: hv: get rid of redundant messagecount in
create_gpadl_header()
Drivers: hv: don't leak memory in vmbus_establish_gpadl()
drivers/hv/channel.c |
On 2016年05月23日 18:43, Michael S. Tsirkin wrote:
This is in response to the proposal by Jason to make tun
rx packet queue lockless using a circular buffer.
My testing seems to show that at least for the common usecase
in networking, which isn't lockless, circular buffer
with indices does not per
Hi Geert!
On 28/05/16 20:06, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham
> wrote:
>> The FCP driver, can also support the FCPF variant for FDP1 compatible
>> processing.
>>
>> Signed-off-by: Kieran Bingham
>
> Thanks for your patch!
>
>> ---
>>
commit 79152e8d085fd64484afd473ef6830b45518acba upstream.
The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
testing 8 kB size blocks:
$ sudo modprobe tcrypt sec=1 mode=500
testing speed of async ecb(aes) (ecb-aes-s5p) encryption
test 0 (128 bit key
Hi Geert,
On 28/05/16 20:03, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham
> wrote:
>> The example misses the power-domains usage, and documentation that the
>> property is used by the node.
>>
>> Signed-off-by: Kieran Bingham
>
> Thanks for your p
On 29-05-16, 02:40, Rafael J. Wysocki wrote:
> I can't really parse the above question, so I'm not going to try to
> answer it. :-)
Sorry about that :(
IOW, I think that we should make this change into the sched-governor (I will
send a patch separately if you agree to this):
diff --git a/kernel/
Am Montag, 30. Mai 2016, 11:12:33 schrieb Masahiro Yamada:
> Tree-wide replacement was done by commit 2ef7d5f342c1 (ARM, ARM64:
> dts: drop "arm,amba-bus" in favor of "simple-bus"), but we have some
> new users of "arm,amba-bus" at Linux 4.7-rc1. Eliminate them now.
>
> Signed-off-by: Masahiro Ya
I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
image for it (see [1]). For development I would like to use
CONFIG_MODULES. However, when I try to insmod the build module I get:
[ 287.903653] module cfg80211: overflow in relocation type 261 val
ffbffc006530
Looking A
Hi Emil,
On Fri, 2016-05-27 at 10:30 +0100, Emil Velikov wrote:
> On 20 May 2016 at 16:05, wrote:
> > From: YT Shen
> >
> > Add MT8173 suffix for hardware related macros.
> >
> Why suffix ? Pretty much everyone else uses prefix.
No problem, I will use prefix in the future.
>
> -Emil
Hi Emil,
On Fri, 2016-05-27 at 10:35 +0100, Emil Velikov wrote:
> Hi YT Shen,
>
> There's a typo in the commit summary - s/mediatke/mediatek/.
Ooops, even I type this word everyday, I still made a mistake...
>
> On 20 May 2016 at 16:05, wrote:
> > From: YT Shen
> >
> > This patch add support f
Hi Emil,
Thanks for your review.
On Fri, 2016-05-27 at 10:24 +0100, Emil Velikov wrote:
> On 27 May 2016 at 08:31, YT Shen wrote:
> > Hi CK,
> >
> >
> > On Mon, 2016-05-23 at 17:43 +0800, CK Hu wrote:
> >> Hi, YT:
> >>
> >> One comment below.
> >>
> >> On Fri, 2016-05-20 at 23:05 +0800, yt.s...@
On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote:
> Patch not applied, SCHED_RR:
ww_mutex isn't RT aware at all; its one of the things I still have on a
todo list. Should I look harder at finding time for this?
On Mon, 30 May 2016, Hans Ulli Kroll wrote:
> Missing event_handler in mfgpt_tick() caused a kernel panic.
So the real problem is that the interrupt in the device is enabled _BEFORE_
the clock event device is registered.
> diff --git a/drivers/clocksource/cs5535-clockevt.c
> b/drivers/clocksou
Hi Shubhrajyoti,
> > + */
> > +static void zynqmp_dma_update_desc_to_ctrlr(struct zynqmp_dma_chan
> *chan,
> > + struct zynqmp_dma_desc_sw *desc)
> > +{
> > + dma_addr_t addr;
> > +
> > + addr = desc->src_p;
> > + writel(addr, chan->regs + ZYNQ
On Mon, May 30, 2016 at 11:52:12AM +0200, Michal Hocko wrote:
> On Mon 30-05-16 09:13:57, Michal Hocko wrote:
> > On Fri 27-05-16 19:48:30, Vladimir Davydov wrote:
> > > On Thu, May 26, 2016 at 02:40:13PM +0200, Michal Hocko wrote:
> > [...]
> > > > @@ -839,6 +841,13 @@ void oom_kill_process(struct
On Monday 30 May 2016 02:39 PM, Axel Lin wrote:
Current code for .set_ramp_delay() rounds down the value written to
register, while the implementation of .set_voltage_time_sel() works on
original constraints (not rounded down).
Fix the logic in .set_ramp_delay and also remove unused ret_val vari
On Mon, May 30, 2016 at 11:39:50AM +0200, Michal Hocko wrote:
> On Mon 30-05-16 11:47:53, Vladimir Davydov wrote:
> > On Mon, May 30, 2016 at 09:07:05AM +0200, Michal Hocko wrote:
> > > On Fri 27-05-16 19:18:21, Vladimir Davydov wrote:
> > > > On Fri, May 27, 2016 at 01:18:03PM +0200, Michal Hocko
On Fri, May 20, 2016 at 11:05:32PM +0800, yt.s...@mediatek.com wrote:
> From: YT Shen
>
> Add MT8173 suffix for hardware related macros.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 62
>
> 1 file changed, 31 insertions(+), 31
Hi,
sorry I couldn't fit the review into last week.
On Tuesday 24 May 2016 14:26:27 Pranay Kr. Srivastava wrote:
> When a timeout occurs or a recv fails, then
> instead of abruplty killing nbd block device
> wait for it's users to finish.
>
> This is more required when filesystem(s) like
> ext2
On Mon, May 23, 2016 at 05:43:02PM +0800, CK Hu wrote:
> Hi, YT:
>
> One comment below.
>
> On Fri, 2016-05-20 at 23:05 +0800, yt.s...@mediatek.com wrote:
> > From: YT Shen
> >
> > There are some hardware settings changed, between MT8173 & MT2701:
> > DISP_OVL address offset changed, color form
On Mon, May 30, 2016 at 12:27:46PM +0200, Peter Zijlstra wrote:
> On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote:
> > Patch not applied, SCHED_RR:
>
> ww_mutex isn't RT aware at all; its one of the things I still have on a
> todo list. Should I look harder at finding time for th
Hi,
sorry for my temporary absence, I have been on holiday the last weeks :-)
Am 30.05.2016 um 11:10 schrieb Daniel Vetter :
> On Sun, May 29, 2016 at 10:33 PM, Jani Nikula wrote:
>> On Fri, 20 May 2016, Jani Nikula wrote:
>>> At this time I've put most effort into the configuration and build
How about the untested attached patch?
Bjørn
>From d1682d6c0a558cf8ffb82af959156f99f0f1f61a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?=
Date: Mon, 30 May 2016 12:44:05 +0200
Subject: [PATCH] lib/uuid.c: use correct offset in uuid parser
MIME-Version: 1.0
Content-Type: text/plai
On Mon 30-05-16 13:40:17, Vladimir Davydov wrote:
> On Mon, May 30, 2016 at 11:52:12AM +0200, Michal Hocko wrote:
> > On Mon 30-05-16 09:13:57, Michal Hocko wrote:
> > > On Fri 27-05-16 19:48:30, Vladimir Davydov wrote:
> > > > On Thu, May 26, 2016 at 02:40:13PM +0200, Michal Hocko wrote:
> > > [..
From: Borislav Petkov
People complained about ARCH_HWEIGHT_CFLAGS and how it throws a wrench
into kcov, lto, etc, experimentations.
Add asm versions for __sw_hweight{32,64}() and do explicit saving and
restoring of clobbered registers. This gets rid of the special calling
convention. We get to c
On Mon, May 30, 2016 at 11:46:05AM +0200, Vlastimil Babka wrote:
> On 05/30/2016 11:01 AM, Mel Gorman wrote:
> >From: Vlastimil Babka
> >
> >In DEBUG_VM kernel, we can hit infinite loop for order == 0 in
> >buffered_rmqueue() when check_new_pcp() returns 1, because the bad page is
> >never removed
在 2016/5/30 17:30, Jiri Olsa 写道:
On Mon, May 30, 2016 at 05:11:35PM +0800, Hekuang wrote:
hi
在 2016/5/30 16:53, Jiri Olsa 写道:
On Sat, May 28, 2016 at 11:59:59AM +, He Kuang wrote:
Support x86(32-bit) cross platform callchain unwind.
Signed-off-by: He Kuang
---
tools/perf/arch/Build
On Fri, 20 May 2016 18:29:06 +0800
Shawn Lin wrote:
> This patch add some required and optional properties for Rockchip
> PCIe controller. Also we add a example for how to use it.
>
> Signed-off-by: Shawn Lin
>
> ---
>
> .../devicetree/bindings/pci/rockchip-pcie.txt | 93
>
On 05/30/2016 10:58 AM, Peter Zijlstra wrote:
> On Fri, May 27, 2016 at 07:10:01PM +0200, Sebastian Andrzej Siewior wrote:
>> On 2016-05-19 14:24:06 [+0200], Peter Zijlstra wrote:
>>> On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
+static struct futex_hash_bucket *hash_futex(
On Mon 30-05-16 13:26:44, Vladimir Davydov wrote:
> On Mon, May 30, 2016 at 11:39:50AM +0200, Michal Hocko wrote:
[...]
> > Yes and that leads me to a suspicion that we can do that. Maybe I should
> > just add a note into the log that we are doing that so that people can
> > complain? Something lik
On Tue, May 10, 2016 at 12:39:43PM +0200, Johannes Thumshirn wrote:
> Hi Greg,
>
> Here are two additional fixes for MCB from me, which would be good to have in
> v4.7.
>
> One fixes a panic when doing a insmod/rmmod loop and one grabs a reference to
> the carrier driver's module as long as clien
Op 30-05-16 om 12:45 schreef Chris Wilson:
> On Mon, May 30, 2016 at 12:27:46PM +0200, Peter Zijlstra wrote:
>> On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote:
>>> Patch not applied, SCHED_RR:
>> ww_mutex isn't RT aware at all; its one of the things I still have on a
>> todo list
On Mon 30-05-16 17:28:40, Wenwei Tao wrote:
> I think explicit BUG_ON may make the debug easier, since it can point
> out the wrong line.
Does it? NULL ptr dereferencec 6 lines below sounds pretty close to me.
I am not nacking this patch I just think it doesn't add much. If others
think it will be
On Fri, May 27, 2016 at 03:10:11PM +1000, Julian Calaby wrote:
> On Fri, May 27, 2016 at 3:05 PM, Michal Suchanek wrote:
> >> Also, should the changes for the drivers be in two separate patches also?
> > That's basically the same driver with different constants so I guess not.
> Fair enough, I
On Thu, May 26, 2016 at 07:25:25PM -, Michal Suchanek wrote:
> - fallback to previous behaviour when DMA initialization fails
>
>+ this has the problem that when the driver happens to load before the dma
> driver it will not use dma - can be addressed with a module parameter
No, yo
This is likely caused by the fact that the Android AArch64 toolchain uses -fpic
by default. Could you try adding -fno-pic to the CFLAGS?
> On 30 mei 2016, at 12:21, Arend Van Spriel
> wrote:
>
> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
> image for it (see [1]).
This allows userspace to identify this case specifically from the
catch all error msg it prints currently.
This is an ABI change
Before
---
| # perf record ls
| Error:
| The sys_perf_event_open() syscall returned with 524 (Unknown error 524)
| for event (cycles:ppp).
| /bin/dmesg may provide
Hi,
This is a repost of RFC [1], rebased on 4.7-rc1, to print pretty PMU lacking
overflow interrupt support if user tries perf sampling.
At the time of RFC review, both PeterZ and Vince seemed convinced to go ahead
with this patch despite the ABI change [2].
Thx,
-Vineet
[1] http://lists.infra
This allows (with next change to perf core) for calling out in userspace
the exact reason for perf record failing when PMU doesn't support
overflow interrupts
Signed-off-by: Vineet Gupta
---
tools/perf/util/evsel.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/perf/util/evsel.
Hi,
On 29-05-16 09:04, Chen-Yu Tsai wrote:
The MMC clock timings were incorrectly calculated, when the conversion
from delay value to delay phase was done.
The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR
unusable. Unfortunately it seems different controllers on the same SoC
have
Sebastian Frias writes:
Barebox shares a good amount of code. For example, when you look at SPI
at AT24/AT25 you'll see that many things are almost identical.
The panel is not used by any legacy board files so the legacy (pdata) boot
support can be dropped.
Signed-off-by: Peter Ujfalusi
---
.../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 44 +++---
include/video/omap-panel-data.h| 14 ---
2 files changed, 6
101 - 200 of 1124 matches
Mail list logo
