* [PATCH v2 3/3] spi: pca2xx-pci: Allow MSI
From: Jarkko Nikula @ 2017-01-17 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484593718.2133.156.camel@linux.intel.com>
On 01/16/2017 09:08 PM, Andy Shevchenko wrote:
> On Mon, 2017-01-16 at 19:44 +0100, Jan Kiszka wrote:
>> Now that the core is ready for edge-triggered interrupts, we can
>> safely
>> allow the PCI versions that provide this to enable the feature and,
>> thus, have less shared interrupts.
>>
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
I was looking at is there need to call pci_free_irq_vectors() but
pcim_release() takes care of that since this driver uses
pcim_enable_device().
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
^ permalink raw reply
* [PATCH v2 1/3] spi: pxa2xx: Factor out handle_bad_msg
From: Jarkko Nikula @ 2017-01-17 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <776c72d3de4b75ff0a8b91791740389950d8abe8.1484592296.git.jan.kiszka@siemens.com>
On 01/16/2017 08:44 PM, Jan Kiszka wrote:
> As suggested by Andy Shevchenko: Decouple this corner cause from the
> general handling logic in ssp_int.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> drivers/spi/spi-pxa2xx.c | 29 +++++++++++++++--------------
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
^ permalink raw reply
* [PATCH] arm64: dts: marvell: Add DT for MACCHIATOBin board
From: Russell King @ 2017-01-17 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Add a cut-down version of the DTS file for the community board
MACCHIATOBin from SolidRun based on Marvell Armada 8040 SoC to suit
the current mainlined Armada 8040 state.
This brings support for mainly SATA, SPI flash and UART. The USB
descriptions are included but are not tested in this form due to the
lack of mainline GPIO.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Acked-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
This is derived from a version from Marvell, but severly cut down,
cleaned up, re-organised and added to to suit mainline kernels. The
only common parts are the header comment, top level model and compatible
strings, the rest has been changed by me in some way.
I'm planning to submit further patches as the mainline Armada 8k support
moves forward.
This is submitted with Rabeeh's confirmation and ack that he (as Solid
Run's CTO) is happy for this to be upstreamed.
Note - the license text is rather "interesting" but matches that which
is already on other ARM64 Marvell-based platforms. I suspect someone at
Free Electrons needs to talk to Marvell to correct the "library" thing,
and clear up the "GPLv2" vs "GPLv2+" confusion in there.
arch/arm64/boot/dts/marvell/Makefile | 1 +
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 138 ++++++++++++++++++++++
2 files changed, 139 insertions(+)
create mode 100644 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 1690883b931a..3e6ce6c15a74 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -7,6 +7,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
new file mode 100644
index 000000000000..b7298429ffa1
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for MACCHIATOBin Armada 8040 community board platform
+ */
+
+#include "armada-8040.dtsi"
+
+/ {
+ model = "Marvell 8040 MACHIATOBin";
+ compatible = "marvell,armada8040-mcbin", "marvell,armada8040",
+ "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+ memory at 00000000 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ /* Regulator labels correspond with schematics */
+ v_3_3: regulator-3-3v {
+ compatible = "regulator-fixed";
+ regulator-name = "v_3_3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ status = "okay";
+ };
+
+ v_vddo_h: regulator-1-8v {
+ compatible = "regulator-fixed";
+ regulator-name = "v_vddo_h";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ status = "okay";
+ };
+
+ v_5v0_usb3_hst_vbus: regulator-usb3-vbus0 {
+ compatible = "regulator-fixed";
+ regulator-name = "v_5v0_usb3_hst_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ /* actually GPIO controlled, but 8k has no GPIO support yet */
+ regulator-always-on;
+ status = "okay";
+ };
+
+ usb3h0_phy: usb3_phy0 {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <&v_5v0_usb3_hst_vbus>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&cpm_i2c0 {
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+&cpm_sata0 {
+ /* CPM Lane 0 - U29 */
+ status = "okay";
+};
+
+&cpm_usb3_0 {
+ /* J38? - USB2.0 only */
+ status = "okay";
+};
+
+&cpm_usb3_1 {
+ /* J38? - USB2.0 only */
+ status = "okay";
+};
+
+&cps_sata0 {
+ /* CPS Lane 1 - U32 */
+ /* CPS Lane 3 - U31 */
+ status = "okay";
+};
+
+&cps_spi1 {
+ status = "okay";
+
+ spi-flash at 0 {
+ compatible = "st,w25q32";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+};
+
+&cps_usb3_0 {
+ /* CPS Lane 2 - CON7 */
+ usb-phy = <&usb3h0_phy>;
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [RFC PATCH] initramfs: finish fput() before accessing any binary from initramfs
From: Lokesh Vutla @ 2017-01-17 11:14 UTC (permalink / raw)
To: linux-arm-kernel
commit 4a9d4b024a31 ("switch fput to task_work_add") implements a
schedule_work() for completing fput(), but did not guarantee calling
__fput() after unpacking initramfs. Because of this, there is a
possibility that during boot a driver can see ETXTBSY when it tries
to load a binary from initramfs as fput() is still pending on that
binary. This patch makes sure that fput() is completed after unpacking
initramfs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
- Reproduced on TI K2HK EVM. K2HK Queue Manager subsystem driver[1] tries
to load a firmware from initramfs during boot. Sometimes loading of this
firmware fails with error ETXTBSY. Digging a bit more observed that
deny_write_access() is returning ETXTBSY as inode->i_writecount is > 0
for that file. This is because Unpacking initramfs does a
get_write_access(from open) but hasn't done put_write_access(from fput)
as it hasn't been scheduled yet.
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/ti/knav_qmss_queue.c
init/initramfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/init/initramfs.c b/init/initramfs.c
index b32ad7d97ac9..c42c69b48a4b 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -18,6 +18,7 @@
#include <linux/dirent.h>
#include <linux/syscalls.h>
#include <linux/utime.h>
+#include <linux/file.h>
static ssize_t __init xwrite(int fd, const char *p, size_t count)
{
@@ -652,6 +653,7 @@ static int __init populate_rootfs(void)
* us a chance to load before device_initcalls.
*/
load_default_modules();
+ flush_delayed_fput();
}
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Mark Rutland @ 2017-01-17 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116082505.GL20972@linaro.org>
On Mon, Jan 16, 2017 at 05:25:07PM +0900, AKASHI Takahiro wrote:
> On Fri, Jan 13, 2017 at 11:17:56AM +0000, Mark Rutland wrote:
> > On Fri, Jan 13, 2017 at 06:13:49PM +0900, AKASHI Takahiro wrote:
> > > On Thu, Jan 12, 2017 at 03:39:45PM +0000, Mark Rutland wrote:
> > > > arm64 we should either ensure that /proc/iomem is consistently usable
> > > > (and have userspace consistently use it), or we should expose a new file
> > > > specifically to expose this information.
> > >
> > > The thing that I had in my mind when adding this property is that
> > > /proc/iomem would be obsolete in the future, then we should have
> > > an alternative in hand.
> >
> > Ok.
> >
> > My disagreement is with using the DT as a channel to convey information
> > from the kernel to userspace.
> >
> > I'm more than happy for a new file or other mechanism to express this
> > information. For example, we could add
> > /sys/kernel/kexec_crash_{base,size} or similar.
>
> It may make sense because /sys/kernel/kexec_crash_size already exists,
> so why not kexec_crash_base?
> My concern, however, is that this kind of interface might prevent us from
> allowing multiple regions to be reserved for crash dump kernel in the future.
> (There is an assumption that we have only one region at least on arm64 though.)
Ok.
If we need to handle that, we should also update the description of
linux,usable-memory-range to allow multiple entries (and probably
s/range/ranges).
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Jerry Huang @ 2017-01-17 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737gikls0.fsf@linux.intel.com>
> -----Original Message-----
> From: Felipe Balbi [mailto:balbi at kernel.org]
> Sent: Tuesday, January 17, 2017 6:45 PM
> To: Jerry Huang <jerry.huang@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: mark.rutland at arm.com; catalin.marinas at arm.com;
> will.deacon at arm.com; linux at armlinux.org.uk; devicetree at vger.kernel.org;
> linux-usb at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-
> type-adjustment" for INCR burst type
>
>
> Hi,
>
> Jerry Huang <jerry.huang@nxp.com> writes:
>
> <snip>
>
> >> >> So, I think we still need two vaue to specify INCRBrstEna and
> >> >> INCRx burst type.
> >> > Hi, Balbi,
> >> > It seems there is no feedback for my comment, so these patches can
> >> > be
> >> accepted?
> >>
> >> probably not, we need to really understand what information we need
> >> so it can be described properly. The last thing we want is
> >> unnecessary DT properties.
> >>
> >> It seems to me that we can extrapolate INCRBrstEna based on which
> >> burst modes are enabled. If only 0 is passed, then that bit should be
> >> 1, if 0 and any other size is passed, then that bit should be 0, no?
> > Hi, Balbi,
> > Below is the definition for this property,
> > snps,incr-burst-type-adjustment = <x>, <y>
> > x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
> > 0 - INCRX burst mode (not enable INCRBrstEna)
> > 1 - INCR (undefined length) burst mode (enable INCRBrstEna)
> > y: the burst length
> >
> > 1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear
> > it) , we select one of
> > INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this
> > value through "y")to set the fix burst length controller supported.
> >
> > For example:
> >
> > snps,incr-burst-type-adjustment = <0>, <16>
> >
> > driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type
> > Enabled), controller will use INCR16 (with 16 bytes) to transfer data.
> >
> > 2> if x = 1: means INCRBrstEna enabled, we select one of
> > INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value
> > through "y") to set the burst length, and controller will use any
> > length less than or equal to that we selected.
> >
> > For example:
> >
> > snps,incr-burst-type-adjustment = <1>, <32>
> >
> > driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type
> > Enabled), controller will use any burst length less than (such as 4,
> > 8, 16 byte) or equal to 32 byte to transfer data.
> >
> > Therefore, I think this two fileds are needed. Do you think about it?
>
> no, I don't think two values are needed, because first value can be
> extrapolated from the second. Something like this:
>
> snps,incr-burst-type-adjustment = <4>, <8>, <16>, <32>;
>
> This is basically telling us that we can support anything in this list. So
> INCRBrstEna should be set to 1.
>
> If DT, on the other hand, says:
>
> snps,incr-burst-type-adjustment = <32>;
>
> this means that we can only support INCR32, so INCRBrstEna should be
> cleared to 0.
Got it, I will try this mode.
Thanks a lot, Balbi,
^ permalink raw reply
* [PATCH v2 11/11] drm/rockchip/dsi: fix insufficient bandwidth of some panel
From: John Keeping @ 2017-01-17 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587DE489.2010004@rock-chips.com>
On Tue, 17 Jan 2017 17:31:53 +0800, Chris Zhong wrote:
> On 01/16/2017 08:44 PM, John Keeping wrote:
> > On Mon, 16 Jan 2017 18:08:31 +0800, Chris Zhong wrote:
> >
> >> Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
> >> for some panel, it will cause the screen display is not normal, so
> >> increases the badnwidth to 1 / 0.8.
> >>
> >> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> >>
> >> ---
> >>
> >> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> index 9dfa73d..5a973fe 100644
> >> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> @@ -501,8 +501,8 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
> >>
> >> mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);
> >> if (mpclk) {
> >> - /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
> >> - tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
> >> + /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
> >> + tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;
> > This and patch 9 are just hacking around the underlying problem in order
> > to make particular panels work. I'm pretty sure the actual issue is the
> > use of hardcoded values when configuring the PHY, since the PHY
> > parameters are specified in clock cycles but the MIPI spec requires
> > absolute time durations.
> >
> > I posted a series addressing this a while ago, although I screwed up
> > sending it so some patches were included twice and since no one
> > expressed any interest I didn't post a cleaned up version.
> >
> > The relevant patch is here:
> >
> > https://patchwork.kernel.org/patch/9340193/
>
> Thanks very much, your patches are very useful for me. It looks your
> method is correct.
> And I am very confused why Mark Yao and me did not receive your patches
> before,
> although we have subscribed the <linux-rockchip@lists.infradead.org>.
>
> In addition, could you tell me which device ware you testing with these
> mipi patches.
> I going to test them these day.
I'm using RK3288 and I tested my patches with three different MIPI
displays, two of which require commands to be sent in order to set up
the panel.
Thanks for testing the patches.
John
^ permalink raw reply
* [PATCH] pinctrl: uniphier: fix Ethernet (RMII) pin-mux setting for LD20
From: Masahiro Yamada @ 2017-01-17 10:52 UTC (permalink / raw)
To: linux-arm-kernel
Fix the pin-mux values for the MDC, MDIO, MDIO_INTL, PHYRSTL pins.
Fixes: 1e359ab1285e ("pinctrl: uniphier: add Ethernet pin-mux settings")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
index aa8bd97..9668633 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
@@ -561,7 +561,7 @@ static const int ether_rgmii_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0};
static const unsigned ether_rmii_pins[] = {30, 31, 32, 33, 34, 35, 36, 37, 39,
41, 42, 45};
-static const int ether_rmii_muxvals[] = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1};
+static const int ether_rmii_muxvals[] = {0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1};
static const unsigned i2c0_pins[] = {63, 64};
static const int i2c0_muxvals[] = {0, 0};
static const unsigned i2c1_pins[] = {65, 66};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Felipe Balbi @ 2017-01-17 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB5PR0401MB1813548526D3C8D34B9CCE52FE7C0@DB5PR0401MB1813.eurprd04.prod.outlook.com>
Hi,
Jerry Huang <jerry.huang@nxp.com> writes:
<snip>
>> >> So, I think we still need two vaue to specify INCRBrstEna and INCRx
>> >> burst type.
>> > Hi, Balbi,
>> > It seems there is no feedback for my comment, so these patches can be
>> accepted?
>>
>> probably not, we need to really understand what information we need so it
>> can be described properly. The last thing we want is unnecessary DT
>> properties.
>>
>> It seems to me that we can extrapolate INCRBrstEna based on which burst
>> modes are enabled. If only 0 is passed, then that bit should be 1, if 0 and any
>> other size is passed, then that bit should be 0, no?
> Hi, Balbi,
> Below is the definition for this property,
> snps,incr-burst-type-adjustment = <x>, <y>
> x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
> 0 - INCRX burst mode (not enable INCRBrstEna)
> 1 - INCR (undefined length) burst mode (enable INCRBrstEna)
> y: the burst length
>
> 1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear
> it) , we select one of
> INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this
> value through "y")to set the fix burst length controller supported.
>
> For example:
>
> snps,incr-burst-type-adjustment = <0>, <16>
>
> driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type
> Enabled), controller will use INCR16 (with 16 bytes) to transfer data.
>
> 2> if x = 1: means INCRBrstEna enabled, we select one of
> INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value
> through "y") to set the burst length, and controller will use any
> length less than or equal to that we selected.
>
> For example:
>
> snps,incr-burst-type-adjustment = <1>, <32>
>
> driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type
> Enabled), controller will use any burst length less than (such as 4,
> 8, 16 byte) or equal to 32 byte to transfer data.
>
> Therefore, I think this two fileds are needed. Do you think about it?
no, I don't think two values are needed, because first value can be
extrapolated from the second. Something like this:
snps,incr-burst-type-adjustment = <4>, <8>, <16>, <32>;
This is basically telling us that we can support anything in this
list. So INCRBrstEna should be set to 1.
If DT, on the other hand, says:
snps,incr-burst-type-adjustment = <32>;
this means that we can only support INCR32, so INCRBrstEna should be
cleared to 0.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/596669fd/attachment.sig>
^ permalink raw reply
* [PATCH] rtc: stm32: fix comparison warnings
From: Alexandre Belloni @ 2017-01-17 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484561333-12087-1-git-send-email-amelie.delaunay@st.com>
On 16/01/2017 at 11:08:53 +0100, Amelie Delaunay wrote :
> This patches fixes comparison between signed and unsigned values as it
> could produce an incorrect result when the signed value is converted to
> unsigned:
>
> drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_valid_alrm':
> drivers/rtc/rtc-stm32.c:404:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> if ((((tm->tm_year > cur_year) &&
> ...
>
> It also fixes comparison always true or false due to the fact that unsigned
> value is compared against zero with >= or <:
>
> drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_init':
> drivers/rtc/rtc-stm32.c:514:35: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
> for (pred_a = pred_a_max; pred_a >= 0; pred_a-- ) {
>
> drivers/rtc/rtc-stm32.c:530:44: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
> (rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
>
> Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> drivers/rtc/rtc-stm32.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] rtc: stm32: use 0 instead of ~PWR_CR_DBP in regmap_update_bits
From: Alexandre Belloni @ 2017-01-17 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484557058-21601-1-git-send-email-amelie.delaunay@st.com>
On 16/01/2017 at 09:57:38 +0100, Amelie Delaunay wrote :
> Using the ~ operator on a BIT() constant results in a large 'unsigned long'
> constant that won't fit into an 'unsigned int' function argument on 64-bit
> architectures, resulting in a harmless build warning in x86 allmodconfig:
>
> drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_probe':
> drivers/rtc/rtc-stm32.c:651:51: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
> regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
>
> As PWR_CR_DBP mask prevents other bits to be cleared, replace all
> ~PWR_CR_DBP by 0.
>
> Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v19 10/15] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT
From: Fu Wei @ 2017-01-17 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADyBb7tFaSshUmZsJbNO2tnbqAKEii39NQVfcx5CqDiDsK5OJA@mail.gmail.com>
Hi Mark,
On 17 January 2017 at 18:30, Fu Wei <fu.wei@linaro.org> wrote:
> Hi Mark,
>
> On 17 January 2017 at 02:30, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Wed, Dec 21, 2016 at 02:45:58PM +0800, fu.wei at linaro.org wrote:
>>> From: Fu Wei <fu.wei@linaro.org>
>>>
>>> The patch refactor original memory-mapped timer init code:
>>> (1) Refactor "arch_timer_mem_init", make it become a common code for
>>> memory-mapped timer init.
>>> (2) Add a new function "arch_timer_mem_of_init" for DT init.
>>
>> As a general note, please write proper commit messages, describing what
>> the problem is, and why we are making the changes. These bullet points
>> don't add anything to what can be derived from a glance at the code.
>>
>> For this patch, you can use:
>>
>> clocksource: arm_arch_timer: refactor MMIO timer probing
>>
>> Currently the code to probe MMIO architected timers mixes DT parsing
>> with actual poking of hardware. This makes the code harder than
>> necessary to understand, and makes it difficult to add support for
>> probing via ACPI.
>>
>> This patch factors all the DT-specific logic out of
>> arch_timer_mem_init(), into a new function, arch_timer_mem_of_init().
>> The former pokes the hardware and determines the suitablility of
>> frames based on a datastructure populated by the latter.
>>
>> This cleanly separates the two and will make it possible to add
>> probing using the ACPI GTDT in subsequent patches.
>
> Great thanks for this upstream tip.
> I have used your example commit message instead.
> It will be in v20.
>
>>
>> [...]
>>
>>> + for_each_available_child_of_node(np, frame_node) {
>>> + int n;
>>> + struct arch_timer_mem_frame *frame = &timer_mem->frame[i];
>>> +
>>> + if (of_property_read_u32(frame_node, "frame-number", &n)) {
>>> + pr_err("Missing frame-number\n");
>>> + of_node_put(frame_node);
>>> + goto out;
>>> + }
>>> + frame->frame_nr = n;
>>> +
>>> + if (of_address_to_resource(frame_node, 0, &res)) {
>>> + of_node_put(frame_node);
>>> + goto out;
>>> + }
>>> + frame->cntbase = res.start;
>>> + frame->size = resource_size(&res);
>>> +
>>> + frame->virt_irq = irq_of_parse_and_map(frame_node,
>>> + ARCH_TIMER_VIRT_SPI);
>>> + frame->phys_irq = irq_of_parse_and_map(frame_node,
>>> + ARCH_TIMER_PHYS_SPI);
>>>
>>> - if (!arch_timer_needs_of_probing())
>>> + if (++i >= ARCH_TIMER_MEM_MAX_FRAMES)
>>> + break;
>>> + }
>>
>> It would be good if we could warn upon seeing more than
>> ARCH_TIMER_MEM_MAX_FRAMES children, since that's obviously an error.
>
> OK, NP, will use
>
> if (i >= ARCH_TIMER_MEM_MAX_FRAMES) {
> pr_err(FW_BUG "too many frames, ARMv8 spec only allows 8.\n");
Sorry, this should be "ARM spec only allows 8.\n"
Not only ARMv8, but also ARMv7
> goto out;
> }
>
> at the beginning of this loop.
>
> Here will be replaced by i++;
>
> Great thanks for your suggestion!
>
>>
>> Thanks,
>> Mark.
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [01/26] drm/rockchip: dw-mipi-dsi: use mode from display state
From: Chris Zhong @ 2017-01-17 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919171747.28512-2-john@metanate.com>
On 09/20/2016 01:17 AM, John Keeping wrote:
> There is no need to keep a pointer to the mode around since we know it
> will be present in the connector state.
>
> Signed-off-by: John Keeping <john@metanate.com>
> ---
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 31 ++++++++++++++++---------------
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index ca22e5ee89ca..a87037556f5c 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -286,7 +286,6 @@ struct dw_mipi_dsi {
> u32 format;
> u16 input_div;
> u16 feedback_div;
> - struct drm_display_mode *mode;
>
> const struct dw_mipi_dsi_plat_data *pdata;
> };
> @@ -332,9 +331,10 @@ static int max_mbps_to_testdin(unsigned int max_mbps)
> */
> static void dw_mipi_dsi_wait_for_two_frames(struct dw_mipi_dsi *dsi)
> {
> + struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
> int refresh, two_frames;
>
> - refresh = drm_mode_vrefresh(dsi->mode);
> + refresh = drm_mode_vrefresh(mode);
> two_frames = DIV_ROUND_UP(MSEC_PER_SEC, refresh) * 2;
> msleep(two_frames);
> }
> @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>
> static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
> {
> + struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
> unsigned int i, pre;
> unsigned long mpclk, pllref, tmp;
> unsigned int m = 1, n = 1, target_mbps = 1000;
> @@ -474,7 +475,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
> return bpp;
> }
>
> - mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);
> + mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
> if (mpclk) {
> /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
> tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
> @@ -689,9 +690,9 @@ static void dw_mipi_dsi_init(struct dw_mipi_dsi *dsi)
> dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
> }
>
> -static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi,
> - struct drm_display_mode *mode)
> +static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi)
> {
> + struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
> u32 val = 0, color = 0;
>
> switch (dsi->format) {
> @@ -726,9 +727,10 @@ static void dw_mipi_dsi_packet_handler_config(struct dw_mipi_dsi *dsi)
> dsi_write(dsi, DSI_PCKHDL_CFG, EN_CRC_RX | EN_ECC_RX | EN_BTA);
> }
>
> -static void dw_mipi_dsi_video_packet_config(struct dw_mipi_dsi *dsi,
> - struct drm_display_mode *mode)
> +static void dw_mipi_dsi_video_packet_config(struct dw_mipi_dsi *dsi)
> {
> + struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
> +
> dsi_write(dsi, DSI_VID_PKT_SIZE, VID_PKT_SIZE(mode->hdisplay));
> }
>
> @@ -744,12 +746,13 @@ static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)
> static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
> u32 hcomponent)
> {
> + struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
> u32 frac, lbcc;
>
> lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
>
> - frac = lbcc % dsi->mode->clock;
> - lbcc = lbcc / dsi->mode->clock;
> + frac = lbcc % mode->clock;
> + lbcc = lbcc / mode->clock;
> if (frac)
> lbcc++;
>
> @@ -759,7 +762,7 @@ static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
> static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
> {
> u32 htotal, hsa, hbp, lbcc;
> - struct drm_display_mode *mode = dsi->mode;
> + struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
>
> htotal = mode->htotal;
> hsa = mode->hsync_end - mode->hsync_start;
> @@ -778,7 +781,7 @@ static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
> static void dw_mipi_dsi_vertical_timing_config(struct dw_mipi_dsi *dsi)
> {
> u32 vactive, vsa, vfp, vbp;
> - struct drm_display_mode *mode = dsi->mode;
> + struct drm_display_mode *mode = &dsi->connector.state->crtc->state->adjusted_mode;
>
> vactive = mode->vdisplay;
> vsa = mode->vsync_end - mode->vsync_start;
> @@ -821,8 +824,6 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
> struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
> int ret;
>
> - dsi->mode = adjusted_mode;
> -
I prefer to keep the original method, although this"dsi->mode" pointer
is same as "&dsi->connector.state->crtc->state->adjusted_mode; "
I still think dsi->mode makes the process easier to read
> ret = dw_mipi_dsi_get_lane_bps(dsi);
> if (ret < 0)
> return;
> @@ -833,10 +834,10 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
> }
>
> dw_mipi_dsi_init(dsi);
> - dw_mipi_dsi_dpi_config(dsi, mode);
> + dw_mipi_dsi_dpi_config(dsi);
> dw_mipi_dsi_packet_handler_config(dsi);
> dw_mipi_dsi_video_mode_config(dsi);
> - dw_mipi_dsi_video_packet_config(dsi, mode);
> + dw_mipi_dsi_video_packet_config(dsi);
> dw_mipi_dsi_command_mode_config(dsi);
> dw_mipi_dsi_line_timer_config(dsi);
> dw_mipi_dsi_vertical_timing_config(dsi);
^ permalink raw reply
* [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Jerry Huang @ 2017-01-17 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tw8zo0c0.fsf@linux.intel.com>
> -----Original Message-----
> From: Felipe Balbi [mailto:balbi at kernel.org]
> Sent: Monday, January 16, 2017 4:50 PM
> To: Jerry Huang <jerry.huang@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: mark.rutland at arm.com; catalin.marinas at arm.com;
> will.deacon at arm.com; linux at armlinux.org.uk; devicetree at vger.kernel.org;
> linux-usb at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-
> type-adjustment" for INCR burst type
>
>
> Hi,
>
> Jerry Huang <jerry.huang@nxp.com> writes:
> >> > On Thu, Dec 22, 2016 at 8:52 PM, Jerry Huang <jerry.huang@nxp.com>
> >> wrote:
> >> > > Hi, Rob,
> >> > >> -----Original Message-----
> >> > >> From: Rob Herring [mailto:robh at kernel.org]
> >> > >> Sent: Friday, December 23, 2016 2:45 AM
> >> > >> To: Jerry Huang <jerry.huang@nxp.com>
> >> > >> Cc: balbi at kernel.org; mark.rutland at arm.com;
> >> > >> catalin.marinas at arm.com; will.deacon at arm.com;
> >> > >> linux at armlinux.org.uk; devicetree at vger.kernel.org;
> >> > >> linux-usb at vger.kernel.org; linux-kernel at vger.kernel.org;
> >> > >> linux-arm- kernel at lists.infradead.org
> >> > >> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps,
> >> > >> incr-burst- type-adjustment" for INCR burst type
> >> > >>
> >> > >> On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote:
> >> > >> > New property "snps,incr-burst-type-adjustment = <x>, <y>" for
> >> > >> > USB3.0
> >> > >> DWC3.
> >> > >> > Field "x": 1/0 - undefined length INCR burst type enable or
> >> > >> > not; Field
> >> > >> > "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst
> >> type.
> >> > >> >
> >> > >> > While enabling undefined length INCR burst type and INCR16
> >> > >> > burst type, get better write performance on NXP Layerscape
> platform:
> >> > >> > around 3% improvement (from 364MB/s to 375MB/s).
> >> > >> >
> >> > >> > Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> >> > >> > ---
> >> > >> > Changes in v3:
> >> > >> > - add new property for INCR burst in usb node.
> >> > >> >
> >> > >> > Documentation/devicetree/bindings/usb/dwc3.txt | 5 +++++
> >> > >> > arch/arm/boot/dts/ls1021a.dtsi | 1 +
> >> > >> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
> >> > >> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 ++
> >> > >> > 4 files changed, 11 insertions(+)
> >> > >> >
> >> > >> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > >> > b/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > >> > index e3e6983..8c405a3 100644
> >> > >> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > >> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > >> > @@ -55,6 +55,10 @@ Optional properties:
> >> > >> > fladj_30mhz_sdbnd signal is invalid or incorrect.
> >> > >> >
> >> > >> > - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has*
> >> > >> > to be
> >> > >> reallocated.
> >> > >> > + - snps,incr-burst-type-adjustment: Value for INCR burst type
> >> > >> > + of
> >> > >> GSBUSCFG0
> >> > >> > + register, undefined length INCR burst type enable and INCRx
> type.
> >> > >> > + First field is for undefined length INCR burst type enable or not.
> >> > >> > + Second field is for largest INCRx type enabled.
> >> > >>
> >> > >> Why do you need the first field? Is the 2nd field used if the 1st is 0?
> >> > >> If not, then just use the presence of the property to enable or not.
> >> > > The first field is one switch.
> >> > > When it is 1, means undefined length INCR burst type enabled, we
> >> > > can use
> >> > any length less than or equal to the largest-enabled burst length
> >> > of INCR4/8/16/32/64/128/256.
> >> > > When it is zero, means INCRx burst mode enabled, we can use one
> >> > > fixed
> >> > burst length of 1/4/8/16/32/64/128/256 byte.
> >> > > So, the 2nd field is used if the 1st is 0, we need to select one
> >> > > largest burst
> >> > length the USB controller can support.
> >> > > If we don't want to change the value of this register (use the
> >> > > default value),
> >> > we don't need to add this property to usb node.
> >> >
> >> > Just make this a single value with 0 meaning INCR and 4/8/16/etc
> >> > being
> >> INCRx.
> >> Maybe, I didn't describe it clearly.
> >> According to DWC3 spec, the value "0" of field INCRBrstEna means
> >> INCRx burst mode, 1 means INCR burst mode.
> >> Regardless of the value of INCRBrstEna [bit0], we need to modify the
> >> other field bit[1,2,3,4,5,6,7] to one INCR burst type for the platform
> supported.
> >> Ad you mentioned, if we just use a single value with 0 meaning INCR
> >> and 4/8/16/etc being INCRx.
> >> I understand totally that when it is none-zero, we can use it for
> >> INCR burst mode.
> >> Then, when it is 0, how to select the INCRx value?
> >>
> >> So, I think we still need two vaue to specify INCRBrstEna and INCRx
> >> burst type.
> > Hi, Balbi,
> > It seems there is no feedback for my comment, so these patches can be
> accepted?
>
> probably not, we need to really understand what information we need so it
> can be described properly. The last thing we want is unnecessary DT
> properties.
>
> It seems to me that we can extrapolate INCRBrstEna based on which burst
> modes are enabled. If only 0 is passed, then that bit should be 1, if 0 and any
> other size is passed, then that bit should be 0, no?
Hi, Balbi,
Below is the definition for this property,
snps,incr-burst-type-adjustment = <x>, <y>
x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
0 - INCRX burst mode (not enable INCRBrstEna)
1 - INCR (undefined length) burst mode (enable INCRBrstEna)
y: the burst length
1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear it) , we select one of INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value through "y")to set the fix burst length controller supported.
For example:
snps,incr-burst-type-adjustment = <0>, <16>
driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type Enabled), controller will use INCR16 (with 16 bytes) to transfer data.
2> if x = 1: means INCRBrstEna enabled, we select one of INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value through "y") to set the burst length, and controller will use any length less than or equal to that we selected.
For example:
snps,incr-burst-type-adjustment = <1>, <32>
driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type Enabled), controller will use any burst length less than (such as 4, 8, 16 byte) or equal to 32 byte to transfer data.
Therefore, I think this two fileds are needed. Do you think about it?
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Add regulators for Vbus and Vbus-Boost
From: Pankaj Dubey @ 2017-01-17 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484649143-19423-1-git-send-email-pankaj.dubey@samsung.com>
Adding fixed voltage regulators for Vbus and Vbus-boost required
by USB 3.0 DRD controller on Exynos7-espresso board.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Vivek Gautam <gautamvivek1987@gmail.com>
---
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 44 +++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 9cf73cf..68f3a51 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -33,6 +33,29 @@
device_type = "memory";
reg = <0x0 0x40000000 0x0 0xC0000000>;
};
+
+ usb30_vbus_reg: regulator-usb30 {
+ compatible = "regulator-fixed";
+ regulator-name = "VBUS_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gph1 1 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb30_vbus_en>;
+ enable-active-high;
+ };
+
+ usb3drd_boost_5v: regulator-usb3drd-boost {
+ compatible = "regulator-fixed";
+ regulator-name = "VUSB_VBUS_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpf4 1 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb3drd_boost_en>;
+ enable-active-high;
+ };
+
};
&fin_pll {
@@ -366,3 +389,24 @@
vqmmc-supply = <&ldo2_reg>;
disable-wp;
};
+
+&usbdrd_phy {
+ vbus-supply = <&usb30_vbus_reg>;
+ vbus-boost-supply = <&usb3drd_boost_5v>;
+};
+
+&pinctrl_bus1 {
+ usb30_vbus_en: usb30-vbus-en {
+ samsung,pins = "gph1-1";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ usb3drd_boost_en: usb3drd-boost-en {
+ samsung,pins = "gpf4-1";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: exynos: Add USB 3.0 controller node for Exynos7
From: Pankaj Dubey @ 2017-01-17 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484649143-19423-1-git-send-email-pankaj.dubey@samsung.com>
Add USB 3.0 DRD controller device node, with its clock
and phy information to enable the same on Exynos7.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Vivek Gautam <gautamvivek1987@gmail.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 34 +++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 9080a11..a2d8d11 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -603,6 +603,40 @@
#include "exynos7-trip-points.dtsi"
};
};
+
+ usbdrd_phy: phy at 15500000 {
+ compatible = "samsung,exynos7-usbdrd-phy";
+ reg = <0x15500000 0x100>;
+ clocks = <&clock_fsys0 ACLK_USBDRD300>,
+ <&clock_fsys0 OSCCLK_PHY_CLKOUT_USB30_PHY>,
+ <&clock_fsys0 PHYCLK_USBDRD300_UDRD30_PIPE_PCLK_USER>,
+ <&clock_fsys0 PHYCLK_USBDRD300_UDRD30_PHYCLK_USER>,
+ <&clock_fsys0 SCLK_USBDRD300_REFCLK>;
+ clock-names = "phy", "ref", "phy_pipe",
+ "phy_utmi", "itp";
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ #phy-cells = <1>;
+ };
+
+ usbdrd3: usb at 15400000 {
+ compatible = "samsung,exynos7-dwusb3";
+ clocks = <&clock_fsys0 ACLK_USBDRD300>,
+ <&clock_fsys0 SCLK_USBDRD300_SUSPENDCLK>,
+ <&clock_fsys0 ACLK_AXIUS_USBDRD30X_FSYS0X>;
+ clock-names = "usbdrd30", "usbdrd30_susp_clk",
+ "usbdrd30_axius_clk";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dwc3 {
+ compatible = "snps,dwc3";
+ reg = <0x15400000 0x10000>;
+ interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] Add USB DRD 3.0 device node for Exynos7
From: Pankaj Dubey @ 2017-01-17 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20170117102937epcas5p1f49119a781097709b6bd6d29730c0c0f@epcas5p1.samsung.com>
This patch series adds USB 3.0 DRD device node for Exynos7 and
required Vbus and Vbus-boost support for espresso dev boards.
These patches are part of patch series [1] earlier submitted by Vivek
[1]: https://lkml.org/lkml/2014/11/21/247
While other patches in these series got merged, DTS related change were
left. I have prepared and tested these patches on top of krzk/for-next.
Pankaj Dubey (2):
arm64: dts: exynos: Add USB 3.0 controller node for Exynos7
arm64: dts: exynos: Add regulators for Vbus and Vbus-Boost
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 44 +++++++++++++++++++++++++
arch/arm64/boot/dts/exynos/exynos7.dtsi | 34 +++++++++++++++++++
2 files changed, 78 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort
From: James Morse @ 2017-01-17 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484244924-24786-5-git-send-email-tbaicar@codeaurora.org>
Hi Tyler,
On 12/01/17 18:15, Tyler Baicar wrote:
> SEA exceptions are often caused by an uncorrected hardware
> error, and are handled when data abort and instruction abort
> exception classes have specific values for their Fault Status
> Code.
> When SEA occurs, before killing the process, go through
> the handlers registered in the notification list.
> Update fault_info[] with specific SEA faults so that the
> new SEA handler is used.
> @@ -480,6 +496,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> return 1;
> }
>
> +/*
> + * This abort handler deals with Synchronous External Abort.
> + * It calls notifiers, and then returns "fault".
> + */
> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> +{
> + struct siginfo info;
> +
> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
> +
> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
> + fault_name(esr), esr, addr);
> +
> + info.si_signo = SIGBUS;
> + info.si_errno = 0;
> + info.si_code = 0;
Half of the other do_*() functions in this file read the signo and code from the
fault_info table.
> + info.si_addr = (void __user *)addr;
addr here was read from FAR_EL1, but for some of the classes of exception you
have listed below this register isn't updated with the faulting address.
The ARM-ARM version 'k' in D1.10.5 "Summary of registers on faults taken to an
Exception level that is using Aarch64" has:
> The architecture permits that the FAR_ELx is UNKNOWN for Synchronous External
> Aborts other than Synchronous External Aborts on Translation Table Walks. In
> this case, the ISS.FnV bit returned in ESR_ELx indicates whether FAR_ELx is
> valid.
This is a problem if we get 'synchronous external abort' or 'synchronous parity
error' while a user space process was running.
> + arm64_notify_die("", regs, &info, esr);
> +
> + return 0;
> +}
> +
> static const struct fault_info {
> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
> int sig;
Thanks,
James
^ permalink raw reply
* [PATCH v19 10/15] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT
From: Fu Wei @ 2017-01-17 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116183032.GL5908@leverpostej>
Hi Mark,
On 17 January 2017 at 02:30, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Dec 21, 2016 at 02:45:58PM +0800, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> The patch refactor original memory-mapped timer init code:
>> (1) Refactor "arch_timer_mem_init", make it become a common code for
>> memory-mapped timer init.
>> (2) Add a new function "arch_timer_mem_of_init" for DT init.
>
> As a general note, please write proper commit messages, describing what
> the problem is, and why we are making the changes. These bullet points
> don't add anything to what can be derived from a glance at the code.
>
> For this patch, you can use:
>
> clocksource: arm_arch_timer: refactor MMIO timer probing
>
> Currently the code to probe MMIO architected timers mixes DT parsing
> with actual poking of hardware. This makes the code harder than
> necessary to understand, and makes it difficult to add support for
> probing via ACPI.
>
> This patch factors all the DT-specific logic out of
> arch_timer_mem_init(), into a new function, arch_timer_mem_of_init().
> The former pokes the hardware and determines the suitablility of
> frames based on a datastructure populated by the latter.
>
> This cleanly separates the two and will make it possible to add
> probing using the ACPI GTDT in subsequent patches.
Great thanks for this upstream tip.
I have used your example commit message instead.
It will be in v20.
>
> [...]
>
>> + for_each_available_child_of_node(np, frame_node) {
>> + int n;
>> + struct arch_timer_mem_frame *frame = &timer_mem->frame[i];
>> +
>> + if (of_property_read_u32(frame_node, "frame-number", &n)) {
>> + pr_err("Missing frame-number\n");
>> + of_node_put(frame_node);
>> + goto out;
>> + }
>> + frame->frame_nr = n;
>> +
>> + if (of_address_to_resource(frame_node, 0, &res)) {
>> + of_node_put(frame_node);
>> + goto out;
>> + }
>> + frame->cntbase = res.start;
>> + frame->size = resource_size(&res);
>> +
>> + frame->virt_irq = irq_of_parse_and_map(frame_node,
>> + ARCH_TIMER_VIRT_SPI);
>> + frame->phys_irq = irq_of_parse_and_map(frame_node,
>> + ARCH_TIMER_PHYS_SPI);
>>
>> - if (!arch_timer_needs_of_probing())
>> + if (++i >= ARCH_TIMER_MEM_MAX_FRAMES)
>> + break;
>> + }
>
> It would be good if we could warn upon seeing more than
> ARCH_TIMER_MEM_MAX_FRAMES children, since that's obviously an error.
OK, NP, will use
if (i >= ARCH_TIMER_MEM_MAX_FRAMES) {
pr_err(FW_BUG "too many frames, ARMv8 spec only allows 8.\n");
goto out;
}
at the beginning of this loop.
Here will be replaced by i++;
Great thanks for your suggestion!
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort
From: Will Deacon @ 2017-01-17 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0ca6c70e-6033-4cca-8833-15cb8573a939@codeaurora.org>
On Mon, Jan 16, 2017 at 01:09:22PM -0700, Baicar, Tyler wrote:
> On 1/16/2017 4:53 AM, Will Deacon wrote:
> >On Thu, Jan 12, 2017 at 11:15:18AM -0700, Tyler Baicar wrote:
> >>SEA exceptions are often caused by an uncorrected hardware
> >>error, and are handled when data abort and instruction abort
> >>exception classes have specific values for their Fault Status
> >>Code.
> >>When SEA occurs, before killing the process, go through
> >>the handlers registered in the notification list.
> >>Update fault_info[] with specific SEA faults so that the
> >>new SEA handler is used.
> >>
> >>Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> >>Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> >>Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> >>---
> >> arch/arm64/include/asm/system_misc.h | 13 ++++++++
> >> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
> >> 2 files changed, 61 insertions(+), 10 deletions(-)
> >>
> >>diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> >>index 57f110b..e7f3440 100644
> >>--- a/arch/arm64/include/asm/system_misc.h
> >>+++ b/arch/arm64/include/asm/system_misc.h
> >>@@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
> >> #endif /* __ASSEMBLY__ */
> >>+/*
> >>+ * The functions below are used to register and unregister callbacks
> >>+ * that are to be invoked when a Synchronous External Abort (SEA)
> >>+ * occurs. An SEA is raised by certain fault status codes that have
> >>+ * either data or instruction abort as the exception class, and
> >>+ * callbacks may be registered to parse or handle such hardware errors.
> >>+ *
> >>+ * Registered callbacks are run in an interrupt/atomic context. They
> >>+ * are not allowed to block or sleep.
> >>+ */
> >>+int register_sea_notifier(struct notifier_block *nb);
> >>+void unregister_sea_notifier(struct notifier_block *nb);
> >I still don't understand why you need notifiers for this. You register
> >precisely one hook in the series.
> I didn't see a response to my last comment on the previous series so I just
> left it in for this series.
> The notifier usage is consistent with the GHES code for SCI errors which are
> also only used a single
> time in the code. If you think making the call directly is a better option I
> will remove the notifiers.
Yes, please. It's easy to add the notifier infrastructure back if/when it's
actually needed and I don't see why the low-level fault dispatching needs to
be consistent with the GHES/SCI code.
Will
^ permalink raw reply
* [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort
From: James Morse @ 2017-01-17 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116115309.GE1510@arm.com>
Hi Tyler,
On 16/01/17 11:53, Will Deacon wrote:
> On Thu, Jan 12, 2017 at 11:15:18AM -0700, Tyler Baicar wrote:
>> SEA exceptions are often caused by an uncorrected hardware
>> error, and are handled when data abort and instruction abort
>> exception classes have specific values for their Fault Status
>> Code.
>> When SEA occurs, before killing the process, go through
>> the handlers registered in the notification list.
>> Update fault_info[] with specific SEA faults so that the
>> new SEA handler is used.
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 05d2bd7..81039c7 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -480,6 +496,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> return 1;
>> }
>>
>> +/*
>> + * This abort handler deals with Synchronous External Abort.
>> + * It calls notifiers, and then returns "fault".
>> + */
>> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> +{
>> + struct siginfo info;
>> +
>> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
>> +
>> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>> + fault_name(esr), esr, addr);
>> +
>> + info.si_signo = SIGBUS;
>> + info.si_errno = 0;
>> + info.si_code = 0;
>> + info.si_addr = (void __user *)addr;
>> + arm64_notify_die("", regs, &info, esr);
>> +
>> + return 0;
>> +}
>> +
>> static const struct fault_info {
>> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
>> int sig;
>> @@ -502,22 +540,22 @@ static const struct fault_info {
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
>> - { do_bad, SIGBUS, 0, "synchronous external abort" },
>> + { do_sea, SIGBUS, 0, "synchronous external abort" },
>> { do_bad, SIGBUS, 0, "unknown 17" },
>> { do_bad, SIGBUS, 0, "unknown 18" },
>> { do_bad, SIGBUS, 0, "unknown 19" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous parity error" },
>> + { do_sea, SIGBUS, 0, "level 0 SEA (translation table walk)" },
>> + { do_sea, SIGBUS, 0, "level 1 SEA (translation table walk)" },
>> + { do_sea, SIGBUS, 0, "level 2 SEA (translation table walk)" },
>> + { do_sea, SIGBUS, 0, "level 3 SEA (translation table walk)" },
>
> Perhaps I wasn't clear enough in my previous review, but please expand the
> acronym for strings and comments.
The 'SEA' in this user-string doesn't add anything. Now that these use do_sea()
instead of do_bad(), when they are printed won't it be:
> Synchronous External Abort: level 3 SEA (translation table walk) (...) at ....
Thanks,
James
^ permalink raw reply
* [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Neil Armstrong @ 2017-01-17 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117093813.mxp2hgoxbgske6ru@lukather>
On 01/17/2017 10:38 AM, Maxime Ripard wrote:
> Hi,
>
> On Mon, Jan 16, 2017 at 08:49:06PM +0200, Krzysztof Kozlowski wrote:
>> On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
>>> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
>>> Allwinner, Amlogic, Mediatek or Rockchip.
>>>
>>> Add a binding for the GPU of that family.
>>>
>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>> ---
>>> .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
>>> 1 file changed, 76 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>>
>> Do you have a driver in kernel which will implement these bindings?
>
> No, but we have bindings for out-of-tree drivers already.
>
>> Defining them for out-of-tree driver does not bring any benefits
>> (3rd party driver will not respect them anyway).
>
> You could see it the other way around too. The out-of-tree drivers
> don't respect it at the moment because there's no binding to respect.
>
> And at least for us, we definitely plan on doing that.
>
> Maxime
Hi Maxime, Krzysztof,
We hope this will be accepted so it will solve the same issue we have on Amlogic SoCs
and all the other mali powered SoCs.
Having mainline bindings will forcre out-of-tree driver to respect those bindings
and remove a dts out-of-tree patch aswell.
Neil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/4be3a61c/attachment.sig>
^ permalink raw reply
* [RFC PATCH 33/33] irqchip/gic-v4: Enable low-level GICv4 operations
From: Marc Zyngier @ 2017-01-17 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484648454-21216-1-git-send-email-marc.zyngier@arm.com>
Get the show on the road...
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/irqchip/Makefile | 2 +-
drivers/irqchip/irq-gic-v3-its.c | 2 +-
drivers/irqchip/irq-gic-v4.c | 11 +++++++++++
include/linux/irqchip/arm-gic-v4.h | 2 ++
4 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 0e55d94..d57e03f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_ARM_GIC_PM) += irq-gic-pm.o
obj-$(CONFIG_ARCH_REALVIEW) += irq-gic-realview.o
obj-$(CONFIG_ARM_GIC_V2M) += irq-gic-v2m.o
obj-$(CONFIG_ARM_GIC_V3) += irq-gic-v3.o irq-gic-common.o
-obj-$(CONFIG_ARM_GIC_V3_ITS) += irq-gic-v3-its.o irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o
+obj-$(CONFIG_ARM_GIC_V3_ITS) += irq-gic-v3-its.o irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o irq-gic-v4.o
obj-$(CONFIG_PARTITION_PERCPU) += irq-partition-percpu.o
obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 3787579..5658dd8 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2824,7 +2824,7 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
has_v4 |= its->is_v4;
if (has_v4 & rdists->has_vlpis)
- its_init_vpe_domain();
+ its_init_v4(its_init_vpe_domain());
return 0;
}
diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
index 8b2d9ee..38ce6f0 100644
--- a/drivers/irqchip/irq-gic-v4.c
+++ b/drivers/irqchip/irq-gic-v4.c
@@ -228,3 +228,14 @@ int its_prop_update_vlpi(int irq, u8 config)
return irq_set_vcpu_affinity(irq, &info);
}
+
+void its_init_v4(struct irq_domain *domain)
+{
+ if (domain) {
+ pr_info("ITS: Enabling GICv4 support\n");
+ its_vpe_domain = domain;
+ return;
+ }
+
+ pr_err("ITS: No GICv4 VPE domain allocated\n");
+}
diff --git a/include/linux/irqchip/arm-gic-v4.h b/include/linux/irqchip/arm-gic-v4.h
index f85a929..b87c54f 100644
--- a/include/linux/irqchip/arm-gic-v4.h
+++ b/include/linux/irqchip/arm-gic-v4.h
@@ -97,4 +97,6 @@ int its_map_vlpi(int irq, struct its_vlpi_map *map);
int its_unmap_vlpi(int irq);
int its_prop_update_vlpi(int irq, u8 config);
+void its_init_v4(struct irq_domain *domain);
+
#endif
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 32/33] irqchip/gic-v4: Add some basic documentation
From: Marc Zyngier @ 2017-01-17 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484648454-21216-1-git-send-email-marc.zyngier@arm.com>
Do a braindump of the way things are supposed to work.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/irqchip/irq-gic-v4.c | 59 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
index 36ccaac..8b2d9ee 100644
--- a/drivers/irqchip/irq-gic-v4.c
+++ b/drivers/irqchip/irq-gic-v4.c
@@ -22,6 +22,65 @@
#include <linux/irqchip/arm-gic-v4.h>
+/*
+ * WARNING: The blurb below assumes that you understand the
+ * intricacies of GICv3, GICv4, and how a guest's view of a GICv3 gets
+ * translated into GICv4 comands. So it effectively targets at most
+ * two individuals. You know who you are.
+ *
+ * The core GICv4 code is designed to *avoid* exposing too much of the
+ * core GIC code (that would in turn leak into the hypervisor code),
+ * and instead provide a hypervisor agnostic interface to the HW (of
+ * course, the astute reader will quickly realize that hypervisor
+ * agnostic actually means KVM-specific - what were you thinking?).
+ *
+ * In order to achieve a modicum of isolation, we try to hide most of
+ * the GICv4 "stuff" behind normal irqchip operations:
+ *
+ * - Any guest-visible VLPI is backed by a Linux interrupt (and a
+ * physical LPI which gets deconfigured when the guest maps the
+ * VLPI). This allows the same DevID/Event pair to be either mapped
+ * to the LPI (host) or the VLPI (guest).
+ *
+ * - Enabling/disabling a VLPI is done by issuing mask/unmask calls.
+ *
+ * - Guest INT/CLEAR commands are implemented through
+ * irq_set_irqchip_state().
+ *
+ * - The *bizarre* stuff (mapping/unmapping an interrupt to a VLPI, or
+ * issuing an INV after changing a priority) gets shoved into the
+ * irq_set_vcpu_affinity() method. While this is quite horrible
+ * (let's face it, this is the irqchip version of an ioctl), it
+ * confines the crap to a single location. And map/unmap really is
+ * about setting the affinity of a VLPI to a vcpu, so only INV is
+ * majorly out of place. So there.
+ *
+ * But handling VLPIs is only one side of the job of the GICv4
+ * code. The other (darker) side is to take care of the doorbell
+ * interrupts which are delivered when a VLPI targeting a non-running
+ * vcpu is being made pending.
+ *
+ * The choice made here is that each vcpu (VPE in old northern GICv4
+ * dialect) gets a single doorbell, no matter how many interrupts are
+ * targeting it. This has a nice property, which is that the interrupt
+ * becomes a handle for the VPE, and that the hypervisor code can
+ * manipulate it through the normal interrupt API:
+ *
+ * - VMs (or rather the VM abstraction that matters to the GIC)
+ * contain an irq domain where each interrupt maps to a VPE. In
+ * turn, this domain stis on top of the normal LPI allocator, and a
+ * specially crafted irq_chip implementation.
+ *
+ * - mask/unmask do what is expected on the doorbell interrupt.
+ *
+ * - irq_set_affinity is used to move a VPE from one redistributor to
+ * another.
+ *
+ * - irq_set_vcpu_affinity once again gets hijacked for the purpose of
+ * creating a new sub-API, namely scheduling/descheduling a VPE and
+ * performing INVALL operations.
+ */
+
static struct irq_domain *its_vpe_domain;
static struct irq_chip its_vcpu_irq_chip = {
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 31/33] irqchip/gic-v4: Add VLPI configuration interface
From: Marc Zyngier @ 2017-01-17 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484648454-21216-1-git-send-email-marc.zyngier@arm.com>
Add the required interfaces to map, unmap and update a VLPI.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/irqchip/irq-gic-v4.c | 29 +++++++++++++++++++++++++++++
include/linux/irqchip/arm-gic-v4.h | 3 +++
2 files changed, 32 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
index 7d74089..36ccaac 100644
--- a/drivers/irqchip/irq-gic-v4.c
+++ b/drivers/irqchip/irq-gic-v4.c
@@ -140,3 +140,32 @@ int its_invall_vpe(struct its_vpe *vpe)
return its_send_vpe_cmd(vpe, &info);
}
+
+int its_map_vlpi(int irq, struct its_vlpi_map *map)
+{
+ struct its_cmd_info info = {
+ .cmd_type = MAP_VLPI,
+ .map = map,
+ };
+
+ return irq_set_vcpu_affinity(irq, &info);
+}
+
+int its_unmap_vlpi(int irq)
+{
+ struct its_cmd_info info = {
+ .cmd_type = UNMAP_VLPI,
+ };
+
+ return irq_set_vcpu_affinity(irq, &info);
+}
+
+int its_prop_update_vlpi(int irq, u8 config)
+{
+ struct its_cmd_info info = {
+ .cmd_type = PROP_UPDATE_VLPI,
+ .config = config,
+ };
+
+ return irq_set_vcpu_affinity(irq, &info);
+}
diff --git a/include/linux/irqchip/arm-gic-v4.h b/include/linux/irqchip/arm-gic-v4.h
index 1c58add..f85a929 100644
--- a/include/linux/irqchip/arm-gic-v4.h
+++ b/include/linux/irqchip/arm-gic-v4.h
@@ -93,5 +93,8 @@ int its_alloc_vcpu_irqs(struct its_vm *vm, struct its_vpe **vpes, int nr_vpes);
void its_free_vcpu_irqs(struct its_vm *vm, int nr_vpes);
int its_schedule_vpe(struct its_vpe *vpe, bool on);
int its_invall_vpe(struct its_vpe *vpe);
+int its_map_vlpi(int irq, struct its_vlpi_map *map);
+int its_unmap_vlpi(int irq);
+int its_prop_update_vlpi(int irq, u8 config);
#endif
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox