On Thu, 2015-12-17 at 11:19 +0800, Dave Young wrote:
>
> Cool, has the fix been in mainline or somewhere else?
>
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=a87da0cbc42949cefc8282c39ab4cb8c460bd6ea
johannes
--
To unsubscribe from this list: send the line "unsubscribe l
; > > Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
> > > Cc: Eric Anholt
> > > Signed-off-by: Sudip Mukherjee
> >
> > I'm happy with this solution, and would also be willing to just depend
> > on the config option as
Hi Arnaldo,
On Wed, Dec 16, 2015 at 09:17:59PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 16, 2015 at 12:35:33AM +0900, Namhyung Kim escreveu:
> > Hello,
> >
> > This is an attempt to improve perf to deal with tracepoint events
> > better. The perf tools can handle tracepoint events bu
Hi Milan,
On 16 December 2015 at 16:08, Milan Broz wrote:
> On 12/16/2015 04:18 AM, Baolin Wang wrote:
>> From the dm-crypt performance report, we found it shows low efficiency
>> with crypto engine for some mode (like ecb or xts mode). Because in dm
>> crypt, it will map the IO data buffer with
In dm-crypt, it need to map one bio to scatterlist for improving the
encryption efficiency. Thus this patch introduces the blk_bio_map_sg()
function to map one bio with scatterlists.
Signed-off-by: Baolin Wang
---
block/blk-merge.c | 45 +
inclu
>From the dm-crypt performance report, we found it shows low efficiency
with crypto engine for some mode (like ecb or xts mode). Because in dm
crypt, it will map the IO data buffer with scatterlist, and send the
scatterlist of one bio to the encryption engine, if send more scatterlists
with bigger
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV in
On 12/16/15, Jeff Merkey wrote:
> Setting the (trap flag | resume flag) inside of an nmi handler results
> in a hard lockup while setting the resume flag works fine.
>
> The watchdog detector fails to detect the lockup. I am currently
> examining the trap gate and interrupt gate setup on Linux an
Hi Steve,
On Wed, Dec 16, 2015 at 06:50:43PM -0800, Steve Muckle wrote:
> On 12/15/2015 03:55 PM, Yuyang Du wrote:
> > Hope the following patch should work.
>
> Thanks Yuyang. AFAICS it should work, though I believe the test on
> last_update_time could instead go at the top of migrate_task_rq_fai
On 11/20/2015 01:37 PM, Johannes Thumshirn wrote:
Several functions in lpfc have comments stating that the function must be
called with the hbalock (or hostlock, or ringlock) held. Add
lockdep_assert_held() annotations to these functions, so one can actually
verify the locks are held.
[ ... ]
@
Greetings,
My name is Mr.Michael J. Tynan, I am a banker with Bank Of America. It is true
that we have not meet each other in person, but I strongly believe in trust and
friendship in every business. I have a Lebanese deceased customer's abandoned
fund, which I am his personal financial adviser
Hi Steve,
On Wed, Dec 16, 2015 at 05:24:56PM -0800, Steve Muckle wrote:
> Hi Leo,
>
> On 12/15/2015 07:48 PM, Leo Yan wrote:
> > I also think "set_current_state(TASK_INTERRUPTIBLE)" will introduce
> > logic error when software flow run into "else" block. The reason is
> > after you set state with
On Mon, Dec 14, 2015 at 07:08:08PM -0500, Sanidhya Solanki wrote:
> The original code defined macros in the source code, making it
> harder to read. Moved them to the header file, as per the TODO file.
>
> Updated the TODO file.
I think the TODO file should not be updated now. There are still som
On Wed, Dec 16, 2015 at 07:43:11AM -0800, Peter Hurley wrote:
> Hi Greg,
>
> This series has been reported to fix a regression with Redhat's kdump
> systemd service redirecting to /dev/console, when /dev/console is a
> serial port.
>
> The redirection consistently fails with EIO since
> "tty: Rem
On 12/17/2015 07:51 AM, Wangnan (F) wrote:
> On 2015/12/17 14:38, Daniel Wagner wrote:
>> On 12/17/2015 06:23 AM, Wang Nan wrote:
>>> Since we already have libbpf in tools/lib, we don't need to maintain
>>> another bpf loader and operations library in samples/bpf.
>>>
>>> In patchset:
>>>
>>> Pat
Hi all,
Changes since 20151216:
News: The arm defconfig build is broken during the configrations stage.
The arm-soc tree gained a build failure for the arm defconfig build.
I left it broken for today.
The i2c tree still had its build failure for which I applied a patch.
The regulator tree
On 2015/12/17 14:38, Daniel Wagner wrote:
Hi,
On 12/17/2015 06:23 AM, Wang Nan wrote:
Since we already have libbpf in tools/lib, we don't need to maintain
another bpf loader and operations library in samples/bpf.
In patchset:
Patch 1/10 - 7/10 improves libbpf, add missing features to supp
On 2015/12/16 22:28, Steven Rostedt wrote:
> On Wed, 16 Dec 2015 18:28:35 +0800
> "Zhang, Yanmin" wrote:
>
>>> + /*
>>> +* If the tracing is enabled, go ahead and enable the record.
>>> +*
>>> +* The reason not to enable the record immediatelly is the
>>> +* inherent check of ftr
Hi all,
After merging the arm-soc tree, today's linux-next build (arm defconfig)
failed like this:
*** Default configuration is based on 'versatile_defconfig'
#
# configuration written to .config
#
make[1]: Leaving directory '/home/sfr/next/arm_defconfig'
.config:2033:warning: symbol value '' inv
Hi,
On 12/17/2015 06:23 AM, Wang Nan wrote:
> Since we already have libbpf in tools/lib, we don't need to maintain
> another bpf loader and operations library in samples/bpf.
>
> In patchset:
>
> Patch 1/10 - 7/10 improves libbpf, add missing features to support
> samples,
>
> Patch 8/10 add
Add bpf_map_lookup_elem(), bpf_map_delete_elem() and bpf_map_get_next_key()
to libbpf so it can issue all BPF map operations.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
---
v1 -> v2: Remove tailing whitespaces.
---
tools/lib/bpf/bpf.c | 32
tools/lib
[SNIP]
+int bpf_map_lookup_elem(int fd, void *key, void *value)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .value = ptr_to_u64(value),
+ };
Tailing whitespace here. Sorry...
--
To unsubscribe from this list: s
On 2015/12/17 13:10, Naveen N. Rao wrote:
On 2015/12/17 01:43AM, Wang Nan wrote:
After this patch other directories can use this architecture detector
without directly including it from perf's directory. Libbpf would
utilize it to get proper $(ARCH) so it can receive correct uapi include
direc
On 16/12/2015:07:43:11 AM, Peter Hurley wrote:
> #1. Respin this series w/o the tty-next dependencies
> #2. Split this series into the minimum necessary to fix the regression
As far as kdump issue is concerned, backporting only 12/12 to 4.4-RC is able to
resolve it.
~Pratyush
--
To unsubscribe fr
On Wed, 2015-12-16 at 14:47 +0100, Hans Verkuil wrote:
> On 12/16/15 14:17, tiffany lin wrote:
> > Hi Hans,
> >
> >
> > On Tue, 2015-12-15 at 15:17 +0100, Hans Verkuil wrote:
> >>
> >> On 12/15/15 14:51, tiffany lin wrote:
> >>> We are not familiar with v4l2-compliance utility, we will check how
On 2015-12-15 22:02, Prarit Bhargava wrote:
> The MSR_PKG_POWER_INFO register (Intel ASDM, section 14.9.3
> "Package RAPL Domain") provides a maximum time window which the
> system can support. This window is read-only and is currently
> not examined when setting the time windows for the package.
Hi,
Triggered this with rc4, but the relevant parts are same in rc5:
offending line is :
(gdb) list *(ieee80211_scan_rx+0x158)
0xf68 is in ieee80211_scan_rx (net/mac80211/scan.c:205).
200 if (!(sdata1 &&
201 (ether_addr_equal(mgmt->da, sdata1->vif.ad
On Thu, 17 Dec 2015 10:58:55 +0530 Vineet Gupta
wrote:
> On Tuesday 24 November 2015 01:20 PM, h...@lst.de wrote:
> > Hi Vineet,
> >
> > the original version went through the buildbot, which succeeded. It seems
> > like the official buildbot does not support arc, and might benefit from
> > hel
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/net/sock.h
net/ipv4/tcp_ipv4.c
between commit:
64be0aed59ad ("net: diag: Add the ability to destroy a socket.")
from the net-next tree and commit:
0e2cde9cf7b6 ("net: tcp_memcontrol: simplify linka
On 17.11.2015 15:05, Pankaj Dubey wrote:
> In this series I am splitting up SoC specific PMU configuration data into
> mach-exynos folder itself, before moving all of them under
> drivers/soc/samsung/. Also instead of making all changes in single patch it
> has been broken into SoC specific patches
Since we already have libbpf in tools/lib, there's no need to maintain
a duplicate BPF loading and operations library in samples.
This patch utilises previous introduced utils.[ch], which calls libbpf
to do these work.
The main changing in this relative large patch is very simple:
1. Makefile m
On Tuesday 24 November 2015 01:20 PM, h...@lst.de wrote:
> Hi Vineet,
>
> the original version went through the buildbot, which succeeded. It seems
> like the official buildbot does not support arc, and might benefit from
> helping to set up an arc environment. However in the meantime Guenther
>
Since we have switched to libbpf in tools/lib, old bpf_load.c and
libbpf.c can be removed safely.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Alex Gartrell
Cc: Arnaldo Carvalho de Melo
Cc: Brenden Blanco
Cc: Daniel Borkmann
Cc: Daniel Wagner
Cc: David S. Miller
Cc: Ingo Molnar
Cc:
On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
wrote:
> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori wrote:
>>
>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan"
>> wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori wrote:
>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>> >
We are going to uses libbpf to replace old libbpf.[ch] and
bpf_load.[ch]. This is the first patch of this work. In this patch,
several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
deal with BPF related things. They would
> The only 'error' cases I've encountered so far is a read of all zeroes (and a
> halting the machine once you've read beyond a certain point) or a read of
> 0xff throughout the entire area. So that approach would work for both of them.
I should add that I'd tested the previous patch and this patc
Hi Eric,
On Wed, Dec 16, 2015 at 03:55:09PM -0800, Eric Anholt wrote:
> @@ -226,6 +228,26 @@ static const struct irq_domain_ops
> bcm2836_arm_irqchip_intc_ops = {
> .xlate = irq_domain_xlate_onecell
> };
>
> +#ifdef CONFIG_SMP
Why not put this section under the existing '#ifdef CONFIG_S
Since we already have libbpf in tools/lib, we don't need to maintain
another bpf loader and operations library in samples/bpf.
In patchset:
Patch 1/10 - 7/10 improves libbpf, add missing features to support
samples,
Patch 8/10 adds utils.[ch], which creates similar API like old
bpf_load.c an
Actually 'license' and 'insns' are const pointer. Before this patch
using 'bpf_load_program(... "GPL", ...)' triggers a warning, which is
unnecessary.
This patch makes these two arguments const pointers.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
---
tools/lib/bpf/bpf.c | 8
Types "u64, u32" don't exist in uapi header (linux/types.h). Because of
that directly include bpf.h causes error.
This patch fixes this by replacing all occurrences of "u32, u64" in API
to "__u32, __u64". The later can be found in 'uapi/linux/types.h' so
it would be safe for normal program (other
Building libbpf with 'make -R' causes error:
$ make -R
Auto-detecting system features:
...libelf: [ on ]
... bpf: [ on ]
CC fixdep.o
LD fixdep-in.o
/bin/sh: -r: command not found
make[2]: *** [fixdep-in.o] Error 127
mak
Before this patch libbpf can only load program with type
BPF_PROG_TYPE_KPROBE program. To make libbpf useful in other scenarios,
this patch introduced bpf_program__set_type() and
bpf_object__set_type() which allows setting program type.
This changes doesn't break old API. The default program type
Add bpf_map_lookup_elem(), bpf_map_delete_elem() and bpf_map_get_next_key()
to libbpf so it can issue all BPF map operations.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
---
tools/lib/bpf/bpf.c | 32
tools/lib/bpf/bpf.h | 4
2 files changed, 36 in
LLVM report compiling error:
/kpathsamples/bpf/tracex5_kern.c:33:15: error: use of undeclared identifier
'__NR_getuid'; did you
mean '__NR_vgetcpu'?
if (sd.nr >= __NR_getuid && sd.nr <= __NR_getsid) {
^~~
__NR_vgetcpu
/kpath/ar
Commit b2197755b2633e164a439682fb05a9b5ea48f706 ("bpf: add support for
persistent maps/progs") introduces two new operations to both map and
program. This patch makes libbpf support it.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo
Cc: Daniel Borkmann
---
tools/l
check map->m_len right after it changes to avoid excess call
to update dnode_of_data.
Signed-off-by: Fan li
---
fs/f2fs/data.c | 69 +---
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 90
Fixed coding style issue for missing blank lines after variable
declarations.
Signed-off-by: Benjamin Young
---
drivers/thunderbolt/cap.c| 2 ++
drivers/thunderbolt/ctl.c| 10 ++
drivers/thunderbolt/eeprom.c | 11 +++
drivers/thunderbolt/nhi.c| 13 +
On 16.11.2015 16:43, Pavel Fedin wrote:
> This patch extends Exynos SROM controller driver with ability to configure
> controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
> which is connected via SROMc bank #3.
>
> With this patchset, support for the whole existing SMDK range
On 12.12.2015 16:43, Pankaj Dubey wrote:
> THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES
>
> Series v5 got merged in kgene/for-next but due to last moment change before
> pull
> these patches were not accepted during 4.3 merge window.After that
> kgene/for-next
> got rebas
On 2015/12/17 01:43AM, Wang Nan wrote:
> After this patch other directories can use this architecture detector
> without directly including it from perf's directory. Libbpf would
> utilize it to get proper $(ARCH) so it can receive correct uapi include
> directory.
>
> Signed-off-by: Wang Nan
> A
Hi,
Any comment on this? I still think it is a valuable change...
--
Stefan
On 2015-10-23 16:44, Stefan Agner wrote:
> There are situations where the backlight should be on at boot time
> (e.g. if the boot loader already turned the display on). The DT
> bindings specify the "default-on" property
On 2015/12/17 09:29AM, Wang Nan wrote:
>
>
> On 2015/12/17 3:42, Arnaldo Carvalho de Melo wrote:
> >Em Tue, Dec 15, 2015 at 05:10:46PM +0530, Naveen N. Rao escreveu:
> >>On 2015/12/15 08:51AM, Wang Nan wrote:
> >>>From: "Naveen N. Rao"
> >>>
> >>>perf build is currently (v4.4-rc5) broken on powe
ed reference to `__aeabi_ldivmod'
Caused by commit
bfad4c280be0 ("rtc: fix overflow and incorrect calculation in
rtc_time64_to_tm")
I have used the rtc tree from next-20151216 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this li
On 2015/12/17 13:48, Xishi Qiu wrote:
> On 2015/12/17 10:53, Kamezawa Hiroyuki wrote:
>
>> On 2015/12/17 11:47, Xishi Qiu wrote:
>>> On 2015/12/17 9:38, Izumi, Taku wrote:
>>>
Dear Xishi,
Sorry for late.
> -Original Message-
> From: Xishi Qiu [mailto:qiuxi...
On 2015/12/17 10:53, Kamezawa Hiroyuki wrote:
> On 2015/12/17 11:47, Xishi Qiu wrote:
>> On 2015/12/17 9:38, Izumi, Taku wrote:
>>
>>> Dear Xishi,
>>>
>>> Sorry for late.
>>>
-Original Message-
From: Xishi Qiu [mailto:qiuxi...@huawei.com]
Sent: Friday, December 11, 2015 6:
I guess it makes sense to add it. Thanks.
Regards,
G
On Wednesday 16 December 2015 07:15 PM, Pali Rohár wrote:
> On Wednesday 16 December 2015 14:53:04 srinivas_g_go...@dell.com wrote:
>>
>> Update Srinivas Gowda as dcdbas driver Maintainer
>>
>> Signed-off-by: Srinivas Gowda
>> Acked-by: Doug
Update Srinivas Gowda as dcdbas driver Maintainer.
Also adding relevant mailing list to this version of the patch
Signed-off-by: Srinivas Gowda
Acked-by: Doug Warzecha
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 79c2e48.
On 2015/12/17 12:32, Johannes Weiner wrote:
On Thu, Dec 17, 2015 at 11:46:27AM +0900, Kamezawa Hiroyuki wrote:
On 2015/12/16 20:09, Johannes Weiner wrote:
On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote:
- swap-full notification via vmpressure or something mechanism.
Why?
Hi acme,
I sent this patch few days ago. Unfortunately nobody has payed attention.
Can you please pick this up.
Regards,
Ravi
On Monday 07 December 2015 12:25 PM, Ravi Bangoria wrote:
While recording guest samples in host using perf kvm record, it will
populate unprocessable sample error, tho
On 12/17/2015 10:44 AM, Kai Huang wrote:
On 12/16/2015 04:39 PM, Xiao Guangrong wrote:
On 12/16/2015 03:51 PM, Kai Huang wrote:
On 12/15/2015 05:10 PM, Xiao Guangrong wrote:
On 12/15/2015 03:52 PM, Kai Huang wrote:
static bool __mmu_gfn_lpage_is_disallowed(gfn_t gfn, int level,
@
On Wed, Dec 16, 2015 at 10:27:11PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 16, 2015 at 07:09:53PM -0600, Josh Poimboeuf escreveu:
> > On Wed, Dec 16, 2015 at 09:57:41PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Dec 15, 2015 at 09:39:38AM -0600, Josh Poimboeuf escreveu:
> > >
Hi Damien,
On Thu, Dec 10, 2015 at 11:11:12AM -0500, Damien Riegel wrote:
> On this board, the touchscreen, an ads7843, is not handled directly by
> Linux but by a companion FPGA. This FPGA is memory-mapped and the IP
> design is very similar to the mk712.
>
> This commit adds the support for this
On Wed, Dec 16, 2015 at 11:43 PM, Arnd Bergmann wrote:
> On Wednesday 16 December 2015 14:55:43 Andre Przywara wrote:
>> Using the plain multi_v7_defconfig (which doesn't have LPAE and makes me
>> loose half of the RAM on that box) didn't show the bug so far.
>> One of the effects of turning on LP
On Wed, Dec 16, 2015 at 10:55 PM, Andre Przywara wrote:
> Hi,
>
> On 15/12/15 13:39, Ming Lei wrote:
>> On Tue, Dec 15, 2015 at 8:23 PM, Andre Przywara
>> wrote:
>>> Hi Ming,
>>>
>>> thanks for the answer!
>>>
>>> On 15/12/15 11:54, Ming Lei wrote:
On Tue, Dec 15, 2015 at 7:05 PM, Andre Prz
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicet...@vger.kernel.org
Signed-off-by: Mark Yao
---
.../bindings/display/rockchip/rockchip-vop.txt |1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/roc
RK3036 registers layout is quite difference with rk3288 layout,
The IC design with different framework, rk3036 vop is VOP LITE,
and rk3288 is VOP FULL.
RK3036 support two overlay plane and one hwc plane, max output
resolution is 1080p. it support IOMMU, and its IOMMU same as
rk3288's.
Signed-off-
This series of patches add rk3036 vop support.
RK3036 registers layout is quite difference with rk3288 layout,
The IC design with different framework, rk3036 vop is VOP LITE,
and rk3288 is VOP FULL.
RK3036 support two overlay plane and one hwc plane, max output
resolution is 1080p. it support IOM
No functional updates. Spilt register related into another file
would be nice to multi vop driver,
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/Makefile |3 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 325 +--
drivers/gpu/drm/rockchip/rockchip_
There are two version scale control register found on vop,
scale full version found on rk3288, support extension registers.
and scale little version found on rk3036, only support common scale.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 46 ++--
Move interrupt registers into vop_data, so it can use at multi-vop driver
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 81 +++
1 file changed, 69 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/dri
Move cfg_done register into vop_data, so it can use at multi-vop driver
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockc
Mark,
+- regulator-vset-regs: Voltage set register offset.
+- regulator-vset-mask: voltage set control mask.
+- regulator-n-vol: The num of support voltages.
+- regulator-vset-table: The table of support voltages.
> Why is this in the binding? This is a binding for a specific device,
> there
This patch is to enable AMD NTB support in Kconfig and Makefile.
Signed-off-by: Xiangliang Yu
---
drivers/ntb/hw/Kconfig | 1 +
drivers/ntb/hw/Makefile | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/ntb/hw/Kconfig b/drivers/ntb/hw/Kconfig
index 4d5535c..0c5c2a6 100644
--- a/drive
> "John" == John Garry writes:
John> It is preferred that drivers use platform_get_irq() instead of
John> irq_of_parse_and_map(), so replace.
Applied to 4.5/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Thu, Dec 17, 2015 at 11:46:27AM +0900, Kamezawa Hiroyuki wrote:
> On 2015/12/16 20:09, Johannes Weiner wrote:
> >On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote:
> >> - swap-full notification via vmpressure or something mechanism.
> >
> >Why?
> >
>
> I think it's a sign of un
AMD NTB support two features: flush pending requests and wakeup
opposite side from low power state. This patch add two interface
to support these features.
Signed-off-by: Xiangliang Yu
---
drivers/ntb/hw/amd/ntb_hw_amd.c | 16
drivers/ntb/hw/amd/ntb_hw_amd.h | 2 ++
include/lin
Mark,
Thanks very much for your review.
On 2015/12/17 3:16, Mark Brown wrote:
> On Tue, Dec 15, 2015 at 08:54:15PM +0800, Chen Feng wrote:
>
>> +config REGULATOR_HI655X
>> +tristate "Hisilicon HI655X PMIC regulators support"
>> +depends on ARCH_HISI
>> +depends on MFD_HI655X_PMIC && O
AMD NTB support following main features:
(1) Three memory windows;
(2) Sixteen 32-bit scratch pad;
(3) Two 16-bit doorbell interrupt;
(4) Five event interrupts;
(5) One system can wake up opposite system of NTB;
(6) Flush previous request to the opposite system;
(7) There are reset and PME_TO mecha
Hi,
On 12/11/15 at 03:26pm, Johannes Berg wrote:
> On Mon, 2015-11-23 at 09:37 +0800, Dave Young wrote:
>
> > Seems there're a lot of other wireless messages. Should we refactor
> > them as well? I still did not get chance to see where is the code.
> > (My wireless driver being used is iwlwifi)
On 12/14/2015 9:08 AM, Joerg Roedel wrote:
On Fri, Dec 11, 2015 at 04:54:38PM -0600, Suravee Suthikulpanit wrote:
Current driver makes assumption that device with devid zero is always
included in the range of devices to be managed by IOMMU. However,
certain FW does not include devid zero in IVRS
Sorry, Ops, fat finger, discard this lost thread mail.
On 2015年12月17日 11:08, Mark Yao wrote:
encoder.enable is more compatible to atomic api than encoder.prepare/commit
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++
Hi, Johannes
Sorry for late feedback, I was busying on other things.
On 12/11/15 at 03:38pm, Johannes Berg wrote:
> On Sun, 2015-11-15 at 15:31 +0800, Dave Young wrote:
> > cfg80211 module prints a lot of messages like below. Actually
> > printing once is acceptable but sometimes it will print ag
Sorry, Ops, fat finger, discard this lost thread mail.
On 2015年12月17日 11:08, Mark Yao wrote:
Fill atomic needed funcs with default atomic helper library.
Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.
Now another drm driver use dw_hdmi i
encoder.enable is more compatible to atomic api than encoder.prepare/commit
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockch
On Wed, 2015-12-16 at 12:48 +, Robin Murphy wrote:
> On 16/12/15 05:59, Yong Wu wrote:
> > On Tue, 2015-12-15 at 12:37 +, Robin Murphy wrote:
> >> On 15/12/15 03:28, Yong Wu wrote:
> >>> On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote:
> On Tue, Dec 08, 2015 at 05:49:12PM +0800,
Fill atomic needed funcs with default atomic helper library.
Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.
Now another drm driver use dw_hdmi is imx, not yet atomic, so
check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
Cc: Ru
Fill atomic needed funcs with default atomic helper library.
Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.
Now another drm driver use dw_hdmi is imx, not yet atomic, so
check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
Cc: Ru
encoder.enable is more compatible to atomic api than encoder.prepare/commit
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockch
Both connecter gate and out_mode are not conflict with mode set
configure. Direct setting connecter gate and out_mode, that allow
connector do rockchip_drm_crtc_mode_config after mode set.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/rockchip_drm_v
If drm core requests a async commit, rockchip_drm_atomic_commit
will schedule a work task to update later.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2:
- serialize outstanding asynchronous commits
drivers/gpu/drm/rockchip/rockchip_drm_drv.c |3 ++
drivers/gpu/drm/rockchip/r
No functional update, drm_vblank_* is the legacy version of
drm_crtc_vblank_*. and use new api make driver more clean.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 13 +++--
drivers/gpu/drm/rockchip/rockchip_drm_drv.
The series of patches coverting drm rockchip to atomic API, do some
cleanup and some fixes on atomic side.
TODO: fence is not support on current version.
Tested on rk3288 popmetal board.
All guys can test it with following url:
test case: https://github.com/markyzq/libdrm.git atomictest
kernel
Rk3288 vop timing registers is immediately register, when configure
timing on display active time, will cause tearing. use dclk reset is
not a good idea to avoid this tearing. we can avoid tearing by using
standby register.
Vop standby register will take effect at end of current frame, and
go back
Rockchip vop not support hw vblank counter, needed check the committed
register if it's really take effect.
Signed-off-by: Mark Yao
Signed-off-by: Tomasz Figa
---
Changes in v3:
Reported by kbuild test robot
- fix rockchip_crtc_wait_for_update undefined when build drm rockchip as
modules.
Chan
For vop, power by enable/disable is more suitable then legacy dpms
function, and enable/disable more closely to the new atomic API.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 37 +++
1 file changed,
On 12/16/2015 8:56 PM, Loc Ho wrote:
Hi,
The current driver uses input clock source frequency to calculate
values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
currently have a good way to provide the frequency information.
Instead, we can leverage the SSCN and FFCN ACPI
On 2015/12/17 9:38, Izumi, Taku wrote:
> Dear Xishi,
>
> Sorry for late.
>
>> -Original Message-
>> From: Xishi Qiu [mailto:qiuxi...@huawei.com]
>> Sent: Friday, December 11, 2015 6:44 PM
>> To: Izumi, Taku/泉 拓
>> Cc: Luck, Tony; linux-kernel@vger.kernel.org; linux...@kvack.org;
>> a..
Hi,
> The current driver uses input clock source frequency to calculate
> values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
> currently have a good way to provide the frequency information.
> Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used
> to
On 12/16/2015 04:48 PM, Xiao Guangrong wrote:
On 12/16/2015 04:05 PM, Kai Huang wrote:
On 12/15/2015 05:25 PM, Xiao Guangrong wrote:
On 12/15/2015 04:43 PM, Kai Huang wrote:
On 12/01/2015 02:26 AM, Xiao Guangrong wrote:
Now, all non-leaf shadow page are page tracked, if gfn is not t
r' [-Werror=implicit-function-declaration]
ctrl_bclr(p->ovf, p->mapcommon + TISRC);
^
Caused by commit
1ddca16cc5b3 ("clocksource/drivers/h8300: Use ioread / iowrite")
ctrl_bclr is only defined for the h8300 arch ...
I have used the clocksource tree from next-20151216
1 - 100 of 872 matches
Mail list logo