* [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Ricky Liang @ 2016-12-12 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480475340-21893-3-git-send-email-rick.chang@mediatek.com>
Hi Rick,
On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang <rick.chang@mediatek.com> wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
<snip...>
> +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx,
> + struct mtk_jpeg_dec_param *param)
> +{
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct mtk_jpeg_q_data *q_data;
> +
> + q_data = &ctx->out_q;
> + if (q_data->w != param->pic_w || q_data->h != param->pic_h) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size change\n");
> + return true;
> + }
> +
> + q_data = &ctx->cap_q;
> + if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc,
> + MTK_JPEG_FMT_TYPE_CAPTURE)) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n");
> + return true;
> + }
> + return false;
<snip...>
> +static void mtk_jpeg_device_run(void *priv)
> +{
> + struct mtk_jpeg_ctx *ctx = priv;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct vb2_buffer *src_buf, *dst_buf;
> + enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> + unsigned long flags;
> + struct mtk_jpeg_src_buf *jpeg_src_buf;
> + struct mtk_jpeg_bs bs;
> + struct mtk_jpeg_fb fb;
> + int i;
> +
> + src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> +
> + if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> + for (i = 0; i < dst_buf->num_planes; i++)
> + vb2_set_plane_payload(dst_buf, i, 0);
> + buf_state = VB2_BUF_STATE_DONE;
> + goto dec_end;
> + }
> +
> + if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
> + mtk_jpeg_queue_src_chg_event(ctx);
> + ctx->state = MTK_JPEG_SOURCE_CHANGE;
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> + return;
> + }
This only detects source change if multiple OUPUT buffers are queued.
It does not catch the source change in the following scenario:
- OUPUT buffers for jpeg1 enqueued
- OUTPUT queue STREAMON
- userspace creates CAPTURE buffers
- CAPTURE buffers enqueued
- CAPTURE queue STREAMON
- decode
- OUTPUT queue STREAMOFF
- userspace recreates OUTPUT buffers for jpeg2
- OUTPUT buffers for jpeg2 enqueued
- OUTPUT queue STREAMON
In the above sequence if jpeg2's decoded size is larger than jpeg1 the
function fails to detect that the existing CAPTURE buffers are not big
enough to hold the decoded data.
A possible fix is to pass *dst_buf to
mtk_jpeg_check_resolution_change(), and check in the function that all
the dst_buf planes are large enough to hold the decoded data.
> +
> + mtk_jpeg_set_dec_src(ctx, src_buf, &bs);
> + if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, &fb))
> + goto dec_end;
> +
> + spin_lock_irqsave(&jpeg->hw_lock, flags);
> + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> + mtk_jpeg_dec_set_config(jpeg->dec_reg_base,
> + &jpeg_src_buf->dec_param, &bs, &fb);
> +
> + mtk_jpeg_dec_start(jpeg->dec_reg_base);
> + spin_unlock_irqrestore(&jpeg->hw_lock, flags);
> + return;
> +
> +dec_end:
> + v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> +}
<snip...>
^ permalink raw reply
* [PATCH] arm64: mm: Fix NOMAP page initialization
From: Yisheng Xie @ 2016-12-12 3:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481307042-29773-1-git-send-email-rrichter@cavium.com>
hi Robert,
On 2016/12/10 2:10, Robert Richter wrote:
> On ThunderX systems with certain memory configurations we see the
> following BUG_ON():
>
> kernel BUG at mm/page_alloc.c:1848!
>
> This happens for some configs with 64k page size enabled. The BUG_ON()
> checks if start and end page of a memmap range belongs to the same
> zone.
>
> The BUG_ON() check fails if a memory zone contains NOMAP regions. In
> this case the node information of those pages is not initialized. This
> causes an inconsistency of the page links with wrong zone and node
> information for that pages. NOMAP pages from node 1 still point to the
> mem zone from node 0 and have the wrong nid assigned.
>
The patch can work for zone contains NOMAP regions.
However, if BIOS do not add WB/WT/WC attribute to a physical address range, the
is_memory(md) will return false and this range will not be added to memblock.
efi_init
-> reserve_regions
if (is_memory(md)) {
early_init_dt_add_memory_arch(paddr, size);
if (!is_usable_memory(md))
memblock_mark_nomap(paddr, size);
}
Then BUG_ON() check will also fails. Any idea about it?
Here is the crash log I got from D05:
crash log---------------
[ 0.000000] Booting Linux on physical CPU 0x10000
[ 0.000000] Linux version 4.9.0-rc8+ (xys at linux-ibm) (gcc version 6.1.1 20160711 (Linaro GCC 6.1-2016.08) ) #61 SMP Fri Dec 9 19:46:24 CST 2016
[ 0.000000] Boot CPU: AArch64 Processor [410fd082]
[ 0.000000] earlycon: pl11 at MMIO32 0x00000000602b0000 (options '')
[ 0.000000] bootconsole [pl11] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: System Table: 0x000000003f150018
[ 0.000000] efi: MemMap Address: 0x0000000031b33018
[ 0.000000] efi: MemMap Size: 0x000009f0
[ 0.000000] efi: MemMap Desc. Size: 0x00000030
[ 0.000000] efi: MemMap Desc. Version: 0x00000001
[ 0.000000] efi: EFI v2.60 by EDK II
[ 0.000000] efi: SMBIOS=0x3f130000 SMBIOS 3.0=0x39ca0000 ACPI=0x39d70000 ACPI 2.0=0x39d70014 MEMATTR=0x3ce14018
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x0 reserved size = 0x1000
[ 0.000000] memory.cnt = 0x1
[ 0.000000] memory[0x0] [0x00000000000000-0xffffffffffffffff], 0x0 bytes on node 0 flags: 0x0
[ 0.000000] reserved.cnt = 0x1
[ 0.000000] reserved[0x0] [0x0000001e400000-0x0000001e400fff], 0x1000 bytes flags: 0x0
[ 0.000000] efi: 0x000000000000-0x00000007ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000000000000-0x0000000007ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000000080000-0x0000016cffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000000080000-0x000000016cffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x0000016d0000-0x00001e3fffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x000000016d0000-0x0000001e3fffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00001e400000-0x00001e40ffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000001e400000-0x0000001e40ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00001e410000-0x00001e47ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000001e410000-0x0000001e47ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00001e480000-0x00001fffffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000001e480000-0x0000001fffffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000020000000-0x00002fbfffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000020000000-0x0000002fbfffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00002fc00000-0x00002fc1ffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000002fc00000-0x0000002fc1ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00002fc20000-0x00003049cfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000002fc20000-0x0000003049ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003049d000-0x000031b0ffff [Loader Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000030490000-0x00000031b0ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b10000-0x000031b2ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b10000-0x00000031b2ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b30000-0x000031b32fff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b30000-0x00000031b3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b33000-0x000031b33fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b30000-0x00000031b3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b34000-0x000031b37fff [Reserved | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b30000-0x00000031b3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b38000-0x000031baefff [Boot Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b30000-0x00000031baffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031baf000-0x000039baffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031ba0000-0x00000039baffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039bb0000-0x000039beffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039bb0000-0x00000039beffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039bf0000-0x000039c3ffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039bf0000-0x00000039c3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039c40000-0x000039c4ffff [ACPI Memory NVS | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039c40000-0x00000039c4ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039c50000-0x000039c8ffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039c50000-0x00000039c8ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039c90000-0x000039d0ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039c90000-0x00000039d0ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039d10000-0x000039d5ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039d10000-0x00000039d5ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039d60000-0x000039d7ffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039d60000-0x00000039d7ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039d80000-0x000039dcffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039d80000-0x00000039dcffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039dd0000-0x000039e1ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039dd0000-0x00000039e1ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039e20000-0x000039e6ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039e20000-0x00000039e6ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039e70000-0x000039f3ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039e70000-0x00000039f3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039f40000-0x000039faffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039f40000-0x00000039faffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039fb0000-0x000039ffffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039fb0000-0x00000039ffffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a000000-0x00003a04ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a000000-0x0000003a04ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a050000-0x00003a09ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a050000-0x0000003a09ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a0a0000-0x00003a0effff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a0a0000-0x0000003a0effff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a0f0000-0x00003a13ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a0f0000-0x0000003a13ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a140000-0x00003a140fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a140000-0x0000003a14ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a141000-0x00003a14bfff [Boot Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a140000-0x0000003a14ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a14c000-0x00003c31dfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a140000-0x0000003c31ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003c31e000-0x00003cdcdfff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003c310000-0x0000003cdcffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003cdce000-0x00003cdfdfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003cdc0000-0x0000003cdfffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003cdfe000-0x00003ef7ffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003cdf0000-0x0000003ef7ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003ef80000-0x00003ef81fff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003ef80000-0x0000003ef8ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003ef82000-0x00003f10ffff [Boot Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003ef80000-0x0000003f10ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003f110000-0x00003f12ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003f110000-0x0000003f12ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003f130000-0x00003f15ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003f130000-0x0000003f15ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003f160000-0x00003f16ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003f160000-0x0000003f16ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003f170000-0x00003fbfffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003f170000-0x0000003fbfffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003fc00000-0x00003fffffff [Reserved | | | | | | | | | | | | ]
[ 0.000000] efi: 0x000078000000-0x00007800ffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000a4000000-0x0000a4ffffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000a6000000-0x0000a600ffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000d00e0000-0x0000d00effff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x001040000000-0x0013fbffffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00001040000000-0x000013fbffffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x041000000000-0x0413fbfeffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00041000000000-0x000413fbfeffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x0413fbff0000-0x0413fbffffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x000413fbff0000-0x000413fbffffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] memblock_reserve: [0x0000003ce14018-0x0000003ce14657] flags 0x0 efi_memattr_init+0x8c/0xa8
[ 0.000000] memblock_reserve: [0x00000031b30000-0x00000031b3ffff] flags 0x0 efi_init+0xa8/0x148
[ 0.000000] memblock_add: [0x0000001e480000-0x0000001fffffff] flags 0x0 arm64_memblock_init+0x16c/0x248
[ 0.000000] memblock_reserve: [0x0000001e480000-0x0000001fffffff] flags 0x0 arm64_memblock_init+0x178/0x248
[ 0.000000] memblock_reserve: [0x00000000080000-0x000000016cffff] flags 0x0 arm64_memblock_init+0x1b0/0x248
[ 0.000000] memblock_reserve: [0x0000001e480000-0x0000001fffdc62] flags 0x0 arm64_memblock_init+0x1cc/0x248
[ 0.000000] cma: Failed to reserve 512 MiB
[ 0.000000] memblock_reserve: [0x000013fbff0000-0x000013fbffffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_reserve: [0x000013fbfe0000-0x000013fbfeffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_reserve: [0x000013fbfd0000-0x000013fbfdffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_reserve: [0x000013fbfc0000-0x000013fbfcffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_reserve: [0x000013fbfb0000-0x000013fbfbffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_free: [0x000013fbff0000-0x000013fbffffff] paging_init+0x65c/0x6ac
[ 0.000000] memblock_free: [0x000000016c0000-0x000000016cffff] paging_init+0x690/0x6ac
[...]
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x00000013fbffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 1: [mem 0x0000000000000000-0x000000000001ffff]
[ 0.000000] node 1: [mem 0x0000000000030000-0x0000000031b0ffff]
[ 0.000000] node 1: [mem 0x0000000031b10000-0x0000000031b3ffff]
[ 0.000000] node 1: [mem 0x0000000031b40000-0x0000000039baffff]
[ 0.000000] node 1: [mem 0x0000000039bb0000-0x000000003a13ffff]
[ 0.000000] node 1: [mem 0x000000003a140000-0x000000003f12ffff]
[ 0.000000] node 1: [mem 0x000000003f130000-0x000000003f15ffff]
[ 0.000000] node 1: [mem 0x000000003f160000-0x000000003fbfffff]
[ 0.000000] node 1: [mem 0x0000001040000000-0x00000013fbffffff]
[ 0.000000] Could not find start_pfn for node 0
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] Initmem setup node 1 [mem 0x0000000000000000-0x00000013fbffffff]
[ 0.000000] Could not find start_pfn for node 2
[ 0.000000] Initmem setup node 2 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] Could not find start_pfn for node 3
[ 0.000000] Initmem setup node 3 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x3fbc00000 reserved size = 0x42a7cc0
[ 0.000000] memory.cnt = 0x9
[ 0.000000] memory[0x0] [0x00000000000000-0x000000000257ff], 0x25800 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x1] [0x00000000025800-0x00000031b0ffff], 0x31aea800 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x2] [0x00000031b10000-0x00000031b3ffff], 0x30000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x3] [0x00000031b40000-0x00000039baffff], 0x8070000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x4] [0x00000039bb0000-0x0000003a13ffff], 0x590000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x5] [0x0000003a140000-0x0000003f12ffff], 0x4ff0000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x6] [0x0000003f130000-0x0000003f15ffff], 0x30000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x7] [0x0000003f160000-0x0000003fbfffff], 0xaa0000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x8] [0x00001040000000-0x000013fbffffff], 0x3bc000000 bytes on node 1 flags: 0x0
[ 0.000000] reserved.cnt = 0x8
[ 0.000000] reserved[0x0] [0x00000000080000-0x000000016bffff], 0x1640000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x0000001e400000-0x0000001e400fff], 0x1000 bytes flags: 0x0
[ 0.000000] reserved[0x2] [0x0000001e480000-0x0000001fffffff], 0x1b80000 bytes flags: 0x0
[ 0.000000] reserved[0x3] [0x00000031b30000-0x00000031b3ffff], 0x10000 bytes flags: 0x0
[ 0.000000] reserved[0x4] [0x0000003ce14018-0x0000003ce14657], 0x640 bytes flags: 0x0
[ 0.000000] reserved[0x5] [0x000013fad20000-0x000013fbd2ffff], 0x1010000 bytes flags: 0x0
[ 0.000000] reserved[0x6] [0x000013fbf37380-0x000013fbfeffff], 0xb8c80 bytes flags: 0x0
[ 0.000000] reserved[0x7] [0x000013fbff2600-0x000013fbffffff], 0xda00 bytes flags: 0x0
[ 0.000000] memblock_reserve: [0x0000003fbfff80-0x0000003fbfffbf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbfff00-0x0000003fbfff3f] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffe80-0x0000003fbffebf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffe00-0x0000003fbffe3f] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffd80-0x0000003fbffdbf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffd00-0x0000003fbffd3f] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffc80-0x0000003fbffcbf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffc00-0x0000003fbffc3f] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffb80-0x0000003fbffbbf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[...]
[ 5.081443] move_freepages: start_page info: zonenum = 0, nid = 1, pfn = 8192, valid = 1, phys = 0x20000000
[ 5.081443] move_freepages: end_page info: zonenum = 0, nid = 0, pfn = 16383, valid = 0, phys = 0x3fff0000
[ 5.091280] ------------[ cut here ]------------
[ 5.095971] kernel BUG at mm/page_alloc.c:1871! ----> is mm/page_alloc.c:1863! without add debug log.
[ 5.100576] Internal error: Oops - BUG: 0 [#1] SMP
[ 5.105446] Modules linked in:
[ 5.108552] CPU: 61 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc8+ #61
[ 5.115101] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 UEFI 16.08 RC1 12/08/2016
[ 5.124126] task: fffffe13f23d1700 task.stack: fffffe13f66a0000
[ 5.130157] PC is at move_freepages+0x280/0x288
[ 5.134764] LR is at move_freepages+0x23c/0x288
[ 5.139365] pc : [<fffffc00081e9698>] lr : [<fffffc00081e9654>] pstate: 200000c5
[ 5.146889] sp : fffffe13f66a38d0
[ 5.150253] x29: fffffe13f66a38f0 x28: fffffdff80000000
[ 5.155652] x27: 0000000000003fff x26: 0000000000002000
[ 5.161051] x25: 0000000000000000 x24: 0000000000000000
[ 5.166453] x23: 0000000000000001 x22: fffffc0008e12328
[ 5.171851] x21: fffffdff800fffc0 x20: fffffe13fbf62680
[ 5.177251] x19: fffffdff80080000 x18: 0000000000000010
[ 5.182652] x17: 0000000000000000 x16: 0000000000000000
[ 5.188053] x15: 0000000000000006 x14: 702c29302c312864
[ 5.193455] x13: 696c61762c293338 x12: 3336312c32393138
[ 5.198854] x11: 286e66702c29302c x10: 0000000000000559
[ 5.204258] x9 : 000000000000006e x8 : 302c303030303030
[ 5.209663] x7 : 3032783028737968 x6 : fffffe13fbff2680
[ 5.215068] x5 : 0000000000000001 x4 : fffffe13fbf62680
[ 5.220468] x3 : 0000000000000000 x2 : 0000000000000000
[ 5.225870] x1 : fffffe13fbff2680 x0 : fffffe13fbf62680
[...]
[ 5.793294] [<fffffc00081e9698>] move_freepages+0x280/0x288
[ 5.798964] [<fffffc00081e9748>] move_freepages_block+0xa8/0xb8
[ 5.804994] [<fffffc00081e9cc4>] __rmqueue+0x494/0x5f0
[ 5.810225] [<fffffc00081eb214>] get_page_from_freelist+0x5ec/0xb58
[ 5.816603] [<fffffc00081ebd54>] __alloc_pages_nodemask+0x144/0xd08
[ 5.822979] [<fffffc000824061c>] alloc_page_interleave+0x64/0xc0
[ 5.829092] [<fffffc0008240c28>] alloc_pages_current+0x108/0x168
[ 5.835207] [<fffffc0008c75410>] atomic_pool_init+0x78/0x1cc
[ 5.840970] [<fffffc0008c755a0>] arm64_dma_init+0x3c/0x44
[ 5.846471] [<fffffc0008082d94>] do_one_initcall+0x44/0x138
[ 5.852143] [<fffffc0008c70d54>] kernel_init_freeable+0x1ec/0x28c
[ 5.858351] [<fffffc00088a7af0>] kernel_init+0x18/0x110
[ 5.863665] [<fffffc0008082b30>] ret_from_fork+0x10/0x20
[ 5.869078] Code: 8b001c80 8b011cc1 eb00003f 54fff080 (d4210000)
[ 5.875318] ---[ end trace b723f6d3d3b4c326 ]---
[ 5.880038] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 5.880038]
[ 5.889340] SMP: stopping secondary CPUs
[ 5.893339] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
^ permalink raw reply
* [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Jacky Bai @ 2016-12-12 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209181201.ewcqeqslyf3je7kq@rob-hp-laptop>
> Subject: Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
>
> On Fri, Dec 02, 2016 at 02:39:33PM +0800, Bai Ping wrote:
> > Add necessary document update for i.MX6SLL support.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> > .../devicetree/bindings/clock/imx6sll-clock.txt | 13 ++++++++
> > .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt | 37 ++++++++++++++++++++++
> > 2 files changed, 50 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > new file mode 100644
> > index 0000000..4f52efa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > @@ -0,0 +1,13 @@
> > +* Clock bindings for Freescale i.MX6 UltraLite
>
> I thought UltraLite was MX6UL?
>
Sorry, it is a typo, will fix in V2.
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx6sll-ccm"
> > +- reg: Address and length of the register set
> > +- #clock-cells: Should be <1>
> > +- clocks: list of clock specifiers, must contain an entry for each
> > +required
> > + entry in clock-names
> > +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell. See
> > +include/dt-bindings/clock/imx6sll-clock.h
> > +for the full list of i.MX6 SLL clock IDs.
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> > b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> > new file mode 100644
> > index 0000000..096e471
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.tx
> > +++ t
> > @@ -0,0 +1,37 @@
> > +* Freescale i.MX6 UltraLite IOMUX Controller
>
> ditto
>
Will fix in V2. Thanks for review.
> > +
> > +Please refer to fsl,imx-pinctrl.txt in this directory for common
> > +binding part and usage.
> > +
> > +Required properties:
> > +- compatible: "fsl,imx6sll-iomuxc"
> > +- fsl,pins: each entry consists of 6 integers and represents the mux
> > +and config
> > + setting for one pin. The first 5 integers <mux_reg conf_reg
> > +input_reg mux_val
> > + input_val> are specified using a PIN_FUNC_ID macro, which can be
> > +found in
> > + imx6ul-pinfunc.h under device tree source folder. The last integer
> > +CONFIG is
> > + the pad setting value like pull-up on this pin. Please refer to
> > +i.MX6SLL
> > + Reference Manual for detailed CONFIG settings.
> > +
> > +CONFIG bits definition:
> > +PAD_CTL_LVE (1 << 22)
> > +PAD_CTL_HYS (1 << 16)
> > +PAD_CTL_PUS_100K_DOWN (0 << 14)
> > +PAD_CTL_PUS_47K_UP (1 << 14)
> > +PAD_CTL_PUS_100K_UP (2 << 14)
> > +PAD_CTL_PUS_22K_UP (3 << 14)
> > +PAD_CTL_PUE (1 << 13)
> > +PAD_CTL_PKE (1 << 12)
> > +PAD_CTL_ODE (1 << 11)
> > +PAD_CTL_SPEED_LOW (0 << 6)
> > +PAD_CTL_SPEED_MED (1 << 6)
> > +PAD_CTL_SPEED_HIGH (3 << 6)
> > +PAD_CTL_DSE_DISABLE (0 << 3)
> > +PAD_CTL_DSE_260ohm (1 << 3)
> > +PAD_CTL_DSE_130ohm (2 << 3)
> > +PAD_CTL_DSE_87ohm (3 << 3)
> > +PAD_CTL_DSE_65ohm (4 << 3)
> > +PAD_CTL_DSE_52ohm (5 << 3)
> > +PAD_CTL_DSE_43ohm (6 << 3)
> > +PAD_CTL_DSE_37ohm (7 << 3)
> > +PAD_CTL_SRE_FAST (1 << 0)
> > +PAD_CTL_SRE_SLOW (0 << 0)
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
From: Jacky Bai @ 2016-12-12 2:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208225257.GP5423@codeaurora.org>
> Subject: Re: [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
>
> On 12/02, Bai Ping wrote:
> > diff --git a/drivers/clk/imx/clk-imx6sll.c
> > b/drivers/clk/imx/clk-imx6sll.c new file mode 100644 index
> > 0000000..c5219e1
> > --- /dev/null
> > +++ b/drivers/clk/imx/clk-imx6sll.c
> > @@ -0,0 +1,366 @@
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> > +
> > +#include <dt-bindings/clock/imx6sll-clock.h>
> > +#include <linux/clk.h>
> > +#include <linux/clkdev.h>
>
> Is this include used?
>
It seems no use, I will remove it in V2.
> > +#include <linux/err.h>
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/types.h>
>
> Is there an include of clk_provider.h missing?
>
clk_provider.h is included in below "clk.h".
> > +
> > +#include "clk.h"
> > +
> > +#define BM_CCM_CCDR_MMDC_CH0_MASK (0x2 << 16)
> > +#define CCDR 0x4
> > +
> > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
>
> const char * const? For all of these names.
>
ok, I will fix in V2.
> > +static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src",
> > +}; static const char *pll2_bypass_sels[] = { "pll2",
> > +"pll2_bypass_src", }; static const char *pll3_bypass_sels[] = {
> > +"pll3", "pll3_bypass_src", }; static const char *pll4_bypass_sels[] =
> > +{ "pll4", "pll4_bypass_src", }; static const char *pll5_bypass_sels[]
> > += { "pll5", "pll5_bypass_src", }; static const char
> > +*pll6_bypass_sels[] = { "pll6", "pll6_bypass_src", }; static const
> > +char *pll7_bypass_sels[] = { "pll7", "pll7_bypass_src", }; static
> > +const char *step_sels[] = { "osc", "pll2_pfd2_396m", }; static const
> > +char *pll1_sw_sels[] = { "pll1_sys", "step", }; static const char
> > +*axi_alt_sels[] = { "pll2_pfd2_396m", "pll3_pfd1_540m", }; static
> > +const char *axi_sels[] = {"periph", "axi_alt_sel", }; static const
> > +char *periph_pre_sels[] = { "pll2_bus", "pll2_pfd2_396m",
> > +"pll2_pfd0_352m", "pll2_198m", }; static const char
> > +*periph2_pre_sels[] = { "pll2_bus", "pll2_pfd2_396m",
> > +"pll2_pfd0_352m", "pll4_audio_div", }; static const char
> > +*periph_clk2_sels[] = { "pll3_usb_otg", "osc", "osc", }; static const
> > +char *periph2_clk2_sels[] = { "pll3_usb_otg", "osc", }; static const
> > +char *periph_sels[] = { "periph_pre", "periph_clk2", }; static const
> > +char *periph2_sels[] = { "periph2_pre", "periph2_clk2", }; static
> > +const char *usdhc_sels[] = { "pll2_pfd2_396m", "pll2_pfd0_352m", };
> > +static const char *ssi_sels[] = {"pll3_pfd2_508m", "pll3_pfd3_454m",
> > +"pll4_audio_div", "dummy",}; static const char *spdif_sels[] = {
> > +"pll4_audio_div", "pll3_pfd2_508m", "pll5_video_div", "pll3_usb_otg",
> > +}; static const char *ldb_di0_div_sels[] = { "ldb_di0_div_3_5",
> > +"ldb_di0_div_7", }; static const char *ldb_di1_div_sels[] = {
> > +"ldb_di1_div_3_5", "ldb_di1_div_7", }; static const char
> > +*ldb_di0_sels[] = { "pll5_video_div", "pll2_pfd0_352m",
> > +"pll2_pfd2_396m", "pll2_pfd3_594m", "pll2_pfd1_594m",
> > +"pll3_pfd3_454m", }; static const char *ldb_di1_sels[] = {
> > +"pll3_usb_otg", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll2_bus",
> > +"pll3_pfd3_454m", "pll3_pfd2_508m", }; static const char
> > +*lcdif_pre_sels[] = { "pll2_bus", "pll3_pfd3_454m", "pll5_video_div",
> > +"pll2_pfd0_352m", "pll2_pfd1_594m", "pll3_pfd1_540m", }; static const
> > +char *ecspi_sels[] = { "pll3_60m", "osc", }; static const char
> > +*uart_sels[] = { "pll3_80m", "osc", }; static const char
> > +*perclk_sels[] = { "ipg", "osc", }; static const char *lcdif_sels[] =
> > +{ "lcdif_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> > +
> > +static const char *epdc_pre_sels[] = { "pll2_bus", "pll3_usb_otg",
> > +"pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m",
> > +"pll3_pfd2_508m", }; static const char *epdc_sels[] = { "epdc_podf",
> > +"ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> > +
> > +static struct clk *clks[IMX6SLL_CLK_END]; static struct
> > +clk_onecell_data clk_data;
> > +
> > +static int const clks_init_on[] __initconst = {
>
> static const int is more preferred style.
>
ok, will fix in V2.
> > + IMX6SLL_CLK_AIPSTZ1, IMX6SLL_CLK_AIPSTZ2,
> > + IMX6SLL_CLK_OCRAM, IMX6SLL_CLK_ARM, IMX6SLL_CLK_ROM,
> > + IMX6SLL_CLK_MMDC_P0_FAST, IMX6SLL_CLK_MMDC_P0_IPG, };
> > +
> > +static struct clk_div_table post_div_table[] = {
>
> const?
>
ok, will fix in V2.
> > + { .val = 2, .div = 1, },
> > + { .val = 1, .div = 2, },
> > + { .val = 0, .div = 4, },
> > + { }
> > +};
> > +
> > +static struct clk_div_table video_div_table[] = {
>
> const?
>
ok. will fix in V2.
> > + { .val = 0, .div = 1, },
> > + { .val = 1, .div = 2, },
> > + { .val = 2, .div = 1, },
> > + { .val = 3, .div = 4, },
> > + { }
> > +};
> > +
> > +static u32 share_count_audio;
> > +static u32 share_count_ssi1;
> > +static u32 share_count_ssi2;
> > +static u32 share_count_ssi3;
> > +
> > +static void __init imx6sll_clocks_init(struct device_node *ccm_node)
> > +{
> > + struct device_node *np;
> > + void __iomem *base;
> > + int i;
> > +
> > + clks[IMX6SLL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
> > +
> > + clks[IMX6SLL_CLK_CKIL] = of_clk_get_by_name(ccm_node, "ckil");
> > + clks[IMX6SLL_CLK_OSC] = of_clk_get_by_name(ccm_node, "osc");
> > +
> > + /* ipp_di clock is external input */
> > + clks[IMX6SLL_CLK_IPP_DI0] = of_clk_get_by_name(ccm_node,
> "ipp_di0");
> > + clks[IMX6SLL_CLK_IPP_DI1] = of_clk_get_by_name(ccm_node,
> "ipp_di1");
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,imx6sll-anatop");
> > + base = of_iomap(np, 0);
> > + WARN_ON(!base);
> > +
> > + clks[IMX6SLL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src",
> base + 0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL2_BYPASS_SRC] = imx_clk_mux("pll2_bypass_src",
> base + 0x30, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL3_BYPASS_SRC] = imx_clk_mux("pll3_bypass_src",
> base + 0x10, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL4_BYPASS_SRC] = imx_clk_mux("pll4_bypass_src",
> base + 0x70, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL5_BYPASS_SRC] = imx_clk_mux("pll5_bypass_src",
> base + 0xa0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL6_BYPASS_SRC] = imx_clk_mux("pll6_bypass_src",
> base + 0xe0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL7_BYPASS_SRC] = imx_clk_mux("pll7_bypass_src",
> base
> > ++ 0x20, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +
> > + clks[IMX6SLL_CLK_PLL1] = imx_clk_pllv3(IMX_PLLV3_SYS, "pll1",
> "pll1_bypass_src", base + 0x00, 0x7f);
> > + clks[IMX6SLL_CLK_PLL2] = imx_clk_pllv3(IMX_PLLV3_GENERIC, "pll2",
> "pll2_bypass_src", base + 0x30, 0x1);
> > + clks[IMX6SLL_CLK_PLL3] = imx_clk_pllv3(IMX_PLLV3_USB, "pll3",
> "pll3_bypass_src", base + 0x10, 0x3);
> > + clks[IMX6SLL_CLK_PLL4] = imx_clk_pllv3(IMX_PLLV3_AV, "pll4",
> "pll4_bypass_src", base + 0x70, 0x7f);
> > + clks[IMX6SLL_CLK_PLL5] = imx_clk_pllv3(IMX_PLLV3_AV, "pll5",
> "pll5_bypass_src", base + 0xa0, 0x7f);
> > + clks[IMX6SLL_CLK_PLL6] = imx_clk_pllv3(IMX_PLLV3_ENET, "pll6",
> "pll6_bypass_src", base + 0xe0, 0x3);
> > + clks[IMX6SLL_CLK_PLL7] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7",
> "pll7_bypass_src", base + 0x20, 0x3);
> > +
> > + clks[IMX6SLL_PLL1_BYPASS] = imx_clk_mux_flags("pll1_bypass", base
> + 0x00, 16, 1, pll1_bypass_sels, ARRAY_SIZE(pll1_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL2_BYPASS] = imx_clk_mux_flags("pll2_bypass", base
> + 0x30, 16, 1, pll2_bypass_sels, ARRAY_SIZE(pll2_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL3_BYPASS] = imx_clk_mux_flags("pll3_bypass", base
> + 0x10, 16, 1, pll3_bypass_sels, ARRAY_SIZE(pll3_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL4_BYPASS] = imx_clk_mux_flags("pll4_bypass", base
> + 0x70, 16, 1, pll4_bypass_sels, ARRAY_SIZE(pll4_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL5_BYPASS] = imx_clk_mux_flags("pll5_bypass", base
> + 0xa0, 16, 1, pll5_bypass_sels, ARRAY_SIZE(pll5_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL6_BYPASS] = imx_clk_mux_flags("pll6_bypass", base
> + 0xe0, 16, 1, pll6_bypass_sels, ARRAY_SIZE(pll6_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL7_BYPASS] = imx_clk_mux_flags("pll7_bypass", base
> +
> > +0x20, 16, 1, pll7_bypass_sels, ARRAY_SIZE(pll7_bypass_sels),
> > +CLK_SET_RATE_PARENT);
> > +
> > + /* Do not bypass PLLs initially */
> > + clk_set_parent(clks[IMX6SLL_PLL1_BYPASS], clks[IMX6SLL_CLK_PLL1]);
> > + clk_set_parent(clks[IMX6SLL_PLL2_BYPASS], clks[IMX6SLL_CLK_PLL2]);
> > + clk_set_parent(clks[IMX6SLL_PLL3_BYPASS], clks[IMX6SLL_CLK_PLL3]);
> > + clk_set_parent(clks[IMX6SLL_PLL4_BYPASS], clks[IMX6SLL_CLK_PLL4]);
> > + clk_set_parent(clks[IMX6SLL_PLL5_BYPASS], clks[IMX6SLL_CLK_PLL5]);
> > + clk_set_parent(clks[IMX6SLL_PLL6_BYPASS], clks[IMX6SLL_CLK_PLL6]);
> > + clk_set_parent(clks[IMX6SLL_PLL7_BYPASS], clks[IMX6SLL_CLK_PLL7]);
>
> Can we just put raw register writes here instead? I'd prefer we didn't use clk
> consumer APIs to do things to the clk tree from the providers. The problem
> there being that:
>
> 1) We're trying to move away from using consumer APIs in provider drivers.
> It's ok if they're used during probe, but inside clk_ops is not preferred.
>
> 2) Even if you have a clk pointer, it may be "orphaned" at the time of
> registration and so calling the APIs here works now but eventually we may
> want to return an EPROBE_DEFER error in that case and this may block that
> effort.
>
> I suppose if this is the only clk driver on this machine then this last point isn't a
> concern and things are probably ok here.
>
Using raw register writing has an issue. The register is modified, but it seems the clock 'parent-child' relationship can
not match the register setting. The register setting is not bypass the pll, but in debug 'clk_summary', the
pll is bypassed.
BR
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Jacky Bai @ 2016-12-12 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208225424.GQ5423@codeaurora.org>
> Subject: Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
>
> On 12/02, Bai Ping wrote:
> > Add necessary document update for i.MX6SLL support.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> > .../devicetree/bindings/clock/imx6sll-clock.txt | 13 ++++++++
> > .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt | 37 ++++++++++++++++++++++
>
> Please split the bindings into different patches and put them closer to the
> drivers that use them in the series.
Ok, I will fix it in V2.
>
> > 2 files changed, 50 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > new file mode 100644
> > index 0000000..4f52efa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > @@ -0,0 +1,13 @@
> > +* Clock bindings for Freescale i.MX6 UltraLite
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx6sll-ccm"
> > +- reg: Address and length of the register set
> > +- #clock-cells: Should be <1>
> > +- clocks: list of clock specifiers, must contain an entry for each
> > +required
> > + entry in clock-names
> > +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell. See
> > +include/dt-bindings/clock/imx6sll-clock.h
> > +for the full list of i.MX6 SLL clock IDs.
>
> Can you add an example node here?
>
Thanks for review, I will add it in V2.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* sunxi-ng clocks: leaving certain clocks alone?
From: André Przywara @ 2016-12-11 23:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I was observing that the new sunxi-ng clock code apparently explicitly
turns off _all_ clocks that are not used or needed. I find this rather
unfortunate, as I wanted to use the THS temperature sensor from ARM
Trusted Firmware to implement emergency shutdown or DVFS throttling.
That works until the clock framework finds the clock (as enumerated in
ccu-sun50i-a64.c) and obviously explicitly clears bit 31 in the THS mod
clock register and bit 8 in the respective clock gate register.
Turning them manually back on via /dev/mem or removing the THS clock
from the sunxi-ng driver fixes this for me.
This was not happening with the old Allwinner clocks, since the kernel
wouldn't even know about it if there was no driver and the clock wasn't
mentioned in the DT.
Now with sunxi-ng even though the THS clock is not actually referenced
or used in the DT, the kernel turns it off. I would expect that upon
entering the kernel all unneeded clocks are turned off anyway, so there
is no need to mess with clocks that have no user, but are enumerated in
the ccu driver.
I wonder if this kills simplefb as well, for instance, since I believe
that U-Boot needs to turn on certain clocks and relies on them staying up.
So my questions:
1) Is this expected behaviour?
2) If yes, should it really be?
3) If yes, shouldn't there be way to explicitly tell Linux to leave that
clock alone, preferably via DT? Although the sunxi-ng clocks take
control over the whole CCU unit, I wonder if it should really mess with
clocks there are not referenced in the DT.
Maybe there is some way to reference those clocks via some dummy driver
or DT node to avoid this behaviour? Is there any prior art in this respect?
I think this issue will affect more future users (thinking of EFI RTC,
EFI graphics, etc.), so I wanted to start a discussion on this.
Any input welcome.
Cheers,
Andre.
P.S. For reference my use case: ARM Trusted Firmware (ATF) enables the
temperature sensor (THS) and programs a shutdown value. It programs the
respective interrupt as secure and registers an IRQ handler in ATF to
shutdown the system or take other appropriate matters to avoid
overheating. Additionally the sensor is exported via the generic SCPI
interface, so the existing scpi-hwmon driver picks it up and reports it
to whoever is interested in Linux land via the normal interfaces.
^ permalink raw reply
* [PATCH 2/2] FPGA: Add TS-7300 FPGA manager
From: Moritz Fischer @ 2016-12-11 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211221750.27743-3-f.fainelli@gmail.com>
Hi Florian,
can you Cc: linxu-fpga at vger.kernel.org for your next round?
On Sun, Dec 11, 2016 at 2:17 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Add support for loading bitstreams on the Altera Cyclone II FPGA
> populated on the TS-7300 board. This is done through the configuration
> and data registers offered through a memory interface between the EP93xx
> SoC and the FPGA.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/ts73xx-fpga.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 173 insertions(+)
> create mode 100644 drivers/fpga/ts73xx-fpga.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index cd84934774cc..109625707ef0 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ZYNQ_FPGA
> help
> FPGA manager driver support for Xilinx Zynq FPGAs.
>
> +config FPGA_MGR_TS73XX
> + tristate "Technologic Systems TS-73xx SBC FPGA Manager"
> + depends on ARCH_EP93XX && MACH_TS72XX
> + help
> + FPGA manager driver support for the Altera Cyclone II FPGA
> + present on the TS-73xx SBC boards.
> +
> endif # FPGA
>
> endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6b1613..5d51265cc1b4 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
> # FPGA Manager Drivers
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> +obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
> diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c
> new file mode 100644
> index 000000000000..2b3d5d668dfc
> --- /dev/null
> +++ b/drivers/fpga/ts73xx-fpga.c
> @@ -0,0 +1,165 @@
> +/*
> + * Technologic Systems TS-73xx SBC FPGA loader
> + *
> + * Copyright (C) 2016 Florian Fainelli <f.fainelli@gmail.com>
> + *
> + * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on
> + * TS-7300, heavily based on load_fpga.c in their vendor tree.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/string.h>
> +#include <linux/bitrev.h>
> +#include <linux/fpga/fpga-mgr.h>
> +
> +#define TS73XX_FPGA_DATA_REG 0
> +#define TS73XX_FPGA_CONFIG_REG 1
> +
> +struct ts73xx_fpga_priv {
> + void __iomem *io_base;
> + struct device *dev;
> +};
> +
> +static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr)
> +{
> + return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int ts73xx_fpga_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> +
> + /* Reset the FPGA */
> + writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + udelay(30);
> + writeb(0x2, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + udelay(80);
> +
> + return 0;
> +}
> +
> +static inline int ts73xx_fpga_can_write(struct ts73xx_fpga_priv *priv)
> +{
> + unsigned int timeout = 1000;
> + u8 reg;
> +
> + while (timeout--) {
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + if (!(reg & 0x1))
> + return 0;
> + cpu_relax();
> + }
You can use readb_poll_timeout() for this I think.
> +
> + return -ETIMEDOUT;
> +}
> +
> +static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> + size_t i = 0;
> + int ret;
> + u8 reg;
> +
> + while (count--) {
> + ret = ts73xx_fpga_can_write(priv);
> + if (ret < 0)
> + return ret;
> +
> + writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG);
> + i++;
> + }
> +
> + usleep_range(1000, 2000);
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + reg |= 0x8;
What's happening here?
> + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + usleep_range(1000, 2000);
> +
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + reg &= ~0x8;
and here? Can we have a named constant for these, or a comment to
explain what happens?
> + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> +
> + return 0;
> +}
> +
> +static int ts73xx_fpga_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> + u8 reg;
> +
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + if ((reg & 0x4) != 0x4)
Named constants, please
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> +static const struct fpga_manager_ops ts73xx_fpga_ops = {
> + .state = ts73xx_fpga_state,
> + .write_init = ts73xx_fpga_write_init,
> + .write = ts73xx_fpga_write,
> + .write_complete = ts73xx_fpga_write_complete,
> +};
> +
> +static int ts73xx_fpga_probe(struct platform_device *pdev)
> +{
> + struct device *kdev = &pdev->dev;
> + struct ts73xx_fpga_priv *priv;
> + struct fpga_manager *mgr;
> + struct resource *res;
> + int err;
> +
> + priv = devm_kzalloc(kdev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = kdev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->io_base = devm_ioremap_resource(kdev, res);
> + if (IS_ERR(priv->io_base))
> + return PTR_ERR(priv->io_base);
Maybe an error message here?
> +
> + err = fpga_mgr_register(kdev, "TS-73xx FPGA Manager",
> + &ts73xx_fpga_ops, priv);
> + if (err) {
> + dev_err(kdev, "failed to register FPGA manager\n");
> + return err;
> + }
> +
> + return err;
> +}
> +
> +static int ts73xx_fpga_remove(struct platform_device *pdev)
> +{
> + fpga_mgr_unregister(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static struct platform_driver ts73xx_fpga_driver = {
> + .driver = {
> + .name = "ts73xx-fpga-mgr",
> + },
> + .probe = ts73xx_fpga_probe,
> + .remove = ts73xx_fpga_remove,
> +};
> +module_platform_driver(ts73xx_fpga_driver);
> +
> +MODULE_AUTHOR("Florian Fainelli <f.fainelli@gmail.com>");
> +MODULE_DESCRIPTION("TS-73xx FPGA Manager driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.9.3
>
Thanks,
Moritz
^ permalink raw reply
* [PATCH 2/2] FPGA: Add TS-7300 FPGA manager
From: Florian Fainelli @ 2016-12-11 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211221750.27743-1-f.fainelli@gmail.com>
Add support for loading bitstreams on the Altera Cyclone II FPGA
populated on the TS-7300 board. This is done through the configuration
and data registers offered through a memory interface between the EP93xx
SoC and the FPGA.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/fpga/Kconfig | 7 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/ts73xx-fpga.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 173 insertions(+)
create mode 100644 drivers/fpga/ts73xx-fpga.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index cd84934774cc..109625707ef0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -26,6 +26,13 @@ config FPGA_MGR_ZYNQ_FPGA
help
FPGA manager driver support for Xilinx Zynq FPGAs.
+config FPGA_MGR_TS73XX
+ tristate "Technologic Systems TS-73xx SBC FPGA Manager"
+ depends on ARCH_EP93XX && MACH_TS72XX
+ help
+ FPGA manager driver support for the Altera Cyclone II FPGA
+ present on the TS-73xx SBC boards.
+
endif # FPGA
endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6b1613..5d51265cc1b4 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
+obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c
new file mode 100644
index 000000000000..2b3d5d668dfc
--- /dev/null
+++ b/drivers/fpga/ts73xx-fpga.c
@@ -0,0 +1,165 @@
+/*
+ * Technologic Systems TS-73xx SBC FPGA loader
+ *
+ * Copyright (C) 2016 Florian Fainelli <f.fainelli@gmail.com>
+ *
+ * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on
+ * TS-7300, heavily based on load_fpga.c in their vendor tree.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+#include <linux/bitrev.h>
+#include <linux/fpga/fpga-mgr.h>
+
+#define TS73XX_FPGA_DATA_REG 0
+#define TS73XX_FPGA_CONFIG_REG 1
+
+struct ts73xx_fpga_priv {
+ void __iomem *io_base;
+ struct device *dev;
+};
+
+static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr)
+{
+ return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ts73xx_fpga_write_init(struct fpga_manager *mgr, u32 flags,
+ const char *buf, size_t count)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+
+ /* Reset the FPGA */
+ writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ udelay(30);
+ writeb(0x2, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ udelay(80);
+
+ return 0;
+}
+
+static inline int ts73xx_fpga_can_write(struct ts73xx_fpga_priv *priv)
+{
+ unsigned int timeout = 1000;
+ u8 reg;
+
+ while (timeout--) {
+ reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ if (!(reg & 0x1))
+ return 0;
+ cpu_relax();
+ }
+
+ return -ETIMEDOUT;
+}
+
+static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf,
+ size_t count)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+ size_t i = 0;
+ int ret;
+ u8 reg;
+
+ while (count--) {
+ ret = ts73xx_fpga_can_write(priv);
+ if (ret < 0)
+ return ret;
+
+ writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG);
+ i++;
+ }
+
+ usleep_range(1000, 2000);
+ reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ reg |= 0x8;
+ writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ usleep_range(1000, 2000);
+
+ reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ reg &= ~0x8;
+ writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+
+ return 0;
+}
+
+static int ts73xx_fpga_write_complete(struct fpga_manager *mgr, u32 flags)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+ u8 reg;
+
+ reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ if ((reg & 0x4) != 0x4)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static const struct fpga_manager_ops ts73xx_fpga_ops = {
+ .state = ts73xx_fpga_state,
+ .write_init = ts73xx_fpga_write_init,
+ .write = ts73xx_fpga_write,
+ .write_complete = ts73xx_fpga_write_complete,
+};
+
+static int ts73xx_fpga_probe(struct platform_device *pdev)
+{
+ struct device *kdev = &pdev->dev;
+ struct ts73xx_fpga_priv *priv;
+ struct fpga_manager *mgr;
+ struct resource *res;
+ int err;
+
+ priv = devm_kzalloc(kdev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = kdev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->io_base = devm_ioremap_resource(kdev, res);
+ if (IS_ERR(priv->io_base))
+ return PTR_ERR(priv->io_base);
+
+ err = fpga_mgr_register(kdev, "TS-73xx FPGA Manager",
+ &ts73xx_fpga_ops, priv);
+ if (err) {
+ dev_err(kdev, "failed to register FPGA manager\n");
+ return err;
+ }
+
+ return err;
+}
+
+static int ts73xx_fpga_remove(struct platform_device *pdev)
+{
+ fpga_mgr_unregister(&pdev->dev);
+
+ return 0;
+}
+
+static struct platform_driver ts73xx_fpga_driver = {
+ .driver = {
+ .name = "ts73xx-fpga-mgr",
+ },
+ .probe = ts73xx_fpga_probe,
+ .remove = ts73xx_fpga_remove,
+};
+module_platform_driver(ts73xx_fpga_driver);
+
+MODULE_AUTHOR("Florian Fainelli <f.fainelli@gmail.com>");
+MODULE_DESCRIPTION("TS-73xx FPGA Manager driver");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
From: Florian Fainelli @ 2016-12-11 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211221750.27743-1-f.fainelli@gmail.com>
Register the TS-7300 FPGA manager device drivers which allows us to load
bitstreams into the on-board Altera Cyclone II FPGA.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mach-ep93xx/ts72xx.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 3b39ea353d30..acf72ea670ef 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -230,6 +230,28 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
.phy_id = 1,
};
+#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
+
+/* Relative to EP93XX_CS1_PHYS_BASE */
+#define TS73XX_FPGA_LOADER_BASE 0x03c00000
+
+static struct resource ts73xx_fpga_resources[] = {
+ {
+ .start = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE,
+ .end = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE + 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device ts73xx_fpga_device = {
+ .name = "ts73xx-fpga-mgr",
+ .id = -1,
+ .resource = ts73xx_fpga_resources,
+ .num_resources = ARRAY_SIZE(ts73xx_fpga_resources),
+};
+
+#endif
+
static void __init ts72xx_init_machine(void)
{
ep93xx_init_devices();
@@ -238,6 +260,10 @@ static void __init ts72xx_init_machine(void)
platform_device_register(&ts72xx_wdt_device);
ep93xx_register_eth(&ts72xx_eth_data, 1);
+#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
+ if (board_is_ts7300())
+ platform_device_register(&ts73xx_fpga_device);
+#endif
}
MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC")
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] FPGA: TS-7300 FPGA manager
From: Florian Fainelli @ 2016-12-11 22:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This patch series adds support for loading bitstreams into the Altera Cyclone II
connected to an EP9302 on a TS-7300 board.
Florian Fainelli (1):
ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
FPGA: Add TS-7300 FPGA manager
drivers/fpga/Kconfig | 7 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/ts73xx-fpga.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
drivers/mfd/Kconfig | 7 ++
4 files changed, 180 insertions(+)
create mode 100644 drivers/fpga/ts73xx-fpga.c
--
2.9.3
^ permalink raw reply
* [PATCH] pinctrl: meson: fix gpio request disabling other modes
From: Beniamino Galvani @ 2016-12-11 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206140817.11708-1-narmstrong@baylibre.com>
On Tue, Dec 06, 2016 at 03:08:16PM +0100, Neil Armstrong wrote:
> The pinctrl_gpio_request is called with the "full" gpio number, already
> containing the base, then meson_pmx_request_gpio is then called with the
> final pin number.
> Remove the base addition when calling meson_pmx_disable_other_groups.
>
> Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs")
> CC: Beniamino Galvani <b.galvani@gmail.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Beniamino Galvani <b.galvani@gmail.com>
^ permalink raw reply
* [PATCH v5 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-12-11 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481185563-8735-3-git-send-email-cedric.madianga@gmail.com>
Hi,
> +config I2C_STM32F4
> + tristate "STMicroelectronics STM32F4 I2C support"
> + depends on ARCH_STM32 || COMPILE_TEST
Double space.
> +#define STM32F4_I2C_MIN_FREQ 2
> +#define STM32F4_I2C_MAX_FREQ 42
Those two must be unsigned to fix the build error (e.g. 2U) reported by
build-bot.
Also, I get the following build warnings:
CC drivers/i2c/busses/i2c-stm32f4.o
drivers/i2c/busses/i2c-stm32f4.c: In function ?stm32f4_i2c_handle_rx_addr?:
drivers/i2c/busses/i2c-stm32f4.c:445:6: warning: variable ?sr2? set but not used [-Wunused-but-set-variable]
u32 sr2;
^~~
drivers/i2c/busses/i2c-stm32f4.c: In function ?stm32f4_i2c_isr_event?:
drivers/i2c/busses/i2c-stm32f4.c:496:41: warning: variable ?sr2? set but not used [-Wunused-but-set-variable]
u32 real_status, possible_status, ien, sr2;
I assume those are reads to clear the register, so we really don't need
to save the value in a variable.
Rest is looking good.
Thanks,
Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161211/0379cc61/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] kcov: make kcov work properly with KASLR enabled
From: Alexander Popov @ 2016-12-11 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACT4Y+bOd-Lzs45jyEr73GkRc7zZDxL8Z3fSc+TeZVRNVC6M-A@mail.gmail.com>
On 11.12.2016 12:32, Dmitry Vyukov wrote:
> On Sun, Dec 11, 2016 at 1:50 AM, Alexander Popov <alex.popov@linux.com> wrote:
>> Subtract KASLR offset from the kernel addresses reported by kcov.
>> Tested on x86_64 and AArch64 (Hikey LeMaker).
>>
>> Signed-off-by: Alexander Popov <alex.popov@linux.com>
>> ---
>> kernel/kcov.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> I think generally this is the right thing to do.
>
> There are 2 pending patches for kcov by +Quentin (hopefully in mm):
> "kcov: add AFL-style tracing"
> "kcov: size of arena is now given in bytes"
> https://groups.google.com/forum/#!topic/syzkaller/gcqbIhKjGcY
> https://groups.google.com/d/msg/syzkaller/gcqbIhKjGcY/KQFryjBKCAAJ
>
> Your patch probably conflicts with them.
> Should you base them on top of these patches, so that Andrew can merge
> it without conflicts?
Excuse me, I can't find these patches in:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
git://git.cmpxchg.org/linux-mmots.git
Could you point at the tree which I can rebase onto?
Should I cherry-pick Quentin's patches manually?
Best regards,
Alexander
^ permalink raw reply
* [PATCH] firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI firmwares
From: Martin Blumenstingl @ 2016-12-11 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <663deed4-fbbb-20ad-1943-dbd4e66e797f@arm.com>
On Wed, Dec 7, 2016 at 7:44 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 24/11/16 00:18, Martin Blumenstingl wrote:
>> The pre-1.0 SCPI firmwares are using one __le32 as sensor value, while
>> the 1.0 SCPI protocol uses two __le32 as sensor values (a total of
>> 64bit, split into 32bit upper and 32bit lower value).
>> Using an "struct sensor_value" to read the sensor value on a pre-1.0
>> SCPI firmware gives garbage in the "hi_val" field. Introducing a
>> separate function which handles scpi_ops.sensor_get_value for pre-1.0
>> SCPI firmware implementations ensures that we do not read memory which
>> was not written by the SCPI firmware (which fixes for example the
>> temperature reported by scpi-hwmon).
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> drivers/firmware/arm_scpi.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
>> index 70e1323..19f750d 100644
>> --- a/drivers/firmware/arm_scpi.c
>> +++ b/drivers/firmware/arm_scpi.c
>> @@ -728,6 +728,20 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
>> return ret;
>> }
>>
>> +static int legacy_scpi_sensor_get_value(u16 sensor, u64 *val)
>> +{
>> + __le16 id = cpu_to_le16(sensor);
>> + __le32 value;
>> + int ret;
>> +
>> + ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
>> + &value, sizeof(value));
>> + if (!ret)
>> + *val = le32_to_cpu(value);
>> +
>> + return ret;
>> +}
>
> Instead of duplicating the code so much, can we just manage something
> like this. If more commands need Rx len, then we can think of adding
> that. Even then reseting shared buffers is not good, we can clear the
> buffers on the stack.
I tested this approach and it's working fine! I just went ahead and
took your patch, moved the comment to a separate line, added a
description and send the patch as v3 (feel free to add yourself as
author and simply replace my Signed-off-by with a Tested-by).
> diff --git i/drivers/firmware/arm_scpi.c w/drivers/firmware/arm_scpi.c
> index 70e13230d8db..04aa873205e9 100644
> --- i/drivers/firmware/arm_scpi.c
> +++ w/drivers/firmware/arm_scpi.c
> @@ -721,11 +721,15 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
>
> ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
> &buf, sizeof(buf));
> - if (!ret)
> + if (ret)
> + return ret;
> +
> + if (scpi_info->is_legacy) /* 32-bits supported, hi_val can be
> junk */
> + *val = le32_to_cpu(buf.lo_val);
> + else
> *val = (u64)le32_to_cpu(buf.hi_val) << 32 |
> le32_to_cpu(buf.lo_val);
> -
> - return ret;
> + return 0;
> }
>
> static int scpi_device_get_power_state(u16 dev_id)
>
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH v3] firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI firmwares
From: Martin Blumenstingl @ 2016-12-11 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211211432.13252-1-martin.blumenstingl@googlemail.com>
The pre-1.0 SCPI firmwares are using one __le32 as sensor value, while
the 1.0 SCPI protocol uses two __le32 as sensor values (a total of
64bit, split into 32bit upper and 32bit lower value).
Using an "struct sensor_value" to read the sensor value on a pre-1.0
SCPI firmware gives garbage in the "hi_val" field. Introducing a
separate function which handles scpi_ops.sensor_get_value for pre-1.0
SCPI firmware implementations ensures that we do not read memory which
was not written by the SCPI firmware (which fixes for example the
temperature reported by scpi-hwmon).
Suggested-by: Sudeep Holla <Sudeep.Holla@arm.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/firmware/arm_scpi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 70e1323..9ad0b19 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -721,11 +721,17 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
&buf, sizeof(buf));
- if (!ret)
+ if (ret)
+ return ret;
+
+ if (scpi_info->is_legacy)
+ /* only 32-bits supported, hi_val can be junk */
+ *val = le32_to_cpu(buf.lo_val);
+ else
*val = (u64)le32_to_cpu(buf.hi_val) << 32 |
le32_to_cpu(buf.lo_val);
- return ret;
+ return 0;
}
static int scpi_device_get_power_state(u16 dev_id)
--
2.10.2
^ permalink raw reply related
* [PATCH v3] SCPI (pre-v1.0): fix reading sensor value
From: Martin Blumenstingl @ 2016-12-11 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125005432.1205-1-martin.blumenstingl@googlemail.com>
I observed the following "strange" value when trying to read the SCPI
temperature sensor on my Amlogic GXM S912 device:
$ cat /sys/class/hwmon/hwmon0/temp1_input
6875990994467160116
The value reported by the original kernel (Amlogic vendor kernel, after
a reboot obviously) was 53C.
The Amlogic SCPI driver only uses a single 32bit value to read the
sensor value, instead of two. After stripping the upper 32bits from
above value gives "52" as result, which is basically identical to
what the vendor kernel reports.
I also compared this with the value shown by u-boot (since there's
less delay between "reboot to u-boot" compared to "reboot from mainline
kernel to vendor kernel") and the temperature reported by u-boot always
matches the lower 32bits of the value from scpi-hwmon temp1_input.
Changes since v2:
- use simplified approach from Sudeep Holla which is similar to v1
but avoids duplicate code by adding a simple
"if (scpi_info->is_legacy)" to scpi_sensor_get_value() instead of
duplicating the logic
Changes since v1:
- zero out the rx_buf before reading the mbox buffer (see long
description above) instead of introducing a separate legacy command
for reading the sensor value
- added patch 2/2 which validates the payload lengths (so nobody can
read or write data beyond rx_buf or tx_buf). This optional and patch
1/2 can be applied without it
Martin Blumenstingl (1):
firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI
firmwares
drivers/firmware/arm_scpi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--
2.10.2
^ permalink raw reply
* [RFC v3 PATCH 00/25] Allow NOMMU for MULTIPLATFORM
From: Peter Korsgaard @ 2016-12-11 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211070104.GB3035@afzalpc>
>>>>> "Afzal" == Afzal Mohammed <afzal.mohd.ma@gmail.com> writes:
Hi,
>> You can build a toolchain and initramfs with Buildroot. Have a look at
>> the stm32f429 nommu config:
>>
>> https://git.buildroot.net/buildroot/tree/configs/stm32f429_disco_defconfig
> iiuc, it builds one for Cortex-M. i already had a file system w/
> busybox compiled using a Cortex-M toolchain (stolen from
> Pengutronix's OSELAS.Toolchain), which works on Cortex M4 (Vybrid
> VF610 M4 core). But it does not work here, i.e. on Cortex A, seems the
> above mentioned also would have the same effect.
Hmm, I'm not sure why a cortex-M toolchain wouldn't work on cortex-A, I
thought the 'M' instruction set was a pure subset of the 'A'.
> And in buildroot, couldn't see Cortex R option in menuconfig, and
> selecting Cortex-A's excludes flat binary target & presents only with
> ELF.
We indeed don't have cortex-R support. I'm not aware of any cortex-R
Linux support.
When you select a cortex-A variant, then we enable MMU support by
default, but you can disable it under toolchain options (Enable MMU) and
then the flat binary option is available.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH] ARM: ep93xx: Disable TS-72xx watchdog before uncompressing
From: Florian Fainelli @ 2016-12-11 19:16 UTC (permalink / raw)
To: linux-arm-kernel
The TS-72xx/73xx boards have a CPLD watchdog which is configured to
reset the board after 8 seconds, if the kernel is large enough that this
takes about this time to decompress the kernel, we will encounter a
spurious reboot.
Do not pull ts72xx.h, but instead locally define what we need to disable
the watchdog.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mach-ep93xx/include/mach/uncompress.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-ep93xx/include/mach/uncompress.h b/arch/arm/mach-ep93xx/include/mach/uncompress.h
index 03c42e5400d2..b0cf2de77f81 100644
--- a/arch/arm/mach-ep93xx/include/mach/uncompress.h
+++ b/arch/arm/mach-ep93xx/include/mach/uncompress.h
@@ -10,6 +10,7 @@
*/
#include <mach/ep93xx-regs.h>
+#include <asm/mach-types.h>
static unsigned char __raw_readb(unsigned int ptr)
{
@@ -75,8 +76,19 @@ static void ethernet_reset(void)
;
}
+#define TS72XX_WDT_CONTROL_PHYS_BASE 0x23800000
+#define TS72XX_WDT_FEED_PHYS_BASE 0x23c00000
+#define TS72XX_WDT_FEED_VAL 0x05
+
+static void __maybe_unused ts72xx_watchdog_disable(void)
+{
+ __raw_writeb(TS72XX_WDT_FEED_VAL, TS72XX_WDT_FEED_PHYS_BASE);
+ __raw_writeb(0, TS72XX_WDT_CONTROL_PHYS_BASE);
+}
static void arch_decomp_setup(void)
{
+ if (machine_is_ts72xx())
+ ts72xx_watchdog_disable();
ethernet_reset();
}
--
2.9.3
^ permalink raw reply related
* [PATCH v9 05/11] arm/arm64: vgic: Introduce VENG0 and VENG1 fields to vmcr struct
From: Christoffer Dall @ 2016-12-11 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <df037898-57d3-93d1-e59c-4055d0f6f0b0@redhat.com>
On Thu, Dec 08, 2016 at 01:50:43PM +0100, Auger Eric wrote:
> Hi Christoffer,
>
> On 08/12/2016 13:21, Christoffer Dall wrote:
> > On Thu, Dec 08, 2016 at 12:52:39PM +0100, Auger Eric wrote:
> >> Hi Vijay,
> >>
> >> On 28/11/2016 15:28, Christoffer Dall wrote:
> >>> On Wed, Nov 23, 2016 at 06:31:52PM +0530, vijay.kilari at gmail.com wrote:
> >>>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>>>
> >>>> ICC_VMCR_EL2 supports virtual access to ICC_IGRPEN1_EL1.Enable
> >>>> and ICC_IGRPEN0_EL1.Enable fields. Add grpen0 and grpen1 member
> >>>> variables to struct vmcr to support read and write of these fields.
> >>>>
> >>>> Also refactor vgic_set_vmcr and vgic_get_vmcr() code.
> >>>> Drop ICH_VMCR_CTLR_SHIFT and ICH_VMCR_CTLR_MASK macros and instead
> >>>> use ICH_VMCR_EOI* and ICH_VMCR_CBPR* macros
> >>>> .
> >>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>>> ---
> >>>> include/linux/irqchip/arm-gic-v3.h | 2 --
> >>>> virt/kvm/arm/vgic/vgic-mmio-v2.c | 16 ----------------
> >>>> virt/kvm/arm/vgic/vgic-mmio.c | 16 ++++++++++++++++
> >>>> virt/kvm/arm/vgic/vgic-v3.c | 22 ++++++++++++++++++++--
> >>>> virt/kvm/arm/vgic/vgic.h | 5 +++++
> >>>> 5 files changed, 41 insertions(+), 20 deletions(-)
> >>>>
> >>>> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> >>>> index b4f8287..406fc3e 100644
> >>>> --- a/include/linux/irqchip/arm-gic-v3.h
> >>>> +++ b/include/linux/irqchip/arm-gic-v3.h
> >>>> @@ -404,8 +404,6 @@
> >>>> #define ICH_HCR_EN (1 << 0)
> >>>> #define ICH_HCR_UIE (1 << 1)
> >>>>
> >>>> -#define ICH_VMCR_CTLR_SHIFT 0
> >>>> -#define ICH_VMCR_CTLR_MASK (0x21f << ICH_VMCR_CTLR_SHIFT)
> >>>> #define ICH_VMCR_CBPR_SHIFT 4
> >>>> #define ICH_VMCR_CBPR_MASK (1 << ICH_VMCR_CBPR_SHIFT)
> >>>> #define ICH_VMCR_EOIM_SHIFT 9
> >>>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >>>> index 2cb04b7..ad353b5 100644
> >>>> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >>>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >>>> @@ -212,22 +212,6 @@ static void vgic_mmio_write_sgipends(struct kvm_vcpu *vcpu,
> >>>> }
> >>>> }
> >>>>
> >>>> -static void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
> >>>> -{
> >>>> - if (kvm_vgic_global_state.type == VGIC_V2)
> >>>> - vgic_v2_set_vmcr(vcpu, vmcr);
> >>>> - else
> >>>> - vgic_v3_set_vmcr(vcpu, vmcr);
> >>>> -}
> >>>> -
> >>>> -static void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
> >>>> -{
> >>>> - if (kvm_vgic_global_state.type == VGIC_V2)
> >>>> - vgic_v2_get_vmcr(vcpu, vmcr);
> >>>> - else
> >>>> - vgic_v3_get_vmcr(vcpu, vmcr);
> >>>> -}
> >>>> -
> >>>> #define GICC_ARCH_VERSION_V2 0x2
> >>>>
> >>>> /* These are for userland accesses only, there is no guest-facing emulation. */
> >>>> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> >>>> index 0d1bc98..f81e0e5 100644
> >>>> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> >>>> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> >>>> @@ -416,6 +416,22 @@ int vgic_validate_mmio_region_addr(struct kvm_device *dev,
> >>>> return -ENXIO;
> >>>> }
> >>>>
> >>>> +void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
> >>>> +{
> >>>> + if (kvm_vgic_global_state.type == VGIC_V2)
> >>>> + vgic_v2_set_vmcr(vcpu, vmcr);
> >>>> + else
> >>>> + vgic_v3_set_vmcr(vcpu, vmcr);
> >>>> +}
> >>>> +
> >>>> +void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
> >>>> +{
> >>>> + if (kvm_vgic_global_state.type == VGIC_V2)
> >>>> + vgic_v2_get_vmcr(vcpu, vmcr);
> >>>> + else
> >>>> + vgic_v3_get_vmcr(vcpu, vmcr);
> >>>> +}
> >>>> +
> >>>> /*
> >>>> * kvm_mmio_read_buf() returns a value in a format where it can be converted
> >>>> * to a byte array and be directly observed as the guest wanted it to appear
> >>>> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> >>>> index 9f0dae3..a3ff04b 100644
> >>>> --- a/virt/kvm/arm/vgic/vgic-v3.c
> >>>> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> >>>> @@ -175,10 +175,19 @@ void vgic_v3_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcrp)
> >>>> {
> >>>> u32 vmcr;
> >>>>
> >>>> - vmcr = (vmcrp->ctlr << ICH_VMCR_CTLR_SHIFT) & ICH_VMCR_CTLR_MASK;
> >>>> + /*
> >>>> + * Ignore the FIQen bit, because GIC emulation always implies
> >>>> + * SRE=1 which means the vFIQEn bit is also RES1.
> >>>> + */
> >>>> + vmcr = (vmcrp->ctlr & ICC_CTLR_EL1_EOImode_MASK) >>
> >>>> + ICC_CTLR_EL1_EOImode_SHIFT;
> >>>> + vmcr = (vmcr << ICH_VMCR_EOIM_SHIFT) & ICH_VMCR_EOIM_MASK;
> >
> >> I am not able to understand why we use ICC_CTLR _*macros here? Please
> >> could you explain it to me? Besides if we want to ignore the FIQen bit
> >> can't we change the ICH_VMCR_CTLR_MASK value?
> >>
> > This first statement is setting the vmcr to the ctlr's bit[1], but
> > placed in bit[0], and then the next statement is moving that bit value
> > to the corresponding place in the vmcr. I think this is correct
> > (although a little opaque).
> Yes the question was more about the semantic of the vmcrp->ctlr field. I
> thought it was supposed to store ICH_VMCR_EL2 ctrl bits as they are and
> not with a different layout.
my understanding is that vmcrp->ctlr is a representation of the
GICC_CTLR field and its bit layout (based on the existin v2 code, unless
I misread it) and the vmcr is the vmcr field.
I don't care much either way, as long as it's clear what the semantics
are. One problem with storing parts of the VMCR in the vmcrp->ctlr
field is that I don't think there's an architectural definition of the
concept 'ICH_VMCR_EL2 ctrl bits'.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 3/3] mm: make pagoff_t type 64-bit
From: Arnd Bergmann @ 2016-12-11 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481461003-14361-4-git-send-email-ynorov@caviumnetworks.com>
On Sunday, December 11, 2016 6:26:42 PM CET Yury Norov wrote:
> Also fix related interfaces
>
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> ---
> fs/btrfs/extent_io.c | 2 +-
> fs/ext2/dir.c | 4 ++--
> include/linux/mm.h | 9 +++++----
> include/linux/radix-tree.h | 8 ++++----
> include/linux/types.h | 2 +-
> lib/radix-tree.c | 8 ++++----
> mm/debug.c | 2 +-
> mm/internal.h | 2 +-
> mm/memory.c | 4 ++--
> mm/mmap.c | 7 ++++---
> mm/readahead.c | 4 ++--
> mm/util.c | 3 ++-
> 12 files changed, 29 insertions(+), 26 deletions(-)
>
Thanks Yury for the demonstration. I think this would put the nail
in the coffin of the idea of mmap64 even for Pavel, who didn't
seem convinced already.
Changing all those interfaces and structure, struct page in particular,
is clearly too costly for any advantage we might have otherwise
gained.
Arnd
^ permalink raw reply
* [PATCH 2/3] sys_mmap64()
From: kbuild test robot @ 2016-12-11 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481461003-14361-3-git-send-email-ynorov@caviumnetworks.com>
Hi Yury,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc8 next-20161209]
[cannot apply to mmotm/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yury-Norov/mm-move-argument-checkers-of-mmap_pgoff-to-separated-routine/20161211-211314
config: c6x-evmc6457_defconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=c6x
All errors (new ones prefixed by >>):
>> arch/c6x/kernel/built-in.o:(.fardata+0xb8c): undefined reference to `sys_mmap64'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 5162 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161211/0adf7b58/attachment.gz>
^ permalink raw reply
* [PATCH 2/3] sys_mmap64()
From: kbuild test robot @ 2016-12-11 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481461003-14361-3-git-send-email-ynorov@caviumnetworks.com>
Hi Yury,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc8 next-20161209]
[cannot apply to mmotm/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yury-Norov/mm-move-argument-checkers-of-mmap_pgoff-to-separated-routine/20161211-211314
config: h8300-h8300h-sim_defconfig (attached as .config)
compiler: h8300-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=h8300
All errors (new ones prefixed by >>):
>> arch/h8300/kernel/built-in.o:(.data+0x48c): undefined reference to `sys_mmap64'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 4484 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161211/8d970fd7/attachment.gz>
^ permalink raw reply
* [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
From: Afzal Mohammed @ 2016-12-11 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211131255.3221-1-afzal.mohd.ma@gmail.com>
Hi,
On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote:
> Kernel text start at an offset of at least 32K to account for page
> tables in MMU case.
Proper way to put it might have been "32K (to account for 16K initial
page tables & the old atags)", unless i missed something.
Regards
afzal
^ permalink raw reply
* [PATCH 3/3] mm: make pagoff_t type 64-bit
From: kbuild test robot @ 2016-12-11 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481461003-14361-4-git-send-email-ynorov@caviumnetworks.com>
Hi Yury,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9-rc8]
[cannot apply to mmotm/master next-20161209]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yury-Norov/mm-move-argument-checkers-of-mmap_pgoff-to-separated-routine/20161211-211314
config: i386-randconfig-x003-201650 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
fs/ext2/dir.c: In function 'ext2_check_page':
>> fs/ext2/dir.c:177:56: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
ext2_error(sb, __func__, "bad entry in directory #%llu: : %s - "
^
>> fs/ext2/dir.c:177:28: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'long long unsigned int' [-Wformat=]
ext2_error(sb, __func__, "bad entry in directory #%llu: : %s - "
^
fs/ext2/dir.c:187:28: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
"entry in directory #%llu spans the page boundary"
^
fs/ext2/dir.c:187:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'long long unsigned int' [-Wformat=]
"entry in directory #%llu spans the page boundary"
^
vim +177 fs/ext2/dir.c
161 Eshort:
162 error = "rec_len is smaller than minimal";
163 goto bad_entry;
164 Ealign:
165 error = "unaligned directory entry";
166 goto bad_entry;
167 Enamelen:
168 error = "rec_len is too small for name_len";
169 goto bad_entry;
170 Espan:
171 error = "directory entry across blocks";
172 goto bad_entry;
173 Einumber:
174 error = "inode out of bounds";
175 bad_entry:
176 if (!quiet)
> 177 ext2_error(sb, __func__, "bad entry in directory #%llu: : %s - "
178 "offset=%lu, inode=%lu, rec_len=%d, name_len=%d",
179 dir->i_ino, error, (page->index<<PAGE_SHIFT)+offs,
180 (unsigned long) le32_to_cpu(p->inode),
181 rec_len, p->name_len);
182 goto fail;
183 Eend:
184 if (!quiet) {
185 p = (ext2_dirent *)(kaddr + offs);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 26862 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161211/8b3995f2/attachment-0001.gz>
^ permalink raw reply
* [PATCH 3/3] mm: make pagoff_t type 64-bit
From: kbuild test robot @ 2016-12-11 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481461003-14361-4-git-send-email-ynorov@caviumnetworks.com>
Hi Yury,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9-rc8]
[cannot apply to mmotm/master next-20161209]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yury-Norov/mm-move-argument-checkers-of-mmap_pgoff-to-separated-routine/20161211-211314
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
arch/x86/mm/pgtable.c: In function 'pgd_set_mm':
>> arch/x86/mm/pgtable.c:108:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
virt_to_page(pgd)->index = (pgoff_t)mm;
^
arch/x86/mm/pgtable.c: In function 'pgd_page_get_mm':
>> arch/x86/mm/pgtable.c:113:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
return (struct mm_struct *)page->index;
^
--
mm/percpu.c: In function 'pcpu_get_page_chunk':
>> mm/percpu.c:240:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
return (struct pcpu_chunk *)page->index;
^
vim +108 arch/x86/mm/pgtable.c
68db065c Jeremy Fitzhardinge 2008-03-17 102 (SHARED_KERNEL_PMD ? KERNEL_PGD_BOUNDARY : PTRS_PER_PGD)
4f76cd38 Jeremy Fitzhardinge 2008-03-17 103
617d34d9 Jeremy Fitzhardinge 2010-09-21 104
617d34d9 Jeremy Fitzhardinge 2010-09-21 105 static void pgd_set_mm(pgd_t *pgd, struct mm_struct *mm)
617d34d9 Jeremy Fitzhardinge 2010-09-21 106 {
617d34d9 Jeremy Fitzhardinge 2010-09-21 107 BUILD_BUG_ON(sizeof(virt_to_page(pgd)->index) < sizeof(mm));
617d34d9 Jeremy Fitzhardinge 2010-09-21 @108 virt_to_page(pgd)->index = (pgoff_t)mm;
617d34d9 Jeremy Fitzhardinge 2010-09-21 109 }
617d34d9 Jeremy Fitzhardinge 2010-09-21 110
617d34d9 Jeremy Fitzhardinge 2010-09-21 111 struct mm_struct *pgd_page_get_mm(struct page *page)
617d34d9 Jeremy Fitzhardinge 2010-09-21 112 {
617d34d9 Jeremy Fitzhardinge 2010-09-21 @113 return (struct mm_struct *)page->index;
617d34d9 Jeremy Fitzhardinge 2010-09-21 114 }
617d34d9 Jeremy Fitzhardinge 2010-09-21 115
617d34d9 Jeremy Fitzhardinge 2010-09-21 116 static void pgd_ctor(struct mm_struct *mm, pgd_t *pgd)
:::::: The code at line 108 was first introduced by commit
:::::: 617d34d9e5d8326ec8f188c616aa06ac59d083fe x86, mm: Hold mm->page_table_lock while doing vmalloc_sync
:::::: TO: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
:::::: CC: H. Peter Anvin <hpa@linux.intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6363 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161211/a02f0aed/attachment.gz>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox