* [PATCH] arm64: fix infinite stacktrace
From: Mark Rutland @ 2018-06-15 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LRH.2.02.1806141457200.4243@file01.intranet.prod.int.rdu2.redhat.com>
Hi,
On Thu, Jun 14, 2018 at 02:58:21PM -0400, Mikulas Patocka wrote:
> I've got this infinite stacktrace when debugging another problem:
> [ 908.795225] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 908.796176] 1-...!: (1 GPs behind) idle=952/1/4611686018427387904 softirq=1462/1462 fqs=355
> [ 908.797692] 2-...!: (1 GPs behind) idle=f42/1/4611686018427387904 softirq=1550/1551 fqs=355
> [ 908.799189] (detected by 0, t=2109 jiffies, g=130, c=129, q=235)
> [ 908.800284] Task dump for CPU 1:
> [ 908.800871] kworker/1:1 R running task 0 32 2 0x00000022
> [ 908.802127] Workqueue: writecache-writeabck writecache_writeback [dm_writecache]
> [ 908.820285] Call trace:
> [ 908.824785] __switch_to+0x68/0x90
> [ 908.837661] 0xfffffe00603afd90
> [ 908.844119] 0xfffffe00603afd90
> [ 908.850091] 0xfffffe00603afd90
> [ 908.854285] 0xfffffe00603afd90
> [ 908.863538] 0xfffffe00603afd90
> [ 908.865523] 0xfffffe00603afd90
>
> The machine just locked up and kept on printing the same line over and
> over again. This patch fixes it.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Cc: stable at vger.kernel.org
Given this can only occur when there's a corrupted stack (where a frame
record points to itself), I'm not sure this requires a cc stable.
> Index: linux-2.6/arch/arm64/kernel/stacktrace.c
> ===================================================================
> --- linux-2.6.orig/arch/arm64/kernel/stacktrace.c
> +++ linux-2.6/arch/arm64/kernel/stacktrace.c
> @@ -56,6 +56,9 @@ int notrace unwind_frame(struct task_str
> frame->fp = READ_ONCE_NOCHECK(*(unsigned long *)(fp));
> frame->pc = READ_ONCE_NOCHECK(*(unsigned long *)(fp + 8));
>
> + if (frame->fp <= fp)
> + return -EINVAL;
> +
Dave Martin had a series [1] which addressed this along with a number of
other cases where stack traces might not terminate.
Dave, do you plan to respin that?
Thanks,
Mark.
[1] https://lkml.kernel.org/r/1524503223-17576-1-git-send-email-Dave.Martin at arm.com
^ permalink raw reply
* [PATCH 1/9] CHROMIUM: v4l: Add H264 low-level decoder API compound controls.
From: Hans Verkuil @ 2018-06-15 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613140714.1686-2-maxime.ripard@bootlin.com>
On 13/06/18 16:07, Maxime Ripard wrote:
> From: Pawel Osciak <posciak@chromium.org>
Obviously this needs a proper commit message.
>
> Signed-off-by: Pawel Osciak <posciak@chromium.org>
> Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
> Tested-by: Tomasz Figa <tfiga@chromium.org>
> [rebase44(groeck): include linux/types.h in v4l2-controls.h]
> Signed-off-by: Guenter Roeck <groeck@chromium.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 42 +++++++
> include/media/v4l2-ctrls.h | 10 ++
> include/uapi/linux/v4l2-controls.h | 164 +++++++++++++++++++++++++++
> include/uapi/linux/videodev2.h | 11 ++
> 4 files changed, 227 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index cdf860c8e3d8..1f63c725bad1 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -807,6 +807,11 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER:return "H264 Number of HC Layers";
> case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP:
> return "H264 Set QP Value for HC Layers";
> + case V4L2_CID_MPEG_VIDEO_H264_SPS: return "H264 SPS";
> + case V4L2_CID_MPEG_VIDEO_H264_PPS: return "H264 PPS";
> + case V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX: return "H264 Scaling Matrix";
> + case V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM: return "H264 Slice Parameters";
> + case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAM: return "H264 Decode Parameters";
> case V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP: return "MPEG4 I-Frame QP Value";
> case V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP: return "MPEG4 P-Frame QP Value";
> case V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP: return "MPEG4 B-Frame QP Value";
> @@ -1272,6 +1277,21 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> case V4L2_CID_RDS_TX_ALT_FREQS:
> *type = V4L2_CTRL_TYPE_U32;
> break;
> + case V4L2_CID_MPEG_VIDEO_H264_SPS:
> + *type = V4L2_CTRL_TYPE_H264_SPS;
> + break;
> + case V4L2_CID_MPEG_VIDEO_H264_PPS:
> + *type = V4L2_CTRL_TYPE_H264_PPS;
> + break;
> + case V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX:
> + *type = V4L2_CTRL_TYPE_H264_SCALING_MATRIX;
> + break;
> + case V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM:
> + *type = V4L2_CTRL_TYPE_H264_SLICE_PARAM;
> + break;
> + case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAM:
> + *type = V4L2_CTRL_TYPE_H264_DECODE_PARAM;
> + break;
> case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> break;
> @@ -1598,6 +1618,13 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32 idx,
> case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> return 0;
>
> + case V4L2_CTRL_TYPE_H264_SPS:
> + case V4L2_CTRL_TYPE_H264_PPS:
> + case V4L2_CTRL_TYPE_H264_SCALING_MATRIX:
> + case V4L2_CTRL_TYPE_H264_SLICE_PARAM:
> + case V4L2_CTRL_TYPE_H264_DECODE_PARAM:
> + return 0;
> +
> default:
> return -EINVAL;
> }
> @@ -2172,6 +2199,21 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
> case V4L2_CTRL_TYPE_U32:
> elem_size = sizeof(u32);
> break;
> + case V4L2_CTRL_TYPE_H264_SPS:
> + elem_size = sizeof(struct v4l2_ctrl_h264_sps);
> + break;
> + case V4L2_CTRL_TYPE_H264_PPS:
> + elem_size = sizeof(struct v4l2_ctrl_h264_pps);
> + break;
> + case V4L2_CTRL_TYPE_H264_SCALING_MATRIX:
> + elem_size = sizeof(struct v4l2_ctrl_h264_scaling_matrix);
> + break;
> + case V4L2_CTRL_TYPE_H264_SLICE_PARAM:
> + elem_size = sizeof(struct v4l2_ctrl_h264_slice_param);
> + break;
> + case V4L2_CTRL_TYPE_H264_DECODE_PARAM:
> + elem_size = sizeof(struct v4l2_ctrl_h264_decode_param);
> + break;
> case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr);
> break;
> diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
> index 963c37b02363..9c223793a16a 100644
> --- a/include/media/v4l2-ctrls.h
> +++ b/include/media/v4l2-ctrls.h
> @@ -41,6 +41,11 @@ struct poll_table_struct;
> * @p_u16: Pointer to a 16-bit unsigned value.
> * @p_u32: Pointer to a 32-bit unsigned value.
> * @p_char: Pointer to a string.
> + * @p_h264_sps: Pointer to a struct v4l2_ctrl_h264_sps.
> + * @p_h264_pps: Pointer to a struct v4l2_ctrl_h264_pps.
> + * @p_h264_scal_mtrx: Pointer to a struct v4l2_ctrl_h264_scaling_matrix.
> + * @p_h264_slice_param: Pointer to a struct v4l2_ctrl_h264_slice_param.
> + * @p_h264_decode_param: Pointer to a struct v4l2_ctrl_h264_decode_param.
> * @p: Pointer to a compound value.
> */
> union v4l2_ctrl_ptr {
> @@ -50,6 +55,11 @@ union v4l2_ctrl_ptr {
> u16 *p_u16;
> u32 *p_u32;
> char *p_char;
> + struct v4l2_ctrl_h264_sps *p_h264_sps;
> + struct v4l2_ctrl_h264_pps *p_h264_pps;
> + struct v4l2_ctrl_h264_scaling_matrix *p_h264_scal_mtrx;
> + struct v4l2_ctrl_h264_slice_param *p_h264_slice_param;
> + struct v4l2_ctrl_h264_decode_param *p_h264_decode_param;
> void *p;
> };
>
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 23da8bfa7e6f..ac307c59683c 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -50,6 +50,8 @@
> #ifndef __LINUX_V4L2_CONTROLS_H
> #define __LINUX_V4L2_CONTROLS_H
>
> +#include <linux/types.h>
> +
> /* Control classes */
> #define V4L2_CTRL_CLASS_USER 0x00980000 /* Old-style 'user' controls */
> #define V4L2_CTRL_CLASS_MPEG 0x00990000 /* MPEG-compression controls */
> @@ -531,6 +533,12 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type {
> };
> #define V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER (V4L2_CID_MPEG_BASE+381)
> #define V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP (V4L2_CID_MPEG_BASE+382)
> +#define V4L2_CID_MPEG_VIDEO_H264_SPS (V4L2_CID_MPEG_BASE+383)
> +#define V4L2_CID_MPEG_VIDEO_H264_PPS (V4L2_CID_MPEG_BASE+384)
> +#define V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX (V4L2_CID_MPEG_BASE+385)
> +#define V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM (V4L2_CID_MPEG_BASE+386)
> +#define V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAM (V4L2_CID_MPEG_BASE+387)
> +
> #define V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP (V4L2_CID_MPEG_BASE+400)
> #define V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP (V4L2_CID_MPEG_BASE+401)
> #define V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP (V4L2_CID_MPEG_BASE+402)
> @@ -1078,6 +1086,162 @@ enum v4l2_detect_md_mode {
> #define V4L2_CID_DETECT_MD_THRESHOLD_GRID (V4L2_CID_DETECT_CLASS_BASE + 3)
> #define V4L2_CID_DETECT_MD_REGION_GRID (V4L2_CID_DETECT_CLASS_BASE + 4)
>
> +/* Complex controls */
The right term is 'Compounds controls'.
> +
> +#define V4L2_H264_SPS_CONSTRAINT_SET0_FLAG 0x01
> +#define V4L2_H264_SPS_CONSTRAINT_SET1_FLAG 0x02
> +#define V4L2_H264_SPS_CONSTRAINT_SET2_FLAG 0x04
> +#define V4L2_H264_SPS_CONSTRAINT_SET3_FLAG 0x08
> +#define V4L2_H264_SPS_CONSTRAINT_SET4_FLAG 0x10
> +#define V4L2_H264_SPS_CONSTRAINT_SET5_FLAG 0x20
> +
> +#define V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE 0x01
> +#define V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS 0x02
> +#define V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO 0x04
> +#define V4L2_H264_SPS_FLAG_GAPS_IN_FRAME_NUM_VALUE_ALLOWED 0x08
> +#define V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY 0x10
> +#define V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD 0x20
> +#define V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE 0x40
Add a newline here. Same for the other structs below.
> +struct v4l2_ctrl_h264_sps {
> + __u8 profile_idc;
> + __u8 constraint_set_flags;
> + __u8 level_idc;
> + __u8 seq_parameter_set_id;
> + __u8 chroma_format_idc;
> + __u8 bit_depth_luma_minus8;
> + __u8 bit_depth_chroma_minus8;
> + __u8 log2_max_frame_num_minus4;
> + __u8 pic_order_cnt_type;
> + __u8 log2_max_pic_order_cnt_lsb_minus4;
There is a hole in the struct here. Is that OK? Are there alignment requirements?
> + __s32 offset_for_non_ref_pic;
> + __s32 offset_for_top_to_bottom_field;
> + __u8 num_ref_frames_in_pic_order_cnt_cycle;
> + __s32 offset_for_ref_frame[255];
Perhaps use a define instead of hardcoding 255? Not sure if that makes sense.
Same for other arrays below.
> + __u8 max_num_ref_frames;
> + __u16 pic_width_in_mbs_minus1;
> + __u16 pic_height_in_map_units_minus1;
> + __u8 flags;
> +};
You have to test the struct layout for 32 bit and 64 bit systems (the latter for both
64 bit arm and Intel). The layout should be the same for all of them since the
control framework does not support compat32 conversions for compound controls.
> +
> +#define V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE 0x0001
> +#define V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT 0x0002
> +#define V4L2_H264_PPS_FLAG_WEIGHTED_PRED 0x0004
> +#define V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT 0x0008
> +#define V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED 0x0010
> +#define V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT 0x0020
> +#define V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE 0x0040
> +#define V4L2_H264_PPS_FLAG_PIC_SCALING_MATRIX_PRESENT 0x0080
> +struct v4l2_ctrl_h264_pps {
> + __u8 pic_parameter_set_id;
> + __u8 seq_parameter_set_id;
> + __u8 num_slice_groups_minus1;
> + __u8 num_ref_idx_l0_default_active_minus1;
> + __u8 num_ref_idx_l1_default_active_minus1;
> + __u8 weighted_bipred_idc;
> + __s8 pic_init_qp_minus26;
> + __s8 pic_init_qs_minus26;
> + __s8 chroma_qp_index_offset;
> + __s8 second_chroma_qp_index_offset;
> + __u8 flags;
> +};
> +
> +struct v4l2_ctrl_h264_scaling_matrix {
> + __u8 scaling_list_4x4[6][16];
> + __u8 scaling_list_8x8[6][64];
> +};
> +
> +struct v4l2_h264_weight_factors {
> + __s8 luma_weight[32];
> + __s8 luma_offset[32];
> + __s8 chroma_weight[32][2];
> + __s8 chroma_offset[32][2];
> +};
> +
> +struct v4l2_h264_pred_weight_table {
> + __u8 luma_log2_weight_denom;
> + __u8 chroma_log2_weight_denom;
> + struct v4l2_h264_weight_factors weight_factors[2];
> +};
> +
> +enum v4l2_h264_slice_type {
> + V4L2_H264_SLICE_TYPE_P = 0,
> + V4L2_H264_SLICE_TYPE_B = 1,
> + V4L2_H264_SLICE_TYPE_I = 2,
> + V4L2_H264_SLICE_TYPE_SP = 3,
> + V4L2_H264_SLICE_TYPE_SI = 4,
> +};
> +
> +#define V4L2_SLICE_FLAG_FIELD_PIC 0x01
> +#define V4L2_SLICE_FLAG_BOTTOM_FIELD 0x02
> +#define V4L2_SLICE_FLAG_DIRECT_SPATIAL_MV_PRED 0x04
> +#define V4L2_SLICE_FLAG_SP_FOR_SWITCH 0x08
> +struct v4l2_ctrl_h264_slice_param {
> + /* Size in bytes, including header */
> + __u32 size;
> + /* Offset in bits to slice_data() from the beginning of this slice. */
> + __u32 header_bit_size;
> +
> + __u16 first_mb_in_slice;
> + enum v4l2_h264_slice_type slice_type;
Avoid enums in a struct.
> + __u8 pic_parameter_set_id;
> + __u8 colour_plane_id;
> + __u16 frame_num;
> + __u16 idr_pic_id;
> + __u16 pic_order_cnt_lsb;
> + __s32 delta_pic_order_cnt_bottom;
> + __s32 delta_pic_order_cnt0;
> + __s32 delta_pic_order_cnt1;
> + __u8 redundant_pic_cnt;
> +
> + struct v4l2_h264_pred_weight_table pred_weight_table;
> + /* Size in bits of dec_ref_pic_marking() syntax element. */
> + __u32 dec_ref_pic_marking_bit_size;
> + /* Size in bits of pic order count syntax. */
> + __u32 pic_order_cnt_bit_size;
> +
> + __u8 cabac_init_idc;
> + __s8 slice_qp_delta;
> + __s8 slice_qs_delta;
> + __u8 disable_deblocking_filter_idc;
> + __s8 slice_alpha_c0_offset_div2;
> + __s8 slice_beta_offset_div2;
> + __u32 slice_group_change_cycle;
> +
> + __u8 num_ref_idx_l0_active_minus1;
> + __u8 num_ref_idx_l1_active_minus1;
> + /* Entries on each list are indices
> + * into v4l2_ctrl_h264_decode_param.dpb[]. */
> + __u8 ref_pic_list0[32];
> + __u8 ref_pic_list1[32];
> +
> + __u8 flags;
> +};
> +
> +/* If not set, this entry is unused for reference. */
> +#define V4L2_H264_DPB_ENTRY_FLAG_ACTIVE 0x01
> +#define V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM 0x02
> +struct v4l2_h264_dpb_entry {
> + __u32 buf_index; /* v4l2_buffer index */
> + __u16 frame_num;
> + __u16 pic_num;
> + /* Note that field is indicated by v4l2_buffer.field */
> + __s32 top_field_order_cnt;
> + __s32 bottom_field_order_cnt;
> + __u8 flags; /* V4L2_H264_DPB_ENTRY_FLAG_* */
> +};
> +
> +struct v4l2_ctrl_h264_decode_param {
> + __u32 num_slices;
> + __u8 idr_pic_flag;
> + __u8 nal_ref_idc;
> + __s32 top_field_order_cnt;
> + __s32 bottom_field_order_cnt;
> + __u8 ref_pic_list_p0[32];
> + __u8 ref_pic_list_b0[32];
> + __u8 ref_pic_list_b1[32];
> + struct v4l2_h264_dpb_entry dpb[16];
> +};
> +
> struct v4l2_ctrl_mpeg2_frame_hdr {
> __u32 slice_len;
> __u32 slice_pos;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 242a6bfa1440..4b4a1b25a0db 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -626,6 +626,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with start codes */
> #define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264 without start codes */
> #define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 MVC */
> +#define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H264 parsed slices */
> #define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263 */
> #define V4L2_PIX_FMT_MPEG1 v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1 ES */
> #define V4L2_PIX_FMT_MPEG2 v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2 ES */
> @@ -1589,6 +1590,11 @@ struct v4l2_ext_control {
> __u8 __user *p_u8;
> __u16 __user *p_u16;
> __u32 __user *p_u32;
> + struct v4l2_ctrl_h264_sps __user *p_h264_sps;
> + struct v4l2_ctrl_h264_pps __user *p_h264_pps;
> + struct v4l2_ctrl_h264_scaling_matrix __user *p_h264_scal_mtrx;
> + struct v4l2_ctrl_h264_slice_param __user *p_h264_slice_param;
> + struct v4l2_ctrl_h264_decode_param __user *p_h264_decode_param;
> struct v4l2_ctrl_mpeg2_frame_hdr __user *p_mpeg2_frame_hdr;
> void __user *ptr;
> };
> @@ -1635,6 +1641,11 @@ enum v4l2_ctrl_type {
> V4L2_CTRL_TYPE_U8 = 0x0100,
> V4L2_CTRL_TYPE_U16 = 0x0101,
> V4L2_CTRL_TYPE_U32 = 0x0102,
> + V4L2_CTRL_TYPE_H264_SPS = 0x0103,
> + V4L2_CTRL_TYPE_H264_PPS = 0x0104,
> + V4L2_CTRL_TYPE_H264_SCALING_MATRIX = 0x0105,
> + V4L2_CTRL_TYPE_H264_SLICE_PARAM = 0x0106,
> + V4L2_CTRL_TYPE_H264_DECODE_PARAM = 0x0107,
> V4L2_CTRL_TYPE_MPEG2_FRAME_HDR = 0x0109,
> };
>
>
Documentation is also missing, but I assume that will be added later in a separate
patch.
I *think* that the alignments of the structs are the same for all architectures,
but I would feel much happier if you can confirm that by testing this.
Regards,
Hans
^ permalink raw reply
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Nicolas Ferre @ 2018-06-15 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BY1PR02MB1114728E5FF0709137B4224FE77C0@BY1PR02MB1114.namprd02.prod.outlook.com>
On 15/06/2018 at 12:01, Ben Whitten wrote:
>> On 14/06/2018 at 10:51, Ben Whitten wrote:
>>> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
>>> ---
>>> arch/arm/boot/dts/Makefile | 3 +-
>>> arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
>>> arch/arm/boot/dts/at91-wb45n.dtsi | 169
>> ++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 237 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
>>> create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index 7e24249..1ee94ee 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
>>> at91sam9g25ek.dtb \
>>> at91sam9g35ek.dtb \
>>> at91sam9x25ek.dtb \
>>> - at91sam9x35ek.dtb
>>> + at91sam9x35ek.dtb \
>>> + at91-wb45n.dtb
>>> dtb-$(CONFIG_SOC_SAM_V7) += \
>>> at91-kizbox2.dtb \
>>> at91-nattis-2-natte-2.dtb \
>>> diff --git a/arch/arm/boot/dts/at91-wb45n.dts b/arch/arm/boot/dts/at91-
>> wb45n.dts
>>> new file mode 100644
>>> index 0000000..4e88815
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/at91-wb45n.dts
>>> @@ -0,0 +1,66 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * at91-wb45n.dts - Device Tree file for WB45NBT board
>>> + *
>>> + * Copyright (C) 2018 Laird
>>> + *
>>> +*/
>>> +/dts-v1/;
>>> +#include "at91-wb45n.dtsi"
>>> +
>>> +/ {
>>> + model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
>>> + compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5",
>> "atmel,at91sam9";
>>
>> "laird" prefix must be added to
>> Documentation/devicetree/bindings/vendor-prefixes.txt before using it:
>> you can do a little patch as a first patch of this series.
>> Otherwise it will trigger a warning message while running
>> scripts/checkpatch.pl on top of your patch.
>>
>>
>>> +
>>> + ahb {
>>> + apb {
>>> + watchdog at fffffe40 {
>>> + status = "okay";
>>> + };
>>> + };
>>> + };
>>> +
>>> + gpio_keys {
>>> + compatible = "gpio-keys";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + irqbtn at pb18 {
>>
>> I'm not sure that the @pb18 can be used like this. This address
>> extension must be used in a "reg" property in the node. dtc used with
>> warning switch on might trigger an error for this.
>>
>>> + label = "IRQBTN";
>>> + linux,code = <99>;
>>> + gpios = <&pioB 18 GPIO_ACTIVE_LOW>;
>>> + gpio-key,wakeup = <1>;
>>> + };
>>> + };
>>> +};
>>> +
>>> +&usb0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&mmc0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&spi0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&macb0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&dbgu {
>>> + status = "okay";
>>> +};
>>> +
>>> +&usart0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&usart3 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&i2c1 {
>>> + status = "okay";
>>> +};
>>> diff --git a/arch/arm/boot/dts/at91-wb45n.dtsi b/arch/arm/boot/dts/at91-
>> wb45n.dtsi
>>> new file mode 100644
>>> index 0000000..2fa58e2
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/at91-wb45n.dtsi
>>> @@ -0,0 +1,169 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * at91-wb45n.dtsi - Device Tree file for WB45NBT board
>>> + *
>>> + * Copyright (C) 2018 Laird
>>> + *
>>> + */
>>> +
>>> +#include "at91sam9g25.dtsi"
>>> +
>>> +/ {
>>> + model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
>>> + compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5",
>> "atmel,at91sam9";
>>> +
>>> + chosen {
>>> + bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs
>> rw";
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + memory {
>>> + reg = <0x20000000 0x4000000>;
>>> + };
>>> +
>>> + ahb {
>>> + apb {
>>> + shdwc at fffffe10 {
>>
>> I would advice you to take exactly the node name:
>> "shutdown-controller at fffffe10"; Anyway, it will go away after you use
>> the label notation as advised by Alexandre.
>>
>>> + atmel,wakeup-mode = "low";
>>> + };
>>> +
>>> + pinctrl at fffff400 {
>>> + usb2 {
>>> + pinctrl_board_usb2: usb2-board {
>>> + atmel,pins =
>>> + <AT91_PIOB 11
>> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB11 gpio
>> vbus sense, deglitch */
>>> + };
>>> + };
>>> + };
>>> +
>>> + rstc at fffffe00 {
>>> + compatible = "atmel,sama5d3-rstc";
>>> + };
>>
>> I don't think this node is needed.
>
> I dug through our old code reviews and found this message relating to testing
> reboot over several thousand times in our testbed:
> After the slow clock has been enabled on the reset controller via upstream
> changes, the dram disable access and power down code is causing the SAM9G25
> to hang occasionally on reboot. Using the simple reset function provided
> for SAMA5D3 instead.
>
> So it appears to be a workaround for a bug that existed ~2 years ago, may still be
> relevant as there haven't been many changes to the reset code in that time.
All right, I read too quickly and thought it was sama5d3... Your
feedback is interesting anyway. I'll store this for future reference and
investigation.
>>> +
>>> + };
>>> + };
>>> +
>>> + atheros {
>>> + compatible = "atheros,ath6kl";
>>> + atheros,board-id = "SD32";
>>> + };
>>> +};
>>> +
>>> +&slow_xtal {
>>> + clock-frequency = <32768>;
>>> +};
>>> +
>>> +&main_xtal {
>>> + clock-frequency = <12000000>;
>>> +};
>>> +
>>> +&ebi {
>>> + status = "okay";
>>> + nand_controller: nand-controller {
>>> + pinctrl-0 = <&pinctrl_nand_cs &pinctrl_nand_rb
>> &pinctrl_nand_oe_we>;
>>> + pinctrl-names = "default";
>>> + status = "okay";
>>> +
>>> + nand at 3 {
>>> + reg = <0x3 0x0 0x800000>;
>>> + rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
>>> + cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
>>> + nand-bus-width = <8>;
>>> + nand-ecc-mode = "hw";
>>> + nand-ecc-strength = <4>;
>>> + nand-ecc-step-size = <512>;
>>> + nand-on-flash-bbt;
>>> + label = "atmel_nand";
>>> +
>>> + partitions {
>>> + compatible = "fixed-partitions";
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> +
>>> + at91bootstrap at 0 {
>>> + label = "at91bs";
>>> + reg = <0x0 0x20000>;
>>> + };
>>> +
>>> + uboot at 20000 {
>>> + label = "u-boot";
>>> + reg = <0x20000 0x80000>;
>>> + };
>>> +
>>> + ubootenv at a0000 {
>>> + label = "u-boot-env";
>>> + reg = <0xa0000 0x20000>;
>>> + };
>>> +
>>> + ubootenv at c0000 {
>>> + label = "redund-env";
>>> + reg = <0xc0000 0x20000>;
>>> + };
>>> +
>>> + kernel-a at e0000 {
>>> + label = "kernel-a";
>>> + reg = <0xe0000 0x280000>;
>>> + };
>>> +
>>> + kernel-b at 360000 {
>>> + label = "kernel-b";
>>> + reg = <0x360000 0x280000>;
>>> + };
>>> +
>>> + rootfs-a at 5e0000 {
>>> + label = "rootfs-a";
>>> + reg = <0x5e0000 0x2600000>;
>>> + };
>>> +
>>> + rootfs-b at 2be0000 {
>>> + label = "rootfs-b";
>>> + reg = <0x2be0000 0x2600000>;
>>> + };
>>> +
>>> + user at 51e0000 {
>>> + label = "user";
>>> + reg = <0x51e0000 0x2dc0000>;
>>> + };
>>> +
>>> + logs at 7fa0000 {
>>> + label = "logs";
>>> + reg = <0x7fa0000 0x60000>;
>>> + };
>>> +
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> +&usb0 {
>>
>> This must be &usb1 label, isn't it?
>> Because you are referring to ohci binding I suspect (found by having a
>> look at: atmel,oc-gpio property...).
>
> I believe usb0 is correct, as this is a at91sam9x5 part, the node in dtsi is -ohci.
> sama5d3 is usb1 for -ohci.
All right, like previous comment, I thought it was sama5d3: sorry for
the noise.
Best regards,
Nicolas
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: add missing of_node_put()
From: Nicholas Mc Guire @ 2018-06-15 12:28 UTC (permalink / raw)
To: linux-arm-kernel
The call to of_find_compatible_node() returns a node pointer with refcount
incremented thus it must be explicitly decremented here after the last
usage. (see drivers/of/base.c:of_find_compatible_node())
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---
Problem located with an experimental coccinelle script
Patch was compile tested with: axm55xx_defconfig
(with some sparse warnings - not related to the proposed change though)
Patch is against 4.17.0 (localversion-next is next-20180614)
arch/arm/mach-axxia/platsmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-axxia/platsmp.c b/arch/arm/mach-axxia/platsmp.c
index 502e3df..c706a11 100644
--- a/arch/arm/mach-axxia/platsmp.c
+++ b/arch/arm/mach-axxia/platsmp.c
@@ -40,10 +40,11 @@ static int axxia_boot_secondary(unsigned int cpu, struct task_struct *idle)
syscon_np = of_find_compatible_node(NULL, NULL, "lsi,axxia-syscon");
if (!syscon_np)
return -ENOENT;
syscon = of_iomap(syscon_np, 0);
+ of_node_put(syscon_np);
if (!syscon)
return -ENOMEM;
tmp = readl(syscon + SC_RST_CPU_HOLD);
writel(0xab, syscon + SC_CRIT_WRITE_KEY);
--
2.1.4
^ permalink raw reply related
* [PATCH 0/3] arm64: kexec, kdump: fix boot failures on acpi-only system
From: Bhupesh Sharma @ 2018-06-15 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org>
Hi Akashi,
Thanks for the patchset - we have been waiting for quite some time for
this fix so that crashkernel can boot on arm64 machines which support
boot'ing via ACPI tables.
I have tested this on my huawei-taishan arm64 board, so:
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
BTW, if possible I would suggest to use:
Reported-by: Bhupesh Sharma <bhsharma@redhat.com>
rather than:
Reported-by: Bhupesh Sharma <bhupesh.linux@gmail.com>
Thanks,
Bhupesh
On Fri, Jun 15, 2018 at 1:26 PM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> # apologies for a bit late updates
>
> This patch series is a set of bug fixes to address kexec/kdump
> failures which are sometimes observed on ACPI-only system and reported
> in LAK-ML before.
>
> In short, the phenomena are:
> 1. kexec'ed kernel can fail to boot because some ACPI table is corrupted
> by a new kernel (or other data) being loaded into System RAM. Currently
> kexec may possibly allocate space ignoring such "reserved" regions.
> We will see no messages after "Bye!"
>
> 2. crash dump (kdump) kernel can fail to boot and get into panic due to
> an alignment fault when accessing ACPI tables. This can happen because
> those tables are not always properly aligned while they are mapped
> non-cacheable (ioremap'ed) as they are not recognized as part of System
> RAM under the current implementation.
>
> After discussing several possibilities to address those issues,
> the agreed approach, in my understanding, is
> * to add resource entries for every "reserved", i.e. memblock_reserve(),
> regions to /proc/iomem.
> (NOMAP regions, also marked as "reserved," remains at top-level for
> backward compatibility.)
> * For case (1), user space (kexec-tools) should rule out such regions
> in searching for free space for loaded data.
> * For case (2), the kernel should access ACPI tables by mapping
> them with appropriate memory attributes described in UEFI memory map.
> (This means that it doesn't require any changes in /proc/iomem, and
> hence user space.)
>
> Please find past discussions about /proc/iomem in [1].
>
> Patch#1 addresses kexec case, for which you are also required to update
> user space. See necessary patches in [2]. If you want to review Patch#1,
> please also take a look at and review [2].
>
> Patch#2 and #3 addresses kdump case. This is a revised version after
> Ard's comments.[3]
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/565980.html
> [2] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git arm64/resv_mem
> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573655.html
>
> AKASHI Takahiro (2):
> arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump
> init: map UEFI memory map early if on arm or arm64
>
> James Morse (1):
> arm64: export memblock_reserve()d regions via /proc/iomem
>
> arch/arm64/include/asm/acpi.h | 23 ++++++++++++------
> arch/arm64/kernel/acpi.c | 11 +++------
> arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++
> drivers/firmware/efi/arm-runtime.c | 27 ++++++++++-----------
> init/main.c | 3 +++
> 5 files changed, 72 insertions(+), 30 deletions(-)
>
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH 1/9] CHROMIUM: v4l: Add H264 low-level decoder API compound controls.
From: Guenter Roeck @ 2018-06-15 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c80de4e-c070-1051-2089-2d53826c6fc7@xs4all.nl>
On Fri, Jun 15, 2018 at 5:00 AM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 13/06/18 16:07, Maxime Ripard wrote:
> > From: Pawel Osciak <posciak@chromium.org>
>
> Obviously this needs a proper commit message.
>
> >
> > Signed-off-by: Pawel Osciak <posciak@chromium.org>
> > Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
> > Tested-by: Tomasz Figa <tfiga@chromium.org>
> > [rebase44(groeck): include linux/types.h in v4l2-controls.h]
That internal note should go away.
Guenter
^ permalink raw reply
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Sekhar Nori @ 2018-06-15 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615050108.GG112168@atomide.com>
Hi Tony,
On Friday 15 June 2018 10:31 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [180614 13:07]:
>> On 12:38-20180614, Tony Lindgren wrote:
>> From A53 view, a more accurate view might be - from an interconnect
>> view of the world (still simplified - i have ignored the sub bus
>> segments in the representations below):
>>
>> msmc {
>> navss_main {
>> cbass_main{
>> cbass_mcu {
>> navss_mcu {
>> };
>> cbass_wkup{
>> };
>> };
>> };
>> };
>> };
>>
>> From R5 view, the view will be very different ofcourse:
>> view of the world (still simplified):
>>
>> cbass_mcu {
>> navss_mcu {
>> };
>> cbass_wkup{
>> };
>> cbass_main{
>> navss_main {
>> msmc {
>> };
>> };
>> };
>> };
>
> Well if we follow the hardware representation of the interconnects,
> it should not matter from which processor view you're looking at things.
> There are just different ranges provided.
AFAIK, the root node needs to have the CPU which is using the DT. So,
the hierarchy will change based on CPU view (if we describe it fully).
How well we can reuse individual interconnect segments is something I
have to think about / experiment. Will have to be wary of any "short
paths" or "cross connections".
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 1/6] dt-bindings: add laird and giantec vendor prefix
From: Ben Whitten @ 2018-06-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
This adds a vendor prefix "laird" for Laird PLC who make
CPU modules and system on chips.
Also adds "giantec" for Giantec Semiconductor, Inc. who
make eeprom memory used on Laird designs.
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index a38d8bf..adf808c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -132,6 +132,7 @@ geekbuying GeekBuying
gef GE Fanuc Intelligent Platforms Embedded Systems, Inc.
GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc.
geniatech Geniatech, Inc.
+giantec Giantec Semiconductor, Inc.
giantplus Giantplus Technology Co., Ltd.
globalscale Globalscale Technologies, Inc.
gmt Global Mixed-mode Technology, Inc.
@@ -188,6 +189,7 @@ kingnovel Kingnovel Technology Co., Ltd.
kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
+laird Laird PLC
lantiq Lantiq Semiconductor
lattice Lattice Semiconductor
lego LEGO Systems A/S
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/6] arm: dts: at91: add labels to soc dtsi for derivative boards
From: Ben Whitten @ 2018-06-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529070055-18701-1-git-send-email-ben.whitten@lairdtech.com>
This adds labels to commonly used device-tree nodes so that derivative
boards can avoid ahb/apb hierarchy.
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/at91sam9x5.dtsi | 8 ++++----
arch/arm/boot/dts/sama5d3.dtsi | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index a3c3c31..11c0ef1 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -389,13 +389,13 @@
};
};
- rstc at fffffe00 {
+ reset_controller: rstc at fffffe00 {
compatible = "atmel,at91sam9g45-rstc";
reg = <0xfffffe00 0x10>;
clocks = <&clk32k>;
};
- shdwc at fffffe10 {
+ shutdown_controller: shdwc at fffffe10 {
compatible = "atmel,at91sam9x5-shdwc";
reg = <0xfffffe10 0x10>;
clocks = <&clk32k>;
@@ -470,7 +470,7 @@
clock-names = "dma_clk";
};
- pinctrl at fffff400 {
+ pinctrl: pinctrl at fffff400 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "atmel,at91sam9x5-pinctrl", "atmel,at91rm9200-pinctrl", "simple-bus";
@@ -1206,7 +1206,7 @@
};
};
- watchdog at fffffe40 {
+ watchdog: watchdog at fffffe40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffe40 0x10>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index eae5e1e..1408fa4 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -494,7 +494,7 @@
atmel,external-irqs = <47>;
};
- pinctrl at fffff200 {
+ pinctrl: pinctrl at fffff200 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "atmel,sama5d3-pinctrl", "atmel,at91sam9x5-pinctrl", "simple-bus";
@@ -1340,13 +1340,13 @@
};
};
- rstc at fffffe00 {
+ reset_controller: rstc at fffffe00 {
compatible = "atmel,sama5d3-rstc", "atmel,at91sam9g45-rstc";
reg = <0xfffffe00 0x10>;
clocks = <&clk32k>;
};
- shutdown-controller at fffffe10 {
+ shutdown_controller: shutdown-controller at fffffe10 {
compatible = "atmel,at91sam9x5-shdwc";
reg = <0xfffffe10 0x10>;
clocks = <&clk32k>;
@@ -1359,7 +1359,7 @@
clocks = <&mck>;
};
- watchdog at fffffe40 {
+ watchdog: watchdog at fffffe40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffe40 0x10>;
interrupts = <4 IRQ_TYPE_LEVEL_HIGH 7>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/6] arm: dts: add support for Laird WB45N cpu module and DVK
From: Ben Whitten @ 2018-06-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529070055-18701-1-git-send-email-ben.whitten@lairdtech.com>
This adds support for Lairds combo CPU module, featuring on board
Atheros wifi, CSR Bluetooth radio and, Atmel CPU.
https://www.lairdtech.com/products/wb45nbt
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-wb45n.dts | 64 +++++++++++++++
arch/arm/boot/dts/at91-wb45n.dtsi | 165 ++++++++++++++++++++++++++++++++++++++
3 files changed, 230 insertions(+)
create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e24249..04604d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -38,6 +38,7 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
at91-ariettag25.dtb \
at91-cosino_mega2560.dtb \
at91-kizboxmini.dtb \
+ at91-wb45n.dtb \
at91sam9g15ek.dtb \
at91sam9g25ek.dtb \
at91sam9g35ek.dtb \
diff --git a/arch/arm/boot/dts/at91-wb45n.dts b/arch/arm/boot/dts/at91-wb45n.dts
new file mode 100644
index 0000000..64ce150
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb45n.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb45n.dts - Device Tree file for WB45NBT board
+ *
+ * Copyright (C) 2018 Laird
+ *
+*/
+/dts-v1/;
+#include "at91-wb45n.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
+ compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5", "atmel,at91sam9";
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ irqbtn at 18 {
+ reg = <18>;
+ label = "IRQBTN";
+ linux,code = <99>;
+ gpios = <&pioB 18 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+ };
+};
+
+&watchdog {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&macb0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&usart0 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/at91-wb45n.dtsi b/arch/arm/boot/dts/at91-wb45n.dtsi
new file mode 100644
index 0000000..ebe61a2
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb45n.dtsi
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb45n.dtsi - Device Tree file for WB45NBT board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+#include "at91sam9g25.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
+ compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5", "atmel,at91sam9";
+
+ chosen {
+ bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs rw";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x4000000>;
+ };
+
+ atheros {
+ compatible = "atheros,ath6kl";
+ atheros,board-id = "SD32";
+ };
+};
+
+&reset_controller {
+ compatible = "atmel,sama5d3-rstc";
+};
+
+&shutdown_controller {
+ atmel,wakeup-mode = "low";
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&ebi {
+ status = "okay";
+ nand_controller: nand-controller {
+ pinctrl-0 = <&pinctrl_nand_cs &pinctrl_nand_rb &pinctrl_nand_oe_we>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ nand at 3 {
+ reg = <0x3 0x0 0x800000>;
+ rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap at 0 {
+ label = "at91bs";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "redund-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ kernel-a at e0000 {
+ label = "kernel-a";
+ reg = <0xe0000 0x280000>;
+ };
+
+ kernel-b at 360000 {
+ label = "kernel-b";
+ reg = <0x360000 0x280000>;
+ };
+
+ rootfs-a at 5e0000 {
+ label = "rootfs-a";
+ reg = <0x5e0000 0x2600000>;
+ };
+
+ rootfs-b at 2be0000 {
+ label = "rootfs-b";
+ reg = <0x2be0000 0x2600000>;
+ };
+
+ user at 51e0000 {
+ label = "user";
+ reg = <0x51e0000 0x2dc0000>;
+ };
+
+ logs at 7fa0000 {
+ label = "logs";
+ reg = <0x7fa0000 0x60000>;
+ };
+
+ };
+ };
+ };
+};
+
+&usb0 {
+ num-ports = <2>;
+ atmel,vbus-gpio = <
+ &pioB 12 GPIO_ACTIVE_HIGH
+ &pioA 31 GPIO_ACTIVE_HIGH
+ >;
+ atmel,oc-gpio = <&pioB 13 GPIO_ACTIVE_LOW>;
+};
+
+&macb0 {
+ phy-mode = "rmii";
+};
+
+&spi0 {
+ cs-gpios = <&pioA 14 0>, <&pioA 7 0>, <0>, <0>;
+};
+
+&usb2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_board_usb2>;
+ atmel,vbus-gpio = <&pioB 11 GPIO_ACTIVE_HIGH>;
+};
+
+&mmc0 {
+ pinctrl-0 = <
+ &pinctrl_mmc0_slot0_clk_cmd_dat0
+ &pinctrl_mmc0_slot0_dat1_3>;
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&pinctrl {
+ usb2 {
+ pinctrl_board_usb2: usb2-board {
+ atmel,pins =
+ <AT91_PIOB 11 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB11 gpio vbus sense, deglitch */
+ };
+ };
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/6] arm: dts: add support for Laird WB50N cpu module and DVK
From: Ben Whitten @ 2018-06-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529070055-18701-1-git-send-email-ben.whitten@lairdtech.com>
This adds support for Lairds CPU module, featuring Atheros wifi, CSR
Bluetooth and, Atmel SAMA5D3 CPU.
https://www.lairdtech.com/products/wb50nbt-wi-fi-bluetooth-module
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-wb50n.dts | 112 +++++++++++++++++++++
arch/arm/boot/dts/at91-wb50n.dtsi | 198 ++++++++++++++++++++++++++++++++++++++
3 files changed, 311 insertions(+)
create mode 100644 arch/arm/boot/dts/at91-wb50n.dts
create mode 100644 arch/arm/boot/dts/at91-wb50n.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 04604d2..07823be 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -52,6 +52,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
at91-tse850-3.dtb \
+ at91-wb50n.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/at91-wb50n.dts b/arch/arm/boot/dts/at91-wb50n.dts
new file mode 100644
index 0000000..8cecc70
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb50n.dts
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb50n.dts - Device Tree file for wb50n evaluation board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+/dts-v1/;
+#include "at91-wb50n.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
+ compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ btn0 at 10 {
+ reg = <10>;
+ label = "BTNESC";
+ linux,code = <1>; /* ESC button */
+ gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+
+ irqbtn at 31 {
+ reg = <31>;
+ label = "IRQBTN";
+ linux,code = <99>; /* SysReq button */
+ gpios = <&pioE 31 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led0 {
+ label = "wb50n:blue:led0";
+ gpios = <&pioA 12 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led1 {
+ label = "wb50n:green:led1";
+ gpios = <&pioA 24 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led2 {
+ label = "wb50n:red:led2";
+ gpios = <&pioA 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+};
+
+&watchdog {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+/* On BB40 this port is labeled UART1 */
+&usart0 {
+ status = "okay";
+};
+
+/* On BB40 this port is labeled UART0 */
+&usart1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+
+ spidev at 0 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <8000000>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-wb50n.dtsi b/arch/arm/boot/dts/at91-wb50n.dtsi
new file mode 100644
index 0000000..85692c8
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb50n.dtsi
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb50n.dtsi - Device Tree include file for wb50n cpu module
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
+ compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs rw";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x4000000>;
+ };
+};
+
+&pinctrl {
+ board {
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins = <AT91_PIOC 26 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PC26 GPIO with pullup deglitch */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins = <AT91_PIOB 13 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB13 GPIO with deglitch */
+ };
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&slow_osc {
+ atmel,osc-bypass;
+};
+
+&usart1_clk {
+ atmel,clk-output-range = <0 132000000>;
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ cd-gpios = <&pioC 26 GPIO_ACTIVE_LOW>;
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3>;
+ status = "okay";
+ atheros at 0 {
+ compatible = "atheros,ath6kl";
+ atheros,board-id = "SD32";
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&macb1 {
+ phy-mode = "rmii";
+};
+
+&dbgu {
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
+
+/* On BB40 this port is labeled UART1 */
+&usart0 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
+};
+
+/* On BB40 this port is labeled UART0 */
+&usart1 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ dtr-gpios = <&pioD 13 GPIO_ACTIVE_LOW>;
+ dsr-gpios = <&pioD 11 GPIO_ACTIVE_LOW>;
+ dcd-gpios = <&pioD 7 GPIO_ACTIVE_LOW>;
+ rng-gpios = <&pioD 8 GPIO_ACTIVE_LOW>;
+};
+
+/* USART3 is direct-connect to the Bluetooth UART on the radio SIP */
+&usart3 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
+ status = "okay";
+};
+
+&spi1 {
+ cs-gpios = <&pioC 25 0>, <0>, <0>, <0>;
+};
+
+&ebi {
+ pinctrl-0 = <&pinctrl_ebi_nand_addr>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&nand_controller {
+ status = "okay";
+
+ nand: nand at 3 {
+ reg = <0x3 0x0 0x2>;
+ atmel,rb = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap at 0 {
+ label = "at91bs";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "u-boot-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ kernel-a at e0000 {
+ label = "kernel-a";
+ reg = <0xe0000 0x500000>;
+ };
+
+ kernel-b at 5e0000 {
+ label = "kernel-b";
+ reg = <0x5e0000 0x500000>;
+ };
+
+ rootfs-a at ae0000 {
+ label = "rootfs-a";
+ reg = <0xae0000 0x3000000>;
+ };
+
+ rootfs-b at 3ae0000 {
+ label = "rootfs-b";
+ reg = <0x3ae0000 0x3000000>;
+ };
+
+ user at 6ae0000 {
+ label = "user";
+ reg = <0x6ae0000 0x14e0000>;
+ };
+ };
+ };
+};
+
+&usb0 {
+ atmel,vbus-gpio = <&pioB 13 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+};
+
+&usb1 {
+ num-ports = <3>;
+ atmel,vbus-gpio = <&pioA 2 GPIO_ACTIVE_LOW>;
+ atmel,oc-gpio = <&pioA 4 GPIO_ACTIVE_LOW>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/6] arm: dts: add support for Gatwick board based on WB50N
From: Ben Whitten @ 2018-06-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529070055-18701-1-git-send-email-ben.whitten@lairdtech.com>
Add support for the LoRa gateway from Laird, the RG1xx.
This board houses the WB50NBT CPU module along with a Semtech SX1301 based
concentrator card.
https://www.lairdtech.com/products/rg1xx-lora-gateway
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
# Conflicts:
# arch/arm/boot/dts/Makefile
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-gatwick.dts | 121 +++++++++++++++++++++++++++++++++++++
2 files changed, 122 insertions(+)
create mode 100644 arch/arm/boot/dts/at91-gatwick.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 07823be..214d5d9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -51,6 +51,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ at91-gatwick.dtb \
at91-tse850-3.dtb \
at91-wb50n.dtb \
sama5d31ek.dtb \
diff --git a/arch/arm/boot/dts/at91-gatwick.dts b/arch/arm/boot/dts/at91-gatwick.dts
new file mode 100644
index 0000000..5a81cab
--- /dev/null
+++ b/arch/arm/boot/dts/at91-gatwick.dts
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-gatwick.dts - Device Tree file for the Gatwick board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+/dts-v1/;
+#include "at91-wb50n.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Project Gatwick";
+ compatible = "laird,gatwick", "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_key_gpio>;
+
+ reset-button {
+ label = "Reset Button";
+ linux,code = <KEY_SETUP>;
+ gpios = <&pioE 31 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ethernet {
+ label = "gatwick:yellow:ethernet";
+ gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ wifi {
+ label = "gatwick:green:wifi";
+ gpios = <&pioA 28 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ ble {
+ label = "gatwick:blue:ble";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ lora {
+ label = "gatwick:orange:lora";
+ gpios = <&pioA 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ blank {
+ label = "gatwick:green:blank";
+ gpios = <&pioA 24 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ user {
+ label = "gatwick:yellow:user";
+ gpios = <&pioA 12 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+};
+
+&pinctrl {
+ board {
+ pinctrl_key_gpio: key_gpio_0 {
+ atmel,pins =
+ <AT91_PIOE 31 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PE31 GPIO with pullup deglitch */
+ };
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+/* FTDI USART */
+&usart0 {
+ status = "okay";
+};
+
+/* GPS USART */
+&usart1 {
+ pinctrl-0 = <&pinctrl_usart1>;
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+
+ spidev at 0 {
+ compatible = "semtech,sx1301";
+ reg = <0>;
+ spi-max-frequency = <8000000>;
+ };
+};
+
+&usb1 {
+ status = "okay";
+ /delete-property/atmel,oc-gpio;
+};
+
+&usb2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 6/6] arm: dts: add support for Laird SOM60 module and DVK boards
From: Ben Whitten @ 2018-06-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529070055-18701-1-git-send-email-ben.whitten@lairdtech.com>
This adds support for Lairds upcoming SOM module, featuring Marvell WiFi
and Bluetooth, 2Gb NAND / 1Gb LPDDR SDRAM, and an Atmel SAMA5D3 CPU.
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-dvk_som60.dts | 95 +++++++++++
arch/arm/boot/dts/at91-dvk_su60_somc.dtsi | 159 ++++++++++++++++++
arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi | 90 ++++++++++
arch/arm/boot/dts/at91-som60.dtsi | 231 ++++++++++++++++++++++++++
5 files changed, 576 insertions(+)
create mode 100644 arch/arm/boot/dts/at91-dvk_som60.dts
create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
create mode 100644 arch/arm/boot/dts/at91-som60.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 214d5d9..b0e164a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -51,6 +51,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d2_ptc_ek.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ at91-dvk_som60.dtb \
at91-gatwick.dtb \
at91-tse850-3.dtb \
at91-wb50n.dtb \
diff --git a/arch/arm/boot/dts/at91-dvk_som60.dts b/arch/arm/boot/dts/at91-dvk_som60.dts
new file mode 100644
index 0000000..ededd5b
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_som60.dts
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_som60.dts - Device Tree file for the DVK SOM60 board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+/dts-v1/;
+#include "at91-som60.dtsi"
+#include "at91-dvk_su60_somc.dtsi"
+#include "at91-dvk_su60_somc_lcm.dtsi"
+
+/ {
+ model = "Laird DVK SOM60";
+ compatible = "laird,dvk-som60", "laird,som60", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = &dbgu;
+ tick-timer = &pit;
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&usart1 {
+ status = "okay";
+};
+
+&usart2 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&pit {
+ status = "okay";
+};
+
+&adc0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&macb0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
new file mode 100644
index 0000000..bb86f17
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_su60_somc.dtsi - Device Tree file for the DVK SOM60 base board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+
+/ {
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck2_as_audio_mck>;
+
+ atmel,model = "wm8904 @ DVK-SOM60";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "okay";
+ };
+};
+
+&mmc0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ slot at 0 {
+ bus-width = <4>;
+ cd-gpios = <&pioE 31 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ /* spi0.0: 4M Flash Macronix MX25R4035FM1IL0 */
+ spi-flash at 0 {
+ compatible = "mxicy,mx25u4035", "jedec,spi-nor";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+};
+
+&ssc0 {
+ atmel,clk-from-rk-pin;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ wm8904: wm8904 at 1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck2>;
+ clock-names = "mclk";
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ eeprom at 87 {
+ compatible = "giantec,gt24c32a", "atmel,24c32";
+ reg = <87>;
+ pagesize = <32>;
+ };
+};
+
+&usart1 {
+ status = "okay";
+};
+
+&usart2 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&pit {
+ status = "okay";
+};
+
+&adc0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&macb0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 7 {
+ reg = <7>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_geth_int>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+};
+
+&macb1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 1 {
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eth_int>;
+ interrupt-parent = <&pioC>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
new file mode 100644
index 0000000..4b9176d
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_su60_somc_lcm.dtsi - Device Tree file for the DVK SOM60 LCD board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+
+/ {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&hlcdc_pwm 0 50000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
+ panel: panel {
+ compatible = "winstar,wf70gtiagdng0", "innolux,at070tn92", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <&vcc_lcd_reg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ panel_input: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&hlcdc_panel_output>;
+ };
+ };
+ };
+
+ vcc_lcd_reg: fixedregulator_lcd {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC LCM";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ status = "okay";
+ };
+};
+
+&pinctrl {
+ board {
+ pinctrl_lcd_ctp_int: lcd_ctp_int {
+ atmel,pins =
+ <AT91_PIOC 28 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ ft5426 at 56 {
+ compatible = "focaltech,ft5426", "edt,edt-ft5406";
+ reg = <56>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_ctp_int>;
+
+ interrupt-parent = <&pioC>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
+
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
+};
+
+&hlcdc {
+ status = "okay";
+
+ hlcdc-display-controller {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+
+ port at 0 {
+ hlcdc_panel_output: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91-som60.dtsi b/arch/arm/boot/dts/at91-som60.dtsi
new file mode 100644
index 0000000..6472fce
--- /dev/null
+++ b/arch/arm/boot/dts/at91-som60.dtsi
@@ -0,0 +1,231 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-som60.dtsi - Device Tree file for the SOM60 module
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+#include "sama5d36.dtsi"
+
+/ {
+ model = "Laird SOM60";
+ compatible = "laird,som60", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = &dbgu;
+ };
+
+ memory {
+ reg = <0x20000000 0x8000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+};
+
+&pinctrl {
+ board {
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOE 31 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_mmc0_en: mmc0_en {
+ atmel,pins =
+ <AT91_PIOE 30 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_nand0_wp: nand0_wp {
+ atmel,pins =
+ <AT91_PIOE 14 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_usb_vbus: usb_vbus {
+ atmel,pins =
+ <AT91_PIOE 20 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ /* Conflicts with USART2_SCK */
+ };
+
+ pinctrl_usart2_sck: usart2_sck {
+ atmel,pins =
+ <AT91_PIOE 20 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ /* Conflicts with USB_VBUS */
+ };
+
+ pinctrl_usb_oc: usb_oc {
+ atmel,pins =
+ <AT91_PIOE 15 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ /* Conflicts with USART3_SCK */
+ };
+
+ pinctrl_usart3_sck: usart3_sck {
+ atmel,pins =
+ <AT91_PIOE 15 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ /* Conflicts with USB_OC */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOC 14 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_geth_int: geth_int {
+ atmel,pins =
+ <AT91_PIOB 25 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ /* Conflicts with USART1_SCK */
+ };
+
+ pinctrl_usart1_sck: usart1_sck {
+ atmel,pins =
+ <AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ /* Conflicts with GETH_INT */
+ };
+
+ pinctrl_eth_int: eth_int {
+ atmel,pins =
+ <AT91_PIOC 10 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_pck2_as_audio_mck: pck2_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOC 15 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ };
+};
+
+&mmc0 {
+ slot at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+};
+
+&mmc1 {
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&spi0 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+};
+
+&usart0 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "okay";
+ pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
+};
+
+&usart1 {
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+};
+
+&usart2 {
+ pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rts_cts>;
+};
+
+&usart3 {
+ pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
+};
+
+&adc0 {
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ &pinctrl_adc0_ad5
+ >;
+};
+
+&macb0 {
+ phy-mode = "rgmii";
+};
+
+&macb1 {
+ phy-mode = "rmii";
+};
+
+
+&ebi {
+ pinctrl-0 = <&pinctrl_ebi_nand_addr>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&nand_controller {
+ status = "okay";
+
+ nand: nand at 3 {
+ reg = <0x3 0x0 0x2>;
+ atmel,rb = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ubootspl at 0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "u-boot-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ ubi at e0000 {
+ label = "ubi";
+ reg = <0xe0000 0xfe00000>;
+ };
+ };
+ };
+};
+
+&usb0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 14 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_vbus &pinctrl_usb_oc>;
+ num-ports = <3>;
+ atmel,vbus-gpio = <0
+ &pioE 20 GPIO_ACTIVE_HIGH
+ 0>;
+ atmel,oc-gpio = <0
+ &pioE 15 GPIO_ACTIVE_LOW
+ 0>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 6/7] mmc: sunxi: Add runtime_pm support
From: Kevin Hilman @ 2018-06-15 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFqc-+cr64DW0r_2V_vM=r45CuFrx5z4_fYf=sebb5EfQg@mail.gmail.com>
On Fri, Jun 15, 2018 at 1:56 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On 14 June 2018 at 16:11, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > Hi Maxime,
> >
> > On 16/04/18 15:23, Maxime Ripard wrote:
> >> So far, even if our card was not in use, we didn't shut down our MMC
> >> controller, which meant that it was still active and clocking the bus.
> >>
> >> While this obviously means that we could save some power there, it also
> >> creates issues when it comes to EMC control since we'll have a perfect peak
> >> at the card clock rate.
> >>
> >> Let's implement runtime_pm with autosuspend so that we will shut down the
> >> controller when it's not been in use for quite some time.
> >>
> >> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> >> ---
> >> drivers/mmc/host/sunxi-mmc.c | 48 +++++++++++++++++++++++++++++++++++++-
> >> 1 file changed, 48 insertions(+)
> >>
> >> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> >> index 0165da0d022a..0253deb153a4 100644
> >> --- a/drivers/mmc/host/sunxi-mmc.c
> >> +++ b/drivers/mmc/host/sunxi-mmc.c
> >> @@ -35,6 +35,7 @@
> >> #include <linux/of_gpio.h>
> >> #include <linux/of_platform.h>
> >> #include <linux/platform_device.h>
> >> +#include <linux/pm_runtime.h>
> >> #include <linux/regulator/consumer.h>
> >> #include <linux/reset.h>
> >> #include <linux/scatterlist.h>
> >> @@ -969,6 +970,9 @@ static void sunxi_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
> >> unsigned long flags;
> >> u32 imask;
> >>
> >> + if (enable)
> >> + pm_runtime_get_noresume(host->dev);
> >> +
> >> spin_lock_irqsave(&host->lock, flags);
> >>
> >> imask = mmc_readl(host, REG_IMASK);
> >> @@ -981,6 +985,9 @@ static void sunxi_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
> >> }
> >> mmc_writel(host, REG_IMASK, imask);
> >> spin_unlock_irqrestore(&host->lock, flags);
> >> +
> >> + if (!enable)
> >> + pm_runtime_put_noidle(host->mmc->parent);
> >> }
> >>
> >> static void sunxi_mmc_hw_reset(struct mmc_host *mmc)
> >> @@ -1394,6 +1401,11 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
> >> if (ret)
> >> goto error_free_dma;
> >>
> >> + pm_runtime_set_active(&pdev->dev);
> >> + pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> >> + pm_runtime_use_autosuspend(&pdev->dev);
> >> + pm_runtime_enable(&pdev->dev);
> >> +
> >> ret = mmc_add_host(mmc);
> >> if (ret)
> >> goto error_free_dma;
> >> @@ -1414,6 +1426,7 @@ static int sunxi_mmc_remove(struct platform_device *pdev)
> >> struct sunxi_mmc_host *host = mmc_priv(mmc);
> >>
> >> mmc_remove_host(mmc);
> >> + pm_runtime_force_suspend(&pdev->dev);
> >> disable_irq(host->irq);
> >> sunxi_mmc_disable(host);
> >> dma_free_coherent(&pdev->dev, PAGE_SIZE, host->sg_cpu, host->sg_dma);
> >> @@ -1422,10 +1435,45 @@ static int sunxi_mmc_remove(struct platform_device *pdev)
> >> return 0;
> >> }
> >>
> >> +static int sunxi_mmc_runtime_resume(struct device *dev)
> >> +{
> >> + struct mmc_host *mmc = dev_get_drvdata(dev);
> >> + struct sunxi_mmc_host *host = mmc_priv(mmc);
> >> + int ret;
> >> +
> >> + ret = sunxi_mmc_enable(host);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + sunxi_mmc_init_host(host);
> >> + sunxi_mmc_set_bus_width(host, mmc->ios.bus_width);
> >> + sunxi_mmc_set_clk(host, &mmc->ios);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int sunxi_mmc_runtime_suspend(struct device *dev)
> >> +{
> >> + struct mmc_host *mmc = dev_get_drvdata(dev);
> >> + struct sunxi_mmc_host *host = mmc_priv(mmc);
> >> +
> >> + sunxi_mmc_reset_host(host);
> >> + sunxi_mmc_disable(host);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static const struct dev_pm_ops sunxi_mmc_pm_ops = {
> >> + SET_RUNTIME_PM_OPS(sunxi_mmc_runtime_suspend,
> >> + sunxi_mmc_runtime_resume,
> >> + NULL)
> >> +};
> >> +
> >> static struct platform_driver sunxi_mmc_driver = {
> >> .driver = {
> >> .name = "sunxi-mmc",
> >> .of_match_table = of_match_ptr(sunxi_mmc_of_match),
> >> + .pm = &sunxi_mmc_pm_ops,
> >> },
> >> .probe = sunxi_mmc_probe,
> >> .remove = sunxi_mmc_remove,
> >>
> >
> > This patch has the unfortunate impact of killing my A20 system
> > (cubietruck), as of 9a8e1e8cc2c02c57c4e941651a8481a633506c91:
> >
> > [...]
> > [ 3.286649] NET: Registered protocol family 10
> > [ 3.291898] mmcblk0: p1
> > [ 3.295297] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> > [ 3.302773] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> > [ 3.305787] Segment Routing with IPv6
> > [ 3.312225] mip6: Mobile IPv6
> > [ 3.316166] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> > [ 3.316246] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> > [ 3.323721] ip6_gre: GRE over IPv6 tunneling driver
> > [ 3.333954] NET: Registered protocol family 17
> > [ 3.338837] 9pnet: Installing 9P2000 support
> > [ 3.343379] NET: Registered protocol family 37
> > [ 3.347885] Key type dns_resolver registered
> > [ 3.352214] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
> > [ 3.352217] openvswitch: Open vSwitch switching datapath
> > [ 3.352620] mpls_gso: MPLS GSO support
> > [ 3.367001] ThumbEE CPU extension supported.
> >
> > and that's where it stops. No message, just a hard lockup (I suppose
> > that both the CPUs are trying to access some device that is now not
> > clocked).
>
> Seems like a reasonable analyze.
>
> >
> > With a working kernel, I see SATA and the wifi SDIO being probed.
> >
> > Happy to help testing stuff if you have any idea.
>
> In principle I would start with avoiding having the sunxi-mmc driver
> to probe. Or bail out early in probe, whichever is the easiest for
> you.
>
> The point is, if the sunxi-mmc driver doesn't even enable its clock,
> it would be interesting to see if there are other that depends on it.
>
> One could also play with clk_disable_unused(), the
> late_initcall_sync(), which can be turned off with the module
> parameter "clk_ignore_unused".
I added clk_ignore_unused to the kernel command-line, and that didn't
help, so it's not just an init-time clock that's causing the problem.
> Anyway, to hide/fix the problem for now, we could add a call to
> pm_runtime_get_noresume() before the sunxi-driver calls
> pm_runtime_enable().
I tried that and it makes the kernel finish booting, so that smells
definitely like the MMC is disabling a clock when it goes idle that
some other device (or CPU) depends on.
Kevin
^ permalink raw reply
* [PATCH v3 6/7] mmc: sunxi: Add runtime_pm support
From: Maxime Ripard @ 2018-06-15 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOi56cX4B=meWmRJz=qvmpxooiWQ+fADRZ4pSd=iimTiWUdRAw@mail.gmail.com>
On Fri, Jun 15, 2018 at 07:45:03AM -0700, Kevin Hilman wrote:
> > >
> > > With a working kernel, I see SATA and the wifi SDIO being probed.
> > >
> > > Happy to help testing stuff if you have any idea.
> >
> > In principle I would start with avoiding having the sunxi-mmc driver
> > to probe. Or bail out early in probe, whichever is the easiest for
> > you.
> >
> > The point is, if the sunxi-mmc driver doesn't even enable its clock,
> > it would be interesting to see if there are other that depends on it.
> >
> > One could also play with clk_disable_unused(), the
> > late_initcall_sync(), which can be turned off with the module
> > parameter "clk_ignore_unused".
>
> I added clk_ignore_unused to the kernel command-line, and that didn't
> help, so it's not just an init-time clock that's causing the problem.
>
> > Anyway, to hide/fix the problem for now, we could add a call to
> > pm_runtime_get_noresume() before the sunxi-driver calls
> > pm_runtime_enable().
>
> I tried that and it makes the kernel finish booting, so that smells
> definitely like the MMC is disabling a clock when it goes idle that
> some other device (or CPU) depends on.
I quickly looked at the A10 and A20 clock driver and I have not seen
any obvious mishap.
If you have ftrace enabled, could you add the trace_clk_disable*
events (along with tp_printk since the kernel seems to break the
entire boot).
That will allow us to see which clock is disabled and shouldn't.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/9d42e687/attachment.sig>
^ permalink raw reply
* [PATCH v2] crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin,_end
From: Herbert Xu @ 2018-06-15 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528443704-26850-1-git-send-email-hejianet@gmail.com>
Jia He <hejianet@gmail.com> wrote:
> In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]:
> [ 7.019116] BUG: sleeping function called from invalid context at
> ./include/crypto/algapi.h:416
> [ 7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name:
> cryptomgr_test
> [ 7.035106] 1 lock held by cryptomgr_test/410:
> [ 7.039549] #0: (ptrval) (&drbg->drbg_mutex){+.+.}, at:
> drbg_instantiate+0x34/0x398
> [ 7.048038] CPU: 9 PID: 410 Comm: cryptomgr_test Not tainted
> 4.17.0-rc6+ #27
> [ 7.068228] dump_backtrace+0x0/0x1c0
> [ 7.071890] show_stack+0x24/0x30
> [ 7.075208] dump_stack+0xb0/0xec
> [ 7.078523] ___might_sleep+0x160/0x238
> [ 7.082360] skcipher_walk_done+0x118/0x2c8
> [ 7.086545] ctr_encrypt+0x98/0x130
> [ 7.090035] simd_skcipher_encrypt+0x68/0xc0
> [ 7.094304] drbg_kcapi_sym_ctr+0xd4/0x1f8
> [ 7.098400] drbg_ctr_update+0x98/0x330
> [ 7.102236] drbg_seed+0x1b8/0x2f0
> [ 7.105637] drbg_instantiate+0x2ac/0x398
> [ 7.109646] drbg_kcapi_seed+0xbc/0x188
> [ 7.113482] crypto_rng_reset+0x4c/0xb0
> [ 7.117319] alg_test_drbg+0xec/0x330
> [ 7.120981] alg_test.part.6+0x1c8/0x3c8
> [ 7.124903] alg_test+0x58/0xa0
> [ 7.128044] cryptomgr_test+0x50/0x58
> [ 7.131708] kthread+0x134/0x138
> [ 7.134936] ret_from_fork+0x10/0x1c
>
> Seems there is a bug in Ard Biesheuvel's commit.
> Fixes: 683381747270 ("crypto: arm64/aes-blk - move kernel mode neon
> en/disable into loop")
>
> [1] https://www.spinics.net/lists/linux-crypto/msg33103.html
>
> Signed-off-by: jia.he at hxt-semitech.com
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: <stable@vger.kernel.org> # 4.17
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 0/4] KVM: arm64: FPSIMD/SVE fixes for 4.17
From: Dave Martin @ 2018-06-15 15:47 UTC (permalink / raw)
To: linux-arm-kernel
This series contains fixes for some issues observed since the KVM arm64
pull request for 4.17.
It supersedes the previous v1 [1].
The first patch (from Mark Rutland) adds a straightforward helper to
modify particular bits in a system register conditionally. This is used
by patch 3 (though obviously it could be coded round and patch 1
dropped, if preferred).
See other patches for details of the individual fixes and changes from
the previous posting.
[1] [PATCH 0/4] KVM: arm64: FPSIMD/SVE fixes for 4.17
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/584107.html
Dave Martin (3):
KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
KVM: arm64/sve: Fix SVE trap restoration for non-current tasks
KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
Mark Rutland (1):
arm64: introduce sysreg_clear_set()
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/sysreg.h | 11 +++++++++++
arch/arm64/kvm/fpsimd.c | 36 +++++++++++++++++++++++++++---------
3 files changed, 39 insertions(+), 9 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v2 1/4] arm64: introduce sysreg_clear_set()
From: Dave Martin @ 2018-06-15 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529077646-2848-1-git-send-email-Dave.Martin@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
Currently we have a couple of helpers to manipulate bits in particular
sysregs:
* config_sctlr_el1(u32 clear, u32 set)
* change_cpacr(u64 val, u64 mask)
The parameters of these differ in naming convention, order, and size,
which is unfortunate. They also differ slightly in behaviour, as
change_cpacr() skips the sysreg write if the bits are unchanged, which
is a useful optimization when sysreg writes are expensive.
Before we gain more yet another sysreg manipulation function, let's
unify these with a common helper, providing a consistent order for
clear/set operands, and the write skipping behaviour from
change_cpacr(). Code will be migrated to the new helper in subsequent
patches.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/sysreg.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 6171178..a8f8481 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -728,6 +728,17 @@ asm(
asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
} while (0)
+/*
+ * Modify bits in a sysreg. Bits in the clear mask are zeroed, then bits in the
+ * set mask are set. Other bits are left as-is.
+ */
+#define sysreg_clear_set(sysreg, clear, set) do { \
+ u64 __scs_val = read_sysreg(sysreg); \
+ u64 __scs_new = (__scs_val & ~(u64)(clear)) | (set); \
+ if (__scs_new != __scs_val) \
+ write_sysreg(__scs_new, sysreg); \
+} while (0)
+
static inline void config_sctlr_el1(u32 clear, u32 set)
{
u32 val;
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/4] KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
From: Dave Martin @ 2018-06-15 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529077646-2848-1-git-send-email-Dave.Martin@arm.com>
Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
guest/host thrashing") introduces a specific helper
kvm_arch_vcpu_put_fp() for saving the vcpu FPSIMD state during
vcpu_put().
This function uses local_bh_disable()/_enable() to protect the
FPSIMD context manipulation from interruption by softirqs.
This approach is not correct, because vcpu_put() can be invoked
either from the KVM host vcpu thread (when exiting the vcpu run
loop), or via a preempt notifier. In the former case, only
preemption is disabled. In the latter case, the function is called
from inside __schedule(), which means that IRQs are disabled.
Use of local_bh_disable()/_enable() with IRQs disabled is considerd
an error, resulting in lockdep splats while running VMs if lockdep
is enabled.
This patch disables IRQs instead of attempting to disable softirqs,
avoiding the problem of calling local_bh_enable() with IRQs
disabled in the __schedule() path. This creates an additional
interrupt blackout during vcpu run loop exit, but this is the rare
case and the blackout latency is still less than that of
__schedule().
Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
Reported-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
Changes since v1:
Requested by Marc Zyngier:
* Disable IRQs unconditionally instead of attempting to conditionally
disable softirqs. This creates an additional interrupt blackout
during vcpu run loop exit. This is the rare case, and the blackout
latency is still less than that of __schedule().
---
arch/arm64/kvm/fpsimd.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index dc6ecfa..f9d0931 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -5,7 +5,7 @@
* Copyright 2018 Arm Limited
* Author: Dave Martin <Dave.Martin@arm.com>
*/
-#include <linux/bottom_half.h>
+#include <linux/irqflags.h>
#include <linux/sched.h>
#include <linux/thread_info.h>
#include <linux/kvm_host.h>
@@ -92,7 +92,9 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
*/
void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
{
- local_bh_disable();
+ unsigned long flags;
+
+ local_irq_save(flags);
update_thread_flag(TIF_SVE,
vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
@@ -106,5 +108,5 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
fpsimd_bind_task_to_cpu();
}
- local_bh_enable();
+ local_irq_restore(flags);
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 3/4] KVM: arm64/sve: Fix SVE trap restoration for non-current tasks
From: Dave Martin @ 2018-06-15 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529077646-2848-1-git-send-email-Dave.Martin@arm.com>
Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
guest/host thrashing") attempts to restore the configuration of
userspace SVE trapping via a call to fpsimd_bind_task_to_cpu(), but
the logic for determining when to do this is not correct.
The patch makes the errnoenous assumption that the only task that
may try to enter userspace with the currently loaded FPSIMD/SVE
register content is current. This may not be the case however: if
some other user task T is scheduled on the CPU during the execution
of the KVM run loop, and the vcpu does not try to use the registers
in the meantime, then T's state may be left there intact. If T
happens to be the next task to enter userspace on this CPU then the
hooks for reloading the register state and configuring traps will
be skipped.
(Also, current never has SVE state at this point anyway and should
always have the trap enabled, as a side-effect of the ioctl()
syscall needed to reach the KVM run loop in the first place.)
This patch instead restores the state of the EL0 trap from the
state observed at the most recent vcpu_load(), ensuring that the
trap is set correctly for the loaded context (if any).
Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/fpsimd.c | 24 ++++++++++++++++++++----
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index fda9a8c..fe8777b 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -306,6 +306,7 @@ struct kvm_vcpu_arch {
#define KVM_ARM64_FP_ENABLED (1 << 1) /* guest FP regs loaded */
#define KVM_ARM64_FP_HOST (1 << 2) /* host FP regs loaded */
#define KVM_ARM64_HOST_SVE_IN_USE (1 << 3) /* backup for host TIF_SVE */
+#define KVM_ARM64_HOST_SVE_ENABLED (1 << 4) /* SVE enabled for EL0 */
#define vcpu_gp_regs(v) (&(v)->arch.ctxt.gp_regs)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index f9d0931..98d19d1 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -12,6 +12,7 @@
#include <asm/kvm_asm.h>
#include <asm/kvm_host.h>
#include <asm/kvm_mmu.h>
+#include <asm/sysreg.h>
/*
* Called on entry to KVM_RUN unless this vcpu previously ran at least
@@ -61,10 +62,16 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
{
BUG_ON(!current->mm);
- vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_HOST_SVE_IN_USE);
+ vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED |
+ KVM_ARM64_HOST_SVE_IN_USE |
+ KVM_ARM64_HOST_SVE_ENABLED);
vcpu->arch.flags |= KVM_ARM64_FP_HOST;
+
if (test_thread_flag(TIF_SVE))
vcpu->arch.flags |= KVM_ARM64_HOST_SVE_IN_USE;
+
+ if (read_sysreg(cpacr_el1) & CPACR_EL1_ZEN_EL0EN)
+ vcpu->arch.flags |= KVM_ARM64_HOST_SVE_ENABLED;
}
/*
@@ -103,9 +110,18 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
/* Clean guest FP state to memory and invalidate cpu view */
fpsimd_save();
fpsimd_flush_cpu_state();
- } else if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
- /* Ensure user trap controls are correctly restored */
- fpsimd_bind_task_to_cpu();
+ } else if (system_supports_sve()) {
+ /*
+ * The FPSIMD/SVE state in the CPU has not been touched, and we
+ * have SVE (and VHE): CPACR_EL1 (alias CPTR_EL2) has been
+ * reset to CPACR_EL1_DEFAULT by the Hyp code, disabling SVE
+ * for EL0. To avoid spurious traps, restore the trap state
+ * seen by kvm_arch_vcpu_load_fp():
+ */
+ if (vcpu->arch.flags & KVM_ARM64_HOST_SVE_ENABLED)
+ sysreg_clear_set(CPACR_EL1, 0, CPACR_EL1_ZEN_EL0EN);
+ else
+ sysreg_clear_set(CPACR_EL1, CPACR_EL1_ZEN_EL0EN, 0);
}
local_irq_restore(flags);
--
2.1.4
^ permalink raw reply related
* [PATCH v2 4/4] KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
From: Dave Martin @ 2018-06-15 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529077646-2848-1-git-send-email-Dave.Martin@arm.com>
Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
guest/host thrashing") uses fpsimd_save() to save the FPSIMD state
for a vcpu when scheduling the vcpu out. However, currently
current's value of TIF_SVE is restored before calling fpsimd_save()
which means that fpsimd_save() may erroneously attempt to save SVE
state from the vcpu. This enables current's vector state to be
polluted with guest data. current->thread.sve_state may be
unallocated or not large enough, so this can also trigger a NULL
dereference or buffer overrun.
Instead of this, TIF_SVE should be configured properly for the
guest when calling fpsimd_save() with the vcpu context loaded.
This patch ensures this by delaying restoration of current's
TIF_SVE until after the call to fpsimd_save().
Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kvm/fpsimd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 98d19d1..aac7808 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -103,9 +103,6 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
local_irq_save(flags);
- update_thread_flag(TIF_SVE,
- vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
-
if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED) {
/* Clean guest FP state to memory and invalidate cpu view */
fpsimd_save();
@@ -124,5 +121,8 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
sysreg_clear_set(CPACR_EL1, CPACR_EL1_ZEN_EL0EN, 0);
}
+ update_thread_flag(TIF_SVE,
+ vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
+
local_irq_restore(flags);
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 0/4] KVM: arm64: FPSIMD/SVE fixes for 4.17
From: Dave Martin @ 2018-06-15 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529077646-2848-1-git-send-email-Dave.Martin@arm.com>
On Fri, Jun 15, 2018 at 04:47:22PM +0100, Dave Martin wrote:
> This series contains fixes for some issues observed since the KVM arm64
> pull request for 4.17.
Groan. Again, this should read "4.18". Apologies for the confusion!
Fixed locally in case I respin.
Cheers
---Dave
>
> It supersedes the previous v1 [1].
>
> The first patch (from Mark Rutland) adds a straightforward helper to
> modify particular bits in a system register conditionally. This is used
> by patch 3 (though obviously it could be coded round and patch 1
> dropped, if preferred).
>
> See other patches for details of the individual fixes and changes from
> the previous posting.
>
> [1] [PATCH 0/4] KVM: arm64: FPSIMD/SVE fixes for 4.17
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/584107.html
>
> Dave Martin (3):
> KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
> KVM: arm64/sve: Fix SVE trap restoration for non-current tasks
> KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
>
> Mark Rutland (1):
> arm64: introduce sysreg_clear_set()
>
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/arm64/include/asm/sysreg.h | 11 +++++++++++
> arch/arm64/kvm/fpsimd.c | 36 +++++++++++++++++++++++++++---------
> 3 files changed, 39 insertions(+), 9 deletions(-)
>
> --
> 2.1.4
>
>
> _______________________________________________
> 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 RESEND v4 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: James Morse @ 2018-06-15 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2455dc33-ae8d-79e6-e915-4181050e1e65@huawei.com>
Hi gengdongjiu,
On 12/06/18 16:48, gengdongjiu wrote:
> On 2018/6/12 23:29, James Morse wrote:
>> On 12/06/18 15:50, gengdongjiu wrote:
>>> On 2018/6/11 21:36, James Morse wrote:
>>>> On 08/06/18 20:48, Dongjiu Geng wrote:
>>>>> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
>>>>> index caae484..c3e6975 100644
>>>>> --- a/arch/arm/include/uapi/asm/kvm.h
>>>>> +++ b/arch/arm/include/uapi/asm/kvm.h
>>>>> @@ -124,6 +124,18 @@ struct kvm_sync_regs {
>>>>> struct kvm_arch_memory_slot {
>>>>> };
>>>>>
>>>>> +/* for KVM_GET/SET_VCPU_EVENTS */
>>>>> +struct kvm_vcpu_events {
>>>>> + struct {
>>>>> + __u8 serror_pending;
>>>>> + __u8 serror_has_esr;
>>>>> + /* Align it to 8 bytes */
>>>>> + __u8 pad[6];
>>>>> + __u64 serror_esr;
>>>>> + } exception;
>>>>> + __u32 reserved[12];
>>>>> +};
>>>>> +
>>>>
>>>> You haven't defined __KVM_HAVE_VCPU_EVENTS for 32bit, so presumably this struct
>>>> will never be used. Why is it here?
>>
>>> if not add it for 32 bits. the 32 arm platform will build Fail, whether you have good
>>> idea to avoid this Failure if not add this struct for the 32 bit?
>>
>> How does this 32bit code build without this patch?
>> If do you provide the struct, how will that code build with older headers?
>>
>> As far as I can see, this is what the __KVM_HAVE_VCPU_EVENTS define is for.
>>
>> This should be both, or neither. Having just the struct is useless.
> It because the caller of kvm_arm_vcpu_get/set_events() is in "virt/kvm/arm/arm.c".
> the virt/kvm/arm/arm.c will used by both arm64 and arm.
> so It needs to add kvm_arm_vcpu_get/set_events() for the 32 bits, however, kvm_arm_vcpu_get/set_events() will directly return,
So you are adding a uapi struct that user-space can't actually use, to avoid a
kernel build-error. Fine, it just looks really strange.
32bit user-space shouldn't try to call this as check-extension reports it as not
present. If it does, it gets -EINVAL back, which is also the default for
kvm_arch_vcpu_ioctl().
Thanks,
James
^ permalink raw reply
* [PATCH v2 1/4] arm64: introduce sysreg_clear_set()
From: Catalin Marinas @ 2018-06-15 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529077646-2848-2-git-send-email-Dave.Martin@arm.com>
On Fri, Jun 15, 2018 at 04:47:23PM +0100, Dave P Martin wrote:
> From: Mark Rutland <mark.rutland@arm.com>
>
> Currently we have a couple of helpers to manipulate bits in particular
> sysregs:
>
> * config_sctlr_el1(u32 clear, u32 set)
>
> * change_cpacr(u64 val, u64 mask)
>
> The parameters of these differ in naming convention, order, and size,
> which is unfortunate. They also differ slightly in behaviour, as
> change_cpacr() skips the sysreg write if the bits are unchanged, which
> is a useful optimization when sysreg writes are expensive.
>
> Before we gain more yet another sysreg manipulation function, let's
> unify these with a common helper, providing a consistent order for
> clear/set operands, and the write skipping behaviour from
> change_cpacr(). Code will be migrated to the new helper in subsequent
> patches.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
Since you are submitting this patch, it should have your signed-off-by
as well. Other than that:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 0/3] arm64: kexec,kdump: fix boot failures on acpi-only system
From: James Morse @ 2018-06-15 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org>
Hi Akashi,
Thanks for putting this together,
On 15/06/18 08:56, AKASHI Takahiro wrote:
> This patch series is a set of bug fixes to address kexec/kdump
> failures which are sometimes observed on ACPI-only system and reported
> in LAK-ML before.
>
> In short, the phenomena are:
> 1. kexec'ed kernel can fail to boot because some ACPI table is corrupted
> by a new kernel (or other data) being loaded into System RAM. Currently
> kexec may possibly allocate space ignoring such "reserved" regions.
> We will see no messages after "Bye!"
>
> 2. crash dump (kdump) kernel can fail to boot and get into panic due to
> an alignment fault when accessing ACPI tables. This can happen because
> those tables are not always properly aligned while they are mapped
> non-cacheable (ioremap'ed) as they are not recognized as part of System
> RAM under the current implementation.
>
> After discussing several possibilities to address those issues,
> the agreed approach, in my understanding, is
> * to add resource entries for every "reserved", i.e. memblock_reserve(),
> regions to /proc/iomem.
> (NOMAP regions, also marked as "reserved," remains at top-level for
> backward compatibility.)
This means user-space can tell the difference between reserved-system-ram and
reserved-address-space.
> * For case (1), user space (kexec-tools) should rule out such regions
> in searching for free space for loaded data.
... but doesn't today, because it fails to account for second-level entries.
We've always had second-level entries, so this is a user-space bug. We need both
fixed to fix the issue.
Our attempts to fix this just in the kernel reached a dead end, because Kdump
needs to include reserved-system-ram, whereas kexec has to avoid it. User-space
needs to be able to tell reserved-system-ram and reserved-address-space apart.
Hence we need to expose that information, and pick it up in user-space.
Patched-kernel and unpatch-user-space will work the same way it does today, as
the additional reserved regions are ignored by user-space.
Unpatched-kernel and patched-user-space will also work the same way it does
today as the additional reserved regions are missing.
I think this is the only way forwards on this issue...
> * For case (2), the kernel should access ACPI tables by mapping
> them with appropriate memory attributes described in UEFI memory map.
> (This means that it doesn't require any changes in /proc/iomem, and
> hence user space.)
(this one is handled entirely in the kernel)
Thanks,
James
^ 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