* [PATCH v2 1/2] arm64: dts: renesas: r8a77980: add I2C support
From: Sergei Shtylyov @ 2018-05-31 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a88f4e9-0a86-8e6f-0ef2-20913dc9431d@cogentembedded.com>
Define the generic R8A77980 parts of the I2C[0-5] device nodes.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- removed the DMA props for I2C3/4;
- fixed a typo in the patch description;
- added Geert's tag.
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 105 ++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -16,6 +16,15 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -135,6 +144,102 @@
#power-domain-cells = <1>;
};
+ i2c0: i2c at e6500000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6500000 0 0x40>;
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 931>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 931>;
+ dmas = <&dmac1 0x91>, <&dmac1 0x90>,
+ <&dmac2 0x91>, <&dmac2 0x90>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at e6508000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 930>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 930>;
+ dmas = <&dmac1 0x93>, <&dmac1 0x92>,
+ <&dmac2 0x93>, <&dmac2 0x92>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at e6510000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6510000 0 0x40>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 929>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 929>;
+ dmas = <&dmac1 0x95>, <&dmac1 0x94>,
+ <&dmac2 0x95>, <&dmac2 0x94>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at e66d0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d0000 0 0x40>;
+ interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 928>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 928>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at e66d8000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d8000 0 0x40>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 927>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 927>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at e66e0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66e0000 0 0x40>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 919>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 919>;
+ dmas = <&dmac1 0x9b>, <&dmac1 0x9a>,
+ <&dmac2 0x9b>, <&dmac2 0x9a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
hscif0: serial at e6540000 {
compatible = "renesas,hscif-r8a77980",
"renesas,rcar-gen3-hscif",
^ permalink raw reply
* [PATCH 0/2] ARM: LEGO MINDSTORMS EV3 Bluetooth support
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
This series adds Bluetooth support to LEGO MINDSTORMS EV3.
The pwm-clock depends on the common clock framework, so this requires the
recent davinci common clock series to switch to the common clock framework
before it will actually work.
David Lechner (2):
ARM: dts: da850-lego-ev3: Add Bluetooth nodes
ARM: davinci_all_defconfig: Enable Bluetooth
arch/arm/boot/dts/da850-lego-ev3.dts | 82 ++++++++++++++++++++++++++
arch/arm/configs/davinci_all_defconfig | 9 +++
2 files changed, 91 insertions(+)
--
2.17.0
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850-lego-ev3: Add Bluetooth nodes
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531202549.11255-1-david@lechnology.com>
This adds nodes for describing the Bluetooth chip and connections on
LEGO MINDSTORMS EV3 to da850-lego-ev3.dts.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850-lego-ev3.dts | 82 ++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
index bef42dc78817..fe4cc87394b9 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -187,6 +187,15 @@
rechargeable-gpios = <&gpio 136 GPIO_ACTIVE_LOW>;
};
+ bt_slow_clk: bt-clock {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ecap2_pins>, <&bt_clock_bias>;
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&ecap2 0 30518 0>;
+ };
+
/* ARM local RAM */
memory at ffff0000 {
compatible = "syscon", "simple-mfd";
@@ -251,6 +260,20 @@
bias-disable;
};
};
+
+ bt_clock_bias: bt-clock-bias-groups {
+ disable {
+ groups = "cp2";
+ bias-disable;
+ };
+ };
+
+ bt_pic_bias: bt-pic-bias-groups {
+ disable {
+ groups = "cp20";
+ bias-disable;
+ };
+ };
};
/* Input port 1 */
@@ -260,6 +283,22 @@
pinctrl-0 = <&serial1_rxtx_pins>;
};
+&serial2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial2_rxtx_pins>, <&serial2_rtscts_pins>, <&bt_pic_bias>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "ti,cc2560";
+ clocks = <&bt_slow_clk>;
+ clock-names = "ext_clock";
+ enable-gpios = <&gpio 73 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ nvmem-cells = <&bdaddr>;
+ nvmem-cell-names = "bd-address";
+ };
+};
+
&rtc0 {
status = "okay";
};
@@ -278,6 +317,12 @@
pagesize = <64>;
read-only;
reg = <0x50>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bdaddr: bdaddr at 3f06 {
+ reg = <0x3f06 0x06>;
+ };
};
};
@@ -362,6 +407,10 @@
};
};
+&ecap2 {
+ status = "okay";
+};
+
&ehrpwm0 {
status = "okay";
};
@@ -375,6 +424,39 @@
gpios = <6 GPIO_ACTIVE_HIGH>;
output-high;
};
+
+ /* Don't impede Bluetooth clock signal */
+ bt_clock_en {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ };
+
+ /*
+ * There is a PIC microcontroller for interfacing with an Apple MFi
+ * chip. This interferes with normal Bluetooth operation, so we need
+ * to make sure it is turned off. Note: The publicly available
+ * schematics from LEGO don't show that these pins are connected to
+ * anything, but they are present in the source code from LEGO.
+ */
+
+ bt_pic_en {
+ gpio-hog;
+ gpios = <51 GPIO_ACTIVE_HIGH>;
+ output-low;
+ };
+
+ bt_pic_rst {
+ gpio-hog;
+ gpios = <78 GPIO_ACTIVE_HIGH>;
+ output-high;
+ };
+
+ bt_pic_cts {
+ gpio-hog;
+ gpios = <87 GPIO_ACTIVE_HIGH>;
+ input;
+ };
};
&usb_phy {
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] ARM: davinci_all_defconfig: Enable Bluetooth
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531202549.11255-1-david@lechnology.com>
This enables Bluetooth modules in davinic_all_defconfig needed for LEGO
MINDSTORMS EV3.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index a1b6e106b867..f8448c4703c1 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -54,6 +54,13 @@ CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_NETFILTER=y
+CONFIG_BT=m
+CONFIG_BT_RFCOMM=m
+CONFIG_BT_BNEP=m
+CONFIG_BT_HIDP=m
+CONFIG_BT_LEDS=y
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_LL=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_FW_LOADER=m
@@ -113,6 +120,7 @@ CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=3
CONFIG_SERIAL_8250_RUNTIME_UARTS=3
CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_DEV_BUS=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
@@ -212,6 +220,7 @@ CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_OMAP=m
CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
+CONFIG_COMMON_CLK_PWM=m
CONFIG_REMOTEPROC=m
CONFIG_DA8XX_REMOTEPROC=m
CONFIG_MEMORY=y
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: renesas: condor: add I2C0 support
From: Sergei Shtylyov @ 2018-05-31 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a88f4e9-0a86-8e6f-0ef2-20913dc9431d@cogentembedded.com>
Define the Condor board dependent part of the I2C0 device node.
The I2C0 bus is populated by 2 ON Semiconductor PCA9654 I/O expanders
and Analog Devices ADV7511W HDMI transmitter (but we're only describing
the former chips now).
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Changes in version 2:
- added Simon's tag.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 27 ++++++++++++++++++++++++
1 file changed, 27 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -80,6 +80,28 @@
clock-frequency = <32768>;
};
+&i2c0 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ io_expander0: gpio at 20 {
+ compatible = "onnn,pca9654";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ io_expander1: gpio at 21 {
+ compatible = "onnn,pca9654";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
&mmc0 {
pinctrl-0 = <&mmc_pins>;
pinctrl-1 = <&mmc_pins_uhs>;
@@ -104,6 +126,11 @@
function = "canfd0";
};
+ i2c0_pins: i2c0 {
+ groups = "i2c0";
+ function = "i2c0";
+ };
+
mmc_pins: mmc {
groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
function = "mmc";
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Actions Semi S900 clk entries
From: Stephen Boyd @ 2018-05-31 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527780180-15041-1-git-send-email-manivannan.sadhasivam@linaro.org>
Quoting Manivannan Sadhasivam (2018-05-31 08:23:00)
> Add S900 clk entries under ARCH_ACTIONS
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
Unless you wanted me to apply this?
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Actions Semi S900 clk entries
From: Andreas Färber @ 2018-05-31 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152779875340.144038.4898809848995507014@swboyd.mtv.corp.google.com>
Am 31.05.2018 um 22:32 schrieb Stephen Boyd:
> Quoting Manivannan Sadhasivam (2018-05-31 08:23:00)
>> Add S900 clk entries under ARCH_ACTIONS
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> ---
>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
>
> Unless you wanted me to apply this?
I'll take it once I have my 4.17 branches rebased to 4.18.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Rohit Khanna @ 2018-05-31 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In the current implementation, __apply_alternatives patches
flush_icache_range and then executes it without invalidating the icache.
Thus, icache can contain some of the old instructions for
flush_icache_range. This can cause unpredictable behavior as during
execution we can get a mix of old and new instructions for
flush_icache_range.
This patch :
1. Adds a new function clean_dcache_range_nopatch for flushing kernel
memory range. This function uses non hot-patched code and can be
safely used to flush cache during code patching.
2. Modifies __apply_alternatives so that it uses
clean_dcache_range_nopatch to flush the cache range after patching code.
Signed-off-by: Rohit Khanna <rokhanna@nvidia.com>
---
arch/arm64/include/asm/sysreg.h | 3 +++
arch/arm64/kernel/alternative.c | 37 ++++++++++++++++++++++++++++++++++++-
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 6171178075dc..9d1aee7c9aba 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -617,6 +617,9 @@
#define MVFR1_FPDNAN_SHIFT 4
#define MVFR1_FPFTZ_SHIFT 0
+/* SYS_CTR_EL0 */
+#define SYS_CTR_ISIZE_SHIFT 0
+#define SYS_CTR_DSIZE_SHIFT 16
#define ID_AA64MMFR0_TGRAN4_SHIFT 28
#define ID_AA64MMFR0_TGRAN64_SHIFT 24
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 5c4bce4ac381..6b8c5438b37b 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -122,6 +122,41 @@ static void patch_alternative(struct alt_instr *alt,
}
}
+/* This is used for flushing kernel memory range after
+ * __apply_alternatives has patched kernel code
+ */
+static void clean_dcache_range_nopatch(void *start, void *end)
+{
+ u64 d_start, i_start, d_size, i_size, ctr_el0;
+
+ /* use sanitised value of ctr_el0 rather than raw value from CPU */
+ ctr_el0 = read_sanitised_ftr_reg(SYS_CTR_EL0);
+ /* size in bytes */
+ d_size = cpuid_feature_extract_unsigned_field(ctr_el0,
+ SYS_CTR_DSIZE_SHIFT);
+ i_size = cpuid_feature_extract_unsigned_field(ctr_el0,
+ SYS_CTR_ISIZE_SHIFT);
+
+ d_start = (u64)start & ~(d_size - 1);
+ while (d_start <= (u64)end) {
+ /* Use civac instead of cvau. This is required
+ * due to ARM errata 826319, 827319, 824069,
+ * 819472 on A53
+ */
+ asm volatile("dc civac, %0" : : "r" (d_start));
+ d_start += d_size;
+ }
+ dsb(ish);
+
+ i_start = (u64)start & ~(i_size - 1);
+ while (i_start <= (u64)end) {
+ asm volatile("ic ivau, %0" : : "r" (i_start));
+ i_start += i_size;
+ }
+ dsb(ish);
+ isb();
+}
+
static void __apply_alternatives(void *alt_region, bool use_linear_alias)
{
struct alt_instr *alt;
@@ -155,7 +190,7 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
alt_cb(alt, origptr, updptr, nr_inst);
- flush_icache_range((uintptr_t)origptr,
+ clean_dcache_range_nopatch((uintptr_t)origptr,
(uintptr_t)(origptr + nr_inst));
}
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 1/2] ARM: debug: Add Iproc UART3 debug addresses
From: Florian Fainelli @ 2018-05-31 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41bbf801-f060-2056-4015-b4d05c6831bb@broadcom.com>
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.
Either way is fine with me (accepting or dropping) the patch, though
there is probably minimal impact in just accepting such a change.
--
Florian
^ permalink raw reply
* linux-next: manual merge of the regulator tree with the arm-soc tree
From: Janusz Krzysztofik @ 2018-05-31 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaotBXbA4pPFHRH0S1SF7-XX_T6yAOwZcbsR3RBcj+-=Q@mail.gmail.com>
On Wednesday, May 30, 2018 9:29:24 AM CEST Linus Walleij wrote:
> On Wed, May 30, 2018 at 7:07 AM, Stephen Rothwell <sfr@canb.auug.org.au>
wrote:
> > Hi all,
> >
> > Today's linux-next merge of the regulator tree got a conflict in:
> > arch/arm/mach-omap1/board-ams-delta.c
> >
> > between commit:
> > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
> >
> > from the arm-soc tree and commit:
> > 6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
> >
> > from the regulator tree.
> >
> > I fixed it up (see below - it may be better done) and can carry the fix
> > as necessary.
>
> OMG that patch on a patch makes my head spin.
>
> I think I just have to look at the eventual result in linux-next and see if
> it makes proper sense, and rely on Janusz to test the result and help
> to fix it up.
Hi,
I confirm the fix by Stephen works for me, however, the conflicting patch by
Linus breaks things a bit.
Lookup tables added to board files use function name "enable" while the
regulator uses NULL. As a result, GPIO descriptor is not matched and not
assigned to the regulator which ends up running with no control over GPIO pin.
Either the regulator driver should use the function name "enable" or that name
should be removed from lookup tables.
Thanks,
Janusz
^ permalink raw reply
* [RFC PATCH] PCI: mediatek: mtk_pcie_pm_ops can be static
From: kbuild test robot @ 2018-06-01 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527647736-19986-1-git-send-email-honghui.zhang@mediatek.com>
Fixes: 24dc21cd1e9d ("PCI: mediatek: Add system pm support for MT2712")
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
pcie-mediatek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index e3b16b0..e01cc66 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -1256,7 +1256,7 @@ static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
return 0;
}
-const struct dev_pm_ops mtk_pcie_pm_ops = {
+static const struct dev_pm_ops mtk_pcie_pm_ops = {
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
mtk_pcie_resume_noirq)
};
^ permalink raw reply related
* [PATCH] PCI: mediatek: Add system pm support for MT2712
From: kbuild test robot @ 2018-06-01 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527647736-19986-1-git-send-email-honghui.zhang@mediatek.com>
Hi Honghui,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on pci/next]
[also build test WARNING on next-20180531]
[cannot apply to v4.17-rc7]
[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/honghui-zhang-mediatek-com/PCI-mediatek-Add-system-pm-support-for-MT2712/20180601-053217
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/pci/host/pcie-mediatek.c:463:40: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile *address @@ got void [novoid volatile *address @@
drivers/pci/host/pcie-mediatek.c:463:40: expected void volatile *address
drivers/pci/host/pcie-mediatek.c:463:40: got void [noderef] <asn:2>*
drivers/pci/host/pcie-mediatek.c:586:44: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile *address @@ got void [novoid volatile *address @@
drivers/pci/host/pcie-mediatek.c:586:44: expected void volatile *address
drivers/pci/host/pcie-mediatek.c:586:44: got void [noderef] <asn:2>*
>> drivers/pci/host/pcie-mediatek.c:1259:25: sparse: symbol 'mtk_pcie_pm_ops' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Levin @ 2018-06-01 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJK4vrmLBeN_ZeGCXAyqshshL16B0KN_+8uvt+=-O9TEw@mail.gmail.com>
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.
>> + compatible = "rockchip,rk3328-gpio-mute";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> + };
>> +
>> +Note: The gpio_mute node should be declared as the child of the GRF (General
>> +Register File) node. The GPIO_MUTE pin is referred to as <&gpio_mute 0>.
> This is wrong because you should have 2 cells. The phandle doesn't
> count as a cell.
>
> Rob
>
Thanks for pointing that out. So it should be:
?? The GPIO_MUTE pin is referred to as <&gpio_mute 0 POLARITY>.
Thanks,
Levin
^ permalink raw reply
* [PATCH v3] PCI: mediatek: Add system pm support for MT2712
From: honghui.zhang at mediatek.com @ 2018-06-01 3:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Honghui Zhang <honghui.zhang@mediatek.com>
The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
the internal control register will be reset after system resume. The PCIe
link should be re-established and the related control register values
should be re-set after system resume.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
CC: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 60 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index dabf1086..5363cc7 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -132,12 +132,14 @@ struct mtk_pcie_port;
/**
* struct mtk_pcie_soc - differentiate between host generations
* @need_fix_class_id: whether this host's class ID needed to be fixed or not
+ * @pm_support: whether the host's MTCMOS will be off when suspend
* @ops: pointer to configuration access functions
* @startup: pointer to controller setting functions
* @setup_irq: pointer to initialize IRQ functions
*/
struct mtk_pcie_soc {
bool need_fix_class_id;
+ bool pm_support;
struct pci_ops *ops;
int (*startup)(struct mtk_pcie_port *port);
int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
@@ -1179,12 +1181,69 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
}
+#ifdef CONFIG_PM_SLEEP
+static int mtk_pcie_suspend_noirq(struct device *dev)
+{
+ struct mtk_pcie *pcie = dev_get_drvdata(dev);
+ const struct mtk_pcie_soc *soc = pcie->soc;
+ struct mtk_pcie_port *port;
+
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ clk_disable_unprepare(port->ahb_ck);
+ clk_disable_unprepare(port->sys_ck);
+ phy_power_off(port->phy);
+ }
+
+ return 0;
+}
+
+static int mtk_pcie_resume_noirq(struct device *dev)
+{
+ struct mtk_pcie *pcie = dev_get_drvdata(dev);
+ const struct mtk_pcie_soc *soc = pcie->soc;
+ struct mtk_pcie_port *port;
+ int ret;
+
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ phy_power_on(port->phy);
+ clk_prepare_enable(port->sys_ck);
+ clk_prepare_enable(port->ahb_ck);
+
+ ret = soc->startup(port);
+ if (ret) {
+ dev_err(dev, "Port%d link down\n", port->slot);
+ phy_power_off(port->phy);
+ clk_disable_unprepare(port->sys_ck);
+ clk_disable_unprepare(port->ahb_ck);
+ return ret;
+ }
+
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ mtk_pcie_enable_msi(port);
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops mtk_pcie_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
+ mtk_pcie_resume_noirq)
+};
+
static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
.ops = &mtk_pcie_ops,
.startup = mtk_pcie_startup_port,
};
static const struct mtk_pcie_soc mtk_pcie_soc_mt2712 = {
+ .pm_support = true,
.ops = &mtk_pcie_ops_v2,
.startup = mtk_pcie_startup_port_v2,
.setup_irq = mtk_pcie_setup_irq,
@@ -1211,6 +1270,7 @@ static struct platform_driver mtk_pcie_driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
.suppress_bind_attrs = true,
+ .pm = &mtk_pcie_pm_ops,
},
};
builtin_platform_driver(mtk_pcie_driver);
--
2.6.4
^ permalink raw reply related
* [PATCH 6/6] arm64: dts: socionext: Add missing cooling device properties for CPUs
From: Masahiro Yamada @ 2018-06-01 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <744f4c0a9a6f0d3acfc36e49ef62f17f53831b3b.1527225682.git.viresh.kumar@linaro.org>
2018-05-25 14:40 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied to linux-uniphier.
I had already sent a PR for v4.18-rc1 before I received this patch.
Please wait for v4.19-rc1.
Thanks.
> ---
> arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> index 3a5ed789c056..10ffb5019013 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> @@ -58,6 +58,7 @@
> clocks = <&sys_clk 32>;
> enable-method = "psci";
> operating-points-v2 = <&cluster0_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu2: cpu at 100 {
> @@ -77,6 +78,7 @@
> clocks = <&sys_clk 33>;
> enable-method = "psci";
> operating-points-v2 = <&cluster1_opp>;
> + #cooling-cells = <2>;
> };
> };
>
> --
> 2.15.0.194.g9af6a3dea062
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 05/15] arm: dts: uniphier: Add missing cooling device properties for CPUs
From: Masahiro Yamada @ 2018-06-01 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51ac4a5f0466aeed3f223663d9c34d6345b2a1f2.1527244201.git.viresh.kumar@linaro.org>
2018-05-25 19:31 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied to linux-uniphier.
I had already sent a PR for v4.18-rc1 before I received this patch.
Please wait for v4.19-rc1.
Thanks.
> ---
> arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> index debcbd15c24b..40ed15465095 100644
> --- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> @@ -36,6 +36,7 @@
> enable-method = "psci";
> next-level-cache = <&l2>;
> operating-points-v2 = <&cpu_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu2: cpu at 2 {
> @@ -46,6 +47,7 @@
> enable-method = "psci";
> next-level-cache = <&l2>;
> operating-points-v2 = <&cpu_opp>;
> + #cooling-cells = <2>;
> };
>
> cpu3: cpu at 3 {
> @@ -56,6 +58,7 @@
> enable-method = "psci";
> next-level-cache = <&l2>;
> operating-points-v2 = <&cpu_opp>;
> + #cooling-cells = <2>;
> };
> };
>
> --
> 2.15.0.194.g9af6a3dea062
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 0/3] arm64: allwinner: a64: Add initial support for Pinebook
From: Vasily Khoruzhick @ 2018-06-01 6:28 UTC (permalink / raw)
To: linux-arm-kernel
This series adds dts for Pinebook with few prerequisites - PWM and R_I2C
devices nodes.
Andre Przywara (1):
dts: sunxi: A64: Add PWM controllers
Icenowy Zheng (2):
arm64: allwinner: a64: add R_I2C controller
arm64: dts: allwinner: add support for Pinebook
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-a64-pinebook.dts | 285 ++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 45 +++
3 files changed, 331 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
--
2.17.1
^ permalink raw reply
* [PATCH 1/3] arm64: allwinner: a64: add R_I2C controller
From: Vasily Khoruzhick @ 2018-06-01 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601062901.8052-1-anarsoul@gmail.com>
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>
---
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";
+ 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";
+ };
};
r_rsb: rsb at 1f03400 {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/3] dts: sunxi: A64: Add PWM controllers
From: Vasily Khoruzhick @ 2018-06-01 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601062901.8052-1-anarsoul@gmail.com>
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)
---
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";
+ };
+
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";
+ };
};
r_rsb: rsb at 1f03400 {
--
2.17.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: allwinner: add support for Pinebook
From: Vasily Khoruzhick @ 2018-06-01 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601062901.8052-1-anarsoul@gmail.com>
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)
+ */
+
+/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>;
+ 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.
+ */
+&r_i2c {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_i2c_pins_a>;
+ status = "okay";
+};
+
+#include "axp803.dtsi"
+
+®_aldo1 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "vcc-csi";
+};
+
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pl";
+};
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+®_dc1sw {
+ regulator-name = "vcc-lcd";
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-3v3";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vcc-dram";
+};
+
+®_dcdc6 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-sys";
+};
+
+®_dldo1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-hdmi";
+};
+
+®_dldo2 {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-name = "vcc-edp";
+};
+
+®_dldo3 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avdd-csi";
+};
+
+®_dldo4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi";
+};
+
+®_eldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "cpvdd";
+};
+
+®_eldo3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vdd-1v8-csi";
+};
+
+®_fldo1 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vcc-1v2-hsic";
+};
+
+®_fldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-cpus";
+};
+
+®_ldo_io0 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-usb";
+ status = "okay";
+};
+
+®_rtc_ldo {
+ regulator-name = "vcc-rtc";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "host";
+};
+
+&usbphy {
+ usb0_vbus-supply = <®_ldo_io0>;
+ usb1_vbus-supply = <®_ldo_io0>;
+ status = "okay";
+};
--
2.17.1
^ permalink raw reply related
* [PATCH] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: kbuild test robot @ 2018-06-01 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527745851-3339-4-git-send-email-hean.loong.ong@intel.com>
Hi Ong,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.17-rc7 next-20180531]
[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/Hean-Loong-Ong/ARM-drm-ivip-Intel-FPGA-Video-and-Image-Processing-Suite/20180601-132429
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All warnings (new ones prefixed by >>):
In file included from include/linux/cdev.h:8:0,
from include/drm/drmP.h:36,
from drivers/gpu//drm/ivip/intel_vip_core.c:24:
drivers/gpu//drm/ivip/intel_vip_core.c: In function 'intelvipfb_enable':
>> drivers/gpu//drm/ivip/intel_vip_core.c:58:33: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
dev_info(pipe->plane.dev->dev, "Address 0x%x\n", addr);
^
include/linux/device.h:1382:51: note: in definition of macro 'dev_info'
#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
^~~
vim +58 drivers/gpu//drm/ivip/intel_vip_core.c
> 24 #include <drm/drmP.h>
25 #include <drm/drm_atomic.h>
26 #include <drm/drm_atomic_helper.h>
27 #include <drm/drm_crtc_helper.h>
28 #include <drm/drm_fb_helper.h>
29 #include <drm/drm_fb_cma_helper.h>
30 #include <drm/drm_gem_cma_helper.h>
31 #include <drm/drm_plane_helper.h>
32 #include <drm/drm_simple_kms_helper.h>
33 #include <drm/drm_gem_framebuffer_helper.h>
34
35 #include <linux/init.h>
36 #include <linux/kernel.h>
37 #include <linux/module.h>
38
39 #include "intel_vip_drv.h"
40
41 static void intelvipfb_enable(struct drm_simple_display_pipe *pipe,
42 struct drm_crtc_state *crtc_state)
43 {
44 /*
45 * The frameinfo variable has to correspond to the size of the VIP Suite
46 * Frame Reader register 7 which will determine the maximum size used
47 * in this frameinfo
48 */
49
50 u32 frameinfo;
51 struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
52 void __iomem *base = priv->base;
53 struct drm_plane_state *state = pipe->plane.state;
54 dma_addr_t addr;
55
56 addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
57
> 58 dev_info(pipe->plane.dev->dev, "Address 0x%x\n", addr);
59
60 frameinfo =
61 readl(base + INTELVIPFB_FRAME_READER) & 0x00ffffff;
62 writel(frameinfo, base + INTELVIPFB_FRAME_INFO);
63 writel(addr, base + INTELVIPFB_FRAME_START);
64 /* Finally set the control register to 1 to start streaming */
65 writel(1, base + INTELVIPFB_CONTROL);
66 }
67
---
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: 53269 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180601/e8feddf3/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Faiz Abbas @ 2018-06-01 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <678ef467-a235-91db-8bae-f249ad98eac8@ti.com>
Hi,
On Thursday 31 May 2018 06:59 PM, Tero Kristo wrote:
> On 31/05/18 13:14, Faiz Abbas wrote:
>> Hi,
>>
>> On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
>>> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
>>>> Add clkctrl data for the m_can clocks and register it within the
>> ...
>>>> ? diff --git a/include/dt-bindings/clock/dra7.h
>>>> b/include/dt-bindings/clock/dra7.h
>>>> index 5e1061b15aed..d7549c57cac3 100644
>>>> --- a/include/dt-bindings/clock/dra7.h
>>>> +++ b/include/dt-bindings/clock/dra7.h
>>>> @@ -168,5 +168,6 @@
>>>> ? #define DRA7_COUNTER_32K_CLKCTRL??? DRA7_CLKCTRL_INDEX(0x50)
>>>> ? #define DRA7_UART10_CLKCTRL??? DRA7_CLKCTRL_INDEX(0x80)
>>>> ? #define DRA7_DCAN1_CLKCTRL??? DRA7_CLKCTRL_INDEX(0x88)
>>>> +#define DRA7_ADC_CLKCTRL??? DRA7_CLKCTRL_INDEX(0xa0)
>>>
>>> ADC and mcan are the same thing?
>>>
>>
>> The register to control MCAN clocks is called ADC_CLKCTRL, Yes.
>
> Is there any reason for this or is that just a documentation bug?
>
Looks like they meant to have an ADC in dra74 or dra72 but decided
against it and then many years later used the same registers for MCAN
instead. You can see ADC_CLKCTRL exists in dra72 TRM but is explicitly
disabled.
http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf pg:1524
Thanks,
Faiz
^ permalink raw reply
* [PATCH 0/7] add non-strict mode support for arm-smmu-v3
From: Leizhen (ThunderTown) @ 2018-06-01 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92b240f5-596e-87a9-863a-b18475042cce@arm.com>
On 2018/5/31 22:25, Robin Murphy wrote:
> On 31/05/18 14:49, Hanjun Guo wrote:
>> Hi Robin,
>>
>> On 2018/5/31 19:24, Robin Murphy wrote:
>>> On 31/05/18 08:42, Zhen Lei wrote:
>>>> In common, a IOMMU unmap operation follow the below steps:
>>>> 1. remove the mapping in page table of the specified iova range
>>>> 2. execute tlbi command to invalid the mapping which is cached in TLB
>>>> 3. wait for the above tlbi operation to be finished
>>>> 4. free the IOVA resource
>>>> 5. free the physical memory resource
>>>>
>>>> This maybe a problem when unmap is very frequently, the combination of tlbi
>>>> and wait operation will consume a lot of time. A feasible method is put off
>>>> tlbi and iova-free operation, when accumulating to a certain number or
>>>> reaching a specified time, execute only one tlbi_all command to clean up
>>>> TLB, then free the backup IOVAs. Mark as non-strict mode.
>>>>
>>>> But it must be noted that, although the mapping has already been removed in
>>>> the page table, it maybe still exist in TLB. And the freed physical memory
>>>> may also be reused for others. So a attacker can persistent access to memory
>>>> based on the just freed IOVA, to obtain sensible data or corrupt memory. So
>>>> the VFIO should always choose the strict mode.
>>>>
>>>> Some may consider put off physical memory free also, that will still follow
>>>> strict mode. But for the map_sg cases, the memory allocation is not controlled
>>>> by IOMMU APIs, so it is not enforceable.
>>>>
>>>> Fortunately, Intel and AMD have already applied the non-strict mode, and put
>>>> queue_iova() operation into the common file dma-iommu.c., and my work is based
>>>> on it. The difference is that arm-smmu-v3 driver will call IOMMU common APIs to
>>>> unmap, but Intel and AMD IOMMU drivers are not.
>>>>
>>>> Below is the performance data of strict vs non-strict for NVMe device:
>>>> Randomly Read IOPS: 146K(strict) vs 573K(non-strict)
>>>> Randomly Write IOPS: 143K(strict) vs 513K(non-strict)
>>>
>>> What hardware is this on? If it's SMMUv3 without MSIs (e.g. D05), then you'll still be using the rubbish globally-blocking sync implementation. If that is the case, I'd be very interested to see how much there is to gain from just improving that - I've had a patch kicking around for a while[1] (also on a rebased branch at [2]), but don't have the means for serious performance testing.
I will try your patch to see how much it can improve. I think the best way
to resovle the globally-blocking sync is that the hardware provide 64bits
CONS regitster, so that it can never be wrapped, and the spinlock can also
be removed.
>>
>> The hardware is the new D06 which the SMMU with MSIs,
>
> Cool! Now that profiling is fairly useful since we got rid of most of the locks, are you able to get an idea of how the overhead in the normal case is distributed between arm_smmu_cmdq_insert_cmd() and __arm_smmu_sync_poll_msi()? We're always trying to improve our understanding of where command-queue-related overheads turn out to be in practice, and there's still potentially room to do nicer things than TLBI_NH_ALL ;)
Even if the software has no overhead, there may still be a problem, because
the smmu need to execute the commands in sequence, especially before
globally-blocking sync has been removed. Base on the actually execute time
of single tlbi and sync, we can get the upper limit in theory.
BTW, I will reply the reset of mail next week. I'm busy with other things now.
>
> Robin.
>
>> it's not D05 :)
>>
>> Thanks
>> Hanjun
>>
>
> .
>
--
Thanks!
BestRegards
^ permalink raw reply
* [PATCH v1 0/4] add mailbox support for i.MX7D
From: Oleksij Rempel @ 2018-06-01 6:58 UTC (permalink / raw)
To: linux-arm-kernel
This patches are providing support for mailbox (Messaging Unit)
for i.MX7D.
Functionality was tested on PHYTEC phyBOARD-Zeta i.MX7D with
Linux running on all cores: ARM Cortex-A7 and ARM Cortex-M4.
Both parts of i.MX messaging Unit are visible for all CPUs available
on i.MX7D. Communication worked independent of MU side in combination
with CPU. For example MU-A used on ARM Cortex-A7 and MU-B used on ARM Cortex-M4
or other ways around.
The question to NXP developers: are there are limitations or
recommendations about MU vs CPU combination? The i.MX7D documentation
talks about "Processor A" and "Processor B". It is not quite clear what
processor it actually is (A7 or M4).
Oleksij Rempel (4):
clk: imx7d: add IMX7D_MU_ROOT_CLK
dt-bindings: mailbox: provide imx-mailbox documentation
ARM: dts: imx7s: add i.MX7 messaging unit support
mailbox: Add support for i.MX7D messaging unit
.../bindings/mailbox/imx-mailbox.txt | 35 +++
arch/arm/boot/dts/imx7s.dtsi | 18 ++
drivers/clk/imx/clk-imx7d.c | 1 +
drivers/mailbox/Kconfig | 6 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/imx-mailbox.c | 289 ++++++++++++++++++
6 files changed, 351 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
create mode 100644 drivers/mailbox/imx-mailbox.c
--
2.17.1
^ permalink raw reply
* [PATCH v1 1/4] clk: imx7d: add IMX7D_MU_ROOT_CLK
From: Oleksij Rempel @ 2018-06-01 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601065821.28234-1-o.rempel@pengutronix.de>
This clock is needed for iMX mailbox driver
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/clk/imx/clk-imx7d.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 975a20d3cc94..1c2541dc40e7 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -793,6 +793,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_DRAM_PHYM_ROOT_CLK] = imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130, 0);
clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] = imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div", base + 0x4130, 0);
clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", "dram_alt_post_div", base + 0x4130, 0);
+ clks[IMX7D_MU_ROOT_CLK] = imx_clk_gate2("mu_root_clk", "ipg_root_clk", base + 0x4270, 0);
clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base + 0x4230, 0);
clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk", base + 0x4250, 0);
clks[IMX7D_CAAM_CLK] = imx_clk_gate4("caam_clk", "ipg_root_clk", base + 0x4240, 0);
--
2.17.1
^ 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