* [PATCH 3/3] ASoC: mchp-i2s-mcc: Fix simultaneous capture and playback in master mode
From: Codrin Ciubotariu @ 2019-08-20 16:24 UTC (permalink / raw)
To: alsa-devel, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, tiwai, ludovic.desroches, broonie,
Codrin Ciubotariu, perex
In-Reply-To: <20190820162411.24836-1-codrin.ciubotariu@microchip.com>
This controller supports capture and playback running at the same time,
with the limitation that both capture and playback must be configured the
same way (sample rate, sample format, number of channels, etc). For this,
we have to assure that the configuration registers look the same when
capture and playback are initiated.
This patch fixes a bug in which the controller is in master mode and the
hw_params() callback fails for the second audio stream. The fail occurs
because the divisors are calculated after comparing the configuration
registers for capture and playback. The fix consists in calculating the
divisors before comparing the configuration registers. BCLK and LRC are
then configured and started only if the controller is not already running.
Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
sound/soc/atmel/mchp-i2s-mcc.c | 70 ++++++++++++++++++----------------
1 file changed, 37 insertions(+), 33 deletions(-)
diff --git a/sound/soc/atmel/mchp-i2s-mcc.c b/sound/soc/atmel/mchp-i2s-mcc.c
index ab7d5f98e759..befc2a3a05b0 100644
--- a/sound/soc/atmel/mchp-i2s-mcc.c
+++ b/sound/soc/atmel/mchp-i2s-mcc.c
@@ -392,11 +392,11 @@ static int mchp_i2s_mcc_clk_get_rate_diff(struct clk *clk,
}
static int mchp_i2s_mcc_config_divs(struct mchp_i2s_mcc_dev *dev,
- unsigned int bclk, unsigned int *mra)
+ unsigned int bclk, unsigned int *mra,
+ unsigned long *best_rate)
{
unsigned long clk_rate;
unsigned long lcm_rate;
- unsigned long best_rate = 0;
unsigned long best_diff_rate = ~0;
unsigned int sysclk;
struct clk *best_clk = NULL;
@@ -423,7 +423,7 @@ static int mchp_i2s_mcc_config_divs(struct mchp_i2s_mcc_dev *dev,
(clk_rate == bclk || clk_rate / (bclk * 2) <= GENMASK(5, 0));
clk_rate += lcm_rate) {
ret = mchp_i2s_mcc_clk_get_rate_diff(dev->gclk, clk_rate,
- &best_clk, &best_rate,
+ &best_clk, best_rate,
&best_diff_rate);
if (ret) {
dev_err(dev->dev, "gclk error for rate %lu: %d",
@@ -437,7 +437,7 @@ static int mchp_i2s_mcc_config_divs(struct mchp_i2s_mcc_dev *dev,
}
ret = mchp_i2s_mcc_clk_get_rate_diff(dev->pclk, clk_rate,
- &best_clk, &best_rate,
+ &best_clk, best_rate,
&best_diff_rate);
if (ret) {
dev_err(dev->dev, "pclk error for rate %lu: %d",
@@ -459,33 +459,17 @@ static int mchp_i2s_mcc_config_divs(struct mchp_i2s_mcc_dev *dev,
dev_dbg(dev->dev, "source CLK is %s with rate %lu, diff %lu\n",
best_clk == dev->pclk ? "pclk" : "gclk",
- best_rate, best_diff_rate);
-
- /* set the rate */
- ret = clk_set_rate(best_clk, best_rate);
- if (ret) {
- dev_err(dev->dev, "unable to set rate %lu to %s: %d\n",
- best_rate, best_clk == dev->pclk ? "PCLK" : "GCLK",
- ret);
- return ret;
- }
+ *best_rate, best_diff_rate);
/* Configure divisors */
if (dev->sysclk)
- *mra |= MCHP_I2SMCC_MRA_IMCKDIV(best_rate / (2 * sysclk));
- *mra |= MCHP_I2SMCC_MRA_ISCKDIV(best_rate / (2 * bclk));
+ *mra |= MCHP_I2SMCC_MRA_IMCKDIV(*best_rate / (2 * sysclk));
+ *mra |= MCHP_I2SMCC_MRA_ISCKDIV(*best_rate / (2 * bclk));
- if (best_clk == dev->gclk) {
+ if (best_clk == dev->gclk)
*mra |= MCHP_I2SMCC_MRA_SRCCLK_GCLK;
- ret = clk_prepare(dev->gclk);
- if (ret < 0)
- dev_err(dev->dev, "unable to prepare GCLK: %d\n", ret);
- else
- dev->gclk_use = 1;
- } else {
+ else
*mra |= MCHP_I2SMCC_MRA_SRCCLK_PCLK;
- dev->gclk_use = 0;
- }
return 0;
}
@@ -502,6 +486,7 @@ static int mchp_i2s_mcc_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
{
+ unsigned long rate = 0;
struct mchp_i2s_mcc_dev *dev = snd_soc_dai_get_drvdata(dai);
u32 mra = 0;
u32 mrb = 0;
@@ -640,6 +625,17 @@ static int mchp_i2s_mcc_hw_params(struct snd_pcm_substream *substream,
return -EINVAL;
}
+ if (set_divs) {
+ bclk_rate = frame_length * params_rate(params);
+ ret = mchp_i2s_mcc_config_divs(dev, bclk_rate, &mra,
+ &rate);
+ if (ret) {
+ dev_err(dev->dev,
+ "unable to configure the divisors: %d\n", ret);
+ return ret;
+ }
+ }
+
/*
* If we are already running, the wanted setup must be
* the same with the one that's currently ongoing
@@ -656,19 +652,27 @@ static int mchp_i2s_mcc_hw_params(struct snd_pcm_substream *substream,
return 0;
}
- /* Save the number of channels to know what interrupts to enable */
- dev->channels = channels;
-
- if (set_divs) {
- bclk_rate = frame_length * params_rate(params);
- ret = mchp_i2s_mcc_config_divs(dev, bclk_rate, &mra);
+ if (mra & MCHP_I2SMCC_MRA_SRCCLK_GCLK && !dev->gclk_use) {
+ /* set the rate */
+ ret = clk_set_rate(dev->gclk, rate);
if (ret) {
- dev_err(dev->dev, "unable to configure the divisors: %d\n",
- ret);
+ dev_err(dev->dev,
+ "unable to set rate %lu to GCLK: %d\n",
+ rate, ret);
+ return ret;
+ }
+
+ ret = clk_prepare(dev->gclk);
+ if (ret < 0) {
+ dev_err(dev->dev, "unable to prepare GCLK: %d\n", ret);
return ret;
}
+ dev->gclk_use = 1;
}
+ /* Save the number of channels to know what interrupts to enable */
+ dev->channels = channels;
+
ret = regmap_write(dev->regmap, MCHP_I2SMCC_MRA, mra);
if (ret < 0) {
if (dev->gclk_use) {
--
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/2] dt-bindings: arm: imx: add imx8mq nitrogen support
From: Dafna Hirschfeld @ 2019-08-20 16:27 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Ezequiel Garcia, Sascha Hauer,
linux-kernel@vger.kernel.org, Troy Kisky, Gary Bisson,
Sascha Hauer, kernel, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJx6pTw7Pr=7f0jkC81JF+EDkyhHrvFehSWZV=0wy+YXQ@mail.gmail.com>
On Mon, 2019-08-19 at 14:08 -0500, Rob Herring wrote:
> On Mon, Aug 19, 2019 at 12:26 PM Dafna Hirschfeld
> <dafna.hirschfeld@collabora.com> wrote:
> > From: Gary Bisson <gary.bisson@boundarydevices.com>
> >
> > The Nitrogen8M is an ARM based single board computer (SBC)
> > designed to leverage the full capabilities of NXP’s i.MX8M
> > Quad processor.
> >
> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> > Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> > [Dafna: porting vendor's code to mainline]
> > Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
> > ---
> > Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> > 1 file changed, 1 insertion(+)
>
> Please add acks/reviewed-bys when posting new versions.
>
Hi,
Thank you for the remark, I forgot to add it. I will add it in the
next.
Regards,
Dafna Hirschfeld
> Rob
_______________________________________________
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/6] dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
From: Ondřej Jirman @ 2019-08-20 16:34 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Alexandre Torgue, netdev,
linux-kernel@vger.kernel.org, Maxime Ripard, linux-stm32,
Chen-Yu Tsai, Jose Abreu, Maxime Coquelin, Giuseppe Cavallaro,
David S. Miller,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqLHeA6A_+ZgmCzC42Y6yJrEq6+D3vKn8ETh2D7LJ+1_-g@mail.gmail.com>
On Tue, Aug 20, 2019 at 11:20:22AM -0500, Rob Herring wrote:
> On Tue, Aug 20, 2019 at 9:53 AM <megous@megous.com> wrote:
> >
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Some PHYs require separate power supply for I/O pins in some modes
> > of operation. Add phy-io-supply property, to allow enabling this
> > power supply.
>
> Perhaps since this is new, such phys should have *-supply in their nodes.
Yes, I just don't understand, since external ethernet phys are so common,
and they require power, how there's no fairly generic mechanism for this
already in the PHY subsystem, or somewhere?
It looks like other ethernet mac drivers also implement supplies on phys
on the EMAC nodes. Just grep phy-supply through dt-bindings/net.
Historical reasons, or am I missing something? It almost seems like I must
be missing something, since putting these properties to phy nodes
seems so obvious.
thank you and regards,
Ondrej
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
_______________________________________________
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/6] arm64: Introduce config for S32
From: Stefan-gabriel Mirea @ 2019-08-20 16:38 UTC (permalink / raw)
To: Shawn Guo
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,
will@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819081457.GH5999@X250>
Hello Shawn,
On 8/19/2019 11:15 AM, Shawn Guo wrote:
> On Fri, Aug 09, 2019 at 11:29:10AM +0000, Stefan-gabriel Mirea wrote:
>> +config ARCH_S32
>> + bool "Freescale S32 SoC Family"
>
> So you still want to use 'Freescale' than 'NXP' here?
>
>> + help
>> + This enables support for the Freescale S32 family of processors.
Thanks; I will replace Freescale with NXP wherever possible in the next
version.
Regards,
Stefan
_______________________________________________
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 3/6] arm64: dts: fsl: Add device tree for S32V234-EVB
From: Stefan-gabriel Mirea @ 2019-08-20 16:38 UTC (permalink / raw)
To: Shawn Guo
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, Dan Nica,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
will@kernel.org, linux-arm-kernel@lists.infradead.org,
Larisa Ileana Grigore
In-Reply-To: <20190819085816.GI5999@X250>
Hello Shawn,
Thank you for your suggestions!
On 8/19/2019 11:58 AM, Shawn Guo wrote:
> On Fri, Aug 09, 2019 at 11:29:12AM +0000, Stefan-gabriel Mirea wrote:
>> .../boot/dts/freescale/fsl-s32v234-evb.dts | 24 ++++
>
> The 'fsl-' prefix can be saved here, so that we can distinguish three
> families by starting string: imx??? for i.MX, fsl-??? for LayerScape,
> and s32??? for S32.
All right, I will remove the prefixes.
>> + model = "Freescale S32V234";
>
> The 'model' is usually used in board level DTS to describe the board.
I will delete the 'model' property from fsl-s32v234.dtsi and add a
suitable one in fsl-s32v234-evb.dts.
>> + };
>
> Please have a newline between nodes.
>
>> + cpu1: cpu@1 {
I've got it.
>> + interrupts = <0 59 1>;
>
> Please use GIC_SPI and IRQ_TYPE_xxx defines to make it more readable.
I will use GIC_SPI/GIC_PPI and IRQ_TYPE_xxx/GIC_CPU_MASK_xxx where
applicable.
>> +
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <1 13 0xf08>,
>> + <1 14 0xf08>,
>> + <1 11 0xf08>,
>> + <1 10 0xf08>;
>> + /* clock-frequency might be modified by u-boot, depending on the
>> + * chip version.
>> + */
>> + clock-frequency = <10000000>;
>> + };
>> +
>> + gic: interrupt-controller@7d001000 {
>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>> + #interrupt-cells = <3>;
>> + #address-cells = <0>;
>> + interrupt-controller;
>> + reg = <0 0x7d001000 0 0x1000>,
>> + <0 0x7d002000 0 0x2000>,
>> + <0 0x7d004000 0 0x2000>,
>> + <0 0x7d006000 0 0x2000>;
>> + interrupts = <1 9 0xf04>;
>> + };
>
> We usually put these core platform devices prior to 'soc' node.
Sure, I will move the 'timer' and 'interrupt-controller' nodes right
before 'soc'.
Regards,
Stefan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC] dt-bindings: regulator: define a mux regulator
From: Rob Herring @ 2019-08-20 16:39 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mark Rutland, devicetree, Liam Girdwood,
linux-kernel@vger.kernel.org, Mark Brown, Sascha Hauer,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190820152511.15307-1-u.kleine-koenig@pengutronix.de>
On Tue, Aug 20, 2019 at 10:25 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> A mux regulator is used to provide current on one of several outputs. It
> might look as follows:
>
> ,------------.
> --<OUT0 A0 <--
> --<OUT1 A1 <--
> --<OUT2 A2 <--
> --<OUT3 |
> --<OUT4 EN <--
> --<OUT5 |
> --<OUT6 IN <--
> --<OUT7 |
> `------------'
>
> Depending on which address is encoded on the three address inputs A0, A1
> and A2 the current provided on IN is provided on one of the eight
> outputs.
>
> What is new here is that the binding makes use of a #regulator-cells
> property. This uses the approach known from other bindings (e.g. gpio)
> to allow referencing all eight outputs with phandle arguments. This
> requires an extention in of_get_regulator to use a new variant of
> of_parse_phandle_with_args that has a cell_count_default parameter that
> is used in absence of a $cell_name property. Even if we'd choose to
> update all regulator-bindings to add #regulator-cells = <0>; we still
> needed something to implement compatibility to the currently defined
> bindings.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> the obvious alternative is to add (here) eight subnodes to represent the
> eight outputs. This is IMHO less pretty, but wouldn't need to introduce
> #regulator-cells.
I'm okay with #regulator-cells approach.
>
> Apart from reg = <..> and a phandle there is (I think) nothing that
> needs to be specified in the subnodes because all properties of an
> output (apart from the address) apply to all outputs.
>
> What do you think?
>
> Best regards
> Uwe
>
> .../bindings/regulator/mux-regulator.yaml | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mux-regulator.yaml
>
> diff --git a/Documentation/devicetree/bindings/regulator/mux-regulator.yaml b/Documentation/devicetree/bindings/regulator/mux-regulator.yaml
> new file mode 100644
> index 000000000000..f06dbb969090
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mux-regulator.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: GPL-2.0
(GPL-2.0-only OR BSD-2-Clause) is preferred.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mux-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MUX regulators
> +
> +properties:
> + compatible:
> + const: XXX,adb708
? I assume you will split this into a common and specific schemas. I
suppose there could be differing ways to control the mux just like all
other muxes.
> +
> + enable-gpios:
> + maxItems: 1
> +
> + address-gpios:
> + description: Array of typically three GPIO pins used to select the
> + regulator's output. The least significant address GPIO must be listed
> + first. The others follow in order of significance.
> + minItems: 1
> +
> + "#regulator-cells":
How is this not required?
> + const: 1
> +
> + regulator-name:
> + description: A string used to construct the sub regulator's names
> + $ref: "/schemas/types.yaml#/definitions/string"
> +
> + supply:
> + description: input supply
> +
> +required:
> + - compatible
> + - regulator-name
> + - supply
> +
> +
> +examples:
> + - |
> + mux-regulator {
> + compatible = "regulator-mux";
> +
> + regulator-name = "blafasel";
> +
> + supply = <&muxin_regulator>;
> +
> + enable-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> + address-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>,
> + <&gpio2 3 GPIO_ACTIVE_HIGH>,
> + <&gpio2 4 GPIO_ACTIVE_HIGH>,
> + };
> +...
> --
> 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 2/8] soc: ti: add initial PRM driver with reset control support
From: Suman Anna @ 2019-08-20 16:47 UTC (permalink / raw)
To: Tero Kristo, Keerthy, ssantosh, linux-arm-kernel, linux-omap,
robh+dt, Philipp Zabel
Cc: tony, devicetree
In-Reply-To: <0f335aec-bfdf-345a-8dfb-dad70aef1af6@ti.com>
On 8/20/19 2:37 AM, Tero Kristo wrote:
> On 20.8.2019 2.01, Suman Anna wrote:
>> Hi Tero,
>>
>> On 8/19/19 4:32 AM, Tero Kristo wrote:
>>> On 08/08/2019 08:26, Keerthy wrote:
>>>>
>>>>
>>>> On 07/08/19 1:18 PM, Tero Kristo wrote:
>>>>> Add initial PRM (Power and Reset Management) driver for TI OMAP class
>>>>> SoCs. Initially this driver only supports reset control, but can be
>>>>> extended to support rest of the functionality, like powerdomain
>>>>> control, PRCM irq support etc.
>>>>>
>>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>>> ---
>>>>> arch/arm/mach-omap2/Kconfig | 1 +
>>>>> drivers/soc/ti/Makefile | 1 +
>>>>> drivers/soc/ti/omap_prm.c | 216
>>>>> ++++++++++++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 218 insertions(+)
>>>>> create mode 100644 drivers/soc/ti/omap_prm.c
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>>>>> index fdb6743..42ad063 100644
>>>>> --- a/arch/arm/mach-omap2/Kconfig
>>>>> +++ b/arch/arm/mach-omap2/Kconfig
>>>>> @@ -109,6 +109,7 @@ config ARCH_OMAP2PLUS
>>>>> select TI_SYSC
>>>>> select OMAP_IRQCHIP
>>>>> select CLKSRC_TI_32K
>>>>> + select RESET_CONTROLLER
>>
>> Use ARCH_HAS_RESET_CONTROLLER instead.
>
> Ok.
>
>>
>>>>> help
>>>>> Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
>>>>> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
>>>>> index b3868d3..788b5cd 100644
>>>>> --- a/drivers/soc/ti/Makefile
>>>>> +++ b/drivers/soc/ti/Makefile
>>>>> @@ -6,6 +6,7 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) +=
>>>>> knav_qmss.o
>>>>> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
>>>>> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
>>>>> obj-$(CONFIG_AMX3_PM) += pm33xx.o
>>>>> +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_prm.o
>>>>> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
>>>>> obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
>>>>> obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
>>>>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>>>>> new file mode 100644
>>>>> index 0000000..7c89eb8
>>>>> --- /dev/null
>>>>> +++ b/drivers/soc/ti/omap_prm.c
>>>>> @@ -0,0 +1,216 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +/*
>>>>> + * OMAP2+ PRM driver
>>>>> + *
>>>>> + * Copyright (C) 2019 Texas Instruments Incorporated -
>>>>> http://www.ti.com/
>>>>> + * Tero Kristo <t-kristo@ti.com>
>>>>> + */
>>>>> +
>>>>> +#include <linux/kernel.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/device.h>
>>>>> +#include <linux/io.h>
>>>>> +#include <linux/of.h>
>>>>> +#include <linux/of_device.h>
>>>>> +#include <linux/platform_device.h>
>>>>> +#include <linux/reset-controller.h>
>>>>> +#include <linux/delay.h>
>>>>> +
>>>>> +struct omap_rst_map {
>>>>> + s8 rst;
>>>>> + s8 st;
>>>>> +};
>>>>> +
>>>>> +struct omap_prm_data {
>>>>> + u32 base;
>>>>> + const char *name;
>>>>> + u16 pwstctrl;
>>>>> + u16 pwstst;
>>>>> + u16 rstctl;
>>
>> Minor nit, can you use rstctrl instead here so that it is in sync with
>> the other variables and with the register names used in TRM.
>
> Ok.
>
>>
>>>>> + u16 rstst;
>>>>> + struct omap_rst_map *rstmap;
>>>>> + u8 flags;
>>>>> +};
>>>>> +
>>>>> +struct omap_prm {
>>>>> + const struct omap_prm_data *data;
>>>>> + void __iomem *base;
>>>>> +};
>>>>> +
>>>>> +struct omap_reset_data {
>>>>> + struct reset_controller_dev rcdev;
>>>>> + struct omap_prm *prm;
>>>>> +};
>>>>> +
>>>>> +#define to_omap_reset_data(p) container_of((p), struct
>>>>> omap_reset_data, rcdev)
>>>>> +
>>>>> +#define OMAP_MAX_RESETS 8
>>>>> +#define OMAP_RESET_MAX_WAIT 10000
>>>>> +
>>>>> +#define OMAP_PRM_NO_RSTST BIT(0)
>>>>> +
>>>>> +static const struct of_device_id omap_prm_id_table[] = {
>>>>> + { },
>>>>> +};
>>>>
>>>> This table is blank and we are doing of_match_device against it.
>>>
>>> Yes, it gets populated with other patches in series, one entry per soc.
>>>
>>>>
>>>>> +
>>>>> +static int omap_reset_status(struct reset_controller_dev *rcdev,
>>>>> + unsigned long id)
>>>>> +{
>>>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>>>> + u32 v;
>>>>> +
>>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>>>>> + v &= 1 << id;
>>>>> + v >>= id;
>>>>> +
>>>>> + return v;
>>>>> +}
>>>>> +
>>>>> +static int omap_reset_assert(struct reset_controller_dev *rcdev,
>>>>> + unsigned long id)
>>>>> +{
>>>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>>>> + u32 v;
>>>>> +
>>>>> + /* assert the reset control line */
>>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>>>> + v |= 1 << id;
>>>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static int omap_reset_get_st_bit(struct omap_reset_data *reset,
>>>>> + unsigned long id)
>>>>> +{
>>>>> + struct omap_rst_map *map = reset->prm->data->rstmap;
>>>>> +
>>>>> + while (map && map->rst >= 0) {
>>>>> + if (map->rst == id)
>>>>> + return map->st;
>>>>> +
>>>>> + map++;
>>>>> + }
>>>>> +
>>>>> + return id;
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * Note that status will not change until clocks are on, and clocks
>>>>> cannot be
>>>>> + * enabled until reset is deasserted. Consumer drivers must check
>>>>> status
>>>>> + * separately after enabling clocks.
>>>>> + */
>>>>> +static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>>>>> + unsigned long id)
>>>>> +{
>>>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>>>> + u32 v;
>>>>> + int st_bit = id;
>>
>> No need to initialize this, will always get overwritten below.
>
> Hmm right, must be a leftover from some earlier code.
>
>>
>>>>> + bool has_rstst;
>>>>> +
>>>>> + /* check the current status to avoid de-asserting the line
>>>>> twice */
>>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>>>> + if (!(v & BIT(id)))
>>>>> + return -EEXIST;
>>>>> +
>>>>> + has_rstst = !(reset->prm->data->flags & OMAP_PRM_NO_RSTST);
>>>>> +
>>>>> + if (has_rstst) {
>>>>> + st_bit = omap_reset_get_st_bit(reset, id);
>>>>> +
>>>>> + /* Clear the reset status by writing 1 to the status bit */
>>>>> + v = readl_relaxed(reset->prm->base +
>>>>> reset->prm->data->rstst);
>>>>> + v |= 1 << st_bit;
>>>>> + writel_relaxed(v, reset->prm->base +
>>>>> reset->prm->data->rstst);
>>>>> + }
>>>>> +
>>>>> + /* de-assert the reset control line */
>>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>>>> + v &= ~(1 << id);
>>>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static const struct reset_control_ops omap_reset_ops = {
>>>>> + .assert = omap_reset_assert,
>>>>> + .deassert = omap_reset_deassert,
>>>>> + .status = omap_reset_status,
>>>>> +};
>>>>> +
>>>>> +static int omap_prm_reset_probe(struct platform_device *pdev,
>>>>> + struct omap_prm *prm)
>>
>> Call this omap_prm_reset_init or something similar to avoid confusion.
>
> Ok, can change this.
>
>>
>>>>> +{
>>>>> + struct omap_reset_data *reset;
>>>>> +
>>>>> + /*
>>>>> + * Check if we have resets. If either rstctl or rstst is
>>>>> + * non-zero, we have reset registers in place. Additionally
>>>>> + * the flag OMAP_PRM_NO_RSTST implies that we have resets.
>>>>> + */
>>>>> + if (!prm->data->rstctl && !prm->data->rstst &&
>>>>> + !(prm->data->flags & OMAP_PRM_NO_RSTST))
>>>>> + return 0;
>>>>> +
>>>>> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
>>>>> + if (!reset)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + reset->rcdev.owner = THIS_MODULE;
>>>>> + reset->rcdev.ops = &omap_reset_ops;
>>>>> + reset->rcdev.of_node = pdev->dev.of_node;
>>>>> + reset->rcdev.nr_resets = OMAP_MAX_RESETS;
>>
>> Suggest adding a number of resets to prm->data, and using it so that we
>> don't even entertain any resets beyond the actual number of resets.
>
> Hmm why bother? Accessing a stale reset bit will just cause access to a
> reserved bit in the reset register, doing basically nothing. Also, this
> would not work for am3/am4 wkup, as there is a single reset bit at an
> arbitrary position.
The generic convention seems to be defining a reset id value defined
from include/dt-bindings/reset/ that can be used to match between the
dt-nodes and the reset-controller driver.
Philipp,
Any comments?
regards
Suman
>
>>
>> You actually seem to be using the bit-position directly in client data
>> instead of a reset number. I am not sure if this is accepted practice
>> with reset controllers, do you incur any memory wastage?
>
> Reset numbering almost always seems to start from 0, I think the only
> exception to this is wkup_m3 on am3/am4. Introducing an additional
> arbitrary mapping for this doesn't seem to make any sense.
>
> Also, resets are allocated on-need-basis, so it only allocates one
> instance for the reset control whatever the index is.
>
>>
>>>>> +
>>>>> + reset->prm = prm;
>>>>> +
>>>>> + return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
>>>>> +}
>>>>> +
>>>>> +static int omap_prm_probe(struct platform_device *pdev)
>>>>> +{
>>>>> + struct resource *res;
>>>>> + const struct omap_prm_data *data;
>>>>> + struct omap_prm *prm;
>>>>> + const struct of_device_id *match;
>>>>> +
>>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>> + if (!res)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + match = of_match_device(omap_prm_id_table, &pdev->dev);
>>>>> + if (!match)
>>>>> + return -ENOTSUPP;
>>
>> Use of_device_get_match_data() instead to do both match and get the
>> data. That can perhaps be the first block.
>>
>>>>> +
>>>>> + prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
>>>>> + if (!prm)
>>>>> + return -ENOMEM;
>>
>> Perhaps move the allocate after the match check to streamline.
>
> Ok, will check these two out.
>
>>
>>>>> +
>>>>> + data = match->data;
>>>>> +
>>>>> + while (data->base != res->start) {
>>>>> + if (!data->base)
>>>>> + return -EINVAL;
>>>>> + data++;
>>>>> + }
>>>>> +
>>>>> + prm->data = data;
>>>>> +
>>>>> + prm->base = devm_ioremap_resource(&pdev->dev, res);
>>>>> + if (!prm->base)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + return omap_prm_reset_probe(pdev, prm);
>>>>> +}
>>>>> +
>>>>> +static struct platform_driver omap_prm_driver = {
>>>>> + .probe = omap_prm_probe,
>>>>> + .driver = {
>>>>> + .name = KBUILD_MODNAME,
>>>>> + .of_match_table = omap_prm_id_table,
>>>>> + },
>>>>> +};
>>>>> +builtin_platform_driver(omap_prm_driver);
>>>>> +
>>>>> +MODULE_ALIAS("platform:prm");
>>
>> Drop this and use MODULE_DEVICE_TABLE instead on omap_prm_id_table if
>> retaining, but I don't think these need to be defined.
>
> Ok, will ditch them.
>
> -Tero
>
>>
>> regards
>> Suman
>>
>>>>> +MODULE_LICENSE("GPL v2");
>>>>> +MODULE_DESCRIPTION("omap2+ prm driver");
>>>>
>>>> It is a builtin_platform_driver so do we need the MODULE*?
>>>
>>> Well, thats debatable, however some existing drivers do introduce this
>>> even if they are builtin.
>>>
>>> -Tero
>>> --
>>
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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/8] soc: ti: Add OMAP PRM driver
From: Suman Anna @ 2019-08-20 16:51 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <b991f374-9e2a-5f1d-d48d-5f50a3c41756@ti.com>
On 8/20/19 2:54 AM, Tero Kristo wrote:
> On 20.8.2019 2.20, Suman Anna wrote:
>> Hi Tero,
>>
>> On 8/7/19 2:48 AM, Tero Kristo wrote:
>>> Hi,
>>>
>>> This series adds OMAP PRM driver which initially supports only reset
>>> handling. Later on, power domain support can be added to this to get
>>> rid of the current OMAP power domain handling code which resides
>>> under the mach-omap2 platform directory. Initially, reset data is
>>> added for AM3, OMAP4 and DRA7 SoCs.
>>
>> Wakeup M3 remoteproc driver is fully upstream, so we should be able to
>> test that driver as well if you can add the AM4 data. That will also
>> unblock my PRUSS.
>>
>> If you can add the data to others as well, it will help in easier
>> migration of the individual drivers, otherwise the ti-sysc interconnect,
>> hwmod, and hwmod reset data combinations will all have to be supported
>> in code.
>
> Ok, so you are saying you would need the PRM data for am4 in addition? I
> can generate that one also.
Yes, if you can include the data for AM4 and OMAP5 as well, then we can
convert all the SoCs other than OMAP2/OMAP3 at the same time as per your
comment on bindings. Almost all of the active remoteprocs will be
covered by these.
OMAP3 ISP driver is also fully upstream, so we would have to manage its
legacy compatibility.
regards
Suman
>
> -Tero
>
>>
>> regards
>> Suman
>>
>>>
>>> I've been testing the reset handling logic with OMAP remoteproc
>>> driver which has been converted to use generic reset framework. This
>>> part is a work in progress, so will be posting patches from that part
>>> later on.
>>>
>>> -Tero
>>>
>>> --
>>>
>>
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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/6] dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
From: Rob Herring @ 2019-08-20 16:57 UTC (permalink / raw)
To: Rob Herring, David S. Miller, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, netdev, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org, linux-stm32
In-Reply-To: <20190820163433.sr4lvjxmmhjtbtcb@core.my.home>
On Tue, Aug 20, 2019 at 11:34 AM Ondřej Jirman <megous@megous.com> wrote:
>
> On Tue, Aug 20, 2019 at 11:20:22AM -0500, Rob Herring wrote:
> > On Tue, Aug 20, 2019 at 9:53 AM <megous@megous.com> wrote:
> > >
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > Some PHYs require separate power supply for I/O pins in some modes
> > > of operation. Add phy-io-supply property, to allow enabling this
> > > power supply.
> >
> > Perhaps since this is new, such phys should have *-supply in their nodes.
>
> Yes, I just don't understand, since external ethernet phys are so common,
> and they require power, how there's no fairly generic mechanism for this
> already in the PHY subsystem, or somewhere?
Because generic mechanisms for this don't work. For example, what
happens when the 2 supplies need to be turned on in a certain order
and with certain timings? And then add in reset or control lines into
the mix... You can see in the bindings we already have some of that.
> It looks like other ethernet mac drivers also implement supplies on phys
> on the EMAC nodes. Just grep phy-supply through dt-bindings/net.
>
> Historical reasons, or am I missing something? It almost seems like I must
> be missing something, since putting these properties to phy nodes
> seems so obvious.
Things get added one by one and one new property isn't that
controversial. We've generally learned the lesson and avoid this
pattern now, but ethernet phys are one of the older bindings.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Mathieu Poirier @ 2019-08-20 16:57 UTC (permalink / raw)
To: Lubashev, Igor
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov,
Arnaldo Carvalho de Melo, Linux Kernel Mailing List,
Alexander Shishkin, Ingo Molnar, Leo Yan, Namhyung Kim,
James Morris, Jiri Olsa, linux-arm-kernel
In-Reply-To: <3f70f6be3a464ca5b4cf563433933245@usma1ex-dag1mb6.msg.corp.akamai.com>
On Mon, 19 Aug 2019 at 16:22, Lubashev, Igor <ilubashe@akamai.com> wrote:
>
> On Mon, August 19, 2019 at 12:51 PM Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> > On Thu, 15 Aug 2019 at 15:42, Arnaldo Carvalho de Melo
> > <arnaldo.melo@gmail.com> wrote:
> > >
> > > Em Thu, Aug 15, 2019 at 02:16:48PM -0600, Mathieu Poirier escreveu:
> > > > On Wed, 14 Aug 2019 at 14:02, Lubashev, Igor <ilubashe@akamai.com>
> > wrote:
> > > > >
> > > > > > On Wed, August 14, 2019 at 2:52 PM Arnaldo Carvalho de Melo
> > <arnaldo.melo@gmail.com> wrote:
> > > > > > Em Wed, Aug 14, 2019 at 03:48:14PM -0300, Arnaldo Carvalho de
> > > > > > Melo
> > > > > > escreveu:
> > > > > > > Em Wed, Aug 14, 2019 at 12:04:33PM -0600, Mathieu Poirier
> > escreveu:
> > > > > > > > # echo 0 > /proc/sys/kernel/kptr_restrict #
> > > > > > > > ./tools/perf/perf record -e instructions:k uname
> > > > > > > > perf: Segmentation fault
> > > > > > > > Obtained 10 stack frames.
> > > > > > > > ./tools/perf/perf(sighandler_dump_stack+0x44)
> > > > > > > > [0x55af9e5da5d4]
> > > > > > > > /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fd31efb6f20]
> > > > > > > > ./tools/perf/perf(perf_event__synthesize_kernel_mmap+0xa7)
> > > > > > > > [0x55af9e590337]
> > > > > > > > ./tools/perf/perf(+0x1cf5be) [0x55af9e50c5be]
> > > > > > > > ./tools/perf/perf(cmd_record+0x1022) [0x55af9e50dff2]
> > > > > > > > ./tools/perf/perf(+0x23f98d) [0x55af9e57c98d]
> > > > > > > > ./tools/perf/perf(+0x23fc9e) [0x55af9e57cc9e]
> > > > > > > > ./tools/perf/perf(main+0x369) [0x55af9e4f6bc9]
> > > > > > > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
> > > > > > > > [0x7fd31ef99b97]
> > > > > > > > ./tools/perf/perf(_start+0x2a) [0x55af9e4f704a] Segmentation
> > > > > > > > fault
> > > > > > > >
> > > > > > > > I can reproduce this on both x86 and ARM64.
> > > > > > >
> > > > > > > I don't see this with these two csets removed:
> > > > > > >
> > > > > > > 7ff5b5911144 perf symbols: Use CAP_SYSLOG with kptr_restrict
> > > > > > > checks d7604b66102e perf tools: Use CAP_SYS_ADMIN with
> > > > > > > perf_event_paranoid checks
> > > > > > >
> > > > > > > Which were the ones I guessed were related to the problem you
> > > > > > > reported, so they are out of my ongoing perf/core pull request
> > > > > > > to Ingo/Thomas, now trying with these applied and your
> > instructions...
> > > > > >
> > > > > > Can't repro:
> > > > > >
> > > > > > [root@quaco ~]# cat /proc/sys/kernel/kptr_restrict
> > > > > > 0
> > > > > > [root@quaco ~]# perf record -e instructions:k uname Linux [ perf
> > record:
> > > > > > Woken up 1 times to write data ] [ perf record: Captured and
> > > > > > wrote 0.024 MB perf.data (1 samples) ] [root@quaco ~]# echo 1 >
> > > > > > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record -e
> > > > > > instructions:k uname Linux [ perf record: Woken up 1 times to write
> > data ] [ perf record:
> > > > > > Captured and wrote 0.024 MB perf.data (1 samples) ] [root@quaco
> > > > > > ~]# echo
> > > > > > 0 > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record
> > > > > > -e instructions:k uname Linux [ perf record: Woken up 1 times to
> > > > > > write data ] [ perf record: Captured and wrote 0.024 MB
> > > > > > perf.data (1 samples) ] [root@quaco ~]#
> > > > > >
> > > > > > [acme@quaco perf]$ git log --oneline --author Lubashev tools/
> > > > > > 7ff5b5911144 (HEAD -> perf/cap, acme.korg/tmp.perf/cap,
> > > > > > acme.korg/perf/cap) perf symbols: Use CAP_SYSLOG with
> > > > > > kptr_restrict checks d7604b66102e perf tools: Use CAP_SYS_ADMIN
> > > > > > with perf_event_paranoid checks c766f3df635d perf ftrace: Use
> > > > > > CAP_SYS_ADMIN instead of euid==0 c22e150e3afa perf tools: Add
> > > > > > helpers to use capabilities if present
> > > > > > 74d5f3d06f70 tools build: Add capability-related feature
> > > > > > detection perf version 5.3.rc4.g7ff5b5911144 [acme@quaco perf]$
> > > > >
> > > > > I got an ARM64 cloud VM, but I cannot reproduce.
> > > > > # cat /proc/sys/kernel/kptr_restrict
> > > > > 0
> > > > >
> > > > > Perf trace works fine (does not die):
> > > > > # ./perf trace -a
> > > > >
> > > > > Here is my setup:
> > > > > Repo: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> > > > > Branch: tmp.perf/cap
> > > > > Commit: 7ff5b5911 "perf symbols: Use CAP_SYSLOG with kptr_restrict
> > checks"
> > > > > gcc --version: gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) 7.4.0
> > > > > uname -a: Linux arm-4-par-1 4.9.93-mainline-rev1 #1 SMP Tue Apr 10
> > > > > 09:54:46 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux lsb_release
> > > > > -a: Ubuntu 18.04.3 LTS
> > > > >
> > > > > Auto-detecting system features:
> > > > > ... dwarf: [ on ]
> > > > > ... dwarf_getlocations: [ on ]
> > > > > ... glibc: [ on ]
> > > > > ... gtk2: [ on ]
> > > > > ... libaudit: [ on ]
> > > > > ... libbfd: [ on ]
> > > > > ... libcap: [ on ]
> > > > > ... libelf: [ on ]
> > > > > ... libnuma: [ on ]
> > > > > ... numa_num_possible_cpus: [ on ]
> > > > > ... libperl: [ on ]
> > > > > ... libpython: [ on ]
> > > > > ... libcrypto: [ on ]
> > > > > ... libunwind: [ on ]
> > > > > ... libdw-dwarf-unwind: [ on ]
> > > > > ... zlib: [ on ]
> > > > > ... lzma: [ on ]
> > > > > ... get_cpuid: [ OFF ]
> > > > > ... bpf: [ on ]
> > > > > ... libaio: [ on ]
> > > > > ... libzstd: [ on ]
> > > > > ... disassembler-four-args: [ on ]
> > > > >
> > > > > I also could not reproduce on x86:
> > > > > lsb_release -a: Ubuntu 18.04.1 LTS gcc --version: gcc (Ubuntu
> > > > > 7.4.0-1ubuntu1~18.04aka10.0.0) 7.4.0 uname -r: 4.4.0-154-generic
> > > >
> > > > I isolated the problem to libcap-dev - if it is not installed a
> > > > segmentation fault will occur. Since this set is about using
> > > > capabilities it is obvious that not having it on a system should
> > > > fail a trace session, but it should not crash it.
> > >
> > > It shouldn't crash on x86_64:
> > >
> > > root@quaco ~]# sysctl kernel.kptr_restrict kernel.kptr_restrict = 0
> > > [root@quaco ~]# perf record -e instructions:k uname Linux [ perf
> > > record: Woken up 1 times to write data ] [ perf record: Captured and
> > > wrote 0.023 MB perf.data (5 samples) ] [root@quaco ~]# ldd ~/bin/perf
> > > | grep libcap [root@quaco ~]# perf -v perf version
> > > 5.3.rc4.g329ca330bf8b [root@quaco ~]# [acme@quaco perf]$ git log
> > > --oneline -4 329ca330bf8b (HEAD -> perf/cap) perf symbols: Use
> > > CAP_SYSLOG with kptr_restrict checks f7b9999387af perf tools: Use
> > > CAP_SYS_ADMIN with perf_event_paranoid checks
> > > 4d0489cf1c47 (acme.korg/tmp.perf/script-switch-on-off, perf/core) perf
> > > report: Add --switch-on/--switch-off events
> > > 2f53ae347f59 perf top: Add --switch-on/--switch-off events [acme@quaco
> > > perf]$
> > >
> > > > If libcap-dev is not installed function
> > > > symbol__restricted_filename() will return true, which in turn will
> > > > prevent symbol_name to be set in
> > > > machine__get_running_kernel_start(). That prevents function
> > > > map__set_kallsyms_ref_reloc_sym() from being called in
> > > > machine__create_kernel_maps(), resulting in kmap->ref_reloc_sym
> > > > being NULL in _perf_event__synthesize_kernel_mmap() and a
> > > > segmentation fault.
> > >
> > > Can you please try with my perf/cap branch? Perhaps you're using
> > > Igor's original set of patches? I made changes to the fallback, he was
> > > making it return false while I made it fallback to geteuid() == 0, as
> > > was before his patches.
> >
> > Things are working properly on your perf/cap branch. I tested with on both
> > x86 and ARM.
>
> Mathieu, you are probably testing with euid==0.
Very true
> If you were to test with euid!=0 but with CAP_SYSLOG and no libcap (and kptr_restrict=0, perf_event_paranoid=2), you would likely hit the bug that you identified in __perf_event__synthesize_kermel_mmap().
>
> See https://lkml.kernel.org/lkml/930a59730c0d495f8c5acf4f99048e8d@usma1ex-dag1mb6.msg.corp.akamai.com for the fix (Option 1 only or Options 1+2).
>
> Arnaldo, once we decide what the right fix is, I am happy to post the update (options 1, 1+2) as a patch series.
CC me on the next patchset and I'll be happy to test it.
>
> - Igor
>
>
> > > > I am not sure how this can be fixed. I counted a total of 19
> > > > instances where kmap->ref_reloc_sym->XYZ is called, only 2 of wich
> > > > care to check if kmap->ref_reloc_sym is valid before proceeding. As
> > > > such I must hope that in the 17 other cases, kmap->ref_reloc_sym is
> > > > guaranteed to be valid. If I am correct then all we need is to
> > > > check for a valid pointer in _perf_event__synthesize_kernel_mmap().
> > > > Otherwise it will be a little harder.
> > > >
> > > > Mathieu
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 3/4] dt-bindings: arm: fsl: Add Kontron i.MX6UL N6310 compatibles
From: Rob Herring @ 2019-08-20 16:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer,
linux-kernel@vger.kernel.org, Schrempf Frieder, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1566315318-30320-3-git-send-email-krzk@kernel.org>
On Tue, Aug 20, 2019 at 10:35 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Add the compatibles for Kontron i.MX6UL N6310 SoM and boards.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v5:
> New patch
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 7294ac36f4c0..d07b3c06d7cf 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -161,6 +161,9 @@ properties:
> items:
> - enum:
> - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
> + - kontron,imx6ul-n6310-som # Kontron N6310 SOM
> + - kontron,imx6ul-n6310-s # Kontron N6310 S Board
> + - kontron,imx6ul-n6310-s-43 # Kontron N6310 S 43 Board
This doesn't match what is in your dts files. Run 'make dtbs_check' and see.
> - const: fsl,imx6ul
>
> - description: i.MX6ULL based Boards
> --
> 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: [EXT] Re: coresight: ACPI hook for funnel on ThunderX2
From: Tanmay Vilas Kumar Jagdale @ 2019-08-20 17:08 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Tomasz Nowicki, Jayachandran Chandrasekharan Nair,
Ganapatrao Kulkarni, linux-arm-kernel@lists.infradead.org,
suzuki.poulose@arm.com
In-Reply-To: <20190819200640.GA8268@xps15>
Hi Mathieu,
Thanks for the review and the pointers. I'll keep those in mind.
Our hardware does not implement anything specific so we will use ARM's ACPI device for our static funnel.
We can drop this patch.
With Regards,
Tanmay
-----Original Message-----
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Sent: Tuesday, August 20, 2019 1:37 AM
To: Tanmay Vilas Kumar Jagdale <tanmay@marvell.com>
Cc: suzuki.poulose@arm.com; linux-arm-kernel@lists.infradead.org; Jayachandran Chandrasekharan Nair <jnair@marvell.com>; Ganapatrao Kulkarni <gkulkarni@marvell.com>; Tomasz Nowicki <tnowicki@marvell.com>
Subject: [EXT] Re: coresight: ACPI hook for funnel on ThunderX2
External Email
----------------------------------------------------------------------
Hi Tanmay,
On Thu, Aug 15, 2019 at 01:58:21PM +0000, Tanmay Vilas Kumar Jagdale wrote:
> Coresight topology on Marvell's ThunderX2 Processor is as follows:
>
> ETM0 _ _ TPIU
> ... \ Static Dynamic /
> ... --> FUNNEL0 --> FUNNEL1 --> ETF --> REPLICATOR --
> ETM127_/ | \_ ETR
> |
> ETM128--|
> /
> Others--/
>
> To support this topology add ACPI hook for Static Funnel0.
>
> Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
There are a few things that aren't working with your patch. First it doesn't clear checkpatch.pl - a lot of maintainers will not even look at a patch when it is the case. Second it doesn't apply to my coresight next branch[1] and third there are formatting issue with the subject line.
I suggest you peruse through the Documentation/process directory with a special interest toward files submitting-patches.rst and submit-checklist.rst. Your life (and mine) will be greatly improved in the process.
More comments below...
> ---
> drivers/hwtracing/coresight/coresight-funnel.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-funnel.c
> b/drivers/hwtracing/coresight/coresight-funnel.c
> index fa97cb9ab4f9..315691fd6f4b 100644
> --- a/drivers/hwtracing/coresight/coresight-funnel.c
> +++ b/drivers/hwtracing/coresight/coresight-funnel.c
> @@ -5,6 +5,7 @@
> * Description: CoreSight Funnel driver
> */
>
> +#include <linux/acpi.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/types.h>
> @@ -297,6 +298,11 @@ static int static_funnel_probe(struct platform_device *pdev)
> return ret;
> }
>
> +static const struct acpi_device_id static_funnel_acpi_ids[] = {
> + { "CAV901A" },
> + {},
> +};
> +
Is there anything different between this static funnel and ARM's static funnel?
An ACPI device for static funnels has already been added[2] - this is probably what you should be using.
Thanks,
Mathieu
[1]. https://git.linaro.org/kernel/coresight.git/log/?h=next
[2]. 991de72831b3 coresight: acpi: Static funnel support
> static const struct of_device_id static_funnel_match[] = {
> {.compatible = "arm,coresight-static-funnel"},
> {}
> @@ -306,6 +312,7 @@ static struct platform_driver static_funnel_driver = {
> .probe = static_funnel_probe,
> .driver = {
> .name = "coresight-static-funnel",
> + .acpi_match_table = ACPI_PTR(static_funnel_acpi_ids),
> .of_match_table = static_funnel_match,
> .pm = &funnel_dev_pm_ops,
> .suppress_bind_attrs = true,
> --
> 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 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Arnaldo Carvalho de Melo @ 2019-08-20 17:13 UTC (permalink / raw)
To: Lubashev, Igor
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra,
Alexey Budankov, Arnaldo Carvalho de Melo,
Linux Kernel Mailing List, Alexander Shishkin, Ingo Molnar,
Leo Yan, Namhyung Kim, James Morris, Jiri Olsa, linux-arm-kernel
In-Reply-To: <3f70f6be3a464ca5b4cf563433933245@usma1ex-dag1mb6.msg.corp.akamai.com>
Em Mon, Aug 19, 2019 at 10:22:07PM +0000, Lubashev, Igor escreveu:
> On Mon, August 19, 2019 at 12:51 PM Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> > On Thu, 15 Aug 2019 at 15:42, Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > Things are working properly on your perf/cap branch. I tested with on both
> > x86 and ARM.
> Mathieu, you are probably testing with euid==0. If you were to test
> with euid!=0 but with CAP_SYSLOG and no libcap (and kptr_restrict=0,
> perf_event_paranoid=2), you would likely hit the bug that you
> identified in __perf_event__synthesize_kermel_mmap().
> See https://lkml.kernel.org/lkml/930a59730c0d495f8c5acf4f99048e8d@usma1ex-dag1mb6.msg.corp.akamai.com for the fix (Option 1 only or Options 1+2).
>
> Arnaldo, once we decide what the right fix is, I am happy to post the update (options 1, 1+2) as a patch series.
I think you should get the checks for ref_reloc_sym in place so as to
make the code overall more robust, and also go on continuing to make the
checks in tools/perf/ to match what is checked on the other side of the
mirror, i.e. by the kernel, so from a quick read, please put first the
robustness patches (check ref_reloc_sym) do your other suggestions and
update the warnings, then refresh the two patches that still are not in
my perf/core branch:
[acme@quaco perf]$ git rebase perf/core
First, rewinding head to replay your work on top of it...
Applying: perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
Applying: perf symbols: Use CAP_SYSLOG with kptr_restrict checks
[acme@quaco perf]$
I've pushed out perf/cap, so you can go from there as it is rebased on
my current perf/core.
Then test all these cases: with/without libcap, with euid==0 and
different than zero, with capabilities, etc, patch by patch so that we
don't break bisection nor regress,
Thanks and keep up the good work!
- Arnaldo
> - Igor
>
>
> > > > I am not sure how this can be fixed. I counted a total of 19
> > > > instances where kmap->ref_reloc_sym->XYZ is called, only 2 of wich
> > > > care to check if kmap->ref_reloc_sym is valid before proceeding. As
> > > > such I must hope that in the 17 other cases, kmap->ref_reloc_sym is
> > > > guaranteed to be valid. If I am correct then all we need is to
> > > > check for a valid pointer in _perf_event__synthesize_kernel_mmap().
> > > > Otherwise it will be a little harder.
> > > >
> > > > Mathieu
>
--
- Arnaldo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 04/11] of/fdt: add early_init_dt_get_dma_zone_size()
From: Rob Herring @ 2019-08-20 17:14 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: open list:GENERIC INCLUDE/ASM HEADER FILES, devicetree,
moderated list:BROADCOM BCM2835 ARM ARCHITECTURE,
Florian Fainelli, Andrew Morton, Frank Rowand, Eric Anholt,
Marc Zyngier, Catalin Marinas, Will Deacon,
linux-kernel@vger.kernel.org, linux-mm, Linux IOMMU,
Matthias Brugger, Stefan Wahren, linux-riscv, Marek Szyprowski,
Robin Murphy, Christoph Hellwig,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, phill
In-Reply-To: <20190820145821.27214-5-nsaenzjulienne@suse.de>
On Tue, Aug 20, 2019 at 9:58 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Some devices might have weird DMA addressing limitations that only apply
> to a subset of the available peripherals. For example the Raspberry Pi 4
> has two interconnects, one able to address the whole lower 4G memory
> area and another one limited to the lower 1G.
>
> Being an uncommon situation we simply hardcode the device wide DMA
> addressable memory size conditionally to the machine compatible name and
> set 'dma_zone_size' accordingly.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> ---
>
> Changes in v2:
> - New approach to getting dma_zone_size, instead of parsing the dts we
> hardcode it conditionally to the machine compatible name.
>
> drivers/of/fdt.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 06ffbd39d9af..f756e8c05a77 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -27,6 +27,7 @@
>
> #include <asm/setup.h> /* for COMMAND_LINE_SIZE */
> #include <asm/page.h>
> +#include <asm/dma.h> /* for dma_zone_size */
>
> #include "of_private.h"
>
> @@ -1195,6 +1196,12 @@ void __init early_init_dt_scan_nodes(void)
> of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> }
>
> +void __init early_init_dt_get_dma_zone_size(void)
static
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> +{
> + if (of_fdt_machine_is_compatible("brcm,bcm2711"))
> + dma_zone_size = 0x3c000000;
> +}
> +
> bool __init early_init_dt_scan(void *params)
> {
> bool status;
> @@ -1204,6 +1211,7 @@ bool __init early_init_dt_scan(void *params)
> return false;
>
> early_init_dt_scan_nodes();
> + early_init_dt_get_dma_zone_size();
> return true;
> }
>
> --
> 2.22.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 03/11] of/fdt: add of_fdt_machine_is_compatible function
From: Rob Herring @ 2019-08-20 17:16 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: open list:GENERIC INCLUDE/ASM HEADER FILES, devicetree,
moderated list:BROADCOM BCM2835 ARM ARCHITECTURE,
Florian Fainelli, Andrew Morton, Frank Rowand, Eric Anholt,
Marc Zyngier, Catalin Marinas, Will Deacon,
linux-kernel@vger.kernel.org, linux-mm, Linux IOMMU,
Matthias Brugger, Stefan Wahren, linux-riscv, Marek Szyprowski,
Robin Murphy, Christoph Hellwig,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, phill
In-Reply-To: <20190820145821.27214-4-nsaenzjulienne@suse.de>
On Tue, Aug 20, 2019 at 9:58 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Provides the same functionality as of_machine_is_compatible.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>
> Changes in v2: None
>
> drivers/of/fdt.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 9cdf14b9aaab..06ffbd39d9af 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -802,6 +802,13 @@ const char * __init of_flat_dt_get_machine_name(void)
> return name;
> }
>
> +static const int __init of_fdt_machine_is_compatible(char *name)
No point in const return (though name could possibly be const), and
the return could be bool instead.
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> +{
> + unsigned long dt_root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(dt_root, name);
> +}
> +
> /**
> * of_flat_dt_match_machine - Iterate match tables to find matching machine.
> *
> --
> 2.22.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 5/8] soc: ti: omap-prm: add omap4 PRM data
From: Suman Anna @ 2019-08-20 17:23 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <9d684bdc-28b8-0772-2957-93e01c55aae4@ti.com>
On 8/20/19 2:52 AM, Tero Kristo wrote:
> On 20.8.2019 2.08, Suman Anna wrote:
>> On 8/7/19 2:48 AM, Tero Kristo wrote:
>>> Add PRM data for omap4 family of SoCs.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>> drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>>> index 870515e3..9b8d5945 100644
>>> --- a/drivers/soc/ti/omap_prm.c
>>> +++ b/drivers/soc/ti/omap_prm.c
>>> @@ -54,7 +54,27 @@ struct omap_reset_data {
>>> #define OMAP_PRM_NO_RSTST BIT(0)
>>> +struct omap_prm_data omap4_prm_data[] = {
>>
>> static const
>
> Will fix this and rest of the similar comments.
>
> -Tero
>
>>
>> regards
>> Suman
>>
>>> + { .name = "mpu", .base = 0x4a306300, .pwstst = 0x4 },
>>> + { .name = "tesla", .base = 0x4a306400, .pwstst = 0x4, .rstctl =
>>> 0x10, .rstst = 0x14 },
>>> + { .name = "abe", .base = 0x4a306500, .pwstst = 0x4 },
>>> + { .name = "always_on_core", .base = 0x4a306600, .pwstst = 0x4 },
>>> + { .name = "core", .base = 0x4a306700, .pwstst = 0x4, .rstctl =
>>> 0x210, .rstst = 0x214 },
>>> + { .name = "ivahd", .base = 0x4a306f00, .pwstst = 0x4, .rstctl =
>>> 0x10, .rstst = 0x14 },
>>> + { .name = "cam", .base = 0x4a307000, .pwstst = 0x4 },
>>> + { .name = "dss", .base = 0x4a307100, .pwstst = 0x4 },
>>> + { .name = "gfx", .base = 0x4a307200, .pwstst = 0x4 },
>>> + { .name = "l3init", .base = 0x4a307300, .pwstst = 0x4 },
>>> + { .name = "l4per", .base = 0x4a307400, .pwstst = 0x4 },
>>> + { .name = "cefuse", .base = 0x4a307600, .pwstst = 0x4 },
>>> + { .name = "wkup", .base = 0x4a307700, .pwstst = 0x4 },
>>> + { .name = "emu", .base = 0x4a307900, .pwstst = 0x4 },
>>> + { .name = "device", .base = 0x4a307b00, .rstctl = 0x0, .rstst =
>>> 0x4 },
So, looks like you are using pwstctrl as 0 by default, but some of them
will neither have pwstctrl or pwstst like "device" PRM here. Is the plan
to use -1 for the fields, or a flags field?
regards
Suman
>>> + { },
>>> +};
>>> +
>>> static const struct of_device_id omap_prm_id_table[] = {
>>> + { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
>>> { },
>>> };
>>>
>>
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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/11] of/fdt: add of_fdt_machine_is_compatible function
From: Nicolas Saenz Julienne @ 2019-08-20 17:27 UTC (permalink / raw)
To: Rob Herring
Cc: open list:GENERIC INCLUDE/ASM HEADER FILES, devicetree,
Florian Fainelli, phill, Will Deacon, linux-mm, Marc Zyngier,
Catalin Marinas, linux-kernel@vger.kernel.org, Christoph Hellwig,
Eric Anholt, Linux IOMMU, Matthias Brugger,
moderated list:BROADCOM BCM2835 ARM ARCHITECTURE, Robin Murphy,
Andrew Morton, Marek Szyprowski, Frank Rowand, linux-riscv,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Stefan Wahren
In-Reply-To: <CAL_JsqJT3UNVKpAt+3g-tosy=uCZTosUxD4RfVYjMJ-gpGmPiA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1094 bytes --]
Hi Rob,
thanks for the rewiew.
On Tue, 2019-08-20 at 12:16 -0500, Rob Herring wrote:
> On Tue, Aug 20, 2019 at 9:58 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> > Provides the same functionality as of_machine_is_compatible.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >
> > Changes in v2: None
> >
> > drivers/of/fdt.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 9cdf14b9aaab..06ffbd39d9af 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -802,6 +802,13 @@ const char * __init of_flat_dt_get_machine_name(void)
> > return name;
> > }
> >
> > +static const int __init of_fdt_machine_is_compatible(char *name)
>
> No point in const return (though name could possibly be const), and
> the return could be bool instead.
Sorry, I completely missed that const, shouldn't have been there to begin with.
I'll add a const to the name argument and return a bool on the next version.
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- 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 11/21] ASoC: sun4i-i2s: Use the actual format width instead of an hardcoded one
From: Mark Brown @ 2019-08-20 17:39 UTC (permalink / raw)
To: Maxime Ripard
Cc: alsa-devel, lgirdwood, linux-kernel, codekipper, Chen-Yu Tsai,
linux-arm-kernel
In-Reply-To: <fcf77b3bee47b54d81d1a3f4f107312f44388f5a.1566242458.git-series.maxime.ripard@bootlin.com>
[-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --]
On Mon, Aug 19, 2019 at 09:25:18PM +0200, Maxime Ripard wrote:
> regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
> SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
> - SUN8I_I2S_FMT0_LRCK_PERIOD(32));
> + SUN8I_I2S_FMT0_LRCK_PERIOD(params_physical_width(params)));
This doesn't build for me:
In file included from sound/soc/sunxi/sun4i-i2s.c:16:
sound/soc/sunxi/sun4i-i2s.c: In function ‘sun4i_i2s_set_clk_rate’:
sound/soc/sunxi/sun4i-i2s.c:360:57: error: ‘params’ undeclared (first use in this function); did you mean ‘parameq’?
SUN8I_I2S_FMT0_LRCK_PERIOD(params_physical_width(params)));
^~~~~~
./include/linux/regmap.h:75:42: note: in definition of macro ‘regmap_update_bits’
regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
^~~
sound/soc/sunxi/sun4i-i2s.c:360:8: note: in expansion of macro ‘SUN8I_I2S_FMT0_LRCK_PERIOD’
SUN8I_I2S_FMT0_LRCK_PERIOD(params_physical_width(params)));
[-- 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
* Applied "ASoC: sun4i-i2s: Remove duplicated quirks structure" to the asoc tree
From: Mark Brown @ 2019-08-20 17:41 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: <5ade5de27d23918c5ef30387c23aead951d5ad64.1566242458.git-series.maxime.ripard@bootlin.com>
The patch
ASoC: sun4i-i2s: Remove duplicated quirks structure
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 3e9acd7ac6933cdc20c441bbf9a38ed9e42e1490 Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Mon, 19 Aug 2019 21:25:24 +0200
Subject: [PATCH] ASoC: sun4i-i2s: Remove duplicated quirks structure
The A83t and H3 have the same quirks, so it doesn't make sense to duplicate
the quirks structure.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/5ade5de27d23918c5ef30387c23aead951d5ad64.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 21 +--------------------
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 9468584f4eb0..4c636f1cf7dc 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1062,25 +1062,6 @@ 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,
- .has_fmt_set_lrck_period = true,
- .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,
@@ -1262,7 +1243,7 @@ static const struct of_device_id sun4i_i2s_match[] = {
},
{
.compatible = "allwinner,sun8i-h3-i2s",
- .data = &sun8i_h3_i2s_quirks,
+ .data = &sun8i_a83t_i2s_quirks,
},
{
.compatible = "allwinner,sun50i-a64-codec-i2s",
--
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: sun4i-i2s: Support more channels" to the asoc tree
From: Mark Brown @ 2019-08-20 17:41 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: <27d9de5cd56f3a544851b8cd8af08bf836d19637.1566242458.git-series.maxime.ripard@bootlin.com>
The patch
ASoC: sun4i-i2s: Support more channels
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 bbf9a127abca4aac5cc75f882bc7efcc398e86ae Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Mon, 19 Aug 2019 21:25:26 +0200
Subject: [PATCH] ASoC: sun4i-i2s: Support more channels
We've been limited to 2 channels in the driver while the controller
supports from 1 to 8 channels, in both capture and playback. let's remove
the hardcoded checks and numbers, and extend the range of channel numbers
we can use.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/27d9de5cd56f3a544851b8cd8af08bf836d19637.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 6b172dfbc25d..9e691baee1e8 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -400,9 +400,6 @@ static int sun4i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
{
unsigned int channels = params_channels(params);
- if (channels != 2)
- return -EINVAL;
-
/* Map the channels for playback and capture */
regmap_write(i2s->regmap, SUN4I_I2S_TX_CHAN_MAP_REG, 0x76543210);
regmap_write(i2s->regmap, SUN4I_I2S_RX_CHAN_MAP_REG, 0x00003210);
@@ -423,9 +420,6 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
{
unsigned int channels = params_channels(params);
- if (channels != 2)
- return -EINVAL;
-
/* Map the channels for playback and capture */
regmap_write(i2s->regmap, SUN8I_I2S_TX_CHAN_MAP_REG, 0x76543210);
regmap_write(i2s->regmap, SUN8I_I2S_RX_CHAN_MAP_REG, 0x76543210);
@@ -458,6 +452,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+ unsigned int channels = params_channels(params);
int ret, sr, wss;
u32 width;
@@ -490,7 +485,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
regmap_field_write(i2s->field_fmt_sr, sr);
return sun4i_i2s_set_clk_rate(dai, params_rate(params),
- 2, params_width(params));
+ channels, params_width(params));
}
static int sun4i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
@@ -814,15 +809,15 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
.probe = sun4i_i2s_dai_probe,
.capture = {
.stream_name = "Capture",
- .channels_min = 2,
- .channels_max = 2,
+ .channels_min = 1,
+ .channels_max = 8,
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.playback = {
.stream_name = "Playback",
- .channels_min = 2,
- .channels_max = 2,
+ .channels_min = 1,
+ .channels_max = 8,
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
--
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: mchp-i2s-mcc: Fix unprepare of GCLK" to the asoc tree
From: Mark Brown @ 2019-08-20 17:41 UTC (permalink / raw)
To: Codrin Ciubotariu
Cc: alexandre.belloni, alsa-devel, linux-kernel, ludovic.desroches,
Mark Brown, tiwai, perex, linux-arm-kernel
In-Reply-To: <20190820162411.24836-2-codrin.ciubotariu@microchip.com>
The patch
ASoC: mchp-i2s-mcc: Fix unprepare of GCLK
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.3
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 988b59467b2b14523a266957affbe9eca3e99fc9 Mon Sep 17 00:00:00 2001
From: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Date: Tue, 20 Aug 2019 19:24:09 +0300
Subject: [PATCH] ASoC: mchp-i2s-mcc: Fix unprepare of GCLK
If hw_free() gets called after hw_params(), GCLK remains prepared,
preventing further use of it. This patch fixes this by unpreparing the
clock in hw_free() or if hw_params() gets an error.
Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Link: https://lore.kernel.org/r/20190820162411.24836-2-codrin.ciubotariu@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/atmel/mchp-i2s-mcc.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/sound/soc/atmel/mchp-i2s-mcc.c b/sound/soc/atmel/mchp-i2s-mcc.c
index 86495883ca3f..319f975586f1 100644
--- a/sound/soc/atmel/mchp-i2s-mcc.c
+++ b/sound/soc/atmel/mchp-i2s-mcc.c
@@ -670,8 +670,13 @@ static int mchp_i2s_mcc_hw_params(struct snd_pcm_substream *substream,
}
ret = regmap_write(dev->regmap, MCHP_I2SMCC_MRA, mra);
- if (ret < 0)
+ if (ret < 0) {
+ if (dev->gclk_use) {
+ clk_unprepare(dev->gclk);
+ dev->gclk_use = 0;
+ }
return ret;
+ }
return regmap_write(dev->regmap, MCHP_I2SMCC_MRB, mrb);
}
@@ -708,9 +713,13 @@ static int mchp_i2s_mcc_hw_free(struct snd_pcm_substream *substream,
regmap_write(dev->regmap, MCHP_I2SMCC_CR, MCHP_I2SMCC_CR_CKDIS);
if (dev->gclk_running) {
- clk_disable_unprepare(dev->gclk);
+ clk_disable(dev->gclk);
dev->gclk_running = 0;
}
+ if (dev->gclk_use) {
+ clk_unprepare(dev->gclk);
+ dev->gclk_use = 0;
+ }
}
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
* Applied "ASoC: sun4i-i2s: Fix WSS and SR fields for the A83t" to the asoc tree
From: Mark Brown @ 2019-08-20 17:41 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: <d93f0943cc39d880750daf459a0eeab34c63518e.1566242458.git-series.maxime.ripard@bootlin.com>
The patch
ASoC: sun4i-i2s: Fix WSS and SR fields for the A83t
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 2e04fc4dbf50195262aa5a2ae6d35baa5b598cae Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Mon, 19 Aug 2019 21:25:21 +0200
Subject: [PATCH] ASoC: sun4i-i2s: Fix WSS and SR fields for the A83t
The A83t has the same bit fields offsets than the A10 and A31, while this
was the first device with the new layout, fix that.
Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/d93f0943cc39d880750daf459a0eeab34c63518e.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 29b5eacd3abe..59d809df8d2a 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1048,8 +1048,8 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.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, 7, 7),
- .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 2, 3),
- .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 5),
+ .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,
--
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: sun4i-i2s: Fix MCLK Enable bit offset on A83t" to the asoc tree
From: Mark Brown @ 2019-08-20 17:41 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: <43b07f8cd8e0e280c64ce61d57c307678c923e9b.1566242458.git-series.maxime.ripard@bootlin.com>
The patch
ASoC: sun4i-i2s: Fix MCLK Enable bit offset on A83t
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 bf943d527987c38f6fb11f9515e0cf2839286eb8 Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Mon, 19 Aug 2019 21:25:22 +0200
Subject: [PATCH] ASoC: sun4i-i2s: Fix MCLK Enable bit offset on A83t
The A83t, unlike previous SoCs, has the MCLK enable bit at the 8th bit of
the CLK_DIV register, unlike what is declared in the driver.
Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/43b07f8cd8e0e280c64ce61d57c307678c923e9b.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 59d809df8d2a..0fce3c476772 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1047,7 +1047,7 @@ 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, 7, 7),
+ .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,
--
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: sun4i-i2s: Fix the LRCK period on A83t" to the asoc tree
From: Mark Brown @ 2019-08-20 17:41 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: <6a0ee0bc1375bcb53840d3fb2d2f3d9732b8e57e.1566242458.git-series.maxime.ripard@bootlin.com>
The patch
ASoC: sun4i-i2s: Fix the LRCK period on A83t
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 69e450e50ca6dde566f3ac3f2c329fb0492441ef Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Mon, 19 Aug 2019 21:25:23 +0200
Subject: [PATCH] ASoC: sun4i-i2s: Fix the LRCK period on A83t
Unlike the previous SoCs, the A83t, like the newer ones, need the LRCK
bitfield to be set. Let's add it.
Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/6a0ee0bc1375bcb53840d3fb2d2f3d9732b8e57e.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 0fce3c476772..9468584f4eb0 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1047,6 +1047,7 @@ 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,
+ .has_fmt_set_lrck_period = true,
.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),
--
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: sun4i-i2s: Pass the channels number as an argument" to the asoc tree
From: Mark Brown @ 2019-08-20 17:41 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: <48887cf7abfaab6597db233b24d7a088a913e48a.1566242458.git-series.maxime.ripard@bootlin.com>
The patch
ASoC: sun4i-i2s: Pass the channels number as an argument
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 0083a507a78fdfa868acc0709408b59e72488a61 Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Mon, 19 Aug 2019 21:25:25 +0200
Subject: [PATCH] ASoC: sun4i-i2s: Pass the channels number as an argument
The channels number have been hardcoded to 2 so far, while the controller
supports more than that.
Remove the instance where it has been hardcoded to compute the BCLK
divider, and pass it through as an argument to ease further support of more
channels.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/48887cf7abfaab6597db233b24d7a088a913e48a.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 4c636f1cf7dc..6b172dfbc25d 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -238,10 +238,11 @@ static unsigned long sun8i_i2s_get_bclk_parent_rate(const struct sun4i_i2s *i2s)
static int sun4i_i2s_get_bclk_div(struct sun4i_i2s *i2s,
unsigned long parent_rate,
unsigned int sampling_rate,
+ unsigned int channels,
unsigned int word_size)
{
const struct sun4i_i2s_clk_div *dividers = i2s->variant->bclk_dividers;
- int div = parent_rate / sampling_rate / word_size / 2;
+ int div = parent_rate / sampling_rate / word_size / channels;
int i;
for (i = 0; i < i2s->variant->num_bclk_dividers; i++) {
@@ -286,6 +287,7 @@ static bool sun4i_i2s_oversample_is_valid(unsigned int oversample)
static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
unsigned int rate,
+ unsigned int channels,
unsigned int word_size)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
@@ -333,7 +335,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
bclk_parent_rate = i2s->variant->get_bclk_parent_rate(i2s);
bclk_div = sun4i_i2s_get_bclk_div(i2s, bclk_parent_rate,
- rate, word_size);
+ rate, channels, word_size);
if (bclk_div < 0) {
dev_err(dai->dev, "Unsupported BCLK divider: %d\n", bclk_div);
return -EINVAL;
@@ -488,7 +490,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
regmap_field_write(i2s->field_fmt_sr, sr);
return sun4i_i2s_set_clk_rate(dai, params_rate(params),
- params_width(params));
+ 2, params_width(params));
}
static int sun4i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
--
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
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