* [PATCH v2 2/6] arm64: dts: lg1312: DT fix s/#interrupts-cells/#interrupt-cells/
From: Chanho Min @ 2016-10-24 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039877-20227-3-git-send-email-geert+renesas@glider.be>
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v2:
> - Add Acked-by,
> - Rebased.
> ---
Acked-by: Chanho Min <chanho.min@lge.com>
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Linus Walleij @ 2016-10-24 1:03 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 4:40 PM, Neil Armstrong <narmstrong@baylibre.com> 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>
Looks good to me. Tell me when I may apply it, it looks orthogonal
to the rest of the patches.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] gpio: mxs: fix duplicate level interrupts
From: Linus Walleij @ 2016-10-24 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021131138.10467-3-s.hauer@pengutronix.de>
On Fri, Oct 21, 2016 at 3:11 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> According to the reference manual level interrupts can't be acked
> using the IRQSTAT registers. The effect is that when a level interrupt
> triggers the following ack is a no-op and the same interrupt triggers
> again right after it has been unmasked after running the interrupt
> handler.
>
> The reference manual says:
>
> Status bits for pins configured as level sensitive interrupts cannot be
> cleared unless either the actual pin is in the non-interrupting state, or
> the pin has been disabled as an interrupt source by clearing its bit in
> HW_PINCTRL_PIN2IRQ.
>
> To work around the duplicated interrupts we can use the PIN2IRQ
> rather than the IRQEN registers to mask the interrupts. This
> probably does not work for the edge interrupts, so we have to split up
> the irq chip into two chip types, one for the level interrupts and
> one for the edge interrupts. We now make use of two different enable
> registers, so we have to take care to always enable the right one,
> especially during switching of the interrupt type. An easy way
> to accomplish this is to use the IRQCHIP_SET_TYPE_MASKED which
> makes sure that set_irq_type is called with masked interrupts. With this
> the flow to change the irq type is like:
>
> - core masks interrupt (using the current chip type)
> - mxs_gpio_set_irq_type() changes chip type if necessary
> - mxs_gpio_set_irq_type() unconditionally sets the enable bit in the
> now unused enable register
> - core eventually unmasks the interrupt (using the new chip type)
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Patch applied with Marek's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] gpio: mxs: use enable/disable regs to (un)mask irqs
From: Linus Walleij @ 2016-10-24 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021131138.10467-2-s.hauer@pengutronix.de>
On Fri, Oct 21, 2016 at 3:11 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> The mxs gpio controller does not only have a mask register to mask
> interrupts, but also enable/disable registers. Use the enable/disable
> registers rather than the mask register. This does not have any
> advantage for now, but makes the next patch simpler.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Patch applied with Marek's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [BUG] LPC32xx gpio driver broken by commit 762c2e46 in 4.9-rc1
From: Linus Walleij @ 2016-10-24 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476807799.10214.25.camel@localhost>
On Tue, Oct 18, 2016 at 6:23 PM, Sylvain Lemieux
<slemieux.tyco@gmail.com> wrote:
> the current LPC32xx GPIO driver is broken by commit 762c2e46
> (gpio: of: remove of_gpiochip_and_xlate() and struct gg_data).
>
> A call to "of_get_named_gpio" to retrieve the GPIO will
> always return -EINVAL, except for the first GPIO bank.
>
> Prior to this commit, the driver was working properly
> because of the side-effect of the match function called by
> "gpiochip_find" inside "of_get_named_gpiod_flags" function.
(...)
> Is there any short-term solution that can be done with
> the existing driver to keep the LPC32xx platform working
> properly in the 4.9 mainline kernel?
Masahiro, what do you think is the best course to proceed here?
Can we
- Restore the behaviour prior to the patches or
- Fix up all users or
- Do we have to revert these two patches?
I would prefer not to revert, because I liked the cleanup a lot ...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 6/8] pinctrl: aspeed-g4: Capture SuperIO pinmux dependency
From: Andrew Jeffery @ 2016-10-24 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYZPcjGuRKVL6qwof1p7ZXT4EvwzAuz59oTgp9Z5Dzixw@mail.gmail.com>
On Mon, 2016-10-24 at 00:09 +0200, Linus Walleij wrote:
> On Fri, Oct 21, 2016 at 2:33 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
> >
> > >
> > > Patch applied for v4.10.
> > > (Tell me if I'm applying patches in wrong order or something, and
> > > I hope this doesn't clash with the fixes.)
> > Both this patch and 8/8 functionally depend on 5/8. I fetched the
> > pinctrl tree to poke around but this patch didn't appear in any of the
> > updated branches, so I'm not sure whether we have the right ordering.
> > Without it we should hit build failures from missing macro definitions.
> >
> > Have you had a chance to look over patch 5/8? Joel wasn't keen on its
> > current form, so I would appreciate your input.
> Oops backed this patch out.
>
> Will look at 5/8.
>
> Appreciate if you repost the remaining patches in the series based on
> v4.9-rc2 once it's out, and I'll rebase the pinctrl tree onto that.
>
Will do!
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/f42ae859/attachment-0001.sig>
^ permalink raw reply
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Andrew Jeffery @ 2016-10-24 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdazJzE=Oa-0-FEYTvUk=-kPLojHY3afZKX5cpmzrUZHGQ@mail.gmail.com>
On Mon, 2016-10-24 at 00:20 +0200, Linus Walleij wrote:
> On Thu, Sep 29, 2016 at 8:45 AM, Joel Stanley <joel@jms.id.au> wrote:
> >
> > On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > >
> > > On the AST2400 and AST2500 a number of pins depend on state in one of
> > > the SIO, LPC or GFX IP blocks, so add support to at least capture what
> > > that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> > > inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> > > the state requirement with the expectation that the platform
> > > designer/maintainer arranges for the appropriate configuration to be
> > > applied through the associated drivers.
> (...)
> >
> >
> > This is unfortunate.
> >
> > This patch kicks the can down the road, but doesn't solve the problem
> > for a user who wants to configure some functionality that depends on
> > the non-SCU bits. Because of this I'm not sure if we want to put it in
> > the tree.
> >
> > However, I'm not sure what a proper solution would look like. Perhaps
> > Linus can point out another SoC that has a similar problem?
> If I could only understand it.
>
> Don't you actually want to go and read a few registers on another
> IO range?
Yes. I guess the hesitation was whether we should also write those
registers so we can apply the requested function.
>
> What we generally do when pin control is spread out in a system is try
> to consolidate it, meaning expose the necessary registers on the remote
> end using syscon (drivers/mfd/syscon) so that we can easily get a handle
> on these registers withe regmap MMIO.
>
> Since regmap handles atomic access to the registers, that way we
> protect from disasters and keep the state in the hardware.
This seems like the reasonable approach if we want to read/write those
registers. The affected IO ranges correspond to:
* SuperIO Controller (SIO)
* SOC Display Controller (GFX)
* LPC Controller (LPC)
SIO and LPC both perform a mishmash of functions and so likely would
use the mfd subsystem anyway. I don't yet have any arguments against
doing it for the GFX IO space. Joel?
>
> I don't know if this is helpful. For a normal peripheral you may not want
> to put a regmap over all its registers but you prefer to ioremap it, and then
> we get the spaghetti of accessor functions to peek and poke into another
> peripherals I/O space, and that is undesireable.
I briefly experimented with the idea of accessing the other IO spaces
but it felt dirty precisely for what would have become accessor
spaghetti. So I wound up with the lame approach in this patch, which
just punts on the problem. I think the mfd/syscon approach would work
well though.
It looks like the rockchip pinctrl bindings are doing something along
the lines of what we need with the rockchip,pmu phandle property. Is it
acceptable to create three properties, a phandle to grab each regmap
for the IO spaces above?
>
> Maybe this is completely not understanding what you want to do, so
> sorry, please elaborate.
No, seems you have understood what we need to do.
> I am afraid the two of you are the only people on
> the planet who actually understand what is going on here.
>
> Also the hardware engineer who wrote the Aspeed pin controller, I would
> like to read this persons design specification, I am pretty sure it is very
> interesting.
Well, presumably this engineer knows too :) And yes, I'd like to know
what constraints existed that forced this design as a solution. I'd
like my sanity back.
>
> >
> > >
> > > -??* @reg: The register offset from base in bytes
> > > +??* @reg: Split into three fields:
> > > +??*???????31:24: IP selector
> > > +??*???????23:12: Reserved
> > > +??*???????11:0: Register offset
> That seems like unnecessary shoehorning. Is it reflecting the register layout
> of the hardware or are you trying to save bits? For the latter, let it
> go and instead
> have one member for offset and one member for selector.
It doesn't represent the register layout. But saving bits also wasn't
the motivation, more avoiding a lot of code churn in the g4/g5 drivers
to populate a new member. Maybe that's a bad motivation. I'll have more
of a think about it.
Thanks for the feedback,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/93d37a58/attachment.sig>
^ permalink raw reply
* [PATCH -next] ARM: mediatek: add terminate entry for of_device_id tables
From: weiyongjun (A) @ 2016-10-24 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477222977-1336-1-git-send-email-weiyj.lk@gmail.com>
> -----Original Message-----
> From: Wei Yongjun [mailto:weiyj.lk at gmail.com]
> Sent: Sunday, October 23, 2016 7:43 PM
> To: Matthias Brugger <matthias.bgg@gmail.com>; Russell King
> <linux@armlinux.org.uk>
> Cc: weiyongjun (A) <weiyongjun1@huawei.com>; linux-arm-
> kernel at lists.infradead.org; linux-mediatek at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: [PATCH -next] ARM: mediatek: add terminate entry for
> of_device_id tables
>
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Make sure of_device_id tables are NULL terminated.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> arch/arm/mach-mediatek/platsmp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Sorry, this patch is not correct since mtk_tz_smp_boot_infos is used
as ARRAY_SIZE(mtk_tz_smp_boot_infos), please ignore it.
Regards,
Yongjun Wei
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Linus Walleij @ 2016-10-24 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPoCmYKrUBEdyNXt8yRMFq_aCmb8WyK-x4a7og66zfeFYX4rQg@mail.gmail.com>
On Thu, Oct 20, 2016 at 6:58 PM, Gottfried Haider
<gottfried.haider@gmail.com> wrote:
> Somewhat off topic: is it planned to add
> support for setting GENERIC_PINCONF style pull-up/pull-down resistors
> throigh the new ABI?
Not planned, as in "I will do the job" but anticipated.
I expect that someone will come up with that usecase (indeed even the
Arduino is doing it) so that we will have to support it.
It's better than inventing a separate userspace ABI for pin control
anyways.
> (The bcm28xx drivers would still need to
> converted to this as well.)
All drivers that want to support it need converting I suspect.
>>> Regarding the proposed format using the header pin numbers: From what I've
>>> seen in terms of existing educational materials, it seems the overwhelming
>>> majority ends up using GPIO numbers instead of physical pin header
>>> numbering. (e.g. [1] [2])
>>
>> What does that number mean? If you are referring to the global
>> GPIO numberspace it is obsolete and just reflecting the fact that
>> people up until now was referring to Linux-internal GPIO numbers.
>
> I am referring to the name of the various GPIO lines as per datasheet
> ("GPIO0", "GPIO1", ...). So far, I believe those matched the global
> GPIO numberspace.
Aha. Yeah that is matching somewhat by chance these days, because:
static struct gpio_chip bcm2835_gpio_chip = {
.label = MODULE_NAME,
(...)
.base = -1,
(...)
};
That means this number is dynamicallly assigned and depend on
things like probe order or another GPIO chip failing etc.
> I understand that Linux can't guarantee a certain global GPIO number -
> but I fear that the board manufacturers also might not think of the
> pin headers as something set in stone (that the can't rearrange in a
> future revision/product).
Depends on which manufacturer. For 96boards there exist a document
specifying how they should be arranged and named:
https://github.com/96boards/documentation
Rpi would be wise to come up with something similar, but I have no
high hopes. We do need standardization and interoperability, but
it is not creating itself. :/
> Would there be a reason against _naming_ the pin "GPIO0"? (even if it
> ends up with a different global, internal number)
No not if it makes electronic sense, like if the schematic or SoC
uses that name, then use that if the board maintainer likes the idea.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 3/6] dt-bindings: pinctrl: Deprecate sunxi pinctrl bindings
From: Linus Walleij @ 2016-10-24 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6aec73cd3b9d3dbf1085d042ec6c23f385a300de.1476971126.git-series.maxime.ripard@free-electrons.com>
On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The generic pin configuration and multiplexing should be preferred now,
> even though we still support the old one.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/6] pinctrl: sunxi: Support generic binding
From: Linus Walleij @ 2016-10-24 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <519ec867509f8033d9235a61f7979bd698906ab5.1476971126.git-series.maxime.ripard@free-electrons.com>
On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Our bindings are mostly irrelevant now that we have generic pinctrl
> bindings that cover exactly the same uses cases.
>
> Add support for the new ones, and obviously keep our old binding support in
> order to keep the ABI stable.
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 2/4] arm64: dts: add Allwinner A64 SoC .dtsi
From: André Przywara @ 2016-10-23 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb11a71c58cd85551d9d793437db1792abd5077c.1476986335.git-series.maxime.ripard@free-electrons.com>
On 20/10/16 19:00, Maxime Ripard wrote:
Hi Maxime,
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> [Maxime: Convert to CCU binding, drop the MMC support for now]
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +-
> MAINTAINERS | 1 +-
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 263 +++++++++++++++++-
> 3 files changed, 265 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 3975d0a0e4c2..4d6467cc2aa2 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,4 +14,5 @@ using one of the following compatible strings:
> allwinner,sun8i-a83t
> allwinner,sun8i-h3
> allwinner,sun9i-a80
> + allwinner,sun50i-a64
> nextthing,gr8
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7e0064..86488e92655f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1019,6 +1019,7 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> N: sun[x456789]i
> F: arch/arm/boot/dts/ntc-gr8*
> +F: arch/arm64/boot/dts/allwinner/
>
> ARM/Allwinner SoC Clock Support
> M: Emilio L?pez <emilio@elopez.com.ar>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> new file mode 100644
> index 000000000000..be51024743b4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -0,0 +1,263 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + * based on the Allwinner H3 dtsi:
> + * Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/clock/sun50i-a64-ccu.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +#include <dt-bindings/reset/sun50i-a64-ccu.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu at 0 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + };
> +
> + cpu1: cpu at 1 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + };
> +
> + cpu2: cpu at 2 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + };
> +
> + cpu3: cpu at 3 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + };
> + };
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc32k: osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + ccu: clock at 01c20000 {
> + compatible = "allwinner,sun50i-a64-ccu";
> + reg = <0x01c20000 0x400>;
> + clocks = <&osc24M>, <&osc32k>;
> + clock-names = "hosc", "losc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + pio: pinctrl at 1c20800 {
> + compatible = "allwinner,sun50i-a64-pinctrl";
> + reg = <0x01c20800 0x400>;
> + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_PIO>;
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + i2c1_pins: i2c1_pins {
> + allwinner,pins = "PH2", "PH3";
> + allwinner,function = "i2c1";
So as Icenowy pointed out, we are missing the drive and pull properties
here, at least as long as we don't have your patch (series) in place to
cope with that.
But if we rely on this series (which seems OK to me), shouldn't we then
use the generic properties for pins and function here as well?
Cheers,
Andre.
> + };
> +
> + uart0_pins_a: uart0 at 0 {
> + allwinner,pins = "PB8", "PB9";
> + allwinner,function = "uart0";
> + };
> + };
> +
> + uart0: serial at 1c28000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28000 0x400>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART0>;
> + resets = <&ccu RST_BUS_UART0>;
> + status = "disabled";
> + };
> +
> + uart1: serial at 1c28400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28400 0x400>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART1>;
> + resets = <&ccu RST_BUS_UART1>;
> + status = "disabled";
> + };
> +
> + uart2: serial at 1c28800 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28800 0x400>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART2>;
> + resets = <&ccu RST_BUS_UART2>;
> + status = "disabled";
> + };
> +
> + uart3: serial at 1c28c00 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28c00 0x400>;
> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART3>;
> + resets = <&ccu RST_BUS_UART3>;
> + status = "disabled";
> + };
> +
> + uart4: serial at 1c29000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c29000 0x400>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART4>;
> + resets = <&ccu RST_BUS_UART4>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c at 1c2ac00 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2ac00 0x400>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C0>;
> + resets = <&ccu RST_BUS_I2C0>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c at 1c2b000 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b000 0x400>;
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C1>;
> + resets = <&ccu RST_BUS_I2C1>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c at 1c2b400 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b400 0x400>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C2>;
> + resets = <&ccu RST_BUS_I2C2>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + gic: interrupt-controller at 1c81000 {
> + compatible = "arm,gic-400";
> + reg = <0x01c81000 0x1000>,
> + <0x01c82000 0x2000>,
> + <0x01c84000 0x2000>,
> + <0x01c86000 0x2000>;
> + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + };
> +
> + rtc: rtc at 1f00000 {
> + compatible = "allwinner,sun6i-a31-rtc";
> + reg = <0x01f00000 0x54>;
> + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +};
>
^ permalink raw reply
* [PATCH 2/2] pinctrl: stm32: move gpio irqs binding to optional
From: Linus Walleij @ 2016-10-23 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476970012-7838-3-git-send-email-alexandre.torgue@st.com>
On Thu, Oct 20, 2016 at 3:26 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> stm32 pinctrl driver could be probed even if no interrupt controller
> is defined to manage gpio irqs. Entries related to gpio irq management
> are moved to optional.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] pinctrl: stm32: remove dependency with interrupt controller
From: Linus Walleij @ 2016-10-23 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476970012-7838-2-git-send-email-alexandre.torgue@st.com>
On Thu, Oct 20, 2016 at 3:26 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch allows to probe stm32 pinctrl driver even if no interrupt
> controller is defined to manage gpio irqs.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL 4/4] Broadcom defconfig-arm64 changes for 4.9 (part 2)
From: Olof Johansson @ 2016-10-23 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <62d5c9b0-9073-c8e3-6a9f-390f381d4d9d@gmail.com>
On Sun, Oct 23, 2016 at 2:55 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 09/30/2016 12:23 PM, Florian Fainelli wrote:
>> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>>
>> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>>
>> are available in the git repository at:
>>
>> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.9/defconfig-arm64
>>
>> for you to fetch changes up to 51e3fb1d3f514cd336faf185df73b25fca194773:
>>
>> Merge tag 'bcm2835-defconfig-64-next-2016-09-22' into defconfig-arm64/next (2016-09-30 12:02:29 -0700)
>>
>> ----------------------------------------------------------------
>> This pull request contains Broadcom ARM64-based SoCs defconfig changes for 4.9,
>> please pull the following changes:
>>
>> - Eric updates the ARMv8 defconfig to contain everything that is needed to run
>> a 64-bit kernel on the Raspberry Pi 3
>>
>> ----------------------------------------------------------------
>> Eric Anholt (1):
>> arm64: Add BCM2835 (Raspberry Pi 3) support to the defconfig
>>
>> Florian Fainelli (1):
>> Merge tag 'bcm2835-defconfig-64-next-2016-09-22' into defconfig-arm64/next
>>
>> arch/arm64/configs/defconfig | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>
> Arnd, Kevin, Olof,
>
> Following Olof's response here:
>
> https://www.spinics.net/lists/arm-kernel/msg534687.html
>
> do you think we could merge these for 4.9-rcX? Let me know if I should
> send a fresh pull request for that.
Main reason to respin would be if you need to rebase due to other
changes that have gone in, or if you expect to have other material
that should be based on a 4.9-rc base.
-Olof
^ permalink raw reply
* [PATCH] pinctrl: st: don't specify default interrupt trigger
From: Linus Walleij @ 2016-10-23 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476774988-13484-1-git-send-email-patrice.chotard@st.com>
On Tue, Oct 18, 2016 at 9:16 AM, <patrice.chotard@st.com> wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> Thanks to 332e99d5ae4 which now alerts of default
> trigger usage when configuring interrupts.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Patch applied with Peter's ACK.
Pls also look into the following: __gpio_irq_handler seems to be
doing some stuff per-IRQ that only pertains to edge-triggered IRQs.
Normally that should be handled by:
- Setting default handler to handle_bad_irq()
- Setting handler to handle_edge_irq() or handle_level_irq() in .set_type()
- Implement .irq_ack() on the irqchip and handle the edge-specific ACKing
there.
See for example drivers/gpio/gpio-pl061.c.
I am not *sure* this applies to pinctrl-st.c but please check if it provides
more elegant code. Notmally the .irq_ack() is for edge detection hardware
that allows ACKing the ege IRQ in a separate register and after that we
can raise another edge IRQ while the current IRQ is being handled.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] Revert "gpio/mvebu: convert to use irq_domain_add_simple()"
From: Linus Walleij @ 2016-10-23 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019210341.GA3746@obsidianresearch.com>
On Wed, Oct 19, 2016 at 11:03 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> From 7566f05ac445b652ba7607cc1899fed10fea1c76 Mon Sep 17 00:00:00 2001
> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Date: Wed, 19 Oct 2016 14:57:45 -0600
> Subject: [PATCH] gpio/mvebu: Use irq_domain_add_linear
>
> This fixes the irq allocation in this driver to not print:
> irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
> irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
>
> Which happens because the driver already called irq_alloc_descs()
> and so the change to use irq_domain_add_simple resulted in calling
> irq_alloc_descs() twice.
>
> Modernize the irq allocation in this driver to use the
> irq_domain_add_linear flow directly and eliminate the use of
> irq_domain_add_simple/legacy
>
> Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
So can I just apply this?
Gregory?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Linus Walleij @ 2016-10-23 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xc7y3GtcJCVYYs-JKTqBZvqVeZaz5MUk=UX151SX1xEFw@mail.gmail.com>
On Thu, Sep 29, 2016 at 8:45 AM, Joel Stanley <joel@jms.id.au> wrote:
> On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>> On the AST2400 and AST2500 a number of pins depend on state in one of
>> the SIO, LPC or GFX IP blocks, so add support to at least capture what
>> that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
>> inspect or modify the state of the off-SCU IP blocks. Instead, it logs
>> the state requirement with the expectation that the platform
>> designer/maintainer arranges for the appropriate configuration to be
>> applied through the associated drivers.
(...)
>
> This is unfortunate.
>
> This patch kicks the can down the road, but doesn't solve the problem
> for a user who wants to configure some functionality that depends on
> the non-SCU bits. Because of this I'm not sure if we want to put it in
> the tree.
>
> However, I'm not sure what a proper solution would look like. Perhaps
> Linus can point out another SoC that has a similar problem?
If I could only understand it.
Don't you actually want to go and read a few registers on another
IO range?
What we generally do when pin control is spread out in a system is try
to consolidate it, meaning expose the necessary registers on the remote
end using syscon (drivers/mfd/syscon) so that we can easily get a handle
on these registers withe regmap MMIO.
Since regmap handles atomic access to the registers, that way we
protect from disasters and keep the state in the hardware.
I don't know if this is helpful. For a normal peripheral you may not want
to put a regmap over all its registers but you prefer to ioremap it, and then
we get the spaghetti of accessor functions to peek and poke into another
peripherals I/O space, and that is undesireable.
Maybe this is completely not understanding what you want to do, so
sorry, please elaborate. I am afraid the two of you are the only people on
the planet who actually understand what is going on here.
Also the hardware engineer who wrote the Aspeed pin controller, I would
like to read this persons design specification, I am pretty sure it is very
interesting.
>> - * @reg: The register offset from base in bytes
>> + * @reg: Split into three fields:
>> + * 31:24: IP selector
>> + * 23:12: Reserved
>> + * 11:0: Register offset
That seems like unnecessary shoehorning. Is it reflecting the register layout
of the hardware or are you trying to save bits? For the latter, let it
go and instead
have one member for offset and one member for selector.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 6/8] pinctrl: aspeed-g4: Capture SuperIO pinmux dependency
From: Linus Walleij @ 2016-10-23 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477010011.8917.20.camel@aj.id.au>
On Fri, Oct 21, 2016 at 2:33 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>> Patch applied for v4.10.
>> (Tell me if I'm applying patches in wrong order or something, and
>> I hope this doesn't clash with the fixes.)
>
> Both this patch and 8/8 functionally depend on 5/8. I fetched the
> pinctrl tree to poke around but this patch didn't appear in any of the
> updated branches, so I'm not sure whether we have the right ordering.
> Without it we should hit build failures from missing macro definitions.
>
> Have you had a chance to look over patch 5/8? Joel wasn't keen on its
> current form, so I would appreciate your input.
Oops backed this patch out.
Will look at 5/8.
Appreciate if you repost the remaining patches in the series based on
v4.9-rc2 once it's out, and I'll rebase the pinctrl tree onto that.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL 4/4] Broadcom defconfig-arm64 changes for 4.9 (part 2)
From: Florian Fainelli @ 2016-10-23 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475263395-27653-4-git-send-email-f.fainelli@gmail.com>
On 09/30/2016 12:23 PM, Florian Fainelli wrote:
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>
> are available in the git repository at:
>
> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.9/defconfig-arm64
>
> for you to fetch changes up to 51e3fb1d3f514cd336faf185df73b25fca194773:
>
> Merge tag 'bcm2835-defconfig-64-next-2016-09-22' into defconfig-arm64/next (2016-09-30 12:02:29 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM64-based SoCs defconfig changes for 4.9,
> please pull the following changes:
>
> - Eric updates the ARMv8 defconfig to contain everything that is needed to run
> a 64-bit kernel on the Raspberry Pi 3
>
> ----------------------------------------------------------------
> Eric Anholt (1):
> arm64: Add BCM2835 (Raspberry Pi 3) support to the defconfig
>
> Florian Fainelli (1):
> Merge tag 'bcm2835-defconfig-64-next-2016-09-22' into defconfig-arm64/next
>
> arch/arm64/configs/defconfig | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Arnd, Kevin, Olof,
Following Olof's response here:
https://www.spinics.net/lists/arm-kernel/msg534687.html
do you think we could merge these for 4.9-rcX? Let me know if I should
send a fresh pull request for that.
Thank you!
--
Florian
^ permalink raw reply
* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: Vineet Gupta @ 2016-10-23 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477138444-14993-1-git-send-email-ynorov@caviumnetworks.com>
On 10/22/2016 05:14 AM, Yury Norov wrote:
> The newer prlimit64 syscall provides all the functionality provided by
> the getrlimit and setrlimit syscalls and adds the pid of target process,
> so future architectures won't need to include getrlimit and setrlimit.
>
> Therefore drop getrlimit and setrlimit syscalls from the generic syscall
> list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
> unistd.h prior to including asm-generic/unistd.h, and adjust all
> architectures using the generic syscall list to define it so that no
> in-tree architectures are affected.
>
> Cc: Vineet Gupta <vgupta@synopsys.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com> #arch/arc bits
Thx,
-Vineet
^ permalink raw reply
* [PATCH] arm64: Neaten show_regs, remove KERN_CONT
From: Joe Perches @ 2016-10-23 20:40 UTC (permalink / raw)
To: linux-arm-kernel
commit db4b0710fae9 ("arm64: fix show_regs fallout from KERN_CONT changes")
corrected the KERN_CONT fallout from commit 4bcc595ccd80
("printk: reinstate KERN_CONT for printing continuation lines"), but
the code still has unnecessary KERN_CONT uses. Remove them.
Miscellanea:
o Remove unnecessary trailing blank from the output too.
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/arm64/kernel/process.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 01753cd7d3f0..2278e7197a8e 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -190,18 +190,16 @@ void __show_regs(struct pt_regs *regs)
i = top_reg;
- while (i >= 0) {
- printk("x%-2d: %016llx ", i, regs->regs[i]);
+ if (i >= 0 && !(i % 2)) {
+ printk("x%-2d: %016llx\n", i, regs->regs[i]);
i--;
-
- if (i % 2 == 0) {
- pr_cont("x%-2d: %016llx ", i, regs->regs[i]);
- i--;
- }
-
- pr_cont("\n");
}
- printk("\n");
+ while (i > 0) {
+ printk("x%-2d: %016llx x%-2d: %016llx\n",
+ i, regs->regs[i],
+ i - 1, regs->regs[i - 1]);
+ i -= 2;
+ }
}
void show_regs(struct pt_regs * regs)
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* [PATCH RFC 10/10] drm/i2c: tda998x: switch to boolean is_on
From: Russell King @ 2016-10-23 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023191002.GJ1041@n2100.armlinux.org.uk>
Rather than storing the DPMS mode (which will always be on or off) use a
boolean to store this instead.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 547cf99ac32d..1f9a25fe17f3 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -42,7 +42,7 @@ struct tda998x_priv {
struct mutex mutex;
u16 rev;
u8 current_page;
- int dpms;
+ bool is_on;
bool is_hdmi_sink;
bool is_hdmi_config;
u8 vip_cntrl_0;
@@ -1150,16 +1150,15 @@ static int tda998x_connector_init(struct tda998x_priv *priv,
static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
{
struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
+ bool on;
/* we only care about on or off: */
- if (mode != DRM_MODE_DPMS_ON)
- mode = DRM_MODE_DPMS_OFF;
+ on = mode == DRM_MODE_DPMS_ON;
- if (mode == priv->dpms)
+ if (on == priv->is_on)
return;
- switch (mode) {
- case DRM_MODE_DPMS_ON:
+ if (on) {
/* enable video ports, audio will be enabled later */
reg_write(priv, REG_ENA_VP_0, 0xff);
reg_write(priv, REG_ENA_VP_1, 0xff);
@@ -1168,16 +1167,16 @@ static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
reg_write(priv, REG_VIP_CNTRL_0, priv->vip_cntrl_0);
reg_write(priv, REG_VIP_CNTRL_1, priv->vip_cntrl_1);
reg_write(priv, REG_VIP_CNTRL_2, priv->vip_cntrl_2);
- break;
- case DRM_MODE_DPMS_OFF:
+
+ priv->is_on = true;
+ } else {
/* disable video ports */
reg_write(priv, REG_ENA_VP_0, 0x00);
reg_write(priv, REG_ENA_VP_1, 0x00);
reg_write(priv, REG_ENA_VP_2, 0x00);
- break;
- }
- priv->dpms = mode;
+ priv->is_on = false;
+ }
}
static void
--
2.1.0
^ permalink raw reply related
* [PATCH RFC 09/10] drm/i2c: tda998x: remove complexity from tda998x_audio_get_eld()
From: Russell King @ 2016-10-23 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023191002.GJ1041@n2100.armlinux.org.uk>
tda998x_audio_get_eld() is needlessly complex - the connector associated
with the encoder is always our own priv->connector. Remove this
complexity, but ensure that there are no races when copying out the ELD.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 6a7095b66a69..547cf99ac32d 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -911,21 +911,13 @@ static int tda998x_audio_get_eld(struct device *dev, void *data,
uint8_t *buf, size_t len)
{
struct tda998x_priv *priv = dev_get_drvdata(dev);
- struct drm_mode_config *config = &priv->encoder.dev->mode_config;
- struct drm_connector *connector;
- int ret = -ENODEV;
-
- mutex_lock(&config->mutex);
- list_for_each_entry(connector, &config->connector_list, head) {
- if (&priv->encoder == connector->encoder) {
- memcpy(buf, connector->eld,
- min(sizeof(connector->eld), len));
- ret = 0;
- }
- }
- mutex_unlock(&config->mutex);
- return ret;
+ mutex_lock(&priv->audio_mutex);
+ memcpy(buf, priv->connector.eld,
+ min(sizeof(priv->connector.eld), len));
+ mutex_unlock(&priv->audio_mutex);
+
+ return 0;
}
static const struct hdmi_codec_ops audio_codec_ops = {
@@ -1082,7 +1074,10 @@ static int tda998x_connector_get_modes(struct drm_connector *connector)
drm_mode_connector_update_edid_property(connector, edid);
n = drm_add_edid_modes(connector, edid);
priv->is_hdmi_sink = drm_detect_hdmi_monitor(edid);
+
+ mutex_lock(&priv->audio_mutex);
drm_edid_to_eld(connector, edid);
+ mutex_unlock(&priv->audio_mutex);
kfree(edid);
--
2.1.0
^ permalink raw reply related
* [PATCH RFC 08/10] drm/i2c: tda998x: group audio functions together
From: Russell King @ 2016-10-23 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023191002.GJ1041@n2100.armlinux.org.uk>
Group the TDA998x audio functions together rather than split between
two different locations in the file, keeping like code together.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 278 +++++++++++++++++++-------------------
1 file changed, 140 insertions(+), 138 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 4379c6aa1c48..6a7095b66a69 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -702,6 +702,8 @@ tda998x_write_avi(struct tda998x_priv *priv, struct drm_display_mode *mode)
tda998x_write_if(priv, DIP_IF_FLAGS_IF2, REG_IF2_HB0, &frame);
}
+/* Audio support */
+
static void tda998x_audio_mute(struct tda998x_priv *priv, bool on)
{
if (on) {
@@ -820,6 +822,144 @@ tda998x_configure_audio(struct tda998x_priv *priv,
return tda998x_write_aif(priv, ¶ms->cea);
}
+static int tda998x_audio_hw_params(struct device *dev, void *data,
+ struct hdmi_codec_daifmt *daifmt,
+ struct hdmi_codec_params *params)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+ int i, ret;
+ struct tda998x_audio_params audio = {
+ .sample_width = params->sample_width,
+ .sample_rate = params->sample_rate,
+ .cea = params->cea,
+ };
+
+ memcpy(audio.status, params->iec.status,
+ min(sizeof(audio.status), sizeof(params->iec.status)));
+
+ switch (daifmt->fmt) {
+ case HDMI_I2S:
+ if (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
+ daifmt->bit_clk_master || daifmt->frame_clk_master) {
+ dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__,
+ daifmt->bit_clk_inv, daifmt->frame_clk_inv,
+ daifmt->bit_clk_master,
+ daifmt->frame_clk_master);
+ return -EINVAL;
+ }
+ for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
+ if (priv->audio_port[i].format == AFMT_I2S)
+ audio.config = priv->audio_port[i].config;
+ audio.format = AFMT_I2S;
+ break;
+ case HDMI_SPDIF:
+ for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
+ if (priv->audio_port[i].format == AFMT_SPDIF)
+ audio.config = priv->audio_port[i].config;
+ audio.format = AFMT_SPDIF;
+ break;
+ default:
+ dev_err(dev, "%s: Invalid format %d\n", __func__, daifmt->fmt);
+ return -EINVAL;
+ }
+
+ if (audio.config == 0) {
+ dev_err(dev, "%s: No audio configutation found\n", __func__);
+ return -EINVAL;
+ }
+
+ mutex_lock(&priv->audio_mutex);
+ /* We must not program the TDA998x for audio if the sink is DVI. */
+ if (priv->is_hdmi_config)
+ ret = tda998x_configure_audio(priv, &audio);
+ else
+ ret = 0;
+
+ if (ret == 0)
+ priv->audio_params = audio;
+ mutex_unlock(&priv->audio_mutex);
+
+ return ret;
+}
+
+static void tda998x_audio_shutdown(struct device *dev, void *data)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+
+ mutex_lock(&priv->audio_mutex);
+
+ reg_write(priv, REG_ENA_AP, 0);
+
+ priv->audio_params.format = AFMT_UNUSED;
+
+ mutex_unlock(&priv->audio_mutex);
+}
+
+int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+
+ mutex_lock(&priv->audio_mutex);
+
+ tda998x_audio_mute(priv, enable);
+
+ mutex_unlock(&priv->audio_mutex);
+ return 0;
+}
+
+static int tda998x_audio_get_eld(struct device *dev, void *data,
+ uint8_t *buf, size_t len)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct drm_mode_config *config = &priv->encoder.dev->mode_config;
+ struct drm_connector *connector;
+ int ret = -ENODEV;
+
+ mutex_lock(&config->mutex);
+ list_for_each_entry(connector, &config->connector_list, head) {
+ if (&priv->encoder == connector->encoder) {
+ memcpy(buf, connector->eld,
+ min(sizeof(connector->eld), len));
+ ret = 0;
+ }
+ }
+ mutex_unlock(&config->mutex);
+
+ return ret;
+}
+
+static const struct hdmi_codec_ops audio_codec_ops = {
+ .hw_params = tda998x_audio_hw_params,
+ .audio_shutdown = tda998x_audio_shutdown,
+ .digital_mute = tda998x_audio_digital_mute,
+ .get_eld = tda998x_audio_get_eld,
+};
+
+static int tda998x_audio_codec_init(struct tda998x_priv *priv,
+ struct device *dev)
+{
+ struct hdmi_codec_pdata codec_data = {
+ .ops = &audio_codec_ops,
+ .max_i2s_channels = 2,
+ };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++) {
+ if (priv->audio_port[i].format == AFMT_I2S &&
+ priv->audio_port[i].config != 0)
+ codec_data.i2s = 1;
+ if (priv->audio_port[i].format == AFMT_SPDIF &&
+ priv->audio_port[i].config != 0)
+ codec_data.spdif = 1;
+ }
+
+ priv->audio_pdev = platform_device_register_data(
+ dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO,
+ &codec_data, sizeof(codec_data));
+
+ return PTR_ERR_OR_ZERO(priv->audio_pdev);
+}
+
/* DRM connector functions */
static int tda998x_connector_dpms(struct drm_connector *connector, int mode)
@@ -1261,144 +1401,6 @@ static void tda998x_destroy(struct tda998x_priv *priv)
i2c_unregister_device(priv->cec);
}
-static int tda998x_audio_hw_params(struct device *dev, void *data,
- struct hdmi_codec_daifmt *daifmt,
- struct hdmi_codec_params *params)
-{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
- int i, ret;
- struct tda998x_audio_params audio = {
- .sample_width = params->sample_width,
- .sample_rate = params->sample_rate,
- .cea = params->cea,
- };
-
- memcpy(audio.status, params->iec.status,
- min(sizeof(audio.status), sizeof(params->iec.status)));
-
- switch (daifmt->fmt) {
- case HDMI_I2S:
- if (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
- daifmt->bit_clk_master || daifmt->frame_clk_master) {
- dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__,
- daifmt->bit_clk_inv, daifmt->frame_clk_inv,
- daifmt->bit_clk_master,
- daifmt->frame_clk_master);
- return -EINVAL;
- }
- for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
- if (priv->audio_port[i].format == AFMT_I2S)
- audio.config = priv->audio_port[i].config;
- audio.format = AFMT_I2S;
- break;
- case HDMI_SPDIF:
- for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
- if (priv->audio_port[i].format == AFMT_SPDIF)
- audio.config = priv->audio_port[i].config;
- audio.format = AFMT_SPDIF;
- break;
- default:
- dev_err(dev, "%s: Invalid format %d\n", __func__, daifmt->fmt);
- return -EINVAL;
- }
-
- if (audio.config == 0) {
- dev_err(dev, "%s: No audio configutation found\n", __func__);
- return -EINVAL;
- }
-
- mutex_lock(&priv->audio_mutex);
- /* We must not program the TDA998x for audio if the sink is DVI. */
- if (priv->is_hdmi_config)
- ret = tda998x_configure_audio(priv, &audio);
- else
- ret = 0;
-
- if (ret == 0)
- priv->audio_params = audio;
- mutex_unlock(&priv->audio_mutex);
-
- return ret;
-}
-
-static void tda998x_audio_shutdown(struct device *dev, void *data)
-{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
-
- mutex_lock(&priv->audio_mutex);
-
- reg_write(priv, REG_ENA_AP, 0);
-
- priv->audio_params.format = AFMT_UNUSED;
-
- mutex_unlock(&priv->audio_mutex);
-}
-
-int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
-{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
-
- mutex_lock(&priv->audio_mutex);
-
- tda998x_audio_mute(priv, enable);
-
- mutex_unlock(&priv->audio_mutex);
- return 0;
-}
-
-static int tda998x_audio_get_eld(struct device *dev, void *data,
- uint8_t *buf, size_t len)
-{
- struct tda998x_priv *priv = dev_get_drvdata(dev);
- struct drm_mode_config *config = &priv->encoder.dev->mode_config;
- struct drm_connector *connector;
- int ret = -ENODEV;
-
- mutex_lock(&config->mutex);
- list_for_each_entry(connector, &config->connector_list, head) {
- if (&priv->encoder == connector->encoder) {
- memcpy(buf, connector->eld,
- min(sizeof(connector->eld), len));
- ret = 0;
- }
- }
- mutex_unlock(&config->mutex);
-
- return ret;
-}
-
-static const struct hdmi_codec_ops audio_codec_ops = {
- .hw_params = tda998x_audio_hw_params,
- .audio_shutdown = tda998x_audio_shutdown,
- .digital_mute = tda998x_audio_digital_mute,
- .get_eld = tda998x_audio_get_eld,
-};
-
-static int tda998x_audio_codec_init(struct tda998x_priv *priv,
- struct device *dev)
-{
- struct hdmi_codec_pdata codec_data = {
- .ops = &audio_codec_ops,
- .max_i2s_channels = 2,
- };
- int i;
-
- for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++) {
- if (priv->audio_port[i].format == AFMT_I2S &&
- priv->audio_port[i].config != 0)
- codec_data.i2s = 1;
- if (priv->audio_port[i].format == AFMT_SPDIF &&
- priv->audio_port[i].config != 0)
- codec_data.spdif = 1;
- }
-
- priv->audio_pdev = platform_device_register_data(
- dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO,
- &codec_data, sizeof(codec_data));
-
- return PTR_ERR_OR_ZERO(priv->audio_pdev);
-}
-
/* I2C driver functions */
static int tda998x_get_audio_ports(struct tda998x_priv *priv,
--
2.1.0
^ 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