* [PATCH 2/2] ARM: defconfig: Switch LPC32xx to use PL11x DRM driver
From: Linus Walleij @ 2018-12-10 12:04 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: Linus Walleij, linux-arm-kernel
In-Reply-To: <20181210120454.9099-1-linus.walleij@linaro.org>
None of the LPC32xx device trees contains any display settings,
it just defines a device tree node for the CLCD (PL11x) left
as "disabled" on lpc3250-ea3250 and "okay" on lpc3250-phy3250
but no panels are attached on any device tree, so the driver
will simply bail out.
I conclude that the hardware is dormant on existing
systems, so we can without any problems switch the defconfig
over from the old ARMCLCD frame buffer driver to the new
PL11x DRM driver.
Cc: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/lpc32xx_defconfig | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
index 120d6b18df9a..6273d90c420a 100644
--- a/arch/arm/configs/lpc32xx_defconfig
+++ b/arch/arm/configs/lpc32xx_defconfig
@@ -111,10 +111,12 @@ CONFIG_SENSORS_DS620=y
CONFIG_SENSORS_MAX6639=y
CONFIG_WATCHDOG=y
CONFIG_PNX4008_WATCHDOG=y
-CONFIG_FB=y
-CONFIG_FB_ARMCLCD=y
+CONFIG_DRM=y
+CONFIG_DRM_PL111=y
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
--
2.19.2
_______________________________________________
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/2] ARM: defconfig: Update LPC32xx defconfig
From: Linus Walleij @ 2018-12-10 12:04 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: Linus Walleij, linux-arm-kernel
This simply updates the LPC18xx defconfig against the current
Kconfig structure in the kernel so we can make changed to the
defconfig without disturbing noise.
Cc: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/lpc32xx_defconfig | 34 +++++++++++-------------------
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
index 0b54b4024e51..120d6b18df9a 100644
--- a/arch/arm/configs/lpc32xx_defconfig
+++ b/arch/arm/configs/lpc32xx_defconfig
@@ -1,6 +1,7 @@
CONFIG_SYSVIPC=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
@@ -11,13 +12,7 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_EMBEDDED=y
CONFIG_SLAB=y
-CONFIG_JUMP_LABEL=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=y
CONFIG_ARCH_LPC32XX=y
-CONFIG_PREEMPT=y
CONFIG_AEABI=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
@@ -26,6 +21,11 @@ CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CMDLINE="console=ttyS0,115200n81 root=/dev/ram0"
CONFIG_CPU_IDLE=y
CONFIG_VFP=y
+CONFIG_JUMP_LABEL=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_NET=y
CONFIG_PACKET=y
@@ -75,9 +75,6 @@ CONFIG_LPC_ENET=y
# CONFIG_NET_VENDOR_STMICRO is not set
CONFIG_SMSC_PHY=y
# CONFIG_WLAN is not set
-# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
-CONFIG_INPUT_MOUSEDEV_SCREEN_X=240
-CONFIG_INPUT_MOUSEDEV_SCREEN_Y=320
CONFIG_INPUT_EVDEV=y
# CONFIG_KEYBOARD_ATKBD is not set
CONFIG_KEYBOARD_GPIO=y
@@ -99,7 +96,6 @@ CONFIG_I2C_PNX=y
CONFIG_SPI=y
CONFIG_SPI_PL022=y
CONFIG_GPIO_SYSFS=y
-CONFIG_GPIO_EM=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_PL061=y
CONFIG_GPIO_ADP5588=y
@@ -111,8 +107,6 @@ CONFIG_GPIO_PCF857X=y
CONFIG_GPIO_74X164=y
CONFIG_GPIO_MAX7301=y
CONFIG_GPIO_MC33880=y
-CONFIG_PINCTRL_MCP23S08=y
-CONFIG_PINCTRL_SX150X=y
CONFIG_SENSORS_DS620=y
CONFIG_SENSORS_MAX6639=y
CONFIG_WATCHDOG=y
@@ -126,14 +120,11 @@ CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_SOUND=y
CONFIG_SND=y
-CONFIG_SND_SEQUENCER=y
-CONFIG_SND_MIXER_OSS=y
-CONFIG_SND_PCM_OSS=y
-CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_VERBOSE=y
+CONFIG_SND_SEQUENCER=y
# CONFIG_SND_DRIVERS is not set
# CONFIG_SND_ARM is not set
# CONFIG_SND_SPI is not set
@@ -146,7 +137,6 @@ CONFIG_USB_LPC32XX=y
CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
-# CONFIG_MMC_BLOCK_BOUNCE is not set
CONFIG_MMC_ARMMMCI=y
CONFIG_MMC_SPI=y
CONFIG_NEW_LEDS=y
@@ -169,10 +159,10 @@ CONFIG_RTC_DRV_LPC32XX=y
CONFIG_DMADEVICES=y
CONFIG_AMBA_PL08X=y
CONFIG_STAGING=y
-CONFIG_LPC32XX_ADC=y
CONFIG_MEMORY=y
CONFIG_ARM_PL172_MPMC=y
CONFIG_IIO=y
+CONFIG_LPC32XX_ADC=y
CONFIG_MAX517=y
CONFIG_PWM=y
CONFIG_PWM_LPC32XX=y
@@ -191,13 +181,13 @@ CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_UTF8=y
+CONFIG_CRYPTO_ANSI_CPRNG=y
+# CONFIG_CRYPTO_HW is not set
+CONFIG_CRC_CCITT=y
CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_FS=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_FTRACE is not set
-# CONFIG_ARM_UNWIND is not set
CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
-CONFIG_CRYPTO_ANSI_CPRNG=y
-# CONFIG_CRYPTO_HW is not set
-CONFIG_CRC_CCITT=y
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 08/13] arm64: expose user PAC bit positions via ptrace
From: Catalin Marinas @ 2018-12-10 12:03 UTC (permalink / raw)
To: Richard Henderson
Cc: Mark Rutland, Andrew Jones, Steve Capper, Jacob Bramley,
Ard Biesheuvel, Marc Zyngier, linux-kernel, Adam Wallis,
Suzuki K Poulose, Will Deacon, Christoffer Dall,
Kristina Martsenko, Dave P Martin, Cyrill Gorcunov,
Ramana Radhakrishnan, Amit Kachhap, kvmarm, linux-arm-kernel,
Kees Cook
In-Reply-To: <a31ca10a-ee1a-71fb-2c3d-a6184e12b543@linaro.org>
On Sun, Dec 09, 2018 at 09:41:31AM -0600, Richard Henderson wrote:
> On 12/7/18 12:39 PM, Kristina Martsenko wrote:
> > When pointer authentication is in use, data/instruction pointers have a
> > number of PAC bits inserted into them. The number and position of these
> > bits depends on the configured TCR_ELx.TxSZ and whether tagging is
> > enabled. ARMv8.3 allows tagging to differ for instruction and data
> > pointers.
>
> At this point I think it's worth starting a discussion about pointer tagging,
> and how we can make it controllable and not mandatory.
>
> With this patch set, we are enabling 7 authentication bits: [54:48].
>
> However, it won't be too long before someone implements support for
> ARMv8.2-LVA, at which point, without changes to mandatory pointer tagging, we
> will only have 3 authentication bits: [54:52]. This seems useless and easily
> brute-force-able.
Such support is already here (about to be queued):
https://lore.kernel.org/linux-arm-kernel/20181206225042.11548-1-steve.capper@arm.com/
> I assume that pointer tagging is primarily used by Android, since I'm not aware
> of anything else that uses it at all.
I would expect it to be enabled more widely (Linux distros), though only
the support for instructions currently in the NOP space.
> Unfortunately, there is no obvious path to making this optional that does not
> break compatibility with Documentation/arm64/tagged-pointers.txt.
There is also the ARMv8.5 MTE (memory tagging) which relies on tagged
pointers.
> I've been thinking that there ought to be some sort of global setting, akin to
> /proc/sys/kernel/randomize_va_space, as well as a prctl which an application
> could use to selectively enable TBI/TBID for an application that actually uses
> tagging.
An alternative would be to allow the opt-in to 52-bit VA, leaving it at
48-bit by default. However, it has the problem of changing the PAC size
and not being able to return.
> The global /proc setting allows the default to remain 1, which would let any
> application using tagging to continue working. If there are none, the sysadmin
> can set the default to 0. Going forward, applications could be updated to use
> the prctl, allowing more systems to set the default to 0.
>
> FWIW, pointer authentication continues to work when enabling TBI, but not the
> other way around. Thus the prctl could be used to enable TBI at any point, but
> if libc is built with PAuth, there's no way to turn it back off again.
This may work but, as you said, TBI is user ABI at this point, we can't
take it away now (at the time we didn't forsee the pauth).
Talking briefly with Will/Kristina/Mark, I think the best option is to
make 52-bit VA default off in the kernel config. Whoever needs it
enabled (enterprise systems) should be aware of the reduced PAC bits. I
don't really think we have a better solution.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver
From: Faiz Abbas @ 2018-12-10 12:04 UTC (permalink / raw)
To: Adrian Hunter, linux-kernel, linux-arm-kernel, devicetree,
linux-mmc
Cc: mark.rutland, ulf.hansson, robh+dt, michal.simek, kishon
In-Reply-To: <970c3531-5d7d-fe94-55c1-13603735b43a@intel.com>
Hi Adrian,
On 07/12/18 7:02 PM, Adrian Hunter wrote:
> On 5/12/18 5:07 PM, Faiz Abbas wrote:
>> Hi Adrian,
>>
>> On 05/12/18 7:12 PM, Adrian Hunter wrote:
>>> On 29/11/18 6:15 PM, Faiz Abbas wrote:
>>>> The host controllers on TI's AM654 SOCs are not compatible with
>>>> the phy and consumer model of the sdhci-of-arasan driver. It turns out
>>>> that for optimal operation at higher speeds, a special tuning procedure
>>>> needs to be implemented which involves configuration of platform
>>>> specific phy registers.
>>>>
>>>> Therefore, branch out to a new sdhci_am654 driver and add the phy
>>>> register space with all phy configurations to it. Populate AM654
>>>> specific callbacks to sdhci_ops and add SDHCI_QUIRKS wherever
>>>> applicable.
>>>>
>>>> Only add support for upto High Speed for SD card and upto DDR52 speed
>>>> mode for eMMC. Higher speeds will be added in subsequent patches.
>>>>
...
>>>> +
>>>> + sdhci_am654->clk_ahb = devm_clk_get(dev, "clk_ahb");
>>>> + if (IS_ERR(sdhci_am654->clk_ahb)) {
>>>> + dev_err(dev, "clk_ahb clock not found.\n");
>>>> + ret = PTR_ERR(sdhci_am654->clk_ahb);
>>>> + goto err_pltfm_free;
>>>> + }
>>>
>>> Did you intend not to enable clks?
>>
>> Yes. Clocks get enabled as a part of pm_runtime calls.
>
> Ok, but that could use an explanatory comment. Also why get a reference to
> clk_ahb if that reference is never used?
>
You're right. It was being used in sdhci-of-arasan because other users
needed to call enable() and disable(). I missed out on removing it when
porting over. Will remove it and add the comment.
Thanks,
Faiz
_______________________________________________
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] cpuidle: big.LITTLE: add of_node_put()
From: Daniel Lezcano @ 2018-12-10 11:59 UTC (permalink / raw)
To: Yangtao Li, rjw, lorenzo.pieralisi
Cc: linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <20181120161451.21149-1-tiny.windzz@gmail.com>
Hi Yangtao,
On 20/11/2018 17:14, Yangtao Li wrote:
> of_find_node_by_path() acquires a reference to the node
> returned by it and that reference needs to be dropped by its caller.
> bl_idle_init() doesn't do that, so fix it.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> Changes in v3:
> -update changelog
> ---
> drivers/cpuidle/cpuidle-big_little.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
> index db2ede565f1a..650f063ef809 100644
> --- a/drivers/cpuidle/cpuidle-big_little.c
> +++ b/drivers/cpuidle/cpuidle-big_little.c
> @@ -174,8 +174,12 @@ static int __init bl_idle_init(void)
> /*
> * Initialize the driver just for a compliant set of machines
> */
> - if (!of_match_node(compatible_machine_match, root))
> + if (!of_match_node(compatible_machine_match, root)){
> + of_node_put(root);
> return -ENODEV;
> + }
> +
> + of_node_put(root);
Don't duplicate the of_node_put.
I suggest:
const struct of_device_id *match_id;
[ ... ]
match_id = of_match_node(compatible_machine_match, root);
of_node_put(root);
if (!match_id)
return -ENODEV;
> if (!mcpm_is_available())
> return -EUNATCH;
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 6/6] arm64: dts: allwinner: a64-amarula-relic: Add OV5640 camera node
From: Jagan Teki @ 2018-12-10 11:52 UTC (permalink / raw)
To: Yong Deng, Mauro Carvalho Chehab, Maxime Ripard, Rob Herring,
Mark Rutland, Chen-Yu Tsai, linux-media, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, linux-amarula,
Michael Trimarchi
Cc: Jagan Teki
In-Reply-To: <20181210115246.8188-1-jagan@amarulasolutions.com>
Amarula A64-Relic board by default bound with OV5640 camera,
so add support for it with below pin information.
- PE13, PE12 via i2c-gpio bitbanging
- CLK_CSI_MCLK as external clock
- PE1 as external clock pin muxing
- ALDO1 as AVDD supply
- DLDO3 as DOVDD supply
- ELDO3 as DVDD supply
- PE14 gpio for reset pin
- PE15 gpio for powerdown pin
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
.../allwinner/sun50i-a64-amarula-relic.dts | 53 +++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index 6cb2b7f0c817..ea6286ce5de3 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -22,6 +22,41 @@
stdout-path = "serial0:115200n8";
};
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = <&pio 4 13 GPIO_ACTIVE_HIGH>; /* CSI-SDA: PE13 */
+ scl-gpios = <&pio 4 12 GPIO_ACTIVE_HIGH>; /* CSI-SCK: PE12 */
+ i2c-gpio,delay-us = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&csi_mclk_pin>;
+ clocks = <&ccu CLK_CSI_MCLK>;
+ clock-names = "xclk";
+
+ AVDD-supply = <®_aldo1>;
+ DOVDD-supply = <®_dldo3>;
+ DVDD-supply = <®_eldo3>;
+ reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */
+ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */
+
+ port {
+ ov5640_ep: endpoint {
+ remote-endpoint = <&csi_ep>;
+ bus-width = <8>;
+ hsync-active = <1>; /* Active high */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+ };
+ };
+
wifi_pwrseq: wifi-pwrseq {
compatible = "mmc-pwrseq-simple";
clocks = <&rtc 1>;
@@ -30,6 +65,24 @@
};
};
+&csi {
+ status = "okay";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi_ep: endpoint {
+ remote-endpoint = <&ov5640_ep>;
+ bus-width = <8>;
+ hsync-active = <1>; /* Active high */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+};
+
&ehci0 {
status = "okay";
};
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v3 5/6] arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1
From: Jagan Teki @ 2018-12-10 11:52 UTC (permalink / raw)
To: Yong Deng, Mauro Carvalho Chehab, Maxime Ripard, Rob Herring,
Mark Rutland, Chen-Yu Tsai, linux-media, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, linux-amarula,
Michael Trimarchi
Cc: Jagan Teki
In-Reply-To: <20181210115246.8188-1-jagan@amarulasolutions.com>
Some camera modules have the SoC feeding a master clock to the sensor
instead of having a standalone crystal. This clock signal is generated
from the clock control unit and output from the CSI MCLK function of
pin PE1.
Add a pinmux setting for it for camera sensors to reference.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 89a0deb3fe6a..dd5740bc3fc9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -538,6 +538,11 @@
function = "csi0";
};
+ csi_mclk_pin: csi-mclk {
+ pins = "PE1";
+ function = "csi0";
+ };
+
i2c0_pins: i2c0_pins {
pins = "PH0", "PH1";
function = "i2c0";
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v3 4/6] arm64: dts: allwinner: a64: Add A64 CSI controller
From: Jagan Teki @ 2018-12-10 11:52 UTC (permalink / raw)
To: Yong Deng, Mauro Carvalho Chehab, Maxime Ripard, Rob Herring,
Mark Rutland, Chen-Yu Tsai, linux-media, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, linux-amarula,
Michael Trimarchi
Cc: Jagan Teki
In-Reply-To: <20181210115246.8188-1-jagan@amarulasolutions.com>
Allwinner A64 CSI controller has similar features as like in
H3, but work by lowering clock than default mod clock.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 384c417cb7a2..89a0deb3fe6a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -532,6 +532,12 @@
interrupt-controller;
#interrupt-cells = <3>;
+ csi_pins: csi-pins {
+ pins = "PE0", "PE2", "PE3", "PE4", "PE5", "PE6",
+ "PE7", "PE8", "PE9", "PE10", "PE11";
+ function = "csi0";
+ };
+
i2c0_pins: i2c0_pins {
pins = "PH0", "PH1";
function = "i2c0";
@@ -899,6 +905,20 @@
status = "disabled";
};
+ csi: csi@1cb0000 {
+ compatible = "allwinner,sun50i-a64-csi";
+ reg = <0x01cb0000 0x1000>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>,
+ <&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&csi_pins>;
+ status = "disabled";
+ };
+
hdmi: hdmi@1ee0000 {
compatible = "allwinner,sun50i-a64-dw-hdmi",
"allwinner,sun8i-a83t-dw-hdmi";
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v3 3/6] media: sun6i: Set 300MHz mod clock for A64
From: Jagan Teki @ 2018-12-10 11:52 UTC (permalink / raw)
To: Yong Deng, Mauro Carvalho Chehab, Maxime Ripard, Rob Herring,
Mark Rutland, Chen-Yu Tsai, linux-media, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, linux-amarula,
Michael Trimarchi
Cc: Jagan Teki
In-Reply-To: <20181210115246.8188-1-jagan@amarulasolutions.com>
The default CSI_SCLK seems unable to drive the sensor to capture
the image, so update it to working clock rate 300MHz for A64.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index bbe45e893722..4b872800b244 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -822,6 +822,11 @@ static int sun6i_csi_resource_request(struct sun6i_csi_dev *sdev,
return PTR_ERR(sdev->clk_mod);
}
+ /* A64 need 300MHz mod clock to operate properly */
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "allwinner,sun50i-a64-csi"))
+ clk_set_rate_exclusive(sdev->clk_mod, 300000000);
+
sdev->clk_ram = devm_clk_get(&pdev->dev, "ram");
if (IS_ERR(sdev->clk_ram)) {
dev_err(&pdev->dev, "Unable to acquire dram-csi clock\n");
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v3 2/6] media: sun6i: Add A64 compatible support
From: Jagan Teki @ 2018-12-10 11:52 UTC (permalink / raw)
To: Yong Deng, Mauro Carvalho Chehab, Maxime Ripard, Rob Herring,
Mark Rutland, Chen-Yu Tsai, linux-media, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, linux-amarula,
Michael Trimarchi
Cc: Jagan Teki
In-Reply-To: <20181210115246.8188-1-jagan@amarulasolutions.com>
Allwinner A64 CSI has single channel time-multiplexed BT.656
CMOS sensor interface like H3 but work by lowering clock than
default mod clock.
So use separate compatibe to support it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index ee882b66a5ea..bbe45e893722 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -892,6 +892,7 @@ static int sun6i_csi_remove(struct platform_device *pdev)
}
static const struct of_device_id sun6i_csi_of_match[] = {
+ { .compatible = "allwinner,sun50i-a64-csi", },
{ .compatible = "allwinner,sun6i-a31-csi", },
{ .compatible = "allwinner,sun8i-h3-csi", },
{ .compatible = "allwinner,sun8i-v3s-csi", },
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v3 1/6] dt-bindings: media: sun6i: Add A64 CSI compatible
From: Jagan Teki @ 2018-12-10 11:52 UTC (permalink / raw)
To: Yong Deng, Mauro Carvalho Chehab, Maxime Ripard, Rob Herring,
Mark Rutland, Chen-Yu Tsai, linux-media, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, linux-amarula,
Michael Trimarchi
Cc: Jagan Teki
In-Reply-To: <20181210115246.8188-1-jagan@amarulasolutions.com>
Allwinner A64 CSI has single channel time-multiplexed BT.656
CMOS sensor interface like H3 but work by lowering clock than
default mod clock.
Add a compatible string for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Documentation/devicetree/bindings/media/sun6i-csi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
index cc37cf7fd051..376aade669a1 100644
--- a/Documentation/devicetree/bindings/media/sun6i-csi.txt
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -7,6 +7,7 @@ Required properties:
- compatible: value must be one of:
* "allwinner,sun6i-a31-csi"
* "allwinner,sun8i-h3-csi"
+ * "allwinner,sun50i-a64-csi"
* "allwinner,sun8i-v3s-csi"
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v3 0/6] media/sun6i: Allwinner A64 CSI support
From: Jagan Teki @ 2018-12-10 11:52 UTC (permalink / raw)
To: Yong Deng, Mauro Carvalho Chehab, Maxime Ripard, Rob Herring,
Mark Rutland, Chen-Yu Tsai, linux-media, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, linux-amarula,
Michael Trimarchi
Cc: Jagan Teki
This series support CSI on Allwinner A64.
Allwinner A64 CSI has single channel time-multiplexed BT.656
CMOS sensor interface like H3 but work by lowering clock than
default mod clock.
Changes for v3:
- update dt-bindings for A64
- set mod clock via csi driver
- remove assign clocks from dtsi
- remove i2c-gpio opendrian
- fix avdd and dovdd supplies
- remove vcc-csi pin group supply
Note: This series created on top of H3 changes [1]
[1] https://patchwork.kernel.org/cover/10705905/
Any inputs,
Jagan.
Jagan Teki (6):
dt-bindings: media: sun6i: Add A64 CSI compatible
media: sun6i: Add A64 compatible support
media: sun6i: Set 300MHz mod clock for A64
arm64: dts: allwinner: a64: Add A64 CSI controller
arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1
arm64: dts: allwinner: a64-amarula-relic: Add OV5640 camera node
.../devicetree/bindings/media/sun6i-csi.txt | 1 +
.../allwinner/sun50i-a64-amarula-relic.dts | 53 +++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 25 +++++++++
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 6 +++
4 files changed, 85 insertions(+)
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 00/10] arm64: assembly export cleanup
From: Will Deacon @ 2018-12-10 11:50 UTC (permalink / raw)
To: Mark Rutland; +Cc: catalin.marinas, linux-arm-kernel
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
On Fri, Dec 07, 2018 at 06:08:13PM +0000, Mark Rutland wrote:
> When exporting a C function, we place the EXPORT_SYMBOL() immediately after the
> function definition. Historically we couldn't do this with assembly functions,
> and hence we collected all of these exports in arm64ksyms.c. Over time, this
> has retained redundant includes and exports for items defined in C code.
>
> For a while now it has been possible to export functions directly from assembly
> files, which is beneficial for ongoing maintenance.
>
> These patches move the exports from arm64ksyms.c into their relevant assembly
> files, and remove the newly redundant arm64ksyms.c. I've pushed the series to
> my arm64/export-cleanup branch [1] on kernel.org.
Cheers, I've picked this up.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 7/8] arm64: KVM: Handle ARM erratum 1165522 in TLB invalidation
From: Christoffer Dall @ 2018-12-10 11:50 UTC (permalink / raw)
To: James Morse
Cc: Mark Rutland, kvm, Suzuki K Poulose, Marc Zyngier,
Catalin Marinas, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <c71d902b-c748-770a-5e6e-f33a204dcb8d@arm.com>
On Mon, Dec 10, 2018 at 11:15:00AM +0000, James Morse wrote:
> Hi Marc, Christoffer,
>
> On 10/12/2018 10:46, Marc Zyngier wrote:
> > On 10/12/2018 10:19, Christoffer Dall wrote:
> >> On Thu, Dec 06, 2018 at 05:31:25PM +0000, Marc Zyngier wrote:
> >>> In order to avoid TLB corruption whilst invalidating TLBs on CPUs
> >>> affected by erratum 1165522, we need to prevent S1 page tables
> >>> from being usable.
> >>>
> >>> For this, we set the EL1 S1 MMU on, and also disable the page table
> >>> walker (by setting the TCR_EL1.EPD* bits to 1).
> >>>
> >>> This ensures that once we switch to the EL1/EL0 translation regime,
> >>> speculated AT instructions won't be able to parse the page tables.
>
> >>> @@ -64,11 +93,18 @@ static void __hyp_text __tlb_switch_to_host_vhe(struct kvm *kvm,
> >>> write_sysreg(0, vttbr_el2);
> >>> write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
> >>> isb();
> >>> - local_irq_restore(flags);
> >>> +
> >>> + if (cpus_have_const_cap(ARM64_WORKAROUND_1165522)) {
> >>> + /* Restore the guest's registers to what they were */
> >>
> >> host's ?
> >
> > Hum... Yes, silly thinko.
>
> I thought these were the guests registers because they are EL1 registers and
> this is a VHE-only path.
> 'interrupted guest' was how I read this. This stuff can get called if memory is
> allocated for guest-A while a vcpu is loaded, and reclaims memory from guest-B
> causing an mmu-notifier call for stage2. This is why we have to put guest-A's
> registers back as we weren't pre-empted, and we expect EL1 to be untouched.
>
> I agree they could belong to no-guest if a vcpu isn't loaded at all... is host
> the term used here?
>
Ah, you're right. Host is not the right term either.
I haven't done the call path analysis, so not sure about all the
possible contexts where all this can be called, but if it's really truly
only in guest context, then we don't need to save the values to a
temporary struct at all, but can save them on the vcpu.
We can also just side-step the whole thing and just say "Restore the
registers to what they were".
Thanks,
Christoffer
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: TK1: DRM, Nouveau and VIC
From: Dmitry Osipenko @ 2018-12-10 11:46 UTC (permalink / raw)
To: Thierry Reding, Marcel Ziswiler, Ben Skeggs
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
mperttunen@nvidia.com, linux-tegra@vger.kernel.org,
jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210102147.GF15154@ulmo>
On 10.12.2018 13:21, Thierry Reding wrote:
> On Sat, Dec 08, 2018 at 02:54:45PM +0000, Marcel Ziswiler wrote:
>> Hi Thierry et al.
>>
>> I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
>> Tegra124") graphics on Apalis TK1 is broken. During boot it fails
>> loading the vic firmware:
>>
>> [ 1.595824] tegra-vic 54340000.vic: Direct firmware load for
>> nvidia/tegra124/vic03_ucode.bin failed with error -2
>> [ 1.606140] tegra-vic: probe of 54340000.vic failed with error -2
>>
>> Subsequently Tegra HDMI seems to fail completely:
>>
>> [ 2.379860] tegra-hdmi 54280000.hdmi: failed to get PLL regulator
>>
>> And finally, Nouveau even crashes:
>>
>> [ 8.241115] nouveau 57000000.gpu: Linked as a consumer to
>> regulator.31
>> [ 8.247889] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1)
>> [ 8.253396] nouveau 57000000.gpu: imem: using IOMMU
>> [ 8.270210] Unable to handle kernel NULL pointer dereference at
>> virtual address 0000006c
>> [ 8.278340] pgd = (ptrval)
>> [ 8.281250] [0000006c] *pgd=00000000
>> [ 8.284944] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>> [ 8.290260] Modules linked in: nouveau(+) ttm
>> [ 8.294625] CPU: 2 PID: 203 Comm: systemd-udevd Not tainted 4.20.0-
>> rc5-next-20181207-00008-g85b0f8e25f86-dirty #110
>> [ 8.305055] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
>> [ 8.311331] PC is at drm_plane_register_all+0x18/0x50
>> [ 8.316373] LR is at drm_modeset_register_all+0xc/0x70
>> [ 8.321513] pc : [<c056200c>] lr : [<c0564cc8>] psr: a0060013
>> [ 8.327768] sp : ed527c70 ip : ecc43ec0 fp : 00000000
>> [ 8.332993] r10: 00000016 r9 : ecc43e80 r8 : 00000000
>> [ 8.338209] r7 : bf182c80 r6 : 00000000 r5 : ed61b24c r4 :
>> fffffffc
>> [ 8.344735] r3 : 0002f000 r2 : ffffffff r1 : 2e124000 r0 :
>> ed61b000
>> [ 8.351260] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA
>> ARM Segment none
>> [ 8.358383] Control: 10c5387d Table: ad64c06a DAC: 00000051
>> [ 8.364127] Process systemd-udevd (pid: 203, stack limit =
>> 0x(ptrval))
>> [ 8.370654] Stack: (0xed527c70 to 0xed528000)
>> [ 8.375004] 7c60: ed61b000
>> ed61b000 00000000 c0564cc8
>> [ 8.383177] 7c80: ed61b000 00000000 00000000 c054b5b8 00000001
>> 00000001 ffffffff ffffffff
>> [ 8.391355] 7ca0: ed527cc0 c0f08c48 ed61b000 00000000 00000000
>> 00000000 bf180c5c bf0dc900
>> [ 8.399531] 7cc0: eda29208 5dfe844b 00000000 ee9f2a10 00000000
>> bf180c5c 00000000 c05a9328
>> [ 8.407695] 7ce0: c1006828 ee9f2a10 c100682c 00000000 00000000
>> c05a744c ee9f2a10 bf180c5c
>> [ 8.415871] 7d00: ee9f2a44 c05a77a8 00000000 c0f08c48 bf182980
>> c05a769c eefd14d0 c05a77a8
>> [ 8.424048] 7d20: 00000000 ee9f2a10 bf180c5c ee9f2a44 c05a77a8
>> 00000000 c0f08c48 bf182980
>> [ 8.432226] 7d40: 00000000 c05a7884 ee9ebfb4 c0f08c48 bf180c5c
>> c05a5790 00000000 ee88135c
>> [ 8.440405] 7d60: ee9ebfb4 5dfe844b c0f71168 bf180c5c ee379e80
>> c0f71168 00000000 c05a692c
>> [ 8.448570] 7d80: bf15dc00 bf180ac8 ffffe000 bf180c5c bf180ac8
>> ffffe000 bf1aa000 c05a84a0
>> [ 8.456746] 7da0: bf182b80 bf180ac8 ffffe000 bf1aa170 c0fbd220
>> c0f08c48 ffffe000 c0102ed0
>> [ 8.464924] 7dc0: ed53f4c0 006000c0 c01b3d98 0000000c 60000113
>> bf182980 00000040 c02592d0
>> [ 8.473102] 7de0: eda60200 2e124000 ee800000 006000c0 006000c0
>> c01b3d98 0000000c c025a8cc
>> [ 8.481281] 7e00: c024ce54 a0000113 bf182980 5dfe844b bf182980
>> 00000002 ed53f4c0 00000002
>> [ 8.489459] 7e20: eceba000 c01b3dd4 c0f08c48 bf182980 00000000
>> ed527f40 00000002 eceb9fc0
>> [ 8.497625] 7e40: 00000002 c01b61a4 bf18298c 00007fff bf182980
>> c01b2f88 00000000 c01b279c
>> [ 8.505800] 7e60: bf1829c8 bf182a80 bf182b6c bf182ab0 c0b03ab0
>> c0d58964 c0ca726c c0ca7278
>> [ 8.513978] 7e80: c0ca72d0 c0f08c48 00000000 c02654a0 00000000
>> 00000000 ffffe000 bf000000
>> [ 8.522157] 7ea0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 6e72656b 00006c65
>> [ 8.530336] 7ec0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [ 8.538502] 7ee0: 00000000 00000000 00000000 00000000 00000000
>> 5dfe844b 7fffffff c0f08c48
>> [ 8.546677] 7f00: 00000000 0000000f b6f761cc c0101204 ed526000
>> 0000017b 004a3270 c01b66a4
>> [ 8.554855] 7f20: 7fffffff 00000000 00000003 00000001 004a3270
>> f0ced000 06e8994c 00000000
>> [ 8.563032] 7f40: f0e37f3a f0e50a40 f0ced000 06e8994c f7b75f9c
>> f7b75d34 f63e62dc 0016b000
>> [ 8.571209] 7f60: 0017f6f0 00000000 00000000 00000000 00050a48
>> 0000003b 0000003c 00000023
>> [ 8.579388] 7f80: 00000000 00000014 00000000 5dfe844b 00000000
>> 004c0ec0 00000000 00000001
>> [ 8.587554] 7fa0: 0000017b c0101000 004c0ec0 00000000 0000000f
>> b6f761cc 00000000 00020000
>> [ 8.595730] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
>> 00000000 00000000 004a3270
>> [ 8.603908] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0 400d0010
>> 0000000f 00000000 00000000
>> [ 8.612096] [<c056200c>] (drm_plane_register_all) from [<c0564cc8>]
>> (drm_modeset_register_all+0xc/0x70)
>> [ 8.621499] [<c0564cc8>] (drm_modeset_register_all) from
>> [<c054b5b8>] (drm_dev_register+0x168/0x1c4)
>> [ 8.630855] [<c054b5b8>] (drm_dev_register) from [<bf0dc900>]
>> (nouveau_platform_probe+0x6c/0x88 [nouveau])
>> [ 8.640739] [<bf0dc900>] (nouveau_platform_probe [nouveau]) from
>> [<c05a9328>] (platform_drv_probe+0x48/0x98)
>> [ 8.650574] [<c05a9328>] (platform_drv_probe) from [<c05a744c>]
>> (really_probe+0x1e0/0x2cc)
>> [ 8.658827] [<c05a744c>] (really_probe) from [<c05a769c>]
>> (driver_probe_device+0x60/0x16c)
>> [ 8.667096] [<c05a769c>] (driver_probe_device) from [<c05a7884>]
>> (__driver_attach+0xdc/0xe0)
>> [ 8.675543] [<c05a7884>] (__driver_attach) from [<c05a5790>]
>> (bus_for_each_dev+0x74/0xb4)
>> [ 8.683729] [<c05a5790>] (bus_for_each_dev) from [<c05a692c>]
>> (bus_add_driver+0x1c0/0x204)
>> [ 8.692004] [<c05a692c>] (bus_add_driver) from [<c05a84a0>]
>> (driver_register+0x74/0x108)
>> [ 8.700324] [<c05a84a0>] (driver_register) from [<bf1aa170>]
>> (nouveau_drm_init+0x170/0x1000 [nouveau])
>> [ 8.709857] [<bf1aa170>] (nouveau_drm_init [nouveau]) from
>> [<c0102ed0>] (do_one_initcall+0x54/0x284)
>> [ 8.718980] [<c0102ed0>] (do_one_initcall) from [<c01b3dd4>]
>> (do_init_module+0x64/0x214)
>> [ 8.727079] [<c01b3dd4>] (do_init_module) from [<c01b61a4>]
>> (load_module+0x21b8/0x246c)
>> [ 8.735094] [<c01b61a4>] (load_module) from [<c01b66a4>]
>> (sys_finit_module+0xc4/0xdc)
>> [ 8.742937] [<c01b66a4>] (sys_finit_module) from [<c0101000>]
>> (ret_fast_syscall+0x0/0x54)
>> [ 8.751114] Exception stack(0xed527fa8 to 0xed527ff0)
>> [ 8.756157] 7fa0: 004c0ec0 00000000 0000000f
>> b6f761cc 00000000 00020000
>> [ 8.764333] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
>> 00000000 00000000 004a3270
>> [ 8.772510] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0
>> [ 8.777556] Code: e5b5424c e1550004 0a00000c e2444004 (e5943070)
>> [ 8.784011] ---[ end trace ad8c21587c118655 ]---
>>
>> Of course my root file system does include resp. vic firmware:
>>
>> 7ef01d2e3f507c91ca79584e89edcc64 /lib/firmware/nvidia/tegra124/vic03_u
>> code.bin
>>
>> If I bake that one into the kernel binary, Nouveau still crashes like
>> above albeit VIC loading and Tegra DRM now at least showing something
>> on HDMI.
>
> Yeah, this is a fairly common pitfall. The general rule of thumb is that
> the firmware has to live on the same medium as the module. So if you've
> built Tegra DRM as a loadable kernel module and installed it in the root
> filesystem, then that's where your firmware file also needs to be. If
> the driver is built-in (or a loadable module installed in the initial
> ramdisk), then the firmware needs to be in the initial ramdisk (or built
> into the kernel image itself). That's somewhat annoying, but it is what
> it is. At least it's logical.
It's not very logical in a sense that display driver doesn't load because of firmware that it doesn't need at all. Deferring firmware load until it is really needed should be the most reasonable approach, please let me make an RFC.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] mmc: mediatek: Add MMC_CAP_SDIO_IRQ support
From: Jjian Zhou @ 2018-12-10 11:43 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-arm-kernel, Ryder Lee, srv_heupstream, Sean Wang, linux-mmc,
linux-kernel, Yong Mao, linux-mediatek, Chaotian Jing,
Matthias Brugger, jjian zhou
From: jjian zhou <jjian.zhou@mediatek.com>
This patch enables support SDIO IRQs. It enables
MMC_CAP_SDIO_IRQ & MMC_CAP2_SDIO_IRQ_NOTHREAD
and implement the ->ack_sdio_irq callback.
Signed-off-by: Jjian Zhou <jjian.zhou@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
---
drivers/mmc/host/mtk-sd.c | 49 ++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 6334cc7..40a1848 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1114,6 +1114,7 @@ static void msdc_start_command(struct msdc_host *host,
struct mmc_request *mrq, struct mmc_command *cmd)
{
u32 rawcmd;
+ unsigned long flags;
WARN_ON(host->cmd);
host->cmd = cmd;
@@ -1131,7 +1132,10 @@ static void msdc_start_command(struct msdc_host *host,
cmd->error = 0;
rawcmd = msdc_cmd_prepare_raw_cmd(host, mrq, cmd);
+ spin_lock_irqsave(&host->lock, flags);
sdr_set_bits(host->base + MSDC_INTEN, cmd_ints_mask);
+ spin_unlock_irqrestore(&host->lock, flags);
+
writel(cmd->arg, host->base + SDC_ARG);
writel(rawcmd, host->base + SDC_CMD);
}
@@ -1351,6 +1355,27 @@ static void msdc_request_timeout(struct work_struct *work)
}
}
+static void msdc_enable_sdio_irq(struct mmc_host *mmc, int enb)
+{
+ unsigned long flags;
+ struct msdc_host *host = mmc_priv(mmc);
+
+ if (enb)
+ pm_runtime_get_sync(host->dev);
+
+ spin_lock_irqsave(&host->lock, flags);
+ if (enb)
+ sdr_set_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
+ else
+ sdr_clr_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
+ spin_unlock_irqrestore(&host->lock, flags);
+
+ if (!enb) {
+ pm_runtime_mark_last_busy(host->dev);
+ pm_runtime_put_autosuspend(host->dev);
+ }
+}
+
static irqreturn_t msdc_irq(int irq, void *dev_id)
{
struct msdc_host *host = (struct msdc_host *) dev_id;
@@ -1373,7 +1398,12 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
data = host->data;
spin_unlock_irqrestore(&host->lock, flags);
- if (!(events & event_mask))
+ if ((events & event_mask) & MSDC_INT_SDIOIRQ) {
+ msdc_enable_sdio_irq(host->mmc, 0);
+ sdio_signal_irq(host->mmc);
+ }
+
+ if (!(events & (event_mask & ~MSDC_INT_SDIOIRQ)))
break;
if (!mrq) {
@@ -1493,8 +1523,11 @@ static void msdc_init_hw(struct msdc_host *host)
*/
sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIO);
- /* disable detect SDIO device interrupt function */
- sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
+ /* Config SDIO device detect interrupt function */
+ if (host->mmc->caps & MMC_CAP_SDIO_IRQ)
+ sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
+ else
+ sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
/* Configure to default data timeout */
sdr_set_field(host->base + SDC_CFG, SDC_CFG_DTOC, 3);
@@ -2013,6 +2046,11 @@ static void msdc_hw_reset(struct mmc_host *mmc)
sdr_clr_bits(host->base + EMMC_IOCON, 1);
}
+static void msdc_ack_sdio_irq(struct mmc_host *mmc)
+{
+ msdc_enable_sdio_irq(mmc, 1);
+}
+
static const struct mmc_host_ops mt_msdc_ops = {
.post_req = msdc_post_req,
.pre_req = msdc_pre_req,
@@ -2020,6 +2058,8 @@ static void msdc_hw_reset(struct mmc_host *mmc)
.set_ios = msdc_ops_set_ios,
.get_ro = mmc_gpio_get_ro,
.get_cd = mmc_gpio_get_cd,
+ .enable_sdio_irq = msdc_enable_sdio_irq,
+ .ack_sdio_irq = msdc_ack_sdio_irq,
.start_signal_voltage_switch = msdc_ops_switch_volt,
.card_busy = msdc_card_busy,
.execute_tuning = msdc_execute_tuning,
@@ -2147,6 +2187,9 @@ static int msdc_drv_probe(struct platform_device *pdev)
else
mmc->f_min = DIV_ROUND_UP(host->src_clk_freq, 4 * 4095);
+ if (mmc->caps & MMC_CAP_SDIO_IRQ)
+ mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;
+
mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
/* MMC core transfer sizes tunable parameters */
mmc->max_segs = MAX_BD_NUM;
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 4/4] ARM: dts: imx7d: sbc imx7: add uart5
From: Fabio Estevam @ 2018-12-10 11:43 UTC (permalink / raw)
To: hohatzel
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
jscheel, NXP Linux Team, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <58a84012-73b8-1679-0c5b-981fd2a0acd6@jusst.de>
Hi Hans,
On Mon, Dec 10, 2018 at 8:52 AM Hans Ole Hatzel <hohatzel@jusst.de> wrote:
> imx7d-pico.dts does this the same way. Is that good enough of a reason?
> If so, should it be included in the commit message?
The UART clock parent initialization has been removed from the imx7d
clock driver since commit (in linux-next):
commit ea662d2f804ad13c3c92c75c7dc1abad30e31c31
Author: Anson Huang <anson.huang@nxp.com>
Date: Fri Oct 19 01:05:36 2018 +0000
clk: imx7d: remove UART1 clock setting
There are clock assignments in all i.MX7D dtb files for UART1,
below is the example in imx7d-sdb.dts, so setting UART1 clock
in clock driver is NOT necessary, actually, module clocks setting
should be done in module driver.
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
assigned-clocks = <&clks IMX7D_UART1_ROOT_SRC>;
assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
status = "okay";
};
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
So the UART clock parent should be set in the device tree.
_______________________________________________
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 00/12] arm64: Paravirtualized time support
From: Mark Rutland @ 2018-12-10 11:40 UTC (permalink / raw)
To: Steven Price
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, Christoffer Dall,
kvmarm, linux-arm-kernel
In-Reply-To: <20181128144527.44710-1-steven.price@arm.com>
On Wed, Nov 28, 2018 at 02:45:15PM +0000, Steven Price wrote:
> This series add support for paravirtualized time for Arm64 guests and
> KVM hosts following the specification in Arm's document DEN 0057A:
>
> https://developer.arm.com/docs/den0057/a
>
> It implements support for Live Physical Time (LPT) which provides the
> guest with a method to derive a stable counter of time during which the
> guest is executing even when the guest is being migrated between hosts
> with different physical counter frequencies.
>
> It also implements support for stolen time, allowing the guest to
> identify time when it is forcibly not executing.
I know that stolen time reporting is important, and I think that we
definitely want to pick up that part of the spec (once it is published
in some non-draft form).
However, I am very concerned with the pv-freq part of LPT, and I'd like
to avoid that if at all possible. I say that because:
* By design, it breaks architectural guarantees from the PoV of SW in
the guest.
A VM may host multiple SW agents serially (e.g. when booting, or
across kexec), or concurrently (e.g. Linux w/ EFI runtime services),
and the host has no way to tell whether all software in the guest will
function correctly. Due to this, it's not possible to have a guest
opt-in to the architecturally-broken timekeeping.
Existing guests will not work correctly once pv-freq is in use, and if
configured without pv-freq (or if the guest fails to discover pv-freq
for any reason), the administrator may encounter anything between
subtle breakage or fatally incorrect timekeeping.
There's plenty of SW agents other than Linux which runs in a guest,
which would need to be updated to handle pv-freq, e.g. GRUB, *BSD,
iPXE.
Given this, I think that this is going to lead to subtle breakage in
real-world scenarios.
* It is (necessarily) invasive to the low-level arch timer code. This is
unfortunate, and I strongly suspect this is going to be an area with
long-term subtle breakage.
* It's not clear to me how strongly people need this. My understanding
is that datacenters would run largely homogeneous platforms. I suspect
large datacenters which would use migration are in a position to
mandate a standard timer frequency from their OEMs or SiPs.
I strongly believe that an architectural fix (e.g. in-hw scaling)
would be the better solution.
I understand that LPT is supposed to account for time lost during the
migration. Can we account for this without pv-freq? e.g. is it possible
to account for this in the same way as stolen time?
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: marvell: mcbin: fix PCIe reset signal
From: Baruch Siach @ 2018-12-10 11:38 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Russell King
Cc: Baruch Siach, linux-arm-kernel
The MPP52 signal is on the seconds GPIO instance of CP0, which
corresponds to the &cp0_gpio2 handle.
Rename the property name to the standard '-gpios' suffix while at it.
Fixes: b83e1669adce6 ("arm64: dts: marvell: mcbin: add support for PCIe")
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index 56fa44860909..46dacfc08cec 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -183,7 +183,7 @@
pinctrl-0 = <&cp0_pcie_pins>;
num-lanes = <4>;
num-viewport = <8>;
- reset-gpio = <&cp0_gpio1 20 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&cp0_gpio2 20 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v7 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: Boris Brezillon @ 2018-12-10 11:38 UTC (permalink / raw)
To: Liang Yang
Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, Richard Weinberger, Yixun Lan, linux-kernel,
Marek Vasut, Jian Hu, linux-mtd, Kevin Hilman, Miquel Raynal,
Carlo Caione, linux-amlogic, Brian Norris, David Woodhouse,
linux-arm-kernel, Jerome Brunet
In-Reply-To: <823825a3-86fb-9a20-ae29-85cc52d44093@amlogic.com>
On Mon, 10 Dec 2018 19:23:46 +0800
Liang Yang <liang.yang@amlogic.com> wrote:
> >> + mtd->ecc_stats.failed++;
> >> + continue;
> >> + }
> >> + mtd->ecc_stats.corrected += ECC_ERR_CNT(*info);
> >> + bitflips = max_t(u32, bitflips, ECC_ERR_CNT(*info));
> >> + }
> >
> > Are you sure you handle correctly empty pages with bf?
> >
> if scramble is enable, i would say yes here.
> when scramble is disabled, i am considering how to use the helper
> nand_check_erased_ecc_chunk, but it seems that i can't get the ecc
> bytes which is caculated by ecc engine.by the way, nfc dma doesn't send
> out the ecc parity bytes.
Even if the ECC engine is disabled?
> so i would suggest using scramble.
>
No, please don't force people to use the scrambler.
> >> +
> >> +const void *
> >> +meson_nand_op_get_dma_safe_output_buf(const struct nand_op_instr *instr)
> >> +{
> >> + if (WARN_ON(instr->type != NAND_OP_DATA_OUT_INSTR))
> >> + return NULL;
> >> +
> >> + if (virt_addr_valid(instr->ctx.data.buf.out) &&
> >> + !object_is_on_stack(instr->ctx.data.buf.out))
> >
> > Can you please create helpers for that? I guess it will help removing
> > these checks once the core will have a DMA-safe approach.
> >
> I will use below definition:
> #define BUFFER_IS_DMA_SAFE(x) \
> (virt_addr_valid((x)) && (!object_is_on_stack((x))))
>
> Is it ok?
Please define a function, not a macro.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: defconfig: Switch LPC18xx to use PL11x DRM driver
From: Linus Walleij @ 2018-12-10 11:37 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: Linux ARM
In-Reply-To: <3c2118a6-b729-b809-654b-717048f56cc9@mleia.com>
On Mon, Dec 10, 2018 at 12:23 PM Vladimir Zapolskiy <vz@mleia.com> wrote:
> FWIW I've tested DRM PL111 driver on my board, if you are interested
> the pending DT patch is https://patchwork.kernel.org/patch/10636591/
Looks good.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Thank you for the changes, I'll review and collect them for v4.22.
OK feel free to use however you like or use your own patches,
all I really want is the PL11x DRM driver to become default
for all platforms using PL11x.
Will send LPC32xx patches next. Same thing there, use it
if you like, all I worry about is the end result :)
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] cpuidle: big.LITTLE: add of_node_put()
From: Rafael J. Wysocki @ 2018-12-10 11:31 UTC (permalink / raw)
To: Frank Lee
Cc: lorenzo.pieralisi, Daniel Lezcano, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <CAEExFWtiqTgQmMLwvMhx8UvfU9o75jsZkAjBgyHhAOwuemJdNw@mail.gmail.com>
On Sunday, December 9, 2018 7:20:26 AM CET Frank Lee wrote:
> On Wed, Nov 21, 2018 at 12:14 AM Yangtao Li <tiny.windzz@gmail.com> wrote:
> >
> > of_find_node_by_path() acquires a reference to the node
> > returned by it and that reference needs to be dropped by its caller.
> > bl_idle_init() doesn't do that, so fix it.
> >
> > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > ---
> > Changes in v3:
> > -update changelog
> > ---
> > drivers/cpuidle/cpuidle-big_little.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
> > index db2ede565f1a..650f063ef809 100644
> > --- a/drivers/cpuidle/cpuidle-big_little.c
> > +++ b/drivers/cpuidle/cpuidle-big_little.c
> > @@ -174,8 +174,12 @@ static int __init bl_idle_init(void)
> > /*
> > * Initialize the driver just for a compliant set of machines
> > */
> > - if (!of_match_node(compatible_machine_match, root))
> > + if (!of_match_node(compatible_machine_match, root)){
> > + of_node_put(root);
> > return -ENODEV;
> > + }
> > +
> > + of_node_put(root);
> >
> > if (!mcpm_is_available())
> > return -EUNATCH;
> > --
> > 2.17.0
> >
> ping......
I've been waiting for the maintainers of this driver to speak up.
I'll pick up the patch later today or tomorrow unless there are objections.
Thanks,
Rafael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v5 3/7] mtd: spi-nor: add opcodes for octal Read/Write commands
From: Yogesh Narayan Gaur @ 2018-12-10 11:28 UTC (permalink / raw)
To: Boris Brezillon
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, vigneshr@ti.com,
robh@kernel.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, marek.vasut@gmail.com,
frieder.schrempf@exceet.de, broonie@kernel.org,
linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210122707.3416095c@bbrezillon>
Hi,
> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Monday, December 10, 2018 4:57 PM
> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
> Cc: linux-mtd@lists.infradead.org; broonie@kernel.org;
> marek.vasut@gmail.com; vigneshr@ti.com; linux-spi@vger.kernel.org;
> devicetree@vger.kernel.org; robh@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; linux-arm-kernel@lists.infradead.org;
> computersforpeace@gmail.com; frieder.schrempf@exceet.de; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH v5 3/7] mtd: spi-nor: add opcodes for octal Read/Write
> commands
>
> On Mon, 10 Dec 2018 11:17:20 +0000
> Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
>
> > Hi Boris,
> >
> > > -----Original Message-----
> > > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> > > Sent: Monday, December 10, 2018 4:27 PM
> > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
> > > Cc: linux-mtd@lists.infradead.org; broonie@kernel.org;
> > > marek.vasut@gmail.com; vigneshr@ti.com; linux-spi@vger.kernel.org;
> > > devicetree@vger.kernel.org; robh@kernel.org; mark.rutland@arm.com;
> > > shawnguo@kernel.org; linux-arm-kernel@lists.infradead.org;
> > > computersforpeace@gmail.com; frieder.schrempf@exceet.de; linux-
> > > kernel@vger.kernel.org
> > > Subject: Re: [PATCH v5 3/7] mtd: spi-nor: add opcodes for octal
> > > Read/Write commands
> > >
> > > On Mon, 3 Dec 2018 08:39:18 +0000
> > > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> > >
> > > > - Add opcodes for octal I/O commands
> > > > * Read : 1-1-8 and 1-8-8 protocol
> > > > * Write : 1-1-8 and 1-8-8 protocol
> > > > * opcodes for 4-byte address mode command
> > > >
> > > > - Entry of macros in _convert_3to4_xxx function
> > > >
> > > > - Add flag specifying flash support octal read commands.
> > > >
> > > > Signed-off-by: Vignesh R <vigneshr@ti.com>
> > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> > >
> > > Looks like the SoB and Author lines do not match
> > >
> > > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> vs Yogesh Gaur
> > > <yogeshnarayan.gaur@nxp.com>
> > >
> > > Can you find a way to make them match?
> > I am sending the patches with my smtp server of OutlookOffice and in that my
> user name is "Yogesh Narayan Gaur" and in gitconfig of my Linux machine I set
> user name as "Yogesh Gaur".
> > Is it mandatory to have same Author name in SoB and Author lines, if yes I
> would change the settings in gitconfig file.
>
> We have scripts that check that the author/committer has its SoB, depending on
> how strict the check is, it might complaint that SoB an author/committer do not
> match, so yes, please change gitconfig to make them match.
>
Ok, sure. In all other future patches would modify my Author name.
> Thanks,
>
> Boris
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
From: Boris Brezillon @ 2018-12-10 11:28 UTC (permalink / raw)
To: Vignesh R
Cc: devicetree, Yogesh Gaur, linux-kernel, Marek Vasut, Rob Herring,
linux-mtd, Brian Norris, Linux ARM Mailing List
In-Reply-To: <f6c3a649-f580-513d-644d-5010b3b5cf0b@ti.com>
On Mon, 10 Dec 2018 16:49:29 +0530
Vignesh R <vigneshr@ti.com> wrote:
> On 10/12/18 2:15 PM, Boris Brezillon wrote:
> > On Wed, 3 Oct 2018 22:26:03 +0530
> > Vignesh R <vigneshr@ti.com> wrote:
> >
> >> Cadence OSPI controller IP supports Octal IO (x8 IO lines),
> >> It also has an integrated PHY. IP register layout is very
> >> similar to existing QSPI IP except for additional bits to support Octal
> >> and Octal DDR mode. Therefore, extend current driver to support Octal
> >> mode.
> >>
> >> Signed-off-by: Vignesh R <vigneshr@ti.com>
> >> ---
> >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
> >> index e24db817154e..48b00e75a879 100644
> >> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> >> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> >> @@ -101,6 +101,7 @@ struct cqspi_st {
> >> #define CQSPI_INST_TYPE_SINGLE 0
> >> #define CQSPI_INST_TYPE_DUAL 1
> >> #define CQSPI_INST_TYPE_QUAD 2
> >> +#define CQSPI_INST_TYPE_OCTAL 3
> >>
> >> #define CQSPI_DUMMY_CLKS_PER_BYTE 8
> >> #define CQSPI_DUMMY_BYTES_MAX 4
> >> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read)
> >> case SNOR_PROTO_1_1_4:
> >> f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
> >> break;
> >> + case SNOR_PROTO_1_1_8:
> >> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
> >> + break;
> >> default:
> >> return -EINVAL;
> >> }
> >> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
> >> SNOR_HWCAPS_READ_FAST |
> >> SNOR_HWCAPS_READ_1_1_2 |
> >> SNOR_HWCAPS_READ_1_1_4 |
> >> + SNOR_HWCAPS_READ_1_1_8 |
> >
> > Is this really supported on qspi versions of this IP? I guess not given
> > the description in the commit message and the name of the new
> > compatible (ospi instead of qspi).
>
> No, qspi version does not support Octal mode. I guess you are pointing
> out its logically wrong for driver with "*-qspi" compatible to declare
> SNOR_HWCAPS_READ_1_1_8 capability.
Exactly.
> Will update patch to declare SNOR_HWCAPS_READ_1_1_8 based on compatible.
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 3/7] mtd: spi-nor: add opcodes for octal Read/Write commands
From: Boris Brezillon @ 2018-12-10 11:27 UTC (permalink / raw)
To: Yogesh Narayan Gaur
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, vigneshr@ti.com,
robh@kernel.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, marek.vasut@gmail.com,
frieder.schrempf@exceet.de, broonie@kernel.org,
linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB5726164D7E52B013FF2F135B99A50@VI1PR04MB5726.eurprd04.prod.outlook.com>
On Mon, 10 Dec 2018 11:17:20 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> Hi Boris,
>
> > -----Original Message-----
> > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> > Sent: Monday, December 10, 2018 4:27 PM
> > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
> > Cc: linux-mtd@lists.infradead.org; broonie@kernel.org;
> > marek.vasut@gmail.com; vigneshr@ti.com; linux-spi@vger.kernel.org;
> > devicetree@vger.kernel.org; robh@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; linux-arm-kernel@lists.infradead.org;
> > computersforpeace@gmail.com; frieder.schrempf@exceet.de; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [PATCH v5 3/7] mtd: spi-nor: add opcodes for octal Read/Write
> > commands
> >
> > On Mon, 3 Dec 2018 08:39:18 +0000
> > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> >
> > > - Add opcodes for octal I/O commands
> > > * Read : 1-1-8 and 1-8-8 protocol
> > > * Write : 1-1-8 and 1-8-8 protocol
> > > * opcodes for 4-byte address mode command
> > >
> > > - Entry of macros in _convert_3to4_xxx function
> > >
> > > - Add flag specifying flash support octal read commands.
> > >
> > > Signed-off-by: Vignesh R <vigneshr@ti.com>
> > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> >
> > Looks like the SoB and Author lines do not match
> >
> > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> vs Yogesh Gaur
> > <yogeshnarayan.gaur@nxp.com>
> >
> > Can you find a way to make them match?
> I am sending the patches with my smtp server of OutlookOffice and in that my user name is "Yogesh Narayan Gaur" and in gitconfig of my Linux machine I set user name as "Yogesh Gaur".
> Is it mandatory to have same Author name in SoB and Author lines, if yes I would change the settings in gitconfig file.
We have scripts that check that the author/committer has its SoB,
depending on how strict the check is, it might complaint that SoB an
author/committer do not match, so yes, please change gitconfig to make
them match.
Thanks,
Boris
_______________________________________________
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