* [PATCH 2/3] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Viresh Kumar @ 2016-10-19 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNATc2XxAZf-rvMkRjGn3q_18yB=9aycAE1j9+n0==xzaHQ@mail.gmail.com>
On 19-10-16, 17:33, Masahiro Yamada wrote:
> Hi Viresh,
>
>
> 2016-10-18 20:25 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> > On 16-10-16, 23:59, Masahiro Yamada wrote:
> >> + cluster0_opp: opp_table {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp at 245000000 {
> >> + opp-hz = /bits/ 64 <245000000>;
> >> + clock-latency-ns = <300>;
> >> + };
> >> + opp at 250000000 {
> >> + opp-hz = /bits/ 64 <250000000>;
> >> + clock-latency-ns = <300>;
> >> + };
> >> + opp at 490000000 {
> >> + opp-hz = /bits/ 64 <490000000>;
> >> + clock-latency-ns = <300>;
> >> + };
> >> + opp at 500000000 {
> >> + opp-hz = /bits/ 64 <500000000>;
> >> + clock-latency-ns = <300>;
> >> + };
> >> + opp at 653333333 {
> >
> > Why isn't ^^ matching with below values ? Same in next patch as well.
>
>
>
> When I try to update /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq,
> it did not work as I had expected.
>
>
> scaling_max_freq is specified by kHz unit,
> on the other hand, clock frequency in the clk driver is specified by Hz.
>
>
>
> If the operating point is 653333kHz, the cpufreq requests
> the clk driver to set 653333000, but it is lower than
> the exact clock, 653333333.
> So, the next lower frequency, 500000000 is selected.
> As a result, the operating point 653333kHz is never enabled.
>
>
> So, the operating point must be equal or a little bit bigger.
>
>
> Do you know a better way to solve this distortion?
I am not sure about how to fix that problem but there is no reason to
have the exact frequency in opp@*** name. Just use what you have used
in opp-hz line and you will have the exact same behavior.
Right now, its a bit confusing if we read the DT.
--
viresh
^ permalink raw reply
* [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Viresh Kumar @ 2016-10-19 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r37d4qlw.fsf@belgarion.home>
On 18-10-16, 17:35, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> > On 15-10-16, 21:57, Robert Jarzmik wrote:
> >> For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is
> >> doing the job as well as pxa2xx-cpufreq, so add these platforms to the
> >> compatibility list.
> >>
> >> This won't work for legacy non device-tree platforms where
> >> pxa2xx-cpufreq is still required.
> >>
> >> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >> ---
> >> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> >> index 0bb44d5b5df4..356825b5c9b8 100644
> >> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> >> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> >> @@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = {
> >> { .compatible = "fsl,imx7d", },
> >>
> >> { .compatible = "marvell,berlin", },
> >> + { .compatible = "marvell,pxa250", },
> >> + { .compatible = "marvell,pxa270", },
> >>
> >> { .compatible = "samsung,exynos3250", },
> >> { .compatible = "samsung,exynos4210", },
> >
> > Isn't there a race between cpufreq-dt and the platform driver to
> > register first ?
> Ah, could you be more specific about the race you're talking of ?
>
> My understanding was that cpufreq-dt-platdev does create the device, and
> cpufreq-dt is a driver for it, so there is no race but a direct relationship
> AFAIU.
I mean that both the driver may try to register to the cpufreq core if
they are both compiled in a single image.
--
viresh
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: pxa: add pxa25x cpu operating points
From: Viresh Kumar @ 2016-10-19 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vawp4qv0.fsf@belgarion.home>
On 18-10-16, 17:30, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> > On 15-10-16, 21:57, Robert Jarzmik wrote:
> >> Add the relevant data taken from the PXA 25x Electrical, Mechanical, and
> >> Thermal Specfication. This will be input data for cpufreq-dt driver.
> >>
> >> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >> ---
> >> arch/arm/boot/dts/pxa25x.dtsi | 25 +++++++++++++++++++++++++
> >> 1 file changed, 25 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
> >> index 0d1e012178c4..16b4e8bad4a5 100644
> >> --- a/arch/arm/boot/dts/pxa25x.dtsi
> >> +++ b/arch/arm/boot/dts/pxa25x.dtsi
> >> @@ -89,4 +89,29 @@
> >> clocks = <&clktimer>;
> >> status = "okay";
> >> };
> >> +
> >> + pxa250_opp_table: opp_table0 {
> >> + compatible = "operating-points-v2";
> >> +
> >> + opp at 99500 {
> >
> > We have been keeping the values in ^^^ same as the values present
> > below. Any specific reason for making it different here ?
> No, that's a good comment, I'll change that.
>
> I wrote this incrementaly, first the node, then the opp-hz. Then I realized that
> the source crystal, at 3.8684 MHz didn't provide a round 99.5 MHz core clock,
> but a 99.5328 MHz clock.
>
> Anyway, I'll change that ... let's say into opp at 99533 in this case ?
Just write the whole value 99532800.
--
viresh
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: Add SPI controller node in H3
From: Milo Kim @ 2016-10-19 13:46 UTC (permalink / raw)
To: linux-arm-kernel
H3 supports two SPI controllers. Four pins (MOSI, MISO, SCLK, SS) are
configured through the pinctrl subsystem. It is almost same as A31 SPI
except buffer size, so those DT properties are reusable.
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 46 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75a8654..c38b028 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -381,6 +381,20 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ spi0_pins: spi0 {
+ allwinner,pins = "PC0", "PC1", "PC2", "PC3";
+ allwinner,function = "spi0";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ spi1_pins: spi1 {
+ allwinner,pins = "PA15", "PA16", "PA14", "PA13";
+ allwinner,function = "spi1";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
uart0_pins_a: uart0 at 0 {
allwinner,pins = "PA4", "PA5";
allwinner,function = "uart0";
@@ -425,6 +439,38 @@
clocks = <&osc24M>;
};
+ spi0: spi at 01c68000 {
+ compatible = "allwinner,sun8i-h3-spi";
+ reg = <0x01c68000 0x1000>;
+ interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma 23>, <&dma 23>;
+ dma-names = "rx", "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ resets = <&ccu RST_BUS_SPI0>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi1: spi at 01c69000 {
+ compatible = "allwinner,sun8i-h3-spi";
+ reg = <0x01c69000 0x1000>;
+ interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI1>, <&ccu CLK_SPI1>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma 24>, <&dma 24>;
+ dma-names = "rx", "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+ resets = <&ccu RST_BUS_SPI1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
wdt0: watchdog at 01c20ca0 {
compatible = "allwinner,sun6i-a31-wdt";
reg = <0x01c20ca0 0x20>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2] arm64: Cortex-A53 errata workaround: check for kernel addresses
From: Andre Przywara @ 2016-10-19 13:40 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
errata-affected core") adds code to execute cache maintenance instructions
in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
It turns out that the address hasn't been checked to be a valid user
space address, allowing userland to clean cache lines in kernel space.
Fix this by introducing an access_ok() check before executing the
instructions on behalf of userland. We have to take care of tagged
pointers here, since the address is not coming in via a syscall (which
requires the tag to be 0).
Fixes: 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core")
Reported-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Changelog v1 .. v2:
- use PAGE_SIZE instead of cache_line_size() for access check
- merge extra function into original macro
- replace access_ok_tagged() with untagged_addr() macro
arch/arm64/include/asm/uaccess.h | 8 ++++++++
arch/arm64/kernel/traps.c | 35 +++++++++++++++++++++++------------
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index bcaf6fb..55d0adb 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -21,6 +21,7 @@
/*
* User space memory access functions
*/
+#include <linux/bitops.h>
#include <linux/kasan-checks.h>
#include <linux/string.h>
#include <linux/thread_info.h>
@@ -102,6 +103,13 @@ static inline void set_fs(mm_segment_t fs)
flag; \
})
+/*
+ * When dealing with data aborts or instruction traps we may end up with
+ * a tagged userland pointer. Clear the tag to get a sane pointer to pass
+ * on to access_ok(), for instance.
+ */
+#define untagged_addr(addr) sign_extend64(addr, 55)
+
#define access_ok(type, addr, size) __range_ok(addr, size)
#define user_addr_max get_fs
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5ff020f..1e81328 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -433,19 +433,30 @@ void cpu_enable_cache_maint_trap(void *__unused)
config_sctlr_el1(SCTLR_EL1_UCI, 0);
}
+/*
+ * Technically the access_ok() check should be done on a cache line size
+ * granularity, but it's tedious the get the right one (dcache vs. icache,
+ * per-core vs. system wide). Since permission checks are based on pages
+ * anyway, just use PAGE_SIZE instead.
+ */
#define __user_cache_maint(insn, address, res) \
- asm volatile ( \
- "1: " insn ", %1\n" \
- " mov %w0, #0\n" \
- "2:\n" \
- " .pushsection .fixup,\"ax\"\n" \
- " .align 2\n" \
- "3: mov %w0, %w2\n" \
- " b 2b\n" \
- " .popsection\n" \
- _ASM_EXTABLE(1b, 3b) \
- : "=r" (res) \
- : "r" (address), "i" (-EFAULT) )
+ if (!access_ok(VERIFY_READ, \
+ untagged_addr(address & PAGE_MASK), \
+ PAGE_SIZE)) \
+ res = -EFAULT; \
+ else \
+ asm volatile ( \
+ "1: " insn ", %1\n" \
+ " mov %w0, #0\n" \
+ "2:\n" \
+ " .pushsection .fixup,\"ax\"\n" \
+ " .align 2\n" \
+ "3: mov %w0, %w2\n" \
+ " b 2b\n" \
+ " .popsection\n" \
+ _ASM_EXTABLE(1b, 3b) \
+ : "=r" (res) \
+ : "r" (address), "i" (-EFAULT) )
static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
{
--
2.9.0
^ permalink raw reply related
* Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
From: Will Deacon @ 2016-10-19 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu869PXA_cXaL6+uokRCS4EZ8-q6x2xnj4e5DWO28B5jCw@mail.gmail.com>
Hi Ard,
On Mon, Oct 17, 2016 at 08:43:19PM +0100, Ard Biesheuvel wrote:
> On 17 October 2016 at 19:38, Will Deacon <will.deacon@arm.com> wrote:
> > I'm seeing an arm64 build failure with -rc1 and GCC trunk, although I
> > believe that the new compiler behaviour at the heart of the problem
> > has the potential to affect other architectures and other pieces of
> > kernel code relying on dead-code elimination to remove deliberately
> > undefined functions.
> >
> > The failure looks like:
> >
> > | drivers/built-in.o: In function `armada_3700_add_composite_clk':
> > |
> > | linux/drivers/clk/mvebu/armada-37xx-periph.c:351:
> > | undefined reference to `____ilog2_NaN'
> > |
> > | linux/drivers/clk/mvebu/armada-37xx-periph.c:351:(.text+0xc72e0):
> > | relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > | `____ilog2_NaN'
> > |
> > | make: *** [vmlinux] Error 1
> >
> > and if we look at the source for armada_3700_add_composite_clk, we see
> > that this is caused by:
> >
> > int table_size = 0;
> >
> > rate->reg = reg + (u64)rate->reg;
> > for (clkt = rate->table; clkt->div; clkt++)
> > table_size++;
> > rate->width = order_base_2(table_size);
> >
> > order_base_2 calls ilog2, which has the ____ilog2_NaN call:
> >
> > #define ilog2(n) \
> > ( \
> > __builtin_constant_p(n) ? ( \
> > (n) < 1 ? ____ilog2_NaN() : \
> >
> > This is because we're in a curious case where GCC has emitted a
> > special-cased version of armada_3700_add_composite_clk, with table_size
> > effectively constant-folded as 0. Whilst we shouldn't see this in a
> > non-buggy kernel (hence the deliberate call to the undefined function
> > ____ilog2_NaN), it means that the final link fails because we have a
> > ____ilog2_NaN in the code, with a runtime check on table_size.
> >
>
> This is indeed an unintended side effect, but I would not call it
> weird behaviour at all. The code in its current form does not handle
> the case where it could end up passing 0 into order_base_2(), and we
> simply need to handle that case.
The reasons I think it's weird are:
(1) The optimisation doesn't generate better code in this case --
optimising for the table_size == 0 case is uninformed, particularly
as that *cannot* happen at runtime (GCC probably can't tell, due
to things like container_of, but all the clock data is static).
(2) __builtin_constant_p(n) could be interpreted by a developer as
"this code will execute with a constant n at runtime". With this
issue, GCC could (in theory) generate a specialisation for every
possible value of a variable, and return __builtin_constant_p as
true for all of them, which somewhat undermines the point of the
builtin.
> If order_base_2() is not defined for input 0, it should BUG() in that
> case, and the associated __builtin_unreachable() should prevent the
> special version from being emitted. If order_base_2() is defined for input
> 0, it should not invoke ilog2() with that argument, and the problem should
> go away as well.
I don't necessarily think it should BUG() if it's not defined for input
0; things like __ffs don't do that and we'd be introducing conditional
checks for cases that should not happen. The comment above order_base_2
does suggest that ob2(0) should return 0, but it can actually end up
invoking ilog2(-1), which is obviously wrong.
I could update the comment, but that doesn't fix the build issue.
Will
^ permalink raw reply
* [PATCH V5 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Vinod Koul @ 2016-10-19 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
On Fri, Oct 07, 2016 at 01:25:05AM -0400, Sinan Kaya wrote:
> The new version of the HW supports MSI interrupts instead of wired
> interrupts. The MSI interrupts are especially useful for the guest machine
> execution. The wired interrupts usually trap to the hypervisor and then are
> relayed to the actual interrupt.
>
> The MSI interrupts can be directly fed into the interrupt controller.
>
> Adding a new OF compat string (qcom,hidma-1.1) and ACPI string (QCOM8062)
> to distinguish newer HW from the older ones.
I was only able to apply 6 patches in this series. Which tree were these
generated against?
Please rebase rest..
--
~Vinod
^ permalink raw reply
* [PATCH v2] mmc: sunxi: Prevent against null dereference for vmmc
From: Maxime Ripard @ 2016-10-19 13:33 UTC (permalink / raw)
To: linux-arm-kernel
VMMC is an optional regulator, which means that mmc_regulator_get_supply
will only return an error in case of a deferred probe, but not when the
regulator is not set in the DT.
However, the sunxi driver assumes that VMMC is always there, and doesn't
check the value of the regulator pointer before using it, which obviously
leads to a (close to) null pointer dereference.
Add proper checks to prevent that.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
Changes from v1:
- remove redundant error message
---
drivers/mmc/host/sunxi-mmc.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index c0a5c676d0e8..b1d1303389a7 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -822,10 +822,13 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
break;
case MMC_POWER_UP:
- host->ferror = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
- ios->vdd);
- if (host->ferror)
- return;
+ if (!IS_ERR(mmc->supply.vmmc)) {
+ host->ferror = mmc_regulator_set_ocr(mmc,
+ mmc->supply.vmmc,
+ ios->vdd);
+ if (host->ferror)
+ return;
+ }
if (!IS_ERR(mmc->supply.vqmmc)) {
host->ferror = regulator_enable(mmc->supply.vqmmc);
@@ -847,7 +850,9 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
case MMC_POWER_OFF:
dev_dbg(mmc_dev(mmc), "power off!\n");
sunxi_mmc_reset_host(host);
- mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+ if (!IS_ERR(mmc->supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+
if (!IS_ERR(mmc->supply.vqmmc) && host->vqmmc_enabled)
regulator_disable(mmc->supply.vqmmc);
host->vqmmc_enabled = false;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Pavel Labath @ 2016-10-19 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019120714.GM9193@arm.com>
I've send the test suite update to Pratyush via github yesterday. I
presume he will come with a v2 soon. :)
regards,
pavel
On 19 October 2016 at 13:07, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Oct 14, 2016 at 08:45:43AM +0530, Pratyush Anand wrote:
>>
>>
>> On Thursday 13 October 2016 10:33 PM, Pavel Labath wrote:
>> >>I think, its easier to go with your implementation. So, I have taken
>> >>> your patch and updated my perf/upstream_arm64_devel branch. May be you
>> >>> can give it a test for your test cases.
>> >I've checked out the new version of your branch, and it works great.
>> >I'll write a patch with additional test cases to go on top of your
>> >branch, as the tests there do not capture the bug I was fixing.
>>
>> That would be great. We can send them all together as V2.
>
> Did you send a v2? I've been holding off reviewing this, but I just want
> to make sure I didn't miss the update.
>
> Cheers,
>
> Will
^ permalink raw reply
* [PATCH] exynos-drm: Fix error messages to print flags and size
From: Inki Dae @ 2016-10-19 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57F64D0B.5050506@math.uni-bielefeld.de>
2016-10-06 22:09 GMT+09:00 Tobias Jakobi <tjakobi@math.uni-bielefeld.de>:
> Hello,
>
> I think this patch was never picked up. So just a short 'ping' from my side.
>
Oops. one I missed. Will pick it up soon.
Thanks,
Inki Dae
> With best wishes,
> Tobias
>
>
> Shuah Khan wrote:
>> Fix exynos_drm_gem_create() error messages to include flags and size when
>> flags and size are invalid.
>>
>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index cdf9f1a..4c4cb0e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -231,12 +231,12 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct drm_device *dev,
>> int ret;
>>
>> if (flags & ~(EXYNOS_BO_MASK)) {
>> - DRM_ERROR("invalid flags.\n");
>> + DRM_ERROR("invalid GEM buffer flags: %u\n", flags);
>> return ERR_PTR(-EINVAL);
>> }
>>
>> if (!size) {
>> - DRM_ERROR("invalid size.\n");
>> + DRM_ERROR("invalid GEM buffer size: %lu\n", size);
>> return ERR_PTR(-EINVAL);
>> }
>>
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] dmaengine: qcom_hidma: cleanup sysfs entries during remove
From: Vinod Koul @ 2016-10-19 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475796189-26553-1-git-send-email-okaya@codeaurora.org>
On Thu, Oct 06, 2016 at 07:23:09PM -0400, Sinan Kaya wrote:
> The 4.8-rc8 kernel is printing duplicate file entry warnings while removing
> the HIDMA object. This is caused by stale sysfs entries remaining from the
> previous execution.
>
> _sysfs_warn_dup+0x5c/0x78
> sysfs_add_file_mode_ns+0x13c/0x1c0
> sysfs_create_file_ns+0x2c/0x40
> device_create_file+0x54/0xa0
> hidma_probe+0x7c8/0x808
>
> Create hidma_sysfs_init and hidma_sysfs_uninit functions and call them from
> the probe and remove path. To do proper clean up, adding the attrs object
> to the device data structure to keep it around until remove call is made.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/dma/qcom/hidma.c | 31 +++++++++++++++++++++++++------
> drivers/dma/qcom/hidma.h | 3 +++
> 2 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index f4fe4ee..414ea12 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -578,8 +578,17 @@ static ssize_t hidma_show_values(struct device *dev,
> return strlen(buf);
> }
>
> -static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
> - int mode)
> +static int hidma_sysfs_uninit(struct hidma_dev *dev)
> +{
> + if (!dev->chid_attrs)
> + return -ENOMEM;
why is this check required? Probe would fail in init case right.
Second returning error doesnt help as you are calling this from remove and
return is not checked so redundant!
--
~Vinod
^ permalink raw reply
* [PATCH -next] dmaengine: st_fdma: Fix the error return code in st_fdma_probe()
From: Wei Yongjun @ 2016-10-19 13:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
In case of error, the function st_slim_rproc_alloc() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/dma/st_fdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 515e1d4..a66a57b 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -802,7 +802,7 @@ static int st_fdma_probe(struct platform_device *pdev)
}
fdev->slim_rproc = st_slim_rproc_alloc(pdev, fdev->fw_name);
- if (!fdev->slim_rproc) {
+ if (IS_ERR(fdev->slim_rproc)) {
ret = PTR_ERR(fdev->slim_rproc);
dev_err(&pdev->dev, "slim_rproc_alloc failed (%d)\n", ret);
goto err;
^ permalink raw reply related
* [PATCH] dmaengine: qcom_hidma: remove useless debugfs file removal
From: Vinod Koul @ 2016-10-19 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475792489-1415-1-git-send-email-okaya@codeaurora.org>
On Thu, Oct 06, 2016 at 06:21:29PM -0400, Sinan Kaya wrote:
> Since 'commit acc29fb8f792 ("debugfs: ->d_parent is never NULL or
> negative")', HIDMA object removal is no longer working. This is due to
> redundant debugfs remove call in hidma_debug_uninit.
>
> debugfs_remove_recursive(dmadev->debugfs);
> debugfs_remove_recursive(dmadev->stats);
>
> The first remove is for the directory. Second remove is for the file under
> the directory. The directory remove makes file remove invalid.
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
> [<ffff00000889f480>] down_write+0x18/0x68
> [<ffff00000831c220>] debugfs_remove_recursive+0x50/0x1c0
> [<ffff00000848e0a8>] hidma_debug_uninit+0x20/0x30
> [<ffff00000848c5d8>] hidma_remove+0x48/0x98
> [<ffff000008511b6c>] platform_drv_remove+0x24/0x68
> [<ffff00000850fac8>] __device_release_driver+0x80/0x118
> [<ffff00000850fb84>] device_release_driver+0x24/0x38
> [<ffff00000850e928>] unbind_store+0xe8/0x110
> [<ffff00000850dd30>] drv_attr_store+0x20/0x30
> [<ffff000008253a48>] sysfs_kf_write+0x48/0x58
> [<ffff000008252dd8>] kernfs_fop_write+0xb0/0x1d8
> [<ffff0000081dab3c>] __vfs_write+0x1c/0x110
> [<ffff0000081db940>] vfs_write+0xa0/0x1b8
> [<ffff0000081dcd34>] SyS_write+0x44/0xa0
> [<ffff000008082ef0>] el0_svc_naked+0x24/0x28
>
> Removing the second line.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] mmc: sunxi: Prevent against null dereference for vmmc
From: Ulf Hansson @ 2016-10-19 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019123629.14525-1-maxime.ripard@free-electrons.com>
On 19 October 2016 at 14:36, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> VMMC is an optional regulator, which means that mmc_regulator_get_supply
> will only return an error in case of a deferred probe, but not when the
> regulator is not set in the DT.
>
> However, the sunxi driver assumes that VMMC is always there, and doesn't
> check the value of the regulator pointer before using it, which obviously
> leads to a (close to) null pointer dereference.
>
> Add proper checks to prevent that.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/mmc/host/sunxi-mmc.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index c0a5c676d0e8..45a051e7d650 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -822,10 +822,16 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> break;
>
> case MMC_POWER_UP:
> - host->ferror = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
> - ios->vdd);
> - if (host->ferror)
> - return;
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + host->ferror = mmc_regulator_set_ocr(mmc,
> + mmc->supply.vmmc,
> + ios->vdd);
> + if (host->ferror) {
> + dev_err(mmc_dev(mmc),
> + "failed to enable vmmc\n");
The print here is already taken care of by mmc_regulator_set_ocr()
> + return;
> + }
> + }
>
> if (!IS_ERR(mmc->supply.vqmmc)) {
> host->ferror = regulator_enable(mmc->supply.vqmmc);
> @@ -847,7 +853,9 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> case MMC_POWER_OFF:
> dev_dbg(mmc_dev(mmc), "power off!\n");
> sunxi_mmc_reset_host(host);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> + if (!IS_ERR(mmc->supply.vmmc))
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> +
> if (!IS_ERR(mmc->supply.vqmmc) && host->vqmmc_enabled)
> regulator_disable(mmc->supply.vqmmc);
> host->vqmmc_enabled = false;
> --
> 2.9.3
>
Otherwise this looks good to me!
Kind regards
Uffe
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: fix uninitialized variable access
From: Vinod Koul @ 2016-10-19 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019120927.3251235-1-arnd@arndb.de>
On Wed, Oct 19, 2016 at 02:09:10PM +0200, Arnd Bergmann wrote:
> The newly added st_fdma driver introduces a build warning for
> allmodconfig when we add '-Wmaybe-uninitialized':
>
> drivers/dma/st_fdma.c: In function 'st_fdma_probe':
> drivers/dma/st_fdma.c:777:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> The warning is correct, though this can't happen in practice
> as the check is redundant (we don't get to this function if
> the pointer is NULL). Even if the function were called with a
> NULL of_node, the check is not needed because of_property_read_u32
> can deal with a NULL argument by returning an error.
>
> Removing the unnecessary code simplifies the function and avoids
> the condition that we get the warning for.
Applied, thanks
--
~Vinod
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Mark Rutland @ 2016-10-19 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019094227.GB1461@amd>
On Wed, Oct 19, 2016 at 11:42:27AM +0200, Pavel Machek wrote:
> On Tue 2016-10-18 11:45:39, Mark Rutland wrote:
> Either the lowlevel suspend code is stable and bug free, and then
> having that code is not a problem.
This ignores the cost of maintaining that code. Kernel APIs change over
time, and no code is ever completely stable, even if at one point in
time it happens to be bug-free.
> Or the lowlevel suspend code is complex enough to contain some bugs,
> and in such case it is better to debug and update it with kernel.
It is better for that code to be debuggable and updateable. That is not
the same as being part of the kernel.
> > ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
> > can use and build atop of. It's open source (three-clause BSD with DCO),
> > and accepts board ports. You can have a completely open stack,
> > regardless of whether part of that stack is firmware.
>
> If something is called "Trusted", it is not trustworthy.
Certainly we shouldn't blindly trust anything.
I object to ATF being called "not trustworthy"; the aims of the project
are certainly not dishonest.
> BSD is better than closed source, but it also means that you will not
> get the sources from your hw vendor.
That depends on your hardware vendor, as always. There are a number of
platform ports in the upstream ATF repo.
It's also worth considering that a number of 32-bit arm parts require
closed firmware (as far as I can tell, including the N900).
> Being separate module means it will be never updated.
That's certainly not true as a blanket statement. The Juno FW (including
an open-source UEFI!) is periodically updated, and mechanisms like
UpdateCapsule() should make this easier in future.
> Being separate module means it will be hard to debug, in area where
> debugging is already pretty hard.
It can be harder, yes. There are also benefits, given the same code can
be tested on a variety of platforms.
> Can it do advanced stuff like deep powersaving on N900 idle?
Sorry, I don't know precisely what you're referring to.
It can do things like shutting down entire CPU clusters (and IIRC
associated interconnect) when all relevant CPUs are idle, if that's what
you mean.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 5/9] of: Add vendor prefix for Netron DY
From: Rob Herring @ 2016-10-19 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019123927.GE16158@ulmo.ba.sec>
On Wed, Oct 19, 2016 at 7:39 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Sep 06, 2016 at 04:46:16PM +0200, Maxime Ripard wrote:
>> Netron DY is a brand of LCD panels found on SBCs and tablets.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>
> Hi Rob,
>
> care to give this your Acked-by?
It helps to send to the DT list.
Acked-by: Rob Herring <robh@kernel.org>
>
> Thanks,
> Thierry
>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 1992aa97d45a..9c1ab3c1132b 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -176,6 +176,7 @@ nec NEC LCD Technologies, Ltd.
>> neonode Neonode Inc.
>> netgear NETGEAR
>> netlogic Broadcom Corporation (formerly NetLogic Microsystems)
>> +netron-dy Netron DY
>> netxeon Shenzhen Netxeon Technology CO., LTD
>> newhaven Newhaven Display International
>> nintendo Nintendo
>> --
>> 2.9.3
>>
^ permalink raw reply
* [RFC PATCH 1/2] efi: libstub: preserve .debug sections after absolute relocation check
From: Cohen, Eugene @ 2016-10-19 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476877232-24308-2-git-send-email-ard.biesheuvel@linaro.org>
I was literally just looking at this. I originally commented out the removal of debug (which I though was really annoying) but ran into the absolute relocations warning for symbols that it need not apply to. Your two-pass solution is a nice one.
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> Sent: Wednesday, October 19, 2016 5:41 AM
> To: linux-efi at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Cc: mark.rutland at arm.com; leif.lindholm at linaro.org; Cohen, Eugene
> <eugene@hp.com>; matt at codeblueprint.co.uk; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>
> Subject: [RFC PATCH 1/2] efi: libstub: preserve .debug sections after absolute
> relocation check
>
> The build commands for the ARM and arm64 EFI stubs strips the .debug
> sections and other sections that my legally contain absolute relocations,
> in order to inspect the remaining sections for the presence of such
> relocations.
>
> This leaves us without debugging symbols in the stub for no good reason,
> given that these sections are omitted from the kernel binary, and that
> these relocations are thus only interpreted by the debugger.
>
> So if the relocation check succeeds, invoke objcopy again, but this time,
> leave the .debug sections in place. Note that these sections may refer
> to ksymtab/kcrctab contents, so leave those in place as well.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Eugene Cohen <eugene@hp.com>
> ---
> drivers/firmware/efi/libstub/Makefile | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/Makefile
> b/drivers/firmware/efi/libstub/Makefile
> index c06945160a41..66584f173123 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -60,7 +60,7 @@ CFLAGS_arm64-stub.o := -
> DTEXT_OFFSET=$(TEXT_OFFSET)
> extra-$(CONFIG_EFI_ARMSTUB) := $(lib-y)
> lib-$(CONFIG_EFI_ARMSTUB) := $(patsubst %.o,%.stub.o,$(lib-y))
>
> -STUBCOPY_FLAGS-y := -R .debug* -R *ksymtab* -R *kcrctab*
> +STUBCOPY_RM := -R .debug* -R *ksymtab* -R *kcrctab*
> STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
> --prefix-symbols=__efistub_
> STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
> @@ -68,11 +68,20 @@ STUBCOPY_RELOC-$(CONFIG_ARM64) :=
> R_AARCH64_ABS
> $(obj)/%.stub.o: $(obj)/%.o FORCE
> $(call if_changed,stubcopy)
>
> +#
> +# This calls objcopy twice: the first time it includes STUBCOPY_RM, and inspects
> +# the result to ensure that the actual code itself does not contain any absolute
> +# references. If this succeeds, the objcopy is performed a second time, but this
> +# time the .debug and other sections are retained, given that we know that the
> +# absolute relocations they may contain are harmless.
> +#
> quiet_cmd_stubcopy = STUBCPY $@
> - cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; then \
> - $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y) \
> - && (echo >&2 "$@: absolute symbol references not allowed in
> the EFI stub"; \
> - rm -f $@; /bin/false); else /bin/false; fi
> + cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $(STUBCOPY_RM) $<
> $@; \
> + then if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); \
> + then (echo >&2 "$@: absolute symbol references not allowed
> in the EFI stub"; \
> + rm -f $@; /bin/false); \
> + else $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; fi \
> + else /bin/false; fi
>
> #
> # ARM discards the .data section because it disallows r/w data in the
> --
> 2.7.4
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: fix uninitialized variable access
From: Peter Griffin @ 2016-10-19 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019120927.3251235-1-arnd@arndb.de>
Hi Arnd,
On Wed, 19 Oct 2016, Arnd Bergmann wrote:
> The newly added st_fdma driver introduces a build warning for
> allmodconfig when we add '-Wmaybe-uninitialized':
>
> drivers/dma/st_fdma.c: In function 'st_fdma_probe':
> drivers/dma/st_fdma.c:777:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> The warning is correct, though this can't happen in practice
> as the check is redundant (we don't get to this function if
> the pointer is NULL). Even if the function were called with a
> NULL of_node, the check is not needed because of_property_read_u32
> can deal with a NULL argument by returning an error.
>
> Removing the unnecessary code simplifies the function and avoids
> the condition that we get the warning for.
>
> Fixes: 6b4cd727eaf1 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Peter Griffin <peter.griffin@linaro.org>
regards,
Peter.
^ permalink raw reply
* [PATCH v5 5/5] ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes
From: Neil Armstrong @ 2016-10-19 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476881472-13055-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 48 +++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 28e218d..ff1975e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -74,6 +74,28 @@
};
};
+ scpi {
+ compatible = "amlogic,meson-gxbb-scpi";
+ mboxes = <&mailbox 1 &mailbox 2>;
+ shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi_dvfs: scpi_clocks at 0 {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <1>;
+ clock-indices = <0>;
+ clock-output-names = "vcpu";
+ };
+ };
+
+ scpi_sensors: sensors {
+ compatible = "arm,scpi-sensors";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+
soc {
usb0_phy: phy at c0000000 {
compatible = "amlogic,meson-gxbb-usb2-phy";
@@ -101,6 +123,16 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0xc8000000 0x14000>;
+
+ cpu_scp_lpri: scp-shmem at 0 {
+ compatible = "amlogic,meson-gxbb-scp-shmem";
+ reg = <0x13000 0x400>;
+ };
+
+ cpu_scp_hpri: scp-shmem at 200 {
+ compatible = "amlogic,meson-gxbb-scp-shmem";
+ reg = <0x13400 0x400>;
+ };
};
usb0: usb at c9000000 {
@@ -143,6 +175,22 @@
};
};
+&cpu0 {
+ clocks = <&scpi_dvfs 0>;
+};
+
+&cpu1 {
+ clocks = <&scpi_dvfs 0>;
+};
+
+&cpu2 {
+ clocks = <&scpi_dvfs 0>;
+};
+
+&cpu3 {
+ clocks = <&scpi_dvfs 0>;
+};
+
&cbus {
reset: reset-controller at 4404 {
compatible = "amlogic,meson-gxbb-reset";
--
1.9.1
^ permalink raw reply related
* [PATCH v5 4/5] ARM64: dts: meson-gxbb: Add SRAM node
From: Neil Armstrong @ 2016-10-19 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476881472-13055-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index aad639a..28e218d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -94,6 +94,15 @@
status = "disabled";
};
+ sram: sram at c8000000 {
+ compatible = "amlogic,meson-gxbb-sram", "mmio-sram";
+ reg = <0x0 0xc8000000 0x0 0x14000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0xc8000000 0x14000>;
+ };
+
usb0: usb at c9000000 {
compatible = "amlogic,meson-gxbb-usb", "snps,dwc2";
reg = <0x0 0xc9000000 0x0 0x40000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 3/5] scpi: Add support for Legacy match table for Amlogic GXBB SoC
From: Neil Armstrong @ 2016-10-19 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476881472-13055-1-git-send-email-narmstrong@baylibre.com>
Add new DT match table to setup the is_legacy boolean value across
the scpi functions.
Add the Amlogic GXBB SoC compatible for platform and as legacy match entry.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/firmware/arm_scpi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 9022336..75b60c4 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -871,6 +871,11 @@ static int scpi_alloc_xfer_list(struct device *dev, struct scpi_chan *ch)
return 0;
}
+static const struct of_device_id legacy_scpi_of_match[] = {
+ {.compatible = "amlogic,meson-gxbb-scpi"},
+ {},
+};
+
static int scpi_probe(struct platform_device *pdev)
{
int count, idx, ret;
@@ -883,6 +888,9 @@ static int scpi_probe(struct platform_device *pdev)
if (!scpi_info)
return -ENOMEM;
+ if (of_match_device(legacy_scpi_of_match, &pdev->dev))
+ scpi_info->is_legacy = true;
+
count = of_count_phandle_with_args(np, "mboxes", "#mbox-cells");
if (count < 0) {
dev_err(dev, "no mboxes property in '%s'\n", np->full_name);
@@ -984,6 +992,7 @@ static int scpi_probe(struct platform_device *pdev)
static const struct of_device_id scpi_of_match[] = {
{.compatible = "arm,scpi"},
+ {.compatible = "amlogic,meson-gxbb-scpi"},
{},
};
--
1.9.1
^ permalink raw reply related
* [PATCH v5 2/5] scpi: Do not fail if get_capabilities is not implemented
From: Neil Armstrong @ 2016-10-19 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476881472-13055-1-git-send-email-narmstrong@baylibre.com>
On Amlogic SCPI legacy implementation, the GET_CAPABILITIES is not
supported, failover by using 0.0.0 version.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/firmware/arm_scpi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 2982bc7..9022336 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -783,6 +783,10 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
info->protocol_version = le32_to_cpu(caps.protocol_version);
info->firmware_version = le32_to_cpu(caps.platform_version);
}
+ /* Ignore error if not implemented */
+ if (scpi_info->is_legacy && ret == -EOPNOTSUPP)
+ return 0;
+
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v5 1/5] scpi: Add alternative legacy structures, functions and macros
From: Neil Armstrong @ 2016-10-19 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476881472-13055-1-git-send-email-narmstrong@baylibre.com>
This patch adds support for the Legacy SCPI protocol in early JUNO versions and
shipped Amlogic ARMv8 based SoCs. Some Rockchip SoC are also known to use this
version of protocol with extended vendor commands.
In order to support the legacy SCPI protocol variant, add back the structures
and macros that varies against the final specification.
Then add indirection table for legacy commands.
Finally Add bitmap field for channel selection since the Legacy protocol mandates to
send a selected subset of the commands on the high priority channel instead of the
low priority channel.
The message sending path differs from the final SCPI procotocol because the
Amlogic SCP firmware always reply 1 instead of a special value containing the command
byte and replied rx data length.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/firmware/arm_scpi.c | 192 +++++++++++++++++++++++++++++++++++++++-----
1 file changed, 174 insertions(+), 18 deletions(-)
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 21542a3..2982bc7 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -50,13 +50,20 @@
#define CMD_TOKEN_ID_MASK 0xff
#define CMD_DATA_SIZE_SHIFT 16
#define CMD_DATA_SIZE_MASK 0x1ff
+#define CMD_LEGACY_DATA_SIZE_SHIFT 20
+#define CMD_LEGACY_DATA_SIZE_MASK 0x1ff
#define PACK_SCPI_CMD(cmd_id, tx_sz) \
((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) | \
(((tx_sz) & CMD_DATA_SIZE_MASK) << CMD_DATA_SIZE_SHIFT))
#define ADD_SCPI_TOKEN(cmd, token) \
((cmd) |= (((token) & CMD_TOKEN_ID_MASK) << CMD_TOKEN_ID_SHIFT))
+#define PACK_LEGACY_SCPI_CMD(cmd_id, tx_sz) \
+ ((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) | \
+ (((tx_sz) & CMD_LEGACY_DATA_SIZE_MASK) << CMD_LEGACY_DATA_SIZE_SHIFT))
#define CMD_SIZE(cmd) (((cmd) >> CMD_DATA_SIZE_SHIFT) & CMD_DATA_SIZE_MASK)
+#define CMD_LEGACY_SIZE(cmd) (((cmd) >> CMD_LEGACY_DATA_SIZE_SHIFT) & \
+ CMD_LEGACY_DATA_SIZE_MASK)
#define CMD_UNIQ_MASK (CMD_TOKEN_ID_MASK << CMD_TOKEN_ID_SHIFT | CMD_ID_MASK)
#define CMD_XTRACT_UNIQ(cmd) ((cmd) & CMD_UNIQ_MASK)
@@ -133,7 +140,62 @@ enum scpi_std_cmd {
SCPI_CMD_COUNT
};
-/* List of all commands used by this driver, used as indices */
+/* SCPI Legacy Commands */
+enum legacy_scpi_std_cmd {
+ LEGACY_SCPI_CMD_INVALID = 0x00,
+ LEGACY_SCPI_CMD_SCPI_READY = 0x01,
+ LEGACY_SCPI_CMD_SCPI_CAPABILITIES = 0x02,
+ LEGACY_SCPI_CMD_EVENT = 0x03,
+ LEGACY_SCPI_CMD_SET_CSS_PWR_STATE = 0x04,
+ LEGACY_SCPI_CMD_GET_CSS_PWR_STATE = 0x05,
+ LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT = 0x06,
+ LEGACY_SCPI_CMD_GET_PWR_STATE_STAT = 0x07,
+ LEGACY_SCPI_CMD_SYS_PWR_STATE = 0x08,
+ LEGACY_SCPI_CMD_L2_READY = 0x09,
+ LEGACY_SCPI_CMD_SET_AP_TIMER = 0x0a,
+ LEGACY_SCPI_CMD_CANCEL_AP_TIME = 0x0b,
+ LEGACY_SCPI_CMD_DVFS_CAPABILITIES = 0x0c,
+ LEGACY_SCPI_CMD_GET_DVFS_INFO = 0x0d,
+ LEGACY_SCPI_CMD_SET_DVFS = 0x0e,
+ LEGACY_SCPI_CMD_GET_DVFS = 0x0f,
+ LEGACY_SCPI_CMD_GET_DVFS_STAT = 0x10,
+ LEGACY_SCPI_CMD_SET_RTC = 0x11,
+ LEGACY_SCPI_CMD_GET_RTC = 0x12,
+ LEGACY_SCPI_CMD_CLOCK_CAPABILITIES = 0x13,
+ LEGACY_SCPI_CMD_SET_CLOCK_INDEX = 0x14,
+ LEGACY_SCPI_CMD_SET_CLOCK_VALUE = 0x15,
+ LEGACY_SCPI_CMD_GET_CLOCK_VALUE = 0x16,
+ LEGACY_SCPI_CMD_PSU_CAPABILITIES = 0x17,
+ LEGACY_SCPI_CMD_SET_PSU = 0x18,
+ LEGACY_SCPI_CMD_GET_PSU = 0x19,
+ LEGACY_SCPI_CMD_SENSOR_CAPABILITIES = 0x1a,
+ LEGACY_SCPI_CMD_SENSOR_INFO = 0x1b,
+ LEGACY_SCPI_CMD_SENSOR_VALUE = 0x1c,
+ LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC = 0x1d,
+ LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS = 0x1e,
+ LEGACY_SCPI_CMD_SENSOR_ASYNC_VALUE = 0x1f,
+ LEGACY_SCPI_CMD_COUNT
+};
+
+/* List all commands that are required to go through the high priority link */
+static int legacy_hpriority_cmds[] = {
+ LEGACY_SCPI_CMD_GET_CSS_PWR_STATE,
+ LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT,
+ LEGACY_SCPI_CMD_GET_PWR_STATE_STAT,
+ LEGACY_SCPI_CMD_SET_DVFS,
+ LEGACY_SCPI_CMD_GET_DVFS,
+ LEGACY_SCPI_CMD_SET_RTC,
+ LEGACY_SCPI_CMD_GET_RTC,
+ LEGACY_SCPI_CMD_SET_CLOCK_INDEX,
+ LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+ LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+ LEGACY_SCPI_CMD_SET_PSU,
+ LEGACY_SCPI_CMD_GET_PSU,
+ LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC,
+ LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS,
+};
+
+/* List all commands used by this driver, used as indexes */
enum scpi_drv_cmds {
CMD_SCPI_CAPABILITIES = 0,
CMD_GET_CLOCK_INFO,
@@ -165,6 +227,21 @@ enum scpi_drv_cmds {
SCPI_CMD_GET_DEVICE_PWR_STATE,
};
+static int scpi_legacy_commands[CMD_MAX_COUNT] = {
+ LEGACY_SCPI_CMD_SCPI_CAPABILITIES,
+ -1, /* GET_CLOCK_INFO */
+ LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+ LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+ LEGACY_SCPI_CMD_GET_DVFS,
+ LEGACY_SCPI_CMD_SET_DVFS,
+ LEGACY_SCPI_CMD_GET_DVFS_INFO,
+ LEGACY_SCPI_CMD_SENSOR_CAPABILITIES,
+ LEGACY_SCPI_CMD_SENSOR_INFO,
+ LEGACY_SCPI_CMD_SENSOR_VALUE,
+ -1, /* SET_DEVICE_PWR_STATE */
+ -1, /* GET_DEVICE_PWR_STATE */
+};
+
struct scpi_xfer {
u32 slot; /* has to be first element */
u32 cmd;
@@ -193,8 +270,10 @@ struct scpi_chan {
struct scpi_drvinfo {
u32 protocol_version;
u32 firmware_version;
+ bool is_legacy;
int num_chans;
int *commands;
+ DECLARE_BITMAP(cmd_priority, LEGACY_SCPI_CMD_COUNT);
atomic_t next_chan;
struct scpi_ops *scpi_ops;
struct scpi_chan *channels;
@@ -211,6 +290,11 @@ struct scpi_shared_mem {
u8 payload[0];
} __packed;
+struct legacy_scpi_shared_mem {
+ __le32 status;
+ u8 payload[0];
+} __packed;
+
struct scp_capabilities {
__le32 protocol_version;
__le32 event_version;
@@ -236,6 +320,12 @@ struct clk_set_value {
__le32 rate;
} __packed;
+struct legacy_clk_set_value {
+ __le32 rate;
+ __le16 id;
+ __le16 reserved;
+} __packed;
+
struct dvfs_info {
__le32 header;
struct {
@@ -307,19 +397,43 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
return;
}
- list_for_each_entry(t, &ch->rx_pending, node)
- if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
- list_del(&t->node);
- match = t;
- break;
- }
+ /* Command type is not replied by the SCP Firmware in legacy Mode
+ * We should consider that command is the head of pending RX commands
+ * if the list is not empty. In TX only mode, the list would be empty.
+ */
+ if (scpi_info->is_legacy) {
+ match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
+ node);
+ list_del(&match->node);
+ } else {
+ list_for_each_entry(t, &ch->rx_pending, node)
+ if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
+ list_del(&t->node);
+ match = t;
+ break;
+ }
+ }
/* check if wait_for_completion is in progress or timed-out */
if (match && !completion_done(&match->done)) {
- struct scpi_shared_mem *mem = ch->rx_payload;
- unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
+ unsigned int len;
+
+ if (scpi_info->is_legacy) {
+ struct legacy_scpi_shared_mem *mem = ch->rx_payload;
+
+ /* RX Length is not replied by the legacy Firmware */
+ len = match->rx_len;
+
+ match->status = le32_to_cpu(mem->status);
+ memcpy_fromio(match->rx_buf, mem->payload, len);
+ } else {
+ struct scpi_shared_mem *mem = ch->rx_payload;
+
+ len = min(match->rx_len, CMD_SIZE(cmd));
+
+ match->status = le32_to_cpu(mem->status);
+ memcpy_fromio(match->rx_buf, mem->payload, len);
+ }
- match->status = le32_to_cpu(mem->status);
- memcpy_fromio(match->rx_buf, mem->payload, len);
if (match->rx_len > len)
memset(match->rx_buf + len, 0, match->rx_len - len);
complete(&match->done);
@@ -331,7 +445,10 @@ static void scpi_handle_remote_msg(struct mbox_client *c, void *msg)
{
struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
struct scpi_shared_mem *mem = ch->rx_payload;
- u32 cmd = le32_to_cpu(mem->command);
+ u32 cmd = 0;
+
+ if (!scpi_info->is_legacy)
+ cmd = le32_to_cpu(mem->command);
scpi_process_cmd(ch, cmd);
}
@@ -343,8 +460,13 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
- if (t->tx_buf)
- memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+ if (t->tx_buf) {
+ if (scpi_info->is_legacy)
+ memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
+ else
+ memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+ }
+
if (t->rx_buf) {
if (!(++ch->token))
++ch->token;
@@ -353,7 +475,9 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
list_add_tail(&t->node, &ch->rx_pending);
spin_unlock_irqrestore(&ch->rx_lock, flags);
}
- mem->command = cpu_to_le32(t->cmd);
+
+ if (!scpi_info->is_legacy)
+ mem->command = cpu_to_le32(t->cmd);
}
static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
@@ -392,15 +516,24 @@ static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
cmd = scpi_info->commands[idx];
- chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
+ if (scpi_info->is_legacy)
+ chan = test_bit(cmd, scpi_info->cmd_priority) ? 1 : 0;
+ else
+ chan = atomic_inc_return(&scpi_info->next_chan) %
+ scpi_info->num_chans;
scpi_chan = scpi_info->channels + chan;
msg = get_scpi_xfer(scpi_chan);
if (!msg)
return -ENOMEM;
- msg->slot = BIT(SCPI_SLOT);
- msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+ if (scpi_info->is_legacy) {
+ msg->cmd = PACK_LEGACY_SCPI_CMD(cmd, tx_len);
+ msg->slot = msg->cmd;
+ } else {
+ msg->slot = BIT(SCPI_SLOT);
+ msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+ }
msg->tx_buf = tx_buf;
msg->tx_len = tx_len;
msg->rx_buf = rx_buf;
@@ -470,6 +603,18 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
&stat, sizeof(stat));
}
+static int legacy_scpi_clk_set_val(u16 clk_id, unsigned long rate)
+{
+ int stat;
+ struct legacy_clk_set_value clk = {
+ .id = cpu_to_le16(clk_id),
+ .rate = cpu_to_le32(rate)
+ };
+
+ return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+ &stat, sizeof(stat));
+}
+
static int scpi_dvfs_get_idx(u8 domain)
{
int ret;
@@ -800,6 +945,17 @@ static int scpi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, scpi_info);
+ if (scpi_info->is_legacy) {
+ /* Replace with legacy variants */
+ scpi_ops.clk_set_val = legacy_scpi_clk_set_val;
+ scpi_info->commands = scpi_legacy_commands;
+
+ /* Fill priority bitmap */
+ for (idx = 0; idx < ARRAY_SIZE(legacy_hpriority_cmds); idx++)
+ set_bit(legacy_hpriority_cmds[idx],
+ scpi_info->cmd_priority);
+ }
+
ret = scpi_init_versions(scpi_info);
if (ret) {
dev_err(dev, "incorrect or no SCP firmware found\n");
--
1.9.1
^ permalink raw reply related
* [PATCH v5 0/5] Add support for legacy SCPI protocol
From: Neil Armstrong @ 2016-10-19 12:51 UTC (permalink / raw)
To: linux-arm-kernel
This patchset aims to support the legacy SCPI firmware implementation that was
delivered as early technology preview for the JUNO platform.
Finally a stable, maintained and public implementation for the SCPI protocol
has been upstreamed part of the JUNO support and it is the recommended way
of implementing SCP communication on ARMv8 platforms.
The Amlogic GXBB platform is using this legacy protocol, as the RK3368 & RK3399
platforms. This patchset will only add support for Amlogic GXBB SoC.
This patchset add support for the legacy protocol in the arm_scpi.c file,
avoiding code duplication.
This patchset is rebased against scpi-updates/for-next from [2] and with
already merged patches [3], [4] and [5] and ommited in this patchset.
Last RFC discution thread can be found at : https://lkml.org/lkml/2016/8/9/210
Changes since v4 at : http://lkml.kernel.org/r/1475652814-30619-1-git-send-email-narmstrong at baylibre.com
- Removed legacy locking scheme
- Removed cmd copy back after token insert
- Various cleanups
Changes since v3 at : http://lkml.kernel.org/r/1473262477-18045-1-git-send-email-narmstrong at baylibre.com
- Changed back author to Sudeep Holla for first patch
- Merged legacy functions to scpi_send_message, tx_prepare and handle_remote_message
- Added legacy locking scheme
- Merged back legacy_scpi_sensor_get_value into scpi_sensor_get_value
- Rebased on linux-next-20161004 with patchset [1]
Changes since v2 at : http://lkml.kernel.org/r/1471952816-30877-1-git-send-email-narmstrong at baylibre.com
- Added command indirection table and use it in each commands
- Added bitmap for high priority commands
- Cleaned up legacy tx_prepare/handle_message to align to standard functions
- Dropped legacy_scpi_ops
Changes since v1 at : http://lkml.kernel.org/r/1471515066-3626-1-git-send-email-narmstrong at baylibre.com
- Dropped vendor_send_message and rockchip vendor mechanism patches
- Merged alternate functions into main functions using is_legacy boolean
- Added DT match table to set is_legacy to true
- Kept alternate scpi_ops structure for legacy
[1] http://lkml.kernel.org/r/1475595430-30075-1-git-send-email-narmstrong at baylibre.com
[2] git.kernel.org/sudeep.holla/linux
[3] scpi: Add cmd indirection table to prepare for legacy commands
[4] scpi: grow MAX_DVFS_OPPS to 16 entries
[5] dt-bindings: Add support for Amlogic GXBB SCPI Interface
Neil Armstrong (5):
scpi: Add alternative legacy structures, functions and macros
scpi: Do not fail if get_capabilities is not implemented
scpi: Add support for Legacy match table for Amlogic GXBB SoC
ARM64: dts: meson-gxbb: Add SRAM node
ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 57 ++++++++
drivers/firmware/arm_scpi.c | 206 +++++++++++++++++++++++++---
2 files changed, 245 insertions(+), 18 deletions(-)
--
1.9.1
^ 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