* [PATCH v3] coresight: tmc-etr: Fix perf_data check.
From: Yabin Cui @ 2019-08-15 18:46 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin
Cc: Yabin Cui, linux-kernel, linux-arm-kernel
When tracing etm data of multiple threads on multiple cpus through
perf interface, each cpu has a unique etr_perf_buffer while sharing
the same etr device. There is no guarantee that the last cpu starts
etm tracing also stops last. This makes perf_data check fail.
Fix it by checking etr_buf instead of etr_perf_buffer.
Also move the code setting and clearing perf_buf to more suitable
places.
Fixes: 3147da92a8a8 ("coresight: tmc-etr: Allocate and free ETR memory buffers for CPU-wide scenarios")
Signed-off-by: Yabin Cui <yabinc@google.com>
---
v2 -> v3:
moved place of setting drvdata->perf_buf based on review comment.
Also moved place of clearing drvdata->perf_buf from
tmc_update_etr_buffer() to tmc_disable_etr_sink() for below
situation:
cpu 0 enable etr device (set perf_buf)
cpu 0 update etr buffer (clear perf_buf)
cpu 1 enable etr device (perf_buf isn't set because pid set by cpu 0)
cpu 0 disable etr device
cpu 1 update etr buffer (perf_buf == NULL, check fails)
To fix it, we need to move clearing perf_buf to the disable function.
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 8 ++++----
drivers/hwtracing/coresight/coresight-tmc.h | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 17006705287a..80af313f55d7 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1484,7 +1484,7 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
goto out;
}
- if (WARN_ON(drvdata->perf_data != etr_perf)) {
+ if (WARN_ON(drvdata->perf_buf != etr_buf)) {
lost = true;
spin_unlock_irqrestore(&drvdata->spinlock, flags);
goto out;
@@ -1496,8 +1496,6 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
tmc_sync_etr_buf(drvdata);
CS_LOCK(drvdata->base);
- /* Reset perf specific data */
- drvdata->perf_data = NULL;
spin_unlock_irqrestore(&drvdata->spinlock, flags);
size = etr_buf->len;
@@ -1556,7 +1554,6 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
}
etr_perf->head = PERF_IDX2OFF(handle->head, etr_perf);
- drvdata->perf_data = etr_perf;
/*
* No HW configuration is needed if the sink is already in
@@ -1572,6 +1569,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
/* Associate with monitored process. */
drvdata->pid = pid;
drvdata->mode = CS_MODE_PERF;
+ drvdata->perf_buf = etr_perf->etr_buf;
atomic_inc(csdev->refcnt);
}
@@ -1617,6 +1615,8 @@ static int tmc_disable_etr_sink(struct coresight_device *csdev)
/* Dissociate from monitored process. */
drvdata->pid = -1;
drvdata->mode = CS_MODE_DISABLED;
+ /* Reset perf specific data */
+ drvdata->perf_buf = NULL;
spin_unlock_irqrestore(&drvdata->spinlock, flags);
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index 1ed50411cc3c..f9a0c95e9ba2 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -178,8 +178,8 @@ struct etr_buf {
* device configuration register (DEVID)
* @idr: Holds etr_bufs allocated for this ETR.
* @idr_mutex: Access serialisation for idr.
- * @perf_data: PERF buffer for ETR.
- * @sysfs_data: SYSFS buffer for ETR.
+ * @sysfs_buf: SYSFS buffer for ETR.
+ * @perf_buf: PERF buffer for ETR.
*/
struct tmc_drvdata {
void __iomem *base;
@@ -202,7 +202,7 @@ struct tmc_drvdata {
struct idr idr;
struct mutex idr_mutex;
struct etr_buf *sysfs_buf;
- void *perf_data;
+ struct etr_buf *perf_buf;
};
struct etr_buf_operations {
--
2.23.0.rc1.153.gdeed80330f-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v8 03/14] media: rkisp1: Add user space ABI definitions
From: Laurent Pinchart @ 2019-08-15 18:46 UTC (permalink / raw)
To: Helen Koike
Cc: devicetree, eddie.cai.linux, kernel, heiko, jacob2.chen,
jeffy.chen, zyc, linux-kernel, tfiga, linux-rockchip,
hans.verkuil, sakari.ailus, zhengsq, mchehab, ezequiel,
linux-arm-kernel, linux-media
In-Reply-To: <20190730184256.30338-4-helen.koike@collabora.com>
Hi Helen,
Thank you ofor the patch.
On Tue, Jul 30, 2019 at 03:42:45PM -0300, Helen Koike wrote:
> From: Jeffy Chen <jeffy.chen@rock-chips.com>
>
> Add the header for userspace
>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> [update for upstream]
> Signed-off-by: Helen Koike <helen.koike@collabora.com>
>
> ---
> Hi,
>
> I don't have the "REF_01 - ISP_user_manual, Rev 2.57" document that was
> mentioned in previous version, so I'm adding a TODO for now to improve
> the docs once we collect the information.
I would keep the document name in the TODO entry, for reference.
> If Rockchip people could help here it would be great.
As you don't have access to the documentation I won't focus on the
issues that you can't address, but in general I think we need more
documentation than what is provided here. In particular we need a
description of the pipeline, with the order of the processing blocks.
> Changes in v8: None
> Changes in v7:
> - Fix checkpatch errors (lines over 80 and SPDX)
> - Add TODO to improve docs
>
> include/uapi/linux/rkisp1-config.h | 816 +++++++++++++++++++++++++++++
> 1 file changed, 816 insertions(+)
> create mode 100644 include/uapi/linux/rkisp1-config.h
>
> diff --git a/include/uapi/linux/rkisp1-config.h b/include/uapi/linux/rkisp1-config.h
> new file mode 100644
> index 000000000000..9ab979bb4adb
> --- /dev/null
> +++ b/include/uapi/linux/rkisp1-config.h
> @@ -0,0 +1,816 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
> +/*
> + * Rockchip isp1 driver
Maybe "Rockchip ISP1 userspace API" ?
> + * Copyright (C) 2017 Rockchip Electronics Co., Ltd.
> + */
> +
> +/*
> + * TODO: Improve documentation, mostly regarding abbreviation and hardware
> + * specificities.
> + */
> +
> +#ifndef _UAPI_RKISP1_CONFIG_H
> +#define _UAPI_RKISP1_CONFIG_H
> +
> +#include <linux/types.h>
> +#include <linux/v4l2-controls.h>
Is v4l2-controls.h needed ?
> +
> +#define CIFISP_MODULE_DPCC (1 << 0)
> +#define CIFISP_MODULE_BLS (1 << 1)
> +#define CIFISP_MODULE_SDG (1 << 2)
> +#define CIFISP_MODULE_HST (1 << 3)
> +#define CIFISP_MODULE_LSC (1 << 4)
> +#define CIFISP_MODULE_AWB_GAIN (1 << 5)
> +#define CIFISP_MODULE_FLT (1 << 6)
> +#define CIFISP_MODULE_BDM (1 << 7)
> +#define CIFISP_MODULE_CTK (1 << 8)
> +#define CIFISP_MODULE_GOC (1 << 9)
> +#define CIFISP_MODULE_CPROC (1 << 10)
> +#define CIFISP_MODULE_AFC (1 << 11)
> +#define CIFISP_MODULE_AWB (1 << 12)
> +#define CIFISP_MODULE_IE (1 << 13)
> +#define CIFISP_MODULE_AEC (1 << 14)
> +#define CIFISP_MODULE_WDR (1 << 15)
> +#define CIFISP_MODULE_DPF (1 << 16)
> +#define CIFISP_MODULE_DPF_STRENGTH (1 << 17)
Should we use BIT() here ?
> +
> +#define CIFISP_CTK_COEFF_MAX 0x100
> +#define CIFISP_CTK_OFFSET_MAX 0x800
> +
> +#define CIFISP_AE_MEAN_MAX 25
> +#define CIFISP_HIST_BIN_N_MAX 16
> +#define CIFISP_AFM_MAX_WINDOWS 3
> +#define CIFISP_DEGAMMA_CURVE_SIZE 17
> +
> +#define CIFISP_BDM_MAX_TH 0xFF
Hex constants are usually expressed lower-case in the kernel.
> +
> +/*
> + * Black level compensation
> + */
> +/* maximum value for horizontal start address */
> +#define CIFISP_BLS_START_H_MAX 0x00000FFF
> +/* maximum value for horizontal stop address */
> +#define CIFISP_BLS_STOP_H_MAX 0x00000FFF
> +/* maximum value for vertical start address */
> +#define CIFISP_BLS_START_V_MAX 0x00000FFF
> +/* maximum value for vertical stop address */
> +#define CIFISP_BLS_STOP_V_MAX 0x00000FFF
> +/* maximum is 2^18 = 262144*/
> +#define CIFISP_BLS_SAMPLES_MAX 0x00000012
> +/* maximum value for fixed black level */
> +#define CIFISP_BLS_FIX_SUB_MAX 0x00000FFF
> +/* minimum value for fixed black level */
> +#define CIFISP_BLS_FIX_SUB_MIN 0xFFFFF000
> +/* 13 bit range (signed)*/
> +#define CIFISP_BLS_FIX_MASK 0x00001FFF
> +
> +/*
> + * Automatic white balance measurments
> + */
> +#define CIFISP_AWB_MAX_GRID 1
> +#define CIFISP_AWB_MAX_FRAMES 7
> +
> +/*
> + * Gamma out
> + */
> +/* Maximum number of color samples supported */
> +#define CIFISP_GAMMA_OUT_MAX_SAMPLES 17
> +
> +/*
> + * Lens shade correction
> + */
> +#define CIFISP_LSC_GRAD_TBL_SIZE 8
> +#define CIFISP_LSC_SIZE_TBL_SIZE 8
> +/*
> + * The following matches the tuning process,
> + * not the max capabilities of the chip.
> + * Last value unused.
> + */
> +#define CIFISP_LSC_DATA_TBL_SIZE 290
> +
> +/*
> + * Histogram calculation
> + */
> +/* Last 3 values unused. */
> +#define CIFISP_HISTOGRAM_WEIGHT_GRIDS_SIZE 28
> +
> +/*
> + * Defect Pixel Cluster Correction
> + */
> +#define CIFISP_DPCC_METHODS_MAX 3
> +
> +/*
> + * Denoising pre filter
> + */
> +#define CIFISP_DPF_MAX_NLF_COEFFS 17
> +#define CIFISP_DPF_MAX_SPATIAL_COEFFS 6
> +
> +/*
> + * Measurement types
> + */
> +#define CIFISP_STAT_AWB (1 << 0)
> +#define CIFISP_STAT_AUTOEXP (1 << 1)
> +#define CIFISP_STAT_AFM_FIN (1 << 2)
> +#define CIFISP_STAT_HIST (1 << 3)
> +
> +enum cifisp_histogram_mode {
> + CIFISP_HISTOGRAM_MODE_DISABLE,
> + CIFISP_HISTOGRAM_MODE_RGB_COMBINED,
> + CIFISP_HISTOGRAM_MODE_R_HISTOGRAM,
> + CIFISP_HISTOGRAM_MODE_G_HISTOGRAM,
> + CIFISP_HISTOGRAM_MODE_B_HISTOGRAM,
> + CIFISP_HISTOGRAM_MODE_Y_HISTOGRAM
> +};
> +
> +enum cifisp_awb_mode_type {
> + CIFISP_AWB_MODE_MANUAL,
> + CIFISP_AWB_MODE_RGB,
> + CIFISP_AWB_MODE_YCBCR
> +};
> +
> +enum cifisp_flt_mode {
> + CIFISP_FLT_STATIC_MODE,
> + CIFISP_FLT_DYNAMIC_MODE
> +};
> +
> +/**
> + * enum cifisp_exp_ctrl_autostop - stop modes
> + * @CIFISP_EXP_CTRL_AUTOSTOP_0: continuous measurement
> + * @CIFISP_EXP_CTRL_AUTOSTOP_1: stop measuring after a complete frame
> + */
> +enum cifisp_exp_ctrl_autostop {
> + CIFISP_EXP_CTRL_AUTOSTOP_0 = 0,
> + CIFISP_EXP_CTRL_AUTOSTOP_1 = 1,
> +};
> +
> +/**
> + * enum cifisp_exp_meas_mode - Exposure measure mode
> + * @CIFISP_EXP_MEASURING_MODE_0: Y = 16 + 0.25R + 0.5G + 0.1094B
> + * @CIFISP_EXP_MEASURING_MODE_1: Y = (R + G + B) x (85/256)
> + */
> +enum cifisp_exp_meas_mode {
> + CIFISP_EXP_MEASURING_MODE_0,
> + CIFISP_EXP_MEASURING_MODE_1,
> +};
> +
> +/*---------- PART1: Input Parameters ------------*/
> +
> +struct cifisp_window {
> + __u16 h_offs;
> + __u16 v_offs;
> + __u16 h_size;
> + __u16 v_size;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_bls_fixed_val - BLS fixed subtraction values
> + *
> + * The values will be subtracted from the sensor
> + * values. Therefore a negative value means addition instead of subtraction!
> + *
> + * @r: Fixed (signed!) subtraction value for Bayer pattern R
> + * @gr: Fixed (signed!) subtraction value for Bayer pattern Gr
> + * @gb: Fixed (signed!) subtraction value for Bayer pattern Gb
> + * @b: Fixed (signed!) subtraction value for Bayer pattern B
> + */
> +struct cifisp_bls_fixed_val {
> + __s16 r;
> + __s16 gr;
> + __s16 gb;
> + __s16 b;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_bls_config - Configuration used by black level subtraction
> + *
> + * @enable_auto: Automatic mode activated means that the measured values
> + * are subtracted. Otherwise the fixed subtraction
> + * values will be subtracted.
> + * @en_windows: enabled window
> + * @bls_window1: Measurement window 1 size
> + * @bls_window2: Measurement window 2 size
> + * @bls_samples: Set amount of measured pixels for each Bayer position
> + * (A, B,C and D) to 2^bls_samples.
> + * @cifisp_bls_fixed_val: Fixed subtraction values
> + */
> +struct cifisp_bls_config {
> + __u8 enable_auto;
> + __u8 en_windows;
> + struct cifisp_window bls_window1;
> + struct cifisp_window bls_window2;
> + __u8 bls_samples;
> + struct cifisp_bls_fixed_val fixed_val;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_dpcc_methods_config - Methods Configuration used by DPCC
> + *
> + * Methods Configuration used by Defect Pixel Cluster Correction
> + *
> + * @method: Method enable bits
> + * @line_thresh: Line threshold
> + * @line_mad_fac: Line MAD factor
> + * @pg_fac: Peak gradient factor
> + * @rnd_thresh: Rank Neighbor Difference threshold
> + * @rg_fac: Rank gradient factor
> + */
> +struct cifisp_dpcc_methods_config {
> + __u32 method;
> + __u32 line_thresh;
> + __u32 line_mad_fac;
> + __u32 pg_fac;
> + __u32 rnd_thresh;
> + __u32 rg_fac;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_dpcc_methods_config - Configuration used by DPCC
Should be cifisp_dpcc_config.
> + *
> + * Configuration used by Defect Pixel Cluster Correction
> + *
> + * @mode: dpcc output mode
> + * @output_mode: whether use hard coded methods
> + * @set_use: stage1 methods set
> + * @methods: methods config
> + * @ro_limits: rank order limits
> + * @rnd_offs: differential rank offsets for rank neighbor difference
> + */
> +struct cifisp_dpcc_config {
> + __u32 mode;
> + __u32 output_mode;
> + __u32 set_use;
> + struct cifisp_dpcc_methods_config methods[CIFISP_DPCC_METHODS_MAX];
> + __u32 ro_limits;
> + __u32 rnd_offs;
> +} __attribute__ ((packed));
> +
> +struct cifisp_gamma_corr_curve {
> + __u16 gamma_y[CIFISP_DEGAMMA_CURVE_SIZE];
> +} __attribute__ ((packed));
> +
> +struct cifisp_gamma_curve_x_axis_pnts {
> + __u32 gamma_dx0;
> + __u32 gamma_dx1;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_gamma_corr_curve - Configuration used by sensor degamma
Should be cifisp_sdg_config
> + *
> + * @curve_x: gamma curve point definition axis for x
> + * @xa_pnts: x increments
> + */
> +struct cifisp_sdg_config {
> + struct cifisp_gamma_corr_curve curve_r;
> + struct cifisp_gamma_corr_curve curve_g;
> + struct cifisp_gamma_corr_curve curve_b;
> + struct cifisp_gamma_curve_x_axis_pnts xa_pnts;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_lsc_config - Configuration used by Lens shading correction
> + *
> + * refer to REF_01 for details
> + */
> +struct cifisp_lsc_config {
> + __u32 r_data_tbl[CIFISP_LSC_DATA_TBL_SIZE];
> + __u32 gr_data_tbl[CIFISP_LSC_DATA_TBL_SIZE];
> + __u32 gb_data_tbl[CIFISP_LSC_DATA_TBL_SIZE];
> + __u32 b_data_tbl[CIFISP_LSC_DATA_TBL_SIZE];
> +
> + __u32 x_grad_tbl[CIFISP_LSC_GRAD_TBL_SIZE];
> + __u32 y_grad_tbl[CIFISP_LSC_GRAD_TBL_SIZE];
> +
> + __u32 x_size_tbl[CIFISP_LSC_SIZE_TBL_SIZE];
> + __u32 y_size_tbl[CIFISP_LSC_SIZE_TBL_SIZE];
> + __u16 config_width;
> + __u16 config_height;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_ie_config - Configuration used by image effects
> + *
> + * @eff_mat_1: 3x3 Matrix Coefficients for Emboss Effect 1
> + * @eff_mat_2: 3x3 Matrix Coefficients for Emboss Effect 2
> + * @eff_mat_3: 3x3 Matrix Coefficients for Emboss 3/Sketch 1
> + * @eff_mat_4: 3x3 Matrix Coefficients for Sketch Effect 2
> + * @eff_mat_5: 3x3 Matrix Coefficients for Sketch Effect 3
> + * @eff_tint: Chrominance increment values of tint (used for sepia effect)
> + */
> +struct cifisp_ie_config {
> + __u16 effect;
> + __u16 color_sel;
> + __u16 eff_mat_1;
> + __u16 eff_mat_2;
> + __u16 eff_mat_3;
> + __u16 eff_mat_4;
> + __u16 eff_mat_5;
> + __u16 eff_tint;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_cproc_config - Configuration used by Color Processing
> + *
> + * @c_out_range: Chrominance pixel clipping range at output.
> + * (0 for limit, 1 for full)
> + * @y_in_range: Luminance pixel clipping range at output.
> + * @y_out_range: Luminance pixel clipping range at output.
> + * @contrast: 00~ff, 0.0~1.992
> + * @brightness: 80~7F, -128~+127
> + * @sat: saturation, 00~FF, 0.0~1.992
> + * @hue: 80~7F, -90~+87.188
> + */
> +struct cifisp_cproc_config {
> + __u8 c_out_range;
> + __u8 y_in_range;
> + __u8 y_out_range;
> + __u8 contrast;
> + __u8 brightness;
> + __u8 sat;
> + __u8 hue;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_awb_meas_config - Configuration used by auto white balance
> + *
> + * @awb_wnd: white balance measurement window (in pixels)
> + * (from enum cifisp_awb_mode_type)
> + * @max_y: only pixels values < max_y contribute to awb measurement, set to 0
> + * to disable this feature
> + * @min_y: only pixels values > min_y contribute to awb measurement
> + * @max_csum: Chrominance sum maximum value, only consider pixels with Cb+Cr,
> + * smaller than threshold for awb measurements
> + * @min_c: Chrominance minimum value, only consider pixels with Cb/Cr
> + * each greater than threshold value for awb measurements
> + * @frames: number of frames - 1 used for mean value calculation
> + * (ucFrames=0 means 1 Frame)
> + * @awb_ref_cr: reference Cr value for AWB regulation, target for AWB
> + * @awb_ref_cb: reference Cb value for AWB regulation, target for AWB
> + */
> +struct cifisp_awb_meas_config {
> + /*
> + * Note: currently the h and v offsets are mapped to grid offsets
> + */
> + struct cifisp_window awb_wnd;
> + __u32 awb_mode;
> + __u8 max_y;
> + __u8 min_y;
> + __u8 max_csum;
> + __u8 min_c;
> + __u8 frames;
> + __u8 awb_ref_cr;
> + __u8 awb_ref_cb;
> + __u8 enable_ymax_cmp;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_awb_gain_config - Configuration used by auto white balance gain
> + *
> + * out_data_x = ( AWB_GEAIN_X * in_data + 128) >> 8
> + */
> +struct cifisp_awb_gain_config {
> + __u16 gain_red;
> + __u16 gain_green_r;
> + __u16 gain_blue;
> + __u16 gain_green_b;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_flt_config - Configuration used by ISP filtering
> + *
> + * @mode: ISP_FILT_MODE register fields (from enum cifisp_flt_mode)
> + * @grn_stage1: ISP_FILT_MODE register fields
> + * @chr_h_mode: ISP_FILT_MODE register fields
> + * @chr_v_mode: ISP_FILT_MODE register fields
> + *
> + * refer to REF_01 for details.
> + */
> +
> +struct cifisp_flt_config {
> + __u32 mode;
> + __u8 grn_stage1;
> + __u8 chr_h_mode;
> + __u8 chr_v_mode;
> + __u32 thresh_bl0;
> + __u32 thresh_bl1;
> + __u32 thresh_sh0;
> + __u32 thresh_sh1;
> + __u32 lum_weight;
> + __u32 fac_sh1;
> + __u32 fac_sh0;
> + __u32 fac_mid;
> + __u32 fac_bl0;
> + __u32 fac_bl1;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_bdm_config - Configuration used by Bayer DeMosaic
> + *
> + * @demosaic_th: threshod for bayer demosaicing texture detection
> + */
> +struct cifisp_bdm_config {
> + __u8 demosaic_th;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_ctk_config - Configuration used by Cross Talk correction
> + *
> + * @coeff: color correction matrix
> + * @ct_offset_b: offset for the crosstalk correction matrix
> + */
> +struct cifisp_ctk_config {
> + __u16 coeff0;
> + __u16 coeff1;
> + __u16 coeff2;
> + __u16 coeff3;
> + __u16 coeff4;
> + __u16 coeff5;
> + __u16 coeff6;
> + __u16 coeff7;
> + __u16 coeff8;
> + __u16 ct_offset_r;
> + __u16 ct_offset_g;
> + __u16 ct_offset_b;
> +} __attribute__ ((packed));
> +
> +enum cifisp_goc_mode {
> + CIFISP_GOC_MODE_LOGARITHMIC,
> + CIFISP_GOC_MODE_EQUIDISTANT
> +};
> +
> +/**
> + * struct cifisp_goc_config - Configuration used by Gamma Out correction
> + *
> + * @mode: goc mode (from enum cifisp_goc_mode)
> + * @gamma_y: gamma out curve y-axis for all color components
> + */
> +struct cifisp_goc_config {
> + __u32 mode;
> + __u16 gamma_y[CIFISP_GAMMA_OUT_MAX_SAMPLES];
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_hst_config - Configuration used by Histogram
> + *
> + * @mode: histogram mode (from enum cifisp_histogram_mode)
> + * @histogram_predivider: process every stepsize pixel, all other pixels are
> + * skipped
> + * @meas_window: coordinates of the measure window
> + * @hist_weight: weighting factor for sub-windows
> + */
> +struct cifisp_hst_config {
> + __u32 mode;
> + __u8 histogram_predivider;
> + struct cifisp_window meas_window;
> + __u8 hist_weight[CIFISP_HISTOGRAM_WEIGHT_GRIDS_SIZE];
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_aec_config - Configuration used by Auto Exposure Control
> + *
> + * @mode: Exposure measure mode (from enum cifisp_exp_meas_mode)
> + * @autostop: stop mode (from enum cifisp_exp_ctrl_autostop)
> + * @meas_window: coordinates of the measure window
> + */
> +struct cifisp_aec_config {
> + __u32 mode;
> + __u32 autostop;
> + struct cifisp_window meas_window;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_afc_config - Configuration used by Auto Focus Control
> + *
> + * @num_afm_win: max CIFISP_AFM_MAX_WINDOWS
> + * @afm_win: coordinates of the meas window
> + * @thres: threshold used for minimizing the influence of noise
> + * @var_shift: the number of bits for the shift operation at the end of the
> + * calculation chain.
> + */
> +struct cifisp_afc_config {
> + __u8 num_afm_win;
> + struct cifisp_window afm_win[CIFISP_AFM_MAX_WINDOWS];
> + __u32 thres;
> + __u32 var_shift;
> +} __attribute__ ((packed));
> +
> +/**
> + * enum cifisp_dpf_gain_usage - dpf gain usage
> + * @CIFISP_DPF_GAIN_USAGE_DISABLED: don't use any gains in preprocessing stage
> + * @CIFISP_DPF_GAIN_USAGE_NF_GAINS: use only the noise function gains from
> + * registers DPF_NF_GAIN_R, ...
> + * @CIFISP_DPF_GAIN_USAGE_LSC_GAINS: use only the gains from LSC module
> + * @CIFISP_DPF_GAIN_USAGE_NF_LSC_GAINS: use the noise function gains and the
> + * gains from LSC module
> + * @CIFISP_DPF_GAIN_USAGE_AWB_GAINS: use only the gains from AWB module
> + * @CIFISP_DPF_GAIN_USAGE_AWB_LSC_GAINS: use the gains from AWB and LSC module
> + * @CIFISP_DPF_GAIN_USAGE_MAX: upper border (only for an internal evaluation)
> + */
> +enum cifisp_dpf_gain_usage {
> + CIFISP_DPF_GAIN_USAGE_DISABLED,
> + CIFISP_DPF_GAIN_USAGE_NF_GAINS,
> + CIFISP_DPF_GAIN_USAGE_LSC_GAINS,
> + CIFISP_DPF_GAIN_USAGE_NF_LSC_GAINS,
> + CIFISP_DPF_GAIN_USAGE_AWB_GAINS,
> + CIFISP_DPF_GAIN_USAGE_AWB_LSC_GAINS,
> + CIFISP_DPF_GAIN_USAGE_MAX
> +};
> +
> +/**
> + * enum cifisp_dpf_gain_usage - dpf gain usage
This should be cifisp_dpf_rb_filtersize and the description should be
updated.
> + * @CIFISP_DPF_RB_FILTERSIZE_13x9: red and blue filter kernel size 13x9
> + * (means 7x5 active pixel)
> + * @CIFISP_DPF_RB_FILTERSIZE_9x9: red and blue filter kernel size 9x9
> + * (means 5x5 active pixel)
> + */
> +enum cifisp_dpf_rb_filtersize {
> + CIFISP_DPF_RB_FILTERSIZE_13x9,
> + CIFISP_DPF_RB_FILTERSIZE_9x9,
> +};
> +
> +/**
> + * enum cifisp_dpf_nll_scale_mode - dpf noise level scale mode
> + * @CIFISP_NLL_SCALE_LINEAR: use a linear scaling
> + * @CIFISP_NLL_SCALE_LOGARITHMIC: use a logarithmic scaling
> + */
> +enum cifisp_dpf_nll_scale_mode {
> + CIFISP_NLL_SCALE_LINEAR,
> + CIFISP_NLL_SCALE_LOGARITHMIC,
> +};
> +
> +/**
> + * struct cifisp_dpf_nll - Noise level lookup
> + *
> + * @coeff: Noise level Lookup coefficient
> + * @scale_mode: dpf noise level scale mode (from enum cifisp_dpf_nll_scale_mode)
> + */
> +struct cifisp_dpf_nll {
> + __u16 coeff[CIFISP_DPF_MAX_NLF_COEFFS];
> + __u32 scale_mode;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_dpf_rb_flt - Red blue filter config
> + *
> + * @fltsize: The filter size for the red and blue pixels
> + * (from enum cifisp_dpf_rb_filtersize)
> + * @spatial_coeff: Spatial weights
> + * @r_enable: enable filter processing for red pixels
> + * @b_enable: enable filter processing for blue pixels
> + */
> +struct cifisp_dpf_rb_flt {
> + __u32 fltsize;
> + __u8 spatial_coeff[CIFISP_DPF_MAX_SPATIAL_COEFFS];
> + __u8 r_enable;
> + __u8 b_enable;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_dpf_g_flt - Green filter Configuration
> + *
> + * @spatial_coeff: Spatial weights
> + * @gr_enable: enable filter processing for green pixels in green/red lines
> + * @gb_enable: enable filter processing for green pixels in green/blue lines
> + */
> +struct cifisp_dpf_g_flt {
> + __u8 spatial_coeff[CIFISP_DPF_MAX_SPATIAL_COEFFS];
> + __u8 gr_enable;
> + __u8 gb_enable;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_dpf_gain - Noise function Configuration
> + *
> + * @mode: dpf gain usage (from enum cifisp_dpf_gain_usage)
> + * @nf_r_gain: Noise function Gain that replaces the AWB gain for red pixels
> + * @nf_b_gain: Noise function Gain that replaces the AWB gain for blue pixels
> + * @nf_gr_gain: Noise function Gain that replaces the AWB gain
> + * for green pixels in a red line
> + * @nf_gb_gain: Noise function Gain that replaces the AWB gain
> + * for green pixels in a blue line
> + */
> +struct cifisp_dpf_gain {
> + __u32 mode;
> + __u16 nf_r_gain;
> + __u16 nf_b_gain;
> + __u16 nf_gr_gain;
> + __u16 nf_gb_gain;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_dpf_config - Configuration used by De-noising pre-filter
> + *
> + * @gain: noise function gain
> + * @g_flt: green filter config
> + * @rb_flt: red blue filter config
> + * @nll: noise level lookup
> + */
> +struct cifisp_dpf_config {
> + struct cifisp_dpf_gain gain;
> + struct cifisp_dpf_g_flt g_flt;
> + struct cifisp_dpf_rb_flt rb_flt;
> + struct cifisp_dpf_nll nll;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_dpf_strength_config - strength of the filter
> + *
> + * @r: filter strength of the RED filter
> + * @g: filter strength of the GREEN filter
> + * @b: filter strength of the BLUE filter
> + */
> +struct cifisp_dpf_strength_config {
> + __u8 r;
> + __u8 g;
> + __u8 b;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_isp_other_cfg - Parameters for some blocks in rockchip isp1
> + *
> + * @dpcc_config: Defect Pixel Cluster Correction config
> + * @bls_config: Black Level Subtraction config
> + * @sdg_config: sensor degamma config
> + * @lsc_config: Lens Shade config
> + * @awb_gain_config: Auto White balance gain config
> + * @flt_config: filter config
> + * @bdm_config: demosaic config
> + * @ctk_config: cross talk config
> + * @goc_config: gamma out config
> + * @bls_config: black level subtraction config
> + * @dpf_config: De-noising pre-filter config
> + * @dpf_strength_config: dpf strength config
> + * @cproc_config: color process config
> + * @ie_config: image effects config
> + */
> +struct cifisp_isp_other_cfg {
> + struct cifisp_dpcc_config dpcc_config;
> + struct cifisp_bls_config bls_config;
> + struct cifisp_sdg_config sdg_config;
> + struct cifisp_lsc_config lsc_config;
> + struct cifisp_awb_gain_config awb_gain_config;
> + struct cifisp_flt_config flt_config;
> + struct cifisp_bdm_config bdm_config;
> + struct cifisp_ctk_config ctk_config;
> + struct cifisp_goc_config goc_config;
> + struct cifisp_dpf_config dpf_config;
> + struct cifisp_dpf_strength_config dpf_strength_config;
> + struct cifisp_cproc_config cproc_config;
> + struct cifisp_ie_config ie_config;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_isp_meas_cfg - Rockchip ISP1 Measure Parameters
> + *
> + * @awb_meas_config: auto white balance config
> + * @hst_config: histogram config
> + * @aec_config: auto exposure config
> + * @afc_config: auto focus config
> + */
> +struct cifisp_isp_meas_cfg {
> + struct cifisp_awb_meas_config awb_meas_config;
> + struct cifisp_hst_config hst_config;
> + struct cifisp_aec_config aec_config;
> + struct cifisp_afc_config afc_config;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct rkisp1_isp_params_cfg - Rockchip ISP1 Input Parameters Meta Data
> + *
> + * @module_en_update: mask the enable bits of which module should be updated
> + * @module_ens: mask the enable value of each module, only update the module
> + * which correspond bit was set in module_en_update
> + * @module_cfg_update: mask the config bits of which module should be updated
> + * @meas: measurement config
> + * @others: other config
> + */
> +struct rkisp1_isp_params_cfg {
> + __u32 module_en_update;
> + __u32 module_ens;
> + __u32 module_cfg_update;
> +
> + struct cifisp_isp_meas_cfg meas;
> + struct cifisp_isp_other_cfg others;
> +} __attribute__ ((packed));
As far as I understand most (all ?) of the structures defined above are
not used directly by the hardware, is that right ? In that case, do they
need to be packed ?
Some of the structures have a _cfg suffix, while others have a _config
suffix. Should we standardise on one of the two ?
> +
> +/*---------- PART2: Measurement Statistics ------------*/
> +
> +/**
> + * struct cifisp_bls_meas_val - AWB measured values
This should be cifisp_awb_meas
> + *
> + * @cnt: White pixel count, number of "white pixels" found during laster
s/laster/last/ ?
> + * measurement
> + * @mean_y_or_g: Mean value of Y within window and frames,
> + * Green if RGB is selected.
> + * @mean_cb_or_b: Mean value of Cb within window and frames,
> + * Blue if RGB is selected.
> + * @mean_cr_or_r: Mean value of Cr within window and frames,
> + * Red if RGB is selected.
> + */
> +struct cifisp_awb_meas {
> + __u32 cnt;
> + __u8 mean_y_or_g;
> + __u8 mean_cb_or_b;
> + __u8 mean_cr_or_r;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_awb_stat - statistics automatic white balance data
> + *
> + * @awb_mean: Mean measured data
> + */
> +struct cifisp_awb_stat {
> + struct cifisp_awb_meas awb_mean[CIFISP_AWB_MAX_GRID];
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_bls_meas_val - BLS measured values
> + *
> + * @meas_r: Mean measured value for Bayer pattern R
> + * @meas_gr: Mean measured value for Bayer pattern Gr
> + * @meas_gb: Mean measured value for Bayer pattern Gb
> + * @meas_b: Mean measured value for Bayer pattern B
> + */
> +struct cifisp_bls_meas_val {
> + __u16 meas_r;
> + __u16 meas_gr;
> + __u16 meas_gb;
> + __u16 meas_b;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_ae_stat - statistics auto exposure data
> + *
> + * @exp_mean: Mean luminance value of block xx
> + * @bls_val: BLS measured values
> + *
> + * Image is divided into 5x5 blocks.
> + */
> +struct cifisp_ae_stat {
> + __u8 exp_mean[CIFISP_AE_MEAN_MAX];
> + struct cifisp_bls_meas_val bls_val;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_af_meas_val - AF measured values
> + *
> + * @sum: sharpness, refer to REF_01 for definition
> + * @lum: luminance, refer to REF_01 for definition
That will be lovely to use without documentation...
> + */
> +struct cifisp_af_meas_val {
> + __u32 sum;
> + __u32 lum;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_af_stat - statistics auto focus data
> + *
> + * @window: AF measured value of window x
> + *
> + * The module measures the sharpness in 3 windows of selectable size via
> + * register settings(ISP_AFM_*_A/B/C)
> + */
> +struct cifisp_af_stat {
> + struct cifisp_af_meas_val window[CIFISP_AFM_MAX_WINDOWS];
> +} __attribute__ ((packed));
> +
> +/**
> + * struct cifisp_hist_stat - statistics histogram data
> + *
> + * @hist_bins: measured bin counters
> + *
> + * Measurement window divided into 25 sub-windows, set
> + * with ISP_HIST_XXX
What is ISP_HIST_XXX ?
> + */
> +struct cifisp_hist_stat {
> + __u16 hist_bins[CIFISP_HIST_BIN_N_MAX];
> +} __attribute__ ((packed));
> +
> +/**
> + * struct rkisp1_stat_buffer - Rockchip ISP1 Statistics Data
> + *
> + * @cifisp_awb_stat: statistics data for automatic white balance
> + * @cifisp_ae_stat: statistics data for auto exposure
> + * @cifisp_af_stat: statistics data for auto focus
> + * @cifisp_hist_stat: statistics histogram data
> + */
> +struct cifisp_stat {
> + struct cifisp_awb_stat awb;
> + struct cifisp_ae_stat ae;
> + struct cifisp_af_stat af;
> + struct cifisp_hist_stat hist;
> +} __attribute__ ((packed));
> +
> +/**
> + * struct rkisp1_stat_buffer - Rockchip ISP1 Statistics Meta Data
> + *
> + * @meas_type: measurement types (CIFISP_STAT_ definitions)
> + * @frame_id: frame ID for sync
> + * @params: statistics data
> + */
> +struct rkisp1_stat_buffer {
> + __u32 meas_type;
> + __u32 frame_id;
> + struct cifisp_stat params;
> +} __attribute__ ((packed));
> +
> +#endif /* _UAPI_RKISP1_CONFIG_H */
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] drm+dma: cache support for arm, etc
From: Christoph Hellwig @ 2019-08-15 18:52 UTC (permalink / raw)
To: Koenig, Christian
Cc: Kate Stewart, Masayoshi Mizuma, Maciej W. Rozycki, Eric Biggers,
Catalin Marinas, Imre Deak, dri-devel, Chris Wilson,
Masahiro Yamada, Benjamin Gaignard, Mauro Carvalho Chehab,
Will Deacon, Christoph Hellwig, Emil Velikov, Rob Clark,
Michael Ellerman, Paul Burton, Mike Rapoport, Geert Uytterhoeven,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), Daniel Vetter,
open list:MIPS, Linus Walleij, Robin Murphy,
open list:DRM DRIVER FOR MSM ADRENO GPU, Sharma, Deepak,
Joerg Roedel, Arnd Bergmann, Anshuman Khandual, Hauke Mehrtens,
Jesper Dangaard Brouer, Wolfram Sang (Renesas),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Alexios Zavras,
Russell King, Doug Anderson, Thomas Gleixner, Sean Paul,
Allison Randal, Christophe Leroy, Ard Biesheuvel, Enrico Weigelt,
open list, Rob Clark, Souptick Joarder, Greg Kroah-Hartman,
Andrew Morton, open list:DRM DRIVER FOR MSM ADRENO GPU
In-Reply-To: <215e5cb7-0fcf-48db-a656-817054dde420@email.android.com>
On Thu, Aug 15, 2019 at 06:48:39PM +0000, Koenig, Christian wrote:
> Well, for the graphics case I absolutely need to keep the linear kernel mapping. Because for certain use cases the memory is accessed by the kernel all the time as well.
Then don't set DMA_ATTR_NO_KERNEL_MAPPING. At least for x86 and arm64
we should be able to support uncached allocations easily even without
that, and I plan to support that for your use case. But if the driver
is explicitly saying it doesn't want a permanent kernel mapping it makes
sense to (optionally if the architecture can easily do it) unmap the
memory from the kernel linear mapping.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 05/14] media: rkisp1: add Rockchip ISP1 subdev driver
From: Laurent Pinchart @ 2019-08-15 19:35 UTC (permalink / raw)
To: Hans Verkuil
Cc: devicetree, eddie.cai.linux, kernel, heiko, jacob2.chen,
jeffy.chen, zyc, linux-kernel, tfiga, Allon Huang, linux-rockchip,
Helen Koike, Jacob Chen, hans.verkuil, sakari.ailus, zhengsq,
mchehab, ezequiel, linux-arm-kernel, linux-media
In-Reply-To: <f229a840-bcf3-50c8-27c6-363c72de1d01@xs4all.nl>
Hi Hans,
On Wed, Aug 07, 2019 at 12:39:17PM +0200, Hans Verkuil wrote:
> On 8/6/19 8:51 PM, Helen Koike wrote:
> > On 7/30/19 3:42 PM, Helen Koike wrote:
> >> From: Jacob Chen <jacob2.chen@rock-chips.com>
> >>
> >> Add the subdev driver for rockchip isp1.
> >>
> >> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> >> Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
> >> Signed-off-by: Yichong Zhong <zyc@rock-chips.com>
> >> Signed-off-by: Jacob Chen <cc@rock-chips.com>
> >> Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
> >> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> >> Signed-off-by: Allon Huang <allon.huang@rock-chips.com>
> >> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
> >> [fixed unknown entity type / switched to PIXEL_RATE]
> >> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> >> [update for upstream]
> >> Signed-off-by: Helen Koike <helen.koike@collabora.com>
> >>
> >> ---
> >>
> >> Changes in v8: None
> >> Changes in v7:
> >> - fixed warning because of unknown entity type
> >> - fixed v4l2-compliance errors regarding rkisp1 formats, try formats
> >> and default values
> >> - fix typo riksp1/rkisp1
> >> - redesign: remove mipi/csi subdevice, sensors connect directly to the
> >> isp subdevice in the media topology now. As a consequence, remove the
> >> hack in mipidphy_g_mbus_config() where information from the sensor was
> >> being propagated through the topology.
> >> - From the old dphy:
> >> * cache get_remote_sensor() in s_stream
> >> * use V4L2_CID_PIXEL_RATE instead of V4L2_CID_LINK_FREQ
> >> - Replace stream state with a boolean
> >> - code styling and checkpatch fixes
> >> - fix stop_stream (return after calling stop, do not reenable the stream)
> >> - fix rkisp1_isp_sd_get_selection when V4L2_SUBDEV_FORMAT_TRY is set
> >> - fix get format in output (isp_sd->out_fmt.mbus_code was being ignored)
> >> - s/intput/input
> >> - remove #define sd_to_isp_sd(_sd), add a static inline as it will be
> >> reused by the capture
> >>
> >> drivers/media/platform/rockchip/isp1/rkisp1.c | 1286 +++++++++++++++++
> >> drivers/media/platform/rockchip/isp1/rkisp1.h | 111 ++
> >> 2 files changed, 1397 insertions(+)
> >> create mode 100644 drivers/media/platform/rockchip/isp1/rkisp1.c
> >> create mode 100644 drivers/media/platform/rockchip/isp1/rkisp1.h
> >>
> >> diff --git a/drivers/media/platform/rockchip/isp1/rkisp1.c b/drivers/media/platform/rockchip/isp1/rkisp1.c
> >> new file mode 100644
> >> index 000000000000..6d0c0ffb5e03
> >> --- /dev/null
> >> +++ b/drivers/media/platform/rockchip/isp1/rkisp1.c
> >> @@ -0,0 +1,1286 @@
>
> <snip>
>
> >> +static int rkisp1_isp_sd_get_fmt(struct v4l2_subdev *sd,
> >> + struct v4l2_subdev_pad_config *cfg,
> >> + struct v4l2_subdev_format *fmt)
> >> +{
> >> + struct rkisp1_isp_subdev *isp_sd = sd_to_isp_sd(sd);
> >> + struct v4l2_mbus_framefmt *mf = &fmt->format;
> >> +
> >> + if ((fmt->pad != RKISP1_ISP_PAD_SINK) &&
> >> + (fmt->pad != RKISP1_ISP_PAD_SOURCE_PATH)) {
> >> + fmt->format.code = MEDIA_BUS_FMT_FIXED;
> >> + /*
> >> + * NOTE: setting a format here doesn't make much sense
> >> + * but v4l2-compliance complains
> >> + */
> >> + fmt->format.width = RKISP1_DEFAULT_WIDTH;
> >> + fmt->format.height = RKISP1_DEFAULT_HEIGHT;
> >
> > As I had mentioned to you, this is called for the isp pads connected to the
> > DMA engines for statistics and parameters (meta data).
> >
> > If I remove those, I get the following errors:
> >
> > Sub-Device ioctls (Sink Pad 1):
> > test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
> > fail: v4l2-test-subdevs.cpp(311): fmt.width == 0 || fmt.width > 65536
> > fail: v4l2-test-subdevs.cpp(356): checkMBusFrameFmt(node, fmt.format)
> > test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
> > test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK
> > test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
> > fail: v4l2-test-subdevs.cpp(311): fmt.width == 0 || fmt.width > 65536
> > fail: v4l2-test-subdevs.cpp(356): checkMBusFrameFmt(node, fmt.format)
> > test Active VIDIOC_SUBDEV_G/S_FMT: FAIL
> > test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK
> > test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
> >
> > Here is the full log: http://ix.io/1QNt
> >
> > Is this a bug in v4l2-compliance?
>
> Yes and no :-)
>
> Currently v4l2-compliance assumes that only video is transferred over a media bus.
> But that's not the case here, and testing the code field doesn't help v4l2-compliance
> since MEDIA_BUS_FMT_FIXED is also still used by some older subdev drivers for video.
>
> I think we need a new bus format: MEDIA_BUS_FMT_FIXED_METADATA. Then v4l2-compliance
> can tell it apart from the regular fixed video bus format.
Wouldn't a pad flag that identifies the type of data transmitted by a
pad be a better, backward-compatible option ? This could be useful for
audio as well.
> If I do a 'git grep MEDIA_BUS_FMT_FIXED' then I see that it is also in use by vsp1
> for histogram information, so that should also be converted to use the new FIXED_METADATA
> format, although that might be too late (there might be userspace complications).
Yes, probably not a good idea.
> >> + fmt->format.field = V4L2_FIELD_NONE;
> >> + return 0;
> >> + }
> >> +
> >> + if (fmt->which == V4L2_SUBDEV_FORMAT_TRY) {
> >> + mf = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
> >> + fmt->format = *mf;
> >> + return 0;
> >> + }
> >> +
> >> + if (fmt->pad == RKISP1_ISP_PAD_SINK) {
> >> + *mf = isp_sd->in_frm;
> >> + } else if (fmt->pad == RKISP1_ISP_PAD_SOURCE_PATH) {
> >> + /* format of source pad */
> >> + *mf = isp_sd->in_frm;
> >> + mf->code = isp_sd->out_fmt.mbus_code;
> >> + /* window size of source pad */
> >> + mf->width = isp_sd->out_crop.width;
> >> + mf->height = isp_sd->out_crop.height;
> >> + mf->quantization = isp_sd->quantization;
> >> + }
> >> + mf->field = V4L2_FIELD_NONE;
> >> +
> >> + return 0;
> >> +}
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] clk: imx8m: Fix incorrect parents
From: Stephen Boyd @ 2019-08-15 19:36 UTC (permalink / raw)
To: Abel Vesa, Jacky Bai, Leonard Crestez, Shawn Guo
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <cover.1565715590.git.leonard.crestez@nxp.com>
Quoting Leonard Crestez (2019-08-13 10:05:27)
> No checks are made to ensure the parents in the _sels arrays actually
> exist and it turns out that several are incorrect.
>
> I found the errors using a hack to clk core, is there a better way?
> Link: https://github.com/cdleonard/linux/commit/da32c2e76eb373e8a03aec905af2eef28a7997a7
Maybe you can make it into some sort of Kconfig option that's behind a
debug flag. Or you can use the possible parent debugfs files and check
for parents from userspace with some script.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/14] ARM: move lpc32xx and dove to multiplatform
From: Arnd Bergmann @ 2019-08-15 19:38 UTC (permalink / raw)
To: Sylvain Lemieux
Cc: Andrew Lunn, LINUXWATCHDOG, Jason Cooper, David S. Miller,
Greg Kroah-Hartman, Gregory Clement, USB list,
Russell King - ARM Linux admin, Vladimir Zapolskiy,
open list:GPIO SUBSYSTEM, SoC Team, Alan Stern, Guenter Roeck,
linux-serial, Networking, Linus Walleij, Linux ARM,
Sebastian Hesselbarth
In-Reply-To: <b43c3d60-b675-442c-c549-25530cfbffe3@gmail.com>
On Thu, Aug 15, 2019 at 8:32 PM Sylvain Lemieux <slemieux.tyco@gmail.com> wrote:
> On 8/15/19 9:11 AM, Arnd Bergmann wrote:
> > On Thu, Aug 1, 2019 at 9:33 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > I applied patches 12 and 13 into the soc tree now. There are some
> > other pending multiplatform conversions (iop32x, ep93xx, lpc32xx,
> > omap1), but it looks like none of those will be complete for 5.4.
>
> I think the patchset (v2) for the LPC32xx is ready for 5.4
> ([PATCH v2 00/13] v2: ARM: move lpc32xx to multiplatform)
Good point. I've merged these into the arm/soc branch now.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 04/22] media: Move v4l2_fwnode_parse_link from v4l2 to driver base
From: Steve Longerbeam @ 2019-08-15 19:56 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Laurent Pinchart, Shawn Guo, Fabio Estevam,
open list:STAGING SUBSYSTEM, Mauro Carvalho Chehab, Michal Simek,
open list:ACPI, Andy Shevchenko, NXP Linux Team, Len Brown,
Philipp Zabel, Sascha Hauer, Thomas Gleixner, Andy Shevchenko,
moderated list:ARM/ZYNQ ARCHITECTURE, Hyun Kwon,
Greg Kroah-Hartman, open list, Jacopo Mondi,
Pengutronix Kernel Team, Hans Verkuil, Linux Media Mailing List,
Enrico Weigelt
In-Reply-To: <20190814231509.GK13294@shell.armlinux.org.uk>
On 8/14/19 4:15 PM, Russell King - ARM Linux admin wrote:
> On Wed, Aug 14, 2019 at 04:00:30PM -0700, Steve Longerbeam wrote:
>>
>> On 8/14/19 3:04 PM, Russell King - ARM Linux admin wrote:
>>> On Wed, Aug 14, 2019 at 12:04:41PM -0700, Steve Longerbeam wrote:
>>>> On 8/14/19 3:30 AM, Russell King - ARM Linux admin wrote:
>>>>> On Tue, Aug 06, 2019 at 09:53:41AM -0700, Steve Longerbeam wrote:
>>>>>> The full patchset doesn't seem to be up yet, but see [1] for the cover
>>>>>> letter.
>>>>> Was the entire series copied to the mailing lists, or just selected
>>>>> patches? I only saw 4, 9, 11 and 13-22 via lakml.
>>>> The whole series was posted to the linux-media ML, see [1]. At the time,
>>>> none of the linux-media ML archives had the whole series.
>>>>
>>>>> In the absence of the other patches, will this solve imx-media binding
>>>>> the internal subdevs of sensor devices to the CSI2 interface?
>>>> "internal subdevs of sensor devices" ?? That doesn't make any sense.
>>> Sorry, but it makes complete sense when you consider that sensor
>>> devices may have more than one subdev, but there should be only one
>>> that is the "output" to whatever the camera is attached to. The
>>> other subdevs are internal to the sensor.
>> Ah, thanks for the clarification. Yes, by "internal subdevs" I understand
>> what you mean now. The adv748x and smiapp are examples.
>>
>>> subdevs are not purely the remit of SoC drivers.
>> So there is no binding of internal subdevs to the receiver CSI-2. The
>> receiver CSI-2 subdev will create media links to the subdev that has an
>> externally exposed fwnode endpoint that connects with the CSI-2 sink pad.
> Maybe - with 5.2, I get:
>
> - entity 15: imx6-mipi-csi2 (5 pads, 6 links)
> type V4L2 subdev subtype Unknown flags 0
> device node name /dev/v4l-subdev2
> pad0: Sink
> ...
> <- "imx219 0-0010":0 []
> <- "imx219 pixel 0-0010":0 []
>
> Adding some debug in gives:
>
> [ 11.963362] imx-media: imx_media_create_of_links() for imx6-mipi-csi2
> [ 11.963396] imx-media: create_of_link(): /soc/aips-bus@2000000/iomuxc-gpr@20e0000/ipu1_csi0_mux
> [ 11.963422] imx-media: create_of_link(): /soc/ipu@2400000
> [ 11.963450] imx-media: create_of_link(): /soc/ipu@2800000
> [ 11.963478] imx-media: create_of_link(): /soc/aips-bus@2000000/iomuxc-gpr@20e0000/ipu2_csi1_mux
> [ 11.963489] imx-media: imx6-mipi-csi2:4 -> ipu2_csi1_mux:0
> [ 11.963522] imx-media: create_of_link(): /soc/aips-bus@2100000/i2c@21a0000/camera@10
> [ 11.963533] imx-media: imx219 0-0010:0 -> imx6-mipi-csi2:0
> [ 11.963549] imx-media: imx_media_create_of_links() for imx219 pixel 0-0010
> [ 11.963577] imx-media: create_of_link(): /soc/aips-bus@2100000/mipi@21dc000
> [ 11.963587] imx-media: imx219 pixel 0-0010:0 -> imx6-mipi-csi2:0
> [ 11.963602] imx-media: imx_media_create_of_links() for imx219 0-0010
>
> Note that it's not created by imx6-mipi-csi2, but by imx-media delving
> around in the imx219 subdevs.
>
> From what I can see, smiapp does the same thing that I do in imx219 -
> sets the subdev->dev member to point at the struct device, which then
> means that v4l2_device_register_subdev() will associate the same fwnode
> with both "imx219 pixel 0-0010" and "imx219 0-0010".
Ok, understood.
I realize imx_media_create_of_link() is a bit intrusive, and that's one
of the things I'm trying to get rid of in this patchset. Unfortunately
it's there for a reason which is described in patch 0021. But to explain
here, the imx6-mipi-csi2 receiver outputs its four virtual channels on
four separate source pads, and those connect to four different
subdevices (video mux's and CSI's), and the problem is that only the
first subdev that adds imx6-mipi-csi2 to its notifier asd list will get
a notifier bind() callback (where links can be created to
imx6-mipi-csi2) -- the other subdevs don't contain it in their asd lists
so they never create the links to imx6-mipi-csi2. So until the
requirement in v4l2-async that no notifiers can contain the same asd in
its list is relaxed, this function will have to remain, but I can make
it less intrusive (only create the missing links from imx6-mipi-csi2).
I'm not able to find a cleaner workaround at the moment.
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 0/8] arm64: MMU enabled kexec relocation
From: Pavel Tatashin @ 2019-08-15 20:09 UTC (permalink / raw)
To: James Morse
Cc: Sasha Levin, Vladimir Murzin, Jonathan Corbet, Marc Zyngier,
Catalin Marinas, Bhupesh Sharma, kexec mailing list, LKML,
James Morris, linux-mm, Eric W. Biederman, Matthias Brugger, will,
Linux ARM
In-Reply-To: <ba8a2519-ed95-2518-d0e8-66e8e0c14ff5@arm.com>
Hi James,
Thank you for your feedback. My replies below:
> > Also, I'd appreciate if anyone could test this series on vhe hardware
> > with vhe kernel, it does not look like QEMU can emulate it yet
>
> This locks up during resume from hibernate on my AMD Seattle, a regular v8.0 machine.
Thanks for reporting a bug I will root cause and fix it.
> Please try and build the series to reduce review time. What you have here is an all-new
> page-table generation API, which you switch hibernate and kexec too. This is effectively a
> new implementation of hibernate and kexec. There are three things here that need review.
>
> You have a regression in your all-new implementation of hibernate. It took six months (and
> lots of review) to get the existing code right, please don't rip it out if there is
> nothing wrong with it.
> Instead, please just move the hibernate copy_page_tables() code, and then wire kexec up.
> You shouldn't need to change anything in the copy_page_tables() code as the linear map is
> the same in both cases.
It is not really an all-new implementation of hibernate (for kexec it
is true though). I used the current implementation of hibernate as
bases, and simply generalized the functions by providing a flexible
interface. So what you are asking is actually exactly what I am doing.
I realize, that I introduced a bug that I will fix.
> It looks like you are creating the page tables just after the kexec:segments have been
> loaded. This will go horribly wrong if anything changes between then and kexec time. (e.g.
> memory you've got mapped gets hot-removed).
> This needs to be done as late as possible, so we don't waste memory, and the world can't
> change around us. Reboot notifiers run before kexec, can't we do the memory-allocation there?
Kexec by design does not allow allocate during kexec time. This is
because we cannot fail during kexec syscall. All allocations must be
done during kexec load time. Kernel memory cannot be hot-removed, as
it is not part of ZONE_MOVABLE, and cannot be migrated.
The current implementation relies on this assumption as well: during
load time the (struct kimage) -> head contains the physical addresses
of sources and destinations. If sources can be moved, this array will
be broken.
> >> Previously:
> >> kernel shutdown 0.022131328s
> >> relocation 0.440510736s
> >> kernel startup 0.294706768s
> >>
> >> Relocation was taking: 58.2% of reboot time
> >>
> >> Now:
> >> kernel shutdown 0.032066576s
> >> relocation 0.022158152s
> >> kernel startup 0.296055880s
> >>
> >> Now: Relocation takes 6.3% of reboot time
> >>
> >> Total reboot is x2.16 times faster.
>
> When I first saw these numbers they were ~'0.29s', which I wrongly assumed was 29 seconds.
> Savings in milliseconds, for _reboot_ is a hard sell. I'm hoping that on the machines that
> take minutes to kexec we'll get numbers that make this change more convincing.
Sure, this userland is very small kernel+userland is only 47M. Here is
another data point: fitImage: 380M, it contains a larger userland.
The numbers for kernel shutdown and startup are the same as this is
the same kernel, but relocation takes: 3.58s
shutdown: 0.02s
relocation: 3.58s
startup: 0.30s
Relocation take 88% of reboot time. And, we must have it under one second.
Thank you,
Pasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Mathieu Poirier @ 2019-08-15 20:16 UTC (permalink / raw)
To: Lubashev, Igor
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov,
Arnaldo Carvalho de Melo, Linux Kernel Mailing List,
Alexander Shishkin, Ingo Molnar, Leo Yan, Namhyung Kim,
James Morris, Jiri Olsa, linux-arm-kernel
In-Reply-To: <23f7b8c7616a467c93ee2c77e8ffd3cf@usma1ex-dag1mb6.msg.corp.akamai.com>
On Wed, 14 Aug 2019 at 14:02, Lubashev, Igor <ilubashe@akamai.com> wrote:
>
> > On Wed, August 14, 2019 at 2:52 PM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > Em Wed, Aug 14, 2019 at 03:48:14PM -0300, Arnaldo Carvalho de Melo
> > escreveu:
> > > Em Wed, Aug 14, 2019 at 12:04:33PM -0600, Mathieu Poirier escreveu:
> > > > # echo 0 > /proc/sys/kernel/kptr_restrict # ./tools/perf/perf record
> > > > -e instructions:k uname
> > > > perf: Segmentation fault
> > > > Obtained 10 stack frames.
> > > > ./tools/perf/perf(sighandler_dump_stack+0x44) [0x55af9e5da5d4]
> > > > /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fd31efb6f20]
> > > > ./tools/perf/perf(perf_event__synthesize_kernel_mmap+0xa7)
> > > > [0x55af9e590337]
> > > > ./tools/perf/perf(+0x1cf5be) [0x55af9e50c5be]
> > > > ./tools/perf/perf(cmd_record+0x1022) [0x55af9e50dff2]
> > > > ./tools/perf/perf(+0x23f98d) [0x55af9e57c98d]
> > > > ./tools/perf/perf(+0x23fc9e) [0x55af9e57cc9e]
> > > > ./tools/perf/perf(main+0x369) [0x55af9e4f6bc9]
> > > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
> > > > [0x7fd31ef99b97]
> > > > ./tools/perf/perf(_start+0x2a) [0x55af9e4f704a] Segmentation fault
> > > >
> > > > I can reproduce this on both x86 and ARM64.
> > >
> > > I don't see this with these two csets removed:
> > >
> > > 7ff5b5911144 perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> > > d7604b66102e perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid
> > > checks
> > >
> > > Which were the ones I guessed were related to the problem you
> > > reported, so they are out of my ongoing perf/core pull request to
> > > Ingo/Thomas, now trying with these applied and your instructions...
> >
> > Can't repro:
> >
> > [root@quaco ~]# cat /proc/sys/kernel/kptr_restrict
> > 0
> > [root@quaco ~]# perf record -e instructions:k uname Linux [ perf record:
> > Woken up 1 times to write data ] [ perf record: Captured and wrote 0.024 MB
> > perf.data (1 samples) ] [root@quaco ~]# echo 1 >
> > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record -e instructions:k
> > uname Linux [ perf record: Woken up 1 times to write data ] [ perf record:
> > Captured and wrote 0.024 MB perf.data (1 samples) ] [root@quaco ~]# echo
> > 0 > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record -e
> > instructions:k uname Linux [ perf record: Woken up 1 times to write data ] [
> > perf record: Captured and wrote 0.024 MB perf.data (1 samples) ]
> > [root@quaco ~]#
> >
> > [acme@quaco perf]$ git log --oneline --author Lubashev tools/
> > 7ff5b5911144 (HEAD -> perf/cap, acme.korg/tmp.perf/cap,
> > acme.korg/perf/cap) perf symbols: Use CAP_SYSLOG with kptr_restrict
> > checks d7604b66102e perf tools: Use CAP_SYS_ADMIN with
> > perf_event_paranoid checks c766f3df635d perf ftrace: Use CAP_SYS_ADMIN
> > instead of euid==0 c22e150e3afa perf tools: Add helpers to use capabilities if
> > present
> > 74d5f3d06f70 tools build: Add capability-related feature detection perf
> > version 5.3.rc4.g7ff5b5911144 [acme@quaco perf]$
>
> I got an ARM64 cloud VM, but I cannot reproduce.
> # cat /proc/sys/kernel/kptr_restrict
> 0
>
> Perf trace works fine (does not die):
> # ./perf trace -a
>
> Here is my setup:
> Repo: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> Branch: tmp.perf/cap
> Commit: 7ff5b5911 "perf symbols: Use CAP_SYSLOG with kptr_restrict checks"
> gcc --version: gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) 7.4.0
> uname -a: Linux arm-4-par-1 4.9.93-mainline-rev1 #1 SMP Tue Apr 10 09:54:46 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
> lsb_release -a: Ubuntu 18.04.3 LTS
>
> Auto-detecting system features:
> ... dwarf: [ on ]
> ... dwarf_getlocations: [ on ]
> ... glibc: [ on ]
> ... gtk2: [ on ]
> ... libaudit: [ on ]
> ... libbfd: [ on ]
> ... libcap: [ on ]
> ... libelf: [ on ]
> ... libnuma: [ on ]
> ... numa_num_possible_cpus: [ on ]
> ... libperl: [ on ]
> ... libpython: [ on ]
> ... libcrypto: [ on ]
> ... libunwind: [ on ]
> ... libdw-dwarf-unwind: [ on ]
> ... zlib: [ on ]
> ... lzma: [ on ]
> ... get_cpuid: [ OFF ]
> ... bpf: [ on ]
> ... libaio: [ on ]
> ... libzstd: [ on ]
> ... disassembler-four-args: [ on ]
>
> I also could not reproduce on x86:
> lsb_release -a: Ubuntu 18.04.1 LTS
> gcc --version: gcc (Ubuntu 7.4.0-1ubuntu1~18.04aka10.0.0) 7.4.0
> uname -r: 4.4.0-154-generic
I isolated the problem to libcap-dev - if it is not installed a
segmentation fault will occur. Since this set is about using
capabilities it is obvious that not having it on a system should fail
a trace session, but it should not crash it.
If libcap-dev is not installed function symbol__restricted_filename()
will return true, which in turn will prevent symbol_name to be set in
machine__get_running_kernel_start(). That prevents function
map__set_kallsyms_ref_reloc_sym() from being called in
machine__create_kernel_maps(), resulting in kmap->ref_reloc_sym being
NULL in _perf_event__synthesize_kernel_mmap() and a segmentation
fault.
I am not sure how this can be fixed. I counted a total of 19
instances where kmap->ref_reloc_sym->XYZ is called, only 2 of wich
care to check if kmap->ref_reloc_sym is valid before proceeding. As
such I must hope that in the 17 other cases, kmap->ref_reloc_sym is
guaranteed to be valid. If I am correct then all we need is to check
for a valid pointer in _perf_event__synthesize_kernel_mmap().
Otherwise it will be a little harder.
Mathieu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/8] arm64, mm: transitional tables
From: Pavel Tatashin @ 2019-08-15 20:18 UTC (permalink / raw)
To: James Morse
Cc: Sasha Levin, Vladimir Murzin, Jonathan Corbet, Marc Zyngier,
Catalin Marinas, Bhupesh Sharma, kexec mailing list, LKML,
James Morris, linux-mm, Eric W. Biederman, Matthias Brugger, will,
Linux ARM
In-Reply-To: <e00455af-a9f6-82e1-4c0d-78fae01ae00a@arm.com>
On Thu, Aug 15, 2019 at 2:11 PM James Morse <james.morse@arm.com> wrote:
>
> Hi Pavel,
>
> On 01/08/2019 16:24, Pavel Tatashin wrote:
> > There are cases where normal kernel pages tables, i.e. idmap_pg_dir
> > and swapper_pg_dir are not sufficient because they may be overwritten.
> >
> > This happens when we transition from one world to another: for example
> > during kexec kernel relocation transition, and also during hibernate
> > kernel restore transition.
> >
> > In these cases, if MMU is needed, the page table memory must be allocated
> > from a safe place. Transitional tables is intended to allow just that.
>
> > diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
> > index db92950bb1a0..dcb4f13c7888 100644
> > --- a/arch/arm64/include/asm/pgtable-hwdef.h
> > +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> > @@ -110,6 +110,7 @@
> > #define PUD_TABLE_BIT (_AT(pudval_t, 1) << 1)
> > #define PUD_TYPE_MASK (_AT(pudval_t, 3) << 0)
> > #define PUD_TYPE_SECT (_AT(pudval_t, 1) << 0)
> > +#define PUD_SECT_RDONLY (_AT(pudval_t, 1) << 7) /* AP[2] */
>
> This shouldn't be needed. As far as I'm aware, we only get read-only pages in the linear
> map from debug-pagealloc, and the module aliases. Both of which require the linear map to
> be made of page-size mappings.
>
> Where are you seeing these?
This was done simply for generalization.
In old copy_pud:
445 set_pud(dst_pudp,
446 __pud(pud_val(pud) & ~PMD_SECT_RDONLY));
In new trans_table_copy_pud():
119 if (!pud_table(src_pud)) {
120 if (info->trans_flags & TRANS_MKWRITE)
121 pud_val(src_pud) &= ~PUD_SECT_RDONLY;
If you want, I can replace it with PMD_SECT_RDONLY
> > + * trans_flags
> > + * - bitmap with flags that control how page table is filled.
> > + * TRANS_MKWRITE: during page table copy make PTE, PME, and PUD page
> > + * writeable by removing RDONLY flag from PTE.
> > + * TRANS_MKVALID: during page table copy, if PTE present, but not valid,
> > + * make it valid.
> > + * TRANS_CHECKPFN: During page table copy, for every PTE entry check that
> > + * PFN that this PTE points to is valid. Otherwise return
> > + * -ENXIO
>
> Adding top-level global knobs to manipulate the copied linear map is going to lead to
> bugs. The existing code will only change the PTE in specific circumstances, that it tests
> for, that only happen at the PTE level.
I am simply doing the same what the old code is doing:
hibernate sets this flag if: debug_pagealloc_enabled() and trans_table
in this case check if pfn_valid() or not. This is part of
generalization, without which it is not possible to re-use the code
between kexec and hibernate.
>
>
> > + * TRANS_FORCEMAP: During page map, if translation exists, force
> > + * overwrite it. Otherwise -ENXIO may be returned by
> > + * trans_table_map_* functions if conflict is detected.
>
I will remove it.
Thank you,
Pasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] nvmem: meson-efuse: bindings: Add secure-monitor phandle
From: Kevin Hilman @ 2019-08-15 21:20 UTC (permalink / raw)
To: robh+dt, devicetree
Cc: narmstrong, Carlo Caione, srinivas.kandagatla, linux-amlogic,
tglx, linux-arm-kernel, jbrunet
In-Reply-To: <20190731082339.20163-3-ccaione@baylibre.com>
Rob,
Carlo Caione <ccaione@baylibre.com> writes:
> Add a new property to link the nvmem driver to the secure-monitor. The
> nvmem driver needs to access the secure-monitor to be able to access the
> fuses.
>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> ---
> Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
> index 2e0723ab3384..f7b3ed74db54 100644
> --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
> +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
> @@ -4,6 +4,7 @@ Required properties:
> - compatible: should be "amlogic,meson-gxbb-efuse"
> - clocks: phandle to the efuse peripheral clock provided by the
> clock controller.
> +- secure-monitor: phandle to the secure-monitor node
>
> = Data cells =
> Are child nodes of eFuse, bindings of which as described in
> @@ -16,6 +17,7 @@ Example:
> clocks = <&clkc CLKID_EFUSE>;
> #address-cells = <1>;
> #size-cells = <1>;
> + secure-monitor = <&sm>;
>
> sn: sn@14 {
> reg = <0x14 0x10>;
> @@ -30,6 +32,10 @@ Example:
> };
> };
>
> + sm: secure-monitor {
> + compatible = "amlogic,meson-gxbb-sm";
> + };
> +
> = Data consumers =
> Are device nodes which consume nvmem data cells.
>
With your review/ack, I'll take this through with the driver changes.
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] pwm: atmel: use a constant for maximum prescale value
From: Uwe Kleine-König @ 2019-08-15 21:41 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190815214133.11134-1-uwe@kleine-koenig.org>
The maximal prescale value is 10 for all supported variants. So drop the
member in the variant description and introduce a global constant instead.
This reduces the size of the variant descriptions and the .apply() callback
can be compiled a bit more effectively.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
drivers/pwm/pwm-atmel.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index ac3d7a200b9e..d7a6d32b5774 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -50,6 +50,8 @@
#define PWMV2_CPRD 0x0C
#define PWMV2_CPRDUPD 0x10
+#define PWM_MAX_PRES 10
+
struct atmel_pwm_registers {
u8 period;
u8 period_upd;
@@ -59,7 +61,6 @@ struct atmel_pwm_registers {
struct atmel_pwm_config {
u32 max_period;
- u32 max_pres;
};
struct atmel_pwm_data {
@@ -126,7 +127,7 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
for (*pres = 0; cycles > atmel_pwm->data->cfg.max_period; cycles >>= 1)
(*pres)++;
- if (*pres > atmel_pwm->data->cfg.max_pres) {
+ if (*pres > PWM_MAX_PRES) {
dev_err(chip->dev, "pres exceeds the maximum value\n");
return -EINVAL;
}
@@ -289,7 +290,6 @@ static const struct atmel_pwm_data atmel_sam9rl_pwm_data = {
.cfg = {
/* 16 bits to keep period and duty. */
.max_period = 0xffff,
- .max_pres = 10,
},
};
@@ -303,7 +303,6 @@ static const struct atmel_pwm_data atmel_sama5_pwm_data = {
.cfg = {
/* 16 bits to keep period and duty. */
.max_period = 0xffff,
- .max_pres = 10,
},
};
@@ -317,7 +316,6 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
.cfg = {
/* 32 bits to keep period and duty. */
.max_period = 0xffffffff,
- .max_pres = 10,
},
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] pwm: atmel: Add link to reference manual
From: Uwe Kleine-König @ 2019-08-15 21:41 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
The reference manual for at least one of the supported variants is
publicly available. Add a link to it at the top of the driver.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
drivers/pwm/pwm-atmel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index e5e1eaf372fa..ac3d7a200b9e 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -4,6 +4,9 @@
*
* Copyright (C) 2013 Atmel Corporation
* Bo Shen <voice.shen@atmel.com>
+ *
+ * Reference manual for "atmel,at91sam9rl-pwm":
+ * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
*/
#include <linux/clk.h>
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] pwm: atmel: replace loop in prescale calculation by ad-hoc calculation
From: Uwe Kleine-König @ 2019-08-15 21:41 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190815214133.11134-1-uwe@kleine-koenig.org>
The calculated values are the same with the modified algorithm. The only
difference is that the calculation is a bit more efficient.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
drivers/pwm/pwm-atmel.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index d7a6d32b5774..42fe7bc043a8 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -60,7 +60,7 @@ struct atmel_pwm_registers {
};
struct atmel_pwm_config {
- u32 max_period;
+ u32 period_bits;
};
struct atmel_pwm_data {
@@ -119,17 +119,27 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
{
struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
unsigned long long cycles = state->period;
+ int shift;
/* Calculate the period cycles and prescale value */
cycles *= clk_get_rate(atmel_pwm->clk);
do_div(cycles, NSEC_PER_SEC);
- for (*pres = 0; cycles > atmel_pwm->data->cfg.max_period; cycles >>= 1)
- (*pres)++;
+ /*
+ * The register for the period length is cfg.period_bits bits wide.
+ * So for each bit the number of clock cycles is wider divide the input
+ * clock frequency by two using pres and shift cprd accordingly.
+ */
+ shift = fls(cycles) - atmel_pwm->data->cfg.period_bits;
- if (*pres > PWM_MAX_PRES) {
+ if (shift > PWM_MAX_PRES) {
dev_err(chip->dev, "pres exceeds the maximum value\n");
return -EINVAL;
+ } else if (shift > 0) {
+ *pres = shift;
+ cycles >>= *pres;
+ } else {
+ *pres = 0;
}
*cprd = cycles;
@@ -289,7 +299,7 @@ static const struct atmel_pwm_data atmel_sam9rl_pwm_data = {
},
.cfg = {
/* 16 bits to keep period and duty. */
- .max_period = 0xffff,
+ .period_bits = 16,
},
};
@@ -302,7 +312,7 @@ static const struct atmel_pwm_data atmel_sama5_pwm_data = {
},
.cfg = {
/* 16 bits to keep period and duty. */
- .max_period = 0xffff,
+ .period_bits = 16,
},
};
@@ -315,7 +325,7 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
},
.cfg = {
/* 32 bits to keep period and duty. */
- .max_period = 0xffffffff,
+ .period_bits = 32,
},
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Arnaldo Carvalho de Melo @ 2019-08-15 21:42 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov, Lubashev, Igor,
Arnaldo Carvalho de Melo, Linux Kernel Mailing List,
Alexander Shishkin, Ingo Molnar, Leo Yan, Namhyung Kim,
James Morris, Jiri Olsa, linux-arm-kernel
In-Reply-To: <CANLsYkxqBcJq8QJq+aLZXQas1VBg_wGh_p5WTUuRVFCYEQWiQw@mail.gmail.com>
Em Thu, Aug 15, 2019 at 02:16:48PM -0600, Mathieu Poirier escreveu:
> On Wed, 14 Aug 2019 at 14:02, Lubashev, Igor <ilubashe@akamai.com> wrote:
> >
> > > On Wed, August 14, 2019 at 2:52 PM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > > Em Wed, Aug 14, 2019 at 03:48:14PM -0300, Arnaldo Carvalho de Melo
> > > escreveu:
> > > > Em Wed, Aug 14, 2019 at 12:04:33PM -0600, Mathieu Poirier escreveu:
> > > > > # echo 0 > /proc/sys/kernel/kptr_restrict # ./tools/perf/perf record
> > > > > -e instructions:k uname
> > > > > perf: Segmentation fault
> > > > > Obtained 10 stack frames.
> > > > > ./tools/perf/perf(sighandler_dump_stack+0x44) [0x55af9e5da5d4]
> > > > > /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fd31efb6f20]
> > > > > ./tools/perf/perf(perf_event__synthesize_kernel_mmap+0xa7)
> > > > > [0x55af9e590337]
> > > > > ./tools/perf/perf(+0x1cf5be) [0x55af9e50c5be]
> > > > > ./tools/perf/perf(cmd_record+0x1022) [0x55af9e50dff2]
> > > > > ./tools/perf/perf(+0x23f98d) [0x55af9e57c98d]
> > > > > ./tools/perf/perf(+0x23fc9e) [0x55af9e57cc9e]
> > > > > ./tools/perf/perf(main+0x369) [0x55af9e4f6bc9]
> > > > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
> > > > > [0x7fd31ef99b97]
> > > > > ./tools/perf/perf(_start+0x2a) [0x55af9e4f704a] Segmentation fault
> > > > >
> > > > > I can reproduce this on both x86 and ARM64.
> > > >
> > > > I don't see this with these two csets removed:
> > > >
> > > > 7ff5b5911144 perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> > > > d7604b66102e perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid
> > > > checks
> > > >
> > > > Which were the ones I guessed were related to the problem you
> > > > reported, so they are out of my ongoing perf/core pull request to
> > > > Ingo/Thomas, now trying with these applied and your instructions...
> > >
> > > Can't repro:
> > >
> > > [root@quaco ~]# cat /proc/sys/kernel/kptr_restrict
> > > 0
> > > [root@quaco ~]# perf record -e instructions:k uname Linux [ perf record:
> > > Woken up 1 times to write data ] [ perf record: Captured and wrote 0.024 MB
> > > perf.data (1 samples) ] [root@quaco ~]# echo 1 >
> > > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record -e instructions:k
> > > uname Linux [ perf record: Woken up 1 times to write data ] [ perf record:
> > > Captured and wrote 0.024 MB perf.data (1 samples) ] [root@quaco ~]# echo
> > > 0 > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record -e
> > > instructions:k uname Linux [ perf record: Woken up 1 times to write data ] [
> > > perf record: Captured and wrote 0.024 MB perf.data (1 samples) ]
> > > [root@quaco ~]#
> > >
> > > [acme@quaco perf]$ git log --oneline --author Lubashev tools/
> > > 7ff5b5911144 (HEAD -> perf/cap, acme.korg/tmp.perf/cap,
> > > acme.korg/perf/cap) perf symbols: Use CAP_SYSLOG with kptr_restrict
> > > checks d7604b66102e perf tools: Use CAP_SYS_ADMIN with
> > > perf_event_paranoid checks c766f3df635d perf ftrace: Use CAP_SYS_ADMIN
> > > instead of euid==0 c22e150e3afa perf tools: Add helpers to use capabilities if
> > > present
> > > 74d5f3d06f70 tools build: Add capability-related feature detection perf
> > > version 5.3.rc4.g7ff5b5911144 [acme@quaco perf]$
> >
> > I got an ARM64 cloud VM, but I cannot reproduce.
> > # cat /proc/sys/kernel/kptr_restrict
> > 0
> >
> > Perf trace works fine (does not die):
> > # ./perf trace -a
> >
> > Here is my setup:
> > Repo: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> > Branch: tmp.perf/cap
> > Commit: 7ff5b5911 "perf symbols: Use CAP_SYSLOG with kptr_restrict checks"
> > gcc --version: gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) 7.4.0
> > uname -a: Linux arm-4-par-1 4.9.93-mainline-rev1 #1 SMP Tue Apr 10 09:54:46 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
> > lsb_release -a: Ubuntu 18.04.3 LTS
> >
> > Auto-detecting system features:
> > ... dwarf: [ on ]
> > ... dwarf_getlocations: [ on ]
> > ... glibc: [ on ]
> > ... gtk2: [ on ]
> > ... libaudit: [ on ]
> > ... libbfd: [ on ]
> > ... libcap: [ on ]
> > ... libelf: [ on ]
> > ... libnuma: [ on ]
> > ... numa_num_possible_cpus: [ on ]
> > ... libperl: [ on ]
> > ... libpython: [ on ]
> > ... libcrypto: [ on ]
> > ... libunwind: [ on ]
> > ... libdw-dwarf-unwind: [ on ]
> > ... zlib: [ on ]
> > ... lzma: [ on ]
> > ... get_cpuid: [ OFF ]
> > ... bpf: [ on ]
> > ... libaio: [ on ]
> > ... libzstd: [ on ]
> > ... disassembler-four-args: [ on ]
> >
> > I also could not reproduce on x86:
> > lsb_release -a: Ubuntu 18.04.1 LTS
> > gcc --version: gcc (Ubuntu 7.4.0-1ubuntu1~18.04aka10.0.0) 7.4.0
> > uname -r: 4.4.0-154-generic
>
> I isolated the problem to libcap-dev - if it is not installed a
> segmentation fault will occur. Since this set is about using
> capabilities it is obvious that not having it on a system should fail
> a trace session, but it should not crash it.
It shouldn't crash on x86_64:
root@quaco ~]# sysctl kernel.kptr_restrict
kernel.kptr_restrict = 0
[root@quaco ~]# perf record -e instructions:k uname
Linux
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.023 MB perf.data (5 samples) ]
[root@quaco ~]# ldd ~/bin/perf | grep libcap
[root@quaco ~]# perf -v
perf version 5.3.rc4.g329ca330bf8b
[root@quaco ~]#
[acme@quaco perf]$ git log --oneline -4
329ca330bf8b (HEAD -> perf/cap) perf symbols: Use CAP_SYSLOG with kptr_restrict checks
f7b9999387af perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
4d0489cf1c47 (acme.korg/tmp.perf/script-switch-on-off, perf/core) perf report: Add --switch-on/--switch-off events
2f53ae347f59 perf top: Add --switch-on/--switch-off events
[acme@quaco perf]$
> If libcap-dev is not installed function symbol__restricted_filename()
> will return true, which in turn will prevent symbol_name to be set in
> machine__get_running_kernel_start(). That prevents function
> map__set_kallsyms_ref_reloc_sym() from being called in
> machine__create_kernel_maps(), resulting in kmap->ref_reloc_sym being
> NULL in _perf_event__synthesize_kernel_mmap() and a segmentation
> fault.
Can you please try with my perf/cap branch? Perhaps you're using Igor's
original set of patches? I made changes to the fallback, he was making
it return false while I made it fallback to geteuid() == 0, as was
before his patches.
- Arnaldo
> I am not sure how this can be fixed. I counted a total of 19
> instances where kmap->ref_reloc_sym->XYZ is called, only 2 of wich
> care to check if kmap->ref_reloc_sym is valid before proceeding. As
> such I must hope that in the 17 other cases, kmap->ref_reloc_sym is
> guaranteed to be valid. If I am correct then all we need is to check
> for a valid pointer in _perf_event__synthesize_kernel_mmap().
> Otherwise it will be a little harder.
>
> Mathieu
--
- Arnaldo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* linux-next: Fixes tag needs some work in the arm-soc tree
From: Stephen Rothwell @ 2019-08-15 21:43 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, ARM
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
kbuild test robot
[-- Attachment #1.1: Type: text/plain, Size: 309 bytes --]
Hi all,
In commit
772775c1dfe0 ("net: lpc-enet: fix badzero.cocci warnings")
Fixes tag
Fixes: e42016eb3844 ("net: lpc-enet: allow compile testing")
has these problem(s):
- Target SHA1 does not exist
I can't quickly find which commit was meant :-(
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Lubashev, Igor @ 2019-08-15 22:27 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov,
Arnaldo Carvalho de Melo, Linux Kernel Mailing List,
Alexander Shishkin, Ingo Molnar, Leo Yan, Namhyung Kim,
James Morris, Jiri Olsa, linux-arm-kernel
In-Reply-To: <CANLsYkxqBcJq8QJq+aLZXQas1VBg_wGh_p5WTUuRVFCYEQWiQw@mail.gmail.com>
On Thu, August 15, 2019 at 4:17 PM Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On Wed, 14 Aug 2019 at 14:02, Lubashev, Igor <ilubashe@akamai.com>
> wrote:
> >
> > > On Wed, August 14, 2019 at 2:52 PM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> > > Em Wed, Aug 14, 2019 at 03:48:14PM -0300, Arnaldo Carvalho de Melo
> > > escreveu:
> > > > Em Wed, Aug 14, 2019 at 12:04:33PM -0600, Mathieu Poirier escreveu:
> > > > > # echo 0 > /proc/sys/kernel/kptr_restrict # ./tools/perf/perf
> > > > > record -e instructions:k uname
> > > > > perf: Segmentation fault
> > > > > Obtained 10 stack frames.
> > > > > ./tools/perf/perf(sighandler_dump_stack+0x44) [0x55af9e5da5d4]
> > > > > /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fd31efb6f20]
> > > > > ./tools/perf/perf(perf_event__synthesize_kernel_mmap+0xa7)
> > > > > [0x55af9e590337]
> > > > > ./tools/perf/perf(+0x1cf5be) [0x55af9e50c5be]
> > > > > ./tools/perf/perf(cmd_record+0x1022) [0x55af9e50dff2]
> > > > > ./tools/perf/perf(+0x23f98d) [0x55af9e57c98d]
> > > > > ./tools/perf/perf(+0x23fc9e) [0x55af9e57cc9e]
> > > > > ./tools/perf/perf(main+0x369) [0x55af9e4f6bc9]
> > > > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
> > > > > [0x7fd31ef99b97]
> > > > > ./tools/perf/perf(_start+0x2a) [0x55af9e4f704a] Segmentation
> > > > > fault
> > > > >
> > > > > I can reproduce this on both x86 and ARM64.
> > > >
> > > > I don't see this with these two csets removed:
> > > >
> > > > 7ff5b5911144 perf symbols: Use CAP_SYSLOG with kptr_restrict
> > > > checks d7604b66102e perf tools: Use CAP_SYS_ADMIN with
> > > > perf_event_paranoid checks
> > > >
> > > > Which were the ones I guessed were related to the problem you
> > > > reported, so they are out of my ongoing perf/core pull request to
> > > > Ingo/Thomas, now trying with these applied and your instructions...
SNIP
> I isolated the problem to libcap-dev - if it is not installed a segmentation fault
> will occur. Since this set is about using capabilities it is obvious that not
> having it on a system should fail a trace session, but it should not crash it.
>
> If libcap-dev is not installed function symbol__restricted_filename() will
> return true, which in turn will prevent symbol_name to be set in
> machine__get_running_kernel_start(). That prevents function
> map__set_kallsyms_ref_reloc_sym() from being called in
> machine__create_kernel_maps(), resulting in kmap->ref_reloc_sym being
> NULL in _perf_event__synthesize_kernel_mmap() and a segmentation fault.
Thank you, great find.
> I am not sure how this can be fixed. I counted a total of 19 instances where
> kmap->ref_reloc_sym->XYZ is called, only 2 of wich care to check if kmap-
> >ref_reloc_sym is valid before proceeding. As such I must hope that in the
> 17 other cases, kmap->ref_reloc_sym is guaranteed to be valid. If I am
> correct then all we need is to check for a valid pointer in
> _perf_event__synthesize_kernel_mmap().
> Otherwise it will be a little harder.
I also see 19 instances in 5 files, but by my inspection all cases but one are ok (the code checks for NULL earlier in the function or in a helper function).
The not ok case is __perf_event__synthesize_kermel_mmap(), which simply checks symbol_conf.kptr_restrict.
==== Option 1 =====
Fix __perf_event__synthesize_kermel_mmap(). This probably should be done regardless.
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index f440fdc3e953..b84f5f3c9651 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -913,11 +913,13 @@ static int __perf_event__synthesize_kernel_mmap(struct perf_tool *tool,
int err;
union perf_event *event;
- if (symbol_conf.kptr_restrict)
- return -1;
if (map == NULL)
return -1;
+ kmap = map__kmap(map);
+ if (!kmap->ref_reloc_sym)
+ return -1;
+
/*
* We should get this from /sys/kernel/sections/.text, but till that is
* available use this, and after it is use this as a fallback for older
@@ -940,7 +942,6 @@ static int __perf_event__synthesize_kernel_mmap(struct perf_tool *tool,
event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
}
- kmap = map__kmap(map);
size = snprintf(event->mmap.filename, sizeof(event->mmap.filename),
"%s%s", machine->mmap_name, kmap->ref_reloc_sym->name) + 1;
size = PERF_ALIGN(size, sizeof(u64));
--
==== Option 2 =====
Move the new perf_event_paranoid() check from symbol__restricted_filename() to symbol__read_kptr_restrict().
Other than the use above, kptr_restrict is only used for printing warnings.
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 7409d2facd5b..035f2e75728c 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -898,11 +898,7 @@ bool symbol__restricted_filename(const char *filename,
{
bool restricted = false;
- /* Per kernel/kallsyms.c:
- * we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
- */
- if (symbol_conf.kptr_restrict ||
- (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))) {
+ if (symbol_conf.kptr_restrict) {
char *r = realpath(filename, NULL);
if (r != NULL) {
@@ -2209,6 +2205,12 @@ static bool symbol__read_kptr_restrict(void)
fclose(fp);
}
+ /* Per kernel/kallsyms.c:
+ * we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
+ */
+ if (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))
+ value = true;
+
return value;
}
--------- And then update the warnings. -----------
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f71631f2bcb5..18505d92ff69 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -2372,7 +2372,7 @@ int cmd_record(int argc, const char **argv)
if (symbol_conf.kptr_restrict && !perf_evlist__exclude_kernel(rec->evlist))
pr_warning(
"WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted,\n"
-"check /proc/sys/kernel/kptr_restrict.\n\n"
+"check /proc/sys/kernel/kptr_restrict and /proc/sys/kernel/perf_event_paranoid.\n\n"
"Samples in kernel functions may not be resolved if a suitable vmlinux\n"
"file is not found in the buildid cache or in the vmlinux path.\n\n"
"Samples in kernel modules won't be resolved at all.\n\n"
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 5970723cd55a..29e910fb2d9a 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -770,7 +770,7 @@ static void perf_event__process_sample(struct perf_tool *tool,
if (!perf_evlist__exclude_kernel(top->session->evlist)) {
ui__warning(
"Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
-"Check /proc/sys/kernel/kptr_restrict.\n\n"
+"Check /proc/sys/kernel/kptr_restrict and /proc/sys/kernel/perf_event_paranoid.\n\n"
"Kernel%s samples will not be resolved.\n",
al.map && map__has_symbols(al.map) ?
" modules" : "");
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index bc44ed29e05a..9443b8e05810 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1381,7 +1381,7 @@ static char *trace__machine__resolve_kernel_addr(void *vmachine, unsigned long l
if (symbol_conf.kptr_restrict) {
pr_warning("Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
- "Check /proc/sys/kernel/kptr_restrict.\n\n"
+ "Check /proc/sys/kernel/kptr_restrict and /proc/sys/kernel/perf_event_paranoid.\n\n"
"Kernel samples will not be resolved.\n");
machine->kptr_restrict_warned = true;
return NULL;
- Igor
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1 2/4] soc: fsl: guts: Add definition for LS1028A
From: Li Yang @ 2019-08-15 22:40 UTC (permalink / raw)
To: Yinbo Zhu
Cc: Mark Rutland, Ulf Hansson, Catalin Marinas, Will Deacon,
Adrian Hunter, Catalin Horghidan, linux-mmc,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rajesh Bhagat, Alison Wang, Ashish Kumar, Claudiu Manoil,
Rob Herring, Vabhav Sharma,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Amit Jain, Alex Marginean, lkml, Rajat Srivastava, Yangbo Lu,
Jiafei Pan, linuxppc-dev, Xiaobo Xie
In-Reply-To: <20190814072649.8237-2-yinbo.zhu@nxp.com>
On Wed, Aug 14, 2019 at 2:26 AM Yinbo Zhu <yinbo.zhu@nxp.com> wrote:
>
> Adding compatible string "ls1028a-dcfg" to initialize guts driver
> for ls1028 and SoC die attribute definition for LS1028A
>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Applied for next.
> ---
> drivers/soc/fsl/guts.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> index 1ef8068c8dd3..34810f9bb2ee 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -102,6 +102,11 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
> .svr = 0x87360000,
> .mask = 0xff3f0000,
> },
> + /* Die: LS1028A, SoC: LS1028A */
> + { .die = "LS1028A",
> + .svr = 0x870b0000,
> + .mask = 0xff3f0000,
> + },
> { },
> };
>
> @@ -224,6 +229,7 @@ static const struct of_device_id fsl_guts_of_match[] = {
> { .compatible = "fsl,ls1012a-dcfg", },
> { .compatible = "fsl,ls1046a-dcfg", },
> { .compatible = "fsl,lx2160a-dcfg", },
> + { .compatible = "fsl,ls1028a-dcfg", },
> {}
> };
> MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 09/11] ARM: dts: qcom: pm8941: add 5vs2 regulator node
From: Brian Masney @ 2019-08-15 22:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jernej Skrabec, Neil Armstrong, Dave Airlie,
linux-kernel@vger.kernel.org, Jonas Karlman, Andy Gross,
open list:DRM PANEL DRIVERS, Bjorn Andersson, Andrzej Hajda,
Rob Clark, Rob Herring, Laurent Pinchart, Daniel Vetter, MSM,
Enric Balletbo i Serra, freedreno, Sean Paul, Linux ARM
In-Reply-To: <CACRpkdYU-6LvFKRkj0yMMCmAnX0XtGe7rMwbXbhf2GCp77Ciyw@mail.gmail.com>
On Thu, Aug 15, 2019 at 10:34:17AM +0200, Linus Walleij wrote:
> On Thu, Aug 15, 2019 at 2:49 AM Brian Masney <masneyb@onstation.org> wrote:
>
> > pm8941 is missing the 5vs2 regulator node so let's add it since its
> > needed to get the external display working. This regulator was already
> > configured in the interrupts property on the parent node.
> >
> > Note that this regulator is referred to as mvs2 in the downstream MSM
> > kernel sources.
>
> When I looked at it it seemed like this convention is used for power
> supplies that appear on both the main PMIC and the "extra (boot? basic?
> low power?) PMIC that the main 80xx PMIC has mvs1 and the
> other 89xx PMIC has mvs2.
According to the downstream MSM sources, the 5vs1 and 5vs2 rails are
both on the second pm8941 PMIC:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-regulator.dtsi#L18
> I suppose it is named "mvs" on both PMICs and this is just a rail
> name so as not to confuse the schematic?
That sounds reasonable.
> > Signed-off-by: Brian Masney <masneyb@onstation.org>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Thank you!
Brian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 06/11] drm/bridge: analogix-anx78xx: add support for avdd33 regulator
From: Brian Masney @ 2019-08-15 22:51 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jernej Skrabec, Neil Armstrong, Dave Airlie,
linux-kernel@vger.kernel.org, Jonas Karlman, Andy Gross,
open list:DRM PANEL DRIVERS, Bjorn Andersson, Andrzej Hajda,
Rob Clark, Rob Herring, Laurent Pinchart, Daniel Vetter, MSM,
Enric Balletbo i Serra, freedreno, Sean Paul, Linux ARM
In-Reply-To: <CACRpkdYdQa+FVfpSjLi0SsBMDT4QC667z1P1dnapz7PXgRoB5Q@mail.gmail.com>
On Thu, Aug 15, 2019 at 10:22:45AM +0200, Linus Walleij wrote:
> On Thu, Aug 15, 2019 at 2:49 AM Brian Masney <masneyb@onstation.org> wrote:
>
> > Add support for the avdd33 regulator to the analogix-anx78xx driver.
> > Note that the regulator is currently enabled during driver probe and
> > disabled when the driver is removed. This is currently how the
> > downstream MSM kernel sources do this.
> >
> > Let's not merge this upstream for the mean time until I get the external
> > display fully working on the Nexus 5 and then I can submit proper
> > support then that powers down this regulator in the power off function.
> >
> > Signed-off-by: Brian Masney <masneyb@onstation.org>
>
> > +static void anx78xx_disable_regulator_action(void *_data)
> > +{
> > + struct anx78xx_platform_data *pdata = _data;
> > +
> > + regulator_disable(pdata->avdd33);
> > +}
> (...)
> > + err = devm_add_action(dev, anx78xx_disable_regulator_action,
> > + pdata);
>
> Clever idea. Good for initial support, probably later on it would
> need to be reworked using runtime PM so it's not constantly
> powered up.
Yes, that's my plan. I suspect that I may have a regulator disabled
somewhere so I was planning to leave this on all the time for the time
being to match the downstream behavior until I get the hot plug detect
GPIO working.
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Thanks,
Brian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/3] bcm2835-dt-next-2019-08-15
From: Florian Fainelli @ 2019-08-15 22:56 UTC (permalink / raw)
To: Stefan Wahren, Florian Fainelli
Cc: Eric Anholt, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <1565894043-5249-1-git-send-email-wahrenst@gmx.net>
On 8/15/19 11:34 AM, Stefan Wahren wrote:
> Hi Florian,
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the git repository at:
>
> git://github.com/anholt/linux tags/bcm2835-dt-next-2019-08-15
>
> for you to fetch changes up to 60c833d5664e1b3f71c4471233469790adf505ca:
>
> ARM: dts: bcm283x: Enable HDMI at board level (2019-08-15 19:35:15 +0200)
>
> ----------------------------------------------------------------
> This pull request prepares the BCM2835 DTS files for the introduction
> of the new SoC BCM2711.
>
> ----------------------------------------------------------------
> Stefan Wahren (4):
> ARM: bcm283x: Reduce register ranges for UART, SPI and I2C
> ARM: dts: bcm283x: Define MMC interfaces at board level
> ARM: dts: bcm283x: Define memory at board level
> ARM: dts: bcm283x: Enable HDMI at board level
Merged into devicetree/next, thanks Stefan!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/3] bcm2835-defconfig-next-2019-08-15
From: Florian Fainelli @ 2019-08-15 22:56 UTC (permalink / raw)
To: Stefan Wahren, Florian Fainelli
Cc: Eric Anholt, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <1565894043-5249-2-git-send-email-wahrenst@gmx.net>
On 8/15/19 11:34 AM, Stefan Wahren wrote:
> Hi Florian,
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the git repository at:
>
> git://github.com/anholt/linux tags/bcm2835-defconfig-next-2019-08-15
>
> for you to fetch changes up to 4c6f5d4038af2c7332630bdd75cfdc0309e97242:
>
> ARM: defconfig: enable cpufreq driver for RPi (2019-07-23 22:53:35 +0200)
>
> ----------------------------------------------------------------
> This pull request enables the new RPi cpufreq driver in the 32-bit
> defconfigs.
>
> ----------------------------------------------------------------
Merged into defconfig/next, thanks Stefan!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 3/3] bcm2835-defconfig-64-next-2019-08-15
From: Florian Fainelli @ 2019-08-15 22:57 UTC (permalink / raw)
To: Stefan Wahren, Florian Fainelli
Cc: Eric Anholt, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <1565894043-5249-3-git-send-email-wahrenst@gmx.net>
On 8/15/19 11:34 AM, Stefan Wahren wrote:
> Hi Florian,
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the git repository at:
>
> git://github.com/anholt/linux tags/bcm2835-defconfig-64-next-2019-08-15
>
> for you to fetch changes up to e2dd73ac4440f7143e990e76bad9a46dc63a5951:
>
> arm64: defconfig: enable cpufreq support for RPi3 (2019-07-23 23:17:09 +0200)
>
> ----------------------------------------------------------------
> This pull request enables the new RPi cpufreq driver in the 64-bit
> defconfig.
>
> ----------------------------------------------------------------
Merged into defconfig-arm64/next, thanks Stefan!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable the DesignWare watchdog
From: Dinh Nguyen @ 2019-08-15 23:12 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: olof, dinguyen, will, shawnguo, catalin.marinas
Enable the DesignWare watchdog driver that is present on the Intel
Stratix10 and Agilex platforms.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..69c19d82d936 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -445,6 +445,7 @@ CONFIG_UNIPHIER_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
+CONFIG_DW_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=m
CONFIG_IMX2_WDT=y
CONFIG_IMX_SC_WDT=m
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* linux-next: build warning after merge of the arm-soc tree
From: Stephen Rothwell @ 2019-08-15 23:23 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, ARM
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1686 bytes --]
Hi all,
After merging the arm-soc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from include/linux/kernel.h:15,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/dma/iop-adma.c:13:
drivers/dma/iop-adma.c: In function '__iop_adma_slot_cleanup':
drivers/dma/iop-adma.c:118:12: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' {aka 'long long unsigned int'} [-Wformat=]
pr_debug("\tcookie: %d slot: %d busy: %d "
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/printk.h:288:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/dynamic_debug.h:143:2: note: in expansion of macro '__dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~~~~
include/linux/dynamic_debug.h:153:2: note: in expansion of macro '_dynamic_func_call'
_dynamic_func_call(fmt, __dynamic_pr_debug, \
^~~~~~~~~~~~~~~~~~
include/linux/printk.h:336:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/dma/iop-adma.c:118:3: note: in expansion of macro 'pr_debug'
pr_debug("\tcookie: %d slot: %d busy: %d "
^~~~~~~~
drivers/dma/iop-adma.c:119:18: note: format string is defined here
"this_desc: %#x next_desc: %#llx ack: %d\n",
~~^
%#llx
Introduced (or exposed?) by commit
00c9755524fb ("dmaengine: iop-adma: use correct printk format strings")
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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