* [PATCH] arm: sun4i: Add support for Pengpod 1000 tablet
From: Bob Ham @ 2018-06-01 17:55 UTC (permalink / raw)
To: linux-arm-kernel
This is initial support for the Pengpod 1000 tablet. The display is
not currently working but the UART, SD card and USB all work fine.
Signed-off-by: Bob Ham <rah@settrans.net>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts | 232 +++++++++++++++++++++++++++
2 files changed, 233 insertions(+)
create mode 100644 arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ade7a38543dc..e6e93e7ffc8b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -893,6 +893,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb \
sun4i-a10-pcduino2.dtb \
+ sun4i-a10-pengpod-1000.dtb \
sun4i-a10-pov-protab2-ips9.dtb
dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-auxtek-t003.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
new file mode 100644
index 000000000000..94560400114d
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
@@ -0,0 +1,232 @@
+/*
+ * Copyright 2015 Hans de Goede <hdegoede@redhat.com>
+ * Copyright 2017 Robert Ham <rah@settrans.net>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "PengPod 1000";
+ compatible = "pengpod,1000", "allwinner,sun4i-a10";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bl_en_pin_pengpod1000>;
+ pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&codec {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic at 34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+ status = "okay";
+
+ mma7660: accelerometer at 4c {
+ compatible = "fsl,mma7660";
+ reg = <0x4c>;
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ ft5406ee8: touchscreen at 38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&touchscreen_pins>;
+ reset-gpios = <&pio 1 13 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <600>;
+ touchscreen-swapped-x-y;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+ status = "okay";
+};
+
+&pio {
+ bl_en_pin_pengpod1000: bl_en_pin at 0 {
+ pins = "PH7";
+ function = "gpio_out";
+ };
+
+ touchscreen_pins: touchscreen_pins at 0 {
+ pins = "PB13";
+ function = "gpio_out";
+ };
+
+ usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+ pins = "PH4";
+ function = "gpio_in";
+ bias-pull-up;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
+ pins = "PH5";
+ function = "gpio_in";
+ bias-pull-down;
+ };
+};
+
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1250000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_usb0_vbus {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+®_usb2_vbus {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+ usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ usb2_vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/2] ARM: debug: Add Iproc UART3 debug addresses
From: Ray Jui @ 2018-06-01 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61a35071-4304-a25f-8c99-fe504b2c2346@gmail.com>
Sorry Florian, I had a couple issues with my email client yesterday and
I'm not sure if you have received my reply.
Please see my reply inline.
On 5/31/2018 3:16 PM, Florian Fainelli wrote:
>
>
> On 05/31/2018 10:24 AM, Ray Jui wrote:
>>
>>
>> On 5/31/2018 1:22 AM, Cl?ment P?ron wrote:
>>> Hi Rai,
>>>
>>> On Wed, 30 May 2018 at 19:25, Ray Jui <ray.jui@broadcom.com> wrote:
>>>>
>>>> Hi Cl?ment,
>>>>
>>>> Correct me if I'm wrong, but I thought the trend is to move to use
>>>> earlycon that can be activated from kernel command line for early print
>>>> before the serial driver is loaded.
>>>>
>>>> Have you tried earlcon?
>>> No, only tested this method.
>>>
>>> Thanks,
>>> Clement
>>>
>>
>> If I remember it correctly, I think the trend is to use earlycon. There
>> are obvious shortcomings by making this configuration compile time based.
>
> This is true, though on ARM 32-bit kernels DEBUG_LL gets used by the
> kernel self-decompressor and also before earlycon has a chance to run,
> this is useful to debugging memory issues where your memory
> configuration is incorrect typically.
>
This is true.
> Either way is fine with me (accepting or dropping) the patch, though
> there is probably minimal impact in just accepting such a change.
>
Will leave the decision to you then.
Thanks,
Ray
^ permalink raw reply
* [PATCH 5/7] iommu/dma: add support for non-strict mode
From: kbuild test robot @ 2018-06-01 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-6-git-send-email-thunder.leizhen@huawei.com>
Hi Zhen,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc7 next-20180601]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Zhen-Lei/add-non-strict-mode-support-for-arm-smmu-v3/20180602-000418
config: x86_64-randconfig-x008-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers//iommu/amd_iommu.c: In function 'amd_iommu_capable':
>> drivers//iommu/amd_iommu.c:3053:2: warning: enumeration value 'IOMMU_CAP_NON_STRICT' not handled in switch [-Wswitch]
switch (cap) {
^~~~~~
vim +/IOMMU_CAP_NON_STRICT +3053 drivers//iommu/amd_iommu.c
645c4c8d arch/x86/kernel/amd_iommu.c Joerg Roedel 2008-12-02 3050
ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3051 static bool amd_iommu_capable(enum iommu_cap cap)
dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3052 {
80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 @3053 switch (cap) {
80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3054 case IOMMU_CAP_CACHE_COHERENCY:
ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3055 return true;
bdddadcb drivers/iommu/amd_iommu.c Joerg Roedel 2012-07-02 3056 case IOMMU_CAP_INTR_REMAP:
ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3057 return (irq_remapping_enabled == 1);
cfdeec22 drivers/iommu/amd_iommu.c Will Deacon 2014-10-27 3058 case IOMMU_CAP_NOEXEC:
cfdeec22 drivers/iommu/amd_iommu.c Will Deacon 2014-10-27 3059 return false;
80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3060 }
80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3061
ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3062 return false;
dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3063 }
dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3064
:::::: The code at line 3053 was first introduced by commit
:::::: 80a506b8fdcfa868bb53eb740f928217d0966fc1 x86/amd-iommu: Export cache-coherency capability
:::::: TO: Joerg Roedel <joerg.roedel@amd.com>
:::::: CC: Joerg Roedel <joerg.roedel@amd.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 28596 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180602/14d67fbb/attachment-0001.gz>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: allwinner: add support for Pinebook
From: Vasily Khoruzhick @ 2018-06-01 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601092346.g2iixqupumn7xo7r@flea>
On Fri, Jun 1, 2018 at 2:23 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Thu, May 31, 2018 at 11:29:01PM -0700, Vasily Khoruzhick wrote:
>> From: Icenowy Zheng <icenowy@aosc.xyz>
>>
>> Pinebook is a A64-based laptop produced by Pine64, with the following
>> peripherals:
>>
>> USB:
>> - Two external USB ports (one is directly connected to A64's OTG
>> controller, the other is under a internal hub connected to the host-only
>> controller.)
>> - USB HID keyboard and touchpad connected to the internal hub.
>> - USB UVC camera connected to the internal hub.
>>
>> Power-related:
>> - A DC IN jack connected to AXP803's DCIN pin.
>> - A Li-Polymer battery connected to AXP803's battery pins.
>>
>> Storage:
>> - An eMMC by Foresee on the main board (in the product revision of the
>> main board it's designed to be switchable).
>> - An external MicroSD card slot.
>>
>> Display:
>> - An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
>> - A mini HDMI port.
>>
>> Misc:
>> - A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
>> - A headphone jack connected to the SoC's internal codec.
>> - A debug UART port muxed with headphone jack.
>>
>> This commit adds basical support for it.
>>
>> [vasily: squashed several commits into one, added simplefb node, added usbphy
>> to ehci0 and ohci0 nodes]
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>> ---
>> arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> .../dts/allwinner/sun50i-a64-pinebook.dts | 285 ++++++++++++++++++
>> 2 files changed, 286 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>> index 8bebe7da5ed9..a8c6d0c6f2c5 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> new file mode 100644
>> index 000000000000..d952db217702
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> @@ -0,0 +1,285 @@
>> +/*
>> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
>> + * Copyright (C) 2018 Vasily Khoruzhick <anarsoul@gmail.com>
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
>
> The SPDX tag should be the first one.
OK, but it's not in number of other dts files, e.g.
sun50i-a64-teres-i.dts or sun50i-h5-orangepi-zero-plus.dts
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pwm/pwm.h>
>> +
>> +/ {
>> + model = "Pinebook";
>> + compatible = "pine64,pinebook", "allwinner,sun50i-a64";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + ethernet0 = &rtl8723cs;
>> + };
>> +
>> + backlight: backlight {
>> + compatible = "pwm-backlight";
>> + pwms = <&pwm 0 50000 0>;
>> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
>
> The perceived brightness should be increasing linearly. This usually
> means that you need an function close to a power of two sequence.
OK, I'll try, but no one complained so far.
>> + default-brightness-level = <2>;
>> + enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> +
>> + framebuffer-lcd {
>> + panel-supply = <®_dc1sw>;
>> + dvdd25-supply = <®_dldo2>;
>> + dvdd12-supply = <®_fldo1>;
>> + };
>> + };
>> +
>> + gpio_keys {
>> + compatible = "gpio-keys";
>> +
>> + lid_switch {
>> + label = "Lid Switch";
>> + gpios = <&r_pio 0 12 GPIO_ACTIVE_LOW>; /* PL12 */
>> + linux,input-type = <EV_SW>;
>> + linux,code = <SW_LID>;
>> + linux,can-disable;
>> + };
>> + };
>> +
>> + reg_vcc3v3: vcc3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vcc3v3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>> + };
>> +};
>> +
>> +&ehci0 {
>> + phys = <&usbphy 0>;
>> + phy-names = "usb";
>> + status = "okay";
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins>;
>> + vmmc-supply = <®_dcdc1>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> + cd-inverted;
>> + disable-wp;
>> + bus-width = <4>;
>> + status = "okay";
>> +};
>> +
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins>;
>> + vmmc-supply = <®_dldo4>;
>> + vqmmc-supply = <®_eldo1>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "okay";
>> +
>> + rtl8723cs: wifi at 1 {
>> + reg = <1>;
>> + };
>> +};
>> +
>> +&mmc2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc2_pins>;
>> + vmmc-supply = <®_dcdc1>;
>> + vqmmc-supply = <®_eldo1>;
>> + bus-width = <8>;
>> + non-removable;
>> + cap-mmc-hw-reset;
>> + mmc-hs200-1_8v;
>> + status = "okay";
>> +};
>> +
>> +&ohci0 {
>> + phys = <&usbphy 0>;
>> + phy-names = "usb";
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&pwm {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pwm_pin>;
>> + status = "okay";
>> +};
>> +
>> +&r_rsb {
>> + status = "okay";
>> +
>> + axp803: pmic at 3a3 {
>> + compatible = "x-powers,axp803";
>> + reg = <0x3a3>;
>> + interrupt-parent = <&r_intc>;
>> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +};
>> +
>> +/* The ANX6345 eDP-bridge is on r_i2c. There is no linux (mainline)
>> + * driver for this chip at the moment, the bootloader initializes it.
>> + * However it can be accessed with the i2c-dev driver from user space.
>> + */
>
> The comment format is wrong, and the part after r_i2c, about i2c-dev
> and the mainline support is not really relevant. The DT describes the
> hardware, and is used by several different projects that might or
> might not have i2c-dev, an interface similar, or might have or not a
> driver for the bridge.
Comment is identical to sun50i-a64-teres-i.dts (which was merged few
months ago).
I'll remove everything but first sentence.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH v3 2/2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Jagan Teki @ 2018-06-01 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601173527.18051-1-jagan@amarulasolutions.com>
Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
- WiFi SDIO interface is connected to MMC1
- WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
- WiFi WL-WAKE-AP pin connected to gpio PL3
- 32kHz external oscillator gate clock from RTC
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- move dtsi change in separate patch
Changes for v2:
- Move external rtc clock nodes into main rtc node definition
of sun50i-a64.dtsi
.../dts/allwinner/sun50i-a64-amarula-relic.dts | 31 ++++++++++++++++++++++
1 file changed, 31 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 ce4a256ff086..eac4793c8502 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -21,12 +21,43 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rtc 1>;
+ clock-names = "ext_clock";
+ reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
+ };
};
&ehci0 {
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dcdc1>;
+ /*
+ * Schematic shows both dldo4 and eldo1 connected for vcc-io-wifi, but
+ * dldo4 connection shows DNP(Do Not Populate) and eldo1 connected with
+ * 0Ohm register to vcc-io-wifi so eldo1 is used.
+ */
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcmf: wifi at 1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&r_pio>;
+ interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
+ interrupt-names = "host-wake";
+ };
+};
+
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
--
2.14.3
^ permalink raw reply related
* [PATCH v3 1/2] arm64: allwinner: a64: Add RTC clock to phandle 32kHz external oscillator
From: Jagan Teki @ 2018-06-01 17:35 UTC (permalink / raw)
To: linux-arm-kernel
Outside of SOC few chips need external clock source
through RTC example Wifi chip. So RTC clock nodes to
phandle 32kHz external oscillator.
prefix rtc- with clock-output-names defined in
dt-binding to avoid confusion with existing osc32k name.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- squash of previous v2 patch
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..82516aec4153 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -634,6 +634,9 @@
reg = <0x01f00000 0x54>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
+ clocks = <&osc32k>;
+ #clock-cells = <1>;
};
r_intc: interrupt-controller at 1f00c00 {
--
2.14.3
^ permalink raw reply related
* [PATCH 2/3] dts: sunxi: A64: Add PWM controllers
From: Vasily Khoruzhick @ 2018-06-01 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601091816.klmc3nfzynxprcso@flea>
On Fri, Jun 1, 2018 at 2:18 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Thu, May 31, 2018 at 11:29:00PM -0700, Vasily Khoruzhick wrote:
>> From: Andre Przywara <andre.przywara@arm.com>
>>
>> The Allwinner A64 SoC features two PWM controllers, which are fully
>> compatible to the one used in the A13 and H3 chips.
>>
>> Add the nodes for the devices (one for the "normal" PWM, the other for
>> the one in the CPUS domain) and the pins their outputs are connected to.
>>
>> On the A64 the "normal" PWM is muxed together with one of the MDIO pins
>> used to communicate with the Ethernet PHY, so it won't be usable on many
>> boards. But the Pinebook laptop uses this pin for controlling the LCD
>> backlight.
>>
>> On Pine64 the CPUS PWM pin however is routed to the "RPi2" header,
>> at the same location as the PWM pin on the RaspberryPi.
>>
>> [vasily: fixed comment message as requested by Stefan Bruens]
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> on Pinebook (only the "normal" PWM)
>> Tested-by: Harald Geyer <harald@ccbib.org> on Teres-I (only the "normal" PWM)
>
> Same thing, you should have your SoB there. And I'm not sure the
> Tested-by format is valid. This information would be better in the
> commit log itself.
OK
>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 +++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index b5e903ccf0ec..e94bfa8477f6 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -365,6 +365,11 @@
>> bias-pull-up;
>> };
>>
>> + pwm_pin: pwm_pin {
>> + pins = "PD22";
>> + function = "pwm";
>> + };
>> +
>
> Is there multiple options for that muxing? If not, add it to the PWM
> node by default.
OK
>
>> rmii_pins: rmii_pins {
>> pins = "PD10", "PD11", "PD13", "PD14", "PD17",
>> "PD18", "PD19", "PD20", "PD22", "PD23";
>> @@ -630,6 +635,15 @@
>> #interrupt-cells = <3>;
>> };
>>
>> + pwm: pwm at 1c21400 {
>> + compatible = "allwinner,sun50i-a64-pwm",
>> + "allwinner,sun5i-a13-pwm";
>> + reg = <0x01c21400 0x400>;
>> + clocks = <&osc24M>;
>> + #pwm-cells = <3>;
>> + status = "disabled";
>> + };
>> +
>> rtc: rtc at 1f00000 {
>> compatible = "allwinner,sun6i-a31-rtc";
>> reg = <0x01f00000 0x54>;
>> @@ -667,6 +681,15 @@
>> #size-cells = <0>;
>> };
>>
>> + r_pwm: pwm at 1f03800 {
>> + compatible = "allwinner,sun50i-a64-pwm",
>> + "allwinner,sun5i-a13-pwm";
>> + reg = <0x01f03800 0x400>;
>> + clocks = <&osc24M>;
>> + #pwm-cells = <3>;
>> + status = "disabled";
>> + };
>> +
>> r_pio: pinctrl at 1f02c00 {
>> compatible = "allwinner,sun50i-a64-r-pinctrl";
>> reg = <0x01f02c00 0x400>;
>> @@ -687,6 +710,11 @@
>> pins = "PL8", "PL9";
>> function = "s_i2c";
>> };
>> +
>> + r_pwm_pin: pwm {
>> + pins = "PL10";
>> + function = "s_pwm";
>> + };
>
> Ditto.
OK
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH 1/3] arm64: allwinner: a64: add R_I2C controller
From: Vasily Khoruzhick @ 2018-06-01 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601091631.wqctilk55fcmggwv@flea>
On Fri, Jun 1, 2018 at 2:16 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> Hi,
>
> On Thu, May 31, 2018 at 11:28:59PM -0700, Vasily Khoruzhick wrote:
>> From: Icenowy Zheng <icenowy@aosc.io>
>>
>> Allwinner A64 has a I2C controller, which is in the R_ MMIO zone and has
>> two groups of pinmuxes on PL bank, so it's called R_I2C.
>>
>> Add support for this I2C controller and the pinmux which doesn't conflict
>> with RSB.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>
> You should have your SoB there.
OK, will do.
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index 1b2ef28c42bd..b5e903ccf0ec 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -46,6 +46,7 @@
>> #include <dt-bindings/clock/sun8i-r-ccu.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/reset/sun50i-a64-ccu.h>
>> +#include <dt-bindings/reset/sun8i-r-ccu.h>
>>
>> / {
>> interrupt-parent = <&gic>;
>> @@ -655,6 +656,17 @@
>> #reset-cells = <1>;
>> };
>>
>> + r_i2c: i2c at 1f02400 {
>> + compatible = "allwinner,sun6i-a31-i2c";
>
> You should add an a64 compatible here
We don't have it for regular i2c, why should I add it here?
>> + reg = <0x01f02400 0x400>;
>> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&r_ccu CLK_APB0_I2C>;
>> + resets = <&r_ccu RST_APB0_I2C>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> r_pio: pinctrl at 1f02c00 {
>> compatible = "allwinner,sun50i-a64-r-pinctrl";
>> reg = <0x01f02c00 0x400>;
>> @@ -670,6 +682,11 @@
>> pins = "PL0", "PL1";
>> function = "s_rsb";
>> };
>> +
>> + r_i2c_pins_a: i2c-a {
>> + pins = "PL8", "PL9";
>> + function = "s_i2c";
>> + };
>
> This should be ordered by alphabetical order
OK
> If this is the only muxing option, you can also add it to the i2c DT
> node.
It's not the only option, but other option conflicts with rsb. Should
I still add it to i2c DT node?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Stephen Boyd @ 2018-06-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521115947.wqrnv2hczate65lz@flea>
Quoting Maxime Ripard (2018-05-21 04:59:47)
> Hi Mike, Stephen,
>
> Please merge the following changes for the next merge window, thanks!
>
Thanks. Pulled into clk-next.
^ permalink raw reply
* [GIT PULL] KVM/ARM updates for 4.18
From: Paolo Bonzini @ 2018-06-01 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601152747.23613-1-marc.zyngier@arm.com>
On 01/06/2018 17:27, Marc Zyngier wrote:
> Paolo, Radim,
>
> This is the set of updates for KVM/ARM for v4.18. This time, lazy
> context switching of the floating point registers for arm64, and the
> ability to deal with multiple redistributor ranges (which allows for
> larger numbers of vcpu).
>
> Note that some additional KVM/ARM updates will come via the arm64 tree
> with the SSBD patches. This will generate three conflicts that are
> pretty simple to resolve (-next has a good example of the resolution).
>
> Please pull,
>
> M.
>
> The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
>
> Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-for-v4.18
>
> for you to fetch changes up to e25028c8ded011d19f9a11164807507c94febc01:
>
> KVM: arm/arm64: Bump VGIC_V3_MAX_CPUS to 512 (2018-05-25 12:29:27 +0100)
>
> ----------------------------------------------------------------
> KVM/ARM updates for 4.18
>
> - Lazy context-switching of FPSIMD registers on arm64
> - Allow virtual redistributors to be part of two or more MMIO ranges
Pulled, thanks.
Paolo
^ permalink raw reply
* [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Stephen Boyd @ 2018-06-01 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9ca51832-6095-c8a5-1347-f57abf99e8f9@codeaurora.org>
Quoting Sricharan R (2018-06-01 06:20:37)
> Hi Stephen,
>
> On 5/31/2018 1:11 PM, Stephen Boyd wrote:
> >
> > Ok. One general comment is that it would be nice if the bindings for all
> > the nodes that are introduced included 'clocks' properties and also
> > maybe 'clock-names' properties for the clocks that are consumed by each
> > node. Right now, we hide those details from DT and rely on the string
> > names to hook the clk tree up for us. That sort of prevents us from
> > moving away from string easily, so I would just throw the clocks into
> > the binding right now and always have them there just in case we want to
> > use the binding to figure out the hierarchy in the future.
> >
>
> ok, understand that mostly. So will try to revamp those patches with
> the 'clocks' property in the binding added, reading them in the driver
> from DT.
Yeah. You don't even have to actually use the clocks property right now
from the drivers. Just add the properties in the binding.
^ permalink raw reply
* [PATCH 1/6] staging: vc04_services: no need to check debugfs return values
From: Eric Anholt @ 2018-06-01 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601111004.1670-1-gregkh@linuxfoundation.org>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Clean up the vchiq_arm code by not caring about the value of debugfs
> calls. This ends up removing a number of lines of code that are not
> needed.
This series is:
Reviewed-by: Eric Anholt <eric@anholt.net>
Thanks for the cleanups!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180601/d86564ed/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Rob Herring @ 2018-06-01 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0d08ba26-77f2-6c42-8fb1-214aaf6085e9@t-chip.com.cn>
On Thu, May 31, 2018 at 9:05 PM, Levin <djw@t-chip.com.cn> wrote:
> Hi Rob,
>
>
> On 2018-05-31 10:45 PM, Rob Herring wrote:
>>
>> On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
>>>
>>> From: Levin Du <djw@t-chip.com.cn>
>>>
>>> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
>>> mute control, can also be used for general purpose. It is manipulated by
>>> the GRF_SOC_CON10 register.
>>>
>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>
>>> ---
>>>
>>> Changes in v3:
>>> - Change from general gpio-syscon to specific rk3328-gpio-mute
>>>
>>> Changes in v2:
>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>
>>> Changes in v1:
>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>> - Add doc rockchip,gpio-syscon.txt
>>>
>>> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28
>>> +++++++++++++++++++
>>> drivers/gpio/gpio-syscon.c | 31
>>> ++++++++++++++++++++++
>>> 2 files changed, 59 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> new file mode 100644
>>> index 0000000..10bc632
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> @@ -0,0 +1,28 @@
>>> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE pin.
>>> +
>>> +In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
>>> mute
>>> +control, can also be used for general purpose. It is manipulated by the
>>> +GRF_SOC_CON10 register.
>>> +
>>> +Required properties:
>>> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
>>> +- gpio-controller: Marks the device node as a gpio controller.
>>> +- #gpio-cells: Should be 2. The first cell is the pin number and
>>> + the second cell is used to specify the gpio polarity:
>>> + 0 = Active high,
>>> + 1 = Active low.
>>> +
>>> +Example:
>>> +
>>> + grf: syscon at ff100000 {
>>> + compatible = "rockchip,rk3328-grf", "syscon",
>>> "simple-mfd";
>>> +
>>> + gpio_mute: gpio-mute {
>>
>> Node names should be generic:
>>
>> gpio {
>>
>> This also means you can't add another GPIO node in the future and
>> you'll have to live with "rockchip,rk3328-gpio-mute" covering more
>> than 1 GPIO if you do need to add more GPIOs.
>
>
> As the first line describes, this GPIO controller is dedicated for the
> GPIO_MUTE pin.
> There's only one GPIO pin in the GRF_SOC_CON10 register. Therefore the
> gpio_mute
> name is proper IMHO.
It's how many GPIOs in the GRF, not this register. What I'm saying is
when you come along later to add another GPIO in the GRF, you had
better just add it to this same node. I'm not going to accept another
GPIO controller node within the GRF. You have the cells to support
more than 1, so it would only be a driver change. The compatible
string would then not be ideally named at that point. But compatible
strings are just unique identifiers, so it doesn't really matter what
the string is.
I'm being told both "this is the only GPIO" and "the GRF has too many
different functions for us to tell you what they all are". So which is
it?
Rob
^ permalink raw reply
* [PATCH 1/4] clk: renesas: cpg-mssr: Stop using printk format %pCr
From: Stephen Boyd @ 2018-06-01 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-2-git-send-email-geert+renesas@glider.be>
Quoting Geert Uytterhoeven (2018-06-01 02:28:19)
> Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
> called in atomic context.
>
> Replace it by open-coding the operation. This is safe here, as the code
> runs in task context.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Chen-Yu Tsai @ 2018-06-01 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601152949.tmw7aitfoo536nxs@flea>
On Fri, Jun 1, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej ?krabec wrote:
>> Dne ?etrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
>> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
>> > > >> > > + if (tcon->quirks->needs_tcon_top) {
>> > > >> > > + struct device_node *np;
>> > > >> > > +
>> > > >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top",
>> > > >> > > 0);
>> > > >> > > + if (np) {
>> > > >> > > + struct platform_device *pdev;
>> > > >> > > +
>> > > >> > > + pdev = of_find_device_by_node(np);
>> > > >> > > + if (pdev)
>> > > >> > > + tcon->tcon_top =
>> > > >> > > platform_get_drvdata(pdev);
>> > > >> > > + of_node_put(np);
>> > > >> > > +
>> > > >> > > + if (!tcon->tcon_top)
>> > > >> > > + return -EPROBE_DEFER;
>> > > >> > > + }
>> > > >> > > + }
>> > > >> > > +
>> > > >> >
>> > > >> > I might have missed it, but I've not seen the bindings additions for
>> > > >> > that property. This shouldn't really be done that way anyway, instead
>> > > >> > of using a direct phandle, you should be using the of-graph, with the
>> > > >> > TCON-top sitting where it belongs in the flow of data.
>> > > >>
>> > > >> Just to answer to the first question, it did describe it in "[PATCH
>> > > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
>> > > >>
>> > > >> As why I designed it that way - HW representation could be described
>> > > >> that way> >>
>> > > >> (ASCII art makes sense when fixed width font is used to view it):
>> > > >> / LCD0/LVDS0
>> > > >>
>> > > >> / TCON-LCD0
>> > > >>
>> > > >> | \ MIPI DSI
>> > > >>
>> > > >> mixer0 |
>> > > >>
>> > > >> \ / TCON-LCD1 - LCD1/LVDS1
>> > > >>
>> > > >> TCON-TOP
>> > > >>
>> > > >> / \ TCON-TV0 - TVE0/RGB
>> > > >>
>> > > >> mixer1 | \
>> > > >>
>> > > >> | TCON-TOP - HDMI
>> > > >> |
>> > > >> | /
>> > > >>
>> > > >> \ TCON-TV1 - TVE1/RGB
>> > > >>
>> > > >> This is a bit simplified, since there is also TVE-TOP, which is
>> > > >> responsible
>> > > >> for sharing 4 DACs between both TVE encoders. You can have two TV outs
>> > > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even
>> > > >> seems that you can arbitrarly choose which DAC is responsible for
>> > > >> which signal, so there is a ton of possible end combinations, but I'm
>> > > >> not 100% sure.
>> > > >>
>> > > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
>> > > >> suggest more possibilities, although some of them seem wrong, like RGB
>> > > >> feeding from LCD TCON. That is confirmed to be wrong when checking BSP
>> > > >> code.
>> > > >>
>> > > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and
>> > > >> LCD1 for pin muxing, although I'm not sure why is that needed at all,
>> > > >> since according to R40 datasheet, TVE0 and TVE1 pins are dedicated and
>> > > >> not on PORT D and PORT H, respectively, as TCON-TOP documentation
>> > > >> suggest. However, HSYNC and PSYNC lines might be shared between TVE
>> > > >> (when it works in RGB mode) and LCD. But that is just my guess since
>> > > >> I'm not really familiar with RGB and LCD interfaces.
>> > > >>
>> > > >> I'm really not sure what would be the best representation in OF-graph.
>> > > >> Can you suggest one?
>> > > >
>> > > > Rob might disagree on this one, but I don't see anything wrong with
>> > > > having loops in the graph. If the TCON-TOP can be both the input and
>> > > > output of the TCONs, then so be it, and have it described that way in
>> > > > the graph.
>> > > >
>> > > > The code is already able to filter out nodes that have already been
>> > > > added to the list of devices we need to wait for in the component
>> > > > framework, so that should work as well.
>> > > >
>> > > > And we'd need to describe TVE-TOP as well, even though we don't have a
>> > > > driver for it yet. That will simplify the backward compatibility later
>> > > > on.
>> > >
>> > > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
>> > > binds everything together, and provides signal routing, kind of like
>> > > DE-TOP on A64. So the signal mux controls that were originally found
>> > > in TCON0 and TVE0 were moved out.
>> > >
>> > > The driver needs to know about that, but the graph about doesn't make
>> > > much sense directly. Without looking at the manual, I understand it to
>> > > likely be one mux between the mixers and TCONs, and one between the
>> > > TCON-TVs and HDMI. Would it make more sense to just have the graph
>> > > connections between the muxed components, and remove TCON-TOP from
>> > > it, like we had in the past? A phandle could be used to reference
>> > > the TCON-TOP for mux controls, in addition to the clocks and resets.
>> > >
>> > > For TVE, we would need something to represent each of the output pins,
>> > > so the device tree can actually describe what kind of signal, be it
>> > > each component of RGB/YUV or composite video, is wanted on each pin,
>> > > if any. This is also needed on the A20 for the Cubietruck, so we can
>> > > describe which pins are tied to the VGA connector, and which one does
>> > > R, G, or B.
>> >
>> > I guess we'll see how the DT maintainers feel about this, but my
>> > impression is that the OF graph should model the flow of data between
>> > the devices. If there's a mux somewhere, then the data is definitely
>> > going through it, and as such it should be part of the graph.
>>
>> I concur, but I spent few days thinking how to represent this sanely in graph,
>> but I didn't find any good solution. I'll represent here my idea and please
>> tell your opinion before I start implementing it.
>>
>> First, let me be clear that mixer0 and mixer1 don't have same capabilities
>> (different number of planes, mixer0 supports writeback, mixer1 does not,
>> etc.). Thus, it does matter which mixer is connected to which TCON/encoder.
>> mixer0 is meant to be connected to main display and mixer1 to auxiliary. That
>> obviously depends on end system.
>>
>> So, TCON TOP has 3 muxes, which have to be represented in graph. Two of them
>> are for mixer/TCON relationship (each of them 1 input and 4 possible outputs)
>> and one for TV TCON/HDMI pair selection (2 possible inputs, 1 output).
>>
>> According to current practice in sun4i-drm driver, graph has to have port 0,
>> representing input and port 1, representing output. This would mean that graph
>> looks something like that:
>>
>> tcon_top: tcon-top at 1c70000 {
>> compatible = "allwinner,sun8i-r40-tcon-top";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_top_in: port at 0 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <0>;
>>
>> tcon_top_in_mixer0: endpoint at 0 {
>> reg = <0>;
>> remote-endpoint = <&mixer0_out_tcon_top>;
>> };
>>
>> tcon_top_in_mixer1: endpoint at 1 {
>> reg = <1>;
>> remote-endpoint = <&mixer1_out_tcon_top>;
>> };
>>
>> tcon_top_in_tcon_tv: endpoint at 2 {
>> reg = <2>;
>> // here is HDMI input connection, part of board DTS
>> remote-endpoint = <board specific phandle to TV TCON output>;
>> };
>> };
>>
>> tcon_top_out: port at 1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> tcon_top_out_tcon0: endpoint at 0 {
>> reg = <0>;
>> // here is mixer0 output connection, part of board DTS
>> remote-endpoint = <board specific phandle to TCON>;
>> };
>>
>> tcon_top_out_tcon1: endpoint at 1 {
>> reg = <1>;
>> // here is mixer1 output connection, part of board DTS
>> remote-endpoint = <board specific phandle to TCON>;
>> };
>>
>> tcon_top_out_hdmi: endpoint at 2 {
>> reg = <2>;
>> remote-endpoint = <&hdmi_in_tcon_top>;
>> };
>> };
>> };
>> };
>
> IIRC, each port is supposed to be one route for the data, so we would
> have multiple ports, one for the mixers in input and for the tcon in
> output, and one for the TCON in input and for the HDMI/TV in
> output. Rob might correct me here.
>
>> tcon_tv0: lcd-controller at 1c73000 {
>> compatible = "allwinner,sun8i-r40-tcon-tv-0";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_tv0_in: port at 0 {
>> reg = <0>;
>>
>> tcon_tv0_in_tcon_top: endpoint {
>> // endpoint depends on board, part of board DTS
>> remote-endpoint = <phandle to one of tcon_top_out_tcon>;
>
> Just curious, what would be there?
>
>> };
>> };
>>
>> tcon_tv0_out: port at 1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> // endpoints to TV TOP and TCON TOP HDMI input
>> ...
>> };
>> };
>> };
>>
>> tcon_tv1: lcd-controller at 1c74000 {
>> compatible = "allwinner,sun8i-r40-tcon-tv-1";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_tv1_in: port at 0 {
>> reg = <0>;
>>
>> tcon_tv1_in_tcon_top: endpoint {
>> // endpoint depends on board, part of board DTS
>> remote-endpoint = <phandle to one of tcon_top_out_tcon>;
>> };
>> };
>>
>> tcon_tv1_out: port at 1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> // endpoints to TV TOP and TCON TOP HDMI input
>> ...
>> };
>> };
>> };
>>
>> tcon_lcd0 and tcon_lcd1 would have similar connections, except that for
>> outputs would be LCD or LVDS panels or MIPI DSI encoder.
>>
>> Please note that each TCON (there are 4 of them) would need to have unique
>> compatible and have HW index stored in quirks data. It would be used by TCON
>> TOP driver for configuring muxes.
>
> Can't we use the port/endpoint ID instead? If the mux is the only
> thing that changes, the compatible has no reason to. It's the same IP,
> and the only thing that changes is something that is not part of that
> IP.
I agree. Endpoint IDs should provide that information. I'm still not
sure How to encode multiple in/out mux groups in a device node though.
ChenYu
^ permalink raw reply
* [RFC PATCH 1/8] dts: binding: coresight: Document graph bindings
From: Mathieu Poirier @ 2018-06-01 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527858967-16047-2-git-send-email-suzuki.poulose@arm.com>
On Fri, Jun 01, 2018 at 02:16:00PM +0100, Suzuki K Poulose wrote:
> Before we updat the bindings, document the current graph bindings
s/updat/update
> and usage of additional properties.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> .../devicetree/bindings/arm/coresight.txt | 28 ++++++++++++++++++----
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index 15ac8e8..bd36e40 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -52,9 +52,7 @@ its hardware characteristcs.
> clocks the core of that coresight component. The latter clock
> is optional.
>
> - * port or ports: The representation of the component's port
> - layout using the generic DT graph presentation found in
> - "bindings/graph.txt".
> + * port or ports: see "Graph bindings for Coresight" below
>
> * Additional required properties for System Trace Macrocells (STM):
> * reg: along with the physical base address and length of the register
> @@ -71,7 +69,7 @@ its hardware characteristcs.
> AMBA markee):
> - "arm,coresight-replicator"
>
> - * port or ports: same as above.
> + * port or ports: see "Graph bindings for Coresight" below.
>
> * Optional properties for ETM/PTMs:
>
> @@ -86,6 +84,28 @@ its hardware characteristcs.
> * arm,buffer-size: size of contiguous buffer space for TMC ETR
> (embedded trace router)
>
> +Graph bindings for Coresight
> +-------------------------------
> +
> +Coresight components are interconnected to create a data path for the flow of
> +trace data generated from the "sources" to their collection points "sink". Each
Over 80 characters.
> +coresight component must describe the "input" and "output" connections.
> +The connections must be described via generic DT graph bindings as described
> +by the "bindings/graph.txt", where each "port" along with an "endpoint" component
Same here.
> +represents a hardware port and the connection.
> +
> +Since it is possible to have multiple connections for any coresight component with
And here.
> +a specific direction of data flow, each connection must define the following
> +properties to uniquely identify the connection details.
> +
> + * Direction of the data flow w.r.t the component :
> + Each input port must have the following property defined at the "endpoint"
> + for the port.
> + "slave-mode"
> +
> + * Hardware Port number at the component:
> + - The hardware port number is assumed to be the address of the "port" component.
And here.
Moveover this patches doesn't apply to my next tree.
> +
>
> Example:
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2] ARM: avoid Cortex-A9 livelock on tight dmb loops
From: Tony Lindgren @ 2018-06-01 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601155502.GB6920@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [180601 15:57]:
> On Fri, Jun 01, 2018 at 08:35:12AM -0700, Tony Lindgren wrote:
> > CONFIG_KERNEL_LZMA fails:
> >
> > Try gzip decompression.
> > Try LZMA decompression.
> > lzma_decompress_file: read on /boot/zImage of 65536 bytes failed
> > kernel: 0xb6abb010 kernel_size: 0x43d0f0
> > MEMORY RANGES
> > 0000000080000000-00000000bfdfffff (0)
> > zImage header: 0x016f2818 0x00000000 0x0043d0f0
> > zImage size 0x43d0f0, file size 0x43d0f0
> > Reserved memory ranges
>
> This looks like an old kexec binary as it's missing the output from:
>
> dbgprintf("zImage requires 0x%08llx bytes\n", (unsigned long long)len);
>
> Please can you test with the current version - the official
> repository should now be up to date with my version. Thanks.
OK great. After updating kexec-tools to latest git veresion LZMA
crashkernel now also boots for me :)
Regards,
Tony
^ permalink raw reply
* [PATCH v2 9/9] arm64: bitops: Include <asm-generic/bitops/ext2-atomic-setbit.h>
From: Will Deacon @ 2018-06-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527869189-31512-1-git-send-email-will.deacon@arm.com>
asm-generic/bitops/ext2-atomic-setbit.h provides the ext2 atomic bitop
definitions, so we don't need to define our own.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/bitops.h | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/bitops.h b/arch/arm64/include/asm/bitops.h
index 13501460be6b..10d536b1af74 100644
--- a/arch/arm64/include/asm/bitops.h
+++ b/arch/arm64/include/asm/bitops.h
@@ -38,11 +38,6 @@
#include <asm-generic/bitops/lock.h>
#include <asm-generic/bitops/non-atomic.h>
#include <asm-generic/bitops/le.h>
-
-/*
- * Ext2 is defined to use little-endian byte ordering.
- */
-#define ext2_set_bit_atomic(lock, nr, p) test_and_set_bit_le(nr, p)
-#define ext2_clear_bit_atomic(lock, nr, p) test_and_clear_bit_le(nr, p)
+#include <asm-generic/bitops/ext2-atomic-setbit.h>
#endif /* __ASM_BITOPS_H */
--
2.1.4
^ permalink raw reply related
* [PATCH v2 8/9] arm64: Replace our atomic/lock bitop implementations with asm-generic
From: Will Deacon @ 2018-06-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527869189-31512-1-git-send-email-will.deacon@arm.com>
The asm-generic/bitops/{atomic,lock}.h implementations are built around
the atomic-fetch ops, which we implement efficiently for both LSE and
LL/SC systems. Use that instead of our hand-rolled, out-of-line bitops.S.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/bitops.h | 14 ++------
arch/arm64/lib/Makefile | 2 +-
arch/arm64/lib/bitops.S | 76 -----------------------------------------
3 files changed, 3 insertions(+), 89 deletions(-)
delete mode 100644 arch/arm64/lib/bitops.S
diff --git a/arch/arm64/include/asm/bitops.h b/arch/arm64/include/asm/bitops.h
index 9c19594ce7cb..13501460be6b 100644
--- a/arch/arm64/include/asm/bitops.h
+++ b/arch/arm64/include/asm/bitops.h
@@ -17,22 +17,11 @@
#define __ASM_BITOPS_H
#include <linux/compiler.h>
-#include <asm/barrier.h>
#ifndef _LINUX_BITOPS_H
#error only <linux/bitops.h> can be included directly
#endif
-/*
- * Little endian assembly atomic bitops.
- */
-extern void set_bit(int nr, volatile unsigned long *p);
-extern void clear_bit(int nr, volatile unsigned long *p);
-extern void change_bit(int nr, volatile unsigned long *p);
-extern int test_and_set_bit(int nr, volatile unsigned long *p);
-extern int test_and_clear_bit(int nr, volatile unsigned long *p);
-extern int test_and_change_bit(int nr, volatile unsigned long *p);
-
#include <asm-generic/bitops/builtin-__ffs.h>
#include <asm-generic/bitops/builtin-ffs.h>
#include <asm-generic/bitops/builtin-__fls.h>
@@ -44,8 +33,9 @@ extern int test_and_change_bit(int nr, volatile unsigned long *p);
#include <asm-generic/bitops/sched.h>
#include <asm-generic/bitops/hweight.h>
-#include <asm-generic/bitops/lock.h>
+#include <asm-generic/bitops/atomic.h>
+#include <asm-generic/bitops/lock.h>
#include <asm-generic/bitops/non-atomic.h>
#include <asm-generic/bitops/le.h>
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 137710f4dac3..68755fd70dcf 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-lib-y := bitops.o clear_user.o delay.o copy_from_user.o \
+lib-y := clear_user.o delay.o copy_from_user.o \
copy_to_user.o copy_in_user.o copy_page.o \
clear_page.o memchr.o memcpy.o memmove.o memset.o \
memcmp.o strcmp.o strncmp.o strlen.o strnlen.o \
diff --git a/arch/arm64/lib/bitops.S b/arch/arm64/lib/bitops.S
deleted file mode 100644
index 43ac736baa5b..000000000000
--- a/arch/arm64/lib/bitops.S
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
- * Based on arch/arm/lib/bitops.h
- *
- * Copyright (C) 2013 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/linkage.h>
-#include <asm/assembler.h>
-#include <asm/lse.h>
-
-/*
- * x0: bits 5:0 bit offset
- * bits 31:6 word offset
- * x1: address
- */
- .macro bitop, name, llsc, lse
-ENTRY( \name )
- and w3, w0, #63 // Get bit offset
- eor w0, w0, w3 // Clear low bits
- mov x2, #1
- add x1, x1, x0, lsr #3 // Get word offset
-alt_lse " prfm pstl1strm, [x1]", "nop"
- lsl x3, x2, x3 // Create mask
-
-alt_lse "1: ldxr x2, [x1]", "\lse x3, [x1]"
-alt_lse " \llsc x2, x2, x3", "nop"
-alt_lse " stxr w0, x2, [x1]", "nop"
-alt_lse " cbnz w0, 1b", "nop"
-
- ret
-ENDPROC(\name )
- .endm
-
- .macro testop, name, llsc, lse
-ENTRY( \name )
- and w3, w0, #63 // Get bit offset
- eor w0, w0, w3 // Clear low bits
- mov x2, #1
- add x1, x1, x0, lsr #3 // Get word offset
-alt_lse " prfm pstl1strm, [x1]", "nop"
- lsl x4, x2, x3 // Create mask
-
-alt_lse "1: ldxr x2, [x1]", "\lse x4, x2, [x1]"
- lsr x0, x2, x3
-alt_lse " \llsc x2, x2, x4", "nop"
-alt_lse " stlxr w5, x2, [x1]", "nop"
-alt_lse " cbnz w5, 1b", "nop"
-alt_lse " dmb ish", "nop"
-
- and x0, x0, #1
- ret
-ENDPROC(\name )
- .endm
-
-/*
- * Atomic bit operations.
- */
- bitop change_bit, eor, steor
- bitop clear_bit, bic, stclr
- bitop set_bit, orr, stset
-
- testop test_and_change_bit, eor, ldeoral
- testop test_and_clear_bit, bic, ldclral
- testop test_and_set_bit, orr, ldsetal
--
2.1.4
^ permalink raw reply related
* [PATCH v2 7/9] asm-generic/bitops/lock.h: Rewrite using atomic_fetch_*
From: Will Deacon @ 2018-06-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527869189-31512-1-git-send-email-will.deacon@arm.com>
The lock bitops can be implemented more efficiently using the atomic_fetch_*
ops, which provide finer-grained control over the memory ordering semantics
than the bitops.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
include/asm-generic/bitops/lock.h | 68 ++++++++++++++++++++++++++++++++-------
1 file changed, 56 insertions(+), 12 deletions(-)
diff --git a/include/asm-generic/bitops/lock.h b/include/asm-generic/bitops/lock.h
index 67ab280ad134..3ae021368f48 100644
--- a/include/asm-generic/bitops/lock.h
+++ b/include/asm-generic/bitops/lock.h
@@ -2,6 +2,10 @@
#ifndef _ASM_GENERIC_BITOPS_LOCK_H_
#define _ASM_GENERIC_BITOPS_LOCK_H_
+#include <linux/atomic.h>
+#include <linux/compiler.h>
+#include <asm/barrier.h>
+
/**
* test_and_set_bit_lock - Set a bit and return its old value, for lock
* @nr: Bit to set
@@ -11,7 +15,20 @@
* the returned value is 0.
* It can be used to implement bit locks.
*/
-#define test_and_set_bit_lock(nr, addr) test_and_set_bit(nr, addr)
+static inline int test_and_set_bit_lock(unsigned int nr,
+ volatile unsigned long *p)
+{
+ long old;
+ unsigned long mask = BIT_MASK(nr);
+
+ p += BIT_WORD(nr);
+ if (READ_ONCE(*p) & mask)
+ return 1;
+
+ old = atomic_long_fetch_or_acquire(mask, (atomic_long_t *)p);
+ return !!(old & mask);
+}
+
/**
* clear_bit_unlock - Clear a bit in memory, for unlock
@@ -20,11 +37,11 @@
*
* This operation is atomic and provides release barrier semantics.
*/
-#define clear_bit_unlock(nr, addr) \
-do { \
- smp_mb__before_atomic(); \
- clear_bit(nr, addr); \
-} while (0)
+static inline void clear_bit_unlock(unsigned int nr, volatile unsigned long *p)
+{
+ p += BIT_WORD(nr);
+ atomic_long_fetch_andnot_release(BIT_MASK(nr), (atomic_long_t *)p);
+}
/**
* __clear_bit_unlock - Clear a bit in memory, for unlock
@@ -37,11 +54,38 @@ do { \
*
* See for example x86's implementation.
*/
-#define __clear_bit_unlock(nr, addr) \
-do { \
- smp_mb__before_atomic(); \
- clear_bit(nr, addr); \
-} while (0)
+static inline void __clear_bit_unlock(unsigned int nr,
+ volatile unsigned long *p)
+{
+ unsigned long old;
-#endif /* _ASM_GENERIC_BITOPS_LOCK_H_ */
+ p += BIT_WORD(nr);
+ old = READ_ONCE(*p);
+ old &= ~BIT_MASK(nr);
+ atomic_long_set_release((atomic_long_t *)p, old);
+}
+
+/**
+ * clear_bit_unlock_is_negative_byte - Clear a bit in memory and test if bottom
+ * byte is negative, for unlock.
+ * @nr: the bit to clear
+ * @addr: the address to start counting from
+ *
+ * This is a bit of a one-trick-pony for the filemap code, which clears
+ * PG_locked and tests PG_waiters,
+ */
+#ifndef clear_bit_unlock_is_negative_byte
+static inline bool clear_bit_unlock_is_negative_byte(unsigned int nr,
+ volatile unsigned long *p)
+{
+ long old;
+ unsigned long mask = BIT_MASK(nr);
+
+ p += BIT_WORD(nr);
+ old = atomic_long_fetch_andnot_release(mask, (atomic_long_t *)p);
+ return !!(old & BIT(7));
+}
+#define clear_bit_unlock_is_negative_byte clear_bit_unlock_is_negative_byte
+#endif
+#endif /* _ASM_GENERIC_BITOPS_LOCK_H_ */
--
2.1.4
^ permalink raw reply related
* [PATCH v2 6/9] asm-generic/bitops/atomic.h: Rewrite using atomic_*
From: Will Deacon @ 2018-06-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527869189-31512-1-git-send-email-will.deacon@arm.com>
The atomic bitops can actually be implemented pretty efficiently using
the atomic_* ops, rather than explicit use of spinlocks.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
include/asm-generic/bitops/atomic.h | 188 +++++++-----------------------------
1 file changed, 33 insertions(+), 155 deletions(-)
diff --git a/include/asm-generic/bitops/atomic.h b/include/asm-generic/bitops/atomic.h
index 04deffaf5f7d..dd90c9792909 100644
--- a/include/asm-generic/bitops/atomic.h
+++ b/include/asm-generic/bitops/atomic.h
@@ -2,189 +2,67 @@
#ifndef _ASM_GENERIC_BITOPS_ATOMIC_H_
#define _ASM_GENERIC_BITOPS_ATOMIC_H_
-#include <asm/types.h>
-#include <linux/irqflags.h>
-
-#ifdef CONFIG_SMP
-#include <asm/spinlock.h>
-#include <asm/cache.h> /* we use L1_CACHE_BYTES */
-
-/* Use an array of spinlocks for our atomic_ts.
- * Hash function to index into a different SPINLOCK.
- * Since "a" is usually an address, use one spinlock per cacheline.
- */
-# define ATOMIC_HASH_SIZE 4
-# define ATOMIC_HASH(a) (&(__atomic_hash[ (((unsigned long) a)/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
-
-extern arch_spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] __lock_aligned;
-
-/* Can't use raw_spin_lock_irq because of #include problems, so
- * this is the substitute */
-#define _atomic_spin_lock_irqsave(l,f) do { \
- arch_spinlock_t *s = ATOMIC_HASH(l); \
- local_irq_save(f); \
- arch_spin_lock(s); \
-} while(0)
-
-#define _atomic_spin_unlock_irqrestore(l,f) do { \
- arch_spinlock_t *s = ATOMIC_HASH(l); \
- arch_spin_unlock(s); \
- local_irq_restore(f); \
-} while(0)
-
-
-#else
-# define _atomic_spin_lock_irqsave(l,f) do { local_irq_save(f); } while (0)
-# define _atomic_spin_unlock_irqrestore(l,f) do { local_irq_restore(f); } while (0)
-#endif
+#include <linux/atomic.h>
+#include <linux/compiler.h>
+#include <asm/barrier.h>
/*
- * NMI events can occur at any time, including when interrupts have been
- * disabled by *_irqsave(). So you can get NMI events occurring while a
- * *_bit function is holding a spin lock. If the NMI handler also wants
- * to do bit manipulation (and they do) then you can get a deadlock
- * between the original caller of *_bit() and the NMI handler.
- *
- * by Keith Owens
+ * Implementation of atomic bitops using atomic-fetch ops.
+ * See Documentation/atomic_bitops.txt for details.
*/
-/**
- * set_bit - Atomically set a bit in memory
- * @nr: the bit to set
- * @addr: the address to start counting from
- *
- * This function is atomic and may not be reordered. See __set_bit()
- * if you do not require the atomic guarantees.
- *
- * Note: there are no guarantees that this function will not be reordered
- * on non x86 architectures, so if you are writing portable code,
- * make sure not to rely on its reordering guarantees.
- *
- * Note that @nr may be almost arbitrarily large; this function is not
- * restricted to acting on a single-word quantity.
- */
-static inline void set_bit(int nr, volatile unsigned long *addr)
+static inline void set_bit(unsigned int nr, volatile unsigned long *p)
{
- unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
- unsigned long flags;
-
- _atomic_spin_lock_irqsave(p, flags);
- *p |= mask;
- _atomic_spin_unlock_irqrestore(p, flags);
+ p += BIT_WORD(nr);
+ atomic_long_or(BIT_MASK(nr), (atomic_long_t *)p);
}
-/**
- * clear_bit - Clears a bit in memory
- * @nr: Bit to clear
- * @addr: Address to start counting from
- *
- * clear_bit() is atomic and may not be reordered. However, it does
- * not contain a memory barrier, so if it is used for locking purposes,
- * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
- * in order to ensure changes are visible on other processors.
- */
-static inline void clear_bit(int nr, volatile unsigned long *addr)
+static inline void clear_bit(unsigned int nr, volatile unsigned long *p)
{
- unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
- unsigned long flags;
-
- _atomic_spin_lock_irqsave(p, flags);
- *p &= ~mask;
- _atomic_spin_unlock_irqrestore(p, flags);
+ p += BIT_WORD(nr);
+ atomic_long_andnot(BIT_MASK(nr), (atomic_long_t *)p);
}
-/**
- * change_bit - Toggle a bit in memory
- * @nr: Bit to change
- * @addr: Address to start counting from
- *
- * change_bit() is atomic and may not be reordered. It may be
- * reordered on other architectures than x86.
- * Note that @nr may be almost arbitrarily large; this function is not
- * restricted to acting on a single-word quantity.
- */
-static inline void change_bit(int nr, volatile unsigned long *addr)
+static inline void change_bit(unsigned int nr, volatile unsigned long *p)
{
- unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
- unsigned long flags;
-
- _atomic_spin_lock_irqsave(p, flags);
- *p ^= mask;
- _atomic_spin_unlock_irqrestore(p, flags);
+ p += BIT_WORD(nr);
+ atomic_long_xor(BIT_MASK(nr), (atomic_long_t *)p);
}
-/**
- * test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It may be reordered on other architectures than x86.
- * It also implies a memory barrier.
- */
-static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_set_bit(unsigned int nr, volatile unsigned long *p)
{
+ long old;
unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
- unsigned long old;
- unsigned long flags;
- _atomic_spin_lock_irqsave(p, flags);
- old = *p;
- *p = old | mask;
- _atomic_spin_unlock_irqrestore(p, flags);
+ p += BIT_WORD(nr);
+ if (READ_ONCE(*p) & mask)
+ return 1;
- return (old & mask) != 0;
+ old = atomic_long_fetch_or(mask, (atomic_long_t *)p);
+ return !!(old & mask);
}
-/**
- * test_and_clear_bit - Clear a bit and return its old value
- * @nr: Bit to clear
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It can be reorderdered on other architectures other than x86.
- * It also implies a memory barrier.
- */
-static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_clear_bit(unsigned int nr, volatile unsigned long *p)
{
+ long old;
unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
- unsigned long old;
- unsigned long flags;
- _atomic_spin_lock_irqsave(p, flags);
- old = *p;
- *p = old & ~mask;
- _atomic_spin_unlock_irqrestore(p, flags);
+ p += BIT_WORD(nr);
+ if (!(READ_ONCE(*p) & mask))
+ return 0;
- return (old & mask) != 0;
+ old = atomic_long_fetch_andnot(mask, (atomic_long_t *)p);
+ return !!(old & mask);
}
-/**
- * test_and_change_bit - Change a bit and return its old value
- * @nr: Bit to change
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It also implies a memory barrier.
- */
-static inline int test_and_change_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_change_bit(unsigned int nr, volatile unsigned long *p)
{
+ long old;
unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
- unsigned long old;
- unsigned long flags;
-
- _atomic_spin_lock_irqsave(p, flags);
- old = *p;
- *p = old ^ mask;
- _atomic_spin_unlock_irqrestore(p, flags);
- return (old & mask) != 0;
+ p += BIT_WORD(nr);
+ old = atomic_long_fetch_xor(mask, (atomic_long_t *)p);
+ return !!(old & mask);
}
#endif /* _ASM_GENERIC_BITOPS_ATOMIC_H */
--
2.1.4
^ permalink raw reply related
* [PATCH v2 5/9] sh: Don't pull in all of linux/bitops.h in asm/cmpxchg-xchg.h
From: Will Deacon @ 2018-06-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527869189-31512-1-git-send-email-will.deacon@arm.com>
The sh implementation of asm/cmpxchg-xchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with linux/bits.h and linux/compiler.h
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/sh/include/asm/cmpxchg-xchg.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/sh/include/asm/cmpxchg-xchg.h b/arch/sh/include/asm/cmpxchg-xchg.h
index 1e881f5db659..593a9704782b 100644
--- a/arch/sh/include/asm/cmpxchg-xchg.h
+++ b/arch/sh/include/asm/cmpxchg-xchg.h
@@ -8,7 +8,8 @@
* This work is licensed under the terms of the GNU GPL, version 2. See the
* file "COPYING" in the main directory of this archive for more details.
*/
-#include <linux/bitops.h>
+#include <linux/bits.h>
+#include <linux/compiler.h>
#include <asm/byteorder.h>
/*
--
2.1.4
^ permalink raw reply related
* [PATCH v2 4/9] openrisc: Don't pull in all of linux/bitops.h in asm/cmpxchg.h
From: Will Deacon @ 2018-06-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527869189-31512-1-git-send-email-will.deacon@arm.com>
The openrisc implementation of asm/cmpxchg.h pulls in linux/bitops.h
so that it can refer to BITS_PER_BYTE. It also transitively relies on
this pulling in linux/compiler.h for READ_ONCE.
Replace the #include with linux/bits.h and linux/compiler.h
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/openrisc/include/asm/cmpxchg.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/openrisc/include/asm/cmpxchg.h b/arch/openrisc/include/asm/cmpxchg.h
index d29f7db53906..f9cd43a39d72 100644
--- a/arch/openrisc/include/asm/cmpxchg.h
+++ b/arch/openrisc/include/asm/cmpxchg.h
@@ -16,8 +16,9 @@
#ifndef __ASM_OPENRISC_CMPXCHG_H
#define __ASM_OPENRISC_CMPXCHG_H
+#include <linux/bits.h>
+#include <linux/compiler.h>
#include <linux/types.h>
-#include <linux/bitops.h>
#define __HAVE_ARCH_CMPXCHG 1
--
2.1.4
^ permalink raw reply related
* [PATCH v2 3/9] asm-generic: Move some macros from linux/bitops.h to a new bits.h file
From: Will Deacon @ 2018-06-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527869189-31512-1-git-send-email-will.deacon@arm.com>
In preparation for implementing the asm-generic atomic bitops in terms
of atomic_long_*, we need to prevent asm/atomic.h implementations from
pulling in linux/bitops.h. A common reason for this include is for the
BITS_PER_BYTE definition, so move this and some other BIT and masking
macros into a new header file, linux/bits.h
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
include/linux/bitops.h | 22 +---------------------
include/linux/bits.h | 26 ++++++++++++++++++++++++++
2 files changed, 27 insertions(+), 21 deletions(-)
create mode 100644 include/linux/bits.h
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 4cac4e1a72ff..af419012d77d 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -2,29 +2,9 @@
#ifndef _LINUX_BITOPS_H
#define _LINUX_BITOPS_H
#include <asm/types.h>
+#include <linux/bits.h>
-#ifdef __KERNEL__
-#define BIT(nr) (1UL << (nr))
-#define BIT_ULL(nr) (1ULL << (nr))
-#define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
-#define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
-#define BIT_ULL_MASK(nr) (1ULL << ((nr) % BITS_PER_LONG_LONG))
-#define BIT_ULL_WORD(nr) ((nr) / BITS_PER_LONG_LONG)
-#define BITS_PER_BYTE 8
#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
-#endif
-
-/*
- * Create a contiguous bitmask starting@bit position @l and ending at
- * position @h. For example
- * GENMASK_ULL(39, 21) gives us the 64bit vector 0x000000ffffe00000.
- */
-#define GENMASK(h, l) \
- (((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h))))
-
-#define GENMASK_ULL(h, l) \
- (((~0ULL) - (1ULL << (l)) + 1) & \
- (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h))))
extern unsigned int __sw_hweight8(unsigned int w);
extern unsigned int __sw_hweight16(unsigned int w);
diff --git a/include/linux/bits.h b/include/linux/bits.h
new file mode 100644
index 000000000000..2b7b532c1d51
--- /dev/null
+++ b/include/linux/bits.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_BITS_H
+#define __LINUX_BITS_H
+#include <asm/bitsperlong.h>
+
+#define BIT(nr) (1UL << (nr))
+#define BIT_ULL(nr) (1ULL << (nr))
+#define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
+#define BIT_ULL_MASK(nr) (1ULL << ((nr) % BITS_PER_LONG_LONG))
+#define BIT_ULL_WORD(nr) ((nr) / BITS_PER_LONG_LONG)
+#define BITS_PER_BYTE 8
+
+/*
+ * Create a contiguous bitmask starting@bit position @l and ending at
+ * position @h. For example
+ * GENMASK_ULL(39, 21) gives us the 64bit vector 0x000000ffffe00000.
+ */
+#define GENMASK(h, l) \
+ (((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h))))
+
+#define GENMASK_ULL(h, l) \
+ (((~0ULL) - (1ULL << (l)) + 1) & \
+ (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h))))
+
+#endif /* __LINUX_BITS_H */
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/9] m68k: Don't use asm-generic/bitops/lock.h
From: Will Deacon @ 2018-06-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527869189-31512-1-git-send-email-will.deacon@arm.com>
asm-generic/bitops/lock.h is shortly going to be built on top of the
atomic_long_* API, which introduces a nasty circular dependency for
m68k where linux/atomic.h pulls in linux/bitops.h via:
linux/atomic.h
asm/atomic.h
linux/irqflags.h
asm/irqflags.h
linux/preempt.h
asm/preempt.h
asm-generic/preempt.h
linux/thread_info.h
asm/thread_info.h
asm/page.h
asm-generic/getorder.h
linux/log2.h
linux/bitops.h
Since m68k isn't SMP and doesn't support ACQUIRE/RELEASE barriers, we
can just define the lock bitops in terms of the atomic bitops in the
asm/bitops.h header.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/m68k/include/asm/bitops.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h
index 93b47b1f6fb4..18193419f97d 100644
--- a/arch/m68k/include/asm/bitops.h
+++ b/arch/m68k/include/asm/bitops.h
@@ -515,12 +515,16 @@ static inline int __fls(int x)
#endif
+/* Simple test-and-set bit locks */
+#define test_and_set_bit_lock test_and_set_bit
+#define clear_bit_unlock clear_bit
+#define __clear_bit_unlock clear_bit_unlock
+
#include <asm-generic/bitops/ext2-atomic.h>
#include <asm-generic/bitops/le.h>
#include <asm-generic/bitops/fls64.h>
#include <asm-generic/bitops/sched.h>
#include <asm-generic/bitops/hweight.h>
-#include <asm-generic/bitops/lock.h>
#endif /* __KERNEL__ */
#endif /* _M68K_BITOPS_H */
--
2.1.4
^ permalink raw reply related
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