Re: [PATCH v3 3/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board support
Hi Dillon,
On Thu, Apr 15, 2021 at 1:05 AM wrote:
> + green {
> + gpios = <&gpio4 8 0>;
Please use GPIO_ACTIVE_HIGH label instead:
gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
> +&clks {
> + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> + <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
> +<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
> +};
You are setting the LDB clock parent, but you don't use LDB in this
devicetree. You could simply remove this.
> +&ecspi1 {
> + cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi1>;
> + status = "okay";
> +
> + flash: m25p80@0 {
Node names should be generic:
m25p80: flash@0
> +&iomuxc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hog>;
> +
> + imx6qdl-ds {
> + pinctrl_hog: hoggrp {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
> + MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> + MX6QDL_PAD_GPIO_0__CCM_CLKO10x130b0
This could be part of the pinctrl_ov2659 group as it provides the
clock for the camera.
Please try to keep in the hoggrp only the pins that cannot be
controlled by any other node.
> +&wdog1 {
> + status = "okay";
> +};
> +
> +&wdog2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wdog>;
> + fsl,ext-reset-output;
> + status = "disabled";
Wouldn't it be better to enable wdog2 and disable wdog1 instead? wdog2
provides a POR, which is preferred.
Re: [PATCH] imx-sc: remove .read_alarm
Hi Alexandre, On Sat, Apr 17, 2021 at 8:52 PM Alexandre Belloni wrote: > > The RTC core properly handles RTC without .read_alarm and doesn't use it to > set alarms. .read_alarm can be safely dropped. > > Signed-off-by: Alexandre Belloni Reviewed-by: Fabio Estevam
Re: [PATCH stable] gpiolib: Read "gpio-line-names" from a firmware node
Hi Greg, On Sat, Apr 10, 2021 at 6:15 AM Greg Kroah-Hartman wrote: > What is the git commit id of it in Linus's tree? It is b41ba2ec54a70908067034f139aa23d0dd2985ce Thanks
Re: [PATCH v2 0/7] remove different PHY fixups
Hi Andrew, On Tue, Mar 30, 2021 at 11:30 AM Andrew Lunn wrote: > Hi Fabio > > I think it should be merged, and we fixup anything which does break. > We are probably at the point where more is broken by not merging it > than merging it. Thanks for your feedback. I agree. Shawn wants to collect some Acked-by for this series. Could you please give your Acked-by for this series? Thanks
Re: [PATCH v2 0/7] remove different PHY fixups
Hi Oleksij, On Tue, Mar 9, 2021 at 8:26 AM Oleksij Rempel wrote: > > changes v2: > - rebase against latest kernel > - fix networking on RIoTBoard > > This patch series tries to remove most of the imx6 and imx7 board > specific PHY configuration via fixup, as this breaks the PHYs when > connected to switch chips or USB Ethernet MACs. > > Each patch has the possibility to break boards, but contains a > recommendation to fix the problem in a more portable and future-proof > way. I think this series moves us in the right direction, even with the possibility to break old dtb's. Reviewed-by: Fabio Estevam Andrew, what do you think? Thanks
Re: [PATCH] usb: dwc3: imx8mp: fix incorrect kernel-doc comment syntax
Hi Aditya, On Mon, Mar 29, 2021 at 11:26 AM Aditya Srivastava wrote: > > The opening comment mark '/**' is used for highlighting the beginning of > kernel-doc comments. > The header for drivers/usb/dwc3/dwc3-imx8mp.c follows this syntax, but the > content inside does not comply with kernel-doc. > > This line was probably not meant for kernel-doc parsing, but is parsed > due to the presence of kernel-doc like comment syntax(i.e, '/**'), which > causes unexpected warning from kernel-doc: > "warning: expecting prototype for dwc3(). Prototype was for USB_WAKEUP_CTRL() > instead" > > Provide a simple fix by replacing this occurrence with general comment > format, i.e. '/*', to prevent kernel-doc from parsing it. > > Signed-off-by: Aditya Srivastava It looks good, thanks: Reviewed-by: Fabio Estevam
Re: [PATCH v2 1/3] ARM: dts: imx6: pfla02: Fix USB vbus enable pinmuxing
Hi Stefan, On Mon, Mar 29, 2021 at 10:01 AM Stefan Riedmueller wrote: > > The pinmuxing for the enable pin of the usbh1 node is wrong. It needs to > be muxed as GPIO. While at it, move the pinctrl to the vbus regulator > since it is actually the regulator enable pin. > > Signed-off-by: Stefan Riedmueller Thanks for the respin: Reviewed-by: Fabio Estevam
Re: [PATCH 3/3] ARM: dts: imx6: pbab01: Set vmmc supply for both SD interfaces
On Mon, Mar 29, 2021 at 8:28 AM Stefan Riedmueller wrote: > > Setting the vmmc supplies is crucial since otherwise the supplying > regulators get disabled and the SD interfaces are no longer powered > which leads to system failures if the system is booted from that SD > interface. It seems that this deserves a Fixes tag. Reviewed-by: Fabio Estevam
Re: [PATCH 2/3] ARM: dts: imx6: pbab01: Set USB OTG port to peripheral
On Mon, Mar 29, 2021 at 8:28 AM Stefan Riedmueller wrote: > > Due to a hardware bug preventing the correct detection if the ID pin > the USB OTG port cannot be used in otg mode. It can either be set to > host or peripheral. Set it to peripheral so vbus is disabled by default. > > Signed-off-by: Stefan Riedmueller Reviewed-by: Fabio Estevam
Re: [PATCH 1/3] ARM: dts: imx6: pfla02: Fix USB vbus enable pinmuxing
Hi Stefan,
On Mon, Mar 29, 2021 at 8:28 AM Stefan Riedmueller
wrote:
> - pinctrl_usbh1: usbh1grp {
> + pinctrl_usbh1_vbus: usbh1vbusgrp {
> fsl,pins = <
> - MX6QDL_PAD_GPIO_0__USB_H1_PWR
> 0x8000
> + MX6QDL_PAD_GPIO_0__GPIO1_IO00
> 0x8000
While you are on it, could you please use avoid the usage of
0x8000 and explicitly pass the default value instead?
Re: [PATCH v2] arm64: dts: imx8mm/q: Fix pad control of SD1_DATA0
Hi Oliver, On Wed, Mar 24, 2021 at 10:28 AM Oliver Stäbler wrote: > > Fix address of the pad control register > (IOMUXC_SW_PAD_CTL_PAD_SD1_DATA0) for SD1_DATA0_GPIO2_IO2. This seems > to be a typo but it leads to an exception when pinctrl is applied due to > wrong memory address access. > > Signed-off-by: Oliver Stäbler Thanks for the fix: Reviewed-by: Fabio Estevam
Re: [PATCH] arm64: dts: imx8mm: Fix pad control of SD1_DATA0
Hi Oliver, On Tue, Mar 23, 2021 at 5:15 PM Oliver Stäbler wrote: > > Fix address of the pad control register > (IOMUXC_SW_PAD_CTL_PAD_SD1_DATA0) for SD1_DATA0_GPIO2_IO2. This seems > to be a typo but it leads to an exception when pinctrl is applied due to > wrong memory address access. > > Signed-off-by: Oliver Stäbler I checked in the RM and your patch is correct, thanks: Reviewed-by: Fabio Estevam I will send a patch fixing imx8mq-pinfunc.h as it has the same error.
Re: [PATCH] drm/imx: fix out of bounds array access warning
Hi Arnd, On Tue, Mar 23, 2021 at 10:05 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > When CONFIG_OF is disabled, building with 'make W=1' produces warnings > about out of bounds array access: > > drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop': > drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below > array bounds of 'struct clk *[4]' [-Werror=array-bounds] What about making the driver depend on OF instead (like it is done in DRM_IMX_HDMI) ? --- a/drivers/gpu/drm/imx/Kconfig +++ b/drivers/gpu/drm/imx/Kconfig @@ -27,7 +27,7 @@ config DRM_IMX_TVE config DRM_IMX_LDB tristate "Support for LVDS displays" - depends on DRM_IMX && MFD_SYSCON + depends on DRM_IMX && MFD_SYSCON && OF depends on COMMON_CLK select DRM_PANEL help
Re: [PATCH v2 1/2] dt-bindings: arm: imx: add imx8mm gw7901 support
On Fri, Mar 19, 2021 at 5:50 PM Tim Harvey wrote: > > The Gateworks GW7901 is an ARM based single board computer (SBC) > featuring: > - i.MX8M Mini SoC > - LPDDR4 DRAM > - eMMC FLASH > - SPI FRAM > - Gateworks System Controller (GSC) > - Atmel ATECC Crypto Authentication > - USB 2.0 > - Microchip GbE Switch > - Multiple multi-protocol RS232/RS485/RS422 Serial ports > - onboard 802.11ac WiFi / BT > - microSD socket > - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets > - Wide range DC power input > - 802.3at PoE > > Acked-by: Rob Herring > Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam
Re: [PATCH v2 2/2] arm64: dts: imx: Add i.mx8mm Gateworks gw7901 dts support
Hi Tim, On Fri, Mar 19, 2021 at 5:50 PM Tim Harvey wrote: > > The Gateworks GW7901 is an ARM based single board computer (SBC) > featuring: > - i.MX8M Mini SoC > - LPDDR4 DRAM > - eMMC FLASH > - SPI FRAM > - Gateworks System Controller (GSC) > - Atmel ATECC Crypto Authentication > - USB 2.0 > - Microchip GbE Switch > - Multiple multi-protocol RS232/RS485/RS422 Serial ports > - onboard 802.11ac WiFi / BT > - microSD socket > - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets > - Wide range DC power input > - 802.3at PoE > > Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam
Re: [PATCH v5 3/3] ARM: imx7d-remarkable2.dts: Initial device tree for reMarkable2
Hi Alistair,
On Mon, Mar 15, 2021 at 11:27 PM Alistair Francis
wrote:
>
> The reMarkable2 (https://remarkable.com) is an e-ink tablet based on
> the imx7d SoC.
>
> This commit is based on the DTS provide by reMarkable but ported to the
> latest kernel (instead of 4.14). I have removed references to
> non-upstream devices and have changed the UART so that the console can
> be accessed without having to open up the device via the OTG pogo pins.
>
> Currently the kernel boots, but there is no support for the display.
>
> WiFi is untested (no dispaly or UART RX makes it hard to test), but
"display"
> + memory {
> + reg = <0x8000 0x4000>;
> + };
This should be:
memory@8000 {
device_type = "memory";
reg = <0x8000 0x4000>;
};
> +&crypto {
> + status = "disabled";
> +};
Why do you need to disable this node?
> +&dma_apbh {
> + status = "disabled";
> +};
Same here.
> +&sdma {
> + status = "okay";
> +};
No need to enable it in the board file.
> +&iomuxc_lpsr {
> + pinctrl_digitizer_reg: digitizerreggrp {
This is not referenced from anywhere.
Re: [PATCH V1] arm64: dts: imx8mp: fix FEC can't work when attached to generic phy driver
Hi Joakim, On Thu, Mar 18, 2021 at 8:04 AM Joakim Zhang wrote: > Hi Shawn, > > Seems you prefer to 2, is it possible to buildin Realtek > PHY(CONFIG_REALTEK_PHY=y)? If not, it is going to be tricky. Yes, we should select the driver as built-in and describe the reset timing requirements as per the datasheet. I have just sent two patches to address the issue you reported. Please test them.
Re: [PATCH v2] arm64: configs: Enable PCIe support for imx8mq boards
Hi Heiko, On Wed, Mar 17, 2021 at 8:52 AM Heiko Thiery wrote: > > Do we really want it to be built-in? If so, it would be nice to have some > > comments about that in commit log. > > Why would you not want it? I see other SOC PCI controllers are also > enabled. I would like to have it because we have an Intel e1000 on our > pitx-imx8m board and the seconds PCI slot is for a m.2 card. So we > would have the PCI support with the default defconfig. On the NXP > imx8mq EVK a m.2 is connected to the PCI interface. > > Is this the kind of comments you want? You have selected the driver to be built-in: CONFIG_PCI_IMX6=y Shawn's question is why it needs to be built-in instead of a kernel module: CONFIG_PCI_IMX6=m On arch/arm64/configs/defconfig the preference is to select the options as modules, whenever possible. If it can't be a module and needs to be built-in, then please provide a justification in the commit log. Hope this can clarify.
Re: [PATCH] sound: soc: fsl: Remove unnecessary THIS_MODULE
Hi Wang, On Sat, Mar 13, 2021 at 5:25 AM Wang Qing wrote: > > As THIS_MODULE has been set in module_platform_driver(), so remove it. > > Signed-off-by: Wang Qing Thanks for the patch, but someone else has already sent the same.
Re: [PATCH v2] ASoC: imx-hdmi: fix platform_no_drv_owner.cocci warnings
Hi Yang, On Thu, Mar 4, 2021 at 6:08 AM Yang Li wrote: > > ./sound/soc/fsl/imx-hdmi.c:226:3-8: No need to set .owner here. The core > will do it. > > Remove .owner field if calls are used which set it automatically > > Reported-by: Abaci Robot > Signed-off-by: Yang Li Reviewed-by: Fabio Estevam
Re: [PATCH] arm64: configs: Enable PCIe support for imx8mq boards
Hi Heiko, On Thu, Mar 11, 2021 at 1:13 PM Heiko Thiery wrote: > > > Enable PCI_IMX6 to get PCI support for imx8mq boards like imx8mq-evk, > > > imx8mq-kontron-pitx-imx8m and imx8mq-zii-ultra. This increases the image > > > by 64k. > > > > The growth of 64k is not right. Please resend this patch without mentioning the image growth size.
Re: [PATCH] ARM: dts: imx6ull: fix ubi filesystem mount failed
Hi Dillon,
On Tue, Mar 9, 2021 at 3:15 AM wrote:
>
> From: dillon min
>
> since Micron MT29F2G08ABAEAWP's ecc error management:
>
> |Description| Requirement
> |Minimum required ECC | 4-bit ECC per 528 bytes
> |Minimum ECC with internal ECC enabled | 4-bit ECC per 516 bytes (user data)
> +
> 8bytes (parity data)
>
> to avoid unnecessary overheads related to bigger ecc calculations.
> need choose to use fsl,use-minimum-ecc, else will run into ecc error.
>
> [9.449265] ubi0: scanning is finished
> [9.463968] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.486940] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.509906] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.532845] ubi0 error: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read 22528 bytes
>
> Fixes: f9ecf10cb88c ("ARM: dts: imx6ull: add MYiR MYS-6ULX SBC")
> Signed-off-by: dillon min
Reviewed-by: Fabio Estevam
Re: [PATCH 1/1] arm64: dts: imx8mm-nitrogen-r2: add espi2 support
Hi Adrien, On Mon, Mar 8, 2021 at 9:40 AM Adrien Grassein wrote: > > Add the description for espi support. Nit: In the subject and commit log, it should be ecspi2 instead of espi. With that fixed: Reviewed-by: Fabio Estevam
Re: [PATCH V2] arm64: dts: imx8mp: add wdog2/3 nodes
On Sun, Mar 7, 2021 at 7:42 AM wrote: > > From: Peng Fan > > There is wdog[2,3] in i.MX8MP, so add them. > > Signed-off-by: Peng Fan Reviewed-by: Fabio Estevam
Re: [PATCH] arm64: dts: imx8mp: add wdog2/3 nodes
Hi Peng, On Sat, Mar 6, 2021 at 8:41 AM wrote: > > From: Peng Fan > > There is wdog[2,3] in i.MX8MP, so add them, all wdogs share the > same clock root, so use the wdog1 clk here. The patch looks good, but I don't understand this sentence where you state that "all wdogs share the same clock root, so use the wdog1 clk here." wdog1 uses IMX8MP_CLK_WDOG1_ROOT wdog2 uses IMX8MP_CLK_WDOG2_ROOT wdog3 uses IMX8MP_CLK_WDOG3_ROOT Please clarify.
Re: [PATCH] ARM: dts: colibri-imx6ull: Change drive strength for usdhc2
Hi Philippe, On Thu, Mar 4, 2021 at 6:31 AM Philippe Schenker wrote: > > The current setting reflects about 86 Ohms of source-impedance > on the SDIO signals where the WiFi board is hooked up. PCB traces are > routed with 50 Ohms impedance and there are no serial resistors on > those traces. > > This commit changes the source-impedance to 52 Ohms to better match our > hardware design. > > The impedances given in this commit message refer to 3.3V operation. > > Signed-off-by: Philippe Schenker Reviewed-by: Fabio Estevam
Re: [PATCH v4 2/2] arm64: dts: fsl: add support for Kontron pitx-imx8m board
Hi Heiko, On Wed, Mar 3, 2021 at 6:11 PM Heiko Thiery wrote: > > The Kontron pitx-imx8m board is based on an i.MX8MQ soc. > > Signed-off-by: Heiko Thiery > Reviewed-by: Krzysztof Kozlowski > Reviewed-by: Michael Walle Reviewed-by: Fabio Estevam
Re: [PATCH] ASoC: hdmi-codec: fix platform_no_drv_owner.cocci warnings
Hi Yang, On Wed, Mar 3, 2021 at 5:54 AM Yang Li wrote: > > ./sound/soc/fsl/imx-hdmi.c:226:3-8: No need to set .owner here. The core > will do it. > > Remove .owner field if calls are used which set it automatically > > Reported-by: Abaci Robot > Signed-off-by: Yang Li The patch looks good, but please send a v2 with the correct Subject. It should mention imx-hdmi instead of hdmi-codec. Thanks
Re: [PATCH v2 2/2] arm64: dts: fsl: add support for Kontron pitx-imx8m board
Hi Heiko,
On Wed, Mar 3, 2021 at 9:54 AM Heiko Thiery wrote:
> > reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
>
> I used the same name as used on imx8mq-evk. Do you think a better name
> is the one you proposed?
Yes, the way I proposed is the preferred one. Thanks
Re: [PATCH v2 2/2] arm64: dts: fsl: add support for Kontron pitx-imx8m board
Hi Heiko,
On Mon, Feb 22, 2021 at 11:08 AM Heiko Thiery wrote:
> + reg_usdhc2_vmmc: regulator-v-3v3-sd {
reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
> + tpm_reset: tpm-reset {
> + compatible = "gpio-reset";
I don't see this compatible string documented.
> + reset-gpios = <&gpio3 2 GPIO_ACTIVE_LOW>;
> + reset-delay-us = <2>;
> + reset-post-delay-ms = <60>;
> + #reset-cells = <0>;
> + };
> +
> + usb_hub_reset: usb-hub-reset {
> + compatible = "gpio-reset";
Same here.
> +&fec1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_fec1>;
> + phy-mode = "rgmii-id";
> + phy-handle = <ðphy0>;
> + phy-reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
This property is deprecated. Please consider using reset-gpios inside
ethernet-phy instead.
> + /* TODO: configure audio, as of now just put a placeholder */
> + wm8904: audio-codec@1a {
> + compatible = "wlf,wm8904";
> + reg = <0x1a>;
> + clocks = <&clk IMX8MQ_CLK_SAI2_ROOT>;
> + clock-names = "mclk";
> + clock-frequency = <2400>;
Not a valid property.
> +/* M.2 B-key slot */
> +&pcie0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie0>;
> + disable-gpio = <&gpio5 29 GPIO_ACTIVE_LOW>;
Not a valid property.
> + reset-gpio = <&gpio1 9 GPIO_ACTIVE_LOW>;
> + clocks = <&clk IMX8MQ_CLK_PCIE1_ROOT>,
> +<&clk IMX8MQ_CLK_PCIE1_AUX>,
> +<&clk IMX8MQ_CLK_PCIE1_PHY>,
> +<&pcie0_refclk>;
> + clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> + ext_osc = <1>;
Not a valid property.
> +/* Intel Ethernet Controller I210/I211 */
> +&pcie1 {
> + clocks = <&clk IMX8MQ_CLK_PCIE2_ROOT>,
> +<&clk IMX8MQ_CLK_PCIE2_AUX>,
> +<&clk IMX8MQ_CLK_PCIE2_PHY>,
> +<&pcie1_refclk>;
> + clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> + ext_osc = <1>;
Not a valid property.
Re: [PATCH v2 3/7] ASoC: dt-bindings: fsl_rpmsg: Add binding doc for rpmsg cpu dai driver
On Thu, Feb 18, 2021 at 4:21 AM Shengjiu Wang wrote: > > rpmsg is a protocol. What's the h/w block? > > On Linux side this driver is a virtual driver, it is running > on Arm Cortex-A core. The h/w block is controlled by > another core (cortex-M core). so this driver actually > doesn't touch any hardware, it just does configuration > for rpmsg channel. > fsl,version: There are maybe different image running on M core, this > is the image version, different image has different function. To answer Rob's question: the hardware block that handles these messages is the Message Unit block.
Re: [PATCH AUTOSEL 5.11 05/67] can: flexcan: add CAN wakeup function for i.MX8QM
Hi Sasha, On Wed, Feb 24, 2021 at 10:35 PM Sasha Levin wrote: > > From: Joakim Zhang > > [ Upstream commit 812f0116c66a3ebaf0b6062226aa85574dd79f67 ] > > The System Controller Firmware (SCFW) is a low-level system function > which runs on a dedicated Cortex-M core to provide power, clock, and > resource management. It exists on some i.MX8 processors. e.g. i.MX8QM > (QM, QP), and i.MX8QX (QXP, DX). SCU driver manages the IPC interface > between host CPU and the SCU firmware running on M4. > > For i.MX8QM, stop mode request is controlled by System Controller Unit(SCU) > firmware, this patch introduces FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW quirk > for this function. > > Signed-off-by: Joakim Zhang > Link: https://lore.kernel.org/r/20201106105627.31061-6-qiangqing.zh...@nxp.com > Signed-off-by: Marc Kleine-Budde > Signed-off-by: Sasha Levin This is adding a new feature and not fixing a bug. Why does it qualify for stable inclusion?
Re: [PATCH] pinctrl: imx: imx8mm: fix pad offset of SD1_DATA0 pin
Hi Claudius,
On Thu, Feb 11, 2021 at 7:15 AM Claudius Heine wrote:
>
> Hi,
>
> can you please add:
>
> Fixes: c1c9d41319c3 ("dt-bindings: imx: Add pinctrl binding doc for imx8mm")
Yes, I was about to suggest the same. Thanks for the fix:
Reviewed-by: Fabio Estevam
Re: [PATCH v3] ARM: imx: avic: Convert to using IRQCHIP_DECLARE
Hi Saravana,
On Thu, Feb 4, 2021 at 10:39 PM Saravana Kannan wrote:
>
> Using IRQCHIP_DECLARE lets fw_devlink know that it should not wait for
> these interrupt controllers to be populated as struct devices. Without
> this change, fw_devlink=on will make the consumers of these interrupt
> controllers wait for the struct device to be added and thereby block the
> consumers' probes forever. Converting to IRQCHIP_DECLARE addresses boot
> issues on imx25 with fw_devlink=on that were reported by Martin.
>
> This also removes a lot of boilerplate code.
>
> Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
> Reported-by: Martin Kaiser
> Signed-off-by: Saravana Kannan
> Tested-by: Martin Kaiser
Thanks for the respin:
Reviewed-by: Fabio Estevam
Re: [PATCH v2] ARM: imx: avic: Convert to using IRQCHIP_DECLARE
Hi Saravana, On Thu, Feb 4, 2021 at 7:56 PM Saravana Kannan wrote: > > Remove a lot of boilerplate code. Also address boot issues on imx25 with > fw_devlink=on that were reported by Martin. The commit message could be improved. It starts like it was just a clean-up and then it says it fixes a boot issue on imx25. Please explain why converting IRQCHIP_DECLARE fixes the boot issue.
Re: [PATCH v3] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver,
On Tue, Feb 2, 2021 at 2:35 PM Oliver Graute wrote:
> +static const struct panel_desc sgd_gktw70sdad1sd = {
> + .timings = &sgd_gktw70sdad1sd_timing,
> + .num_timings = 1,
> + .bpc = 6,
> + .size = {
> + .width = 153,
> + .height = 86,
> + },
> + .delay = {
> + .prepare = 20 + 20 + 10 + 10,
Adding the datasheet label like Marco suggested make it clearer where
these numbers come from : /* T0 + T2 + T3 + T4 */
Glad you got it working on your imx6ul board:
Reviewed-by: Fabio Estevam
Re: [PATCH] spi: Fix the logic around the maximum speed
Hi Miquel,
On Wed, Feb 3, 2021 at 2:06 PM Miquel Raynal wrote:
>
> Commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max
> speed")
> rationaly introduced a new condition on which the device's maximum
> speed would be set to the controller's one: if the device advertizes a
> higher speed than the one supported by the controller.
Already fixed:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6820e812dafb4258bc14692f686eec5bde6fba86
Re: [PATCH] pinctrl: Support pin that does not support configuration option
Hi Michael, On Sat, Jan 30, 2021 at 5:21 AM Michael Trimarchi wrote: > > Some of the iMX25 pins have not an associated configuration register so > when they are configured the standard way through the device tree the > kernel complains with: > > imx25-pinctrl 43fac000.iomuxc: Pin(MX25_PAD_EXT_ARMCLK) does not support > config function Could you please share your device tree that causes this warning? Shouldn't you pass 0x8000 in the devicetree for this pad then? 0x8000 means that the kernel should not touch the PAD_CTL register and use the default configuration from the bootloader/POR.
Re: [PATCH v1] ARM: imx: avic: Convert to using IRQCHIP_DECLARE
Hi Saravana,
On Sun, Jan 31, 2021 at 5:56 PM Saravana Kannan wrote:
> +static int __init imx_avic_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + void __iomem *avic_base;
> +
> + avic_base = of_iomap(node, 0);
> + BUG_ON(!avic_base);
> + mxc_init_irq(avic_base);
> + return 0;
> +}
> +
> +IRQCHIP_DECLARE(imx_avic, "fsl,imx31-avic", imx_avic_init);
Shouldn't the compatible be "fsl,avic" instead?
Re: [PATCH] ARM: dts: imx6qdl-wandboard: add scl/sda gpios definitions for i2c bus recovery
On Sun, Jan 31, 2021 at 12:55 PM Dima Azarkin wrote: > > The i2c bus on imx6qdl-wandboard has intermittent issues where SDA can freeze > on low level at the end of transaction so the bus can no longer work. This > impacts reading of EDID data leading to incorrect TV resolution and no audio. > > This scenario is improved by adding scl/sda gpios definitions to implement the > i2c bus recovery mechanism. > > Signed-off-by: Dima Azarkin Reviewed-by: Fabio Estevam
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Mon, Jan 25, 2021 at 7:17 PM Oliver Graute wrote: > I would prefer mine, because I got a wrong colored penguin on bootup > with yours :-) I have originally passed .bpc = 8, but looking at the panel datasheet, this should be: .bpc = 6 instead. In your patch, you pass the timing parameters three times, but they are all the same. Usually, it is meant to be: minimal, typical, maximum values.
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Mon, Jan 25, 2021 at 6:29 PM Oliver Graute wrote: > Ok I fixed the pin conflict with regulator-gpio and added a 5V > regulator node in my dts file. Now the display is working fine! That's good news :-) > I'll post the dts files soon and check if there is something to > improve for this patch. Did the panel patch I sent earlier work? https://pastebin.com/raw/diTMVsh8 If it does, I can send it formally if you want.
Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
Hi Haibo,
Could you please take a look?
Thanks
On Thu, Jan 21, 2021 at 10:26 AM Ulf Hansson wrote:
>
> + Fabio, Haibo
>
> On Thu, 21 Jan 2021 at 10:54, Wang, Xiaolei
> wrote:
> >
> > Hi
> >
> > >Are you sure this is an eMMC problem and not a mmc host driver issue?
> >
> > >Can you elaborate more what happens?
> >
> > When I use the mkfs.f2fs tool to format the eMMC file system on the imx8qxp
> > board,
> > because mkfs.f2fs will use secdiscard first, when entering
> > mmc_blk_issue_secdiscard_rq erase,
> > once the parameters are passed into MMC_SECURE_TRIM1_ARG, this function
> > will take a long time to return .
> > The program has not ended, has been in TASK_UNINTERRUPTIBLE state.
> >
> > I compared the mkfs.ext4 tool to format the file system. Because it
> > directly uses mmc_blk_issue_discard_rq,
> > this is a normal formatting phenomenon.
> >
> > mmc_blk_issue_secdiscard_rq and mmc_blk_issue_discard_rq are just different
> > commands and parameters sent by the host as a bus.
> > I did not see the description of trim in the data sheet. Could the host
> > driver cause this problem?
>
> Yes, it can - and we have had issues like these before. So before
> adding a card quirk, I think we need to make sure this isn't the case.
>
> When using MMC_SECURE_TRIM1_ARG, it's very likely that the request
> takes longer to complete.
>
> The mmc host is responsible for either dealing with busy detection
> with the help of its HW/controller - or if that can't be supported,
> the mmc core falls back to polling the card for busy with a CMD13.
>
> See mmc_do_erase() in /drivers/mmc/core/core.c
>
> >
> > Note:
> > The host driver I use is sdhci-esdhc-imx.c
>
> Alright, I have looped in Fabio and Haibo that knows this driver,
> let's see if they can help.
>
> >
> > Thanks
> > Xiaolei
>
> Kind regards
> Uffe
>
> >
> > -Original Message-
> > From: Ulf Hansson
> > Sent: Wednesday, January 20, 2021 9:41 PM
> > To: Wang, Xiaolei
> > Cc: Pali Rohár ; Lee Jones ;
> > linux-...@vger.kernel.org; Linux Kernel Mailing List
> >
> > Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> >
> > [Please note this e-mail is from an EXTERNAL e-mail address]
> >
> > On Mon, 18 Jan 2021 at 05:27, Xiaolei Wang
> > wrote:
> > >
> > > R1J57L mmc chip hw capibility indicates that it supports trim
> > > function, but this function does not work properly, the SDIO bus does
> > > not respond, and the IO has been waiting so set quirks to skip trim
> >
> > Are you sure this is an eMMC problem and not a mmc host driver issue?
> >
> > Can you elaborate more what happens?
> >
> > Kind regards
> > Uffe
> >
> > >
> > > Signed-off-by: Xiaolei Wang
> > > ---
> > > drivers/mmc/core/quirks.h | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
> > > index d68e6e513a4f..63e02391c133 100644
> > > --- a/drivers/mmc/core/quirks.h
> > > +++ b/drivers/mmc/core/quirks.h
> > > @@ -89,6 +89,8 @@ static const struct mmc_fixup __maybe_unused
> > > mmc_blk_fixups[] = {
> > > MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY,
> > > add_quirk_mmc,
> > > MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > + MMC_FIXUP("R1J57L", CID_MANFID_MICRON, CID_OEMID_ANY,
> > > add_quirk_mmc,
> > > + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > >
> > > /*
> > > * On Some Kingston eMMCs, performing trim can result in @@
> > > -98,6 +100,8 @@ static const struct mmc_fixup __maybe_unused
> > > mmc_blk_fixups[] = {
> > > MMC_QUIRK_TRIM_BROKEN),
> > > MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY,
> > > add_quirk_mmc,
> > > MMC_QUIRK_TRIM_BROKEN),
> > > + MMC_FIXUP("R1J57L", CID_MANFID_MICRON, CID_OEMID_ANY,
> > > add_quirk_mmc,
> > > + MMC_QUIRK_TRIM_BROKEN),
> > >
> > > END_FIXUP
> > > };
> > > --
> > > 2.25.1
> > >
Re: [PATCH v2 6/7] ARM: dts: imx6dl-prtvt7: fix PWM cell count for the backlight node.
Hi Oleksij, On Thu, Jan 21, 2021 at 3:12 AM Oleksij Rempel wrote: > > At some point PWM cell count was changed, but it didn't triggered any It changed in this commit: commit fa28d8212ede9c533ae87a737571a9d3b3eebb29 Author: Uwe Kleine-König Date: Fri Jul 10 07:19:37 2020 +0200 ARM: dts: imx: default to #pwm-cells = <3> in the SoC dtsi files The imx-pwm driver supports 3 cells and this is the more flexible setting. So use it by default and overwrite it back to two for the files that reference the PWMs with just 2 cells to minimize changes. This allows to drop explicit setting to 3 cells for the boards that already depend on this. The boards that are now using 2 cells explicitly can be converted to 3 individually. Signed-off-by: Uwe Kleine-König Signed-off-by: Shawn Guo
Re: [PATCH v2] clk: imx6q: demote warning about pre-boot ldb_di_clk reparenting
Hi Ahmad,
On Mon, Jan 18, 2021 at 8:30 AM Ahmad Fatoum wrote:
>
> Since 5d283b083800 ("clk: imx6: Fix procedure to switch the parent
> of LDB_DI_CLK"), the clock driver warns if ldb_di\d_sel is changed
> from reset value on system boot. This warning is printed even if
> the bootloader (or a previous kernel that did kexec) followed the
> correct procedure for glitch-free reparenting.
>
> As such systems are doing everything correctly, a warning is too
> harsh. Demote to a notice, so users are still alerted, but without
> cluttering a loglevel=5 boot.
>
> While at it, add the words "possible glitch" into the log message, to
> make it more user-friendly.
>
> Signed-off-by: Ahmad Fatoum
Reviewed-by: Fabio Estevam
Re: [PATCH] spi: imx: Don't print error on -EPROBEDEFER
On Mon, Jan 18, 2021 at 1:31 PM Guido Günther wrote:
>
> This avoids
>
> [0.962538] spi_imx 3082.spi: bitbang start failed with -517
>
> durig driver probe.
>
> Fixes: 8197f489f4c4 ("spi: imx: Fix failure path leak on GPIO request error
> correctly")
> Signed-off-by: Guido Günther
Reviewed-by: Fabio Estevam
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
On Sat, Jan 16, 2021 at 9:49 AM Oliver Graute wrote: > > power-supply = <®_touch_3v3> is not correct, as the reg_touch_3v3 > > does not power the LCD. > > yes, but how is the LCD correctly powered then? J4 is powered by VCC_5V and VCC_3V#. > [7.795980] pwm-backlight backlight: supply power not found, using dummy > regulator > [7.804436] OF: /backlight: #pwm-cells = 3 found -1 > [7.806563] of_pwm_get(): can't parse "pwms" property > [7.812026] pwm-backlight backlight: unable to request PWM > [7.822929] pwm-backlight: probe of backlight failed with error -22 You need to fix this. > [7.876831] imx-sdma 20ec000.sdma: Direct firmware load for > imx/sdma/sdma-imx6q.bin failed with error -2 > [7.884231] imx-sdma 20ec000.sdma: Falling back to sysfs fallback for: > imx/sdma/sdma-imx6q.bin > [7.916013] printk: console [ttymxc0] enabled > [7.916013] printk: console [ttymxc0] enabled > [7.922351] printk: bootconsole [ec_imx6q0] disabled > [7.922351] printk: bootconsole [ec_imx6q0] disabled > [7.952397] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 68, base_baud > = 500) is a IMX > [7.970794] 21ec000.serial: ttymxc2 at MMIO 0x21ec000 (irq = 69, base_baud > = 500) is a IMX > [8.033015] [ cut here ] > [8.037826] WARNING: CPU: 0 PID: 1 at > ../drivers/gpu/drm/panel/panel-simple.c:577 panel_simple_probe+0x5dc/0x6b8 And this too > [8.846104] imx6ul-pinctrl 20e.pinctrl: pin MX6UL_PAD_NAND_CE0_B > already requested by regulator-gpio; cannot claim for 1806000.nand-controller > [8.859641] imx6ul-pinctrl 20e.pinctrl: pin-107 > (1806000.nand-controller) status -22 > [8.867851] imx6ul-pinctrl 20e.pinctrl: could not request pin 107 > (MX6UL_PAD_NAND_CE0_B) from group gpminandgrp on device 20e.pinctrl > [8.880930] gpmi-nand 1806000.nand-controller: Error applying setting, > reverse things back > [8.889726] gpmi-nand: probe of 1806000.nand-controller failed with error > -22 And this pin conflict too.
Re: [PATCH] drm/bridge: nwl-dsi: Avoid potential multiplication overflow on 32-bit
Hi Geert, On Mon, Jan 11, 2021 at 10:02 AM Geert Uytterhoeven wrote: > > As nwl_dsi.lanes is u32, and NSEC_PER_SEC is 10L, the second > multiplication in > > dsi->lanes * 8 * NSEC_PER_SEC > > will overflow on a 32-bit platform. Fix this by making the constant > unsigned long long, forcing 64-bit arithmetic. > > While iMX8 is arm64, this driver is currently used on 64-bit platforms > only, where long is 64-bit, so this cannot happen. But the issue may > start to happen when the driver is reused for a 32-bit SoC, or when code > is copied for a new driver. This IP is also present on i.MX7ULP, which is 32-bit, but not supported yet. Thanks for taking care of this. Reviewed-by: Fabio Estevam
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
On Sun, Jan 10, 2021 at 5:09 PM Oliver Graute wrote: > here the schematics and my dts. The board is using a LVDS connector for > the display. The schematics shows the GKTW70SDAD1SD panel in the J4 connector, not the LVDS J7 connector. > https://www.variscite.de/wp-content/uploads/2017/12/VAR-6ULCustomboard-Schematics.pdf > https://lore.kernel.org/linux-arm-kernel/1610144511-19018-3-git-send-email-oliver.gra...@gmail.com/ As I mentioned earlier you should remove the display timings from the dts when using the compatible string for the panel. power-supply = <®_touch_3v3> is not correct, as the reg_touch_3v3 does not power the LCD. Another hint is to use the PLL5_VIDEO as the clock source for the lcdif controller as done in the imx6ul evk dtsi. It would also help if you could share the complete boot log.
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Sun, Jan 10, 2021 at 12:35 PM Oliver Graute wrote: > the first two errors are gone. But I still get this: > > [ 42.387107] mxsfb 21c8000.lcdif: Cannot connect bridge: -517 > > The panel is still off perhaps I miss something else. Some suggestions: - Take a look at arch/arm/boot/dts/imx6ul-14x14-evk.dtsi as a reference as it has display functional - Use imx_v6_v7_defconfig to make sure all the required drivers are selected - If it still does not work, share the dts and schematics
Re: [PATCH v3 3/3] dt-bindings: arm: fsl: Add Variscite i.MX6UL compatibles
On Fri, Jan 8, 2021 at 7:23 PM Oliver Graute wrote: > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml > b/Documentation/devicetree/bindings/arm/fsl.yaml > index 05906e2..5f74d78 100644 > --- a/Documentation/devicetree/bindings/arm/fsl.yaml > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > @@ -240,6 +240,7 @@ properties: >- technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL > Pico-Dwarf >- technexion,imx6ul-pico-hobbit # TechNexion i.MX6UL > Pico-Hobbit >- technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi > + - variscite,imx6ul-var-6ulcustomboard # i.MX UltraLite > Carrier-board You missed to add a "6" in the description: i.MX6 UltraLite Carrier-board
Re: [PATCH v8 2/3] ARM: dts: Add support for i.MX6 UltraLite DART Variscite Customboard
On Fri, Jan 8, 2021 at 7:23 PM Oliver Graute wrote:
> + panel1: panel-lcd {
> + compatible = "sgd,gktw70sdad1sd";
> +
> + backlight = <&backlight_lcd>;
> + power-supply = <®_touch_3v3>;
> + label = "gktw70sdad1sd";
> +
> + display-timing {
If you pass the compatible, then you don't need to add the
display-timing in the device tree.
Re: [PATCH v8 1/3] ARM: dts: imx6ul: Add Variscite DART-6UL SoM support
Hi Oliver,
On Fri, Jan 8, 2021 at 7:22 PM Oliver Graute wrote:
> +&fec1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet1>;
> + phy-mode = "rmii";
> + phy-handle = <ðphy0>;
> + phy-reset-gpios=<&gpio5 10 1>;
> + phy-reset-duration=<100>;
These properties are obsolete. Please describe the Ethernet PHY reset
inside the ethernet-phy nodes as per:
Documentation/devicetree/bindings/net/ethernet-phy.yaml
> + phy-reset-on-resume;
This property does not exist.
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Fri, Jan 8, 2021 at 7:24 PM Oliver Graute wrote: > > On 19/12/20, Oliver Graute wrote: > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD > > to panel-simple. > > > > The panel spec from Variscite can be found at: > > https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf > > some clue what bus_format and bus_flags I have to use? > > [ 42.505156] panel-simple panel-lcd: Specify missing bus_flags > [ 42.511090] panel-simple panel-lcd: Specify missing bus_format > [ 42.615131] mxsfb 21c8000.lcdif: Cannot connect bridge: -517 Does this patch work? https://pastebin.com/raw/diTMVsh8
Re: [PATCH 3/4] ARM: imx6q: Fix missing need_resched() check after rcu_idle_enter()
Hi Frederic, On Mon, Jan 4, 2021 at 12:21 PM Frederic Weisbecker wrote: > > Entering RCU idle mode may cause a deferred wake up of an RCU NOCB_GP > kthread (rcuog) to be serviced. > > Usually a wake up happening while running the idle task is spotted in > one of the need_resched() checks carefully placed within the idle loop > that can break to the scheduler. > > Unfortunately imx6q_enter_wait() is beyond the last generic > need_resched() check and it performs a wfi right away after the call to > rcu_idle_enter(). We may halt the CPU with a resched request unhandled, > leaving the task hanging. > > Fix this with performing a last minute need_resched() check after > calling rcu_idle_enter(). Shouldn't tif_need_resched() be used instead of need_resched() in the commit log?
Re: [PATCH v2] spi: fix the divide by 0 error when calculating xfer waiting time
On Sat, Jan 2, 2021 at 12:07 AM Xu Yilun wrote: > > The xfer waiting time is the result of xfer->len / xfer->speed_hz. This > patch makes the assumption of 1khz xfer speed if the xfer->speed_hz is You missed to update the commit log to 100kHz.
Re: [PATCH] Revert "clk: imx: fix composite peripheral flags"
Hi Martin,
On Thu, Dec 31, 2020 at 11:22 AM Martin Kepplinger
wrote:
>
> This reverts commit 936c383673b9e3007432f17140ac62de53d87db9.
>
> It breaks clock reparenting via devfreq on the imx8mq used in the
> Librem 5 phone. When switching dram frequency (which worked before)
> the system now hangs after this where the dram_apb clock cannot be
> set:
>
> [ 129.391755] imx8m-ddrc-devfreq 3d40.memory-controller: failed to
> set dram_apb parent: -16
> [ 129.391959] imx8m-ddrc-devfreq 3d40.memory-controller: ddrc
> failed freq switch to 2500 from 8: error -16. now at 2500
> [ 129.406133] imx8m-ddrc-devfreq 3d40.memory-controller: failed to
> update frequency from PM QoS (-16)
I am wondering whether IMX8MQ_CLK_DRAM_ALT should also be marked as
CLK_IS_CRITICAL.
Could you please try the following change without the revert?
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -458,7 +458,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
* Mark with GET_RATE_NOCACHE to always read div value from hardware
*/
hws[IMX8MQ_CLK_DRAM_CORE] =
imx_clk_hw_mux2_flags("dram_core_clk", base + 0x9800, 24, 1,
imx8mq_dram_core_sels, ARRAY_SIZE(imx8mq_dram_core_sels),
CLK_IS_CRITICAL);
- hws[IMX8MQ_CLK_DRAM_ALT] =
__imx8m_clk_hw_composite("dram_alt", imx8mq_dram_alt_sels, base +
0xa000, CLK_GET_RATE_NOCACHE);
+ hws[IMX8MQ_CLK_DRAM_ALT] =
__imx8m_clk_hw_composite("dram_alt", imx8mq_dram_alt_sels, base +
0xa000, CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);
hws[IMX8MQ_CLK_DRAM_APB] =
__imx8m_clk_hw_composite("dram_apb", imx8mq_dram_apb_sels, base +
0xa080, CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);
Thanks
Re: [PATCH 3/3] ARM: dts: imx28: Add DTS description of imx28 based XEA board
Hi Lukasz,
On Wed, Nov 25, 2020 at 1:19 PM Lukasz Majewski wrote:
> diff --git a/arch/arm/boot/dts/imx28-lwe.dtsi
> b/arch/arm/boot/dts/imx28-lwe.dtsi
> new file mode 100644
> index ..cb2eb4377d9c
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx28-lwe.dtsi
> @@ -0,0 +1,185 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/*
> + * Copyright 2020
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + */
> +
> +/dts-v1/;
> +#include "imx28.dtsi"
> +
> +/ {
> + compatible = "fsl,imx28";
You can drop this one.
> +
> + aliases {
> + spi2 = &ssp3;
> + };
> +
> + chosen {
> + bootargs = "root=/dev/mmcblk0p2 rootfstype=ext4 ro rootwait
> console=ttyAMA0,115200 panic=1";
You could remove bootargs and let the bootloader pass it.
We usually don't pass bootargs in the i.MX dts files.
> + };
> +
> + memory {
memory@4000
otherwise you will get dtc build warnings with W=1.
> + reg = <0x4000 0x0800>;
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
No need for this 'regulators' container.
> +
> + reg_3v3: regulator@0 {
reg_3v3: regulator-reg-3v3 {
> + compatible = "regulator-fixed";
> + reg = <0>;
Remove the reg = <0>
Same applies to other regulators.
> + reg_usb_5v: regulator@1 {
> + compatible = "regulator-fixed";
> + reg = <1>;
> + regulator-name = "usb_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + enable-active-high;
Why passing 'enable-active-high' when this is not gpio controlled?
> + };
> +
> + reg_fec_3v3: regulator@2 {
> + compatible = "regulator-fixed";
> + reg = <2>;
> + regulator-name = "fec-phy";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + enable-active-high;
Same here.
> +&ssp3 {
> + compatible = "fsl,imx28-spi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi3_pins_a>;
> + status = "okay";
> +
> + flash0: s25fl256s0@0 {
Node names should be generic
flash@0
> +
> +/dts-v1/;
> +#include "imx28-lwe.dtsi"
> +
> +/ {
> + model = "XEA";
compatible = "xea,imx20-lwe", "fsl,imx28";
You should add xea to the vendor prefix in a separate patch.
You also need to add thie board to
Documentation/devicetree/bindings/arm/fsl.yaml
Re: [PATCH v2] ARM: dts: imx28: add pinmux for USB1 overcurrent on pwm2
On Wed, Dec 9, 2020 at 7:10 PM Lukasz Majewski wrote: > > From: Mans Rullgard > > Add pinmux setting for USB1 overcurrent on pwm2 pad. > > Signed-off-by: Mans Rullgard > Signed-off-by: Lukasz Majewski Reviewed-by: Fabio Estevam
Re: [PATCH -next] i2c: busses: use DIV_ROUND_UP macro to do calculation
Hi Zheng, On Tue, Dec 22, 2020 at 10:31 AM Zheng Yongjun wrote: > > Don't open-code DIV_ROUND_UP() kernel macro. > > Signed-off-by: Zheng Yongjun Reviewed-by: Fabio Estevam
Re: [PATCH v9 4/4] soc: imx8m: change to use platform driver
Hi Alice,
On Tue, Dec 22, 2020 at 5:11 AM Alice Guo (OSS) wrote:
> - soc_uid = readl_relaxed(ocotp_base + OCOTP_UID_HIGH);
> - soc_uid <<= 32;
> - soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW);
> + if (dev) {
> + int ret = 0;
No need to initialize ret to 0.
> - imx8mm_soc_uid();
> + if (dev) {
> + int ret = 0;
Ditto.
> +/* Retain device_initcall is for backward compatibility with DTS. */
> +static int __init imx8_soc_init(void)
> +{
> + int ret = 0;
Ditto.
> +
> + if (of_find_matching_node_and_match(NULL, imx8_soc_match, NULL))
> + return 0;
> +
> + ret = imx8_soc_info(NULL);
> + return ret;
Or you could even get rid of 'ret' and return imx8_soc_info() directly.
Re: [PATCH] i2c-imx.c: Synthesize end of transaction events without idle interrupts
Hi Kevin, On Fri, Dec 18, 2020 at 2:53 PM Kevin Herbert wrote: > > From feaf638fb9b9a483c0d6090b277f34db21160885 Mon Sep 17 00:00:00 2001 > From: Kevin Paul Herbert > Date: Tue, 15 Dec 2020 16:50:34 -0800 > Subject: [PATCH] i2c-imx.c: Synthesize end of transaction events without idle > interrupts Your patch is corrupted. Please use 'git send-mail' and submit it again. Thanks
Re: [PATCH 1/1] ARM: dts: opos6ul: add ksz8081 phy properties
On Thu, Dec 17, 2020 at 7:49 AM Sébastien Szymanski wrote: > > Set clock mode and the LED mode in the device tree instead of relying on > the fixup in mach-imx6ul. > > Signed-off-by: Sébastien Szymanski Reviewed-by: Fabio Estevam
Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
Hi Shengjiu,
On Wed, Dec 16, 2020 at 7:52 AM Shengjiu Wang wrote:
>
> From: shengjiu wang
>
> When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in))
> is true, then goto fail, the uninitialized variable ret will be
> returned.
>
> Signed-off-by: shengjiu wang
> Reported-by: kernel test robot
Thanks for the fix.
This should have:
Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver")
Reviewed-by: Fabio Estevam
Re: [PATCH v3 0/2] Add support of nxp pf8x00 regulator
Hi Adrien, On Tue, Dec 15, 2020 at 10:16 AM Adrien Grassein wrote: > Could you please tell me where this driver was merged? > I checked the main kernel Linux and I can find out this one. It is in the linux-next tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers?h=next-20201215&id=d3795d6321ecaa55d94dc24c3b1e3cce608aabd6 Regards, Fabio Estevam
[PATCH] regulator: pfuze100: Convert the driver to DT-only
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code
by removing the unused non-DT support.
Signed-off-by: Fabio Estevam
---
drivers/regulator/Kconfig | 2 +-
drivers/regulator/pfuze100-regulator.c | 34 +-
include/linux/regulator/pfuze100.h | 6 -
3 files changed, 2 insertions(+), 40 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index cffadf8b2c37..53fa84f4d1e1 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -830,7 +830,7 @@ config REGULATOR_PF8X00
config REGULATOR_PFUZE100
tristate "Freescale PFUZE100/200/3000/3001 regulator driver"
- depends on I2C
+ depends on I2C && OF
select REGMAP_I2C
help
Say y here to support the regulators found on the Freescale
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
index 01a12cfcea7c..d60d7d1b7fa2 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -105,15 +105,6 @@ static const int pfuze3000_sw2hi[] = {
250, 280, 285, 300, 310, 315, 320, 330,
};
-static const struct i2c_device_id pfuze_device_id[] = {
- {.name = "pfuze100", .driver_data = PFUZE100},
- {.name = "pfuze200", .driver_data = PFUZE200},
- {.name = "pfuze3000", .driver_data = PFUZE3000},
- {.name = "pfuze3001", .driver_data = PFUZE3001},
- { }
-};
-MODULE_DEVICE_TABLE(i2c, pfuze_device_id);
-
static const struct of_device_id pfuze_dt_ids[] = {
{ .compatible = "fsl,pfuze100", .data = (void *)PFUZE100},
{ .compatible = "fsl,pfuze200", .data = (void *)PFUZE200},
@@ -440,7 +431,6 @@ static struct pfuze_regulator pfuze3001_regulators[] = {
PFUZE100_VGEN_REG(PFUZE3001, VLDO4, PFUZE100_VGEN6VOL, 180,
330, 10),
};
-#ifdef CONFIG_OF
/* PFUZE100 */
static struct of_regulator_match pfuze100_matches[] = {
{ .name = "sw1ab", },
@@ -578,22 +568,6 @@ static inline struct device_node *match_of_node(int index)
{
return pfuze_matches[index].of_node;
}
-#else
-static int pfuze_parse_regulators_dt(struct pfuze_chip *chip)
-{
- return 0;
-}
-
-static inline struct regulator_init_data *match_init_data(int index)
-{
- return NULL;
-}
-
-static inline struct device_node *match_of_node(int index)
-{
- return NULL;
-}
-#endif
static struct pfuze_chip *syspm_pfuze_chip;
@@ -708,8 +682,6 @@ static int pfuze100_regulator_probe(struct i2c_client
*client,
const struct i2c_device_id *id)
{
struct pfuze_chip *pfuze_chip;
- struct pfuze_regulator_platform_data *pdata =
- dev_get_platdata(&client->dev);
struct regulator_config config = { };
int i, ret;
const struct of_device_id *match;
@@ -802,10 +774,7 @@ static int pfuze100_regulator_probe(struct i2c_client
*client,
desc = &pfuze_chip->regulator_descs[i].desc;
- if (pdata)
- init_data = pdata->init_data[i];
- else
- init_data = match_init_data(i);
+ init_data = match_init_data(i);
/* SW2~SW4 high bit check and modify the voltage value table */
if (i >= sw_check_start && i <= sw_check_end) {
@@ -879,7 +848,6 @@ static int pfuze100_regulator_remove(struct i2c_client
*client)
}
static struct i2c_driver pfuze_driver = {
- .id_table = pfuze_device_id,
.driver = {
.name = "pfuze100-regulator",
.of_match_table = pfuze_dt_ids,
diff --git a/include/linux/regulator/pfuze100.h
b/include/linux/regulator/pfuze100.h
index d47e668d9ca8..c964fe8ab698 100644
--- a/include/linux/regulator/pfuze100.h
+++ b/include/linux/regulator/pfuze100.h
@@ -63,10 +63,4 @@
#define PFUZE3001_VLDO38
#define PFUZE3001_VLDO49
-struct regulator_init_data;
-
-struct pfuze_regulator_platform_data {
- struct regulator_init_data *init_data[PFUZE100_MAX_REGULATOR];
-};
-
#endif /* __LINUX_REG_PFUZE100_H */
--
2.17.1
Re: [PATCH v1] ARM: imx: mach-imx6ul: remove 14x14 EVK specific PHY fixup
On Wed, Dec 9, 2020 at 9:21 AM Oleksij Rempel wrote:
>
> Remove board specific PHY fixup introduced by commit:
>
> | 709bc0657fe6f9f5 ("ARM: imx6ul: add fec MAC refrence clock and phy fixup
> init")
>
> This fixup addresses boards with a specific configuration: a KSZ8081RNA
> PHY with attached clock source to XI (Pin 8) of the PHY equal to 50MHz.
>
> For the KSZ8081RND PHY, the meaning of the reg 0x1F bit 7 is different
> (compared to the KSZ8081RNA). A set bit means:
>
> - KSZ8081RNA: clock input to XI (Pin 8) is 50MHz for RMII
> - KSZ8081RND: clock input to XI (Pin 8) is 25MHz for RMII
>
> In other configurations, for example a KSZ8081RND PHY or a KSZ8081RNA
> with 25Mhz clock source, the PHY will glitch and stay in not recoverable
> state.
>
> It is not possible to detect the clock source frequency of the PHY. And
> it is not possible to automatically detect KSZ8081 PHY variant - both
> have same PHY ID. It is not possible to overwrite the fixup
> configuration by providing proper device tree description. The only way
> is to remove this fixup.
>
> If this patch breaks network functionality on your board, fix it by
> adding PHY node with following properties:
>
> ethernet-phy@x {
> ...
> micrel,led-mode = <1>;
> clocks = <&clks IMX6UL_CLK_ENET_REF>;
> clock-names = "rmii-ref";
> ...
> };
>
> The board which was referred in the initial patch is already fixed.
> See: arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
>
> Signed-off-by: Oleksij Rempel
Reviewed-by: Fabio Estevam
Re: [PATCH 08/10] arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini C.TOUCH 2.0
On Wed, Dec 2, 2020 at 2:45 PM Krzysztof Kozlowski wrote: > You have multiple DTSI files to only include one DTSI. I was trying to > follow the logic here but I failed... Agreed. It is hard to understand the purpose of so many dts files in this patch series. Regards, Fabio Estevam
[PATCH v4] media: coda: Convert the driver to DT-only
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code
by removing the unused non-DT support.
Signed-off-by: Fabio Estevam
---
Changes since v3:
- Add a explicit OF dependency - Andy
drivers/media/platform/Kconfig| 2 +-
drivers/media/platform/coda/coda-common.c | 27 ++-
include/linux/platform_data/media/coda.h | 14
3 files changed, 3 insertions(+), 40 deletions(-)
delete mode 100644 include/linux/platform_data/media/coda.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ef2267f4..9fdbfea06087 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -201,7 +201,7 @@ if V4L_MEM2MEM_DRIVERS
config VIDEO_CODA
tristate "Chips&Media Coda multi-standard codec IP"
- depends on VIDEO_DEV && VIDEO_V4L2 && (ARCH_MXC || COMPILE_TEST)
+ depends on VIDEO_DEV && VIDEO_V4L2 && OF && (ARCH_MXC || COMPILE_TEST)
select SRAM
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index d30eafea701d..995e95272e51 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
@@ -3102,13 +3101,6 @@ static const struct coda_devtype coda_devdata[] = {
},
};
-static const struct platform_device_id coda_platform_ids[] = {
- { .name = "coda-imx27", .driver_data = CODA_IMX27 },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(platform, coda_platform_ids);
-
-#ifdef CONFIG_OF
static const struct of_device_id coda_dt_ids[] = {
{ .compatible = "fsl,imx27-vpu", .data = &coda_devdata[CODA_IMX27] },
{ .compatible = "fsl,imx51-vpu", .data = &coda_devdata[CODA_IMX51] },
@@ -3118,14 +3110,9 @@ static const struct of_device_id coda_dt_ids[] = {
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, coda_dt_ids);
-#endif
static int coda_probe(struct platform_device *pdev)
{
- const struct of_device_id *of_id =
- of_match_device(of_match_ptr(coda_dt_ids), &pdev->dev);
- const struct platform_device_id *pdev_id;
- struct coda_platform_data *pdata = pdev->dev.platform_data;
struct device_node *np = pdev->dev.of_node;
struct gen_pool *pool;
struct coda_dev *dev;
@@ -3135,14 +3122,7 @@ static int coda_probe(struct platform_device *pdev)
if (!dev)
return -ENOMEM;
- pdev_id = of_id ? of_id->data : platform_get_device_id(pdev);
-
- if (of_id)
- dev->devtype = of_id->data;
- else if (pdev_id)
- dev->devtype = &coda_devdata[pdev_id->driver_data];
- else
- return -EINVAL;
+ dev->devtype = of_device_get_match_data(&pdev->dev);
dev->dev = &pdev->dev;
dev->clk_per = devm_clk_get(&pdev->dev, "per");
@@ -3200,10 +3180,8 @@ static int coda_probe(struct platform_device *pdev)
return ret;
}
- /* Get IRAM pool from device tree or platform data */
+ /* Get IRAM pool from device tree */
pool = of_gen_pool_get(np, "iram", 0);
- if (!pool && pdata)
- pool = gen_pool_get(pdata->iram_dev, NULL);
if (!pool) {
dev_err(&pdev->dev, "iram pool not available\n");
return -ENOMEM;
@@ -3342,7 +3320,6 @@ static struct platform_driver coda_driver = {
.of_match_table = of_match_ptr(coda_dt_ids),
.pm = &coda_pm_ops,
},
- .id_table = coda_platform_ids,
};
module_platform_driver(coda_driver);
diff --git a/include/linux/platform_data/media/coda.h
b/include/linux/platform_data/media/coda.h
deleted file mode 100644
index 293b61b60c9d..
--- a/include/linux/platform_data/media/coda.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (C) 2013 Philipp Zabel, Pengutronix
- */
-#ifndef PLATFORM_CODA_H
-#define PLATFORM_CODA_H
-
-struct device;
-
-struct coda_platform_data {
- struct device *iram_dev;
-};
-
-#endif
--
2.17.1
[PATCH v3] media: coda: Convert the driver to DT-only
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code
by removing the unused non-DT support.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Forgot to Cc linux-media list.
Changes since v1:
- Drop include/linux/platform_data/media/coda.h and pdata - Hans
drivers/media/platform/coda/coda-common.c | 27 ++-
include/linux/platform_data/media/coda.h | 14
2 files changed, 2 insertions(+), 39 deletions(-)
delete mode 100644 include/linux/platform_data/media/coda.h
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index d30eafea701d..995e95272e51 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
@@ -3102,13 +3101,6 @@ static const struct coda_devtype coda_devdata[] = {
},
};
-static const struct platform_device_id coda_platform_ids[] = {
- { .name = "coda-imx27", .driver_data = CODA_IMX27 },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(platform, coda_platform_ids);
-
-#ifdef CONFIG_OF
static const struct of_device_id coda_dt_ids[] = {
{ .compatible = "fsl,imx27-vpu", .data = &coda_devdata[CODA_IMX27] },
{ .compatible = "fsl,imx51-vpu", .data = &coda_devdata[CODA_IMX51] },
@@ -3118,14 +3110,9 @@ static const struct of_device_id coda_dt_ids[] = {
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, coda_dt_ids);
-#endif
static int coda_probe(struct platform_device *pdev)
{
- const struct of_device_id *of_id =
- of_match_device(of_match_ptr(coda_dt_ids), &pdev->dev);
- const struct platform_device_id *pdev_id;
- struct coda_platform_data *pdata = pdev->dev.platform_data;
struct device_node *np = pdev->dev.of_node;
struct gen_pool *pool;
struct coda_dev *dev;
@@ -3135,14 +3122,7 @@ static int coda_probe(struct platform_device *pdev)
if (!dev)
return -ENOMEM;
- pdev_id = of_id ? of_id->data : platform_get_device_id(pdev);
-
- if (of_id)
- dev->devtype = of_id->data;
- else if (pdev_id)
- dev->devtype = &coda_devdata[pdev_id->driver_data];
- else
- return -EINVAL;
+ dev->devtype = of_device_get_match_data(&pdev->dev);
dev->dev = &pdev->dev;
dev->clk_per = devm_clk_get(&pdev->dev, "per");
@@ -3200,10 +3180,8 @@ static int coda_probe(struct platform_device *pdev)
return ret;
}
- /* Get IRAM pool from device tree or platform data */
+ /* Get IRAM pool from device tree */
pool = of_gen_pool_get(np, "iram", 0);
- if (!pool && pdata)
- pool = gen_pool_get(pdata->iram_dev, NULL);
if (!pool) {
dev_err(&pdev->dev, "iram pool not available\n");
return -ENOMEM;
@@ -3342,7 +3320,6 @@ static struct platform_driver coda_driver = {
.of_match_table = of_match_ptr(coda_dt_ids),
.pm = &coda_pm_ops,
},
- .id_table = coda_platform_ids,
};
module_platform_driver(coda_driver);
diff --git a/include/linux/platform_data/media/coda.h
b/include/linux/platform_data/media/coda.h
deleted file mode 100644
index 293b61b60c9d..
--- a/include/linux/platform_data/media/coda.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (C) 2013 Philipp Zabel, Pengutronix
- */
-#ifndef PLATFORM_CODA_H
-#define PLATFORM_CODA_H
-
-struct device;
-
-struct coda_platform_data {
- struct device *iram_dev;
-};
-
-#endif
--
2.17.1
[PATCH v2] media: coda: Convert the driver to DT-only
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code
by removing the unused non-DT support.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Drop include/linux/platform_data/media/coda.h and pdata - Hans
drivers/media/platform/coda/coda-common.c | 27 ++-
include/linux/platform_data/media/coda.h | 14
2 files changed, 2 insertions(+), 39 deletions(-)
delete mode 100644 include/linux/platform_data/media/coda.h
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index d30eafea701d..995e95272e51 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
@@ -3102,13 +3101,6 @@ static const struct coda_devtype coda_devdata[] = {
},
};
-static const struct platform_device_id coda_platform_ids[] = {
- { .name = "coda-imx27", .driver_data = CODA_IMX27 },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(platform, coda_platform_ids);
-
-#ifdef CONFIG_OF
static const struct of_device_id coda_dt_ids[] = {
{ .compatible = "fsl,imx27-vpu", .data = &coda_devdata[CODA_IMX27] },
{ .compatible = "fsl,imx51-vpu", .data = &coda_devdata[CODA_IMX51] },
@@ -3118,14 +3110,9 @@ static const struct of_device_id coda_dt_ids[] = {
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, coda_dt_ids);
-#endif
static int coda_probe(struct platform_device *pdev)
{
- const struct of_device_id *of_id =
- of_match_device(of_match_ptr(coda_dt_ids), &pdev->dev);
- const struct platform_device_id *pdev_id;
- struct coda_platform_data *pdata = pdev->dev.platform_data;
struct device_node *np = pdev->dev.of_node;
struct gen_pool *pool;
struct coda_dev *dev;
@@ -3135,14 +3122,7 @@ static int coda_probe(struct platform_device *pdev)
if (!dev)
return -ENOMEM;
- pdev_id = of_id ? of_id->data : platform_get_device_id(pdev);
-
- if (of_id)
- dev->devtype = of_id->data;
- else if (pdev_id)
- dev->devtype = &coda_devdata[pdev_id->driver_data];
- else
- return -EINVAL;
+ dev->devtype = of_device_get_match_data(&pdev->dev);
dev->dev = &pdev->dev;
dev->clk_per = devm_clk_get(&pdev->dev, "per");
@@ -3200,10 +3180,8 @@ static int coda_probe(struct platform_device *pdev)
return ret;
}
- /* Get IRAM pool from device tree or platform data */
+ /* Get IRAM pool from device tree */
pool = of_gen_pool_get(np, "iram", 0);
- if (!pool && pdata)
- pool = gen_pool_get(pdata->iram_dev, NULL);
if (!pool) {
dev_err(&pdev->dev, "iram pool not available\n");
return -ENOMEM;
@@ -3342,7 +3320,6 @@ static struct platform_driver coda_driver = {
.of_match_table = of_match_ptr(coda_dt_ids),
.pm = &coda_pm_ops,
},
- .id_table = coda_platform_ids,
};
module_platform_driver(coda_driver);
diff --git a/include/linux/platform_data/media/coda.h
b/include/linux/platform_data/media/coda.h
deleted file mode 100644
index 293b61b60c9d..
--- a/include/linux/platform_data/media/coda.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (C) 2013 Philipp Zabel, Pengutronix
- */
-#ifndef PLATFORM_CODA_H
-#define PLATFORM_CODA_H
-
-struct device;
-
-struct coda_platform_data {
- struct device *iram_dev;
-};
-
-#endif
--
2.17.1
Re: [PATCH v1 2/2] ARM: dts: add Protonic MVT board
Hi Oleksij,
On Mon, Nov 30, 2020 at 10:14 AM Oleksij Rempel wrote:
> +&ecspi1 {
> + cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
Shouldn't this be GPIO_ACTIVE_LOW instead?
Re: [PATCH] rtc: mxc{,_v2}: enable COMPILE_TEST
On Sat, Nov 21, 2020 at 7:45 PM Alexandre Belloni wrote: > > Extend code coverage for the rtc-mxc and rtc-mxc-v2 drivers. > > Signed-off-by: Alexandre Belloni Reviewed-by: Fabio Estevam
Re: drivers/media/platform/fsl-viu.c:253:2: error: implicit declaration of function 'out_be32'
On Wed, Nov 18, 2020 at 10:15 PM kernel test robot wrote: > > Hi Fabio, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: c2e7554e1b85935d962127efa3c2a76483b0b3b6 > commit: 17621758e53f0e6bf1ac469cca2a59fa6457d205 media: fsl-viu: Do not > redefine out_be32()/in_be32() for CONFIG_M68K > date: 3 months ago > config: m68k-randconfig-r013-20201118 (attached as .config) > compiler: m68k-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=17621758e53f0e6bf1ac469cca2a59fa6457d205 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 17621758e53f0e6bf1ac469cca2a59fa6457d205 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=m68k > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >drivers/media/platform/fsl-viu.c: In function 'viu_start_dma': > >> drivers/media/platform/fsl-viu.c:253:2: error: implicit declaration of > >> function 'out_be32' [-Werror=implicit-function-declaration] > 253 | out_be32(&vr->status_cfg, SOFT_RST); > | ^~~~ >drivers/media/platform/fsl-viu.c: In function 'viu_stop_dma': > >> drivers/media/platform/fsl-viu.c:266:15: error: implicit declaration of > >> function 'in_be32' [-Werror=implicit-function-declaration] > 266 | status_cfg = in_be32(&vr->status_cfg); > | ^~~ >cc1: some warnings being treated as errors It seems that Geert has submitted a proper fix a long time ago: https://lkml.org/lkml/2020/8/17/2376
Re: [PATCH] rtc: mxc: use of_device_get_match_data
On Tue, Nov 17, 2020 at 5:30 PM Alexandre Belloni wrote: > > Use of_device_get_match_data to simplify mxc_rtc_probe. > > Signed-off-by: Alexandre Belloni Reviewed-by: Fabio Estevam
Re: [PATCH] spi: imx: enable runtime pm support
Hi Nikita, On Fri, Nov 13, 2020 at 6:18 AM Nikita Shubin wrote: > > Hello Clark, > > This patch breaks spi-imx on imx7d. > Toradex Colibri imx7d spi reports with: > > [4.258468] inv-mpu6000-spi spi2.0: I/O Error in PIO > [4.264269] inv-mpu6000-spi spi2.0: SPI transfer failed: -110 > [4.264305] spi_master spi2: failed to transfer one message from queue > > We are using spi-imx with dma. > > Reverting your patch fixes this issue. > > The baseline commit 951cbbc386ff01b50da4f46387e994e81d9ab431 (tag: v5.9.8, > stable/linux-5.9.y) > > Could you please give some comments on this issue ? Could you please try this patch from Sascha? https://lkml.org/lkml/2020/10/12/981
Re: [PATCH] ARM: mxs: Add serial number support for i.MX23, i.MX28 SoCs
Hi Ivan, On Wed, Nov 11, 2020 at 2:19 AM Ivan Zaentsev wrote: > > i.MX23 and i.MX28 SoCs unique identifiers are factory-programmed > in On-Chip OTP memory. i.MX28's 64-bit unique id is in > HW_OCOTP_OPS2:HW_OCOTP_OPS3 (see MCIMX28 Ref. Man., sec. 20.4.22-23). > > i.MX23 provides 32-bit long unique id in HW_OCOTP_OPS3. > Though not clearly documented, there is a clue in sec. 35.9.3. > > The unique id is reported in /sys/devices/soc0/serial_number > and in /proc/cpuinfo > > Signed-off-by: Ivan Zaentsev > Suggested-by: Evgeny Boger It looks good, thanks: Reviewed-by: Fabio Estevam
Re: [PATCH v1] ARM: imx: mach-imx6q: correctly identify i.MX6QP SoCs
On Wed, Nov 4, 2020 at 1:54 PM Sven Van Asbroeck wrote: > > The i.MX6QP rev 1.1 SoC on my board is mis-identified by Linux: > the log (incorrectly) shows "i.MX6Q rev 2.1". > > Correct this by assuming that every SoC that identifies as > i.MX6Q with rev >= 2.0 is really an i.MX6QP. > > Signed-off-by: Sven Van Asbroeck Reviewed-by: Fabio Estevam
Re: [PATCH AUTOSEL 5.9 131/147] soc: imx: gpcv2: Use dev_err_probe() to simplify error handling
Hi Sasha, On Mon, Oct 26, 2020 at 8:56 PM Sasha Levin wrote: > > From: Anson Huang > > [ Upstream commit b663b798d04fb73f1ad4d54c46582d2fde7a76d6 ] > > dev_err_probe() can reduce code size, uniform error handling and record the > defer probe reason etc., use it to simplify the code. > > Signed-off-by: Anson Huang > Reviewed-by: Guido Günther > Signed-off-by: Shawn Guo > Signed-off-by: Sasha Levin Does this qualify for stable since it is just a cleanup and not a bug fix?
Re: [PATCH] arm64: defconfig: enable CONFIG_GPIO_MXC
Hi Peng, On Wed, Oct 21, 2020 at 3:38 AM wrote: > > From: Peng Fan > > To i.MX8MP, always met "Waiting for root device /dev/mmcblk1p2...", > it is because the gpio driver not enabled. So enable CONFIG_GPIO_MXC > to make sure it could boot well. > > Signed-off-by: Peng Fan Anson has already submitted this change: https://patchwork.ozlabs.org/project/linux-gpio/patch/1600320829-1453-2-git-send-email-anson.hu...@nxp.com/
Re: [PATCH 2/3] arm64: dts: imx8mm: Add node for SPDIF
Hi Krzysztof,
On Mon, Oct 12, 2020 at 2:00 PM Krzysztof Kozlowski wrote:
> > + spdif1: spdif@3009 {
> > + compatible = "fsl,imx8mm-spdif",
> > "fsl,imx35-spdif";
>
> This does not pass the dtschema validation, so only "fsl,imx35-spdif".
Shouldn't the dt schema validation be changed then to accept this format?
Re: [PATCH] clk: imx8mq: Fix usdhc parents order
Hi Abel,
On Thu, Oct 15, 2020 at 6:26 AM Abel Vesa wrote:
>
> According to the latest RM (see Table 5-1. Clock Root Table),
> both usdhc root clocks have the parent order as follows:
>
> 000 - 25M_REF_CLK
> 001 - SYSTEM_PLL1_DIV2
> 010 - SYSTEM_PLL1_CLK
> 011 - SYSTEM_PLL2_DIV2
> 100 - SYSTEM_PLL3_CLK
> 101 - SYSTEM_PLL1_DIV3
> 110 - AUDIO_PLL2_CLK
> 111 - SYSTEM_PLL1_DIV8
>
> So the audio_pll2_out and sys3_pll_out have to be swapped.
>
> Fixes: b80522040cd3 ("clk: imx: Add clock driver for i.MX8MQ CCM")
> Signed-off-by: Abel Vesa
> Reported-by: Cosmin Stefan Stoica
Thanks for the fix:
Reviewed-by: Fabio Estevam
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
Hi Florian, On Sun, Oct 11, 2020 at 6:59 PM Florian Fainelli wrote: > however the NAND warning still remains. Someone else familiar with these > NXP development boards should fix the DTS so as to provide the require > ECC strength property. The ECC NAND warning looks like a regression. I had originally reported it for an imx27 board and now I also pointed out that it also affects Layerscape: https://lore.kernel.org/linux-mtd/20201013193652.0c535c7c@xps13/T/#m09fad7eacdf86aee0834bbd8863d6d5ee2e69f8c Thanks, Fabio Estevam
Re: PHY reset question
Hi Oleksij,
On Tue, Oct 6, 2020 at 5:05 AM Oleksij Rempel wrote:
>
> Hello PHY experts,
>
> Short version:
> what is the proper way to handle the PHY reset before identifying PHY?
>
> Long version:
> I stumbled over following issue:
> If PHY reset is registered within PHY node. Then, sometimes, we will not be
> able to identify it (read PHY ID), because PHY is under reset.
>
> mdio {
> compatible = "virtual,mdio-gpio";
>
> [...]
>
> /* Microchip KSZ8081 */
> usbeth_phy: ethernet-phy@3 {
> reg = <0x3>;
>
> interrupts-extended = <&gpio5 12 IRQ_TYPE_LEVEL_LOW>;
> reset-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
> reset-assert-us = <500>;
> reset-deassert-us = <1000>;
> };
>
> [...]
> };
>
> On simple boards with one PHY per MDIO bus, it is easy to workaround by using
> phy-reset-gpios withing MAC node (illustrated in below DT example), instead of
> using reset-gpios within PHY node (see above DT example).
>
> &fec {
> [...]
> phy-mode = "rmii";
> phy-reset-gpios = <&gpio4 12 GPIO_ACTIVE_LOW>;
> [...]
I thought this has been fixed by Bruno's series:
https://www.spinics.net/lists/netdev/msg673611.html
Re: [PATCH v2 08/12] ARM: dts: imx6dl-pico: fix board compatibles
Hi Marco, On Fri, Oct 2, 2020 at 5:41 AM Marco Felsch wrote: > Question is what was the author's intention? @Fabio do you have any > comments here? Krzysztof's patch looks good: Reviewed-by: Fabio Estevam Thanks
Re: [PATCH] arm64: dts: fix endianness of rcpm
Hi Ran, On Mon, Sep 28, 2020 at 6:14 AM Ran Wang wrote: > > From: Biwen Li > > Add little-endian property of rcpm for ls1028a,ls1088a,ls208xa > > Signed-off-by: Biwen Li You missed your Signed-off-by tag. What about adding a Fixes tag?
Re: [PATCH 1/2] drm/bridge: sii902x: Enable I/O and core VCC supplies if present
Hi Alexandre,
On Thu, Sep 24, 2020 at 5:16 PM Alexandru Gagniuc wrote:
> + ret = regulator_enable(sii902x->cvcc12);
> + if (ret < 0) {
> + dev_err(dev, "Failed to enable cvcc12 supply: %d\n", ret);
> + regulator_disable(sii902x->iovcc);
> + return PTR_ERR(sii902x->cvcc12);
return ret;
>
> ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
> @@ -1012,11 +1052,11 @@ static int sii902x_probe(struct i2c_client *client,
> regmap_read(sii902x->regmap, SII902X_INT_STATUS, &status);
> regmap_write(sii902x->regmap, SII902X_INT_STATUS, status);
>
> - if (client->irq > 0) {
> + if (sii902x->i2c->irq > 0) {
Unrelated change.
> regmap_write(sii902x->regmap, SII902X_INT_ENABLE,
> SII902X_HOTPLUG_EVENT);
>
> - ret = devm_request_threaded_irq(dev, client->irq, NULL,
> + ret = devm_request_threaded_irq(dev, sii902x->i2c->irq, NULL,
Unrelated change.
sii902x_interrupt,
> IRQF_ONESHOT, dev_name(dev),
> sii902x);
> @@ -1031,9 +1071,9 @@ static int sii902x_probe(struct i2c_client *client,
>
> sii902x_audio_codec_init(sii902x, dev);
>
> - i2c_set_clientdata(client, sii902x);
> + i2c_set_clientdata(sii902x->i2c, sii902x);
Unrelated change.
> - sii902x->i2cmux = i2c_mux_alloc(client->adapter, dev,
> + sii902x->i2cmux = i2c_mux_alloc(sii902x->i2c->adapter, dev,
Unrelated change.
Re: [PATCH v3 16/16] ARM: Remove custom IRQ stat accounting
Hi Guillaume, On Thu, Sep 24, 2020 at 6:01 AM Guillaume Tucker wrote: > This appears to be causing a NULL pointer dereference on > beaglebone-black, it got bisected automatically several times. > None of the other platforms in the KernelCI labs appears to be > affected. Actually imx53-qsb is also affected: https://storage.kernelci.org/next/master/next-20200924/arm/imx_v6_v7_defconfig/gcc-8/lab-pengutronix/baseline-imx53-qsrb.html kernelci marks it Boot result: PASS though. Shouldn't kernelci flag a warning or error instead? Thanks
Re: [PATCH V2 0/4] imx: support i.MX7ULP HSRUN mode
Hi Peng, On Tue, Sep 15, 2020 at 11:55 PM wrote: > > From: Peng Fan > > V2: > Update to use pmc0/pmc1 following hardware naming > > This patchset is to add HSRUN mode support. > Patch 1,2 is to add binding doc and dts node > Patch 3 is to support HSRUN mode > Patch 4 is to use wait mode when HSRUN working per hardware state machine > requirement. > > Peng Fan (4): > dt-bindings: fsl: add i.MX7ULP PMC > ARM: dts: imx7ulp: add pmc node > ARM: imx: imx7ulp: support HSRUN mode > ARM: imx: cpuidle-imx7ulp: Stop mode disallowed when HSRUN It seems that a patch adding the 720MHz HSRUN operational point in imx7ulp.dtsi is missing. Thanks
Re: [RFC PATCH v1 3/3] dt-binding: display: Require two rests on mantix panel
Hi Guido, On Mon, Sep 21, 2020 at 1:56 PM Guido Günther wrote: > > We need to reset both for the panel to show an image. There is a typo in "resets" in the Subject line.
Re: [PATCH v2 0/3] ASoC: fsl_sai: update the register list
Hi Shengjiu, On Thu, Sep 17, 2020 at 3:18 AM Shengjiu Wang wrote: > > As sai ip is upgraded, so update sai register list. > > Shengjiu Wang (3): > ASoC: fsl_sai: Add new added registers and new bit definition > ASoC: fsl_sai: Add fsl_sai_check_version function > ASoC: fsl_sai: Set MCLK input or output direction > > changes in v2: > - update commit message for first commit > - Add acked-by Nicolin For the whole series: Reviewed-by: Fabio Estevam
Re: [PATCH 1/3] ASoC: fsl_sai: Add new added registers and new bit definition
Hi Shengjiu, On Wed, Sep 16, 2020 at 7:23 AM Shengjiu Wang wrote: > > On i.MX850/i.MX815/i.MX845 platform, the sai IP is upgraded. Please avoid such internal SoC namings and use i.MX8MQ/i.MX8MN/iMX8MM instead.
Re: [PATCH 0/3] ASoC: fsl_sai: update the register list
On Wed, Sep 16, 2020 at 8:47 AM Fabio Estevam wrote: > > Knob kmg Please ignore. It seems my cellphone wanted to write something.
Re: [PATCH -next] clk: imx35: Make mx35_clocks_init static
Hi YueHaibing, On Tue, Sep 15, 2020 at 11:02 AM YueHaibing wrote: > > Fix sparse warning: > > drivers/clk/imx/clk-imx35.c:251:12: warning: > symbol 'mx35_clocks_init' was not declared. Should it be static? This is not the correct fix. mx35_clocks_init() was only used by imx35 board files. Now that imx35 board files are gone, this function can be removed. I will send a patch removing it.
Re: [PATCH 3/3] clk: imx31: Make mx31_clocks_init static
On Tue, Sep 15, 2020 at 11:02 AM YueHaibing wrote: > > Fix sparse warning: > > drivers/clk/imx/clk-imx31.c:135:12: warning: > symbol 'mx31_clocks_init' was not declared. Should it be static? Same as the other comment for mx35, This function should be removed. I will send a patch removing it.
Re: (EXT) Re: (EXT) Re: (EXT) Re: [PATCH] spi-imx: remove num-cs support, set num_chipselect to 4
Hi Matthias, On Mon, Sep 7, 2020 at 4:40 AM Matthias Schiffer wrote: > My rationale here is the following: As broken as the native CS of these > controllers is, it isn't an unreasonable assumption that it is working > fine with *some* devices or for some usecases - after all the support > was implemented at some point, and has existed for a long time now. If > we really want to remove this feature, a deprecation period with a > warning message seems like the proper way to deal with this. > > Hypothetically, existing out-of-tree DTS could have used the native CS > with num-cs set to 4. Always setting num_chipselect to 4 ensures that > we don't break such DTS with the num-cs removal. I still think this is more of a theoretical issue rather than a real use case one. Anyway, I have a proposal that I think will make both of us happy :-) I will submit a patch shortly.
Re: [PATCH] i2c: mxs: use MXS_DMA_CTRL_WAIT4END instead of DMA_CTRL_ACK
Hi Matthias,
On Fri, Sep 11, 2020 at 12:01 PM Matthias Schiffer
wrote:
>
> The driver-specific usage of the DMA_CTRL_ACK flag was replaced with a
> custom flag in commit ceeeb99cd821 ("dmaengine: mxs: rename custom flag"),
> but i2c-mxs was not updated to use the new flag, completely breaking I2C
> transactions using DMA.
>
> Fixes: ceeeb99cd821 ("dmaengine: mxs: rename custom flag")
> Signed-off-by: Matthias Schiffer
Thanks for the fix:
Reviewed-by: Fabio Estevam
Re: [PATCH v2] drm: mxsfb: check framebuffer pitch
Hi Stefan, On Tue, Sep 8, 2020 at 9:56 AM Stefan Agner wrote: > > The lcdif IP does not support a framebuffer pitch (stride) other than > framebuffer width. Check for equality and reject the framebuffer > otherwise. > > This prevents a distorted picture when using 640x800 and running the > Mesa graphics stack. Mesa tires to use a cache aligned stride, which > leads at that particular resolution to width != stride. Currently > Mesa has no fallback behavior, but rejecting this configuration allows > userspace to handle the issue correctly. What about adding a Fixes tag so that it can be backported to old stable kernels? Thanks
Re: (EXT) Re: (EXT) Re: [PATCH] spi-imx: remove num-cs support, set num_chipselect to 4
Hi Mark,
On Fri, Sep 4, 2020 at 12:05 PM Mark Brown wrote:
>
> On Fri, Sep 04, 2020 at 04:34:43PM +0200, Matthias Schiffer wrote:
>
> > Nevertheless, I don't see why we should deliberately remove the native
> > CS support - my understanding was that we try to avoid breaking changes
> > to DT interpretation even for unknown/out-of-tree DTS.
>
> Yes, we should try to maintain compatibility for anyone that was using
> it.
We are not breaking compatibility.
Prior to 8cdcd8aeee281 ("spi: imx/fsl-lpspi: Convert to GPIO
descriptors") num_chipselect was 1 for all device tree users.
i.MX board files will be removed, so we don't need to worry about them.
What will cause breakage is to say that the driver supports the native
chip-select.
I have just done a quick test on an imx6q-sabresd.
With the original dts that uses cs-gpios the SPI NOR is correctly probed:
[5.402627] spi-nor spi0.0: m25p32 (4096 Kbytes)
However, using native chip select with this dts change:
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -189,7 +189,6 @@
};
&ecspi1 {
- cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
status = "okay";
@@ -506,7 +505,7 @@
MX6QDL_PAD_KEY_COL1__ECSPI1_MISO0x100b1
MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI0x100b1
MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK0x100b1
- MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
+ MX6QDL_PAD_KEY_ROW1__ECSPI1_SS0 0x1b0b0
>;
};
Causes SPI NOR probe to fail:
[5.388704] spi-nor spi0.0: unrecognized JEDEC id bytes: 00 00 00 00 00 00
That's why I prefer we do not advertise that we can use the native
chip-select with this driver.
Re: (EXT) Re: [PATCH] spi-imx: remove num-cs support, set num_chipselect to 4
On Fri, Sep 4, 2020 at 10:02 AM Matthias Schiffer wrote: > This would make num_chipselect default to 1 again (set by > __spi_alloc_controller()), breaking every i.MX board that uses more > than 1 native CS. Which boards are that? Are you referring to non-DT i.MX boards? If so, I have sent a patch removing all non-DT i.MX boards. > I'm aware that using cs-gpios instead of native CS is probably a good > idea in any case, as the native CS of this SPI controller is kinda > flaky (and at a glance it looks like all in-tree DTs do this; not sure > about board files that don't use DTs?), but I'm not convinced that > breaking native CS support completely is desirable either. Initial i.MX chips with this SPI IP had issues in using chip-select in native mode and GPIO chip-select has been used since them. Do we have i.MX dts that make use of native chip select?
