[PATCH v2 05/11] drm/komeda: Add komeda_crtc_prepare/unprepare
From: "james qian wang (Arm Technology China)"
These two function will be used by komeda_crtc_enable/disable to do some
prepartion works when enable/disable a crtc. like enable a crtc:
1. Adjust display operation mode.
2. Enable/prepare needed clk.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 32 ++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 104 ++
.../gpu/drm/arm/display/komeda/komeda_dev.c | 2 +
.../gpu/drm/arm/display/komeda/komeda_dev.h | 26 +
4 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 74aab4f23ea0..2fb29aea9f69 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -241,6 +241,37 @@ static int d71_disable_irq(struct komeda_dev *mdev)
return 0;
}
+static int to_d71_opmode(int core_mode)
+{
+ switch (core_mode) {
+ case KOMEDA_MODE_DISP0:
+ return DO0_ACTIVE_MODE;
+ case KOMEDA_MODE_DISP1:
+ return DO1_ACTIVE_MODE;
+ case KOMEDA_MODE_DUAL_DISP:
+ return DO01_ACTIVE_MODE;
+ case KOMEDA_MODE_INACTIVE:
+ return INACTIVE_MODE;
+ default:
+ WARN(1, "Unknown operation mode");
+ return INACTIVE_MODE;
+ }
+}
+
+static int d71_change_opmode(struct komeda_dev *mdev, int new_mode)
+{
+ struct d71_dev *d71 = mdev->chip_data;
+ u32 opmode = to_d71_opmode(new_mode);
+ int ret;
+
+ malidp_write32_mask(d71->gcu_addr, BLK_CONTROL, 0x7, opmode);
+
+ ret = dp_wait_cond(((malidp_read32(d71->gcu_addr, BLK_CONTROL) & 0x7)
== opmode),
+ 100, 1000, 1);
+
+ return ret > 0 ? 0 : -ETIMEDOUT;
+}
+
static void d71_flush(struct komeda_dev *mdev,
int master_pipe, u32 active_pipes)
{
@@ -467,6 +498,7 @@ static struct komeda_dev_funcs d71_chip_funcs = {
.irq_handler= d71_irq_handler,
.enable_irq = d71_enable_irq,
.disable_irq= d71_disable_irq,
+ .change_opmode = d71_change_opmode,
.flush = d71_flush,
};
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 7e0bf78da733..ef4c3ee2a688 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -40,6 +40,110 @@ komeda_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
}
+u32 komeda_calc_mclk(struct komeda_crtc_state *kcrtc_st)
+{
+ unsigned long mclk = kcrtc_st->base.adjusted_mode.clock * 1000;
+
+ return mclk;
+}
+
+/* For active a crtc, mainly need two parts of preparation
+ * 1. adjust display operation mode.
+ * 2. enable needed clk
+ */
+int
+komeda_crtc_prepare(struct komeda_crtc *kcrtc)
+{
+ struct komeda_dev *mdev = kcrtc->base.dev->dev_private;
+ struct komeda_pipeline *master = kcrtc->master;
+ struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(kcrtc->base.state);
+ unsigned long pxlclk_rate = kcrtc_st->base.adjusted_mode.clock * 1000;
+ u32 new_mode;
+ int err;
+
+ mutex_lock(>lock);
+
+ new_mode = mdev->dpmode | BIT(master->id);
+ if (WARN_ON(new_mode == mdev->dpmode)) {
+ err = 0;
+ goto unlock;
+ }
+
+ err = mdev->funcs->change_opmode(mdev, new_mode);
+ if (err) {
+ DRM_ERROR("failed to change opmode: 0x%x -> 0x%x.\n,",
+ mdev->dpmode, new_mode);
+ goto unlock;
+ }
+
+ mdev->dpmode = new_mode;
+ /* Only need to enable mclk on single display mode, but no need to
+* enable mclk it on dual display mode, since the dual mode always
+* switch from single display mode, the mclk already enabled, no need
+* to enable it again.
+*/
+ if (new_mode != KOMEDA_MODE_DUAL_DISP) {
+ err = clk_set_rate(mdev->mclk, komeda_calc_mclk(kcrtc_st));
+ if (err)
+ DRM_ERROR("failed to set mclk.\n");
+ err = clk_prepare_enable(mdev->mclk);
+ if (err)
+ DRM_ERROR("failed to enable mclk.\n");
+ }
+
+ err = clk_prepare_enable(master->aclk);
+ if (err)
+ DRM_ERROR("failed to enable axi clk for pipe%d.\n", master->id);
+ err = clk_set_rate(master->pxlclk, pxlclk_rate);
+ if (err)
+ DRM_ERROR("failed to set pxlclk for pipe%d\n", master->id);
+ err = clk_prepare_enable(master->pxlclk);
+ if (err)
+ DRM_ERROR("failed to enable pxl clk for pipe%d.\n", master->id);
+
+unlock:
+ mutex_unlock(>lock);
+
+ return err;
+}
+
+int
+komeda_crtc_unprepare(struct komeda_crtc *kcrtc)
+{
+ struct
[PATCH v2 10/11] drm/komeda: Add sysfs attribute: core_id and config_id
From: "james qian wang (Arm Technology China)"
Add two sysfs node: core_id, config_id, user can read them to fetch the
HW product information.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_product.h | 12 +
.../gpu/drm/arm/display/komeda/komeda_dev.c | 48 +++
.../gpu/drm/arm/display/komeda/komeda_dev.h | 2 +
.../gpu/drm/arm/display/komeda/komeda_drv.c | 7 +++
4 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h
b/drivers/gpu/drm/arm/display/include/malidp_product.h
index b35fc5db866b..1053b11352eb 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_product.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
@@ -20,4 +20,16 @@
/* Mali-display product IDs */
#define MALIDP_D71_PRODUCT_ID 0x0071
+union komeda_config_id {
+ struct {
+ __u32 max_line_sz:16,
+ n_pipelines:2,
+ n_scalers:2, /* number of scalers per pipeline */
+ n_layers:3, /* number of layers per pipeline */
+ n_richs:3, /* number of rich layers per pipeline */
+ reserved_bits:6;
+ };
+ __u32 value;
+};
+
#endif /* _MALIDP_PRODUCT_H_ */
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 7152f2c08e01..9e017ce89d69 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -53,6 +53,46 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
mdev, _register_fops);
}
+static ssize_t
+core_id_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct komeda_dev *mdev = dev_to_mdev(dev);
+
+ return snprintf(buf, PAGE_SIZE, "0x%08x\n", mdev->chip.core_id);
+}
+static DEVICE_ATTR_RO(core_id);
+
+static ssize_t
+config_id_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct komeda_dev *mdev = dev_to_mdev(dev);
+ struct komeda_pipeline *pipe = mdev->pipelines[0];
+ union komeda_config_id config_id = {0,};
+ int i;
+
+ config_id.max_line_sz = pipe->layers[0]->hsize_in.end;
+ config_id.n_pipelines = mdev->n_pipelines;
+ config_id.n_scalers = pipe->n_scalers;
+ config_id.n_layers = pipe->n_layers;
+ config_id.n_richs = 0;
+ for (i = 0; i < pipe->n_layers; i++) {
+ if (pipe->layers[i]->layer_type == KOMEDA_FMT_RICH_LAYER)
+ config_id.n_richs++;
+ }
+ return snprintf(buf, PAGE_SIZE, "0x%08x\n", config_id.value);
+}
+static DEVICE_ATTR_RO(config_id);
+
+static struct attribute *komeda_sysfs_entries[] = {
+ _attr_core_id.attr,
+ _attr_config_id.attr,
+ NULL,
+};
+
+static struct attribute_group komeda_sysfs_attr_group = {
+ .attrs = komeda_sysfs_entries,
+};
+
static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node
*np)
{
struct komeda_pipeline *pipe;
@@ -201,6 +241,12 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
goto err_cleanup;
}
+ err = sysfs_create_group(>kobj, _sysfs_attr_group);
+ if (err) {
+ DRM_ERROR("create sysfs group failed.\n");
+ goto err_cleanup;
+ }
+
#ifdef CONFIG_DEBUG_FS
komeda_debugfs_init(mdev);
#endif
@@ -218,6 +264,8 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
struct komeda_dev_funcs *funcs = mdev->funcs;
int i;
+ sysfs_remove_group(>kobj, _sysfs_attr_group);
+
#ifdef CONFIG_DEBUG_FS
debugfs_remove_recursive(mdev->debugfs_root);
#endif
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index 8acd25afb3e9..0c3e32b596d9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -190,4 +190,6 @@ d71_identify(u32 __iomem *reg, struct komeda_chip_info
*chip);
struct komeda_dev *komeda_dev_create(struct device *dev);
void komeda_dev_destroy(struct komeda_dev *mdev);
+struct komeda_dev *dev_to_mdev(struct device *dev);
+
#endif /*_KOMEDA_DEV_H_*/
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index 2bdd189b041d..0285fd37a016 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -17,6 +17,13 @@ struct komeda_drv {
struct komeda_kms_dev *kms;
};
+struct komeda_dev *dev_to_mdev(struct device *dev)
+{
+ struct komeda_drv *mdrv = dev_get_drvdata(dev);
+
+ return mdrv ? mdrv->mdev : NULL;
+}
+
static void komeda_unbind(struct device *dev)
{
struct komeda_drv *mdrv = dev_get_drvdata(dev);
--
2.17.1
[PATCH v2 11/11] drm/komeda: Expose bus_width to Komeda-CORE
From: "james qian wang (Arm Technology China)"
CHIP set bus_width according to the HW configuration, and CORE will use
it as buffer alignment.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 1 +
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index f517ab0ceae9..a6ca3ff16fef 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -518,6 +518,7 @@ d71_identify(u32 __iomem *reg_base, struct komeda_chip_info
*chip)
chip->arch_id = malidp_read32(reg_base, GLB_ARCH_ID);
chip->core_id = malidp_read32(reg_base, GLB_CORE_ID);
chip->core_info = malidp_read32(reg_base, GLB_CORE_INFO);
+ chip->bus_width = D71_BUS_WIDTH_16_BYTES;
return _chip_funcs;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 337e6fddead0..ed54beaee2f9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -21,10 +21,10 @@ static int komeda_gem_cma_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
- u32 alignment = 16; /* TODO get alignment from dev */
+ struct komeda_dev *mdev = dev->dev_private;
+ u32 pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
- args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8),
- alignment);
+ args->pitch = ALIGN(pitch, mdev->chip.bus_width);
return drm_gem_cma_dumb_create_internal(file, dev, args);
}
--
2.17.1
[PATCH v4 2/3] ASoC: add fsl_audmix DT binding documentation
Add the DT binding documentation for NXP Audio Mixer
CPU DAI driver.
Signed-off-by: Viorel Suman
---
.../devicetree/bindings/sound/fsl,audmix.txt | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.txt
diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.txt
b/Documentation/devicetree/bindings/sound/fsl,audmix.txt
new file mode 100644
index 000..45f807e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,audmix.txt
@@ -0,0 +1,54 @@
+NXP Audio Mixer (AUDMIX).
+
+The Audio Mixer is a on-chip functional module that allows mixing of two
+audio streams into a single audio stream. Audio Mixer has two input serial
+audio interfaces. These are driven by two Synchronous Audio interface
+modules (SAI). Each input serial interface carries 8 audio channels in its
+frame in TDM manner. Mixer mixes audio samples of corresponding channels
+from two interfaces into a single sample. Before mixing, audio samples of
+two inputs can be attenuated based on configuration. The output of the
+Audio Mixer is also a serial audio interface. Like input interfaces it has
+the same TDM frame format. This output is used to drive the serial DAC TDM
+interface of audio codec and also sent to the external pins along with the
+receive path of normal audio SAI module for readback by the CPU.
+
+The output of Audio Mixer can be selected from any of the three streams
+ - serial audio input 1
+ - serial audio input 2
+ - mixed audio
+
+Mixing operation is independent of audio sample rate but the two audio
+input streams must have same audio sample rate with same number of channels
+in TDM frame to be eligible for mixing.
+
+Device driver required properties:
+=
+ - compatible : Compatible list, contains "fsl,imx8qm-audmix"
+
+ - reg: Offset and length of the register set for the
device.
+
+ - clocks : Must contain an entry for each entry in clock-names.
+
+ - clock-names: Must include the "ipg" for register access.
+
+ - power-domains : Must contain the phandle to AUDMIX power domain node
+
+ - dais : Must contain a list of phandles to AUDMIX connected
+ DAIs. The current implementation requires two phandles
+ to SAI interfaces to be provided, the first SAI in the
+ list being used to route the AUDMIX output.
+
+ - model : Must contain machine driver name which will configure
+ and instantiate the appropriate audio card.
+
+Device driver configuration example:
+==
+ audmix: audmix@5984 {
+compatible = "fsl,imx8qm-audmix";
+reg = <0x0 0x5984 0x0 0x1>;
+clocks = < IMX8QXP_AUD_AUDMIX_IPG>;
+clock-names = "ipg";
+power-domains = <_audmix>;
+dais = <>, <>;
+model = "imx-audmix";
+ };
--
2.7.4
[PATCH v4 1/3] ASoC: fsl: Add Audio Mixer CPU DAI driver
This patch implements Audio Mixer CPU DAI driver for NXP iMX8 SOCs.
The Audio Mixer is a on-chip functional module that allows mixing of
two audio streams into a single audio stream.
Audio Mixer datasheet is available here:
https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
Signed-off-by: Viorel Suman
---
sound/soc/fsl/Kconfig | 7 +
sound/soc/fsl/Makefile | 3 +
sound/soc/fsl/fsl_audmix.c | 576 +
sound/soc/fsl/fsl_audmix.h | 102
4 files changed, 688 insertions(+)
create mode 100644 sound/soc/fsl/fsl_audmix.c
create mode 100644 sound/soc/fsl/fsl_audmix.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 7b1d997..0af2e056 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -24,6 +24,13 @@ config SND_SOC_FSL_SAI
This option is only useful for out-of-tree drivers since
in-tree drivers select it automatically.
+config SND_SOC_FSL_AUDMIX
+ tristate "Audio Mixer (AUDMIX) module support"
+ select REGMAP_MMIO
+ help
+ Say Y if you want to add Audio Mixer (AUDMIX)
+ support for the NXP iMX CPUs.
+
config SND_SOC_FSL_SSI
tristate "Synchronous Serial Interface module (SSI) support"
select SND_SOC_IMX_PCM_DMA if SND_IMX_SOC != n
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 3c0ff31..4172d5a 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -12,6 +12,7 @@ snd-soc-p1022-rdk-objs := p1022_rdk.o
obj-$(CONFIG_SND_SOC_P1022_RDK) += snd-soc-p1022-rdk.o
# Freescale SSI/DMA/SAI/SPDIF Support
+snd-soc-fsl-audmix-objs := fsl_audmix.o
snd-soc-fsl-asoc-card-objs := fsl-asoc-card.o
snd-soc-fsl-asrc-objs := fsl_asrc.o fsl_asrc_dma.o
snd-soc-fsl-sai-objs := fsl_sai.o
@@ -22,6 +23,8 @@ snd-soc-fsl-esai-objs := fsl_esai.o
snd-soc-fsl-micfil-objs := fsl_micfil.o
snd-soc-fsl-utils-objs := fsl_utils.o
snd-soc-fsl-dma-objs := fsl_dma.o
+
+obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o
obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o
obj-$(CONFIG_SND_SOC_FSL_ASRC) += snd-soc-fsl-asrc.o
obj-$(CONFIG_SND_SOC_FSL_SAI) += snd-soc-fsl-sai.o
diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
new file mode 100644
index 000..3356cb6
--- /dev/null
+++ b/sound/soc/fsl/fsl_audmix.c
@@ -0,0 +1,576 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NXP AUDMIX ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright 2017 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fsl_audmix.h"
+
+#define SOC_ENUM_SINGLE_S(xreg, xshift, xtexts) \
+ SOC_ENUM_SINGLE(xreg, xshift, ARRAY_SIZE(xtexts), xtexts)
+
+static const char
+ *tdm_sel[] = { "TDM1", "TDM2", },
+ *mode_sel[] = { "Disabled", "TDM1", "TDM2", "Mixed", },
+ *width_sel[] = { "16b", "18b", "20b", "24b", "32b", },
+ *endis_sel[] = { "Disabled", "Enabled", },
+ *updn_sel[] = { "Downward", "Upward", },
+ *mask_sel[] = { "Unmask", "Mask", };
+
+static const struct soc_enum fsl_audmix_enum[] = {
+/* FSL_AUDMIX_CTR enums */
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_MIXCLK_SHIFT, tdm_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_OUTSRC_SHIFT, mode_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_OUTWIDTH_SHIFT, width_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_MASKRTDF_SHIFT, mask_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_MASKCKDF_SHIFT, mask_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_SYNCMODE_SHIFT, endis_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_SYNCSRC_SHIFT, tdm_sel),
+/* FSL_AUDMIX_ATCR0 enums */
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_ATCR0, 0, endis_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_ATCR0, 1, updn_sel),
+/* FSL_AUDMIX_ATCR1 enums */
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_ATCR1, 0, endis_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_ATCR1, 1, updn_sel),
+};
+
+struct fsl_audmix_state {
+ u8 tdms;
+ u8 clk;
+ char msg[64];
+};
+
+static const struct fsl_audmix_state prms[4][4] = {{
+ /* DIS->DIS, do nothing */
+ { .tdms = 0, .clk = 0, .msg = "" },
+ /* DIS->TDM1*/
+ { .tdms = 1, .clk = 1, .msg = "DIS->TDM1: TDM1 not started!\n" },
+ /* DIS->TDM2*/
+ { .tdms = 2, .clk = 2, .msg = "DIS->TDM2: TDM2 not started!\n" },
+ /* DIS->MIX */
+ { .tdms = 3, .clk = 0, .msg = "DIS->MIX: Please start both TDMs!\n" }
+}, { /* TDM1->DIS */
+ { .tdms = 1, .clk = 0, .msg = "TDM1->DIS: TDM1 not started!\n" },
+ /* TDM1->TDM1, do nothing */
+ { .tdms = 0, .clk = 0, .msg = "" },
+ /* TDM1->TDM2 */
+ { .tdms = 3, .clk = 2, .msg = "TDM1->TDM2: Please start both TDMs!\n" },
+ /* TDM1->MIX */
+ { .tdms = 3, .clk = 0, .msg = "TDM1->MIX: Please start both TDMs!\n" }
+}, { /* TDM2->DIS */
+ { .tdms = 2, .clk = 0, .msg = "TDM2->DIS: TDM2 not started!\n" },
+ /* TDM2->TDM1 */
+ { .tdms = 3, .clk
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
On Thu, Jan 17, 2019 at 10:02:12AM +0530, Jagan Teki wrote: > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard > wrote: > > > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > > Again, I cannot help you without the datasheet for the panels > > > > > > > > you're > > > > > > > > trying to submit. > > > > > > > > > > > > > > The panel bound with Sitronix ST7701 IC > > > > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > > > > > > > > > > > It's the controller, not the panel > > > > > > > > > > As I said before, the datasheet of that panel doesn't have any > > > > > information except electrical characteristics and used IC which is > > > > > ST7701. > > > > > > > > > > I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 > > > > > please find the attachment for the same. > > > > > > > > > > Here is some more details of the same. > > > > > > > > > > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erobbing/x300/x300.dtsi#L81 > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > matches timings for > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > Where did you get the timings from then? > > > > > > You mean drm_mode timings, the same panel with RGB available in > > > panel-simple[1], and dsi driver in Mailing list[2] and actual DSI > > > sequence commands from BSP[3] > > > > > > [1] > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > [3] > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > So you had no reliable source for the timings then? How do you know if > > all your patches that are timing related are right then? > > I don't understand your point, or may be I confused with many links > that I attached in previous mail. > > 1. Patch for same panel timings are already in Mainline that was > tested on one of the board. [1] > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > Do you think the above two points are not valid sources? I'm saying that the only valid source is the datasheet or a DSI analyzer. Maxmie -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [kbuild-all] arch/x86/include/asm/cmpxchg.h:245:2: error: 'asm' operand has impossible constraints
On Tue, Jan 22, 2019 at 11:08:34AM +0100, Borislav Petkov wrote: > On Tue, Jan 22, 2019 at 12:53:11PM +0800, kbuild test robot wrote: > > Hi Ingo, > > > > FYI, the error/warning still remains. > > Guys, > > we already discussed this: > > https://lists.01.org/pipermail/kbuild-all/2018-December/056206.html > > but you keep reporting it. > > You need to fix your reported issues tracking or otherwise no one will > bother anymore. thanks for the feedback, we will blacklist this. So may i understand based on the thread at https://lists.01.org/pipermail/kbuild-all/2018-December/056225.html, this is gcc-4.9 problem? > > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply. > ___ > kbuild-all mailing list > kbuild-...@lists.01.org > https://lists.01.org/mailman/listinfo/kbuild-all
[PATCH v4 3/3] ASoC: fsl: Add Audio Mixer machine driver
This patch implements Audio Mixer machine driver for NXP iMX8 SOCs.
It connects together Audio Mixer and related SAI instances.
Signed-off-by: Viorel Suman
---
sound/soc/fsl/Kconfig | 9 ++
sound/soc/fsl/Makefile | 2 +
sound/soc/fsl/imx-audmix.c | 327 +
3 files changed, 338 insertions(+)
create mode 100644 sound/soc/fsl/imx-audmix.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 0af2e056..d87c842 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -303,6 +303,15 @@ config SND_SOC_FSL_ASOC_CARD
CS4271, CS4272 and SGTL5000.
Say Y if you want to add support for Freescale Generic ASoC Sound Card.
+config SND_SOC_IMX_AUDMIX
+ tristate "SoC Audio support for i.MX boards with AUDMIX"
+ select SND_SOC_FSL_AUDMIX
+ select SND_SOC_FSL_SAI
+ help
+ SoC Audio support for i.MX boards with Audio Mixer
+ Say Y if you want to add support for SoC audio on an i.MX board with
+ an Audio Mixer.
+
endif # SND_IMX_SOC
endmenu
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 4172d5a..c0dd044 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -62,6 +62,7 @@ snd-soc-imx-es8328-objs := imx-es8328.o
snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
snd-soc-imx-spdif-objs := imx-spdif.o
snd-soc-imx-mc13783-objs := imx-mc13783.o
+snd-soc-imx-audmix-objs := imx-audmix.o
obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
obj-$(CONFIG_SND_SOC_PHYCORE_AC97) += snd-soc-phycore-ac97.o
@@ -71,3 +72,4 @@ obj-$(CONFIG_SND_SOC_IMX_ES8328) += snd-soc-imx-es8328.o
obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
obj-$(CONFIG_SND_SOC_IMX_MC13783) += snd-soc-imx-mc13783.o
+obj-$(CONFIG_SND_SOC_IMX_AUDMIX) += snd-soc-imx-audmix.o
diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
new file mode 100644
index 000..72e37ca
--- /dev/null
+++ b/sound/soc/fsl/imx-audmix.c
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2017 NXP
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "fsl_sai.h"
+#include "fsl_audmix.h"
+
+struct imx_audmix {
+ struct platform_device *pdev;
+ struct snd_soc_card card;
+ struct platform_device *audmix_pdev;
+ struct platform_device *out_pdev;
+ struct clk *cpu_mclk;
+ int num_dai;
+ struct snd_soc_dai_link *dai;
+ int num_dai_conf;
+ struct snd_soc_codec_conf *dai_conf;
+ int num_dapm_routes;
+ struct snd_soc_dapm_route *dapm_routes;
+};
+
+static const u32 imx_audmix_rates[] = {
+ 8000, 12000, 16000, 24000, 32000, 48000, 64000, 96000,
+};
+
+static const struct snd_pcm_hw_constraint_list imx_audmix_rate_constraints = {
+ .count = ARRAY_SIZE(imx_audmix_rates),
+ .list = imx_audmix_rates,
+};
+
+static int imx_audmix_fe_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct imx_audmix *priv = snd_soc_card_get_drvdata(rtd->card);
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct device *dev = rtd->card->dev;
+ unsigned long clk_rate = clk_get_rate(priv->cpu_mclk);
+ int ret;
+
+ if (clk_rate % 24576000 == 0) {
+ ret = snd_pcm_hw_constraint_list(runtime, 0,
+SNDRV_PCM_HW_PARAM_RATE,
+_audmix_rate_constraints);
+ if (ret < 0)
+ return ret;
+ } else {
+ dev_warn(dev, "mclk may be not supported %lu\n", clk_rate);
+ }
+
+ ret = snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
+ 1, 8);
+ if (ret < 0)
+ return ret;
+
+ return snd_pcm_hw_constraint_mask64(runtime, SNDRV_PCM_HW_PARAM_FORMAT,
+ FSL_AUDMIX_FORMATS);
+}
+
+static int imx_audmix_fe_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct device *dev = rtd->card->dev;
+ bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
+ unsigned int fmt = SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_NB_NF;
+ u32 channels = params_channels(params);
+ int ret, dir;
+
+ /* For playback the AUDMIX is slave, and for record is master */
+ fmt |= tx ? SND_SOC_DAIFMT_CBS_CFS :
[PATCH v4 0/3] Add NXP AUDMIX device and machine drivers
The patchset adds NXP Audio Mixer (AUDMIX) device and machine drivers and related DT bindings documentation. Changes since V3: 1. Removed machine driver DT bindings documentation. 2. Trigger machine driver probe from device driver as suggested by Nicolin. Changes since V2: 1. Moved "dais" node from machine driver DTS node to device driver DTS node as suggested by Rob. Changes since V1: 1. Original patch split into distinct patches for the device driver and DT binding documentation. 2. Replaced AMIX with AUDMIX in both code and file names as it looks more RM-compliant. 3. Removed polarity control from CPU DAI driver as suggested by Nicolin. 4. Added machine driver and related DT binding documentation. Viorel Suman (3): ASoC: fsl: Add Audio Mixer CPU DAI driver ASoC: add fsl_audmix DT binding documentation ASoC: fsl: Add Audio Mixer machine driver .../devicetree/bindings/sound/fsl,audmix.txt | 54 ++ sound/soc/fsl/Kconfig | 16 + sound/soc/fsl/Makefile | 5 + sound/soc/fsl/fsl_audmix.c | 576 + sound/soc/fsl/fsl_audmix.h | 102 sound/soc/fsl/imx-audmix.c | 327 6 files changed, 1080 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.txt create mode 100644 sound/soc/fsl/fsl_audmix.c create mode 100644 sound/soc/fsl/fsl_audmix.h create mode 100644 sound/soc/fsl/imx-audmix.c -- 2.7.4
Re: [PATCH v2] tty: moxa: Fix coding style issues
On 21. 01. 19, 23:45, Antoine Robertson wrote:
> Fix coding style issues
>
> Signed-off-by: Antoine Robertson
> ---
> drivers/tty/moxa.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/tty/moxa.c b/drivers/tty/moxa.c
> index 3a1a5e0ee93f..9b6dcb4f7905 100644
> --- a/drivers/tty/moxa.c
> +++ b/drivers/tty/moxa.c
...
> @@ -1159,9 +1158,8 @@ static int moxa_open(struct tty_struct *tty, struct
> file *filp)
> int port;
>
> port = tty->index;
> - if (port == MAX_PORTS) {
> + if (port == MAX_PORTS)
> return capable(CAP_SYS_ADMIN) ? 0 : -EPERM;
> - }
Put a newline instead here, please.
> if (mutex_lock_interruptible(_openlock))
> return -ERESTARTSYS;
> brd = _boards[port / MAX_PORTS_PER_BOARD];
--
js
suse labs
Re: [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers
Hi Nicolin, On Vi, 2019-01-18 at 11:46 -0800, Nicolin Chen wrote: > On Fri, Jan 18, 2019 at 01:16:24PM +, Viorel Suman wrote: > > > > > > > > > > > > > 1. Moved "dais" node from machine driver DTS node to device > > > > driver > > > > DTS node > > > > as suggested by Rob. > > > That was not what I suggested. You still have a virtual node > > > which > > > looks to me to be unnecessary. > > To me removing virtual node implies that AUDMIX machine driver > > (imx- > > audmix.c + virtual node) shall be removed and machine driver code > > merged into device driver (fsl_audmix.c + device node) - please let > > me > > know if my understanding is wrong. > We could use a non-DT configuration right? From the driver logic, > DT just registers a device corresponding to the machine driver so > that it can probe(). We could register one in fsl_audmix instead. > Please refer to how fsl_ssi registers the sound card device. The > machine driver can get audmix_np from the parent device pointer, > and I think that's all you need. > > Or maybe someone else would provide a better way. But it'd work. Sent V4 - it implements the approach you suggested. Thank you for the hint, works well indeed. Regards, Viorel
[PATCH v2 1/4] mtd: nand: Always store info about bad block markers in chip struct
From: Frieder Schrempf
The information about where the manufacturer puts the bad block
markers inside the bad block and in the OOB data is stored in
different places. Let's move this information to nand_chip.options
and nand_chip.badblockpos.
As this chip-specific information is not directly related to the
bad block table (BBT) and to make them more flexible, we also rename
the flags and create separate flags for storing the BBM in the first
and the second page instead of the combined flag.
Signed-off-by: Frieder.Schrempf
---
drivers/mtd/nand/onenand/onenand_base.c | 2 +-
drivers/mtd/nand/onenand/onenand_bbt.c | 2 +-
drivers/mtd/nand/raw/nand_amd.c | 2 +-
drivers/mtd/nand/raw/nand_base.c| 14 --
drivers/mtd/nand/raw/nand_bbt.c | 5 +++--
drivers/mtd/nand/raw/nand_esmt.c| 2 +-
drivers/mtd/nand/raw/nand_hynix.c | 4 ++--
drivers/mtd/nand/raw/nand_macronix.c| 2 +-
drivers/mtd/nand/raw/nand_micron.c | 2 +-
drivers/mtd/nand/raw/nand_samsung.c | 4 ++--
drivers/mtd/nand/raw/nand_toshiba.c | 2 +-
drivers/mtd/nand/raw/sh_flctl.c | 4 ++--
include/linux/mtd/bbm.h | 14 +-
include/linux/mtd/rawnand.h | 16
14 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/drivers/mtd/nand/onenand/onenand_base.c
b/drivers/mtd/nand/onenand/onenand_base.c
index 4ca4b194e7d7..d6701b8f031f 100644
--- a/drivers/mtd/nand/onenand/onenand_base.c
+++ b/drivers/mtd/nand/onenand/onenand_base.c
@@ -2458,7 +2458,7 @@ static int onenand_default_block_markbad(struct mtd_info
*mtd, loff_t ofs)
bbm->bbt[block >> 2] |= 0x01 << ((block & 0x03) << 1);
/* We write two bytes, so we don't have to mess with 16-bit access */
-ofs += mtd->oobsize + (bbm->badblockpos & ~0x01);
+ofs += mtd->oobsize + (this->badblockpos & ~0x01);
/* FIXME : What to do when marking SLC block in partition
* with MLC erasesize? For now, it is not advisable to
* create partitions containing both SLC and MLC regions.
diff --git a/drivers/mtd/nand/onenand/onenand_bbt.c
b/drivers/mtd/nand/onenand/onenand_bbt.c
index dde20487937d..880b0abd36c8 100644
--- a/drivers/mtd/nand/onenand/onenand_bbt.c
+++ b/drivers/mtd/nand/onenand/onenand_bbt.c
@@ -191,7 +191,7 @@ static int onenand_scan_bbt(struct mtd_info *mtd, struct
nand_bbt_descr *bd)
return -ENOMEM;
/* Set the bad block position */
- bbm->badblockpos = ONENAND_BADBLOCK_POS;
+ this->badblockpos = NAND_BBM_POS_ONENAND;
/* Set erase shift */
bbm->bbt_erase_shift = this->erase_shift;
diff --git a/drivers/mtd/nand/raw/nand_amd.c b/drivers/mtd/nand/raw/nand_amd.c
index 890c5b43e03c..6202cbf7ee8d 100644
--- a/drivers/mtd/nand/raw/nand_amd.c
+++ b/drivers/mtd/nand/raw/nand_amd.c
@@ -40,7 +40,7 @@ static void amd_nand_decode_id(struct nand_chip *chip)
static int amd_nand_init(struct nand_chip *chip)
{
if (nand_is_slc(chip))
- chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
+ chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE;
return 0;
}
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index cca4b24d2ffa..9ef7b86cdc42 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -298,11 +298,12 @@ static int nand_block_bad(struct nand_chip *chip, loff_t
ofs)
int page, page_end, res;
u8 bad;
- if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
+ if (chip->options & NAND_BBM_LASTPAGE)
ofs += mtd->erasesize - mtd->writesize;
page = (int)(ofs >> chip->page_shift) & chip->pagemask;
- page_end = page + (chip->bbt_options & NAND_BBT_SCAN2NDPAGE ? 2 : 1);
+ page_end = page + (((chip->options & NAND_BBM_FIRSTPAGE) &&
+ (chip->options & NAND_BBM_SECONDPAGE)) ? 2 : 1);
for (; page < page_end; page++) {
res = chip->ecc.read_oob(chip, page);
@@ -541,7 +542,7 @@ static int nand_default_block_markbad(struct nand_chip
*chip, loff_t ofs)
ops.mode = MTD_OPS_PLACE_OOB;
/* Write to first/last page(s) if necessary */
- if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
+ if (chip->options & NAND_BBM_LASTPAGE)
ofs += mtd->erasesize - mtd->writesize;
do {
res = nand_do_write_oob(chip, ofs, );
@@ -550,7 +551,8 @@ static int nand_default_block_markbad(struct nand_chip
*chip, loff_t ofs)
i++;
ofs += mtd->writesize;
- } while ((chip->bbt_options & NAND_BBT_SCAN2NDPAGE) && i < 2);
+ } while ((chip->options & NAND_BBM_FIRSTPAGE) &&
+(chip->options & NAND_BBM_SECONDPAGE) && i < 2);
return ret;
}
@@ -4576,9 +4578,9 @@ static void nand_decode_bbm_options(struct nand_chip
*chip)
/* Set the bad
[PATCH v2 3/4] mtd: rawnand: ESMT: Also use the last page for bad block markers
From: Frieder Schrempf
It is known that some ESMT SLC NANDs have been shipped
with the factory bad block markers in the first or last page
of the block, instead of the first or second page. To be on
the safe side, let's check all three locations.
Signed-off-by: Frieder Schrempf
---
drivers/mtd/nand/raw/nand_esmt.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/nand_esmt.c b/drivers/mtd/nand/raw/nand_esmt.c
index 99a8092969a7..b37e0b5af5ae 100644
--- a/drivers/mtd/nand/raw/nand_esmt.c
+++ b/drivers/mtd/nand/raw/nand_esmt.c
@@ -36,7 +36,14 @@ static void esmt_nand_decode_id(struct nand_chip *chip)
static int esmt_nand_init(struct nand_chip *chip)
{
if (nand_is_slc(chip))
- chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE;
+ /*
+* It is known that some ESMT SLC NANDs have been shipped
+* with the factory bad block markers in the first or last page
+* of the block, instead of the first or second page. To be on
+* the safe side, let's check all three locations.
+*/
+ chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE |
+NAND_BBM_LASTPAGE;
return 0;
}
--
2.17.1
[PATCH v2 4/4] mtd: rawnand: AMD: Also use the last page for bad block markers
From: Frieder Schrempf
According to the datasheet of some Cypress SLC NANDs, the bad
block markers can be in the first, second or last page of a block.
So let's check all three locations.
Signed-off-by: Frieder Schrempf
---
drivers/mtd/nand/raw/nand_amd.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/nand_amd.c b/drivers/mtd/nand/raw/nand_amd.c
index 6202cbf7ee8d..2ffcddff3e27 100644
--- a/drivers/mtd/nand/raw/nand_amd.c
+++ b/drivers/mtd/nand/raw/nand_amd.c
@@ -40,7 +40,13 @@ static void amd_nand_decode_id(struct nand_chip *chip)
static int amd_nand_init(struct nand_chip *chip)
{
if (nand_is_slc(chip))
- chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE;
+ /*
+* According to the datasheet of some Cypress SLC NANDs,
+* the bad block markers can be in the first, second or last
+* page of a block. So let's check all three locations.
+*/
+ chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE |
+NAND_BBM_LASTPAGE;
return 0;
}
--
2.17.1
[PATCH v2 0/4] mtd: rawnand: Support bad block markers in first, second or last page
From: Frieder Schrempf Currently supported bad block marker positions within the block are: * in first page only * in last page only * in first or second page Some ESMT NANDs are known to have been shipped by the manufacturer with bad block markers in the first or last page, instead of the first or second page. Also the datasheets for Cypress/Spansion/AMD NANDs claim that the first, second *and* last page needs to be checked. Therefore we make it possible to set NAND_BBT_SCAN2NDPAGE and NAND_BBT_SCANLASTPAGE at the same time to scan/set all three pages. This series also contains patches for AMD/Spansion/Cypress and ESMT chips to enable both flags at the same time. --- Changes in v2: == * Rebase on 5.0-rc1 * Add patch to move bad block marker position info to a common place and rename/prepare existing flags * improve/rename function nand_bbm_get_next_page() to use new flags --- Frieder Schrempf (4): mtd: nand: Always store info about bad block markers in chip struct mtd: rawnand: Support bad block markers in first, second or last page mtd: rawnand: ESMT: Also use the last page for bad block markers mtd: rawnand: AMD: Also use the last page for bad block markers drivers/mtd/nand/onenand/onenand_base.c | 2 +- drivers/mtd/nand/onenand/onenand_bbt.c | 2 +- drivers/mtd/nand/raw/internals.h| 1 + drivers/mtd/nand/raw/nand_amd.c | 8 +++- drivers/mtd/nand/raw/nand_base.c| 64 + drivers/mtd/nand/raw/nand_bbt.c | 28 +-- drivers/mtd/nand/raw/nand_esmt.c| 9 +++- drivers/mtd/nand/raw/nand_hynix.c | 4 +- drivers/mtd/nand/raw/nand_macronix.c| 2 +- drivers/mtd/nand/raw/nand_micron.c | 2 +- drivers/mtd/nand/raw/nand_samsung.c | 4 +- drivers/mtd/nand/raw/nand_toshiba.c | 2 +- drivers/mtd/nand/raw/sh_flctl.c | 4 +- include/linux/mtd/bbm.h | 14 +- include/linux/mtd/rawnand.h | 16 +++ 15 files changed, 100 insertions(+), 62 deletions(-) -- 2.17.1
[PATCH v2 2/4] mtd: rawnand: Support bad block markers in first, second or last page
From: Frieder Schrempf
Currently supported bad block marker positions within the block are:
* in first page only
* in last page only
* in first or second page
Some ESMT NANDs are known to have been shipped by the manufacturer
with bad block markers in the first or last page, instead of the
first or second page.
Also the datasheets for Cypress/Spansion/AMD NANDs claim that the
first, second *and* last page needs to be checked.
Therefore we make it possible to set NAND_BBM_FIRSTPAGE,
NAND_BBM_SECONDPAGE and NAND_BBM_LASTPAGE independently in any
combination.
To simplify the code, the logic to evaluate the flags is moved to a
a new function nand_bbm_get_next_page().
Signed-off-by: Frieder Schrempf
---
drivers/mtd/nand/raw/internals.h | 1 +
drivers/mtd/nand/raw/nand_base.c | 62 ---
drivers/mtd/nand/raw/nand_bbt.c | 29 +++-
3 files changed, 55 insertions(+), 37 deletions(-)
diff --git a/drivers/mtd/nand/raw/internals.h b/drivers/mtd/nand/raw/internals.h
index fbf6ca015cd7..97ae67e009d5 100644
--- a/drivers/mtd/nand/raw/internals.h
+++ b/drivers/mtd/nand/raw/internals.h
@@ -76,6 +76,7 @@ extern const struct nand_manufacturer_ops
toshiba_nand_manuf_ops;
/* Core functions */
const struct nand_manufacturer *nand_get_manufacturer(u8 id);
+int nand_bbm_get_next_page(struct nand_chip *chip, int page);
int nand_markbad_bbm(struct nand_chip *chip, loff_t ofs);
int nand_erase_nand(struct nand_chip *chip, struct erase_info *instr,
int allowbbt);
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 9ef7b86cdc42..7bc20c1fe23c 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -285,6 +285,31 @@ static void nand_release_device(struct nand_chip *chip)
spin_unlock(>controller->lock);
}
+/**
+ * nand_bbm_get_next_page - Get the next page for bad block markers
+ * @chip: NAND chip object
+ * @index: Current page, only pages beyond this will be considered
+ *
+ * Returns an integer that corresponds to the page offset within a block, for
+ * a page that is used to store bad block markers. If no more pages are
+ * available, -1 is returned.
+ */
+int nand_bbm_get_next_page(struct nand_chip *chip, int page)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ int last_page = ((mtd->erasesize - mtd->writesize) >>
+chip->page_shift) & chip->pagemask;
+
+ if (page < 0 && chip->options & NAND_BBM_FIRSTPAGE)
+ return 0;
+ else if (page < 1 && chip->options & NAND_BBM_SECONDPAGE)
+ return 1;
+ else if (page < last_page && chip->options & NAND_BBM_LASTPAGE)
+ return last_page;
+
+ return -1;
+}
+
/**
* nand_block_bad - [DEFAULT] Read bad block marker from the chip
* @chip: NAND chip object
@@ -294,19 +319,14 @@ static void nand_release_device(struct nand_chip *chip)
*/
static int nand_block_bad(struct nand_chip *chip, loff_t ofs)
{
- struct mtd_info *mtd = nand_to_mtd(chip);
- int page, page_end, res;
+ int page_offset;
+ int res, first_page = (int)(ofs >> chip->page_shift) & chip->pagemask;
u8 bad;
- if (chip->options & NAND_BBM_LASTPAGE)
- ofs += mtd->erasesize - mtd->writesize;
+ page_offset = nand_bbm_get_next_page(chip, -1);
- page = (int)(ofs >> chip->page_shift) & chip->pagemask;
- page_end = page + (((chip->options & NAND_BBM_FIRSTPAGE) &&
- (chip->options & NAND_BBM_SECONDPAGE)) ? 2 : 1);
-
- for (; page < page_end; page++) {
- res = chip->ecc.read_oob(chip, page);
+ while (page_offset != -1) {
+ res = chip->ecc.read_oob(chip, first_page + page_offset);
if (res < 0)
return res;
@@ -318,6 +338,8 @@ static int nand_block_bad(struct nand_chip *chip, loff_t
ofs)
res = hweight8(bad) < chip->badblockbits;
if (res)
return res;
+
+ page_offset = nand_bbm_get_next_page(chip, page_offset);
}
return 0;
@@ -528,7 +550,7 @@ static int nand_default_block_markbad(struct nand_chip
*chip, loff_t ofs)
struct mtd_info *mtd = nand_to_mtd(chip);
struct mtd_oob_ops ops;
uint8_t buf[2] = { 0, 0 };
- int ret = 0, res, i = 0;
+ int ret = 0, res, page_offset;
memset(, 0, sizeof(ops));
ops.oobbuf = buf;
@@ -541,18 +563,18 @@ static int nand_default_block_markbad(struct nand_chip
*chip, loff_t ofs)
}
ops.mode = MTD_OPS_PLACE_OOB;
- /* Write to first/last page(s) if necessary */
- if (chip->options & NAND_BBM_LASTPAGE)
- ofs += mtd->erasesize - mtd->writesize;
- do {
- res = nand_do_write_oob(chip, ofs, );
+ page_offset = nand_bbm_get_next_page(chip, -1);
+
+ while (page_offset != -1) {
Re: [PATCH v6 08/16] sched/cpufreq: uclamp: Add utilization clamping for FAIR tasks
On 22-Jan 12:04, Rafael J. Wysocki wrote: > On Tue, Jan 22, 2019 at 12:02 PM Patrick Bellasi > wrote: > > > > On 22-Jan 11:37, Rafael J. Wysocki wrote: > > > On Tuesday, January 15, 2019 11:15:05 AM CET Patrick Bellasi wrote: > > Merge the two together, please. Ok, will do in v7, thanks. -- #include Patrick Bellasi
Re: [GIT PULL 0/7] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > Regards, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 4e72ee8872279a70ebe973172133b98e8acbf54e: > > Merge tag 'perf-core-for-mingo-5.0-20190110' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent > (2019-01-11 08:12:09 +0100) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-5.0-20190121 > > for you to fetch changes up to 8bf8c6da53c2265aea365a1de6038f118f522113: > > perf script: Fix crash when processing recorded stat data (2019-01-21 > 11:29:07 -0300) > > > perf/urgent fixes: > > Kernel: > > Stephane Eranian: > > - Fix perf_proc_update_handler() bug. > > perf script: > > Andi Kleen: > > - Fix crash with printing mixed trace point and other events. > > Tony Jones: > > - Fix crash when processing recorded stat data. > > perf top: > > He Kuang: > > - Fix wrong hottest instruction highlighted. > > perf python: > > Arnaldo Carvalho de Melo: > > - Remove -fstack-clash-protection when building with some clang versions. > > perf ordered_events: > > Jiri Olsa: > > - Fix out of buffers crash in ordered_events__free(). > > perf cpu_map: > > Stephane Eranian: > > - Handle TOPOLOGY headers with no CPU. > > Signed-off-by: Arnaldo Carvalho de Melo > > > Andi Kleen (1): > perf script: Fix crash with printing mixed trace point and other events > > Arnaldo Carvalho de Melo (1): > perf python: Remove -fstack-clash-protection when building with some > clang versions > > He Kuang (1): > perf top: Fix wrong hottest instruction highlighted > > Jiri Olsa (1): > perf ordered_events: Fix crash in ordered_events__free > > Stephane Eranian (2): > perf core: Fix perf_proc_update_handler() bug > perf tools: Handle TOPOLOGY headers with no CPU > > Tony Jones (1): > perf script: Fix crash when processing recorded stat data > > kernel/events/core.c | 14 +++--- > tools/perf/builtin-script.c | 9 +++-- > tools/perf/ui/browsers/annotate.c | 16 ++-- > tools/perf/util/cpumap.c | 11 +-- > tools/perf/util/ordered-events.c | 6 -- > tools/perf/util/setup.py | 2 ++ > 6 files changed, 35 insertions(+), 23 deletions(-) Pulled, thanks a lot Arnaldo! Ingo
[tip:perf/urgent] perf ordered_events: Fix crash in ordered_events__free
Commit-ID: 99d86c8b88393e29cf07c020585f2c8afbcdd97d
Gitweb: https://git.kernel.org/tip/99d86c8b88393e29cf07c020585f2c8afbcdd97d
Author: Jiri Olsa
AuthorDate: Thu, 17 Jan 2019 12:30:17 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 17 Jan 2019 11:07:00 -0300
perf ordered_events: Fix crash in ordered_events__free
Song Liu reported crash in 'perf record':
> #0 0x00500055 in ordered_events(float, long double,...)(...) ()
> #1 0x00500196 in ordered_events.reinit ()
> #2 0x004fe413 in perf_session.process_events ()
> #3 0x00440431 in cmd_record ()
> #4 0x004a439f in run_builtin ()
> #5 0x0042b3e5 in main ()"
This can happen when we get out of buffers during event processing.
The subsequent ordered_events__free() call assumes oe->buffer != NULL
and crashes. Add a check to prevent that.
Reported-by: Song Liu
Signed-off-by: Jiri Olsa
Reviewed-by: Song Liu
Tested-by: Song Liu
Cc: Alexander Shishkin
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/20190117113017.12977-1-jo...@kernel.org
Fixes: d5ceb62b3654 ("perf ordered_events: Add 'struct ordered_events_buffer'
layer")
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/ordered-events.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 897589507d97..ea523d3b248f 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -391,8 +391,10 @@ void ordered_events__free(struct ordered_events *oe)
* Current buffer might not have all the events allocated
* yet, we need to free only allocated ones ...
*/
- list_del(>buffer->list);
- ordered_events_buffer__free(oe->buffer, oe->buffer_idx, oe);
+ if (oe->buffer) {
+ list_del(>buffer->list);
+ ordered_events_buffer__free(oe->buffer, oe->buffer_idx, oe);
+ }
/* ... and continue with the rest */
list_for_each_entry_safe(buffer, tmp, >to_free, list) {
[tip:perf/urgent] perf script: Fix crash with printing mixed trace point and other events
Commit-ID: 96167167b6e17b25c0e05ecc31119b73baeab094
Gitweb: https://git.kernel.org/tip/96167167b6e17b25c0e05ecc31119b73baeab094
Author: Andi Kleen
AuthorDate: Thu, 17 Jan 2019 11:48:34 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 18 Jan 2019 09:53:07 -0300
perf script: Fix crash with printing mixed trace point and other events
'perf script' crashes currently when printing mixed trace points and
other events because the trace format does not handle events without
trace meta data. Add a simple check to avoid that.
% cat > test.c
main()
{
printf("Hello world\n");
}
^D
% gcc -g -o test test.c
% sudo perf probe -x test 'test.c:3'
% perf record -e '{cpu/cpu-cycles,period=1/,probe_test:main}:S' ./test
% perf script
Committer testing:
Before:
# perf probe -x /lib64/libc-2.28.so malloc
Added new event:
probe_libc:malloc(on malloc in /usr/lib64/libc-2.28.so)
You can now use it in all perf tools, such as:
perf record -e probe_libc:malloc -aR sleep 1
# perf probe -l
probe_libc:malloc(on __libc_malloc@malloc/malloc.c in
/usr/lib64/libc-2.28.so)
# perf record -e '{cpu/cpu-cycles,period=1/,probe_libc:*}:S' sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.023 MB perf.data (40 samples) ]
# perf script
Segmentation fault (core dumped)
^C
#
After:
# perf script | head -6
sleep 2888 94796.944981: 16198 cpu/cpu-cycles,period=1/:
925dc04f get_random_u32+0x1f (/lib/modules/5.0.0-rc2+/build/vmlinux)
sleep 2888 [-01] 94796.944981: probe_libc:malloc:
sleep 2888 94796.944983: 4713 cpu/cpu-cycles,period=1/:
922763af change_protection+0xcf (/lib/modules/5.0.0-rc2+/build/vmlinux)
sleep 2888 [-01] 94796.944983: probe_libc:malloc:
sleep 2888 94796.944986: 9934 cpu/cpu-cycles,period=1/:
922777e0 move_page_tables+0x0 (/lib/modules/5.0.0-rc2+/build/vmlinux)
sleep 2888 [-01] 94796.944986: probe_libc:malloc:
#
Signed-off-by: Andi Kleen
Tested-by: Arnaldo Carvalho de Melo
Acked-by: Jiri Olsa
Link: http://lkml.kernel.org/r/20190117194834.21940-1-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index d079f36d342d..357906ed1898 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1794,7 +1794,7 @@ static void process_event(struct perf_script *script,
return;
}
- if (PRINT_FIELD(TRACE)) {
+ if (PRINT_FIELD(TRACE) && sample->raw_data) {
event_format__fprintf(evsel->tp_format, sample->cpu,
sample->raw_data, sample->raw_size, fp);
}
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi
On 2018/12/04 22:32, Rob Herring wrote:
On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
wrote:
Hi
On 2018/12/04 0:49, Rob Herring wrote:
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
wrote:
Hi,
On 2018/11/30 17:16, Stephen Boyd wrote:
Quoting Sugaya, Taichi (2018-11-29 04:24:51)
On 2018/11/28 11:01, Stephen Boyd wrote:
Quoting Sugaya Taichi (2018-11-18 17:01:07)
create mode 100644
Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
new file mode 100644
index 000..f5d906c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
@@ -0,0 +1,12 @@
+Socionext M10V SMP trampoline driver binding
+
+This is a driver to wait for sub-cores while boot process.
+
+- compatible: should be "socionext,smp-trampoline"
+- reg: should be <0x4C000100 0x100>
+
+EXAMPLE
+ trampoline: trampoline@0x4C000100 {
Drop the 0x part of unit addresses.
Okay.
+ compatible = "socionext,smp-trampoline";
+ reg = <0x4C000100 0x100>;
Looks like a software construct, which we wouldn't want to put into DT
this way. DT doesn't describe drivers.
We would like to use this node only getting the address of the
trampoline area
in which sub-cores wait. (They have finished to go to this area in previous
bootloader process.)
Is this area part of memory, or a special SRAM? If it's part of memory,
I would expect this node to be under the reserved-memory node and
pointed to by some other node that uses this region. Could even be the
CPU nodes.
Yes, 0x4C000100 is a part of memory under the reserved-memory node. So
we would like to use the SRAM ( allocated 0x ) area instead.
BTW, sorry, the trampoline address of this example is simply wrong. We
were going to use a part of the SRAM from the beginning.
So should we embed the constant value in source codes instead of getting
from
DT because the address is constant at the moment? Or is there other
approach?
If it's constant then that also works. Why does it need to come from DT
at all then?
We think it is not good to embed constant value in driver codes and do
not have another way...
Are there better ways?
If this is just memory, can you use the standard spin-table binding in
the DT spec? There are some requirements like 64-bit values even on
32-bit machines (though this gets violated).
The spin-table seems to be used on only 64-bit arch. Have it ever worked
on 32-bit machine?
Yes.
And I would like not to use it because avoid violation.
The issue now that I remember is cpu-release-addr is defined to always
be a 64-bit value while some platforms made it a 32-bit value.
'cpu-release-addr' is also used for some other enable-methods.
I have a question about the spin-table.
The code "smp_spin_table.c" is only in "arch/arm64/kernel" directory so
can not be compiled in arm-v7 arch. That means the spin-table can not be
used arm-v7 arch..? , or is there the way to compile the code in arm-v7
arch?
Thanks,
Sugaya Taichi
Rob
[PATCH] firmware: arm_scmi: provide the mandatory device release callback
The device/driver model clearly mandates that bus driver that discover
and allocate the device must set the release callback. This callback
will be used to free the device after all references have gone away.
scmi bus driver is missing the obvious callback which will result in
the following warning if the device is unregistered:
Device 'scmi_dev.1' does not have a release() function, it is broken and
must be fixed. See Documentation/kobject.txt.
WARNING at drivers/base/core.c:922 device_release+0x8c/0xa0
Hardware name: ARM LTD Juno Development Platform BIOS EDK II Jan 21 2019
Workqueue: events deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO)
pc : device_release+0x8c/0xa0
lr : device_release+0x8c/0xa0
Call trace:
device_release+0x8c/0xa0
kobject_put+0x8c/0x208
device_unregister+0x30/0x78
scmi_device_destroy+0x28/0x50
scmi_probe+0x354/0x5b0
platform_drv_probe+0x58/0xa8
really_probe+0x2c4/0x3e8
driver_probe_device+0x12c/0x148
__device_attach_driver+0xac/0x150
bus_for_each_drv+0x78/0xd8
__device_attach+0xe0/0x168
device_initial_probe+0x24/0x30
bus_probe_device+0xa0/0xa8
deferred_probe_work_func+0x8c/0xe0
process_one_work+0x1f0/0x478
worker_thread+0x22c/0x450
kthread+0x134/0x138
ret_from_fork+0x10/0x1c
---[ end trace 420bdb7f6af50937 ]---
Fix the issue by providing scmi_device_release callback. We have
everything required for device release already in scmi_device_destroy,
so we just need to move freeing of the device to scmi_device_release.
Fixes: 933c504424a2 ("firmware: arm_scmi: add scmi protocol bus to enumerate
protocol devices")
Signed-off-by: Sudeep Holla
---
drivers/firmware/arm_scmi/bus.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Hi ARM-SoC team,
Can you apply this one patch directly or I can send pull request if you
prefer ?
Regards,
Sudeep
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 472c88ae1c0f..92f843eaf1e0 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -119,6 +119,11 @@ void scmi_driver_unregister(struct scmi_driver *driver)
}
EXPORT_SYMBOL_GPL(scmi_driver_unregister);
+static void scmi_device_release(struct device *dev)
+{
+ kfree(to_scmi_dev(dev));
+}
+
struct scmi_device *
scmi_device_create(struct device_node *np, struct device *parent, int protocol)
{
@@ -138,6 +143,7 @@ scmi_device_create(struct device_node *np, struct device
*parent, int protocol)
scmi_dev->dev.parent = parent;
scmi_dev->dev.of_node = np;
scmi_dev->dev.bus = _bus_type;
+ scmi_dev->dev.release = scmi_device_release;
dev_set_name(_dev->dev, "scmi_dev.%d", id);
retval = device_register(_dev->dev);
@@ -156,9 +162,8 @@ scmi_device_create(struct device_node *np, struct device
*parent, int protocol)
void scmi_device_destroy(struct scmi_device *scmi_dev)
{
scmi_handle_put(scmi_dev->handle);
- device_unregister(_dev->dev);
ida_simple_remove(_bus_id, scmi_dev->id);
- kfree(scmi_dev);
+ device_unregister(_dev->dev);
}
void scmi_set_handle(struct scmi_device *scmi_dev)
--
2.17.1
[tip:perf/urgent] perf core: Fix perf_proc_update_handler() bug
Commit-ID: 1a51c5da5acc6c188c917ba572eebac5f8793432
Gitweb: https://git.kernel.org/tip/1a51c5da5acc6c188c917ba572eebac5f8793432
Author: Stephane Eranian
AuthorDate: Thu, 10 Jan 2019 17:17:16 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 18 Jan 2019 11:10:38 -0300
perf core: Fix perf_proc_update_handler() bug
The perf_proc_update_handler() handles
/proc/sys/kernel/perf_event_max_sample_rate
syctl variable. When the PMU IRQ handler timing monitoring is disabled, i.e,
when /proc/sys/kernel/perf_cpu_time_max_percent is equal to 0 or 100,
then no modification to sysctl_perf_event_sample_rate is allowed to prevent
possible hang from wrong values.
The problem is that the test to prevent modification is made after the
sysctl variable is modified in perf_proc_update_handler().
You get an error:
$ echo 10001 >/proc/sys/kernel/perf_event_max_sample_rate
echo: write error: invalid argument
But the value is still modified causing all sorts of inconsistencies:
$ cat /proc/sys/kernel/perf_event_max_sample_rate
10001
This patch fixes the problem by moving the parsing of the value after
the test.
Committer testing:
# echo 100 > /proc/sys/kernel/perf_cpu_time_max_percent
# echo 10001 > /proc/sys/kernel/perf_event_max_sample_rate
-bash: echo: write error: Invalid argument
# cat /proc/sys/kernel/perf_event_max_sample_rate
10001
#
Signed-off-by: Stephane Eranian
Reviewed-by: Andi Kleen
Reviewed-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Kan Liang
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1547169436-6266-1-git-send-email-eran...@google.com
Signed-off-by: Arnaldo Carvalho de Melo
---
kernel/events/core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 3cd13a30f732..e5ede6918050 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -436,18 +436,18 @@ int perf_proc_update_handler(struct ctl_table *table, int
write,
void __user *buffer, size_t *lenp,
loff_t *ppos)
{
- int ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
-
- if (ret || !write)
- return ret;
-
+ int ret;
+ int perf_cpu = sysctl_perf_cpu_time_max_percent;
/*
* If throttling is disabled don't allow the write:
*/
- if (sysctl_perf_cpu_time_max_percent == 100 ||
- sysctl_perf_cpu_time_max_percent == 0)
+ if (write && (perf_cpu == 100 || perf_cpu == 0))
return -EINVAL;
+ ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
+ if (ret || !write)
+ return ret;
+
max_samples_per_tick = DIV_ROUND_UP(sysctl_perf_event_sample_rate, HZ);
perf_sample_period_ns = NSEC_PER_SEC / sysctl_perf_event_sample_rate;
update_perf_cpu_limits();
[tip:perf/urgent] perf top: Fix wrong hottest instruction highlighted
Commit-ID: da06d568386877809532e8ec678f4a5e300f0951
Gitweb: https://git.kernel.org/tip/da06d568386877809532e8ec678f4a5e300f0951
Author: He Kuang
AuthorDate: Mon, 21 Jan 2019 00:05:22 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 21 Jan 2019 11:29:07 -0300
perf top: Fix wrong hottest instruction highlighted
The annotation line percentage is compared and inserted into the rbtree,
but the percent field of 'struct annotation_data' is an array, the
comparison result between them is the address difference.
This patch compares the right slot of percent array according to
opts->percent_type and makes things right.
The problem can be reproduced by pressing 'H' in perf top annotation view.
It should highlight the instruction line which has the highest sampling
percentage.
Signed-off-by: He Kuang
Reviewed-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190120160523.4391-1-heku...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/annotate.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index 1d00e5ec7906..82e16bf84466 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -224,20 +224,24 @@ static unsigned int annotate_browser__refresh(struct
ui_browser *browser)
return ret;
}
-static int disasm__cmp(struct annotation_line *a, struct annotation_line *b)
+static double disasm__cmp(struct annotation_line *a, struct annotation_line *b,
+ int percent_type)
{
int i;
for (i = 0; i < a->data_nr; i++) {
- if (a->data[i].percent == b->data[i].percent)
+ if (a->data[i].percent[percent_type] ==
b->data[i].percent[percent_type])
continue;
- return a->data[i].percent < b->data[i].percent;
+ return a->data[i].percent[percent_type] -
+ b->data[i].percent[percent_type];
}
return 0;
}
-static void disasm_rb_tree__insert(struct rb_root *root, struct
annotation_line *al)
+static void disasm_rb_tree__insert(struct annotate_browser *browser,
+ struct annotation_line *al)
{
+ struct rb_root *root = >entries;
struct rb_node **p = >rb_node;
struct rb_node *parent = NULL;
struct annotation_line *l;
@@ -246,7 +250,7 @@ static void disasm_rb_tree__insert(struct rb_root *root,
struct annotation_line
parent = *p;
l = rb_entry(parent, struct annotation_line, rb_node);
- if (disasm__cmp(al, l))
+ if (disasm__cmp(al, l, browser->opts->percent_type) < 0)
p = &(*p)->rb_left;
else
p = &(*p)->rb_right;
@@ -329,7 +333,7 @@ static void annotate_browser__calc_percent(struct
annotate_browser *browser,
RB_CLEAR_NODE(>al.rb_node);
continue;
}
- disasm_rb_tree__insert(>entries, >al);
+ disasm_rb_tree__insert(browser, >al);
}
pthread_mutex_unlock(>lock);
[tip:perf/urgent] perf tools: Handle TOPOLOGY headers with no CPU
Commit-ID: 1497e804d1a6e2bd9107ddf64b0310449f4673eb
Gitweb: https://git.kernel.org/tip/1497e804d1a6e2bd9107ddf64b0310449f4673eb
Author: Stephane Eranian
AuthorDate: Sat, 19 Jan 2019 00:12:39 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 21 Jan 2019 11:28:56 -0300
perf tools: Handle TOPOLOGY headers with no CPU
This patch fixes an issue in cpumap.c when used with the TOPOLOGY
header. In some configurations, some NUMA nodes may have no CPU (empty
cpulist). Yet a cpumap map must be created otherwise perf abort with an
error. This patch handles this case by creating a dummy map.
Before:
$ perf record -o - -e cycles noploop 2 | perf script -i -
0x6e8 [0x6c]: failed to process type: 80
After:
$ perf record -o - -e cycles noploop 2 | perf script -i -
noploop for 2 seconds
Signed-off-by: Stephane Eranian
Acked-by: Jiri Olsa
Cc: Andi Kleen
Cc: Kan Liang
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1547885559-1657-1-git-send-email-eran...@google.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/cpumap.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
index 1ccbd3342069..383674f448fc 100644
--- a/tools/perf/util/cpumap.c
+++ b/tools/perf/util/cpumap.c
@@ -134,7 +134,12 @@ struct cpu_map *cpu_map__new(const char *cpu_list)
if (!cpu_list)
return cpu_map__read_all_cpu_map();
- if (!isdigit(*cpu_list))
+ /*
+* must handle the case of empty cpumap to cover
+* TOPOLOGY header for NUMA nodes with no CPU
+* ( e.g., because of CPU hotplug)
+*/
+ if (!isdigit(*cpu_list) && *cpu_list != '\0')
goto out;
while (isdigit(*cpu_list)) {
@@ -181,8 +186,10 @@ struct cpu_map *cpu_map__new(const char *cpu_list)
if (nr_cpus > 0)
cpus = cpu_map__trim_new(nr_cpus, tmp_cpus);
- else
+ else if (*cpu_list != '\0')
cpus = cpu_map__default_new();
+ else
+ cpus = cpu_map__dummy_new();
invalid:
free(tmp_cpus);
out:
[tip:perf/urgent] perf script: Fix crash when processing recorded stat data
Commit-ID: 8bf8c6da53c2265aea365a1de6038f118f522113
Gitweb: https://git.kernel.org/tip/8bf8c6da53c2265aea365a1de6038f118f522113
Author: Tony Jones
AuthorDate: Sun, 20 Jan 2019 11:14:14 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 21 Jan 2019 11:29:07 -0300
perf script: Fix crash when processing recorded stat data
While updating perf to work with Python3 and Python2 I noticed that the
stat-cpi script was dumping core.
$ perf stat -e cycles,instructions record -o /tmp/perf.data /bin/false
Performance counter stats for '/bin/false':
802,148 cycles
604,622 instructions
802,148 cycles
604,622 instructions
0.001445842 seconds time elapsed
$ perf script -i /tmp/perf.data -s scripts/python/stat-cpi.py
Segmentation fault (core dumped)
...
...
rblist=rblist@entry=0xb2a200 ,
new_entry=new_entry@entry=0x7ffcb755c310) at util/rblist.c:33
ctx=, type=, create=,
cpu=, evsel=) at util/stat-shadow.c:118
ctx=, type=, st=)
at util/stat-shadow.c:196
count=count@entry=727442, cpu=cpu@entry=0, st=0xb2a200 )
at util/stat-shadow.c:239
config=config@entry=0xafeb40 ,
counter=counter@entry=0x133c6e0) at util/stat.c:372
...
...
The issue is that since 1fcd03946b52 perf_stat__update_shadow_stats now calls
update_runtime_stat passing rt_stat rather than calling update_stats but
perf_stat__init_shadow_stats has never been called to initialize rt_stat in
the script path processing recorded stat data.
Since I can't see any reason why perf_stat__init_shadow_stats() is presently
initialized like it is in builtin-script.c::perf_sample__fprint_metric()
[4bd1bef8bba2f] I'm proposing it instead be initialized once in __cmd_script
Committer testing:
After applying the patch:
# perf script -i /tmp/perf.data -s tools/perf/scripts/python/stat-cpi.py
0.001970: cpu -1, thread -1 -> cpi 1.709079 (1075684/629394)
#
No segfault.
Signed-off-by: Tony Jones
Reviewed-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Tested-by: Ravi Bangoria
Cc: Andi Kleen
Cc: Jin Yao
Fixes: 1fcd03946b52 ("perf stat: Update per-thread shadow stats")
Link: http://lkml.kernel.org/r/20190120191414.12925-1-to...@suse.de
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 357906ed1898..ac221f137ed2 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1681,13 +1681,8 @@ static void perf_sample__fprint_metric(struct
perf_script *script,
.force_header = false,
};
struct perf_evsel *ev2;
- static bool init;
u64 val;
- if (!init) {
- perf_stat__init_shadow_stats();
- init = true;
- }
if (!evsel->stats)
perf_evlist__alloc_stats(script->session->evlist, false);
if (evsel_script(evsel->leader)->gnum++ == 0)
@@ -2359,6 +2354,8 @@ static int __cmd_script(struct perf_script *script)
signal(SIGINT, sig_handler);
+ perf_stat__init_shadow_stats();
+
/* override event processing functions */
if (script->show_task_events) {
script->tool.comm = process_comm_event;
RE: [PATCH v3] pinctrl: freescale: fix link errors
> From: Anders Roxell [mailto:anders.rox...@linaro.org] > Sent: Tuesday, January 22, 2019 4:38 PM > > Subject: [PATCH v3] pinctrl: freescale: fix link errors Please change to: pinctrl: imx: fix scu link errors > Fix link errors when PINCTRL_IMX_SCU, PINCTRL_IMX8QM or > PINCTRL_IMXBQXP is enabled as a module and the dependent module is > built-in. Non of them can be built as module. I think the problem is that the dependent module IMX_SCU is not build in, right? So you need update the commit message. > > ld: drivers/pinctrl/freescale/pinctrl-scu.o: in function > `imx_pinctrl_sc_ipc_init': > pinctrl-scu.c:(.text+0x10): undefined reference to `imx_scu_get_handle' > ld: pinctrl-scu.c:(.text+0x10): relocation truncated to fit: R_AARCH64_CALL26 > against undefined symbol `imx_scu_get_handle' > ld: drivers/pinctrl/freescale/pinctrl-scu.o: in function > `imx_pinconf_get_scu': > pinctrl-scu.c:(.text+0xa0): undefined reference to `imx_scu_call_rpc' > ld: pinctrl-scu.c:(.text+0xa0): relocation truncated to fit: R_AARCH64_CALL26 > against undefined symbol `imx_scu_call_rpc' > ld: drivers/pinctrl/freescale/pinctrl-scu.o: in function > `imx_pinconf_set_scu': > pinctrl-scu.c:(.text+0x1b4): undefined reference to `imx_scu_call_rpc' > ld: pinctrl-scu.c:(.text+0x1b4): relocation truncated to fit: R_AARCH64_CALL26 > against undefined symbol `imx_scu_call_rpc' > ld: drivers/pinctrl/freescale/pinctrl-imx8qxp.o: in function > `imx8qxp_pinctrl_probe': > pinctrl-imx8qxp.c:(.text+0x28): undefined reference to `imx_pinctrl_probe' > ld: pinctrl-imx8qxp.c:(.text+0x28): relocation truncated to fit: > R_AARCH64_CALL26 against undefined symbol `imx_pinctrl_probe' > > Rework so that PINCTRL_IMX_SCU and the config's that 'select > PINCTRL_IMX_SCU' depends on IMX_SCU=y. Update here as well > > Suggested-by: Arnd Bergmann > Signed-off-by: Anders Roxell > --- > drivers/pinctrl/freescale/Kconfig | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/pinctrl/freescale/Kconfig > b/drivers/pinctrl/freescale/Kconfig > index b318c24b61be..af141dd2331d 100644 > --- a/drivers/pinctrl/freescale/Kconfig > +++ b/drivers/pinctrl/freescale/Kconfig > @@ -7,7 +7,7 @@ config PINCTRL_IMX > > config PINCTRL_IMX_SCU > bool > - depends on IMX_SCU > + depends on IMX_SCU=y You don't need =y here. Otherwise, you can add my tag when you resent. Acked-by: Dong Aisheng Regards Dong Aisheng > select PINCTRL_IMX > > config PINCTRL_IMX1_CORE > @@ -131,14 +131,14 @@ config PINCTRL_IMX8MQ > > config PINCTRL_IMX8QM > bool "IMX8QM pinctrl driver" > - depends on ARCH_MXC && ARM64 > + depends on IMX_SCU && ARCH_MXC && ARM64 > select PINCTRL_IMX_SCU > help > Say Y here to enable the imx8qm pinctrl driver > > config PINCTRL_IMX8QXP > bool "IMX8QXP pinctrl driver" > - depends on ARCH_MXC && ARM64 > + depends on IMX_SCU && ARCH_MXC && ARM64 > select PINCTRL_IMX_SCU > help > Say Y here to enable the imx8qxp pinctrl driver > -- > 2.19.2
Re: [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers
Hi Rob, On Lu, 2019-01-21 at 09:23 -0600, Rob Herring wrote: > On Fri, Jan 18, 2019 at 11:46:42AM -0800, Nicolin Chen wrote: > > > > On Fri, Jan 18, 2019 at 01:16:24PM +, Viorel Suman wrote: > > > > > > > > > > > > > > > > > 1. Moved "dais" node from machine driver DTS node to device > > > > > driver > > > > > DTS node > > > > > as suggested by Rob. > > > > That was not what I suggested. You still have a virtual node > > > > which > > > > looks to me to be unnecessary. > > > To me removing virtual node implies that AUDMIX machine driver > > > (imx- > > > audmix.c + virtual node) shall be removed and machine driver code > > > merged into device driver (fsl_audmix.c + device node) - please > > > let me > > > know if my understanding is wrong. > > We could use a non-DT configuration right? From the driver logic, > > DT just registers a device corresponding to the machine driver so > > that it can probe(). We could register one in fsl_audmix instead. > > Please refer to how fsl_ssi registers the sound card device. The > > machine driver can get audmix_np from the parent device pointer, > > and I think that's all you need. > Yes. Thank you, sent V4 which implements the approach suggested by Nicolin. > > > > > Or maybe someone else would provide a better way. But it'd work. > Or the machine driver could create the audmix device. That probably > makes less sense, but either way there doesn't have to be a 1-1 > correspondence of DT nodes and (platform) devices. > > I'm not an ASoC expert, but why can't the machine driver just control > the audmix directly (with DAIs as separate drivers)? Is the audmix > ever going to a be a component for a different machine driver? > > Rob Currently I'm not aware of any information with regard to if audmix is ever going to work with other DAIs than SAI. Howerver from audmix IP block integration perspective the only requirement is that the input DAI must be connected to audmix over I2S bus, possible DAI options are SAI, ESAI, etc - I think the approach to mix both device and machine drivers into a single entity is not the best way to go. /Viorel
Re: [PATCH 1/1] irqchip: gpcv2: make config option visible
On Tue, 22 Jan 2019 11:04:48 +, Aisheng Dong wrote: > > > > > From: Marc Zyngier [mailto:marc.zyng...@arm.com] > > Sent: Friday, January 18, 2019 6:10 PM > [...] > > >>> > > >>> config IMX_GPCV2 > > >>> - bool > > >>> + bool "i.MX GPCv2 IRQ chip" > > >>> + depends on ARCH_MXC || (COMPILE_TEST && OF) > > >>> select IRQ_DOMAIN > > >>> help > > >>> Enables the wakeup IRQs for IMX platforms with GPCv2 block > > >>> > > >> > > >> How does it help exactly? It is pretty difficult for a user to know > > >> exactly what they need. I'd rather see it selected by ARCH_MXC, which > > >> makes it > > > > > > ARM64 SoC maintainers suggest not add more driver specific options > > > except an Generic ARCH option. > > > > > > As GPCv2 is also used in MX8MQ. So we may select it in armv8 defconfig. > > > If this option is invisible, we can't select it. > > > > And conversely, users have no idea of what letter soup they have to select > > to > > make their HW work properly. Selecting the driver when the platform is > > supposed to be supported is the right way to solve this problem. > > > > I think the problem is that we have no platform specific CONFIGs for arm v8 > platforms. > We have only one CONFIG_ARCH_MXC for all MX8 SoCs, e.g. mx8qxp, mx8mq... > Only MX8MQ needs to use GPCv2. Selecting GPCv2 under ARCH_MXC means users > have no chance to disable it for mx8qxp which does not need it. And where is the problem to select this on platforms that do not strictly require it? Code bloat? If you want fine grained selection for people dealing with a single SoC, make it depend on CONFIG_EXPERT. Don't force this on unsuspecting users who expect their HW to just work. Something like: config IMX_GPCV2 bool "i.MX GPCv2 IRQ chip" if EXPERT def_bool ARCH_MXC select IRQ_DOMAIN help Enables the wakeup IRQs for IMX platforms with GPCv2 block > > We probably could introduce SOC option under drivers/soc/ to do the default > configs > selection. But we've already handled all other driver selections in defconfig > e.g. firmware, clk, pinctrl, power domain and etc. > Not sure whether GPCv2 should be an exception. I think something like the above should be the rule. Configuration feature creep is not helping anyone. M. -- Jazz is not dead, it just smell funny.
Re: linux-next: manual merge of the pidfd tree with the y2038 tree
On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner wrote: > On Tue, Jan 22, 2019 at 11:48:12AM +0100, Arnd Bergmann wrote: > > Do you mean the asm-generic uapi header? In my current series, I do that: > > Yes. My idea was to only change pidfd_send_signal's entry to 424 and > leave the other ones untouched: > > # > # x32-specific system call numbers start at 512 to avoid cache impact > diff --git a/include/uapi/asm-generic/unistd.h > b/include/uapi/asm-generic/unistd.h > index b77538af7aca..4d86d0787d99 100644 > --- a/include/uapi/asm-generic/unistd.h > +++ b/include/uapi/asm-generic/unistd.h > @@ -740,7 +740,7 @@ __SC_COMP(__NR_io_pgetevents, sys_io_pgetevents, > compat_sys_io_pgetevents) > __SYSCALL(__NR_rseq, sys_rseq) > #define __NR_kexec_file_load 294 > __SYSCALL(__NR_kexec_file_load, sys_kexec_file_load) > -#define __NR_pidfd_send_signal 295 > +#define __NR_pidfd_send_signal 424 > __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal) > > and also leave Yes, that looks good. > #undef __NR_syscalls > #define __NR_syscalls 296 > > Does that work to avoid the merge conflict or do you need something > more? You need to change __NR_syscalls to 425 as well. This will clearly create a conflict, but then the resolution will be to pick the correct (a.k.a. highest) number, rather than remembering to update it manually. Arnd
Re: proc.c:undefined reference to `strcmp'
On Tue, Jan 22, 2019 at 11:11 AM kbuild test robot wrote:
> It's probably a bug fix that unveils the link errors.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 47bfa6d9dc8c060bf56554a465c9031e286d2f80
> commit: 35004f2e55807a1a1491db24ab512dd2f770a130 lib/genalloc.c: include
> vmalloc.h
> date: 2 weeks ago
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 35004f2e55807a1a1491db24ab512dd2f770a130
> # save the attached .config to linux build tree
> GCC_VERSION=8.2.0 make.cross ARCH=m68k
>
> All errors (new ones prefixed by >>):
>
>m68k-linux-gnu-ld: block/partitions/ldm.o: in function `ldm_partition':
>ldm.c:(.text+0x1900): undefined reference to `strcmp'
>m68k-linux-gnu-ld: ldm.c:(.text+0x1964): undefined reference to `strcmp'
>m68k-linux-gnu-ld: drivers/rtc/proc.o: in function `is_rtc_hctosys':
> >> proc.c:(.text+0x18c): undefined reference to `strcmp'
>m68k-linux-gnu-ld: drivers/watchdog/watchdog_pretimeout.o: in function
> `watchdog_register_governor':
>watchdog_pretimeout.c:(.text+0x142): undefined reference to `strcmp'
>m68k-linux-gnu-ld: drivers/devfreq/devfreq.o: in function
> `try_then_request_governor':
>devfreq.c:(.text+0x9c6): undefined reference to `strcmp'
I guess this bisection is a false positive. Have you just upgraded to gcc 8?
Gcc 8 replaces the strncmp() in is_rtc_hctosys() to strcmp().
Will be fixed in v5.1 by
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/commit/?h=for-v5.1=28713169d879b67be2ef2f84dcf54905de238294
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Xen-devel] [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote: Hello, Julien! Hi, On 1/21/19 7:09 PM, Julien Grall wrote: Well, I didn't get the attributes of pages at the backend side, but IMO those do not matter in my use-case (for simplicity I am not using zero-copying at backend side): They are actually important no matter what is your use case. If you access the same physical page with different attributes, then you are asking for trouble. This is why Xen imposes all the pages shared to have their memory attributes following some rules. Actually, speaking with Mark R., we may want to tight a bit more the attributes. 1. Frontend device allocates display buffer pages which come from shmem and have these attributes: !PTE_RDONLY + PTE_PXN + PTE_SHARED + PTE_AF + PTE_UXN + PTE_ATTRINDX(MT_NORMAL) My knowledge of Xen DRM is inexistent. However, looking at the code in 5.0-rc2, I don't seem to find the same attributes. For instance xen_drm_front_gem_prime_vmap and gem_mmap_obj are using pgprot_writecombine. So it looks like, the mapping will be non-cacheable on Arm64. Can you explain how you came up to these attributes? 2. Frontend grants references to these pages and shares those with the backend 3. Backend is a user-space application (Weston client), so it uses gntdev kernel driver to mmap the pages. The pages, which are used by gntdev, are those coming from the Xen balloon driver and I believe they are all normal memory and shouldn't be non-cached. 4. Once the frontend starts displaying it flips the buffers and backend does *memcpy* from the frontend-backend shared buffer into Weston's buffer. This means no HW at the backend side touches the shared buffer. 5. I can see distorted picture. Previously I used setup with zero-copying, so then the picture becomes more complicated in terms of buffers and how those used by the backed, but anyways it seems that the very basic scenario with memory copying doesn't work for me. Using DMA API on frontend's side does help - no artifacts are seen. This is why I'm thinking that this is related to frontend/kernel side rather then to the backend side. This is why I'm thinking this is related to caches and trying to figure out what can be done here instead of using DMA API. We actually never required to use cache flush in other PV protocol, so I still don't understand why the PV DRM should be different here. To me, it looks like that you are either missing some barriers or the memory attributes are not correct. Cheers, -- Julien Grall
Re: linux-next: manual merge of the pidfd tree with the y2038 tree
On Tue, Jan 22, 2019 at 12:42:44PM +0100, Arnd Bergmann wrote: > On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner > wrote: > > On Tue, Jan 22, 2019 at 11:48:12AM +0100, Arnd Bergmann wrote: > > > > Do you mean the asm-generic uapi header? In my current series, I do that: > > > > Yes. My idea was to only change pidfd_send_signal's entry to 424 and > > leave the other ones untouched: > > > > # > > # x32-specific system call numbers start at 512 to avoid cache impact > > diff --git a/include/uapi/asm-generic/unistd.h > > b/include/uapi/asm-generic/unistd.h > > index b77538af7aca..4d86d0787d99 100644 > > --- a/include/uapi/asm-generic/unistd.h > > +++ b/include/uapi/asm-generic/unistd.h > > @@ -740,7 +740,7 @@ __SC_COMP(__NR_io_pgetevents, sys_io_pgetevents, > > compat_sys_io_pgetevents) > > __SYSCALL(__NR_rseq, sys_rseq) > > #define __NR_kexec_file_load 294 > > __SYSCALL(__NR_kexec_file_load, sys_kexec_file_load) > > -#define __NR_pidfd_send_signal 295 > > +#define __NR_pidfd_send_signal 424 > > __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal) > > > > and also leave > > Yes, that looks good. > > > #undef __NR_syscalls > > #define __NR_syscalls 296 > > > > Does that work to avoid the merge conflict or do you need something > > more? > > You need to change __NR_syscalls to 425 as well. This will > clearly create a conflict, but then the resolution will be to pick > the correct (a.k.a. highest) number, rather than remembering > to update it manually. Hm, ok. Wasn't sure if that would confuse people. Ok, when I sent my PR I will make a note in the PR that this branch is aligned to create only minimal conflicts with your y2038 branch. The patch carries your ack already so this should be good. Thanks Arnd! Christian
Re: [RFC PATCH v2 02/13] epoll: introduce user structures for polling from userspace
On 2019-01-21 22:34, Linus Torvalds wrote:
So I'm not entirely convinced, but I guess actual numbers and users
might convince me otherwise.
However, a quick comment:
On Tue, Jan 22, 2019 at 9:15 AM Roman Penyaev wrote:
+struct epoll_uitem {
+ __poll_t ready_events;
+ struct epoll_event event;
+};
This really ends up being a horrible data structure.
struct epoll_event is declared as
struct epoll_event {
__poll_t events;
__u64 data;
} EPOLL_PACKED;
and __poll_t is "unsigned". So on pretty much all 64-bit architectures
except for x86-64 (which sets that packed attribute), you have a
packing hole there in between the events and the data, and "struct
epoll_event" has 8-byte alignment.
Now, in "struct epoll_uitem", you end up having *another* packing hold
in between "ready_events" and "struct epoll_event".
So this data structure that has 16 bytes of actual data, ends up being
24 bytes in size.
Again, x86-64 happens to be the exception to this, but that's a random
small implementation detail, not a design thing.
I think "struct epoll_event" was badly designed to begin with to have
this issue, but it shouldn't then be an excuse to make things even
worse with this array of "struct epoll_uitem" things.
Hmm?
Ha! Yes, you are right. Eyes see "packed" and brain responds
"ok, this is 12 bytes, + 4 for ready_events = 16, perfect".
I have not paid any attention to how actually this EPOLL_PACKED is
defined. Not nice at all. I will unfold the structure like this:
/*
* Item, shared with userspace. Unfortunately we can't embed
epoll_event
* structure, because it is badly aligned on all 64-bit archs, except
* x86-64 (see EPOLL_PACKED). sizeof(epoll_uitem) == 16
*/
struct epoll_uitem {
__poll_t ready_events;
__poll_t events;
__u64 data;
};
Also BUILD_BUG_ON(sizeof(epoll_uitem) != 16) somewhere in alloc won't
hurt.
--
Roman
Re: [PATCH v3 3/9] platform/chrome: Add support for raw commands in debugfs
Hi Nick, Why not create a module_platform_driver for this? So you have a kernel module that you can load and unload for debug purposes instead of add/remove the functionality at build time. Missatge de Nick Crews del dia ds., 19 de gen. 2019 a les 1:18: > > From: Duncan Laurie > > Add a debugfs attribute that allows sending raw commands to the EC. > This is useful for development and debug but should not be enabled > in a production environment. > > Turn the keyboard global mic mute led on > > echo 00 f2 01 76 06 00 00 01 01 > /sys/kernel/debug/wilco_ec/raw > Turn the keyboard global mic mute led off > > echo 00 f2 01 76 06 00 00 01 00 > /sys/kernel/debug/wilco_ec/raw > Get the EC firmware build date > First send the request command > > echo 00 f0 38 00 03 00 > raw > Then read the result. "12/21/18" is in the middle of the response > > cat raw > 00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18... > > Signed-off-by: Duncan Laurie > Signed-off-by: Nick Crews > --- > > Changes in v3: > - Move the attribute to the debugfs system > - Move the implementation to debugfs.c > - Improve the raw hex parsing > - Encapsulate global variables in one object > - Add safety check when passing less than 3 bytes > - Move documentation to debugfs-wilco-ec > > Changes in v2: > - Add sysfs documentation > - rm duplicate EC_MAILBOX_DATA_SIZE defs > - Make docstrings follow kernel style > - Fix tags in commit msg > - Move Kconfig to subdirectory > - Reading raw now includes ASCII translation > > Documentation/ABI/testing/debugfs-wilco-ec | 23 +++ > drivers/platform/chrome/wilco_ec/Kconfig | 9 + > drivers/platform/chrome/wilco_ec/Makefile | 2 +- > drivers/platform/chrome/wilco_ec/core.c| 17 ++ > drivers/platform/chrome/wilco_ec/debugfs.c | 218 + > include/linux/platform_data/wilco-ec.h | 3 + > 6 files changed, 271 insertions(+), 1 deletion(-) > create mode 100644 Documentation/ABI/testing/debugfs-wilco-ec > create mode 100644 drivers/platform/chrome/wilco_ec/debugfs.c > > diff --git a/Documentation/ABI/testing/debugfs-wilco-ec > b/Documentation/ABI/testing/debugfs-wilco-ec > new file mode 100644 > index ..90bc3fe08dff > --- /dev/null > +++ b/Documentation/ABI/testing/debugfs-wilco-ec > @@ -0,0 +1,23 @@ > +What: /sys/kernel/debug/wilco_ec/raw > +Date: January 2019 > +KernelVersion: 4.19 > +Description: > + Write and read raw mailbox commands to the EC. > + > + For writing: > + Bytes 0-1 indicate the message type: > + 00 F0 = Execute Legacy Command > + 00 F2 = Read/Write NVRAM Property > + Byte 2 provides the command code > + Bytes 3+ consist of the data passed in the request > + > + Example: > + // Request EC info type 3 (EC firmware build date) > + $ echo 00 f0 38 00 03 00 > raw > + // View the result. The decoded ASCII result "12/21/18" is > + // included after the raw hex. > + $ cat raw > + 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00 > .12/21/18.8... > + > + At least three bytes are required, for the msg type and > command, > + with additional bytes optional for additional data. > diff --git a/drivers/platform/chrome/wilco_ec/Kconfig > b/drivers/platform/chrome/wilco_ec/Kconfig > index f8e6c9e8c5cd..0bd84c98b79b 100644 > --- a/drivers/platform/chrome/wilco_ec/Kconfig > +++ b/drivers/platform/chrome/wilco_ec/Kconfig > @@ -21,4 +21,13 @@ config WILCO_EC > To compile this driver as a module, choose M here: the > module will be called wilco_ec. > > +config WILCO_EC_SYSFS_RAW s/SYSFS/DEBUGFS/ > + bool "Enable raw access to EC via sysfs" s/sysfs/debugfs/ > + depends on WILCO_EC > + help > + If you say Y here, you get support for sending raw commands to > + the Wilco EC via sysfs. These commands do not do any byte s/sysfs/debugfs/ > + manipulation and allow for testing arbitrary commands. This > + interface is intended for debug only and is disabled by default. > + > endif # WILCO_EC_PLATFORM > diff --git a/drivers/platform/chrome/wilco_ec/Makefile > b/drivers/platform/chrome/wilco_ec/Makefile > index 03b32301dc61..86d0457d85ea 100644 > --- a/drivers/platform/chrome/wilco_ec/Makefile > +++ b/drivers/platform/chrome/wilco_ec/Makefile > @@ -1,4 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > > -wilco_ec-objs := core.o mailbox.o > +wilco_ec-objs := core.o mailbox.o debugfs.o > obj-$(CONFIG_WILCO_EC) += wilco_ec.o > diff --git a/drivers/platform/chrome/wilco_ec/core.c > b/drivers/platform/chrome/wilco_ec/core.c > index 13fe21dd235a..749fd6a36057 100644 > --- a/drivers/platform/chrome/wilco_ec/core.c > +++ b/drivers/platform/chrome/wilco_ec/core.c > @@
Re: [PATCH 1/4] dt-binding: irq: imx-irqsteer: use irq number per channel instead of group number
On Tue, 22 Jan 2019 10:56:42 +, Aisheng Dong wrote: > > > From: Marc Zyngier [mailto:marc.zyng...@arm.com] > > Sent: Friday, January 18, 2019 6:12 PM > [...] > > >> From: Marc Zyngier [mailto:marc.zyng...@arm.com] > > >> Sent: Friday, January 18, 2019 5:39 PM On 18/01/2019 08:48, Lucas > > >> Stach wrote: > > >>> Am Freitag, den 18.01.2019, 07:53 + schrieb Aisheng Dong: > > Not all 64 interrupts may be used in one group. e.g. most irqsteer > > in imx8qxp and imx8qm subsystems supports only 32 interrupts. > > > > As the IP integration parameters are Channel number and interrupts > > number, let's use fsl,irqs-per-chan to represents how many > > interrupts supported by this irqsteer channel. > > >>> > > >>> Sorry, but total NACK. I've got to great lengths with dumping the > > >>> actually implemented register layout on i.MX8M and AFAICS the IRQs > > >>> are always managed in groups of 64 IRQs, even if less than that are > > >>> connected as input IRQs. This is what the actually present register > > >>> set on i.MX8M tells us. > > >> > > >> Also, I'd really like the DT bindings not to change at every release. > > >> So whatever change (if any) has to be done for this driver to support > > >> existing HW, please make sure that the DT bindings are kept as stable as > > possible. > > >> > > > > > > Sorry I should clarify it a bit. > > > There's still no users in Devicetree. > > > So I guess we can update it, right? Or not? > > > > What do you mean by no users? This driver is in 5.0, and I assume people are > > using it one way or another. Not having a platform in the kernel tree is > > pretty > > much irrelevant, as the kernel tree is not a canonical repository of > > existing > > platforms. > > > > I understand the concern. > Theoretically yes, but it's very unlikely that there's already an out of tree > users > wants to use it for a long term as we're still at the very initial stage. > > And the most important reason is that current using actually is wrong. > We can also choose to mark it as 'depreciated' and keep the backward > compatibility in driver, > but I'm not sure whether it's worthy to do it as we may add a lot ugly code > in driver > benefits no users. > > Ideas? At this stage, and given that there is no consensus on how this driver should work, I'm tempted to just rip it out entirely by reverting 0136afa08967 and be done with it until people work out a way forward. M. -- Jazz is not dead, it just smell funny.
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
On Tue, Jan 22, 2019 at 08:36:03PM +0900, Sugaya, Taichi wrote:
> Hi
>
> On 2018/12/04 22:32, Rob Herring wrote:
> > On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
> > wrote:
> > >
> > > Hi
> > >
> > > On 2018/12/04 0:49, Rob Herring wrote:
> > > > On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On 2018/11/30 17:16, Stephen Boyd wrote:
> > > > > > Quoting Sugaya, Taichi (2018-11-29 04:24:51)
> > > > > > > On 2018/11/28 11:01, Stephen Boyd wrote:
> > > > > > > > Quoting Sugaya Taichi (2018-11-18 17:01:07)
> > > > > > > > > create mode 100644
> > > > > > > > > Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > >
> > > > > > > > > b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000..f5d906c
> > > > > > > > > --- /dev/null
> > > > > > > > > +++
> > > > > > > > > b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > > @@ -0,0 +1,12 @@
> > > > > > > > > +Socionext M10V SMP trampoline driver binding
> > > > > > > > > +
> > > > > > > > > +This is a driver to wait for sub-cores while boot process.
> > > > > > > > > +
> > > > > > > > > +- compatible: should be "socionext,smp-trampoline"
> > > > > > > > > +- reg: should be <0x4C000100 0x100>
> > > > > > > > > +
> > > > > > > > > +EXAMPLE
> > > > > > > > > + trampoline: trampoline@0x4C000100 {
> > > > > > > > Drop the 0x part of unit addresses.
> > > > > > >
> > > > > > > Okay.
> > > > > > >
> > > > > > >
> > > > > > > > > + compatible = "socionext,smp-trampoline";
> > > > > > > > > + reg = <0x4C000100 0x100>;
> > > > > > > > Looks like a software construct, which we wouldn't want to put
> > > > > > > > into DT
> > > > > > > > this way. DT doesn't describe drivers.
> > > > > > > We would like to use this node only getting the address of the
> > > > > > > trampoline area
> > > > > > > in which sub-cores wait. (They have finished to go to this area
> > > > > > > in previous
> > > > > > > bootloader process.)
> > > > > >
> > > > > > Is this area part of memory, or a special SRAM? If it's part of
> > > > > > memory,
> > > > > > I would expect this node to be under the reserved-memory node and
> > > > > > pointed to by some other node that uses this region. Could even be
> > > > > > the
> > > > > > CPU nodes.
> > > > >
> > > > > Yes, 0x4C000100 is a part of memory under the reserved-memory node. So
> > > > > we would like to use the SRAM ( allocated 0x ) area instead.
> > > > > BTW, sorry, the trampoline address of this example is simply wrong.
> > > > > We
> > > > > were going to use a part of the SRAM from the beginning.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > So should we embed the constant value in source codes instead of
> > > > > > > getting
> > > > > > > from
> > > > > > > DT because the address is constant at the moment? Or is there
> > > > > > > other
> > > > > > > approach?
> > > > > > >
> > > > > >
> > > > > > If it's constant then that also works. Why does it need to come
> > > > > > from DT
> > > > > > at all then?
> > > > >
> > > > > We think it is not good to embed constant value in driver codes and do
> > > > > not have another way...
> > > > > Are there better ways?
> > > >
> > > > If this is just memory, can you use the standard spin-table binding in
> > > > the DT spec? There are some requirements like 64-bit values even on
> > > > 32-bit machines (though this gets violated).
> > >
> > > The spin-table seems to be used on only 64-bit arch. Have it ever worked
> > > on 32-bit machine?
> >
> > Yes.
> >
> > > And I would like not to use it because avoid violation.
> >
> > The issue now that I remember is cpu-release-addr is defined to always
> > be a 64-bit value while some platforms made it a 32-bit value.
> > 'cpu-release-addr' is also used for some other enable-methods.
>
> I have a question about the spin-table.
> The code "smp_spin_table.c" is only in "arch/arm64/kernel" directory so can
> not be compiled in arm-v7 arch. That means the spin-table can not be used
> arm-v7 arch..? , or is there the way to compile the code in arm-v7 arch?
Why do you think you need it? Do you have no way to control individual
CPUs?
We are going through a process in 32-bit eliminating the "spin table"
stuff from platforms.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH v3 2/9] platform/chrome: Add new driver for Wilco EC
Hi Nick, I've two more comments, sorry to not tell you this before. After this solved the patch looks good to me, so, for next version and for my own reference, please add the following. Acked-for-chrome-platform-by: Enric Balletbo i Serra Missatge de Nick Crews del dia ds., 19 de gen. 2019 a les 1:18: > > From: Duncan Laurie > > This EC is an incompatible variant of the typical Chrome OS embedded > controller. It uses the same low-level communication and a similar > protocol with some significant differences. The EC firmware does > not support the same mailbox commands so it is not registered as a > cros_ec device type. > > Signed-off-by: Duncan Laurie > Signed-off-by: Nick Crews > --- > > Changes in v3: > - remove unused ret in probe() > - Add newline spacer in probe() > - rm unnecessary res in get_resource() > - s/8bit/8-bit > - rm first sleep when sending command to EC > > Changes in v2: > - Remove COMPILE_TEST from Kconfig because inb()/outb() > won't work on anything but X86 > - Add myself as module author > - Tweak mailbox() > > drivers/platform/chrome/Kconfig| 4 +- > drivers/platform/chrome/Makefile | 2 + > drivers/platform/chrome/wilco_ec/Kconfig | 24 +++ > drivers/platform/chrome/wilco_ec/Makefile | 4 + > drivers/platform/chrome/wilco_ec/core.c| 96 + > drivers/platform/chrome/wilco_ec/mailbox.c | 236 + > include/linux/platform_data/wilco-ec.h | 138 > 7 files changed, 503 insertions(+), 1 deletion(-) > create mode 100644 drivers/platform/chrome/wilco_ec/Kconfig > create mode 100644 drivers/platform/chrome/wilco_ec/Makefile > create mode 100644 drivers/platform/chrome/wilco_ec/core.c > create mode 100644 drivers/platform/chrome/wilco_ec/mailbox.c > create mode 100644 include/linux/platform_data/wilco-ec.h > > diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig > index 16b1615958aa..bf889adfd4ef 100644 > --- a/drivers/platform/chrome/Kconfig > +++ b/drivers/platform/chrome/Kconfig > @@ -49,6 +49,8 @@ config CHROMEOS_TBMC > To compile this driver as a module, choose M here: the > module will be called chromeos_tbmc. > > +source "drivers/platform/chrome/wilco_ec/Kconfig" > + > config CROS_EC_CTL > tristate > > @@ -86,7 +88,7 @@ config CROS_EC_LPC > > config CROS_EC_LPC_MEC > bool "ChromeOS Embedded Controller LPC Microchip EC (MEC) variant" > - depends on CROS_EC_LPC > + depends on CROS_EC_LPC || WILCO_EC > default n > help > If you say Y here, a variant LPC protocol for the Microchip EC > diff --git a/drivers/platform/chrome/Makefile > b/drivers/platform/chrome/Makefile > index cd591bf872bb..7242ee2b13c5 100644 > --- a/drivers/platform/chrome/Makefile > +++ b/drivers/platform/chrome/Makefile > @@ -13,3 +13,5 @@ cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC)+= > cros_ec_lpc_mec.o > obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpcs.o > obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o > obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o > + > +obj-$(CONFIG_WILCO_EC) += wilco_ec/ > diff --git a/drivers/platform/chrome/wilco_ec/Kconfig > b/drivers/platform/chrome/wilco_ec/Kconfig > new file mode 100644 > index ..f8e6c9e8c5cd > --- /dev/null > +++ b/drivers/platform/chrome/wilco_ec/Kconfig > @@ -0,0 +1,24 @@ > +menuconfig WILCO_EC_PLATFORM > + bool "Platform support for Wilco Embedded Controller hardware" > + help > + Say Y here to get to see options for platform support for > + various Wilco EC features. This option alone does > + not add any kernel code. > + > + If you say N, all options in this submenu will be skipped and > disabled. > + > +if WILCO_EC_PLATFORM > + > +config WILCO_EC > + tristate "ChromeOS Wilco Embedded Controller" > + depends on ACPI && X86 > + select CROS_EC_LPC_MEC > + help > + If you say Y here, you get support for talking to the ChromeOS > + Wilco EC over an eSPI bus. This uses a simple byte-level protocol > + with a checksum. > + > + To compile this driver as a module, choose M here: the > + module will be called wilco_ec. > + > +endif # WILCO_EC_PLATFORM We will have something like this: [ ] Platform support for Wilco Embedded Controller hardware ---> |- < > ChromeOS Wilco Embedded Controller |- [ ] Enable raw access to EC via debugfs |- ( ...) The question is, apart from the ChromeOS Wilco Embedded Controller, it will be something else hanging from "Platform support for Wilco Embedded Controller hardware"? I.e. [ ] Platform support for Wilco Embedded Controller hardware ---> |- < > ChromeOS Wilco Embedded Controller | |- [ ] Enable raw access to EC via sysfs | |- ( ...) |- < > Another Wilco Embedded Controller feature none dependent of the core If the answer is
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
On Tue, Jan 22, 2019 at 4:41 PM Maxime Ripard wrote: > > On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote: > > On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki > > wrote: > > > > > > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard > > > wrote: > > > > > > > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > > > > Again, I cannot help you without the datasheet for the > > > > > > > > > > panels you're > > > > > > > > > > trying to submit. > > > > > > > > > > > > > > > > > > The panel bound with Sitronix ST7701 IC > > > > > > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > > > > > > > > > > > > > > > It's the controller, not the panel > > > > > > > > > > > > > > As I said before, the datasheet of that panel doesn't have any > > > > > > > information except electrical characteristics and used IC which is > > > > > > > ST7701. > > > > > > > > > > > > > > I have one more panel, which is from Bananapi, S070WV20-CT16 > > > > > > > ICN621 > > > > > > > please find the attachment for the same. > > > > > > > > > > > > > > Here is some more details of the same. > > > > > > > > > > > > > > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erobbing/x300/x300.dtsi#L81 > > > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > > > matches timings for > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > > > > > Where did you get the timings from then? > > > > > > > > > > You mean drm_mode timings, the same panel with RGB available in > > > > > panel-simple[1], and dsi driver in Mailing list[2] and actual DSI > > > > > sequence commands from BSP[3] > > > > > > > > > > [1] > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > > > [3] > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > > > > > So you had no reliable source for the timings then? How do you know if > > > > all your patches that are timing related are right then? > > > > > > I don't understand your point, or may be I confused with many links > > > that I attached in previous mail. > > > > > > 1. Patch for same panel timings are already in Mainline that was > > > tested on one of the board. [1] > > > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > > > > > Do you think the above two points are not valid sources? > > > > fyi, the panel datasheet attached in above mail has timing information. > > Do you have a page number? Page 4 5.2 Interface Timings
Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
+Andy
On Mon, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> The reason of doing this is because all NI multi port serial cards
> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> serial_pci_is_class_communication test added in the commit 7d8905d06405
> ("serial: 8250_pci: Enable device after we check black list").
OK, so commit 7d8905d06405 ("serial: 8250_pci: Enable device after we
check black list") has created a regression. If the device does not
use PCI_CLASS_COMMUNICATION*SERIAL class, probe will fail, and I
don't think that is how the driver should function.
If the device id is listed in serial_pci_tbl, we need to probe the
device, regardless of the class id.
> Signed-off-by: Guan Yung Tseng
> ---
> drivers/tty/serial/8250/8250_pci.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_pci.c
> b/drivers/tty/serial/8250/8250_pci.c
> index 4986b4a..0949db1 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -663,6 +663,13 @@ static int pci_xircom_init(struct pci_dev *dev)
> return 0;
> }
>
> +static int pci_ni_probe(struct pci_dev *dev)
> +{
> + dev->class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8 |
> + (dev->class & 0xff);
> + return 0;
> +}
This is only working around the regression that 7d8905d064058 created,
and only with your UART. There may be others.
We need to fix the regression, not work around it. How about something
like the attached diff?
thanks,
--
heikki
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index f80a300b5d68..8b555c3a3670 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3375,10 +3375,22 @@ static const struct pci_device_id blacklist[] = {
/* Exar devices */
{ PCI_VDEVICE(EXAR, PCI_ANY_ID), },
{ PCI_VDEVICE(COMMTECH, PCI_ANY_ID), },
+ { }
};
-static int serial_pci_is_class_communication(struct pci_dev *dev)
+/*
+ * Given a complete unknown PCI device, try to use some heuristics to
+ * guess what the configuration might be, based on the pitiful PCI
+ * serial specs. Returns 0 on success, -ENODEV on failure.
+ */
+static int
+serial_pci_guess_board(struct pci_dev *dev, struct pciserial_board *board)
{
+ int first_port = -1;
+ int num_iomem;
+ int num_port;
+ int i;
+
/*
* If it is not a communications device or the programming
* interface is greater than 6, give up.
@@ -3389,38 +3401,6 @@ static int serial_pci_is_class_communication(struct
pci_dev *dev)
(dev->class & 0xff) > 6)
return -ENODEV;
- return 0;
-}
-
-static int serial_pci_is_blacklisted(struct pci_dev *dev)
-{
- const struct pci_device_id *bldev;
-
- /*
-* Do not access blacklisted devices that are known not to
-* feature serial ports or are handled by other modules.
-*/
- for (bldev = blacklist;
-bldev < blacklist + ARRAY_SIZE(blacklist);
-bldev++) {
- if (dev->vendor == bldev->vendor &&
- dev->device == bldev->device)
- return -ENODEV;
- }
-
- return 0;
-}
-
-/*
- * Given a complete unknown PCI device, try to use some heuristics to
- * guess what the configuration might be, based on the pitiful PCI
- * serial specs. Returns 0 on success, -ENODEV on failure.
- */
-static int
-serial_pci_guess_board(struct pci_dev *dev, struct pciserial_board *board)
-{
- int num_iomem, num_port, first_port = -1, i;
-
/*
* Should we try to make guesses for multiport serial devices later?
*/
@@ -3647,13 +3627,8 @@ pciserial_init_one(struct pci_dev *dev, const struct
pci_device_id *ent)
board = _boards[ent->driver_data];
- rc = serial_pci_is_class_communication(dev);
- if (rc)
- return rc;
-
- rc = serial_pci_is_blacklisted(dev);
- if (rc)
- return rc;
+ if (pci_match_id(blacklist, dev))
+ return -ENODEV;
rc = pcim_enable_device(dev);
pci_save_state(dev);
Re: [kbuild-all] arch/x86/include/asm/cmpxchg.h:245:2: error: 'asm' operand has impossible constraints
On Tue, Jan 22, 2019 at 07:13:59PM +0800, Philip Li wrote: > thanks for the feedback, we will blacklist this. So may i understand based on > the thread at > https://lists.01.org/pipermail/kbuild-all/2018-December/056225.html, > this is gcc-4.9 problem? AFAICT, this triggers only on gcc-4.9, 32-bit build. Or do you have other configurations which trigger it? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v2 2/5] tpm: ppi: rename TPM_PPI_REVISION_ID to TPM_PPI_REVISION_ID_1
On Thu, Jan 17, 2019 at 12:41:32PM -0500, Stefan Berger wrote: > TPM PPI 1.3 introduces a function revision 2 for some functions. So, > rename the existing TPM_PPI_REVISION_ID to TPM_PPI_REVISION_ID_1. > > Signed-off-by: Stefan Berger > Tested-by: David Safford Reviewed-by: Jarkko Sakkinen /Jarkko
[PATCH 1/2] ACPI: EC: Untangle boot EC setup
From: Rafael J. Wysocki
The checks in acpi_config_boot_ec() are mostly redundant in all of
the cases when it is called and it is better to do them directly
in its callers anyway, so do that and get rid of it.
First, note that acpi_ec_ecdt_probe() is called when boot_ec is not
set, so it doesn't neeed to take the other possibility into account.
Accordingly, it only needs to set the handle field in the ec object
to ACPI_ROOT_OBJECT, call acpi_ec_setup() and (if that is successful)
set boot_ec to ec and boot_ec_is_ecdt to 'true'. Make it do so
directly, without calling acpi_config_boot_ec(), and avoid the
pointless checks in the latter.
Second, acpi_ec_dsdt_probe() returns early if boot_ec is set, so at
the point when it calls acpi_config_boot_ec() (passing ec->handle
as the handle argument to it), boot_ec is always unset. Thus calling
acpi_config_boot_ec() then is not really useful. It is sufficient to
call acpi_ec_setup() directly and (if that is successful) set boot_ec,
so make acpi_ec_dsdt_probe() do that.
Finally, acpi_ec_add() calls acpi_config_boot_ec() when it finds that
the device object passed to it represents a "boot" EC, but in that
case the ec pointer passed to acpi_config_boot_ec() is guaranteed
to be equal to boot_ec (and ec->handle is passed as the handle
argument to it), so acpi_config_boot_ec() really only calls
acpi_ec_setup() and prints a message. Avoid the pointless checks in
acpi_config_boot_ec() by calling acpi_ec_setup() directly and print
the message separately.
With the above changes in place, there are no users of
acpi_config_boot_ec(), so drop it.
No intentional functional impact except for changed messages.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/ec.c | 69 --
1 file changed, 21 insertions(+), 48 deletions(-)
Index: linux-pm/drivers/acpi/ec.c
===
--- linux-pm.orig/drivers/acpi/ec.c
+++ linux-pm/drivers/acpi/ec.c
@@ -1539,49 +1539,6 @@ static int acpi_ec_setup(struct acpi_ec
return ret;
}
-static int acpi_config_boot_ec(struct acpi_ec *ec, acpi_handle handle,
- bool handle_events, bool is_ecdt)
-{
- int ret;
-
- /*
-* Changing the ACPI handle results in a re-configuration of the
-* boot EC. And if it happens after the namespace initialization,
-* it causes _REG evaluations.
-*/
- if (boot_ec && boot_ec->handle != handle)
- ec_remove_handlers(boot_ec);
-
- /* Unset old boot EC */
- if (boot_ec != ec)
- acpi_ec_free(boot_ec);
-
- /*
-* ECDT device creation is split into acpi_ec_ecdt_probe() and
-* acpi_ec_ecdt_start(). This function takes care of completing the
-* ECDT parsing logic as the handle update should be performed
-* between the installation/uninstallation of the handlers.
-*/
- if (ec->handle != handle)
- ec->handle = handle;
-
- ret = acpi_ec_setup(ec, handle_events);
- if (ret)
- return ret;
-
- /* Set new boot EC */
- if (!boot_ec) {
- boot_ec = ec;
- boot_ec_is_ecdt = is_ecdt;
- }
-
- acpi_handle_info(boot_ec->handle,
-"Used as boot %s EC to handle transactions%s\n",
-is_ecdt ? "ECDT" : "DSDT",
-handle_events ? " and events" : "");
- return ret;
-}
-
static bool acpi_ec_ecdt_get_handle(acpi_handle *phandle)
{
struct acpi_table_ecdt *ecdt_ptr;
@@ -1649,12 +1606,17 @@ static int acpi_ec_add(struct acpi_devic
acpi_ec_free(ec);
ec = boot_ec;
}
- ret = acpi_config_boot_ec(ec, ec->handle, true, is_ecdt);
- } else
- ret = acpi_ec_setup(ec, true);
+ }
+
+ ret = acpi_ec_setup(ec, true);
if (ret)
goto err_query;
+ if (ec == boot_ec)
+ acpi_handle_info(ec->handle,
+ "Boot %s EC used to handle transactions and events\n",
+ is_ecdt ? "ECDT" : "DSDT");
+
device->driver_data = ec;
ret = !!request_region(ec->data_addr, 1, "EC data");
@@ -1766,9 +1728,14 @@ void __init acpi_ec_dsdt_probe(void)
* At this point, the GPE is not fully initialized, so do not to
* handle the events.
*/
- ret = acpi_config_boot_ec(ec, ec->handle, false, false);
+ ret = acpi_ec_setup(ec, false);
if (ret)
acpi_ec_free(ec);
+
+ boot_ec = ec;
+
+ acpi_handle_info(ec->handle,
+"Boot DSDT EC used to handle transactions\n");
}
/*
@@ -1905,14 +1872,20 @@ void __init acpi_ec_ecdt_probe(void)
ec->data_addr = ecdt_ptr->data.address;
}
ec->gpe = ecdt_ptr->gpe;
+ ec->handle
[PATCH 0/2] ACPI: EC: Simplify boot EC setup
Hi All, The setup of the boot EC is unnecessarily tangled now, so untangle it to make the code flow in there easier to follow. The only intentional functional impact of this series should be changes in messages printed to the kernel log. The patches are on top of https://patchwork.kernel.org/patch/10773757/ Thanks, Rafael
[PATCH] input: keyboard: gpio-keys-polled: use input name from pdata if available
Instead of hardcoding the input name to the driver name ('gpio-keys-polled'),
allow the passing a name via platform data ('name' field was already present),
but default to old behaviour in case of NULL.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/input/keyboard/gpio_keys_polled.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c
b/drivers/input/keyboard/gpio_keys_polled.c
index edc7262..3312186 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -272,7 +272,7 @@ static int gpio_keys_polled_probe(struct platform_device
*pdev)
input = poll_dev->input;
- input->name = pdev->name;
+ input->name = (pdata->name ? pdata->name : pdev->name);
input->phys = DRV_NAME"/input0";
input->id.bustype = BUS_HOST;
--
1.9.1
[PATCH 1/2] ACPI: EC: Simplify boot EC checks in acpi_ec_add()
From: Rafael J. Wysocki
Consolidate boot EC checks in acpi_ec_add(), put the acpi_is_boot_ec()
checks directly into it and drop the latter.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/ec.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
Index: linux-pm/drivers/acpi/ec.c
===
--- linux-pm.orig/drivers/acpi/ec.c
+++ linux-pm/drivers/acpi/ec.c
@@ -1558,16 +1558,6 @@ static bool acpi_ec_ecdt_get_handle(acpi
return true;
}
-static bool acpi_is_boot_ec(struct acpi_ec *ec)
-{
- if (!boot_ec)
- return false;
- if (ec->command_addr == boot_ec->command_addr &&
- ec->data_addr == boot_ec->data_addr)
- return true;
- return false;
-}
-
static int acpi_ec_add(struct acpi_device *device)
{
struct acpi_ec *ec = NULL;
@@ -1579,22 +1569,22 @@ static int acpi_ec_add(struct acpi_devic
strcpy(acpi_device_class(device), ACPI_EC_CLASS);
if (!strcmp(acpi_device_hid(device), ACPI_ECDT_HID)) {
- is_ecdt = true;
ec = boot_ec;
+ boot_ec_is_ecdt = true;
+ is_ecdt = true;
} else {
ec = acpi_ec_alloc();
if (!ec)
return -ENOMEM;
+
status = ec_parse_device(device->handle, 0, ec, NULL);
if (status != AE_CTRL_TERMINATE) {
ret = -EINVAL;
goto err_alloc;
}
- }
- if (acpi_is_boot_ec(ec)) {
- boot_ec_is_ecdt = is_ecdt;
- if (!is_ecdt) {
+ if (boot_ec && ec->command_addr == boot_ec->command_addr &&
+ ec->data_addr == boot_ec->data_addr) {
/*
* Trust PNP0C09 namespace location rather than
* ECDT ID. But trust ECDT GPE rather than _GPE
Re: [PATCH v2 4/5] tpm: ppi: Possibly show command parameter if TPM PPI 1.3 is used
On Thu, Jan 17, 2019 at 12:41:34PM -0500, Stefan Berger wrote: > TPM PPI 1.3 introduces an additional optional command parameter > that may be needed for some commands. Display the parameter if the > command requires such a parameter. Only command 23 needs one. > > The PPI request file will show output like this then: > ># echo "23 16" > request ># cat request >23 16 > ># echo "5" > request ># cat request >5 > > Signed-off-by: Stefan Berger > Tested-by: David Safford Reviewed-by: Jarkko Sakkinen /Jarkko
[PATCH] .gitignore: add some missing excludes
For now they're all catched by ".*", but some folks might remove that in order to add their own .config file. Signed-off-by: Enrico Weigelt, metux IT consult --- .gitignore | 6 ++ scripts/kconfig/.gitignore | 1 + 2 files changed, 7 insertions(+) diff --git a/.gitignore b/.gitignore index 97ba6b7..294452e 100644 --- a/.gitignore +++ b/.gitignore @@ -10,11 +10,14 @@ # Normal rules (sorted alphabetically) # .* +*.cmd +*.config.old *.a *.asn1.[ch] *.bin *.bz2 *.c.[012]*.* +.*.d *.dtb *.dtb.S *.dwo @@ -35,12 +38,15 @@ *.order *.patch *.s +.scmversion *.so *.so.dbg *.su *.symtypes +.tmp_* *.tab.[ch] *.tar +*.version *.xz Module.symvers modules.builtin diff --git a/scripts/kconfig/.gitignore b/scripts/kconfig/.gitignore index 0aabc1d..db990ae 100644 --- a/scripts/kconfig/.gitignore +++ b/scripts/kconfig/.gitignore @@ -2,6 +2,7 @@ # Generated files # *.moc +.mconf-cfg # # configuration programs -- 1.9.1
Re: [PATCH v2 5/5] tpm: ppi: Enable submission of optional command parameter for PPI 1.3
On Thu, Jan 17, 2019 at 12:41:35PM -0500, Stefan Berger wrote: > This patch enables a user to specify the additional optional command > parameter by writing it into the request file: > ># echo "23 16" > request ># cat request >23 16 > > For backwards compatibility: > > If only 1 parameter is given then we assume this is the operation request > number. > ># echo "5" > request ># cat request >5 > > Signed-off-by: Stefan Berger > Tested-by: David Safford Reviewed-by: Jarkko Sakkinen /Jarkko
RE: [PATCH 4/4] irq: imx: irqsteer: add multi output interrupts support
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Tuesday, January 22, 2019 6:59 PM
>
> Am Dienstag, den 22.01.2019, 10:39 + schrieb Aisheng Dong:
> > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > Sent: Friday, January 18, 2019 6:23 PM
> >
> > [...]
> > > > > This has been discussed when upstreaming the driver. The
> > > > > controller may support multiple output IRQs, but only one them
> > > > > is actually used depending on the CHANCTRL config. There is no
> > > > > use in hooking up all the output IRQs in DT, if only one of them
> > > > > is actually used. Some of the outputs may not even be visible to
> > > > > the Linux system, but may belong to a Cortex M4 subsystem. All
> > > > > of those configurations can be described in DT by changing the
> > > > > upstream interrupt and "fsl,channel" in a
> > >
> > > coherent way.
> > > > >
> > > > > Please correct me if my understanding is totally wrong.
> > > >
> > > > I'm afraid your understanding of CHAN seems wrong.
> > > > (Binding doc of that property needs change as well).
> > > >
> > > > On QXP DC SS, the IRQSTEER supports 512 interrupts with 8
> > > > interrupt output Conntected to GIC.
> > > > The current driver does not support it as it assumes only one
> > > > interrupt
> > >
> > > output used.
> > >
> > > Okay, so let's take a step back. The description in the QXP RM is
> > > actually better than what I've seen until now. Still it's totally
> > > confusing that
> the "channel"
> > > terminology used with different meanings in docs. Let's try to avoid
> > > this as much as possible.
> > >
> > > So to get things straight: Each irqsteer controller has a number of IRQ
> groups.
> > > All the input IRQs of one group are ORed together to form on output IRQ.
> > > Depending on the SoC integration, a group can contain 32 or
> > > 64 IRQs, where DCSS irqsteer on MX8M and the big 512 input
> > > controllers on QXP and QM both use 64 IRQs per group. You are
> > > claiming that the smaller controllers on both QXP am QM have only 32
> IRQs per group, right?
> > >
> > > So the only change that is needed is that the driver needs to know
> > > the number of input IRQs per group, with a default of 64 to not break DT
> compatibility.
> > >
> >
> > Not exactly.
> > from HW point of view , there're two parameters during IRQSTEER
> integration.
> > For example,
> > DC in QXP:
> > > > parameter IRQCHAN = 1; //Number of IRQ Channels/Slots
> > > > parameter NINT32 = 8; //Number of interrupts in
> > > > multiple
> of 32
>
> If this is always in multiples of 32, the only change we need to make to the
> driver is to fix DT binding and interpretation of the "fsl,irq-groups"
> property to
> be in multiples of 32.
>
> This means i.MX8MQ DCSS irqsteer would need to change to 2 irq-groups, but
> as this isn't used upstream yet we can still do this change without breaking
> too
> much stuff and I would rather correct this now than keeping a DT binding
> around that doesn't match the HW.
>
We want to avoid using of irq-groups as it's wrong.
Stick to HW parameters, only channel number and interrupts number should be
used.
> > MIPI CSI in MQ:
> > > Parameter IRQCHAN= 1
> > > Parameter NINT32 = 1
> >
> > You will see no group concept used here. Only channel number and
> interrupts number.
> > The group is an IP internal concept that ORed a group of 64 interrupts
> > into an output interrupt. But it may also only use 32 interrupts in the same
> group.
>
> I suppose that the OR group size at that point is always 64 input IRQs per
> output IRQ, right? So with NINT32 == 1 you end up with 1 output IRQ, but for
> NINT32 == 3 you get 2 output IRQs, correct?
Yes, that's right.
>
> > > Also if the connection between IRQ group and output IRQ is fixed,
> > > the driver should be more clever about handling the chained IRQ. If
> > > you know which of the upstream IRQs fired you only need to look at
> > > the 32 or 64 IRQ status registers of that specific group, not all of them.
> >
> > Yes, that's right.
> > I planned to do that later with a separate patch before.
>
> Let's do it right with the first patch. This doesn't seem like a big change.
>
We can do it.
> >
> > >
> > > Can you please clarify what the CHANCTRL setting changes in this setup?
> > >
> >
> > IRQsteer supports up to 5 separate CAHNNELS which each of them
> > supports up to 512 interrupts. CHANCTL is used to enable those respective
> CHAN output interrupts.
> > e.g.
> > 1~8 output interrupts of CHAN0.
> >
> > One notable thing is the each channel has a separate address space.
> > That means the chan1 reg address is not the one we specified in default reg
> property.
> > So the correct dts may be like for multi channels cases.
> > interrupt-controller@32e2d000 {
> > compatible = "fsl,imx8m-irqsteer", "fsl,imx-irqsteer";
> > reg = <0x32e2d000 0x1000>,
> > <0x32e2e000 0x1000>,
> >
Re: [PATCH 1/2] ACPI: EC: Simplify boot EC checks in acpi_ec_add()
On Tue, Jan 22, 2019 at 1:01 PM Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> Consolidate boot EC checks in acpi_ec_add(), put the acpi_is_boot_ec()
> checks directly into it and drop the latter.
>
> No intentional functional impact.
>
> Signed-off-by: Rafael J. Wysocki
This is the second patch in the series, the numbering in the subject
is incorrect. Sorry about that.
> ---
> drivers/acpi/ec.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> Index: linux-pm/drivers/acpi/ec.c
> ===
> --- linux-pm.orig/drivers/acpi/ec.c
> +++ linux-pm/drivers/acpi/ec.c
> @@ -1558,16 +1558,6 @@ static bool acpi_ec_ecdt_get_handle(acpi
> return true;
> }
>
> -static bool acpi_is_boot_ec(struct acpi_ec *ec)
> -{
> - if (!boot_ec)
> - return false;
> - if (ec->command_addr == boot_ec->command_addr &&
> - ec->data_addr == boot_ec->data_addr)
> - return true;
> - return false;
> -}
> -
> static int acpi_ec_add(struct acpi_device *device)
> {
> struct acpi_ec *ec = NULL;
> @@ -1579,22 +1569,22 @@ static int acpi_ec_add(struct acpi_devic
> strcpy(acpi_device_class(device), ACPI_EC_CLASS);
>
> if (!strcmp(acpi_device_hid(device), ACPI_ECDT_HID)) {
> - is_ecdt = true;
> ec = boot_ec;
> + boot_ec_is_ecdt = true;
> + is_ecdt = true;
> } else {
> ec = acpi_ec_alloc();
> if (!ec)
> return -ENOMEM;
> +
> status = ec_parse_device(device->handle, 0, ec, NULL);
> if (status != AE_CTRL_TERMINATE) {
> ret = -EINVAL;
> goto err_alloc;
> }
> - }
>
> - if (acpi_is_boot_ec(ec)) {
> - boot_ec_is_ecdt = is_ecdt;
> - if (!is_ecdt) {
> + if (boot_ec && ec->command_addr == boot_ec->command_addr &&
> + ec->data_addr == boot_ec->data_addr) {
> /*
> * Trust PNP0C09 namespace location rather than
> * ECDT ID. But trust ECDT GPE rather than _GPE
>
Re: [PATCH v2 5/5] tpm: ppi: Enable submission of optional command parameter for PPI 1.3
On Tue, Jan 22, 2019 at 02:01:59PM +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 17, 2019 at 12:41:35PM -0500, Stefan Berger wrote:
> > This patch enables a user to specify the additional optional command
> > parameter by writing it into the request file:
> >
> ># echo "23 16" > request
> ># cat request
> >23 16
> >
> > For backwards compatibility:
> >
> > If only 1 parameter is given then we assume this is the operation request
> > number.
> >
> ># echo "5" > request
> ># cat request
> >5
> >
> > Signed-off-by: Stefan Berger
> > Tested-by: David Safford
>
> Reviewed-by: Jarkko Sakkinen
Oops, sorry, this was meant for 4/5, so please ignore that.
The goto statement in tpm_store_ppi_request() is a bit messy as you
jump between branches. Definitely works, but very unreadable.
To get around it, you could change the branching as
if (strcmp(chip->ppi_version, "1.3") == 0 &&
sscanf(buf, "%llu %llu", [0].integer.value,
[1].integer.value) == 2) {
/* ... */
} else if (strcmp(chip->ppi_version, "1.2") == 0) {
/* ... */
} else {
/* ... */
}
/Jarkko
[PATCH 1/2] dt-bindings: iio: imu: add icm20602 bindings to mpu6050
Adding the invensense ICM-20602 to the compatible list of the mpu6050 driver Signed-off-by: Randolph Maaßen --- Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt b/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt index 6ab9a9d196b0..268bf7568e19 100644 --- a/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt +++ b/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt @@ -11,6 +11,7 @@ Required properties: "invensense,mpu9250" "invensense,mpu9255" "invensense,icm20608" + "invensense,icm20602" - reg : the I2C address of the sensor - interrupts: interrupt mapping for IRQ. It should be configured with flags IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or -- 2.11.0
[PATCH 2/2] iio: imu: mpu6050: Add support for the ICM 20602 IMU
The Invensense ICM-20602 is a 6-axis MotionTracking device that
combines a 3-axis gyroscope and an 3-axis accelerometer. It is very
similar to the ICM-20608 imu which is already supported by the mpu6050
driver. The main difference is that the ICM-20602 has the i2c bus
disable bit in a separate register.
Signed-off-by: Randolph Maaßen
---
drivers/iio/imu/inv_mpu6050/Kconfig| 8
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 29 +
drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 6 ++
drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 8
drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c | 12 +---
5 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/imu/inv_mpu6050/Kconfig
b/drivers/iio/imu/inv_mpu6050/Kconfig
index 5483b2ea754d..d2fe9dbddda7 100644
--- a/drivers/iio/imu/inv_mpu6050/Kconfig
+++ b/drivers/iio/imu/inv_mpu6050/Kconfig
@@ -13,8 +13,8 @@ config INV_MPU6050_I2C
select INV_MPU6050_IIO
select REGMAP_I2C
help
- This driver supports the Invensense MPU6050/6500/9150 and ICM20608
- motion tracking devices over I2C.
+ This driver supports the Invensense MPU6050/6500/9150 and
+ ICM20608/20602 motion tracking devices over I2C.
This driver can be built as a module. The module will be called
inv-mpu6050-i2c.
@@ -24,7 +24,7 @@ config INV_MPU6050_SPI
select INV_MPU6050_IIO
select REGMAP_SPI
help
- This driver supports the Invensense MPU6050/6500/9150 and ICM20608
- motion tracking devices over SPI.
+ This driver supports the Invensense MPU6050/6500/9150 and
+ ICM20608/20602 motion tracking devices over SPI.
This driver can be built as a module. The module will be called
inv-mpu6050-spi.
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index 1e428c196a82..01c856417d8f 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -38,6 +38,29 @@ static const int gyro_scale_6050[] = {133090, 266181,
532362, 1064724};
*/
static const int accel_scale[] = {598, 1196, 2392, 4785};
+static const struct inv_mpu6050_reg_map reg_set_icm20602 = {
+ .sample_rate_div= INV_MPU6050_REG_SAMPLE_RATE_DIV,
+ .lpf= INV_MPU6050_REG_CONFIG,
+ .accel_lpf = INV_MPU6500_REG_ACCEL_CONFIG_2,
+ .user_ctrl = INV_MPU6050_REG_USER_CTRL,
+ .fifo_en= INV_MPU6050_REG_FIFO_EN,
+ .gyro_config= INV_MPU6050_REG_GYRO_CONFIG,
+ .accl_config= INV_MPU6050_REG_ACCEL_CONFIG,
+ .fifo_count_h = INV_MPU6050_REG_FIFO_COUNT_H,
+ .fifo_r_w = INV_MPU6050_REG_FIFO_R_W,
+ .raw_gyro = INV_MPU6050_REG_RAW_GYRO,
+ .raw_accl = INV_MPU6050_REG_RAW_ACCEL,
+ .temperature= INV_MPU6050_REG_TEMPERATURE,
+ .int_enable = INV_MPU6050_REG_INT_ENABLE,
+ .int_status = INV_MPU6050_REG_INT_STATUS,
+ .pwr_mgmt_1 = INV_MPU6050_REG_PWR_MGMT_1,
+ .pwr_mgmt_2 = INV_MPU6050_REG_PWR_MGMT_2,
+ .int_pin_cfg= INV_MPU6050_REG_INT_PIN_CFG,
+ .accl_offset= INV_MPU6500_REG_ACCEL_OFFSET,
+ .gyro_offset= INV_MPU6050_REG_GYRO_OFFSET,
+ .i2c_if = INV_ICM20602_REG_I2C_IF,
+};
+
static const struct inv_mpu6050_reg_map reg_set_6500 = {
.sample_rate_div= INV_MPU6050_REG_SAMPLE_RATE_DIV,
.lpf= INV_MPU6050_REG_CONFIG,
@@ -140,6 +163,12 @@ static const struct inv_mpu6050_hw hw_info[] = {
.reg = _set_6500,
.config = _config_6050,
},
+ {
+ .whoami = INV_ICM20602_WHOAMI_VALUE,
+ .name = "ICM20602",
+ .reg = _set_icm20602,
+ .config = _config_6050,
+ },
};
int inv_mpu6050_switch_engine(struct inv_mpu6050_state *st, bool en, u32 mask)
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
index dd758e3d403d..e46eb4ddea21 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
@@ -127,6 +127,7 @@ static int inv_mpu_probe(struct i2c_client *client,
st = iio_priv(dev_get_drvdata(>dev));
switch (st->chip_type) {
case INV_ICM20608:
+ case INV_ICM20602:
/* no i2c auxiliary bus on the chip */
break;
default:
@@ -179,6 +180,7 @@ static const struct i2c_device_id inv_mpu_id[] = {
{"mpu9250", INV_MPU9250},
{"mpu9255", INV_MPU9255},
{"icm20608", INV_ICM20608},
+ {"icm20602", INV_ICM20602},
{}
};
@@ -213,6 +215,10 @@ static const struct of_device_id inv_of_match[] = {
Re: [PATCH v6 11/16] sched/fair: Add uclamp support to energy_compute()
On Tuesday 15 Jan 2019 at 10:15:08 (+), Patrick Bellasi wrote:
> The Energy Aware Scheduler (AES) estimates the energy impact of waking
s/AES/EAS :-)
[...]
> + for_each_cpu_and(cpu, pd_mask, cpu_online_mask) {
> + cfs_util = cpu_util_next(cpu, p, dst_cpu);
> +
> + /*
> + * Busy time computation: utilization clamping is not
> + * required since the ratio (sum_util / cpu_capacity)
> + * is already enough to scale the EM reported power
> + * consumption at the (eventually clamped) cpu_capacity.
> + */
Right.
> + sum_util += schedutil_cpu_util(cpu, cfs_util, cpu_cap,
> +ENERGY_UTIL, NULL);
> +
> + /*
> + * Performance domain frequency: utilization clamping
> + * must be considered since it affects the selection
> + * of the performance domain frequency.
> + */
So that actually affects the way we deal with RT I think. I assume the
idea is to say if you don't want to reflect the RT-go-to-max-freq thing
in EAS (which is what we do now) you should set the min cap for RT to 0.
Is that correct ?
I'm fine with this conceptually but maybe the specific case of RT should
be mentioned somewhere in the commit message or so ? I think it's
important to say that clearly since this patch changes the default
behaviour.
> + cpu_util = schedutil_cpu_util(cpu, cfs_util, cpu_cap,
> + FREQUENCY_UTIL,
> + cpu == dst_cpu ? p :
> NULL);
> + max_util = max(max_util, cpu_util);
> }
>
> energy += em_pd_energy(pd->em_pd, max_util, sum_util);
Thanks,
Quentin
[PATCH] f2fs: fix to avoid deadlock of atomic file operations
Thread AThread B - __fput - f2fs_release_file - drop_inmem_pages - mutex_lock(>inmem_lock) - __revoke_inmem_pages - lock_page(page) - open - f2fs_setattr - truncate_setsize - truncate_inode_pages_range - lock_page(page) - truncate_cleanup_page - f2fs_invalidate_page - drop_inmem_page - mutex_lock(>inmem_lock); We may encounter above ABBA deadlock as reported by Kyungtae Kim: I'm reporting a bug in linux-4.17.19: "INFO: task hung in drop_inmem_page" (no reproducer) I think this might be somehow related to the following: https://groups.google.com/forum/#!searchin/syzkaller-bugs/INFO$3A$20task$20hung$20in$20%7Csort:date/syzkaller-bugs/c6soBTrdaIo/AjAzPeIzCgAJ = INFO: task syz-executor7:10822 blocked for more than 120 seconds. Not tainted 4.17.19 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor7 D27024 10822 6346 0x0004 Call Trace: context_switch kernel/sched/core.c:2867 [inline] __schedule+0x721/0x1e60 kernel/sched/core.c:3515 schedule+0x88/0x1c0 kernel/sched/core.c:3559 schedule_preempt_disabled+0x18/0x30 kernel/sched/core.c:3617 __mutex_lock_common kernel/locking/mutex.c:833 [inline] __mutex_lock+0x5bd/0x1410 kernel/locking/mutex.c:893 mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:908 drop_inmem_page+0xcb/0x810 fs/f2fs/segment.c:327 f2fs_invalidate_page+0x337/0x5e0 fs/f2fs/data.c:2401 do_invalidatepage mm/truncate.c:165 [inline] truncate_cleanup_page+0x261/0x330 mm/truncate.c:187 truncate_inode_pages_range+0x552/0x1610 mm/truncate.c:367 truncate_inode_pages mm/truncate.c:478 [inline] truncate_pagecache+0x6d/0x90 mm/truncate.c:801 truncate_setsize+0x81/0xa0 mm/truncate.c:826 f2fs_setattr+0x44f/0x1270 fs/f2fs/file.c:781 notify_change+0xa62/0xe80 fs/attr.c:313 do_truncate+0x12e/0x1e0 fs/open.c:63 do_last fs/namei.c:2955 [inline] path_openat+0x2042/0x29f0 fs/namei.c:3505 do_filp_open+0x1bd/0x2c0 fs/namei.c:3540 do_sys_open+0x35e/0x4e0 fs/open.c:1101 __do_sys_open fs/open.c:1119 [inline] __se_sys_open fs/open.c:1114 [inline] __x64_sys_open+0x89/0xc0 fs/open.c:1114 do_syscall_64+0xc4/0x4e0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4497b9 RSP: 002b:7f734e459c68 EFLAGS: 0246 ORIG_RAX: 0002 RAX: ffda RBX: 7f734e45a6cc RCX: 004497b9 RDX: 0104 RSI: 000a8280 RDI: 2080 RBP: 0071bea0 R08: R09: R10: R11: 0246 R12: R13: 7230 R14: 006f02d0 R15: 7f734e45a700 INFO: task syz-executor7:10858 blocked for more than 120 seconds. Not tainted 4.17.19 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor7 D28880 10858 6346 0x0004 Call Trace: context_switch kernel/sched/core.c:2867 [inline] __schedule+0x721/0x1e60 kernel/sched/core.c:3515 schedule+0x88/0x1c0 kernel/sched/core.c:3559 __rwsem_down_write_failed_common kernel/locking/rwsem-xadd.c:565 [inline] rwsem_down_write_failed+0x5e6/0xc90 kernel/locking/rwsem-xadd.c:594 call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117 __down_write arch/x86/include/asm/rwsem.h:142 [inline] down_write+0x58/0xa0 kernel/locking/rwsem.c:72 inode_lock include/linux/fs.h:713 [inline] do_truncate+0x120/0x1e0 fs/open.c:61 do_last fs/namei.c:2955 [inline] path_openat+0x2042/0x29f0 fs/namei.c:3505 do_filp_open+0x1bd/0x2c0 fs/namei.c:3540 do_sys_open+0x35e/0x4e0 fs/open.c:1101 __do_sys_open fs/open.c:1119 [inline] __se_sys_open fs/open.c:1114 [inline] __x64_sys_open+0x89/0xc0 fs/open.c:1114 do_syscall_64+0xc4/0x4e0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4497b9 RSP: 002b:7f734e3b4c68 EFLAGS: 0246 ORIG_RAX: 0002 RAX: ffda RBX: 7f734e3b56cc RCX: 004497b9 RDX: 0104 RSI: 000a8280 RDI: 2080 RBP: 0071c238 R08: R09: R10: R11: 0246 R12: R13: 7230 R14: 006f02d0 R15: 7f734e3b5700 INFO: task syz-executor5:10829 blocked for more than 120 seconds. Not tainted 4.17.19 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor5 D28760 10829 6308 0x8002 Call Trace: context_switch kernel/sched/core.c:2867 [inline] __schedule+0x721/0x1e60 kernel/sched/core.c:3515 schedule+0x88/0x1c0 kernel/sched/core.c:3559
Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
On Tue, Jan 22, 2019 at 11:32:41AM +0800, Chao Fan wrote: > But I notice the only function call entry is in kaslr.c which needs > RANDOMIZE_BASE, so do I need change it as: > vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/acpi.o Well, the very first patch in this thread doesn't have anything to do with CONFIG_RANDOMIZE_BASE but wants RDSP too. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [RESEND PATCH 00/12] eeprom: at24: remove platform_data
On Thu, Jan 10, 2019 at 07:43:47PM +0530, Sekhar Nori wrote: > Hi Bartosz, > > On 08/01/19 2:45 PM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > Hi Sekhar, > > > > now that all dependencies are in and v5.0-rc1 is tagged, please consider > > picking up the second batch of davinci-specific changes into your tree. > > Once that's done, please provide me with an immutable branch for me to > > apply the last patch to my at24 tree. > > You can use branch v5.1/eeprom-for-bartosz in my tree for this (commit > e430685f4969). > > > > > This is the second part of the effort to modernize the at24 driver and > > remove the legacy platform data structure in favor of device properties. > > It required getting rid of the at24 setup callback in favor of nvmem > > lookups. > > > > Re-tested with da850-evm and dm365-evm. > > Applied patches 1-11 for v5.1 Feel free to take patch 12 as well :) thanks, greg k-h
Re: linux-next: manual merge of the pidfd tree with the y2038 tree
On Tue, Jan 22, 2019 at 12:46:56PM +0100, Christian Brauner wrote: > On Tue, Jan 22, 2019 at 12:42:44PM +0100, Arnd Bergmann wrote: > > On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner > > wrote: > > > On Tue, Jan 22, 2019 at 11:48:12AM +0100, Arnd Bergmann wrote: > > > > > > Do you mean the asm-generic uapi header? In my current series, I do > > > > that: > > > > > > Yes. My idea was to only change pidfd_send_signal's entry to 424 and > > > leave the other ones untouched: > > > > > > # > > > # x32-specific system call numbers start at 512 to avoid cache impact > > > diff --git a/include/uapi/asm-generic/unistd.h > > > b/include/uapi/asm-generic/unistd.h > > > index b77538af7aca..4d86d0787d99 100644 > > > --- a/include/uapi/asm-generic/unistd.h > > > +++ b/include/uapi/asm-generic/unistd.h > > > @@ -740,7 +740,7 @@ __SC_COMP(__NR_io_pgetevents, sys_io_pgetevents, > > > compat_sys_io_pgetevents) > > > __SYSCALL(__NR_rseq, sys_rseq) > > > #define __NR_kexec_file_load 294 > > > __SYSCALL(__NR_kexec_file_load, sys_kexec_file_load) > > > -#define __NR_pidfd_send_signal 295 > > > +#define __NR_pidfd_send_signal 424 > > > __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal) > > > > > > and also leave > > > > Yes, that looks good. > > > > > #undef __NR_syscalls > > > #define __NR_syscalls 296 > > > > > > Does that work to avoid the merge conflict or do you need something > > > more? > > > > You need to change __NR_syscalls to 425 as well. This will > > clearly create a conflict, but then the resolution will be to pick > > the correct (a.k.a. highest) number, rather than remembering > > to update it manually. > > Hm, ok. Wasn't sure if that would confuse people. > > Ok, when I sent my PR I will make a note in the PR that this branch is > aligned to create only minimal conflicts with your y2038 branch. The > patch carries your ack already so this should be good. Arnd, in case you care to take a look https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=for-next Thanks! Christian
RE: [PATCH 1/1] irqchip: gpcv2: make config option visible
> From: Marc Zyngier [mailto:marc.zyng...@arm.com] > Sent: Tuesday, January 22, 2019 7:40 PM > On Tue, 22 Jan 2019 11:04:48 +, > Aisheng Dong wrote: > > > > > > > > > From: Marc Zyngier [mailto:marc.zyng...@arm.com] > > > Sent: Friday, January 18, 2019 6:10 PM > > [...] > > > >>> > > > >>> config IMX_GPCV2 > > > >>> - bool > > > >>> + bool "i.MX GPCv2 IRQ chip" > > > >>> + depends on ARCH_MXC || (COMPILE_TEST && OF) > > > >>> select IRQ_DOMAIN > > > >>> help > > > >>> Enables the wakeup IRQs for IMX platforms with GPCv2 block > > > >>> > > > >> > > > >> How does it help exactly? It is pretty difficult for a user to > > > >> know exactly what they need. I'd rather see it selected by > > > >> ARCH_MXC, which makes it > > > > > > > > ARM64 SoC maintainers suggest not add more driver specific options > > > > except an Generic ARCH option. > > > > > > > > As GPCv2 is also used in MX8MQ. So we may select it in armv8 defconfig. > > > > If this option is invisible, we can't select it. > > > > > > And conversely, users have no idea of what letter soup they have to > > > select to make their HW work properly. Selecting the driver when the > > > platform is supposed to be supported is the right way to solve this > problem. > > > > > > > I think the problem is that we have no platform specific CONFIGs for arm v8 > platforms. > > We have only one CONFIG_ARCH_MXC for all MX8 SoCs, e.g. mx8qxp, > mx8mq... > > Only MX8MQ needs to use GPCv2. Selecting GPCv2 under ARCH_MXC means > > users have no chance to disable it for mx8qxp which does not need it. > > And where is the problem to select this on platforms that do not strictly > require it? Code bloat? I think it's not a big problem. > > If you want fine grained selection for people dealing with a single SoC, make > it > depend on CONFIG_EXPERT. Don't force this on unsuspecting users who expect > their HW to just work. > Seems not too necessary > Something like: > > config IMX_GPCV2 > bool "i.MX GPCv2 IRQ chip" if EXPERT > def_bool ARCH_MXC > select IRQ_DOMAIN > help > Enables the wakeup IRQs for IMX platforms with GPCv2 block > > > > > We probably could introduce SOC option under drivers/soc/ to do the > > default configs selection. But we've already handled all other driver > > selections in defconfig e.g. firmware, clk, pinctrl, power domain and etc. > > Not sure whether GPCv2 should be an exception. > > I think something like the above should be the rule. Configuration feature > creep is not helping anyone. Got it, thanks for the suggestion. Regards Dong Aisheng > > M. > > -- > Jazz is not dead, it just smell funny.
Re: [PATCH v3] drivers/base: add sysfs entries for suppliers and consumers
On Thu, Dec 20, 2018 at 01:05:11PM +, Ioana Ciornei wrote:
> Instead of scraping dmesg for messages such as 'Linked as a consumer to'
> or 'Dropping the link to' export two new sysfs entries in the device
> folder that contain a list of the consumer and supplier devices.
What is userspace going to do with that information? Why does it care?
>
> Also, lower the log level of the prints since the same information
> is available in the sysfs entries.
>
> Signed-off-by: Ioana Ciornei
> ---
> Changes in v3:
> - lower the log level of prints
> Changes in v2:
> - add documentation entries for the new sysfs files
>
> Documentation/ABI/testing/sysfs-devices-links | 13 +++
> drivers/base/core.c | 52
> ---
> 2 files changed, 60 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-devices-links
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-links
> b/Documentation/ABI/testing/sysfs-devices-links
> new file mode 100644
> index 000..d3951c5
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-devices-links
> @@ -0,0 +1,13 @@
> +What:/sys/devices/.../consumers
> +Date:December 2018
> +Contact: Ioana Ciornei
> +Description:
> + Read-only attribute that lists the current "consumers" of
> + a specific device.
> +
> +What:/sys/devices/.../suppliers
> +Date:December 2018
> +Contact: Ioana Ciornei
> +Description:
> + Read-only attribute that lists the current "suppliers" of
> + a specific device.
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index a4ced33..5339bcf 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -301,7 +301,7 @@ struct device_link *device_link_add(struct device
> *consumer,
> list_add_tail_rcu(>s_node, >links.consumers);
> list_add_tail_rcu(>c_node, >links.suppliers);
>
> - dev_info(consumer, "Linked as a consumer to %s\n", dev_name(supplier));
> + dev_dbg(consumer, "Linked as a consumer to %s\n", dev_name(supplier));
>
> out:
> device_pm_unlock();
> @@ -327,8 +327,8 @@ static void __device_link_del(struct kref *kref)
> {
> struct device_link *link = container_of(kref, struct device_link, kref);
>
> - dev_info(link->consumer, "Dropping the link to %s\n",
> - dev_name(link->supplier));
> + dev_dbg(link->consumer, "Dropping the link to %s\n",
> + dev_name(link->supplier));
>
> if (link->flags & DL_FLAG_PM_RUNTIME)
> pm_runtime_drop_link(link->consumer);
> @@ -342,8 +342,8 @@ static void __device_link_del(struct kref *kref)
> {
> struct device_link *link = container_of(kref, struct device_link, kref);
>
> - dev_info(link->consumer, "Dropping the link to %s\n",
> - dev_name(link->supplier));
> + dev_dbg(link->consumer, "Dropping the link to %s\n",
> + dev_name(link->supplier));
>
> if (link->flags & DL_FLAG_PM_RUNTIME)
> pm_runtime_drop_link(link->consumer);
> @@ -1117,6 +1117,34 @@ static ssize_t online_store(struct device *dev, struct
> device_attribute *attr,
> }
> static DEVICE_ATTR_RW(online);
>
> +static ssize_t suppliers_show(struct device *dev, struct device_attribute
> *attr,
> + char *buf)
> +{
> + struct device_link *link;
> + size_t count = 0;
> +
> + list_for_each_entry(link, >links.suppliers, c_node)
> + count += scnprintf(buf + count, PAGE_SIZE - count, "%s\n",
> +dev_name(link->supplier));
> +
> + return count;
> +}
> +static DEVICE_ATTR_RO(suppliers);
> +
> +static ssize_t consumers_show(struct device *dev, struct device_attribute
> *attr,
> + char *buf)
> +{
> + struct device_link *link;
> + size_t count = 0;
> +
> + list_for_each_entry(link, >links.consumers, s_node)
> + count += scnprintf(buf + count, PAGE_SIZE - count, "%s\n",
> +dev_name(link->consumer));
sysfs is supposed to be one value per file, this violates that. I don't
like that at all, now this file has to be parsed by userspace.
> +
> + return count;
> +}
> +static DEVICE_ATTR_RO(consumers);
Turn these into an attribute group, so you can add them all at once?
And do you really need these for _EVERY_ device in the system? That
feels like a lot of extra files for almost no users.
> +
> int device_add_groups(struct device *dev, const struct attribute_group
> **groups)
> {
> return sysfs_create_groups(>kobj, groups);
> @@ -1288,8 +1316,20 @@ static int device_add_attrs(struct device *dev)
> goto err_remove_dev_groups;
> }
>
> + error = device_create_file(dev, _attr_suppliers);
> + if (error)
> + goto err_remove_online;
> +
> + error = device_create_file(dev,
Re: [PATCH v6 09/16] sched/cpufreq: uclamp: Add utilization clamping for RT tasks
On Tuesday 15 Jan 2019 at 10:15:06 (+), Patrick Bellasi wrote:
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index 520ee2b785e7..38a05a4f78cc 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -201,9 +201,6 @@ unsigned long schedutil_freq_util(int cpu, unsigned long
> util_cfs,
> unsigned long dl_util, util, irq;
> struct rq *rq = cpu_rq(cpu);
>
> - if (type == FREQUENCY_UTIL && rt_rq_is_runnable(>rt))
> - return max;
> -
> /*
>* Early check to see if IRQ/steal time saturates the CPU, can be
>* because of inaccuracies in how we track these -- see
> @@ -219,15 +216,19 @@ unsigned long schedutil_freq_util(int cpu, unsigned
> long util_cfs,
>* utilization (PELT windows are synchronized) we can directly add them
>* to obtain the CPU's actual utilization.
>*
> - * CFS utilization can be boosted or capped, depending on utilization
> - * clamp constraints requested by currently RUNNABLE tasks.
> + * CFS and RT utilization can be boosted or capped, depending on
> + * utilization clamp constraints requested by currently RUNNABLE
> + * tasks.
>* When there are no CFS RUNNABLE tasks, clamps are released and
>* frequency will be gracefully reduced with the utilization decay.
>*/
> - util = (type == ENERGY_UTIL)
> - ? util_cfs
> - : uclamp_util(rq, util_cfs);
> - util += cpu_util_rt(rq);
> + util = cpu_util_rt(rq);
> + if (type == FREQUENCY_UTIL) {
> + util += cpu_util_cfs(rq);
> + util = uclamp_util(rq, util);
So with this we don't go to max to anymore for CONFIG_UCLAMP_TASK=n no ?
Thanks,
Quentin
Verificação de e-mail
Notificação de email do Web Admin Esta mensagem é do nosso centro de mensagens do Web Admin para todos os nossos proprietários de contas de e-mail. Estamos eliminando o acesso a todos os nossos clientes de webmail. Sua conta de e-mail será atualizada para uma interface de usuário de webmail nova e melhorada, fornecida pelo nosso Administrador assim que este e-mail for recebido. Descontinuaremos o uso de nossas interfaces do webmail Lite, para garantir que seu catálogo de endereços seja salvo em nosso banco de dados, clique ou copie e cole o link abaixo em seu navegador e digite seu Nome de Usuário e Senha para atualizar sua conta. Se o clique não funcionar, copie e cole o URL abaixo em um navegador da web para verificá-lo. Clique no link http://administradordecorreo.xtgem.com/index se clicar não funcionar, copie e cole em sua webrowser e atualize sua conta para que possamos transferir seus contatos para nosso novo banco de dados de clientes de webmail. Todos os emails estarão seguros nesta transição! Todas as suas mensagens antigas estarão lá e você terá novas mensagens não lidas esperando por você. Estamos Claro que você vai gostar da nova e melhorada interface de webmail. Se você não cumprir este aviso, retiraremos imediatamente o acesso à sua conta de e-mail. Obrigado por usar nosso webmail. == == = Número de registro 65628698L) Identificação do cliente 779862 == == = Sinceramente Web Admin. E-mail Atendimento ao cliente 46569 Copyright c 2019 E! Inc. (Co Reg.No. 65628698L) Todos os direitos reservados.
Verificação de e-mail
Notificação de email do Web Admin Esta mensagem é do nosso centro de mensagens do Web Admin para todos os nossos proprietários de contas de e-mail. Estamos eliminando o acesso a todos os nossos clientes de webmail. Sua conta de e-mail será atualizada para uma interface de usuário de webmail nova e melhorada, fornecida pelo nosso Administrador assim que este e-mail for recebido. Descontinuaremos o uso de nossas interfaces do webmail Lite, para garantir que seu catálogo de endereços seja salvo em nosso banco de dados, clique ou copie e cole o link abaixo em seu navegador e digite seu Nome de Usuário e Senha para atualizar sua conta. Se o clique não funcionar, copie e cole o URL abaixo em um navegador da web para verificá-lo. Clique no link http://administradordecorreo.xtgem.com/index se clicar não funcionar, copie e cole em sua webrowser e atualize sua conta para que possamos transferir seus contatos para nosso novo banco de dados de clientes de webmail. Todos os emails estarão seguros nesta transição! Todas as suas mensagens antigas estarão lá e você terá novas mensagens não lidas esperando por você. Estamos Claro que você vai gostar da nova e melhorada interface de webmail. Se você não cumprir este aviso, retiraremos imediatamente o acesso à sua conta de e-mail. Obrigado por usar nosso webmail. == == = Número de registro 65628698L) Identificação do cliente 779862 == == = Sinceramente Web Admin. E-mail Atendimento ao cliente 46569 Copyright c 2019 E! Inc. (Co Reg.No. 65628698L) Todos os direitos reservados.
Re: [PATCH v6 09/16] sched/cpufreq: uclamp: Add utilization clamping for RT tasks
On 22-Jan 12:30, Quentin Perret wrote:
> On Tuesday 15 Jan 2019 at 10:15:06 (+), Patrick Bellasi wrote:
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 520ee2b785e7..38a05a4f78cc 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -201,9 +201,6 @@ unsigned long schedutil_freq_util(int cpu, unsigned
> > long util_cfs,
> > unsigned long dl_util, util, irq;
> > struct rq *rq = cpu_rq(cpu);
> >
> > - if (type == FREQUENCY_UTIL && rt_rq_is_runnable(>rt))
> > - return max;
> > -
> > /*
> > * Early check to see if IRQ/steal time saturates the CPU, can be
> > * because of inaccuracies in how we track these -- see
> > @@ -219,15 +216,19 @@ unsigned long schedutil_freq_util(int cpu, unsigned
> > long util_cfs,
> > * utilization (PELT windows are synchronized) we can directly add them
> > * to obtain the CPU's actual utilization.
> > *
> > -* CFS utilization can be boosted or capped, depending on utilization
> > -* clamp constraints requested by currently RUNNABLE tasks.
> > +* CFS and RT utilization can be boosted or capped, depending on
> > +* utilization clamp constraints requested by currently RUNNABLE
> > +* tasks.
> > * When there are no CFS RUNNABLE tasks, clamps are released and
> > * frequency will be gracefully reduced with the utilization decay.
> > */
> > - util = (type == ENERGY_UTIL)
> > - ? util_cfs
> > - : uclamp_util(rq, util_cfs);
> > - util += cpu_util_rt(rq);
> > + util = cpu_util_rt(rq);
> > + if (type == FREQUENCY_UTIL) {
> > + util += cpu_util_cfs(rq);
> > + util = uclamp_util(rq, util);
>
> So with this we don't go to max to anymore for CONFIG_UCLAMP_TASK=n no ?
Mmm... good point!
I need to guard this chagen for the !CONFIG_UCLAMP_TASK case!
>
> Thanks,
> Quentin
Cheers Patrick
--
#include
Patrick Bellasi
[PATCH v5] driver: uio: fix possible memory leak in uio_open
If 'idev->info' is NULL, we need to free 'listener'
Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
Signed-off-by: Liu Jian
---
v1->v2:
rename the "err_infoopen" to "err_idev_info"
v2->3:
put the extra info after the "--"
v3-v4:
add git log
v4-v5:
correct git log
drivers/uio/uio.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 1313422..b4ae2d9 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -491,18 +491,19 @@ static int uio_open(struct inode *inode, struct file
*filep)
if (!idev->info) {
mutex_unlock(>info_lock);
ret = -EINVAL;
- goto err_alloc_listener;
+ goto err_idev_info;
}
if (idev->info && idev->info->open)
ret = idev->info->open(idev->info, inode);
mutex_unlock(>info_lock);
if (ret)
- goto err_infoopen;
+ goto err_idev_info;
return 0;
-err_infoopen:
+err_idev_info:
+ filep->private_data = NULL;
kfree(listener);
err_alloc_listener:
--
2.7.4
Re: [PATCH v25 0/6] Add io{read|write}64 to io-64-atomic headers
On Wed, Jan 16, 2019 at 11:25:17AM -0700, Logan Gunthorpe wrote: > This is resend number 6 since the last change to this series. > > This cleanup was requested by Greg KH back in June of 2017. I've resent the > series > a couple times a cycle since then, updating and fixing as feedback was slowly > recieved some patches were alread accepted by specific arches. In June 2018, > Andrew picked the remainder of this up and it was in linux-next for a > couple weeks. There were a couple problems that were identified and addressed > back then and I'd really like to get the ball rolling again. A year > and a half of sending this without much feedback is far too long. > > @Andrew, can you please pick this set up again so it can get into > linux-next? Or let me know if there's something else I should be doing. version 25? That's crazy, this has gone on too long. I've taken this into my char/misc driver tree now, so sorry for the long suffering you have gone through for this. Thanks for being persistent, greg k-h
Re: [PATCH v13 0/8] Introduce on-chip interconnect API
On Wed, Jan 16, 2019 at 06:10:55PM +0200, Georgi Djakov wrote: > Modern SoCs have multiple processors and various dedicated cores (video, gpu, > graphics, modem). These cores are talking to each other and can generate a > lot of data flowing through the on-chip interconnects. These interconnect > buses could form different topologies such as crossbar, point to point buses, > hierarchical buses or use the network-on-chip concept. > > These buses have been sized usually to handle use cases with high data > throughput but it is not necessary all the time and consume a lot of power. > Furthermore, the priority between masters can vary depending on the running > use case like video playback or CPU intensive tasks. > > Having an API to control the requirement of the system in terms of bandwidth > and QoS, so we can adapt the interconnect configuration to match those by > scaling the frequencies, setting link priority and tuning QoS parameters. > This configuration can be a static, one-time operation done at boot for some > platforms or a dynamic set of operations that happen at run-time. > > This patchset introduce a new API to get the requirement and configure the > interconnect buses across the entire chipset to fit with the current demand. > The API is NOT for changing the performance of the endpoint devices, but only > the interconnect path in between them. > > The API is using a consumer/provider-based model, where the providers are > the interconnect buses and the consumers could be various drivers. > The consumers request interconnect resources (path) to an endpoint and set > the desired constraints on this data flow path. The provider(s) receive > requests from consumers and aggregate these requests for all master-slave > pairs on that path. Then the providers configure each participating in the > topology node according to the requested data flow path, physical links and > constraints. The topology could be complicated and multi-tiered and is SoC > specific. > > Below is a simplified diagram of a real-world SoC topology. The interconnect > providers are the NoCs. > > ++++ > | HW Accelerator |--->| M NoC |<---+ > ++++| > | |++ > +-+ +-+ V +--+ || > | DDR | |++ | PCIe | || > +-+ || Slaves | +--+ || >^ ^|++ | | C NoC| >| |V V || > +--+ ++ || +-+ > | |-->||-->||-->| CPU | > | |-->||<--|| +-+ > | Mem NoC | | S NoC | ++ > | |<--||-+| > | |<--||<--+ || ++ > +--+ ++ | |+-->| Slaves | > ^ ^^^ ^ | |++ > | ||| | | V > +--+ | +-+ +-+ +-+ ++ ++ > | CPUs | | | GPU | | DSP | | Masters |-->| P NoC|-->| Slaves | > +--+ | +-+ +-+ +-+ ++ ++ > | > +---+ > | Modem | > +---+ > > It's important to note that the interconnect API, in contrast with devfreq, > is allowing drivers to express their needs in advance and be proactive. > Devfreq is using a reactive approach (e.g. monitor performance counters and > reconfigure bandwidth when the bottleneck had already occurred), which is > suboptimal and might not work well. The interconnect API is designed to > deal with multi-tiered bus topologies and aggregating constraints provided > by drivers, while the devfreq is more oriented towards a device like GPU > or CPU, that controls the power/performance of itself and not other devices. > > Some examples of how interconnect API is used by consumers: > https://lkml.org/lkml/2018/12/20/811 > https://lkml.org/lkml/2019/1/9/740 > https://lkml.org/lkml/2018/10/11/499 > https://lkml.org/lkml/2018/9/20/986 > > Platform drivers for different SoCs are available: > https://lkml.org/lkml/2018/11/17/368 > https://lkml.org/lkml/2018/8/10/380 All now queued up, thanks. greg k-h
Re: [RFC] irq-gic-v3-its: fix occasional VLPI drop
Hi Marc,
Thanks for your feedback. Please see my comments below.
On 2019/1/22 17:53, Marc Zyngier wrote:
Hi Heyi,
On Mon, 21 Jan 2019 11:51:48 +,
Heyi Guo wrote:
Every VLPI will temporarily be mapped to the first CPU in system
(normally CPU0) and then moved to the real scheduled CPU later. There
is a time window so a VLPI may be sent to CPU0 instead of the real
scheduled vCPU, in a multi-CPU virtual machine. However, CPU0 may have
not been scheduled as a virtual CPU after system boots up, so the
value of GICR_VPROPBASER still be the reset value. According to GIC
spec, the reset value of IDbits in GICR_VPROPBASER is architecturally
UNKNOWN, and the GIC will behave as if all virtual LPIs are out of
range if it is less than 0b1101. On our platform the GICR will simply
drop the incoming VLPI, which results in interrupt missing in Guest.
OK, it took me some time to page this horror back in. So let's see if
I can sum-up the issue correctly:
Sorry for not explaining the whole thing clearly...
- When a VM gets created, all the vPEs are mapped to CPU0's
redistributor.
Not exactly on VM geting created, but when the passthru PCI device driver in
Guest tries to enable MSI interrupts. The specific code is in its_map_vm().
- If a device starts emitting VLPIs targeting a vPE that has not run
yet, these VLPIs are forwarded to CPU0's redistributor.
- If CPU0 has itself never run any vPE, its GICR_PROPBASER is not
initialised, meaning that the IDbits field may contain a value that
makes the redistributor drop the interrupt on the floor.
Yes.
Is that a correct assessment of the issue you're seeing? If so, I
think you have a very good point here, and this looks like a hole in
the driver.
Comments below:
As no code will clear GICR_VPROPBASER at runtime, we can safely
initialize the IDbits field at boot time for each CPU to get rid of
this issue.
Signed-off-by: Heyi Guo
Signed-off-by: Heyi Guo
---
drivers/irqchip/irq-gic-v3-its.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index db20e99..6116215 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2144,6 +2144,20 @@ static void its_cpu_init_lpis(void)
val |= GICR_CTLR_ENABLE_LPIS;
writel_relaxed(val, rbase + GICR_CTLR);
+ /*
+* Temporary workaround for vlpi drop on Hi1620.
Why is this specific to this implementation? Isn't this an issue that
affects every GICv4 implementations?
This was an internal patch and I forgot to modify the comment before sending
out, either not 100% sure that it is the common behavior of GICv4 to drop VLPI
if IDbits is not correctly configured.
I can change it in V2.
+* IDbits must be set before any VLPI is sent to this CPU, or else the
+* VLPI will be considered as out of range and dropped.
+*/
+ if (gic_rdists->has_vlpis) {
+ void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
+
+ val = (LPI_NRBITS - 1) & GICR_VPROPBASER_IDBITS_MASK;
+ pr_info("GICv4: CPU%d: Init IDbits to 0x%llx for
GICR_VPROPBASER\n",
+ smp_processor_id(), val);
I don't think this pr_info is useful to a normal user, as it is only
debug information. I'm actually minded to demote a bunch of the GICv3
prints to pr_debug.
OK.
+ gits_write_vpropbaser(val, vlpi_base + GICR_VPROPBASER);
+ }
+
I think we need to clear GICR_VPENDBASER.Valid too (you can probably
reuse part of its_vpe_deschedule for that), so that we don't get into
a bizarre situation where CPU0's redistributor has some ancient
programming left in, and could start corrupting memory.
I can do that for safety. But is it possible of corrupting memory? Even if
GICR_VPENDBASER.Valid==1, I don't think it is possible that
GICR_VPENDBASER.Physical_Address equals to VPT_addr, so kernel should consider
vPE is not sheculed on CPU0 and only memory pointed by VPT_addr will be
modified. Please let me know if I'm wrong :)
/* Make sure the GIC has seen the above */
dsb(sy);
out:
--
1.8.3.1
Can you please respin this quickly with the above changes?
Sure.
Thanks,
Heyi
Thanks,
M.
[PATCH v2 0/2] fix possible memory leak and use-after-free in __uio_register_device
fix possible memory leak and use-after-free in __uio_register_device v1->v2: fix email From:line Liu Jian (2): driver: uio: fix possible memory leak in __uio_register_device driver: uio: fix possible use-after-free in __uio_register_device drivers/uio/uio.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) -- 2.7.4
[PATCH v2 1/2] driver: uio: fix possible memory leak in __uio_register_device
'idev' is malloced in __uio_register_device() and leak free it before
leaving from the uio_get_minor() error handing case, it will cause
memory leak.
Fixes: a93e7b331568 ("uio: Prevent device destruction while fds are
open")
Signed-off-by: Liu Jian
Reviewed-by: Hamish Martin
---
drivers/uio/uio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index b4ae2d9..4d20220 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -941,8 +941,10 @@ int __uio_register_device(struct module *owner,
atomic_set(>event, 0);
ret = uio_get_minor(idev);
- if (ret)
+ if (ret) {
+ kfree(idev);
return ret;
+ }
idev->dev.devt = MKDEV(uio_major, idev->minor);
idev->dev.class = _class;
--
2.7.4
Re: [PATCH v6 11/16] sched/fair: Add uclamp support to energy_compute()
On 22-Jan 12:13, Quentin Perret wrote:
> On Tuesday 15 Jan 2019 at 10:15:08 (+), Patrick Bellasi wrote:
> > The Energy Aware Scheduler (AES) estimates the energy impact of waking
[...]
> > + for_each_cpu_and(cpu, pd_mask, cpu_online_mask) {
> > + cfs_util = cpu_util_next(cpu, p, dst_cpu);
> > +
> > + /*
> > +* Busy time computation: utilization clamping is not
> > +* required since the ratio (sum_util / cpu_capacity)
> > +* is already enough to scale the EM reported power
> > +* consumption at the (eventually clamped) cpu_capacity.
> > +*/
>
> Right.
>
> > + sum_util += schedutil_cpu_util(cpu, cfs_util, cpu_cap,
> > + ENERGY_UTIL, NULL);
> > +
> > + /*
> > +* Performance domain frequency: utilization clamping
> > +* must be considered since it affects the selection
> > +* of the performance domain frequency.
> > +*/
>
> So that actually affects the way we deal with RT I think. I assume the
> idea is to say if you don't want to reflect the RT-go-to-max-freq thing
> in EAS (which is what we do now) you should set the min cap for RT to 0.
> Is that correct ?
By default configuration, RT tasks still go to max when uclamp is
enabled, since they get a util_min=1024.
If we want to save power on RT tasks, we can set a smaller util_min...
but not necessarily 0. A util_min=0 for RT tasks means to use just
cpu_util_rt() for that class.
> I'm fine with this conceptually but maybe the specific case of RT should
> be mentioned somewhere in the commit message or so ? I think it's
> important to say that clearly since this patch changes the default
> behaviour.
Default behavior for RT should not be affected. While a capping is
possible for those tasks... where do you see issues ?
Here we are just figuring out what's the capacity the task will run
at, if we will have clamped RT tasks will not be the max but: is that
a problem ?
> > + cpu_util = schedutil_cpu_util(cpu, cfs_util, cpu_cap,
> > + FREQUENCY_UTIL,
> > + cpu == dst_cpu ? p :
> > NULL);
> > + max_util = max(max_util, cpu_util);
> > }
> >
> > energy += em_pd_energy(pd->em_pd, max_util, sum_util);
>
> Thanks,
> Quentin
--
#include
Patrick Bellasi
[PATCH v2 2/2] driver: uio: fix possible use-after-free in __uio_register_device
In uio_dev_add_attributes() error handing case, idev is used after
device_unregister(), in which 'idev' has been released, touch idev cause
use-after-free.
Fixes: a93e7b331568 ("uio: Prevent device destruction while fds are
open")
Signed-off-by: Liu Jian
Reviewed-by: Hamish Martin
---
drivers/uio/uio.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 4d20220..7ee21c8 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -946,6 +946,7 @@ int __uio_register_device(struct module *owner,
return ret;
}
+ device_initialize(>dev);
idev->dev.devt = MKDEV(uio_major, idev->minor);
idev->dev.class = _class;
idev->dev.parent = parent;
@@ -956,7 +957,7 @@ int __uio_register_device(struct module *owner,
if (ret)
goto err_device_create;
- ret = device_register(>dev);
+ ret = device_add(>dev);
if (ret)
goto err_device_create;
@@ -988,9 +989,10 @@ int __uio_register_device(struct module *owner,
err_request_irq:
uio_dev_del_attributes(idev);
err_uio_dev_add_attributes:
- device_unregister(>dev);
+ device_del(>dev);
err_device_create:
uio_free_minor(idev);
+ put_device(>dev);
return ret;
}
EXPORT_SYMBOL_GPL(__uio_register_device);
--
2.7.4
[PATCH] tracing: probeevent: Correctly update remaining space in dynamic area
Commit 9178412ddf5a ("tracing: probeevent: Return consumed
bytes of dynamic area") improved the string fetching
mechanism by returning the number of required bytes after
copying the argument to the dynamic area. However, this
return value is now only used to increment the pointer
inside the dynamic area but misses updating the 'maxlen'
variable which indicates the remaining space in the dynamic
area.
This means that fetch_store_string() always reads the *total*
size of the dynamic area from the data_loc pointer instead of
the *remaining* size (and passes it along to
strncpy_from_{user,unsafe}) even if we're already about to
copy data into the middle of the dynamic area.
Fixes: 9178412ddf5a ("tracing: probeevent: Return consumed bytes of dynamic
area")
Signed-off-by: Andreas Ziegler
---
kernel/trace/trace_probe_tmpl.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_probe_tmpl.h b/kernel/trace/trace_probe_tmpl.h
index 5c56afc17cf8..0cf953e47584 100644
--- a/kernel/trace/trace_probe_tmpl.h
+++ b/kernel/trace/trace_probe_tmpl.h
@@ -182,8 +182,10 @@ store_trace_args(void *data, struct trace_probe *tp,
struct pt_regs *regs,
ret = process_fetch_insn(arg->code, regs, dl, base);
if (unlikely(ret < 0 && arg->dynamic))
*dl = make_data_loc(0, dyndata - base);
- else
+ else {
dyndata += ret;
+ maxlen -= ret;
+ }
}
}
--
2.17.1
RE: [PATCH 4/4] irq: imx: irqsteer: add multi output interrupts support
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Tuesday, January 22, 2019 6:59 PM
> To: Aisheng Dong ; linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; shawn...@kernel.org; dl-linux-imx
> ; robh...@kernel.org; devicet...@vger.kernel.org;
> t...@linutronix.de; Marc Zyngier
> Subject: Re: [PATCH 4/4] irq: imx: irqsteer: add multi output interrupts
> support
>
> Am Dienstag, den 22.01.2019, 10:39 + schrieb Aisheng Dong:
> > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > Sent: Friday, January 18, 2019 6:23 PM
> >
> > [...]
> > > > > This has been discussed when upstreaming the driver. The
> > > > > controller may support multiple output IRQs, but only one them
> > > > > is actually used depending on the CHANCTRL config. There is no
> > > > > use in hooking up all the output IRQs in DT, if only one of them
> > > > > is actually used. Some of the outputs may not even be visible to
> > > > > the Linux system, but may belong to a Cortex M4 subsystem. All
> > > > > of those configurations can be described in DT by changing the
> > > > > upstream interrupt and "fsl,channel" in a
> > >
> > > coherent way.
> > > > >
> > > > > Please correct me if my understanding is totally wrong.
> > > >
> > > > I'm afraid your understanding of CHAN seems wrong.
> > > > (Binding doc of that property needs change as well).
> > > >
> > > > On QXP DC SS, the IRQSTEER supports 512 interrupts with 8
> > > > interrupt output Conntected to GIC.
> > > > The current driver does not support it as it assumes only one
> > > > interrupt
> > >
> > > output used.
> > >
> > > Okay, so let's take a step back. The description in the QXP RM is
> > > actually better than what I've seen until now. Still it's totally
> > > confusing that
> the "channel"
> > > terminology used with different meanings in docs. Let's try to avoid
> > > this as much as possible.
> > >
> > > So to get things straight: Each irqsteer controller has a number of IRQ
> groups.
> > > All the input IRQs of one group are ORed together to form on output IRQ.
> > > Depending on the SoC integration, a group can contain 32 or
> > > 64 IRQs, where DCSS irqsteer on MX8M and the big 512 input
> > > controllers on QXP and QM both use 64 IRQs per group. You are
> > > claiming that the smaller controllers on both QXP am QM have only 32
> IRQs per group, right?
> > >
> > > So the only change that is needed is that the driver needs to know
> > > the number of input IRQs per group, with a default of 64 to not break DT
> compatibility.
> > >
> >
> > Not exactly.
> > from HW point of view , there're two parameters during IRQSTEER
> integration.
> > For example,
> > DC in QXP:
> > > > parameter IRQCHAN = 1; //Number of IRQ Channels/Slots
> > > > parameter NINT32 = 8; //Number of interrupts in
> > > > multiple
> of 32
>
> If this is always in multiples of 32, the only change we need to make to the
> driver is to fix DT binding and interpretation of the "fsl,irq-groups"
> property to
> be in multiples of 32.
>
> This means i.MX8MQ DCSS irqsteer would need to change to 2 irq-groups, but
> as this isn't used upstream yet we can still do this change without breaking
> too
> much stuff and I would rather correct this now than keeping a DT binding
> around that doesn't match the HW.
>
> > MIPI CSI in MQ:
> > > Parameter IRQCHAN= 1
> > > Parameter NINT32 = 1
> >
> > You will see no group concept used here. Only channel number and
> interrupts number.
> > The group is an IP internal concept that ORed a group of 64 interrupts
> > into an output interrupt. But it may also only use 32 interrupts in the same
> group.
>
> I suppose that the OR group size at that point is always 64 input IRQs per
> output IRQ, right? So with NINT32 == 1 you end up with 1 output IRQ, but for
> NINT32 == 3 you get 2 output IRQs, correct?
>
> > > Also if the connection between IRQ group and output IRQ is fixed,
> > > the driver should be more clever about handling the chained IRQ. If
> > > you know which of the upstream IRQs fired you only need to look at
> > > the 32 or 64 IRQ status registers of that specific group, not all of them.
> >
> > Yes, that's right.
> > I planned to do that later with a separate patch before.
>
> Let's do it right with the first patch. This doesn't seem like a big change.
>
> >
> > >
> > > Can you please clarify what the CHANCTRL setting changes in this setup?
> > >
> >
> > IRQsteer supports up to 5 separate CAHNNELS which each of them
> > supports up to 512 interrupts. CHANCTL is used to enable those respective
> CHAN output interrupts.
> > e.g.
> > 1~8 output interrupts of CHAN0.
> >
> > One notable thing is the each channel has a separate address space.
> > That means the chan1 reg address is not the one we specified in default reg
> property.
> > So the correct dts may be like for multi channels cases.
> > interrupt-controller@32e2d000 {
> > compatible =
Re: [PATCH V3] cacheinfo: Keep the old value if of_property_read_u32 fails
On Wed, Dec 19, 2018 at 04:16:03PM +0800, Huacai Chen wrote:
> Commit 448a5a552f336bd7b847b1951 ("drivers: base: cacheinfo: use OF
> property_read_u32 instead of get_property,read_number") makes cache
> size and number_of_sets be 0 if DT doesn't provide there values. I
> think this is unreasonable so make them keep the old values, which is
> the same as old kernels.
>
> Fixes: 448a5a552f33 ("drivers: base: cacheinfo: use OF property_read_u32
> instead of get_property,read_number")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Huacai Chen
> Reviewed-by: Sudeep Holla
> ---
> V2: Add Cc and Reviewed-by
> V3: Add ChangeLog
Sorry for the delay, now queued up.
greg k-h
Re: [PATCH 4/4] irq: imx: irqsteer: add multi output interrupts support
Am Dienstag, den 22.01.2019, 12:03 + schrieb Aisheng Dong: > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > Sent: Tuesday, January 22, 2019 6:59 PM > > > > Am Dienstag, den 22.01.2019, 10:39 + schrieb Aisheng Dong: > > > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > > > > > > > Sent: Friday, January 18, 2019 6:23 PM > > > > > > [...] > > > > > > This has been discussed when upstreaming the driver. The > > > > > > controller may support multiple output IRQs, but only one them > > > > > > is actually used depending on the CHANCTRL config. There is no > > > > > > use in hooking up all the output IRQs in DT, if only one of them > > > > > > is actually used. Some of the outputs may not even be visible to > > > > > > the Linux system, but may belong to a Cortex M4 subsystem. All > > > > > > of those configurations can be described in DT by changing the > > > > > > upstream interrupt and "fsl,channel" in a > > > > > > > > coherent way. > > > > > > > > > > > > Please correct me if my understanding is totally wrong. > > > > > > > > > > I'm afraid your understanding of CHAN seems wrong. > > > > > (Binding doc of that property needs change as well). > > > > > > > > > > On QXP DC SS, the IRQSTEER supports 512 interrupts with 8 > > > > > interrupt output Conntected to GIC. > > > > > The current driver does not support it as it assumes only one > > > > > interrupt > > > > > > > > output used. > > > > > > > > Okay, so let's take a step back. The description in the QXP RM is > > > > actually better than what I've seen until now. Still it's totally > > > > confusing that > > > > the "channel" > > > > terminology used with different meanings in docs. Let's try to avoid > > > > this as much as possible. > > > > > > > > So to get things straight: Each irqsteer controller has a number of IRQ > > > > groups. > > > > All the input IRQs of one group are ORed together to form on output IRQ. > > > > Depending on the SoC integration, a group can contain 32 or > > > > 64 IRQs, where DCSS irqsteer on MX8M and the big 512 input > > > > controllers on QXP and QM both use 64 IRQs per group. You are > > > > claiming that the smaller controllers on both QXP am QM have only 32 > > > > IRQs per group, right? > > > > > > > > So the only change that is needed is that the driver needs to know > > > > the number of input IRQs per group, with a default of 64 to not break DT > > > > compatibility. > > > > > > > > > > Not exactly. > > > from HW point of view , there're two parameters during IRQSTEER > > > > integration. > > > For example, > > > DC in QXP: > > > > > > > > > > > > > > > parameter IRQCHAN= 1; > > > > > > > > > > > > > > > //Number of IRQ Channels/Slots > > > > > parameter NINT32 = 8; //Number of interrupts in > > > > > multiple > > > > of 32 > > > > If this is always in multiples of 32, the only change we need to make to the > > driver is to fix DT binding and interpretation of the "fsl,irq-groups" > > property to > > be in multiples of 32. > > > > This means i.MX8MQ DCSS irqsteer would need to change to 2 irq-groups, but > > as this isn't used upstream yet we can still do this change without > > breaking too > > much stuff and I would rather correct this now than keeping a DT binding > > around that doesn't match the HW. > > > > We want to avoid using of irq-groups as it's wrong. > Stick to HW parameters, only channel number and interrupts number should be > used. The fsl,irq-groups property is exactly your NINT32 parameter above. I just wrongly assumed that it's always in multiples of 64, as that's what the i.MX8MQ DCSS irqsteer module looks like. We should fix this and be done with it. > > > MIPI CSI in MQ: > > > > > > > > Parameter IRQCHAN = 1 > > > > Parameter NINT32 = 1 > > > > > > You will see no group concept used here. Only channel number and > > > > interrupts number. > > > The group is an IP internal concept that ORed a group of 64 interrupts > > > into an output interrupt. But it may also only use 32 interrupts in the > > > same > > > > group. > > > > I suppose that the OR group size at that point is always 64 input IRQs per > > output IRQ, right? So with NINT32 == 1 you end up with 1 output IRQ, but for > > NINT32 == 3 you get 2 output IRQs, correct? > > Yes, that's right. > > > > > > > Also if the connection between IRQ group and output IRQ is fixed, > > > > the driver should be more clever about handling the chained IRQ. If > > > > you know which of the upstream IRQs fired you only need to look at > > > > the 32 or 64 IRQ status registers of that specific group, not all of > > > > them. > > > > > > Yes, that's right. > > > I planned to do that later with a separate patch before. > > > > Let's do it right with the first patch. This doesn't seem like a big change. > > > > We can do it. > > > > > > > > > > > > Can you please clarify what the CHANCTRL setting changes in this
Re: [for next][PATCH 2/2] x86/Kconfig: Select PCI_LOCKLESS_CONFIG if PCI is enabled
On Mon, Jan 21, 2019 at 11:19:58PM +, Sinan Kaya wrote:
> After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
> CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
> satisfied implicitly through dependencies on CONFIG_ACPI have to be
> specified directly.
>
> PCI_LOCKLESS_CONFIG depends on PCI but this dependency has not been
> mentioned in the Kconfig.
>
> Add an explicit dependency here.
>
> Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI
> set")
> Signed-off-by: Sinan Kaya
> ---
> arch/x86/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 568f339595ed..0519da6f8ee4 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -199,7 +199,7 @@ config X86
> select IRQ_FORCED_THREADING
> select NEED_SG_DMA_LENGTH
> select PCI_DOMAINS if PCI
> - select PCI_LOCKLESS_CONFIG
> + select PCI_LOCKLESS_CONFIG if PCI
> select PERF_EVENTS
> select RTC_LIB
> select RTC_MC146818_LIB
> --
AFAICT, this is not really fixing a random config build issue but only
correcting the dependency, right?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v4 4/4] perf record: implement --affinity=node|cpu option
On 21.01.2019 14:54, Jiri Olsa wrote: > On Wed, Jan 16, 2019 at 12:23:56PM +0300, Alexey Budankov wrote: >> >> Implement --affinity=node|cpu option for the record mode defaulting >> to system affinity mask bouncing. >> >> Signed-off-by: Alexey Budankov >> --- >> changes in v3: >> - adjusted indentation at record__parse_affinity() > > having problems to apply this one: > > Applying: perf record: allocate affinity masks > Applying: perf record: bind the AIO user space buffers to nodes > Applying: perf record: apply affinity masks when reading mmap buffers > Applying: perf record: implement --affinity=node|cpu option > error: corrupt patch at line 62 > Patch failed at 0004 perf record: implement --affinity=node|cpu option It looks like Arnaldo's perf/core is progressing fast. Currently I have this thing when building clean Arnaldo's perf/core: CC tests/hists_output.o In file included from util/session.c:26: util/sample-raw.h:9:6: error: redundant redeclaration of perf_evlist__s390_sample_raw [-Werror=redundant-decls] void perf_evlist__s390_sample_raw(struct perf_evlist *evlist, ^~~~ In file included from util/session.c:13: util/evlist.h:321:6: note: previous declaration of perf_evlist__s390_sample_raw was here void perf_evlist__s390_sample_raw(struct perf_evlist *evlist, union perf_event *event, ^~~~ CC tests/hists_cumulate.o CC tests/python-use.o CC util/s390-sample-raw.o Thanks, Alexey > > > jirka >
Re: [PATCH v4 3/4] perf record: apply affinity masks when reading mmap buffers
Hi,
On 21.01.2019 14:54, Jiri Olsa wrote:
> On Wed, Jan 16, 2019 at 12:23:05PM +0300, Alexey Budankov wrote:
>
> SNIP
>
>> static int record__mmap_read_evlist(struct record *rec, struct perf_evlist
>> *evlist,
>> bool overwrite)
>> {
>> @@ -755,6 +768,7 @@ static int record__mmap_read_evlist(struct record *rec,
>> struct perf_evlist *evli
>> struct perf_mmap *map = [i];
>>
>> if (map->base) {
>> +record__adjust_affinity(rec, map);
>> if (!record__aio_enabled(rec)) {
>> if (perf_mmap__push(map, rec, record__pushfn)
>> != 0) {
>> rc = -1;
>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
>> index 08cedb643ea6..178d3280ba62 100644
>> --- a/tools/perf/util/evlist.c
>> +++ b/tools/perf/util/evlist.c
>> @@ -1032,7 +1032,11 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
>> unsigned int pages,
>> * Its value is decided by evsel's write_backward.
>> * So should not be passed through const pointer.
>> */
>> -struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity =
>> affinity };
>> +struct mmap_params mp = {
>> +.nr_cblocks = nr_cblocks,
>> +.affinity = affinity,
>> +.cpu_map= cpu_map__new(NULL) /* from
>> /sys/devices/system/cpu/online */
>> +};
>
> cpu_map won't get released.. if there's no better solution,
> at least we could have it as static in build_node_mask..
> this way it will be created only once
nice catch, thanks!! moved the static into a separate cpu_map__online()
in cpumap.c and that simplified the changes a bit.
Alexey
>
> jirka
>
Re: [PATCH] ath: move spin_lock_bh to spin_lock in tasklet
Hi Zhiwei,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Zhiwei-Jiang/ath-move-spin_lock_bh-to-spin_lock-in-tasklet/20190121-185529
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
smatch warnings:
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:584 ath9k_tx_failed_tasklet()
warn: inconsistent returns 'bottom_half:'.
Locked on: line 584
Unlocked on: line 580
#
https://github.com/0day-ci/linux/commit/953929a8fc22ae7ab9adafed62c84a11c4be2270
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 953929a8fc22ae7ab9adafed62c84a11c4be2270
vim +584 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
27876a29 Sujith Manoharan 2011-04-13 572
27876a29 Sujith Manoharan 2011-04-13 573 void
ath9k_tx_failed_tasklet(unsigned long data)
27876a29 Sujith Manoharan 2011-04-13 574 {
27876a29 Sujith Manoharan 2011-04-13 575 struct ath9k_htc_priv *priv =
(struct ath9k_htc_priv *)data;
b587fc81 Sujith Manoharan 2011-04-13 576
953929a8 Zhiwei Jiang 2019-01-19 577 spin_lock(>tx.tx_lock);
27876a29 Sujith Manoharan 2011-04-13 578 if (priv->tx.flags &
ATH9K_HTC_OP_TX_DRAIN) {
27876a29 Sujith Manoharan 2011-04-13 579
spin_unlock_bh(>tx.tx_lock);
^^^
Missed this one.
27876a29 Sujith Manoharan 2011-04-13 580 return;
b587fc81 Sujith Manoharan 2011-04-13 581 }
953929a8 Zhiwei Jiang 2019-01-19 582 spin_unlock(>tx.tx_lock);
b587fc81 Sujith Manoharan 2011-04-13 583
27876a29 Sujith Manoharan 2011-04-13 @584 ath9k_htc_tx_drainq(priv,
>tx.tx_failed);
b587fc81 Sujith Manoharan 2011-04-13 585 }
27876a29 Sujith Manoharan 2011-04-13 586
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v4 1/4] can: m_can: Create a m_can platform framework
Wolfgang
Thanks for the review
On 1/22/19 2:16 AM, Wolfgang Grandegger wrote:
> Hello Dan,
>
> looks already quite good...
>
> Am 17.01.19 um 21:05 schrieb Dan Murphy:
>> Create a m_can platform framework that peripherial
>> devices can register to and use common code and register sets.
>> The peripherial devices may provide read/write and configuration
>> support of the IP.
>>
>> Signed-off-by: Dan Murphy
>> ---
>> drivers/net/can/m_can/m_can.c | 6 +
>> drivers/net/can/m_can/m_can_platform.c | 209 +
>> drivers/net/can/m_can/m_can_platform.h | 163 +++
>> 3 files changed, 378 insertions(+)
>> create mode 100644 drivers/net/can/m_can/m_can_platform.c
>> create mode 100644 drivers/net/can/m_can/m_can_platform.h
>>
>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>> index 9b449400376b..f817b28582e9 100644
>> --- a/drivers/net/can/m_can/m_can.c
>> +++ b/drivers/net/can/m_can/m_can.c
>> @@ -414,6 +414,9 @@ static inline void m_can_config_endisable(const struct
>> m_can_priv *priv,
>> u32 timeout = 10;
>> u32 val = 0;
>>
>> +if (cccr & CCCR_CSR)
>> +cccr &= ~CCCR_CSR;
>> +
>
> This is an unrelated change/fix. Should go somewhere else.
>
I thought I pulled this and the change below out of of this patchset.
>> if (enable) {
>> /* enable m_can configuration */
>> m_can_write(priv, M_CAN_CCCR, cccr | CCCR_INIT);
>> @@ -1155,6 +1158,9 @@ static void m_can_chip_config(struct net_device *dev)
>> m_can_set_bittiming(dev);
>>
>> m_can_config_endisable(priv, false);
>> +
>> +if (priv->device_init)
>> +priv->device_init(priv);
>> }
>>
>> static void m_can_start(struct net_device *dev)
>> diff --git a/drivers/net/can/m_can/m_can_platform.c
>> b/drivers/net/can/m_can/m_can_platform.c
>> new file mode 100644
>> index ..03172911323a
>> --- /dev/null
>> +++ b/drivers/net/can/m_can/m_can_platform.c
>> @@ -0,0 +1,209 @@
>> +/*
>> + * CAN bus driver for Bosch M_CAN controller
>> + *
>> + * Copyright (C) 2014 Freescale Semiconductor, Inc.
>> + * Dong Aisheng
>> + *
>> + * Bosch M_CAN user manual can be obtained from:
>> + * http://www.bosch-semiconductors.de/media/pdf_1/ipmodules_1/m_can/
>> + * mcan_users_manual_v302.pdf
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "m_can_platform.h"
>> +
>> +struct m_can_plat_priv {
>> +void __iomem *base;
>> +void __iomem *mram_base;
>> +};
>> +
>> +static u32 iomap_read_reg(struct m_can_classdev *m_can_class, int reg)
>> +{
>> +struct m_can_plat_priv *priv = (struct m_can_plat_priv
>> *)m_can_class->device_data;
>> +
>> +return readl(priv->base + reg);
>> +}
>> +
>> +static u32 iomap_read_fifo(struct m_can_classdev *m_can_class, int
>> addr_offset)
>
> Why not just "offset".
>
I can change the name
>> +{
>> +struct m_can_plat_priv *priv = (struct m_can_plat_priv
>> *)m_can_class->device_data;
>> +
>> +return readl(priv->mram_base + addr_offset);
>> +}
>> +
>> +static int iomap_write_reg(struct m_can_classdev *m_can_class, int reg, int
>> val)
>> +{
>> +struct m_can_plat_priv *priv = (struct m_can_plat_priv
>> *)m_can_class->device_data;
>> +
>> +writel(val, priv->base + reg);
>> +
>> +return 0;
>> +}
>> +
>> +static int iomap_write_fifo(struct m_can_classdev *m_can_class, int
>> addr_offset, int val)
>> +{
>> +struct m_can_plat_priv *priv = (struct m_can_plat_priv
>> *)m_can_class->device_data;
>> +
>> +writel(val, priv->base + addr_offset);
>> +
>> +return 0;
>> +}
>> +
>> +static int m_can_plat_probe(struct platform_device *pdev)
>> +{
>> +struct m_can_classdev *mcan_class;
>> +struct m_can_plat_priv *priv;
>> +struct resource *res;
>> +void __iomem *addr;
>> +void __iomem *mram_addr;
>> +int irq, ret = 0;
>> +
>> +mcan_class = m_can_core_allocate_dev(>dev);
>> +priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
>> +if (!priv)
>> +return -ENOMEM;
>> +
>> +mcan_class->device_data = priv;
>> +
>> +m_can_core_get_clocks(mcan_class);
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "m_can");
>> +addr = devm_ioremap_resource(>dev, res);
>> +irq = platform_get_irq_byname(pdev, "int0");
>> +if (IS_ERR(addr) || irq < 0) {
>> +ret = -EINVAL;
>> +goto failed_ret;
>> +}
>> +
>> +/* message ram could be shared */
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "message_ram");
>> +if (!res) {
>> +ret = -ENODEV;
>> +goto failed_ret;
>> +}
>> +
>> +
Re: [PATCH] iommu/intel-iommu: fix memory leak in intel_iommu_put_resv_regions()
On Wed, Jan 16, 2019 at 08:11:44PM +0100, Gerald Schaefer wrote:
> Commit 9d3a4de4cb8d ("iommu: Disambiguate MSI region types") changed
> the reserved region type in intel_iommu_get_resv_regions() from
> IOMMU_RESV_RESERVED to IOMMU_RESV_MSI, but it forgot to also change
> the type in intel_iommu_put_resv_regions().
>
> This leads to a memory leak, because now the check in
> intel_iommu_put_resv_regions() for IOMMU_RESV_RESERVED will never
> be true, and no allocated regions will be freed.
>
> Fix this by changing the region type in intel_iommu_put_resv_regions()
> to IOMMU_RESV_MSI, matching the type of the allocated regions.
>
> Fixes: 9d3a4de4cb8d ("iommu: Disambiguate MSI region types")
> Cc: # v4.11+
> Signed-off-by: Gerald Schaefer
> ---
> drivers/iommu/intel-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
Re: [PATCH v4] media: vimc: Add vimc-streamer for stream control
Hi Lucas,
On 1/21/19 11:05 PM, Lucas A. M. Magalhaes wrote:
> Add a linear pipeline logic for the stream control. It's created by
> walking backwards on the entity graph. When the stream starts it will
> simply loop through the pipeline calling the respective process_frame
> function of each entity.
>
> Fixes: f2fe89061d797 ("vimc: Virtual Media Controller core, capture
> and sensor")
> Cc: sta...@vger.kernel.org # for v4.20
> Signed-off-by: Lucas A. M. Magalhães
lgtm, thanks for the patch.
Acked-by: Helen Koike
Regards,
Helen
> ---
>
> The actual approach for streaming frames on vimc uses a recursive
> logic[1]. This algorithm may cause problems as the stack usage
> increases a with the topology. For the actual topology almost 1Kb of
> stack is used if compiled with KASAN on a 64bit architecture. However
> the topology is fixed and hard-coded on vimc-core[2]. So it's a
> controlled situation if used as is.
>
> [1]
> The stream starts on vim-sensor's thread
> https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-sensor.c#n204
> It proceeds calling successively vimc_propagate_frame
> https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-common.c#n210
> Then processes_frame on the next entity
> https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-scaler.c#n349
> https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-debayer.c#n483
> This goes until the loop ends on a vimc-capture device
> https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-capture.c#n358
>
> [2]https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-core.c#n80
>
> Thanks the review Helen. I've made the change you pointed out. There was
> really
> a bug for single entity pipelines.
>
> Changed from v3:
> * Fix vimc_streamer_pipeline_init and vimc_streamer_pipeline_terminate for a
> single entity pipeline.
> * Remove unnecessary checks and comments.
> * Alignment and style.
>
> drivers/media/platform/vimc/Makefile| 3 +-
> drivers/media/platform/vimc/vimc-capture.c | 18 +-
> drivers/media/platform/vimc/vimc-common.c | 35
> drivers/media/platform/vimc/vimc-common.h | 15 +-
> drivers/media/platform/vimc/vimc-debayer.c | 26 +--
> drivers/media/platform/vimc/vimc-scaler.c | 28 +--
> drivers/media/platform/vimc/vimc-sensor.c | 56 ++
> drivers/media/platform/vimc/vimc-streamer.c | 188
> drivers/media/platform/vimc/vimc-streamer.h | 38
> 9 files changed, 260 insertions(+), 147 deletions(-)
> create mode 100644 drivers/media/platform/vimc/vimc-streamer.c
> create mode 100644 drivers/media/platform/vimc/vimc-streamer.h
>
> diff --git a/drivers/media/platform/vimc/Makefile
> b/drivers/media/platform/vimc/Makefile
> index 4b2e3de7856e..c4fc8e7d365a 100644
> --- a/drivers/media/platform/vimc/Makefile
> +++ b/drivers/media/platform/vimc/Makefile
> @@ -5,6 +5,7 @@ vimc_common-objs := vimc-common.o
> vimc_debayer-objs := vimc-debayer.o
> vimc_scaler-objs := vimc-scaler.o
> vimc_sensor-objs := vimc-sensor.o
> +vimc_streamer-objs := vimc-streamer.o
>
> obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o
> vimc-debayer.o \
> - vimc_scaler.o vimc_sensor.o
> + vimc_scaler.o vimc_sensor.o vimc_streamer.o
> diff --git a/drivers/media/platform/vimc/vimc-capture.c
> b/drivers/media/platform/vimc/vimc-capture.c
> index aaeddf24b042..93837d9eecd2 100644
> --- a/drivers/media/platform/vimc/vimc-capture.c
> +++ b/drivers/media/platform/vimc/vimc-capture.c
> @@ -24,6 +24,7 @@
> #include
>
> #include "vimc-common.h"
> +#include "vimc-streamer.h"
>
> #define VIMC_CAP_DRV_NAME "vimc-capture"
>
> @@ -44,7 +45,7 @@ struct vimc_cap_device {
> spinlock_t qlock;
> struct mutex lock;
> u32 sequence;
> - struct media_pipeline pipe;
> + struct vimc_stream stream;
> };
>
> static const struct v4l2_pix_format fmt_default = {
> @@ -248,14 +249,13 @@ static int vimc_cap_start_streaming(struct vb2_queue
> *vq, unsigned int count)
> vcap->sequence = 0;
>
> /* Start the media pipeline */
> - ret = media_pipeline_start(entity, >pipe);
> + ret = media_pipeline_start(entity, >stream.pipe);
> if (ret) {
> vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
> return ret;
> }
>
> - /* Enable streaming from the pipe */
> - ret = vimc_pipeline_s_stream(>vdev.entity, 1);
> + ret = vimc_streamer_s_stream(>stream, >ved, 1);
> if (ret) {
> media_pipeline_stop(entity);
> vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
> @@ -273,8 +273,7 @@ static void vimc_cap_stop_streaming(struct vb2_queue *vq)
> {
> struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
>
> - /* Disable streaming from the pipe */
> -
Re: question about head_64.S
On Tue, Jan 22, 2019 at 03:31:25PM +0800, Cao jin wrote: > Hi, Kirll, > > On 1/15/19 7:45 PM, Cao jin wrote: > > Hi, > > I have been digging into this file for a while, and I still have 2 > > questions unclear, hope to get your help. > > > > > > > 2. > > Why gdt64 has following definition?: > > > > gdt64: > > .word gdt_end - gdt > > .long 0 > > .word 0 > > .quad 0 > > > > obviously, gdt64 stores the GDTR content under x86_64, which is 10 bytes > > long, so why not just: > > > > gdt64: > > .word gdt_end - gdt > > .quad 0 > > > > With above modification, it can boot. > > > > Seems you introduced gdt64 code in commit beebaccd50, could you help > with this question? Looks like you are right. I've got confused at some point. Could you prepare a patch? > And it also remind me of another question about adjust_got which is also > introduced by you. Because I failed to construct a test environment with > ld version less than 2.24 until now, so I wanna do a quick ask here: > does it make sense to adjust GOT from the 4th entry of it? Because as I > know, the first 3 entries are special one, which (I guess) will be not used. No. These 3 entries are reserved for a special symbols (like entry 0 for _DYNAMIC). It means linker should not use these entries for normal symbols, but it doesn't mean that they don't need to be adjusted during the load. -- Kirill A. Shutemov
Re: [PATCH v2 0/4] mtd: rawnand: Support bad block markers in first, second or last page
On 22.01.19 12:22, Schrempf Frieder wrote: > From: Frieder Schrempf > > Currently supported bad block marker positions within the block are: > * in first page only > * in last page only > * in first or second page > > Some ESMT NANDs are known to have been shipped by the manufacturer > with bad block markers in the first or last page, instead of the > first or second page. > > Also the datasheets for Cypress/Spansion/AMD NANDs claim that the > first, second *and* last page needs to be checked. > > Therefore we make it possible to set NAND_BBT_SCAN2NDPAGE and > NAND_BBT_SCANLASTPAGE at the same time to scan/set all three pages. In v2 the flags were redefined and are now called NAND_BBM_FIRSTPAGE, NAND_BBM_FIRSTPAGE and NAND_BBM_LASTPAGE. I forgot to edit this paragraph. > > This series also contains patches for AMD/Spansion/Cypress and ESMT > chips to enable both flags at the same time. > --- > Changes in v2: > == > * Rebase on 5.0-rc1 > * Add patch to move bad block marker position info to a common place and >rename/prepare existing flags > * improve/rename function nand_bbm_get_next_page() to use new flags > --- > Frieder Schrempf (4): >mtd: nand: Always store info about bad block markers in chip struct >mtd: rawnand: Support bad block markers in first, second or last page >mtd: rawnand: ESMT: Also use the last page for bad block markers >mtd: rawnand: AMD: Also use the last page for bad block markers > > drivers/mtd/nand/onenand/onenand_base.c | 2 +- > drivers/mtd/nand/onenand/onenand_bbt.c | 2 +- > drivers/mtd/nand/raw/internals.h| 1 + > drivers/mtd/nand/raw/nand_amd.c | 8 +++- > drivers/mtd/nand/raw/nand_base.c| 64 + > drivers/mtd/nand/raw/nand_bbt.c | 28 +-- > drivers/mtd/nand/raw/nand_esmt.c| 9 +++- > drivers/mtd/nand/raw/nand_hynix.c | 4 +- > drivers/mtd/nand/raw/nand_macronix.c| 2 +- > drivers/mtd/nand/raw/nand_micron.c | 2 +- > drivers/mtd/nand/raw/nand_samsung.c | 4 +- > drivers/mtd/nand/raw/nand_toshiba.c | 2 +- > drivers/mtd/nand/raw/sh_flctl.c | 4 +- > include/linux/mtd/bbm.h | 14 +- > include/linux/mtd/rawnand.h | 16 +++ > 15 files changed, 100 insertions(+), 62 deletions(-) >
Re: [PATCH v7 2/3] arm64: implement ftrace with regs
Hi Balbir!
On Tue, Jan 22, 2019 at 02:39:32PM +1300, Singh, Balbir wrote:
>
> On 1/19/19 5:39 AM, Torsten Duwe wrote:
> > + */
> > +ftrace_common_return:
> > + /* restore function args */
> > + ldp x0, x1, [sp]
> > + ldp x2, x3, [sp, #S_X2]
> > + ldp x4, x5, [sp, #S_X4]
> > + ldp x6, x7, [sp, #S_X6]
> > + ldr x8, [sp, #S_X8]
> > +
> > + /* restore fp and x28 */
> > + ldp x28, x29, [sp, #S_X28]
> > +
> > + ldr lr, [sp, #S_LR]
> > + ldr x9, [sp, #S_PC]
>
> Is it fair to assume that we never modify registers beyond LR and PC as a
> result of ftrace/livepatching? I presume it is, but just checking.
These are either callee-save or scratch. Whatever is called, ftrace framework
functions or replacement functions, must preserve the callee-saved regs; and
the caller, who made a function call (sic!-) saves caller-saved and marks the
rest dead on return. So it's the arguments that matter after all.
As you can see, disabling IPA-RA is cruicial here.
Or are you talking about deliberate argument manipulation?
> > + unsigned long pc = rec->ip + REC_IP_BRANCH_OFFSET;
> > + u32 old, new;
> > +
> > + old = aarch64_insn_gen_branch_imm(pc, old_addr, true);
> > + new = aarch64_insn_gen_branch_imm(pc, addr, true);
> > +
>
> Is this a branch or a call? Does addr always fit in the immediate limits?
As Julien has now pointed out, the correct enum value AARCH64_INSN_BRANCH_LINK
should clarify this. It will surely fit for the kernel proper, and the modules
are handled with the trampolines.
> > + return ftrace_modify_code(pc, old, new, true);
>
> Can you talk to the semantics of whether this operation is atomic w.r.t
> system? Will old and new return consistent values? Given the nature of
> ftrace, I presume it's well isolated.
aarch64_insn_patch_text_nosync() does a __flush_icache_range() on success.
Mark wrote that this is already sufficient IIRC. (I had memory barriers
there, when I was still trying to modify 2 insns every time).
>
> > + if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_REGS) &&
> > + addr == MCOUNT_ADDR) {
> > + old = aarch64_insn_gen_nop();
> > + new = MOV_X9_X30;
> > + pc -= REC_IP_BRANCH_OFFSET;
> > + return ftrace_modify_code(pc, old, new, validate);
>
> I presume all the icache flush and barrier handling is in
> ftrace_modify_code()?
Yes, see above.
> > + }
> > +
> > if (offset < -SZ_128M || offset >= SZ_128M) {
> > #ifdef CONFIG_ARM64_MODULE_PLTS
> > u32 replaced;
> > --- a/arch/arm64/include/asm/module.h
> > +++ b/arch/arm64/include/asm/module.h
> > @@ -32,7 +32,8 @@ struct mod_arch_specific {
> > struct mod_plt_sec init;
> >
> > /* for CONFIG_DYNAMIC_FTRACE */
> > - struct plt_entry*ftrace_trampoline;
> > + struct plt_entry*ftrace_trampolines;
> > +#define MOD_ARCH_NR_FTRACE_TRAMPOLINES 2
>
> I don't see the generation of ftrace_trampolines[1]
>
That was further up, install_ftrace_trampoline() in kernel/ftrace.c.
+ if (*addr == FTRACE_ADDR)
+ mod_trampoline = >arch.ftrace_trampolines[0];
+ else if (*addr == FTRACE_REGS_ADDR)
+ mod_trampoline = >arch.ftrace_trampolines[1];
[...]
+ trampoline = get_plt_entry(*addr, mod_trampoline);
+
+ if (!plt_entries_equal(mod_trampoline, )) {
[...]
get_plt_entry() generates a small bunch of instructions that easily
fit into the argument registers. Compare commit bdb85cd1d20669dfae8
for the new trampoline insns.
Hope I've covered all your concerns,
Torsten
Re: [RFC PATCH net-next 2/5] net: 8021q: vlan_dev: add vid tag for uc and mc address lists
On Mon, Jan 21, 2019 at 03:37:41PM -0800, Florian Fainelli wrote: On 12/4/18 3:42 PM, Ivan Khoronzhuk wrote: On Tue, Dec 04, 2018 at 11:49:27AM -0800, Florian Fainelli wrote: [...] Ivan, based on the recent submission I copied you on [1], it sounds like we want to move ahead with your proposal to extend netdev_hw_addr with a vid member. On second thought, your approach is good and if we enclose the vid member within an #if IS_ENABLED(CONFIG_VLAN)8021Q) we should be good for most foreseeable use cases, if not, we can always introduce a variable size/defined context in the future. Can you resubmit this patch series as non-RFC in the next few days so I can also repost mine [1] and take advantage of these changes for multicast over VLAN when VLAN filtering is globally enabled on the device. [1]: https://www.spinics.net/lists/netdev/msg544722.html Thanks! Yes, sure. I can start to do that in several days. Just a little busy right now. Just before doing this, maybe some comments could be added as it has more attention now. Meanwhile I can send alternative variant but based on real dev splitting addresses between vlans. In this approach it leaves address space w/o vid extension but requires more changes to vlan core. Drawback here that to change one address alg traverses all related vlan addresses, it can be cpu/time wasteful, if it's done regularly, but saves memory Basically it's implemented locally in cpsw and requires more changes to move it as some vlan core auxiliary functions to be reused. But it can work only with vlans directly on top of real dev, which is fixable. Core function here: __hw_addr_ref_sync_dev it is called only for address the link of which was increased/decreased, thus update made only on one address, comparing it for every vlan dev. It was added with this patch: [1] net: core: dev_addr_lists: add auxiliary func to handle reference address update e7946760de5852f32 And used by this patch: [2] net: ethernet: ti: cpsw: fix vlan mcast 15180eca569bfe1d4d So, idea is to move [2] to be vlan core auxiliary function to be reused by NIC drivers. But potentially it can bring a little more changes I assume: 1) add priv_flag |= IFF_IV_FLT (independent vlan filtering). It allows to reuse this flag for farther changes, probably for per vlan allmulti or so. 2) real dev has to have complete list for vlans, not only their vids, but also all vlandevs in device chain above it. So changes in add_vid can be required. Vlan core can assign vlan dev pointer to real device only after it's completely initialized. And for propagation reasons it requires every device in infrastructure to be aware. That seems doable, but depends not only on me. 3) Move code from [2] to be auxiliary vlan core API for setting mc and uc. From this patch only one function is cpsw specific: cpsw_set_mc(). The rest can be applicable on every NIC supporting IFF_IV_FLT. 4) Move code from link below to do the same but for uc addresses: https://git.linaro.org/people/ivan.khoronzhuk/tsn_kernel.git/commit/?h=ucast_vlan_fix=ebc88a7d8758759322d9ff88f25f8bac51ce7219 here only one func cpsw specific: cpsw_set_uc() the rest can be generic. As third alternative, we can think about how to reduce memory for addresses by reusing them or else, but this is as continuation of addr+vid approach, and API probably would be the same. Then all this can be compared for proper decision. -- Florian -- Regards, Ivan Khoronzhuk
Re: [PATCH v2 1/4] mtd: nand: Always store info about bad block markers in chip struct
On 22.01.19 12:22, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> The information about where the manufacturer puts the bad block
> markers inside the bad block and in the OOB data is stored in
> different places. Let's move this information to nand_chip.options
> and nand_chip.badblockpos.
>
> As this chip-specific information is not directly related to the
> bad block table (BBT) and to make them more flexible, we also rename
> the flags and create separate flags for storing the BBM in the first
> and the second page instead of the combined flag.
>
> Signed-off-by: Frieder.Schrempf
This dot between my first and last name is obviously rubbish ;)
> ---
> drivers/mtd/nand/onenand/onenand_base.c | 2 +-
> drivers/mtd/nand/onenand/onenand_bbt.c | 2 +-
> drivers/mtd/nand/raw/nand_amd.c | 2 +-
> drivers/mtd/nand/raw/nand_base.c| 14 --
> drivers/mtd/nand/raw/nand_bbt.c | 5 +++--
> drivers/mtd/nand/raw/nand_esmt.c| 2 +-
> drivers/mtd/nand/raw/nand_hynix.c | 4 ++--
> drivers/mtd/nand/raw/nand_macronix.c| 2 +-
> drivers/mtd/nand/raw/nand_micron.c | 2 +-
> drivers/mtd/nand/raw/nand_samsung.c | 4 ++--
> drivers/mtd/nand/raw/nand_toshiba.c | 2 +-
> drivers/mtd/nand/raw/sh_flctl.c | 4 ++--
> include/linux/mtd/bbm.h | 14 +-
> include/linux/mtd/rawnand.h | 16
> 14 files changed, 41 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/mtd/nand/onenand/onenand_base.c
> b/drivers/mtd/nand/onenand/onenand_base.c
> index 4ca4b194e7d7..d6701b8f031f 100644
> --- a/drivers/mtd/nand/onenand/onenand_base.c
> +++ b/drivers/mtd/nand/onenand/onenand_base.c
> @@ -2458,7 +2458,7 @@ static int onenand_default_block_markbad(struct
> mtd_info *mtd, loff_t ofs)
> bbm->bbt[block >> 2] |= 0x01 << ((block & 0x03) << 1);
>
> /* We write two bytes, so we don't have to mess with 16-bit access
> */
> -ofs += mtd->oobsize + (bbm->badblockpos & ~0x01);
> +ofs += mtd->oobsize + (this->badblockpos & ~0x01);
> /* FIXME : What to do when marking SLC block in partition
>* with MLC erasesize? For now, it is not advisable to
>* create partitions containing both SLC and MLC regions.
> diff --git a/drivers/mtd/nand/onenand/onenand_bbt.c
> b/drivers/mtd/nand/onenand/onenand_bbt.c
> index dde20487937d..880b0abd36c8 100644
> --- a/drivers/mtd/nand/onenand/onenand_bbt.c
> +++ b/drivers/mtd/nand/onenand/onenand_bbt.c
> @@ -191,7 +191,7 @@ static int onenand_scan_bbt(struct mtd_info *mtd, struct
> nand_bbt_descr *bd)
> return -ENOMEM;
>
> /* Set the bad block position */
> - bbm->badblockpos = ONENAND_BADBLOCK_POS;
> + this->badblockpos = NAND_BBM_POS_ONENAND;
>
> /* Set erase shift */
> bbm->bbt_erase_shift = this->erase_shift;
> diff --git a/drivers/mtd/nand/raw/nand_amd.c b/drivers/mtd/nand/raw/nand_amd.c
> index 890c5b43e03c..6202cbf7ee8d 100644
> --- a/drivers/mtd/nand/raw/nand_amd.c
> +++ b/drivers/mtd/nand/raw/nand_amd.c
> @@ -40,7 +40,7 @@ static void amd_nand_decode_id(struct nand_chip *chip)
> static int amd_nand_init(struct nand_chip *chip)
> {
> if (nand_is_slc(chip))
> - chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
> + chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE;
>
> return 0;
> }
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index cca4b24d2ffa..9ef7b86cdc42 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -298,11 +298,12 @@ static int nand_block_bad(struct nand_chip *chip,
> loff_t ofs)
> int page, page_end, res;
> u8 bad;
>
> - if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
> + if (chip->options & NAND_BBM_LASTPAGE)
> ofs += mtd->erasesize - mtd->writesize;
>
> page = (int)(ofs >> chip->page_shift) & chip->pagemask;
> - page_end = page + (chip->bbt_options & NAND_BBT_SCAN2NDPAGE ? 2 : 1);
> + page_end = page + (((chip->options & NAND_BBM_FIRSTPAGE) &&
> + (chip->options & NAND_BBM_SECONDPAGE)) ? 2 : 1);
>
> for (; page < page_end; page++) {
> res = chip->ecc.read_oob(chip, page);
> @@ -541,7 +542,7 @@ static int nand_default_block_markbad(struct nand_chip
> *chip, loff_t ofs)
> ops.mode = MTD_OPS_PLACE_OOB;
>
> /* Write to first/last page(s) if necessary */
> - if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
> + if (chip->options & NAND_BBM_LASTPAGE)
> ofs += mtd->erasesize - mtd->writesize;
> do {
> res = nand_do_write_oob(chip, ofs, );
> @@ -550,7 +551,8 @@ static int nand_default_block_markbad(struct nand_chip
> *chip, loff_t ofs)
>
> i++;
> ofs += mtd->writesize;
> - } while
Re: [PATCH] tracing: probeevent: Correctly update remaining space in dynamic area
On Tue, 22 Jan 2019 13:48:48 +0100
Andreas Ziegler wrote:
> Commit 9178412ddf5a ("tracing: probeevent: Return consumed
> bytes of dynamic area") improved the string fetching
> mechanism by returning the number of required bytes after
> copying the argument to the dynamic area. However, this
> return value is now only used to increment the pointer
> inside the dynamic area but misses updating the 'maxlen'
> variable which indicates the remaining space in the dynamic
> area.
Oops! Good catch! :)
>
> This means that fetch_store_string() always reads the *total*
> size of the dynamic area from the data_loc pointer instead of
> the *remaining* size (and passes it along to
> strncpy_from_{user,unsafe}) even if we're already about to
> copy data into the middle of the dynamic area.
>
This looks good to me.
Acked-by: Masami Hiramatsu
Thank you!!
> Fixes: 9178412ddf5a ("tracing: probeevent: Return consumed bytes of dynamic
> area")
> Signed-off-by: Andreas Ziegler
> ---
> kernel/trace/trace_probe_tmpl.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace_probe_tmpl.h b/kernel/trace/trace_probe_tmpl.h
> index 5c56afc17cf8..0cf953e47584 100644
> --- a/kernel/trace/trace_probe_tmpl.h
> +++ b/kernel/trace/trace_probe_tmpl.h
> @@ -182,8 +182,10 @@ store_trace_args(void *data, struct trace_probe *tp,
> struct pt_regs *regs,
> ret = process_fetch_insn(arg->code, regs, dl, base);
> if (unlikely(ret < 0 && arg->dynamic))
> *dl = make_data_loc(0, dyndata - base);
> - else
> + else {
> dyndata += ret;
> + maxlen -= ret;
> + }
> }
> }
>
> --
> 2.17.1
>
--
Masami Hiramatsu
RE: [PATCH 4/4] irq: imx: irqsteer: add multi output interrupts support
> From: Lucas Stach [mailto:l.st...@pengutronix.de] > Sent: Tuesday, January 22, 2019 8:52 PM > To: Aisheng Dong ; linux-kernel@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org; shawn...@kernel.org; dl-linux-imx > ; robh...@kernel.org; devicet...@vger.kernel.org; > t...@linutronix.de; Marc Zyngier > Subject: Re: [PATCH 4/4] irq: imx: irqsteer: add multi output interrupts > support > > Am Dienstag, den 22.01.2019, 12:03 + schrieb Aisheng Dong: > > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > > Sent: Tuesday, January 22, 2019 6:59 PM > > > > > > Am Dienstag, den 22.01.2019, 10:39 + schrieb Aisheng Dong: > > > > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > > > > > > > > > Sent: Friday, January 18, 2019 6:23 PM > > > > > > > > [...] > > > > > > > This has been discussed when upstreaming the driver. The > > > > > > > controller may support multiple output IRQs, but only one > > > > > > > them is actually used depending on the CHANCTRL config. > > > > > > > There is no use in hooking up all the output IRQs in DT, if > > > > > > > only one of them is actually used. Some of the outputs may > > > > > > > not even be visible to the Linux system, but may belong to a > > > > > > > Cortex M4 subsystem. All of those configurations can be > > > > > > > described in DT by changing the upstream interrupt and > > > > > > > "fsl,channel" in a > > > > > > > > > > coherent way. > > > > > > > > > > > > > > Please correct me if my understanding is totally wrong. > > > > > > > > > > > > I'm afraid your understanding of CHAN seems wrong. > > > > > > (Binding doc of that property needs change as well). > > > > > > > > > > > > On QXP DC SS, the IRQSTEER supports 512 interrupts with 8 > > > > > > interrupt output Conntected to GIC. > > > > > > The current driver does not support it as it assumes only one > > > > > > interrupt > > > > > > > > > > output used. > > > > > > > > > > Okay, so let's take a step back. The description in the QXP RM > > > > > is actually better than what I've seen until now. Still it's > > > > > totally confusing that > > > > > > the "channel" > > > > > terminology used with different meanings in docs. Let's try to > > > > > avoid this as much as possible. > > > > > > > > > > So to get things straight: Each irqsteer controller has a number > > > > > of IRQ > > > > > > groups. > > > > > All the input IRQs of one group are ORed together to form on output > IRQ. > > > > > Depending on the SoC integration, a group can contain 32 or > > > > > 64 IRQs, where DCSS irqsteer on MX8M and the big 512 input > > > > > controllers on QXP and QM both use 64 IRQs per group. You are > > > > > claiming that the smaller controllers on both QXP am QM have > > > > > only 32 > > > > > > IRQs per group, right? > > > > > > > > > > So the only change that is needed is that the driver needs to > > > > > know the number of input IRQs per group, with a default of 64 to > > > > > not break DT > > > > > > compatibility. > > > > > > > > > > > > > Not exactly. > > > > from HW point of view , there're two parameters during IRQSTEER > > > > > > integration. > > > > For example, > > > > DC in QXP: > > > > > > > > > > > > > > > > parameter IRQCHAN = 1; > //Number of IRQ Channels/Slots > > > > > > parameter NINT32 = 8; //Number of interrupts in > multiple > > > > > > of 32 > > > > > > If this is always in multiples of 32, the only change we need to > > > make to the driver is to fix DT binding and interpretation of the > > > "fsl,irq-groups" property to be in multiples of 32. > > > > > > This means i.MX8MQ DCSS irqsteer would need to change to 2 > > > irq-groups, but as this isn't used upstream yet we can still do this > > > change without breaking too much stuff and I would rather correct > > > this now than keeping a DT binding around that doesn't match the HW. > > > > > > > We want to avoid using of irq-groups as it's wrong. > > Stick to HW parameters, only channel number and interrupts number should > be used. > > The fsl,irq-groups property is exactly your NINT32 parameter above. I just > wrongly assumed that it's always in multiples of 64, as that's what the > i.MX8MQ DCSS irqsteer module looks like. We should fix this and be done with > it. > No, not exactly the same thing. Using group will confuse people that the group is 32. However, internally Group is fixed 64 interrupts although it may not use all the 64 interrupts. E.g. 32 interrupts. See CHn_MINTDIS register which is also defined fixed to 64. The two HW parameter for integration is already very clear. We should use interrupts Number for the channel. Not group. > > > > MIPI CSI in MQ: > > > > > > > > > Parameter IRQCHAN= 1 > > > > > Parameter NINT32 = 1 > > > > > > > > You will see no group concept used here. Only channel number and > > > > > > interrupts number. > > > > The group is an IP internal concept that ORed a group of 64 > > > > interrupts into an output
Re: [PATCH v2 1/4] mtd: nand: Always store info about bad block markers in chip struct
On Tue, 22 Jan 2019 11:23:29 +
Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> The information about where the manufacturer puts the bad block
> markers inside the bad block and in the OOB data is stored in
> different places. Let's move this information to nand_chip.options
> and nand_chip.badblockpos.
>
> As this chip-specific information is not directly related to the
> bad block table (BBT) and to make them more flexible, we also rename
> the flags and create separate flags for storing the BBM in the first
> and the second page instead of the combined flag.
The separation for first and second page flags should IMO be done in a
separate patch. Looks good otherwise.
>
> Signed-off-by: Frieder.Schrempf
> ---
> drivers/mtd/nand/onenand/onenand_base.c | 2 +-
> drivers/mtd/nand/onenand/onenand_bbt.c | 2 +-
> drivers/mtd/nand/raw/nand_amd.c | 2 +-
> drivers/mtd/nand/raw/nand_base.c| 14 --
> drivers/mtd/nand/raw/nand_bbt.c | 5 +++--
> drivers/mtd/nand/raw/nand_esmt.c| 2 +-
> drivers/mtd/nand/raw/nand_hynix.c | 4 ++--
> drivers/mtd/nand/raw/nand_macronix.c| 2 +-
> drivers/mtd/nand/raw/nand_micron.c | 2 +-
> drivers/mtd/nand/raw/nand_samsung.c | 4 ++--
> drivers/mtd/nand/raw/nand_toshiba.c | 2 +-
> drivers/mtd/nand/raw/sh_flctl.c | 4 ++--
> include/linux/mtd/bbm.h | 14 +-
> include/linux/mtd/rawnand.h | 16
> 14 files changed, 41 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/mtd/nand/onenand/onenand_base.c
> b/drivers/mtd/nand/onenand/onenand_base.c
> index 4ca4b194e7d7..d6701b8f031f 100644
> --- a/drivers/mtd/nand/onenand/onenand_base.c
> +++ b/drivers/mtd/nand/onenand/onenand_base.c
> @@ -2458,7 +2458,7 @@ static int onenand_default_block_markbad(struct
> mtd_info *mtd, loff_t ofs)
> bbm->bbt[block >> 2] |= 0x01 << ((block & 0x03) << 1);
>
> /* We write two bytes, so we don't have to mess with 16-bit access */
> -ofs += mtd->oobsize + (bbm->badblockpos & ~0x01);
> +ofs += mtd->oobsize + (this->badblockpos & ~0x01);
> /* FIXME : What to do when marking SLC block in partition
>* with MLC erasesize? For now, it is not advisable to
>* create partitions containing both SLC and MLC regions.
> diff --git a/drivers/mtd/nand/onenand/onenand_bbt.c
> b/drivers/mtd/nand/onenand/onenand_bbt.c
> index dde20487937d..880b0abd36c8 100644
> --- a/drivers/mtd/nand/onenand/onenand_bbt.c
> +++ b/drivers/mtd/nand/onenand/onenand_bbt.c
> @@ -191,7 +191,7 @@ static int onenand_scan_bbt(struct mtd_info *mtd, struct
> nand_bbt_descr *bd)
> return -ENOMEM;
>
> /* Set the bad block position */
> - bbm->badblockpos = ONENAND_BADBLOCK_POS;
> + this->badblockpos = NAND_BBM_POS_ONENAND;
>
> /* Set erase shift */
> bbm->bbt_erase_shift = this->erase_shift;
> diff --git a/drivers/mtd/nand/raw/nand_amd.c b/drivers/mtd/nand/raw/nand_amd.c
> index 890c5b43e03c..6202cbf7ee8d 100644
> --- a/drivers/mtd/nand/raw/nand_amd.c
> +++ b/drivers/mtd/nand/raw/nand_amd.c
> @@ -40,7 +40,7 @@ static void amd_nand_decode_id(struct nand_chip *chip)
> static int amd_nand_init(struct nand_chip *chip)
> {
> if (nand_is_slc(chip))
> - chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
> + chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE;
>
> return 0;
> }
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index cca4b24d2ffa..9ef7b86cdc42 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -298,11 +298,12 @@ static int nand_block_bad(struct nand_chip *chip,
> loff_t ofs)
> int page, page_end, res;
> u8 bad;
>
> - if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
> + if (chip->options & NAND_BBM_LASTPAGE)
> ofs += mtd->erasesize - mtd->writesize;
>
> page = (int)(ofs >> chip->page_shift) & chip->pagemask;
> - page_end = page + (chip->bbt_options & NAND_BBT_SCAN2NDPAGE ? 2 : 1);
> + page_end = page + (((chip->options & NAND_BBM_FIRSTPAGE) &&
> + (chip->options & NAND_BBM_SECONDPAGE)) ? 2 : 1);
>
> for (; page < page_end; page++) {
> res = chip->ecc.read_oob(chip, page);
> @@ -541,7 +542,7 @@ static int nand_default_block_markbad(struct nand_chip
> *chip, loff_t ofs)
> ops.mode = MTD_OPS_PLACE_OOB;
>
> /* Write to first/last page(s) if necessary */
> - if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
> + if (chip->options & NAND_BBM_LASTPAGE)
> ofs += mtd->erasesize - mtd->writesize;
> do {
> res = nand_do_write_oob(chip, ofs, );
> @@ -550,7 +551,8 @@ static int nand_default_block_markbad(struct nand_chip
> *chip, loff_t ofs)
>
> i++;
> ofs += mtd->writesize;
>
Re: [PATCH net-next] net: dsa: mv88e6xxx: Add suspend/resume callbacks
> I am not sure to understand what is lost. On my setup ethtool shows > that everything is fine after resume but maybe I fall into a "default" > working case. Hi Miquèl Is the power removed from the switch? If so, you need to restore the full switch configuration. The current code might be sufficient for runtime suspend, where the switch is put into a low power mode, but it is kept powered. It is not sufficient for a full power cycle. > When I compare with the two drivers pointed out by Andrew: > * qca8k resume callback: > * enable ports, > * call dsa_switch_resume(). > * bcm_sf2 resume callback: > * call dsa_switch_resume(), > * reset the switch, > * refresh rules (Not applicable?), > * enable the PHYs, > * setup the ports, > * configure vlan (Not applicable?), > * mv88e6xxx resume callback: > * reset the switch, > * enable the PHYs, > * setup the ports, > * enable IRQs, > * call dsa_switch_resume(). Here are some commands to try before you suspend: ip link add name br0 type bridge ip link set br0 up ip link set lan1 up ip link set lan1 master br0 ip link set lan2 up ip link set lan2 master br0 At this point, you should be able to pass traffic between lan1 and lan2. bridge fdb add 00:42:42:42:42:42 lan1 bridge fdb add 00:24:24:24:24:24 lan2 That adds two static forwarding database entries. You can show these using bridge fdb show There are likely to be additional dynamic FDB entries. It is O.K. to loose the dynamic entries over a suspend/resume cycle, but the static ones must remain. > This looks pretty similar. Maybe the ports setup are set to default > values while I should save some parameters at suspend? I changed a > few parameters (like the MTU or the queue length) but they seem to be > correct across suspend cycles. MTU and queue length have nothing to do with the actual switch. Your tests need to actually program the hardware. Andrew
[PATCH 2/3] dmaengine: sprd: Add new DMA engine translation function
Add new DMA engine translation function to get the hardware slave id
of the corresponding DMA engine channel. Meanwhile we do not need
to set default slave id in sprd_dma_alloc_chan_resources(), remove it.
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c | 49
1 file changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index e2f0167..7d180bb 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -204,9 +204,9 @@ struct sprd_dma_dev {
struct sprd_dma_chn channels[0];
};
-static bool sprd_dma_filter_fn(struct dma_chan *chan, void *param);
-static struct of_dma_filter_info sprd_dma_info = {
- .filter_fn = sprd_dma_filter_fn,
+struct sprd_dma_filter_param {
+ u32 chn_id;
+ u32 slave_id;
};
static inline struct sprd_dma_chn *to_sprd_dma_chan(struct dma_chan *c)
@@ -580,15 +580,7 @@ static irqreturn_t dma_irq_handle(int irq, void *dev_id)
static int sprd_dma_alloc_chan_resources(struct dma_chan *chan)
{
- struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
- int ret;
-
- ret = pm_runtime_get_sync(chan->device->dev);
- if (ret < 0)
- return ret;
-
- schan->dev_id = SPRD_DMA_SOFTWARE_UID;
- return 0;
+ return pm_runtime_get_sync(chan->device->dev);
}
static void sprd_dma_free_chan_resources(struct dma_chan *chan)
@@ -1022,12 +1014,31 @@ static bool sprd_dma_filter_fn(struct dma_chan *chan,
void *param)
{
struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
struct sprd_dma_dev *sdev = to_sprd_dma_dev(>vc.chan);
- u32 req = *(u32 *)param;
+ struct sprd_dma_filter_param *sparam = param;
- if (req < sdev->total_chns)
- return req == schan->chn_num + 1;
- else
- return false;
+ if (sparam->chn_id < sdev->total_chns &&
+ sparam->chn_id == schan->chn_num + 1) {
+ schan->dev_id = sparam->slave_id;
+ return true;
+ }
+
+ return false;
+}
+
+static struct dma_chan *sprd_dma_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct sprd_dma_dev *sdev = ofdma->of_dma_data;
+ dma_cap_mask_t mask = sdev->dma_dev.cap_mask;
+ struct sprd_dma_filter_param param;
+
+ if (dma_spec->args_count != 2)
+ return NULL;
+
+ param.chn_id = dma_spec->args[0];
+ param.slave_id = dma_spec->args[1];
+
+ return dma_request_channel(mask, sprd_dma_filter_fn, );
}
static int sprd_dma_probe(struct platform_device *pdev)
@@ -1133,9 +1144,7 @@ static int sprd_dma_probe(struct platform_device *pdev)
goto err_register;
}
- sprd_dma_info.dma_cap = sdev->dma_dev.cap_mask;
- ret = of_dma_controller_register(np, of_dma_simple_xlate,
-_dma_info);
+ ret = of_dma_controller_register(np, sprd_dma_xlate, sdev);
if (ret)
goto err_of_register;
--
1.7.9.5
[PATCH 3/3] arm64: dts: sprd: Change 2 cells to provide DMA controller specific information
Change to use 2 cells to provide the channel id and slave id for client.
Signed-off-by: Baolin Wang
---
arch/arm64/boot/dts/sprd/whale2.dtsi |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/sprd/whale2.dtsi
b/arch/arm64/boot/dts/sprd/whale2.dtsi
index 34b6ca0..dbd61f8 100644
--- a/arch/arm64/boot/dts/sprd/whale2.dtsi
+++ b/arch/arm64/boot/dts/sprd/whale2.dtsi
@@ -117,7 +117,7 @@
compatible = "sprd,sc9860-dma";
reg = <0 0x2010 0 0x4000>;
interrupts = ;
- #dma-cells = <1>;
+ #dma-cells = <2>;
#dma-channels = <32>;
clock-names = "enable";
clocks = <_gate CLK_DMA_EB>;
@@ -273,7 +273,7 @@
agcp_dma: dma-controller@4158 {
compatible = "sprd,sc9860-dma";
reg = <0 0x4158 0 0x4000>;
- #dma-cells = <1>;
+ #dma-cells = <2>;
#dma-channels = <32>;
clock-names = "enable", "ashb_eb";
clocks = <_gate CLK_AGCP_DMAAP_EB>,
--
1.7.9.5
[PATCH 1/3] dt-bindings: dmaengine: Add one new cell to present hardware slave id
The DMA engine clients can trigger DMA engine automatically by setting
the corresponding hardware slave id for the DMA engine. Thus add one
cell to present the hardware slave id for DMA clients.
Signed-off-by: Baolin Wang
---
Documentation/devicetree/bindings/dma/sprd-dma.txt | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/sprd-dma.txt
b/Documentation/devicetree/bindings/dma/sprd-dma.txt
index 7a10fea..7812cf0 100644
--- a/Documentation/devicetree/bindings/dma/sprd-dma.txt
+++ b/Documentation/devicetree/bindings/dma/sprd-dma.txt
@@ -6,8 +6,8 @@ Required properties:
- compatible: Should be "sprd,sc9860-dma".
- reg: Should contain DMA registers location and length.
- interrupts: Should contain one interrupt shared by all channel.
-- #dma-cells: must be <1>. Used to represent the number of integer
- cells in the dmas property of client device.
+- #dma-cells: must be <2>. Used to represent the channel id and slave id
+ of integer cells in the dmas property of client device.
- #dma-channels : Number of DMA channels supported. Should be 32.
- clock-names: Should contain the clock of the DMA controller.
- clocks: Should contain a clock specifier for each entry in clock-names.
@@ -28,14 +28,16 @@ apdma: dma-controller@2010 {
Client:
DMA clients connected to the Spreadtrum DMA controller must use the format
-described in the dma.txt file, using a two-cell specifier for each channel.
-The two cells in order are:
+described in the dma.txt file, using a three-cell specifier for each channel.
+The three cells in order are:
1. A phandle pointing to the DMA controller.
2. The channel id.
+3. The hardware slave id which is used for clients to trigger DMA engine
+automatically.
spi0: spi@70a0{
...
dma-names = "rx_chn", "tx_chn";
- dmas = < 11>, < 12>;
+ dmas = < 11 11>, < 12 12>;
...
};
--
1.7.9.5
[PATCH] drm/sun4i: hdmi: Improve compatibility with hpd-less HDMI displays
From: Priit Laes
Even though HDMI connector features hotplug detect pin (HPD), there
are older devices which do not support it. For these devices fall
back to additional check on I2C bus to probe for EDID data.
One known example is HDMI/DVI display with following edid:
$ xxd -p display.edid
000005a1e0030100150f0103800f05780a0f6ea05748
9a2610474f20010101010101010101010101010101012a08804520e0
0b10200040009536001800fd0034441a2403000a202020202020
001000310a202020202020202020202000102a4030701300
782d111e006b
$ edid-decode display.edid
EDID version: 1.3
Manufacturer: AMA Model 3e0 Serial Number 1
Digital display
Maximum image size: 15 cm x 5 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
Red: 0.6250, 0.3398
Green: 0.2841, 0.6044
Blue: 0.1494, 0.0644
White: 0.2802, 0.3105
Established timings supported:
640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
Standard timings supported:
Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm
640 672 672 709 hborder 0
480 484 484 491 vborder 0
-hsync -vsync
VertFreq: 60 Hz, HorFreq: 29478 Hz
Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz
Dummy block
Dummy block
Checksum: 0x6b (valid)
Now, current implementation is still flawed, as HDMI uses the
HPD signal to indicate that the source should re-read the EDID
due to change in device capabilities. With current HPD polling
implementation we would most certainly miss those notifications
as one can try just swapping two HDMI monitors really fast.
Proper fix would be skipping the HPD pin detection and relying
on just EDID fetching and acting on its changes.
CC: Russell King
Signed-off-by: Priit Laes
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 25f4d676fd82..3b80380bc76e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -242,14 +242,18 @@ sun4i_hdmi_connector_detect(struct drm_connector
*connector, bool force)
struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
unsigned long reg;
- if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
- reg & SUN4I_HDMI_HPD_HIGH,
- 0, 50)) {
- cec_phys_addr_invalidate(hdmi->cec_adap);
- return connector_status_disconnected;
- }
-
- return connector_status_connected;
+ /* TODO: Drop HPD polling and instead keep track of EDID changes */
+ if (!readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
+ reg & SUN4I_HDMI_HPD_HIGH,
+ 0, 50))
+ return connector_status_connected;
+
+ /* Fall back to EDID in case display does not support HPD */
+ if (!IS_ERR(hdmi->i2c) && drm_probe_ddc(hdmi->i2c))
+ return connector_status_connected;
+
+ cec_phys_addr_invalidate(hdmi->cec_adap);
+ return connector_status_disconnected;
}
static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
--
2.11.0
[PATCH 2/2] ARM: dts: Add stmpe-adc DT node to Toradex T30 modules
From: Philippe Schenker
Add the stmpe-adc DT node as found on Toradex T30 modules
Signed-off-by: Philippe Schenker
---
arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi | 22 ++
arch/arm/boot/dts/tegra30-apalis.dtsi | 22 ++
arch/arm/boot/dts/tegra30-colibri.dtsi | 22 ++
3 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi
b/arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi
index 02f8126481a2..8b7a827d604d 100644
--- a/arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi
@@ -994,11 +994,17 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -1008,17 +1014,17 @@
* current limit value
*/
st,i-drive = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+ stmpe_adc {
+ compatible = "st,stmpe-adc";
+ /* forbid to use ADC channels 3-0 (touch) */
+ st,norequest-mask = <0x0F>;
+ };
};
/*
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 7f112f192fe9..c18f6f61d764 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -976,11 +976,17 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -990,17 +996,17 @@
* current limit value
*/
st,i-drive = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+ stmpe_adc {
+ compatible = "st,stmpe-adc";
+ /* forbid to use ADC channels 3-0 (touch) */
+ st,norequest-mask = <0x0F>;
+ };
};
/*
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi
b/arch/arm/boot/dts/tegra30-colibri.dtsi
index 35af03ca9e90..3c421a5cfbc2
[PATCH 1/2] ARM: dts: Add stmpe-adc DT node to Toradex iMX6 modules
From: Philippe Schenker
Add the stmpe-adc DT node as found on Toradex iMX6 modules
Signed-off-by: Philippe Schenker
---
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 22 ++
arch/arm/boot/dts/imx6qdl-colibri.dtsi | 22 ++
2 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 8380f1b26826..e8c7ef7e078a 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -332,11 +332,17 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -346,17 +352,17 @@
* current limit value
*/
st,i-drive = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+ stmpe_adc {
+ compatible = "st,stmpe-adc";
+ /* forbid to use ADC channels 3-0 (touch) */
+ st,norequest-mask = <0x0F>;
+ };
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
index 87e15e7cb32b..eb8603a2444e 100644
--- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
@@ -262,11 +262,17 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -276,17 +282,17 @@
* current limit value
*/
st,i-drive = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+ stmpe_adc {
+ compatible = "st,stmpe-adc";
+ /* forbid to use ADC channels 3-0 (touch) */
+ st,norequest-mask = <0x0F>;
+ };
};
};
--
2.20.1
[PATCH 0/2] Adding DTS to support STMPE811 ADC on Toradex Boards
From: Philippe Schenker Hello, Recently the STMPE811 driver got pulled by MFD (for 5.1). This patches I'm sending are now adding support for STMPE811 ADC in devicetree. These patches have been in the STMPE811 ADC driver patchset but were not pulled by Lee, as they had no reviews and I also corrected some minor comment errors. Philippe Schenker (2): ARM: dts: Add stmpe-adc DT node to Toradex iMX6 modules ARM: dts: Add stmpe-adc DT node to Toradex T30 modules arch/arm/boot/dts/imx6qdl-apalis.dtsi | 22 ++ arch/arm/boot/dts/imx6qdl-colibri.dtsi | 22 ++ arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi | 22 ++ arch/arm/boot/dts/tegra30-apalis.dtsi | 22 ++ arch/arm/boot/dts/tegra30-colibri.dtsi | 22 ++ 5 files changed, 70 insertions(+), 40 deletions(-) -- 2.20.1
