* [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
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Will Deacon @ 2016-10-19 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5cf1acbf9c42cc99e5cc0dacb50b7a92c3bd0feb.1476702234.git.robin.murphy@arm.com>
On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
> We now delay installing our per-bus iommu_ops until we know an SMMU has
> successfully probed, as they don't serve much purpose beforehand, and
> doing so also avoids fights between multiple IOMMU drivers in a single
> kernel. However, the upshot of passing the return value of bus_set_iommu()
> back from our probe function is that if there happens to be more than
> one SMMUv3 device in a system, the second and subsequent probes will
> wind up returning -EBUSY to the driver core and getting torn down again.
>
> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
> 1. The bus already has iommu_ops installed
> 2. One of the add_device callbacks from the initial notifier failed
> 3. Allocating or installing the notifier itself failed
>
> The first two are down to devices other than the SMMU in question, so
> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
> indicative of the kind of catastrophic system failure which isn't going
> to get much further anyway. Consequently, there is little harm in
> ignoring the return value either way.
>
> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 15c01c3cd540..74fbef384deb 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> #ifdef CONFIG_PCI
> pci_request_acs();
> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> - if (ret)
> - return ret;
> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> #endif
> #ifdef CONFIG_ARM_AMBA
> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> - if (ret)
> - return ret;
> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> #endif
> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> + return 0;
In which case, we should probably add an iommu_present check, like we
have for the v2 driver.
Will
^ permalink raw reply
* [PATCH] ARM: mm: add ARM_L1_CACHE_SHIFT_7 for UniPhier outer cache
From: Masahiro Yamada @ 2016-10-19 12:39 UTC (permalink / raw)
To: linux-arm-kernel
The UniPhier outer cache (arch/arm/mm/cache-uniphier.c) has 128 byte
line length and its tags are also managed per 128 byte line. This
is very unfortunate, but the current 64 byte alignment for kmalloc()
causes sharing problems on DMA if used with this outer cache.
This commit adds ARM_L1_CACHE_SHIFT_7 to increase the DMA minimum
alignment to 128 byte if CACHE_UNIPHIER is enabled. There are
several drivers that assume aligning to L1_CACHE_BYTES will be DMA
safe, so this commit also changes the L1_CACHE_BYTES for safety.
Having said that, I hesitate to align all the other SoCs in Multi
platform to the UniPhier's requirement. So, I am disabling the
CONFIG_CACHE_UNIPHIER by default, so that multi_v7_defconfig will
still with CONFIG_ARM_L1_CACHE_SHIFT=6. With this, UniPhier SoCs
become a bit slower, but it is much better than system crash.
If desired, the outer-cache can be enabled by the merge_config or
something.
Note:
The UniPhier PH1-Pro5 SoC is equipped also with L3 cache with 256 byte
line size but its tags are managed per 128 byte sub-line.
So, ARM_L1_CACHE_SHIFT_7 should be fine for all the UniPhier SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
I threw a question in January this year:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/400289.html
After a long interval, I came back to this topic.
arch/arm/mm/Kconfig | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c1799dd..f68e8ec 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -991,7 +991,7 @@ config CACHE_TAUROS2
config CACHE_UNIPHIER
bool "Enable the UniPhier outer cache controller"
depends on ARCH_UNIPHIER
- default y
+ select ARM_L1_CACHE_SHIFT_7
select OUTER_CACHE
select OUTER_CACHE_SYNC
help
@@ -1012,8 +1012,14 @@ config ARM_L1_CACHE_SHIFT_6
help
Setting ARM L1 cache line size to 64 Bytes.
+config ARM_L1_CACHE_SHIFT_7
+ bool
+ help
+ Setting ARM L1 cache line size to 128 Bytes.
+
config ARM_L1_CACHE_SHIFT
int
+ default 7 if ARM_L1_CACHE_SHIFT_7
default 6 if ARM_L1_CACHE_SHIFT_6
default 5
--
1.9.1
^ permalink raw reply related
* [PATCH v2 5/9] of: Add vendor prefix for Netron DY
From: Thierry Reding @ 2016-10-19 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160906144620.6322-6-maxime.ripard@free-electrons.com>
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?
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/8e2680c2/attachment-0001.sig>
^ permalink raw reply
* [PATCH] mmc: sunxi: Prevent against null dereference for vmmc
From: Maxime Ripard @ 2016-10-19 12:36 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>
---
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");
+ 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
^ permalink raw reply related
* [PATCH v2 4/9] pinctrl: sunxi: Deal with configless pins
From: Maxime Ripard @ 2016-10-19 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64gBi71W=+Tu2vz94xFDtuRNHUyVWK3ken8CSOWvK5t0g@mail.gmail.com>
On Tue, Oct 18, 2016 at 03:47:03PM +0800, Chen-Yu Tsai wrote:
> > @@ -342,6 +365,8 @@ static void sunxi_pctrl_dt_free_map(struct pinctrl_dev *pctldev,
> > struct pinctrl_map *map,
> > unsigned num_maps)
> > {
> > + unsigned long *pinconfig;
>
> This looks out of place and context?
Yeah, sorry, it's just a leftover from the previous version. This has
been removed.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/a478c38b/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Linus Walleij @ 2016-10-19 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018163808.6318-1-eric@anholt.net>
On Tue, Oct 18, 2016 at 6:38 PM, Eric Anholt <eric@anholt.net> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The idea is to give useful names to GPIO lines that an implementer
> will be using from userspace, e.g. for maker type projects. These are
> user-visible using tools/gpio/lsgpio.c
>
> v2: Major rewrite by anholt: Flatten each GPIO line to a line in the
> file for better diffing, prefix all expansion header pins with
> "P<number>" or "P5HEADER_P<number>" and drop the mostly-unused
> GPIO_GEN<smallnumber> names in favor of GPIO<socgpionumber>, fix
> extra '[]' on a couple of lines, fix locations of SD_CARD_DETECT,
> CAM_GPIO and STATUS_LED, fix HDMI_HPD polarities, rewrite A+ using
> unreleased schematics.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Eric Anholt <eric@anholt.net>
Generally looks good!
I fully trust your usage of he Pnn_* prefix, I assume this
makes a lot of sense to RPi users.
> Note: I haven't actually booted these and checked that the names line
> up, just tried to visually review them. Hopefully with more
> GPIO<number> values, it's easier to spot errors.
>
> The only other thing here I think I would do is drop the [] around
> names for behavior when pinmuxed. I find it more confusing than
> helpful.
I added this on the 96board HiKey instead of just leaving it blank.
The idea was to distinguish somehow between GPIO proper and
a GPIO line that is actually not used as GPIO. It is only really
reflecting the schematic, so whatever makes sense for someone
familiar with the schematics apply.
I think it is up to the .dts file maintainer to decide. May even be
different things that make sense on different boards.
> Linus, are these names considered ABI? Will we be locked into
> whatever set of names we merge and release? My assumption would be
> "yes".
It is ABI if there is a userspace making use of it. So once libs
like libmraa (is that the name?) and similar things that do userspace
GPIO start using it, it becomes ABI.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: fix uninitialized variable access
From: Arnd Bergmann @ 2016-10-19 12:09 UTC (permalink / raw)
To: linux-arm-kernel
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>
---
drivers/dma/st_fdma.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 515e1d4c43e8..232d3547a6a3 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -720,21 +720,11 @@ static int st_fdma_parse_dt(struct platform_device *pdev,
const struct st_fdma_driverdata *drvdata,
struct st_fdma_dev *fdev)
{
- struct device_node *np = pdev->dev.of_node;
- int ret;
-
- if (!np)
- goto err;
-
- ret = of_property_read_u32(np, "dma-channels", &fdev->nr_channels);
- if (ret)
- goto err;
-
snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
drvdata->name, drvdata->id);
-err:
- return ret;
+ return of_property_read_u32(pdev->dev.of_node, "dma-channels",
+ &fdev->nr_channels);
}
#define FDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Will Deacon @ 2016-10-19 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16572d35-bf69-1680-717a-d2815b121c32@redhat.com>
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
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