* [PATCH 2/3] arm64: defconfig: Enable the EFI Framebuffer
From: Lee Jones @ 2019-09-03 19:26 UTC (permalink / raw)
To: soc; +Cc: Lee Jones, linux-kernel, linux-arm-kernel
In-Reply-To: <20190903192625.14775-1-lee.jones@linaro.org>
Tested on the Lenovo Yoga C630 where this patch enables the
framebuffer (screen/monitor). Without it the device appears
not to boot.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0fe943ac53b5..af7ca722b519 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -540,6 +540,7 @@ CONFIG_DRM_LIMA=m
CONFIG_DRM_PANFROST=m
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
+CONFIG_FB_EFI=y
CONFIG_BACKLIGHT_GENERIC=m
CONFIG_BACKLIGHT_PWM=m
CONFIG_BACKLIGHT_LP855X=m
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] arm64: defconfig: Enable Qualcomm GENI based I2C controller
From: Lee Jones @ 2019-09-03 19:26 UTC (permalink / raw)
To: soc; +Cc: Lee Jones, linux-kernel, linux-arm-kernel
Tested on the Lenovo Yoga C630 where this patch enables the
keyboard, touchpad and touchscreen.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index facf19cc275d..0fe943ac53b5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -366,6 +366,7 @@ CONFIG_I2C_IMX_LPI2C=y
CONFIG_I2C_MESON=y
CONFIG_I2C_MV64XXX=y
CONFIG_I2C_PXA=y
+CONFIG_I2C_QCOM_GENI=m
CONFIG_I2C_QUP=y
CONFIG_I2C_RK3X=y
CONFIG_I2C_SH_MOBILE=y
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCHv1 0/3] Odroid c2 missing regulator linking
From: Martin Blumenstingl @ 2019-09-03 19:07 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: <CANAwSgQwZg_AXAnAY4KwDzHpwcSA9up7SrR6jyv5Bem24wtaJg@mail.gmail.com>
Hi Anand,
On Fri, Aug 30, 2019 at 11:34 AM Anand Moon <linux.amoon@gmail.com> wrote:
[...]
> > SCPI works fine on all tested devices, except Odroid-C2, because Hardkernel left
> > the > 1.5GHz freq in the initial SCPI tables loaded by the BL2, i.e. packed with U-Boot.
> > Nowadays they have removed the bad frequencies, but still some devices uses the old
> > bootloader.
> >
> > But in the SCPI case we trust the table returned by the firmware and use it as-in,
> > and there is no (simple ?) way to override the table and set a max frequency.
> >
> > This is why we disabled SCPI.
> >
> > See https://patchwork.kernel.org/patch/9500175/
>
> I have quickly enable this on my board and here the cpufreq info
[...]
> Almost all the test case pass with this one as off now.
I suggest to send an RFC patch to (re-)enable DVFS on Odroid-C2
I find it easy to miss a DVFS discussion inside a "missing regulator" series
with a separate patch you can also get feedback from other Odroid-C2
owners who can help testing
coincidence or not: on Friday someone asked in the #linux-amlogic IRC
channel why Odroid-C2 didn't have DVFS enabled and what to do about it
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2-next 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
From: Martin Blumenstingl @ 2019-09-03 19:03 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: <20190902085821.1263-2-linux.amoon@gmail.com>
Hi Anand,
On Mon, Sep 2, 2019 at 10:58 AM Anand Moon <linux.amoon@gmail.com> wrote:
>
> As per schematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
> fixed regulator output which is supplied by P5V0.
>
> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
one comment below, but overall this looks good:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[...]
> + vddc_ddr: regulator-vddc-ddr {
> + compatible = "regulator-fixed";
> + regulator-name = "DDR3_1V5";
I prefer if the node name matches the regulator name, so in this case
I would write above:
ddr3_1v5: regulator-ddr-1v5 {
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2-next 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
From: Martin Blumenstingl @ 2019-09-03 19:00 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: <20190902085821.1263-4-linux.amoon@gmail.com>
On Mon, Sep 2, 2019 at 10:58 AM Anand Moon <linux.amoon@gmail.com> wrote:
>
> As per schematics HDMI_P5V0 is supplied by P5V0 so add missing link.
>
> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [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
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