* Re: [PATCH v2 0/5] 0/6] arm64: meson-sm1: add support for DVFS
From: Kevin Hilman @ 2019-08-27 19:12 UTC (permalink / raw)
To: Jerome Brunet, Neil Armstrong
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <1jblwc6wjq.fsf@starbuckisacylon.baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> On Mon 26 Aug 2019 at 09:25, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
>> Following DVFS support for the Amlogic G12A and G12B SoCs, this serie
>> enables DVFS on the SM1 SoC for the SEI610 board.
>>
>> The SM1 Clock structure is slightly different because of the Cortex-A55
>> core used, having the capability for each core of a same cluster to run
>> at a different frequency thanks to the newly used DynamIQ Shared Unit.
>>
>> This is why SM1 has a CPU clock tree for each core and for DynamIQ Shared Unit,
>> with a bypass mux to use the CPU0 instead of the dedicated trees.
>>
>> The DSU uses a new GP1 PLL as default clock, thus GP1 is added as read-only.
>>
>> The SM1 OPPs has been taken from the Amlogic Vendor tree, and unlike
>> G12A only a single version of the SoC is available.
>>
>> Dependencies:
>> - patch 6 is based on the "arm64: meson: add support for SM1 Power Domains" serie,
>> but is not a strong dependency, it will work without
>>
>> Changes since v1:
>> - exposed GP1, DSU and CPU 1,2,3 clock in patch 1
>>
>> Neil Armstrong (5):
>> dt-bindings: clk: meson: add sm1 periph clock controller bindings
>> clk: meson: g12a: add support for SM1 GP1 PLL
>> clk: meson: g12a: add support for SM1 DynamIQ Shared Unit clock
>> clk: meson: g12a: add support for SM1 CPU 1, 2 & 3 clocks
>> arm64: dts: meson-sm1-sei610: enable DVFS
>>
>> .../bindings/clock/amlogic,gxbb-clkc.txt | 1 +
>> .../boot/dts/amlogic/meson-sm1-sei610.dts | 59 +-
>> arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 69 +++
>> drivers/clk/meson/g12a.c | 544 ++++++++++++++++++
>> drivers/clk/meson/g12a.h | 24 +-
>> include/dt-bindings/clock/g12a-clkc.h | 5 +
>> 6 files changed, 697 insertions(+), 5 deletions(-)
>
> Applied 1 to 4
Will there be a stable tag I can use for that so I can apply patch 5?
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] drm/meson: add resume/suspend hooks
From: Kevin Hilman @ 2019-08-27 19:17 UTC (permalink / raw)
To: Neil Armstrong, dri-devel
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190827095825.21015-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> This serie adds the resume/suspend hooks in the Amlogic Meson VPU main driver
> and the DW-HDMI Glue driver to correctly save state and disable HW before
> suspend, and succesfully re-init the HW to recover functionnal display
> after resume.
>
> This serie has been tested on Amlogic G12A based SEI510 board, using
> the newly accepted VRTC driver and the rtcwake utility.
Tested-by: Kevin Hilman <khilman@baylibre.com>
Tested on my G12A SEI510 board, and I verified that it fixes
suspend/resume issues previously seen.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/8] coresight: etm4x: Fixes for ETM v4.4 architecture updates.
From: Mathieu Poirier @ 2019-08-27 19:19 UTC (permalink / raw)
To: Mike Leach; +Cc: linux-arm-kernel, Suzuki K. Poulose
In-Reply-To: <CAJ9a7Vj90=m+m+NhBW7d=nYMH6SP47BpF968F9Q5z6g3WjrEvw@mail.gmail.com>
On Tue, 27 Aug 2019 at 04:13, Mike Leach <mike.leach@linaro.org> wrote:
>
> Hi Mathieu,
>
> On Mon, 26 Aug 2019 at 22:47, Mathieu Poirier
> <mathieu.poirier@linaro.org> wrote:
> >
> > Hi Mike,
> >
> >
> > On Mon, Aug 19, 2019 at 09:57:13PM +0100, Mike Leach wrote:
> > > ETMv4.4 adds in support for tracing secure EL2 (per arch 8.x updates).
> >
> > What is the name of the ETMv4.4 document? I can only find up to 4.2 on line.
> >
>
> Arm® Embedded Trace Macrocell
> Architecture Specification
> ETMv4.0 to ETMv4.4
>
> ARM IHI0064F
>
> Published 2018 - non-confidential.
>
> So should be available.
With the name above I quickly found the document on line:
https://static.docs.arm.com/ihi0064/f/etm_v4_4_architecture_specification_IHI0064F.pdf
On the flip side the inforcenter site still has the old 4.0 to 4.2 version.
>
> > > Patch accounts for this new capability.
> > >
> > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > ---
> > > .../hwtracing/coresight/coresight-etm4x-sysfs.c | 12 ++++++------
> > > drivers/hwtracing/coresight/coresight-etm4x.c | 5 ++++-
> > > drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++----
> > > 3 files changed, 21 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > > index 219c10eb752c..b6984be0c515 100644
> > > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > > @@ -738,7 +738,7 @@ static ssize_t s_exlevel_vinst_show(struct device *dev,
> > > struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > > struct etmv4_config *config = &drvdata->config;
> > >
> > > - val = BMVAL(config->vinst_ctrl, 16, 19);
> > > + val = (config->vinst_ctrl & ETM_EXLEVEL_S_VICTLR_MASK) >> 16;
> > > return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > > }
> > >
> > > @@ -754,8 +754,8 @@ static ssize_t s_exlevel_vinst_store(struct device *dev,
> > > return -EINVAL;
> > >
> > > spin_lock(&drvdata->spinlock);
> > > - /* clear all EXLEVEL_S bits (bit[18] is never implemented) */
> > > - config->vinst_ctrl &= ~(BIT(16) | BIT(17) | BIT(19));
> > > + /* clear all EXLEVEL_S bits */
> > > + config->vinst_ctrl &= ~(ETM_EXLEVEL_S_VICTLR_MASK);
> > > /* enable instruction tracing for corresponding exception level */
> > > val &= drvdata->s_ex_level;
> > > config->vinst_ctrl |= (val << 16);
> > > @@ -773,7 +773,7 @@ static ssize_t ns_exlevel_vinst_show(struct device *dev,
> > > struct etmv4_config *config = &drvdata->config;
> > >
> > > /* EXLEVEL_NS, bits[23:20] */
> > > - val = BMVAL(config->vinst_ctrl, 20, 23);
> > > + val = (config->vinst_ctrl & ETM_EXLEVEL_NS_VICTLR_MASK) >> 20;
> > > return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > > }
> > >
> > > @@ -789,8 +789,8 @@ static ssize_t ns_exlevel_vinst_store(struct device *dev,
> > > return -EINVAL;
> > >
> > > spin_lock(&drvdata->spinlock);
> > > - /* clear EXLEVEL_NS bits (bit[23] is never implemented */
> > > - config->vinst_ctrl &= ~(BIT(20) | BIT(21) | BIT(22));
> > > + /* clear EXLEVEL_NS bits */
> > > + config->vinst_ctrl &= ~(ETM_EXLEVEL_NS_VICTLR_MASK);
> > > /* enable instruction tracing for corresponding exception level */
> > > val &= drvdata->ns_ex_level;
> > > config->vinst_ctrl |= (val << 20);
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> > > index a128b5063f46..52b8876de157 100644
> > > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > > @@ -629,6 +629,7 @@ static void etm4_init_arch_data(void *info)
> > > * TRCARCHMAJ, bits[11:8] architecture major versin number
> > > */
> > > drvdata->arch = BMVAL(etmidr1, 4, 11);
> > > + drvdata->config.arch = drvdata->arch;
> > >
> > > /* maximum size of resources */
> > > etmidr2 = readl_relaxed(drvdata->base + TRCIDR2);
> > > @@ -780,6 +781,7 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
> > > static u64 etm4_get_access_type(struct etmv4_config *config)
> > > {
> > > u64 access_type = etm4_get_ns_access_type(config);
> > > + u64 s_hyp = (config->arch & 0x0f) >= 0x4 ? ETM_EXLEVEL_S_HYP : 0;
> > >
> > > /*
> > > * EXLEVEL_S, bits[11:8], don't trace anything happening
> > > @@ -787,7 +789,8 @@ static u64 etm4_get_access_type(struct etmv4_config *config)
> > > */
> > > access_type |= (ETM_EXLEVEL_S_APP |
> > > ETM_EXLEVEL_S_OS |
> > > - ETM_EXLEVEL_S_HYP);
> > > + s_hyp |
> > > + ETM_EXLEVEL_S_MON);
> > >
> > > return access_type;
> > > }
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> > > index 4523f10ddd0f..60bc2fb5159b 100644
> > > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > > @@ -180,17 +180,22 @@
> > > /* PowerDown Control Register bits */
> > > #define TRCPDCR_PU BIT(3)
> > >
> > > -/* secure state access levels */
> > > +/* secure state access levels - TRCACATRn */
> > > #define ETM_EXLEVEL_S_APP BIT(8)
> > > #define ETM_EXLEVEL_S_OS BIT(9)
> > > -#define ETM_EXLEVEL_S_NA BIT(10)
> > > -#define ETM_EXLEVEL_S_HYP BIT(11)
> > > -/* non-secure state access levels */
> > > +#define ETM_EXLEVEL_S_HYP BIT(10)
> > > +#define ETM_EXLEVEL_S_MON BIT(11)
> > > +/* non-secure state access levels - TRCACATRn */
> > > #define ETM_EXLEVEL_NS_APP BIT(12)
> > > #define ETM_EXLEVEL_NS_OS BIT(13)
> > > #define ETM_EXLEVEL_NS_HYP BIT(14)
> > > #define ETM_EXLEVEL_NS_NA BIT(15)
> > >
> > > +/* secure / non secure masks - TRCVICTLR, IDR3 */
> > > +#define ETM_EXLEVEL_S_VICTLR_MASK GENMASK(19, 16)
> > > +/* NS MON (EL3) mode never implemented */
> > > +#define ETM_EXLEVEL_NS_VICTLR_MASK GENMASK(22, 20)
> >
> > It is hard to say without documentation but shouldn't this be GENMASK(23, 20)?
> >
> Per the comment above, EL3_NS is prohibited so the mask refers to only
> the 3 allow bits (NS EL0 - EL2).
>
Yes, the 4.4 documentation makes it obvious.
> > > +
> > > /**
> > > * struct etmv4_config - configuration information related to an ETMv4
> > > * @mode: Controls various modes supported by this ETM.
> > > @@ -237,6 +242,7 @@
> > > * @vmid_mask0: VM ID comparator mask for comparator 0-3.
> > > * @vmid_mask1: VM ID comparator mask for comparator 4-7.
> > > * @ext_inp: External input selection.
> > > + * @arch: ETM architecture version (for arch dependent config).
> > > */
> > > struct etmv4_config {
> > > u32 mode;
> > > @@ -279,6 +285,7 @@ struct etmv4_config {
> > > u32 vmid_mask0;
> > > u32 vmid_mask1;
> > > u32 ext_inp;
> > > + u8 arch;
> > > };
> > >
> > > /**
> > > --
> > > 2.17.1
> > >
>
>
>
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv5] drivers/amba: add reset control to amba bus probe
From: Valdis Klētnieks @ 2019-08-27 19:25 UTC (permalink / raw)
To: Dinh Nguyen
Cc: devicetree, daniel.thompson, tony.luck, manivannan.sadhasivam,
keescook, robh, linus.walleij, anton, linux, linux-kernel,
p.zabel, ccross, frowand.list, linux-arm-kernel
In-Reply-To: <20190826154252.22952-1-dinguyen@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 803 bytes --]
On Mon, 26 Aug 2019 10:42:52 -0500, Dinh Nguyen said:
> The primecell controller on some SoCs, i.e. SoCFPGA, is held in reset by
> default. Until recently, the DMA controller was brought out of reset by the
> bootloader(i.e. U-Boot). But a recent change in U-Boot, the peripherals
> that are not used are held in reset and are left to Linux to bring them
> out of reset.
>
> Add a mechanism for getting the reset property and de-assert the primecell
> module from reset if found. This is a not a hard fail if the reset properti
> is not present in the device tree node, so the driver will continue to
> probe.
Does this DTRT for both old and new U-Boots? My naive reading of this patch
says on an old U-Boot, we end up attempting to bring it out of reset even though
they had already been brought out.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Applied "ASoC: sun4i: Revert A83t description" to the asoc tree
From: Mark Brown @ 2019-08-27 19:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: alsa-devel, lgirdwood, Maxime Ripard, linux-kernel, codekipper,
Chen-Yu Tsai, Mark Brown, linux-arm-kernel
In-Reply-To: <20190827123131.29129-2-mripard@kernel.org>
The patch
ASoC: sun4i: Revert A83t description
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 9ec05d4723bf83dd272cef5ccf508e5fe4d30fa3 Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Tue, 27 Aug 2019 14:31:31 +0200
Subject: [PATCH] ASoC: sun4i: Revert A83t description
The last set of reworks included some fixes to change the A83t behaviour
and "fix" it.
It turns out that the controller described in the datasheet and the one
supported here are not the same, yet the A83t has the two of them, and the
one supported in the driver wasn't the one described in the datasheet.
Fix this by reintroducing the proper quirks.
Fixes: 69e450e50ca6 ("ASoC: sun4i-i2s: Fix the LRCK period on A83t")
Fixes: bf943d527987 ("ASoC: sun4i-i2s: Fix MCLK Enable bit offset on A83t")
Fixes: 2e04fc4dbf50 ("ASoC: sun4i-i2s: Fix WSS and SR fields for the A83t")
Fixes: 515fcfbc7736 ("ASoC: sun4i-i2s: Fix LRCK and BCLK polarity offsets on newer SoCs")
Fixes: c1d3a921d72b ("ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs")
Fixes: fb19739d7f68 ("ASoC: sun4i-i2s: Use module clock as BCLK parent on newer SoCs")
Fixes: 71137bcd0a9a ("ASoC: sun4i-i2s: Move the format configuration to a callback")
Fixes: d70be625f25a ("ASoC: sun4i-i2s: Move the channel configuration to a callback")
Reported-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/20190827123131.29129-2-mripard@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index a6a3f772fdf0..d0a8d5810c0a 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1106,18 +1106,18 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
- .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
- .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
- .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
- .bclk_dividers = sun8i_i2s_clk_div,
- .num_bclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
- .mclk_dividers = sun8i_i2s_clk_div,
- .num_mclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
- .get_bclk_parent_rate = sun8i_i2s_get_bclk_parent_rate,
- .get_sr = sun8i_i2s_get_sr_wss,
- .get_wss = sun8i_i2s_get_sr_wss,
- .set_chan_cfg = sun8i_i2s_set_chan_cfg,
- .set_fmt = sun8i_i2s_set_soc_fmt,
+ .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
+ .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 2, 3),
+ .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 5),
+ .bclk_dividers = sun4i_i2s_bclk_div,
+ .num_bclk_dividers = ARRAY_SIZE(sun4i_i2s_bclk_div),
+ .mclk_dividers = sun4i_i2s_mclk_div,
+ .num_mclk_dividers = ARRAY_SIZE(sun4i_i2s_mclk_div),
+ .get_bclk_parent_rate = sun4i_i2s_get_bclk_parent_rate,
+ .get_sr = sun4i_i2s_get_sr,
+ .get_wss = sun4i_i2s_get_wss,
+ .set_chan_cfg = sun4i_i2s_set_chan_cfg,
+ .set_fmt = sun4i_i2s_set_soc_fmt,
};
static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Applied "ASoC: SOF: imx8: Fix return value check in imx8_probe()" to the asoc tree
From: Mark Brown @ 2019-08-27 19:58 UTC (permalink / raw)
To: Wei Yongjun
Cc: alsa-devel, Pengutronix, linux-kernel, Sascha Hauer, Takashi Iwai,
kernel-janitors, Liam Girdwood, Jaroslav Kysela, Mark Brown,
Shawn Guo, Daniel Baluta, linux-arm-kernel
In-Reply-To: <20190826120003.183279-1-weiyongjun1@huawei.com>
The patch
ASoC: SOF: imx8: Fix return value check in imx8_probe()
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 393151c211006cc5ac6af26ecd9982dd916a8104 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 26 Aug 2019 12:00:03 +0000
Subject: [PATCH] ASoC: SOF: imx8: Fix return value check in imx8_probe()
In case of error, the function devm_ioremap_wc() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: 202acc565a1f ("ASoC: SOF: imx: Add i.MX8 HW support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20190826120003.183279-1-weiyongjun1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sof/imx/imx8.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sof/imx/imx8.c b/sound/soc/sof/imx/imx8.c
index 640472491037..c9d849ced54a 100644
--- a/sound/soc/sof/imx/imx8.c
+++ b/sound/soc/sof/imx/imx8.c
@@ -296,10 +296,10 @@ static int imx8_probe(struct snd_sof_dev *sdev)
sdev->bar[SOF_FW_BLK_TYPE_SRAM] = devm_ioremap_wc(sdev->dev, res.start,
res.end - res.start +
1);
- if (IS_ERR(sdev->bar[SOF_FW_BLK_TYPE_SRAM])) {
+ if (!sdev->bar[SOF_FW_BLK_TYPE_SRAM]) {
dev_err(sdev->dev, "failed to ioremap mem 0x%x size 0x%x\n",
base, size);
- ret = PTR_ERR(sdev->bar[SOF_FW_BLK_TYPE_SRAM]);
+ ret = -ENOMEM;
goto exit_pdev_unregister;
}
sdev->mailbox_bar = SOF_FW_BLK_TYPE_SRAM;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Applied "ASoC: imx-audmix: register the card on a proper dev" to the asoc tree
From: Mark Brown @ 2019-08-27 19:58 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, Viorel Suman, timur, Xiubo.Lee, linuxppc-dev, s.hauer,
tiwai, lgirdwood, linux-kernel, nicoleotsuka, Mark Brown,
linux-imx, kernel, shawnguo, perex, festevam, linux-arm-kernel
In-Reply-To: <1566921315-23402-1-git-send-email-shengjiu.wang@nxp.com>
The patch
ASoC: imx-audmix: register the card on a proper dev
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 9573820eb1951e0cb0f329886abcb4153f2ea798 Mon Sep 17 00:00:00 2001
From: Shengjiu Wang <shengjiu.wang@nxp.com>
Date: Tue, 27 Aug 2019 11:55:15 -0400
Subject: [PATCH] ASoC: imx-audmix: register the card on a proper dev
This platform device is registered from "fsl_audmix", which is
its parent device. If use pdev->dev.parent for the priv->card.dev,
the value set by dev_set_drvdata in parent device will be covered
by the value in child device.
Fixes: b86ef5367761 ("ASoC: fsl: Add Audio Mixer machine driver")
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/1566921315-23402-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/fsl/imx-audmix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index 9e1cb18859ce..71590ca6394b 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -325,14 +325,14 @@ static int imx_audmix_probe(struct platform_device *pdev)
priv->card.num_configs = priv->num_dai_conf;
priv->card.dapm_routes = priv->dapm_routes;
priv->card.num_dapm_routes = priv->num_dapm_routes;
- priv->card.dev = pdev->dev.parent;
+ priv->card.dev = &pdev->dev;
priv->card.owner = THIS_MODULE;
priv->card.name = "imx-audmix";
platform_set_drvdata(pdev, &priv->card);
snd_soc_card_set_drvdata(&priv->card, priv);
- ret = devm_snd_soc_register_card(pdev->dev.parent, &priv->card);
+ ret = devm_snd_soc_register_card(&pdev->dev, &priv->card);
if (ret) {
dev_err(&pdev->dev, "snd_soc_register_card failed\n");
return ret;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Applied "ASoC: SOF: imx8: Make some functions static" to the asoc tree
From: Mark Brown @ 2019-08-27 19:58 UTC (permalink / raw)
To: YueHaibing
Cc: pierre-louis.bossart, alsa-devel, daniel.baluta, s.hauer, tiwai,
yuehaibing, lgirdwood, linux-kernel, Hulk Robot, Mark Brown,
linux-imx, kernel, shawnguo, perex, festevam, linux-arm-kernel
In-Reply-To: <20190823125939.30012-1-yuehaibing@huawei.com>
The patch
ASoC: SOF: imx8: Make some functions static
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From b9a4805a4ac1200326ee0c78df0ae3faceabad49 Mon Sep 17 00:00:00 2001
From: YueHaibing <yuehaibing@huawei.com>
Date: Fri, 23 Aug 2019 20:59:39 +0800
Subject: [PATCH] ASoC: SOF: imx8: Make some functions static
Fix sparse warnings:
sound/soc/sof/imx/imx8.c:104:6: warning: symbol 'imx8_dsp_handle_reply' was not declared. Should it be static?
sound/soc/sof/imx/imx8.c:115:6: warning: symbol 'imx8_dsp_handle_request' was not declared. Should it be static?
sound/soc/sof/imx/imx8.c:336:5: warning: symbol 'imx8_get_bar_index' was not declared. Should it be static?
sound/soc/sof/imx/imx8.c:341:6: warning: symbol 'imx8_ipc_msg_data' was not declared. Should it be static?
sound/soc/sof/imx/imx8.c:348:5: warning: symbol 'imx8_ipc_pcm_params' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20190823125939.30012-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sof/imx/imx8.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/sof/imx/imx8.c b/sound/soc/sof/imx/imx8.c
index e502f584207f..640472491037 100644
--- a/sound/soc/sof/imx/imx8.c
+++ b/sound/soc/sof/imx/imx8.c
@@ -101,7 +101,7 @@ static int imx8_get_window_offset(struct snd_sof_dev *sdev, u32 id)
return MBOX_OFFSET;
}
-void imx8_dsp_handle_reply(struct imx_dsp_ipc *ipc)
+static void imx8_dsp_handle_reply(struct imx_dsp_ipc *ipc)
{
struct imx8_priv *priv = imx_dsp_get_data(ipc);
unsigned long flags;
@@ -112,7 +112,7 @@ void imx8_dsp_handle_reply(struct imx_dsp_ipc *ipc)
spin_unlock_irqrestore(&priv->sdev->ipc_lock, flags);
}
-void imx8_dsp_handle_request(struct imx_dsp_ipc *ipc)
+static void imx8_dsp_handle_request(struct imx_dsp_ipc *ipc)
{
struct imx8_priv *priv = imx_dsp_get_data(ipc);
@@ -333,21 +333,21 @@ static int imx8_remove(struct snd_sof_dev *sdev)
}
/* on i.MX8 there is 1 to 1 match between type and BAR idx */
-int imx8_get_bar_index(struct snd_sof_dev *sdev, u32 type)
+static int imx8_get_bar_index(struct snd_sof_dev *sdev, u32 type)
{
return type;
}
-void imx8_ipc_msg_data(struct snd_sof_dev *sdev,
- struct snd_pcm_substream *substream,
- void *p, size_t sz)
+static void imx8_ipc_msg_data(struct snd_sof_dev *sdev,
+ struct snd_pcm_substream *substream,
+ void *p, size_t sz)
{
sof_mailbox_read(sdev, sdev->dsp_box.offset, p, sz);
}
-int imx8_ipc_pcm_params(struct snd_sof_dev *sdev,
- struct snd_pcm_substream *substream,
- const struct sof_ipc_pcm_params_reply *reply)
+static int imx8_ipc_pcm_params(struct snd_sof_dev *sdev,
+ struct snd_pcm_substream *substream,
+ const struct sof_ipc_pcm_params_reply *reply)
{
return 0;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V4 1/4] dt-bindings: watchdog: Add i.MX7ULP bindings
From: Rob Herring @ 2019-08-27 20:08 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, leonard.crestez, schnitzeltony,
linux-watchdog, otavio, festevam, s.hauer, jan.tuerk, linux,
linux-kernel, linux-arm-kernel, kernel, u.kleine-koenig, wim,
shawnguo, linux, Linux-imx
In-Reply-To: <1566441463-11911-1-git-send-email-Anson.Huang@nxp.com>
On Wed, Aug 21, 2019 at 10:37:40PM -0400, Anson Huang wrote:
> Add the watchdog bindings for Freescale i.MX7ULP.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> No changes.
> ---
> .../bindings/watchdog/fsl-imx7ulp-wdt.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
> new file mode 100644
> index 0000000..d83fc5c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
> @@ -0,0 +1,22 @@
> +* Freescale i.MX7ULP Watchdog Timer (WDT) Controller
> +
> +Required properties:
> +- compatible : Should be "fsl,imx7ulp-wdt"
> +- reg : Should contain WDT registers location and length
> +- interrupts : Should contain WDT interrupt
> +- clocks: Should contain a phandle pointing to the gated peripheral clock.
> +
> +Optional properties:
> +- timeout-sec : Contains the watchdog timeout in seconds
> +
> +Examples:
> +
> +wdog1: wdog@403d0000 {
watchdog@...
With that,
Reviewed-by: Rob Herring <rohb@kernel.org>
> + compatible = "fsl,imx7ulp-wdt";
> + reg = <0x403d0000 0x10000>;
> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
> + assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
> + assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
> + timeout-sec = <40>;
> +};
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/7] ARM: configs: aspeed_g5: Enable AST2600
From: Arnd Bergmann @ 2019-08-27 20:12 UTC (permalink / raw)
To: Joel Stanley
Cc: Mark Rutland, devicetree, Ryan Chen, linux-aspeed, Andrew Jeffery,
Rob Herring, Cédric Le Goater, Olof Johansson, Linux ARM
In-Reply-To: <CACPK8Xe=mq_Zuw6vsFtb=42ZodbHcizX9QwUoRzY0cDdoWr-Fw@mail.gmail.com>
On Thu, Aug 22, 2019 at 6:43 AM Joel Stanley <joel@jms.id.au> wrote:
>
> On Thu, 22 Aug 2019 at 02:07, Andrew Jeffery <andrew@aj.id.au> wrote:
> > > +CONFIG_MMC=y
> > > +CONFIG_MMC_SDHCI=y
> > > +CONFIG_MMC_SDHCI_PLTFM=y
> > > +CONFIG_MMC_SDHCI_OF_ASPEED=y
> >
> > The patches haven't yet been applied to the MMC tree, maybe we should
> > add this later?
>
> When enabling drivers in the same merge window as they go into the
> tree we will always be in this situation.
>
> If the driver doesn't make it in this merge window, or first has has
> changes, the worst that will happen is the kconfig name changes and I
> need to update it later. I think we're safe to include it as-is.
Yes, that's fine.
Please also enable all the drivers you need in multi_v7_defconfig
now, preferably as loadable modules.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Suman Anna @ 2019-08-27 20:25 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <20190827051007.GK1263@builder>
Hi Bjorn,
On 8/27/19 12:10 AM, Bjorn Andersson wrote:
> On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
>
>> Hi Bjorn,
>>
>
> Hi Suman
>
>> On 10/23/18 8:19 PM, Suman Anna wrote:
>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>>> printing the vring buffer address. This prints only a hashed
>>> pointer even for previliged users. Use "%pK" instead so that
>>> the address can be printed during debug using kptr_restrict
>>> sysctl.
>>
>> Seems to have been lost among the patches, can you pick up this trivial
>> patch for 5.4? Should apply cleanly on the latest HEAD as well.
>>
>
> I share Andrew's question regarding what benefit you have from knowing
> this value. Should we not just remove the va from the print? Or do you
> actually have a use case for it?.
I mainly use it during debug when comparing against kernel_page_tables
and vmallocinfo. The pools that we use are not always guaranteed to be
from linear memory, and behavior changes when using with CMA or DMA pools.
Note that usage of %pK does not leak the addresses automatically, but
atleast enables me to get the values when needed. The changes also bring
the usage in rpmsg core in sync with the remoteproc core.
regards
Suman
>
> Regards,
> Bjorn
>
>> regards
>> Suman
>>
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>>> index f29dee731026..1345f373a1a0 100644
>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>> goto vqs_del;
>>> }
>>>
>>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
>>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
>>> bufs_va, &vrp->bufs_dma);
>>>
>>> /* half of the buffers is dedicated for RX */
>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 6/7] dt-bindings: serial: Document Freescale LINFlexD UART
From: Rob Herring @ 2019-08-27 20:26 UTC (permalink / raw)
To: Stefan-gabriel Mirea
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, corbet@lwn.net,
gregkh@linuxfoundation.org, jslaby@suse.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
Cosmin Stefan Stoica, robh+dt@kernel.org,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
shawnguo@kernel.org, will@kernel.org,
linux-arm-kernel@lists.infradead.org, Larisa Ileana Grigore
In-Reply-To: <20190823191115.18490-7-stefan-gabriel.mirea@nxp.com>
On Fri, 23 Aug 2019 19:11:40 +0000, Stefan-gabriel Mirea wrote:
> From: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
>
> Add documentation for the serial communication interface module (LINFlexD),
> found in two instances on S32V234.
>
> Signed-off-by: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
> Signed-off-by: Larisa Grigore <Larisa.Grigore@nxp.com>
> Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
> ---
> .../bindings/serial/fsl,s32-linflexuart.txt | 22 +++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next] phy: mdio-bcm-iproc: use devm_platform_ioremap_resource() to simplify code
From: Ray Jui @ 2019-08-27 20:40 UTC (permalink / raw)
To: YueHaibing, andrew, f.fainelli, hkallweit1, davem, rjui, sbranden
Cc: netdev, bcm-kernel-feedback-list, linux-kernel, linux-arm-kernel
In-Reply-To: <20190827134616.11396-1-yuehaibing@huawei.com>
On 2019-08-27 6:46 a.m., YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/phy/mdio-bcm-iproc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/phy/mdio-bcm-iproc.c b/drivers/net/phy/mdio-bcm-iproc.c
> index 7d0f388..7e9975d 100644
> --- a/drivers/net/phy/mdio-bcm-iproc.c
> +++ b/drivers/net/phy/mdio-bcm-iproc.c
> @@ -123,15 +123,13 @@ static int iproc_mdio_probe(struct platform_device *pdev)
> {
> struct iproc_mdio_priv *priv;
> struct mii_bus *bus;
> - struct resource *res;
> int rc;
>
> priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->base = devm_ioremap_resource(&pdev->dev, res);
> + priv->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(priv->base)) {
> dev_err(&pdev->dev, "failed to ioremap register\n");
> return PTR_ERR(priv->base);
>
Looks good to me. Thanks.
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: l2c: move cache-aurora-l2.h to asm/hardware
From: Chris Packham @ 2019-08-27 20:49 UTC (permalink / raw)
To: patches, linux, mark.rutland, jlu, gregory.clement, bp
Cc: Chris Packham, linux-kernel, linux-arm-kernel, linux-edac
From: Jan Luebbe <jlu@pengutronix.de>
This include file will be used by the AURORA EDAC code.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
KernelVersion: 5.3rc
Hi Russell,
This is the missing first patch for the Armada EDAC series
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8885/1
arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h | 0
arch/arm/mm/cache-l2x0.c | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h (100%)
diff --git a/arch/arm/mm/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
similarity index 100%
rename from arch/arm/mm/cache-aurora-l2.h
rename to arch/arm/include/asm/hardware/cache-aurora-l2.h
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5b251c8ecd45..428d08718107 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -18,8 +18,8 @@
#include <asm/cp15.h>
#include <asm/cputype.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/hardware/cache-aurora-l2.h>
#include "cache-tauros3.h"
-#include "cache-aurora-l2.h"
struct l2c_init_data {
const char *type;
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Chris Packham @ 2019-08-27 20:56 UTC (permalink / raw)
To: linux@armlinux.org.uk
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jlu@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, james.morse@arm.com, patches@armlinux.org.uk,
gregory.clement@free-electrons.com, bp@alien8.de,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-edac@vger.kernel.org
In-Reply-To: <20190827091336.GI13294@shell.armlinux.org.uk>
On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
wrote:
> On Mon, Aug 26, 2019 at 12:46:44AM +0000, Chris Packham wrote:
> > Hi Russell,
> >
> > On Fri, 2019-08-23 at 11:50 +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux
> > > admin wrote:
> > > > I can't apply this series - this file does not exist in my tree,
> > > > and
> > > > from what git tells me, it never has existed. Maybe it's in
> > > > someone
> > > > elses tree?
> > >
> > > I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
> > > which is where it has been since it was originally submitted in 2012.
> >
> > Sorry there is a missing patch that moves it next to the
> > hardware/cache-*.h. I can send the missing patch or I can re-send the
> > whole series. If I do send the whole series do you want me to rebase it
> > against a particular tag/tree?
>
> Just send the single patch to the patch tracker - having it against
> 5.3-rc is fine (I don't think anything has changed for a long time
> with that file.)
Done
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
I'm still not entirely sure what to put for the KernelVersion tag. In
hindsight think I misinterpreted your comment above and set it to 5.3rc
(where you meant a series based on 5.3-rcX should apply cleanly). It
probably should have been next or master because it's way past the
merge window for 5.3.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-27 21:07 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jlu@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, james.morse@arm.com, patches@armlinux.org.uk,
gregory.clement@free-electrons.com, bp@alien8.de,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-edac@vger.kernel.org
In-Reply-To: <b1e2e5b325b3c4453e2ed63c17e1e11d6b24f099.camel@alliedtelesis.co.nz>
On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> wrote:
> > Just send the single patch to the patch tracker - having it against
> > 5.3-rc is fine (I don't think anything has changed for a long time
> > with that file.)
>
> Done
> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
>
> I'm still not entirely sure what to put for the KernelVersion tag. In
> hindsight think I misinterpreted your comment above and set it to 5.3rc
> (where you meant a series based on 5.3-rcX should apply cleanly). It
> probably should have been next or master because it's way past the
> merge window for 5.3.
Think about it as "which kernel version was _this_ patch generated
against" - it's a guide for me to know which kernel version it
should be applied to. The nearest Linus release (rc or final) is
generally sufficient.
If it doesn't apply to my current base, then I might check out that
version, apply it there, and then merge it in, resolving any
conflicts during the merge.
It started off with a different purpose: when we had the older
development system, such as the 2.x series kernels, we would have
even x being the current stable kernels, and concurrently we'd
also have x+1 as the development series. When someone sent me a
patch back then, it was important to know which kernel series it
was meant for.
I decided not to get rid of it because it provides useful
information when patches don't apply, and gives more options
than me just discarding the patch with a comment saying it
doesn't apply.
--
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] i2c: bcm2835: Add full name of devicetree node to adapter name
From: Scott Branden @ 2019-08-27 21:10 UTC (permalink / raw)
To: Stefan Wahren, Wolfram Sang, Eric Anholt, Florian Fainelli,
Ray Jui, Scott Branden
Cc: linux-i2c, linux-arm-kernel
In-Reply-To: <1566925456-5928-4-git-send-email-wahrenst@gmx.net>
On 2019-08-27 10:04 a.m., Stefan Wahren wrote:
> Inspired by Lori Hikichi's patch for iproc, this adds the full name of
> the devicetree node to the adapter name. With the introduction of
> BCM2711 it's very difficult to distinguish between the multiple instances.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Acked-by: Scott Branden <scott.branden@broadcom.com>
> =2D--
> drivers/i2c/busses/i2c-bcm2835.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm=
> 2835.c
> index ab5502f..e01b2b5 100644
> =2D-- a/drivers/i2c/busses/i2c-bcm2835.c
> +++ b/drivers/i2c/busses/i2c-bcm2835.c
> @@ -472,7 +472,8 @@ static int bcm2835_i2c_probe(struct platform_device *p=
> dev)
> i2c_set_adapdata(adap, i2c_dev);
> adap->owner =3D THIS_MODULE;
> adap->class =3D I2C_CLASS_DEPRECATED;
> - strlcpy(adap->name, "bcm2835 I2C adapter", sizeof(adap->name));
> + snprintf(adap->name, sizeof(adap->name), "bcm2835 (%s)",
> + of_node_full_name(pdev->dev.of_node));
> adap->algo =3D &bcm2835_i2c_algo;
> adap->dev.parent =3D &pdev->dev;
> adap->dev.of_node =3D pdev->dev.of_node;
> =2D-
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Chris Packham @ 2019-08-27 21:13 UTC (permalink / raw)
To: linux@armlinux.org.uk
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jlu@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, james.morse@arm.com, patches@armlinux.org.uk,
gregory.clement@free-electrons.com, bp@alien8.de,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-edac@vger.kernel.org
In-Reply-To: <20190827210713.GO13294@shell.armlinux.org.uk>
On Tue, 2019-08-27 at 22:07 +0100, Russell King - ARM Linux admin
wrote:
> On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> > On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> > wrote:
> > > Just send the single patch to the patch tracker - having it against
> > > 5.3-rc is fine (I don't think anything has changed for a long time
> > > with that file.)
> >
> > Done
> > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
> >
> > I'm still not entirely sure what to put for the KernelVersion tag. In
> > hindsight think I misinterpreted your comment above and set it to 5.3rc
> > (where you meant a series based on 5.3-rcX should apply cleanly). It
> > probably should have been next or master because it's way past the
> > merge window for 5.3.
>
> Think about it as "which kernel version was _this_ patch generated
> against" - it's a guide for me to know which kernel version it
> should be applied to. The nearest Linus release (rc or final) is
> generally sufficient.
>
> If it doesn't apply to my current base, then I might check out that
> version, apply it there, and then merge it in, resolving any
> conflicts during the merge.
>
> It started off with a different purpose: when we had the older
> development system, such as the 2.x series kernels, we would have
> even x being the current stable kernels, and concurrently we'd
> also have x+1 as the development series. When someone sent me a
> patch back then, it was important to know which kernel series it
> was meant for.
>
> I decided not to get rid of it because it provides useful
> information when patches don't apply, and gives more options
> than me just discarding the patch with a comment saying it
> doesn't apply.
>
Thanks for the info. So 5.3-rc is not as wrong as I thought it was.
One could even summarize the above as.
git format-patch --add-header \
"KernelVersion: $(git describe --abbrev=0 HEAD)"
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-27 21:15 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jlu@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, james.morse@arm.com, patches@armlinux.org.uk,
gregory.clement@free-electrons.com, bp@alien8.de,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-edac@vger.kernel.org
In-Reply-To: <0e9c7c7cb17b6fdea8d49b06925badb0b3d2ff8b.camel@alliedtelesis.co.nz>
On Tue, Aug 27, 2019 at 09:13:11PM +0000, Chris Packham wrote:
> On Tue, 2019-08-27 at 22:07 +0100, Russell King - ARM Linux admin
> wrote:
> > On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> > > On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> > > wrote:
> > > > Just send the single patch to the patch tracker - having it against
> > > > 5.3-rc is fine (I don't think anything has changed for a long time
> > > > with that file.)
> > >
> > > Done
> > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
> > >
> > > I'm still not entirely sure what to put for the KernelVersion tag. In
> > > hindsight think I misinterpreted your comment above and set it to 5.3rc
> > > (where you meant a series based on 5.3-rcX should apply cleanly). It
> > > probably should have been next or master because it's way past the
> > > merge window for 5.3.
> >
> > Think about it as "which kernel version was _this_ patch generated
> > against" - it's a guide for me to know which kernel version it
> > should be applied to. The nearest Linus release (rc or final) is
> > generally sufficient.
> >
> > If it doesn't apply to my current base, then I might check out that
> > version, apply it there, and then merge it in, resolving any
> > conflicts during the merge.
> >
> > It started off with a different purpose: when we had the older
> > development system, such as the 2.x series kernels, we would have
> > even x being the current stable kernels, and concurrently we'd
> > also have x+1 as the development series. When someone sent me a
> > patch back then, it was important to know which kernel series it
> > was meant for.
> >
> > I decided not to get rid of it because it provides useful
> > information when patches don't apply, and gives more options
> > than me just discarding the patch with a comment saying it
> > doesn't apply.
> >
>
> Thanks for the info. So 5.3-rc is not as wrong as I thought it was.
>
> One could even summarize the above as.
>
> git format-patch --add-header \
> "KernelVersion: $(git describe --abbrev=0 HEAD)"
Yep, I should probably update the patch system help with that, and
actually strip out everything about the old diff and patch way of
working.
--
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] amlogic: arm: add Amlogic SM1 based Khadas VIM3 variant bindings
From: Martin Blumenstingl @ 2019-08-27 21:18 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman, linux-amlogic, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <c853d934-113c-2305-f229-1e2c7138fc3f@baylibre.com>
On Mon, Aug 26, 2019 at 9:42 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
[...]
> >> diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
> >> index b48ea1e4913a..2751dd778ce0 100644
> >> --- a/Documentation/devicetree/bindings/arm/amlogic.yaml
> >> +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
> >> @@ -150,9 +150,10 @@ properties:
> >> - const: amlogic,s922x
> >> - const: amlogic,g12b
> >>
> >> - - description: Boards with the Amlogic Meson SM1 S905X3 SoC
> >> + - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
> >> items:
> >> - enum:
> >> - seirobotics,sei610
> >> + - khadas,vim3
>
> Khadas asked me to rename the board to "vim3l", which is the commercial name,
> should I only change the DT name or also the compatible "khadas,vim3l" ?
I vote for being consistent:
- rename the .dts to vim3l
- and change the compatible string
> >> - const: amlogic,sm1
> > on the GXL we differentiate between S905X and S905D
> > do we need to differentiate S905X3 from S905D3 (for example)?
>
> From a pure SoC die perspective they are the same, exactly like
> the S905X and S905D, only the package changes.
> So only the board DT will determine which eth PHY is used,
> if a DSI panel is connected, a demodulator is connected.. even
> if the underlying package is S905Y3 without any of these pins
> available.
OK, I see - fine for me then
GXL's S905W and/or S805X are the "special cases" then which (AFAIK)
use a different (smaller) package (so it made sense to differentiate
all GXL SoCs)
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv4 0/3] Odroid c2 usb fixs
From: Martin Blumenstingl @ 2019-08-27 21:19 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, Neil Armstrong, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CANAwSgTsua_x6fi7NzC2XjcV19OJcN3NhOT_niKXN4RR4X+qVQ@mail.gmail.com>
On Mon, Aug 26, 2019 at 6:38 AM Anand Moon <linux.amoon@gmail.com> wrote:
>
> Hi Martin,
>
> On Sun, 25 Aug 2019 at 02:48, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
> >
> > Hi Anand,
> >
> > thank you for the patches
> >
> > On Sat, Aug 24, 2019 at 8:49 PM Anand Moon <linux.amoon@gmail.com> wrote:
> > [...]
> > > Anand Moon (3):
> > > arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input
> > > arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus
> > > arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power
> > > failed warning
> > this whole series is:
> > Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> Thanks, I have some more patch in line for this board.
great, any improvement counts (especially since most boards are
derived from Amlogic reference designs, so it's likely that more than
just the Odroid-C2 will benefit from your patches) :)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] coresight: etm4x: Improve usability of sysfs API.
From: Mathieu Poirier @ 2019-08-27 21:35 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20190819205720.24457-6-mike.leach@linaro.org>
On Mon, Aug 19, 2019 at 09:57:17PM +0100, Mike Leach wrote:
> Some changes to make the sysfs programming more intuitive.
>
> 1) Setting include / exclude on a range had to be done by setting
> the bit in 'mode' before setting the range. However, setting this
> bit also had the effect of altering the current range as well.
>
> Changed to only set include / exclude setting of a range at the point of
> setting that range. Either use a 3rd input parameter as the include exclude
> value, or if not present use the current value of 'mode'. Do not change
> current range when 'mode' changes.
>
> 2) Context ID and VM ID masks required 2 value inputs, even when the
> second value is ignored as insufficient CID / VMID comparators are
> implemented.
> Permit a single value to be used if that is sufficient to cover all
> implemented comparators.
Please split in two patches. With that:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 24 +++++++++++++------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index 3bcc260c9e55..baac5b48b7ac 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -297,8 +297,6 @@ static ssize_t mode_store(struct device *dev,
>
> spin_lock(&drvdata->spinlock);
> config->mode = val & ETMv4_MODE_ALL;
> - etm4_set_mode_exclude(drvdata,
> - config->mode & ETM_MODE_EXCLUDE ? true : false);
>
> if (drvdata->instrp0 == true) {
> /* start by clearing instruction P0 field */
> @@ -972,8 +970,12 @@ static ssize_t addr_range_store(struct device *dev,
> unsigned long val1, val2;
> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etmv4_config *config = &drvdata->config;
> + int elements, exclude;
>
> - if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
> + elements = sscanf(buf, "%lx %lx %x", &val1, &val2, &exclude);
> +
> + /* exclude is optional, but need at least two parameter */
> + if (elements < 2)
> return -EINVAL;
> /* lower address comparator cannot have a higher address value */
> if (val1 > val2)
> @@ -1001,9 +1003,11 @@ static ssize_t addr_range_store(struct device *dev,
> /*
> * Program include or exclude control bits for vinst or vdata
> * whenever we change addr comparators to ETM_ADDR_TYPE_RANGE
> + * use supplied value, or default to bit set in 'mode'
> */
> - etm4_set_mode_exclude(drvdata,
> - config->mode & ETM_MODE_EXCLUDE ? true : false);
> + if (elements != 3)
> + exclude = config->mode & ETM_MODE_EXCLUDE;
> + etm4_set_mode_exclude(drvdata, exclude ? true : false);
>
> spin_unlock(&drvdata->spinlock);
> return size;
> @@ -1787,6 +1791,7 @@ static ssize_t ctxid_masks_store(struct device *dev,
> unsigned long val1, val2, mask;
> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etmv4_config *config = &drvdata->config;
> + int nr_inputs;
>
> /*
> * Don't use contextID tracing if coming from a PID namespace. See
> @@ -1802,7 +1807,9 @@ static ssize_t ctxid_masks_store(struct device *dev,
> */
> if (!drvdata->ctxid_size || !drvdata->numcidc)
> return -EINVAL;
> - if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
> + /* one mask if < 4 comparators, two for up to 8 */
> + nr_inputs = sscanf(buf, "%lx %lx", &val1, &val2);
> + if ((drvdata->numcidc > 4) && (nr_inputs != 2))
> return -EINVAL;
>
> spin_lock(&drvdata->spinlock);
> @@ -1976,6 +1983,7 @@ static ssize_t vmid_masks_store(struct device *dev,
> unsigned long val1, val2, mask;
> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etmv4_config *config = &drvdata->config;
> + int nr_inputs;
>
> /*
> * only implemented when vmid tracing is enabled, i.e. at least one
> @@ -1983,7 +1991,9 @@ static ssize_t vmid_masks_store(struct device *dev,
> */
> if (!drvdata->vmid_size || !drvdata->numvmidc)
> return -EINVAL;
> - if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
> + /* one mask if < 4 comparators, two for up to 8 */
> + nr_inputs = sscanf(buf, "%lx %lx", &val1, &val2);
> + if ((drvdata->numvmidc > 4) && (nr_inputs != 2))
> return -EINVAL;
>
> spin_lock(&drvdata->spinlock);
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/8] coresight: etm4x: Add view comparator settings API to sysfs.
From: Mathieu Poirier @ 2019-08-27 21:40 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20190819205720.24457-7-mike.leach@linaro.org>
On Mon, Aug 19, 2019 at 09:57:18PM +0100, Mike Leach wrote:
> Currently it is not possible to view the current settings of a given
> address comparator without knowing what type it is set to. For example, if
> a comparator is set as an addr_start comparator, attempting to read
> addr_stop for the same index will result in an error.
>
> addr_cmp_view is added to allow the user to see the current settings of
> the indexed address comparator without resorting to trail and error when
> the set type is not known.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 51 +++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index baac5b48b7ac..483976074779 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -1272,6 +1272,56 @@ static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(addr_exlevel_s_ns);
>
> +static const char * const addr_type_names[] = {
> + "unused",
> + "single",
> + "range",
> + "start",
> + "stop"
> +};
> +
> +static ssize_t addr_cmp_view_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + u8 idx, addr_type;
> + unsigned long addr_v, addr_v2, addr_ctrl;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> + int size = 0;
> + bool exclude = false;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->addr_idx;
> + addr_v = config->addr_val[idx];
> + addr_ctrl = config->addr_acc[idx];
> + addr_type = config->addr_type[idx];
> + if (addr_type == ETM_ADDR_TYPE_RANGE) {
> + if (idx%2) {
> + idx -= 1;
> + addr_v2 = addr_v;
> + addr_v = config->addr_val[idx];
> + } else
> + addr_v2 = config->addr_val[idx+1];
s/"idx+1"/"idx + 1"/
With that:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> + exclude = config->viiectlr & BIT(idx / 2 + 16);
> + }
> + spin_unlock(&drvdata->spinlock);
> + if (addr_type) {
> + size = scnprintf(buf, PAGE_SIZE, "addr_cmp[%i] %s %#lx", idx,
> + addr_type_names[addr_type], addr_v);
> + if (addr_type == ETM_ADDR_TYPE_RANGE) {
> + size += scnprintf(buf+size, PAGE_SIZE-size,
> + " %#lx %s", addr_v2,
> + exclude ? "exclude" : "include");
> + }
> + size += scnprintf(buf+size, PAGE_SIZE-size,
> + " ctrl(%#lx)\n", addr_ctrl);
> + } else {
> + size = scnprintf(buf, PAGE_SIZE, "addr_cmp[%i] unused\n", idx);
> + }
> + return size;
> +}
> +static DEVICE_ATTR_RO(addr_cmp_view);
> +
> static ssize_t vinst_pe_cmp_start_stop_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -2117,6 +2167,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> &dev_attr_addr_ctxtype.attr,
> &dev_attr_addr_context.attr,
> &dev_attr_addr_exlevel_s_ns.attr,
> + &dev_attr_addr_cmp_view.attr,
> &dev_attr_vinst_pe_cmp_start_stop.attr,
> &dev_attr_seq_idx.attr,
> &dev_attr_seq_state.attr,
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: Rob Herring @ 2019-08-27 21:51 UTC (permalink / raw)
To: René van Dorst
Cc: devicetree, Nelson Chang, Frank Wunderlich, netdev, Sean Wang,
linux-mips, linux-mediatek, John Crispin, Matthias Brugger,
Stefan Roese, David S . Miller, linux-arm-kernel
In-Reply-To: <20190821144336.9259-4-opensource@vdorst.com>
On Wed, Aug 21, 2019 at 04:43:36PM +0200, René van Dorst wrote:
> This patch the removes the recently added mediatek,physpeed property.
> Use the fixed-link property speed = <2500> to set the phy in 2.5Gbit.
> See mt7622-bananapi-bpi-r64.dts for a working example.
>
> Signed-off-by: René van Dorst <opensource@vdorst.com>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> --
> v1->v2:
> * SGMII port only support BASE-X at 2.5Gbit.
> ---
> .../arm/mediatek/mediatek,sgmiisys.txt | 2 --
Bindings and dts files should be separate patches.
> .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 28 +++++++++++++------
> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 -
> 3 files changed, 19 insertions(+), 12 deletions(-)
In any case,
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: meson-g12: specify suspend OPP
From: Kevin Hilman @ 2019-08-27 21:56 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190827100307.21661-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Tag the 1,2GHz OPP as suspend OPP to be set before going in suspend mode,
> for the G12A, G12B and SM1 SoCs.
>
> It has been reported that using various OPPs can lead to error or
> resume with a different OPP from the ROM, thus use this safe OPP as
> it is the default OPP used by the BL2 boot firmware.
>
> Neil Armstrong (3):
> arm64: dts: meson-g12a: specify suspend OPP
> arm64: dts: meson-sm1: specify suspend OPP
> arm64: dts: meson-g12b: specify suspend OPP
Queued patches 1, 3 for v5.4.
The SM1 patch has a dependency on the SM1 DVFS series, which in turn has
a dependency on clock changes. Once I get a stable tag for the SM1
clock changes, I'll queue up the rest.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox