* Re: [PATCH 3/9] arm64: mm: install SError abort handler
From: Florian Fainelli @ 2017-03-24 19:02 UTC (permalink / raw)
To: Mark Rutland
Cc: Doug Berger, catalin.marinas-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, will.deacon-5wv7dgnIgG8,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA, james.morse-5wv7dgnIgG8,
vladimir.murzin-5wv7dgnIgG8, panand-H+wXaHxf7aLQT0dZR+AlfA,
andre.przywara-5wv7dgnIgG8, cmetcalf-VPRAkNaXOzVWk0Htik3J/w,
mingo-DgEjT+Ai2ygdnm+yROfE0A,
sandeepa.s.prabhu-Re5JQEeQqe8AvxtiuMwx3w,
shijie.huang-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
olof-nZhT3qVonbNeoWH0uzbU5w, mirza.krak-Re5JQEeQqe8AvxtiuMwx3w,
suzuki.poulose-5wv7dgnIgG8, bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
marc.zyngier-5wv7dgnIgG8
In-Reply-To: <20170324183051.GD10746@leverpostej>
On 03/24/2017 11:31 AM, Mark Rutland wrote:
> Hi Florian,
>
> On Fri, Mar 24, 2017 at 10:53:48AM -0700, Florian Fainelli wrote:
>> On 03/24/2017 10:35 AM, Mark Rutland wrote:
>>> On Fri, Mar 24, 2017 at 09:48:40AM -0700, Doug Berger wrote:
>>>> On 03/24/2017 08:16 AM, Mark Rutland wrote:
>>>>> On Fri, Mar 24, 2017 at 07:46:26AM -0700, Doug Berger wrote:
>>>
>>>> If you would consider an alternative implementation where we scrap
>>>> the SError handler (i.e. maintain the ugliness in our downstream
>>>> kernel) in favor of a more gentle user mode crash on SError that
>>>> allows the kernel the opportunity to service the interrupt for
>>>> diagnostic purposes I could try to repackage that.
>>>
>>> If this is just for diagnostic purposes, I believe you can register a
>>> panic notifier, which can then read from the bus. The panic will occur,
>>> but you'll have the opportunity to log some information to dmesg.
>>
>> And crash the kernel? That sounds awful, FWIW the ARM/Linux kernel is
>> able to recover just fine from user-space accessing e.g: invalid
>> physical addresses in the GISB register space, bringing the same level
>> of functionality to ARM64/Linux sounds reasonable to me.
>
> I disagree, given that:
>
> (a) You cannot determine the (HW) origin of the SError in an
> architecturally portable way. i.e. when you take an SError, you have
> no way of determining what asynchronous event caused it.
>
> (b) SError is effectively an edge-triggered interrupt for fatal system
> errors (e.g. it may be triggered in resonse to ECC errors,
> corruption detected in caches, etc). Even if you can determine that
> the GISB triggered *an* SError, this does not tell you that this was
> the *only* SError.
Correct, which is why Doug's changes allow chaining of handlers.
>
> If you take an SError, something bad has already happened. Your data
> may already have been corrupted, and worse, you don't know when or
> where specifically this occurred (nor how many times).
Sure, but that still allows you to send the correct signal to a faulting
application (unless I am missing something here).
>
> (c) You cannot determine the (SW) origin of an SError without relying
> upon implementation details. This cannot be written in a way that
> does not rely on microarchitecture, integration, etc, and would need
> to be updated for every future system with this misfeature.
Which is exactly what is being done here, with the help of platform
specific information (we would not load brcmstb_gisb.c if we were not on
a platform where it makes sense to use that HW).
>
> (d) Even if you can determine the (SW) origin of an SError by relying on
> IMPLEMENTATION DEFINED details, your handler needs to be intimately
> familiar with the arch in question in order to attempt to recover.
>
> For example, the existing code tries to skip an ARM instruction in
> some cases. For arm64 there are three cases that would need to be
> handled (AArch64 A64, AArch32 A32/ARM, AArch32 T32/Thumb).
>
> Further, it appears to me that the existing code is broken given
> that it doesn't handle Thumb, and given that it's skipping an
> instruction in response to an asynchronous event -- i.e. some
> arbitrary instruction after the one which triggered the abort.
OK, that could presumably be fixed though.
>
> For better or worse, SError *must* be treated as fatal.
I disagree here, since this is a platform specific SError exception that
we can actually handle correctly there is a chance to actually not take
down the system on something that can be made non fatal and informative
at the same time.
>
> As Doug stated:
>
> The main benefit is to help debug user mode code that accidentally
> maps a bad address since we would never make such an egregious error
> in the kernel ;)
>
> This is just one of many ways a userspace application with direct HW
> access can bring down the system. I see no reason to treat it any
> differently, especially given the above points.
Partially disagree, in the absence of a way to specifically deal with
the exception, I would almost agree, but this is not the case here, we
have a piece of HW that can help us locate the problem, display an
informative message, and send a SIGBUS to the faulting application.
Anyway, I won't argue much further than that, but I certainly don't
think taking down an entire system is going to prove itself useful when
you need to deploy such a kernel to hundreds of people who have no clue
what so ever what their actual problem is in the first place. Taking a
SIGBUS and printing a message can at least allow us to say: read more
carefully, it say exactly what's wrong.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL
From: Kevin Hilman @ 2017-03-24 19:20 UTC (permalink / raw)
To: Neil Armstrong
Cc: sboyd-sgV2jX0FEOL9JmXXK+q4OQ, carlo-KA+7E9HrN00dnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490177935-9646-4-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>
> The node is simply added in the meson-gxbb.dtsi file.
>
> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> dtsi files.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
LGTM, I can apply this when the clk driver changes are merged (feel free
to let me know when that happens, in case I'm not paying attention.)
<bikeshed>
nit: This series (and previous ones) use MALI, but I believe the correct
way is Mali. Could you standarize on that throughout the series?
</bikeshed>
Kevin
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 37 ++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi | 43 ++++++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi | 1 +
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 1 +
> 4 files changed, 82 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 04b3324..0617a3d 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -478,6 +478,43 @@
> };
> };
>
> +&apb {
> + mali: gpu@c0000 {
> + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> + reg = <0x0 0xc0000 0x0 0x40000>;
> + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> + "pp0", "ppmmu0", "pp1", "ppmmu1",
> + "pp2", "ppmmu2";
> + clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
> + clock-names = "bus", "core";
> +
> + /*
> + * Mali clocking is provided by two identical clock paths
> + * MALI_0 and MALI_1 muxed to a single clock by a glitch
> + * free mux to safely change frequency while running.
> + */
> + assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
> + <&clkc CLKID_MALI_0>,
> + <&clkc CLKID_MALI>; /* Glitch free mux */
> + assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
> + <0>, /* Do Nothing */
> + <&clkc CLKID_MALI_0>;
> + assigned-clock-rates = <0>, /* Do Nothing */
> + <666666666>,
> + <0>; /* Do Nothing */
> + };
> +};
> +
> &i2c_A {
> clocks = <&clkc CLKID_I2C>;
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> new file mode 100644
> index 0000000..f06cc234
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright (c) 2017 BayLibre SAS
> + * Author: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +&apb {
> + mali: gpu@c0000 {
> + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> + reg = <0x0 0xc0000 0x0 0x40000>;
> + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> + "pp0", "ppmmu0", "pp1", "ppmmu1",
> + "pp2", "ppmmu2";
> + clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
> + clock-names = "bus", "core";
> +
> + /*
> + * Mali clocking is provided by two identical clock paths
> + * MALI_0 and MALI_1 muxed to a single clock by a glitch
> + * free mux to safely change frequency while running.
> + */
> + assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
> + <&clkc CLKID_MALI_0>,
> + <&clkc CLKID_MALI>; /* Glitch free mux */
> + assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
> + <0>, /* Do Nothing */
> + <&clkc CLKID_MALI_0>;
> + assigned-clock-rates = <0>, /* Do Nothing */
> + <666666666>,
> + <0>; /* Do Nothing */
> + };
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> index 615308e..5a90e30 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> @@ -42,6 +42,7 @@
> */
>
> #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>
> / {
> compatible = "amlogic,s905d", "amlogic,meson-gxl";
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> index 08237ee..0f78d83 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> @@ -42,6 +42,7 @@
> */
>
> #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>
> / {
> compatible = "amlogic,s905x", "amlogic,meson-gxl";
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/5] firmware: Add coreboot device tree binding documentation
From: Julius Werner @ 2017-03-24 19:32 UTC (permalink / raw)
To: Brian Norris
Cc: Mark Rutland, Thierry Escande, Rob Herring, Greg Kroah-Hartman,
Olof Johansson, Stephen Warren, LKML, devicetree@vger.kernel.org,
Julius Werner
In-Reply-To: <20170324175727.GB119093@google.com>
[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]
>
> > Devicetree bindings should be in vendor,prefix format. This doesn't
> > represent every aspect of coreboot, so it needs a more descriptive
> > string.
>
> Any particular suggestion? I suppose this is Google's interpretation of
> coreboot tables, so "google,coreboot"?
No. This binding is for the coreboot project in general and has nothing to
do with Google. coreboot is both the vendor and the product, so I think
"coreboot" would look better than "coreboot,coreboot". And yes, it is
supposed to represent every aspect of coreboot (right now the "coreboot
tables" are already sort of a catch-all data structure used by coreboot to
pass on any sort of info it wants later stages to know... and if we ever
have any additional things we'd like to pass on, we'd probably want to add
them to this binding as well).
> > > + - reg: Address and length of the following two memory regions, in
> order:
> > > + 1.) The coreboot table. This is a list of variable-sized
> descriptors
> > > + that contain various compile- and run-time generated firmware
> > > + parameters. It is identified by the magic string "LBIO" in its
> first
> > > + four bytes.
> > > + See coreboot's src/commonlib/include/commonlib/coreboot_tables.h
> for
> > > + details.
> >
> > Given this is a memory region, it should be described under the
> > reserved-memory node.
>
> We've painted this bikeshed before. I guess the result was either to use
> /reserved-memory or /memreserve/. I believe we've been using
> /memreserve/. I suppose we could document a method to use either, but
> the main "agreement" was to use the /firmware/coreboot path instead of
> /reserved-memory/coreboot.
>
See the old thread Brian linked for some arguments for and against this. I
think particularly because we want this node to represent every aspect of
coreboot (which I think makes more sense than spreading stuff all over the
place), treating it as reserved memory would not work well if we might
later add other fields.
Also, since we didn't get any more responses the last time we tried to
upstream this and had schedules to keep, we had to go ahead with what we
had. So right now there are already millions of devices shipped with this
binding in firmware, and the only question we still have left to decide is
whether Linux wants to support them upstream or not.
[-- Attachment #2: Type: text/html, Size: 3062 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] firmware: Add coreboot device tree binding documentation
From: Julius Werner @ 2017-03-24 19:33 UTC (permalink / raw)
To: Julius Werner
Cc: Brian Norris, Mark Rutland, Thierry Escande, Rob Herring,
Greg Kroah-Hartman, Olof Johansson, Stephen Warren, LKML,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAODwPW94vsaWF8+DrLduWhHpbBvdvynbDocXCv2ekZH178BHjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
...and again in plaintext, sorry about that.
On Fri, Mar 24, 2017 at 12:32 PM, Julius Werner <jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> > Devicetree bindings should be in vendor,prefix format. This doesn't
>> > represent every aspect of coreboot, so it needs a more descriptive
>> > string.
>>
>> Any particular suggestion? I suppose this is Google's interpretation of
>> coreboot tables, so "google,coreboot"?
>
>
> No. This binding is for the coreboot project in general and has nothing to
> do with Google. coreboot is both the vendor and the product, so I think
> "coreboot" would look better than "coreboot,coreboot". And yes, it is
> supposed to represent every aspect of coreboot (right now the "coreboot
> tables" are already sort of a catch-all data structure used by coreboot to
> pass on any sort of info it wants later stages to know... and if we ever
> have any additional things we'd like to pass on, we'd probably want to add
> them to this binding as well).
>
>>
>> > > + - reg: Address and length of the following two memory regions, in
>> > > order:
>> > > + 1.) The coreboot table. This is a list of variable-sized
>> > > descriptors
>> > > + that contain various compile- and run-time generated firmware
>> > > + parameters. It is identified by the magic string "LBIO" in its
>> > > first
>> > > + four bytes.
>> > > + See coreboot's src/commonlib/include/commonlib/coreboot_tables.h
>> > > for
>> > > + details.
>> >
>> > Given this is a memory region, it should be described under the
>> > reserved-memory node.
>>
>> We've painted this bikeshed before. I guess the result was either to use
>> /reserved-memory or /memreserve/. I believe we've been using
>> /memreserve/. I suppose we could document a method to use either, but
>> the main "agreement" was to use the /firmware/coreboot path instead of
>> /reserved-memory/coreboot.
>
>
> See the old thread Brian linked for some arguments for and against this. I
> think particularly because we want this node to represent every aspect of
> coreboot (which I think makes more sense than spreading stuff all over the
> place), treating it as reserved memory would not work well if we might later
> add other fields.
>
> Also, since we didn't get any more responses the last time we tried to
> upstream this and had schedules to keep, we had to go ahead with what we
> had. So right now there are already millions of devices shipped with this
> binding in firmware, and the only question we still have left to decide is
> whether Linux wants to support them upstream or not.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/4] RK3399 dw-mipi-dsi patches
From: Sean Paul @ 2017-03-24 19:38 UTC (permalink / raw)
To: Chris Zhong
Cc: Mark Rutland, devicetree, linux-kernel, dri-devel, linux-rockchip,
Rob Herring, linux-arm-kernel
In-Reply-To: <1490147691-4489-1-git-send-email-zyw@rock-chips.com>
On Wed, Mar 22, 2017 at 09:54:47AM +0800, Chris Zhong wrote:
> Hi all
>
> This series set the phy_cfg_clk to be a required clock for RK3399, and
> add a grf clock control in dw-mipi-dsi driver. And then correct a
> register name.
>
Applied to drm-misc
Thanks,
Sean
>
> Changes in v4:
> - remove "additional"
> - print the err after clk_prepare_enable(dsi->grf_clk)
>
> Changes in v3:
> - add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399
> - add a DW_MIPI_NEEDS_GRF_CLK for RK3399
>
> Changes in v2:
> - check the grf_clk only for RK3399
>
> Chris Zhong (4):
> drm/rockchip/dsi: check phy_cfg_clk only for RK3399
> dt-bindings: add the grf clock for dw-mipi-dsi
> drm/rockchip/dsi: enable the grf clk before writing grf registers
> drm/rockchip/dsi: correct the grf_switch_reg name
>
> .../display/rockchip/dw_mipi_dsi_rockchip.txt | 2 +-
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 42 +++++++++++++++++-----
> 2 files changed, 35 insertions(+), 9 deletions(-)
>
> --
> 2.6.3
>
--
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 5/5] firmware: google memconsole: Add ARM/ARM64 support
From: Julius Werner @ 2017-03-24 19:50 UTC (permalink / raw)
To: Mark Rutland
Cc: Thierry Escande, Rob Herring, Greg Kroah-Hartman, Olof Johansson,
Stephen Warren, LKML,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Julius Werner,
Brian Norris
In-Reply-To: <20170324122858.GF22771@leverpostej>
> What exactly is the "memory console"? Is it a log that coreboot writes into?
Yes. It contains log messages, like coreboot's equivalent of dmesg.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/8] pinctrl: meson: add audio output pins
From: Kevin Hilman @ 2017-03-24 19:52 UTC (permalink / raw)
To: Jerome Brunet
Cc: Linus Walleij, Carlo Caione, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170323165101.29262-1-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> This patchset adds the pinctrl definition and the related device-tree
> bindings of the i2s output and spdif output pins on the meson gxbb and
> gxl SoCs.
>
> This is part of the ongoing work to bring audio output suppot on the
> meson family. It was tested on the gxbb p200 and gxl p230.
Series looks good to me,
However, I'm not sure about Linus's preference, but most maintainers
(myself included) prefer a small description in the changelog, even if
it restates (with slightly more description) what's already in the
$SUBJECT.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5] hwmon: ads7828 optional parameters from the device tree
From: Guenter Roeck @ 2017-03-24 19:55 UTC (permalink / raw)
To: Rob Herring
Cc: Sam Povilus, Wolfram Sang, jdelvare, linux-hwmon, linux-i2c,
devicetree, mark.rutland
In-Reply-To: <20170324161003.hv2bqpyspjdkx5j4@rob-hp-laptop>
On Fri, Mar 24, 2017 at 11:10:03AM -0500, Rob Herring wrote:
> On Wed, Mar 22, 2017 at 07:05:55AM -0600, Sam Povilus wrote:
> > On Wed, Mar 22, 2017 at 09:42:40AM +0100, Wolfram Sang wrote:
> > >
> > > > .../devicetree/bindings/i2c/trivial-devices.txt | 2 --
> > >
> > > This file is about to get moved one directory up:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/commit/?h=dt/next&id=b7e252fcddfa573bb1ee275b53bba6cef85671d4
> > >
> > > Just so you know already...
> > >
> >
> > Thanks! I'm a bit new to this, what's the best way for me to handle
> > this? Submit against Linus' tree (presumably making a merge nightmare
> > for someone) or rebase my branch off robh's (and presumably risking some
> > other branch's patch conflicting)?
>
> Send me a separate patch for just this file and I'll pick it up.
>
Agreed, that seems to be the best approach.
Thanks,
Guenter
^ permalink raw reply
* Re: [RESEND PATCH v2 00/53] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
From: Boris Brezillon @ 2017-03-24 20:13 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
laurent.monat-1zQW0WpQGTYgLlGVC3PcNw,
thorsten.christiansson-1zQW0WpQGTYgLlGVC3PcNw, Enrico Jorns,
Artem Bityutskiy, Dinh Nguyen, Marek Vasut, Graham Moore,
David Woodhouse, Masami Hiramatsu, Chuanxiao Dong, Jassi Brar,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland
In-Reply-To: <1490213273-8571-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Hi Masahiro,
On Thu, 23 Mar 2017 05:06:59 +0900
Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> wrote:
> It took a couple months to update this series, but finally here is v2.
> (v1: https://lkml.org/lkml/2016/11/26/144 )
>
> This driver includes many problems.
>
> One of the biggest one is a bunch of hard-coded parameters. This IP
> has many parameters that can be customized when a delivery RTL is
> generated. However, this driver was upstreamed by Intel, with
> Intel parameters hard-coded. Later, Altera added denali_dt.c to use
> this driver for embedded boards, but they did not fix the code in
> denali.c So, this driver has never worked. Even some DT bindings
> actually turned out wrong.
>
> There are more problems: [1] The driver just retrieves the OOB area as-is
> whereas the controller uses syndrome page layout. [2] Many NAND chip
> specific parameters are hard-coded in the driver. [3] ONFi devices are
> not working [4] It can not read Bad Block Marker
>
> This patch series intends to solve those problems.
>
> Since v1, here are more fixes/improvements:
> - Fix raw/oob callbacks for syndrome page layout
> - Implement setup_data_interface() callback
> - Fix/implement more commands for ONFi devices
> - Allow to skip the driver internal bounce buffer
> - Support PIO in case DMA is not supported
> - Switch from ->cmdfunc over to ->cmd_ctrl
>
>
> Masahiro Yamada (53):
> mtd: nand: allow to set only one of ECC size and ECC strength from DT
> mtd: nand: use read_oob() instead of cmdfunc() for bad block check
> mtd: nand: denali: remove unused CONFIG option and macros
> mtd: nand: denali: remove redundant define of BANK(x)
> mtd: nand: denali: remove more unused struct members
> mtd: nand: denali: fix comment of denali_nand_info::flash_mem
> mtd: nand: denali: consolidate INTR_STATUS__* and INTR_EN__* macros
> mtd: nand: denali: introduce capability flag
> mtd: nand: denali: use int where no reason to use fixed width variable
> mtd: nand: denali: fix erased page checking
> mtd: nand: denali: fix bitflips calculation in handle_ecc()
> mtd: nand: denali: support HW_ECC_FIXUP capability
> mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant
> mtd: nand: denali: support 64bit capable DMA engine
> mtd: nand: denali_dt: remove dma-mask DT property
> mtd: nand: denali_dt: use pdev instead of ofdev for platform_device
> mtd: nand: denali: allow to override revision number
> mtd: nand: denali: use nand_chip to hold frequently accessed data
> mtd: nand: denali: call nand_set_flash_node() to set DT node
> mtd: nand: denali: do not set mtd->name
> mtd: nand: denali: move multi device fixup code to a helper function
> mtd: nand: denali: simplify multi device fixup code
> mtd: nand: denali: set DEVICES_CONNECTED 1 if not set
> mtd: nand: denali: remove meaningless writes to read-only registers
> mtd: nand: denali: remove unnecessary writes to ECC_CORRECTION
> mtd: nand: denali: support 1024 byte ECC step size
> mtd: nand: denali: avoid hard-coding ecc.strength and ecc.bytes
> mtd: nand: denali: support "nand-ecc-strength" DT property
> mtd: nand: denali: remove Toshiba and Hynix specific fixup code
> mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
> mtd: nand: denali: set NAND_ECC_CUSTOM_PAGE_ACCESS
> mtd: nand: denali: do not propagate NAND_STATUS_FAIL to waitfunc()
> mtd: nand: denali: use BIT() and GENMASK() for register macros
> mtd: nand: denali: remove unneeded find_valid_banks()
> mtd: nand: denali: handle timing parameters by setup_data_interface()
> mtd: nand: denali: remove meaningless pipeline read-ahead operation
> mtd: nand: denali: rework interrupt handling
> mtd: nand: denali: fix NAND_CMD_STATUS handling
> mtd: nand: denali: fix NAND_CMD_PARAM handling
> mtd: nand: do not check R/B# for CMD_READID in nand_command(_lp)
> mtd: nand: do not check R/B# for CMD_SET_FEATURES in nand_command(_lp)
> mtd: nand: denali: switch over to cmd_ctrl instead of cmdfunc
> mtd: nand: denali: fix bank reset function
> mtd: nand: denali: use interrupt instead of polling for bank reset
> mtd: nand: denali: propagate page to helpers via function argument
> mtd: nand: denali: merge struct nand_buf into struct denali_nand_info
> mtd: nand: denali: use flag instead of register macro for direction
> mtd: nand: denali: fix raw and oob accessors for syndrome page layout
> mtd: nand: denali: support hardware-assisted erased page detection
> mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset
> mtd: nand: denali: skip driver internal bounce buffer when possible
> mtd: nand: denali: use non-managed kmalloc() for DMA buffer
> mtd: nand: denali: enable bad block table scan
Applied patch 1 to 9, 40 and 41. I'll see what else I can apply so that
you don't have to re-post the remaining 42 patches, but I fear some of
them won't apply correctly without patch 10 on which I had comments.
Thanks,
Boris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 1/2] mfd: cpcap: Add missing include dependencies
From: Jacek Anaszewski @ 2017-03-24 20:44 UTC (permalink / raw)
To: Sebastian Reichel, Richard Purdie, Pavel Machek, Lee Jones
Cc: Tony Lindgren, Rob Herring, Mark Rutland, linux-leds, devicetree,
linux-kernel
In-Reply-To: <20170324084732.31255-1-sre@kernel.org>
Hi Sebastianm
On 03/24/2017 09:47 AM, Sebastian Reichel wrote:
> This fixes compilation for files, that try to include the
> cpcap header in alphabetically sorted #include lists.
>
> Acked-by: Pavel Machek <pavel@ucw.cz>
> Acked-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
> Changes since PATCHv2:
> - Add Acked-by from Tony & Pavel
> ---
> include/linux/mfd/motorola-cpcap.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/mfd/motorola-cpcap.h b/include/linux/mfd/motorola-cpcap.h
> index 793aa695faa0..aefc49cb7ba9 100644
> --- a/include/linux/mfd/motorola-cpcap.h
> +++ b/include/linux/mfd/motorola-cpcap.h
> @@ -14,6 +14,9 @@
> * published by the Free Software Foundation.
> */
>
> +#include <linux/device.h>
> +#include <linux/regmap.h>
> +
> #define CPCAP_VENDOR_ST 0
> #define CPCAP_VENDOR_TI 1
>
>
Both patches applied to the for-next branch of linux-leds.git, thanks.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCHv2] power: supply: cpcap-charger: Add minimal CPCAP PMIC battery charger
From: Sebastian Reichel @ 2017-03-24 21:04 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Michael Scott
In-Reply-To: <20170324140807.GW10760-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
Hi,
On Fri, Mar 24, 2017 at 07:08:07AM -0700, Tony Lindgren wrote:
> > s->battdetb = cpcap_sense_virq(ddata->reg, ddata->irq_battdetb);
> > (and so on)
> >
> > looks cleaner IMHO.
>
> I figured I'll do a follow up patch for when available to remove
> dependencies between subsystems.
Ok. I'm fine with that.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v11 01/10] devicetree: power: Add battery.txt
From: Liam Breck @ 2017-03-24 21:11 UTC (permalink / raw)
To: Rob Herring
Cc: Andrew F. Davis, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170324155531.gn6iw6w3f5nqbpnx@rob-hp-laptop>
Hi Rob,
On Fri, Mar 24, 2017 at 8:55 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Mon, Mar 20, 2017 at 02:43:26AM -0700, Liam Breck wrote:
>> From: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
>>
>> Documentation of static battery characteristics that can be defined
>> for batteries which cannot self-identify. This information is required
>> by fuel-gauge and charger chips for proper handling of the battery.
>>
>> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
>> Signed-off-by: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
>> ---
>> .../devicetree/bindings/power/supply/battery.txt | 43 ++++++++++++++++++++++
>> 1 file changed, 43 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/supply/battery.txt
>
> While "simple" is not generally something I like to see in a compatible
> string, we've beat this one to death.
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks. Are you in agreement with Sebastian on the following, or is
this OK to include?
On Thu, Mar 23, 2017 at 3:20 AM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> +Battery properties are named, where possible, for the corresponding
>> +elements in enum power_supply_property, defined in
>> +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h#n86
>
>The above paragraph does not belong into DT bindings.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/8] pinctrl: meson: add audio output pins
From: Jerome Brunet @ 2017-03-24 21:23 UTC (permalink / raw)
To: Kevin Hilman, Linus Walleij
Cc: devicetree, linux-kernel, linux-gpio, Carlo Caione, linux-amlogic,
linux-arm-kernel
In-Reply-To: <m2wpbeh2pf.fsf@baylibre.com>
On Fri, 2017-03-24 at 12:52 -0700, Kevin Hilman wrote:
> Jerome Brunet <jbrunet@baylibre.com> writes:
>
> > This patchset adds the pinctrl definition and the related device-tree
> > bindings of the i2s output and spdif output pins on the meson gxbb and
> > gxl SoCs.
> >
> > This is part of the ongoing work to bring audio output suppot on the
> > meson family. It was tested on the gxbb p200 and gxl p230.
>
> Series looks good to me,
>
> However, I'm not sure about Linus's preference, but most maintainers
> (myself included) prefer a small description in the changelog, even if
> it restates (with slightly more description) what's already in the
> $SUBJECT.
Understood. thanks for pointing it out.
This series was going to clash with Neil's pinctrl fixes anyway.
I'll respin it taking this into account.
>
> Kevin
^ permalink raw reply
* Re: [PATCH] of: add stub for of_n_addr_cells
From: Arnd Bergmann @ 2017-03-24 21:23 UTC (permalink / raw)
To: Tobias Regnery
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, Simon Horman
In-Reply-To: <20170324103940.30902-1-tobias.regnery-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Mar 24, 2017 at 11:39 AM, Tobias Regnery
<tobias.regnery-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> With CONFIG_OF=n and CONFIG_COMPILE_TEST=y the rcar pci-e driver fails to
> build on arm:
>
> drivers/pci/host/pcie-rcar.c: In function 'pci_dma_range_parser_init':
> drivers/pci/host/pcie-rcar.c:1035:16: error: implicit declaration of function 'of_n_addr_cells' [-Werror=implicit-function-declaration]
> parser->pna = of_n_addr_cells(node);
> ^~~~~~~~~~~~~~~
>
> Fix this by adding an inline stub for of_n_addr_cells
>
> Signed-off-by: Tobias Regnery <tobias.regnery-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> This is against next-20140324
>
> include/linux/of.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 21e6323de0f3..9978c918222e 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -710,6 +710,11 @@ static inline struct device_node *of_get_cpu_node(int cpu,
> return NULL;
> }
>
> +static inline int of_n_addr_cells(struct device_node *np)
> +{
> + return 0;
> +}
> +
This looks good, but we should also do the same thing for of_n_size_cells().
I think I sent something like this a few years ago, but never resubmitted it
when it was ignored at first.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/2] ARM: dts: sunxi: Add CAN node and can0_pins_a pinctrl setting
From: Patrick Menschel @ 2017-03-24 21:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, maxime.ripard, wens, devicetree,
linux-arm-kernel, linux-kernel, linux-can
Cc: Patrick Menschel
The Allwinner A10/A20 SoCs have an on-board CAN (Controller Area Network)
controller. This patch adds the CAN core to the SoC's include files,
sun4i-a10.dtsi and sun7i-a20.dtsi.
On linux-can mailing list was a discussion about updating the device tree bindings
https://lkml.org/lkml/2015/9/17/220
but it did not progress past writing the documentation file.
Documentation/devicetree/bindings/net/can/sun4i_can.txt
The CAN controller can be enabled in a board specific dts file as
described in the documentation file or by using a device tree overlay.
I have tested the patch v2 on a Banana Pi (A20 SoC) with mainline kernel 4.10.5.
History:
v2: changed can0_pins_a node contents to new generic binding method,
changed can0_pins_a node position by alphabetical order,
changed can0 device node position by rising physical address order
v1: initial
Patrick Menschel (2):
ARM: dts: sun4i: Add CAN node and can0_pins_a pinctrl settings
ARM: dts: sun7i: Add CAN node and can0_pins_a pinctrl settings
arch/arm/boot/dts/sun4i-a10.dtsi | 13 +++++++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 13 +++++++++++++
2 files changed, 26 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: sun4i: Add CAN node and can0_pins_a pinctrl settings
From: Patrick Menschel @ 2017-03-24 21:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, maxime.ripard, wens, devicetree,
linux-arm-kernel, linux-kernel, linux-can
Cc: Patrick Menschel
In-Reply-To: <1490392339-23565-1-git-send-email-menschel.p@posteo.de>
The A10 SoC has an on-board CAN controller. This patch adds the device node
and the corresponding pinctrl settings for pins PH20 and PH21.
This patch is adapted from the description in
Documentation/devicetree/bindings/net/can/sun4i_can.txt
Signed-off-by: Patrick Menschel <menschel.p@posteo.de>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index ba20b48..f7dced4 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -974,6 +974,11 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
+ can0_pins_a: can0@0 {
+ pins = "PH20","PH21";
+ function = "can";
+ };
+
emac_pins_a: emac0@0 {
pins = "PA0", "PA1", "PA2",
"PA3", "PA4", "PA5", "PA6",
@@ -1313,6 +1318,14 @@
#size-cells = <0>;
};
+ can0: can@01c2bc00 {
+ compatible = "allwinner,sun4i-a10-can";
+ reg = <0x01c2bc00 0x400>;
+ interrupts = <26>;
+ clocks = <&apb1_gates 4>;
+ status = "disabled";
+ };
+
ps20: ps2@01c2a000 {
compatible = "allwinner,sun4i-a10-ps2";
reg = <0x01c2a000 0x400>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: sun7i: Add CAN node and can0_pins_a pinctrl settings
From: Patrick Menschel @ 2017-03-24 21:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, maxime.ripard, wens, devicetree,
linux-arm-kernel, linux-kernel, linux-can
Cc: Patrick Menschel
In-Reply-To: <1490392339-23565-1-git-send-email-menschel.p@posteo.de>
The A20 SoC has an on-board CAN controller. This patch adds the device node
and the corresponding pinctrl settings for pins PH20 and PH21.
The CAN controller is inherited from the A10 SoC and uses the same driver.
This patch is adapted from the description in
Documentation/devicetree/bindings/net/can/sun4i_can.txt
Signed-off-by: Patrick Menschel <menschel.p@posteo.de>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 2db97fc..25af586 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1096,6 +1096,11 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
+ can0_pins_a: can0@0 {
+ pins = "PH20","PH21";
+ function = "can";
+ };
+
clk_out_a_pins_a: clk_out_a@0 {
pins = "PI12";
function = "clk_out_a";
@@ -1582,6 +1587,14 @@
#size-cells = <0>;
};
+ can0: can@01c2bc00 {
+ compatible = "allwinner,sun4i-a10-can";
+ reg = <0x01c2bc00 0x400>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&apb1_gates 4>;
+ status = "disabled";
+ };
+
i2c4: i2c@01c2c000 {
compatible = "allwinner,sun7i-a20-i2c",
"allwinner,sun4i-a10-i2c";
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/4] gpio: mvebu: Add limited PWM support
From: Ralph Sennhauser @ 2017-03-24 22:21 UTC (permalink / raw)
To: Rob Herring, Thomas Petazzoni
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA, Andrew Lunn, Imre Kaloz,
Thierry Reding, Linus Walleij, Alexandre Courbot, Mark Rutland,
Greg Kroah-Hartman, David S. Miller, Geert Uytterhoeven,
Mauro Carvalho Chehab, Guenter Roeck, open list:PWM SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Gregory CLEMENT
In-Reply-To: <20170324151829.awmhshsent4ngqb5@rob-hp-laptop>
On Fri, 24 Mar 2017 10:18:29 -0500
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Sat, Mar 18, 2017 at 04:43:01PM +0100, Ralph Sennhauser wrote:
> > From: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> >
> > Armada 370/XP devices can 'blink' gpio lines with a configurable on
> > and off period. This can be modelled as a PWM.
> >
> > However, there are only two sets of PWM configuration registers for
> > all the gpio lines. This driver simply allows a single gpio line per
> > gpio chip of 32 lines to be used as a PWM. Attempts to use more
> > return EBUSY.
> >
> > Due to the interleaving of registers it is not simple to separate
> > the PWM driver from the gpio driver. Thus the gpio driver has been
> > extended with a PWM driver.
> >
> > Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> > URL: https://patchwork.ozlabs.org/patch/427287/
> > URL: https://patchwork.ozlabs.org/patch/427295/
> > [Ralph Sennhauser:
> > * port forward
> > * merge pwm portion into gpio-mvebu.c
> > * merge documentation patch
> > * update MAINTAINERS]
> > Signed-off-by: Ralph Sennhauser <ralph.sennhauser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > .../devicetree/bindings/gpio/gpio-mvebu.txt | 31 +++
> > MAINTAINERS | 2 +
> > drivers/gpio/gpio-mvebu.c | 291
> > +++++++++++++++++++-- 3 files changed, 307 insertions(+), 17
> > deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> > b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt index
> > a6f3bec..86932e3 100644 ---
> > a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt +++
> > b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt @@ -38,6
> > +38,23 @@ Required properties:
> > - #gpio-cells: Should be two. The first cell is the pin number. The
> > second cell is reserved for flags, unused at the moment.
> >
> > +Optional properties:
> > +
> > +In order to use the gpio lines in PWM mode, some additional
> > optional +properties are required. Only Armada 370 and XP support
> > these properties. +
> > +- reg: an additional register set is needed, for the GPIO Blink
> > + Counter on/off registers.
> > +
> > +- reg-names: Must contain an entry "pwm" corresponding to the
> > + additional register range needed for pwm operation.
> > +
> > +- #pwm-cells: Should be two. The first cell is the pin number.
> > The
>
> s/pin number/gpio line/ ?
Better indeed.
>
> > + second cell is reserved for flags and should be set to 0, so it
> > has a
> > + known value. It then becomes possible to use it in the future.
> > +
> > +- clocks: Must be a phandle to the clock for the gpio controller.
> > +
> > Example:
> >
> > gpio0: gpio@d0018100 {
> > @@ -51,3 +68,17 @@ Example:
> > #interrupt-cells = <2>;
> > interrupts = <16>, <17>, <18>, <19>;
> > };
> > +
> > + gpio1: gpio@18140 {
> > + compatible = "marvell,orion-gpio";
>
> If only 370 and XP support this, I'd expect a compatible string for
> one of them here.
Commit 5f79c651e81e ("arm: mvebu: use global interrupts for GPIOs on
Armada XP") changes it from "marvell,armadaxp-gpio". The commit message
says for 3.8 basically leaving it open for a "fix" later.
Adding Thomas Petazzoni as the author.
Thomas, would you happen to know if this is still how it's supposed to
be for now?
Thanks
Ralph
>
> > + reg = <0x18140 0x40>, <0x181c8 0x08>;
> > + reg-names = "gpio", "pwm";
> > + ngpios = <17>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + #pwm-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + interrupts = <87>, <88>, <89>;
> > + clocks = <&coreclk 0>;
> > + };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/4] mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
From: Ralph Sennhauser @ 2017-03-24 22:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA, Imre Kaloz, Thierry Reding,
Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
Jason Cooper, Gregory Clement, Sebastian Hesselbarth,
Russell King, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170324143505.GK28518-g2DYL2Zd6BY@public.gmane.org>
On Fri, 24 Mar 2017 15:35:05 +0100
Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
> > + pwm_fan {
> > /* SUNON HA4010V4-0000-C99 */
> > - compatible = "gpio-fan";
> > - gpios = <&gpio0 24 0>;
> >
> > - gpio-fan,speed-map = <0 0
> > - 4500 1>;
> > + compatible = "pwm-fan";
> > + pwms = <&gpio0 24 4000 0>;
>
> Hi Ralph
>
> I believe this last 0 is the flags parameter. Now that we have
> #pwm-cells = 1, i think this last 0 should be dropped.
>
> Andrew
Missed it. Duly noted like the other comments.
Thanks
Ralph
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 1/7] devicetree: power: battery: Add properties for pre-charge and end-charge current
From: Liam Breck @ 2017-03-25 0:34 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Tony Lindgren, linux-pm-u79uwXL29TY76Z2rM5mHXA, Hans de Goede,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, Liam Breck
In-Reply-To: <20170324090158.tl55neisjws66naf@earth>
On Fri, Mar 24, 2017 at 2:01 AM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hi,
>
> On Tue, Mar 21, 2017 at 03:09:15PM -0700, Liam Breck wrote:
>> From: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
>>
>> precharge-current-microamp and endcharge-current-microamp are used
>> by battery chargers at the beginning and end of a charging cycle.
>>
>> Depends-on: https://patchwork.kernel.org/patch/9633605/
>> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
>
> Acked-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> I think it makes sense to merge this into the patch adding
> simple-battery.
It would make sense, but it means a new _prop_precharge/endcharge
patch in that patchset, and I am trying to constrain it at this stage.
So if it's OK, I'd like to keep all that in this patchset.
>> Documentation/devicetree/bindings/power/supply/battery.txt | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>> index 53a68c0..494374a 100644
>> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>> @@ -12,6 +12,8 @@ Optional Properties:
>> - voltage-min-design-microvolt: drained battery voltage
>> - energy-full-design-microwatt-hours: battery design energy
>> - charge-full-design-microamp-hours: battery design capacity
>> + - precharge-current-microamp: current for pre-charge phase
>> + - endcharge-current-microamp: current for charge termination phase
>>
>> Battery properties are named, where possible, for the corresponding
>> elements in enum power_supply_property, defined in
>> @@ -28,6 +30,8 @@ Example:
>> voltage-min-design-microvolt = <3200000>;
>> energy-full-design-microwatt-hours = <5290000>;
>> charge-full-design-microamp-hours = <1430000>;
>> + precharge-current-microamp = <256000>;
>> + endcharge-current-microamp = <128000>;
>> };
>>
>> charger: charger@11 {
>> --
>> 2.9.3
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 09/23] MAINTAINERS: Add file patterns for infiniband device tree bindings
From: Doug Ledford @ 2017-03-25 2:40 UTC (permalink / raw)
To: Geert Uytterhoeven, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Sean Hefty, Hal Rosenstock, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1489324627-19126-10-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
On Sun, 2017-03-12 at 14:16 +0100, Geert Uytterhoeven wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> Cc: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Hal Rosenstock <hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> Please apply this patch directly if you want to be involved in device
> tree binding documentation for your subsystem.
I assume this is going through someone else' tree since I only see
patch 09 of 23 and not the entire series. But, for this specific
patch:
Acked-by: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> v2:
> - New.
>
> Impact on next-20170310:
>
> +Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (supporter:INFINIBAND SUBSYSTEM)
> +Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (supporter:INFINIBAND SUBSYSTEM)
> +Hal Rosenstock <hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (supporter:INFINIBAND
> SUBSYSTEM)
> Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> (maintainer:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS)
> Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> (maintainer:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS)
> -Wei Hu <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> (commit_signer:2/2=100%)
> -Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> (commit_signer:2/2=100%,authored:2/2=100%)
> -Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (commit_signer:2/2=100%)
> -Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> (commit_signer:1/2=50%)
> +linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:INFINIBAND SUBSYSTEM)
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS)
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list)
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fa42535181d48e27..c3fbd1af0f49a7e9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6459,6 +6459,7 @@ W: http://www.openfabrics.org/
> Q: http://patchwork.kernel.org/project/linux-rdma/list/
> T: git
> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
> S: Supported
> +F: Documentation/devicetree/bindings/infiniband/
> F: Documentation/infiniband/
> F: drivers/infiniband/
> F: include/uapi/linux/if_infiniband.h
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/9] bus: brcmstb_gisb: Use register offsets with writes too
From: Gregory Fong @ 2017-03-25 5:21 UTC (permalink / raw)
To: Doug Berger
Cc: Catalin Marinas, Rob Herring, Mark Rutland, Will Deacon,
Brian Norris, Florian Fainelli, bcm-kernel-feedback-list,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA, james.morse-5wv7dgnIgG8,
vladimir.murzin-5wv7dgnIgG8, panand-H+wXaHxf7aLQT0dZR+AlfA,
andre.przywara-5wv7dgnIgG8, cmetcalf-VPRAkNaXOzVWk0Htik3J/w,
mingo-DgEjT+Ai2ygdnm+yROfE0A,
sandeepa.s.prabhu-Re5JQEeQqe8AvxtiuMwx3w,
shijie.huang-5wv7dgnIgG8, Linus Walleij,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
Olof Johansson, mirza.krak-Re5JQEeQqe8AvxtiuMwx3w,
suzuki.poulose-5wv7dgnIgG8, bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170324144632.5896-5-opendmb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Mar 24, 2017 at 7:46 AM, Doug Berger <opendmb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> This commit corrects the bug introduced in commit f80835875d3d
> ("bus: brcmstb_gisb: Look up register offsets in a table") such
> that gisb_write() translates the register enumeration into an
> offset from the base address for writes as well as reads.
>
> Fixes: f80835875d3d ("bus: brcmstb_gisb: Look up register offsets in a table")
> Signed-off-by: Doug Berger <opendmb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Gregory Fong <gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask
From: Oza Pawandeep via iommu @ 2017-03-25 5:31 UTC (permalink / raw)
To: Joerg Roedel, Robin Murphy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
it is possible that PCI device supports 64-bit DMA addressing,
and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
however PCI host bridge may have limitations on the inbound
transaction addressing. As an example, consider NVME SSD device
connected to iproc-PCIe controller.
Currently, the IOMMU DMA ops only considers PCI device dma_mask
when allocating an IOVA. This is particularly problematic on
ARM/ARM64 SOCs where the IOMMU (i.e. SMMU) translates IOVA to
PA for in-bound transactions only after PCI Host has forwarded
these transactions on SOC IO bus. This means on such ARM/ARM64
SOCs the IOVA of in-bound transactions has to honor the addressing
restrictions of the PCI Host.
current pcie frmework and of framework integration assumes dma-ranges
in a way where memory-mapped devices define their dma-ranges.
dma-ranges: (child-bus-address, parent-bus-address, length).
but iproc based SOCs and even Rcar based SOCs has PCI world dma-ranges.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
of_dma_configure is specifically witten to take care of memory mapped devices.
but no implementation exists for pci to take care of pcie based memory ranges.
in fact pci world doesnt seem to define standard dma-ranges
this patch implements of_pci_get_dma_ranges to cater to pci world dma-ranges.
so then the returned size get best possible (largest) dma_mask.
for e.g.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7fffffffff.
Reviewed-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
diff --git a/drivers/of/device.c b/drivers/of/device.c
index b1e6beb..d362a98 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -9,6 +9,7 @@
#include <linux/module.h>
#include <linux/mod_devicetable.h>
#include <linux/slab.h>
+#include <linux/of_pci.h>
#include <asm/errno.h>
#include "of_private.h"
@@ -104,7 +105,11 @@ void of_dma_configure(struct device *dev, struct device_node *np)
if (!dev->dma_mask)
dev->dma_mask = &dev->coherent_dma_mask;
- ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ if (dev_is_pci(dev))
+ ret = of_pci_get_dma_ranges(np, &dma_addr, &paddr, &size);
+ else
+ ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+
if (ret < 0) {
dma_addr = offset = 0;
size = dev->coherent_dma_mask + 1;
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..c7f8626 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -283,6 +283,52 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
return err;
}
EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+int of_pci_get_dma_ranges(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+{
+ struct device_node *node = of_node_get(np);
+ int rlen, ret = 0;
+ const int na = 3, ns = 2;
+ struct of_pci_range_parser parser;
+ struct of_pci_range range;
+
+ if (!node)
+ return -EINVAL;
+
+ parser.node = node;
+ parser.pna = of_n_addr_cells(node);
+ parser.np = parser.pna + na + ns;
+
+ parser.range = of_get_property(node, "dma-ranges", &rlen);
+
+ if (!parser.range) {
+ pr_debug("pcie device has no dma-ranges defined for node(%s)\n", np->full_name);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ parser.end = parser.range + rlen / sizeof(__be32);
+ *size = 0;
+
+ for_each_of_pci_range(&parser, &range) {
+ if (*size < range.size) {
+ *dma_addr = range.pci_addr;
+ *size = range.size;
+ *paddr = range.cpu_addr;
+ }
+ }
+
+ pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+ *dma_addr, *paddr, *size);
+ *dma_addr = range.pci_addr;
+ *size = range.size;
+
+out:
+ of_node_put(node);
+ return ret;
+
+}
+EXPORT_SYMBOL_GPL(of_pci_get_dma_ranges);
#endif /* CONFIG_OF_ADDRESS */
#ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 0e0974e..907ace0 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -76,6 +76,7 @@ static inline void of_pci_check_probe_only(void) { }
int of_pci_get_host_bridge_resources(struct device_node *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
+int of_pci_get_dma_ranges(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size);
#else
static inline int of_pci_get_host_bridge_resources(struct device_node *dev,
unsigned char busno, unsigned char bus_max,
@@ -83,6 +84,11 @@ static inline int of_pci_get_host_bridge_resources(struct device_node *dev,
{
return -EINVAL;
}
+
+static inline int of_pci_get_dma_ranges(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+{
+ return -EINVAL;
+}
#endif
#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 2/3] iommu/dma: account pci host bridge dma_mask for IOVA allocation
From: Oza Pawandeep via iommu @ 2017-03-25 5:31 UTC (permalink / raw)
To: Joerg Roedel, Robin Murphy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490419893-5073-1-git-send-email-oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
it is possible that PCI device supports 64-bit DMA addressing,
and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
however PCI host bridge may have limitations on the inbound
transaction addressing. As an example, consider NVME SSD device
connected to iproc-PCIe controller.
Currently, the IOMMU DMA ops only considers PCI device dma_mask
when allocating an IOVA. This is particularly problematic on
ARM/ARM64 SOCs where the IOMMU (i.e. SMMU) translates IOVA to
PA for in-bound transactions only after PCI Host has forwarded
these transactions on SOC IO bus. This means on such ARM/ARM64
SOCs the IOVA of in-bound transactions has to honor the addressing
restrictions of the PCI Host.
this patch is inspired by
http://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1306545.html
http://www.spinics.net/lists/arm-kernel/msg566947.html
but above inspiraiton solves the half of the problem.
the rest of the problem is descrbied below, what we face on iproc based
SOCs.
current pcie frmework and of framework integration assumes dma-ranges
in a way where memory-mapped devices define their dma-ranges.
dma-ranges: (child-bus-address, parent-bus-address, length).
but iproc based SOCs and even Rcar based SOCs has PCI world dma-ranges.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
of_dma_configure is specifically witten to take care of memory mapped devices.
but no implementation exists for pci to take care of pcie based memory ranges.
in fact pci world doesnt seem to define standard dma-ranges
this patch implements of_pci_get_dma_ranges to cater to pci world dma-ranges.
so then the returned size get best possible (largest) dma_mask.
for e.g.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7fffffffff.
Reviewed-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8c7c244..20cfff7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -217,6 +217,9 @@ config NEED_DMA_MAP_STATE
config NEED_SG_DMA_LENGTH
def_bool y
+config ARCH_HAS_DMA_SET_COHERENT_MASK
+ def_bool y
+
config SMP
def_bool y
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 73d5bab..64b4dc3 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -20,6 +20,7 @@ struct dev_archdata {
#ifdef CONFIG_IOMMU_API
void *iommu; /* private IOMMU data */
#endif
+ u64 parent_dma_mask;
bool dma_coherent;
};
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 81cdb2e..5845ecd 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -564,6 +564,7 @@ static void flush_page(struct device *dev, const void *virt, phys_addr_t phys)
__dma_flush_area(virt, PAGE_SIZE);
}
+
static void *__iommu_alloc_attrs(struct device *dev, size_t size,
dma_addr_t *handle, gfp_t gfp,
unsigned long attrs)
@@ -795,6 +796,20 @@ static void __iommu_unmap_sg_attrs(struct device *dev,
iommu_dma_unmap_sg(dev, sgl, nelems, dir, attrs);
}
+static int __iommu_set_dma_mask(struct device *dev, u64 mask)
+{
+ /* device is not DMA capable */
+ if (!dev->dma_mask)
+ return -EIO;
+
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+ *dev->dma_mask = mask;
+
+ return 0;
+}
+
static const struct dma_map_ops iommu_dma_ops = {
.alloc = __iommu_alloc_attrs,
.free = __iommu_free_attrs,
@@ -811,8 +826,21 @@ static void __iommu_unmap_sg_attrs(struct device *dev,
.map_resource = iommu_dma_map_resource,
.unmap_resource = iommu_dma_unmap_resource,
.mapping_error = iommu_dma_mapping_error,
+ .set_dma_mask = __iommu_set_dma_mask,
};
+int dma_set_coherent_mask(struct device *dev, u64 mask)
+{
+ if (get_dma_ops(dev) == &iommu_dma_ops &&
+ mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+ dev->coherent_dma_mask = mask;
+ return 0;
+}
+EXPORT_SYMBOL(dma_set_coherent_mask);
+
+
/*
* TODO: Right now __iommu_setup_dma_ops() gets called too early to do
* everything it needs to - the device is only partially created and the
@@ -975,6 +1003,8 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (!dev->dma_ops)
dev->dma_ops = &swiotlb_dma_ops;
+ dev->archdata.parent_dma_mask = size - 1;
+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
}
diff --git a/drivers/of/device.c b/drivers/of/device.c
index d362a98..471dcdf 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -139,10 +139,8 @@ void of_dma_configure(struct device *dev, struct device_node *np)
* Limit coherent and dma mask based on size and default mask
* set by the driver.
*/
- dev->coherent_dma_mask = min(dev->coherent_dma_mask,
- DMA_BIT_MASK(ilog2(dma_addr + size)));
- *dev->dma_mask = min((*dev->dma_mask),
- DMA_BIT_MASK(ilog2(dma_addr + size)));
+ dev->coherent_dma_mask = DMA_BIT_MASK(ilog2(dma_addr + size));
+ *dev->dma_mask = dev->coherent_dma_mask;
coherent = of_dma_is_coherent(np);
dev_dbg(dev, "device is%sdma coherent\n",
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 3/3] of: fix node traversing in of_dma_get_range
From: Oza Pawandeep via iommu @ 2017-03-25 5:31 UTC (permalink / raw)
To: Joerg Roedel, Robin Murphy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490419893-5073-1-git-send-email-oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
it jumps to the parent node without examining the child node.
also with that, it throws "no dma-ranges found for node"
for pci dma-ranges.
this patch fixes device node traversing for dma-ranges.
Reviewed-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..3293d55 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -836,9 +836,6 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
while (1) {
naddr = of_n_addr_cells(node);
nsize = of_n_size_cells(node);
- node = of_get_next_parent(node);
- if (!node)
- break;
ranges = of_get_property(node, "dma-ranges", &len);
@@ -852,6 +849,10 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
*/
if (!ranges)
break;
+
+ node = of_get_next_parent(node);
+ if (!node)
+ break;
}
if (!ranges) {
--
1.9.1
^ 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