* [PATCH v9 2/4] soc: mediatek: Init MT8173 scpsys driver earlier
From: James Liao @ 2016-10-31 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14a1ebb2-fda2-278b-b2f0-8f9c6ff6a83d@gmail.com>
On Mon, 2016-10-31 at 01:08 +0100, Matthias Brugger wrote:
> Hi James,
>
> On 10/20/2016 10:56 AM, James Liao wrote:
> > Some power domain comsumers may init before module_init.
> > So the power domain provider (scpsys) need to be initialized
> > earlier too.
> >
> > Take an example for our IOMMU (M4U) and SMI. SMI is a bridge
> > between IOMMU and multimedia HW. SMI is responsible to
> > enable/disable iommu and help transfer data for each multimedia
> > HW. Both of them have to wait until the power and clocks are
> > enabled.
> >
> > So scpsys driver should be initialized before SMI, and SMI should
> > be initialized before IOMMU, and then init IOMMU consumers
> > (display/vdec/venc/camera etc.).
> >
> > IOMMU is subsys_init by default. So we need to init scpsys driver
> > before subsys_init.
> >
> > Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> > Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> > ---
>
> I didn't applied this patch for now.
> I answered you in v7 of this series [1]. I would prefer to see if we can
> fix that otherwise.
>
> Would be great if you or Yong could provide some feedback.
>
> Thanks,
> Matthias
>
> [1] https://patchwork.kernel.org/patch/9397405/
>
> > drivers/soc/mediatek/mtk-scpsys.c | 19 ++++++++++++++++++-
> > 1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> > index fa9ee69..dd7a07d 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -613,4 +613,21 @@ static int scpsys_probe(struct platform_device *pdev)
> > .of_match_table = of_match_ptr(of_scpsys_match_tbl),
> > },
> > };
> > -builtin_platform_driver(scpsys_drv);
> > +
> > +static int __init scpsys_drv_init(void)
> > +{
> > + return platform_driver_register(&scpsys_drv);
> > +}
> > +
> > +/*
> > + * There are some Mediatek drivers which depend on the power domain driver need
> > + * to probe in earlier initcall levels. So scpsys driver also need to probe
> > + * earlier.
> > + *
> > + * IOMMU(M4U) and SMI drivers for example. SMI is a bridge between IOMMU and
> > + * multimedia HW. IOMMU depends on SMI, and SMI is a power domain consumer,
> > + * so the proper probe sequence should be scpsys -> SMI -> IOMMU driver.
> > + * IOMMU drivers are initialized during subsys_init by default, so we need to
> > + * move SMI and scpsys drivers to subsys_init or earlier init levels.
> > + */
> > +subsys_initcall(scpsys_drv_init);
> >
Hi Matthias,
I got it, thanks.
Hi Yong,
Is this patch still needed on latest kernel for IOMMU driver? Or we have
other solutions for IOMMU driver init?
Best regards,
James
^ permalink raw reply
* [PATCH RESEND] tty: amba-pl011: Add earlycon support for SBSA UART
From: Kefeng Wang @ 2016-10-31 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030133139.GA1595@kroah.com>
Declare an OF early console for SBSA UART so that the early console device
can be specified via the "stdout-path" property in device-tree.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/tty/serial/amba-pl011.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index e2c33b9..a4a0b3d 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2357,6 +2357,7 @@ static int __init pl011_early_console_setup(struct earlycon_device *device,
return 0;
}
OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
+OF_EARLYCON_DECLARE(pl011, "arm,sbsa-uart", pl011_early_console_setup);
#else
#define AMBA_CONSOLE NULL
--
1.7.12.4
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: Document Broadcom OTP controller driver
From: Rob Herring @ 2016-10-31 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477336324-10543-2-git-send-email-jonathan.richardson@broadcom.com>
On Mon, Oct 24, 2016 at 12:12:02PM -0700, Jonathan Richardson wrote:
> From: Jonathan Richardson <jonathar@broadcom.com>
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Oza Pawandeep <oza@broadcom.com>
> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> ---
> Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
> new file mode 100644
> index 0000000..6462e12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
> @@ -0,0 +1,17 @@
> +Broadcom OTP memory controller
> +
> +Required Properties:
> +- compatible: "brcm,ocotp" for the first generation Broadcom OTPC which is used
> + in Cygnus and supports 32 bit read/write. Use "brcm,ocotp-v2" for the second
> + generation Broadcom OTPC which is used in SoC's such as Stingray and supports
> + 64-bit read/write.
These should be SoC specific. While I'd guess this block is simple
enough, having the SoC can define what all the bits are. Yes, there is a
binding to define those, but you may not use that.
> +- reg: Base address of the OTP controller.
> +- brcm,ocotp-size: Amount of memory available, in 32 bit words
> +
> +Example:
> +
> +otp: otp at 0301c800 {
> + compatible = "brcm,ocotp";
> + reg = <0x0301c800 0x2c>;
> + brcm,ocotp-size = <2048>;
> +};
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] arm64: dts: mt8173: Fix auxadc node
From: Matthias Brugger @ 2016-10-31 0:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026141500.27105-1-matthias.bgg@gmail.com>
On 10/26/2016 04:15 PM, Matthias Brugger wrote:
> The devicetree node for mt8173-auxadc lacks the clock and
> io-channel-cells property. This leads to a non-working driver.
>
> mt6577-auxadc 11001000.auxadc: failed to get auxadc clock
> mt6577-auxadc: probe of 11001000.auxadc failed with error -2
>
> Fix these fields to get the device up and running.
>
> Fixes: 748c7d4de46a ("ARM64: dts: mt8173: Add thermal/auxadc device
> nodes")
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
Applied.
^ permalink raw reply
* [PATCH v9 2/4] soc: mediatek: Init MT8173 scpsys driver earlier
From: Matthias Brugger @ 2016-10-31 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476953798-23263-3-git-send-email-jamesjj.liao@mediatek.com>
Hi James,
On 10/20/2016 10:56 AM, James Liao wrote:
> Some power domain comsumers may init before module_init.
> So the power domain provider (scpsys) need to be initialized
> earlier too.
>
> Take an example for our IOMMU (M4U) and SMI. SMI is a bridge
> between IOMMU and multimedia HW. SMI is responsible to
> enable/disable iommu and help transfer data for each multimedia
> HW. Both of them have to wait until the power and clocks are
> enabled.
>
> So scpsys driver should be initialized before SMI, and SMI should
> be initialized before IOMMU, and then init IOMMU consumers
> (display/vdec/venc/camera etc.).
>
> IOMMU is subsys_init by default. So we need to init scpsys driver
> before subsys_init.
>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> ---
I didn't applied this patch for now.
I answered you in v7 of this series [1]. I would prefer to see if we can
fix that otherwise.
Would be great if you or Yong could provide some feedback.
Thanks,
Matthias
[1] https://patchwork.kernel.org/patch/9397405/
> drivers/soc/mediatek/mtk-scpsys.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index fa9ee69..dd7a07d 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -613,4 +613,21 @@ static int scpsys_probe(struct platform_device *pdev)
> .of_match_table = of_match_ptr(of_scpsys_match_tbl),
> },
> };
> -builtin_platform_driver(scpsys_drv);
> +
> +static int __init scpsys_drv_init(void)
> +{
> + return platform_driver_register(&scpsys_drv);
> +}
> +
> +/*
> + * There are some Mediatek drivers which depend on the power domain driver need
> + * to probe in earlier initcall levels. So scpsys driver also need to probe
> + * earlier.
> + *
> + * IOMMU(M4U) and SMI drivers for example. SMI is a bridge between IOMMU and
> + * multimedia HW. IOMMU depends on SMI, and SMI is a power domain consumer,
> + * so the proper probe sequence should be scpsys -> SMI -> IOMMU driver.
> + * IOMMU drivers are initialized during subsys_init by default, so we need to
> + * move SMI and scpsys drivers to subsys_init or earlier init levels.
> + */
> +subsys_initcall(scpsys_drv_init);
>
^ permalink raw reply
* [PATCH v9 3/4] soc: mediatek: Add MT2701 power dt-bindings
From: Matthias Brugger @ 2016-10-31 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19220b7f-84c3-eefe-333c-bd1ddfa988a3@gmail.com>
On 10/31/2016 12:57 AM, Matthias Brugger wrote:
>
>
> On 10/20/2016 10:56 AM, James Liao wrote:
>> From: Shunli Wang <shunli.wang@mediatek.com>
>>
>> Add power dt-bindings for MT2701.
>>
>> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
>> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
>
> Applied to v4.9-next/soc
Of course this has to be applied to v4.9-next/dts, fixed now.
Thanks,
Matthias
^ permalink raw reply
* [PATCH v9 4/4] soc: mediatek: Add MT2701 scpsys driver
From: Matthias Brugger @ 2016-10-30 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476953798-23263-5-git-send-email-jamesjj.liao@mediatek.com>
On 10/20/2016 10:56 AM, James Liao wrote:
> From: Shunli Wang <shunli.wang@mediatek.com>
>
> Add scpsys driver for MT2701.
>
> mtk-scpsys now supports MT8173 (arm64) and MT2701 (arm). So it should
> be enabled on both arm64 and arm platforms.
>
> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> ---
Applied to v4.9-next/soc
^ permalink raw reply
* [PATCH v9 3/4] soc: mediatek: Add MT2701 power dt-bindings
From: Matthias Brugger @ 2016-10-30 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476953798-23263-4-git-send-email-jamesjj.liao@mediatek.com>
On 10/20/2016 10:56 AM, James Liao wrote:
> From: Shunli Wang <shunli.wang@mediatek.com>
>
> Add power dt-bindings for MT2701.
>
> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Applied to v4.9-next/soc
^ permalink raw reply
* [PATCH v9 1/4] soc: mediatek: Refine scpsys to support multiple platform
From: Matthias Brugger @ 2016-10-30 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477647408.24014.6.camel@mtksdaap41>
On 10/28/2016 11:36 AM, James Liao wrote:
> Hi Matthias,
>
> Sorry for late reply due to our email service.
>
> On Tue, 2016-10-25 at 16:04 +0200, Matthias Brugger wrote:
>> Hi James,
>>
>> On 10/20/2016 10:56 AM, James Liao wrote:
>>> -static int scpsys_probe(struct platform_device *pdev)
>>> +static void init_clks(struct platform_device *pdev, struct clk *clk[CLK_MAX])
>>
>> I prefer struct clk **clk.
>
> Okay.
>
>>> +{
>>> + int i;
>>> +
>>> + for (i = CLK_NONE + 1; i < CLK_MAX; i++)
>>> + clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
>>> +}
>>> +
>>> +static struct scp *init_scp(struct platform_device *pdev,
>>> + const struct scp_domain_data *scp_domain_data, int num)
>>> {
>>> struct genpd_onecell_data *pd_data;
>>> struct resource *res;
>>> - int i, j, ret;
>>> + int i, j;
>>> struct scp *scp;
>>> - struct clk *clk[MT8173_CLK_MAX];
>>> + struct clk *clk[CLK_MAX];
>>
>> should be *[CLK_MAX - 1] but I would prefer to define in the enum:
>> CLK_MAX = CLK_VENC_LT,
>
> After init_clks() the clk[] will have valid contents between
> clk[1]..clk[CLK_MAX-1], so it's necessary to declare clk[] with CLK_MAX
> elements.
>
>> If you are ok with it, I can fix both of my comments when applying.
>
> Yes. struct clk **clk can be applied directly. But I think clk[CLK_MAX]
> should be kept in current implementation.
>
Ok, we won't never use clk[0] but it's ok for now.
Applied to v4.9-next/soc
>
> Best regards,
>
> James
>
>
^ permalink raw reply
* [PATCH v7 REPOST 8/9] arm: add sysfs cpu_capacity attribute
From: Russell King - ARM Linux @ 2016-10-30 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017154650.18779-9-juri.lelli@arm.com>
On Mon, Oct 17, 2016 at 04:46:49PM +0100, Juri Lelli wrote:
> +#ifdef CONFIG_PROC_SYSCTL
> +#include <asm/cpu.h>
> +#include <linux/string.h>
Include files at the top of the file please. No need to ifdef them.
They're sorted alphabetically, so new additions should be alphabetical.
(That's a general rule - if something is already alphabetical, do not
make it non-alphabetical.)
> +static ssize_t show_cpu_capacity(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct cpu *cpu = container_of(dev, struct cpu, dev);
> + ssize_t rc;
> + int cpunum = cpu->dev.id;
> + unsigned long capacity = arch_scale_cpu_capacity(NULL, cpunum);
> +
> + rc = sprintf(buf, "%lu\n", capacity);
> +
> + return rc;
Way too many lines for such a simple function. This can be simplified
to just:
struct cpu *cpu = container_of(dev, struct cpu, dev);
return sprintf(buf, "%lu\n", arch_scale_cpu_capacity(NULL, cpu->dev.id);
If you don't like the last line ending on column 79, then feel free to
break it across two lines after the format string.
> +}
> +
> +static ssize_t store_cpu_capacity(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct cpu *cpu = container_of(dev, struct cpu, dev);
> + int this_cpu = cpu->dev.id, i;
> + unsigned long new_capacity;
> + ssize_t ret;
> +
> + if (count) {
> + char *p = (char *) buf;
> +
> + ret = kstrtoul(p, 0, &new_capacity);
Unnecessary cast - kstrtoul takes a const char pointer, and in any case
it's really bad form to cast away the "const-ness" of any pointer. So,
just:
if (count) {
ret = kstrtoul(buf, 0, &new_capacity);
should work just fine.
> + if (ret)
> + return ret;
> + if (new_capacity > SCHED_CAPACITY_SCALE)
> + return -EINVAL;
> +
> + mutex_lock(&cpu_scale_mutex);
> + for_each_cpu(i, &cpu_topology[this_cpu].core_sibling)
> + set_capacity_scale(i, new_capacity);
> + mutex_unlock(&cpu_scale_mutex);
> + }
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(cpu_capacity,
> + 0644,
> + show_cpu_capacity,
> + store_cpu_capacity);
There's a move to use the named DEVICE_ATTR_RW() for this kind of thing,
it'll want the functions named xxx_show() and xxx_store(). I see
there's some recent patches to do this conversion across the kernel, so
this should probably be done before submission.
> +
> +static int register_cpu_capacity_sysctl(void)
> +{
> + int i;
> + struct device *cpu;
> +
> + for_each_possible_cpu(i) {
> + cpu = get_cpu_device(i);
> + if (!cpu) {
> + pr_err("%s: too early to get CPU%d device!\n",
> + __func__, i);
> + continue;
> + }
> + device_create_file(cpu, &dev_attr_cpu_capacity);
> + }
> +
> + return 0;
> +}
> +late_initcall(register_cpu_capacity_sysctl);
Hmm, this is really weird. topology_init() in arch/arm/kernel/setup.c
is where these devices get created, and they're created at
subsys_initcall() time. By that point, the list of possible CPUs has
to be static, it's not going to change. I don't see why this has to be
done at late_initcall() - and since topology.c will be linked after
setup.c, I don't see why it shouldn't be at subsys_initcall() level to
follow on after topology_init().
--
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/RFT v2 09/17] regulator: fixed: Add over current event
From: Rob Herring @ 2016-10-30 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-10-ahaslam@baylibre.com>
On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> Some regulator supplies have an over-current pin that is
> activated when the hw detects an over current condition.
> When this happens, the hardware enters a current limited
> mode.
>
> Extend the fixed regulator driver with the ability
> to handle irq's from the over-current pin and report
> an over current event to the consumers via a regulator
> notifier. Also, add device tree bindings to allow to
> pass a gpio for over current monitoring.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> .../bindings/regulator/fixed-regulator.txt | 4 ++
> drivers/regulator/fixed.c | 64 ++++++++++++++++++++++
> include/linux/regulator/consumer.h | 5 ++
> include/linux/regulator/fixed.h | 3 +
> 4 files changed, 76 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> index 4fae41d..d20bf67 100644
> --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> @@ -11,6 +11,8 @@ If this property is missing, the default assumed is Active low.
> - gpio-open-drain: GPIO is open drain type.
> If this property is missing then default assumption is false.
> -vin-supply: Input supply name.
> +- oc-gpio: Input gpio that signals an over current condition
"-gpios" is the preferred form. So "oc-gpios".
> +- oc-active-high: The polarity of the over current pin is high
This should be specified in the gpio flags cell.
Rob
^ permalink raw reply
* [PATCH 5/5] irqchip: st: Remove obsolete platforms from dt binding doc
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-6-git-send-email-patrice.chotard@st.com>
On Fri, Oct 21, 2016 at 05:57:23PM +0200, patrice.chotard at st.com wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> STiH415/6 SoC support is being removed from the kernel.
> This patch updates the sti irchip and removes
> references to these obsolete platforms.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> Cc: <tglx@linutronix.de>
> Cc: <jason@lakedaemon.net>
> Cc: <marc.zyngier@arm.com>
> ---
> .../devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-2-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 04:40:26PM +0200, Neil Armstrong wrote:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/meson/Makefile | 3 +-
> drivers/pinctrl/meson/pinctrl-meson-gxl.c | 589 +++++++++++++++++++++
> drivers/pinctrl/meson/pinctrl-meson.c | 8 +
> drivers/pinctrl/meson/pinctrl-meson.h | 2 +
> include/dt-bindings/gpio/meson-gxl-gpio.h | 131 +++++
> 6 files changed, 734 insertions(+), 1 deletion(-)
> create mode 100644 drivers/pinctrl/meson/pinctrl-meson-gxl.c
> create mode 100644 include/dt-bindings/gpio/meson-gxl-gpio.h
^ permalink raw reply
* [PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477058754-13866-1-git-send-email-krzk@kernel.org>
On Fri, Oct 21, 2016 at 05:05:54PM +0300, Krzysztof Kozlowski wrote:
> The samsung,power-domain property is obsolete since commit 0da658704136
> ("ARM: dts: convert to generic power domain bindings for exynos DT").
> Replace it with generic one.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
You didn't send this To me, so I assume someone else is applying it.
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 01/23] reset: Add renesas,rst DT bindings
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-2-git-send-email-geert+renesas@glider.be>
On Fri, Oct 21, 2016 at 03:17:15PM +0200, Geert Uytterhoeven wrote:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
>
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
>
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
> - Add Acked-by,
> - Fix comma and period in list,
> - Add RZ/G1M and RZ/G1E,
>
> v3:
> - Clarify current usage,
> - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
> - Drop "syscon" compatible value,
> - Add R-Car M3-W,
> - Add R-Car Gen1,
>
> v2:
> - Add Acked-by.
> ---
> .../devicetree/bindings/reset/renesas,rst.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477053961-27128-2-git-send-email-t-kristo@ti.com>
On Fri, Oct 21, 2016 at 03:45:59PM +0300, Tero Kristo wrote:
> Add a clock implementation, TI SCI clock, that will hook to the common
> clock framework, and allow each clock to be controlled via TI SCI
> protocol.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../devicetree/bindings/clock/ti,sci-clk.txt | 37 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> new file mode 100644
> index 0000000..bfc3ca4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> @@ -0,0 +1,37 @@
> +Texas Instruments TI-SCI Clocks
> +===============================
> +
> +All clocks on Texas Instruments' SoCs that contain a System Controller,
> +are only controlled by this entity. Communication between a host processor
> +running an OS and the System Controller happens through a protocol known
> +as TI-SCI[1]. This clock implementation plugs into the common clock
> +framework and makes use of the TI-SCI protocol on clock API requests.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +Required properties:
> +-------------------
> +- compatible: Must be "ti,k2g-sci-clk"
> +- #clock-cells: Shall be 2.
> + In clock consumers, this cell represents the device ID and clock ID
> + exposed by the PM firmware. The assignments can be found in the header
> + files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and
> + <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where <soc>
> + is the SoC involved, for example 'k2g'.
> +
> +Examples:
> +--------
> +
> +pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> +
> + k2g_clks: k2g_clks {
Use "clocks" for node name instead.
> + compatible = "ti,k2g-sci-clk";
I'm starting to think all these child nodes for SCI are pointless. Is
there any reason why the parent node can't be the clock provider (along
with all the other providers it acks as)?
> + #clock-cells = <2>;
> + };
> +};
> +
> +uart0: serial at 2530c00 {
> + compatible = "ns16550a";
> + clocks = <&k2g_clks K2G_DEV_UART0 0>;
> +};
^ permalink raw reply
* [PATCH v2 4/9] regulator: lp873x: Add support for populating input supply
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-5-lokeshvutla@ti.com>
On Fri, Oct 21, 2016 at 04:08:36PM +0530, Lokesh Vutla wrote:
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Keerthy <j-keerthy@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> index 52766c2..998837a 100644
> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> @@ -7,6 +7,9 @@ Required properties:
> - #gpio-cells: Should be two. The first cell is the pin number and
> the second cell is used to specify flags.
> See ../gpio/gpio.txt for more information.
> + - xxx-in-supply: Phandle to parent supply node of each regulator
> + populated under regulators node. xxx should match
> + the supply_name populated in driver.
The driver is irrelevant. This should reference a list in this document.
> - regulators: List of child nodes that specify the regulator
> initialization data.
> Example:
> @@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
> gpio-controller;
> #gpio-cells = <2>;
>
> + buck0-in-supply = <&vsys_3v3>;
> + buck1-in-supply = <&vsys_3v3>;
> + ldo0-in-supply = <&vsys_3v3>;
> + ldo1-in-supply = <&vsys_3v3>;
> +
> regulators {
> lp8733_buck0: buck0 {
> regulator-name = "lp8733-buck0";
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021084445.24989-1-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
It's preferred that bindings are a separate patch.
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
> 4 files changed, 275 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>
> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
> - Drop init/exit callbacks
> - Implement proper remove and PM callback
> - Call init from probe
> - Disable/Unprepare clock if stmmac probe fails
>
> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
> new file mode 100644
> index 0000000..5d2696c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
> @@ -0,0 +1,44 @@
> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
> +
> +The device inherits all the properties of the dwmac/stmmac devices
> +described in the file stmmac.txt in the current directory with the
> +following changes.
> +
> +Required properties on all platforms:
> +
> +- compatible: Depending on the platform this should be one of:
> + - "oxsemi,ox820-dwmac"
> + Additionally "snps,dwmac" and any applicable more
> + detailed version number described in net/stmmac.txt
> + should be used.
You should be explicit what version applies to ox820. "snps,dwmac"
should probably be deprecated IMO. There are so many variations of DW
h/w.
> +
> +- reg: The first register range should be the one of the DWMAC
> + controller.
This is worded like there's a 2nd range?
> +
> +- clocks: Should contain phandles to the following clocks
> +- clock-names: Should contain the following:
> + - "stmmaceth" - see stmmac.txt
> + - "gmac" - peripheral gate clock
> +
> +- oxsemi,sys-ctrl: a phandle to the system controller syscon node
> +
> +Example :
> +
> +etha: ethernet at 40400000 {
> + compatible = "oxsemi,ox820-dwmac", "snps,dwmac";
> + reg = <0x40400000 0x2000>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "macirq", "eth_wake_irq";
> + mac-address = [000000000000]; /* Filled in by U-Boot */
> + phy-mode = "rgmii";
> +
> + clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
> + clock-names = "gmac", "stmmaceth";
> + resets = <&reset RESET_MAC>;
> +
> + /* Regmap for sys registers */
> + oxsemi,sys-ctrl = <&sys>;
> +
> + status = "disabled";
> +};
^ permalink raw reply
* [PATCH v5 3/7] drm: sunxi: add DE2 HDMI support
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <36bd5454897c8ab77749e0294e4a4ecc2450dd12.1477142934.git.moinejf@free.fr>
On Fri, Oct 21, 2016 at 10:08:06AM +0200, Jean-Francois Moine wrote:
> This patch adds a HDMI driver to the DE2 based Allwinner's SoCs
> as A83T and H3.
> Audio and video are supported.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../devicetree/bindings/display/sunxi/hdmi.txt | 52 ++
> drivers/gpu/drm/sunxi/Kconfig | 8 +
> drivers/gpu/drm/sunxi/Makefile | 2 +
> drivers/gpu/drm/sunxi/de2_hdmi.c | 396 +++++++++
> drivers/gpu/drm/sunxi/de2_hdmi.h | 40 +
> drivers/gpu/drm/sunxi/de2_hdmi_io.c | 927 +++++++++++++++++++++
> drivers/gpu/drm/sunxi/de2_hdmi_io.h | 25 +
> 7 files changed, 1450 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.h
> create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.h
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> new file mode 100644
> index 0000000..0558c07
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> @@ -0,0 +1,52 @@
> +Allwinner HDMI Transmitter
> +==========================
> +
> +The Allwinner HDMI transmitters are included in the SoCs.
> +They support audio and video.
> +
> +Required properties:
> + - #address-cells : should be <1>
> + - #size-cells : should be <0>
> + - compatible : should be
> + "allwinner,sun8i-a83t-hdmi" or
> + "allwinner,sun8i-h3-hdmi"
> + - clocks : phandles to the HDMI clocks as described in
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + - clock-names : must be
> + "gate" : bus gate
> + "clock" : streaming clock
> + "ddc-clock" : DDC clock
> + - resets : One or two phandles to the HDMI resets
> + - reset-names : must be
> + "hdmi0" and "hdmi1"
> +
> +Required nodes:
> + - port: Audio and video input port nodes with endpoint definitions
> + as defined in Documentation/devicetree/bindings/graph.txt.
Please define which port number is audio and which is video.
Rob
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8afc5e020c5767face34fe3a9ab300ce9e67ba00.1477142934.git.moinejf@free.fr>
On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> engine, DE2.
> This patch adds a DRM video driver for this device.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../bindings/display/sunxi/sunxi-de2.txt | 83 +++
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/sunxi/Kconfig | 21 +
> drivers/gpu/drm/sunxi/Makefile | 7 +
> drivers/gpu/drm/sunxi/de2_crtc.c | 475 +++++++++++++++++
> drivers/gpu/drm/sunxi/de2_crtc.h | 63 +++
> drivers/gpu/drm/sunxi/de2_de.c | 591 +++++++++++++++++++++
> drivers/gpu/drm/sunxi/de2_drm.h | 47 ++
> drivers/gpu/drm/sunxi/de2_drv.c | 378 +++++++++++++
> drivers/gpu/drm/sunxi/de2_plane.c | 119 +++++
> 11 files changed, 1787 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> create mode 100644 drivers/gpu/drm/sunxi/Kconfig
> create mode 100644 drivers/gpu/drm/sunxi/Makefile
> create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
> create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
> create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> new file mode 100644
> index 0000000..f9cd67a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> + hdmi: hdmi at 01ee0000 {
> + ...
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port {
> + type = "video";
This is proposed, but not an accepted property. Please drop.
> + hdmi_ep: endpoint {
> + remote-endpoint = <&lcd0_ep>;
> + };
> + };
> + };
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Rob Herring @ 2016-10-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025161441.6b248efe9229bd80e3f7a33c@free.fr>
On Tue, Oct 25, 2016 at 04:14:41PM +0200, Jean-Francois Moine wrote:
> On Mon, 24 Oct 2016 16:04:19 +0200
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
>
> Hi Maxime,
>
> > On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> > > Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> > > engine, DE2.
> > > This patch adds a DRM video driver for this device.
> > >
> > > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> >
> > Output from checkpatch:
> > total: 0 errors, 20 warnings, 83 checks, 1799 lines checked
> >
> > > ---
> > > .../bindings/display/sunxi/sunxi-de2.txt | 83 +++
> > > drivers/gpu/drm/Kconfig | 2 +
> > > drivers/gpu/drm/Makefile | 1 +
> > > drivers/gpu/drm/sunxi/Kconfig | 21 +
> > > drivers/gpu/drm/sunxi/Makefile | 7 +
> > > drivers/gpu/drm/sunxi/de2_crtc.c | 475 +++++++++++++++++
> > > drivers/gpu/drm/sunxi/de2_crtc.h | 63 +++
> > > drivers/gpu/drm/sunxi/de2_de.c | 591 +++++++++++++++++++++
> > > drivers/gpu/drm/sunxi/de2_drm.h | 47 ++
> > > drivers/gpu/drm/sunxi/de2_drv.c | 378 +++++++++++++
> > > drivers/gpu/drm/sunxi/de2_plane.c | 119 +++++
> > > 11 files changed, 1787 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> > > create mode 100644 drivers/gpu/drm/sunxi/Kconfig
> > > create mode 100644 drivers/gpu/drm/sunxi/Makefile
> > > create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
> > > create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
> > > create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
> > > create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
> > > create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
> > > create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> > > new file mode 100644
> > > index 0000000..f9cd67a
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
[...]
> > > +
> > > +- resets: phandle to the reset of the device
> > > +
> > > +- ports: phandle's to the LCD ports
> >
> > Please use the OF graph.
>
> These ports are references to the graph of nodes. See
> http://www.kernelhub.org/?msg=911825&p=2
I think what Maxime means is describe the DE to LCD connection with OF
graph, not just a phandle.
Rob
^ permalink raw reply
* [PATCH 1/2] ABI: rtc-ab8500: fix rtc_calibration documentation
From: Alexandre Belloni @ 2016-10-30 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <364a36215c44e0c2785911e9d9259cd866283cb9.1477735797.git.mchehab@s-opensource.com>
On 29/10/2016 at 08:10:02 -0200, Mauro Carvalho Chehab wrote :
> The "What:" field at the ABI should describe the location of
> the ABI, e. g. the position under a mounted sysfs.
>
> Fix it.
>
> Cc: Mark Godfrey <mark.godfrey@stericsson.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alessandro Zummo <a.zummo@towertech.it>
> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: rtc-linux at googlegroups.com
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> .../ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RFC] fpga: Pull checks for supported operations into framework
From: Moritz Fischer @ 2016-10-30 18:12 UTC (permalink / raw)
To: linux-arm-kernel
Most of the drivers only support a subset of {PARTIAL, FULL}
reconfiguration.
Pull duplicate checks in each driver into the framework.
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Alan Tull <atull@opensource.altera.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
Hi all,
with the new drivers (ice40, altera-ps-spi) being submitted I've noticed
we're duplicating this check over and over again,
so I figured we might as well pull it into the framework.
I'm not sure if there are gonna be other 'flags' we need to support
in the short term (we talked about byte-swapping ...)
Note: This patch goes on top of greg's char-misc-testing that already
contains Alan's latest changes to support the A10 and won't apply
to master.
Cheers,
Moritz
---
drivers/fpga/fpga-mgr.c | 12 ++++++++++++
drivers/fpga/socfpga-a10.c | 4 +++-
drivers/fpga/socfpga.c | 3 ++-
drivers/fpga/zynq-fpga.c | 3 ++-
include/linux/fpga/fpga-mgr.h | 9 +++++++--
5 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index c58b4c4..85f17d8 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -49,6 +49,11 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, struct fpga_image_info *info,
struct device *dev = &mgr->dev;
int ret;
+ if (!(mgr->supported_flags & info->flags)) {
+ dev_err(dev, "Unsupported flags passed\n");
+ return -ENOTSUPP;
+ }
+
/*
* Call the low level driver's write_init function. This will do the
* device-specific things to get the FPGA into the state where it is
@@ -252,6 +257,7 @@ EXPORT_SYMBOL_GPL(fpga_mgr_put);
*/
int fpga_mgr_register(struct device *dev, const char *name,
const struct fpga_manager_ops *mops,
+ u32 supported_flags,
void *priv)
{
struct fpga_manager *mgr;
@@ -268,6 +274,11 @@ int fpga_mgr_register(struct device *dev, const char *name,
return -EINVAL;
}
+ if (!supported_flags) {
+ dev_err(dev, "Attempt to register with no supported flags\n");
+ return -EINVAL;
+ }
+
mgr = kzalloc(sizeof(*mgr), GFP_KERNEL);
if (!mgr)
return -ENOMEM;
@@ -282,6 +293,7 @@ int fpga_mgr_register(struct device *dev, const char *name,
mgr->name = name;
mgr->mops = mops;
+ mgr->supported_flags = supported_flags;
mgr->priv = priv;
/*
diff --git a/drivers/fpga/socfpga-a10.c b/drivers/fpga/socfpga-a10.c
index ccd9fb2..e7c82ff 100644
--- a/drivers/fpga/socfpga-a10.c
+++ b/drivers/fpga/socfpga-a10.c
@@ -519,7 +519,9 @@ static int socfpga_a10_fpga_probe(struct platform_device *pdev)
}
return fpga_mgr_register(dev, "SoCFPGA Arria10 FPGA Manager",
- &socfpga_a10_fpga_mgr_ops, priv);
+ &socfpga_a10_fpga_mgr_ops,
+ FPGA_MGR_PARTIAL_RECONFIG,
+ priv);
}
static int socfpga_a10_fpga_remove(struct platform_device *pdev)
diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
index b6672e6..3285b7d 100644
--- a/drivers/fpga/socfpga.c
+++ b/drivers/fpga/socfpga.c
@@ -582,7 +582,8 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
return ret;
return fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager",
- &socfpga_fpga_ops, priv);
+ &socfpga_fpga_ops, FPGA_MGR_FULL_RECONFIG,
+ priv);
}
static int socfpga_fpga_remove(struct platform_device *pdev)
diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
index 249682e..1dabd25 100644
--- a/drivers/fpga/zynq-fpga.c
+++ b/drivers/fpga/zynq-fpga.c
@@ -413,6 +413,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
struct zynq_fpga_priv *priv;
struct resource *res;
int err;
+ u32 flags = FPGA_MGR_FULL_RECONFIG | FPGA_MGR_PARTIAL_RECONFIG;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -465,7 +466,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
clk_disable(priv->clk);
err = fpga_mgr_register(dev, "Xilinx Zynq FPGA Manager",
- &zynq_fpga_ops, priv);
+ &zynq_fpga_ops, flags, priv);
if (err) {
dev_err(dev, "unable to register FPGA manager");
clk_unprepare(priv->clk);
diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index 040b86d..4f4bcf2 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -64,9 +64,12 @@ enum fpga_mgr_states {
/*
* FPGA Manager flags
+ * FPGA_MGR_FULL_RECONFIG: do full reconfiguration if supported
* FPGA_MGR_PARTIAL_RECONFIG: do partial reconfiguration if supported
*/
-#define FPGA_MGR_PARTIAL_RECONFIG BIT(0)
+#define FPGA_MGR_FULL_RECONFIG BIT(0)
+#define FPGA_MGR_PARTIAL_RECONFIG BIT(1)
+#define FPGA_MGR_EXTERNAL_CONFIG BIT(2)
/**
* struct fpga_image_info - information specific to a FPGA image
@@ -119,6 +122,7 @@ struct fpga_manager {
enum fpga_mgr_states state;
const struct fpga_manager_ops *mops;
void *priv;
+ u32 supported_flags;
};
#define to_fpga_manager(d) container_of(d, struct fpga_manager, dev)
@@ -135,7 +139,8 @@ struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
void fpga_mgr_put(struct fpga_manager *mgr);
int fpga_mgr_register(struct device *dev, const char *name,
- const struct fpga_manager_ops *mops, void *priv);
+ const struct fpga_manager_ops *mops, u32 supported_flags,
+ void *priv);
void fpga_mgr_unregister(struct device *dev);
--
2.4.11
^ permalink raw reply related
* [PATCH V2 2/2] ARM: dts: bcm283x: fix typo in mailbox address
From: Stefan Wahren @ 2016-10-30 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b13e96d-78d1-fcab-4273-803310ae4da6@suse.de>
The address of the mailbox node in the bcm283x.dtsi also has a typo.
So fix it accordingly.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Andreas F?rber <afaerber@suse.de>
Fixes: 05b682b7a3b2 ("ARM: bcm2835: dt: Add the mailbox to the device tree")
---
Changes in V2:
* fixed commit message as reported by Andreas
arch/arm/boot/dts/bcm283x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 46d46d8..74dd21b 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -104,7 +104,7 @@
reg = <0x7e104000 0x10>;
};
- mailbox: mailbox at 7e00b800 {
+ mailbox: mailbox at 7e00b880 {
compatible = "brcm,bcm2835-mbox";
reg = <0x7e00b880 0x40>;
interrupts = <0 1>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/4] mfd: ti_am335x_tscadc: store physical address
From: Jonathan Cameron @ 2016-10-30 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026121730.GS8574@dell>
On 26/10/16 13:17, Lee Jones wrote:
> On Fri, 30 Sep 2016, Mugunthan V N wrote:
>
>> On Wednesday 28 September 2016 01:10 AM, Lee Jones wrote:
>>> On Wed, 21 Sep 2016, Mugunthan V N wrote:
>>>
>>>> store the physical address of the device in its priv to use it
>>>> for DMA addressing in the client drivers.
>>>>
>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>>>> ---
>>>> drivers/mfd/ti_am335x_tscadc.c | 1 +
>>>> include/linux/mfd/ti_am335x_tscadc.h | 1 +
>>>> 2 files changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
>>>> index c8f027b..0f3fab4 100644
>>>> --- a/drivers/mfd/ti_am335x_tscadc.c
>>>> +++ b/drivers/mfd/ti_am335x_tscadc.c
>>>> @@ -183,6 +183,7 @@ static int ti_tscadc_probe(struct platform_device *pdev)
>>>> tscadc->irq = err;
>>>>
>>>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> + tscadc->tscadc_phys_base = res->start;
>>>
>>> This is unusual. Can't you use a virt_to_phys() variant instead?
>>>
>>
>> I tried using virt_to_phys(), but its not working for me.
>> Also saw many drivers uses like this to get physical address
>> ("git grep -n " res->start;" drivers/*").
>
> Very well:
>
> For my own reference:
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
>
> Let me know how you wish this set to be handled.
I'm happy to pick up the whole series. There are some more mfd
header changes in patch 2 but as they only add defines, I
don't mind that much if I don't an Ack from you on those
(btw this got to V3 but as patch 1 didn't change I'll carry
your ack forwards).
Do you want an immutable branch? Seems unlikely to cause
much trouble even if there is a merge issue on all 10ish
lines of mfd code in the next merge window.
Jonathan
>
^ 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