* Re: [PATCHv4-next 2/3] arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus
From: Martin Blumenstingl @ 2019-09-03 18:57 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, Neil Armstrong, Kevin Hilman, linux-kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <20190902054935.4899-3-linux.amoon@gmail.com>
On Mon, Sep 2, 2019 at 7:50 AM Anand Moon <linux.amoon@gmail.com> wrote:
>
> Add missing linking regulator node to usb bus for power usb devices.
>
> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> Re-base on linux-next
> Added Ack from Martin.
>
> Changes from previous patch
> [1] https://lore.kernel.org/patchwork/patch/1031243/
> split the changes and add the comments to power source
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 0cb5831d9daf..d4c8b896dd26 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -36,8 +36,15 @@
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
>
> + /*
> + * signal name from schematics: PWREN
> + */
> gpio = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> + /*
> + * signal name from sehematics: USB_POWER
nit-pick: should be "schematics"
I hope that Kevin can fix that up when applying
_______________________________________________
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] ARM: Emit __gnu_mcount_nc when using Clang 10.0.0 or newer
From: Matthias Kaehlcke @ 2019-09-03 18:48 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Arnd Bergmann, Nick Desaulniers, Russell King, Stefan Agner,
linux-kernel, clang-built-linux, linux-arm-kernel
In-Reply-To: <20190831060530.43082-1-natechancellor@gmail.com>
On Fri, Aug 30, 2019 at 11:05:31PM -0700, Nathan Chancellor wrote:
> Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
> with clang:
>
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
> softirq.c:(.text+0x504): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
> softirq.c:(.text+0x58c): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
> softirq.c:(.text+0x6c8): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
> softirq.c:(.text+0x75c): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
> softirq.c:(.text+0x840): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow
>
> clang can emit a working mcount symbol, __gnu_mcount_nc, when
> '-meabi gnu' is passed to it. Until r369147 in LLVM, this was
> broken and caused the kernel not to boot with '-pg' because the
> calling convention was not correct. Always build with '-meabi gnu'
> when using clang but ensure that '-pg' (which is added with
> CONFIG_FUNCTION_TRACER and its prereq CONFIG_HAVE_FUNCTION_TRACER)
> cannot be added with it unless this is fixed (which means using
> clang 10.0.0 and newer).
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/35
> Link: https://bugs.llvm.org/show_bug.cgi?id=33845
> Link: https://github.com/llvm/llvm-project/commit/16fa8b09702378bacfa3d07081afe6b353b99e60
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Reviewed-by: Stefan Agner <stefan@agner.ch>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.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: [PULL 2/3] Renesas driver updates for v5.4
From: Geert Uytterhoeven @ 2019-09-03 18:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: arm-soc, Geert Uytterhoeven, Magnus Damm, Linux-Renesas, arm-soc,
Simon Horman, Linux ARM
In-Reply-To: <CAK8P3a0S3axohc7iq_vx_5i+KGiC0fX=rctvY8uXdhwz6Z9YCQ@mail.gmail.com>
Hi Arnd,
On Tue, Sep 3, 2019 at 8:23 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Aug 2, 2019 at 2:04 PM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> >
> > Renesas driver updates for v5.4
> >
> > - Fix a flexible array member definition in the R-Car SYSC driver.
> >
> I see I merged this earlier but forgot to reply.
No worries, my git notices.
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: [PULL 2/3] Renesas driver updates for v5.4
From: Arnd Bergmann @ 2019-09-03 18:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Linux-Renesas, arm-soc, arm-soc,
Linux ARM
In-Reply-To: <20190802120355.1430-3-geert+renesas@glider.be>
On Fri, Aug 2, 2019 at 2:04 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> Renesas driver updates for v5.4
>
> - Fix a flexible array member definition in the R-Car SYSC driver.
>
I see I merged this earlier but forgot to reply.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
From: Jernej Škrabec @ 2019-09-03 18:08 UTC (permalink / raw)
To: Neil Armstrong
Cc: alsa-devel, kuninori.morimoto.gx, cain.cai, airlied, dri-devel,
dianders, a.hajda, Laurent.pinchart, Yakir Yang, sam,
Cheng-Yi Chiang, zhengxing, linux-rockchip, dgreid, tzungbi,
Jonas Karlman, jeffy.chen, eddie.cai, linux-arm-kernel,
linux-kernel, daniel, enric.balletbo, kuankuan.y
In-Reply-To: <d8a80ba5-dd2b-f84d-bbfc-9dd5ccbc26e9@baylibre.com>
Hi!
Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
> Hi,
>
> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
> > Hi,
> >
> > On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> >> From: Yakir Yang <ykk@rock-chips.com>
> >>
> >> When transmitting IEC60985 linear PCM audio, we configure the
> >> Audio Sample Channel Status information of all the channel
> >> status bits in the IEC60958 frame.
> >> Refer to 60958-3 page 10 for frequency, original frequency, and
> >> wordlength setting.
> >>
> >> This fix the issue that audio does not come out on some monitors
> >> (e.g. LG 22CV241)
> >>
> >> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> >> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> >> ---
> >>
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++++++++++++++++++++++
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++++++++
> >> 2 files changed, 79 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> >> bd65d0479683..34d46e25d610 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
> >> freq, unsigned long pixel_clk)>>
> >> return n;
> >>
> >> }
> >>
> >> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> >> +{
> >> + u8 aud_schnl_samplerate;
> >> + u8 aud_schnl_8;
> >> +
> >> + /* These registers are on RK3288 using version 2.0a. */
> >> + if (hdmi->version != 0x200a)
> >> + return;
> >
> > Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> > SoCs ?
>
> After investigations, Amlogic sets these registers on their 2.0a version
> aswell, and Jernej (added in Cc) reported me Allwinner sets them on their
> < 2.0a and > 2.0a IPs versions.
>
> Can you check on the Rockchip IP versions in RK3399 ?
>
> For reference, the HDMI 1.4a IP version allwinner setups is:
> https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/master/drivers/vide
> o/fbdev/sunxi/disp2/hdmi/hdmi_bsp_sun8iw7.c#L531-L539 (registers a
> "scrambled" but a custom bit can reset to the original mapping, 0x1066 ...
> 0x106f)
For easier reading, here is similar, but annotated version: http://ix.io/1Ub6
Check function bsp_hdmi_audio().
Unless there is a special reason, you can just remove that check.
Best regards,
Jernej
>
> Neil
>
> >> +
> >> + switch (hdmi->sample_rate) {
> >> + case 32000:
> >> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
> >> + break;
> >> + case 44100:
> >> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> >> + break;
> >> + case 48000:
> >> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
> >> + break;
> >> + case 88200:
> >> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
> >> + break;
> >> + case 96000:
> >> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
> >> + break;
> >> + case 176400:
> >> + aud_schnl_samplerate =
HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
> >> + break;
> >> + case 192000:
> >> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
> >> + break;
> >> + case 768000:
> >> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
> >> + break;
> >> + default:
> >> + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)
\n",
> >> + hdmi->sample_rate);
> >> + return;
> >> + }
> >> +
> >> + /* set channel status register */
> >> + hdmi_modb(hdmi, aud_schnl_samplerate,
HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
> >> + HDMI_FC_AUDSCHNLS7);
> >> +
> >> + /*
> >> + * Set original frequency to be the same as frequency.
> >> + * Use one-complement value as stated in IEC60958-3 page 13.
> >> + */
> >> + aud_schnl_8 = (~aud_schnl_samplerate) <<
> >> + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
> >> +
> >> + /* This means word length is 16 bit. Refer to IEC60958-3 page 12.
*/
> >> + aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
> >> +
> >> + hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
> >> +}
> >> +
> >>
> >> static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> >>
> >> unsigned long pixel_clk, unsigned int sample_rate)
> >>
> >> {
> >>
> >> @@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi
> >> *hdmi,>>
> >> hdmi->audio_cts = cts;
> >> hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
> >> spin_unlock_irq(&hdmi->audio_lock);
> >>
> >> +
> >> + hdmi_set_schnl(hdmi);
> >>
> >> }
> >>
> >> static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
> >> 6988f12d89d9..619ebc1c8354 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> >> @@ -158,6 +158,17 @@
> >>
> >> #define HDMI_FC_SPDDEVICEINF 0x1062
> >> #define HDMI_FC_AUDSCONF 0x1063
> >> #define HDMI_FC_AUDSSTAT 0x1064
> >>
> >> +#define HDMI_FC_AUDSV 0x1065
> >> +#define HDMI_FC_AUDSU 0x1066
> >> +#define HDMI_FC_AUDSCHNLS0 0x1067
> >> +#define HDMI_FC_AUDSCHNLS1 0x1068
> >> +#define HDMI_FC_AUDSCHNLS2 0x1069
> >> +#define HDMI_FC_AUDSCHNLS3 0x106a
> >> +#define HDMI_FC_AUDSCHNLS4 0x106b
> >> +#define HDMI_FC_AUDSCHNLS5 0x106c
> >> +#define HDMI_FC_AUDSCHNLS6 0x106d
> >> +#define HDMI_FC_AUDSCHNLS7 0x106e
> >> +#define HDMI_FC_AUDSCHNLS8 0x106f
> >>
> >> #define HDMI_FC_DATACH0FILL 0x1070
> >> #define HDMI_FC_DATACH1FILL 0x1071
> >> #define HDMI_FC_DATACH2FILL 0x1072
> >>
> >> @@ -706,6 +717,15 @@ enum {
> >>
> >> /* HDMI_FC_AUDSCHNLS7 field values */
> >>
> >> HDMI_FC_AUDSCHNLS7_ACCURACY_OFFSET = 4,
> >> HDMI_FC_AUDSCHNLS7_ACCURACY_MASK = 0x30,
> >>
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_MASK = 0x0f,
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_192K = 0xe,
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_176K4 = 0xc,
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_96K = 0xa,
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_768K = 0x9,
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_88K2 = 0x8,
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_32K = 0x3,
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_48K = 0x2,
> >> + HDMI_FC_AUDSCHNLS7_SMPRATE_44K1 = 0x0,
> >>
> >> /* HDMI_FC_AUDSCHNLS8 field values */
> >>
> >> HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_MASK = 0xf0,
_______________________________________________
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] i2c: stm32f7: Make structure stm32f7_i2c_algo constant
From: Wolfram Sang @ 2019-09-03 18:05 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: alexandre.torgue, linux-kernel, pierre-yves.mordret, linux-i2c,
mcoquelin.stm32, linux-stm32, linux-arm-kernel
In-Reply-To: <20190815055857.1944-1-nishkadg.linux@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1175 bytes --]
On Thu, Aug 15, 2019 at 11:28:57AM +0530, Nishka Dasgupta wrote:
> Static structure stm32f7_i2c_algo, of type i2c_algorithm, is used only
> when it is assigned to constant field algo of a variable having type
> i2c_adapter. As stm32f7_i2c_algo is therefore never modified, make it
> const as well to protect it from unintended modification.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> ---
Are you guys okay with this patch?
> drivers/i2c/busses/i2c-stm32f7.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
> index 266d1c269b83..d36cf08461f7 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -1809,7 +1809,7 @@ static u32 stm32f7_i2c_func(struct i2c_adapter *adap)
> I2C_FUNC_SMBUS_I2C_BLOCK;
> }
>
> -static struct i2c_algorithm stm32f7_i2c_algo = {
> +static const struct i2c_algorithm stm32f7_i2c_algo = {
> .master_xfer = stm32f7_i2c_xfer,
> .smbus_xfer = stm32f7_i2c_smbus_xfer,
> .functionality = stm32f7_i2c_func,
> --
> 2.19.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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 V3 1/5] dt-bindings: fsl: scu: add scu key binding
From: Rob Herring @ 2019-09-03 18:01 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, ulf.hansson, ping.bai, catalin.marinas, peng.fan,
stefan, bjorn.andersson, leonard.crestez, will, festevam,
yuehaibing, marcin.juszkiewicz, jagan, linux-input, ronald,
Linux-imx, devicetree, arnd, s.hauer, mripard, m.felsch, robh+dt,
tglx, andriy.shevchenko, daniel.baluta, linux-arm-kernel,
aisheng.dong, fugang.duan, gregkh, dmitry.torokhov, linux-kernel,
dinguyen, kernel, olof, shawnguo
In-Reply-To: <1567546600-21566-1-git-send-email-Anson.Huang@nxp.com>
On Tue, 3 Sep 2019 17:36:36 -0400, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and scu key event etc. management, Linux kernel has
> to communicate with system controller via MU (message unit) IPC
> to get scu key event, add binding doc for i.MX system controller
> key driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V2:
> - use "key" instead of "pwrkey" as the key function can be defined in DT.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
From: Neil Armstrong @ 2019-09-03 18:00 UTC (permalink / raw)
To: Cheng-Yi Chiang, linux-kernel, dri-devel, Jernej Skrabec,
Jonas Karlman
Cc: alsa-devel, tzungbi, zhengxing, kuninori.morimoto.gx,
linux-rockchip, airlied, sam, jeffy.chen, dianders, cain.cai,
a.hajda, eddie.cai, Laurent.pinchart, daniel, Yakir Yang,
enric.balletbo, dgreid, kuankuan.y, linux-arm-kernel
In-Reply-To: <e1c3483c-baa6-c726-e547-fadf40d259f4@baylibre.com>
Hi,
Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
> Hi,
>
> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
>> From: Yakir Yang <ykk@rock-chips.com>
>>
>> When transmitting IEC60985 linear PCM audio, we configure the
>> Audio Sample Channel Status information of all the channel
>> status bits in the IEC60958 frame.
>> Refer to 60958-3 page 10 for frequency, original frequency, and
>> wordlength setting.
>>
>> This fix the issue that audio does not come out on some monitors
>> (e.g. LG 22CV241)
>>
>> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
>> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++++++++++++++++++++++
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++++++++
>> 2 files changed, 79 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index bd65d0479683..34d46e25d610 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk)
>> return n;
>> }
>>
>> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
>> +{
>> + u8 aud_schnl_samplerate;
>> + u8 aud_schnl_8;
>> +
>> + /* These registers are on RK3288 using version 2.0a. */
>> + if (hdmi->version != 0x200a)
>> + return;
>
> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> SoCs ?
After investigations, Amlogic sets these registers on their 2.0a version
aswell, and Jernej (added in Cc) reported me Allwinner sets them on their
< 2.0a and > 2.0a IPs versions.
Can you check on the Rockchip IP versions in RK3399 ?
For reference, the HDMI 1.4a IP version allwinner setups is:
https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/master/drivers/video/fbdev/sunxi/disp2/hdmi/hdmi_bsp_sun8iw7.c#L531-L539
(registers a "scrambled" but a custom bit can reset to the original mapping,
0x1066 ... 0x106f)
Neil
>
>> +
>> + switch (hdmi->sample_rate) {
>> + case 32000:
>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
>> + break;
>> + case 44100:
>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
>> + break;
>> + case 48000:
>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
>> + break;
>> + case 88200:
>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
>> + break;
>> + case 96000:
>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
>> + break;
>> + case 176400:
>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
>> + break;
>> + case 192000:
>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
>> + break;
>> + case 768000:
>> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
>> + break;
>> + default:
>> + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n",
>> + hdmi->sample_rate);
>> + return;
>> + }
>> +
>> + /* set channel status register */
>> + hdmi_modb(hdmi, aud_schnl_samplerate, HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
>> + HDMI_FC_AUDSCHNLS7);
>> +
>> + /*
>> + * Set original frequency to be the same as frequency.
>> + * Use one-complement value as stated in IEC60958-3 page 13.
>> + */
>> + aud_schnl_8 = (~aud_schnl_samplerate) <<
>> + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
>> +
>> + /* This means word length is 16 bit. Refer to IEC60958-3 page 12. */
>> + aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
>> +
>> + hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
>> +}
>> +
>> static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
>> unsigned long pixel_clk, unsigned int sample_rate)
>> {
>> @@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
>> hdmi->audio_cts = cts;
>> hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
>> spin_unlock_irq(&hdmi->audio_lock);
>> +
>> + hdmi_set_schnl(hdmi);
>> }
>>
>> static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>> index 6988f12d89d9..619ebc1c8354 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
>> @@ -158,6 +158,17 @@
>> #define HDMI_FC_SPDDEVICEINF 0x1062
>> #define HDMI_FC_AUDSCONF 0x1063
>> #define HDMI_FC_AUDSSTAT 0x1064
>> +#define HDMI_FC_AUDSV 0x1065
>> +#define HDMI_FC_AUDSU 0x1066
>> +#define HDMI_FC_AUDSCHNLS0 0x1067
>> +#define HDMI_FC_AUDSCHNLS1 0x1068
>> +#define HDMI_FC_AUDSCHNLS2 0x1069
>> +#define HDMI_FC_AUDSCHNLS3 0x106a
>> +#define HDMI_FC_AUDSCHNLS4 0x106b
>> +#define HDMI_FC_AUDSCHNLS5 0x106c
>> +#define HDMI_FC_AUDSCHNLS6 0x106d
>> +#define HDMI_FC_AUDSCHNLS7 0x106e
>> +#define HDMI_FC_AUDSCHNLS8 0x106f
>> #define HDMI_FC_DATACH0FILL 0x1070
>> #define HDMI_FC_DATACH1FILL 0x1071
>> #define HDMI_FC_DATACH2FILL 0x1072
>> @@ -706,6 +717,15 @@ enum {
>> /* HDMI_FC_AUDSCHNLS7 field values */
>> HDMI_FC_AUDSCHNLS7_ACCURACY_OFFSET = 4,
>> HDMI_FC_AUDSCHNLS7_ACCURACY_MASK = 0x30,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_MASK = 0x0f,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_192K = 0xe,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_176K4 = 0xc,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_96K = 0xa,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_768K = 0x9,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_88K2 = 0x8,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_32K = 0x3,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_48K = 0x2,
>> + HDMI_FC_AUDSCHNLS7_SMPRATE_44K1 = 0x0,
>>
>> /* HDMI_FC_AUDSCHNLS8 field values */
>> HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_MASK = 0xf0,
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
From: Jack Pham @ 2019-09-03 17:39 UTC (permalink / raw)
To: Jorge Ramirez
Cc: mark.rutland, robh, kishon, gregkh, Stephen Boyd, linux-usb,
khasim.mohammed, linux-kernel, Bjorn Andersson, devicetree,
linux-arm-msm, andy.gross, shawn.guo, linux-arm-kernel
In-Reply-To: <f3584f38-dabc-7e7a-d1cb-84c80ed26215@linaro.org>
On Mon, Sep 02, 2019 at 08:23:04AM +0200, Jorge Ramirez wrote:
> On 8/30/19 20:28, Stephen Boyd wrote:
> > Quoting Bjorn Andersson (2019-08-30 09:45:20)
> >> On Fri 30 Aug 09:01 PDT 2019, Stephen Boyd wrote:
> >>
> >>> Quoting Jorge Ramirez (2019-08-29 00:03:48)
> >>>> On 2/23/19 17:52, Bjorn Andersson wrote:
> >>>>> On Thu 07 Feb 03:17 PST 2019, Jorge Ramirez-Ortiz wrote:
> >>>>>> +
> >>>>>> +Required child nodes:
> >>>>>> +
> >>>>>> +- usb connector node as defined in bindings/connector/usb-connector.txt
> >>>>>> + containing the property vbus-supply.
> >>>>>> +
> >>>>>> +Example:
> >>>>>> +
> >>>>>> +usb3_phy: usb3-phy@78000 {
> >>>>>> + compatible = "qcom,snps-usb-ssphy";
> >>>>>> + reg = <0x78000 0x400>;
> >>>>>> + #phy-cells = <0>;
> >>>>>> + clocks = <&rpmcc RPM_SMD_LN_BB_CLK>,
> >>>>>> + <&gcc GCC_USB_HS_PHY_CFG_AHB_CLK>,
> >>>>>> + <&gcc GCC_USB3_PHY_PIPE_CLK>;
> >>>>>> + clock-names = "ref", "phy", "pipe";
> >>>>>> + resets = <&gcc GCC_USB3_PHY_BCR>,
> >>>>>> + <&gcc GCC_USB3PHY_PHY_BCR>;
> >>>>>> + reset-names = "com", "phy";
> >>>>>> + vdd-supply = <&vreg_l3_1p05>;
> >>>>>> + vdda1p8-supply = <&vreg_l5_1p8>;
> >>>>>> + usb3_c_connector: usb3-c-connector {
> >>>
> >>> Node name should be 'connector', not usb3-c-connector.
> >>>
> >>
> >> It probably has to be usb-c-connector, because we have a
> >> micro-usb-connector on the same board.
> >
> > Ok. Or connector@1 and connector@2? Our toplevel node container story is
> > sort of sad because we have to play tricks with node names. But in the
> > example, just connector I presume?
> >
> >>
> >>>>>
> >>>>> The USB-C connector is attached both to the HS and SS PHYs, so I think
> >>>>> you should represent this external to this node and use of_graph to
> >>>>> query it.
> >>>>
> >>>> but AFAICS we wont be able to retrieve the vbux-supply from an external
> >>>> node (that interface does not exist).
> >>>>
> >>>> rob, do you have a suggestion?
> >>>
> >>> Shouldn't the vbus supply be in the phy? Or is this a situation where
> >>> the phy itself doesn't have the vbus supply going to it because the PMIC
> >>> gets in the way and handles the vbus for the connector by having the SoC
> >>> communicate with the PMIC about when to turn the vbus on and off, etc?
> >>>
> >>
> >> That's correct, the VBUS comes out of the PMIC and goes directly to the
> >> connector.
> >>
> >> The additional complicating factor here is that the connector is wired
> >> to a USB2 phy as well, so we need to wire up detection and vbus control
> >> to both of them - but I think this will be fine, if we can only figure
> >> out a sane way of getting hold of the vbus-supply.
> >>
> >
> > Does it really matter to describe this situation though? Maybe it's
> > simpler to throw the vbus supply into the phy and control it from the
> > phy driver, even if it never really goes there. Or put it into the
> > toplevel usb controller?
> >
> that would work for me - the connector definition seemed a better way to
> explain the connectivity but since we cant retrieve the supply from the
> external node is not of much functional use.
>
> but please let me know how to proceed. shall I add the supply back to
> the phy?
Putting it in the toplevel usb node makes sense to me, since that's
usually the driver that knows when it's switching into host mode and
needs to turn on VBUS. The dwc3-qcom driver & bindings currently don't
do this but there's precedent in a couple of the other dwc3 "glues"--see
Documentation/devicetree/bindings/usb/{amlogic\,dwc3,omap-usb}.txt
One exception is if the PMIC is also USB-PD capable and can do power
role swap, in which case the VBUS control needs to be done by the TCPM,
so that'd be a case where having vbus-supply in the connector node might
make more sense.
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
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/4] dt-bindings: arm: amlogic: add Amlogic AD401 bindings
From: Rob Herring @ 2019-09-03 17:38 UTC (permalink / raw)
To: Jianxin Pan
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, linux-kernel, Qiufang Dai,
Jian Hu, Xingyu Chen, Tao Zeng, Carlo Caione, linux-amlogic,
linux-arm-kernel, Jerome Brunet
In-Reply-To: <1567493475-75451-4-git-send-email-jianxin.pan@amlogic.com>
On Tue, 3 Sep 2019 02:51:14 -0400, Jianxin Pan wrote:
> Add the compatible for the Amlogic A1 Based AD401 board.
>
> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: arm: amlogic: add A1 bindings
From: Rob Herring @ 2019-09-03 17:38 UTC (permalink / raw)
To: Jianxin Pan
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, linux-kernel, Qiufang Dai,
Jian Hu, Xingyu Chen, Tao Zeng, Carlo Caione, linux-amlogic,
linux-arm-kernel, Jerome Brunet
In-Reply-To: <1567493475-75451-3-git-send-email-jianxin.pan@amlogic.com>
On Tue, 3 Sep 2019 02:51:13 -0400, Jianxin Pan wrote:
> Add bindings for the new Amlogic A1 SoC family.
>
> A1 is an application processor designed for smart audio and IoT applications,
> with dual core Cortex-A35.
>
> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/3] ARM: samsung: mach for v5.4
From: Arnd Bergmann @ 2019-09-03 17:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
SoC Team, arm-soc, Kukjin Kim, Olof Johansson, Linux ARM
In-Reply-To: <CAJKOXPfdvzvomUfmxhGf0qjEQH3K8TADCneo9SM6m50k4b=Gyw@mail.gmail.com>
On Wed, Aug 21, 2019 at 9:52 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Fri, 16 Aug 2019 at 18:30, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > ----------------------------------------------------------------
> > Linus Walleij (1):
> > ARM: samsung: Include GPIO driver header
> >
> > Pankaj Dubey (1):
> > ARM: exynos: Enable exynos-chipid driver
>
> This last patch should be dropped so I will rework the pull request
> and send later v2. Please ignore it for now.
I don't see the v2 yet. Are you still planning to send it?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v3 2/3] dt-bindings: net: dsa: mt7530: Add support for port 5
From: Rob Herring @ 2019-09-03 17:28 UTC (permalink / raw)
To: René van Dorst
Cc: Andrew Lunn, Florian Fainelli, Frank Wunderlich, netdev,
Sean Wang, Russell King, David S . Miller, René van Dorst,
devicetree, linux-mediatek, John Crispin, Matthias Brugger,
linux-mips, Vivien Didelot, linux-arm-kernel
In-Reply-To: <20190902130226.26845-3-opensource@vdorst.com>
On Mon, 2 Sep 2019 15:02:25 +0200, =?UTF-8?q?Ren=C3=A9=20van=20Dorst?= wrote:
> MT7530 port 5 has many modes/configurations.
> Update the documentation how to use port 5.
>
> Signed-off-by: René van Dorst <opensource@vdorst.com>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> ---
> v2->v3:
> * Remove 'status = "okay";' lines, suggested by Rob Herring
> v1->v2:
> * Adding extra note about RGMII2 and gpio use.
> rfc->v1:
> * No change
>
> .../devicetree/bindings/net/dsa/mt7530.txt | 214 ++++++++++++++++++
> 1 file changed, 214 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/3] soc: samsung: Exynos for v5.4
From: Arnd Bergmann @ 2019-09-03 17:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
SoC Team, arm-soc, Kukjin Kim, Olof Johansson, Linux ARM
In-Reply-To: <20190822183519.GA23735@kozik-lap>
On Thu, Aug 22, 2019 at 8:35 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Aug 21, 2019 at 09:51:09AM +0200, Krzysztof Kozlowski wrote:
> > On Fri, 16 Aug 2019 at 18:30, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
> > >
> > > Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
> > >
> > > are available in the Git repository at:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.4
> > >
> > > for you to fetch changes up to 40d8aff614f71ab3cab20785b4f213e3802d4e87:
> > >
> > > soc: samsung: chipid: Convert exynos-chipid driver to use the regmap API (2019-08-15 20:25:25 +0200)
> > >
> > > ----------------------------------------------------------------
> > > Samsung soc drivers changes for v5.4
> > >
> > > Add Exynos Chipid driver for identification of product IDs and SoC
> > > revisions. The driver also exposes chipid regmap, later to be used by
> > > Exynos Adaptive Supply Voltage driver (adjusting voltages to different
> > > revisions of same SoC).
> >
> > It turns out that it brings troubles (code is executed on every
> > platform polluting logs because it is an initcall, not a driver) so
> > Sylwester (submitter) asked to skip the submission.
> >
> > Please ignore the pull request.
>
> I talked with Sylwester and Bartlomiej who contributed the chipid driver
> and they provided small incremental fixes. The driver is still useful
> and in the future it will be expanded towards AVS. Therefore please pull
> it or optionally wait a week and I will send incremental pull request
> with fixes.
Pulled into arm/drivers for now.
I have drafted a related patch recently, regarding the related
arch/arm/plat-samsung/cpu.c file. This is part of a longer series
I'm working on, see https://pastebin.com/ZqeU3Mth for the
current version of this patch. The observation is that mach-exynos
is almost completely independent of plat-samsung these days, and my
patch removes the last obstacle from separating the two. I have
another set of patches to do the same for mach-s5pv210 (which shares
half of its pm.c with plat-samsung, but nothing else).
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] PCI: Remove unused includes and superfluous struct declaration
From: Rob Herring @ 2019-09-03 17:20 UTC (permalink / raw)
To: Krzysztof Wilczynski
Cc: devicetree, Lorenzo Pieralisi, Jingoo Han, Joerg Roedel,
linux-pci, linux-kernel, iommu, Bjorn Helgaas, Thomas Petazzoni,
Gustavo Pimentel, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190903113059.2901-1-kw@linux.com>
On Tue, Sep 03, 2019 at 01:30:59PM +0200, Krzysztof Wilczynski wrote:
> Remove <linux/pci.h> and <linux/msi.h> from being included
> directly as part of the include/linux/of_pci.h, and remove
> superfluous declaration of struct of_phandle_args.
>
> Move users of include <linux/of_pci.h> to include <linux/pci.h>
> and <linux/msi.h> directly rather than rely on both being
> included transitively through <linux/of_pci.h>.
>
> Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
> ---
> drivers/iommu/of_iommu.c | 2 ++
> drivers/irqchip/irq-gic-v2m.c | 1 +
> drivers/irqchip/irq-gic-v3-its-pci-msi.c | 1 +
> drivers/pci/controller/dwc/pcie-designware-host.c | 1 +
> drivers/pci/controller/pci-aardvark.c | 1 +
> drivers/pci/controller/pci-thunder-pem.c | 1 +
> drivers/pci/pci.c | 1 +
> drivers/pci/probe.c | 1 +
> include/linux/of_pci.h | 5 ++---
> 9 files changed, 11 insertions(+), 3 deletions(-)
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
* [PATCH v4] drm/mcde: Fix DSI transfers
From: Linus Walleij @ 2019-09-03 17:08 UTC (permalink / raw)
To: dri-devel, Maarten Lankhorst, Maxime Ripard, Sean Paul
Cc: Linus Walleij, Stephan Gerhold, kbuild test robot,
linux-arm-kernel
There were bugs in the DSI transfer (read and write) function
as it was only tested with displays ever needing a single byte
to be written. Fixed it up and tested so we can now write
messages of up to 16 bytes and read up to 4 bytes from the
display.
Tested with a Sony ACX424AKP display: this display now self-
identifies and can control backlight in command mode.
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v3->v4:
- Fix further message bugs caused when fixing bugs in messages.
- Considering not coding while I have fever ... nah it's too
much fun.
ChangeLog v2->v3:
- Fix an error message to indicate reading error rather than
writing error.
- Use the local variable for underflow print.
- Collected Stephan's reviewed-by.
ChangeLog v1->v2:
- Fix a print modifier for dev_err() found by the build robot.
---
drivers/gpu/drm/mcde/mcde_dsi.c | 70 ++++++++++++++++++++++-----------
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 07f7090d08b3..f9c9e32b299c 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -178,22 +178,26 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
const u32 loop_delay_us = 10; /* us */
const u8 *tx = msg->tx_buf;
u32 loop_counter;
- size_t txlen;
+ size_t txlen = msg->tx_len;
+ size_t rxlen = msg->rx_len;
u32 val;
int ret;
int i;
- txlen = msg->tx_len;
- if (txlen > 12) {
+ if (txlen > 16) {
dev_err(d->dev,
- "dunno how to write more than 12 bytes yet\n");
+ "dunno how to write more than 16 bytes yet\n");
+ return -EIO;
+ }
+ if (rxlen > 4) {
+ dev_err(d->dev,
+ "dunno how to read more than 4 bytes yet\n");
return -EIO;
}
dev_dbg(d->dev,
- "message to channel %d, %zd bytes",
- msg->channel,
- txlen);
+ "message to channel %d, write %zd bytes read %zd bytes\n",
+ msg->channel, txlen, rxlen);
/* Command "nature" */
if (MCDE_DSI_HOST_IS_READ(msg->type))
@@ -210,9 +214,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
if (mipi_dsi_packet_format_is_long(msg->type))
val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT;
val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT;
- /* Add one to the length for the MIPI DCS command */
- val |= txlen
- << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
+ val |= txlen << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN;
val |= msg->type << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT;
writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS);
@@ -249,17 +251,36 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
writel(1, d->regs + DSI_DIRECT_CMD_SEND);
loop_counter = 1000 * 1000 / loop_delay_us;
- while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
- DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
- && --loop_counter)
- usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
-
- if (!loop_counter) {
- dev_err(d->dev, "DSI write timeout!\n");
- return -ETIME;
+ if (MCDE_DSI_HOST_IS_READ(msg->type)) {
+ /* Read command */
+ while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
+ (DSI_DIRECT_CMD_STS_READ_COMPLETED |
+ DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR))
+ && --loop_counter)
+ usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
+ if (!loop_counter) {
+ dev_err(d->dev, "DSI read timeout!\n");
+ return -ETIME;
+ }
+ } else {
+ /* Writing only */
+ while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
+ DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
+ && --loop_counter)
+ usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
+
+ if (!loop_counter) {
+ dev_err(d->dev, "DSI write timeout!\n");
+ return -ETIME;
+ }
}
val = readl(d->regs + DSI_DIRECT_CMD_STS);
+ if (val & DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR) {
+ dev_err(d->dev, "read completed with error\n");
+ writel(1, d->regs + DSI_DIRECT_CMD_RD_INIT);
+ return -EIO;
+ }
if (val & DSI_DIRECT_CMD_STS_ACKNOWLEDGE_WITH_ERR_RECEIVED) {
val >>= DSI_DIRECT_CMD_STS_ACK_VAL_SHIFT;
dev_err(d->dev, "error during transmission: %04x\n",
@@ -269,10 +290,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
if (!MCDE_DSI_HOST_IS_READ(msg->type)) {
/* Return number of bytes written */
- if (mipi_dsi_packet_format_is_long(msg->type))
- ret = 4 + txlen;
- else
- ret = 4;
+ ret = txlen;
} else {
/* OK this is a read command, get the response */
u32 rdsz;
@@ -282,7 +300,13 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
rdsz = readl(d->regs + DSI_DIRECT_CMD_RD_PROPERTY);
rdsz &= DSI_DIRECT_CMD_RD_PROPERTY_RD_SIZE_MASK;
rddat = readl(d->regs + DSI_DIRECT_CMD_RDDAT);
- for (i = 0; i < 4 && i < rdsz; i++)
+ if (rdsz < rxlen) {
+ dev_err(d->dev, "read error, requested %zd got %d\n",
+ rxlen, rdsz);
+ return -EIO;
+ }
+ /* FIXME: read more than 4 bytes */
+ for (i = 0; i < 4 && i < rxlen; i++)
rx[i] = (rddat >> (i * 8)) & 0xff;
ret = rdsz;
}
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL 7/7] i.MX defconfig update for 5.4
From: Arnd Bergmann @ 2019-09-03 17:00 UTC (permalink / raw)
To: Shawn Guo
Cc: Stefan Agner, Li Yang, SoC Team, arm-soc, NXP Linux Team,
Sascha Hauer, Fabio Estevam, Linux ARM
In-Reply-To: <20190825153237.28829-7-shawnguo@kernel.org>
On Sun, Aug 25, 2019 at 5:33 PM Shawn Guo <shawnguo@kernel.org> wrote:
> ----------------------------------------------------------------
> i.MX defconfig update for 5.4:
> - Enable pinctrl and clock driver support for i.MX8MN SoC.
> - Enable SDMA support for i.MX8MQ and i.MX8MM SoC, including
> FW_LOADER_USER_HELPER and FW_LOADER_USER_HELPER_FALLBACK to support
> SDMA firmware loading via udev.
> - Enable module build of i.MX8 DDR PMU driver and ETNAVIV GPU driver.
> - Enable module build of OV5645 camera driver in imx_v6_v7_defconfig.
Pulled int arm/defconfig, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] ARM: aspeed: defconfig changes for 5.4
From: Arnd Bergmann @ 2019-09-03 16:59 UTC (permalink / raw)
To: Joel Stanley; +Cc: Andrew Jeffery, SoC Team, arm, Linux ARM, linux-aspeed
In-Reply-To: <CACPK8XdyWzghA0QPDzA_MK5FYwhT5afqDJHNdhc8mfD2uk8MfQ@mail.gmail.com>
On Sun, Aug 25, 2019 at 4:10 PM Joel Stanley <joel@jms.id.au> wrote:
> ----------------------------------------------------------------
> ASPEED defconfig updates for 5.4
>
> - Enable the new AST2600 in multi_v7 and the aspeed_g5 configs.
>
> - Regenerate defconfigs to drop old options
>
> - Clean up network options
Pulled into arm/defconfig, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Allwinner arm64 Defconfig Changes for 5.4
From: Arnd Bergmann @ 2019-09-03 16:57 UTC (permalink / raw)
To: Maxime Ripard; +Cc: SoC Team, arm-soc, Chen-Yu Tsai, Linux ARM
In-Reply-To: <24f215ca-f3a8-4497-bf98-9ba1808b37be.lettre@localhost>
On Fri, Aug 23, 2019 at 4:31 PM Maxime Ripard <mripard@kernel.org> wrote:
> Allwinner arm64 defconfig changes for 5.4
>
> Two patches to enable the IR receiver and the SPDIF transceiver found on
> the Allwinner SoCs.
Pulled into arm/defconfig, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/2] arm64: defconfig: updates for v5.4
From: Arnd Bergmann @ 2019-09-03 16:56 UTC (permalink / raw)
To: Dinh Nguyen; +Cc: SoC Team, arm-soc, Linux ARM
In-Reply-To: <20190819141659.26414-2-dinguyen@kernel.org>
On Mon, Aug 19, 2019 at 4:17 PM Dinh Nguyen <dinguyen@kernel.org> wrote:
> ----------------------------------------------------------------
> arm64 defconfig for v5.4
> - Add CONFIG_DW_WATCHDOG to support the Designware watchdog driver
Pulled into arm/defconfig, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] STM32 defconfig changes for v5.4 #1
From: Arnd Bergmann @ 2019-09-03 16:56 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Kevin Hilman, SoC Team, arm-soc, Maxime Coquelin, Olof Johansson,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <b164eaa8-4553-9c0f-0729-2ecc96fbae7a@st.com>
On Fri, Aug 2, 2019 at 4:49 PM Alexandre Torgue <alexandre.torgue@st.com> wrote:
> ----------------------------------------------------------------
> STM32 defconfig updates for v5.4, round 1
>
> Highlights:
> ----------
>
> -Enable FMC2 NAND (used for STM32MP socs)
> -Enable STM32 booster regulator as module
> -Enable STM32 QSPI as module
Fore reference, I had pulled these before my vacation,
but not sent out an email notification.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] [MT6660] Mediatek Smart Amplifier Driver
From: Mark Brown @ 2019-09-03 16:38 UTC (permalink / raw)
To: richtek.jeff.chang
Cc: alsa-devel, linux-kernel, tiwai, lgirdwood, linux-mediatek,
matthias.bgg, perex, linux-arm-kernel
In-Reply-To: <1567494501-3427-1-git-send-email-richtek.jeff.chang@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3976 bytes --]
On Tue, Sep 03, 2019 at 03:08:21PM +0800, richtek.jeff.chang@gmail.com wrote:
> --- /dev/null
> +++ b/sound/soc/codecs/mt6660.c
> @@ -0,0 +1,802 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + */
Please make the entire comment block a C++ comment so things look more
consistent.
> +struct reg_size_table {
> + u32 addr;
> + u8 size;
> +};
> +static const struct reg_size_table mt6660_reg_size_table[] = {
> + { MT6660_REG_HPF1_COEF, 4 },
> + { MT6660_REG_HPF2_COEF, 4 },
> + { MT6660_REG_TDM_CFG3, 2 },
> + { MT6660_REG_RESV17, 2 },
> + { MT6660_REG_RESV23, 2 },
> + { MT6660_REG_SIGMAX, 2 },
> + { MT6660_REG_DEVID, 2},
> + { MT6660_REG_TDM_CFG3, 2},
> + { MT6660_REG_HCLIP_CTRL, 2},
> + { MT6660_REG_DA_GAIN, 2},
> +};
Please talk to your hardware designers about the benefits of consistent
register sizes :/
> +static int32_t mt6660_i2c_update_bits(struct mt6660_chip *chip,
> + uint32_t addr, uint32_t mask, uint32_t data)
> +{
It would be good to implement a regmap rather than open coding
*everything* - it'd give you things like this without needing to open
code them. Providing you don't use the cache code it should cope fine
with variable register sizes.
> +
> +static int mt6660_i2c_init_setting(struct mt6660_chip *chip)
> +{
> + int i, len, ret;
> + const struct codec_reg_val *init_table;
> +
> + init_table = e4_reg_inits;
> + len = ARRAY_SIZE(e4_reg_inits);
> +
> + for (i = 0; i < len; i++) {
> + ret = mt6660_i2c_update_bits(chip, init_table[i].addr,
> + init_table[i].mask, init_table[i].data);
> + if (ret < 0)
> + return ret;
Why are we not using the chip defaults here?
> +static int mt6660_chip_power_on(
> + struct snd_soc_component *component, int on_off)
> +{
> + struct mt6660_chip *chip = (struct mt6660_chip *)
> + snd_soc_component_get_drvdata(component);
> + int ret = 0;
> + unsigned int val;
> +
> + dev_dbg(component->dev, "%s: on_off = %d\n", __func__, on_off);
> + mutex_lock(&chip->var_lock);
> + if (on_off) {
> + if (chip->pwr_cnt == 0) {
> + ret = mt6660_i2c_update_bits(chip,
> + MT6660_REG_SYSTEM_CTRL, 0x01, 0x00);
> + val = mt6660_i2c_read(chip, MT6660_REG_IRQ_STATUS1);
> + dev_info(chip->dev,
> + "%s reg0x05 = 0x%x\n", __func__, val);
> + }
> + chip->pwr_cnt++;
This looks like you're open coding runtime PM stuff? AFAICT the issue
is that you need to write to this register to do any I/O. Just
implement this via the standard runtime PM framework, you'll need to do
something about the register I/O in the controls (ideally in the
framework, it'd be a lot easier if you did have a cache) but you could
cut out this bit.
> +static int mt6660_component_set_bias_level(struct snd_soc_component *component,
> + enum snd_soc_bias_level level)
> +{
> + struct snd_soc_dapm_context *dapm =
> + snd_soc_component_get_dapm(component);
> + int ret;
> + unsigned int val;
> + struct mt6660_chip *chip = snd_soc_component_get_drvdata(component);
> +
> + if (dapm->bias_level == level) {
> + dev_warn(component->dev, "%s: repeat level change\n", __func__);
This shouldn't be a warning.
> +static const struct snd_kcontrol_new mt6660_component_snd_controls[] = {
> + SOC_SINGLE_EXT_TLV("Volume_Ctrl", MT6660_REG_VOL_CTRL, 0, 255,
> + 1, snd_soc_get_volsw, mt6660_component_put_volsw,
> + vol_ctl_tlv),
> + SOC_SINGLE_EXT("WDT_Enable", MT6660_REG_WDT_CTRL, 7, 1, 0,
> + snd_soc_get_volsw, mt6660_component_put_volsw),
These control names should all use standard ALSA control names - on/off
switches should end in Switch, volume controls in Volume.
> + SOC_SINGLE_EXT("I2SLRS", MT6660_REG_DATAO_SEL, 6, 3, 0,
> + snd_soc_get_volsw, mt6660_component_put_volsw),
> + SOC_SINGLE_EXT("I2SDOLS", MT6660_REG_DATAO_SEL, 3, 7, 0,
> + snd_soc_get_volsw, mt6660_component_put_volsw),
> + SOC_SINGLE_EXT("I2SDORS", MT6660_REG_DATAO_SEL, 0, 7, 0,
> + snd_soc_get_volsw, mt6660_component_put_volsw),
What do these controls do?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 03/10] arm64: atomics: avoid out-of-line ll/sc atomics
From: Will Deacon @ 2019-09-03 16:37 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland, peterz, catalin.marinas, ndesaulniers,
Ard.Biesheuvel, Nathan Chancellor, robin.murphy, linux-arm-kernel
In-Reply-To: <20190903153120.GT9720@e119886-lin.cambridge.arm.com>
On Tue, Sep 03, 2019 at 04:31:20PM +0100, Andrew Murray wrote:
> On Tue, Sep 03, 2019 at 04:15:44PM +0100, Andrew Murray wrote:
> > On Tue, Sep 03, 2019 at 03:45:34PM +0100, Will Deacon wrote:
> > > Does it work if the only thing you change is the toolchain, and use GCC
> > > instead?
> >
> > Yup.
>
> Also this is Clang generation:
>
> ffff8000100f2700 <__ptrace_link>:
> ffff8000100f2700: f9426009 ldr x9, [x0, #1216]
> ffff8000100f2704: 91130008 add x8, x0, #0x4c0
> ffff8000100f2708: eb09011f cmp x8, x9
> ffff8000100f270c: 540002a1 b.ne ffff8000100f2760 <__ptrace_link+0x60> // b.any
> ffff8000100f2710: f9425829 ldr x9, [x1, #1200]
> ffff8000100f2714: 9112c02a add x10, x1, #0x4b0
> ffff8000100f2718: f9000528 str x8, [x9, #8]
> ffff8000100f271c: f9026009 str x9, [x0, #1216]
> ffff8000100f2720: f902640a str x10, [x0, #1224]
> ffff8000100f2724: f9025828 str x8, [x1, #1200]
> ffff8000100f2728: f9024001 str x1, [x0, #1152]
> ffff8000100f272c: b4000162 cbz x2, ffff8000100f2758 <__ptrace_link+0x58>
> ffff8000100f2730: b900985f str wzr, [x2, #152]
> ffff8000100f2734: 14000004 b ffff8000100f2744 <__ptrace_link+0x44>
> ffff8000100f2738: 14000001 b ffff8000100f273c <__ptrace_link+0x3c>
> ffff8000100f273c: 14000006 b ffff8000100f2754 <__ptrace_link+0x54>
> ffff8000100f2740: 14000001 b ffff8000100f2744 <__ptrace_link+0x44>
> ffff8000100f2744: 52800028 mov w8, #0x1 // #1
> ffff8000100f2748: b828005f stadd w8, [x2]
> ffff8000100f274c: f9030002 str x2, [x0, #1536]
> ffff8000100f2750: d65f03c0 ret
> ffff8000100f2754: 140007fd b ffff8000100f4748 <ptrace_check_attach+0xf8>
> ...
>
> This looks like the default path (before we write over it) will take you to
> the LSE code (e.g. ffff8000100f2734). I'm pretty sure this is wrong, or at
> least not what we expected to see. Also why 4 branches?
So I reproduced this with a silly atomic_inc wrapper:
void will_atomic_inc(atomic_t *v)
{
atomic_inc(v);
}
Compiles to:
0000000000000018 <will_atomic_inc>:
18: 14000004 b 28 <will_atomic_inc+0x10>
1c: 14000001 b 20 <will_atomic_inc+0x8>
20: 14000005 b 34 <will_atomic_inc+0x1c>
24: 14000001 b 28 <will_atomic_inc+0x10>
28: 52800028 mov w8, #0x1 // #1
2c: b828001f stadd w8, [x0]
30: d65f03c0 ret
34: 14000027 b d0 <dump_kernel_offset+0x60>
38: d65f03c0 ret
which is going to explode.
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 AUTOSEL 5.2 17/23] usb: chipidea: imx: fix EPROBE_DEFER support during driver probe
From: Sasha Levin @ 2019-09-03 16:24 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Peter Chen, Fabio Estevam, André Draszik, Sascha Hauer,
linux-usb, NXP Linux Team, Pengutronix Kernel Team,
Greg Kroah-Hartman, Shawn Guo, linux-arm-kernel
In-Reply-To: <20190903162424.6877-1-sashal@kernel.org>
From: André Draszik <git@andred.net>
If driver probe needs to be deferred, e.g. because ci_hdrc_add_device()
isn't ready yet, this driver currently misbehaves badly:
a) success is still reported to the driver core (meaning a 2nd
probe attempt will never be done), leaving the driver in
a dysfunctional state and the hardware unusable
b) driver remove / shutdown OOPSes:
[ 206.786916] Unable to handle kernel paging request at virtual address fffffdff
[ 206.794148] pgd = 880b9f82
[ 206.796890] [fffffdff] *pgd=abf5e861, *pte=00000000, *ppte=00000000
[ 206.803179] Internal error: Oops: 37 [#1] PREEMPT SMP ARM
[ 206.808581] Modules linked in: wl18xx evbug
[ 206.813308] CPU: 1 PID: 1 Comm: systemd-shutdow Not tainted 4.19.35+gf345c93b4195 #1
[ 206.821053] Hardware name: Freescale i.MX7 Dual (Device Tree)
[ 206.826813] PC is at ci_hdrc_remove_device+0x4/0x20
[ 206.831699] LR is at ci_hdrc_imx_remove+0x20/0xe8
[ 206.836407] pc : [<805cd4b0>] lr : [<805d62cc>] psr: 20000013
[ 206.842678] sp : a806be40 ip : 00000001 fp : 80adbd3c
[ 206.847906] r10: 80b1b794 r9 : 80d5dfe0 r8 : a8192c44
[ 206.853136] r7 : 80db93a0 r6 : a8192c10 r5 : a8192c00 r4 : a93a4a00
[ 206.859668] r3 : 00000000 r2 : a8192ce4 r1 : ffffffff r0 : fffffdfb
[ 206.866201] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 206.873341] Control: 10c5387d Table: a9e0c06a DAC: 00000051
[ 206.879092] Process systemd-shutdow (pid: 1, stack limit = 0xb271353c)
[ 206.885624] Stack: (0xa806be40 to 0xa806c000)
[ 206.889992] be40: a93a4a00 805d62cc a8192c1c a8170e10 a8192c10 8049a490 80d04d08 00000000
[ 206.898179] be60: 00000000 80d0da2c fee1dead 00000000 a806a000 00000058 00000000 80148b08
[ 206.906366] be80: 01234567 80148d8c a9858600 00000000 00000000 00000000 00000000 80d04d08
[ 206.914553] bea0: 00000000 00000000 a82741e0 a9858600 00000024 00000002 a9858608 00000005
[ 206.922740] bec0: 0000001e 8022c058 00000000 00000000 a806bf14 a9858600 00000000 a806befc
[ 206.930927] bee0: a806bf78 00000000 7ee12c30 8022c18c a806bef8 a806befc 00000000 00000001
[ 206.939115] bf00: 00000000 00000024 a806bf14 00000005 7ee13b34 7ee12c68 00000004 7ee13f20
[ 206.947302] bf20: 00000010 7ee12c7c 00000005 7ee12d04 0000000a 76e7dc00 00000001 80d0f140
[ 206.955490] bf40: ab637880 a974de40 60000013 80d0f140 ab6378a0 80d04d08 a8080470 a9858600
[ 206.963677] bf60: a9858600 00000000 00000000 8022c24c 00000000 80144310 00000000 00000000
[ 206.971864] bf80: 80101204 80d04d08 00000000 80d04d08 00000000 00000000 00000003 00000058
[ 206.980051] bfa0: 80101204 80101000 00000000 00000000 fee1dead 28121969 01234567 00000000
[ 206.988237] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000
[ 206.996425] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6 60000030 fee1dead 00000000 00000000
[ 207.004622] [<805cd4b0>] (ci_hdrc_remove_device) from [<805d62cc>] (ci_hdrc_imx_remove+0x20/0xe8)
[ 207.013509] [<805d62cc>] (ci_hdrc_imx_remove) from [<8049a490>] (device_shutdown+0x16c/0x218)
[ 207.022050] [<8049a490>] (device_shutdown) from [<80148b08>] (kernel_restart+0xc/0x50)
[ 207.029980] [<80148b08>] (kernel_restart) from [<80148d8c>] (sys_reboot+0xf4/0x1f0)
[ 207.037648] [<80148d8c>] (sys_reboot) from [<80101000>] (ret_fast_syscall+0x0/0x54)
[ 207.045308] Exception stack(0xa806bfa8 to 0xa806bff0)
[ 207.050368] bfa0: 00000000 00000000 fee1dead 28121969 01234567 00000000
[ 207.058554] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000
[ 207.066737] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6
[ 207.071799] Code: ebffffa8 e3a00000 e8bd8010 e92d4010 (e5904004)
[ 207.078021] ---[ end trace be47424e3fd46e9f ]---
[ 207.082647] Kernel panic - not syncing: Fatal exception
[ 207.087894] ---[ end Kernel panic - not syncing: Fatal exception ]---
c) the error path in combination with driver removal causes
imbalanced calls to the clk_*() and pm_()* APIs
a) happens because the original intended return value is
overwritten (with 0) by the return code of
regulator_disable() in ci_hdrc_imx_probe()'s error path
b) happens because ci_pdev is -EPROBE_DEFER, which causes
ci_hdrc_remove_device() to OOPS
Fix a) by being more careful in ci_hdrc_imx_probe()'s error
path and not overwriting the real error code
Fix b) by calling the respective cleanup functions during
remove only when needed (when ci_pdev != NULL, i.e. when
everything was initialised correctly). This also has the
side effect of not causing imbalanced clk_*() and pm_*()
API calls as part of the error code path.
Fixes: 7c8e8909417e ("usb: chipidea: imx: add HSIC support")
Signed-off-by: André Draszik <git@andred.net>
Cc: stable <stable@vger.kernel.org>
CC: Peter Chen <Peter.Chen@nxp.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Shawn Guo <shawnguo@kernel.org>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Pengutronix Kernel Team <kernel@pengutronix.de>
CC: Fabio Estevam <festevam@gmail.com>
CC: NXP Linux Team <linux-imx@nxp.com>
CC: linux-usb@vger.kernel.org
CC: linux-arm-kernel@lists.infradead.org
CC: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20190810150758.17694-1-git@andred.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/chipidea/ci_hdrc_imx.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index a76708501236d..5faae96735e62 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -453,9 +453,11 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
imx_disable_unprepare_clks(dev);
disable_hsic_regulator:
if (data->hsic_pad_regulator)
- ret = regulator_disable(data->hsic_pad_regulator);
+ /* don't overwrite original ret (cf. EPROBE_DEFER) */
+ regulator_disable(data->hsic_pad_regulator);
if (pdata.flags & CI_HDRC_PMQOS)
pm_qos_remove_request(&data->pm_qos_req);
+ data->ci_pdev = NULL;
return ret;
}
@@ -468,14 +470,17 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
pm_runtime_put_noidle(&pdev->dev);
}
- ci_hdrc_remove_device(data->ci_pdev);
+ if (data->ci_pdev)
+ ci_hdrc_remove_device(data->ci_pdev);
if (data->override_phy_control)
usb_phy_shutdown(data->phy);
- imx_disable_unprepare_clks(&pdev->dev);
- if (data->plat_data->flags & CI_HDRC_PMQOS)
- pm_qos_remove_request(&data->pm_qos_req);
- if (data->hsic_pad_regulator)
- regulator_disable(data->hsic_pad_regulator);
+ if (data->ci_pdev) {
+ imx_disable_unprepare_clks(&pdev->dev);
+ if (data->plat_data->flags & CI_HDRC_PMQOS)
+ pm_qos_remove_request(&data->pm_qos_req);
+ if (data->hsic_pad_regulator)
+ regulator_disable(data->hsic_pad_regulator);
+ }
return 0;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 02/11] kselftest: arm64: adds first test and common utils
From: Cristian Marussi @ 2019-09-03 16:08 UTC (permalink / raw)
To: Dave Martin; +Cc: andreyknvl, shuah, linux-kselftest, linux-arm-kernel
In-Reply-To: <20190903153456.GM27757@arm.com>
Hi
On 03/09/2019 16:34, Dave Martin wrote:
> Hi, responding to some non-trivial comments here where re-work isn't
> needed -- so we have the right context for the mail thread.
>
> For any remaining nits, I'll comment on the v5 patch.
>
ok
> On Wed, Aug 28, 2019 at 06:34:09PM +0100, Cristian Marussi wrote:
>> Hi
>>
>> On 13/08/2019 17:24, Dave Martin wrote:
>
> [...]
>
>>>> diff --git a/tools/testing/selftests/arm64/signal/Makefile b/tools/testing/selftests/arm64/signal/Makefile
>
> [...]
>
>>>> +# Guessing as best as we can where the Kernel headers
>>>> +# could have been installed depending on ENV config and
>>>> +# type of invocation.
>>>> +ifeq ($(KBUILD_OUTPUT),)
>>>> +khdr_dir = $(top_srcdir)/usr/include
>>>> +else
>>>> +ifeq (0,$(MAKELEVEL))
>>>> +khdr_dir = $(KBUILD_OUTPUT)/usr/include
>>>> +else
>>>> +# the KSFT preferred location when KBUILD_OUTPUT is set
>>>> +khdr_dir = $(KBUILD_OUTPUT)/kselftest/usr/include
>>>> +endif
>>>> +endif
>>>
>>> When is KBUILD_OUTPUT set / not set?
>>>
>>
>> Depending how the user/CI is configured KSFT installs the kernel
>> headers in different places....here I'm trying to guess where they
>> have been installed by KSFT.
>>
>>>> +
>>>> +CFLAGS += -I$(khdr_dir)
>>>
>>> Do we rely on any non-UAPI headers? If not, the default should probably
>>> be to rely on the system headers (or toolchain default headers) -- i.e.,
>>> add no -I option at all.
>>
>> I only need updated UAPI headers, but I cannot build without this specific -I..
>> that points to the installed kernel headers directory.
>>
>> As an example it fails with: undefined HWCAP_SSBS if I remove the -I
>>
>>>
>>> I'm wondering why none of the other kselftests need this header search
>>> logic.
>>>
>>
>> Well... a lot of KSFT tests has something related to headers search in their Makefiles:
>>
>> ../kcmp/Makefile:CFLAGS += -I../../../../usr/include/
>> ../networking/timestamping/Makefile:CFLAGS += -I../../../../../usr/include
>> ../ipc/Makefile:CFLAGS += -I../../../../usr/include/
>> ../memfd/Makefile:CFLAGS += -I../../../../include/uapi/
>> ../memfd/Makefile:CFLAGS += -I../../../../include/
>> ../memfd/Makefile:CFLAGS += -I../../../../usr/include/
>>
>> which seems aimed at doing the same thing, but it is a broken approach
>> as far as I can see since if KBUILD_OUTPUT is set, KSFT will install the
>> headers accordingly, so that the above static includes won't work anymore.
>>
>> Not sure if I'm missing something here, but my understanding was that
>>
>> - some KSFT requires arch specific bits, usually included within the dedicated kernel
>> headers provided with the source itself and installed with make headers_install.
>>
>> and that
>>
>> - such headers can be found naturally, being included from top level libc headers
>> only if:
>>
>> 1. a fully updated toolchain containing updated headers too is available at CROSS_COMPILE=
>>
>> or
>>
>> 2. proper -I options are specified to the compiler to specify where KSFT installed the
>> kernel headers related to this kernel and its related KSFT testcases
>>
>> or
>>
>> 3. updated kernel headers were installed on top of the available CROSS_COMPILE toolchain
>>
>> or
>>
>> 4. we are building and running natively, so you can install the kernel headers on
>> system default path and those will be searched
>>
>>
>> My 'feeling' would have been that in the KSFT scenario we should try to stick with option 2.,
>> in order to be able to run KSFT and run the related testcases, relying just on the shipped
>> Kernel/KSFT and possibly underlying hw features, but not having any dependencies
>> on the toolchain/libc.
>>
>> My question is: what happens on a CI-somewhere if suddenly there's the need to update
>> the toolchain somehow (fully or partially only the headers) to be able to simply
>> build/run the new KSFT included with this Kernel ?; even if we accept this need to update
>> the toochain, where this CI should get/scrap-from these minimum toolchain requirements ?
>> (in an automated manner)
>>
>> If instead we can agree to stick with 2., I wonder if this locate-headers mechanism which I introduced
>> here should be in charge of the KSFT framework or if there is something broken in my tests: but
>> in these regards similar issues seems to affect KSFT arm64 tags tests queued on arm64/for-next
>>
>> https://lkml.org/lkml/2019/8/23/721
>
> Ack, I think we should stick with option 2 for now, but I agree to keep
> it local to your tests for now to avoid breaking stuff elsewhere.
>
> In general I think that kselftest should always search the installed
> UAPI headers from the containing kernel tree first, since that's the
> best way to ensure the headers are 100% up to date.
>
> This may need wider discussion in order to be deployed more widely
> across kselftest though.
>
Yes I agree, in the meantime in V5 I moved such mechanism (2. add -I$(khdr_src)) into the toplevel
KSFT arm64 Makefile at least so that it transparently works for all arm64 KSFT test families...in fact
in this way now also KSFT tags tests from Andrey compile fine (without a custom -I ../../../)
...not sure if it is the proper fix anyway.
> [...]
>
>>>> diff --git a/tools/testing/selftests/arm64/signal/test_signals.h b/tools/testing/selftests/arm64/signal/test_signals.h
>
> [...]
>
>>>> + * "The infrastructure emulates only the following system register space:
>>>> + * Op0=3, Op1=0, CRn=0, CRm=0,4,5,6,7
>>>> + */
>>>> +#define get_regval(regname, out) \
>>>> + asm volatile("mrs %0, " __stringify(regname) : "=r" (out) :: "memory")
>>>> +
>>>> +/* Regs encoding and masks naming copied in from sysreg.h */
>>>> +#define SYS_ID_AA64MMFR1_EL1 S3_0_C0_C7_1 /* MRS Emulated */
>>>> +#define SYS_ID_AA64MMFR2_EL1 S3_0_C0_C7_2 /* MRS Emulated */
>>>
>>> These ID regs are part of armv8.0-a, so we don't need to use the magic
>>> syntax.
>>> mmm... why I found them in non UAPI headers defined as follows ?
>>
>> arch/arm64/include/asm/sysreg.h:#define SYS_ID_AA64MMFR1_EL1 sys_reg(3, 0, 0, 7, 1)
>>
>> anyway I tried to use nonS3 regular sysreg naming (with a reasonably new compiler:
>>
>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-
>>
>> and it fails (only on id_aa64mmfr2_el1) as follows:
>> /tmp/ccqAyE8P.s: Assembler messages:
>> /tmp/ccoGrnGc.s:1085: Error: selected processor does not support system register name 'id_aa64mmfr2_el1'
>>
>> In fact this seems to remind me (not totally sure) that this was the reason to use such S3 syntax on this
>> sysregs too.
>
> Ah, it looks like ID_AA64MMFR2_EL1 was added from ARMv8.2-A only. My
> bad.
>
> To keep things consistent, I'm fine with keeping the S3_ syntax for
> everything here.
>
>>>> +#define ID_AA64MMFR1_PAN_SHIFT 20
>>>> +#define ID_AA64MMFR2_UAO_SHIFT 4
>
> [...]
>
Not sure if in v5 I fixed only the fixable or left everything as it was...I have to double check.
>>>> diff --git a/tools/testing/selftests/arm64/signal/test_signals_utils.c b/tools/testing/selftests/arm64/signal/test_signals_utils.c
>
> [...]
>
>>>> +static inline bool are_feats_ok(struct tdescr *td)
>>>> +{
>>>> + return td ? td->feats_required == td->feats_supported : 0;
>>>
>>> Should this be something like
>>> (td->feats_required & td->feats_supported) == td->feats_required ?
>>>
>>> Otherwise additional supported features that our test doesn't care about
>>> will cause this check to fail.
>>>
>> Yes better.
>>
>>>
>>> Do we really need to check td?
>>>
>>
>> Overly defensive
>>
>>> assert(foo); followed by dereferincing foo is usually a bit pointless
>>> because you'd get a SIGSEGV anyway.
>>>
>>> However, since the tests generate deliberate SIGSEGVs too this could
>>> be confusing -- in which case, having an explicit assert() here does
>>> no harm.
>>>
>> not sure about which assert you refer here
>
> I was persuading myself that my own comment was unnecessary, so don't
> worry about it. The code is fine as-is.
ok
>
>>>> +}
>>>> +
>>>> +static void default_handler(int signum, siginfo_t *si, void *uc)
>>>> +{
>>>> + if (current->sig_trig && signum == current->sig_trig) {
>>>> + fprintf(stderr, "Handling SIG_TRIG\n");
>>>> + current->triggered = 1;
>>>> + /* ->run was asserted NON-NULL in test_setup() already */
>>>> + current->run(current, si, uc);
>>>> + } else if (signum == SIGILL && !current->initialized) {
>>>> + /*
>>>> + * A SIGILL here while still not initialized means we failed
>>>> + * even to asses the existence of features during init
>>>> + */
>>>> + fprintf(stdout,
>>>> + "Got SIGILL test_init. Marking ALL features UNSUPPORTED.\n");
>>>> + current->feats_supported = 0;
>>>> + } else if (current->sig_ok && signum == current->sig_ok) {
>>>> + /* it's a bug in the test code when this assert fail */
>>>
>>> Why? Is this because sig_ok is considered acceptable only as an effect
>>> of the test -- i.e., we shouldn't see it if the test hasn't been
>>> triggered yet?
>>
>> This assert would like to ensure that when you receive a sig_ok signal,
>> if a sig_trig was defined != 0, the trigger have been in fact used and processed before
>> receiving this sig_ok here: so you didn't define a signal trigger at all, or, if defined
>> it has been fired to arrive here. I'll add some commenting about this.
>
> OK
>
>>>> + assert(!current->sig_trig || current->triggered);
>>>> + fprintf(stderr,
>>>> + "SIG_OK -- SP:%p si_addr@:0x%p si_code:%d token@:0x%p offset:%ld\n",
>>>> + ((ucontext_t *)uc)->uc_mcontext.sp,
>>>> + si->si_addr, si->si_code, current->token,
>>>> + current->token - si->si_addr);
>>>> + /*
>>>> + * fake_sigreturn tests, which have sanity_enabled=1, set, at
>>>> + * the very last time, the token field to the SP address used
>>>> + * to place the fake sigframe: so token==0 means we never made
>>>> + * it to the end, segfaulting well-before, and the test is
>>>> + * possibly broken.
>>>> + */
>>>> + if (!current->sanity_disabled && !current->token) {
>>>> + fprintf(stdout,
>>>> + "current->token ZEROED...test is probably broken!\n");
>>>> + assert(0);
>>>
>>> In case someone builds with -DNDEBUG, should we add abort()?
>>>
>> Well, in such a case all the test suite is mostly compromised anyway.
>> But you are right, I'll add an abort() at least here when broken tests
>> are detected.
>
> I guess you're right. The abort() does no harm, anyway.
> Gone with abort() in v5
> [...]
>
>>>> diff --git a/tools/testing/selftests/arm64/signal/testcases/testcases.c b/tools/testing/selftests/arm64/signal/testcases/testcases.c
>
> [...]
>
>>>> +bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err)
>>>> +{
>>>> + bool terminated = false;
>>>> + size_t offs = 0;
>>>> + int flags = 0;
>>>> + struct extra_context *extra = NULL;
>>>> + struct _aarch64_ctx *head =
>>>> + (struct _aarch64_ctx *)uc->uc_mcontext.__reserved;
>>>> +
>>>> + if (!err)
>>>> + return false;
>>>> + /* Walk till the end terminator verifying __reserved contents */
>>>> + while (head && !terminated && offs < resv_sz) {
>>>> + if ((uint64_t)head & 0x0fUL) {
>>>> + *err = "Misaligned HEAD";
>>>> + return false;
>>>> + }
>>>> +
>>>> + switch (head->magic) {
>>>> + case 0:
>>>> + if (head->size)
>>>> + *err = "Bad size for MAGIC0";
>>>
>>> Or "terminator". We don't have an actual symbolic name for magic number
>>> 0. (Arguably it would have been nice to have a name, but we managed
>>> without.)
>>
>> ok
>>>
>>>> + else
>>>> + terminated = true;
>>>> + break;
>>>> + case FPSIMD_MAGIC:
>>>> + if (flags & FPSIMD_CTX)
>>>> + *err = "Multiple FPSIMD_MAGIC";
>>>> + else if (head->size !=
>>>> + sizeof(struct fpsimd_context))
>>>> + *err = "Bad size for fpsimd_context";
>>>> + flags |= FPSIMD_CTX;
>>>> + break;
>>>> + case ESR_MAGIC:
>>>> + if (head->size != sizeof(struct esr_context))
>>>> + fprintf(stderr,
>>>> + "Bad size for esr_context is not an error...just ignore.\n");
>>>
>>> Why isn't this an error? Should the kernel ever write an esr_context
>>> with a different size?
>>
>> There is no check on Kernel side:
>>
>> case ESR_MAGIC:
>> /* ignore */
>> break;
>>
>> so I sticked with that, since this function can be used to validate a
>> Kernel originated sigframe or a crafted one which will be passed down
>> to the Kernel.
>
> I see where you're coming from: I'll comment on the v5 patch instead of
> here, to make it easier to track any rework.
>
ok
> [...]
>
>>>> + if (flags & EXTRA_CTX)
>>>> + if (!validate_extra_context(extra, err))
>>>> + return false;
>>>
>>> Can we validate the contents of the extra context too?
>>>
>>> Ideally we can use the same code to check __reserved[] and the extra
>>> context.
>>>
>> Do you mean the content pointed by extra->datap ?
>> This extra_context validation routine is generally under review and fixes in a further
>> arm64/signal SVE extensions patch still to be published (and cleaned up):
>> [kselftest: arm64: adds SVE-related signal test], given that EXTRA_CONTEXT can effectively
>> appear only when SVE related instruction are used properly.
>>
>> Should I introduce this and other extra-context related fixes here instead ?
>> (it is hard to test and debug without any triggering SVE instruction though...)
>
> No, it's fine to exclude it for now.
>
> If there's a plan to add it later, that's good enough for me.
ok
>
> [...]
>
> Cheers
> ---Dave
>
Thanks
Cheers
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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