* [PATCH 0/4] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-10-10 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475572167-29581-1-git-send-email-geert+renesas@glider.be>
On Tuesday, October 4, 2016 11:09:23 AM CEST Geert Uytterhoeven wrote:
> Hi all,
>
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0). This needs to
> be catered for by drivers and/or platform code. The recently proposed
> soc_device_match() API seems like a good fit to handle this.
>
> This patch series implements the core infrastructure to provide SoC and
> revision information through the SoC bus for Renesas ARM SoCs. It
> consists of 4 patches:
> - Patch 1 avoids a crash when SoC revision information is needed and
> provided early,
> - Patch 2 (from Arnd) introduces the soc_device_match() API.
> I don't know if, when, and through which channel this patch is
> planned to go upstream,
> - Patch 3 fixes a bug in soc_device_match(), causing a crash when
> trying to match on an SoC attribute that is not provided (seen on
> EMEV2, RZ/A, and R-Car M1A, which lack revision information),
> - Patch 4 identifies Renesas SoCs and registers them with the SoC bus.
>
> Tested on (family, machine, soc_id, optional revision):
>
> Emma Mobile EV2, EMEV2 KZM9D Board, emev2
> RZ/A, Genmai, r7s72100
> R-Mobile, APE6EVM, r8a73a4, ES1.0
> R-Mobile, armadillo 800 eva, r8a7740, ES2.0
> R-Car Gen1, bockw, r8a7778
> R-Car Gen1, marzen, r8a7779, ES1.0
> R-Car Gen2, Lager, r8a7790, ES1.0
> R-Car Gen2, Koelsch, r8a7791, ES1.0
> R-Car Gen2, Gose, r8a7793, ES1.0
> R-Car Gen2, Alt, r8a7794, ES1.0
> R-Car Gen3, Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
> R-Car Gen3, Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
> SH-Mobile, KZM-A9-GT, sh73a0, ES2.0
As mentioned in the comment for the driver patch, I think this makes
a lot of sense for the machines that have a revision register, in
particular when the interpretation of that register is always done
the same way, but I'm a bit skeptical about doing it in the same driver
for machines that don't have the register.
Matching by a device rather than the SoC platform also has the advantage
that there is no need to maintain a list of compatible numbers in the
driver.
Arnd
^ permalink raw reply
* [PATCH v13 03/15] iommu/dma: Allow MSI-only cookies
From: Robin Murphy @ 2016-10-10 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006141717.13c9c111@t450s.home>
Hi Alex, Eric,
On 06/10/16 21:17, Alex Williamson wrote:
> On Thu, 6 Oct 2016 08:45:19 +0000
> Eric Auger <eric.auger@redhat.com> wrote:
>
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>> with regard to mapping MSI messages in systems where the MSI write is
>> subject to IOMMU translation. With the relevant infrastructure now in
>> place for managed DMA domains, it's actually really simple for other
>> users to piggyback off that and reap the benefits without giving up
>> their own IOVA management, and without having to reinvent their own
>> wheel in the MSI layer.
>>
>> Allow such users to opt into automatic MSI remapping by dedicating a
>> region of their IOVA space to a managed cookie.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> v1 -> v2:
>> - compared to Robin's version
>> - add NULL last param to iommu_dma_init_domain
>> - set the msi_geometry aperture
>> - I removed
>> if (base < U64_MAX - size)
>> reserve_iova(iovad, iova_pfn(iovad, base + size), ULONG_MAX);
>> don't get why we would reserve something out of the scope of the iova domain?
>> what do I miss?
>> ---
>> drivers/iommu/dma-iommu.c | 40 ++++++++++++++++++++++++++++++++++++++++
>> include/linux/dma-iommu.h | 9 +++++++++
>> 2 files changed, 49 insertions(+)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab866..11da1a0 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -716,3 +716,43 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
>> msg->address_lo += lower_32_bits(msi_page->iova);
>> }
>> }
>> +
>> +/**
>> + * iommu_get_dma_msi_region_cookie - Configure a domain for MSI remapping only
>
> Should this perhaps be iommu_setup_dma_msi_region_cookie, or something
> along those lines. I'm not sure what we're get'ing. Thanks,
What we're getting is private third-party resources for the iommu_domain
given in the argument. It's a get/put rather than alloc/free model since
we operate opaquely on the domain as a container, rather than on the
actual resource in question (an IOVA allocator).
Since this particular use case is slightly different from the normal
flow and has special initialisation requirements, it seemed a lot
cleaner to simply combine that initialisation operation with the
prerequisite "get" into a single call. Especially as it helps emphasise
that this is not 'normal' DMA cookie usage.
>
> Alex
>
>> + * @domain: IOMMU domain to prepare
>> + * @base: Base address of IOVA region to use as the MSI remapping aperture
>> + * @size: Size of the desired MSI aperture
>> + *
>> + * Users who manage their own IOVA allocation and do not want DMA API support,
>> + * but would still like to take advantage of automatic MSI remapping, can use
>> + * this to initialise their own domain appropriately.
>> + */
>> +int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
>> + dma_addr_t base, u64 size)
>> +{
>> + struct iommu_dma_cookie *cookie;
>> + struct iova_domain *iovad;
>> + int ret;
>> +
>> + if (domain->type == IOMMU_DOMAIN_DMA)
>> + return -EINVAL;
>> +
>> + ret = iommu_get_dma_cookie(domain);
>> + if (ret)
>> + return ret;
>> +
>> + ret = iommu_dma_init_domain(domain, base, size, NULL);
>> + if (ret) {
>> + iommu_put_dma_cookie(domain);
>> + return ret;
>> + }
It *is* necessary to explicitly reserve the upper part of the IOVA
domain here - the aforementioned "special initialisation" - because
dma_32bit_pfn is only an optimisation hint to prevent the allocator
walking down from the very top of the the tree every time when devices
with different DMA masks share a domain (I'm in two minds as to whether
to tweak the way the iommu-dma code uses it in this respect, now that I
fully understand things). The only actual upper limit to allocation is
the DMA mask passed into each alloc_iova() call, so if we want to ensure
IOVAs are really allocated within this specific region, we have to carve
out everything above it.
Robin.
>> +
>> + domain->msi_geometry.aperture_start = base;
>> + domain->msi_geometry.aperture_end = base + size - 1;
>> +
>> + cookie = domain->iova_cookie;
>> + iovad = &cookie->iovad;
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(iommu_get_dma_msi_region_cookie);
>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>> index 32c5890..1c55413 100644
>> --- a/include/linux/dma-iommu.h
>> +++ b/include/linux/dma-iommu.h
>> @@ -67,6 +67,9 @@ int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
>> /* The DMA API isn't _quite_ the whole story, though... */
>> void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>>
>> +int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
>> + dma_addr_t base, u64 size);
>> +
>> #else
>>
>> struct iommu_domain;
>> @@ -90,6 +93,12 @@ static inline void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
>> {
>> }
>>
>> +static inline int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
>> + dma_addr_t base, u64 size)
>> +{
>> + return -ENODEV;
>> +}
>> +
>> #endif /* CONFIG_IOMMU_DMA */
>> #endif /* __KERNEL__ */
>> #endif /* __DMA_IOMMU_H */
>
^ permalink raw reply
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-10-10 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475572167-29581-5-git-send-email-geert+renesas@glider.be>
On Tuesday, October 4, 2016 11:09:27 AM CEST Geert Uytterhoeven wrote:
> Identify the SoC type and revision, and register this information with
> the SoC bus, so it is available under /sys/devices/soc0/, and can be
> checked where needed using soc_device_match().
>
> In addition, on SoCs that support it, the product ID is read from a
> hardware register and validated, to catch accidental use of a DTB for a
> different SoC.
>
> Example:
>
> Detected Renesas r8a7791 ES1.0
> ...
> # cat /sys/devices/soc0/{family,machine,soc_id,revision}
> R-Car Gen2
> Koelsch
> r8a7791
> ES1.0
>
Seems all reasonable.
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> This patch does NOT add a call to
>
> of_platform_default_populate(NULL, NULL,
> soc_device_to_device(soc_dev));
>
> Contrary to suggested by commit 74d1d82cdaaec727 ("drivers/base: add bus
> for System-on-Chip devices), doing so would not only move on-SoC devices
> from /sys/devices/platform/ to /sys/devices/soc0/, but also all other
> board (off-SoC) devices specified in the DTB.
Right, we have moved away from that a while ago, and now just
use the device for identification, not to model the device
hierarchy.
> diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
> new file mode 100644
> index 0000000000000000..74b72e4112b8889e
> --- /dev/null
> +++ b/drivers/soc/renesas/renesas-soc.c
> @@ -0,0 +1,266 @@
> +/*
> + * Renesas SoC Identification
> + *
> + * Copyright (C) 2014-2016 Glider bvba
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/sys_soc.h>
> +
> +
> +struct renesas_family {
> + const char name[16];
> + u32 reg; /* CCCR, PVR, or PRR */
> +};
> +
> +static const struct renesas_family fam_emev2 __initconst = {
> + .name = "Emma Mobile EV2",
> +};
As this is not related to the others and doesn't have the respective
register, I'd leave the platform out of this, and possibly have
a separate driver for it.
> +static const struct renesas_family fam_rza __initconst = {
> + .name = "RZ/A",
> +};
I'm not sure about the relationship between this one and the others,
maybe it should be treated in the same way as emev2 and left out from
this driver?
> +static const struct renesas_family fam_rmobile __initconst = {
> + .name = "R-Mobile",
> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
> +};
> +
> +static const struct renesas_family fam_rcar_gen1 __initconst = {
> + .name = "R-Car Gen1",
> + .reg = 0xff000044, /* PRR (Product Register) */
> +};
> +
> +static const struct renesas_family fam_rcar_gen2 __initconst = {
> + .name = "R-Car Gen2",
> + .reg = 0xff000044, /* PRR (Product Register) */
> +};
> +
> +static const struct renesas_family fam_rcar_gen3 __initconst = {
> + .name = "R-Car Gen3",
> + .reg = 0xfff00044, /* PRR (Product Register) */
> +};
> +
> +static const struct renesas_family fam_rzg __initconst = {
> + .name = "RZ/G",
> + .reg = 0xff000044, /* PRR (Product Register) */
> +};
> +
> +static const struct renesas_family fam_shmobile __initconst = {
> + .name = "SH-Mobile",
> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
> +};
These seem to fall into two distinct categories, maybe there is a
better way to group them. What device contain the two kinds of
registers (PRR, CCCR)?
Hardcoding the register address seems rather ugly here, so maybe
there is a way to have two separate probe methods based on the
surrounding register range, and then bind to that?
> +static const struct of_device_id renesas_socs[] __initconst = {
> +#ifdef CONFIG_ARCH_EMEV2
> + { .compatible = "renesas,emev2", .data = &soc_emev2 },
> +#endif
> +#ifdef CONFIG_ARCH_R7S72100
> + { .compatible = "renesas,r7s72100", .data = &soc_rz_a1h },
> +#endif
> +#ifdef CONFIG_ARCH_R8A73A4
I think the #ifdefs here will result in warnings for unused symbols
when the Kconfig symbols are disabled.
Arnd
^ permalink raw reply
* MAINTAINERS entry for ARM/CLKDEV SUPPORT
From: Russell King - ARM Linux @ 2016-10-10 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010140810.GA30609@mwanda>
On Mon, Oct 10, 2016 at 05:08:10PM +0300, Dan Carpenter wrote:
> Hello Stephen Boyd,
Okay, that's really not nice.
This is _not_ a question for Stephen. Stephen does _not_ co-maintain
clkdev or the clk API, but co-maintains CCF. I've no idea why you are
addressing this to Stephen when this is clearly a question for me to
answer.
> The MAINTAINERS entry looks like this:
>
> ARM/CLKDEV SUPPORT
> M: Russell King <linux@armlinux.org.uk>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/include/asm/clkdev.h
> F: drivers/clk/clkdev.c
>
>
> We removed arch/arm/include/asm/clkdev.h in 34d2f4d3a4d6a6b ('ARM: Use
> generic clkdev.h header'). Do you still need to be CC'd on the clkdev.c
> changes?
Technically, it is redundant anyway, as I'm listed for all arch/arm
changes. However, the maintainership of arch/arm and the maintainership
of clkdev are separate, the explicit entry is quite right.
It's also right that it's retained, because if we stop using the generic
clkdev.h header, I want to be copied on such a change, and this entry
will allow checkpatch to list me as clkdev maintainer.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-10 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1610091713490.1734-100000@netrider.rowland.org>
hi Alan/Krzysztof,
On 10 October 2016 at 02:47, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sun, 9 Oct 2016, Krzysztof Kozlowski wrote:
>
>> On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
>> > Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
>> > as to avoid them being build when not used. This also allows us to use the
>> > SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>> >
>> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> > ---
>> > drivers/usb/host/ehci-exynos.c | 14 ++++++--------
>> > 1 file changed, 6 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> > index 42e5b66..1899900 100644
>> > --- a/drivers/usb/host/ehci-exynos.c
>> > +++ b/drivers/usb/host/ehci-exynos.c
>> > @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
>> > return 0;
>> > }
>> >
>> > -#ifdef CONFIG_PM
>> > +#ifdef CONFIG_PM_SLEEP
>>
>> Does not look like an equivalent change. How will it behave in a config
>> with !SUSPEND && !HIBERNATE && PM?
>
> It's hard to say what Anand originally had in mind. To me, it looks
> like it will behave exactly the same as before, the only difference
> being that the object image will not contain unused exynos_ehci_suspend
> and exynos_ehci_resume routines. And the compiler won't issue a
> warning at build time that the routines are unused.
>
> Alan Stern
>
Thanks for looking into this closely.
I will just send one line changes to use SET_SYSTEM_SLEEP_PM_OPS
with better commit logs, if you people agree with this.
Best Regards
-Anand Moon
^ permalink raw reply
* [PATCH 1/4] base: soc: Early register bus when needed
From: Arnd Bergmann @ 2016-10-10 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475572167-29581-2-git-send-email-geert+renesas@glider.be>
On Tuesday, October 4, 2016 11:09:24 AM CEST Geert Uytterhoeven wrote:
> If soc_device_register() is called before soc_bus_register(), it crashes
> with a NULL pointer dereference.
>
> soc_bus_register() is already a core_initcall(), but drivers/base/ is
> entered later than e.g. drivers/pinctrl/ and drivers/soc/. Hence there
> are several subsystems that may need to know SoC revision information,
> while it's not so easy to initialize the SoC bus even earlier using an
> initcall.
>
> To fix this, let soc_device_register() register the bus early if that
> hasn't happened yet.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
Not nice, but I can't think of a better alternative, so
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH 3/4] base: soc: Check for NULL SoC device attributes
From: Arnd Bergmann @ 2016-10-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475572167-29581-4-git-send-email-geert+renesas@glider.be>
On Tuesday, October 4, 2016 11:09:26 AM CEST Geert Uytterhoeven wrote:
> If soc_device_match() is used to check the value of a specific
> attribute that is not present for the current SoC, the kernel crashes
> with a NULL pointer dereference.
>
> Fix this by explicitly checking for the absence of a needed property,
> and considering this a non-match.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot
From: Vignesh R @ 2016-10-10 14:11 UTC (permalink / raw)
To: linux-arm-kernel
U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and
cannot fit into existing partition. So, increase the SPI Flash partition
for U-Boot to 1MB for all Keystone2 devices.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
This was submitted to v4.9 merge window but was never picked up:
https://patchwork.kernel.org/patch/9135023/
arch/arm/boot/dts/keystone-k2e-evm.dts | 4 ++--
arch/arm/boot/dts/keystone-k2hk-evm.dts | 4 ++--
arch/arm/boot/dts/keystone-k2l-evm.dts | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e-evm.dts b/arch/arm/boot/dts/keystone-k2e-evm.dts
index ae1ebe7ee021..08ca9dc6ef7c 100644
--- a/arch/arm/boot/dts/keystone-k2e-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2e-evm.dts
@@ -137,13 +137,13 @@
partition at 0 {
label = "u-boot-spl";
- reg = <0x0 0x80000>;
+ reg = <0x0 0x100000>;
read-only;
};
partition at 1 {
label = "misc";
- reg = <0x80000 0xf80000>;
+ reg = <0x100000 0xf00000>;
};
};
};
diff --git a/arch/arm/boot/dts/keystone-k2hk-evm.dts b/arch/arm/boot/dts/keystone-k2hk-evm.dts
index 2156ff92d08f..369e1245f1ba 100644
--- a/arch/arm/boot/dts/keystone-k2hk-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2hk-evm.dts
@@ -161,13 +161,13 @@
partition at 0 {
label = "u-boot-spl";
- reg = <0x0 0x80000>;
+ reg = <0x0 0x100000>;
read-only;
};
partition at 1 {
label = "misc";
- reg = <0x80000 0xf80000>;
+ reg = <0x100000 0xf00000>;
};
};
};
diff --git a/arch/arm/boot/dts/keystone-k2l-evm.dts b/arch/arm/boot/dts/keystone-k2l-evm.dts
index 056b42f99d7a..63ae65987ca5 100644
--- a/arch/arm/boot/dts/keystone-k2l-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2l-evm.dts
@@ -110,13 +110,13 @@
partition at 0 {
label = "u-boot-spl";
- reg = <0x0 0x80000>;
+ reg = <0x0 0x100000>;
read-only;
};
partition at 1 {
label = "misc";
- reg = <0x80000 0xf80000>;
+ reg = <0x100000 0xf00000>;
};
};
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Fabio Estevam @ 2016-10-10 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e8696869cc82443825a590966bbd3a265befdfa.1476092427.git.emil@limesaudio.com>
On Mon, Oct 10, 2016 at 7:03 AM, Emil Lundmark <emil@limesaudio.com> wrote:
> Since 'parent_rate * mfn' may overflow 32 bits, the result should be
> stored using 64 bits.
It would be nice to add the text you put in the cover letter where you
explain the PLL4 clock discrepancy here in the commit log.
>
> Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
Would be nice to Cc the author of this commit (Anson Huang). Added on Cc.
Another hint: ./scripts/get_maintainer.pl drivers/clk/imx/clk-pllv3.c
gives you some suggestions on people and lists to add to Cc.
^ permalink raw reply
* MAINTAINERS entry for ARM/CLKDEV SUPPORT
From: Dan Carpenter @ 2016-10-10 14:08 UTC (permalink / raw)
To: linux-arm-kernel
Hello Stephen Boyd,
The MAINTAINERS entry looks like this:
ARM/CLKDEV SUPPORT
M: Russell King <linux@armlinux.org.uk>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/include/asm/clkdev.h
F: drivers/clk/clkdev.c
We removed arch/arm/include/asm/clkdev.h in 34d2f4d3a4d6a6b ('ARM: Use
generic clkdev.h header'). Do you still need to be CC'd on the clkdev.c
changes?
regards,
dan carpenter
^ permalink raw reply
* [PATCH v2 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Uwe Kleine-König @ 2016-10-10 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e8696869cc82443825a590966bbd3a265befdfa.1476092427.git.emil@limesaudio.com>
On Mon, Oct 10, 2016 at 12:03:05PM +0200, Emil Lundmark wrote:
> Since 'parent_rate * mfn' may overflow 32 bits, the result should be
> stored using 64 bits.
>
> Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
> Signed-off-by: Emil Lundmark <emil@limesaudio.com>
> ---
> drivers/clk/imx/clk-pllv3.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index 19f9b622981a..bc7f163ea13c 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -247,7 +247,11 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
> do_div(temp64, parent_rate);
> mfn = temp64;
>
> - return parent_rate * div + parent_rate * mfn / mfd;
> + temp64 = (u64)parent_rate;
> + temp64 *= mfn;
> + do_div(temp64, mfd);
If you change parent_rate from unsigned long to u64 this simplifies to
temp64 = parent_rate * mfn
do_div(temp64, mfd);
> +
> + return parent_rate * div + (u32)temp64;
When thinking about overflow problems: Should this fail somehow if
temp64 != (u32)temp64?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 1/5] clk: add support for runtime pm
From: Ulf Hansson @ 2016-10-10 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86cd1c31-6265-7493-fe6d-9a64fc34cd65@samsung.com>
[...]
>>> @@ -157,11 +181,17 @@ static bool clk_core_is_prepared(struct clk_core
>>> *core)
>>> if (!core->ops->is_prepared)
>>> return core->prepare_count;
>>>
>>> - return core->ops->is_prepared(core->hw);
>>> + clk_pm_runtime_get(core);
>>
>> I guess you should assign status to the return code, and check it.
>
>
> Okay. I assume that in case of any failure from runtime pm, the function
> should return false?
I think so, yes.
>
>
[...]
>>> static void clk_disable_unused_subtree(struct clk_core *core)
>>> @@ -768,6 +834,9 @@ static void clk_disable_unused_subtree(struct
>>> clk_core *core)
>>> if (core->flags & CLK_OPS_PARENT_ENABLE)
>>> clk_core_prepare_enable(core->parent);
>>>
>>> + if (clk_pm_runtime_get(core) != 0)
>>
>> Is there any reason to why you haven't moved this further down in this
>> function, like just before calling clk_core_is_enabled()?
>
>
> Yes, clk_enable_lock() takes a spinlock, so I cannot call pm_runtime_get
> after it.
Of course, you are right!
>
>
>>
>> You may also simplify this:
>> if (clk_pm_runtime_get(core))
>>
>>> + return;
>>> +
>>
>> You need to restore the call made to clk_core_prepare_enable()
>> earlier, so please update the error handling to cope with this.
>>
[...]
>>> @@ -2546,6 +2631,8 @@ struct clk *clk_register(struct device *dev, struct
>>> clk_hw *hw)
>>> goto fail_name;
>>> }
>>> core->ops = hw->init->ops;
>>> + if (dev && (hw->init->flags & CLK_RUNTIME_PM))
>>> + core->dev = dev;
>>
>> I guess you need this to play safe, although I am really wondering if
>> we should try without.
>>
>> Not that many clocks are currently being registered with a valid
>> struct device pointer. For the other cases why not try to use runtime
>> PM as per default?
>
>
> I've that tried initially, but it causes failure for all the clock
> controllers, which don't enable runtime pm. One of such case is max77686
> PMIC, which provides 3 clocks. Maybe a negative flag (CLK_NO_RUNTIME_PM)
> will be a better solution, so by default the runtime pm calls will be
> enabled for every driver providing struct device?
I assume that's because the runtime PM errors in clk_pm_runtime_get()
and friends, are being propagated to the callers? Especially because
the runtime PM core returns error codes, in cases when runtime PM
hasn't been enabled for the device.
>
>> Moreover we anyway rely on the clock provider to enable runtime PM for
>> the clock device, and when that isn't the case the runtime PM
>> deployment in the core should still be safe, right!?
>
>
> I don't get the above comment. Do you want to check if runtime pm has
> been enabled during clock registration?
Yes, something like that. Apologize, I was clearly being too vague.
My point is, we don't need to invent a specific clock provider flag
for this. Instead the clock core could just at clock registration
check if runtime PM is enabled for the device (pm_runtime_enabled()),.
and from that assign an internal clock core flag to keep track of
whether runtime PM should be managed or not.
>
>>> if (dev && dev->driver)
>>> core->owner = dev->driver->owner;
>>> core->hw = hw;
>>> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
>>> index a39c0c530778..8a131eb71fdf 100644
>>> --- a/include/linux/clk-provider.h
>>> +++ b/include/linux/clk-provider.h
>>> @@ -35,6 +35,7 @@
>>> #define CLK_IS_CRITICAL BIT(11) /* do not gate, ever */
>>> /* parents need enable during gate/ungate, set rate and re-parent */
>>> #define CLK_OPS_PARENT_ENABLE BIT(12)
>>> +#define CLK_RUNTIME_PM BIT(13)
>>>
>>> struct clk;
>>> struct clk_hw;
>>> --
>>> 1.9.1
>>>
>>
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
Kind regards
Uffe
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Lucas Stach @ 2016-10-10 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161002164435.5812-1-marex@denx.de>
Am Sonntag, den 02.10.2016, 18:44 +0200 schrieb Marek Vasut:
> The LCDIF interrupt should be triggered by the rising edge of the
> IRQ line because we only want the interrupt to trigger once per each
> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
> by software, so the previous behavior before this patch, where the
> interrupt was triggered by level-high status of the IRQ line, caused
> the interrupt to fire again immediatelly after it was handled, which
> caused the system to lock up due to the high rate of interrupts.
>
If there is no way to ack the IRQ how is the line going low again? Some
hardware state machine?
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> ---
> arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 1a473e8..9526c38 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -1143,7 +1143,7 @@
> lcdif1: lcdif at 02220000 {
> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
> reg = <0x02220000 0x4000>;
> - interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
> clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
> <&clks IMX6SX_CLK_LCDIF_APB>,
> <&clks IMX6SX_CLK_DISPLAY_AXI>;
> @@ -1154,7 +1154,7 @@
> lcdif2: lcdif at 02224000 {
> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
> reg = <0x02224000 0x4000>;
> - interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>;
> clocks = <&clks IMX6SX_CLK_LCDIF2_PIX>,
> <&clks IMX6SX_CLK_LCDIF_APB>,
> <&clks IMX6SX_CLK_DISPLAY_AXI>;
^ permalink raw reply
* [PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Rob Herring @ 2016-10-10 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-2-mugunthanvnm@ti.com>
On Thu, Oct 06, 2016 at 10:43:52AM +0530, Mugunthan V N wrote:
> Add documention of ti,impedance-control which can be used to
Needs updating.
> correct MAC impedance mismatch using phy extended registers.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
> index 5d21141..85bf945 100644
> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
> @@ -9,6 +9,18 @@ Required properties:
> - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
> for applicable values
>
> +Optional property:
> + - ti,min-output-impedance - MAC Interface Impedance control to set
> + the programmable output impedance to
> + minimum value (35 ohms).
> + - ti,max-output-impedance - MAC Interface Impedance control to set
> + the programmable output impedance to
> + maximum value (70 ohms).
Define what are valid range of values for these.
> +
> +Note: ti,min-output-impedance and ti,max-output-impedance are mutually
> + exclusive. When both properties are present ti,max-output-impedance
> + takes precedence.
> +
> Default child nodes are standard Ethernet PHY device
> nodes as described in Documentation/devicetree/bindings/net/phy.txt
>
> --
> 2.10.0.372.g6fe1b14
>
^ permalink raw reply
* [PATCH 2/3] dt-bindings: mtd: add DT binding for s3c2410 flash controller
From: Rob Herring @ 2016-10-10 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-3-git-send-email-sergio.prado@e-labworks.com>
On Wed, Oct 05, 2016 at 08:46:56PM -0300, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C2410 and
> compatible NAND flash controller.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> .../devicetree/bindings/mtd/samsung-s3c2410.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 2/4] power: add axp20x-battery driver
From: Maxime Ripard @ 2016-10-10 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010125726.GJ3462@lukather>
Adding the real Quentin address
On Mon, Oct 10, 2016 at 02:57:26PM +0200, Maxime Ripard wrote:
> Hi Icenowy,
>
> On Sun, Oct 09, 2016 at 02:27:12PM +0800, Icenowy Zheng wrote:
> > + case POWER_SUPPLY_PROP_CURRENT_NOW:
> > + ret = regmap_read(power->regmap, AXP20X_BATT_DISCHRG_I_H, &dh);
> > + if (ret)
> > + return ret;
> > + ret = regmap_read(power->regmap, AXP20X_BATT_DISCHRG_I_L, &dl);
> > + if (ret)
> > + return ret;
> > + /* it's a 12 bit integer, high 8-bit is stored in dh */
> > + val->intval = dh << 4 | dl >> 4;
> > + break;
> > + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> > + ret = regmap_read(power->regmap, AXP20X_BATT_V_H, &dh);
> > + if (ret)
> > + return ret;
> > + ret = regmap_read(power->regmap, AXP20X_BATT_V_L, &dl);
> > + if (ret)
> > + return ret;
> > + /* it's a 12 bit integer, high 8-bit is stored in dh */
> > + val->intval = dh << 4 | dl >> 4;
> > + /* The formula below is from axp22_vbat_to_mV function
> > + * of Allwinner 3.4 kernel.
> > + */
> > + val->intval = val->intval * 1100 / 1000;
> > + break;
>
> I really feel that this should be implemented through a IIO driver
> (like the AXP288). This is especially true for the AXP209 and its
> multiple GPIOs that can be muxed to a general purpose ADC, but it's
> also true for the AXP221 / 223 TS pin that can also be used as an ADC.
>
> Quentin has been working on this lately for the AXP209, feel free to
> sync with him to support the AXP22*
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161010/ff37d435/attachment.sig>
^ permalink raw reply
* [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: Jean-Francois Moine @ 2016-10-10 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010123511.GA16103@Red>
On Mon, 10 Oct 2016 14:35:11 +0200
LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> On Mon, Oct 10, 2016 at 02:30:46PM +0200, Maxime Ripard wrote:
> > On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> > > Enable the sun8i-emac driver in the multi_v7 default configuration
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > arch/arm/configs/multi_v7_defconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> > > index 5845910..f44d633 100644
> > > --- a/arch/arm/configs/multi_v7_defconfig
> > > +++ b/arch/arm/configs/multi_v7_defconfig
> > > @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> > > CONFIG_VIRTIO_NET=y
> > > CONFIG_HIX5HD2_GMAC=y
> > > CONFIG_SUN4I_EMAC=y
> > > +CONFIG_SUN8I_EMAC=y
> >
> > Any reason to build it statically?
> >
>
> No, just copied the same than CONFIG_SUN4I_EMAC that probably do not need it also.
All arm configs are done the same way, and, some day, the generic ARM
V7 kernel will not be loadable in 1Gb RAM...
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [RESEND PATCH v2 3/3] dt-bindings: reset: oxnas: Update for OX820
From: Rob Herring @ 2016-10-10 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-4-narmstrong@baylibre.com>
On Wed, Oct 05, 2016 at 05:27:10PM +0200, Neil Armstrong wrote:
> Add new compatible string for reset and sys-ctrl for the Oxford
> Semiconductor OX820 Support.
> Drop the OX810SE indices since they moved in a dedicated include file.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/reset/oxnas,reset.txt | 44 +++++-----------------
> 1 file changed, 9 insertions(+), 35 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 6/6] dt-bindings: clk: oxnas,stdclk: Add OX820 bindings
From: Rob Herring @ 2016-10-10 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-7-narmstrong@baylibre.com>
On Wed, Oct 05, 2016 at 05:07:52PM +0200, Neil Armstrong wrote:
> Add OX820 bindings and remove clock indices from bindings since they are present
> in the dt-bindings headers files.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/clock/oxnas,stdclk.txt | 19 ++++++-------------
> 1 file changed, 6 insertions(+), 13 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 2/4] power: add axp20x-battery driver
From: Maxime Ripard @ 2016-10-10 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009062714.5085-2-icenowy@aosc.xyz>
Hi Icenowy,
On Sun, Oct 09, 2016 at 02:27:12PM +0800, Icenowy Zheng wrote:
> + case POWER_SUPPLY_PROP_CURRENT_NOW:
> + ret = regmap_read(power->regmap, AXP20X_BATT_DISCHRG_I_H, &dh);
> + if (ret)
> + return ret;
> + ret = regmap_read(power->regmap, AXP20X_BATT_DISCHRG_I_L, &dl);
> + if (ret)
> + return ret;
> + /* it's a 12 bit integer, high 8-bit is stored in dh */
> + val->intval = dh << 4 | dl >> 4;
> + break;
> + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> + ret = regmap_read(power->regmap, AXP20X_BATT_V_H, &dh);
> + if (ret)
> + return ret;
> + ret = regmap_read(power->regmap, AXP20X_BATT_V_L, &dl);
> + if (ret)
> + return ret;
> + /* it's a 12 bit integer, high 8-bit is stored in dh */
> + val->intval = dh << 4 | dl >> 4;
> + /* The formula below is from axp22_vbat_to_mV function
> + * of Allwinner 3.4 kernel.
> + */
> + val->intval = val->intval * 1100 / 1000;
> + break;
I really feel that this should be implemented through a IIO driver
(like the AXP288). This is especially true for the AXP209 and its
multiple GPIOs that can be muxed to a general purpose ADC, but it's
also true for the AXP221 / 223 TS pin that can also be used as an ADC.
Quentin has been working on this lately for the AXP209, feel free to
sync with him to support the AXP22*
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161010/f2256077/attachment.sig>
^ permalink raw reply
* [PATCH v4 04/10] ARM: dts: sun8i-h3: Add dt node for the syscon control module
From: Jean-Francois Moine @ 2016-10-10 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010123151.GI3462@lukather>
On Mon, 10 Oct 2016 14:31:51 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Fri, Oct 07, 2016 at 10:25:51AM +0200, Corentin Labbe wrote:
> > This patch add the dt node for the syscon register present on the
> > Allwinner H3.
> >
> > Only two register are present in this syscon and the only one useful is
> > the one dedicated to EMAC clock.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 8a95e36..1101d2f 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -140,6 +140,11 @@
> > #size-cells = <1>;
> > ranges;
> >
> > + syscon: syscon at 01c00000 {
> > + compatible = "syscon";
>
> It would be great to have a more specific compatible here in addition
> to the syscon, like "allwinner,sun8i-h3-system-controller".
The System Control area is just like the PRCM area: it would be simpler
to define the specific registers in the associated drivers.
Here, instead of the syscon node, plus
+ emac: ethernet at 1c30000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
...
there would be no 'syscon' node and
+ emac: ethernet at 1c30000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x104>, /* EMAC */
+ <0x01c00030 4>; /* system control */
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
...
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH] PM / AVS: rockchip-io: make the log more consistent
From: Shawn Lin @ 2016-10-10 12:44 UTC (permalink / raw)
To: linux-arm-kernel
When testing SD hotplug automatically, I got bunch of
useless log like this:
[ 588.357838] mmc0: card 0007 removed
[ 589.492664] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[ 589.500698] vccio_sd: ramp_delay not set
[ 589.504817] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[ 589.669705] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[ 589.677593] vccio_sd: ramp_delay not set
[ 589.681581] rockchip-iodomain ff770000.syscon:io-domains: Setting to 1800000 done
[ 590.032820] dwmmc_rockchip ff0c0000.dwmmc: Successfully tuned phase to 140
[ 590.039725] mmc0: new ultra high speed SDR50 SDHC card at address 0007
[ 590.046641] mmcblk0: mmc0:0007 SD32G 29.3 GiB
[ 590.052163] mmcblk0: p1
Moreover the code is intent to print the 'uV' for debug but
later print it using dev_info. It looks more like to me that
it should be the real intention of the code. Anyway, let's
mark this verbose log as debug message.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/power/avs/rockchip-io-domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/avs/rockchip-io-domain.c b/drivers/power/avs/rockchip-io-domain.c
index 01b6d3f..56bce19 100644
--- a/drivers/power/avs/rockchip-io-domain.c
+++ b/drivers/power/avs/rockchip-io-domain.c
@@ -143,7 +143,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
return NOTIFY_BAD;
- dev_info(supply->iod->dev, "Setting to %d done\n", uV);
+ dev_dbg(supply->iod->dev, "Setting to %d done\n", uV);
return NOTIFY_OK;
}
--
2.3.7
^ permalink raw reply related
* [PATCH 1/2] mmc: block: add missing header dependencies
From: Ulf Hansson @ 2016-10-10 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475199459-4775-1-git-send-email-baoyou.xie@linaro.org>
On 30 September 2016 at 03:37, Baoyou Xie <baoyou.xie@linaro.org> wrote:
> We get 1 warning when building kernel with W=1:
> drivers/mmc/card/block.c:2147:5: warning: no previous prototype for 'mmc_blk_issue_rq' [-Wmissing-prototypes]
>
> In fact, this function is declared in drivers/mmc/card/block.h,
> so this patch adds missing header dependencies.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Thanks, applied for fixes!
Kind regards
Uffe
> ---
> drivers/mmc/card/block.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index c333511..0f2cc9f2 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -46,6 +46,7 @@
> #include <asm/uaccess.h>
>
> #include "queue.h"
> +#include "block.h"
>
> MODULE_ALIAS("mmc:block");
> #ifdef MODULE_PARAM_PREFIX
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH -next] mmc: sdhci-of-arasan: Fix non static symbol warning
From: Ulf Hansson @ 2016-10-10 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474818243-19207-1-git-send-email-weiyj.lk@gmail.com>
On 25 September 2016 at 17:44, Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
> symbol 'sdhci_arasan_reset' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Thanks, applied for fixes!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index da8e40a..e263671 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -250,7 +250,7 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
> writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
> }
>
> -void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> +static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> {
> u8 ctrl;
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>
>
>
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Marek Szyprowski @ 2016-10-10 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475600632-21289-1-git-send-email-sricharan@codeaurora.org>
Hi Sricharan,
On 2016-10-04 19:03, Sricharan R wrote:
> Initial post from Laurent Pinchart[1]. This is
> series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
>
> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
> | |
> pci_bus_add_device (device_add/driver_register)
> | |
> device_attach device_initial_probe
> | |
> __device_attach_driver __device_attach_driver
> |
> driver_probe_device
> |
> really_probe
> |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> If the ACPI bus code follows the same, we can add acpi_dma_configure
> at the same place as of_dma_configure.
>
> This series is based on the recently merged Generic DT bindings for
> PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy at arm.com [2]
>
> This time tested this with platform and pci device for probe deferral
> and reprobe on arm64 based platform. There is an issue on the cleanup
> path for arm64 though, where there is WARN_ON if the dma_ops is reset while
> device is attached to an domain in arch_teardown_dma_ops.
> But with iommu_groups created from the iommu driver, the device is always
> attached to a domain/default_domain. So so the WARN has to be removed/handled
> probably.
Thanks for continuing work on this feature! Your can add my:
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
It works fine with Exynos SYSMMU driver, although a patch is needed to fix
infinite loop due to list corruption (same element is added twice if master
device fails with deferred probe):
From: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Mon, 10 Oct 2016 14:22:42 +0200
Subject: [PATCH] iommu/exynos: ensure that sysmmu is added only once to its
master
Since adding IOMMU deferred probing support, of_xlate() callback might
be called more than once for given master device (for example it happens
when masters device driver fails with EPROBE_DEFER), so ensure that
SYSMMU controller is added to its master device (owner) only once.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/iommu/exynos-iommu.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 30808e91b775..1525a86eb829 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1253,7 +1253,7 @@ static int exynos_iommu_of_xlate(struct device *dev,
{
struct exynos_iommu_owner *owner = dev->archdata.iommu;
struct platform_device *sysmmu = of_find_device_by_node(spec->np);
- struct sysmmu_drvdata *data;
+ struct sysmmu_drvdata *data, *entry;
if (!sysmmu)
return -ENODEV;
@@ -1271,6 +1271,10 @@ static int exynos_iommu_of_xlate(struct device *dev,
dev->archdata.iommu = owner;
}
+ list_for_each_entry(entry, &owner->controllers, owner_node)
+ if (entry == data)
+ return 0;
+
list_add_tail(&data->owner_node, &owner->controllers);
return 0;
}
--
1.9.1
>
> Previous post of this series [3].
>
> [V3]
> * Removed the patch to split dma_masks/dma_ops configuration separately
> based on review comments that both masks and ops are required only
> during the device probe time.
>
> * Reworked the series based on Generic DT bindings series [2].
>
> * Added call to iommu's remove_device in the cleanup path for arm and arm64.
>
> * Removed the notifier trick in arm64 to handle early device registration.
>
> * Added reset of dma_ops in cleanup path for arm based on comments.
>
> * Fixed the pci_iommu_configure path and tested with PCI device as well.
>
> * Fixed a bug to return the correct iommu_ops from patch 7 [4] in last post.
>
> * Fixed few other cosmetic comments.
>
> [V2]
> * Updated the Initial post to call dma_configure/deconfigure from generic code
>
> * Added iommu add_device callback from of_iommu_configure path
>
> [V1]
> * Initial post
>
> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> [2] http://www.spinics.net/lists/devicetree/msg142943.html
> [3] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13941.html
> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
>
>
>
> Laurent Pinchart (4):
> arm: dma-mapping: Don't override dma_ops in arch_setup_dma_ops()
> of: dma: Move range size workaround to of_dma_get_range()
> of: dma: Make of_dma_deconfigure() public
> iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
> Sricharan R (4):
> drivers: platform: Configure dma operations at probe time
> arm: dma-mapping: Reset the device's dma_ops
> arm/arm64: dma-mapping: Call iommu's remove_device callback during
> device detach
> arm64: dma-mapping: Remove the notifier trick to handle early setting
> of dma_ops
>
> arch/arm/mm/dma-mapping.c | 18 ++++++++
> arch/arm64/mm/dma-mapping.c | 107 +++++---------------------------------------
> drivers/base/dd.c | 10 +++++
> drivers/base/dma-mapping.c | 11 +++++
> drivers/iommu/of_iommu.c | 47 +++++++++++++++++--
> drivers/of/address.c | 20 ++++++++-
> drivers/of/device.c | 34 +++++++-------
> drivers/of/platform.c | 9 ----
> drivers/pci/probe.c | 5 +--
> include/linux/dma-mapping.h | 3 ++
> include/linux/of_device.h | 7 ++-
> 11 files changed, 138 insertions(+), 133 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox