* [PATCH] ARM: Kconfig: select GENERIC_CLOCKEVENTS_BROADCAST also on UP
From: Lucas Stach @ 2016-09-16 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609161223311.5384@nanos>
Am Freitag, den 16.09.2016, 12:30 +0200 schrieb Thomas Gleixner:
> On Fri, 16 Sep 2016, Russell King - ARM Linux wrote:
> > On Fri, Sep 16, 2016 at 11:32:20AM +0200, Lucas Stach wrote:
> > > Hi Russell,
> > >
> > > can you please take a look at this and tell if there is something wrong
> > > about it, or if you think it can go in?
> > >
> > > Without this patch the kernel is unable to use the deeper CPU idle
> > > states on i.MX6S if it isn't built with SMP support enabled.
> >
> > Without spending a lot of time digging into this code, working out what
> > these configuration symbols do, I frankly don't know if it's a sensible
> > thing to do or not. I guess tglx knows this code like the back of his
> > hand, and would be in a better position to comment.
> >
> > There's two factors there:
> > 1. the amount of undocumented code in the kernel needing the code to be
> > read and understood to understand various aspects of it from the
> > architecture point of view.
>
> Yeah. I know that this stuff lacks documentation.
>
> > 2. your architecture maintainer has done very little actual platform
> > development (not through his own choice) for the last 10 or so years,
> > which means he's not had to dig into these areas.
> >
> > So, I'm afraid I feel less than qualified on this at the moment. I'll
> > try to look into this and talk to tglx to work out whether it's a
> > sensible change.
>
> The broadcast feature has the following functionality:
>
> It lets you use fast accessible (cpu local) timers for normal operation
> and in case of deep idle sleeps where the cpu local timer stops switch
> to broadcast operation, which arms a slower to access (global) timer
> device which does not stop in deep idle.
>
> On UP we usually just use the global device, but on SMP we need the cpu
> local timers for normal (non idle) operation. Though there is no reason
> to restrict this UP from a technical POV especially when the local
> timer is way cheaper to access than the other device.
>
> Hope that helps.
What I take from this is that the i.MX6 decision to use the local timer
for normal operation on UP is sane, as it's both cheaper to access, as
well as providing higher accuracy.
In fact this behavior has been explicitly enabled by a patch "ARM: imx:
always use TWD on IMX6Q" from Sebastian Andrzej Siewior to get better
responsiveness in cyclictest.
So the subject patch is actually a regression fix, as we now need the
timer broadcast infrastructure to be able to use the deeper idle states,
instead of having them enabled by always using the global timer on UP.
Russell, okay to put it in the patch system?
Regards,
Lucas
^ permalink raw reply
* [PATCH v2] dmaengine: s3c24xx: Add dma_slave_map for s3c2440 devices
From: Sylwester Nawrocki @ 2016-09-16 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473968506-4150-1-git-send-email-sam.van.den.berge@telenet.be>
On 09/15/2016 09:41 PM, Sam Van Den Berge wrote:
> @@ -445,10 +446,44 @@ static struct s3c24xx_dma_channel s3c2440_dma_channels[DMACH_MAX] = {
> [DMACH_USB_EP4] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(4, 3), },
> };
>
> +static const struct dma_slave_map s3c2440_dma_slave_map[] = {
> + /* TODO: DMACH_XD0 */
> + /* TODO: DMACH_XD1 */
> + { "3c2440-sdi", "rx-tx", (void *)DMACH_SDI },
Thanks for the patch, still device name needs to be changed here
to "s3c2440-sdi".
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH v7 08/11] arm64: dts: r8a7796: add SDHI nodes
From: Simon Horman @ 2016-09-16 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916103048.GL1411@katana>
On Fri, Sep 16, 2016 at 12:30:48PM +0200, Wolfram Sang wrote:
> On Tue, Sep 13, 2016 at 12:57:05PM +0200, Simon Horman wrote:
> > Add SDHI nodes to the DT of the r8a7796 SoC.
> >
> > Based on the DT of the r8a7795 SoC.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> If you remove the two lines you removed from H3 already:
Thanks, done.
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
^ permalink raw reply
* [PATCH] dmaengine: omap-dma: Enable burst and data pack for SG
From: Peter Ujfalusi @ 2016-09-16 10:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Misael Lopez Cruz <misael.lopez@ti.com>
Enable the burst and data pack modes for the scatter-gather
in order to improve the throughput of the data transfers.
The improvement has been verified with MMC HS200 mode in
the DRA72 EVM using the iozone tool to compare the read
throughput (in kB/s) with and without burst/pack for
different reclens (in kB).
With
reclen Baseline sDMA burst/pack
------ -------- ---------------
64 46568 50820
128 57564 63413
256 65634 74937
512 72427 83483
1024 74563 84504
2048 76265 86079
4096 78045 87335
8192 78989 88154
16384 81265 91034
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/omap-dma.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 1b7f5f32bf74..7ca27d4b1c54 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -904,13 +904,16 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
d->es = es;
d->ccr = c->ccr | CCR_SYNC_FRAME;
- if (dir == DMA_DEV_TO_MEM)
+ if (dir == DMA_DEV_TO_MEM) {
d->ccr |= CCR_DST_AMODE_POSTINC | CCR_SRC_AMODE_CONSTANT;
- else
+ d->csdp = CSDP_DST_BURST_64 | CSDP_DST_PACKED;
+ } else {
d->ccr |= CCR_DST_AMODE_CONSTANT | CCR_SRC_AMODE_POSTINC;
+ d->csdp = CSDP_SRC_BURST_64 | CSDP_SRC_PACKED;
+ }
d->cicr = CICR_DROP_IE | CICR_BLOCK_IE;
- d->csdp = es;
+ d->csdp |= es;
if (dma_omap1()) {
d->cicr |= CICR_TOUT_IE;
--
2.10.0
^ permalink raw reply related
* [PATCH v7 07/11] ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104
From: Simon Horman @ 2016-09-16 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916102710.GJ1411@katana>
On Fri, Sep 16, 2016 at 12:27:10PM +0200, Wolfram Sang wrote:
> On Tue, Sep 13, 2016 at 12:57:04PM +0200, Simon Horman wrote:
> > Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1}.
> > And the sd-uhs-sdr104 property to SDHI0.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> If you drop sdr104 here for now as well:
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Thanks, done.
The result is as follows:
From: Simon Horman <horms+renesas@verge.net.au>
Date: Tue, 13 Sep 2016 12:57:04 +0200
Subject: [PATCH] ARM: dts: alt: enable UHS for SDHI 0 & 1
Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1}.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7794-alt.dts | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index 8d1b35afaf82..325d3f972c57 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -207,11 +207,25 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
};
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
};
};
@@ -255,23 +269,27 @@
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi0>;
vqmmc-supply = <&vccq_sdhi0>;
cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
status = "okay";
};
&sdhi1 {
pinctrl-0 = <&sdhi1_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi1_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi1>;
vqmmc-supply = <&vccq_sdhi1>;
cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
status = "okay";
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: aspeed: Enable BT IPMI BMC device
From: Cédric Le Goater @ 2016-09-16 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474022367-21029-1-git-send-email-clg@kaod.org>
Signed-off-by: C?dric Le Goater <clg@kaod.org>
---
Changes since v1:
- added the soc name ast2400 in the compatible cell
arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
arch/arm/boot/dts/aspeed-g5.dtsi | 6 ++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 22dee5937d5c..7bb00b6f13d8 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -82,6 +82,12 @@
clocks = <&clk_apb>;
};
+ ibt: ibt at 1e789140 {
+ compatible = "aspeed,ast2400-bt-bmc";
+ reg = <0x1e789140 0x18>;
+ interrupts = <8>;
+ };
+
wdt1: wdt at 1e785000 {
compatible = "aspeed,wdt";
reg = <0x1e785000 0x1c>;
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index dd94d9361fda..1d8f81b548b3 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -86,6 +86,12 @@
clocks = <&clk_apb>;
};
+ ibt: ibt at 1e789140 {
+ compatible = "aspeed,ast2400-bt-bmc";
+ reg = <0x1e789140 0x18>;
+ interrupts = <8>;
+ };
+
wdt1: wdt at 1e785000 {
compatible = "aspeed,wdt";
reg = <0x1e785000 0x1c>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] ARM: aspeed: Add defconfigs for CONFIG_ASPEED_BT_IPMI_BMC
From: Cédric Le Goater @ 2016-09-16 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474022367-21029-1-git-send-email-clg@kaod.org>
Signed-off-by: C?dric Le Goater <clg@kaod.org>
---
Changes since v1:
- renamed config option
arch/arm/configs/aspeed_g4_defconfig | 1 +
arch/arm/configs/aspeed_g5_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index ca39c04fec6b..af3847db00f8 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -53,6 +53,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_ASPEED_BT_IPMI_BMC=y
# CONFIG_HW_RANDOM is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index 4f366b0370e9..5d46290736fb 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -54,6 +54,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_ASPEED_BT_IPMI_BMC=y
# CONFIG_HW_RANDOM is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_IOMMU_SUPPORT is not set
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Cédric Le Goater @ 2016-09-16 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474022367-21029-1-git-send-email-clg@kaod.org>
From: Alistair Popple <alistair@popple.id.au>
This patch adds a simple device driver to expose the iBT interface on
Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
commonly used as BMCs (BaseBoard Management Controllers) and this
driver implements the BMC side of the BT interface.
The BT (Block Transfer) interface is used to perform in-band IPMI
communication between a host and its BMC. Entire messages are buffered
before sending a notification to the other end, host or BMC, that
there is data to be read. Usually, the host emits requests and the BMC
responses but the specification provides a mean for the BMC to send
SMS Attention (BMC-to-Host attention or System Management Software
attention) messages.
For this purpose, the driver introduces a specific ioctl on the
device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
on the BMC to signal the host of such an event.
The device name defaults to '/dev/ipmi-bt-host'
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
[clg: - checkpatch fixes
- added a devicetree binding documentation
- replace 'bt_host' by 'bt_bmc' to reflect that the driver is
the BMC side of the IPMI BT interface
- renamed the device to 'ipmi-bt-host'
- introduced a temporary buffer to copy_{to,from}_user
- used platform_get_irq()
- moved the driver under drivers/char/ipmi/ but kept it as a misc
device
- changed the compatible cell to "aspeed,ast2400-bt-bmc"
]
Signed-off-by: C?dric Le Goater <clg@kaod.org>
---
Changes since v1:
- replace 'bt_host' by 'bt_bmc' to reflect that the driver is
the BMC side of the IPMI BT interface
- renamed the device to 'ipmi-bt-host'
- introduced a temporary buffer to copy_{to,from}_user
- used platform_get_irq()
- moved the driver under drivers/char/ipmi/ but kept it as a misc
device
- changed the compatible cell to "aspeed,ast2400-bt-bmc"
.../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
drivers/Makefile | 2 +-
drivers/char/ipmi/Kconfig | 7 +
drivers/char/ipmi/Makefile | 1 +
drivers/char/ipmi/bt-bmc.c | 486 +++++++++++++++++++++
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/bt-bmc.h | 18 +
7 files changed, 537 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
create mode 100644 drivers/char/ipmi/bt-bmc.c
create mode 100644 include/uapi/linux/bt-bmc.h
diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
new file mode 100644
index 000000000000..fbbacd958240
--- /dev/null
+++ b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
@@ -0,0 +1,23 @@
+* Aspeed BT (Block Transfer) IPMI interface
+
+The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs
+(BaseBoard Management Controllers) and the BT interface can be used to
+perform in-band IPMI communication with their host.
+
+Required properties:
+
+- compatible : should be "aspeed,ast2400-bt-bmc"
+- reg: physical address and size of the registers
+
+Optional properties:
+
+- interrupts: interrupt generated by the BT interface. without an
+ interrupt, the driver will operate in poll mode.
+
+Example:
+
+ ibt at 1e789140 {
+ compatible = "aspeed,ast2400-bt-bmc";
+ reg = <0x1e789140 0x18>;
+ interrupts = <8>;
+ };
diff --git a/drivers/Makefile b/drivers/Makefile
index 53abb4a5f736..5a9e7b6b7928 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -21,7 +21,7 @@ obj-y += video/
obj-y += idle/
# IPMI must come before ACPI in order to provide IPMI opregion support
-obj-$(CONFIG_IPMI_HANDLER) += char/ipmi/
+obj-y += char/ipmi/
obj-$(CONFIG_ACPI) += acpi/
obj-$(CONFIG_SFI) += sfi/
diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index 5a9350b1069a..2c234e3e7513 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -76,3 +76,10 @@ config IPMI_POWEROFF
the IPMI management controller is capable of this.
endif # IPMI_HANDLER
+
+config ASPEED_BT_IPMI_BMC
+ tristate "BT IPMI bmc driver"
+ help
+ Provides a driver for the BT (Block Transfer) IPMI interface
+ found on Aspeed SOCs (AST2400 and AST2500). The driver
+ implements the BMC side of the BT interface.
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index f3ffde1f5f1f..0d98cd91def1 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
+obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
new file mode 100644
index 000000000000..b96cb421e1c2
--- /dev/null
+++ b/drivers/char/ipmi/bt-bmc.c
@@ -0,0 +1,486 @@
+/*
+ * Copyright (c) 2015-2016, IBM Corporation.
+ *
+ * This program 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.
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/errno.h>
+#include <linux/poll.h>
+#include <linux/sched.h>
+#include <linux/spinlock.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/miscdevice.h>
+#include <linux/timer.h>
+#include <linux/jiffies.h>
+#include <linux/bt-bmc.h>
+
+/*
+ * This is a BMC device used to communicate to the host
+ */
+#define DEVICE_NAME "ipmi-bt-host"
+
+#define BT_IO_BASE 0xe4
+#define BT_IRQ 10
+
+#define BT_CR0 0x0
+#define BT_CR0_IO_BASE 16
+#define BT_CR0_IRQ 12
+#define BT_CR0_EN_CLR_SLV_RDP 0x8
+#define BT_CR0_EN_CLR_SLV_WRP 0x4
+#define BT_CR0_ENABLE_IBT 0x1
+#define BT_CR1 0x4
+#define BT_CR1_IRQ_H2B 0x01
+#define BT_CR1_IRQ_HBUSY 0x40
+#define BT_CR2 0x8
+#define BT_CR2_IRQ_H2B 0x01
+#define BT_CR2_IRQ_HBUSY 0x40
+#define BT_CR3 0xc
+#define BT_CTRL 0x10
+#define BT_CTRL_B_BUSY 0x80
+#define BT_CTRL_H_BUSY 0x40
+#define BT_CTRL_OEM0 0x20
+#define BT_CTRL_SMS_ATN 0x10
+#define BT_CTRL_B2H_ATN 0x08
+#define BT_CTRL_H2B_ATN 0x04
+#define BT_CTRL_CLR_RD_PTR 0x02
+#define BT_CTRL_CLR_WR_PTR 0x01
+#define BT_BMC2HOST 0x14
+#define BT_INTMASK 0x18
+#define BT_INTMASK_B2H_IRQEN 0x01
+#define BT_INTMASK_B2H_IRQ 0x02
+#define BT_INTMASK_BMC_HWRST 0x80
+
+struct bt_bmc {
+ struct device dev;
+ struct miscdevice miscdev;
+ void __iomem *base;
+ int open_count;
+ int irq;
+ wait_queue_head_t queue;
+ struct timer_list poll_timer;
+};
+
+static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
+{
+ return ioread8(bt_bmc->base + reg);
+}
+
+static void bt_outb(struct bt_bmc *bt_bmc, u8 data, int reg)
+{
+ iowrite8(data, bt_bmc->base + reg);
+}
+
+static void clr_rd_ptr(struct bt_bmc *bt_bmc)
+{
+ bt_outb(bt_bmc, BT_CTRL_CLR_RD_PTR, BT_CTRL);
+}
+
+static void clr_wr_ptr(struct bt_bmc *bt_bmc)
+{
+ bt_outb(bt_bmc, BT_CTRL_CLR_WR_PTR, BT_CTRL);
+}
+
+static void clr_h2b_atn(struct bt_bmc *bt_bmc)
+{
+ bt_outb(bt_bmc, BT_CTRL_H2B_ATN, BT_CTRL);
+}
+
+static void set_b_busy(struct bt_bmc *bt_bmc)
+{
+ if (!(bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_B_BUSY))
+ bt_outb(bt_bmc, BT_CTRL_B_BUSY, BT_CTRL);
+}
+
+static void clr_b_busy(struct bt_bmc *bt_bmc)
+{
+ if (bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_B_BUSY)
+ bt_outb(bt_bmc, BT_CTRL_B_BUSY, BT_CTRL);
+}
+
+static void set_b2h_atn(struct bt_bmc *bt_bmc)
+{
+ bt_outb(bt_bmc, BT_CTRL_B2H_ATN, BT_CTRL);
+}
+
+static u8 bt_read(struct bt_bmc *bt_bmc)
+{
+ return bt_inb(bt_bmc, BT_BMC2HOST);
+}
+
+static ssize_t bt_readn(struct bt_bmc *bt_bmc, u8 *buf, size_t n)
+{
+ int i;
+
+ for (i = 0; i < n; i++)
+ buf[i] = bt_read(bt_bmc);
+ return n;
+}
+
+static void bt_write(struct bt_bmc *bt_bmc, u8 c)
+{
+ bt_outb(bt_bmc, c, BT_BMC2HOST);
+}
+
+static ssize_t bt_writen(struct bt_bmc *bt_bmc, u8 *buf, size_t n)
+{
+ int i;
+
+ for (i = 0; i < n; i++)
+ bt_write(bt_bmc, buf[i]);
+ return n;
+}
+
+static void set_sms_atn(struct bt_bmc *bt_bmc)
+{
+ bt_outb(bt_bmc, BT_CTRL_SMS_ATN, BT_CTRL);
+}
+
+static struct bt_bmc *file_bt_bmc(struct file *file)
+{
+ return container_of(file->private_data, struct bt_bmc, miscdev);
+}
+
+static int bt_bmc_open(struct inode *inode, struct file *file)
+{
+ struct bt_bmc *bt_bmc = file_bt_bmc(file);
+
+ clr_b_busy(bt_bmc);
+
+ return 0;
+}
+
+#define BT_BMC_BUFFER_SIZE 256
+
+/*
+ * The BT (Block Transfer) interface means that entire messages are
+ * buffered by the host before a notification is sent to the BMC that
+ * there is data to be read. The first byte is the length and the
+ * message data follows. The read operation just tries to capture the
+ * whole before returning it to userspace.
+ */
+static ssize_t bt_bmc_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct bt_bmc *bt_bmc = file_bt_bmc(file);
+ u8 len;
+ int len_byte = 1;
+ u8 kbuffer[BT_BMC_BUFFER_SIZE];
+ ssize_t ret = 0;
+ ssize_t nread;
+
+ if (!access_ok(VERIFY_WRITE, buf, count))
+ return -EFAULT;
+
+ WARN_ON(*ppos);
+
+ if (wait_event_interruptible(bt_bmc->queue,
+ bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN))
+ return -ERESTARTSYS;
+
+ set_b_busy(bt_bmc);
+ clr_h2b_atn(bt_bmc);
+ clr_rd_ptr(bt_bmc);
+
+ /*
+ * The BT frames start with the message length, which does not
+ * include the length byte.
+ */
+ kbuffer[0] = bt_read(bt_bmc);
+ len = kbuffer[0];
+
+ /* We pass the length back to userspace as well */
+ if (len + 1 > count)
+ len = count - 1;
+
+ while (len) {
+ nread = min_t(ssize_t, len, sizeof(kbuffer) - len_byte);
+
+ bt_readn(bt_bmc, kbuffer + len_byte, nread);
+
+ if (copy_to_user(buf, kbuffer, nread + len_byte)) {
+ ret = -EFAULT;
+ break;
+ }
+ len -= nread;
+ buf += nread + len_byte;
+ ret += nread + len_byte;
+ len_byte = 0;
+ }
+
+ clr_b_busy(bt_bmc);
+
+ return ret;
+}
+
+static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct bt_bmc *bt_bmc = file_bt_bmc(file);
+ u8 kbuffer[BT_BMC_BUFFER_SIZE];
+ ssize_t ret = 0;
+ ssize_t nwritten;
+
+ if (!access_ok(VERIFY_READ, buf, count))
+ return -EFAULT;
+
+ WARN_ON(*ppos);
+
+ /* There's no interrupt for clearing bmc busy so we have to
+ * poll
+ */
+ if (wait_event_interruptible(bt_bmc->queue,
+ !(bt_inb(bt_bmc, BT_CTRL) &
+ (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN))))
+ return -ERESTARTSYS;
+
+ clr_wr_ptr(bt_bmc);
+
+ while (count) {
+ nwritten = min_t(ssize_t, count, sizeof(kbuffer));
+ if (copy_from_user(&kbuffer, buf, nwritten)) {
+ ret = -EFAULT;
+ break;
+ }
+
+ bt_writen(bt_bmc, kbuffer, nwritten);
+
+ count -= nwritten;
+ buf += nwritten;
+ ret += nwritten;
+ }
+
+ set_b2h_atn(bt_bmc);
+
+ return ret;
+}
+
+static long bt_bmc_ioctl(struct file *file, unsigned int cmd,
+ unsigned long param)
+{
+ struct bt_bmc *bt_bmc = file_bt_bmc(file);
+
+ switch (cmd) {
+ case BT_BMC_IOCTL_SMS_ATN:
+ set_sms_atn(bt_bmc);
+ return 0;
+ }
+ return -EINVAL;
+}
+
+static int bt_bmc_release(struct inode *inode, struct file *file)
+{
+ struct bt_bmc *bt_bmc = file_bt_bmc(file);
+
+ set_b_busy(bt_bmc);
+ return 0;
+}
+
+static unsigned int bt_bmc_poll(struct file *file, poll_table *wait)
+{
+ struct bt_bmc *bt_bmc = file_bt_bmc(file);
+ unsigned int mask = 0;
+ uint8_t ctrl;
+
+ poll_wait(file, &bt_bmc->queue, wait);
+
+ ctrl = bt_inb(bt_bmc, BT_CTRL);
+
+ if (ctrl & BT_CTRL_H2B_ATN)
+ mask |= POLLIN;
+
+ if (!(ctrl & (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN)))
+ mask |= POLLOUT;
+
+ return mask;
+}
+
+static const struct file_operations bt_bmc_fops = {
+ .owner = THIS_MODULE,
+ .open = bt_bmc_open,
+ .read = bt_bmc_read,
+ .write = bt_bmc_write,
+ .release = bt_bmc_release,
+ .poll = bt_bmc_poll,
+ .unlocked_ioctl = bt_bmc_ioctl,
+};
+
+static void poll_timer(unsigned long data)
+{
+ struct bt_bmc *bt_bmc = (void *)data;
+
+ bt_bmc->poll_timer.expires += msecs_to_jiffies(500);
+ wake_up(&bt_bmc->queue);
+ add_timer(&bt_bmc->poll_timer);
+}
+
+static irqreturn_t bt_bmc_irq(int irq, void *arg)
+{
+ struct bt_bmc *bt_bmc = arg;
+ uint32_t reg;
+
+ reg = ioread32(bt_bmc->base + BT_CR2);
+ reg &= BT_CR2_IRQ_H2B | BT_CR2_IRQ_HBUSY;
+ if (!reg)
+ return IRQ_NONE;
+
+ /* ack pending IRQs */
+ iowrite32(reg, bt_bmc->base + BT_CR2);
+
+ wake_up(&bt_bmc->queue);
+ return IRQ_HANDLED;
+}
+
+static int bt_bmc_config_irq(struct bt_bmc *bt_bmc,
+ struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ uint32_t reg;
+ int rc;
+
+ bt_bmc->irq = platform_get_irq(pdev, 0);
+ if (!bt_bmc->irq)
+ return -ENODEV;
+
+ rc = devm_request_irq(dev, bt_bmc->irq, bt_bmc_irq, IRQF_SHARED,
+ DEVICE_NAME, bt_bmc);
+ if (rc < 0) {
+ dev_warn(dev, "Unable to request IRQ %d\n", bt_bmc->irq);
+ bt_bmc->irq = 0;
+ return rc;
+ }
+
+ /* Configure IRQs on the bmc clearing the H2B and HBUSY bits;
+ * H2B will be asserted when the bmc has data for us; HBUSY
+ * will be cleared (along with B2H) when we can write the next
+ * message to the BT buffer
+ */
+ reg = ioread32(bt_bmc->base + BT_CR1);
+ reg |= BT_CR1_IRQ_H2B | BT_CR1_IRQ_HBUSY;
+ iowrite32(reg, bt_bmc->base + BT_CR1);
+
+ return 0;
+}
+
+static int bt_bmc_probe(struct platform_device *pdev)
+{
+ struct bt_bmc *bt_bmc;
+ struct device *dev;
+ struct resource *res;
+ int rc;
+
+ if (!pdev || !pdev->dev.of_node)
+ return -ENODEV;
+
+ dev = &pdev->dev;
+ dev_info(dev, "Found bt bmc device\n");
+
+ bt_bmc = devm_kzalloc(dev, sizeof(*bt_bmc), GFP_KERNEL);
+ if (!bt_bmc)
+ return -ENOMEM;
+
+ dev_set_drvdata(&pdev->dev, bt_bmc);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, "Unable to find resources\n");
+ rc = -ENXIO;
+ goto out_free;
+ }
+
+ bt_bmc->base = devm_ioremap_resource(&pdev->dev, res);
+ if (!bt_bmc->base) {
+ rc = -ENOMEM;
+ goto out_free;
+ }
+
+ init_waitqueue_head(&bt_bmc->queue);
+
+ bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
+ bt_bmc->miscdev.name = DEVICE_NAME,
+ bt_bmc->miscdev.fops = &bt_bmc_fops,
+ bt_bmc->miscdev.parent = dev;
+ rc = misc_register(&bt_bmc->miscdev);
+ if (rc) {
+ dev_err(dev, "Unable to register device\n");
+ goto out_unmap;
+ }
+
+ bt_bmc_config_irq(bt_bmc, pdev);
+
+ if (bt_bmc->irq) {
+ dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
+ } else {
+ dev_info(dev, "No IRQ; using timer\n");
+ setup_timer(&bt_bmc->poll_timer, poll_timer,
+ (unsigned long)bt_bmc);
+ bt_bmc->poll_timer.expires = jiffies + msecs_to_jiffies(10);
+ add_timer(&bt_bmc->poll_timer);
+ }
+
+ iowrite32((BT_IO_BASE << BT_CR0_IO_BASE) |
+ (BT_IRQ << BT_CR0_IRQ) |
+ BT_CR0_EN_CLR_SLV_RDP |
+ BT_CR0_EN_CLR_SLV_WRP |
+ BT_CR0_ENABLE_IBT,
+ bt_bmc->base + BT_CR0);
+
+ clr_b_busy(bt_bmc);
+
+ return 0;
+
+out_unmap:
+ devm_iounmap(&pdev->dev, bt_bmc->base);
+
+out_free:
+ devm_kfree(dev, bt_bmc);
+ return rc;
+
+}
+
+static int bt_bmc_remove(struct platform_device *pdev)
+{
+ struct bt_bmc *bt_bmc = dev_get_drvdata(&pdev->dev);
+
+ misc_deregister(&bt_bmc->miscdev);
+ if (!bt_bmc->irq)
+ del_timer_sync(&bt_bmc->poll_timer);
+ devm_iounmap(&pdev->dev, bt_bmc->base);
+ devm_kfree(&pdev->dev, bt_bmc);
+ bt_bmc = NULL;
+
+ return 0;
+}
+
+static const struct of_device_id bt_bmc_match[] = {
+ { .compatible = "aspeed,ast2400-bt-bmc" },
+ { },
+};
+
+static struct platform_driver bt_bmc_driver = {
+ .driver = {
+ .name = DEVICE_NAME,
+ .of_match_table = bt_bmc_match,
+ },
+ .probe = bt_bmc_probe,
+ .remove = bt_bmc_remove,
+};
+
+module_platform_driver(bt_bmc_driver);
+
+MODULE_DEVICE_TABLE(of, bt_bmc_match);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alistair Popple <alistair@popple.id.au>");
+MODULE_DESCRIPTION("Linux device interface to the BT interface");
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 185f8ea2702f..17b12942c67d 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -74,6 +74,7 @@ header-y += bpf_common.h
header-y += bpf.h
header-y += bpqether.h
header-y += bsg.h
+header-y += bt-bmc.h
header-y += btrfs.h
header-y += can.h
header-y += capability.h
diff --git a/include/uapi/linux/bt-bmc.h b/include/uapi/linux/bt-bmc.h
new file mode 100644
index 000000000000..d9ec766a63d0
--- /dev/null
+++ b/include/uapi/linux/bt-bmc.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (c) 2015-2016, IBM Corporation.
+ *
+ * This program 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.
+ */
+
+#ifndef _UAPI_LINUX_BT_BMC_H
+#define _UAPI_LINUX_BT_BMC_H
+
+#include <linux/ioctl.h>
+
+#define __BT_BMC_IOCTL_MAGIC 0xb1
+#define BT_BMC_IOCTL_SMS_ATN _IO(__BT_BMC_IOCTL_MAGIC, 0x00)
+
+#endif /* _UAPI_LINUX_BT_BMC_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/3] ARM: aspeed: add support for the BT IPMI interface
From: Cédric Le Goater @ 2016-09-16 10:39 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This serie adds support for the iBT interface on Aspeed SOCs (AST2400
and AST2500). The BT (Block Transfer) interface is used to perform
in-band IPMI communication between a host and its BMC. This driver
implements the BMC side.
Most noticeable changes in v2 are:
- the driver is now called 'bt-bmc' and the device node '/dev/ipmi-bt-host'
- the code is now under drivers/char/ipmi/. This required a change of
the top Makefile in drivers/ to compile the bt-bmc driver with the
ipmi handlers not being selected. That might be an issue.
- changed the read/write operations to use a temporary buffer and get
rid of the {get,put}_user calls
Thanks,
C.
Alistair Popple (1):
misc: Add Aspeed BT IPMI BMC driver
C?dric Le Goater (2):
ARM: aspeed: Add defconfigs for CONFIG_ASPEED_BT_IPMI_BMC
ARM: dts: aspeed: Enable BT IPMI BMC device
.../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
arch/arm/boot/dts/aspeed-g5.dtsi | 6 +
arch/arm/configs/aspeed_g4_defconfig | 1 +
arch/arm/configs/aspeed_g5_defconfig | 1 +
drivers/Makefile | 2 +-
drivers/char/ipmi/Kconfig | 7 +
drivers/char/ipmi/Makefile | 1 +
drivers/char/ipmi/bt-bmc.c | 486 +++++++++++++++++++++
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/bt-bmc.h | 18 +
11 files changed, 551 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
create mode 100644 drivers/char/ipmi/bt-bmc.c
create mode 100644 include/uapi/linux/bt-bmc.h
--
2.7.4
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Robin Murphy @ 2016-09-16 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2210422.ogrYIr1eQU@avalon>
On 16/09/16 10:48, Laurent Pinchart wrote:
> Hi Arnd,
>
> On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
>> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
>>> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
>>>> On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
>>>>> Hi,
>>>>>
>>>>> This series tries to solve the problem with DMA with device registers
>>>>> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
>>>>> recent patch '9575632 (dmaengine: make slave address physical)'
>>>>> clarifies that DMA slave address provided by clients is the physical
>>>>> address. This puts the task of mapping the DMA slave address from a
>>>>> phys_addr_t to a dma_addr_t on the DMA engine.
>>>>>
>>>>> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
>>>>> the same and no special care is needed. However if you have a IOMMU
>>>>> you need to map the DMA slave phys_addr_t to a dma_addr_t using
>>>>> something like this.
>>>>>
>>>>> This series is based on top of v4.8-rc1. And I'm hoping to be able to
>>>>> collect a Ack from Russell King on patch 4/6 that adds the ARM
>>>>> specific part and then be able to take the whole series through the
>>>>> dmaengine tree. If this is not the best route I'm more then happy to
>>>>> do it another way.
>>>>>
>>>>> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
>>>>> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting
>>>>> with /dev/mmcblk1, i2c and the serial console which are devices behind
>>>>> the iommu.
>>>>
>>>> As I said in last one, the dmaengine parts look fine to me. But to go
>>>> thru dmaengine tree I would need ACK on non dmaengine patches.
>>>
>>> I havent heard back from this one and I am inclined to merge this one now.
>>> If anyone has any objects, please speak up now...
>>>
>>> Also ACKs welcome...
>>
>> I had not looked at the series earlier, but this version looks entirely
>> reasonable to me, so
>>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>
>>
>> One concern I have is that we might get an awkward situation if we ever
>> encounter one DMA engine hardware that is used in different systems that all
>> have an IOMMU, but on some of them the connection between the DMA master and
>> the slave FIFO bypasses the IOMMU while on others the IOMMU is required.
>
> Do you mean systems where some of the channels of a specific DMA engine go
> through the IOMMU while others do not ? We indeed have no solution today for
> such a situation.
>
> The problem is a bit broader than that, we'll also have an issue with DMA
> engines that have different channels served by different IOMMUs. I recall
> discussing this in the past with you, and the solution you proposed was to add
> a channel index to struct dma_attrs seems good to me. To support the case
> where some channels don't go through an IOMMU we would only need support for
> null entries in the IOMMUs list associated with a device (for instance in the
> DT case null entries in the iommus property).
I think at that point we just create the channels as child devices of
the main dmaengine device so they each get their own DMA ops, and can do
whatever. The Qualcomm HIDMA driver already does that for a very similar
reason (so that the IOMMU can map individual channels into different
guest VMs).
Robin.
> Now I see that struct dma_attrs has been replaced by unsigned long in
>
> commit 00085f1efa387a8ce100e3734920f7639c80caa3
> Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Date: Wed Aug 3 13:46:00 2016 -0700
>
> dma-mapping: use unsigned long for dma_attrs
>
> We still have enough bits to reserve some of them for a channel number, but
> I'm not very happy with that patch as I can see how a future proposal to
> handle the channel number through the DMA attributes will get rejected on the
> grounds of bits starvation then :-(
>
>> I don't have any idea for how this could be handled in a generic way, so my
>> best answer here is to hope we never get there, and if we do, handle it
>> using some local hack in the driver.
>
^ permalink raw reply
* [RFC PATCH 2/8] thread_info: allow custom in-task thread_info
From: Mark Rutland @ 2016-09-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrWni0aZ71r-R6oYG98kZvZA8a184UR0YURk_=tXu8HXMw@mail.gmail.com>
On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote:
> On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > Currently, task_struct is defined in <linux/sched.h>, which (indirectly)
> > pulls in a number of low-level arch headers such as <asm/preempt.h>
> > through a number of other headers. Thus, code and structures in these
> > headers can't rely on the definition of task_struct. Some of these
> > headers are necessary for the definition of task_struct, so moving
> > task_struct into its own header is insufficient tio avoid circular
> > includes.
>
> The flippant answer is to fix the headers, but I tried that myself and
> gave up :(
Agreed; likewise (though I gave up quicker, I suspect). :(
Longer-term I'd still hope that we can do this.
> But how about this slightly less duplicative alternative:
>
> struct thread_info {
> #ifdef arch_thread_info
> struct arch_thread_info arch_ti;
> #endif
> };
I'm happy to have an arch_thread_info.
Just to check, what do you mean to happen with the flags field? Should
that always be in the generic thread_info? e.g.
struct thread_info {
u32 flags;
#ifdef arch_thread_info
struct arch_thread_info arch_ti;
#endif
};
Thanks,
Mark,
^ permalink raw reply
* [PATCH v7 10/11] arm64: dts: r8a7796: salvator-x: enable UHS for SDHI 0 & 3
From: Wolfram Sang @ 2016-09-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-11-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:07PM +0200, Simon Horman wrote:
> Based on work for the r8a7796 by Wolfram Sang.
>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/713b8378/attachment.sig>
^ permalink raw reply
* [PATCH v7 09/11] arm64: dts: r8a7796: salvator-x: enable SDHI0 & 3
From: Wolfram Sang @ 2016-09-16 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-10-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:06PM +0200, Simon Horman wrote:
> Enable the exposed SD card slots in the DT of the r8a7796/salvator-x.
>
> Based on work for the r8a7795/salvator-x by Ai Kyuse.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/1552eba8/attachment.sig>
^ permalink raw reply
* [PATCH v7 08/11] arm64: dts: r8a7796: add SDHI nodes
From: Wolfram Sang @ 2016-09-16 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-9-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:05PM +0200, Simon Horman wrote:
> Add SDHI nodes to the DT of the r8a7796 SoC.
>
> Based on the DT of the r8a7795 SoC.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
If you remove the two lines you removed from H3 already:
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> + sdhi2: sd at ee140000 {
> + compatible = "renesas,sdhi-r8a7796";
> + reg = <0 0xee140000 0 0x2000>;
> + interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 312>;
> + max-frequency = <200000000>;
> + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
> + cap-mmc-highspeed;
This one...
> + status = "disabled";
> + };
> +
> + sdhi3: sd at ee160000 {
> + compatible = "renesas,sdhi-r8a7796";
> + reg = <0 0xee160000 0 0x2000>;
> + interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 311>;
> + max-frequency = <200000000>;
> + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
> + cap-mmc-highspeed;
... and ditto.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/93927e10/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: Kconfig: select GENERIC_CLOCKEVENTS_BROADCAST also on UP
From: Thomas Gleixner @ 2016-09-16 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916102051.GG1041@n2100.armlinux.org.uk>
On Fri, 16 Sep 2016, Russell King - ARM Linux wrote:
> On Fri, Sep 16, 2016 at 11:32:20AM +0200, Lucas Stach wrote:
> > Hi Russell,
> >
> > can you please take a look at this and tell if there is something wrong
> > about it, or if you think it can go in?
> >
> > Without this patch the kernel is unable to use the deeper CPU idle
> > states on i.MX6S if it isn't built with SMP support enabled.
>
> Without spending a lot of time digging into this code, working out what
> these configuration symbols do, I frankly don't know if it's a sensible
> thing to do or not. I guess tglx knows this code like the back of his
> hand, and would be in a better position to comment.
>
> There's two factors there:
> 1. the amount of undocumented code in the kernel needing the code to be
> read and understood to understand various aspects of it from the
> architecture point of view.
Yeah. I know that this stuff lacks documentation.
> 2. your architecture maintainer has done very little actual platform
> development (not through his own choice) for the last 10 or so years,
> which means he's not had to dig into these areas.
>
> So, I'm afraid I feel less than qualified on this at the moment. I'll
> try to look into this and talk to tglx to work out whether it's a
> sensible change.
The broadcast feature has the following functionality:
It lets you use fast accessible (cpu local) timers for normal operation
and in case of deep idle sleeps where the cpu local timer stops switch
to broadcast operation, which arms a slower to access (global) timer
device which does not stop in deep idle.
On UP we usually just use the global device, but on SMP we need the cpu
local timers for normal (non idle) operation. Though there is no reason
to restrict this UP from a technical POV especially when the local
timer is way cheaper to access than the other device.
Hope that helps.
> As I never had a reply to my last email to tglx about threaded interrupts
> vs tasklets (for a reported performance regression in my crypto patches
> already queued for the next merge window) I'm not hoping for much help.
Sorry, got lost in my mail backlog. Looking at it next.
Thanks,
tglx
^ permalink raw reply
* [PATCH v7 07/11] ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104
From: Wolfram Sang @ 2016-09-16 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-8-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:04PM +0200, Simon Horman wrote:
> Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1}.
> And the sd-uhs-sdr104 property to SDHI0.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
If you drop sdr104 here for now as well:
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/2907a398/attachment-0001.sig>
^ permalink raw reply
* [PATCH v7 06/11] ARM: dts: r8a7794: set maximum frequency for SDHI clocks
From: Wolfram Sang @ 2016-09-16 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-7-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:03PM +0200, Simon Horman wrote:
> Define the upper limit otherwise the driver cannot utilize max speeds.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/54d0476b/attachment.sig>
^ permalink raw reply
* [PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104
From: Wolfram Sang @ 2016-09-16 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916100031.GH14562@verge.net.au>
On Fri, Sep 16, 2016 at 12:00:32PM +0200, Simon Horman wrote:
> On Tue, Sep 13, 2016 at 12:57:02PM +0200, Simon Horman wrote:
> > Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
> > And the sd-uhs-sdr104 property to SDHI0.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> As SDR50 support is present in the driver in mainline (correct me if I am
> wrong!) I have queued this up after dropping the sdr104 portion and
> updating the changelog accordingly.
Looks good!
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/685f0fe7/attachment.sig>
^ permalink raw reply
* [PATCH v7 02/11] arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3
From: Wolfram Sang @ 2016-09-16 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916095500.GG14562@verge.net.au>
On Fri, Sep 16, 2016 at 11:55:00AM +0200, Simon Horman wrote:
> On Tue, Sep 13, 2016 at 12:56:59PM +0200, Simon Horman wrote:
> > From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> As SDR50 support is present in the driver in mainline (correct me if I am
> wrong!) I am queuing this up.
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/dbe6ea4b/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: Kconfig: select GENERIC_CLOCKEVENTS_BROADCAST also on UP
From: Russell King - ARM Linux @ 2016-09-16 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474018340.2243.103.camel@pengutronix.de>
On Fri, Sep 16, 2016 at 11:32:20AM +0200, Lucas Stach wrote:
> Hi Russell,
>
> can you please take a look at this and tell if there is something wrong
> about it, or if you think it can go in?
>
> Without this patch the kernel is unable to use the deeper CPU idle
> states on i.MX6S if it isn't built with SMP support enabled.
Without spending a lot of time digging into this code, working out what
these configuration symbols do, I frankly don't know if it's a sensible
thing to do or not. I guess tglx knows this code like the back of his
hand, and would be in a better position to comment.
There's two factors there:
1. the amount of undocumented code in the kernel needing the code to be
read and understood to understand various aspects of it from the
architecture point of view.
2. your architecture maintainer has done very little actual platform
development (not through his own choice) for the last 10 or so years,
which means he's not had to dig into these areas.
So, I'm afraid I feel less than qualified on this at the moment. I'll
try to look into this and talk to tglx to work out whether it's a
sensible change. As I never had a reply to my last email to tglx about
threaded interrupts vs tasklets (for a reported performance regression
in my crypto patches already queued for the next merge window) I'm not
hoping for much help.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Marc Zyngier @ 2016-09-16 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474007187-18673-1-git-send-email-agraf@suse.de>
Hi Alex,
On 16/09/16 07:26, Alexander Graf wrote:
> Some systems out there (well, one type in particular - the Raspberry Pi series)
> do have virtualization capabilities in the core, but no ARM GIC interrupt
> controller.
>
> To run on these systems, the cleanest route is to just handle all
> interrupt delivery in user space and only deal with IRQ pins in the core
> side in KVM.
>
> This works pretty well already, but breaks when the guest starts to use
> architected timers, as these are handled straight inside kernel space today.
>
> This patch set allows user space to receive vtimer events as well as mask
> them, so that we can handle all vtimer related interrupt injection from user
> space, enabling us to use architected timer with user space gic emulation.
I have already voiced my concerns in the past, including face to face,
and I'm going to repeat it: I not keen at all on adding a new userspace
interface that is going to bitrot extremely quickly.
Let's face it, this new ABI will have a single user, with a limited
shelf life. I understand that the RPi is a popular product, but it looks
fairly obvious that this kind of sub-standard HW will eventually
disappear. We'll then be left with a userspace ABI that will break at
every single release, given that nobody in the RPi community actually
uses a mainline kernel.
And breaking this ABI will introduce userspace exploitable bugs, like
the one you've already shown. If anything, I would have loved to
completely kill the whole userspace GIC, because nobody cares. Yes, I
understand it is fun to have KVM running on the RPi. But the maintenance
costs far outweigh the fun aspect already.
You could still run KVM with an external emulated timer (not the arch
timer). No need for a new ABI for that.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: dts: wheat: add DU support
From: Simon Horman @ 2016-09-16 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ba5b2f8e-13f8-6c7d-17c1-44988d30a947@cogentembedded.com>
On Mon, Sep 12, 2016 at 08:52:40PM +0300, Sergei Shtylyov wrote:
> On 09/02/2016 12:29 AM, Sergei Shtylyov wrote:
>
> >Define the Wheat board dependent part of the DU device node.
> >Add the device nodes for the Analog Devices ADV7513 HDMI transmitters
> >connected to DU0/1. Add the necessary subnodes to interconnect DU with
> >HDMI transmitters/connectors.
> >
> >Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >
> >---
> >This patch is against the 'renesas-devel-20160901-v4.8-rc4' of Simon Horman's
> >'renesas.git' repo plus the Wheat CAN and SDHI patches posted earlier...
> >The path depends on the 2 DRM patches just posted in order to work correctly!
>
> In principle, both these patches have been queued by the maintainers...
> Simon, are you going to wait till they hit media_tree.git? Linus' tree?
I don't think that is necessary. I was waiting for some review.
But in any case it looks like this patch no longer applies cleanly.
Could you rebase?
^ permalink raw reply
* [PATCH] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Pavel Labath @ 2016-09-16 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916085825.GL3380@arm.com>
Hello Will,
thank you for the review. I will be a bit busy in the next few weeks,
so I don't think I'll be able to submit a revised version of the patch
that quickly. Until then, here I my responses.
On 16 September 2016 at 09:58, Will Deacon <will.deacon@arm.com> wrote:
> Hi Pavel,
>
> On Mon, Sep 12, 2016 at 03:07:24PM +0100, Pavel Labath wrote:
>> Arm64 hardware does not always report a watchpoint hit address that
>> matches one of the watchpoints set. It can also report an address
>> "near" the watchpoint if a single instruction access both watched and
>> unwatched addresses. There is no straight-forward way, short of
>> disassembling the offending instruction, to map that address back to
>> the watchpoint.
>>
>> Previously, when the hardware reported a watchpoint hit on an address
>> that did not match our watchpoint (this happens in case of instructions
>> which access large chunks of memory such as "stp") the process would
>> enter a loop where we would be continually resuming it (because we did
>> not recognise that watchpoint hit) and it would keep hitting the
>> watchpoint again and again. The tracing process would never get
>> notified of the watchpoint hit.
>>
>> This commit fixes the problem by looking at the watchpoints near the
>> address reported by the hardware. If the address does not exactly match
>> one of the watchpoints we have set, it attributes the hit to the
>> nearest watchpoint we have. This heuristic is a bit dodgy, but I don't
>> think we can do much more, given the hardware limitations.
>> I include a kernel selftest which triggers this code.
>
> Thanks for the patch. Comments inline.
>
>> Signed-off-by: Pavel Labath <labath@google.com>
>> ---
>> arch/arm64/kernel/hw_breakpoint.c | 104 +++++++---
>> tools/testing/selftests/breakpoints/Makefile | 5 +-
>> .../selftests/breakpoints/breakpoint_test-arm.c | 217 +++++++++++++++++++++
>> 3 files changed, 298 insertions(+), 28 deletions(-)
>> create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test-arm.c
>
> Could you split the test out into a separate patch please?
Sure thing.
>
>> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
>> index 26a6bf7..d0ebfe6 100644
>> --- a/arch/arm64/kernel/hw_breakpoint.c
>> +++ b/arch/arm64/kernel/hw_breakpoint.c
>> @@ -661,50 +661,80 @@ unlock:
>> }
>> NOKPROBE_SYMBOL(breakpoint_handler);
>>
>> +/*
>> + * Arm64 hardware does not always report a watchpoint hit address that matches
>> + * one of the watchpoints set. It can also report an address "near" the
>> + * watchpoint if a single instruction access both watched and unwatched
>> + * addresses. There is no straight-forward way, short of disassembling the
>> + * offending instruction, to map that address back to the watchpoint. This
>> + * function computes the distance of the memory access from the watchpoint as a
>> + * heuristic for the likelyhood that a given access triggered the watchpoint.
>> + *
>> + * See Section D2.10.5 "Determining the memory location that caused a Watchpoint
>> + * exception" of ARMv8 Architecture Reference Manual for details.
>> + *
>> + * The function returns the distance of the address from the bytes watched by
>> + * the watchpoint. In case of an exact match, it returns 0.
>> + */
>> +static u64 get_distance_from_watchpoint(unsigned long addr, int i,
>> + struct arch_hw_breakpoint *info)
>> +{
>> + u64 val, alignment_mask, wp_low, wp_high;
>> + u32 ctrl_reg;
>> + int first_bit;
>> + struct arch_hw_breakpoint_ctrl ctrl;
>> +
>> + /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
>> + if (is_compat_task()) {
>> + if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
>> + alignment_mask = 0x7;
>> + else
>> + alignment_mask = 0x3;
>> + } else {
>> + alignment_mask = 0x7;
>> + }
>
> We have identical logic elsewhere in this file, so please stick this into
> a get_watchpoint_alignment_mask function.
I presume you mean the code in arch_validate_hwbkpt_settings. I'll put
that up as a separate patch as well, as it does not seem to be a
completely trivial cut'n'paste job.
>
>> +
>> + val = read_wb_reg(AARCH64_DBG_REG_WVR, i) & ~alignment_mask;
>> +
>> + ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
>> + decode_ctrl_reg(ctrl_reg, &ctrl);
>> + first_bit = ffs(ctrl.len);
>> + if (first_bit == 0)
>> + return -1;
>> + wp_low = val + first_bit - 1;
>> + wp_high = val + fls(ctrl.len) - 1;
>> + if (addr < wp_low)
>> + return wp_low - addr;
>> + else if (addr > wp_high)
>> + return addr - wp_high;
>
> Why do you need to read the control register? We already have the length
> in the arch_hw_breakpoint, and that should be sufficient for the check, no?
I did this because the original code (see below) relied on reading the
register instead of struct arch_hw_breakpoint. However, if you believe
that is ok, I can do it that way. It will certainly make this code
less complicated.
>
>> static int watchpoint_handler(unsigned long addr, unsigned int esr,
>> struct pt_regs *regs)
>> {
>> - int i, step = 0, *kernel_step, access;
>> - u32 ctrl_reg;
>> - u64 val, alignment_mask;
>> + int i, step = 0, *kernel_step, access, closest_match;
>> + u64 min_dist = -1, dist;
>> struct perf_event *wp, **slots;
>> struct debug_info *debug_info;
>> struct arch_hw_breakpoint *info;
>> - struct arch_hw_breakpoint_ctrl ctrl;
>>
>> slots = this_cpu_ptr(wp_on_reg);
>> debug_info = ¤t->thread.debug;
>>
>> + /*
>> + * Find all watchpoints that match the reported address. If no exact
>> + * match is found. Attribute the hit to the closest watchpoint.
>> + */
>> for (i = 0; i < core_num_wrps; ++i) {
>> rcu_read_lock();
>>
>> wp = slots[i];
>> -
>> if (wp == NULL)
>> goto unlock;
>>
>> - info = counter_arch_bp(wp);
>> - /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
>> - if (is_compat_task()) {
>> - if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
>> - alignment_mask = 0x7;
>> - else
>> - alignment_mask = 0x3;
>> - } else {
>> - alignment_mask = 0x7;
>> - }
>> -
>> - /* Check if the watchpoint value matches. */
>> - val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
>> - if (val != (addr & ~alignment_mask))
>> - goto unlock;
>> -
>> - /* Possible match, check the byte address select to confirm. */
>> - ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
>> - decode_ctrl_reg(ctrl_reg, &ctrl);
>> - if (!((1 << (addr & alignment_mask)) & ctrl.len))
>> - goto unlock;
Original code reading the control register.
>> -
>> /*
>> * Check that the access type matches.
>> * 0 => load, otherwise => store
>> @@ -714,6 +744,17 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
>> if (!(access & hw_breakpoint_type(wp)))
>> goto unlock;
>>
>> + info = counter_arch_bp(wp);
>> +
>> + dist = get_distance_from_watchpoint(addr, i, info);
>> + if (dist < min_dist) {
>> + min_dist = dist;
>> + closest_match = i;
>> + }
>> + /* Is this an exact match? */
>> + if (dist != 0)
>> + goto unlock;
>> +
>> info->trigger = addr;
>> perf_bp_event(wp, regs);
>>
>> @@ -724,6 +765,15 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
>> unlock:
>> rcu_read_unlock();
>> }
>> + if (min_dist > 0 && min_dist != -1) {
>> + /* No exact match found. */
>> + rcu_read_lock();
>> + wp = slots[closest_match];
>> + info = counter_arch_bp(wp);
>> + info->trigger = addr;
>> + perf_bp_event(wp, regs);
>> + rcu_read_unlock();
>
> Hmm, are you sure it's safe to drop and retake the RCU lock here? If the
> event is destroyed before we retake the RCU lock, won't htis go horribly
> wrong? It's probably best to hold the lock outside the loop :(
I am definitely not sure of that. :) It's not even clear to me what
data does this lock protect. Doing the locking outside the loop would
certainly be safer though.
regards,
pavel
^ permalink raw reply
* [PATCH] ARM: dts: gose: use generic pinctrl properties in SDHI nodes
From: Simon Horman @ 2016-09-16 10:04 UTC (permalink / raw)
To: linux-arm-kernel
Since 16ccaf5bb5a5 ("pinctrl: sh-pfc: Accept standard function, pins and
groups properties") renesas pfc drivers accept generic "function", "pins"
and "groups" properties.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7793-gose.dts | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 90af18600124..dc311eba4444 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -346,18 +346,18 @@
};
sdhi0_pins: sd0 {
- renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
- renesas,function = "sdhi0";
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
};
sdhi1_pins: sd1 {
- renesas,groups = "sdhi1_data4", "sdhi1_ctrl";
- renesas,function = "sdhi1";
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
};
sdhi2_pins: sd2 {
- renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
- renesas,function = "sdhi2";
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
};
qspi_pins: qspi {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104
From: Simon Horman @ 2016-09-16 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-6-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:02PM +0200, Simon Horman wrote:
> Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
> And the sd-uhs-sdr104 property to SDHI0.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
As SDR50 support is present in the driver in mainline (correct me if I am
wrong!) I have queued this up after dropping the sdr104 portion and
updating the changelog accordingly.
The result is as follows:
From: Simon Horman <horms+renesas@verge.net.au>
Date: Tue, 13 Sep 2016 12:57:02 +0200
Subject: [PATCH] ARM: dts: koelsch: arm64: dts: r8a7795: salvator-x: enable
UHS for SDHI 0, 1 & 3
Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f8a7d090fd01..f17bfa000f73 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -360,16 +360,37 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
};
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
};
sdhi2_pins: sd2 {
groups = "sdhi2_data4", "sdhi2_ctrl";
function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
};
qspi_pins: qspi {
@@ -454,33 +475,39 @@
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi0>;
vqmmc-supply = <&vccq_sdhi0>;
cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
+ sd-uhs-sdr50;
status = "okay";
};
&sdhi1 {
pinctrl-0 = <&sdhi1_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi1_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi1>;
vqmmc-supply = <&vccq_sdhi1>;
cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 15 GPIO_ACTIVE_HIGH>;
+ sd-uhs-sdr50;
status = "okay";
};
&sdhi2 {
pinctrl-0 = <&sdhi2_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi2>;
vqmmc-supply = <&vccq_sdhi2>;
cd-gpios = <&gpio6 22 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
status = "okay";
};
--
2.7.0.rc3.207.g0ac5344
^ 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