* RE: [PATCH 2/2] drm/amd/amdgpu: Tidy up formatting in si_enums.h
From: Deucher, Alexander @ 2016-11-14 20:12 UTC (permalink / raw)
To: 'Tom St Denis',
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: StDenis, Tom
In-Reply-To: <20161114185746.18225-2-tom.stdenis-5C7GfCeVMHo@public.gmane.org>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Tom St Denis
> Sent: Monday, November 14, 2016 1:58 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: StDenis, Tom
> Subject: [PATCH 2/2] drm/amd/amdgpu: Tidy up formatting in si_enums.h
>
> Clean up formatting/alignment in si_enums.h to make it
> more presentable.
>
> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
NACK on this one. It makes it harder to see which defines are related to which packets.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/si_enums.h | 241 +++++++++++++++++-----
> ------------
> 1 file changed, 121 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/si_enums.h
> b/drivers/gpu/drm/amd/amdgpu/si_enums.h
> index fde2086246fa..8fd54f6cd4f0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si_enums.h
> +++ b/drivers/gpu/drm/amd/amdgpu/si_enums.h
> @@ -146,127 +146,128 @@
> #define VERDE_GB_ADDR_CONFIG_GOLDEN 0x12010002
> #define HAINAN_GB_ADDR_CONFIG_GOLDEN 0x02010001
>
> -#define PACKET3(op, n) ((RADEON_PACKET_TYPE3 << 30) | \
> - (((op) & 0xFF) << 8) | \
> +#define PACKET3(op, n) ((RADEON_PACKET_TYPE3 << 30) | \
> + (((op) & 0xFF) << 8) | \
> ((n) & 0x3FFF) << 16)
> +
> #define PACKET3_COMPUTE(op, n) (PACKET3(op, n) | 1 << 1)
> -#define PACKET3_NOP 0x10
> -#define PACKET3_SET_BASE 0x11
> -#define PACKET3_BASE_INDEX(x) ((x) << 0)
> -#define PACKET3_CLEAR_STATE 0x12
> -#define PACKET3_INDEX_BUFFER_SIZE 0x13
> -#define PACKET3_DISPATCH_DIRECT 0x15
> -#define PACKET3_DISPATCH_INDIRECT 0x16
> -#define PACKET3_ALLOC_GDS 0x1B
> -#define PACKET3_WRITE_GDS_RAM 0x1C
> -#define PACKET3_ATOMIC_GDS 0x1D
> -#define PACKET3_ATOMIC 0x1E
> -#define PACKET3_OCCLUSION_QUERY 0x1F
> -#define PACKET3_SET_PREDICATION 0x20
> -#define PACKET3_REG_RMW 0x21
> -#define PACKET3_COND_EXEC 0x22
> -#define PACKET3_PRED_EXEC 0x23
> -#define PACKET3_DRAW_INDIRECT 0x24
> -#define PACKET3_DRAW_INDEX_INDIRECT 0x25
> -#define PACKET3_INDEX_BASE 0x26
> -#define PACKET3_DRAW_INDEX_2 0x27
> -#define PACKET3_CONTEXT_CONTROL 0x28
> -#define PACKET3_INDEX_TYPE 0x2A
> -#define PACKET3_DRAW_INDIRECT_MULTI 0x2C
> -#define PACKET3_DRAW_INDEX_AUTO
> 0x2D
> -#define PACKET3_DRAW_INDEX_IMMD
> 0x2E
> -#define PACKET3_NUM_INSTANCES 0x2F
> -#define PACKET3_DRAW_INDEX_MULTI_AUTO
> 0x30
> -#define PACKET3_INDIRECT_BUFFER_CONST 0x31
> -#define PACKET3_INDIRECT_BUFFER 0x3F
> -#define PACKET3_STRMOUT_BUFFER_UPDATE 0x34
> -#define PACKET3_DRAW_INDEX_OFFSET_2 0x35
> -#define PACKET3_DRAW_INDEX_MULTI_ELEMENT 0x36
> -#define PACKET3_WRITE_DATA 0x37
> -#define PACKET3_DRAW_INDEX_INDIRECT_MULTI 0x38
> -#define PACKET3_MEM_SEMAPHORE 0x39
> -#define PACKET3_MPEG_INDEX 0x3A
> -#define PACKET3_COPY_DW 0x3B
> -#define PACKET3_WAIT_REG_MEM 0x3C
> -#define PACKET3_MEM_WRITE 0x3D
> -#define PACKET3_COPY_DATA 0x40
> -#define PACKET3_CP_DMA 0x41
> -# define PACKET3_CP_DMA_DST_SEL(x) ((x) << 20)
> -# define PACKET3_CP_DMA_ENGINE(x) ((x) << 27)
> -# define PACKET3_CP_DMA_SRC_SEL(x) ((x) << 29)
> -# define PACKET3_CP_DMA_CP_SYNC (1 << 31)
> -# define PACKET3_CP_DMA_DIS_WC (1 << 21)
> -# define PACKET3_CP_DMA_CMD_SRC_SWAP(x) ((x) << 22)
> -# define PACKET3_CP_DMA_CMD_DST_SWAP(x) ((x) << 24)
> -# define PACKET3_CP_DMA_CMD_SAS (1 << 26)
> -# define PACKET3_CP_DMA_CMD_DAS (1 << 27)
> -# define PACKET3_CP_DMA_CMD_SAIC (1 << 28)
> -# define PACKET3_CP_DMA_CMD_DAIC (1 << 29)
> -# define PACKET3_CP_DMA_CMD_RAW_WAIT (1 << 30)
> -#define PACKET3_PFP_SYNC_ME 0x42
> -#define PACKET3_SURFACE_SYNC 0x43
> -# define PACKET3_DEST_BASE_0_ENA (1 << 0)
> -# define PACKET3_DEST_BASE_1_ENA (1 << 1)
> -# define PACKET3_CB0_DEST_BASE_ENA (1 << 6)
> -# define PACKET3_CB1_DEST_BASE_ENA (1 << 7)
> -# define PACKET3_CB2_DEST_BASE_ENA (1 << 8)
> -# define PACKET3_CB3_DEST_BASE_ENA (1 << 9)
> -# define PACKET3_CB4_DEST_BASE_ENA (1 << 10)
> -# define PACKET3_CB5_DEST_BASE_ENA (1 << 11)
> -# define PACKET3_CB6_DEST_BASE_ENA (1 << 12)
> -# define PACKET3_CB7_DEST_BASE_ENA (1 << 13)
> -# define PACKET3_DB_DEST_BASE_ENA (1 << 14)
> -# define PACKET3_DEST_BASE_2_ENA (1 << 19)
> -# define PACKET3_DEST_BASE_3_ENA (1 << 21)
> -# define PACKET3_TCL1_ACTION_ENA (1 << 22)
> -# define PACKET3_TC_ACTION_ENA (1 << 23)
> -# define PACKET3_CB_ACTION_ENA (1 << 25)
> -# define PACKET3_DB_ACTION_ENA (1 << 26)
> -# define PACKET3_SH_KCACHE_ACTION_ENA (1 << 27)
> -# define PACKET3_SH_ICACHE_ACTION_ENA (1 << 29)
> -#define PACKET3_ME_INITIALIZE 0x44
> -#define PACKET3_ME_INITIALIZE_DEVICE_ID(x) ((x) << 16)
> -#define PACKET3_COND_WRITE 0x45
> -#define PACKET3_EVENT_WRITE 0x46
> -#define PACKET3_EVENT_WRITE_EOP 0x47
> -#define PACKET3_EVENT_WRITE_EOS 0x48
> -#define PACKET3_PREAMBLE_CNTL 0x4A
> -# define PACKET3_PREAMBLE_BEGIN_CLEAR_STATE (2 << 28)
> -# define PACKET3_PREAMBLE_END_CLEAR_STATE (3 << 28)
> -#define PACKET3_ONE_REG_WRITE 0x57
> -#define PACKET3_LOAD_CONFIG_REG 0x5F
> -#define PACKET3_LOAD_CONTEXT_REG 0x60
> -#define PACKET3_LOAD_SH_REG 0x61
> -#define PACKET3_SET_CONFIG_REG 0x68
> -#define PACKET3_SET_CONFIG_REG_START
> 0x00002000
> -#define PACKET3_SET_CONFIG_REG_END
> 0x00002c00
> -#define PACKET3_SET_CONTEXT_REG 0x69
> -#define PACKET3_SET_CONTEXT_REG_START
> 0x000a000
> -#define PACKET3_SET_CONTEXT_REG_END
> 0x000a400
> -#define PACKET3_SET_CONTEXT_REG_INDIRECT 0x73
> -#define PACKET3_SET_RESOURCE_INDIRECT 0x74
> -#define PACKET3_SET_SH_REG 0x76
> -#define PACKET3_SET_SH_REG_START
> 0x00002c00
> -#define PACKET3_SET_SH_REG_END
> 0x00003000
> -#define PACKET3_SET_SH_REG_OFFSET 0x77
> -#define PACKET3_ME_WRITE 0x7A
> -#define PACKET3_SCRATCH_RAM_WRITE 0x7D
> -#define PACKET3_SCRATCH_RAM_READ 0x7E
> -#define PACKET3_CE_WRITE 0x7F
> -#define PACKET3_LOAD_CONST_RAM 0x80
> -#define PACKET3_WRITE_CONST_RAM 0x81
> -#define PACKET3_WRITE_CONST_RAM_OFFSET
> 0x82
> -#define PACKET3_DUMP_CONST_RAM 0x83
> -#define PACKET3_INCREMENT_CE_COUNTER 0x84
> -#define PACKET3_INCREMENT_DE_COUNTER 0x85
> -#define PACKET3_WAIT_ON_CE_COUNTER 0x86
> -#define PACKET3_WAIT_ON_DE_COUNTER 0x87
> -#define PACKET3_WAIT_ON_DE_COUNTER_DIFF
> 0x88
> -#define PACKET3_SET_CE_DE_COUNTERS 0x89
> -#define PACKET3_WAIT_ON_AVAIL_BUFFER 0x8A
> -#define PACKET3_SWITCH_BUFFER 0x8B
> -#define PACKET3_SEM_WAIT_ON_SIGNAL (0x1 << 12)
> -#define PACKET3_SEM_SEL_SIGNAL (0x6 << 29)
> -#define PACKET3_SEM_SEL_WAIT (0x7 << 29)
> +#define PACKET3_NOP 0x10
> +#define PACKET3_SET_BASE 0x11
> +#define PACKET3_BASE_INDEX(x) ((x) << 0)
> +#define PACKET3_CLEAR_STATE 0x12
> +#define PACKET3_INDEX_BUFFER_SIZE 0x13
> +#define PACKET3_DISPATCH_DIRECT 0x15
> +#define PACKET3_DISPATCH_INDIRECT 0x16
> +#define PACKET3_ALLOC_GDS 0x1B
> +#define PACKET3_WRITE_GDS_RAM 0x1C
> +#define PACKET3_ATOMIC_GDS 0x1D
> +#define PACKET3_ATOMIC 0x1E
> +#define PACKET3_OCCLUSION_QUERY 0x1F
> +#define PACKET3_SET_PREDICATION 0x20
> +#define PACKET3_REG_RMW 0x21
> +#define PACKET3_COND_EXEC 0x22
> +#define PACKET3_PRED_EXEC 0x23
> +#define PACKET3_DRAW_INDIRECT 0x24
> +#define PACKET3_DRAW_INDEX_INDIRECT 0x25
> +#define PACKET3_INDEX_BASE 0x26
> +#define PACKET3_DRAW_INDEX_2 0x27
> +#define PACKET3_CONTEXT_CONTROL 0x28
> +#define PACKET3_INDEX_TYPE 0x2A
> +#define PACKET3_DRAW_INDIRECT_MULTI 0x2C
> +#define PACKET3_DRAW_INDEX_AUTO 0x2D
> +#define PACKET3_DRAW_INDEX_IMMD 0x2E
> +#define PACKET3_NUM_INSTANCES 0x2F
> +#define PACKET3_DRAW_INDEX_MULTI_AUTO 0x30
> +#define PACKET3_INDIRECT_BUFFER_CONST 0x31
> +#define PACKET3_INDIRECT_BUFFER 0x3F
> +#define PACKET3_STRMOUT_BUFFER_UPDATE 0x34
> +#define PACKET3_DRAW_INDEX_OFFSET_2 0x35
> +#define PACKET3_DRAW_INDEX_MULTI_ELEMENT 0x36
> +#define PACKET3_WRITE_DATA 0x37
> +#define PACKET3_DRAW_INDEX_INDIRECT_MULTI 0x38
> +#define PACKET3_MEM_SEMAPHORE 0x39
> +#define PACKET3_MPEG_INDEX 0x3A
> +#define PACKET3_COPY_DW 0x3B
> +#define PACKET3_WAIT_REG_MEM 0x3C
> +#define PACKET3_MEM_WRITE 0x3D
> +#define PACKET3_COPY_DATA 0x40
> +#define PACKET3_CP_DMA 0x41
> +#define PACKET3_CP_DMA_DST_SEL(x) ((x) << 20)
> +#define PACKET3_CP_DMA_ENGINE(x) ((x) << 27)
> +#define PACKET3_CP_DMA_SRC_SEL(x) ((x) << 29)
> +#define PACKET3_CP_DMA_CP_SYNC (1 << 31)
> +#define PACKET3_CP_DMA_DIS_WC (1 << 21)
> +#define PACKET3_CP_DMA_CMD_SRC_SWAP(x) ((x) << 22)
> +#define PACKET3_CP_DMA_CMD_DST_SWAP(x) ((x) << 24)
> +#define PACKET3_CP_DMA_CMD_SAS (1 << 26)
> +#define PACKET3_CP_DMA_CMD_DAS (1 << 27)
> +#define PACKET3_CP_DMA_CMD_SAIC (1 << 28)
> +#define PACKET3_CP_DMA_CMD_DAIC (1 << 29)
> +#define PACKET3_CP_DMA_CMD_RAW_WAIT (1 << 30)
> +#define PACKET3_PFP_SYNC_ME 0x42
> +#define PACKET3_SURFACE_SYNC 0x43
> +#define PACKET3_DEST_BASE_0_ENA (1 << 0)
> +#define PACKET3_DEST_BASE_1_ENA (1 << 1)
> +#define PACKET3_CB0_DEST_BASE_ENA (1 << 6)
> +#define PACKET3_CB1_DEST_BASE_ENA (1 << 7)
> +#define PACKET3_CB2_DEST_BASE_ENA (1 << 8)
> +#define PACKET3_CB3_DEST_BASE_ENA (1 << 9)
> +#define PACKET3_CB4_DEST_BASE_ENA (1 << 10)
> +#define PACKET3_CB5_DEST_BASE_ENA (1 << 11)
> +#define PACKET3_CB6_DEST_BASE_ENA (1 << 12)
> +#define PACKET3_CB7_DEST_BASE_ENA (1 << 13)
> +#define PACKET3_DB_DEST_BASE_ENA (1 << 14)
> +#define PACKET3_DEST_BASE_2_ENA (1 << 19)
> +#define PACKET3_DEST_BASE_3_ENA (1 << 21)
> +#define PACKET3_TCL1_ACTION_ENA (1 << 22)
> +#define PACKET3_TC_ACTION_ENA (1 << 23)
> +#define PACKET3_CB_ACTION_ENA (1 << 25)
> +#define PACKET3_DB_ACTION_ENA (1 << 26)
> +#define PACKET3_SH_KCACHE_ACTION_ENA (1 << 27)
> +#define PACKET3_SH_ICACHE_ACTION_ENA (1 << 29)
> +#define PACKET3_ME_INITIALIZE 0x44
> +#define PACKET3_ME_INITIALIZE_DEVICE_ID(x) ((x) << 16)
> +#define PACKET3_COND_WRITE 0x45
> +#define PACKET3_EVENT_WRITE 0x46
> +#define PACKET3_EVENT_WRITE_EOP 0x47
> +#define PACKET3_EVENT_WRITE_EOS 0x48
> +#define PACKET3_PREAMBLE_CNTL 0x4A
> +#define PACKET3_PREAMBLE_BEGIN_CLEAR_STATE (2 << 28)
> +#define PACKET3_PREAMBLE_END_CLEAR_STATE (3 << 28)
> +#define PACKET3_ONE_REG_WRITE 0x57
> +#define PACKET3_LOAD_CONFIG_REG 0x5F
> +#define PACKET3_LOAD_CONTEXT_REG 0x60
> +#define PACKET3_LOAD_SH_REG 0x61
> +#define PACKET3_SET_CONFIG_REG 0x68
> +#define PACKET3_SET_CONFIG_REG_START 0x00002000
> +#define PACKET3_SET_CONFIG_REG_END 0x00002c00
> +#define PACKET3_SET_CONTEXT_REG 0x69
> +#define PACKET3_SET_CONTEXT_REG_START 0x000a000
> +#define PACKET3_SET_CONTEXT_REG_END 0x000a400
> +#define PACKET3_SET_CONTEXT_REG_INDIRECT 0x73
> +#define PACKET3_SET_RESOURCE_INDIRECT 0x74
> +#define PACKET3_SET_SH_REG 0x76
> +#define PACKET3_SET_SH_REG_START 0x00002c00
> +#define PACKET3_SET_SH_REG_END 0x00003000
> +#define PACKET3_SET_SH_REG_OFFSET 0x77
> +#define PACKET3_ME_WRITE 0x7A
> +#define PACKET3_SCRATCH_RAM_WRITE 0x7D
> +#define PACKET3_SCRATCH_RAM_READ 0x7E
> +#define PACKET3_CE_WRITE 0x7F
> +#define PACKET3_LOAD_CONST_RAM 0x80
> +#define PACKET3_WRITE_CONST_RAM 0x81
> +#define PACKET3_WRITE_CONST_RAM_OFFSET 0x82
> +#define PACKET3_DUMP_CONST_RAM 0x83
> +#define PACKET3_INCREMENT_CE_COUNTER 0x84
> +#define PACKET3_INCREMENT_DE_COUNTER 0x85
> +#define PACKET3_WAIT_ON_CE_COUNTER 0x86
> +#define PACKET3_WAIT_ON_DE_COUNTER 0x87
> +#define PACKET3_WAIT_ON_DE_COUNTER_DIFF 0x88
> +#define PACKET3_SET_CE_DE_COUNTERS 0x89
> +#define PACKET3_WAIT_ON_AVAIL_BUFFER 0x8A
> +#define PACKET3_SWITCH_BUFFER 0x8B
> +#define PACKET3_SEM_WAIT_ON_SIGNAL (0x1 << 12)
> +#define PACKET3_SEM_SEL_SIGNAL (0x6 << 29)
> +#define PACKET3_SEM_SEL_WAIT (0x7 << 29)
>
> #endif
> --
> 2.10.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [U-Boot] [PATCH RESEND 6/9] eeprom: Add DS2431 support
From: Maxime Ripard @ 2016-11-14 20:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161114151457.GG27304@bill-the-cat>
On Mon, Nov 14, 2016 at 10:14:57AM -0500, Tom Rini wrote:
> On Mon, Nov 14, 2016 at 02:42:59PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Nov 11, 2016 at 11:16:39AM -0800, Moritz Fischer wrote:
> > > > +U_BOOT_DRIVER(ds2431) = {
> > > > + .name = "ds2431",
> > > > + .id = UCLASS_EEPROM,
> > > > + .ops = &ds2431_ops,
> > >
> > > Do you want to add a .flags = DM_UC_FLAG_SEQ_ALIAS here?
> >
> > I don't know. I was kind of wondering why U-Boot relies on aliases so
> > much, especially when the Linux DT maintainers are saying that aliases
> > should be avoided entirely, and we'll won't be able to upstream those
> > changes.
>
> Bah. Do you have a pointer to some discussion about this handy?
Rob said this multiple times, but here is an example:
http://lkml.iu.edu/hypermail/linux/kernel/1609.1/00653.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/a0ffdcc3/attachment.sig>
^ permalink raw reply
* Re: [Libtirpc-devel] [PATCH rpcbind] Move default state-dir to /run/rpcbind
From: Mike Frysinger @ 2016-11-14 20:12 UTC (permalink / raw)
To: Steve Dickson; +Cc: NeilBrown, Linux NFS Mailing List, libtirpc-devel
In-Reply-To: <8cbf8fc2-d358-37ca-75cf-c4e85e7aa3a4@RedHat.com>
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
On 14 Nov 2016 14:26, Steve Dickson wrote:
> On 11/14/2016 02:12 PM, Mike Frysinger wrote:
> > On 14 Nov 2016 10:09, NeilBrown wrote:
> >> On Sat, Nov 12 2016, Mike Frysinger wrote:
> >>> On 11 Nov 2016 14:36, NeilBrown wrote:
> >>>> rpcbind can save state in a file to allow restart without forgetting
> >>>> about running services.
> >>>>
> >>>> The default location is currently "/tmp" which is an over-used
> >>>> directory that isn't really suitable for system files.
> >>>> The modern preferences would be a subdirectory of "/run", which can
> >>>> be selected with a ./configure option. That subdirectory would still need
> >>>> to be created by something.
> >>> the portable path is /var/cache instead of /run. i don't think libtirpc
> >>> should be configuring itself to assume Linux by default.
> >> In principle I agree. But is /var/cache really a good choice?
> >> We don't want the state files to persist over a reboot, and I strongly
> >> suspect that /var/cache is designed to do exactly that.
> >>
> >> Are there agree standards that are broader than Linux that we can look
> >> to?
> >> FHS defines /var/run (or even /run) but I suspect it is linux-only.
> > /var/run should work across systems i believe. at least BSD's support it.
>
> In the Red Hat distos /var/run is a symbolic link to /run and the systemd
> folks have asked us to use /run instead of /var/run
yes, but we already know that's not an acceptable default -- /run today
is Linux specific. the question i was responding to here is if there's
a portable location that is better than /tmp.
Linux distros already know that for many packages they need to pass
flags to get /run behavior. rpcbind is no different.
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2] mm, thb: propagation of conditional compilation in khugepaged.c
From: Jérémy Lefaure @ 2016-11-14 20:12 UTC (permalink / raw)
To: Andrew Morton, Kirill A. Shutemov; +Cc: linux-mm, Jérémy Lefaure
Commit b46e756f5e47 ("thp: extract khugepaged from mm/huge_memory.c")
moved code from huge_memory.c to khugepaged.c. Some of this code should
be compiled only when CONFIG_SYSFS is enabled but the condition around
this code was not moved into khugepaged.c. The result is a compilation
error when CONFIG_SYSFS is disabled:
mm/built-in.o: In function `khugepaged_defrag_store':
khugepaged.c:(.text+0x2d095): undefined reference to
`single_hugepage_flag_store'
mm/built-in.o: In function `khugepaged_defrag_show':
khugepaged.c:(.text+0x2d0ab): undefined reference to
`single_hugepage_flag_show'
This commit adds the #ifdef CONFIG_SYSFS around the code related to
sysfs.
Signed-off-by: JA(C)rA(C)my Lefaure <jeremy.lefaure@lse.epita.fr>
---
After having discuted with Hillf, I changed the subject to replace "thb" by
"mm, thb". I also rewrote the subject.
mm/khugepaged.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 728d779..87e1a7ca 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -103,6 +103,7 @@ static struct khugepaged_scan khugepaged_scan = {
.mm_head = LIST_HEAD_INIT(khugepaged_scan.mm_head),
};
+#ifdef CONFIG_SYSFS
static ssize_t scan_sleep_millisecs_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -295,6 +296,7 @@ struct attribute_group khugepaged_attr_group = {
.attrs = khugepaged_attr,
.name = "khugepaged",
};
+#endif /* CONFIG_SYSFS */
#define VM_NO_KHUGEPAGED (VM_SPECIAL | VM_HUGETLB)
--
2.10.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning
From: Tom Rini @ 2016-11-14 20:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <91683a9a-6f16-21dc-4295-d49f35acfce6@arm.com>
On Mon, Nov 14, 2016 at 07:43:40PM +0000, Andr? Przywara wrote:
[snip]
> On a related matter, I ran buildman on HEAD for armv8 today and GCC 6.2
> found quite some issues (will send out the fixes ASAP).
> So is there some buildbot somewhere that runs buildman? If yes, with
> what compilers?
What gcc-6.2 compilers are you using? The travis-ci setup is using the
Ubuntu 'Trusty' compilers, which are not that recent. I also have been
running debian/unstable in a chroot, but it's old enough of a copy to be
using gcc-5.3.1 currently. I'm going to kick off a new debootstrap
now'ish to see what toolchain versions I can get there. Do you know if
these gcc-6.2 problems you see would also show up for rpi3 in 64bit
mode? That's my current easiest test platform for aarch64. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/d9cf91c9/attachment.sig>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 02/21] specs/qcow2: do not use wording 'bitmap header'
From: John Snow @ 2016-11-14 20:08 UTC (permalink / raw)
To: Vladimir Sementsov-Ogievskiy, qemu-block, qemu-devel
Cc: kwolf, famz, armbru, mreitz, stefanha, pbonzini, den
In-Reply-To: <1478715476-132280-3-git-send-email-vsementsov@virtuozzo.com>
On 11/09/2016 01:17 PM, Vladimir Sementsov-Ogievskiy wrote:
> A bitmap directory entry is sometimes called a 'bitmap header'. This
> patch leaves only one name - 'bitmap directory entry'. The name 'bitmap
> header' creates misunderstandings with 'qcow2 header' and 'qcow2 bitmap
> header extension' (which is extension of qcow2 header)
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> ---
> docs/specs/qcow2.txt | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
> index dda53dd..8874e8c 100644
> --- a/docs/specs/qcow2.txt
> +++ b/docs/specs/qcow2.txt
> @@ -201,7 +201,7 @@ The fields of the bitmaps extension are:
>
> 8 - 15: bitmap_directory_size
> Size of the bitmap directory in bytes. It is the cumulative
> - size of all (nb_bitmaps) bitmap headers.
> + size of all (nb_bitmaps) bitmap directory entries.
>
> 16 - 23: bitmap_directory_offset
> Offset into the image file at which the bitmap directory
> @@ -426,8 +426,7 @@ Each bitmap saved in the image is described in a bitmap directory entry. The
> bitmap directory is a contiguous area in the image file, whose starting offset
> and length are given by the header extension fields bitmap_directory_offset and
> bitmap_directory_size. The entries of the bitmap directory have variable
> -length, depending on the lengths of the bitmap name and extra data. These
> -entries are also called bitmap headers.
> +length, depending on the lengths of the bitmap name and extra data.
>
> Structure of a bitmap directory entry:
>
>
Great improvement.
Reviewed-by: John Snow <jsnow@redhat.com>
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: sun8i: reference-design-tablet: ldo_io1 is vcc-touchscreen
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree
In-Reply-To: <20161113192203.7101-2-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
On Sun, Nov 13, 2016 at 08:22:03PM +0100, Hans de Goede wrote:
> On some Q8 and other tablets ldo_io1 is used as vcc-touchscreen,
> config at as such in sun8i-reference-design-tablet.dtsi.
>
> Note that it will only be enabled when it us actually referenced by
> a foo-supply property in the touchscreen node, so for tablets which
> do not use ldo_io1 as vcc-touchscreen, it will be disabled.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 2/2] ARM: dts: sun8i: reference-design-tablet: ldo_io1 is vcc-touchscreen
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-2-hdegoede@redhat.com>
On Sun, Nov 13, 2016 at 08:22:03PM +0100, Hans de Goede wrote:
> On some Q8 and other tablets ldo_io1 is used as vcc-touchscreen,
> config at as such in sun8i-reference-design-tablet.dtsi.
>
> Note that it will only be enabled when it us actually referenced by
> a foo-supply property in the touchscreen node, so for tablets which
> do not use ldo_io1 as vcc-touchscreen, it will be disabled.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/4197396f/attachment.sig>
^ permalink raw reply
* Re: [PATCH v10 3/3] drm/fence: add out-fences support
From: Daniel Vetter @ 2016-11-14 20:08 UTC (permalink / raw)
To: Brian Starkey
Cc: Gustavo Padovan, dri-devel, Linux Kernel Mailing List,
Daniel Stone, Rob Clark, Greg Hackmann, John Harrison,
Laurent Pinchart, Sean Paul, Stéphane Marchesin, m.chehab,
Maarten Lankhorst, Gustavo Padovan, Syrjala, Ville
In-Reply-To: <20161114145720.GB24412@e106950-lin.cambridge.arm.com>
On Mon, Nov 14, 2016 at 3:57 PM, Brian Starkey <brian.starkey@arm.com> wrote:
> I was just writing some internal docs, and it occurred to me that the
> out-fence implementation here doesn't seem to match what we discussed
> with Ville a few weeks back (which had completely slipped my mind).
>
> Did the idea of returning -1 fences for multiple commits within a
> frame get dropped? I didn't see any discussion further than that
> thread on v5 from October:
> http://lkml.iu.edu/hypermail/linux/kernel/1610.2/04727.html
Atm we only support a queue depth of 1, and not faster than vblank.
This was just discussions to make sure we're not drawing ourselves
into a corner with this uabi.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree
In-Reply-To: <20161113192203.7101-1-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4706 bytes --]
Hi,
On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
>
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
>
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
> 2 files changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> index a8b0bcc..3d7ff10 100644
> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> @@ -83,22 +83,6 @@
> allwinner,pins = "PG3";
> };
>
> -&i2c1 {
> - icn8318: touchscreen@40 {
> - compatible = "chipone,icn8318";
> - reg = <0x40>;
> - interrupt-parent = <&pio>;
> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> - pinctrl-names = "default";
> - pinctrl-0 = <&ts_wake_pin_p66>;
> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> - touchscreen-size-x = <800>;
> - touchscreen-size-y = <480>;
> - touchscreen-inverted-x;
> - touchscreen-swapped-x-y;
> - };
> -};
> -
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins_a>;
> @@ -121,20 +105,26 @@
> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
> -
> - ts_wake_pin_p66: ts_wake_pin@0 {
> - allwinner,pins = "PB3";
> - allwinner,function = "gpio_out";
> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> - };
> -
> };
>
> ®_usb0_vbus {
> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> };
>
> +&touchscreen {
> + compatible = "chipone,icn8318";
> + reg = <0x40>;
> + /* The P66 uses a different EINT then the reference design */
> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + touchscreen-inverted-x;
> + touchscreen-swapped-x-y;
> + status = "okay";
> +};
> +
> &uart1 {
> /* The P66 uses the uart pins as gpios */
> status = "disabled";
> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> index 20cc940..7af488a 100644
> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> @@ -41,6 +41,7 @@
> */
> #include "sunxi-reference-design-tablet.dtsi"
>
> +#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pwm/pwm.h>
>
> / {
> @@ -84,6 +85,23 @@
> };
>
> &i2c1 {
> + /*
> + * The gsl1680 is rated at 400KHz and it will not work reliable at
> + * 100KHz, this has been confirmed on multiple different q8 tablets.
> + * All other devices on this bus are also rated for 400KHz.
> + */
> + clock-frequency = <400000>;
> +
> + touchscreen: touchscreen {
> + interrupt-parent = <&pio>;
> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_power_pin>;
> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + /* Tablet dts must provide reg and compatible */
> + status = "disabled";
> + };
> +
> pcf8563: rtc@51 {
> compatible = "nxp,pcf8563";
> reg = <0x51>;
> @@ -125,6 +143,13 @@
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
>
> + ts_power_pin: ts_power_pin {
> + allwinner,pins = "PB3";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
For the next release, we'll switch to the generic pin mux properties
("pins" and "function"), and we actually implemented the fact that the
drive and pull properties are optional, so you can drop them both.
You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-1-hdegoede@redhat.com>
Hi,
On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
>
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
>
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
> 2 files changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> index a8b0bcc..3d7ff10 100644
> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> @@ -83,22 +83,6 @@
> allwinner,pins = "PG3";
> };
>
> -&i2c1 {
> - icn8318: touchscreen at 40 {
> - compatible = "chipone,icn8318";
> - reg = <0x40>;
> - interrupt-parent = <&pio>;
> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> - pinctrl-names = "default";
> - pinctrl-0 = <&ts_wake_pin_p66>;
> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> - touchscreen-size-x = <800>;
> - touchscreen-size-y = <480>;
> - touchscreen-inverted-x;
> - touchscreen-swapped-x-y;
> - };
> -};
> -
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins_a>;
> @@ -121,20 +105,26 @@
> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
> -
> - ts_wake_pin_p66: ts_wake_pin at 0 {
> - allwinner,pins = "PB3";
> - allwinner,function = "gpio_out";
> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> - };
> -
> };
>
> ®_usb0_vbus {
> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> };
>
> +&touchscreen {
> + compatible = "chipone,icn8318";
> + reg = <0x40>;
> + /* The P66 uses a different EINT then the reference design */
> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + touchscreen-inverted-x;
> + touchscreen-swapped-x-y;
> + status = "okay";
> +};
> +
> &uart1 {
> /* The P66 uses the uart pins as gpios */
> status = "disabled";
> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> index 20cc940..7af488a 100644
> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> @@ -41,6 +41,7 @@
> */
> #include "sunxi-reference-design-tablet.dtsi"
>
> +#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pwm/pwm.h>
>
> / {
> @@ -84,6 +85,23 @@
> };
>
> &i2c1 {
> + /*
> + * The gsl1680 is rated at 400KHz and it will not work reliable at
> + * 100KHz, this has been confirmed on multiple different q8 tablets.
> + * All other devices on this bus are also rated for 400KHz.
> + */
> + clock-frequency = <400000>;
> +
> + touchscreen: touchscreen {
> + interrupt-parent = <&pio>;
> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_power_pin>;
> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + /* Tablet dts must provide reg and compatible */
> + status = "disabled";
> + };
> +
> pcf8563: rtc at 51 {
> compatible = "nxp,pcf8563";
> reg = <0x51>;
> @@ -125,6 +143,13 @@
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
>
> + ts_power_pin: ts_power_pin {
> + allwinner,pins = "PB3";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
For the next release, we'll switch to the generic pin mux properties
("pins" and "function"), and we actually implemented the fact that the
drive and pull properties are optional, so you can drop them both.
You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/7e78a172/attachment.sig>
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: James Pharaoh @ 2016-11-14 20:07 UTC (permalink / raw)
To: Zygo Blaxell, Austin S. Hemmelgarn; +Cc: Mark Fasheh, linux-btrfs
In-Reply-To: <20161114195102.GI21290@hungrycats.org>
On 14/11/16 20:51, Zygo Blaxell wrote:
> On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
>> On 2016-11-14 13:22, James Pharaoh wrote:
>>> One thing I am keen to understand is if BTRFS will automatically ignore
>>> a request to deduplicate a file if it is already deduplicated? Given the
>>> performance I see when doing a repeat deduplication, it seems to me that
>>> it can't be doing so, although this could be caused by the CPU usage you
>>> mention above.
>>
>> What's happening is that the dedupe ioctl does a byte-wise comparison of the
>> ranges to make sure they're the same before linking them. This is actually
>> what takes most of the time when calling the ioctl, and is part of why it
>> takes longer the larger the range to deduplicate is. In essence, it's
>> behaving like an OS should and not trusting userspace to make reasonable
>> requests (which is also why there's a separate ioctl to clone a range from
>> another file instead of deduplicating existing data).
>
> - the extent-same ioctl could check to see which extents
> are referenced by the src and dst ranges, and return success
> immediately without reading data if they are the same (but
> userspace should already know this, or it's wasting a huge amount
> of time before it even calls the kernel).
Yes, this is what I am talking about. I believe I should be able to read
data about the BTRFS data structures and determine if this is the case.
I don't care if there are false matches, due to concurrent updates, but
there'll be a /lot/ of repeat deduplications unless I do this, because
even if the file is identical, the mtime etc hasn't changed, and I have
a record of previously doing a dedupe, there's no guarantee that the
file hasn't been rewritten in place (eg by rsync), and no way that I
know of to reliably detect if a file has been changed.
I am sure there are libraries out there which can look into the data
structures of a BTRFS file system, I haven't researched this in detail
though. I imagine that with some kind of lock on a BTRFS root, this
could be achieved by simply reading the data from the disk, since I
believe that everything is copy-on-write, so no existing data should be
overwritten until all roots referring to it are updated. Perhaps I'm
missing something though...
James
^ permalink raw reply
* Re: [PATCH v5 04/21] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
From: Konrad Rzeszutek Wilk @ 2016-11-14 20:05 UTC (permalink / raw)
To: xen-devel, boris.ostrovsky
Cc: andrew.cooper3, wei.liu2, klancaster, jbeulich, lars.kurth
In-Reply-To: <1474571626-6694-5-git-send-email-boris.ostrovsky@oracle.com>
On Sat, Nov 12, 2016 at 01:02:08PM +0000, Ken Lancaster wrote:
> My apologies for the delay, this is approved.
>
> We approve the action to re-license http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=801d469ad8b2b88f669326327df03d03200efbfb under LGPLv2.1 as requested.
>
> Best,
>
> Ken Lancaster
>
>
..snip..
Heya!
Sending this email to xen-devel mailing list.
Ken,
Thank you so much for helping out with this!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 0/7] FBC atomic cleanups
From: Paulo Zanoni @ 2016-11-14 20:04 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1478883461-20201-1-git-send-email-paulo.r.zanoni@intel.com>
Em Sex, 2016-11-11 às 14:57 -0200, Paulo Zanoni escreveu:
> Ville pointed out two ugly defects in the FBC code, and while trying
> to fix them I spotted a few extra things. No real-world bugs fixed
> here, but IMHO the code is much easier to read now.
I merged patches 1-5 and 7, and will resend patch 6 as a separate
series. Thanks for the quick reviews!
>
> Paulo Zanoni (7):
> drm/i915/fbc: move the intel_fbc_can_choose() call out of the loop
> drm/i915/fbc: replace a loop with
> drm_atomic_get_existing_crtc_state()
> drm/i915/fbc: extract intel_fbc_can_enable()
> drm/i915/fbc: inline intel_fbc_can_choose()
> drm/i915/fbc: use drm_atomic_get_existing_crtc_state when
> appropriate
> drm/i915/fbc: move from crtc_state->enable_fbc to
> plane_state->enable_fbc
> drm/i915/fbc: convert intel_fbc.c to use INTEL_GEN()
>
> drivers/gpu/drm/i915/intel_drv.h | 4 +-
> drivers/gpu/drm/i915/intel_fbc.c | 97 ++++++++++++++++++----------
> ------------
> 2 files changed, 46 insertions(+), 55 deletions(-)
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] Handle SForced in storage_modifiers
From: Luc Van Oostenryck @ 2016-11-14 20:04 UTC (permalink / raw)
To: Jeff Layton; +Cc: linux-sparse, Al Viro
In-Reply-To: <1479150736-28392-1-git-send-email-jlayton@redhat.com>
On Mon, Nov 14, 2016 at 02:12:16PM -0500, Jeff Layton wrote:
> We have been seeing errors like this for a while now in the sparse
> Fedora package, when doing kernel builds:
>
> ./include/linux/err.h:53:25: warning: dereference of noderef expression
> ./include/linux/err.h:35:16: warning: dereference of noderef expression
>
> This spews all over the build because this comes from IS_ERR(), which
> is called everywhere. Even odder, it turns out that if we build the
> package with -fpic turned off, then it works fine.
>
> With some brute-force debugging, I think I've finally found the cause.
> This array is missing the SForced element. When this is added then the
> problem goes away.
>
> As to why this goes away when -fpic is removed, I can only assume that
> we get lucky with the memory layout and have a zeroed out region just
> beyond the end of the array.
>
> Fixes: 3829c4d8b097776e6b3472290a9fae08a705ab7a
> Cc: Al Viro <viro@ftp.linux.org.uk>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> parse.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/parse.c b/parse.c
> index 205e12644a6c..b290ff2636f2 100644
> --- a/parse.c
> +++ b/parse.c
> @@ -1286,7 +1286,8 @@ static unsigned long storage_modifiers(struct decl_state *ctx)
> [SAuto] = MOD_AUTO,
> [SExtern] = MOD_EXTERN,
> [SStatic] = MOD_STATIC,
> - [SRegister] = MOD_REGISTER
> + [SRegister] = MOD_REGISTER,
> + [SForced] = 0
> };
> return mod[ctx->storage_class] | (ctx->is_inline ? MOD_INLINE : 0)
> | (ctx->is_tls ? MOD_TLS : 0);
> --
Humm,
The array is statically initialized and never modified,
your patch shouldn't change anything, and this regardless of
the memory layout or compiler options.
Luc Van Oostenryck
^ permalink raw reply
* Re: [PATCH 1/3] block: fast-path for small and simple direct I/O requests
From: Jens Axboe @ 2016-11-14 20:00 UTC (permalink / raw)
To: Omar Sandoval; +Cc: axboe, linux-block, linux-fsdevel, hch, Christoph Hellwig
In-Reply-To: <20161114193339.GA31821@vader.DHCP.thefacebook.com>
On 11/14/2016 12:33 PM, Omar Sandoval wrote:
> On Fri, Nov 11, 2016 at 10:11:25PM -0700, Jens Axboe wrote:
>> From: Christoph Hellwig <hch@lst.de>
>>
>> This patch adds a small and simple fast patch for small direct I/O
>> requests on block devices that don't use AIO. Between the neat
>> bio_iov_iter_get_pages helper that avoids allocating a page array
>> for get_user_pages and the on-stack bio and biovec this avoid memory
>> allocations and atomic operations entirely in the direct I/O code
>> (lower levels might still do memory allocations and will usually
>> have at least some atomic operations, though).
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Jens Axboe <axboe@fb.com>
>> ---
>> fs/block_dev.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 80 insertions(+)
>>
>
> [snip]
>
>> static ssize_t
>> blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
>> {
>> struct file *file = iocb->ki_filp;
>> struct inode *inode = bdev_file_inode(file);
>> + int nr_pages;
>>
>> + nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
>> + if (!nr_pages)
>> + return 0;
>> + if (is_sync_kiocb(iocb) && nr_pages <= DIO_INLINE_BIO_VECS)
>> + return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
>> return __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
>> blkdev_get_block, NULL, NULL,
>> DIO_SKIP_DIO_COUNT);
>
> __blockdev_direct_IO() does a few cache prefetches that we're now
> bypassing, do we want to do the same in __blkdev_direct_IO_simple()?
> That's the stuff added in 65dd2aa90aa1 ("dio: optimize cache misses in
> the submission path").
Prefetches like that tend to grow stale, in my experience. So we should
probably just evaluate the new path cache behavior and see if it makes
sense.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Geert Uytterhoeven @ 2016-11-14 20:04 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, Ramesh Shanmugasundaram, Mark Rutland,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
Linux Media Mailing List, devicetree@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20161114195200.s62ga2bnutsrocyf@rob-hp-laptop>
Hi Rob,
On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring <robh@kernel.org> wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@
>> > +Example
>> > +--------
>> > +
>> > +SoC common dtsi file
>> > +
>> > + drif00: rif@e6f40000 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f40000 0 0x64>;
>> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
>> > + clocks = <&cpg CPG_MOD 515>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
>> > + dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.
The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif01: rif@e6f50000 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f50000 0 0x64>;
>> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
>> > + clocks = <&cpg CPG_MOD 514>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
>> > + dma-names = "rx", "rx";
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif0: rif@0 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + sub-channels = <&drif00>, <&drif01>;
>> > + status = "disabled";
>> > + };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two channels
>> are mostly independent having separate DT nodes makes sense to me. However, as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.
Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Geert Uytterhoeven @ 2016-11-14 20:04 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, Ramesh Shanmugasundaram, Mark Rutland,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
Linux Media Mailing List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <20161114195200.s62ga2bnutsrocyf@rob-hp-laptop>
Hi Rob,
On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@
>> > +Example
>> > +--------
>> > +
>> > +SoC common dtsi file
>> > +
>> > + drif00: rif@e6f40000 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f40000 0 0x64>;
>> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
>> > + clocks = <&cpg CPG_MOD 515>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
>> > + dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.
The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif01: rif@e6f50000 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f50000 0 0x64>;
>> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
>> > + clocks = <&cpg CPG_MOD 514>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
>> > + dma-names = "rx", "rx";
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif0: rif@0 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + sub-channels = <&drif00>, <&drif01>;
>> > + status = "disabled";
>> > + };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two channels
>> are mostly independent having separate DT nodes makes sense to me. However, as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.
Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
From: Paulo Zanoni @ 2016-11-14 20:03 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx, stable
In-Reply-To: <20161109013809.GG6536@intel.com>
Em Ter, 2016-11-08 às 17:38 -0800, Matt Roper escreveu:
> On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> >
> > The previous spec version said "double Ytile planes minimum lines",
> > and I interpreted this as referring to what the spec calls "Y tile
> > minimum", but in fact it was referring to what the spec calls
> > "Minimum
> > Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> > interpretation, so I sent and email to the spec authors and got
> > clarification on the correct meaning. Also, BSpec was updated and
> > should be clear now.
> >
> > Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the
> > memory bandwidth WA")
> > Cc: stable@vger.kernel.org
> > Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> This seems to match my reading of the spec update from Nov 4th, so:
>
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Patch merged today. Thanks for the review!
>
>
> >
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index cc9e0c0..653525f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > y_min_scanlines = 4;
> > }
> >
> > + if (apply_memory_bw_wa)
> > + y_min_scanlines *= 2;
> > +
> > plane_bytes_per_line = width * cpp;
> > if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > plane_blocks_per_line);
> >
> > y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> > - if (apply_memory_bw_wa)
> > - y_tile_minimum *= 2;
> >
> > if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
^ permalink raw reply
* Re: [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
From: Paulo Zanoni @ 2016-11-14 20:03 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx, stable
In-Reply-To: <20161109013809.GG6536@intel.com>
Em Ter, 2016-11-08 às 17:38 -0800, Matt Roper escreveu:
> On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> >
> > The previous spec version said "double Ytile planes minimum lines",
> > and I interpreted this as referring to what the spec calls "Y tile
> > minimum", but in fact it was referring to what the spec calls
> > "Minimum
> > Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> > interpretation, so I sent and email to the spec authors and got
> > clarification on the correct meaning. Also, BSpec was updated and
> > should be clear now.
> >
> > Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the
> > memory bandwidth WA")
> > Cc: stable@vger.kernel.org
> > Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> This seems to match my reading of the spec update from Nov 4th, so:
>
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Patch merged today. Thanks for the review!
>
>
> >
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index cc9e0c0..653525f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > y_min_scanlines = 4;
> > }
> >
> > + if (apply_memory_bw_wa)
> > + y_min_scanlines *= 2;
> > +
> > plane_bytes_per_line = width * cpp;
> > if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > plane_blocks_per_line);
> >
> > y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> > - if (apply_memory_bw_wa)
> > - y_tile_minimum *= 2;
> >
> > if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/2] clk: hisilicon: add CRG driver for Hi3516CV300 SoC
From: Stephen Boyd @ 2016-11-14 20:03 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, robh+dt, mark.rutland, linux-kernel, linux-clk,
devicetree, bin.chen, elder, hermit.wangheming, yanhaifeng,
wenpan, howell.yang
In-Reply-To: <0c3b49a4-f58c-253a-fd87-ab52b0b26010@hisilicon.com>
On 11/14, Jiancheng Xue wrote:
> Hi Stephen,
>
> On 2016/11/12 8:04, Stephen Boyd wrote:
> > On 10/29, Jiancheng Xue wrote:
> >
> > Should be a From: Pan Wen here?
> >
> >> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
> >> Generator) module generates clock and reset signals used
> >> by other module blocks on SoC.
> >>
> >> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
> >
> > And you should have signed it off? Care to resend or state that
> > this is incorrectly attributed to you instead of Pan Wen?
> >
>
> Pan Wen is the main author of this patch. I just made some small modification
> with agreement from him. Do I need to resend this patch if it's better to add my
> signed-off?
>
Sure I'll apply the resent one. But you should also make sure to
retain Pan Wen's authorship. I'll go do that when applying it.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [merged] lib-stackdepot-export-save-fetch-stack-for-drivers.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: chris, aryabinin, daniel.vetter, dvyukov, glider, iamjoonsoo.kim,
kirill, mm-commits
The patch titled
Subject: lib/stackdepot: export save/fetch stack for drivers
has been removed from the -mm tree. Its filename was
lib-stackdepot-export-save-fetch-stack-for-drivers.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: lib/stackdepot: export save/fetch stack for drivers
Some drivers would like to record stacktraces in order to aide leak
tracing. As stackdepot already provides a facility for only storing the
unique traces, thereby reducing the memory required, export that
functionality for use by drivers.
The code was originally created for KASAN and moved under lib in commit
cd11016e5f521 ("mm, kasan: stackdepot implementation. Enable stackdepot
for SLAB") so that it could be shared with mm/. In turn, we want to share
it now with drivers.
Link: http://lkml.kernel.org/r/20161108133209.22704-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/stackdepot.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN lib/stackdepot.c~lib-stackdepot-export-save-fetch-stack-for-drivers lib/stackdepot.c
--- a/lib/stackdepot.c~lib-stackdepot-export-save-fetch-stack-for-drivers
+++ a/lib/stackdepot.c
@@ -192,6 +192,7 @@ void depot_fetch_stack(depot_stack_handl
trace->entries = stack->entries;
trace->skip = 0;
}
+EXPORT_SYMBOL_GPL(depot_fetch_stack);
/**
* depot_save_stack - save stack in a stack depot.
@@ -283,3 +284,4 @@ exit:
fast_exit:
return retval;
}
+EXPORT_SYMBOL_GPL(depot_save_stack);
_
Patches currently in -mm which might be from chris@chris-wilson.co.uk are
^ permalink raw reply
* [merged] mm-kmemleak-scan-dataro_after_init.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: jakub.kicinski, arnd, catalin.marinas, heiko.carstens, johannes,
schwidefsky, xiyou.wangcong, mm-commits
The patch titled
Subject: mm: kmemleak: scan .data.ro_after_init
has been removed from the -mm tree. Its filename was
mm-kmemleak-scan-dataro_after_init.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: mm: kmemleak: scan .data.ro_after_init
Limit the number of kmemleak false positives by including
.data.ro_after_init in memory scanning. To achieve this we need to add
symbols for start and end of the section to the linker scripts.
The problem was been uncovered by commit 56989f6d8568 ("genetlink: mark
families as __ro_after_init").
Link: http://lkml.kernel.org/r/1478274173-15218-1-git-send-email-jakub.kicinski@netronome.com
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/s390/kernel/vmlinux.lds.S | 2 ++
include/asm-generic/sections.h | 3 +++
include/asm-generic/vmlinux.lds.h | 5 ++++-
mm/kmemleak.c | 1 +
4 files changed, 10 insertions(+), 1 deletion(-)
diff -puN arch/s390/kernel/vmlinux.lds.S~mm-kmemleak-scan-dataro_after_init arch/s390/kernel/vmlinux.lds.S
--- a/arch/s390/kernel/vmlinux.lds.S~mm-kmemleak-scan-dataro_after_init
+++ a/arch/s390/kernel/vmlinux.lds.S
@@ -62,9 +62,11 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__start_ro_after_init = .;
+ __start_data_ro_after_init = .;
.data..ro_after_init : {
*(.data..ro_after_init)
}
+ __end_data_ro_after_init = .;
EXCEPTION_TABLE(16)
. = ALIGN(PAGE_SIZE);
__end_ro_after_init = .;
diff -puN include/asm-generic/sections.h~mm-kmemleak-scan-dataro_after_init include/asm-generic/sections.h
--- a/include/asm-generic/sections.h~mm-kmemleak-scan-dataro_after_init
+++ a/include/asm-generic/sections.h
@@ -14,6 +14,8 @@
* [_sdata, _edata]: contains .data.* sections, may also contain .rodata.*
* and/or .init.* sections.
* [__start_rodata, __end_rodata]: contains .rodata.* sections
+ * [__start_data_ro_after_init, __end_data_ro_after_init]:
+ * contains data.ro_after_init section
* [__init_begin, __init_end]: contains .init.* sections, but .init.text.*
* may be out of this range on some architectures.
* [_sinittext, _einittext]: contains .init.text.* sections
@@ -31,6 +33,7 @@ extern char _data[], _sdata[], _edata[];
extern char __bss_start[], __bss_stop[];
extern char __init_begin[], __init_end[];
extern char _sinittext[], _einittext[];
+extern char __start_data_ro_after_init[], __end_data_ro_after_init[];
extern char _end[];
extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
extern char __kprobes_text_start[], __kprobes_text_end[];
diff -puN include/asm-generic/vmlinux.lds.h~mm-kmemleak-scan-dataro_after_init include/asm-generic/vmlinux.lds.h
--- a/include/asm-generic/vmlinux.lds.h~mm-kmemleak-scan-dataro_after_init
+++ a/include/asm-generic/vmlinux.lds.h
@@ -259,7 +259,10 @@
* own by defining an empty RO_AFTER_INIT_DATA.
*/
#ifndef RO_AFTER_INIT_DATA
-#define RO_AFTER_INIT_DATA *(.data..ro_after_init)
+#define RO_AFTER_INIT_DATA \
+ __start_data_ro_after_init = .; \
+ *(.data..ro_after_init) \
+ __end_data_ro_after_init = .;
#endif
/*
diff -puN mm/kmemleak.c~mm-kmemleak-scan-dataro_after_init mm/kmemleak.c
--- a/mm/kmemleak.c~mm-kmemleak-scan-dataro_after_init
+++ a/mm/kmemleak.c
@@ -1414,6 +1414,7 @@ static void kmemleak_scan(void)
/* data/bss scanning */
scan_large_block(_sdata, _edata);
scan_large_block(__bss_start, __bss_stop);
+ scan_large_block(__start_data_ro_after_init, __end_data_ro_after_init);
#ifdef CONFIG_SMP
/* per-cpu sections scanning */
_
Patches currently in -mm which might be from jakub.kicinski@netronome.com are
^ permalink raw reply
* [merged] memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: gthelen, cl, hannes, iamjoonsoo.kim, mhocko, penberg, rientjes,
thgarnie, vdavydov.dev, mm-commits
The patch titled
Subject: memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB
has been removed from the -mm tree. Its filename was
memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Greg Thelen <gthelen@google.com>
Subject: memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB
While testing OBJFREELIST_SLAB integration with pagealloc, we found a bug
where kmem_cache(sys) would be created with both CFLGS_OFF_SLAB &
CFLGS_OBJFREELIST_SLAB. When it happened, critical allocations needed for
loading drivers or creating new caches will fail.
The original kmem_cache is created early making OFF_SLAB not possible.
When kmem_cache(sys) is created, OFF_SLAB is possible and if pagealloc is
enabled it will try to enable it first under certain conditions. Given
kmem_cache(sys) reuses the original flag, you can have both flags at the
same time resulting in allocation failures and odd behaviors.
This fix discards allocator specific flags from memcg before calling
create_cache.
The bug exists since 4.6-rc1 and affects testing debug pagealloc
configurations.
Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB")
Link: http://lkml.kernel.org/r/1478553075-120242-1-git-send-email-thgarnie@google.com
Signed-off-by: Greg Thelen <gthelen@google.com>
Signed-off-by: Thomas Garnier <thgarnie@google.com>
Tested-by: Thomas Garnier <thgarnie@google.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/slab_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN mm/slab_common.c~memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab mm/slab_common.c
--- a/mm/slab_common.c~memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab
+++ a/mm/slab_common.c
@@ -533,8 +533,8 @@ void memcg_create_kmem_cache(struct mem_
s = create_cache(cache_name, root_cache->object_size,
root_cache->size, root_cache->align,
- root_cache->flags, root_cache->ctor,
- memcg, root_cache);
+ root_cache->flags & CACHE_CREATE_MASK,
+ root_cache->ctor, memcg, root_cache);
/*
* If we could not create a memcg cache, do not complain, because
* that's not critical at all as we can always proceed with the root
_
Patches currently in -mm which might be from gthelen@google.com are
mm-slab-faster-active-and-free-stats.patch
^ permalink raw reply
* [merged] coredump-fix-unfreezable-coredumping-task.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: aryabinin, mhocko, oleg, pavel, rjw, stable, tj, viro, mm-commits
The patch titled
Subject: coredump: fix unfreezable coredumping task
has been removed from the -mm tree. Its filename was
coredump-fix-unfreezable-coredumping-task.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: coredump: fix unfreezable coredumping task
It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.
Inability to freeze a task during suspend will cause suspend to fail.
Also CRIU uses cgroup freezer during dump operation. So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.
Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.
Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/coredump.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN fs/coredump.c~coredump-fix-unfreezable-coredumping-task fs/coredump.c
--- a/fs/coredump.c~coredump-fix-unfreezable-coredumping-task
+++ a/fs/coredump.c
@@ -1,6 +1,7 @@
#include <linux/slab.h>
#include <linux/file.h>
#include <linux/fdtable.h>
+#include <linux/freezer.h>
#include <linux/mm.h>
#include <linux/stat.h>
#include <linux/fcntl.h>
@@ -423,7 +424,9 @@ static int coredump_wait(int exit_code,
if (core_waiters > 0) {
struct core_thread *ptr;
+ freezer_do_not_count();
wait_for_completion(&core_state->startup);
+ freezer_count();
/*
* Wait for all the threads to become inactive, so that
* all the thread context (extended register state, like
_
Patches currently in -mm which might be from aryabinin@virtuozzo.com are
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.