* [PATCH 11/15] arm: dts: berlin: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing properties (clocks, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/berlin2.dtsi | 10 ++++++++++
arch/arm/boot/dts/berlin2q.dtsi | 33 +++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index d575823c5750..487e9de53244 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -81,6 +81,16 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
};
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index bf3a6c9a1d34..9cd00ab53f2d 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -76,6 +76,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
cpu at 2 {
@@ -83,6 +94,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <2>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
cpu at 3 {
@@ -90,6 +112,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <3>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 12/15] arm: dts: highbank: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing property (clock latency) as well to make it all
work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/highbank.dts | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index ed14aeac0566..50278715de76 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -56,6 +56,16 @@
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz ignored */
+ 1300000 1000000
+ 1200000 1000000
+ 1100000 1000000
+ 800000 1000000
+ 400000 1000000
+ 200000 1000000
+ >;
+ clock-latency = <100000>;
};
cpu at 902 {
@@ -65,6 +75,16 @@
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz ignored */
+ 1300000 1000000
+ 1200000 1000000
+ 1100000 1000000
+ 800000 1000000
+ 400000 1000000
+ 200000 1000000
+ >;
+ clock-latency = <100000>;
};
cpu at 903 {
@@ -74,6 +94,16 @@
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
+ operating-points = <
+ /* kHz ignored */
+ 1300000 1000000
+ 1200000 1000000
+ 1100000 1000000
+ 800000 1000000
+ 400000 1000000
+ 200000 1000000
+ >;
+ clock-latency = <100000>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing properties (like clocks, supply, clock latency) as
well to make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/imx6dl.dtsi | 23 ++++++++++
arch/arm/boot/dts/imx6q-cm-fx6.dts | 66 +++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6q.dtsi | 87 ++++++++++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx7d.dtsi | 5 +++
4 files changed, 178 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index b384913c34dd..cc8ffc42d128 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -50,6 +50,29 @@
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 996000 1250000
+ 792000 1175000
+ 396000 1150000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 1175000
+ 792000 1175000
+ 396000 1175000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ clocks = <&clks IMX6QDL_CLK_ARM>,
+ <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+ <&clks IMX6QDL_CLK_STEP>,
+ <&clks IMX6QDL_CLK_PLL1_SW>,
+ <&clks IMX6QDL_CLK_PLL1_SYS>;
+ clock-names = "arm", "pll2_pfd2_396m", "step",
+ "pll1_sw", "pll1_sys";
+ arm-supply = <®_arm>;
+ pu-supply = <®_pu>;
+ soc-supply = <®_soc>;
};
};
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index 65ef4cacbc71..18ae4f3be6e3 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -187,6 +187,72 @@
>;
};
+&cpu1 {
+ /*
+ * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+ * the module behaves unstable at this frequency. Hence, remove the
+ * 1.2GHz operation point here.
+ */
+ operating-points = <
+ /* kHz uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+};
+
+&cpu2 {
+ /*
+ * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+ * the module behaves unstable at this frequency. Hence, remove the
+ * 1.2GHz operation point here.
+ */
+ operating-points = <
+ /* kHz uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+};
+
+&cpu3 {
+ /*
+ * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+ * the module behaves unstable at this frequency. Hence, remove the
+ * 1.2GHz operation point here.
+ */
+ operating-points = <
+ /* kHz uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+};
+
&ecspi1 {
cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>, <&gpio3 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 70483ce72ba6..78b89bb1bfed 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -50,25 +50,106 @@
soc-supply = <®_soc>;
};
- cpu at 1 {
+ cpu1: cpu at 1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ clocks = <&clks IMX6QDL_CLK_ARM>,
+ <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+ <&clks IMX6QDL_CLK_STEP>,
+ <&clks IMX6QDL_CLK_PLL1_SW>,
+ <&clks IMX6QDL_CLK_PLL1_SYS>;
+ clock-names = "arm", "pll2_pfd2_396m", "step",
+ "pll1_sw", "pll1_sys";
+ arm-supply = <®_arm>;
+ pu-supply = <®_pu>;
+ soc-supply = <®_soc>;
};
- cpu at 2 {
+ cpu2: cpu at 2 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <2>;
next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ clocks = <&clks IMX6QDL_CLK_ARM>,
+ <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+ <&clks IMX6QDL_CLK_STEP>,
+ <&clks IMX6QDL_CLK_PLL1_SW>,
+ <&clks IMX6QDL_CLK_PLL1_SYS>;
+ clock-names = "arm", "pll2_pfd2_396m", "step",
+ "pll1_sw", "pll1_sys";
+ arm-supply = <®_arm>;
+ pu-supply = <®_pu>;
+ soc-supply = <®_soc>;
};
- cpu at 3 {
+ cpu3: cpu at 3 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <3>;
next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 975000
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 1200000 1275000
+ 996000 1250000
+ 852000 1250000
+ 792000 1175000
+ 396000 1175000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ clocks = <&clks IMX6QDL_CLK_ARM>,
+ <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+ <&clks IMX6QDL_CLK_STEP>,
+ <&clks IMX6QDL_CLK_PLL1_SW>,
+ <&clks IMX6QDL_CLK_PLL1_SYS>;
+ clock-names = "arm", "pll2_pfd2_396m", "step",
+ "pll1_sw", "pll1_sys";
+ arm-supply = <®_arm>;
+ pu-supply = <®_pu>;
+ soc-supply = <®_soc>;
};
};
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 4c9877ec29f2..5434a8aa5602 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -21,6 +21,11 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ operating-points = <
+ /* KHz uV */
+ 996000 1075000
+ 792000 975000
+ >;
clock-frequency = <996000000>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* REGRESSION: iommu fails to take address limit into account
From: Robin Murphy @ 2018-05-25 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9HoV-V4nj3j6VPzwGz3Z-G4G7zUQcUHufQ6Rdkk8-VNQ@mail.gmail.com>
Hi Ard,
On 25/05/18 10:48, Ard Biesheuvel wrote:
> Hello all,
>
> I am looking into an issue where a platform device is wired to a
> MMU-500, and for some reason (which is under investigation) the
> platform device can not drive all address bits. I can work around this
> by limiting the DMA mask to 40 bits in the driver. However, the IORT
> table allows me to set the address limit as well, and so I was
> expecting this to be taken into account by the SMMU driver.
>
> When the iort/iommu layer sets up the DMA operations,
> iommu_dma_init_domain() is entered with the expected values:
>
> base == 0
> size == 0x100_0000_0000
>
> However, the iommu layer ends up generating IOVA addresses that have
> bits [47:40] set (which is what the MMU-500 supports). Looking closer,
> this is not surprising, given that the end_pfn variable that is
> calculated in iommu_dma_init_domain() is no longer used after Zhen's
> patch aa3ac9469c185 ("iommu/iova: Make dma_32bit_pfn implicit") was
> applied.
>
> So effectively, this is a regression, and I would like your help
> figuring out how to go about fixing this.
Note that the size passed to iommu_dma_init_domain() has *never* been
any kind of enforced limit, so nothing is actually regressing here. If
the device master interface is natively >40 bits wide (such that the
driver would expect to set a larger DMA mask) and the restriction is
purely in the interconnect between device and SMMU, then that's the case
which has always been broken.
I do have a long-standing plan of attack for fixing the underlying issue
(of actually enforcing any dma mask restriction described by IORT or DT
"dma-ranges"), but it's one of those things that's tied to a whole bunch
of other rework and fixes in order to be viable. I'm about to go off on
holiday for a while but I should hopefully have the bandwidth to start
looking at this seriously once I get back (frankly it's been getting
bumped down my to-do list for far too long now...)
Robin.
^ permalink raw reply
* REGRESSION: iommu fails to take address limit into account
From: Ard Biesheuvel @ 2018-05-25 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9HoV-V4nj3j6VPzwGz3Z-G4G7zUQcUHufQ6Rdkk8-VNQ@mail.gmail.com>
On 25 May 2018 at 11:48, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Hello all,
>
> I am looking into an issue where a platform device is wired to a
> MMU-500, and for some reason (which is under investigation) the
> platform device can not drive all address bits. I can work around this
> by limiting the DMA mask to 40 bits in the driver. However, the IORT
> table allows me to set the address limit as well, and so I was
> expecting this to be taken into account by the SMMU driver.
>
> When the iort/iommu layer sets up the DMA operations,
> iommu_dma_init_domain() is entered with the expected values:
>
> base == 0
> size == 0x100_0000_0000
>
> However, the iommu layer ends up generating IOVA addresses that have
> bits [47:40] set (which is what the MMU-500 supports). Looking closer,
> this is not surprising, given that the end_pfn variable that is
> calculated in iommu_dma_init_domain() is no longer used after Zhen's
> patch aa3ac9469c185 ("iommu/iova: Make dma_32bit_pfn implicit") was
> applied.
>
> So effectively, this is a regression, and I would like your help
> figuring out how to go about fixing this.
>
I have narrowed it down a bit further: even though the IOVA range
ignores the IORT address limit, the device's DMA mask is set
correctly. The only problem is that the driver (like all drivers
afaict) does not take into account the fact that its DMA mask has
already been set by the bus layer before its probe function is called.
I could add something like this
- if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
+ if (dma_get_mask(&pdev->dev) == DMA_BIT_MASK(32) &&
+ dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
dev_warn(&pdev->dev, "Failed to enable 64-bit DMA\n");
to only override the mask if it is not at its default value, but it
feels like papering over the problem given that most drivers appear to
ignore the preset mask as well.
^ permalink raw reply
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Suzuki K Poulose @ 2018-05-25 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0673d7e-9a1e-7dcb-5322-c05fe0821349@arm.com>
On 25/05/18 11:17, Julien Thierry wrote:
>
>
> On 25/05/18 11:04, Suzuki K Poulose wrote:
>> On 25/05/18 10:49, Julien Thierry wrote:
>>> Add a cpufeature indicating whether a cpu supports masking interrupts
>>> by priority.
>>
>> How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
>> the description ?
>
> More or less.
>
> It is just to have an easier condition in the rest of the series. Basically the PRIO masking feature is enabled if we have a GICv3 CPUIF working *and* the option was selected at build time. Before this meant that I was checking for the GIC_CPUIF cap inside #ifdefs (and putting alternatives depending on that inside #ifdefs as well).
>
> Having this as a separate feature feels easier to manage in the code. It also makes it clearer at boot time that the kernel will be using irq priorities (although I admit it was not the initial intention):
>
> [??? 0.000000] CPU features: detected: IRQ priority masking
>
>
> But yes that new feature will be detected only if SYSREG_GIC_CPUIF gets detected as well.
Well, you could always wrap the check like :
static inline bool system_has_irq_priority_masking(void)
{
return (IS_ENABLED(CONFIG_YOUR_CONFIG) && cpus_have_const_cap(HWCAP_SYSREG_GIC_CPUIF));
}
and use it everywhere.
The description could be statically changed to reflect based on the #ifdef.
static const struct arm64_cpu_capabilities arm64_features[] = {
{
#ifdef CONFIG_YOUR_CONFIG
.desc = "GIC System register CPU interface with IRQ priority masking"
#else
.desc = "GIC system register CPU interface",
#endif
.capability = ARM64_HAS_SYSREG_GIC_CPUIF,
.type = ARM64_CPUCAP_SYSTEM_FEATURE,
.matches = has_useable_gicv3_cpuif,
.sys_reg = SYS_ID_AA64PFR0_EL1,
.field_pos = ID_AA64PFR0_GIC_SHIFT,
.sign = FTR_UNSIGNED,
.min_field_value = 1,
Cheers
Suzuki
^ permalink raw reply
* [PATCH V3 0/4] clk: new APIs to handle all available clocks
From: Dong Aisheng @ 2018-05-25 10:37 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is a continue of discussion from here,
https://patchwork.kernel.org/patch/9986293/
that some users may want to handle all available clocks from device
tree without need to know the detailed clock information likes clock
numbers and names. This is useful in writing some generic drivers to
handle clock part.
Note:
This patch series is tested on MX6Q SDB cpufreq driver with a minor change
to switch to use clk_bulk_get_all.
But patch 4 only test compiling. Hopefully someone could help test
the function.
v2->v3:
* address all comments from Stephen
* fix build warnings on other architectures.
v1->v2:
* add clk_bulk_{get|put}_all() which only supports DT platform currently
* remove _all variants and the wrapper struct clk_bulk
* make of_clk_bulk_get and of_clk_bulk_get_all private until someone
proves they need it because they don't have a struct device pointer.
Dong Aisheng (4):
clk: bulk: add of_clk_bulk_get()
clk: add new APIs to operate on all available clocks
clk: add managed version of clk_bulk_get_all
video: simplefb: switch to use clk_bulk API to simplify clock
operations
drivers/clk/clk-bulk.c | 80 ++++++++++++++++++++++++++++++++++++++++++
drivers/clk/clk-devres.c | 24 +++++++++++++
drivers/video/fbdev/simplefb.c | 66 +++++++---------------------------
include/linux/clk.h | 65 +++++++++++++++++++++++++++++++++-
4 files changed, 180 insertions(+), 55 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH V3 1/4] clk: bulk: add of_clk_bulk_get()
From: Dong Aisheng @ 2018-05-25 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527244643-10736-1-git-send-email-aisheng.dong@nxp.com>
'clock-names' property is optional in DT, so of_clk_bulk_get() is
introduced here to handle this for DT users without 'clock-names'
specified. Later clk_bulk_get_all() will be implemented on top of
it and this API will be kept private until someone proves they need
it because they don't have a struct device pointer.
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reported-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v2->v3:
* remove #if define condition
* remove EXPORT_SYMBOL
---
drivers/clk/clk-bulk.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c
index 6904ed6..4460ac5 100644
--- a/drivers/clk/clk-bulk.c
+++ b/drivers/clk/clk-bulk.c
@@ -19,6 +19,35 @@
#include <linux/clk.h>
#include <linux/device.h>
#include <linux/export.h>
+#include <linux/of.h>
+
+static int __must_check of_clk_bulk_get(struct device_node *np, int num_clks,
+ struct clk_bulk_data *clks)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < num_clks; i++)
+ clks[i].clk = NULL;
+
+ for (i = 0; i < num_clks; i++) {
+ clks[i].clk = of_clk_get(np, i);
+ if (IS_ERR(clks[i].clk)) {
+ ret = PTR_ERR(clks[i].clk);
+ pr_err("%pOF: Failed to get clk index: %d ret: %d\n",
+ np, i, ret);
+ clks[i].clk = NULL;
+ goto err;
+ }
+ }
+
+ return 0;
+
+err:
+ clk_bulk_put(i, clks);
+
+ return ret;
+}
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks)
{
--
2.7.4
^ permalink raw reply related
* [PATCH V3 2/4] clk: add new APIs to operate on all available clocks
From: Dong Aisheng @ 2018-05-25 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527244643-10736-1-git-send-email-aisheng.dong@nxp.com>
This patch introduces of_clk_bulk_get_all and clk_bulk_x_all APIs
to users who just want to handle all available clocks from device tree
without need to know the detailed clock information likes clock numbers
and names. This is useful in writing some generic drivers to handle clock
part.
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v2->v3:
* remove #if define condition
* use kmalloc_array
v1->v2:
* make of_clk_bulk_get_all private
* add clk_bulk_get/put_all
---
drivers/clk/clk-bulk.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/clk.h | 42 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c
index 4460ac5..6a7118d 100644
--- a/drivers/clk/clk-bulk.c
+++ b/drivers/clk/clk-bulk.c
@@ -17,9 +17,11 @@
*/
#include <linux/clk.h>
+#include <linux/clk-provider.h>
#include <linux/device.h>
#include <linux/export.h>
#include <linux/of.h>
+#include <linux/slab.h>
static int __must_check of_clk_bulk_get(struct device_node *np, int num_clks,
struct clk_bulk_data *clks)
@@ -49,6 +51,32 @@ static int __must_check of_clk_bulk_get(struct device_node *np, int num_clks,
return ret;
}
+static int __must_check of_clk_bulk_get_all(struct device_node *np,
+ struct clk_bulk_data **clks)
+{
+ struct clk_bulk_data *clk_bulk;
+ int num_clks;
+ int ret;
+
+ num_clks = of_clk_get_parent_count(np);
+ if (!num_clks)
+ return 0;
+
+ clk_bulk = kmalloc_array(num_clks, sizeof(*clk_bulk), GFP_KERNEL);
+ if (!clk_bulk)
+ return -ENOMEM;
+
+ ret = of_clk_bulk_get(np, num_clks, clk_bulk);
+ if (ret) {
+ kfree(clk_bulk);
+ return ret;
+ }
+
+ *clks = clk_bulk;
+
+ return num_clks;
+}
+
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks)
{
while (--num_clks >= 0) {
@@ -88,6 +116,29 @@ int __must_check clk_bulk_get(struct device *dev, int num_clks,
}
EXPORT_SYMBOL(clk_bulk_get);
+void clk_bulk_put_all(int num_clks, struct clk_bulk_data *clks)
+{
+ if (IS_ERR_OR_NULL(clks))
+ return;
+
+ clk_bulk_put(num_clks, clks);
+
+ kfree(clks);
+}
+EXPORT_SYMBOL(clk_bulk_put_all);
+
+int __must_check clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks)
+{
+ struct device_node *np = dev_of_node(dev);
+
+ if (!np)
+ return 0;
+
+ return of_clk_bulk_get_all(np, clks);
+}
+EXPORT_SYMBOL(clk_bulk_get_all);
+
#ifdef CONFIG_HAVE_CLK_PREPARE
/**
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 0dbd088..a76fdff 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -279,7 +279,26 @@ struct clk *clk_get(struct device *dev, const char *id);
*/
int __must_check clk_bulk_get(struct device *dev, int num_clks,
struct clk_bulk_data *clks);
-
+/**
+ * clk_bulk_get_all - lookup and obtain all available references to clock
+ * producer.
+ * @dev: device for clock "consumer"
+ * @clks: pointer to the clk_bulk_data table of consumer
+ *
+ * This helper function allows drivers to get all clk consumers in one
+ * operation. If any of the clk cannot be acquired then any clks
+ * that were obtained will be freed before returning to the caller.
+ *
+ * Returns a positive value for the number of clocks obtained while the
+ * clock references are stored in the clk_bulk_data table in @clks field.
+ * Returns 0 if there're none and a negative value if something failed.
+ *
+ * Drivers must assume that the clock source is not enabled.
+ *
+ * clk_bulk_get should not be called from within interrupt context.
+ */
+int __must_check clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks);
/**
* devm_clk_bulk_get - managed get multiple clk consumers
* @dev: device for clock "consumer"
@@ -455,6 +474,19 @@ void clk_put(struct clk *clk);
void clk_bulk_put(int num_clks, struct clk_bulk_data *clks);
/**
+ * clk_bulk_put_all - "free" all the clock source
+ * @num_clks: the number of clk_bulk_data
+ * @clks: the clk_bulk_data table of consumer
+ *
+ * Note: drivers must ensure that all clk_bulk_enable calls made on this
+ * clock source are balanced by clk_bulk_disable calls prior to calling
+ * this function.
+ *
+ * clk_bulk_put_all should not be called from within interrupt context.
+ */
+void clk_bulk_put_all(int num_clks, struct clk_bulk_data *clks);
+
+/**
* devm_clk_put - "free" a managed clock source
* @dev: device used to acquire the clock
* @clk: clock source acquired with devm_clk_get()
@@ -609,6 +641,12 @@ static inline int __must_check clk_bulk_get(struct device *dev, int num_clks,
return 0;
}
+static inline int __must_check clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks)
+{
+ return 0;
+}
+
static inline struct clk *devm_clk_get(struct device *dev, const char *id)
{
return NULL;
@@ -630,6 +668,8 @@ static inline void clk_put(struct clk *clk) {}
static inline void clk_bulk_put(int num_clks, struct clk_bulk_data *clks) {}
+static inline void clk_bulk_put_all(int num_clks, struct clk_bulk_data *clks) {}
+
static inline void devm_clk_put(struct device *dev, struct clk *clk) {}
--
2.7.4
^ permalink raw reply related
* [PATCH V3 3/4] clk: add managed version of clk_bulk_get_all
From: Dong Aisheng @ 2018-05-25 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527244643-10736-1-git-send-email-aisheng.dong@nxp.com>
This patch introduces the managed version of clk_bulk_get_all.
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v2->v3:
* a minor fix of build warning on PowerPC platform.
v1->v2:
* new patch
---
drivers/clk/clk-devres.c | 24 ++++++++++++++++++++++++
include/linux/clk.h | 23 +++++++++++++++++++++++
2 files changed, 47 insertions(+)
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index d854e26..6d3ca5e 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -70,6 +70,30 @@ int __must_check devm_clk_bulk_get(struct device *dev, int num_clks,
}
EXPORT_SYMBOL_GPL(devm_clk_bulk_get);
+int __must_check devm_clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks)
+{
+ struct clk_bulk_devres *devres;
+ int ret;
+
+ devres = devres_alloc(devm_clk_bulk_release,
+ sizeof(*devres), GFP_KERNEL);
+ if (!devres)
+ return -ENOMEM;
+
+ ret = clk_bulk_get_all(dev, clks);
+ if (ret > 0) {
+ devres->clks = *clks;
+ devres->num_clks = ret;
+ devres_add(dev, devres);
+ } else {
+ devres_free(devres);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(devm_clk_bulk_get_all);
+
static int devm_clk_match(struct device *dev, void *res, void *data)
{
struct clk **c = res;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index a76fdff..ef20217 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -313,6 +313,22 @@ int __must_check clk_bulk_get_all(struct device *dev,
*/
int __must_check devm_clk_bulk_get(struct device *dev, int num_clks,
struct clk_bulk_data *clks);
+/**
+ * devm_clk_bulk_get_all - managed get multiple clk consumers
+ * @dev: device for clock "consumer"
+ * @clks: pointer to the clk_bulk_data table of consumer
+ *
+ * Returns a positive value for the number of clocks obtained while the
+ * clock references are stored in the clk_bulk_data table in @clks field.
+ * Returns 0 if there're none and a negative value if something failed.
+ *
+ * This helper function allows drivers to get several clk
+ * consumers in one operation with management, the clks will
+ * automatically be freed when the device is unbound.
+ */
+
+int __must_check devm_clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks);
/**
* devm_clk_get - lookup and obtain a managed reference to a clock producer.
@@ -658,6 +674,13 @@ static inline int __must_check devm_clk_bulk_get(struct device *dev, int num_clk
return 0;
}
+static inline int __must_check devm_clk_bulk_get_all(struct device *dev,
+ struct clk_bulk_data **clks)
+{
+
+ return 0;
+}
+
static inline struct clk *devm_get_clk_from_child(struct device *dev,
struct device_node *np, const char *con_id)
{
--
2.7.4
^ permalink raw reply related
* [PATCH V3 4/4] video: simplefb: switch to use clk_bulk API to simplify clock operations
From: Dong Aisheng @ 2018-05-25 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527244643-10736-1-git-send-email-aisheng.dong@nxp.com>
Switching to use clk_bulk API to simplify clock operations.
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-fbdev at vger.kernel.org
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v2->v3:
* fix a build warning on x86 platform due to a wrong
of the prototype of simplefb_clocks_enable
v1->v2:
* switch to clk_bulk_get_all from of_clk_bulk_get_all
---
drivers/video/fbdev/simplefb.c | 66 ++++++++----------------------------------
1 file changed, 12 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index a3c44ec..db74354 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -182,7 +182,7 @@ struct simplefb_par {
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
bool clks_enabled;
unsigned int clk_count;
- struct clk **clks;
+ struct clk_bulk_data *clks;
#endif
#if defined CONFIG_OF && defined CONFIG_REGULATOR
bool regulators_enabled;
@@ -214,37 +214,13 @@ static int simplefb_clocks_get(struct simplefb_par *par,
struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct clk *clock;
- int i;
if (dev_get_platdata(&pdev->dev) || !np)
return 0;
- par->clk_count = of_clk_get_parent_count(np);
- if (!par->clk_count)
- return 0;
-
- par->clks = kcalloc(par->clk_count, sizeof(struct clk *), GFP_KERNEL);
- if (!par->clks)
- return -ENOMEM;
-
- for (i = 0; i < par->clk_count; i++) {
- clock = of_clk_get(np, i);
- if (IS_ERR(clock)) {
- if (PTR_ERR(clock) == -EPROBE_DEFER) {
- while (--i >= 0) {
- if (par->clks[i])
- clk_put(par->clks[i]);
- }
- kfree(par->clks);
- return -EPROBE_DEFER;
- }
- dev_err(&pdev->dev, "%s: clock %d not found: %ld\n",
- __func__, i, PTR_ERR(clock));
- continue;
- }
- par->clks[i] = clock;
- }
+ par->clk_count = clk_bulk_get_all(&pdev->dev, &par->clks);
+ if ((par->clk_count < 0) && (par->clk_count == -EPROBE_DEFER))
+ return -EPROBE_DEFER;
return 0;
}
@@ -252,39 +228,21 @@ static int simplefb_clocks_get(struct simplefb_par *par,
static void simplefb_clocks_enable(struct simplefb_par *par,
struct platform_device *pdev)
{
- int i, ret;
+ int ret;
+
+ ret = clk_bulk_prepare_enable(par->clk_count, par->clks);
+ if (ret)
+ dev_warn(&pdev->dev, "failed to enable clocks\n");
- for (i = 0; i < par->clk_count; i++) {
- if (par->clks[i]) {
- ret = clk_prepare_enable(par->clks[i]);
- if (ret) {
- dev_err(&pdev->dev,
- "%s: failed to enable clock %d: %d\n",
- __func__, i, ret);
- clk_put(par->clks[i]);
- par->clks[i] = NULL;
- }
- }
- }
par->clks_enabled = true;
}
static void simplefb_clocks_destroy(struct simplefb_par *par)
{
- int i;
-
- if (!par->clks)
- return;
-
- for (i = 0; i < par->clk_count; i++) {
- if (par->clks[i]) {
- if (par->clks_enabled)
- clk_disable_unprepare(par->clks[i]);
- clk_put(par->clks[i]);
- }
- }
+ if (par->clks_enabled)
+ clk_bulk_disable_unprepare(par->clk_count, par->clks);
- kfree(par->clks);
+ clk_bulk_put_all(par->clk_count, par->clks);
}
#else
static int simplefb_clocks_get(struct simplefb_par *par,
--
2.7.4
^ permalink raw reply related
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Julien Thierry @ 2018-05-25 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4e5f8ff-ecde-7b88-8a37-39e47ef22917@arm.com>
On 25/05/18 11:36, Suzuki K Poulose wrote:
> On 25/05/18 11:17, Julien Thierry wrote:
>>
>>
>> On 25/05/18 11:04, Suzuki K Poulose wrote:
>>> On 25/05/18 10:49, Julien Thierry wrote:
>>>> Add a cpufeature indicating whether a cpu supports masking interrupts
>>>> by priority.
>>>
>>> How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
>>> the description ?
>>
>> More or less.
>>
>> It is just to have an easier condition in the rest of the series.
>> Basically the PRIO masking feature is enabled if we have a GICv3 CPUIF
>> working *and* the option was selected at build time. Before this meant
>> that I was checking for the GIC_CPUIF cap inside #ifdefs (and putting
>> alternatives depending on that inside #ifdefs as well).
>>
>> Having this as a separate feature feels easier to manage in the code.
>> It also makes it clearer at boot time that the kernel will be using
>> irq priorities (although I admit it was not the initial intention):
>>
>> [??? 0.000000] CPU features: detected: IRQ priority masking
>>
>>
>> But yes that new feature will be detected only if SYSREG_GIC_CPUIF
>> gets detected as well.
>
> Well, you could always wrap the check like :
>
> static inline bool system_has_irq_priority_masking(void)
> {
> ????return (IS_ENABLED(CONFIG_YOUR_CONFIG) &&
> cpus_have_const_cap(HWCAP_SYSREG_GIC_CPUIF));
> }
>
> and use it everywhere.
>
Yes, but I can't use that in the asm parts that use alternatives and
would need to surround them in #ifdef... :\
> The description could be statically changed to reflect based on the #ifdef.
>
>
> static const struct arm64_cpu_capabilities arm64_features[] = {
> ??????? {
> #ifdef CONFIG_YOUR_CONFIG
> ??????? .desc = "GIC System register CPU interface with IRQ priority
> masking"
> #else
> ??????????????? .desc = "GIC system register CPU interface",
> #endif
> ??????????????? .capability = ARM64_HAS_SYSREG_GIC_CPUIF,
> ??????????????? .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> ??????????????? .matches = has_useable_gicv3_cpuif,
> ??????????????? .sys_reg = SYS_ID_AA64PFR0_EL1,
> ??????????????? .field_pos = ID_AA64PFR0_GIC_SHIFT,
> ??????????????? .sign = FTR_UNSIGNED,
> ??????????????? .min_field_value = 1,
>
> Cheers
> Suzuki
--
Julien Thierry
^ permalink raw reply
* [PATCH v4 00/26] arm64: provide pseudo NMI with GICv3
From: Julien Thierry @ 2018-05-25 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525101632.cfcfnmnt2u7rz3lt@holly.lan>
On 25/05/18 11:16, Daniel Thompson wrote:
> On Fri, May 25, 2018 at 10:49:06AM +0100, Julien Thierry wrote:
>> 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.
>>
>> 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.
>>
>> After the big refactoring I get performances similar to the ones I had
>> in v3[2], reposting old results here:
>>
>> - "hackbench 200 process 1000" (average over 20 runs)
>> +-----------+----------+------------+------------------+
>> | | native | PMR guest | v4.17-rc6 guest |
>> +-----------+----------+------------+------------------+
>> | PMR host | 40.0336s | 39.3039s | 39.2044s |
>> | v4.17-rc6 | 40.4040s | 39.6011s | 39.1147s |
>> +-----------+----------+------------+------------------+
>>
>> - Kernel build from defconfig:
>> PMR host: 13m45.743s
>> v4.17-rc6: 13m40.400s
>>
>> I'll try to post more detailed benchmarks later if I find notable
>> differences with the previous version.
>
> Do you have a public git tree anywhere... I *can* apply 26 patches from
> e-mail but I'd rather pull them!
>
Yes that makes sense, I'll try to get one set up.
I'll let you know once I have done so.
Cheers,
>
> Daniel.
>
>>
>>
>> Requirements to use this:
>> - Have GICv3
>> - SCR_EL3.FIQ is set to 1 when linux runs or have single security state
>> - Select Kernel Feature -> Use ICC system registers for IRQ masking
>>
>>
>> * Patches 1 to 4 aim at applying some alternatives early in the boot
>> process, including the feature for priority masking.
>>
>> * Patches 5 to 7 and 17 lightly refactor bits of GIC driver to make things
>> nicer for the rest of the series.
>>
>> * Patches 8 to 10 and 16 ensure the logic of daifflags remains valid
>> after arch_local_irq flags use ICC_PMR_EL1.
>>
>> * Patches 11 to 14 do some required PMR treatement in order for things to
>> work when the system uses priority masking.
>>
>> * Patches 15, 18, 19, 20 and 21 actually make the changes to use
>> ICC_PMR_EL1 for priority masking/unmasking when disabling/enabling
>> interrupts.
>>
>> * Patches 22 to 26 provide support for pseudo-NMI in the GICv3 driver
>> when priority masking is enabled.
>>
>>
>> Changes since V3[2]:
>> * Big refactoring. As suggested by Marc Z., some of the bigger patches
>> needed to be split into smaller one.
>>
>> * Try to reduce the amount of #ifdef for the new feature by introducing
>> an individual cpufeature for priority masking
>>
>> * Do not track which alternatives have been applied (was a bit dodgy
>> anyway), and use an alternative for VHE cpu_enable callback
>>
>> * Fix a build failure with arm by adding the correct RPR accessors
>>
>> * Added Suggested-by tags for changes from comming or inspired by Daniel's
>> series. Do let me know if you feel I missed something and am not giving
>> you due credit.
>>
>> Changes since V2[3]:
>> * Series rebase to v4.17-rc6
>>
>> * Adapt pathces 1 and 2 to the rework of cpufeatures framework
>>
>> * Use the group0 detection scheme in the GICv3 driver to identify
>> the priority view, and drop the use of a fake interrupt
>>
>> * Add the case for a GIC configured in a single security state
>>
>> * Use local_daif_restore instead of local_irq_enable the first time
>> we enable interrupts after a bp hardening in the handling of a kernel
>> entry. Otherwise PRS.I remains set...
>>
>> Changes since V1[4]:
>> * Series rebased to v4.15-rc8.
>>
>> * Check for arm64_early_features in this_cpu_has_cap (spotted by Suzuki).
>>
>> * Fix issue where debug exception were not masked when enabling debug in
>> mdscr_el1.
>>
>> Changes since RFC[5]:
>> * 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://lkml.org/lkml/2018/5/21/276
>> [3] https://lkml.org/lkml/2018/1/17/335
>> [4] https://www.spinics.net/lists/arm-kernel/msg620763.html
>> [5] https://www.spinics.net/lists/arm-kernel/msg610736.html
>>
>> Cheers,
>>
>> Julien
>>
>> -->
>>
>> Daniel Thompson (1):
>> arm64: alternative: Apply alternatives early in boot process
>>
>> Julien Thierry (25):
>> arm64: cpufeature: Set SYSREG_GIC_CPUIF as a boot system feature
>> arm64: cpufeature: Add cpufeature for IRQ priority masking
>> arm64: cpufeature: Use alternatives for VHE cpu_enable
>> irqchip/gic: Unify GIC priority definitions
>> irqchip/gic: Lower priority of GIC interrupts
>> irqchip/gic-v3: Remove acknowledge loop
>> arm64: daifflags: Use irqflags functions for daifflags
>> arm64: Use daifflag_restore after bp_hardening
>> arm64: Delay daif masking for user return
>> arm64: Make PMR part of task context
>> arm64: Unmask PMR before going idle
>> arm/arm64: gic-v3: Add helper functions to manage IRQ priorities
>> arm64: kvm: Unmask PMR before entering guest
>> arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking
>> arm64: daifflags: Include PMR in daifflags restore operations
>> irqchip/gic-v3: Factor group0 detection into functions
>> irqchip/gic-v3: Do not overwrite PMR value
>> irqchip/gic-v3: Switch to PMR masking after IRQ acknowledge
>> arm64: Switch to PMR masking when starting CPUs
>> arm64: Add build option for IRQ masking via priority
>> arm64: Detect current view of GIC priorities
>> irqchip/gic: Add functions to access irq priorities
>> irqchip/gic-v3: Add base support for pseudo-NMI
>> irqchip/gic-v3: Provide NMI handlers
>> irqchip/gic-v3: Allow interrupts to be set as pseudo-NMI
>>
>> Documentation/arm64/booting.txt | 5 +
>> arch/arm/include/asm/arch_gicv3.h | 33 ++++
>> arch/arm64/Kconfig | 15 ++
>> arch/arm64/include/asm/alternative.h | 3 +-
>> arch/arm64/include/asm/arch_gicv3.h | 32 ++++
>> arch/arm64/include/asm/assembler.h | 17 +-
>> arch/arm64/include/asm/cpucaps.h | 3 +-
>> arch/arm64/include/asm/cpufeature.h | 2 +
>> arch/arm64/include/asm/daifflags.h | 32 ++--
>> arch/arm64/include/asm/efi.h | 3 +-
>> arch/arm64/include/asm/irqflags.h | 100 ++++++++---
>> arch/arm64/include/asm/kvm_host.h | 12 ++
>> arch/arm64/include/asm/processor.h | 1 +
>> arch/arm64/include/asm/ptrace.h | 13 +-
>> arch/arm64/kernel/alternative.c | 30 +++-
>> arch/arm64/kernel/asm-offsets.c | 1 +
>> arch/arm64/kernel/cpufeature.c | 35 +++-
>> arch/arm64/kernel/entry.S | 67 ++++++-
>> arch/arm64/kernel/head.S | 35 ++++
>> arch/arm64/kernel/process.c | 2 +
>> arch/arm64/kernel/smp.c | 12 ++
>> arch/arm64/kvm/hyp/switch.c | 17 ++
>> arch/arm64/mm/fault.c | 5 +-
>> arch/arm64/mm/proc.S | 18 ++
>> 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 | 318 +++++++++++++++++++++++++++------
>> include/linux/interrupt.h | 1 +
>> include/linux/irqchip/arm-gic-common.h | 6 +
>> include/linux/irqchip/arm-gic.h | 5 -
>> 31 files changed, 719 insertions(+), 118 deletions(-)
>>
>> --
>> 1.9.1
--
Julien Thierry
^ permalink raw reply
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Suzuki K Poulose @ 2018-05-25 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54ff6127-928d-99a3-a6e9-59799628ca87@arm.com>
On 25/05/18 11:39, Julien Thierry wrote:
>
>
> On 25/05/18 11:36, Suzuki K Poulose wrote:
>> On 25/05/18 11:17, Julien Thierry wrote:
>>>
>>>
>>> On 25/05/18 11:04, Suzuki K Poulose wrote:
>>>> On 25/05/18 10:49, Julien Thierry wrote:
>>>>> Add a cpufeature indicating whether a cpu supports masking interrupts
>>>>> by priority.
>>>>
>>>> How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
>>>> the description ?
>>>
>>> More or less.
>>>
>>> It is just to have an easier condition in the rest of the series. Basically the PRIO masking feature is enabled if we have a GICv3 CPUIF working *and* the option was selected at build time. Before this meant that I was checking for the GIC_CPUIF cap inside #ifdefs (and putting alternatives depending on that inside #ifdefs as well).
>>>
>>> Having this as a separate feature feels easier to manage in the code. It also makes it clearer at boot time that the kernel will be using irq priorities (although I admit it was not the initial intention):
>>>
>>> [??? 0.000000] CPU features: detected: IRQ priority masking
>>>
>>>
>>> But yes that new feature will be detected only if SYSREG_GIC_CPUIF gets detected as well.
>>
>> Well, you could always wrap the check like :
>>
>> static inline bool system_has_irq_priority_masking(void)
>> {
>> ?????return (IS_ENABLED(CONFIG_YOUR_CONFIG) && cpus_have_const_cap(HWCAP_SYSREG_GIC_CPUIF));
>> }
>>
>> and use it everywhere.
>>
>
> Yes, but I can't use that in the asm parts that use alternatives and would need to surround them in #ifdef... :\
I thought there is _ALTERNATIVE_CFG() to base the alternative depend on a CONFIG_xxx ?
Doesn't that solve the problem ?
Suzuki
^ permalink raw reply
* [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains
From: Ulf Hansson @ 2018-05-25 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2c63af8c-4745-a751-8d3d-f7122e921e6f@nvidia.com>
On 25 May 2018 at 10:31, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 24/05/18 22:11, Ulf Hansson wrote:
>>
>> On 24 May 2018 at 17:48, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>
>>>
>>> On 18/05/18 11:31, Ulf Hansson wrote:
>>>>
>>>>
>>>> The existing dev_pm_domain_attach() function, allows a single PM domain
>>>> to
>>>> be attached per device. To be able to support devices that are
>>>> partitioned
>>>> across multiple PM domains, let's introduce a new interface,
>>>> dev_pm_domain_attach_by_id().
>>>>
>>>> The dev_pm_domain_attach_by_id() returns a new allocated struct device
>>>> with
>>>> the corresponding attached PM domain. This enables for example a driver
>>>> to
>>>> operate on the new device from a power management point of view. The
>>>> driver
>>>> may then also benefit from using the received device, to set up so
>>>> called
>>>> device-links towards its original device. Depending on the situation,
>>>> these
>>>> links may then be dynamically changed.
>>>>
>>>> The new interface is typically called by drivers during their probe
>>>> phase,
>>>> in case they manages devices which uses multiple PM domains. If that is
>>>> the
>>>> case, the driver also becomes responsible of managing the detaching of
>>>> the
>>>> PM domains, which typically should be done at the remove phase.
>>>> Detaching
>>>> is done by calling the existing dev_pm_domain_detach() function and for
>>>> each of the received devices from dev_pm_domain_attach_by_id().
>>>>
>>>> Note, currently its only genpd that supports multiple PM domains per
>>>> device, but dev_pm_domain_attach_by_id() can easily by extended to cover
>>>> other PM domain types, if/when needed.
>>>>
>>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>> ---
>>>> drivers/base/power/common.c | 33 ++++++++++++++++++++++++++++++++-
>>>> include/linux/pm_domain.h | 7 +++++++
>>>> 2 files changed, 39 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
>>>> index 7ae62b6..d3db974 100644
>>>> --- a/drivers/base/power/common.c
>>>> +++ b/drivers/base/power/common.c
>>>> @@ -117,13 +117,44 @@ int dev_pm_domain_attach(struct device *dev, bool
>>>> power_on)
>>>> EXPORT_SYMBOL_GPL(dev_pm_domain_attach);
>>>> /**
>>>> + * dev_pm_domain_attach_by_id - Attach a device to one of its PM
>>>> domains.
>>>
>>>
>>>
>>> Isn't this more of a 'get'?
>>
>>
>> I don't think so, at least according to the common understanding of
>> how we use get and put APIs.
>>
>> For example, clk_get() returns a cookie to a clk, which you then can
>> do a hole bunch of different clk specific operations on.
>>
>> This is different, there are no specific PM domain operations the
>> caller can or should do. Instead the idea is to keep drivers more or
>> less transparent, still using runtime PM as before. The only care the
>> caller need to take is to use device links, which BTW isn't a PM
>> domain specific thing.
>
>
> Yes, but a user can still call pm_runtime_get/put with the device returned
> if they wish to, right?
Correct.
[...]
>>>> + */
>>>> +struct device *dev_pm_domain_attach_by_id(struct device *dev,
>>>> + unsigned int index)
>>>> +{
>>>> + if (dev->pm_domain)
>>>
>>>
>>>
>>> I wonder if this is worthy of a ...
>>>
>>> if (WARN_ON(dev->pm_domain))
>>>
>>>> + return NULL;
>>>
>>>
>>>
>>> Don't we consider this an error case? I wonder why not return PTR_ERR
>>> here
>>> as well? This would be consistent with dev_pm_domain_attach().
>>
>>
>> Please see above comment.
>
>
> Right, but this case still seems like an error. My understanding is that
> only drivers will use this API directly and it will not be used by the
> device driver core (unlike dev_pm_domain_attach), so if anyone calls this
> attempting to attach another PM domain when one is already attached, they
> are doing something wrong.
[...]
You may be right!
What I was thinking of is whether multiple PM domains may be optional
in some cases, but instead a PM domain have already been attached by
dev_pm_domain_attach(), prior the driver starts to probe.
Then, assuming we return an error for this case, that means the caller
then need to check the dev->pm_domain pointer, prior calling
dev_pm_domain_attach_by_id(). Wouldn't it? Perhaps that is more clear
though?
Kind regards
Uffe
^ permalink raw reply
* [PATCH v11 08/19] arm64: fpsimd: Eliminate task->mm checks
From: Dave Martin @ 2018-05-25 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r2m0rqzw.fsf@linaro.org>
On Fri, May 25, 2018 at 11:04:03AM +0100, Alex Benn?e wrote:
>
> Dave Martin <Dave.Martin@arm.com> writes:
>
> > Currently the FPSIMD handling code uses the condition task->mm ==
> > NULL as a hint that task has no FPSIMD register context.
> >
> > The ->mm check is only there to filter out tasks that cannot
> > possibly have FPSIMD context loaded, for optimisation purposes.
> > Also, TIF_FOREIGN_FPSTATE must always be checked anyway before
> > saving FPSIMD context back to memory. For these reasons, the ->mm
> > checks are not useful, providing that TIF_FOREIGN_FPSTATE is
> > maintained in a consistent way for all threads.
> >
> > The context switch logic is already deliberately optimised to defer
> > reloads of the regs until ret_to_user (or sigreturn as a special
> > case), and save them only if they have been previously loaded.
> > These paths are the only places where the wrong_task and wrong_cpu
> > conditions can be made false, by calling fpsimd_bind_task_to_cpu().
> > Kernel threads by definition never reach these paths. As a result,
> > the wrong_task and wrong_cpu tests in fpsimd_thread_switch() will
> > always yield true for kernel threads.
> >
> > This patch removes the redundant checks and special-case code, ensuring that TIF_FOREIGN_FPSTATE is set whenever a kernel thread is scheduled in, and ensures that this flag is set for the init
> > task. The fpsimd_flush_task_state() call already present in
> > copy_thread() ensures the same for any new task.
> >
> > With TIF_FOREIGN_FPSTATE always set for kernel threads, this patch
> > ensures that no extra context save work is added for kernel
> > threads, and eliminates the redundant context saving that may
> > currently occur for kernel threads that have acquired an mm via
> > use_mm().
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
>
> Still good (although obviously without the ws damage in the commit).
Agreed -- I'll coordinate with Marc to make sure that gets fixed.
Thanks for the review.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Julien Thierry @ 2018-05-25 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3f0afa54-8e98-798e-68dc-bbbc74bd9e19@arm.com>
On 25/05/18 11:41, Suzuki K Poulose wrote:
> On 25/05/18 11:39, Julien Thierry wrote:
>>
>>
>> On 25/05/18 11:36, Suzuki K Poulose wrote:
>>> On 25/05/18 11:17, Julien Thierry wrote:
>>>>
>>>>
>>>> On 25/05/18 11:04, Suzuki K Poulose wrote:
>>>>> On 25/05/18 10:49, Julien Thierry wrote:
>>>>>> Add a cpufeature indicating whether a cpu supports masking interrupts
>>>>>> by priority.
>>>>>
>>>>> How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
>>>>> the description ?
>>>>
>>>> More or less.
>>>>
>>>> It is just to have an easier condition in the rest of the series.
>>>> Basically the PRIO masking feature is enabled if we have a GICv3
>>>> CPUIF working *and* the option was selected at build time. Before
>>>> this meant that I was checking for the GIC_CPUIF cap inside #ifdefs
>>>> (and putting alternatives depending on that inside #ifdefs as well).
>>>>
>>>> Having this as a separate feature feels easier to manage in the
>>>> code. It also makes it clearer at boot time that the kernel will be
>>>> using irq priorities (although I admit it was not the initial
>>>> intention):
>>>>
>>>> [??? 0.000000] CPU features: detected: IRQ priority masking
>>>>
>>>>
>>>> But yes that new feature will be detected only if SYSREG_GIC_CPUIF
>>>> gets detected as well.
>>>
>>> Well, you could always wrap the check like :
>>>
>>> static inline bool system_has_irq_priority_masking(void)
>>> {
>>> ?????return (IS_ENABLED(CONFIG_YOUR_CONFIG) &&
>>> cpus_have_const_cap(HWCAP_SYSREG_GIC_CPUIF));
>>> }
>>>
>>> and use it everywhere.
>>>
>>
>> Yes, but I can't use that in the asm parts that use alternatives and
>> would need to surround them in #ifdef... :\
>
> I thought there is _ALTERNATIVE_CFG() to base the alternative depend on
> a CONFIG_xxx ?
> Doesn't that solve the problem ?
Right, I didn't see that one. It should work yes.
I'll try that when working on the next version.
Thanks,
--
Julien Thierry
^ permalink raw reply
* REGRESSION: iommu fails to take address limit into account
From: Robin Murphy @ 2018-05-25 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_0ECwLhoA2ywp3nntFX=RxfpM+MWFwTain1WN1sMrW9g@mail.gmail.com>
On 25/05/18 11:35, Ard Biesheuvel wrote:
> On 25 May 2018 at 11:48, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> Hello all,
>>
>> I am looking into an issue where a platform device is wired to a
>> MMU-500, and for some reason (which is under investigation) the
>> platform device can not drive all address bits. I can work around this
>> by limiting the DMA mask to 40 bits in the driver. However, the IORT
>> table allows me to set the address limit as well, and so I was
>> expecting this to be taken into account by the SMMU driver.
>>
>> When the iort/iommu layer sets up the DMA operations,
>> iommu_dma_init_domain() is entered with the expected values:
>>
>> base == 0
>> size == 0x100_0000_0000
>>
>> However, the iommu layer ends up generating IOVA addresses that have
>> bits [47:40] set (which is what the MMU-500 supports). Looking closer,
>> this is not surprising, given that the end_pfn variable that is
>> calculated in iommu_dma_init_domain() is no longer used after Zhen's
>> patch aa3ac9469c185 ("iommu/iova: Make dma_32bit_pfn implicit") was
>> applied.
>>
>> So effectively, this is a regression, and I would like your help
>> figuring out how to go about fixing this.
>>
>
> I have narrowed it down a bit further: even though the IOVA range
> ignores the IORT address limit, the device's DMA mask is set
> correctly. The only problem is that the driver (like all drivers
> afaict) does not take into account the fact that its DMA mask has
> already been set by the bus layer before its probe function is called.
>
> I could add something like this
>
> - if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
> + if (dma_get_mask(&pdev->dev) == DMA_BIT_MASK(32) &&
> + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
> dev_warn(&pdev->dev, "Failed to enable 64-bit DMA\n");
>
> to only override the mask if it is not at its default value, but it
> feels like papering over the problem given that most drivers appear to
> ignore the preset mask as well.
Yup, that's the crux of it - if, say, the firmware describes an explicit
restriction to 32 bits, then drivers have no way to tell the difference
between that and the default mask initialised by the bus code (which
they *should* be able to widen), and at the moment neither does arch
code or anyone else (and the current interface between arch code and
firmware code does not help matters).
Robin.
^ permalink raw reply
* [PATCHv2] ARM64: KVM: use lm_alias() for kvm_ksym_ref()
From: Mark Rutland @ 2018-05-25 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510111347.32253-1-mark.rutland@arm.com>
On Thu, May 10, 2018 at 12:13:47PM +0100, Mark Rutland wrote:
> For historical reasons, we open-code lm_alias() in kvm_ksym_ref().
>
> Let's use lm_alias() to avoid duplication and make things clearer.
>
> As we have to pull this from <linux/mm.h> (which is not safe for
> inclusion in assembly), we may as well move the kvm_ksym_ref()
> definition into the existing !__ASSEMBLY__ block.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Christoffer Dall <christoffer.dall@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: kvmarm at lists.cs.columbia.edu
> ---
> arch/arm64/include/asm/kvm_asm.h | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Marc, Christoffer, are you happy to pick this up?
Mark.
> Since v1 [1]:
> * Rebase to v4.17-rc4
> * Fix typo in commit message
>
> Mark.
>
> [1] https://lkml.kernel.org/r/20180406151909.57197-1-mark.rutland at arm.com
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index f6648a3e4152..a9ceeec5a76f 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -33,16 +33,19 @@
> #define KVM_ARM64_DEBUG_DIRTY_SHIFT 0
> #define KVM_ARM64_DEBUG_DIRTY (1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
>
> +#ifndef __ASSEMBLY__
> +
> +#include <linux/mm.h>
> +
> /* Translate a kernel address of @sym into its equivalent linear mapping */
> #define kvm_ksym_ref(sym) \
> ({ \
> void *val = &sym; \
> if (!is_kernel_in_hyp_mode()) \
> - val = phys_to_virt((u64)&sym - kimage_voffset); \
> + val = lm_alias(&sym); \
> val; \
> })
>
> -#ifndef __ASSEMBLY__
> struct kvm;
> struct kvm_vcpu;
>
> --
> 2.11.0
>
^ permalink raw reply
* REGRESSION: iommu fails to take address limit into account
From: Ard Biesheuvel @ 2018-05-25 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d95cd70-70bd-9e63-c148-d535fbedb0d0@arm.com>
On 25 May 2018 at 12:49, Robin Murphy <robin.murphy@arm.com> wrote:
> On 25/05/18 11:35, Ard Biesheuvel wrote:
>>
>> On 25 May 2018 at 11:48, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>>
>>> Hello all,
>>>
>>> I am looking into an issue where a platform device is wired to a
>>> MMU-500, and for some reason (which is under investigation) the
>>> platform device can not drive all address bits. I can work around this
>>> by limiting the DMA mask to 40 bits in the driver. However, the IORT
>>> table allows me to set the address limit as well, and so I was
>>> expecting this to be taken into account by the SMMU driver.
>>>
>>> When the iort/iommu layer sets up the DMA operations,
>>> iommu_dma_init_domain() is entered with the expected values:
>>>
>>> base == 0
>>> size == 0x100_0000_0000
>>>
>>> However, the iommu layer ends up generating IOVA addresses that have
>>> bits [47:40] set (which is what the MMU-500 supports). Looking closer,
>>> this is not surprising, given that the end_pfn variable that is
>>> calculated in iommu_dma_init_domain() is no longer used after Zhen's
>>> patch aa3ac9469c185 ("iommu/iova: Make dma_32bit_pfn implicit") was
>>> applied.
>>>
>>> So effectively, this is a regression, and I would like your help
>>> figuring out how to go about fixing this.
>>>
>>
>> I have narrowed it down a bit further: even though the IOVA range
>> ignores the IORT address limit, the device's DMA mask is set
>> correctly. The only problem is that the driver (like all drivers
>> afaict) does not take into account the fact that its DMA mask has
>> already been set by the bus layer before its probe function is called.
>>
>> I could add something like this
>>
>> - if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
>> + if (dma_get_mask(&pdev->dev) == DMA_BIT_MASK(32) &&
>> + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
>> dev_warn(&pdev->dev, "Failed to enable 64-bit DMA\n");
>>
>> to only override the mask if it is not at its default value, but it
>> feels like papering over the problem given that most drivers appear to
>> ignore the preset mask as well.
>
>
> Yup, that's the crux of it - if, say, the firmware describes an explicit
> restriction to 32 bits, then drivers have no way to tell the difference
> between that and the default mask initialised by the bus code (which they
> *should* be able to widen), and at the moment neither does arch code or
> anyone else (and the current interface between arch code and firmware code
> does not help matters).
>
OK, so I guess we need an additional bus limit field that is
initialized to ~0 and can only be narrowed, and take that into account
when dma_set_mask_and_coherent() is called. Not pretty, but at least
we won't have to fix all the drivers.
^ permalink raw reply
* [PATCH v2 10/13] dmaengine: pxa: document pxad_param
From: Vinod @ 2018-05-25 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-11-robert.jarzmik@free.fr>
On 24-05-18, 09:07, Robert Jarzmik wrote:
> Add some documentation for the pxad_param structure, and describe the
> contract behind the minimal required priority of a DMA channel.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* [PATCH v2 11/13] dmaengine: pxa: make the filter function internal
From: Vinod @ 2018-05-25 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-12-robert.jarzmik@free.fr>
On 24-05-18, 09:07, Robert Jarzmik wrote:
> As the pxa architecture and all its related drivers do not rely anymore
> on the filter function, thanks to the slave map conversion, make
> pxad_filter_fn() static, and remove it from the global namespace.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* qcom: add firmware file for Venus on SDM845
From: Vikash Garodia @ 2018-05-25 11:03 UTC (permalink / raw)
To: linux-arm-kernel
hi,
This pull request adds firmware files for Venus h/w codec found on the Qualcomm SDM845 chipset.
The following changes since commit 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
Merge branch 'for-upstreaming-v1.7.2' of https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)
are available in the git repository at:
https://github.com/vgarodia/linux-firmware master
for you to fetch changes up to d6088b9c9d7f49d3c6c43681190889eca0abdcce:
qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
----------------------------------------------------------------
Vikash Garodia (1):
qcom: add venus firmware files for v5.2
WHENCE | 9 +++++++++
qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
qcom/venus-5.2/venus.b04 | 1 +
qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
8 files changed, 10 insertions(+)
create mode 100644 qcom/venus-5.2/venus.b00
create mode 100644 qcom/venus-5.2/venus.b01
create mode 100644 qcom/venus-5.2/venus.b02
create mode 100644 qcom/venus-5.2/venus.b03
create mode 100644 qcom/venus-5.2/venus.b04
create mode 100644 qcom/venus-5.2/venus.mbn
create mode 100644 qcom/venus-5.2/venus.mdt
^ permalink raw reply
* qcom: add firmware file for Venus on SDM845
From: Vikash Garodia @ 2018-05-25 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527246209-26685-1-git-send-email-vgarodia@codeaurora.org>
This pull request adds firmware files for Venus h/w codec found on the Qualcomm SDM845 chipset.
The following changes since commit 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
Merge branch 'for-upstreaming-v1.7.2' of https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)
are available in the git repository at:
https://github.com/vgarodia/linux-firmware master
for you to fetch changes up to d6088b9c9d7f49d3c6c43681190889eca0abdcce:
qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
----------------------------------------------------------------
Vikash Garodia (1):
qcom: add venus firmware files for v5.2
WHENCE | 9 +++++++++
qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
qcom/venus-5.2/venus.b04 | 1 +
qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
8 files changed, 10 insertions(+)
create mode 100644 qcom/venus-5.2/venus.b00
create mode 100644 qcom/venus-5.2/venus.b01
create mode 100644 qcom/venus-5.2/venus.b02
create mode 100644 qcom/venus-5.2/venus.b03
create mode 100644 qcom/venus-5.2/venus.b04
create mode 100644 qcom/venus-5.2/venus.mbn
create mode 100644 qcom/venus-5.2/venus.mdt
^ permalink raw reply
* [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Marc Zyngier @ 2018-05-25 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <25470133.K8n9sLBzRS@diego>
[Thanks Robin for pointing me to that patch.]
Hi Heiko,
On 24/05/18 23:06, Heiko St?bner wrote:
> From: Sandy Huang <hjc@rock-chips.com>
>
> The vop irq is shared between vop and iommu and irq probing in the
> iommu driver moved to the probe function recently. This can in some
> cases lead to a stall if the irq is triggered while the vop driver
> still has it disabled.
>
> But there is no real need to disable the irq, as the vop can simply
> also track its enabled state and ignore irqs in that case.
>
> So remove the enable/disable handling and add appropriate condition
> to the irq handler.
>
> Signed-off-by: Sandy Huang <hjc@rock-chips.com>
> [added an actual commit message]
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Hi Ezequiel,
>
> this patch came from a discussion I had with Rockchip people over the
> iommu changes and resulting issues back in april, but somehow was
> forgotten and not posted to the lists. Correcting that now.
>
> So removing the enable/disable voodoo on the shared interrupt is
> the preferred way.
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 510cdf0..61493d4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc)
>
> spin_unlock(&vop->reg_lock);
>
> - enable_irq(vop->irq);
> -
> drm_crtc_vblank_on(crtc);
>
> return 0;
> @@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
>
> vop_dsp_hold_valid_irq_disable(vop);
>
> - disable_irq(vop->irq);
> -
> vop->is_enabled = false;
>
> /*
> @@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data)
> int ret = IRQ_NONE;
>
> /*
> + * since the irq is shared with iommu, iommu irq is enabled before vop
> + * enable, so before vop enable we do nothing.
> + */
> + if (!vop->is_enabled)
> + return IRQ_NONE;
> +
What guarantee do we have that the IOMMU will actually service that
interrupt? Can't we get into a situation where the interrupt gets
ignored by both drivers and subsequently disabled by the core irq code
as being spurious?
>From what I understood of the way things are plugged together on the
rockchip platforms, each individual VOP is behind a single IOMMU, hence
there there is hardly any point in handling IOMMU interrupts if the VOP
is off.
But I'm missing the actual reason behind this patch. Could you enlighten me?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
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