On Fri, Nov 30, 2018 at 06:59:20PM +0100, David Hildenbrand wrote:
>Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device
>memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No
>functional change.
I would suggest to put more words to this.
"
Function arch_add_m
On Fri, Nov 30, 2018 at 08:26:30PM -0500, Yangtao Li wrote:
> We already have the DEFINE_SHOW_ATTRIBUTE.There is no need to define
> such a macro,so remove BINDER_DEBUG_ENTRY.
>
> Signed-off-by: Yangtao Li
Good catch.
Reviewed-by: Joey Pabalinas
On Fri, Nov 30, 2018 at 08:26:30PM -0500, Yangt
We already have the DEFINE_SHOW_ATTRIBUTE.There is no need to define
such a macro,so remove BINDER_DEBUG_ENTRY.
Signed-off-by: Yangtao Li
---
drivers/android/binder.c | 48 ++--
1 file changed, 17 insertions(+), 31 deletions(-)
diff --git a/drivers/android/bi
On Fri, Nov 30, 2018 at 06:59:19PM +0100, David Hildenbrand wrote:
>Memory onlining should always be handled by user space, because only user
>space knows which use cases it wants to satisfy. E.g. memory might be
>onlined to the MOVABLE zone even if it can never be removed from the
>system, e.g. to
On Fri, Nov 30, 2018 at 06:59:18PM +0100, David Hildenbrand wrote:
>This is the second approach, introducing more meaningful memory block
>types and not changing online behavior in the kernel. It is based on
>latest linux-next.
>
>As we found out during dicussion, user space should always handle on
The pull request you sent on Fri, 30 Nov 2018 17:04:57 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> tags/staging-4.20-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cd9a0433238da43611179e44b1d71ad24998b107
Thank you!
--
Deet-doot-
> From: KY Srinivasan
> Sent: Friday, November 30, 2018 9:31 AM
> > From: Dexuan Cui
> > Sent: Thursday, November 29, 2018 12:17 AM
> > To: gre...@linuxfoundation.org
> > Cc: KY Srinivasan ; Haiyang Zhang
> > ; Stephen Hemminger
> > ; linux-ker...@vger.kernel.org;
> > de...@linuxdriverproject.org
Let's introduce new types for different kinds of memory blocks and use
them in existing code. As I don't see an easy way to split this up,
do it in one hunk for now.
acpi:
Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.
Properly change the type when trying to add memor
We now have proper types for all users, we can drop this one.
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Pavel Tatashin
Cc: Stephen Rothwell
Cc: Andrew Banman
Cc: "mike.tra...@hpe.com"
Cc: Oscar Salvador
Cc: Dave Hansen
Cc: Michal Hocko
Cc: Mich
Memory onlining should always be handled by user space, because only user
space knows which use cases it wants to satisfy. E.g. memory might be
onlined to the MOVABLE zone even if it can never be removed from the
system, e.g. to make usage of huge pages more reliable.
However to implement such rul
Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device
memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No
functional change.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Martin Schwidefsky
Cc: Heiko
This is the second approach, introducing more meaningful memory block
types and not changing online behavior in the kernel. It is based on
latest linux-next.
As we found out during dicussion, user space should always handle onlining
of memory, in any case. However in order to make smart decisions
> -Original Message-
> From: Dexuan Cui
> Sent: Thursday, November 29, 2018 12:17 AM
> To: gre...@linuxfoundation.org
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; a...@canonical.com; vkuznets
> ; o...@aepfle.
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-4.20-rc5
for you to fetch changes up to c648284f6c96
seq_file.h does not need to be included,so remove it.
Signed-off-by: Yangtao Li
---
drivers/staging/android/ion/ion.c | 1 -
drivers/staging/android/ion/ion_system_heap.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android
Hi,
On Fri, 2018-11-30 at 11:38 +0800, Chen-Yu Tsai wrote:
> On Fri, Nov 16, 2018 at 12:52 AM Chen-Yu Tsai wrote:
> > On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
> > wrote:
> > > Add the H5-specific system control node description to its device-tree
> > > with support for the SRAM C1 sect
Hi,
On Thu, 2018-11-15 at 23:35 +0800, Chen-Yu Tsai wrote:
> On Thu, Nov 15, 2018 at 10:51 PM Paul Kocialkowski
> wrote:
> > This adds nodes for the Video Engine and the associated reserved memory
> > for the H5. Up to 96 MiB of memory are dedicated to the CMA pool.
> >
> > The pool is located a
On Tue, Nov 27, 2018 at 05:59:48AM +, Cheng Fei Phung wrote:
> This patch adds RIFFA PCIe linux driver for
> https://github.com/promach/riffa/tree/full_duplex/driver/linux
>
> This staging driver is modified from this upstream driver at
> https://github.com/KastnerRG/riffa/tree/master/driver
On Tue, Nov 27, 2018 at 12:19:07AM +0100, Cristian Sicilia wrote:
> In the first patch there is a fix of some parenthesis that terminate
> on end of line and some parameters that are not aligned with
> previous parenthesis.
>
> The second patch is a proposal that avoid the long line refactoring
>
We initially introduced a spin lock to ensure that the VPU registers
are not accessed concurrently between our setup function and IRQ
handler. The V4L2 M2M API ensures that only one decoding job runs at a
time, so the interrupt signaling the end of decoding will not occur
while the next picture is
20 matches
Mail list logo
