* [PATCH v5 02/15] ASoC: sun4i-i2s: Add set_tdm_slot functionality
From: codekipper @ 2019-08-14 6:08 UTC (permalink / raw)
To: maxime.ripard, wens, linux-sunxi
Cc: alsa-devel, Marcus Cooper, lgirdwood, linux-kernel, be17068,
broonie, linux-arm-kernel
In-Reply-To: <20190814060854.26345-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
Codecs without a control connection such as i2s based HDMI audio and
the Pine64 DAC require a different amount of bit clocks per frame than
what is calculated by the sample width. Use the tdm slot bindings to
provide this mechanism.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
sound/soc/sunxi/sun4i-i2s.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 8201334a059b..7c37b6291df0 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -195,6 +195,9 @@ struct sun4i_i2s {
struct regmap_field *field_rxchansel;
const struct sun4i_i2s_quirks *variant;
+
+ unsigned int tdm_slots;
+ unsigned int slot_width;
};
struct sun4i_i2s_clk_div {
@@ -346,7 +349,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
if (i2s->variant->has_fmt_set_lrck_period)
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(word_size));
/* Set sign extension to pad out LSB with 0 */
regmap_field_write(i2s->field_fmt_sext, 0);
@@ -450,7 +453,8 @@ 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));
+ i2s->tdm_slots ?
+ i2s->slot_width : params_width(params));
}
static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
@@ -693,10 +697,25 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai *dai, int clk_id,
return 0;
}
+static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
+ unsigned int tx_mask,
+ unsigned int rx_mask,
+ int slots, int width)
+{
+ struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+
+ i2s->tdm_slots = slots;
+
+ i2s->slot_width = width;
+
+ return 0;
+}
+
static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
.hw_params = sun4i_i2s_hw_params,
.set_fmt = sun4i_i2s_set_fmt,
.set_sysclk = sun4i_i2s_set_sysclk,
+ .set_tdm_slot = sun4i_i2s_set_dai_tdm_slot,
.trigger = sun4i_i2s_trigger,
};
--
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 related
* [PATCH v5 01/15] ASoC: sun4i-i2s: Add regmap field to sign extend sample
From: codekipper @ 2019-08-14 6:08 UTC (permalink / raw)
To: maxime.ripard, wens, linux-sunxi
Cc: alsa-devel, Marcus Cooper, lgirdwood, linux-kernel, be17068,
broonie, linux-arm-kernel
In-Reply-To: <20190814060854.26345-1-codekipper@gmail.com>
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>
---
sound/soc/sunxi/sun4i-i2s.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 793457394efe..8201334a059b 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -135,6 +135,7 @@ struct sun4i_i2s;
* @field_fmt_bclk: regmap field to set clk polarity.
* @field_fmt_lrclk: regmap field to set frame polarity.
* @field_fmt_mode: regmap field to set the operational mode.
+ * @field_fmt_sext: regmap field to set the sign extension.
* @field_txchanmap: location of the tx channel mapping register.
* @field_rxchanmap: location of the rx channel mapping register.
* @field_txchansel: location of the tx channel select bit fields.
@@ -159,6 +160,7 @@ struct sun4i_i2s_quirks {
struct reg_field field_fmt_bclk;
struct reg_field field_fmt_lrclk;
struct reg_field field_fmt_mode;
+ struct reg_field field_fmt_sext;
struct reg_field field_txchanmap;
struct reg_field field_rxchanmap;
struct reg_field field_txchansel;
@@ -186,6 +188,7 @@ struct sun4i_i2s {
struct regmap_field *field_fmt_bclk;
struct regmap_field *field_fmt_lrclk;
struct regmap_field *field_fmt_mode;
+ struct regmap_field *field_fmt_sext;
struct regmap_field *field_txchanmap;
struct regmap_field *field_rxchanmap;
struct regmap_field *field_txchansel;
@@ -345,6 +348,9 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
SUN8I_I2S_FMT0_LRCK_PERIOD(32));
+ /* Set sign extension to pad out LSB with 0 */
+ regmap_field_write(i2s->field_fmt_sext, 0);
+
return 0;
}
@@ -917,6 +923,7 @@ static const struct sun4i_i2s_quirks sun4i_a10_i2s_quirks = {
.field_fmt_lrclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 7, 7),
.has_slave_select_bit = true,
.field_fmt_mode = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 1),
+ .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 8, 8),
.field_txchanmap = REG_FIELD(SUN4I_I2S_TX_CHAN_MAP_REG, 0, 31),
.field_rxchanmap = REG_FIELD(SUN4I_I2S_RX_CHAN_MAP_REG, 0, 31),
.field_txchansel = REG_FIELD(SUN4I_I2S_TX_CHAN_SEL_REG, 0, 2),
@@ -936,6 +943,7 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
.field_fmt_lrclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 7, 7),
.has_slave_select_bit = true,
.field_fmt_mode = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 1),
+ .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 8, 8),
.field_txchanmap = REG_FIELD(SUN4I_I2S_TX_CHAN_MAP_REG, 0, 31),
.field_rxchanmap = REG_FIELD(SUN4I_I2S_RX_CHAN_MAP_REG, 0, 31),
.field_txchansel = REG_FIELD(SUN4I_I2S_TX_CHAN_SEL_REG, 0, 2),
@@ -979,6 +987,7 @@ static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
.field_fmt_bclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 7, 7),
.field_fmt_lrclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 19, 19),
.field_fmt_mode = REG_FIELD(SUN4I_I2S_CTRL_REG, 4, 5),
+ .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 4, 5),
.field_txchanmap = REG_FIELD(SUN8I_I2S_TX_CHAN_MAP_REG, 0, 31),
.field_rxchanmap = REG_FIELD(SUN8I_I2S_RX_CHAN_MAP_REG, 0, 31),
.field_txchansel = REG_FIELD(SUN8I_I2S_TX_CHAN_SEL_REG, 0, 2),
@@ -998,6 +1007,7 @@ static const struct sun4i_i2s_quirks sun50i_a64_codec_i2s_quirks = {
.field_fmt_bclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 6, 6),
.field_fmt_lrclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 7, 7),
.field_fmt_mode = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 1),
+ .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 8, 8),
.field_txchanmap = REG_FIELD(SUN4I_I2S_TX_CHAN_MAP_REG, 0, 31),
.field_rxchanmap = REG_FIELD(SUN4I_I2S_RX_CHAN_MAP_REG, 0, 31),
.field_txchansel = REG_FIELD(SUN4I_I2S_TX_CHAN_SEL_REG, 0, 2),
@@ -1045,6 +1055,12 @@ static int sun4i_i2s_init_regmap_fields(struct device *dev,
if (IS_ERR(i2s->field_fmt_mode))
return PTR_ERR(i2s->field_fmt_mode);
+ i2s->field_fmt_sext =
+ devm_regmap_field_alloc(dev, i2s->regmap,
+ i2s->variant->field_fmt_sext);
+ if (IS_ERR(i2s->field_fmt_sext))
+ return PTR_ERR(i2s->field_fmt_sext);
+
i2s->field_txchanmap =
devm_regmap_field_alloc(dev, i2s->regmap,
i2s->variant->field_txchanmap);
--
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 related
* [PATCH v5 00/15] ASoC: sun4i-i2s: Updates to the driver
From: codekipper @ 2019-08-14 6:08 UTC (permalink / raw)
To: maxime.ripard, wens, linux-sunxi
Cc: alsa-devel, Marcus Cooper, lgirdwood, linux-kernel, be17068,
broonie, linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
Hi All,
here is a patch series to add some improvements to the sun4i-i2s driver
found whilst getting slave clocking and hdmi audio working on the newer
SoCs. As the LibreELEC project is progressing extremely well then there
has been some activity getting H6 SoC support with surround sound
working and these changes are also included.
The functionality included with the new patch set has been extended to
cover more sample resolutions, multi-lane data output for HDMI audio
and some bug fixes that have been discovered along the way. I have
changed some of the original reg fields into function calls as this made
it easier to setup for multi-channel audio especially across different
SoCs.
I can see more usage of the tdm property since I last attempted to push
these patches and the examples currently in mainline sort of the opposite
to what I'm trying to achieve. When we first started looking at the i2s
driver, the codecs that we were using allowed for the frame width to be
determined based on the sampling resolution but in most use cases it
seems that a fixed width is required(my highest priority should be to get
HDMI audio support in). We're using the tdm property to override the old
way to calculate the frame width. What I've seen in what has already been
mainlined is that the i2s driver has a frame width that is fixed to 32
bits and this can be overridden using the tdm property.
My test branch for this can be found at
https://github.com/codekipper/linux-sunxi/commits/upstream-i2s , I've been
using a Pine64 to test with; validating the new SoC block with HDMI audio
and ensuring that I've not broken the old block by making sure that the audio
codec still works. If we able to get the first three patches delivered then
that is enough for HDMI audio support on the newer SoCs(H3, A64 etc).
I still need to investigate the FIFO syncing issues which i've not had a
chance to change or address the concerns that broonie and wens brought up.
This change has been moved to the top of the patch stack. I would also like
to make the multi-channel audio and audio mapping more configurable via the
device tree. Currently what is implemented suites our current needs.
BR,
CK
---
v5 changes compared to v4 are:
- removed delivered patches.
- Added more details to commit messages.
- replaced some reg fields with function calls.
- Added DSP_A and DSP_B support for H3 and later SoCs.
- Added support for the Allwinner H6.
v4 changes compared to v3 are:
- Moved patches around so that the more controversial of patches are
at the top of the stack.
- Added more details to commit messages.
- Fixed 20bit audio PCM format to use 4 bytes.
- Reduced number of flags used to indicate a new SoC.
v3 changes compared to v2 are:
- added back slave mode changes
- added back the use of tdm properties
- changes to regmap and caching
- removed loopback functionality
- fixes to the channel offset mask
v2 changes compared to v1 are:
- removed slave mode changes which didn't set mclk and bclk div.
- removed use of tdm and now use a dedicated property.
- fix commit message to better explain reason for sign extending
- add divider calculations for newer SoCs.
- add support for multi-lane i2s data output.
- add support for 20, 24 and 32 bit samples.
- add loopback property so blocks can be tested without a codec.
---
Jernej Skrabec (3):
clk: sunxi-ng: h6: Allow I2S to change parent rate
dt-bindings: ASoC: sun4i-i2s: Add H6 compatible
ASoC: sun4i-i2s: Add support for H6 I2S
Marcus Cooper (12):
ASoC: sun4i-i2s: Add regmap field to sign extend sample
ASoC: sun4i-i2s: Add set_tdm_slot functionality
ASoC: sun4i-i2s: Correct divider calculations
ASoC: sun4i-i2s: Support more formats on newer SoCs
ASoC: sun4i-i2s: Add functions for RX and TX channel offsets
ASoC: sun4i-i2s: Add functions for RX and TX channel enables
ASoC: sun4i-i2s: Add functions for RX and TX channel selects
ASoC: sun4i-i2s: Add functions for channel mapping
ASoC: sun4i-i2s: Add multi-lane functionality
ASoC: sun4i-i2s: Add multichannel functionality
ASoc: sun4i-i2s: Add 20, 24 and 32 bit support
ASoC: sun4i-i2s: Adjust regmap settings
.../sound/allwinner,sun4i-a10-i2s.yaml | 2 +
drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 8 +-
sound/soc/sunxi/sun4i-i2s.c | 690 ++++++++++++++----
3 files changed, 542 insertions(+), 158 deletions(-)
--
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 1/2] arm64: dts: fsl: add support for Hummingboard Pulse
From: Baruch Siach @ 2019-08-14 5:59 UTC (permalink / raw)
To: Marco Felsch
Cc: Sascha Hauer, Jon Nettleton, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
linux-arm-kernel
In-Reply-To: <20190809044754.r4f4y3hi7rkjbfpa@pengutronix.de>
Hi Marco,
On Fri, Aug 09, 2019 at 06:47:54AM +0200, Marco Felsch wrote:
> On 19-08-08 20:48, Baruch Siach wrote:
> > From: Jon Nettleton <jon@solid-run.com>
> >
> > The SolidRun Hummingboard Pulse carrier board carries the SolidRun
> > i.MX8MQ based SOM.
> >
> > Notably missing is PCIe support that depends on analog PLLOUT clock.
> > Current imx clk driver does not support this clock.
> >
> > Signed-off-by: Jon Nettleton <jon@solid-run.com>
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
[...]
> > +#include "imx8mq-sr-som.dtsi"
> > +
> > +/ {
> > + model = "SolidRun i.MX8MQ HummingBoard Pulse";
> > + compatible = "solidrun,hummingboard-pulse", "fsl,imx8mq";
> > +
> > + chosen {
> > + stdout-path = &uart1;
> > + };
>
> Do we need that node? In case of barebox this is only relevant to the
> barebox dts.
This is a standard DT property that describes the boot console. Most other dts
files have it.
[...]
> > +&iomuxc {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hog>;
> > +
> > + pinctrl_hog: hoggrp {
> > + fsl,pins = <
> > + /* MikroBus Analog */
> > + MX8MQ_IOMUXC_NAND_DATA05_GPIO3_IO11 0x41
> > + /* MikroBus Reset */
> > + MX8MQ_IOMUXC_SAI2_RXD0_GPIO4_IO23 0x41
> > + /*
> > + * The following 2 pins need to be commented out and
> > + * reconfigured to enable RTS/CTS on UART3
> > + */
> > + /* MikroBus PWM */
> > + MX8MQ_IOMUXC_ECSPI1_MISO_GPIO5_IO8 0x41
> > + /* MikroBus INT */
> > + MX8MQ_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x41
> > + >;
> > + };
>
> Sorry for asking but whats a MikroBus?
This is a common IO form factor and pinout from MikroElektronika.
https://www.mikroe.com/mikrobus
> > +&uart1 { /* console */
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart1>;
> > + assigned-clocks = <&clk IMX8MQ_CLK_UART1>;
> > + assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
> > + assigned-clock-rates = <25000000>;
>
> It seems that the clock parent reordering apply always if someone is
> using this SoM. So should we do the reordering also for uart2/3 here?
I'm not following you here. Why do you think we need the clock definition for
uart2/uart3 here in the SOM .dtsi?
baruch
_______________________________________________
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/5] ARM: dts: sunxi: Add missing watchdog interrupts
From: Chen-Yu Tsai @ 2019-08-14 4:44 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Rob Herring, linux-arm-kernel, Wim Van Sebroeck, Frank Rowand,
Guenter Roeck
In-Reply-To: <20190813124744.32614-5-mripard@kernel.org>
On Tue, Aug 13, 2019 at 8:48 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The watchdog has an interrupt on all our SoCs, but it wasn't always listed.
> Add it to the devicetree where it's missing.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
On a separate note, the A31 has four watchdogs in the timer block, and
one interrupt for each watchdog. Should we expand the node to encompass
all of them, or add separate nodes for each additional one?
Thanks
_______________________________________________
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 4/5] ARM: dts: sun8i: a83t: Remove the watchdog clock
From: Chen-Yu Tsai @ 2019-08-14 4:38 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Rob Herring, linux-arm-kernel, Wim Van Sebroeck, Frank Rowand,
Guenter Roeck
In-Reply-To: <20190813124744.32614-4-mripard@kernel.org>
On Tue, Aug 13, 2019 at 8:47 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The watchdog binding doesn't define a clock, and it indeed looks like
> there's no explicit clock feeding it.
The diagram on page 133 of the manual shows OSC24M / 750 feeding the watchdog.
Other manuals, such as the A10 one, mention:
Watchdog clock source is OSC24M. if the OSC24M is turned off, the watchdog
will not work.
So in fact it does use a clock signal. It's just that we've been lazy, since
the clock rate is fixed and is always on.
ChenYu
> Let's remove it from our DT.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 523be6611c50..15f8c80f69a5 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -817,7 +817,6 @@
> compatible = "allwinner,sun6i-a31-wdt";
> reg = <0x01c20ca0 0x20>;
> interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&osc24M>;
> };
>
> spdif: spdif@1c21000 {
> --
> 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 next v9 07/11] usb: roles: Add fwnode_usb_role_switch_get() function
From: Chunfeng Yun @ 2019-08-14 4:33 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Mark Rutland, devicetree, Hans de Goede, Greg Kroah-Hartman,
Linus Walleij, linux-usb, linux-kernel, Biju Das,
Badhri Jagan Sridharan, Andy Shevchenko, Rob Herring,
linux-mediatek, Min Guo, Matthias Brugger, Nagarjuna Kristam,
Adam Thomson, linux-arm-kernel, Li Jun
In-Reply-To: <20190813130110.GE4691@kuha.fi.intel.com>
On Tue, 2019-08-13 at 16:01 +0300, Heikki Krogerus wrote:
> On Tue, Aug 13, 2019 at 07:27:10PM +0800, Chunfeng Yun wrote:
> > From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> >
> > The fwnode_usb_role_switch_get() function is exactly the
> > same as usb_role_switch_get(), except that it takes struct
> > fwnode_handle as parameter instead of struct device.
> >
> > Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>
> Why is my SoB replaced with Suggested-by tag in this patch?
Sorry, my mistake, I misunderstand what you mean, you suggest use
Suggested-by in [v8 08/11], but I replaced it all for [06, 07, 08],
will abandon the changes of [06,07] in next version.
>
> thanks,
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add mdio bus sub-node to GMAC
From: Chen-Yu Tsai @ 2019-08-14 4:22 UTC (permalink / raw)
To: Maxime Ripard; +Cc: devicetree, Chen-Yu Tsai, linux-kernel, linux-arm-kernel
From: Chen-Yu Tsai <wens@csie.org>
The DWMAC binding never supported having the Ethernet PHY node as a
direct child to the controller, nor did it support the "phy" property
as a way to specify which Ethernet PHY to use. What seemed to work
was simply the implementation ignoring the "phy" property and instead
probing all addresses on the MDIO bus and using the first available
one.
The recent switch from "phy" to "phy-handle" breaks the assumptions
of the implementation, and does not match what the binding requires.
The binding requires that if an MDIO bus is described, it shall be
a sub-node with the "snps,dwmac-mdio" compatible string.
Add a device node for the MDIO bus, and move the Ethernet PHY node
under it. Also fix up the #address-cells and #size-cells properties
where needed.
Fixes: de332de26d19 ("ARM: dts: sunxi: Switch from phy to phy-handle")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31-colombus.dts | 10 ++++++----
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 16 +++++++++-------
arch/arm/boot/dts/sun6i-a31-i7.dts | 10 ++++++----
arch/arm/boot/dts/sun6i-a31-m9.dts | 10 ++++++----
.../boot/dts/sun6i-a31-mele-a1000g-quad.dts | 10 ++++++----
arch/arm/boot/dts/sun6i-a31.dtsi | 8 ++++++--
arch/arm/boot/dts/sun6i-a31s-cs908.dts | 9 ++++++---
arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 10 ++++++----
.../boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 14 ++++++++------
.../boot/dts/sun7i-a20-bananapi-m1-plus.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-hummingbird.dts | 18 ++++++++++--------
arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-icnova-swac.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-itead-ibox.dts | 2 ++
arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts | 2 --
arch/arm/boot/dts/sun7i-a20-m3.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 10 ++++++----
.../boot/dts/sun7i-a20-olimex-som204-evb.dts | 18 ++++++++++--------
arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts | 10 ++++++----
.../arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 10 ++++++----
.../arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-orangepi.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 10 ++++++----
.../boot/dts/sun7i-a20-wits-pro-a20-dkt.dts | 10 ++++++----
arch/arm/boot/dts/sun7i-a20.dtsi | 8 ++++++--
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 10 ++++++----
arch/arm/boot/dts/sun9i-a80-optimus.dts | 2 ++
arch/arm/boot/dts/sun9i-a80.dtsi | 8 ++++++--
34 files changed, 203 insertions(+), 132 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts b/arch/arm/boot/dts/sun6i-a31-colombus.dts
index 50092b0bd0fe..93a15eaaa8cb 100644
--- a/arch/arm/boot/dts/sun6i-a31-colombus.dts
+++ b/arch/arm/boot/dts/sun6i-a31-colombus.dts
@@ -79,10 +79,6 @@
phy-handle = <&phy1>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c0 {
@@ -104,6 +100,12 @@
};
};
+&mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v0>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 7c611ddbaf2f..049e6ab3cf56 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -156,13 +156,6 @@
phy-handle = <&phy1>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- reset-gpios = <&pio 0 21 GPIO_ACTIVE_LOW>;
- reset-assert-us = <10000>;
- reset-deassert-us = <30000>;
- };
};
&hdmi {
@@ -199,6 +192,15 @@
status = "okay";
};
+&mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ reset-gpios = <&pio 0 21 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <30000>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_dcdc1>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun6i-a31-i7.dts b/arch/arm/boot/dts/sun6i-a31-i7.dts
index ebb0b4710afb..6cc8ccf53d88 100644
--- a/arch/arm/boot/dts/sun6i-a31-i7.dts
+++ b/arch/arm/boot/dts/sun6i-a31-i7.dts
@@ -120,10 +120,6 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -142,6 +138,12 @@
status = "okay";
};
+&mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun6i-a31-m9.dts b/arch/arm/boot/dts/sun6i-a31-m9.dts
index 4910c6ccf2f7..a645c8f4257c 100644
--- a/arch/arm/boot/dts/sun6i-a31-m9.dts
+++ b/arch/arm/boot/dts/sun6i-a31-m9.dts
@@ -88,10 +88,6 @@
phy-mode = "mii";
phy-supply = <®_dldo1>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&ir {
@@ -100,6 +96,12 @@
status = "okay";
};
+&mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_dcdc1>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts b/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts
index 703e1c19b407..648f24746234 100644
--- a/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts
+++ b/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts
@@ -88,10 +88,6 @@
phy-mode = "mii";
phy-supply = <®_dldo1>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&ir {
@@ -100,6 +96,12 @@
status = "okay";
};
+&mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_dcdc1>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 9ddde111f675..8d0db8a2f9d1 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -939,8 +939,12 @@
snps,fixed-burst;
snps,force_sf_dma_mode;
status = "disabled";
- #address-cells = <1>;
- #size-cells = <0>;
+
+ mdio: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
crypto: crypto-engine@1c15000 {
diff --git a/arch/arm/boot/dts/sun6i-a31s-cs908.dts b/arch/arm/boot/dts/sun6i-a31s-cs908.dts
index 6e9ec3f1695e..1d15e15011c6 100644
--- a/arch/arm/boot/dts/sun6i-a31s-cs908.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-cs908.dts
@@ -70,9 +70,6 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&ir {
@@ -81,6 +78,12 @@
status = "okay";
};
+&mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&ohci1 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
index c92779bc8f85..0af48e143b66 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
@@ -119,10 +119,6 @@
phy-mode = "mii";
phy-supply = <®_dldo1>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -160,6 +156,12 @@
};
};
+&mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_dcdc1>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
index e993b2d8ddd0..708caee52425 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
@@ -96,7 +96,15 @@
phy-mode = "rgmii";
phy-supply = <®_dldo1>;
status = "okay";
+};
+
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&s_ir_rx_pin>;
+ status = "okay";
+};
+&mdio {
phy1: ethernet-phy@1 {
reg = <1>;
reset-gpios = <&pio 0 21 GPIO_ACTIVE_LOW>; /* PA21 */
@@ -105,12 +113,6 @@
};
};
-&ir {
- pinctrl-names = "default";
- pinctrl-0 = <&s_ir_rx_pin>;
- status = "okay";
-};
-
&mmc0 {
vmmc-supply = <®_dcdc1>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index c601ecf5ab35..32d5d45a35c0 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -133,10 +133,6 @@
phy-mode = "rgmii";
phy-supply = <®_gmac_3v3>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -171,6 +167,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index c5730b30a15d..bb3987e101c2 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -135,10 +135,6 @@
phy-mode = "rgmii";
phy-supply = <®_gmac_3v3>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -171,6 +167,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 86f4ebb77703..01ccff756996 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -113,10 +113,6 @@
phy-mode = "rgmii";
phy-supply = <®_gmac_3v3>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c0 {
@@ -143,6 +139,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index e322f0f06003..b8203e4ef21c 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -118,10 +118,6 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -161,6 +157,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&ohci0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index a8f7f63fdde1..8c8dee6ea461 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -153,10 +153,6 @@
phy-handle = <&phy1>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -194,6 +190,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-hummingbird.dts b/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
index 322717cb0b9a..3def2a330598 100644
--- a/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
+++ b/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
@@ -104,14 +104,6 @@
phy-mode = "rgmii";
phy-supply = <®_gmac_vdd>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- reset-gpios = <&pio 0 17 GPIO_ACTIVE_LOW>; /* PA17 */
- reset-assert-us = <10000>;
- /* wait 1s after reset, otherwise fail to read phy id */
- reset-deassert-us = <1000000>;
- };
};
&i2c0 {
@@ -145,6 +137,16 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ reset-gpios = <&pio 0 17 GPIO_ACTIVE_LOW>; /* PA17 */
+ reset-assert-us = <10000>;
+ /* wait 1s after reset, otherwise fail to read phy id */
+ reset-deassert-us = <1000000>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v0>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
index 8a610dacb983..358ed5f1b1c1 100644
--- a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
+++ b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
@@ -119,10 +119,6 @@
phy-mode = "mii";
phy-supply = <®_gmac_3v3>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c0 {
@@ -145,6 +141,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts b/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
index a20e91c8dbe5..413505f45a81 100644
--- a/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
+++ b/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
@@ -79,10 +79,6 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c0 {
@@ -99,6 +95,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
index c27567c0b027..946c27278321 100644
--- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
+++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
@@ -100,7 +100,9 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
+};
+&gmac_mdio {
phy1: ethernet-phy@1 {
reg = <1>;
};
diff --git a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
index 3e170cfac86a..17fa8901fc00 100644
--- a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
+++ b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
@@ -123,8 +123,6 @@
phy-mode = "rgmii";
phy-supply = <®_gmac_3v3>;
status = "okay";
- /delete-property/#address-cells;
- /delete-property/#size-cells;
fixed-link {
speed = <1000>;
diff --git a/arch/arm/boot/dts/sun7i-a20-m3.dts b/arch/arm/boot/dts/sun7i-a20-m3.dts
index bde0ef783e71..6bff9e731fc3 100644
--- a/arch/arm/boot/dts/sun7i-a20-m3.dts
+++ b/arch/arm/boot/dts/sun7i-a20-m3.dts
@@ -85,10 +85,6 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c0 {
@@ -111,6 +107,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
index f419b9ee9d1e..6f9c54b8e49a 100644
--- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -114,10 +114,6 @@
phy-handle = <&phy1>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -202,6 +198,12 @@
};
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som204-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som204-evb.dts
index d3d03b7ffb1a..230d62a6b8f1 100644
--- a/arch/arm/boot/dts/sun7i-a20-olimex-som204-evb.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som204-evb.dts
@@ -109,14 +109,6 @@
phy-mode = "rgmii";
phy-supply = <®_vcc3v3>;
status = "okay";
-
- phy3: ethernet-phy@3 {
- reg = <3>;
- reset-gpios = <&pio 0 17 GPIO_ACTIVE_LOW>; /* PA17 */
- reset-assert-us = <10000>;
- /* wait 1s after reset, otherwise fail to read phy id */
- reset-deassert-us = <1000000>;
- };
};
&hdmi {
@@ -161,6 +153,16 @@
status = "okay";
};
+&gmac_mdio {
+ phy3: ethernet-phy@3 {
+ reg = <3>;
+ reset-gpios = <&pio 0 17 GPIO_ACTIVE_LOW>; /* PA17 */
+ reset-assert-us = <10000>;
+ /* wait 1s after reset, otherwise fail to read phy id */
+ reset-deassert-us = <1000000>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
index 70a883276d34..2adbac860119 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
@@ -109,10 +109,6 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -149,6 +145,12 @@
};
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index 0fe657e062a7..9ba62774e89a 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -114,10 +114,6 @@
phy-handle = <&phy1>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -154,6 +150,12 @@
vref-supply = <®_vcc3v0>;
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index 559736961b54..359bd0d5b3b1 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -121,10 +121,6 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -215,6 +211,12 @@
};
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts b/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
index a94ff50bcf73..2e328d2cefc1 100644
--- a/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
+++ b/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
@@ -124,10 +124,6 @@
phy-mode = "rgmii";
phy-supply = <®_gmac_3v3>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -158,6 +154,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi.dts b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
index 956579a10b5f..d75b2e2bab28 100644
--- a/arch/arm/boot/dts/sun7i-a20-orangepi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
@@ -100,10 +100,6 @@
phy-mode = "rgmii";
phy-supply = <®_gmac_3v3>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c0 {
@@ -124,6 +120,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
index 993fb97d19df..fce2f7fcd084 100644
--- a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
+++ b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
@@ -117,10 +117,6 @@
phy-handle = <&phy1>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&hdmi {
@@ -149,6 +145,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
index 02e321523d0e..cc8271d777b8 100644
--- a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
+++ b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
@@ -125,10 +125,6 @@
phy-handle = <&phy1>;
phy-mode = "mii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c0 {
@@ -149,6 +145,12 @@
status = "okay";
};
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
index 9dfe7e2a08cc..3bfae98f3cc3 100644
--- a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
+++ b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
@@ -84,10 +84,6 @@
phy-handle = <&phy1>;
phy-mode = "rgmii";
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c0 {
@@ -110,6 +106,12 @@
#include "axp209.dtsi"
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 9ad8e445b240..651d7fe6b8ba 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1437,8 +1437,12 @@
snps,fixed-burst;
snps,force_sf_dma_mode;
status = "disabled";
- #address-cells = <1>;
- #size-cells = <0>;
+
+ gmac_mdio: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
hstimer@1c60000 {
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 650890b049e2..d3b337b043a1 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -132,10 +132,6 @@
phy-mode = "rgmii";
phy-supply = <®_cldo1>;
status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
&i2c3 {
@@ -144,6 +140,12 @@
status = "okay";
};
+&mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 03ad25534f20..bbc6335e5631 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -127,7 +127,9 @@
phy-mode = "rgmii";
phy-supply = <®_cldo1>;
status = "okay";
+};
+&mdio {
phy1: ethernet-phy@1 {
reg = <1>;
};
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 310cd972ee5b..c34d505c7efe 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -331,8 +331,12 @@
snps,fixed-burst;
snps,force_sf_dma_mode;
status = "disabled";
- #address-cells = <1>;
- #size-cells = <0>;
+
+ mdio: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
ehci0: usb@a00000 {
--
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 v5 08/18] thermal: sun8i: support mod clocks
From: Vasily Khoruzhick @ 2019-08-14 3:01 UTC (permalink / raw)
To: Vasily Khoruzhick, Frank Lee, Mark Rutland, devicetree, Linux PM,
Maxime Ripard, Greg Kroah-Hartman, Daniel Lezcano, linux-kernel,
Eduardo Valentin, Chen-Yu Tsai, Rob Herring, Jonathan.Cameron,
Mauro Carvalho Chehab, rui.zhang, David S. Miller, arm-linux
In-Reply-To: <20190813200623.2dmxcwibuyolnuhh@core.my.home>
On Tue, Aug 13, 2019 at 1:06 PM Ondřej Jirman <megous@megous.com> wrote:
>
> On Mon, Aug 12, 2019 at 04:54:15PM -0700, Vasily Khoruzhick wrote:
> > On Mon, Aug 12, 2019 at 4:46 PM Frank Lee <tiny.windzz@gmail.com> wrote:
> > >
> > > HI Vasily,
> > >
> > > On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > > >
> > > > On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li <tiny.windzz@gmail.com> wrote:
> > > > >
> > > > > H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> > > > > and adds the process of the clock.
> > > > >
> > > > > This is pre-work for supprt it.
> > > > >
> > > > > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > > > > ---
> > > > > drivers/thermal/sun8i_thermal.c | 17 ++++++++++++++++-
> > > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> > > > > index b934bc81eba7..6f4294c2aba7 100644
> > > > > --- a/drivers/thermal/sun8i_thermal.c
> > > > > +++ b/drivers/thermal/sun8i_thermal.c
> > > > > @@ -54,6 +54,7 @@ struct tsensor {
> > > > > };
> > > > >
> > > > > struct ths_thermal_chip {
> > > > > + bool has_mod_clk;
> > > > > int sensor_num;
> > > > > int offset;
> > > > > int scale;
> > > > > @@ -69,6 +70,7 @@ struct ths_device {
> > > > > struct regmap *regmap;
> > > > > struct reset_control *reset;
> > > > > struct clk *bus_clk;
> > > > > + struct clk *mod_clk;
> > > > > struct tsensor sensor[MAX_SENSOR_NUM];
> > > > > };
> > > > >
> > > > > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
> > > > > if (IS_ERR(tmdev->bus_clk))
> > > > > return PTR_ERR(tmdev->bus_clk);
> > > > >
> > > > > + if (tmdev->chip->has_mod_clk) {
> > > > > + tmdev->mod_clk = devm_clk_get(&pdev->dev, "mod");
> > > > > + if (IS_ERR(tmdev->mod_clk))
> > > > > + return PTR_ERR(tmdev->mod_clk);
> > > > > + }
> > > > > +
> > > > > ret = reset_control_deassert(tmdev->reset);
> > > > > if (ret)
> > > > > return ret;
> > > > > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
> > > > > if (ret)
> > > > > goto assert_reset;
> > > > >
> > > > > - ret = sun50i_ths_calibrate(tmdev);
> > > > > + ret = clk_prepare_enable(tmdev->mod_clk);
> > > >
> > > > You have to set rate of modclk before enabling it since you can't rely
> > > > on whatever bootloader left for you.
> > > >
> > > > Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
> > > > ACQ1 are too aggressive and may result in high interrupt rate to the
> > > > point when it may stall RCU. I changed driver a bit to use params from
> > > > Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
> > > > is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
> > > > details.
> > >
> > > Why is the RCU stall happening, is it caused by a deadlock?
> > > Can you provide log information and your configuration?
> > > I am a bit curious.
> >
> > It's not deadlock, I believe it just can't handle that many interrupts
> > when running at lowest CPU frequency. Even with Philipp's settings
> > there's ~20 interrupts a second from ths. I don't remember how many
> > interrupts were there with your settings.
> >
> > Unfortunately there's nothing interesting in backtraces, I'm using
> > Pine64-LTS board.
>
> Recently there was a similar issue, with buggy CCU driver that caused
> CIR interrupts being fired constantly, and it also resulted in RCU
> stalls. Looks like a comon cause of RCU stalls.
>
> THS timing settings probably need to be made specific to the SoC, because
> I noticed that the same settings lead to wildly different timings on
> different SoCs.
>
> It would be good to measure how often ths interrupt fires with this driver
> on various SoCs.
>
> 20 times a second and more sounds like overkill. I'd expect a useful
> range to be at most 5-10 times a second. That should be enough to stop
> overheating the SoC due to suddenly increased load, even without a
> heatsink.
Note that A64 has 3 sensors and each sensor has individual interrupt,
so technically it's 6-7 interrupts per sensor per second
> regards,
> o.
>
> > > Thx,
> > > Yangtao
> > >
> > > >
> > > > [1] https://github.com/anarsoul/linux-2.6/commit/46b8bb0fe2ccd1cd88fa9181a2ecbf79e8d513b2
> > > >
> > > >
> > > > > if (ret)
> > > > > goto bus_disable;
> > > > >
> > > > > + ret = sun50i_ths_calibrate(tmdev);
> > > > > + if (ret)
> > > > > + goto mod_disable;
> > > > > +
> > > > > return 0;
> > > > >
> > > > > +mod_disable:
> > > > > + clk_disable_unprepare(tmdev->mod_clk);
> > > > > bus_disable:
> > > > > clk_disable_unprepare(tmdev->bus_clk);
> > > > > assert_reset:
> > > > > @@ -395,6 +409,7 @@ static int sun8i_ths_remove(struct platform_device *pdev)
> > > > > {
> > > > > struct ths_device *tmdev = platform_get_drvdata(pdev);
> > > > >
> > > > > + clk_disable_unprepare(tmdev->mod_clk);
> > > > > clk_disable_unprepare(tmdev->bus_clk);
> > > > > reset_control_assert(tmdev->reset);
> > > > >
> > > > > --
> > > > > 2.17.1
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > linux-arm-kernel mailing list
> > > > > linux-arm-kernel@lists.infradead.org
> > > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv6 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-14 2:03 UTC (permalink / raw)
To: minghuan.Lian, mingkai.hu, roy.zang, lorenzo.pieralisi, bhelgaas,
linuxppc-dev, linux-pci, linux-arm-kernel, linux-kernel
Cc: Xiaowei Bao
The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
is 32bit, BAR2 and BAR4 is 64bit, this is determined by hardware,
so set the bar_fixed_64bit with 0x14.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- Replace value 0x14 with a macro.
v3:
- No change.
v4:
- send the patch again with '--to'.
v5:
- fix the commit message.
v6:
- remove the [EXT] tag of the $SUBJECT in email.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index be61d96..ca9aa45 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -44,6 +44,7 @@ static const struct pci_epc_features ls_pcie_epc_features = {
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = false,
+ .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
};
static const struct pci_epc_features*
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv6 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
From: Xiaowei Bao @ 2019-08-14 2:03 UTC (permalink / raw)
To: minghuan.Lian, mingkai.hu, roy.zang, lorenzo.pieralisi, bhelgaas,
linuxppc-dev, linux-pci, linux-arm-kernel, linux-kernel
Cc: Xiaowei Bao
In-Reply-To: <20190814020330.12133-1-xiaowei.bao@nxp.com>
Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- No change.
v3:
- modify the commit message.
v4:
- send the patch again with '--to'.
v5:
- No change.
v6:
- remove the [EXT] tag of the $SUBJECT in email.
drivers/pci/controller/dwc/Kconfig | 20 ++++++++++++++++++--
drivers/pci/controller/dwc/Makefile | 3 ++-
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index 6ea778a..869c645 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP
DesignWare core functions to implement the driver.
config PCI_LAYERSCAPE
- bool "Freescale Layerscape PCIe controller"
+ bool "Freescale Layerscape PCIe controller - Host mode"
depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
select MFD_SYSCON
select PCIE_DW_HOST
help
- Say Y here if you want PCIe controller support on Layerscape SoCs.
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Host mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
+
+config PCI_LAYERSCAPE_EP
+ bool "Freescale Layerscape PCIe controller - Endpoint mode"
+ depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
+ depends on PCI_ENDPOINT
+ select PCIE_DW_EP
+ help
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Endpoint mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
config PCI_HISI
depends on OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index b085dfd..824fde7 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
-obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
+obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
--
2.9.5
_______________________________________________
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] clk: imx8mn: fix int pll clk gate
From: peng.fan @ 2019-08-14 1:53 UTC (permalink / raw)
To: mturquette, sboyd, shawnguo, s.hauer
Cc: peng.fan, ping.bai, Anson.Huang, linux-kernel, linux-imx, kernel,
festevam, linux-clk, linux-arm-kernel, abel.vesa
From: Peng Fan <peng.fan@nxp.com>
To Frac pll, the gate shift is 13, however to Int PLL the gate shift
is 11.
Cc: <stable@vger.kernel.org>
Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
---
drivers/clk/imx/clk-imx8mn.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index ecd1062f6847..c5838710e1d8 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -436,12 +436,12 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
clks[IMX8MN_AUDIO_PLL2_OUT] = imx_clk_gate("audio_pll2_out", "audio_pll2_bypass", base + 0x14, 13);
clks[IMX8MN_VIDEO_PLL1_OUT] = imx_clk_gate("video_pll1_out", "video_pll1_bypass", base + 0x28, 13);
clks[IMX8MN_DRAM_PLL_OUT] = imx_clk_gate("dram_pll_out", "dram_pll_bypass", base + 0x50, 13);
- clks[IMX8MN_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out", "gpu_pll_bypass", base + 0x64, 13);
- clks[IMX8MN_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out", "vpu_pll_bypass", base + 0x74, 13);
- clks[IMX8MN_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out", "arm_pll_bypass", base + 0x84, 13);
- clks[IMX8MN_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", "sys_pll1_bypass", base + 0x94, 13);
- clks[IMX8MN_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", "sys_pll2_bypass", base + 0x104, 13);
- clks[IMX8MN_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out", "sys_pll3_bypass", base + 0x114, 13);
+ clks[IMX8MN_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out", "gpu_pll_bypass", base + 0x64, 11);
+ clks[IMX8MN_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out", "vpu_pll_bypass", base + 0x74, 11);
+ clks[IMX8MN_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out", "arm_pll_bypass", base + 0x84, 11);
+ clks[IMX8MN_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", "sys_pll1_bypass", base + 0x94, 11);
+ clks[IMX8MN_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", "sys_pll2_bypass", base + 0x104, 11);
+ clks[IMX8MN_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out", "sys_pll3_bypass", base + 0x114, 11);
/* SYS PLL fixed output */
clks[IMX8MN_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m", "sys_pll1_out", 1, 20);
--
2.16.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: [PATCHv2] PM / devfreq: Add dev_pm_qos support
From: Chanwoo Choi @ 2019-08-14 1:17 UTC (permalink / raw)
To: Leonard Crestez, Viresh Kumar, Saravana Kannan
Cc: Artur Świgoń, linux-pm@vger.kernel.org,
Rafael J. Wysocki, Krzysztof Kozlowski, Lukasz Luba,
Kyungmin Park, MyungJoo Ham, Alexandre Bailon,
cpgs (cpgs@samsung.com), Georgi Djakov,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <a9328230-96f3-6bab-826a-bb199de4ad48@samsung.com>
On 19. 8. 14. 오전 10:06, Chanwoo Choi wrote:
> Hi,
>
> On 19. 8. 13. 오후 8:27, Leonard Crestez wrote:
>> On 13.08.2019 09:10, Chanwoo Choi wrote:
>>> In case of cpufreq, cpufreq.c replace the body of store_min_freq()
>>> and store_max_freq() by using struct dev_pm_qos_request instancce
>>> with dev_pm_qos_update_request().
>>>
>>> If you use the new way with dev_pm_qos_update_request() for
>>> min_freq_store() and max_freq_store(), it doesn't need to
>>> get the final frequency from three candidate frequencies.
>>
>> Yes, I saw that but didn't implement the equivalent for devfreq because
>> it's not clear what there is to gain.
>
> I think that it is clear. Just use the dev_pm_qos_request interface
> for both user input through sysfs and device input with qos request.
> Already PM_QOS has the feature to get the final freuency among
> the multiple request. When use the dev_pm_qos request, the devfreq
> doesn't need to compare between user input and device input with qos.
> It make devfreq core more clear and simple
>
>>
>> Since dev_pm_qos is measured in khz it means that min_freq/max_req on
>> sysfq would lose 3 significant digits, however those digits are probably
>> useless anyway.
>
> I think that it doesn't matter. This patch already considers the this issue
> by using '* 1000'. We can get either KHz or MHz with additional operation.
> I think that it is not problem.
>
>>
>>> In result, We only consider the following two candidate frequencies
>>> as following:
>>> 1. "devfreq->scaling_min_freq" will contain the requirement
>>> from devfreq thermal throttling by OPP interface.
>>
>> It's a bit awkward that the OPPs enable/disable API is not obviously
>> specific to "thermal".
>
> driver/thermal/devfreq_cooling.c uses the OPP interface to enable/disable
> the OPP entries according to the thermal throttling policy.
>
>>
>>> 2. "devfreq->min_freq" will contain the requirements
>>> from both user input through sysfs and the dev_pm_qos_request.
>> According to a comment on a previous version it would be useful to have
>> a separate files for "constraint min/max freq" and "user min/max freq":
>>
>> https://patchwork.kernel.org/patch/11078475/#22805379
>
> Actually, I think that I want to use the only dev_pm_qos_request
> for all external request like devfreq cooling of thermal,
> user input through sysfs and device request with dev_pm_qos_request.
>
> Already, dev_pm_qos_request is designed to consider the multiple requirements.
> We don't need to use the various method (OPP interface, sysfs input, dev_pm_qos)
> because make it more simple and easy.
>
> I think that after finished the review of this patch, I will do refactor the devfreq_cooling.c
> by using the dev_pm_qos_request. Or, if there are some volunteeer,
Sorry, I would withdraw the this opinion about replacing
the OPP enable/disable interface with the dev_pm_qos_request
because even if devfreq-cooling.c needs the 'dev' instance
to use the dev_pm_qos_request method, it is not clear until now.
It needs how to get the device instance of devfreq on device-tree.
Keep discussing without it.
>
>>
>> Combining min/max requests from dev_pm_qos and sysfs would make this
>> harder to implement. I guess user_min_freq could be implemented by
>
> I think that it is not difficult. Just make the different dev_pm_qos_request
> instances. When qos has the multiple request from one more dev_pm_qos_request,
> just get the value by using dev_pm_qos_read_value().
> - a dev_pm_qos_request for user input
> - b dev_pm_qos_request for device request on other device driver
>
>
>> reading back the dev_pm_qos request but there would be no way to
>> implement a qos_min_freq entry.
>
> I don't understand. Just devfreq show the min freq from dev_pm_qos_request
> which contains the all requirement of minimum frequency.
>
> If there are no any request to dev_pm_qos_request, we can just
> get the minimum frequency from dev_pm_qos_request because
> the devfreq device would call the dev_pm_qos_update_request(..., min_freq)
> on the probe time.
>
> If I know the wrong information, please let me know.
>
>
>>
>>>> +static int devfreq_qos_min_notifier_call(struct notifier_block *nb, unsigned long val, void *ptr)
>>>
>>> Please keep the under 80 line if there are no any special reason.
>>
>> OK, will check.
>>
>>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2] PM / devfreq: Add dev_pm_qos support
From: Chanwoo Choi @ 2019-08-14 1:06 UTC (permalink / raw)
To: Leonard Crestez, Viresh Kumar, Saravana Kannan
Cc: Artur Świgoń, linux-pm@vger.kernel.org,
Rafael J. Wysocki, Krzysztof Kozlowski, Lukasz Luba,
Kyungmin Park, MyungJoo Ham, Alexandre Bailon,
cpgs (cpgs@samsung.com), Georgi Djakov,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB7023EB13BB2DE94814B38477EED20@VI1PR04MB7023.eurprd04.prod.outlook.com>
Hi,
On 19. 8. 13. 오후 8:27, Leonard Crestez wrote:
> On 13.08.2019 09:10, Chanwoo Choi wrote:
>> In case of cpufreq, cpufreq.c replace the body of store_min_freq()
>> and store_max_freq() by using struct dev_pm_qos_request instancce
>> with dev_pm_qos_update_request().
>>
>> If you use the new way with dev_pm_qos_update_request() for
>> min_freq_store() and max_freq_store(), it doesn't need to
>> get the final frequency from three candidate frequencies.
>
> Yes, I saw that but didn't implement the equivalent for devfreq because
> it's not clear what there is to gain.
I think that it is clear. Just use the dev_pm_qos_request interface
for both user input through sysfs and device input with qos request.
Already PM_QOS has the feature to get the final freuency among
the multiple request. When use the dev_pm_qos request, the devfreq
doesn't need to compare between user input and device input with qos.
It make devfreq core more clear and simple
>
> Since dev_pm_qos is measured in khz it means that min_freq/max_req on
> sysfq would lose 3 significant digits, however those digits are probably
> useless anyway.
I think that it doesn't matter. This patch already considers the this issue
by using '* 1000'. We can get either KHz or MHz with additional operation.
I think that it is not problem.
>
>> In result, We only consider the following two candidate frequencies
>> as following:
>> 1. "devfreq->scaling_min_freq" will contain the requirement
>> from devfreq thermal throttling by OPP interface.
>
> It's a bit awkward that the OPPs enable/disable API is not obviously
> specific to "thermal".
driver/thermal/devfreq_cooling.c uses the OPP interface to enable/disable
the OPP entries according to the thermal throttling policy.
>
>> 2. "devfreq->min_freq" will contain the requirements
>> from both user input through sysfs and the dev_pm_qos_request.
> According to a comment on a previous version it would be useful to have
> a separate files for "constraint min/max freq" and "user min/max freq":
>
> https://patchwork.kernel.org/patch/11078475/#22805379
Actually, I think that I want to use the only dev_pm_qos_request
for all external request like devfreq cooling of thermal,
user input through sysfs and device request with dev_pm_qos_request.
Already, dev_pm_qos_request is designed to consider the multiple requirements.
We don't need to use the various method (OPP interface, sysfs input, dev_pm_qos)
because make it more simple and easy.
I think that after finished the review of this patch, I will do refactor the devfreq_cooling.c
by using the dev_pm_qos_request. Or, if there are some volunteeer,
>
> Combining min/max requests from dev_pm_qos and sysfs would make this
> harder to implement. I guess user_min_freq could be implemented by
I think that it is not difficult. Just make the different dev_pm_qos_request
instances. When qos has the multiple request from one more dev_pm_qos_request,
just get the value by using dev_pm_qos_read_value().
- a dev_pm_qos_request for user input
- b dev_pm_qos_request for device request on other device driver
> reading back the dev_pm_qos request but there would be no way to
> implement a qos_min_freq entry.
I don't understand. Just devfreq show the min freq from dev_pm_qos_request
which contains the all requirement of minimum frequency.
If there are no any request to dev_pm_qos_request, we can just
get the minimum frequency from dev_pm_qos_request because
the devfreq device would call the dev_pm_qos_update_request(..., min_freq)
on the probe time.
If I know the wrong information, please let me know.
>
>>> +static int devfreq_qos_min_notifier_call(struct notifier_block *nb, unsigned long val, void *ptr)
>>
>> Please keep the under 80 line if there are no any special reason.
>
> OK, will check.
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
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] iommu/arm-smmu-v3: add nr_ats_masters to avoid unnecessary operations
From: Leizhen (ThunderTown) @ 2019-08-14 0:41 UTC (permalink / raw)
To: Will Deacon, John Garry
Cc: jean-philippe, Jean-Philippe Brucker, Joerg Roedel, linux-kernel,
iommu, Robin Murphy, linux-arm-kernel
In-Reply-To: <20190813171039.y64wslo4dzgyis3e@willie-the-truck>
On 2019/8/14 1:10, Will Deacon wrote:
> On Mon, Aug 12, 2019 at 11:42:17AM +0100, John Garry wrote:
>> On 01/08/2019 13:20, Zhen Lei wrote:
>>> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a
>>> smmu domain does not contain any ats master, the operations of
>>> arm_smmu_atc_inv_to_cmd() and lock protection in arm_smmu_atc_inv_domain()
>>> are always executed. This will impact performance, especially in
>>> multi-core and stress scenarios. For my FIO test scenario, about 8%
>>> performance reduced.
>>>
>>> In fact, we can use a atomic member to record how many ats masters the
>>> smmu contains. And check that without traverse the list and check all
>>> masters one by one in the lock protection.
>>>
>>
>> Hi Will, Robin, Jean-Philippe,
>>
>> Can you kindly check this issue? We have seen a signifigant performance
>> regression here.
>
> Sorry, John: Robin and Jean-Philippe are off at the moment and I've been
> swamped dealing with the arm64 queue. I'll try to get to this tomorrow.
Hi, all:
I found my patch have some mistake, see below. I'm sorry I didn't see this coupling.
I'm preparing v2.
> @@ -1915,10 +1921,10 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
> list_del(&master->domain_head);
> spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
>
> - master->domain = NULL;
> arm_smmu_install_ste_for_dev(master);
"master->domain = NULL" is needed in arm_smmu_install_ste_for_dev().
>
> arm_smmu_disable_ats(master);
> + master->domain = NULL;
> }
>
> Will
>
> .
>
_______________________________________________
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] coresight: Serialize enabling/disabling a link device.
From: Yabin Cui @ 2019-08-14 0:35 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin
Cc: Yabin Cui, linux-kernel, linux-arm-kernel
In-Reply-To: <CANLsYkzH-ZWV3qF4p4Yvfy3EfBvZUYyDH+SDdUyuS3fGw9h_Fw@mail.gmail.com>
> The patch isn't difficult to do but does go deeper in each link
> drivers (ETF, funnel, replicator). Let me know if you are not
> comfortable with the idea and I will see what I can do on my side.
I am comfortable with the idea. I chose to add lock in coresight_enable_link() just because it
is the smallest change. But a refactor probably is better for maintainance.
Feel free to upload a new patch fixing the problem. I can help to test it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64/efi: Move variable assignments after SECTIONS
From: Kees Cook @ 2019-08-13 23:04 UTC (permalink / raw)
To: Will Deacon
Cc: Fangrui Song, Ard Biesheuvel, Catalin Marinas, linux-kernel,
clang-built-linux, Peter Smith, Nathan Chancellor,
linux-arm-kernel
It seems that LLVM's linker does not correctly handle variable assignments
involving section positions that are updated during the SECTIONS
parsing. Commit aa69fb62bea1 ("arm64/efi: Mark __efistub_stext_offset as
an absolute symbol explicitly") ran into this too, but found a different
workaround.
However, this was not enough, as other variables were also miscalculated
which manifested as boot failures under UEFI where __efistub__end was
not taking the correct _end value (they should be the same):
$ ld.lld -EL -maarch64elf --no-undefined -X -shared \
-Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
-o vmlinux.lld -T poc.lds --whole-archive vmlinux.o && \
readelf -Ws vmlinux.lld | egrep '\b(__efistub_|)_end\b'
368272: ffff000002218000 0 NOTYPE LOCAL HIDDEN 38 __efistub__end
368322: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 38 _end
$ aarch64-linux-gnu-ld.bfd -EL -maarch64elf --no-undefined -X -shared \
-Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
-o vmlinux.bfd -T poc.lds --whole-archive vmlinux.o && \
readelf -Ws vmlinux.bfd | egrep '\b(__efistub_|)_end\b'
338124: ffff000012318000 0 NOTYPE LOCAL DEFAULT ABS __efistub__end
383812: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 15325 _end
To work around this, all of the __efistub_-prefixed variable assignments
need to be moved after the linker script's SECTIONS entry. As it turns
out, this also solves the problem fixed in commit aa69fb62bea1, so those
changes are reverted here.
Link: https://github.com/ClangBuiltLinux/linux/issues/634
Link: https://bugs.llvm.org/show_bug.cgi?id=42990
Signed-off-by: Kees Cook <keescook@chromium.org>
---
arch/arm64/kernel/image-vars.h | 51 +++++++++++++++++++++++++++++++++
arch/arm64/kernel/image.h | 42 ---------------------------
arch/arm64/kernel/vmlinux.lds.S | 2 ++
3 files changed, 53 insertions(+), 42 deletions(-)
create mode 100644 arch/arm64/kernel/image-vars.h
diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
new file mode 100644
index 000000000000..25a2a9b479c2
--- /dev/null
+++ b/arch/arm64/kernel/image-vars.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Linker script variables to be set after section resolution, as
+ * ld.lld does not like variables assigned before SECTIONS is processed.
+ */
+#ifndef __ARM64_KERNEL_IMAGE_VARS_H
+#define __ARM64_KERNEL_IMAGE_VARS_H
+
+#ifndef LINKER_SCRIPT
+#error This file should only be included in vmlinux.lds.S
+#endif
+
+#ifdef CONFIG_EFI
+
+__efistub_stext_offset = stext - _text;
+
+/*
+ * The EFI stub has its own symbol namespace prefixed by __efistub_, to
+ * isolate it from the kernel proper. The following symbols are legally
+ * accessed by the stub, so provide some aliases to make them accessible.
+ * Only include data symbols here, or text symbols of functions that are
+ * guaranteed to be safe when executed at another offset than they were
+ * linked at. The routines below are all implemented in assembler in a
+ * position independent manner
+ */
+__efistub_memcmp = __pi_memcmp;
+__efistub_memchr = __pi_memchr;
+__efistub_memcpy = __pi_memcpy;
+__efistub_memmove = __pi_memmove;
+__efistub_memset = __pi_memset;
+__efistub_strlen = __pi_strlen;
+__efistub_strnlen = __pi_strnlen;
+__efistub_strcmp = __pi_strcmp;
+__efistub_strncmp = __pi_strncmp;
+__efistub_strrchr = __pi_strrchr;
+__efistub___flush_dcache_area = __pi___flush_dcache_area;
+
+#ifdef CONFIG_KASAN
+__efistub___memcpy = __pi_memcpy;
+__efistub___memmove = __pi_memmove;
+__efistub___memset = __pi_memset;
+#endif
+
+__efistub__text = _text;
+__efistub__end = _end;
+__efistub__edata = _edata;
+__efistub_screen_info = screen_info;
+
+#endif
+
+#endif /* __ARM64_KERNEL_IMAGE_VARS_H */
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index 2b85c0d6fa3d..c7d38c660372 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -65,46 +65,4 @@
DEFINE_IMAGE_LE64(_kernel_offset_le, TEXT_OFFSET); \
DEFINE_IMAGE_LE64(_kernel_flags_le, __HEAD_FLAGS);
-#ifdef CONFIG_EFI
-
-/*
- * Use ABSOLUTE() to avoid ld.lld treating this as a relative symbol:
- * https://github.com/ClangBuiltLinux/linux/issues/561
- */
-__efistub_stext_offset = ABSOLUTE(stext - _text);
-
-/*
- * The EFI stub has its own symbol namespace prefixed by __efistub_, to
- * isolate it from the kernel proper. The following symbols are legally
- * accessed by the stub, so provide some aliases to make them accessible.
- * Only include data symbols here, or text symbols of functions that are
- * guaranteed to be safe when executed at another offset than they were
- * linked at. The routines below are all implemented in assembler in a
- * position independent manner
- */
-__efistub_memcmp = __pi_memcmp;
-__efistub_memchr = __pi_memchr;
-__efistub_memcpy = __pi_memcpy;
-__efistub_memmove = __pi_memmove;
-__efistub_memset = __pi_memset;
-__efistub_strlen = __pi_strlen;
-__efistub_strnlen = __pi_strnlen;
-__efistub_strcmp = __pi_strcmp;
-__efistub_strncmp = __pi_strncmp;
-__efistub_strrchr = __pi_strrchr;
-__efistub___flush_dcache_area = __pi___flush_dcache_area;
-
-#ifdef CONFIG_KASAN
-__efistub___memcpy = __pi_memcpy;
-__efistub___memmove = __pi_memmove;
-__efistub___memset = __pi_memset;
-#endif
-
-__efistub__text = _text;
-__efistub__end = _end;
-__efistub__edata = _edata;
-__efistub_screen_info = screen_info;
-
-#endif
-
#endif /* __ARM64_KERNEL_IMAGE_H */
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 7fa008374907..803b24d2464a 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -245,6 +245,8 @@ SECTIONS
HEAD_SYMBOLS
}
+#include "image-vars.h"
+
/*
* The HYP init code and ID map text can't be longer than a page each,
* and should not cross a page boundary.
--
2.17.1
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* linux-next: build failure after merge of the arm-soc tree
From: Stephen Rothwell @ 2019-08-13 22:49 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, ARM
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1162 bytes --]
Hi all,
After merging the arm-soc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
arch/arm/Kconfig:720: syntax error
arch/arm/Kconfig:719: invalid statement
arch/arm/Kconfig:720: can't open file "arch/arm/mach-ks8695/Kconfig"
Caused by commit
eb4f78f8b8cb ("ARM: remove ks8695 platform")
I applied the following patch for today
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2019 08:46:39 +1000
Subject: [PATCH] arm-soc: fix up bad rebase?
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm/Kconfig | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1597c542dc4f..769a853c8c6e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -716,12 +716,6 @@ source "arch/arm/mach-ixp4xx/Kconfig"
source "arch/arm/mach-keystone/Kconfig"
-<<<<<<< HEAD
-source "arch/arm/mach-ks8695/Kconfig"
-=======
-source "arch/arm/mach-lpc32xx/Kconfig"
->>>>>>> ARM: remove ks8695 platform
-
source "arch/arm/mach-mediatek/Kconfig"
source "arch/arm/mach-meson/Kconfig"
--
2.20.1
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Rob Herring @ 2019-08-13 22:14 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland, devicetree, Ulf Hansson, linux-aspeed, Ryan Chen,
linux-mmc, Adrian Hunter, linux-kernel@vger.kernel.org,
Joel Stanley,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190807003629.2974-2-andrew@aj.id.au>
On Tue, Aug 6, 2019 at 6:38 PM Andrew Jeffery <andrew@aj.id.au> wrote:
>
> The ASPEED SD/SDIO/MMC controller exposes two slots implementing the
> SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
> data bus if only a single slot is enabled.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>
> ---
> v4:
> * Make use of mmc-controller.yaml
> * Document sdhci,auto-cmd12
>
> v2:
> * Fix compatible enums
> * Add AST2600 compatibles
> * Describe #address-cells / #size-cells
> ---
> .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 105 ++++++++++++++++++
> 1 file changed, 105 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
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: linux-next: Fixes tags need some work in the arm-soc tree
From: Stephen Rothwell @ 2019-08-13 21:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexandre Torgue, Linux Kernel Mailing List,
Linux Next Mailing List, Olof Johansson, Fabrice Gasnier, ARM
In-Reply-To: <CAK8P3a2q1mShg-EQhiAFUOAET8UEMHfLJV-+HoLTaSQY+M7yBQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]
Hi Arnd,
On Tue, 13 Aug 2019 21:35:58 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Aug 13, 2019 at 4:28 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> >
> > Please do not split Fixes tags over more than one line. Also, please
> > keep them with the rest of the other tags.
>
> Thanks for the report. How bad is this? Should I undo the merge and
> wait for an updated pull request?
Its probably ok to leave as long as lessons are learnt :-)
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: watchdog: sun4i: Add the watchdog interrupts
From: Rob Herring @ 2019-08-13 21:32 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Maxime Ripard,
linux-kernel@vger.kernel.org, Chen-Yu Tsai,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Wim Van Sebroeck, Frank Rowand, Guenter Roeck
In-Reply-To: <20190813124744.32614-3-mripard@kernel.org>
On Tue, Aug 13, 2019 at 6:47 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The Allwinner watchdog has an interrupt, either shared or dedicated
> depending on the SoC, that has been described in some DT, but not all of
> them.
>
> The binding is also completely missing that description. Let's add that
> property to be consistent.
I'm fine with fixing errors like this in the conversion patch.
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../bindings/watchdog/allwinner,sun4i-a10-wdt.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
Either way:
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 2/5] dt-bindings: watchdog: Convert Allwinner watchdog to a schema
From: Rob Herring @ 2019-08-13 21:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Maxime Ripard,
linux-kernel@vger.kernel.org, Chen-Yu Tsai,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Wim Van Sebroeck, Frank Rowand, Guenter Roeck
In-Reply-To: <20190813124744.32614-2-mripard@kernel.org>
On Tue, Aug 13, 2019 at 6:47 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The Allwinner SoCs have a watchdog supported in Linux, with a matching
> Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../watchdog/allwinner,sun4i-a10-wdt.yaml | 50 +++++++++++++++++++
> .../bindings/watchdog/sunxi-wdt.txt | 22 --------
> 2 files changed, 50 insertions(+), 22 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
> delete mode 100644 Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
> new file mode 100644
> index 000000000000..93df27ec1664
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/watchdog/allwinner,sun4i-a10-wdt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner A10 Watchdog Device Tree Bindings
> +
> +maintainers:
> + - Chen-Yu Tsai <wens@csie.org>
> + - Maxime Ripard <maxime.ripard@bootlin.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: allwinner,sun4i-a10-wdt
> + - const: allwinner,sun6i-a31-wdt
> + - items:
> + - const: allwinner,sun50i-a64-wdt
> + - const: allwinner,sun6i-a31-wdt
> + - items:
> + - const: allwinner,sun50i-h6-wdt
> + - const: allwinner,sun6i-a31-wdt
> + - items:
> + - const: allwinner,suniv-f1c100s-wdt
> + - const: allwinner,sun4i-a10-wdt
> +
> + reg:
> + maxItems: 1
> +
> + timeout-sec:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Contains the watchdog timeout in seconds.
Can you do a common watchdog schema to include with this and the node
name at least.
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] coresight: Serialize enabling/disabling a link device.
From: Mathieu Poirier @ 2019-08-13 21:30 UTC (permalink / raw)
To: Yabin Cui
Cc: Alexander Shishkin, Linux Kernel Mailing List, linux-arm-kernel,
Suzuki K Poulose
In-Reply-To: <20190812195725.11793-1-yabinc@google.com>
Hi Yabin,
On Mon, 12 Aug 2019 at 13:57, Yabin Cui <yabinc@google.com> wrote:
>
> When tracing etm data of multiple threads on multiple cpus through perf
> interface, some link devices are shared between paths of different cpus.
> It creates race conditions when different cpus wants to enable/disable
> the same link device at the same time.
>
> Example 1:
> Two cpus want to enable different ports of a coresight funnel, thus
> calling the funnel enable operation at the same time. But the funnel
> enable operation isn't reentrantable.
>
> Example 2:
> For an enabled coresight dynamic replicator with refcnt=1, one cpu wants
> to disable it, while another cpu wants to enable it. Ideally we still have
> an enabled replicator with refcnt=1 at the end. But in reality the result
> is uncertain.
>
> Since coresight devices claim themselves when enabled for self-hosted
> usage, the race conditions above usually make the link devices not usable
> after many cycles.
>
> To fix the race conditions, this patch adds a spinlock to serialize
> enabling/disabling a link device.
>
> Fixes: a06ae8609b3d ("coresight: add CoreSight core layer framework")
When "a06ae8609b3d" was introduced there wasn't any race condition as
all access to links were guarded by the coresight_mutex in
coresight_enable/disable() functions. The problem was really
introduced when integration with the perf subsystem was added, though
it would have been really difficult to trigger due to the HW
topologies available at the time.
So, to be exact:
Fixes: 0bcbf2e30ff2 ("coresight: etm-perf: new PMU driver for ETM tracers")
> Signed-off-by: Yabin Cui <yabinc@google.com>
> ---
>
> v2 -> v3: extend lock range to protect csdev->enable for link devices.
> Add fixes tag.
>
> ---
> drivers/hwtracing/coresight/coresight.c | 12 +++++++++++-
> include/linux/coresight.h | 3 +++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> index 55db77f6410b..c069ada151b8 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -256,6 +256,7 @@ static int coresight_enable_link(struct coresight_device *csdev,
> int ret;
> int link_subtype;
> int refport, inport, outport;
> + unsigned long flags;
>
> if (!parent || !child)
> return -EINVAL;
> @@ -274,17 +275,20 @@ static int coresight_enable_link(struct coresight_device *csdev,
> if (refport < 0)
> return refport;
>
> + spin_lock_irqsave(&csdev->spinlock, flags);
> if (atomic_inc_return(&csdev->refcnt[refport]) == 1) {
> if (link_ops(csdev)->enable) {
> ret = link_ops(csdev)->enable(csdev, inport, outport);
> if (ret) {
> atomic_dec(&csdev->refcnt[refport]);
> + spin_unlock_irqrestore(&csdev->spinlock, flags);
> return ret;
> }
> }
> }
>
> csdev->enable = true;
> + spin_unlock_irqrestore(&csdev->spinlock, flags);
>
> return 0;
> }
> @@ -296,6 +300,7 @@ static void coresight_disable_link(struct coresight_device *csdev,
> int i, nr_conns;
> int link_subtype;
> int refport, inport, outport;
> + unsigned long flags;
>
> if (!parent || !child)
> return;
> @@ -315,16 +320,20 @@ static void coresight_disable_link(struct coresight_device *csdev,
> nr_conns = 1;
> }
>
> + spin_lock_irqsave(&csdev->spinlock, flags);
> if (atomic_dec_return(&csdev->refcnt[refport]) == 0) {
> if (link_ops(csdev)->disable)
> link_ops(csdev)->disable(csdev, inport, outport);
> }
>
> for (i = 0; i < nr_conns; i++)
> - if (atomic_read(&csdev->refcnt[i]) != 0)
> + if (atomic_read(&csdev->refcnt[i]) != 0) {
> + spin_unlock_irqrestore(&csdev->spinlock, flags);
> return;
> + }
>
> csdev->enable = false;
> + spin_unlock_irqrestore(&csdev->spinlock, flags);
> }
>
> static int coresight_enable_source(struct coresight_device *csdev, u32 mode)
> @@ -1225,6 +1234,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
> csdev->subtype = desc->subtype;
> csdev->ops = desc->ops;
> csdev->orphan = false;
> + spin_lock_init(&csdev->spinlock);
Your patch will work and I see the problem it is addressing. I
contemplated doing exactly the same thing for sink devices but
couldn't due to memory management issues. In the end I moved the
reference counting inside each driver where it could be guarded by
drvdata->spinlock.
I suggest to do the same thing for links to avoid dealing with two
different ways of doing things. As such we could get rid of the
"refport" thing I never liked in coresight_enable_link(), invariably
call link_ops()->enable() and let each driver deal with its own port
management. The same logic applies to the disable() path.
The patch isn't difficult to do but does go deeper in each link
drivers (ETF, funnel, replicator). Let me know if you are not
comfortable with the idea and I will see what I can do on my side.
Thanks,
Mathieu
>
> csdev->dev.type = &coresight_dev_type[desc->type];
> csdev->dev.groups = desc->groups;
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index a2b68823717b..dd28d9ab841d 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -9,6 +9,7 @@
> #include <linux/device.h>
> #include <linux/perf_event.h>
> #include <linux/sched.h>
> +#include <linux/spinlock.h>
>
> /* Peripheral id registers (0xFD0-0xFEC) */
> #define CORESIGHT_PERIPHIDR4 0xfd0
> @@ -153,6 +154,7 @@ struct coresight_connection {
> * activated but not yet enabled. Enabling for a _sink_
> * appens when a source has been selected for that it.
> * @ea: Device attribute for sink representation under PMU directory.
> + * @spinlock: Serialize enabling/disabling this device.
> */
> struct coresight_device {
> struct coresight_platform_data *pdata;
> @@ -166,6 +168,7 @@ struct coresight_device {
> /* sink specific fields */
> bool activated; /* true only if a sink is part of a path */
> struct dev_ext_attribute *ea;
> + spinlock_t spinlock;
> };
>
> /*
> --
> 2.23.0.rc1.153.gdeed80330f-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: mfd: Convert Allwinner GPADC bindings to a schema
From: Rob Herring @ 2019-08-13 21:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Maxime Ripard,
linux-kernel@vger.kernel.org, Chen-Yu Tsai,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Wim Van Sebroeck, Frank Rowand, Guenter Roeck
In-Reply-To: <20190813124744.32614-1-mripard@kernel.org>
On Tue, Aug 13, 2019 at 6:47 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The Allwinner SoCs have an embedded GPADC that is doing thermal reading as
> well, supported in Linux, with a matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../iio/adc/allwinner,sun8i-a33-ths.yaml | 43 +++++++++++
> .../bindings/mfd/allwinner,sun4i-a10-ts.yaml | 76 +++++++++++++++++++
> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 59 --------------
> 3 files changed, 119 insertions(+), 59 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml
> create mode 100644 Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
> delete mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: media: Convert Allwinner A10 IR to a schema
From: Rob Herring @ 2019-08-13 21:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Young, Maxime Ripard,
linux-kernel@vger.kernel.org, Chen-Yu Tsai, Mauro Carvalho Chehab,
Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <20190813124513.31413-2-mripard@kernel.org>
On Tue, Aug 13, 2019 at 6:45 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The older Allwinner SoCs have a IR receiver supported in Linux, with a
> matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../media/allwinner,sun4i-a10-ir.yaml | 80 +++++++++++++++++++
> .../devicetree/bindings/media/sunxi-ir.txt | 35 --------
> 2 files changed, 80 insertions(+), 35 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
> delete mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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