* [PATCH 0/7] ARM: dts: dra7: Enable x2 lane mode support
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
Add properties to enable PCIe x2 lane mode since all dra7
based SoCs support x2 lane mode.
However only dra76-evm has a slot which can support x2 lane
cards. Hence only enable x2 lane mode in dra76-evm.
(am571x-idk can support x2 lane mode but that makes usb port
not functional so not including the patch to enable
x2 mode in am571x-idk)
Also included in this series is patch to enable PCIe configs
(both host and device) in omap2plus_defconfig and
multi_v7_defconfig
In order to get x2 mode working [1] is required.
However by keeping the older compatible, this series won't
break functionality if this series is merged before [1]
[1] -> https://lkml.org/lkml/2017/12/19/175
Kishon Vijay Abraham I (7):
ARM: dts: dra7: Add properties to enable PCIe x2 lane mode
ARM: dts: DRA74x: Use PCIe compatible specific to dra74
ARM: dts: DRA72x: Use PCIe compatible specific to dra72
ARM: dts: dra76-evm: Enable x2 PCIe lanes
ARM: dts: dra7: Remove deprecated PCI compatible string
ARM: omap2plus_defconfig: Enable CONFIG_PCI_DRA7XX (Host & Device
modes)
ARM: multi_v7_defconfig: Enable CONFIG_PCI_DRA7XX (Host & Device
modes)
arch/arm/boot/dts/dra7.dtsi | 9 +++++----
arch/arm/boot/dts/dra72x.dtsi | 12 ++++++++++++
arch/arm/boot/dts/dra74x.dtsi | 12 ++++++++++++
arch/arm/boot/dts/dra76-evm.dts | 16 ++++++++++++++++
arch/arm/configs/multi_v7_defconfig | 6 ++++++
arch/arm/configs/omap2plus_defconfig | 8 ++++++++
6 files changed, 59 insertions(+), 4 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/7] ARM: dts: dra7: Add properties to enable PCIe x2 lane mode
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
ti,syscon-lane-sel and ti,syscon-lane-conf properties specific to enable
PCIe x2 lane mode are added here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ac9216293b7c..9966d82dbd7c 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -309,6 +309,8 @@
ti,hwmods = "pcie1";
phys = <&pcie1_phy>;
phy-names = "pcie-phy0";
+ ti,syscon-lane-conf = <&scm_conf 0x558>;
+ ti,syscon-lane-sel = <&scm_conf_pcie 0x18>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie1_intc 1>,
<0 0 0 2 &pcie1_intc 2>,
@@ -334,6 +336,8 @@
phys = <&pcie1_phy>;
phy-names = "pcie-phy0";
ti,syscon-unaligned-access = <&scm_conf1 0x14 2>;
+ ti,syscon-lane-conf = <&scm_conf 0x558>;
+ ti,syscon-lane-sel = <&scm_conf_pcie 0x18>;
status = "disabled";
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/7] ARM: dts: DRA74x: Use PCIe compatible specific to dra74
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
Use dra74 specific compatible string for PCIe while preserving
the older compatible. While at that add a new label for the
2nd instance of pcie.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/dra74x.dtsi | 12 ++++++++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9966d82dbd7c..333f6a634ff9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -349,7 +349,7 @@
ranges = <0x51800000 0x51800000 0x3000
0x0 0x30000000 0x10000000>;
status = "disabled";
- pcie at 51800000 {
+ pcie2_rc: pcie at 51800000 {
compatible = "ti,dra7-pcie";
reg = <0x51800000 0x2000>, <0x51802000 0x14c>, <0x1000 0x2000>;
reg-names = "rc_dbics", "ti_conf", "config";
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 24e6746c5b26..a001eecf3b14 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -124,3 +124,15 @@
status = "disabled";
};
};
+
+&pcie1_rc {
+ compatible = "ti,dra746-pcie-rc", "ti,dra7-pcie";
+};
+
+&pcie1_ep {
+ compatible = "ti,dra746-pcie-ep", "ti,dra7-pcie-ep";
+};
+
+&pcie2_rc {
+ compatible = "ti,dra746-pcie-rc", "ti,dra7-pcie";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 3/7] ARM: dts: DRA72x: Use PCIe compatible specific to dra72
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
Use dra72 specific compatible string for PCIe while preserving
the older compatible.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra72x.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index 67107605fb4c..2dafad834d3d 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -50,3 +50,15 @@
status = "disabled";
};
};
+
+&pcie1_rc {
+ compatible = "ti,dra726-pcie-rc", "ti,dra7-pcie";
+};
+
+&pcie1_ep {
+ compatible = "ti,dra726-pcie-ep", "ti,dra7-pcie-ep";
+};
+
+&pcie2_rc {
+ compatible = "ti,dra726-pcie-rc", "ti,dra7-pcie";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 4/7] ARM: dts: dra76-evm: Enable x2 PCIe lanes
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
DRA76 EVM has a 4-lane PCIe connector and DRA76 can support x2 lanes.
Enable both the PCIe lanes here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra76-evm.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index b024a65c6e27..244e553f2247 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -421,3 +421,19 @@
spi-max-frequency = <96000000>;
};
};
+
+&pcie2_phy {
+ status = "okay";
+};
+
+&pcie1_rc {
+ num-lanes = <2>;
+ phys = <&pcie1_phy>, <&pcie2_phy>;
+ phy-names = "pcie-phy0", "pcie-phy1";
+};
+
+&pcie1_ep {
+ num-lanes = <2>;
+ phys = <&pcie1_phy>, <&pcie2_phy>;
+ phy-names = "pcie-phy0", "pcie-phy1";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 5/7] ARM: dts: dra7: Remove deprecated PCI compatible string
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
Since SoC specific compatible strings are used for PCIe in
dra74x.dtsi and dra72x.dtsi, remove the compatible property
from dra7.dtsi which uses the deprecated compatible string.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 333f6a634ff9..1efa908c7bce 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -293,7 +293,6 @@
* node and enable pcie1_ep mode.
*/
pcie1_rc: pcie at 51000000 {
- compatible = "ti,dra7-pcie";
reg = <0x51000000 0x2000>, <0x51002000 0x14c>, <0x1000 0x2000>;
reg-names = "rc_dbics", "ti_conf", "config";
interrupts = <0 232 0x4>, <0 233 0x4>;
@@ -325,7 +324,6 @@
};
pcie1_ep: pcie_ep at 51000000 {
- compatible = "ti,dra7-pcie-ep";
reg = <0x51000000 0x28>, <0x51002000 0x14c>, <0x51001000 0x28>, <0x1000 0x10000000>;
reg-names = "ep_dbics", "ti_conf", "ep_dbics2", "addr_space";
interrupts = <0 232 0x4>;
@@ -350,7 +348,6 @@
0x0 0x30000000 0x10000000>;
status = "disabled";
pcie2_rc: pcie at 51800000 {
- compatible = "ti,dra7-pcie";
reg = <0x51800000 0x2000>, <0x51802000 0x14c>, <0x1000 0x2000>;
reg-names = "rc_dbics", "ti_conf", "config";
interrupts = <0 355 0x4>, <0 356 0x4>;
--
2.11.0
^ permalink raw reply related
* [PATCH 6/7] ARM: omap2plus_defconfig: Enable CONFIG_PCI_DRA7XX (Host & Device modes)
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
Enable CONFIG_PCI_DRA7XX in order to be able to configure PCIe
controller present in dra7 SoCs in both host mode and device mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 7b97200c1d64..a01871d5aa73 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -48,6 +48,13 @@ CONFIG_SOC_AM43XX=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_ERRATA_411920=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_DRA7XX=y
+CONFIG_PCI_DRA7XX_EP=y
+CONFIG_PCI_ENDPOINT=y
+CONFIG_PCI_ENDPOINT_CONFIGFS=y
+CONFIG_PCI_EPF_TEST=m
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_CMA=y
@@ -137,6 +144,7 @@ CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_SENSORS_TSL2550=m
CONFIG_SRAM=y
+CONFIG_PCI_ENDPOINT_TEST=m
CONFIG_EEPROM_AT24=m
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_SCAN_ASYNC=y
--
2.11.0
^ permalink raw reply related
* [PATCH 7/7] ARM: multi_v7_defconfig: Enable CONFIG_PCI_DRA7XX (Host & Device modes)
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
Enable CONFIG_PCI_DRA7XX in order to be able to configure PCIe
controller present in dra7 SoCs in both host mode and device mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/configs/multi_v7_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 61509c4b769f..6faecd55ccbd 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -116,6 +116,8 @@ CONFIG_ARCH_ZYNQ=y
CONFIG_TRUSTED_FOUNDATIONS=y
CONFIG_PCI=y
CONFIG_PCI_HOST_GENERIC=y
+CONFIG_PCI_DRA7XX=y
+CONFIG_PCI_DRA7XX_EP=y
CONFIG_PCI_KEYSTONE=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MVEBU=y
@@ -123,6 +125,9 @@ CONFIG_PCI_TEGRA=y
CONFIG_PCI_RCAR_GEN2=y
CONFIG_PCIE_RCAR=y
CONFIG_PCIEPORTBUS=y
+CONFIG_PCI_ENDPOINT=y
+CONFIG_PCI_ENDPOINT_CONFIGFS=y
+CONFIG_PCI_EPF_TEST=m
CONFIG_SMP=y
CONFIG_NR_CPUS=16
CONFIG_HIGHPTE=y
@@ -222,6 +227,7 @@ CONFIG_ATMEL_SSC=m
CONFIG_QCOM_COINCELL=m
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
+CONFIG_PCI_ENDPOINT_TEST=m
CONFIG_EEPROM_AT24=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
--
2.11.0
^ permalink raw reply related
* [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver
From: Mark Brown @ 2017-12-19 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <43426b67-3546-8422-7fcb-9fa1ff192679@st.com>
On Fri, Dec 15, 2017 at 03:15:22PM +0000, Olivier MOYSAN wrote:
> You are right. wm8994 allows to select either MCLK for each AIF.
> From this point of view, the current patch is too limiting.
> MCLK information in DT allows to enforce MCLK use, but an additionnal
> information is required to determine AIF MCLK assignment.
> Available properties in codec DAI node, such as clocks property, cannot
> help here.
> Maybe a DAPM linked to a control is a better way to select AIF source,
> When source is not provided by clk_id in wm8994_set_dai_sysclk().
> In this case, wm8994_set_dai_sysclk() would only have to check
> if clock source is not already set.
> Please let me know if this option sounds better to you.
What are you trying to accomplish here? You appear to be trying to move
the system clocking configuration from the machine driver to the CODEC
which is not how things are supposed to work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171219/7608e3f2/attachment.sig>
^ permalink raw reply
* [PATCH v5 7/9] arm64: Topology, rename cluster_id
From: Morten Rasmussen @ 2017-12-19 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218154703.GA8157@red-moon>
On Mon, Dec 18, 2017 at 03:47:03PM +0000, Lorenzo Pieralisi wrote:
> On Mon, Dec 18, 2017 at 12:42:29PM +0000, Morten Rasmussen wrote:
> > On Fri, Dec 15, 2017 at 10:36:35AM -0600, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 12/13/2017 12:02 PM, Lorenzo Pieralisi wrote:
> > > >[+Morten, Dietmar]
> > > >
> > > >$SUBJECT should be:
> > > >
> > > >arm64: topology: rename cluster_id
> > >
> > > Sure..
> > >
> > > >
> > > >On Fri, Dec 01, 2017 at 04:23:28PM -0600, Jeremy Linton wrote:
> > > >>Lets match the name of the arm64 topology field
> > > >>to the kernel macro that uses it.
> > > >>
> > > >>Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> > > >>---
> > > >> arch/arm64/include/asm/topology.h | 4 ++--
> > > >> arch/arm64/kernel/topology.c | 27 ++++++++++++++-------------
> > > >> 2 files changed, 16 insertions(+), 15 deletions(-)
> > > >>
> > > >>diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> > > >>index c4f2d50491eb..118136268f66 100644
> > > >>--- a/arch/arm64/include/asm/topology.h
> > > >>+++ b/arch/arm64/include/asm/topology.h
> > > >>@@ -7,14 +7,14 @@
> > > >> struct cpu_topology {
> > > >> int thread_id;
> > > >> int core_id;
> > > >>- int cluster_id;
> > > >>+ int physical_id;
> > > >
> > > >package_id ?
> > >
> > > Given the macro is topology_physical_package_id, either makes sense to me.
> > > <shrug> I will change it in the next set.
> >
> > I would vote for package_id too. arch/arm has 'socket_id' though.
> >
> > > >
> > > >It has been debated before, I know. Should we keep the cluster_id too
> > > >(even if it would be 1:1 mapped to package_id - for now) ?
> > >
> > > Well given that this patch replaces the patch that did that at your
> > > request..
> > >
> > > I was hoping someone else would comment here, but my take at this point is
> > > that it doesn't really matter in a functional sense at the moment.
> > > Like the chiplet discussion it can be the subject of a future patch along
> > > with the patches which tweak the scheduler to understand the split.
> > >
> > > BTW, given that i'm OoO next week, and the following that are the holidays,
> > > I don't intend to repost this for a couple weeks. I don't think there are
> > > any issues with this set.
> > >
> > > >
> > > >There is also arch/arm to take into account, again, this patch is
> > > >just renaming (as it should have named since the beginning) a
> > > >topology level but we should consider everything from a legacy
> > > >perspective.
> >
> > arch/arm has gone for thread/core/socket for the three topology levels
> > it supports.
> >
> > I'm not sure what short term value keeping cluster_id has? Isn't it just
> > about where we make the package = cluster assignment? Currently it is in
> > the definition of topology_physical_package_id. If we keep cluster_id
> > and add package_id, it gets moved into the MPIDR/DT parsing code.
> >
> > Keeping cluster_id and introducing a topology_cluster_id function could
> > help cleaning up some of the users of topology_physical_package_id that
> > currently assumes package_id == cluster_id though.
>
> I think we should settle for a name (eg package_id), remove cluster_id
> and convert arch/arm socket_id to the same naming used on arm64 (for
> consistency - it is just a variable rename).
Agreed.
> This leaves us with the naming "cluster" only in DT topology bindings,
> which should be fine, given that "cluster" in that context is just a
> "processor-container" - yes we could have chosen a better naming in
> the first place but that's what it is.
I think having "clusters" in DT is fine as it represent the actual
hardware topology and uses the actual "Arm" term to describe it. The
default topology in Linux just doesn't have an equivalent topology
level, but that can be fixed. DT is however missing a notion of package.
> We should nuke the existing users of topology_physical_package_id()
> to identify clusters, I would not add another function for that purpose,
> let's nip it in the bud.
Even better if that can be pulled of.
Morten
^ permalink raw reply
* [RFC PATCH v2] draft for gpio pinconf
From: Ludovic Desroches @ 2017-12-19 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
Hi,
After discussing with Maxime Ripard, I realize that the first approach
may not be a good one.
For instance, the drive-strength is a digital value so it will take
ake several bits. Having a whole pin configuration in 32 bits may not
be the right solution.
My aim is to use the existing pinconf bindings.
This patch is a draft to test the feasibility. Sorry to provide it in
this state (several ugly hacks) but I didn't want to spend time on a clean
solution if it will be rejected.
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 +-----
arch/arm/boot/dts/sama5d2.dtsi | 2 +-
drivers/gpio/gpiolib-of.c | 10 +++++++++-
drivers/gpio/gpiolib.c | 24 +++++++++++++++++++-----
drivers/gpio/gpiolib.h | 2 ++
drivers/pinctrl/core.c | 5 ++---
drivers/pinctrl/pinctrl-at91-pio4.c | 19 +++++++++++++++++++
include/linux/gpio/driver.h | 5 +++--
include/linux/pinctrl/consumer.h | 4 ++--
9 files changed, 58 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 56de21de2779..709c9c3ae622 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -413,7 +413,6 @@
};
pinctrl_key_gpio_default: key_gpio_default {
- pinmux = <PIN_PB9__GPIO>;
bias-pull-up;
};
@@ -545,12 +544,9 @@
gpio_keys {
compatible = "gpio-keys";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_key_gpio_default>;
-
bp1 {
label = "PB_USER";
- gpios = <&pioA PIN_PB9 GPIO_ACTIVE_LOW>;
+ gpios = <&pioA PIN_PB9 GPIO_ACTIVE_LOW &pinctrl_key_gpio_default>;
linux,code = <0x104>;
wakeup-source;
};
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index b44e63995583..cccd404192cc 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -1444,7 +1444,7 @@
interrupt-controller;
#interrupt-cells = <2>;
gpio-controller;
- #gpio-cells = <2>;
+ #gpio-cells = <3>;
clocks = <&pioA_clk>;
};
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 4a2b8d3397c7..605017a4d2d8 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -46,7 +46,7 @@ static struct gpio_desc *of_xlate_and_get_gpiod_flags(struct gpio_chip *chip,
{
int ret;
- if (chip->of_gpio_n_cells != gpiospec->args_count)
+ if (chip->of_gpio_n_cells > gpiospec->args_count)
return ERR_PTR(-EINVAL);
ret = chip->of_xlate(chip, gpiospec, flags);
@@ -93,6 +93,14 @@ struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np,
if (IS_ERR(desc))
goto out;
+ if (gpiospec.args_count > chip->of_gpio_n_cells) {
+ desc->np_pincfg = of_parse_phandle(np, propname, gpiospec.args_count);
+ if (!desc->np_pincfg) {
+ printk("ERROR\n");
+ goto out;
+ }
+ }
+
pr_debug("%s: parsed '%s' property of node '%pOF[%d]' - status (%d)\n",
__func__, propname, np, index,
PTR_ERR_OR_ZERO(desc));
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 0621baddfddc..543a120a0f84 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -29,6 +29,8 @@
#include <uapi/linux/gpio.h>
#include "gpiolib.h"
+#include "../pinctrl/core.h"
+#include "../pinctrl/pinconf.h"
#define CREATE_TRACE_POINTS
#include <trace/events/gpio.h>
@@ -1997,9 +1999,9 @@ EXPORT_SYMBOL_GPL(gpiochip_generic_free);
* @config: the configuration to be applied
*/
int gpiochip_generic_config(struct gpio_chip *chip, unsigned offset,
- unsigned long config)
+ unsigned long *configs, unsigned num_configs)
{
- return pinctrl_gpio_set_config(chip->gpiodev->base + offset, config);
+ return pinctrl_gpio_set_config(chip->gpiodev->base + offset, configs, num_configs);
}
EXPORT_SYMBOL_GPL(gpiochip_generic_config);
@@ -2161,6 +2163,18 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
goto done;
}
}
+ if (chip->set_config) {
+ unsigned long *configs;
+ unsigned num_configs;
+ int ret;
+
+ ret = pinconf_generic_parse_dt_config(desc->np_pincfg, NULL, &configs, &num_configs);
+ if (ret < 0) {
+ /* TODO */
+ }
+ chip->set_config(chip, gpio_chip_hwgpio(desc), configs, num_configs);
+ kfree(configs);
+ }
if (chip->get_direction) {
/* chip->get_direction may sleep */
spin_unlock_irqrestore(&gpio_lock, flags);
@@ -2404,7 +2418,7 @@ static int gpio_set_drive_single_ended(struct gpio_chip *gc, unsigned offset,
{
unsigned long config = { PIN_CONF_PACKED(mode, 0) };
- return gc->set_config ? gc->set_config(gc, offset, config) : -ENOTSUPP;
+ return gc->set_config ? gc->set_config(gc, offset, &config, 1) : -ENOTSUPP;
}
static int gpiod_direction_output_raw_commit(struct gpio_desc *desc, int value)
@@ -2529,7 +2543,7 @@ int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce)
}
config = pinconf_to_config_packed(PIN_CONFIG_INPUT_DEBOUNCE, debounce);
- return chip->set_config(chip, gpio_chip_hwgpio(desc), config);
+ return chip->set_config(chip, gpio_chip_hwgpio(desc), &config, 1);
}
EXPORT_SYMBOL_GPL(gpiod_set_debounce);
@@ -2565,7 +2579,7 @@ int gpiod_set_transitory(struct gpio_desc *desc, bool transitory)
packed = pinconf_to_config_packed(PIN_CONFIG_PERSIST_STATE,
!transitory);
gpio = gpio_chip_hwgpio(desc);
- rc = chip->set_config(chip, gpio, packed);
+ rc = chip->set_config(chip, gpio, &packed, 1);
if (rc == -ENOTSUPP) {
dev_dbg(&desc->gdev->dev, "Persistence not supported for GPIO %d\n",
gpio);
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index 5e1f7cc6eeb6..79119548cc33 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -215,6 +215,8 @@ struct gpio_desc {
const char *label;
/* Name of the GPIO */
const char *name;
+ /* Pin configuration node */
+ struct device_node *np_pincfg;
};
int gpiod_request(struct gpio_desc *desc, const char *label);
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 4c8d5b23e4d0..89976f35a6a3 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -857,9 +857,8 @@ EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_output);
* they need to call the underlying pin controller to change GPIO config
* (for example set debounce time).
*/
-int pinctrl_gpio_set_config(unsigned gpio, unsigned long config)
+int pinctrl_gpio_set_config(unsigned gpio, unsigned long *configs, unsigned num_configs)
{
- unsigned long configs[] = { config };
struct pinctrl_gpio_range *range;
struct pinctrl_dev *pctldev;
int ret, pin;
@@ -870,7 +869,7 @@ int pinctrl_gpio_set_config(unsigned gpio, unsigned long config)
mutex_lock(&pctldev->mutex);
pin = gpio_to_pin(range, gpio);
- ret = pinconf_set_config(pctldev, pin, configs, ARRAY_SIZE(configs));
+ ret = pinconf_set_config(pctldev, pin, configs, num_configs);
mutex_unlock(&pctldev->mutex);
return ret;
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index b1ca838dd80a..477a4d7ddbaf 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -358,12 +358,15 @@ static int atmel_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
}
static struct gpio_chip atmel_gpio_chip = {
+ .request = gpiochip_generic_request,
+ .free = gpiochip_generic_free,
.direction_input = atmel_gpio_direction_input,
.get = atmel_gpio_get,
.direction_output = atmel_gpio_direction_output,
.set = atmel_gpio_set,
.to_irq = atmel_gpio_to_irq,
.base = 0,
+ .set_config = gpiochip_generic_config,
};
/* --- PINCTRL --- */
@@ -643,11 +646,26 @@ static int atmel_pmx_set_mux(struct pinctrl_dev *pctldev,
return 0;
}
+static int atmel_pmx_gpio_request_enable(struct pinctrl_dev *pctldev, struct pinctrl_gpio_range *range, unsigned offset)
+{
+ u32 conf;
+
+ conf = atmel_pin_config_read(pctldev, offset);
+ conf &= (~ATMEL_PIO_CFGR_FUNC_MASK);
+ atmel_pin_config_write(pctldev, offset, conf);
+
+ dev_dbg(pctldev->dev, "enable pin %u as GPIO\n", offset);
+
+ return 0;
+}
+
static const struct pinmux_ops atmel_pmxops = {
+ .gpio_request_enable = atmel_pmx_gpio_request_enable,
.get_functions_count = atmel_pmx_get_functions_count,
.get_function_name = atmel_pmx_get_function_name,
.get_function_groups = atmel_pmx_get_function_groups,
.set_mux = atmel_pmx_set_mux,
+ .strict = true,
};
static int atmel_conf_pin_config_group_get(struct pinctrl_dev *pctldev,
@@ -817,6 +835,7 @@ static void atmel_conf_pin_config_dbg_show(struct pinctrl_dev *pctldev,
}
static const struct pinconf_ops atmel_confops = {
+ .pin_config_set = atmel_conf_pin_config_group_set,
.pin_config_group_get = atmel_conf_pin_config_group_get,
.pin_config_group_set = atmel_conf_pin_config_group_set,
.pin_config_dbg_show = atmel_conf_pin_config_dbg_show,
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 55e672592fa9..b54968cd6dfc 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -247,7 +247,8 @@ struct gpio_chip {
unsigned long *bits);
int (*set_config)(struct gpio_chip *chip,
unsigned offset,
- unsigned long config);
+ unsigned long *configs,
+ unsigned num_configs);
int (*to_irq)(struct gpio_chip *chip,
unsigned offset);
@@ -490,7 +491,7 @@ static inline int gpiochip_irqchip_add_nested(struct gpio_chip *gpiochip,
int gpiochip_generic_request(struct gpio_chip *chip, unsigned offset);
void gpiochip_generic_free(struct gpio_chip *chip, unsigned offset);
int gpiochip_generic_config(struct gpio_chip *chip, unsigned offset,
- unsigned long config);
+ unsigned long *configs, unsigned num_configs);
#ifdef CONFIG_PINCTRL
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index 0412cc9833e9..14be53e1e053 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -29,7 +29,7 @@ extern int pinctrl_gpio_request(unsigned gpio);
extern void pinctrl_gpio_free(unsigned gpio);
extern int pinctrl_gpio_direction_input(unsigned gpio);
extern int pinctrl_gpio_direction_output(unsigned gpio);
-extern int pinctrl_gpio_set_config(unsigned gpio, unsigned long config);
+extern int pinctrl_gpio_set_config(unsigned gpio, unsigned long *configs, unsigned num_configs);
extern struct pinctrl * __must_check pinctrl_get(struct device *dev);
extern void pinctrl_put(struct pinctrl *p);
@@ -81,7 +81,7 @@ static inline int pinctrl_gpio_direction_output(unsigned gpio)
return 0;
}
-static inline int pinctrl_gpio_set_config(unsigned gpio, unsigned long config)
+static inline int pinctrl_gpio_set_config(unsigned gpio, unsigned long *configs, unsigned num_configs)
{
return 0;
}
--
2.12.2
^ permalink raw reply related
* [PATCH 0/6] arm64: provide pseudo NMI with GICv3
From: Julien Thierry @ 2017-12-19 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512493912-37478-1-git-send-email-julien.thierry@arm.com>
Hi,
Just a little Christmas ping on this series.
Cheers,
On 05/12/17 17:11, Julien Thierry wrote:
> Hi,
>
> This series is a continuation of the work started by Daniel [1]. The goal is
> to use GICv3 interrupt priorities to simulate an NMI.
>
> To achieve this, set two priorities, one for standard interrupts and
> another, higher priority, for NMIs. Whenever we want to disable interrupts,
> we mask the standard priority instead so NMIs can still be raised. Some
> corner cases though still require to actually mask all interrupts
> effectively disabling the NMI.
>
> Of course, using priority masking instead of PSR.I comes at some cost. On
> hackbench, I notice a ~6-0% drop of performance. When I submitted the RFC,
> the drop seemed always present, now things seem more variable. On a kernel
> build, there still isn't any significan drop of performance.
> KVM Guests do not seem to be affected preformance-wise by the host using
> PMR to mask interrupts or not.
>
> Results when using this NMI for the arm_pmu interrupt are rather positive
> (at least for _raw_spin_unlock_irq_restore).
> Perf record on hackbench without NMI:
>
> # Overhead Command Symbol
> # ........ ............... ...........................................
> #
> 12.45% hackbench [k] _raw_spin_unlock_irqrestore
> 6.26% hackbench [k] el0_svc_naked
> 5.35% hackbench [k] unix_stream_read_generic
> 4.42% hackbench [k] __arch_copy_to_user
> 3.87% hackbench [k] refcount_inc_not_zero
> 3.70% hackbench [k] __slab_free
> 3.66% hackbench [k] _raw_spin_unlock_irq
> 3.53% hackbench [k] skb_release_data
> 3.10% hackbench [k] kmem_cache_free
> 2.90% hackbench [k] __lock_text_start
>
> Perf record on hackbench with PseudoNMI:
>
> # Overhead Command Symbol
> # ........ ............... .................................
> #
> 8.00% hackbench [k] _raw_spin_unlock_irqrestore
> 6.27% hackbench [k] el0_svc_naked
> 5.53% hackbench [k] unix_stream_read_generic
> 4.40% hackbench [k] __arch_copy_to_user
> 3.94% hackbench [k] refcount_inc_not_zero
> 3.47% hackbench [k] __slab_free
> 3.19% hackbench [k] kfree
> 3.11% hackbench [k] __lock_text_start
> 2.92% hackbench [k] kmem_cache_free
> 2.73% hackbench [.] 0x0000000000005258
>
>
> Currently, only PPIs and SPIs can be set as NMIs. IPIs being currently
> hardcoded IRQ numbers, there isn't a generic interface to set SGIs as NMI
> for now. I don't think there is any reason LPIs should be allowed to be set
> as NMI as they do not have an active state.
> When an NMI is active on a CPU, no other NMI can be triggered on the CPU.
>
> Requirements to use this:
> - Have GICv3
> - SCR_EL3.FIQ is set to 1 when linux runs
> - Select Kernel Feature -> Use ICC system registers for IRQ masking
>
> * Patches 1 and 2 allows to detect and enable the use of GICv3 system
> registers during boot time.
> * Patch 3 introduces the masking of IRQs using priorities replacing irq
> disabling.
> * Patch 4 adds some utility functions
> * Patch 5 add detection of the view linux has on GICv3 priorities, without
> this we cannot easily mask specific priorities in an accurate manner
> * Patch 6 adds the support for NMIs
>
>
> Changes since RFC[2]:
> * The series was rebased to v4.15-rc2 which implied some changes mainly
> related to the work on exception entries and daif flags by James Morse.
>
> - The first patch in the previous series was dropped because no longer
> applicable.
>
> - With the semantics James introduced of "inheriting" daif flags,
> handling of PMR on exception entry is simplified as PMR is not altered
> by taking an exception and already inherited from previous state.
>
> - James pointed out that taking a PseudoNMI before reading the FAR_EL1
> register should not be allowed as per the TRM (D10.2.29):
> "FAR_EL1 is made UNKNOWN on an exception return from EL1."
> So in this submission PSR.I bit is cleared only after FAR_EL1 is read.
>
> * For KVM, only deal with PMR unmasking/restoring in common code, and VHE
> specific code makes sure PSR.I bit is set when necessary.
>
> * When detecting the GIC priority view (patch 5), wait for an actual
> interrupt instead of trying only once.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg525077.html
> [2] https://www.spinics.net/lists/arm-kernel/msg610736.html
>
> Cheers,
>
> Julien
>
> --->
>
> Daniel Thompson (3):
> arm64: cpufeature: Allow early detect of specific features
> arm64: alternative: Apply alternatives early in boot process
> arm64: irqflags: Use ICC sysregs to implement IRQ masking
>
> Julien Thierry (3):
> irqchip/gic: Add functions to access irq priorities
> arm64: Detect current view of GIC priorities
> arm64: Add support for pseudo-NMIs
>
> Documentation/arm64/booting.txt | 5 +
> arch/arm64/Kconfig | 15 ++
> arch/arm64/include/asm/alternative.h | 1 +
> arch/arm64/include/asm/arch_gicv3.h | 42 +++++
> arch/arm64/include/asm/assembler.h | 25 ++-
> arch/arm64/include/asm/daifflags.h | 36 ++--
> arch/arm64/include/asm/efi.h | 5 +
> arch/arm64/include/asm/irqflags.h | 131 ++++++++++++++
> arch/arm64/include/asm/processor.h | 4 +
> arch/arm64/include/asm/ptrace.h | 14 +-
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/kernel/alternative.c | 39 ++++-
> arch/arm64/kernel/asm-offsets.c | 1 +
> arch/arm64/kernel/cpufeature.c | 68 +++++---
> arch/arm64/kernel/entry.S | 84 ++++++++-
> arch/arm64/kernel/head.S | 38 ++++
> arch/arm64/kernel/process.c | 6 +
> arch/arm64/kernel/smp.c | 14 ++
> arch/arm64/kvm/hyp/hyp-entry.S | 20 +++
> arch/arm64/kvm/hyp/switch.c | 21 +++
> arch/arm64/mm/proc.S | 23 +++
> drivers/irqchip/irq-gic-common.c | 10 ++
> drivers/irqchip/irq-gic-common.h | 2 +
> drivers/irqchip/irq-gic-v3-its.c | 2 +-
> drivers/irqchip/irq-gic-v3.c | 307 +++++++++++++++++++++++++++++----
> include/linux/interrupt.h | 1 +
> include/linux/irqchip/arm-gic-common.h | 6 +
> include/linux/irqchip/arm-gic.h | 5 -
> 28 files changed, 841 insertions(+), 85 deletions(-)
>
> --
> 1.9.1
>
--
Julien Thierry
^ permalink raw reply
* [PATCH] ARM: imx: remove unused imx3 pm definitions
From: Martin Kaiser @ 2017-12-19 10:07 UTC (permalink / raw)
To: linux-arm-kernel
Remove the defintion of mx3_cpu_lp_set(), this function is not
implemented anywhere. Remove then mx3_cpu_pwr_mode enum as well,
it was used only as parameter of mx3_cpu_lp_set().
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/mach-imx/common.h | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index b09a2ec..c8d68e9 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -71,15 +71,6 @@ enum mxc_cpu_pwr_mode {
STOP_POWER_OFF, /* STOP + SRPG */
};
-enum mx3_cpu_pwr_mode {
- MX3_RUN,
- MX3_WAIT,
- MX3_DOZE,
- MX3_SLEEP,
-};
-
-void mx3_cpu_lp_set(enum mx3_cpu_pwr_mode mode);
-
void imx_enable_cpu(int cpu, bool enable);
void imx_set_cpu_jump(int cpu, void *jump_addr);
u32 imx_get_cpu_arg(int cpu);
--
2.1.4
^ permalink raw reply related
* [PATCH] spi: atmel: fixed spin_lock usage inside atmel_spi_remove
From: Nicolas Ferre @ 2017-12-19 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513352417-15275-1-git-send-email-radu.pirea@microchip.com>
On 15/12/2017 at 16:40, Radu Pirea wrote:
> The only part of atmel_spi_remove which needs to be atomic is hardware
> reset.
>
> atmel_spi_stop_dma calls dma_terminate_all and this needs interrupts
> enabled.
> atmel_spi_release_dma calls dma_release_channel and dma_release_channel
> locks a mutex inside of spin_lock.
>
> So the call of these functions can't be inside a spin_lock.
>
> Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks Radu. Regards,
Nicolas
> ---
> drivers/spi/spi-atmel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index f95da36..6694709 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1661,12 +1661,12 @@ static int atmel_spi_remove(struct platform_device *pdev)
> pm_runtime_get_sync(&pdev->dev);
>
> /* reset the hardware and block queue progress */
> - spin_lock_irq(&as->lock);
> if (as->use_dma) {
> atmel_spi_stop_dma(master);
> atmel_spi_release_dma(master);
> }
>
> + spin_lock_irq(&as->lock);
> spi_writel(as, CR, SPI_BIT(SWRST));
> spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
> spi_readl(as, SR);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: Vladimir Murzin @ 2017-12-19 10:23 UTC (permalink / raw)
To: linux-arm-kernel
With switch to dynamic exception base address setting, VBAR/Hivecs
set only for boot CPU, but secondaries stay unaware of that. That
might lead to weird effects when trying up to bring up secondaries.
Fixes: ad475117d201 ("ARM: 8649/2: nommu: remove Hivecs configuration is asm")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/memory.h | 9 +++++++++
arch/arm/kernel/smp.c | 2 ++
arch/arm/mm/nommu.c | 4 ++--
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 1f54e4e..65c52ac 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -165,6 +165,15 @@ extern unsigned long vectors_base;
#ifndef __ASSEMBLY__
+#ifndef CONFIG_MMU
+extern unsigned long setup_vectors_base(void);
+#else
+static inline unsigned long setup_vectors_base(void)
+{
+ return 0;
+}
+#endif
+
/*
* Physical vs virtual RAM address space conversion. These are
* private definitions which should NOT be used outside memory.h
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4fbf00..248e33f 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -379,6 +379,8 @@ asmlinkage void secondary_start_kernel(void)
cpu_init();
+ setup_vectors_base();
+
pr_debug("CPU%u: Booted secondary processor\n", cpu);
preempt_disable();
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 885b106..c8beaab 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -31,7 +31,7 @@ struct mpu_rgn_info mpu_rgn_info;
#ifdef CONFIG_CPU_CP15
#ifdef CONFIG_CPU_HIGH_VECTOR
-static unsigned long __init setup_vectors_base(void)
+unsigned long setup_vectors_base(void)
{
unsigned long reg = get_cr();
@@ -58,7 +58,7 @@ static inline bool security_extensions_enabled(void)
return 0;
}
-static unsigned long __init setup_vectors_base(void)
+unsigned long setup_vectors_base(void)
{
unsigned long base = 0, reg = get_cr();
--
2.0.0
^ permalink raw reply related
* [PATCH v2] spi: atmel: Implements transfers with bounce buffer
From: Nicolas Ferre @ 2017-12-19 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513093032-11570-1-git-send-email-radu.pirea@microchip.com>
On 12/12/2017 at 16:37, Radu Pirea wrote:
> This patch enables DMA transfers for Atmel SAM9 SoCs and implements a bounce
> buffer for transfers which have vmalloc allocated buffers. Those buffers are
> not cache coherent even if they have been transformed into sg lists. UBIFS
> is affected by this cache coherency issue.
>
> In this patch I also reverted "spi: atmel: fix corrupted data issue on SAM9
> family SoCs"(7094576ccdc3acfe1e06a1e2ab547add375baf7f).
>
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Best regards,
Nicolas
> ---
> Please ignore the previous version. I messed up with file names.
> drivers/spi/spi-atmel.c | 113 +++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 84 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index f95da36..198b4cd 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -291,6 +291,10 @@ struct atmel_spi {
> struct spi_transfer *current_transfer;
> int current_remaining_bytes;
> int done_status;
> + dma_addr_t dma_addr_rx_bbuf;
> + dma_addr_t dma_addr_tx_bbuf;
> + void *addr_rx_bbuf;
> + void *addr_tx_bbuf;
>
> struct completion xfer_completion;
>
> @@ -436,6 +440,11 @@ static void atmel_spi_unlock(struct atmel_spi *as) __releases(&as->lock)
> spin_unlock_irqrestore(&as->lock, as->flags);
> }
>
> +static inline bool atmel_spi_is_vmalloc_xfer(struct spi_transfer *xfer)
> +{
> + return is_vmalloc_addr(xfer->tx_buf) || is_vmalloc_addr(xfer->rx_buf);
> +}
> +
> static inline bool atmel_spi_use_dma(struct atmel_spi *as,
> struct spi_transfer *xfer)
> {
> @@ -448,7 +457,12 @@ static bool atmel_spi_can_dma(struct spi_master *master,
> {
> struct atmel_spi *as = spi_master_get_devdata(master);
>
> - return atmel_spi_use_dma(as, xfer);
> + if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5))
> + return atmel_spi_use_dma(as, xfer) &&
> + !atmel_spi_is_vmalloc_xfer(xfer);
> + else
> + return atmel_spi_use_dma(as, xfer);
> +
> }
>
> static int atmel_spi_dma_slave_config(struct atmel_spi *as,
> @@ -594,6 +608,11 @@ static void dma_callback(void *data)
> struct spi_master *master = data;
> struct atmel_spi *as = spi_master_get_devdata(master);
>
> + if (is_vmalloc_addr(as->current_transfer->rx_buf) &&
> + IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
> + memcpy(as->current_transfer->rx_buf, as->addr_rx_bbuf,
> + as->current_transfer->len);
> + }
> complete(&as->xfer_completion);
> }
>
> @@ -744,17 +763,41 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
> goto err_exit;
>
> /* Send both scatterlists */
> - rxdesc = dmaengine_prep_slave_sg(rxchan,
> - xfer->rx_sg.sgl, xfer->rx_sg.nents,
> - DMA_FROM_DEVICE,
> - DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (atmel_spi_is_vmalloc_xfer(xfer) &&
> + IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
> + rxdesc = dmaengine_prep_slave_single(rxchan,
> + as->dma_addr_rx_bbuf,
> + xfer->len,
> + DMA_FROM_DEVICE,
> + DMA_PREP_INTERRUPT |
> + DMA_CTRL_ACK);
> + } else {
> + rxdesc = dmaengine_prep_slave_sg(rxchan,
> + xfer->rx_sg.sgl,
> + xfer->rx_sg.nents,
> + DMA_FROM_DEVICE,
> + DMA_PREP_INTERRUPT |
> + DMA_CTRL_ACK);
> + }
> if (!rxdesc)
> goto err_dma;
>
> - txdesc = dmaengine_prep_slave_sg(txchan,
> - xfer->tx_sg.sgl, xfer->tx_sg.nents,
> - DMA_TO_DEVICE,
> - DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (atmel_spi_is_vmalloc_xfer(xfer) &&
> + IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
> + memcpy(as->addr_tx_bbuf, xfer->tx_buf, xfer->len);
> + txdesc = dmaengine_prep_slave_single(txchan,
> + as->dma_addr_tx_bbuf,
> + xfer->len, DMA_TO_DEVICE,
> + DMA_PREP_INTERRUPT |
> + DMA_CTRL_ACK);
> + } else {
> + txdesc = dmaengine_prep_slave_sg(txchan,
> + xfer->tx_sg.sgl,
> + xfer->tx_sg.nents,
> + DMA_TO_DEVICE,
> + DMA_PREP_INTERRUPT |
> + DMA_CTRL_ACK);
> + }
> if (!txdesc)
> goto err_dma;
>
> @@ -1426,27 +1469,7 @@ static void atmel_get_caps(struct atmel_spi *as)
>
> as->caps.is_spi2 = version > 0x121;
> as->caps.has_wdrbt = version >= 0x210;
> -#ifdef CONFIG_SOC_SAM_V4_V5
> - /*
> - * Atmel SoCs based on ARM9 (SAM9x) cores should not use spi_map_buf()
> - * since this later function tries to map buffers with dma_map_sg()
> - * even if they have not been allocated inside DMA-safe areas.
> - * On SoCs based on Cortex A5 (SAMA5Dx), it works anyway because for
> - * those ARM cores, the data cache follows the PIPT model.
> - * Also the L2 cache controller of SAMA5D2 uses the PIPT model too.
> - * In case of PIPT caches, there cannot be cache aliases.
> - * However on ARM9 cores, the data cache follows the VIVT model, hence
> - * the cache aliases issue can occur when buffers are allocated from
> - * DMA-unsafe areas, by vmalloc() for instance, where cache coherency is
> - * not taken into account or at least not handled completely (cache
> - * lines of aliases are not invalidated).
> - * This is not a theorical issue: it was reproduced when trying to mount
> - * a UBI file-system on a at91sam9g35ek board.
> - */
> - as->caps.has_dma_support = false;
> -#else
> as->caps.has_dma_support = version >= 0x212;
> -#endif
> as->caps.has_pdc_support = version < 0x212;
> }
>
> @@ -1592,6 +1615,30 @@ static int atmel_spi_probe(struct platform_device *pdev)
> as->use_pdc = true;
> }
>
> + if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
> + as->addr_rx_bbuf = dma_alloc_coherent(&pdev->dev,
> + SPI_MAX_DMA_XFER,
> + &as->dma_addr_rx_bbuf,
> + GFP_KERNEL | GFP_DMA);
> + if (!as->addr_rx_bbuf) {
> + as->use_dma = false;
> + } else {
> + as->addr_tx_bbuf = dma_alloc_coherent(&pdev->dev,
> + SPI_MAX_DMA_XFER,
> + &as->dma_addr_tx_bbuf,
> + GFP_KERNEL | GFP_DMA);
> + if (!as->addr_tx_bbuf) {
> + as->use_dma = false;
> + dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
> + as->addr_rx_bbuf,
> + as->dma_addr_rx_bbuf);
> + }
> + }
> + if(!as->use_dma)
> + dev_info(master->dev.parent,
> + " can not allocate dma coherent memory\n");
> + }
> +
> if (as->caps.has_dma_support && !as->use_dma)
> dev_info(&pdev->dev, "Atmel SPI Controller using PIO only\n");
>
> @@ -1665,6 +1712,14 @@ static int atmel_spi_remove(struct platform_device *pdev)
> if (as->use_dma) {
> atmel_spi_stop_dma(master);
> atmel_spi_release_dma(master);
> + if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
> + dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
> + as->addr_tx_bbuf,
> + as->dma_addr_tx_bbuf);
> + dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
> + as->addr_rx_bbuf,
> + as->dma_addr_rx_bbuf);
> + }
> }
>
> spi_writel(as, CR, SPI_BIT(SWRST));
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2] IPI performance benchmark
From: Yury Norov @ 2017-12-19 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uGjeT3waQaC+Ak=gmNkLFsFO6HshyEwsYA5QX2RjK0XNw@mail.gmail.com>
On Tue, Dec 19, 2017 at 10:26:02AM +0100, Philippe Ombredanne wrote:
> Dear Yury,
>
> On Tue, Dec 19, 2017 at 9:50 AM, Yury Norov <ynorov@caviumnetworks.com> wrote:
> > This benchmark sends many IPIs in different modes and measures
> > time for IPI delivery (first column), and total time, ie including
> > time to acknowledge the receive by sender (second column).
>
> <snip>
>
> > --- /dev/null
> > +++ b/kernel/ipi_benchmark.c
> > @@ -0,0 +1,153 @@
> > +/*
> > + * Performance test for IPI on SMP machines.
> > + *
> > + * Copyright (c) 2017 Cavium Networks.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of version 2 of the GNU General Public
> > + * License as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * General Public License for more details.
> > + */
>
> Would you mind using the new SPDX tags documented in Thomas patch set
> [1] rather than this fine but longer legalese?
Of course. I'll collect more comments, if any, and send v3 soon.
> Each time long
> legalese is added as a comment to a kernel file, there is a whole star
> system that dies somewhere in the universe, which is not a good thing.
You can save all that stars and hours of your time if add
corresponding rule to checkpatch. ;)
> SPDX tags eschew this problem by using a simple one line comment and
> this has been proven to be mostly harmless. And if you could spread
> the word to others in your team this would be very nice. I recently
> nudged Aleksey who nicely updated his patches a short while ago.
>
> > +MODULE_LICENSE("GPL");
>
> There is a problem here: your MODULE_LICENSE tag means GPL-2.0 or
> later versions as documented in module.h. This is not consistent with
> your top level license notice. You should make this consistent IMHO
> .... and use SPDX tags for the top level notice of course!
>
> Thank you!
>
> [1] https://lkml.org/lkml/2017/12/4/934
>
> CC: Aleksey Makarov <aleksey.makarov@cavium.com>
> --
> Cordially
> Philippe Ombredanne
^ permalink raw reply
* [PATCH V4 02/26] powerpc/PCI: deprecate pci_get_bus_and_slot()
From: Michael Ellerman @ 2017-12-19 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-3-git-send-email-okaya@codeaurora.org>
Sinan Kaya <okaya@codeaurora.org> writes:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
> Use pci_get_domain_bus_and_slot() with a domain number of 0 as the code
> is not ready to consume multiple domains and existing code used domain
> number 0.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> arch/powerpc/kernel/pci_32.c | 3 ++-
> arch/powerpc/platforms/powermac/feature.c | 2 +-
> arch/powerpc/sysdev/mv64x60_pci.c | 4 ++--
> 3 files changed, 5 insertions(+), 4 deletions(-)
Looks to do what it says. I don't know if any of these call sites could
be improved to provide the domain, but that's not really your problem.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* [xlnx:2017.3_video_ea 6589/6615] include/linux/dmaengine.h:1409: undefined reference to `dma_request_slave_channel'
From: kbuild test robot @ 2017-12-19 10:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jeffrey,
It's probably a bug fix that unveils the link errors.
tree: https://github.com/Xilinx/linux-xlnx 2017.3_video_ea
head: 57af48e31ef9c4a9fa54914afa723ce818c4c21a
commit: 62a7ed2f02d28f73f2c09d61ecbe1f289aecc6e5 [6589/6615] staging: xilinx: mixer: Initial commit of Xilinx Video Mixer IP DRM driver
config: i386-randconfig-s0-201751 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 62a7ed2f02d28f73f2c09d61ecbe1f289aecc6e5
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `__dma_request_slave_channel_compat':
>> include/linux/dmaengine.h:1409: undefined reference to `dma_request_slave_channel'
>> include/linux/dmaengine.h:1416: undefined reference to `__dma_request_channel'
>> include/linux/dmaengine.h:1409: undefined reference to `dma_request_slave_channel'
>> include/linux/dmaengine.h:1416: undefined reference to `__dma_request_channel'
drivers/built-in.o: In function `pxa2xx_spi_dma_setup':
>> drivers/spi/spi-pxa2xx-dma.c:208: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `pxa2xx_spi_dma_release':
drivers/spi/spi-pxa2xx-dma.c:222: undefined reference to `dma_release_channel'
drivers/spi/spi-pxa2xx-dma.c:227: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `rockchip_spi_remove':
>> drivers/spi/spi-rockchip.c:821: undefined reference to `dma_release_channel'
drivers/spi/spi-rockchip.c:823: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `rockchip_spi_probe':
>> drivers/spi/spi-rockchip.c:752: undefined reference to `dma_request_chan'
drivers/spi/spi-rockchip.c:763: undefined reference to `dma_request_chan'
>> drivers/spi/spi-rockchip.c:774: undefined reference to `dma_get_slave_caps'
drivers/spi/spi-rockchip.c:796: undefined reference to `dma_release_channel'
drivers/spi/spi-rockchip.c:799: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `pch_spi_request_dma':
>> drivers/spi/spi-topcliff-pch.c:878: undefined reference to `__dma_request_channel'
drivers/spi/spi-topcliff-pch.c:893: undefined reference to `__dma_request_channel'
>> drivers/spi/spi-topcliff-pch.c:897: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `pch_spi_release_dma':
drivers/spi/spi-topcliff-pch.c:911: undefined reference to `dma_release_channel'
drivers/spi/spi-topcliff-pch.c:915: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `usdhi6_dma_release':
>> drivers/mmc/host/usdhi6rol0.c:525: undefined reference to `dma_release_channel'
drivers/mmc/host/usdhi6rol0.c:530: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `usdhi6_dma_request':
>> drivers/mmc/host/usdhi6rol0.c:683: undefined reference to `dma_request_slave_channel'
drivers/mmc/host/usdhi6rol0.c:698: undefined reference to `dma_request_slave_channel'
drivers/mmc/host/usdhi6rol0.c:716: undefined reference to `dma_release_channel'
drivers/mmc/host/usdhi6rol0.c:719: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `Si5324_RatApprox':
>> drivers/staging/xilinx/clk/si5324drv.c:45: undefined reference to `__udivdi3'
>> drivers/staging/xilinx/clk/si5324drv.c:52: undefined reference to `__umoddi3'
drivers/staging/xilinx/clk/si5324drv.c:56: undefined reference to `__udivdi3'
drivers/built-in.o: In function `Si5324_FindN2ls':
drivers/staging/xilinx/clk/si5324drv.c:95: undefined reference to `__udivdi3'
drivers/staging/xilinx/clk/si5324drv.c:95: undefined reference to `__udivdi3'
drivers/staging/xilinx/clk/si5324drv.c:124: undefined reference to `__udivdi3'
drivers/staging/xilinx/clk/si5324drv.c:126: undefined reference to `__udivdi3'
drivers/built-in.o:drivers/staging/xilinx/clk/si5324drv.c:189: more undefined references to `__udivdi3' follow
drivers/built-in.o: In function `Si5324_CalcFreqSettings':
>> drivers/staging/xilinx/clk/si5324drv.c:312: undefined reference to `__divdi3'
drivers/staging/xilinx/clk/si5324drv.c:316: undefined reference to `__divdi3'
drivers/built-in.o: In function `xvmixer_drm_encoder_create':
>> drivers/staging/xilinx/xvmixer/xvmixer_drm_encoder.c:201: undefined reference to `of_find_device_by_node'
drivers/built-in.o: In function `xilinx_drm_plane_destroy':
>> drivers/staging/xilinx/xvmixer/xvmixer_drm_plane.c:244: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `xvmixer_drm_plane_commit':
>> drivers/staging/xilinx/xvmixer/xvmixer_drm_plane.c:89: undefined reference to `xilinx_xdma_drm_config'
drivers/built-in.o: In function `xvmixer_drm_mixer_init_plane':
drivers/staging/xilinx/xvmixer/xvmixer_drm_plane.c:447: undefined reference to `dma_release_channel'
drivers/built-in.o: In function `xilinx_mixer_set_layer_buff_addr':
>> drivers/staging/xilinx/xvmixer/xilinx_mixer_hw.c:657: undefined reference to `__umoddi3'
>> drivers/staging/xilinx/xvmixer/xilinx_mixer_hw.c:657: undefined reference to `__umoddi3'
drivers/built-in.o: In function `perf_remove':
vim +1409 include/linux/dmaengine.h
c13c8260 Chris Leech 2006-05-23 1392
c13c8260 Chris Leech 2006-05-23 1393 int dma_async_device_register(struct dma_device *device);
c13c8260 Chris Leech 2006-05-23 1394 void dma_async_device_unregister(struct dma_device *device);
07f2211e Dan Williams 2009-01-05 1395 void dma_run_dependencies(struct dma_async_tx_descriptor *tx);
7bb587f4 Zhangfei Gao 2013-06-28 1396 struct dma_chan *dma_get_slave_channel(struct dma_chan *chan);
8010dad5 Stephen Warren 2013-11-26 1397 struct dma_chan *dma_get_any_slave_channel(struct dma_device *device);
59b5ec21 Dan Williams 2009-01-06 1398 #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
864ef69b Matt Porter 2013-02-01 1399 #define dma_request_slave_channel_compat(mask, x, y, dev, name) \
864ef69b Matt Porter 2013-02-01 1400 __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
864ef69b Matt Porter 2013-02-01 1401
864ef69b Matt Porter 2013-02-01 1402 static inline struct dma_chan
a53e28da Lars-Peter Clausen 2013-03-25 1403 *__dma_request_slave_channel_compat(const dma_cap_mask_t *mask,
a53e28da Lars-Peter Clausen 2013-03-25 1404 dma_filter_fn fn, void *fn_param,
1dc04288 Jarkko Nikula 2015-08-12 1405 struct device *dev, const char *name)
864ef69b Matt Porter 2013-02-01 1406 {
864ef69b Matt Porter 2013-02-01 1407 struct dma_chan *chan;
864ef69b Matt Porter 2013-02-01 1408
864ef69b Matt Porter 2013-02-01 @1409 chan = dma_request_slave_channel(dev, name);
864ef69b Matt Porter 2013-02-01 1410 if (chan)
864ef69b Matt Porter 2013-02-01 1411 return chan;
864ef69b Matt Porter 2013-02-01 1412
7dfffb95 Geert Uytterhoeven 2015-08-17 1413 if (!fn || !fn_param)
7dfffb95 Geert Uytterhoeven 2015-08-17 1414 return NULL;
7dfffb95 Geert Uytterhoeven 2015-08-17 1415
864ef69b Matt Porter 2013-02-01 @1416 return __dma_request_channel(mask, fn, fn_param);
:::::: The code at line 1409 was first introduced by commit
:::::: 864ef69b2d9b34e7c85baa9c5c601d5e735b208a dmaengine: add dma_request_slave_channel_compat()
:::::: TO: Matt Porter <mporter@ti.com>
:::::: CC: Vinod Koul <vinod.koul@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 23957 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171219/c72692a5/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2] spi: atmel: Implements transfers with bounce buffer
From: Alexandre Belloni @ 2017-12-19 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513093032-11570-1-git-send-email-radu.pirea@microchip.com>
On 12/12/2017 at 17:37:12 +0200, Radu Pirea wrote:
> This patch enables DMA transfers for Atmel SAM9 SoCs and implements a bounce
> buffer for transfers which have vmalloc allocated buffers. Those buffers are
> not cache coherent even if they have been transformed into sg lists. UBIFS
> is affected by this cache coherency issue.
>
> In this patch I also reverted "spi: atmel: fix corrupted data issue on SAM9
> family SoCs"(7094576ccdc3acfe1e06a1e2ab547add375baf7f).
>
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> Please ignore the previous version. I messed up with file names.
> drivers/spi/spi-atmel.c | 113 +++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 84 insertions(+), 29 deletions(-)
>
There are multiple checkpatch issues, can you fix them?
> + if(!as->use_dma)
Especially that missing space.
> + dev_info(master->dev.parent,
> + " can not allocate dma coherent memory\n");
> + }
> +
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/2] ARM: davinici: move watchdog restart from mach to drivers
From: Sekhar Nori @ 2017-12-19 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513012869-7647-1-git-send-email-david@lechnology.com>
Hi David,
On Monday 11 December 2017 10:51 PM, David Lechner wrote:
> This series moves the watchdog restart code from arch/arm/mach-davinci
> to drivers/watchdog.
>
> Tested working on LEGO MINDSTORMS EV3 (TI AM1808 processor).
The patches look good to me. I also tested them on keystone-k2hk-evm and
da850-lcdk board. Thanks for the much needed clean-up!
Hi Wim,
How do you want to handle this series? Patch 2/2 definitely needs to go
through my tree as it will clash with other code I am queuing.
I can either take 1/2 also through ARM-SoC with your ack (preferred) or
if you give me an immutable commit/tag over v4.15-rc1, I can merge that
to preserve bisect-ability.
Thanks,
Sekhar
^ permalink raw reply
* Linux Kernel handling AXI DECERR/SLVERR
From: Mark Rutland @ 2017-12-19 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BLUPR0201MB1505A278D2EF1EABD80555EEA50F0@BLUPR0201MB1505.namprd02.prod.outlook.com>
On Tue, Dec 19, 2017 at 10:23:25AM +0000, Bharat Kumar Gogada wrote:
> Hi All,
Hi,
> When Linux is booted on ARM64 platform and an access to peripheral returns
> DECERR or SLVERR on AXI.
>
> In the above error cases how would Linux kernel handle these faults ? Will it
> hang/recover ?
I believe that on contemporary CPUs these will result in an SError. As
SErrors are asynchronous, and (in the absence of RAS extensions) their
cause cannot be determined, these are treated as fatal, and the kernel
will panic().
Thanks,
Mark.
^ permalink raw reply
* [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: Andy Shevchenko @ 2017-12-19 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-15-git-send-email-okaya@codeaurora.org>
On Tue, 2017-12-19 at 00:37 -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
Where this idea come from?
pci_get_bus_and_slot() still might be useful for the wired devices in
SoC where we know for sure that domain == 0.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string
From: Tomi Valkeinen @ 2017-12-19 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211152203.GH24344@atomide.com>
On 11/12/17 17:22, Tony Lindgren wrote:
> * H. Nikolaus Schaller <hns@goldelico.com> [171201 07:44]:
>> Official vendor string is now "tpo" and not "toppoly".
>>
>> Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
>> so that the driver understands both.
>
> Tomi, so what's the plan with the dependency patch, is that for v4.16
> or for the v4.15-rc cycle?
The dependency patch for this one is queued for v4.16 (I just sent a
pull request today). I could pick this one up (if you give an ack) if I
send another DRM pull request, but I probably don't have anything else
to send so most likely I won't pick this up for v4.16.
The patch 2/2 in the series doesn't have dependencies and can be applied
as a fix for 4.15, or for 4.16.
Neither of these are critical, as things work fine without these patches.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH] dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63
From: Peter Ujfalusi @ 2017-12-19 10:51 UTC (permalink / raw)
To: linux-arm-kernel
From: Vignesh R <vigneshr@ti.com>
Register layout of a typical TPCC_EVT_MUX_M_N register is such that the
lowest numbered event is at the lowest byte address and highest numbered
event at highest byte address. But TPCC_EVT_MUX_60_63 register layout is
different, in that the lowest numbered event is at the highest address
and highest numbered event is at the lowest address. Therefore, modify
ti_am335x_xbar_write() to handle TPCC_EVT_MUX_60_63 register
accordingly.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 7df910e7c348..9272b173c746 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -54,7 +54,15 @@ struct ti_am335x_xbar_map {
static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val, iomem + event);
+ /*
+ * TPCC_EVT_MUX_60_63 register layout is different than the
+ * rest, in the sense, that event 63 is mapped to lowest byte
+ * and event 60 is mapped to highest, handle it separately.
+ */
+ if (event >= 60 && event <= 63)
+ writeb_relaxed(val, iomem + (63 - event % 4));
+ else
+ writeb_relaxed(val, iomem + event);
}
static void ti_am335x_xbar_free(struct device *dev, void *route_data)
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ 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