* [PATCH v2 2/2] ASoC: sun4i: Revert A83t description
From: Maxime Ripard @ 2019-08-27 12:31 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20190827123131.29129-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
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>
---
Changes from v1:
- Fix function name
---
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.21.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
* [PATCH v2 1/2] ASoC: sun4i-i2s: Revert "ASoC: sun4i-i2s: Remove duplicated quirks structure"
From: Maxime Ripard @ 2019-08-27 12:31 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
From: Maxime Ripard <maxime.ripard@bootlin.com>
This reverts commit 3e9acd7ac6933cdc20c441bbf9a38ed9e42e1490.
It turns out that while one I2S controller is described in the A83t
datasheet, the driver supports another, undocumented, one that has been
inherited from the older SoCs, while the documented one uses the new
design.
Fixes: 3e9acd7ac693 ("ASoC: sun4i-i2s: Remove duplicated quirks structure")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
Changes from v1:
- Add the proper prefix to the commit title
---
sound/soc/sunxi/sun4i-i2s.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 57bf2a33753e..a6a3f772fdf0 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1097,6 +1097,11 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
.set_fmt = sun4i_i2s_set_soc_fmt,
};
+/*
+ * This doesn't describe the TDM controller documented in the A83t
+ * datasheet, but the three undocumented I2S controller that use the
+ * older design.
+ */
static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1115,6 +1120,24 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.set_fmt = sun8i_i2s_set_soc_fmt,
};
+static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
+ .has_reset = true,
+ .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
+ .sun4i_i2s_regmap = &sun8i_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,
+};
+
static const struct sun4i_i2s_quirks sun50i_a64_codec_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1296,7 +1319,7 @@ static const struct of_device_id sun4i_i2s_match[] = {
},
{
.compatible = "allwinner,sun8i-h3-i2s",
- .data = &sun8i_a83t_i2s_quirks,
+ .data = &sun8i_h3_i2s_quirks,
},
{
.compatible = "allwinner,sun50i-a64-codec-i2s",
--
2.21.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] arm: xen: mm: use __GPF_DMA32 for arm64
From: Robin Murphy @ 2019-08-27 12:23 UTC (permalink / raw)
To: Peng Fan, sstabellini@kernel.org, linux@armlinux.org.uk
Cc: van.freenix@gmail.com, xen-devel@lists.xenproject.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <20190709083729.11135-1-peng.fan@nxp.com>
On 09/07/2019 09:22, Peng Fan wrote:
> arm64 shares some code under arch/arm/xen, including mm.c.
> However ZONE_DMA is removed by commit
> ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> So to ARM64, need use __GFP_DMA32.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> arch/arm/xen/mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index e1d44b903dfc..a95e76d18bf9 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
>
> for_each_memblock(memory, reg) {
> if (reg->base < (phys_addr_t)0xffffffff) {
> - flags |= __GFP_DMA;
> + flags |= __GFP_DMA | __GFP_DMA32;
Given the definition of GFP_ZONE_BAD, I'm not sure this combination of
flags is strictly valid, but rather is implicitly reliant on only one of
those zones ever actually existing. As such, it seems liable to blow up
if the plans to add ZONE_DMA to arm64[1] go ahead.
Robin.
[1]
https://lore.kernel.org/linux-arm-kernel/20190820145821.27214-1-nsaenzjulienne@suse.de/
> break;
> }
> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] Documentation: add link to stm32mp157 docs
From: Gerald BAEZA @ 2019-08-27 12:19 UTC (permalink / raw)
To: corbet@lwn.net, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
linux-doc@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Gerald BAEZA
Link to the online stm32mp157 documentation added
in the overview.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
Documentation/arm/stm32/stm32mp157-overview.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
index f62fdc8..8d5a476 100644
--- a/Documentation/arm/stm32/stm32mp157-overview.rst
+++ b/Documentation/arm/stm32/stm32mp157-overview.rst
@@ -14,6 +14,12 @@ It features:
- Standard connectivity, widely inherited from the STM32 MCU family
- Comprehensive security support
+Resources
+---------
+
+Datasheet and reference manual are publicly available on ST website:
+.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
+
:Authors:
- Ludovic Barre <ludovic.barre@st.com>
--
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 related
* Re: [PATCH] usb: dwc3: Add shutdown to platform_driver
From: Vicente Bergas @ 2019-08-27 12:16 UTC (permalink / raw)
To: Felipe Balbi
Cc: Matthias Brugger, Heiko Stuebner, MarcZyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-rockchip, Greg Kroah-Hartman,
Robin Murphy, linux-arm-kernel
In-Reply-To: <87v9uix1sv.fsf@gmail.com>
On Tuesday, August 27, 2019 1:53:04 PM CEST, Felipe Balbi wrote:
> Hi,
>
> Vicente Bergas <vicencb@gmail.com> writes:
>> On Saturday, August 17, 2019 7:41:40 PM CEST, Vicente Bergas wrote:
>>> Otherwise the device keeps writing to memory after kexec and disturbs
>>> the next kernel.
...
>
> why don't you just have shutdown use the same exact function as remove?
> Frankly, though, I still don't fully understand what's going wrong
> here. Why is the device still alive during kexec?
>
> cheers
Hi Felipe,
the remove and shutdown functions have different prototypes, so
shutdown is wrapping remove.
Would it be preferable to cast remove as shutdown?
The issue with kexec is that the device is being used during the livetime
of the first kernel. When the first kernel executes kexec it calls the
shutdown function of drivers (instead of remove). Because of this the dwc3
device keeps doing things like DMA.
While the second kernel is taking over, it gets its memory corrupted with
such DMA accesses from the device. When the second kernel reaches the point
of taking over the dwc3 device, re-initializes it, but it is already too
late. Still worse, if the second kernel did not have the dwc3 driver, it
would get endless memory corruptions.
All in all, devices that can do DMA need to stop doing it on shutdown.
Regards,
Vicenç.
_______________________________________________
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 01/11] kselftest: arm64: introduce new boilerplate code
From: Cristian Marussi @ 2019-08-27 12:14 UTC (permalink / raw)
To: Dave Martin; +Cc: andreyknvl, shuah, linux-arm-kernel, linux-kselftest
In-Reply-To: <20190813162337.GY10425@arm.com>
Hi
On 13/08/2019 17:23, Dave Martin wrote:
> ^ Regarding the subject line, "boilerplate code" sounds a bit vague.
> Could we say something like "Add skeleton Makefile"?
>
Yes of course.
> On Fri, Aug 02, 2019 at 06:02:50PM +0100, Cristian Marussi wrote:
>> Added a new arm64-specific empty subsystem amongst TARGETS of KSFT build
>> framework; once populated with testcases, it will be possible to build
>> and invoke the new KSFT TARGETS=arm64 related tests from the toplevel
>> Makefile in the usual ways.
>>
>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> ---
>> Reviewed the build instructions reported in the README, to be more
>> agnostic regarding user/device etc..
>> ---
>> tools/testing/selftests/Makefile | 1 +
>> tools/testing/selftests/arm64/Makefile | 51 ++++++++++++++++++++++++++
>> tools/testing/selftests/arm64/README | 43 ++++++++++++++++++++++
>> 3 files changed, 95 insertions(+)
>> create mode 100644 tools/testing/selftests/arm64/Makefile
>> create mode 100644 tools/testing/selftests/arm64/README
>>
>> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
>> index 25b43a8c2b15..1722dae9381a 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -1,5 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0
>> TARGETS = android
>> +TARGETS += arm64
>> TARGETS += bpf
>> TARGETS += breakpoints
>> TARGETS += capabilities
>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>> new file mode 100644
>> index 000000000000..03a0d4f71218
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/Makefile
>> @@ -0,0 +1,51 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +# Copyright (C) 2019 ARM Limited
>> +
>> +# When ARCH not overridden for crosscompiling, lookup machine
>> +ARCH ?= $(shell uname -m)
>> +ARCH := $(shell echo $(ARCH) | sed -e s/aarch64/arm64/)
>> +
>> +ifeq ("x$(ARCH)", "xarm64")
>> +SUBDIRS :=
>> +else
>> +SUBDIRS :=
>> +endif
>> +
>> +CFLAGS := -Wall -O2 -g
>> +
>> +export CC
>> +export CFLAGS
>> +
>> +all:
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + mkdir -p $$BUILD_TARGET; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +install: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +run_tests: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +# Avoid any output on non arm64 on emit_tests
>> +emit_tests: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +clean:
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +.PHONY: all clean install run_tests emit_tests
>> diff --git a/tools/testing/selftests/arm64/README b/tools/testing/selftests/arm64/README
>> new file mode 100644
>> index 000000000000..dee3306071cc
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/README
>> @@ -0,0 +1,43 @@
>> +KSelfTest ARM64
>> +===============
>> +
>> +- These tests are arm64 specific and so not built or run but just skipped
>> + completely when env-variable ARCH is found to be different than 'arm64'
>> + and `uname -m` reports other than 'aarch64'.
>> +
>> +- Holding true the above, ARM64 KSFT tests can be run:
>> +
>> + + as standalone (example for signal tests)
>> +
>> + $ make -C tools/testing/selftest/arm64/signal \
>> + INSTALL_PATH=<your-installation-path> install
>> +
>> + and then launching on the target device inside the installed path:
>> +
>> + $ <your-installed-path>/test_arm64_signals.sh [-k | -v]
>> +
>> + + within the KSelfTest framework using standard Linux top-level-makefile
>> + targets:
>> +
>> + $ make TARGETS=arm64 kselftest-clean
>> + $ make TARGETS=arm64 kselftest
>> +
>> + Further details on building and running KFST can be found in:
>> + Documentation/dev-tools/kselftest.rst
>
> The next two paragraphs aren't relevant yet. Can we split them out of
> this patch and add them alongside the relevant code / Makefile changes?
>
Sure. I'm going to remove also standalone mode in V4 as elsewhere advised,
so I'll drop part of this README too.
>> +
>> +- Tests can depend on some arch-specific definitions which can be found in a
>> + standard Kernel Headers installation in $(top_srcdir)/usr/include.
>> + Such Kernel Headers are automatically installed (via make headers_install)
>> + by KSFT framework itself in a dedicated directory when tests are launched
>> + via KSFT itself; when running standalone, instead, a Warning is issued
>> + if such headers cannot be found somewhere (we try to guess a few standard
>> + locations anyway)
>> +
>> +- Some of these tests may be related to possibly not implemented ARMv8
>> + features: depending on their implementation status on the effective HW
>> + we'll expect different results. The tests' harness will take care to check
>> + at run-time if the required features are supported and will act accordingly.
>> + Moreover, in order to avoid any kind of compile-time dependency on the
>> + toolchain (possibly due to the above mentioned not-implemented features),
>> + we make strictly use of direct 'S3_ sysreg' raw-encoding while checking for
>> + those features and/or lookin up sysregs.
>
> This last paragraph is only relevant for people adding new tests. It
> probably makes sense to start "When adding new tests, try to avoid
> unnecessary toolchain dependencies where possible. [...]"
>
> Cheers
> ---Dave
>
Cheers
Cristian
_______________________________________________
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 v4 4/8] dt-bindings: clock: Add devicetree binding for BM1880 SoC
From: Rob Herring @ 2019-08-27 12:12 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, Stephen Boyd, Michael Turquette,
linux-kernel@vger.kernel.org, darren.tsao, haitao.suo,
fisher.cheng, alec.lin, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190822172426.25879-5-manivannan.sadhasivam@linaro.org>
On Thu, Aug 22, 2019 at 12:25 PM Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> Add YAML devicetree binding for Bitmain BM1880 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/clock/bitmain,bm1880-clk.yaml | 74 +++++++++++++++++
> include/dt-bindings/clock/bm1880-clock.h | 82 +++++++++++++++++++
> 2 files changed, 156 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
> create mode 100644 include/dt-bindings/clock/bm1880-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
> new file mode 100644
> index 000000000000..31c48dcf5b8e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: GPL-2.0+
Dual license please.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bindings/clock/bitmain,bm1880-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bitmain BM1880 Clock Controller
> +
> +maintainers:
> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> +
> +description: |
> + The Bitmain BM1880 clock controller generates and supplies clock to
> + various peripherals within the SoC.
> +
> + This binding uses common clock bindings
> + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +properties:
> + compatible:
> + const: bitmain,bm1880-clk
> +
> + reg:
> + items:
> + - description: pll registers
> + - description: system registers
> +
> + reg-names:
> + items:
> + - const: pll
> + - const: sys
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: osc
> +
> + '#clock-cells':
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - '#clock-cells'
additionalProperties: false
> +
> +examples:
> + # Clock controller node:
> + - |
> + clk: clock-controller@e8 {
> + compatible = "bitmain,bm1880-clk";
> + reg = <0xe8 0x0c>, <0x800 0xb0>;
> + reg-names = "pll", "sys";
> + clocks = <&osc>;
> + clock-names = "osc";
> + #clock-cells = <1>;
> + };
> +
> + # Example UART controller node that consumes clock generated by the clock controller:
> + - |
> + uart0: serial@58018000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x0 0x58018000 0x0 0x2000>;
> + clocks = <&clk 45>, <&clk 46>;
> + clock-names = "baudclk", "apb_pclk";
> + interrupts = <0 9 4>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + };
> +
> +...
> diff --git a/include/dt-bindings/clock/bm1880-clock.h b/include/dt-bindings/clock/bm1880-clock.h
> new file mode 100644
> index 000000000000..b46732361b25
> --- /dev/null
> +++ b/include/dt-bindings/clock/bm1880-clock.h
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Device Tree binding constants for Bitmain BM1880 SoC
> + *
> + * Copyright (c) 2019 Linaro Ltd.
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_BM1880_H
> +#define __DT_BINDINGS_CLOCK_BM1880_H
> +
> +#define BM1880_CLK_OSC 0
> +#define BM1880_CLK_MPLL 1
> +#define BM1880_CLK_SPLL 2
> +#define BM1880_CLK_FPLL 3
> +#define BM1880_CLK_DDRPLL 4
> +#define BM1880_CLK_A53 5
> +#define BM1880_CLK_50M_A53 6
> +#define BM1880_CLK_AHB_ROM 7
> +#define BM1880_CLK_AXI_SRAM 8
> +#define BM1880_CLK_DDR_AXI 9
> +#define BM1880_CLK_EFUSE 10
> +#define BM1880_CLK_APB_EFUSE 11
> +#define BM1880_CLK_AXI5_EMMC 12
> +#define BM1880_CLK_EMMC 13
> +#define BM1880_CLK_100K_EMMC 14
> +#define BM1880_CLK_AXI5_SD 15
> +#define BM1880_CLK_SD 16
> +#define BM1880_CLK_100K_SD 17
> +#define BM1880_CLK_500M_ETH0 18
> +#define BM1880_CLK_AXI4_ETH0 19
> +#define BM1880_CLK_500M_ETH1 20
> +#define BM1880_CLK_AXI4_ETH1 21
> +#define BM1880_CLK_AXI1_GDMA 22
> +#define BM1880_CLK_APB_GPIO 23
> +#define BM1880_CLK_APB_GPIO_INTR 24
> +#define BM1880_CLK_GPIO_DB 25
> +#define BM1880_CLK_AXI1_MINER 26
> +#define BM1880_CLK_AHB_SF 27
> +#define BM1880_CLK_SDMA_AXI 28
> +#define BM1880_CLK_SDMA_AUD 29
> +#define BM1880_CLK_APB_I2C 30
> +#define BM1880_CLK_APB_WDT 31
> +#define BM1880_CLK_APB_JPEG 32
> +#define BM1880_CLK_JPEG_AXI 33
> +#define BM1880_CLK_AXI5_NF 34
> +#define BM1880_CLK_APB_NF 35
> +#define BM1880_CLK_NF 36
> +#define BM1880_CLK_APB_PWM 37
> +#define BM1880_CLK_DIV_0_RV 38
> +#define BM1880_CLK_DIV_1_RV 39
> +#define BM1880_CLK_MUX_RV 40
> +#define BM1880_CLK_RV 41
> +#define BM1880_CLK_APB_SPI 42
> +#define BM1880_CLK_TPU_AXI 43
> +#define BM1880_CLK_DIV_UART_500M 44
> +#define BM1880_CLK_UART_500M 45
> +#define BM1880_CLK_APB_UART 46
> +#define BM1880_CLK_APB_I2S 47
> +#define BM1880_CLK_AXI4_USB 48
> +#define BM1880_CLK_APB_USB 49
> +#define BM1880_CLK_125M_USB 50
> +#define BM1880_CLK_33K_USB 51
> +#define BM1880_CLK_DIV_12M_USB 52
> +#define BM1880_CLK_12M_USB 53
> +#define BM1880_CLK_APB_VIDEO 54
> +#define BM1880_CLK_VIDEO_AXI 55
> +#define BM1880_CLK_VPP_AXI 56
> +#define BM1880_CLK_APB_VPP 57
> +#define BM1880_CLK_DIV_0_AXI1 58
> +#define BM1880_CLK_DIV_1_AXI1 59
> +#define BM1880_CLK_AXI1 60
> +#define BM1880_CLK_AXI2 61
> +#define BM1880_CLK_AXI3 62
> +#define BM1880_CLK_AXI4 63
> +#define BM1880_CLK_AXI5 64
> +#define BM1880_CLK_DIV_0_AXI6 65
> +#define BM1880_CLK_DIV_1_AXI6 66
> +#define BM1880_CLK_MUX_AXI6 67
> +#define BM1880_CLK_AXI6 68
> +#define BM1880_NR_CLKS 69
> +
> +#endif /* __DT_BINDINGS_CLOCK_BM1880_H */
> --
> 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 v3 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
From: Rob Herring @ 2019-08-27 12:09 UTC (permalink / raw)
To: Guido Günther
Cc: Mark Rutland, devicetree, Jernej Skrabec, Daniel Vetter,
Sam Ravnborg, Neil Armstrong, David Airlie, Fabio Estevam,
Sascha Hauer, Jonas Karlman, linux-kernel@vger.kernel.org,
dri-devel, Andrzej Hajda, Arnd Bergmann, NXP Linux Team,
Pengutronix Kernel Team, Robert Chiras, Lee Jones, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Laurent Pinchart
In-Reply-To: <36f62b431f32bc76e92d21e04dc48464aef43869.1566470526.git.agx@sigxcpu.org>
On Thu, Aug 22, 2019 at 5:44 AM Guido Günther <agx@sigxcpu.org> wrote:
>
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 155 ++++++++++++++++++
> 1 file changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> new file mode 100644
> index 000000000000..24d17a6310dc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -0,0 +1,155 @@
> +# SPDX-License-Identifier: GPL-2.0
(GPL-2.0-only OR BSD-2-Clause) is preferred for new bindings.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Northwest Logic MIPI-DSI controller on i.MX SoCs
> +
> +maintainers:
> + - Guido Gúnther <agx@sigxcpu.org>
> + - Robert Chiras <robert.chiras@nxp.com>
> +
> +description: |
> + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge for
> + the SOCs NWL MIPI-DSI host controller.
> +
> +properties:
> + compatible:
> + const: fsl,imx8mq-nwl-dsi
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: DSI core clock
> + - description: RX_ESC clock (used in escape mode)
> + - description: TX_ESC clock (used in escape mode)
> + - description: PHY_REF clock
> +
> + clock-names:
> + items:
> + - const: core
> + - const: rx_esc
> + - const: tx_esc
> + - const: phy_ref
> +
> + mux-controls:
> + description:
> + mux controller node to use for operating the input mux
> +
> + phys:
> + maxItems: 1
> + description:
> + A phandle to the phy module representing the DPHY
> +
> + phy-names:
> + items:
> + - const: dphy
> +
> + power-domains:
> + maxItems: 1
> + description:
> + A phandle to the power domain
Don't need a description for common properties unless you have
something specific about this device to say.
> +
> + resets:
> + description:
> + phandles to the reset controller
Same here.
> + items:
> + - description: dsi byte reset line
> + - description: dsi dpi reset line
> + - description: dsi esc reset line
> + - description: dsi pclk reset line
> +
> + reset-names:
> + items:
> + - const: byte
> + - const: dpi
> + - const: esc
> + - const: pclk
> +
> + ports:
> + type: object
> + description:
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/graph.txt.
> +
> + port@0:
These are child nodes of ports. So under ports you need 'properties'
with these. And 'required'.
> + type: object
> + description:
> + Input port node to receive pixel data from the
> + display controller
> +
> + port@1:
> + type: object
> + description:
> + DSI output port node to the panel or the next bridge
> + in the chain
> +
> +patternProperties:
> + "^panel@[0-9]+$": true
This is a node, so:
type: object
> +
> +required:
> + - clock-names
> + - clocks
> + - compatible
> + - interrupts
> + - mux-controls
> + - phy-names
> + - phys
> + - ports
> + - reg
> + - reset-names
> + - resets
Add a:
additionalProperties: false
> +
> +examples:
> + - |
> +
> + mipi_dsi: mipi_dsi@30a00000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
These need to be listed above.
> + compatible = "fsl,imx8mq-nwl-dsi";
> + reg = <0x30A00000 0x300>;
> + clocks = <&clk 163>, <&clk 244>, <&clk 245>, <&clk 164>;
> + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> + interrupts = <0 34 4>;
> + mux-controls = <&mux 0>;
> + power-domains = <&pgc_mipi>;
> + resets = <&src 0>, <&src 1>, <&src 2>, <&src 3>;
> + reset-names = "byte", "dpi", "esc", "pclk";
> + phys = <&dphy>;
> + phy-names = "dphy";
> +
> + panel@0 {
> + compatible = "rocktech,jh057n00900";
> + reg = <0>;
> + port@0 {
> + panel_in: endpoint {
> + remote-endpoint = <&mipi_dsi_out>;
> + };
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + mipi_dsi_in: endpoint {
> + remote-endpoint = <&lcdif_mipi_dsi>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + mipi_dsi_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> + };
> --
> 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
* Re: [PATCH v2 03/20] dt-bindings: arm: mrvl: Document MMP3 compatible string
From: Rob Herring @ 2019-08-27 12:00 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Olof Johansson, Thomas Gleixner, linux-clk,
linux-kernel@vger.kernel.org
In-Reply-To: <20190822092643.593488-4-lkundrak@v3.sk>
On Thu, Aug 22, 2019 at 4:33 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Marvel MMP3 is a successor to MMP2, containing similar peripherals with two
> PJ4B cores.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Rebased on top of mrvl.txt->mrvl.yaml conversion
>
> Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml | 3 +++
> 1 file changed, 3 insertions(+)
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 v2 02/20] dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema
From: Rob Herring @ 2019-08-27 11:59 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Olof Johansson, Thomas Gleixner, linux-clk,
linux-kernel@vger.kernel.org
In-Reply-To: <20190822092643.593488-3-lkundrak@v3.sk>
On Thu, Aug 22, 2019 at 4:27 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Convert Marvell MMP SoC bindings to DT schema format using json-schema.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Added this patch
>
> .../devicetree/bindings/arm/mrvl/mrvl.txt | 14 ---------
> .../devicetree/bindings/arm/mrvl/mrvl.yaml | 31 +++++++++++++++++++
> 2 files changed, 31 insertions(+), 14 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> create mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> deleted file mode 100644
> index 951687528efb0..0000000000000
> --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -Marvell Platforms Device Tree Bindings
> -----------------------------------------------------
> -
> -PXA168 Aspenite Board
> -Required root node properties:
> - - compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
> -
> -PXA910 DKB Board
> -Required root node properties:
> - - compatible = "mrvl,pxa910-dkb";
> -
> -MMP2 Brownstone Board
> -Required root node properties:
> - - compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
> new file mode 100644
> index 0000000000000..dc9de506ac6e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
> @@ -0,0 +1,31 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mrvl/mrvl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell Platforms Device Tree Bindings
> +
> +maintainers:
> + - Lubomir Rintel <lkundrak@v3.sk>
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> + - description: PXA168 Aspenite Board
> + items:
> + - enum:
> + - mrvl,pxa168-aspenite
> + - const: mrvl,pxa168
> + - description: PXA910 DKB Board
> + items:
> + - enum:
> + - mrvl,pxa910-dkb
Doesn't match what's in dts file:
arch/arm/boot/dts/pxa910-dkb.dts: compatible =
"mrvl,pxa910-dkb", "mrvl,pxa910";
> + - description: MMP2 Brownstone Board
If this entry is only for this board...
> + items:
> + - enum:
> + - mrvl,mmp2-brownstone
...then this can be a 'const' instead. Same for the others.
> + - const: mrvl,mmp2
> +...
> --
> 2.21.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Christoph Hellwig @ 2019-08-27 11:55 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ulf Hansson, Tony Lindgren, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Max Filippov, Christoph Hellwig,
Marek Szyprowski, Stephen Rothwell, Joerg Roedel, Russell King,
Thierry Reding, linux-xtensa, Kees Cook, Nicolin Chen,
Andrew Morton, linux-arm-kernel, Chris Zankel, Wolfram Sang,
Robin Murphy, linux-mmc, Adrian Hunter, iommu, iamjoonsoo.kim,
David Woodhouse
In-Reply-To: <CAK7LNAQZ+bueZZzSoMADmgLjWNvijHRV=wLQzN_kvLG3b5Uu+w@mail.gmail.com>
On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> Yes, this makes my driver working again
> when CONFIG_DMA_CMA=y.
>
>
> If I apply the following, my driver gets back working
> irrespective of CONFIG_DMA_CMA.
That sounds a lot like the device simply isn't 64-bit DMA capable, and
previously always got CMA allocations under the limit it actually
supported. I suggest that you submit this quirk to the mmc maintainers.
_______________________________________________
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 1/2] dt-bindings: arm: sunxi: Add compatible for A64 OlinuXino with eMMC
From: Rob Herring @ 2019-08-27 11:55 UTC (permalink / raw)
To: Sunil Mohan Adapa
Cc: Maxime Ripard, devicetree, Chen-Yu Tsai, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190821195217.4166-2-sunil@medhas.org>
On Wed, Aug 21, 2019 at 2:53 PM Sunil Mohan Adapa <sunil@medhas.org> wrote:
>
> A64 OLinuXino board from Olimex has three variants with onboard eMMC:
> A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In
> addition, there are two variants without eMMC. One without eMMC and one with SPI
> flash. This suggests the need for separate device tree for the three eMMC
> variants.
>
> Add new compatible string to the bindings documentation for the A64 OlinuXino
> board variant with on-board eMMC.
>
> Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
> ---
> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
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] usb: dwc3: Add shutdown to platform_driver
From: Felipe Balbi @ 2019-08-27 11:53 UTC (permalink / raw)
To: Vicente Bergas, Robin Murphy
Cc: Matthias Brugger, Heiko Stuebner, MarcZyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-rockchip, Greg Kroah-Hartman,
linux-arm-kernel
In-Reply-To: <8d48017a-64c5-4b25-8d85-113ffcf502c9@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1852 bytes --]
Hi,
Vicente Bergas <vicencb@gmail.com> writes:
> On Saturday, August 17, 2019 7:41:40 PM CEST, Vicente Bergas wrote:
>> Otherwise the device keeps writing to memory after kexec and disturbs
>> the next kernel.
>>
>> Signed-off-by: Vicente Bergas <vicencb@gmail.com>
>> ---
>> drivers/usb/dwc3/dwc3-of-simple.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> Hi Felipe, Robin,
>> this version calls 'remove' from 'shutdown' instead of just asserting
>> a reset because it looks like a cleaner way to stop the device.
>>
>> Calling remove from shutdown in core.c instead of dwc3-of-simple.c does not
>> fix the issue either.
>>
>> It has been tested on the sapphire board, a RK3399 platform.
>>
>> Regards,
>> Vicenç.
>>
>> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
>> b/drivers/usb/dwc3/dwc3-of-simple.c
>> index bdac3e7d7b18..d5fd45c64901 100644
>> --- a/drivers/usb/dwc3/dwc3-of-simple.c
>> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>> @@ -133,6 +133,11 @@ static int dwc3_of_simple_remove(struct
>> platform_device *pdev)
>> return 0;
>> }
>>
>> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
>> +{
>> + dwc3_of_simple_remove(pdev);
>> +}
>> +
>> static int __maybe_unused
>> dwc3_of_simple_runtime_suspend(struct device *dev)
>> {
>> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
>> @@ -190,6 +195,7 @@ MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
>> static struct platform_driver dwc3_of_simple_driver = {
>> .probe = dwc3_of_simple_probe,
>> .remove = dwc3_of_simple_remove,
>> + .shutdown = dwc3_of_simple_shutdown,
why don't you just have shutdown use the same exact function as remove?
Frankly, though, I still don't fully understand what's going wrong
here. Why is the device still alive during kexec?
cheers
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- 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
* Re: [PATCH] usb: dwc3: Add shutdown to platform_driver
From: Vicente Bergas @ 2019-08-27 11:45 UTC (permalink / raw)
To: Felipe Balbi, Robin Murphy
Cc: Matthias Brugger, Heiko Stuebner, MarcZyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-rockchip, Greg Kroah-Hartman,
linux-arm-kernel
In-Reply-To: <20190817174140.6394-1-vicencb@gmail.com>
On Saturday, August 17, 2019 7:41:40 PM CEST, Vicente Bergas wrote:
> Otherwise the device keeps writing to memory after kexec and disturbs
> the next kernel.
>
> Signed-off-by: Vicente Bergas <vicencb@gmail.com>
> ---
> drivers/usb/dwc3/dwc3-of-simple.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> Hi Felipe, Robin,
> this version calls 'remove' from 'shutdown' instead of just asserting
> a reset because it looks like a cleaner way to stop the device.
>
> Calling remove from shutdown in core.c instead of dwc3-of-simple.c does not
> fix the issue either.
>
> It has been tested on the sapphire board, a RK3399 platform.
>
> Regards,
> Vicenç.
>
> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
> b/drivers/usb/dwc3/dwc3-of-simple.c
> index bdac3e7d7b18..d5fd45c64901 100644
> --- a/drivers/usb/dwc3/dwc3-of-simple.c
> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> @@ -133,6 +133,11 @@ static int dwc3_of_simple_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
> +{
> + dwc3_of_simple_remove(pdev);
> +}
> +
> static int __maybe_unused
> dwc3_of_simple_runtime_suspend(struct device *dev)
> {
> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
> @@ -190,6 +195,7 @@ MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
> static struct platform_driver dwc3_of_simple_driver = {
> .probe = dwc3_of_simple_probe,
> .remove = dwc3_of_simple_remove,
> + .shutdown = dwc3_of_simple_shutdown,
> .driver = {
> .name = "dwc3-of-simple",
> .of_match_table = of_dwc3_simple_match,
Hi,
please, can you provide some feedback on this?
Regards,
Vicenç.
_______________________________________________
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] fdt: Update CRC check for rng-seed
From: Geert Uytterhoeven @ 2019-08-27 11:19 UTC (permalink / raw)
To: Hsin-Yi Wang; +Cc: Linux-Renesas, Will Deacon, Linux ARM
In-Reply-To: <20190827103353.109218-1-hsinyi@chromium.org>
Hi Hsin-Yi,
Thanks for the prompt fix!
On Tue, Aug 27, 2019 at 12:34 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> Commit 428826f5358c ("fdt: add support for rng-seed") moves of_fdt_crc32
> from early_init_dt_verify() to early_init_dt_scan() since
> early_init_dt_scan_chosen() may modify fdt to erase rng-seed.
>
> However, arm and some other arch won't call early_init_dt_scan(), they
> call early_init_dt_verify() then early_init_dt_scan_nodes().
>
> Restore of_fdt_crc32 to early_init_dt_verify() then update it in
> early_init_dt_scan_chosen() if fdt if updated.
>
> Fixes: 428826f5358c ("fdt: add support for rng-seed")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
_______________________________________________
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 v4 1/7] perf: arm64: Add test to check userspace access to hardware counters.
From: Jonathan Cameron @ 2019-08-27 11:17 UTC (permalink / raw)
To: Raphael Gault
Cc: mark.rutland, raph.gault+kdev, peterz, catalin.marinas,
will.deacon, linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <20190822144220.27860-2-raphael.gault@arm.com>
On Thu, 22 Aug 2019 15:42:14 +0100
Raphael Gault <raphael.gault@arm.com> wrote:
> This test relies on the fact that the PMU registers are accessible
> from userspace. It then uses the perf_event_mmap_page to retrieve
> the counter index and access the underlying register.
>
> This test uses sched_setaffinity(2) in order to run on all CPU and thus
> check the behaviour of the PMU of all cpus in a big.LITTLE environment.
>
> Signed-off-by: Raphael Gault <raphael.gault@arm.com>
Hi Raphael,
I just tested this on 1620 and it works fairly nicely with one exception...
The test will run and generate garbage numbers if the rest of the
series isn't yet applied to the kernel. Is there anything we can do
to prevent that?
It's a slightly silly complaint, but this also take a while compared to all
the other tests if you have lots of cores, so maybe a slightly shorter
test?
Thanks,
Jonathan
> ---
> tools/perf/arch/arm64/include/arch-tests.h | 7 +
> tools/perf/arch/arm64/tests/Build | 1 +
> tools/perf/arch/arm64/tests/arch-tests.c | 4 +
> tools/perf/arch/arm64/tests/user-events.c | 254 +++++++++++++++++++++
> 4 files changed, 266 insertions(+)
> create mode 100644 tools/perf/arch/arm64/tests/user-events.c
>
> diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
> index 90ec4c8cb880..6a8483de1015 100644
> --- a/tools/perf/arch/arm64/include/arch-tests.h
> +++ b/tools/perf/arch/arm64/include/arch-tests.h
> @@ -2,11 +2,18 @@
> #ifndef ARCH_TESTS_H
> #define ARCH_TESTS_H
>
> +#include <linux/compiler.h>
> +
> #ifdef HAVE_DWARF_UNWIND_SUPPORT
> struct thread;
> struct perf_sample;
> +int test__arch_unwind_sample(struct perf_sample *sample,
> + struct thread *thread);
> #endif
>
> extern struct test arch_tests[];
> +int test__rd_pmevcntr(struct test *test __maybe_unused,
> + int subtest __maybe_unused);
> +
>
> #endif
> diff --git a/tools/perf/arch/arm64/tests/Build b/tools/perf/arch/arm64/tests/Build
> index a61c06bdb757..3f9a20c17fc6 100644
> --- a/tools/perf/arch/arm64/tests/Build
> +++ b/tools/perf/arch/arm64/tests/Build
> @@ -1,4 +1,5 @@
> perf-y += regs_load.o
> perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
>
> +perf-y += user-events.o
> perf-y += arch-tests.o
> diff --git a/tools/perf/arch/arm64/tests/arch-tests.c b/tools/perf/arch/arm64/tests/arch-tests.c
> index 5b1543c98022..57df9b89dede 100644
> --- a/tools/perf/arch/arm64/tests/arch-tests.c
> +++ b/tools/perf/arch/arm64/tests/arch-tests.c
> @@ -10,6 +10,10 @@ struct test arch_tests[] = {
> .func = test__dwarf_unwind,
> },
> #endif
> + {
> + .desc = "User counter access",
> + .func = test__rd_pmevcntr,
> + },
> {
> .func = NULL,
> },
> diff --git a/tools/perf/arch/arm64/tests/user-events.c b/tools/perf/arch/arm64/tests/user-events.c
> new file mode 100644
> index 000000000000..b048d7e392bc
> --- /dev/null
> +++ b/tools/perf/arch/arm64/tests/user-events.c
> @@ -0,0 +1,254 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <asm/bug.h>
> +#include <errno.h>
> +#include <unistd.h>
> +#include <sched.h>
> +#include <stdlib.h>
> +#include <signal.h>
> +#include <sys/mman.h>
> +#include <sys/sysinfo.h>
> +#include <sys/types.h>
> +#include <sys/wait.h>
> +#include <linux/types.h>
> +#include "perf.h"
> +#include "debug.h"
> +#include "tests/tests.h"
> +#include "cloexec.h"
> +#include "util.h"
> +#include "arch-tests.h"
> +
> +/*
> + * ARMv8 ARM reserves the following encoding for system registers:
> + * (Ref: ARMv8 ARM, Section: "System instruction class encoding overview",
> + * C5.2, version:ARM DDI 0487A.f)
> + * [20-19] : Op0
> + * [18-16] : Op1
> + * [15-12] : CRn
> + * [11-8] : CRm
> + * [7-5] : Op2
> + */
> +#define Op0_shift 19
> +#define Op0_mask 0x3
> +#define Op1_shift 16
> +#define Op1_mask 0x7
> +#define CRn_shift 12
> +#define CRn_mask 0xf
> +#define CRm_shift 8
> +#define CRm_mask 0xf
> +#define Op2_shift 5
> +#define Op2_mask 0x7
> +
> +#define __stringify(x) #x
> +
> +#define read_sysreg(r) ({ \
> + u64 __val; \
> + asm volatile("mrs %0, " __stringify(r) : "=r" (__val)); \
> + __val; \
> +})
> +
> +#define PMEVCNTR_READ_CASE(idx) \
> + case idx: \
> + return read_sysreg(pmevcntr##idx##_el0)
> +
> +#define PMEVCNTR_CASES(readwrite) \
> + PMEVCNTR_READ_CASE(0); \
> + PMEVCNTR_READ_CASE(1); \
> + PMEVCNTR_READ_CASE(2); \
> + PMEVCNTR_READ_CASE(3); \
> + PMEVCNTR_READ_CASE(4); \
> + PMEVCNTR_READ_CASE(5); \
> + PMEVCNTR_READ_CASE(6); \
> + PMEVCNTR_READ_CASE(7); \
> + PMEVCNTR_READ_CASE(8); \
> + PMEVCNTR_READ_CASE(9); \
> + PMEVCNTR_READ_CASE(10); \
> + PMEVCNTR_READ_CASE(11); \
> + PMEVCNTR_READ_CASE(12); \
> + PMEVCNTR_READ_CASE(13); \
> + PMEVCNTR_READ_CASE(14); \
> + PMEVCNTR_READ_CASE(15); \
> + PMEVCNTR_READ_CASE(16); \
> + PMEVCNTR_READ_CASE(17); \
> + PMEVCNTR_READ_CASE(18); \
> + PMEVCNTR_READ_CASE(19); \
> + PMEVCNTR_READ_CASE(20); \
> + PMEVCNTR_READ_CASE(21); \
> + PMEVCNTR_READ_CASE(22); \
> + PMEVCNTR_READ_CASE(23); \
> + PMEVCNTR_READ_CASE(24); \
> + PMEVCNTR_READ_CASE(25); \
> + PMEVCNTR_READ_CASE(26); \
> + PMEVCNTR_READ_CASE(27); \
> + PMEVCNTR_READ_CASE(28); \
> + PMEVCNTR_READ_CASE(29); \
> + PMEVCNTR_READ_CASE(30)
> +
> +/*
> + * Read a value direct from PMEVCNTR<idx>
> + */
> +static u64 read_evcnt_direct(int idx)
> +{
> + switch (idx) {
> + PMEVCNTR_CASES(READ);
> + default:
> + WARN_ON(1);
> + }
> +
> + return 0;
> +}
> +
> +static u64 mmap_read_self(void *addr)
> +{
> + struct perf_event_mmap_page *pc = addr;
> + u32 seq, idx, time_mult = 0, time_shift = 0;
> + u64 count, cyc = 0, time_offset = 0, enabled, running, delta;
> +
> + do {
> + seq = READ_ONCE(pc->lock);
> + barrier();
> +
> + enabled = READ_ONCE(pc->time_enabled);
> + running = READ_ONCE(pc->time_running);
> +
> + if (enabled != running) {
> + cyc = read_sysreg(cntvct_el0);
> + time_mult = READ_ONCE(pc->time_mult);
> + time_shift = READ_ONCE(pc->time_shift);
> + time_offset = READ_ONCE(pc->time_offset);
> + }
> +
> + idx = READ_ONCE(pc->index);
> + count = READ_ONCE(pc->offset);
> + if (idx)
> + count += read_evcnt_direct(idx - 1);
> +
> + barrier();
> + } while (READ_ONCE(pc->lock) != seq);
> +
> + if (enabled != running) {
> + u64 quot, rem;
> +
> + quot = (cyc >> time_shift);
> + rem = cyc & (((u64)1 << time_shift) - 1);
> + delta = time_offset + quot * time_mult +
> + ((rem * time_mult) >> time_shift);
> +
> + enabled += delta;
> + if (idx)
> + running += delta;
> +
> + quot = count / running;
> + rem = count % running;
> + count = quot * enabled + (rem * enabled) / running;
> + }
> +
> + return count;
> +}
> +
> +static int __test__rd_pmevcntr(void)
> +{
> + volatile int tmp = 0;
> + u64 i, loops = 1000;
> + int n;
> + int fd;
> + void *addr;
> + struct perf_event_attr attr = {
> + .type = PERF_TYPE_HARDWARE,
> + .config = PERF_COUNT_HW_INSTRUCTIONS,
> + .exclude_kernel = 1,
> + };
> + u64 delta_sum = 0;
> + char sbuf[STRERR_BUFSIZE];
> +
> + fd = sys_perf_event_open(&attr, 0, -1, -1,
> + perf_event_open_cloexec_flag());
> + if (fd < 0) {
> + pr_err("Error: sys_perf_event_open() syscall returned with %d (%s)\n", fd,
> + str_error_r(errno, sbuf, sizeof(sbuf)));
> + return -1;
> + }
> +
> + addr = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, 0);
> + if (addr == (void *)(-1)) {
> + pr_err("Error: mmap() syscall returned with (%s)\n",
> + str_error_r(errno, sbuf, sizeof(sbuf)));
> + goto out_close;
> + }
> +
> + for (n = 0; n < 6; n++) {
> + u64 stamp, now, delta;
> +
> + stamp = mmap_read_self(addr);
> +
> + for (i = 0; i < loops; i++)
> + tmp++;
> +
> + now = mmap_read_self(addr);
> + loops *= 10;
> +
> + delta = now - stamp;
> + pr_debug("%14d: %14llu\n", n, (long long)delta);
> +
> + delta_sum += delta;
> + }
> +
> + munmap(addr, page_size);
> + pr_debug(" ");
> +
> +out_close:
> + close(fd);
> +
> + if (!delta_sum)
> + return -1;
> +
> + return 0;
> +}
> +
> +int test__rd_pmevcntr(struct test __maybe_unused *test,
> + int __maybe_unused subtest)
> +{
> + int status = 0;
> + int wret = 0;
> + int ret = 0;
> + int pid;
> + int cpu;
> + cpu_set_t cpu_set;
> +
> + pid = fork();
> + if (pid < 0)
> + return -1;
> +
> + if (!pid) {
> + for (cpu = 0; cpu < get_nprocs(); cpu++) {
> + pr_info("setting affinity to cpu: %d\n", cpu);
> + CPU_ZERO(&cpu_set);
> + CPU_SET(cpu, &cpu_set);
> + if (sched_setaffinity(getpid(),
> + sizeof(cpu_set),
> + &cpu_set) == -1) {
> + pr_err("Error: impossible to set cpu (%d) affinity\n",
> + cpu);
> + continue;
> + }
> + ret = __test__rd_pmevcntr();
> + }
> + exit(ret);
> + }
> +
> + wret = waitpid(pid, &status, 0);
> + if (wret < 0)
> + return -1;
> +
> + if (WIFSIGNALED(status)) {
> + pr_err("Error: the child process was interrupted by a signal\n");
> + return -1;
> +
> + if (WIFEXITED(status) && WEXITSTATUS(status)) {
> + pr_err("Error: the child process exited with: %d\n",
> + WEXITSTATUS(status));
> + return -1;
> + }
> +
> + return 0;
> +}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BOOTWRAPPER PATCH] Enable TME for lower exception levels
From: Mark Rutland @ 2019-08-27 11:08 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-arm-kernel
In-Reply-To: <20190823145015.15974-1-will@kernel.org>
On Fri, Aug 23, 2019 at 03:50:15PM +0100, Will Deacon wrote:
> By default, TME is not available to exception levels below EL3, so
> enable it in SCR_EL3 if we detect that it is implemented.
>
> Signed-off-by: Will Deacon <will@kernel.org>
Applied, thanks!
Mark.
> ---
> arch/aarch64/boot.S | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
> index 74705cded338..c2fe92c90297 100644
> --- a/arch/aarch64/boot.S
> +++ b/arch/aarch64/boot.S
> @@ -48,6 +48,13 @@ _start:
> orr x0, x0, #(1 << 16) // AP key enable
> orr x0, x0, #(1 << 17) // AP insn enable
> 1:
> + /* Enable TME if present */
> + mrs x1, id_aa64isar0_el1
> + ubfx x1, x1, #24, #4
> + cbz x1, 1f
> +
> + orr x0, x0, #(1 << 34) // TME enable
> +1:
> #ifndef KERNEL_32
> orr x0, x0, #(1 << 10) // 64-bit EL2
> #endif
> --
> 2.11.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Changing default kernel load address
From: Mark Rutland @ 2019-08-27 11:02 UTC (permalink / raw)
To: Noam Camus; +Cc: linux-arm-kernel
In-Reply-To: <CABhetiwRF2Gq3HeG_QNT6t3GtCNJzedeenn6vQC_0FYr5Ee+mA@mail.gmail.com>
On Mon, Aug 26, 2019 at 08:12:27PM +0300, Noam Camus wrote:
> Hi,
>
> I wish to change an arm64 machine kernel load address and I hope this
> forum can assist.
>
> In my current setup the KERNEL_START macro (_text) equals 128.5MB:
> KIMAGE_VADDR=128MB
> TEXT_OFFSET=512KB
>
> I wish to change kernel load address to reside on my internal RAM
> which locates beyond 4GB.
You shouldn't need to modify anything; the kernel can be loaded at any
2MiB-aligned physical address + TEXT_OFFSET. KERNEL_START and
KIMAGE_VADDR are virtual addresses and don't require a specific physical
address.
Please see:
https://www.kernel.org/doc/html/latest/arm64/booting.html
> Can someone tell what changes I need to do so kernel load address will
> be above 4GB.
>
> Note: I use FIT image to provide U-Boot the kernel Load address.
I don't know how FIT works, but the U-Boot "booti" command should do the
right thing if given an arm64 kernel Image.
Thanks,
Mark.
_______________________________________________
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 v6 2/3] ASoC: sun4i-i2s: Add regmap field to sign extend sample
From: Code Kipper @ 2019-08-27 10:55 UTC (permalink / raw)
To: Maxime Ripard
Cc: Linux-ALSA, linux-sunxi, linux-kernel, Liam Girdwood,
Andrea Venturi (pers), Chen-Yu Tsai, Mark Brown, linux-arm-kernel
In-Reply-To: <20190827093429.fkh4cqbygxxyvkk3@flea>
On Tue, 27 Aug 2019 at 11:34, Maxime Ripard <mripard@kernel.org> wrote:
>
> On Mon, Aug 26, 2019 at 08:07:33PM +0200, codekipper@gmail.com wrote:
> > From: Marcus Cooper <codekipper@gmail.com>
> >
> > On the newer SoCs such as the H3 and A64 this is set by default
> > to transfer a 0 after each sample in each slot. However the A10
> > and A20 SoCs that this driver was developed on had a default
> > setting where it padded the audio gain with zeros.
> >
> > This isn't a problem whilst we have only support for 16bit audio
> > but with larger sample resolution rates in the pipeline then SEXT
> > bits should be cleared so that they also pad at the LSB. Without
> > this the audio gets distorted.
> >
> > Signed-off-by: Marcus Cooper <codekipper@gmail.com>
>
> If anything, I'd like to have less regmap_fields rather than more of
> them. This is pretty easy to add to one of the callbacks, especially
> since the field itself has been completely reworked from one
> generation to the other.
>
ACK
That's fine....I've been doing that with the patches which follow this.
CK
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
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/8] coresight: etm4x: Add missing API to set EL match on address filters
From: Mike Leach @ 2019-08-27 10:55 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: Coresight ML, linux-arm-kernel, Suzuki K. Poulose
In-Reply-To: <20190826225949.GC24690@xps15>
Hi Mathieu,
On Mon, 26 Aug 2019 at 23:59, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> On Mon, Aug 19, 2019 at 09:57:15PM +0100, Mike Leach wrote:
> > TRCACATRn registers have match bits for secure and non-secure exception
> > levels which are not accessible by the sysfs API.
> > This adds a new sysfs parameter to enable this - addr_exlevel_s_ns.
> >
> > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > ---
> > .../coresight/coresight-etm4x-sysfs.c | 39 +++++++++++++++++++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index fa1d6a938f6c..7eab5d7d0b62 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -1233,6 +1233,44 @@ static ssize_t addr_context_store(struct device *dev,
> > }
> > static DEVICE_ATTR_RW(addr_context);
> >
> > +static ssize_t addr_exlevel_s_ns_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->addr_idx;
> > + val = BMVAL(config->addr_acc[idx], 14, 8);
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->addr_idx;
> > + /* clear Exlevel_ns & Exlevel_s bits[14:12, 11:8] */
> > + config->addr_acc[idx] &= ~(GENMASK(14, 8));
> > + config->addr_acc[idx] |= (val << 8);
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(addr_exlevel_s_ns);
> > +
> > static ssize_t seq_idx_show(struct device *dev,
> > struct device_attribute *attr,
> > char *buf)
> > @@ -2038,6 +2076,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> > &dev_attr_addr_stop.attr,
> > &dev_attr_addr_ctxtype.attr,
> > &dev_attr_addr_context.attr,
> > + &dev_attr_addr_exlevel_s_ns.attr,
> > &dev_attr_seq_idx.attr,
> > &dev_attr_seq_state.attr,
> > &dev_attr_seq_event.attr,
>
> I'm ok with this patch but the new entry needs to be documented in [1].
It is in a later patch.
> But
> before moving forward with that I'm wondering if this is the way to go. Would
> it be better to consolidate type, ctxtype, context and exlevel_s_ns in a single
> entry, say addr_acc_type? We'd shed a fair amount of code and make it more
> simple for users to configure.
>
It will mean the user has less writes to do - but is it really simpler
to understand?
At present each feature takes the input value and interprets / shifts
it to set the relevant bits in the address comparator control
registers (context type being a string input rather than bit values).
The alternative is to require the user to understand the bit values -
which they may well do if they are referring to the ETM docs to
program in this detail, and provide a correct input value for their
requirements.
My addition adds to the API, rather than changes it, but if you prefer
we could go with an update to a single feature to control this value
in the comparator control registers.
Mike
>
> [1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
>
> > --
> > 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: Applied "ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs" to the asoc tree
From: Mark Brown @ 2019-08-27 10:46 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Linux-ALSA, Maxime Ripard, linux-kernel, Maxime Ripard,
Liam Girdwood, Marcus Cooper, linux-arm-kernel
In-Reply-To: <CAGb2v64vzcZbXqfW27cgobpQ-AXQjb2zanqotAR0ezw+6KCdpw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 809 bytes --]
On Tue, Aug 27, 2019 at 05:25:21PM +0800, Chen-Yu Tsai wrote:
> > From: Marcus Cooper <codekipper@gmail.com>
> The authorship of this patch looks to be wrong. Maybe it's a tooling issue.
> I imagine it might have happened if Maxime created the patches using
> `git format-patch` with his @bootlin.com address, then sent them with his
> @kernel.org address, and `git send-email` swapped out the "From:" header
> and prepended it to the body.
No idea. In any case it's kind of hard to fix at this point
since there's a merge in the way. This is why I like using
branches for things but Linus doesn't :/
> Either way the "From:" line looks odd in the commit log.
This is what git format-patch does when sending stuff via e-mail
if the author is different from the sender, it uses that to
override things.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] Revert "ASoC: sun4i-i2s: Remove duplicated quirks structure"
From: Mark Brown @ 2019-08-27 10:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: alsa-devel, lgirdwood, linux-kernel, codekipper, Chen-Yu Tsai,
linux-arm-kernel
In-Reply-To: <20190827093206.17919-1-mripard@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 547 bytes --]
On Tue, Aug 27, 2019 at 11:32:05AM +0200, Maxime Ripard wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> This reverts commit 3e9acd7ac6933cdc20c441bbf9a38ed9e42e1490.
>
> It turns out that while one I2S controller is described in the A83t
> datasheet, the driver supports another, undocumented, one that has been
> inherited from the older SoCs, while the documented one uses the new
> design.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] fdt: Update CRC check for rng-seed
From: Hsin-Yi Wang @ 2019-08-27 10:33 UTC (permalink / raw)
To: Will Deacon, linux-arm-kernel, Geert Uytterhoeven
Commit 428826f5358c ("fdt: add support for rng-seed") moves of_fdt_crc32
from early_init_dt_verify() to early_init_dt_scan() since
early_init_dt_scan_chosen() may modify fdt to erase rng-seed.
However, arm and some other arch won't call early_init_dt_scan(), they
call early_init_dt_verify() then early_init_dt_scan_nodes().
Restore of_fdt_crc32 to early_init_dt_verify() then update it in
early_init_dt_scan_chosen() if fdt if updated.
Fixes: 428826f5358c ("fdt: add support for rng-seed")
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
drivers/of/fdt.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 7d97ab6d0e31..223d617ecfe1 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1086,6 +1086,10 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
/* try to clear seed so it won't be found. */
fdt_nop_property(initial_boot_params, node, "rng-seed");
+
+ /* update CRC check value */
+ of_fdt_crc32 = crc32_be(~0, initial_boot_params,
+ fdt_totalsize(initial_boot_params));
}
/* break now */
@@ -1176,6 +1180,8 @@ bool __init early_init_dt_verify(void *params)
/* Setup flat device-tree pointer */
initial_boot_params = params;
+ of_fdt_crc32 = crc32_be(~0, initial_boot_params,
+ fdt_totalsize(initial_boot_params));
return true;
}
@@ -1205,8 +1211,6 @@ bool __init early_init_dt_scan(void *params)
return false;
early_init_dt_scan_nodes();
- of_fdt_crc32 = crc32_be(~0, initial_boot_params,
- fdt_totalsize(initial_boot_params));
return true;
}
--
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: [linux-sunxi] [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
From: Chen-Yu Tsai @ 2019-08-27 10:28 UTC (permalink / raw)
To: Code Kipper
Cc: Linux-ALSA, linux-kernel, Maxime Ripard, Liam Girdwood,
Andrea Venturi (pers), linux-sunxi, Mark Brown, linux-arm-kernel
In-Reply-To: <CAEKpxBn3g2hFaei6thAnAHX4nemrs9c_xWp1GheMfMS6+TJ7gQ@mail.gmail.com>
On Tue, Aug 27, 2019 at 4:35 PM Code Kipper <codekipper@gmail.com> wrote:
>
> On Tue, 27 Aug 2019 at 10:01, Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > On Tue, Aug 27, 2019 at 1:55 PM Code Kipper <codekipper@gmail.com> wrote:
> > >
> > > On Tue, 27 Aug 2019 at 06:13, Chen-Yu Tsai <wens@csie.org> wrote:
> > > >
> > > > On Tue, Aug 27, 2019 at 2:07 AM <codekipper@gmail.com> wrote:
> > > > >
> > > > > From: Marcus Cooper <codekipper@gmail.com>
> > > > >
> > > > > The regmap configuration is set up for the legacy block on the
> > > > > A83T whereas it uses the new block with a larger register map.
> > > >
> > > > Looking at the code Allwinner previously released [1], that doesn't seem to be
> > > > the case. Keep in mind that the register map shown in the user manual is for
> > > > the TDM interface, which we don't actually support right now.
> > >
> > > Should it matter what we support right now?, the block according to the user
> > > manual shows the bigger range. I don't have a A83T device and from what I
> >
> > There are a total of four I2S controllers on the A83T. Currently three of them
> > are listed in the dtsi file, which are _not_ the one shown in the user manual.
> > The one shown is the fourth one, which is the TDM controller.
>
> The configuration for the A83T suggests that it's a mixture of old and
> new which I don't
> think is the case considering it was released around the same time as
> the H3. There
> is enough similarity between the blocks for it to still work. For
> example on the H6
> we referenced by mistake the H3 block and we still got audio (with
> only slight distortion).
The difference with the A83T here is large enough that if you play anything
it will simply stall. I already reported it as broken and Maxime has sent
fixes.
> I would suggest to validate all of the i2s blocks we need to test
> using the internal loopback
> as that will also cover capture.
>
> >
> > It's not like we haven't seen this before. IIRC the A64 also had two variants
> > of the I2S interface. The one coupled with the audio codec was different from
> > the others.
>
> Yes...but the i2s of the audio codec was documented in the audio codec
> section. I've used
> this device to ensure that I've not broken anything in the old block
> with these new changes.
>
> >
> > > gather not many users do. But the compatible for the H3 has been removed
> > > and replaced with the settings for the A83T which also has default settings in
> > > registers further up than SUNXI_RXCHMAP.
> >
> > I'll sync up with Maxime on this.
> >
> > > >
> > > > The file shows the base address as 0x01c22800, and the last defined register
> > > > is SUNXI_RXCHMAP at 0x3c.
> > > >
> > > > The I2S driver [2] also shows that it is the old register map size, but with
> > > > TX_FIFO and INT_STA swapped around. This might mean that it would need a
> > > > separate regmap_config, as the read/write callbacks need to be changed to
> > > > fit the swapped registers.
> > > >
> > > > Finally, the TDM driver [3], which matches the TDM section in the manual, shows
> > > > a larger register map.
> > > >
> > > > A83T is SUN8IW6, while SUN8IW7 refers to the H3.
> > >
> > > Since when have we trusted Allwinner code?, the TDM labelled block
> > > clearly supports
> >
> > Since they haven't listed the I2S block in the user manual, so that is what we
> > have to go by.
> >
> > The TDM section in the user manual only lists the block at 0x1c23000. The memory
> > map says DAUDIO-[012] for addresses 0x1c22000, 0x1c22400, 0x1c22800, and TDM for
> > address 0x1c23000. One would assume this meant these are somewhat different.
> >
> > > I2S. The biggest use case for this block is getting HDMI audio working
> > > on the newer
> >
> > I understand that.
> >
> > > devices(LibreELEC nightlies has a user base of over 300) and I've tested this on
> > > numerous set ups over the last couple of years.
> >
> > Tested on the H3, correct?
>
> Yes....but only with the additional changes for multi-channel with my
> LibreELEC build.
> These changes I tested on my pine64 before pushing upstream.
>
> >
> > > Failing that reverting (3e9acd7ac693: "ASoC: sun4i-i2s: Remove
> > > duplicated quirks structure")
> > > would help.
> >
> > I'll take a look. IIRC it worked with the old layout, with the two registers
> > swapped, playing standard 48 KHz / 16 bit audio when I added supported for
> > the A83T. Then again maybe the stars were perfectly aligned. At the very least
> > we could separate A83T and H3 as you suggested.
Maxime has sent a patch reverting the merger.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Matthias Brugger @ 2019-08-27 10:13 UTC (permalink / raw)
To: Bibby Hsieh
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
linux-arm-kernel, ginny.chen
In-Reply-To: <1566878368.29523.1.camel@mtksdaap41>
On 27/08/2019 05:59, Bibby Hsieh wrote:
> On Fri, 2019-08-23 at 16:21 +0200, Matthias Brugger wrote:
>>
>> On 20/08/2019 10:49, Bibby Hsieh wrote:
>>> GCE cannot know the register base address, this function
>>> can help cmdq client to get the cmdq_client_reg structure.
>>>
>>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>>> ---
>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++++++++++++++++++++++++++
>>> include/linux/soc/mediatek/mtk-cmdq.h | 21 +++++++++++++++++++
>>> 2 files changed, 50 insertions(+)
>>>
>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> index c53f8476c68d..80f75a1075b4 100644
>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> @@ -27,6 +27,35 @@ struct cmdq_instruction {
>>> u8 op;
>>> };
>>>
>>> +int cmdq_dev_get_client_reg(struct device *dev,
>>> + struct cmdq_client_reg *client_reg, int idx)
>>> +{
>>
>> Can't we do/call this in cmdq_mbox_create parsing the number of gce-client-reg
>> properties we have and allocating these using a pointer to cmdq_client_reg in
>> cmdq_client?
>> We will have to free the pointer then in cmdq_mbox_destroy.
>>
>> Regards,
>> Matthias
>
> I don't think we need to keep the cmdq_client_reg in cmdq_client
> structure.
> Because our client will have own data structure, they will copy the
> client_reg information into their own structure.
>
> In the design now, we do not allocate the cmdq_client_reg, client pass
> the cmdq_client_reg pointer into this API.
> Client will destroy the pointer after they get the information they
> want.
>
My point wasn't so much about the lifecycle of the object, but the fact that we
add another call, which can be already full-filled by a necessary previous call
to cmdq_mbox_create. So I would prefer to add the information gathering for
cmdq_client_reg in this call, and let it live there for the time cmdq_client
lives. In the end we are talking about 40 bits of memory.
Regards,
Matthias
> Thanks for the comments so much.
>
> Bibby
>
>>
>>> + struct of_phandle_args spec;
>>> + int err;
>>> +
>>> + if (!client_reg)
>>> + return -ENOENT;
>>> +
>>> + err = of_parse_phandle_with_fixed_args(dev->of_node,
>>> + "mediatek,gce-client-reg",
>>> + 3, idx, &spec);
>>> + if (err < 0) {
>>> + dev_err(dev,
>>> + "error %d can't parse gce-client-reg property (%d)",
>>> + err, idx);
>>> +
>>> + return err;
>>> + }
>>> +
>>> + client_reg->subsys = (u8)spec.args[0];
>>> + client_reg->offset = (u16)spec.args[1];
>>> + client_reg->size = (u16)spec.args[2];
>>> + of_node_put(spec.np);
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
>>> +
>>> static void cmdq_client_timeout(struct timer_list *t)
>>> {
>>> struct cmdq_client *client = from_timer(client, t, timer);
>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>>> index a345870a6d10..02ddd60b212f 100644
>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>> @@ -15,6 +15,12 @@
>>>
>>> struct cmdq_pkt;
>>>
>>> +struct cmdq_client_reg {
>>> + u8 subsys;
>>> + u16 offset;
>>> + u16 size;
>>> +};
>>> +
>>> struct cmdq_client {
>>> spinlock_t lock;
>>> u32 pkt_cnt;
>>> @@ -24,6 +30,21 @@ struct cmdq_client {
>>> u32 timeout_ms; /* in unit of microsecond */
>>> };
>>>
>>> +/**
>>> + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
>>> + * node of CMDQ client
>>> + * @dev: device of CMDQ mailbox client
>>> + * @client_reg: CMDQ client reg pointer
>>> + * @idx: the index of desired reg
>>> + *
>>> + * Return: 0 for success; else the error code is returned
>>> + *
>>> + * Help CMDQ client parsing the cmdq client reg
>>> + * from the device node of CMDQ client.
>>> + */
>>> +int cmdq_dev_get_client_reg(struct device *dev,
>>> + struct cmdq_client_reg *client_reg, int idx);
>>> +
>>> /**
>>> * cmdq_mbox_create() - create CMDQ mailbox client and channel
>>> * @dev: device of CMDQ mailbox client
>>>
>
>
_______________________________________________
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