* Re: [PATCH] gpio: pl061: Fix the issue failed to register the ACPI interruption
From: Linus Walleij @ 2019-08-14 9:04 UTC (permalink / raw)
To: Wei Xu
Cc: Salil Mehta, jinying, Tangkunshan, John Garry,
linux-kernel@vger.kernel.org, Shameerali Kolothum Thodi, Linuxarm,
open list:GPIO SUBSYSTEM, huangdaode, Jonathan Cameron,
Liguozhu (Kenneth), Zhangyi ac,
linux-arm-kernel@lists.infradead.org, Shiju Jose
In-Reply-To: <5D514D6F.4090904@hisilicon.com>
Hi Wei,
thanks for your patch!
This doesn't apply for my "devel" branch, can you rebase
on this:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
We have moved some ACPI headers around recently.
On Mon, Aug 12, 2019 at 1:28 PM Wei Xu <xuwei5@hisilicon.com> wrote:
> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
> attached to the pl061 acpi node to register interruption.
Makes sense.
> Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
I doubt this is a regression since I haven't seen anyone use this
gpiochip with ACPI before.
Please rename the patch "gpio: pl061: Add ACPI support" unless
you can convince me it worked without changes before.
Please include some ACPI people on review of this. From
MAINTAINERS:
ACPI
M: "Rafael J. Wysocki" <rjw@rjwysocki.net>
M: Len Brown <lenb@kernel.org>
L: linux-acpi@vger.kernel.org
I would also include Andy Shevchenko and Mika Westerberg for
the GPIO aspects.
Thanks!
Linus Walleij
_______________________________________________
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-sunxi] [PATCH v5 14/15] ASoc: sun4i-i2s: Add 20, 24 and 32 bit support
From: Code Kipper @ 2019-08-14 9:03 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Linux-ALSA, linux-kernel, Chen-Yu Tsai, Liam Girdwood,
Andrea Venturi (pers), linux-sunxi, Mark Brown, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <4297791.2mJM636zur@jernej-laptop>
On Wed, 14 Aug 2019 at 10:28, Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi!
>
> Dne sreda, 14. avgust 2019 ob 08:08:53 CEST je codekipper@gmail.com
> napisal(a):
> > From: Marcus Cooper <codekipper@gmail.com>
> >
> > Extend the functionality of the driver to include support of 20 and
> > 24 bits per sample for the earlier SoCs.
> >
> > Newer SoCs can also handle 32bit samples.
> >
> > Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> > ---
> > sound/soc/sunxi/sun4i-i2s.c | 21 +++++++++++++++++++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> > index a71969167053..d3c8789f70bb 100644
> > --- a/sound/soc/sunxi/sun4i-i2s.c
> > +++ b/sound/soc/sunxi/sun4i-i2s.c
> > @@ -690,6 +690,11 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> > *substream, case 16:
> > width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> > break;
> > + case 20:
> > + case 24:
> > + case 32:
>
> params_physical_width() returns 32 also for 20 and 24-bit formats, so drop 20
> and 24.
ACK
>
> Best regards,
> Jernej
>
> > + width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> > + break;
> > default:
> > dev_err(dai->dev, "Unsupported physical sample width:
> %d\n",
> > params_physical_width(params));
> > @@ -1015,6 +1020,13 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai
> > *dai) return 0;
> > }
> >
> > +#define SUN4I_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
> > + SNDRV_PCM_FMTBIT_S20_LE | \
> > + SNDRV_PCM_FMTBIT_S24_LE)
> > +
> > +#define SUN8I_FORMATS (SUN4I_FORMATS | \
> > + SNDRV_PCM_FMTBIT_S32_LE)
> > +
> > static struct snd_soc_dai_driver sun4i_i2s_dai = {
> > .probe = sun4i_i2s_dai_probe,
> > .capture = {
> > @@ -1022,14 +1034,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
> > .channels_min = 2,
> > .channels_max = 2,
> > .rates = SNDRV_PCM_RATE_8000_192000,
> > - .formats = SNDRV_PCM_FMTBIT_S16_LE,
> > + .formats = SUN4I_FORMATS,
> > },
> > .playback = {
> > .stream_name = "Playback",
> > .channels_min = 2,
> > .channels_max = 2,
> > .rates = SNDRV_PCM_RATE_8000_192000,
> > - .formats = SNDRV_PCM_FMTBIT_S16_LE,
> > + .formats = SUN4I_FORMATS,
> > },
> > .ops = &sun4i_i2s_dai_ops,
> > .symmetric_rates = 1,
> > @@ -1505,6 +1517,11 @@ static int sun4i_i2s_probe(struct platform_device
> > *pdev) goto err_pm_disable;
> > }
> >
> > + if (i2s->variant->has_fmt_set_lrck_period) {
> > + soc_dai->playback.formats = SUN8I_FORMATS;
> > + soc_dai->capture.formats = SUN8I_FORMATS;
> > + }
> > +
> > if (!of_property_read_u32(pdev->dev.of_node,
> > "allwinner,playback-channels",
> &val)) {
> > if (val >= 2 && val <= 8)
>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
From: Sean Young @ 2019-08-14 9:03 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Chen-Yu Tsai, Rob Herring, mchehab, Frank Rowand,
linux-arm-kernel, linux-media
In-Reply-To: <20190813124513.31413-1-mripard@kernel.org>
On Tue, Aug 13, 2019 at 02:45:12PM +0200, Maxime Ripard wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The RC controllers have a bunch of generic properties that are needed in a
> device tree. Add a YAML schemas for those.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../devicetree/bindings/media/rc.txt | 118 +--------------
> .../devicetree/bindings/media/rc.yaml | 135 ++++++++++++++++++
> 2 files changed, 136 insertions(+), 117 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/rc.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt
> index d3e7a012bfda..be629f7fa77e 100644
> --- a/Documentation/devicetree/bindings/media/rc.txt
> +++ b/Documentation/devicetree/bindings/media/rc.txt
> @@ -1,117 +1 @@
> -The following properties are common to the infrared remote controllers:
> -
> -- linux,rc-map-name: string, specifies the scancode/key mapping table
> - defined in-kernel for the remote controller. Support values are:
> - * "rc-adstech-dvb-t-pci"
> - * "rc-alink-dtu-m"
> - * "rc-anysee"
> - * "rc-apac-viewcomp"
> - * "rc-asus-pc39"
> - * "rc-asus-ps3-100"
> - * "rc-ati-tv-wonder-hd-600"
> - * "rc-ati-x10"
> - * "rc-avermedia-a16d"
> - * "rc-avermedia-cardbus"
> - * "rc-avermedia-dvbt"
> - * "rc-avermedia-m135a"
> - * "rc-avermedia-m733a-rm-k6"
> - * "rc-avermedia-rm-ks"
> - * "rc-avermedia"
> - * "rc-avertv-303"
> - * "rc-azurewave-ad-tu700"
> - * "rc-behold-columbus"
> - * "rc-behold"
> - * "rc-budget-ci-old"
> - * "rc-cec"
> - * "rc-cinergy-1400"
> - * "rc-cinergy"
> - * "rc-delock-61959"
> - * "rc-dib0700-nec"
> - * "rc-dib0700-rc5"
> - * "rc-digitalnow-tinytwin"
> - * "rc-digittrade"
> - * "rc-dm1105-nec"
> - * "rc-dntv-live-dvbt-pro"
> - * "rc-dntv-live-dvb-t"
> - * "rc-dtt200u"
> - * "rc-dvbsky"
> - * "rc-empty"
> - * "rc-em-terratec"
> - * "rc-encore-enltv2"
> - * "rc-encore-enltv-fm53"
> - * "rc-encore-enltv"
> - * "rc-evga-indtube"
> - * "rc-eztv"
> - * "rc-flydvb"
> - * "rc-flyvideo"
> - * "rc-fusionhdtv-mce"
> - * "rc-gadmei-rm008z"
> - * "rc-geekbox"
> - * "rc-genius-tvgo-a11mce"
> - * "rc-gotview7135"
> - * "rc-hauppauge"
> - * "rc-imon-mce"
> - * "rc-imon-pad"
> - * "rc-iodata-bctv7e"
> - * "rc-it913x-v1"
> - * "rc-it913x-v2"
> - * "rc-kaiomy"
> - * "rc-kworld-315u"
> - * "rc-kworld-pc150u"
> - * "rc-kworld-plus-tv-analog"
> - * "rc-leadtek-y04g0051"
> - * "rc-lirc"
> - * "rc-lme2510"
> - * "rc-manli"
> - * "rc-medion-x10"
> - * "rc-medion-x10-digitainer"
> - * "rc-medion-x10-or2x"
> - * "rc-msi-digivox-ii"
> - * "rc-msi-digivox-iii"
> - * "rc-msi-tvanywhere-plus"
> - * "rc-msi-tvanywhere"
> - * "rc-nebula"
> - * "rc-nec-terratec-cinergy-xs"
> - * "rc-norwood"
> - * "rc-npgtech"
> - * "rc-pctv-sedna"
> - * "rc-pinnacle-color"
> - * "rc-pinnacle-grey"
> - * "rc-pinnacle-pctv-hd"
> - * "rc-pixelview-new"
> - * "rc-pixelview"
> - * "rc-pixelview-002t"
> - * "rc-pixelview-mk12"
> - * "rc-powercolor-real-angel"
> - * "rc-proteus-2309"
> - * "rc-purpletv"
> - * "rc-pv951"
> - * "rc-hauppauge"
> - * "rc-rc5-tv"
> - * "rc-rc6-mce"
> - * "rc-real-audio-220-32-keys"
> - * "rc-reddo"
> - * "rc-snapstream-firefly"
> - * "rc-streamzap"
> - * "rc-tbs-nec"
> - * "rc-technisat-ts35"
> - * "rc-technisat-usb2"
> - * "rc-terratec-cinergy-c-pci"
> - * "rc-terratec-cinergy-s2-hd"
> - * "rc-terratec-cinergy-xs"
> - * "rc-terratec-slim"
> - * "rc-terratec-slim-2"
> - * "rc-tevii-nec"
> - * "rc-tivo"
> - * "rc-total-media-in-hand"
> - * "rc-total-media-in-hand-02"
> - * "rc-trekstor"
> - * "rc-tt-1500"
> - * "rc-twinhan-dtv-cab-ci"
> - * "rc-twinhan1027"
> - * "rc-videomate-k100"
> - * "rc-videomate-s350"
> - * "rc-videomate-tv-pvr"
> - * "rc-winfast"
> - * "rc-winfast-usbii-deluxe"
> - * "rc-su3000"
> +This file has been moved to rc.yaml.
> diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml
> new file mode 100644
> index 000000000000..19b28e7edf9c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/rc.yaml
> @@ -0,0 +1,135 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/rc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic Infrared Remote Controller Device Tree Bindings
> +
> +maintainers:
> + - Mauro Carvalho Chehab <mchehab@kernel.org>
> + - Sean Young <sean@mess.org>
> +
> +properties:
> + $nodename:
> + pattern: "^ir(@[a-f0-9]+)?$"
> +
> + linux,rc-map-name:
> + description:
> + Specifies the scancode/key mapping table defined in-kernel for
> + the remote controller.
> + allOf:
> + - $ref: '/schemas/types.yaml#/definitions/string'
> + - enum:
> + - rc-adstech-dvb-t-pci
> + - rc-alink-dtu-m
> + - rc-anysee
> + - rc-apac-viewcomp
> + - rc-asus-pc39
> + - rc-asus-ps3-100
> + - rc-ati-tv-wonder-hd-600
> + - rc-ati-x10
> + - rc-avermedia
> + - rc-avermedia-a16d
> + - rc-avermedia-cardbus
> + - rc-avermedia-dvbt
> + - rc-avermedia-m135a
> + - rc-avermedia-m733a-rm-k6
> + - rc-avermedia-rm-ks
> + - rc-avertv-303
> + - rc-azurewave-ad-tu700
> + - rc-behold
> + - rc-behold-columbus
> + - rc-budget-ci-old
> + - rc-cec
> + - rc-cinergy
> + - rc-cinergy-1400
> + - rc-delock-61959
> + - rc-dib0700-nec
> + - rc-dib0700-rc5
> + - rc-digitalnow-tinytwin
> + - rc-digittrade
> + - rc-dm1105-nec
> + - rc-dntv-live-dvb-t
> + - rc-dntv-live-dvbt-pro
> + - rc-dtt200u
> + - rc-dvbsky
> + - rc-em-terratec
> + - rc-empty
> + - rc-encore-enltv
> + - rc-encore-enltv-fm53
> + - rc-encore-enltv2
> + - rc-evga-indtube
> + - rc-eztv
> + - rc-flydvb
> + - rc-flyvideo
> + - rc-fusionhdtv-mce
> + - rc-gadmei-rm008z
> + - rc-geekbox
> + - rc-genius-tvgo-a11mce
> + - rc-gotview7135
> + - rc-hauppauge
> + - rc-imon-mce
> + - rc-imon-pad
> + - rc-iodata-bctv7e
> + - rc-it913x-v1
> + - rc-it913x-v2
> + - rc-kaiomy
> + - rc-kworld-315u
> + - rc-kworld-pc150u
> + - rc-kworld-plus-tv-analog
> + - rc-leadtek-y04g0051
> + - rc-lirc
> + - rc-lme2510
> + - rc-manli
> + - rc-medion-x10
> + - rc-medion-x10-digitainer
> + - rc-medion-x10-or2x
> + - rc-msi-digivox-ii
> + - rc-msi-digivox-iii
> + - rc-msi-tvanywhere
> + - rc-msi-tvanywhere-plus
> + - rc-nebula
> + - rc-nec-terratec-cinergy-xs
> + - rc-norwood
> + - rc-npgtech
> + - rc-pctv-sedna
> + - rc-pinnacle-color
> + - rc-pinnacle-grey
> + - rc-pinnacle-pctv-hd
> + - rc-pixelview
> + - rc-pixelview-002t
> + - rc-pixelview-mk12
> + - rc-pixelview-new
> + - rc-powercolor-real-angel
> + - rc-proteus-2309
> + - rc-purpletv
> + - rc-pv951
> + - rc-rc5-tv
> + - rc-rc6-mce
> + - rc-real-audio-220-32-keys
> + - rc-reddo
> + - rc-snapstream-firefly
> + - rc-streamzap
> + - rc-su3000
> + - rc-tbs-nec
> + - rc-technisat-ts35
> + - rc-technisat-usb2
> + - rc-terratec-cinergy-c-pci
> + - rc-terratec-cinergy-s2-hd
> + - rc-terratec-cinergy-xs
> + - rc-terratec-slim
> + - rc-terratec-slim-2
> + - rc-tevii-nec
> + - rc-tivo
> + - rc-total-media-in-hand
> + - rc-total-media-in-hand-02
> + - rc-trekstor
> + - rc-tt-1500
> + - rc-twinhan-dtv-cab-ci
> + - rc-twinhan1027
> + - rc-videomate-k100
> + - rc-videomate-s350
> + - rc-videomate-tv-pvr
> + - rc-winfast
> + - rc-winfast-usbii-deluxe
The list of keymaps is out of date. Might as well fix it up at now?
Thanks
Sean
# awk -F ' ' '/define RC_MAP_/ { gsub(/"/, "", $3); print " - " $3 }' < include/media/rc-map.h
- rc-adstech-dvb-t-pci
- rc-alink-dtu-m
- rc-anysee
- rc-apac-viewcomp
- rc-astrometa-t2hybrid
- rc-asus-pc39
- rc-asus-ps3-100
- rc-ati-tv-wonder-hd-600
- rc-ati-x10
- rc-avermedia-a16d
- rc-avermedia-cardbus
- rc-avermedia-dvbt
- rc-avermedia-m135a
- rc-avermedia-m733a-rm-k6
- rc-avermedia-rm-ks
- rc-avermedia
- rc-avertv-303
- rc-azurewave-ad-tu700
- rc-behold-columbus
- rc-behold
- rc-budget-ci-old
- rc-cec
- rc-cinergy-1400
- rc-cinergy
- rc-d680-dmb
- rc-delock-61959
- rc-dib0700-nec
- rc-dib0700-rc5
- rc-digitalnow-tinytwin
- rc-digittrade
- rc-dm1105-nec
- rc-dntv-live-dvbt-pro
- rc-dntv-live-dvb-t
- rc-dtt200u
- rc-dvbsky
- rc-dvico-mce
- rc-dvico-portable
- rc-empty
- rc-em-terratec
- rc-encore-enltv2
- rc-encore-enltv-fm53
- rc-encore-enltv
- rc-evga-indtube
- rc-eztv
- rc-flydvb
- rc-flyvideo
- rc-fusionhdtv-mce
- rc-gadmei-rm008z
- rc-geekbox
- rc-genius-tvgo-a11mce
- rc-gotview7135
- rc-hauppauge
- rc-hisi-poplar
- rc-hisi-tv-demo
- rc-imon-mce
- rc-imon-pad
- rc-imon-rsc
- rc-iodata-bctv7e
- rc-it913x-v1
- rc-it913x-v2
- rc-kaiomy
- rc-kworld-315u
- rc-kworld-pc150u
- rc-kworld-plus-tv-analog
- rc-leadtek-y04g0051
- rc-lme2510
- rc-manli
- rc-medion-x10
- rc-medion-x10-digitainer
- rc-medion-x10-or2x
- rc-msi-digivox-ii
- rc-msi-digivox-iii
- rc-msi-tvanywhere-plus
- rc-msi-tvanywhere
- rc-nebula
- rc-nec-terratec-cinergy-xs
- rc-norwood
- rc-npgtech
- rc-pctv-sedna
- rc-pinnacle-color
- rc-pinnacle-grey
- rc-pinnacle-pctv-hd
- rc-pixelview-new
- rc-pixelview
- rc-pixelview-002t
- rc-pixelview-mk12
- rc-powercolor-real-angel
- rc-proteus-2309
- rc-purpletv
- rc-pv951
- rc-hauppauge
- rc-rc5-tv
- rc-rc6-mce
- rc-real-audio-220-32-keys
- rc-reddo
- rc-snapstream-firefly
- rc-streamzap
- rc-tango
- rc-tbs-nec
- rc-technisat-ts35
- rc-technisat-usb2
- rc-terratec-cinergy-c-pci
- rc-terratec-cinergy-s2-hd
- rc-terratec-cinergy-xs
- rc-terratec-slim
- rc-terratec-slim-2
- rc-tevii-nec
- rc-tivo
- rc-total-media-in-hand
- rc-total-media-in-hand-02
- rc-trekstor
- rc-tt-1500
- rc-twinhan-dtv-cab-ci
- rc-twinhan1027
- rc-videomate-k100
- rc-videomate-s350
- rc-videomate-tv-pvr
- rc-winfast
- rc-winfast-usbii-deluxe
- rc-su3000
- rc-xbox-dvd
- rc-zx-irdec
_______________________________________________
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-sunxi] [PATCH v5 15/15] ASoC: sun4i-i2s: Adjust regmap settings
From: Code Kipper @ 2019-08-14 9:02 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Linux-ALSA, linux-kernel, Chen-Yu Tsai, Liam Girdwood,
Andrea Venturi (pers), linux-sunxi, Mark Brown, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <3741744.8c7tOhJ1tT@jernej-laptop>
On Wed, 14 Aug 2019 at 10:38, Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi!
>
> Dne sreda, 14. avgust 2019 ob 08:08:54 CEST je codekipper@gmail.com
> napisal(a):
> > From: Marcus Cooper <codekipper@gmail.com>
> >
> > Bypass the regmap cache when flushing the i2s FIFOs and modify the tables
> > to reflect this.
> >
> > Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> > ---
> > sound/soc/sunxi/sun4i-i2s.c | 31 ++++++++++---------------------
> > 1 file changed, 10 insertions(+), 21 deletions(-)
> >
> > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> > index d3c8789f70bb..ecfc1ed79379 100644
> > --- a/sound/soc/sunxi/sun4i-i2s.c
> > +++ b/sound/soc/sunxi/sun4i-i2s.c
> > @@ -876,9 +876,11 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai,
> > unsigned int fmt) static void sun4i_i2s_start_capture(struct sun4i_i2s
> > *i2s)
> > {
> > /* Flush RX FIFO */
> > + regcache_cache_bypass(i2s->regmap, true);
> > regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> > SUN4I_I2S_FIFO_CTRL_FLUSH_RX,
> > SUN4I_I2S_FIFO_CTRL_FLUSH_RX);
> > + regcache_cache_bypass(i2s->regmap, false);
>
> Did you try with regmap_write_bits() instead? This function will
> unconditionally write bits so it's nicer solution, because you don't have to
> use regcache_cache_bypass().
I didn't....with all the rework I've avoided messing with this change.
Now that the dust
has settled, I can go back to look at this.
Thanks,
CK
>
> >
> > /* Clear RX counter */
> > regmap_write(i2s->regmap, SUN4I_I2S_RX_CNT_REG, 0);
> > @@ -897,9 +899,11 @@ static void sun4i_i2s_start_capture(struct sun4i_i2s
> > *i2s) static void sun4i_i2s_start_playback(struct sun4i_i2s *i2s)
> > {
> > /* Flush TX FIFO */
> > + regcache_cache_bypass(i2s->regmap, true);
> > regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> > SUN4I_I2S_FIFO_CTRL_FLUSH_TX,
> > SUN4I_I2S_FIFO_CTRL_FLUSH_TX);
> > + regcache_cache_bypass(i2s->regmap, false);
>
> Ditto.
>
> >
> > /* Clear TX counter */
> > regmap_write(i2s->regmap, SUN4I_I2S_TX_CNT_REG, 0);
> > @@ -1053,13 +1057,7 @@ static const struct snd_soc_component_driver
> > sun4i_i2s_component = {
> >
> > static bool sun4i_i2s_rd_reg(struct device *dev, unsigned int reg)
> > {
> > - switch (reg) {
> > - case SUN4I_I2S_FIFO_TX_REG:
> > - return false;
> > -
> > - default:
> > - return true;
> > - }
> > + return true;
>
> Why did you change this? Manual mentions that SUN4I_I2S_FIFO_TX_REG is write-
> only register. Even if it can be read, then it's better to remove whole
> function, which will automatically mean that all registers can be read.
>
>
> > }
> >
> > static bool sun4i_i2s_wr_reg(struct device *dev, unsigned int reg)
> > @@ -1078,6 +1076,8 @@ static bool sun4i_i2s_volatile_reg(struct device *dev,
> > unsigned int reg) {
> > switch (reg) {
> > case SUN4I_I2S_FIFO_RX_REG:
> > + case SUN4I_I2S_FIFO_TX_REG:
> > + case SUN4I_I2S_FIFO_STA_REG:
> > case SUN4I_I2S_INT_STA_REG:
> > case SUN4I_I2S_RX_CNT_REG:
> > case SUN4I_I2S_TX_CNT_REG:
>
> SUN4I_I2S_FIFO_CTRL_REG should be put here, because it has two bits which
> returns to 0 immediately after they are set to 1.
>
> Best regards,
> Jernej
>
> > @@ -1088,23 +1088,12 @@ static bool sun4i_i2s_volatile_reg(struct device
> > *dev, unsigned int reg) }
> > }
> >
> > -static bool sun8i_i2s_rd_reg(struct device *dev, unsigned int reg)
> > -{
> > - switch (reg) {
> > - case SUN8I_I2S_FIFO_TX_REG:
> > - return false;
> > -
> > - default:
> > - return true;
> > - }
> > -}
> > -
> > static bool sun8i_i2s_volatile_reg(struct device *dev, unsigned int reg)
> > {
> > if (reg == SUN8I_I2S_INT_STA_REG)
> > return true;
> > if (reg == SUN8I_I2S_FIFO_TX_REG)
> > - return false;
> > + return true;
> >
> > return sun4i_i2s_volatile_reg(dev, reg);
> > }
> > @@ -1175,7 +1164,7 @@ static const struct regmap_config
> > sun8i_i2s_regmap_config = { .reg_defaults = sun8i_i2s_reg_defaults,
> > .num_reg_defaults = ARRAY_SIZE(sun8i_i2s_reg_defaults),
> > .writeable_reg = sun4i_i2s_wr_reg,
> > - .readable_reg = sun8i_i2s_rd_reg,
> > + .readable_reg = sun4i_i2s_rd_reg,
> > .volatile_reg = sun8i_i2s_volatile_reg,
> > };
> >
> > @@ -1188,7 +1177,7 @@ static const struct regmap_config
> > sun50i_i2s_regmap_config = { .reg_defaults = sun50i_i2s_reg_defaults,
> > .num_reg_defaults = ARRAY_SIZE(sun50i_i2s_reg_defaults),
> > .writeable_reg = sun4i_i2s_wr_reg,
> > - .readable_reg = sun8i_i2s_rd_reg,
> > + .readable_reg = sun4i_i2s_rd_reg,
> > .volatile_reg = sun8i_i2s_volatile_reg,
> > };
>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: CPUfreq fail on rk3399-firefly (was: next/master boot: 285 boots: 16 failed, 264 passed with 3 offline, 1 untried/unknown, 1 conflict (next-20190718))
From: Heiko Stuebner @ 2019-08-14 9:01 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-rockchip, Mark Brown, linux-next, linux-arm-kernel,
kernel-build-reports
In-Reply-To: <7hmugdynmk.fsf@baylibre.com>
Hi,
Am Dienstag, 13. August 2019, 19:35:31 CEST schrieb Kevin Hilman:
> [ resent with correct addr for linux-rockchip list ]
>
> Mark Brown <broonie@kernel.org> writes:
>
> > On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
> >
> > Today's -next started failing to boot defconfig on rk3399-firefly:
> >
> >> arm64:
> >
> >> defconfig:
> >> gcc-8:
> >> rk3399-firefly: 1 failed lab
> >
> > It hits a BUG() trying to set up cpufreq:
> >
> > [ 87.381606] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
> > [ 87.393244] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
> > [ 87.469777] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz
> > [ 87.488595] cpu cpu4: _generic_set_opp_clk_only: failed to set clock rate: -22
> > [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
> > [ 87.495335] ------------[ cut here ]------------
> > [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
> > [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> >
> > I'm struggling to see anything relevant in the diff from yesterday, the
> > unlisted frequency warnings were there in the logs yesterday but no oops
> > and I'm not seeing any changes in cpufreq, clk or anything relevant
> > looking.
> >
> > Full bootlog and other info can be found here:
> >
> > https://kernelci.org/boot/id/5d302d8359b51498d049e983/
>
> I confirm that disabling CPUfreq in the defconfig (CONFIG_CPU_FREQ=n)
> makes the firefly board start working again.
>
> Note that the default defconfig enables the "performance" CPUfreq
> governor as the default governor, so during kernel boot, it will always
> switch to the max frequency.
>
> For fun, I set the default governor to "userspace" so the kernel
> wouldn't make any OPP changes, and that leads to a slightly more
> informative splat[1]
>
> There is still an OPP change happening because the detected OPP is not
> one that's listed in the table, so it tries to change to a listed OPP
> and fails in the bowels of clk_set_rate()
Though I think that might only be a symptom as well.
Both the PLL setting code as well as the actual cpu-clock implementation
is unchanged since 2017 (and runs just fine on all boards in my farm).
One source for these issues is often the regulator supplying the cpu
going haywire - aka the voltage not matching the opp.
As in this error-case it's CPU4 being set, this would mean it might
be the big cluster supplied by the external syr825 (fan5355 clone)
that might act up. In the Firefly-rk3399 case this is even stranger.
There is a discrepancy between the "fcs,suspend-voltage-selector"
between different bootloader versions (how the selection-pin is set up),
so the kernel might actually write his requested voltage to the wrong
register (not the one for actual voltage, but the second set used for
the suspend voltage).
Did you by chance swap bootloaders at some point in recent past?
I'd assume [2] might actually be the same issue last year, though
the CI-logs are not available anymore it seems.
Could you try to set the vdd_cpu_b regulator to disabled, so that
cpufreq for this cluster defers and see what happens?
I don't really have a Firefly in my boardfarm, so I let 5.3-rc run on
a Theobroma Puma which has the same regulator setup as the Firefly
and all including the performance governor did run nicely, so it really
looks like some sort of Firefly specific issue.
Heiko
> [1] https://termbin.com/3oum
[2] https://lkml.org/lkml/2018/6/19/1167
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: aspeed: Remove mention of deprecated compatibles
From: Linus Walleij @ 2019-08-14 8:41 UTC (permalink / raw)
To: Lee Jones
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-aspeed, Andrew Jeffery, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Rob Herring, Joel Stanley, Linux ARM
In-Reply-To: <20190812101504.GF26727@dell>
On Mon, Aug 12, 2019 at 12:15 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 05 Aug 2019, Linus Walleij wrote:
>
> > On Wed, Jul 24, 2019 at 10:13 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > > Guide readers away from using the aspeed,g[45].* compatible patterns.
> > >
> > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> >
> > Patch applied to the pinctrl tree.
>
> With my Ack?
Sorry no. :( Was I too trigger-happy?
Usually I take Rob's ACK as authoritative for anything under
Documentation/devicetree but if you have concerns about the
patch from an MFD point of view I will revert it pending further
discussion.
Yours,
Linus Walleij
_______________________________________________
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-sunxi] [PATCH v5 15/15] ASoC: sun4i-i2s: Adjust regmap settings
From: Jernej Škrabec @ 2019-08-14 8:37 UTC (permalink / raw)
To: linux-sunxi, codekipper
Cc: alsa-devel, linux-kernel, lgirdwood, be17068, wens, broonie,
maxime.ripard, linux-arm-kernel
In-Reply-To: <20190814060854.26345-16-codekipper@gmail.com>
Hi!
Dne sreda, 14. avgust 2019 ob 08:08:54 CEST je codekipper@gmail.com
napisal(a):
> From: Marcus Cooper <codekipper@gmail.com>
>
> Bypass the regmap cache when flushing the i2s FIFOs and modify the tables
> to reflect this.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
> sound/soc/sunxi/sun4i-i2s.c | 31 ++++++++++---------------------
> 1 file changed, 10 insertions(+), 21 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index d3c8789f70bb..ecfc1ed79379 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -876,9 +876,11 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai,
> unsigned int fmt) static void sun4i_i2s_start_capture(struct sun4i_i2s
> *i2s)
> {
> /* Flush RX FIFO */
> + regcache_cache_bypass(i2s->regmap, true);
> regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> SUN4I_I2S_FIFO_CTRL_FLUSH_RX,
> SUN4I_I2S_FIFO_CTRL_FLUSH_RX);
> + regcache_cache_bypass(i2s->regmap, false);
Did you try with regmap_write_bits() instead? This function will
unconditionally write bits so it's nicer solution, because you don't have to
use regcache_cache_bypass().
>
> /* Clear RX counter */
> regmap_write(i2s->regmap, SUN4I_I2S_RX_CNT_REG, 0);
> @@ -897,9 +899,11 @@ static void sun4i_i2s_start_capture(struct sun4i_i2s
> *i2s) static void sun4i_i2s_start_playback(struct sun4i_i2s *i2s)
> {
> /* Flush TX FIFO */
> + regcache_cache_bypass(i2s->regmap, true);
> regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> SUN4I_I2S_FIFO_CTRL_FLUSH_TX,
> SUN4I_I2S_FIFO_CTRL_FLUSH_TX);
> + regcache_cache_bypass(i2s->regmap, false);
Ditto.
>
> /* Clear TX counter */
> regmap_write(i2s->regmap, SUN4I_I2S_TX_CNT_REG, 0);
> @@ -1053,13 +1057,7 @@ static const struct snd_soc_component_driver
> sun4i_i2s_component = {
>
> static bool sun4i_i2s_rd_reg(struct device *dev, unsigned int reg)
> {
> - switch (reg) {
> - case SUN4I_I2S_FIFO_TX_REG:
> - return false;
> -
> - default:
> - return true;
> - }
> + return true;
Why did you change this? Manual mentions that SUN4I_I2S_FIFO_TX_REG is write-
only register. Even if it can be read, then it's better to remove whole
function, which will automatically mean that all registers can be read.
> }
>
> static bool sun4i_i2s_wr_reg(struct device *dev, unsigned int reg)
> @@ -1078,6 +1076,8 @@ static bool sun4i_i2s_volatile_reg(struct device *dev,
> unsigned int reg) {
> switch (reg) {
> case SUN4I_I2S_FIFO_RX_REG:
> + case SUN4I_I2S_FIFO_TX_REG:
> + case SUN4I_I2S_FIFO_STA_REG:
> case SUN4I_I2S_INT_STA_REG:
> case SUN4I_I2S_RX_CNT_REG:
> case SUN4I_I2S_TX_CNT_REG:
SUN4I_I2S_FIFO_CTRL_REG should be put here, because it has two bits which
returns to 0 immediately after they are set to 1.
Best regards,
Jernej
> @@ -1088,23 +1088,12 @@ static bool sun4i_i2s_volatile_reg(struct device
> *dev, unsigned int reg) }
> }
>
> -static bool sun8i_i2s_rd_reg(struct device *dev, unsigned int reg)
> -{
> - switch (reg) {
> - case SUN8I_I2S_FIFO_TX_REG:
> - return false;
> -
> - default:
> - return true;
> - }
> -}
> -
> static bool sun8i_i2s_volatile_reg(struct device *dev, unsigned int reg)
> {
> if (reg == SUN8I_I2S_INT_STA_REG)
> return true;
> if (reg == SUN8I_I2S_FIFO_TX_REG)
> - return false;
> + return true;
>
> return sun4i_i2s_volatile_reg(dev, reg);
> }
> @@ -1175,7 +1164,7 @@ static const struct regmap_config
> sun8i_i2s_regmap_config = { .reg_defaults = sun8i_i2s_reg_defaults,
> .num_reg_defaults = ARRAY_SIZE(sun8i_i2s_reg_defaults),
> .writeable_reg = sun4i_i2s_wr_reg,
> - .readable_reg = sun8i_i2s_rd_reg,
> + .readable_reg = sun4i_i2s_rd_reg,
> .volatile_reg = sun8i_i2s_volatile_reg,
> };
>
> @@ -1188,7 +1177,7 @@ static const struct regmap_config
> sun50i_i2s_regmap_config = { .reg_defaults = sun50i_i2s_reg_defaults,
> .num_reg_defaults = ARRAY_SIZE(sun50i_i2s_reg_defaults),
> .writeable_reg = sun4i_i2s_wr_reg,
> - .readable_reg = sun8i_i2s_rd_reg,
> + .readable_reg = sun4i_i2s_rd_reg,
> .volatile_reg = sun8i_i2s_volatile_reg,
> };
_______________________________________________
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/7] [RFC] ARM: remove Intel iop33x and iop13xx support
From: Linus Walleij @ 2019-08-14 8:36 UTC (permalink / raw)
To: Martin Michlmayr
Cc: Peter Teichmann, Arnd Bergmann, open list:GPIO SUBSYSTEM,
Linux Kernel Mailing List, soc, Russell King, Bartosz Golaszewski,
Vinod Koul, linux-i2c, dmaengine, Dan Williams, Linux ARM
In-Reply-To: <20190812094456.GI10598@jirafa.cyrius.com>
On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote:
> As Arnd points out, Debian used to have support for various iop32x
> devices. While Debian hasn't supported iop32x in a number of years,
> these devices are still usable and in use (RMK being a prime example).
I suppose it could be a good idea to add support for iop32x to
OpenWrt and/or OpenEmbedded, both of which support some
pretty constrained systems. I am personally using these
distributions to support elder ARM hardware these days.
Just my €0.01
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/8] arm64: memory: Fix virt_addr_valid() using __is_lm_address()
From: Will Deacon @ 2019-08-14 8:32 UTC (permalink / raw)
To: Steve Capper
Cc: Mark Rutland, Ard Biesheuvel, Catalin Marinas, Qian Cai,
Andrey Konovalov, Geert Uytterhoeven, nd, linux-arm-kernel
In-Reply-To: <20190813191124.GA21406@capper-ampere.manchester.arm.com>
On Tue, Aug 13, 2019 at 07:11:26PM +0000, Steve Capper wrote:
> On Tue, Aug 13, 2019 at 09:09:16PM +0300, Ard Biesheuvel wrote:
> > On Tue, 13 Aug 2019 at 20:02, Will Deacon <will@kernel.org> wrote:
> > >
> > > virt_addr_valid() is intended to test whether or not the passed address
> > > is a valid linear map address. Unfortunately, it relies on
> > > _virt_addr_is_linear() which is broken because it assumes the linear
> > > map is at the top of the address space, which it no longer is.
> > >
> > > Reimplement virt_addr_valid() using __is_lm_address() and remove
> > > _virt_addr_is_linear() entirely. At the same time, ensure we evaluate
> > > the macro parameter only once and move it within the __ASSEMBLY__ block.
> > >
> > > Reported-by: Qian Cai <cai@lca.pw>
> > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Fixes: 14c127c957c1 ("arm64: mm: Flip kernel VA space")
> > > Signed-off-by: Will Deacon <will@kernel.org>
> > > ---
> > > arch/arm64/include/asm/memory.h | 14 +++++++-------
> > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index afaf512c0e1b..442ab861cab8 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -244,9 +244,9 @@ static inline const void *__tag_set(const void *addr, u8 tag)
> > > /*
> > > * The linear kernel range starts in the middle of the virtual adddress
> > > * space.
> >
> > This is no longer true either.
> >
>
> Whoops agreed.
Bah, stupid comment. Dunno how I missed that when I was editing it. I'll
change "starts in the middle" to be "starts at the bottom".
We can look at the wasted VA space issue as part of a seperate series,
since I'd rather not hold the current patches up on that.
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: [linux-sunxi] [PATCH v5 14/15] ASoc: sun4i-i2s: Add 20, 24 and 32 bit support
From: Jernej Škrabec @ 2019-08-14 8:28 UTC (permalink / raw)
To: linux-sunxi, codekipper
Cc: alsa-devel, linux-kernel, lgirdwood, be17068, wens, broonie,
maxime.ripard, linux-arm-kernel
In-Reply-To: <20190814060854.26345-15-codekipper@gmail.com>
Hi!
Dne sreda, 14. avgust 2019 ob 08:08:53 CEST je codekipper@gmail.com
napisal(a):
> From: Marcus Cooper <codekipper@gmail.com>
>
> Extend the functionality of the driver to include support of 20 and
> 24 bits per sample for the earlier SoCs.
>
> Newer SoCs can also handle 32bit samples.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
> sound/soc/sunxi/sun4i-i2s.c | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index a71969167053..d3c8789f70bb 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -690,6 +690,11 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream, case 16:
> width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> break;
> + case 20:
> + case 24:
> + case 32:
params_physical_width() returns 32 also for 20 and 24-bit formats, so drop 20
and 24.
Best regards,
Jernej
> + width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + break;
> default:
> dev_err(dai->dev, "Unsupported physical sample width:
%d\n",
> params_physical_width(params));
> @@ -1015,6 +1020,13 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai
> *dai) return 0;
> }
>
> +#define SUN4I_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
> + SNDRV_PCM_FMTBIT_S20_LE | \
> + SNDRV_PCM_FMTBIT_S24_LE)
> +
> +#define SUN8I_FORMATS (SUN4I_FORMATS | \
> + SNDRV_PCM_FMTBIT_S32_LE)
> +
> static struct snd_soc_dai_driver sun4i_i2s_dai = {
> .probe = sun4i_i2s_dai_probe,
> .capture = {
> @@ -1022,14 +1034,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
> .channels_min = 2,
> .channels_max = 2,
> .rates = SNDRV_PCM_RATE_8000_192000,
> - .formats = SNDRV_PCM_FMTBIT_S16_LE,
> + .formats = SUN4I_FORMATS,
> },
> .playback = {
> .stream_name = "Playback",
> .channels_min = 2,
> .channels_max = 2,
> .rates = SNDRV_PCM_RATE_8000_192000,
> - .formats = SNDRV_PCM_FMTBIT_S16_LE,
> + .formats = SUN4I_FORMATS,
> },
> .ops = &sun4i_i2s_dai_ops,
> .symmetric_rates = 1,
> @@ -1505,6 +1517,11 @@ static int sun4i_i2s_probe(struct platform_device
> *pdev) goto err_pm_disable;
> }
>
> + if (i2s->variant->has_fmt_set_lrck_period) {
> + soc_dai->playback.formats = SUN8I_FORMATS;
> + soc_dai->capture.formats = SUN8I_FORMATS;
> + }
> +
> if (!of_property_read_u32(pdev->dev.of_node,
> "allwinner,playback-channels",
&val)) {
> if (val >= 2 && val <= 8)
_______________________________________________
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-sunxi] [PATCH v5 12/15] ASoC: sun4i-i2s: Add multi-lane functionality
From: Jernej Škrabec @ 2019-08-14 8:27 UTC (permalink / raw)
To: linux-sunxi, codekipper
Cc: alsa-devel, linux-kernel, lgirdwood, be17068, wens, broonie,
maxime.ripard, linux-arm-kernel
In-Reply-To: <20190814060854.26345-13-codekipper@gmail.com>
Hi!
Dne sreda, 14. avgust 2019 ob 08:08:51 CEST je codekipper@gmail.com
napisal(a):
> From: Marcus Cooper <codekipper@gmail.com>
>
> The i2s block supports multi-lane i2s output however this functionality
> is only possible in earlier SoCs where the pins are exposed and for
> the i2s block used for HDMI audio on the later SoCs.
>
> To enable this functionality, an optional property has been added to
> the bindings.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
> sound/soc/sunxi/sun4i-i2s.c | 28 +++++++++++++++++++++++++---
> 1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index a8d98696fe7c..a020c3b372a8 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -23,7 +23,7 @@
>
> #define SUN4I_I2S_CTRL_REG 0x00
> #define SUN4I_I2S_CTRL_SDO_EN_MASK GENMASK(11, 8)
> -#define SUN4I_I2S_CTRL_SDO_EN(sdo) BIT(8 +
(sdo))
> +#define SUN4I_I2S_CTRL_SDO_EN(lines) (((1 << lines) - 1)
<< 8)
> #define SUN4I_I2S_CTRL_MODE_MASK BIT(5)
> #define SUN4I_I2S_CTRL_MODE_SLAVE (1 << 5)
> #define SUN4I_I2S_CTRL_MODE_MASTER (0 << 5)
> @@ -614,6 +614,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream, struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
> int sr, wss, channels;
> u32 width;
> + int lines;
>
> channels = params_channels(params);
> if (channels != 2) {
> @@ -622,6 +623,13 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream, return -EINVAL;
> }
>
> + lines = (channels + 1) / 2;
> +
> + /* Enable the required output lines */
> + regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG,
> + SUN4I_I2S_CTRL_SDO_EN_MASK,
> + SUN4I_I2S_CTRL_SDO_EN(lines));
As Maxime said before, this doesn't work for TDM. Maybe we can skip this for
now, until we agree on method how to describe channel allocation?
> +
> if (i2s->variant->has_chcfg) {
> regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
>
SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK,
> @@ -1389,9 +1397,10 @@ static int sun4i_i2s_init_regmap_fields(struct device
> *dev, static int sun4i_i2s_probe(struct platform_device *pdev)
> {
> struct sun4i_i2s *i2s;
> + struct snd_soc_dai_driver *soc_dai;
> struct resource *res;
> void __iomem *regs;
> - int irq, ret;
> + int irq, ret, val;
>
> i2s = devm_kzalloc(&pdev->dev, sizeof(*i2s), GFP_KERNEL);
> if (!i2s)
> @@ -1456,6 +1465,19 @@ static int sun4i_i2s_probe(struct platform_device
> *pdev) i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG;
> i2s->capture_dma_data.maxburst = 8;
>
> + soc_dai = devm_kmemdup(&pdev->dev, &sun4i_i2s_dai,
> + sizeof(*soc_dai), GFP_KERNEL);
> + if (!soc_dai) {
> + ret = -ENOMEM;
> + goto err_pm_disable;
> + }
> +
> + if (!of_property_read_u32(pdev->dev.of_node,
> + "allwinner,playback-channels",
&val)) {
> + if (val >= 2 && val <= 8)
> + soc_dai->playback.channels_max = val;
> + }
> +
Rather than inventing new DT properties, I would rather have multiple
snd_soc_dai_driver structures, depending on capabilities of that particular
I2S block. That way we avoid some boilerplate code as can be seen here and
it's IMO more transparent.
In this case, I would make another snd_soc_dai_driver struct for H3, which has
channel_max property set to 8 and from patch 14, additional supported formats.
Best regards,
Jernej
> pm_runtime_enable(&pdev->dev);
> if (!pm_runtime_enabled(&pdev->dev)) {
> ret = sun4i_i2s_runtime_resume(&pdev->dev);
> @@ -1465,7 +1487,7 @@ static int sun4i_i2s_probe(struct platform_device
> *pdev)
>
> ret = devm_snd_soc_register_component(&pdev->dev,
>
&sun4i_i2s_component,
> - &sun4i_i2s_dai,
1);
> + soc_dai, 1);
> if (ret) {
> dev_err(&pdev->dev, "Could not register DAI\n");
> goto err_suspend;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 00/21] MT8183 IOMMU SUPPORT
From: Will Deacon @ 2019-08-14 8:24 UTC (permalink / raw)
To: Joerg Roedel
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, chao.hao, linux-kernel, Evan Green, Tomasz Figa,
iommu, Rob Herring, linux-mediatek, linux-arm-kernel,
Matthias Brugger, ming-fan.chen, anan.sun, Robin Murphy,
Matthias Kaehlcke, Yong Wu
In-Reply-To: <20190814081825.GA22669@8bytes.org>
On Wed, Aug 14, 2019 at 10:18:25AM +0200, Joerg Roedel wrote:
> On Sat, Aug 10, 2019 at 03:58:00PM +0800, Yong Wu wrote:
> > Change notes:
> > v9:
> > 1) rebase on v5.3-rc1.
> > 2) In v7s, Use oas to implement MTK 4GB mode. It nearly reconstruct the
> > patch, so I don't keep the R-b.
>
> Okay, this looks close to being ready, just the io-pgtable patches still
> need review.
On my list for today :) (Today is SMMU day for me. Send coffee.)
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] bus: imx-weim: module_platform_driver()
From: Sascha Hauer @ 2019-08-14 8:23 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sascha Hauer, Shawn Guo, NXP Linux Team, Pengutronix Kernel Team
Switch from module_platform_driver_probe() to module_platform_driver().
The former is not suitable for booting with device tree as the driver
will be registered before the device and thus won't be probed again
when the device is present.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/bus/imx-weim.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index db74334ca5ef..8a9f8a4328c2 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -183,8 +183,7 @@ static int __init weim_timing_setup(struct device *dev,
return 0;
}
-static int __init weim_parse_dt(struct platform_device *pdev,
- void __iomem *base)
+static int weim_parse_dt(struct platform_device *pdev, void __iomem *base)
{
const struct of_device_id *of_id = of_match_device(weim_id_table,
&pdev->dev);
@@ -217,7 +216,7 @@ static int __init weim_parse_dt(struct platform_device *pdev,
return ret;
}
-static int __init weim_probe(struct platform_device *pdev)
+static int weim_probe(struct platform_device *pdev)
{
struct resource *res;
struct clk *clk;
@@ -254,8 +253,9 @@ static struct platform_driver weim_driver = {
.name = "imx-weim",
.of_match_table = weim_id_table,
},
+ .probe = weim_probe,
};
-module_platform_driver_probe(weim_driver, weim_probe);
+module_platform_driver(weim_driver);
MODULE_AUTHOR("Freescale Semiconductor Inc.");
MODULE_DESCRIPTION("i.MX EIM Controller Driver");
--
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 00/12] 52-bit kernel + user VAs
From: Will Deacon @ 2019-08-14 8:21 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Christoph von Recklinghausen, Ard Biesheuvel, Catalin Marinas,
Steve Capper, Linux-Renesas, Geert Uytterhoeven, maz, Linux ARM
In-Reply-To: <CACi5LpNhh0a0ktLeDDCO4K3-mBx0D8QZ344juAzbHeP4QFtGDw@mail.gmail.com>
On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> I still see the following issue on a 48-bit hardware (i.e. _non_
> ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
> d2d73d2fef421ca0d4 as the HEAD:
Have you tried the patches I posted here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html
?
Whilst they're being reviewed, I've dropped the 52-bit branch from
linux-next (for-next/core) so that people don't keep running into this.
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 v9 00/21] MT8183 IOMMU SUPPORT
From: Joerg Roedel @ 2019-08-14 8:18 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, chao.hao, Robin Murphy, linux-kernel, Evan Green,
Tomasz Figa, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
ming-fan.chen, anan.sun, Will Deacon, Matthias Kaehlcke,
linux-arm-kernel
In-Reply-To: <1565423901-17008-1-git-send-email-yong.wu@mediatek.com>
On Sat, Aug 10, 2019 at 03:58:00PM +0800, Yong Wu wrote:
> Change notes:
> v9:
> 1) rebase on v5.3-rc1.
> 2) In v7s, Use oas to implement MTK 4GB mode. It nearly reconstruct the
> patch, so I don't keep the R-b.
Okay, this looks close to being ready, just the io-pgtable patches still
need review.
Regards,
Joerg
_______________________________________________
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] dt-bindings: pinctrl: stm32: Fix 'st,syscfg' schema
From: Linus Walleij @ 2019-08-14 8:14 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Torgue, open list:GPIO SUBSYSTEM, Maxime Coquelin,
linux-stm32, Linux ARM
In-Reply-To: <20190813205528.16651-1-robh@kernel.org>
On Tue, Aug 13, 2019 at 10:55 PM Rob Herring <robh@kernel.org> wrote:
> The proper way to add additional contraints to an existing json-schema
> is using 'allOf' to reference the base schema. Using just '$ref' doesn't
> work. Fix this for the 'st,syscfg' property.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> I've got some other fixes queued up and can take this via the DT tree.
OK!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] CP115 pinctrl support
From: Linus Walleij @ 2019-08-14 8:12 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Yan Markman, Antoine Tenart, Grzegorz Jaszczyk, Gregory Clement,
Maxime Chevallier, Nadav Haklai, open list:GPIO SUBSYSTEM,
Rob Herring, Thomas Petazzoni, Stefan Chulski, Marcin Wojtas,
Linux ARM
In-Reply-To: <CACRpkdar5jE116CcywYxLR9JKWunRusJjNw7f3C0SFK4-4+dNQ@mail.gmail.com>
On Wed, Aug 7, 2019 at 2:47 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Aug 5, 2019 at 12:16 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > This is the second batch of changes (out of three) to support the brand
> > new Marvell CN9130 SoCs which are made of one AP807 and one CP115.
> >
> > We add a new compatible (and the relevant support in the pinctrl
> > driver) before the addition in batch 3/3 of CN9130 SoCs DT using it.
>
> Waiting for review from the Mvebu maintainers.
>
> If it takes too long just nudge me, it looks good to me.
So if the other MVEBU maintainers don't really look much at MVEBU
patches anymore while Miquel is working a lot on the platform,
what about listing Miquel as maintainer under the SoC entry, hm?
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v7 2/2] gpio: aspeed: Add SGPIO driver
From: Linus Walleij @ 2019-08-14 8:09 UTC (permalink / raw)
To: Hongwei Zhang
Cc: linux-aspeed, Bartosz Golaszewski, Andrew Jeffery,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
Joel Stanley, Linux ARM
In-Reply-To: <1564603297-1391-3-git-send-email-hongweiz@ami.com>
Hi Hongwei,
thanks for your patch!
I have now merged the bindings so you only need to respin
this patch.
On Wed, Jul 31, 2019 at 10:02 PM Hongwei Zhang <hongweiz@ami.com> wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
I guess I need to go with this, there are some minor things
I still want to be fixed:
> +static void __aspeed_sgpio_set(struct gpio_chip *gc, unsigned int offset, int val)
I don't like __underscore_functions because their semantic
is ambiguous.
Rename this something like aspeed_sgpio_commit() or
whatever best fits the actual use.
> +static int aspeed_sgpio_setup_irqs(struct aspeed_sgpio *gpio,
> + struct platform_device *pdev)
> +{
(...)
> + rc = gpiochip_irqchip_add(&gpio->chip, &aspeed_sgpio_irqchip,
> + 0, handle_bad_irq, IRQ_TYPE_NONE);
(...)
> + gpiochip_set_chained_irqchip(&gpio->chip, &aspeed_sgpio_irqchip,
> + gpio->irq, aspeed_sgpio_irq_handler);
We do not set up chained irqchips like this anymore, sorry.
I am currently rewriting all existing chained drivers to pass
an initialized irqchip when registering the whole gpio chip.
See drivers/gpio/TODO.
Here are examples:
https://lore.kernel.org/linux-gpio/20190811080539.15647-1-linus.walleij@linaro.org/
https://lore.kernel.org/linux-gpio/20190812132554.18313-1-linus.walleij@linaro.org/
> + /* set all SGPIO pins as input (1). */
> + memset(gpio->dir_in, 0xff, sizeof(gpio->dir_in));
Do the irqchip set-up here, before adding the gpio_chip.
> + rc = devm_gpiochip_add_data(&pdev->dev, &gpio->chip, gpio);
> + if (rc < 0)
> + return rc;
> +
> + return aspeed_sgpio_setup_irqs(gpio, pdev);
Yours,
Linus Walleij
_______________________________________________
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: [PATCH 05/10] dt-bindings: display: Add max-res property for mxsfb
From: Robert Chiras @ 2019-08-14 8:05 UTC (permalink / raw)
To: robh@kernel.org
Cc: marex@denx.de, devicetree@vger.kernel.org, kernel@pengutronix.de,
airlied@linux.ie, shawnguo@kernel.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
stefan@agner.ch, dl-linux-imx, daniel@ffwll.ch,
mark.rutland@arm.com, festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190722174853.GA31795@bogus>
On Lu, 2019-07-22 at 11:48 -0600, Rob Herring wrote:
> On Wed, Jun 26, 2019 at 04:32:13PM +0300, Robert Chiras wrote:
> >
> > Add new optional property 'max-res', to limit the maximum supported
> > resolution by the MXSFB_DRM driver.
> Bindings are for h/w description, not driver config.
>
> >
> >
> > Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
> > ---
> > Documentation/devicetree/bindings/display/mxsfb.txt | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt
> > b/Documentation/devicetree/bindings/display/mxsfb.txt
> > index 472e1ea..55e22ed 100644
> > --- a/Documentation/devicetree/bindings/display/mxsfb.txt
> > +++ b/Documentation/devicetree/bindings/display/mxsfb.txt
> > @@ -17,6 +17,12 @@ Required properties:
> > Required sub-nodes:
> > - port: The connection to an encoder chip.
> >
> > +Optional properties:
> > +- max-res: an array with a maximum of two integers, representing
> > the
> > + maximum supported resolution, in the form of
> > + <maxX>, <maxY>; if one of the item is <0>, the
> > default
> > + driver-defined maximum resolution for that axis is
> > used
> I suppose what you are after is bandwidth limits? IIRC, there's
> already
> some bindings expressing such limits. Also, wouldn't you need to
> account
> for bpp and using the 2nd plane (IIRC that there is one).
I am sorry for this late reply, but I was looking after the existing
bindings expressing such limits. I didn't find such bindings related to
this driver though, I found some limits present in some other drivers.
Indeed, this limitation is actually due to bandwidth limitation, but
the problem is that this limitation comes i.MX8M (known as mScale
850D), where the memory bandwidth cannot support: GPU/VPU workload in
the same time with both DCSS driving 4k@60 and eLCDIF driving 1080p@60.
Since eLCDIF is a secondary display we though to add the posibility to
limit it's bandwidth by limiting the resolution.
Indeed, there is also a second plane, but currently not yet supported
(there is no support for second plane in MXSFB in the upstream driver
or in our internal tree).
If you think this limitation doesn't make sense, I can just drop it.
>
> Rob
Thanks,
Robert
_______________________________________________
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 V5 00/12] 52-bit kernel + user VAs
From: Bhupesh Sharma @ 2019-08-14 8:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Christoph von Recklinghausen, Ard Biesheuvel, Catalin Marinas,
Steve Capper, Linux-Renesas, maz, Will Deacon, Linux ARM
In-Reply-To: <CAMuHMdXr+S2QeOSEXZoGGDOB_PrgENPbVXFjS=pEfbHfvN2zhw@mail.gmail.com>
Hi Will, Steve,
I still see the following issue on a 48-bit hardware (i.e. _non_
ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
d2d73d2fef421ca0d4 as the HEAD:
[ 41.318745] Freeing initrd memory: 25856K
[ 41.333312] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7
counters available
[ 41.341818] kvm [1]: IPA Size Limit: 44bits
[ 41.346131] kvm [1]: GICv3: no GICV resource entry
[ 41.350908] kvm [1]: disabling GICv2 emulation
[ 41.355358] kvm [1]: GIC system register CPU interface enabled
[ 41.363504] kvm [1]: vgic interrupt IRQ1
[ 41.370029] kvm [1]: VHE mode initialized successfully
[ 41.380484] Unable to handle kernel paging request at virtual
address ffffffffffe432c8
[ 41.388401] Mem abort info:
[ 41.391182] ESR = 0x96000006
[ 41.394227] Exception class = DABT (current EL), IL = 32 bits
[ 41.400133] SET = 0, FnV = 0
[ 41.403176] EA = 0, S1PTW = 0
[ 41.406303] Data abort info:
[ 41.409170] ISV = 0, ISS = 0x00000006
[ 41.412994] CM = 0, WnR = 0
[ 41.415949] swapper pgtable: 64k pages, 48-bit VAs, pgdp=0000000081230000
[ 41.422726] [ffffffffffe432c8] pgd=0000000081890003,
pud=0000000081890003, pmd=0000000000000000
[ 41.431413] Internal error: Oops: 96000006 [#1] SMP
[ 41.436278] Modules linked in:
[ 41.439321] CPU: 2 PID: 1357 Comm: modprobe Not tainted 5.3.0-rc3+ #1
[ 41.445748] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS
0ACKL025 01/18/2019
[ 41.453738] pstate: 80400009 (Nzcv daif +PAN -UAO)
[ 41.458520] pc : __check_object_size+0xc8/0x1f8
[ 41.463037] lr : __check_object_size+0xac/0x1f8
[ 41.467553] sp : ffff800031b2fcf0
[ 41.470854] x29: ffff800031b2fcf0 x28: ffff009f51c1c440
[ 41.476153] x27: 0000000000000000 x26: 0000000000002d29
[ 41.481451] x25: ffff009f51c1c440 x24: 0000000000000018
[ 41.486749] x23: 0000000000000004 x22: ffff800010cb1a19
[ 41.492046] x21: 0000000000000001 x20: 0000000000000001
[ 41.497344] x19: ffff800010cb1a18 x18: 0000000000000000
[ 41.502641] x17: 0000000000000000 x16: 0000000000000000
[ 41.507939] x15: 0000000000000000 x14: 0000000000000000
[ 41.513236] x13: 0000000000000000 x12: 0000000000000000
[ 41.518533] x11: 0000000000000000 x10: 0000000000000000
[ 41.523831] x9 : 0000000000000000 x8 : 0000000000000000
[ 41.529129] x7 : 000000003fcf0000 x6 : 0000000000000018
[ 41.534426] x5 : ffff800011d22840 x4 : ffff800011d22828
[ 41.539723] x3 : 0000000000000002 x2 : ffffffffffe432c0
[ 41.545021] x1 : 00000000c0000000 x0 : ffffffdfffe00000
[ 41.550319] Call trace:
[ 41.552753] __check_object_size+0xc8/0x1f8
[ 41.556923] filldir64+0x1e0/0x2d8
[ 41.560312] dcache_readdir+0x60/0x180
[ 41.564048] iterate_dir+0x14c/0x1a0
[ 41.567609] ksys_getdents64+0xa0/0x170
[ 41.571431] __arm64_sys_getdents64+0x28/0x38
[ 41.575777] el0_svc_handler+0xb0/0x180
[ 41.579601] el0_svc+0x8/0xc
[ 41.582472] Code: b26babe0 d350fc42 f2dffbe0 8b021802 (f9400440)
[ 41.588639] ---[ end trace 1e1de241f266e888 ]---
[ 41.593243] Kernel panic - not syncing: Fatal exception
[ 41.598477] SMP: stopping secondary CPUs
[ 41.602431] Kernel Offset: disabled
[ 41.605907] CPU features: 0x0002,22000c38
[ 41.609902] Memory Limit: none
[ 41.612967] ---[ end Kernel panic - not syncing: Fatal exception ]---
- git bisect points to 14c127c957c1c6070 as the offending patch.
- Here is a brief snippet of my .config flags enabling 48-bit VA and 52-bit PA:
CONFIG_ARM64_64K_PAGES=y
CONFIG_ARM64_VA_BITS_48=y
CONFIG_ARM64_VA_BITS=48
CONFIG_ARM64_PA_BITS_52=y
CONFIG_ARM64_PA_BITS=52
- Any idea if this is the same issue as Geert observed? Or should I
debug it further to determine the offending code in the patch pointed
to by git bisect.
Thanks,
Bhupesh
On Tue, Aug 13, 2019 at 7:06 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Will,
>
> On Tue, Aug 13, 2019 at 3:10 PM Will Deacon <will@kernel.org> wrote:
> > On Tue, Aug 13, 2019 at 02:43:23PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Aug 9, 2019 at 6:47 PM Will Deacon <will@kernel.org> wrote:
> > > > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote:
> > > > > This patch series adds support for 52-bit kernel VAs using some of the
> > > > > machinery already introduced by the 52-bit userspace VA code in 5.0.
> > > >
> > > > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one
> > > > small patch on top and Catalin's tags added.
> > >
> > > As of commit 14c127c957c1c607 ("arm64: mm: Flip kernel VA space"), the
> > > kernel log is spammed with
> > >
> > > virt_to_phys used for non-linear address: (____ptrval____)
> > > (__func__.6603+0x14d681/0x17fb3d)
> > > WARNING: CPU: 0 PID: 264 at arch/arm64/mm/physaddr.c:15
> > > __virt_to_phys+0x28/0x58
> > > Modules linked in:
> > > CPU: 0 PID: 264 Comm: mdev Not tainted
> > > 5.3.0-rc3-rcar3-initrd-00002-g14c127c957c1c607 #38
> > > Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT)
> > > pstate: 60000005 (nZCv daif -PAN -UAO)
> > > pc : __virt_to_phys+0x28/0x58
> > > lr : __virt_to_phys+0x28/0x58
> > > sp : ffffffc011953c80
> > > x29: ffffffc011953c80 x28: ffffff8078790140
> > > x27: 0000000000000000 x26: 0000000000000000
> > > x25: ffffffc010a539b9 x24: ffffffc010a86000
> > > x23: ffffffc010a539ba x22: 0000000000000001
> > > x21: 0000000000202038 x20: 0000000000000001
> > > x19: ffffffc010a539b9 x18: 000000000000000a
> > > x17: 0000000000000000 x16: 0000000000000000
> > > x15: 00000000000ca51d x14: 0720072007200720
> > > x13: 0720072007200720 x12: 0720072007200720
> > > x11: 0720072007200720 x10: 0720072007200720
> > > x9 : 0720072007200720 x8 : 0000000000000001
> > > x7 : 0000000000000007 x6 : ffffff8079824f00
> > > x5 : 0000000000000140 x4 : 0000000000000000
> > > x3 : 0000000000000000 x2 : 00000000ffffffff
> > > x1 : 0713abbc9281cf00 x0 : 0000000000000000
> > > Call trace:
> > > __virt_to_phys+0x28/0x58
> > > __check_object_size+0xd0/0x1e0
> > > filldir64+0x1d8/0x2b0
> > > kernfs_fop_readdir+0x64/0x200
> > > iterate_dir+0x68/0x144
> > > ksys_getdents64+0x88/0x154
> > > __arm64_sys_getdents64+0x18/0x24
> > > el0_svc_common.constprop.0+0x84/0xe8
> > > el0_svc_compat_handler+0x18/0x20
> > > el0_svc_compat+0x8/0x10
> > > ---[ end trace 6980a45f636e18be ]---
> > >
> > > as soon as userspace starts.
> >
> > Can you try the hack I posted here, please?
> >
> > https://lkml.org/lkml/2019/8/13/555
>
> Thanks, that seems to do the trick!
>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> > Also, what .config are you using?
>
> Attached.
>
> Probably CONFIG_DEBUG_VIRTUAL=y is what you're missing.
>
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/8] Fix issues with 52-bit kernel virtual addressing
From: Geert Uytterhoeven @ 2019-08-14 8:01 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Steve Capper, Catalin Marinas, Qian Cai,
Andrey Konovalov, Linux ARM
In-Reply-To: <20190813170149.26037-1-will@kernel.org>
Hi Will,
On Tue, Aug 13, 2019 at 7:01 PM Will Deacon <will@kernel.org> wrote:
> This patch series addresses some issues with 52-bit kernel VAs reported
> by Qian Cai and Geert. It's all confined to asm/memory.h and I got a bit
> carried away cleaning that thing up so the patches get more worthless
> as you go through the series. Still, I'd like to queue this on top of
> the 52-bit VA stuff currently sitting in -next.
>
> Although Geert and Steve tested my initial hacks, I dropped the tags
> because I've split things up and could've easily broken things again.
Thanks, this fixes the problem I was seeing, so
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Will Deacon (8):
> arm64: memory: Fix virt_addr_valid() using __is_lm_address()
> arm64: memory: Ensure address tag is masked in conversion macros
> arm64: memory: Rewrite default page_to_virt()/virt_to_page()
> arm64: memory: Simplify virt_to_page() implementation
> arm64: memory: Simplify _VA_START and _PAGE_OFFSET definitions
> arm64: memory: Implement __tag_set() as common function
> arm64: memory: Add comments to end of non-trivial #ifdef blocks
> arm64: memory: Cosmetic cleanups
>
> arch/arm64/include/asm/memory.h | 89 ++++++++++++++++++++---------------------
> 1 file changed, 44 insertions(+), 45 deletions(-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v7 1/2] dt-bindings: gpio: aspeed: Add SGPIO support
From: Linus Walleij @ 2019-08-14 7:59 UTC (permalink / raw)
To: Hongwei Zhang
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-aspeed, open list:GPIO SUBSYSTEM, Andrew Jeffery,
linux-kernel@vger.kernel.org, Bartosz Golaszewski, Rob Herring,
Joel Stanley, Linux ARM
In-Reply-To: <1564603297-1391-2-git-send-email-hongweiz@ami.com>
On Wed, Jul 31, 2019 at 10:01 PM Hongwei Zhang <hongweiz@ami.com> wrote:
> Add bindings to support SGPIO on AST2400 or AST2500.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
OK timeout for further DT binding review. I adjusted a bunch
of things like whitespace and referencing other files when
applying.
Yours,
Linus Walleij
_______________________________________________
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] efi/arm: fix allocation failure when reserving the kernel base
From: Guillaume Gardet @ 2019-08-14 7:58 UTC (permalink / raw)
To: Ard Biesheuvel, Chester Lin, linux@armlinux.org.uk
Cc: Juergen Gross, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org, rppt@linux.ibm.com, Joey Lee,
geert@linux-m68k.org, ren_guo@c-sky.com, Gary Lin,
akpm@linux-foundation.org, mingo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu-yaNYsLQOOcr8srW91-nt-w0e+RBqxXGOagiGGT69n1Q@mail.gmail.com>
> -----Original Message-----
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Sent: 04 August 2019 09:57
> To: Chester Lin <clin@suse.com>; linux@armlinux.org.uk
> Cc: akpm@linux-foundation.org; rppt@linux.ibm.com; ren_guo@c-sky.com;
> Juergen Gross <JGross@suse.com>; geert@linux-m68k.org; mingo@kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> efi@vger.kernel.org; Guillaume Gardet <Guillaume.Gardet@arm.com>; Joey Lee
> <JLee@suse.com>; Gary Lin <GLin@suse.com>
> Subject: Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel
> base
>
> Hello Chester,
>
> On Fri, 2 Aug 2019 at 08:40, Chester Lin <clin@suse.com> wrote:
> >
> > In some cases the arm32 efistub could fail to allocate memory for
> > uncompressed kernel. For example, we got the following error message
> > when verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> >
> > EFI stub: Booting Linux Kernel...
> > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> > EFI stub: ERROR: Failed to relocate kernel
> >
> > After checking the EFI memory map we found that the first page [0 -
> > 0xfff] had been reserved by Raspberry Pi-2's firmware, and the efistub
> > tried to set the dram base at 0, which was actually in a reserved region.
> >
>
> This by itself is a violation of the Linux boot protocol for 32-bit ARM when using
> the decompressor. The decompressor rounds down its own base address to a
> multiple of 128 MB, and assumes the whole area is available for the
> decompressed kernel and related data structures.
> (The first TEXT_OFFSET bytes are no longer used in practice, which is why putting
> a reserved region of 4 KB bytes works at the moment, but this is fragile). Note
> that the decompressor does not look at any DT or EFI provided memory maps
> *at all*.
>
> So unfortunately, this is not something we can fix in the kernel, but we should fix
> it in the bootloader or in GRUB, so it does not put any reserved regions in the
> first 128 MB of memory,
FYI, this is in Raspberry Pi firmware: https://github.com/raspberrypi/firmware/issues/1199
>
>
> > grub> lsefimmap
> > Type Physical start - end #Pages Size Attributes
> > reserved 0000000000000000-0000000000000fff 00000001 4KiB WB
> > conv-mem 0000000000001000-0000000007ef5fff 00007ef5 130004KiB WB
> > RT-data 0000000007ef6000-0000000007f09fff 00000014 80KiB RT WB
> > conv-mem 0000000007f0a000-000000002d871fff 00025968 615840KiB WB
> > .....
> >
> > To avoid a reserved address, we have to ignore the memory regions
> > which are marked as EFI_RESERVED_TYPE, and only conventional memory
> > regions can be chosen. If the region before the kernel base is
> > unaligned, it will be marked as EFI_RESERVED_TYPE and let kernel
> > ignore it so that memblock_limit will not be sticked with a very low address
> such as 0x1000.
> >
> > Signed-off-by: Chester Lin <clin@suse.com>
> > ---
> > arch/arm/mm/mmu.c | 3 ++
> > drivers/firmware/efi/libstub/arm32-stub.c | 43
> > ++++++++++++++++++-----
> > 2 files changed, 37 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index
> > f3ce34113f89..909b11ba48d8 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > phys_addr_t block_start = reg->base;
> > phys_addr_t block_end = reg->base + reg->size;
> >
> > + if (memblock_is_nomap(reg))
> > + continue;
> > +
> > if (reg->base < vmalloc_limit) {
> > if (block_end > lowmem_limit)
> > /*
> > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > b/drivers/firmware/efi/libstub/arm32-stub.c
> > index e8f7aefb6813..10d33d36df00 100644
> > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > @@ -128,7 +128,7 @@ static efi_status_t
> > reserve_kernel_base(efi_system_table_t *sys_table_arg,
> >
> > for (l = 0; l < map_size; l += desc_size) {
> > efi_memory_desc_t *desc;
> > - u64 start, end;
> > + u64 start, end, spare, kernel_base;
> >
> > desc = (void *)memory_map + l;
> > start = desc->phys_addr; @@ -144,27 +144,52 @@ static
> > efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > case EFI_BOOT_SERVICES_DATA:
> > /* Ignore types that are released to the OS anyway */
> > continue;
> > -
> > + case EFI_RESERVED_TYPE:
> > + /* Ignore reserved regions */
> > + continue;
> > case EFI_CONVENTIONAL_MEMORY:
> > /*
> > * Reserve the intersection between this entry and the
> > * region.
> > */
> > start = max(start, (u64)dram_base);
> > - end = min(end, (u64)dram_base + MAX_UNCOMP_KERNEL_SIZE);
> > + kernel_base = round_up(start, PMD_SIZE);
> > + spare = kernel_base - start;
> > + end = min(end, kernel_base +
> > + MAX_UNCOMP_KERNEL_SIZE);
> > +
> > + status = efi_call_early(allocate_pages,
> > + EFI_ALLOCATE_ADDRESS,
> > + EFI_LOADER_DATA,
> > + MAX_UNCOMP_KERNEL_SIZE / EFI_PAGE_SIZE,
> > + &kernel_base);
> > + if (status != EFI_SUCCESS) {
> > + pr_efi_err(sys_table_arg,
> > + "reserve_kernel_base: alloc failed.\n");
> > + goto out;
> > + }
> > + *reserve_addr = kernel_base;
> >
> > + if (!spare)
> > + break;
> > + /*
> > + * If there's a gap between start and kernel_base,
> > + * it needs be reserved so that the memblock_limit
> > + * will not fall on a very low address when running
> > + * adjust_lowmem_bounds(), wchich could eventually
> > + * cause CMA reservation issue.
> > + */
> > status = efi_call_early(allocate_pages,
> > EFI_ALLOCATE_ADDRESS,
> > - EFI_LOADER_DATA,
> > - (end - start) / EFI_PAGE_SIZE,
> > + EFI_RESERVED_TYPE,
> > + spare / EFI_PAGE_SIZE,
> > &start);
> > if (status != EFI_SUCCESS) {
> > pr_efi_err(sys_table_arg,
> > - "reserve_kernel_base(): alloc failed.\n");
> > + "reserve spare-region
> > + failed\n");
> > goto out;
> > }
> > - break;
> >
> > + break;
> > case EFI_LOADER_CODE:
> > case EFI_LOADER_DATA:
> > /*
> > @@ -220,7 +245,7 @@ efi_status_t handle_kernel_image(efi_system_table_t
> *sys_table,
> > *image_size = image->image_size;
> > status = efi_relocate_kernel(sys_table, image_addr, *image_size,
> > *image_size,
> > - dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
> > + *reserve_addr +
> > + MAX_UNCOMP_KERNEL_SIZE, 0);
> > if (status != EFI_SUCCESS) {
> > pr_efi_err(sys_table, "Failed to relocate kernel.\n");
> > efi_free(sys_table, *reserve_size, *reserve_addr); @@
> > -233,7 +258,7 @@ efi_status_t handle_kernel_image(efi_system_table_t
> *sys_table,
> > * in memory. The kernel determines the base of DRAM from the
> > * address at which the zImage is loaded.
> > */
> > - if (*image_addr + *image_size > dram_base + ZIMAGE_OFFSET_LIMIT) {
> > + if (*image_addr + *image_size > *reserve_addr +
> > + ZIMAGE_OFFSET_LIMIT) {
> > pr_efi_err(sys_table, "Failed to relocate kernel, no low memory
> available.\n");
> > efi_free(sys_table, *reserve_size, *reserve_addr);
> > *reserve_size = 0;
> > --
> > 2.22.0
> >
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
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 v5 11/15] ASoC: sun4i-i2s: Add support for H6 I2S
From: Jernej Škrabec @ 2019-08-14 7:57 UTC (permalink / raw)
To: codekipper
Cc: alsa-devel, linux-kernel, wens, lgirdwood, be17068, linux-sunxi,
broonie, maxime.ripard, linux-arm-kernel
In-Reply-To: <20190814060854.26345-12-codekipper@gmail.com>
Hi!
Dne sreda, 14. avgust 2019 ob 08:08:50 CEST je codekipper@gmail.com
napisal(a):
> From: Jernej Skrabec <jernej.skrabec@siol.net>
>
> H6 I2S is very similar to that in H3, except it supports up to 16
> channels.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Your Signed-off-by is missing here and on all other patches made originally by
me.
Best regards,
Jernej
> ---
> sound/soc/sunxi/sun4i-i2s.c | 148 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 148 insertions(+)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 6de3cb41aaf6..a8d98696fe7c 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -121,6 +121,21 @@
> #define SUN8I_I2S_RX_CHAN_SEL_REG 0x54
> #define SUN8I_I2S_RX_CHAN_MAP_REG 0x58
>
> +/* Defines required for sun50i-h6 support */
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK GENMASK(21, 20)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(offset) ((offset) << 20)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_MASK GENMASK(19, 16)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL(chan) ((chan - 1) << 16)
> +#define SUN50I_H6_I2S_TX_CHAN_EN_MASK GENMASK(15, 0)
> +#define SUN50I_H6_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1))
> +
> +#define SUN50I_H6_I2S_TX_CHAN_MAP0_REG 0x44
> +#define SUN50I_H6_I2S_TX_CHAN_MAP1_REG 0x48
> +
> +#define SUN50I_H6_I2S_RX_CHAN_SEL_REG 0x64
> +#define SUN50I_H6_I2S_RX_CHAN_MAP0_REG 0x68
> +#define SUN50I_H6_I2S_RX_CHAN_MAP1_REG 0x6C
> +
> struct sun4i_i2s;
>
> /**
> @@ -440,6 +455,25 @@ static void sun8i_i2s_set_rxchanoffset(const struct
> sun4i_i2s *i2s) SUN8I_I2S_TX_CHAN_OFFSET(i2s->offset));
> }
>
> +static void sun50i_h6_i2s_set_txchanoffset(const struct sun4i_i2s *i2s, int
> output) +{
> + if (output >= 0 && output < 4) {
> + regmap_update_bits(i2s->regmap,
> + SUN8I_I2S_TX_CHAN_SEL_REG +
(output * 4),
> +
SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK,
> +
SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(i2s->offset));
> + }
> +
> +}
> +
> +static void sun50i_h6_i2s_set_rxchanoffset(const struct sun4i_i2s *i2s)
> +{
> + regmap_update_bits(i2s->regmap,
> + SUN50I_H6_I2S_RX_CHAN_SEL_REG,
> + SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK,
> + SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(i2s-
>offset));
> +}
> +
> static void sun8i_i2s_set_txchanen(const struct sun4i_i2s *i2s, int output,
> int channel)
> {
> @@ -459,6 +493,26 @@ static void sun8i_i2s_set_rxchanen(const struct
> sun4i_i2s *i2s, int channel) SUN8I_I2S_TX_CHAN_EN(channel));
> }
>
> +
> +static void sun50i_h6_i2s_set_txchanen(const struct sun4i_i2s *i2s, int
> output, + int channel)
> +{
> + if (output >= 0 && output < 4) {
> + regmap_update_bits(i2s->regmap,
> + SUN8I_I2S_TX_CHAN_SEL_REG +
(output * 4),
> + SUN50I_H6_I2S_TX_CHAN_EN_MASK,
> +
SUN50I_H6_I2S_TX_CHAN_EN(channel));
> + }
> +}
> +
> +static void sun50i_h6_i2s_set_rxchanen(const struct sun4i_i2s *i2s, int
> channel) +{
> + regmap_update_bits(i2s->regmap,
> + SUN50I_H6_I2S_RX_CHAN_SEL_REG,
> + SUN50I_H6_I2S_TX_CHAN_EN_MASK,
> + SUN50I_H6_I2S_TX_CHAN_EN(channel));
> +}
> +
> static void sun4i_i2s_set_txchansel(const struct sun4i_i2s *i2s, int
> output, int channel)
> {
> @@ -495,6 +549,25 @@ static void sun8i_i2s_set_rxchansel(const struct
> sun4i_i2s *i2s, int channel) SUN8I_I2S_TX_CHAN_SEL(channel));
> }
>
> +static void sun50i_h6_i2s_set_txchansel(const struct sun4i_i2s *i2s, int
> output, + int channel)
> +{
> + if (output >= 0 && output < 4) {
> + regmap_update_bits(i2s->regmap,
> + SUN8I_I2S_TX_CHAN_SEL_REG +
(output * 4),
> + SUN50I_H6_I2S_TX_CHAN_SEL_MASK,
> +
SUN50I_H6_I2S_TX_CHAN_SEL(channel));
> + }
> +}
> +
> +static void sun50i_h6_i2s_set_rxchansel(const struct sun4i_i2s *i2s, int
> channel) +{
> + regmap_update_bits(i2s->regmap,
> + SUN50I_H6_I2S_RX_CHAN_SEL_REG,
> + SUN50I_H6_I2S_TX_CHAN_SEL_MASK,
> + SUN50I_H6_I2S_TX_CHAN_SEL(channel));
> +}
> +
> static void sun4i_i2s_set_txchanmap(const struct sun4i_i2s *i2s, int
> output, int channel)
> {
> @@ -520,6 +593,20 @@ static void sun8i_i2s_set_rxchanmap(const struct
> sun4i_i2s *i2s, int channel) regmap_write(i2s->regmap,
> SUN8I_I2S_RX_CHAN_MAP_REG, channel);
> }
>
> +static void sun50i_h6_i2s_set_txchanmap(const struct sun4i_i2s *i2s, int
> output, + int channel)
> +{
> + if (output >= 0 && output < 4) {
> + regmap_write(i2s->regmap,
> + SUN50I_H6_I2S_TX_CHAN_MAP1_REG + (output
* 8), channel);
> + }
> +}
> +
> +static void sun50i_h6_i2s_set_rxchanmap(const struct sun4i_i2s *i2s, int
> channel) +{
> + regmap_write(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_MAP1_REG, channel);
> +}
> +
> static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
> struct snd_pcm_hw_params *params,
> struct snd_soc_dai *dai)
> @@ -996,6 +1083,22 @@ static const struct reg_default
> sun8i_i2s_reg_defaults[] = { { SUN8I_I2S_RX_CHAN_MAP_REG, 0x00000000 },
> };
>
> +static const struct reg_default sun50i_i2s_reg_defaults[] = {
> + { SUN4I_I2S_CTRL_REG, 0x00060000 },
> + { SUN4I_I2S_FMT0_REG, 0x00000033 },
> + { SUN4I_I2S_FMT1_REG, 0x00000030 },
> + { SUN4I_I2S_FIFO_CTRL_REG, 0x000400f0 },
> + { SUN4I_I2S_DMA_INT_CTRL_REG, 0x00000000 },
> + { SUN4I_I2S_CLK_DIV_REG, 0x00000000 },
> + { SUN8I_I2S_CHAN_CFG_REG, 0x00000000 },
> + { SUN8I_I2S_TX_CHAN_SEL_REG, 0x00000000 },
> + { SUN50I_H6_I2S_TX_CHAN_MAP0_REG, 0x00000000 },
> + { SUN50I_H6_I2S_TX_CHAN_MAP1_REG, 0x00000000 },
> + { SUN50I_H6_I2S_RX_CHAN_SEL_REG, 0x00000000 },
> + { SUN50I_H6_I2S_RX_CHAN_MAP0_REG, 0x00000000 },
> + { SUN50I_H6_I2S_RX_CHAN_MAP1_REG, 0x00000000 },
> +};
> +
> static const struct regmap_config sun4i_i2s_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> @@ -1023,6 +1126,19 @@ static const struct regmap_config
> sun8i_i2s_regmap_config = { .volatile_reg = sun8i_i2s_volatile_reg,
> };
>
> +static const struct regmap_config sun50i_i2s_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .max_register = SUN50I_H6_I2S_RX_CHAN_MAP1_REG,
> + .cache_type = REGCACHE_FLAT,
> + .reg_defaults = sun50i_i2s_reg_defaults,
> + .num_reg_defaults = ARRAY_SIZE(sun50i_i2s_reg_defaults),
> + .writeable_reg = sun4i_i2s_wr_reg,
> + .readable_reg = sun8i_i2s_rd_reg,
> + .volatile_reg = sun8i_i2s_volatile_reg,
> +};
> +
> static int sun4i_i2s_runtime_resume(struct device *dev)
> {
> struct sun4i_i2s *i2s = dev_get_drvdata(dev);
> @@ -1197,6 +1313,34 @@ static const struct sun4i_i2s_quirks
> sun50i_a64_codec_i2s_quirks = { .set_rxchanmap =
sun4i_i2s_set_rxchanmap,
> };
>
> +static const struct sun4i_i2s_quirks sun50i_h6_i2s_quirks = {
> + .has_reset = true,
> + .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
> + .sun4i_i2s_regmap = &sun50i_i2s_regmap_config,
> + .has_fmt_set_lrck_period = true,
> + .has_chcfg = true,
> + .has_chsel_tx_chen = true,
> + .has_chsel_offset = 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),
> + .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),
> + .get_sr = sun8i_i2s_get_sr_wss,
> + .get_wss = sun8i_i2s_get_sr_wss,
> + .set_format = sun8i_i2s_set_format,
> + .set_txchanoffset = sun50i_h6_i2s_set_txchanoffset,
> + .set_rxchanoffset = sun50i_h6_i2s_set_rxchanoffset,
> + .set_txchanen = sun50i_h6_i2s_set_txchanen,
> + .set_rxchanen = sun50i_h6_i2s_set_rxchanen,
> + .set_txchansel = sun50i_h6_i2s_set_txchansel,
> + .set_rxchansel = sun50i_h6_i2s_set_rxchansel,
> + .set_txchanmap = sun50i_h6_i2s_set_txchanmap,
> + .set_rxchanmap = sun50i_h6_i2s_set_rxchanmap,
> +};
> +
> static int sun4i_i2s_init_regmap_fields(struct device *dev,
> struct sun4i_i2s *i2s)
> {
> @@ -1389,6 +1533,10 @@ static const struct of_device_id sun4i_i2s_match[] =
> { .compatible = "allwinner,sun50i-a64-codec-i2s",
> .data = &sun50i_a64_codec_i2s_quirks,
> },
> + {
> + .compatible = "allwinner,sun50i-h6-i2s",
> + .data = &sun50i_h6_i2s_quirks,
> + },
> {}
> };
> MODULE_DEVICE_TABLE(of, sun4i_i2s_match);
_______________________________________________
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 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Tony Lindgren @ 2019-08-14 7:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Aaro Koskinen, Greg Kroah-Hartman, Linus Walleij,
Bartlomiej Zolnierkiewicz, Linux Kernel Mailing List,
Dominik Brodowski, Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <CAK8P3a0LjKrc+7c5Ht9OL7LfYyLnG9=y7u+w24ujA1xAid_yCQ@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [190813 19:34]:
> On Tue, Aug 13, 2019 at 8:12 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > On Tue, Aug 13, 2019 at 01:02:16PM +0200, Arnd Bergmann wrote:
> > > On Tue, Aug 13, 2019 at 12:36 PM Tony Lindgren <tony@atomide.com> wrote:
> >
> > > - I force CONFIG_PCI to be enabled here in order to keep the
> > > asm/io.h logic unchanged. If PCI support in itself is an issue,
> > > then turning on CONFIG_PCI without the rest of this patch
> > > should also break.
> >
> > The board dies early, probably in pci_reserve_io():
> >
> > Starting kernel ...
> >
> > [ 0.000000] Booting Linux on physical CPU 0x0
> > [ 0.000000] Linux version 5.3.0-rc4-osk-los_80efa+-00028-g09f6f22a63e9 (aaro@amd-fx-6350) (gcc version 8.3.0 (GCC)) #1 Tue Aug 13 20:50:11 EEST 2019
> > [ 0.000000] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=0005317f
> > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
> > [ 0.000000] Machine: TI-OSK
> > [ 0.000000] Ignoring tag cmdline (using the default kernel command line)
> > [ 0.000000] printk: bootconsole [earlycon0] enabled
> > [ 0.000000] Memory policy: Data cache writeback
> > [ 0.000000] Internal error: Oops - undefined instruction: 0 [#1] ARM
> > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.3.0-rc4-osk-los_80efa+-00028-g09f6f22a63e9 #1
> > [ 0.000000] Hardware name: TI-OSK
> > [ 0.000000] PC is at vm_area_add_early+0x1c/0x74
>
> That sounds like an address conflict in the virtual addres space.
>
> In multiplatform kernels, PCI I/O space is hardwired to addresses
> 0xfee00000-0xfeffffff,
> which happened to be available on all the other machines that needed it so far.
>
> OMAP1_IO_VIRT is 0xfefb0000-0xfefeffff, which clearly overlaps with the end of
> the PCI I/O area.
>
> We only really need 4KB of I/O space rather than the full 2MB, but it
> would also be
> good not to make this too machine specific.
>
> Could we change OMAP1_IO_OFFSET to stay out of that area? Something like
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 97c114c1ef80..3b66d203dc98 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1794,9 +1794,9 @@ config DEBUG_UART_VIRT
> default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
> default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
> default 0xfef36000 if DEBUG_HIGHBANK_UART
> - default 0xfefb0000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
> - default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
> - default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
> + default 0xff000000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
> + default 0xff000800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
> + default 0xff009800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
> default 0xff003000 if DEBUG_U300_UART
> default 0xffd01000 if DEBUG_HIP01_UART
> default DEBUG_UART_PHYS if !MMU
> diff --git a/arch/arm/mach-omap1/hardware.h b/arch/arm/mach-omap1/hardware.h
> index 232b8deef907..9fc76a3c9e57 100644
> --- a/arch/arm/mach-omap1/hardware.h
> +++ b/arch/arm/mach-omap1/hardware.h
> @@ -61,7 +61,7 @@ static inline u32 omap_cs3_phys(void)
>
> #endif /* ifndef __ASSEMBLER__ */
>
> -#define OMAP1_IO_OFFSET 0x01000000 /* Virtual IO
> = 0xfefb0000 */
> +#define OMAP1_IO_OFFSET 0x00fb0000 /* Virtual IO
> = 0xff000000 */
> #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET)
>
> #include "serial.h"
Oh OK yeah sounds like that's the issue.
> There may be additional locations that hardcode the virtual address.
Those should be in mach-omap1/io.c, and I recall innovator had some
hardcoded fpga address that should also be checked.
Regards,
Tony
_______________________________________________
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