* Re: [PATCH v4 3/9] dt-bindings: pinctrl: Add RZ/A1 bindings doc
From: Geert Uytterhoeven @ 2017-04-26 9:02 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Linus Walleij, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491401247-7030-4-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Hi Jacopo,
On Wed, Apr 5, 2017 at 4:07 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
GPIO
> controller.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Thank you for the extensive documentation, incl. good examples!
> ---
> .../bindings/pinctrl/renesas,rza1-pinctrl.txt | 218 +++++++++++++++++++++
> 1 file changed, 218 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> new file mode 100644
> index 0000000..46584ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> @@ -0,0 +1,218 @@
> +Renesas RZ/A1 combined Pin and GPIO controller
> +
> +The Renesas SoCs of RZ/A1 family feature a combined Pin and GPIO controller,
Renesas SoCs of the RZ/A1 family
> +named "Ports" in the hardware reference manual.
> +Pin multiplexing and GPIO configuration is performed on a per-pin basis
> +writing configuration values to per-port register sets.
> +Each "port" features up to 16 pins, each of them configurable for GPIO
> +function (port mode) or in alternate function mode.
> +Up to 8 different alternate function modes exist for each single pin.
> +
> +Pin controller node
> +-------------------
> +
> +Required properties:
> + - compatible
> + this shall be "renesas,r7s72100-ports".
> +
> + - reg
> + address base and length of the memory area where pin controller
the pin controller hardware
> + hardware is mapped to.
> +
> +Example:
> +Pin controller node for RZ/A1H SoC (r7s72100)
> +
> +pinctrl: pin-controller@fcfe3000 {
> + compatible = "renesas,r7s72100-ports";
> +
> + reg = <0xfcfe3000 0x4230>;
> +};
> +
> +Sub-nodes
> +---------
> +
> +The child nodes of the pin controller node describe a pin multiplexing
> +function or a gpio controller alternatively.
"GPIO", to be consistent (there are more to fix)
> +
> +- Pin multiplexing sub-nodes:
> + A pin multiplexing sub-node describes how to configure a set of
> + (or a single) pin in some desired alternate function mode.
> + A single sub-node may define several pin configurations.
> + Some alternate functions require special pin configuration flags to be
> + supplied along with the alternate function configuration number.
> + When hardware reference manual specifies a pin function to be either
the hardware reference manual
> + "bi-directional" or "software IO driven", use the generic properties from
from the
> + <include/linux/pinctrl/pinconf_generic.h> header file to instruct the
> + pin controller to perform the desired pin configuration operations.
> + Please refer to pinctrl-bindings.txt to get to know more on generic
> + pin properties usage.
> + Supported generic properties:
Optional generic properties?
> + - bi-directional:
> + for pins requiring bi-directional operations.
> + - input-enable:
> + for pins requiring software driven IO input operations.
> + - output-enable:
> + for pins requiring software driver IO output operations.
I think you can move this here:
The hardware reference manual specifies when a pin has to be configured to
work in bi-directional mode.
> +
> + Example:
> + A serial communication interface with a TX output pin and an RX input pin.
[...]
> + Pin #4 on port #1 is configured as alternate function #1.
> + Pin #5 on port #1 is configured as alternate function #1.
> + Both need to work in bi-directional mode.
> + The hardware reference manual specifies when a pin has to be configured to
> + work in bi-directional mode.
... and remove the two lines above here...
> +
> + Example 3:
> + Multi-function timer input and output compare pins.
> + Configure TIOC0A as software driven input and TIOC0B as software driven
> + output.
[...]
> + Pin #0 on port #4 is configured as alternate function #2 with IO direction
> + specified by software as input.
> + Pin #1 on port #4 is configured as alternate function #1 with IO direction
> + specified by software as output.
> + The hardware reference manual specifies when a pin has to be configured with
> + input/output direction specified by software.
... and here.
> +
> +- GPIO controller sub-nodes:
> + Each port of the r7s72100 pin controller hardware is itself a gpio controller.
> + Different SoCs have different number of available pins per port, but
numbers of
> + generally speaking, each of them can be configured in GPIO ("port") mode
> + on this hardware.
> + Describe gpio-controllers using sub-nodes with the following properties.
GPIO controllers
> +
> + Required properties:
> + - gpio-controller
> + empty property as defined by the gpio bindings documentation.
> + - #gpio-cells
> + number of cells required to identify and configure a GPIO.
> + Shall be 2.
> + - gpio-ranges
> + Describes a gpio controller specifying its specific pin base, the pin
> + base in the global pin numbering space, and the number of controlled
> + pins, as defined by the gpio bindings documentation. Refer to this file
Documentation/devicetree/bindings/gpio/gpio.txt
> + for a more detailed description.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 1/5] dt-bindings: Document the STM32 DMAMUX bindings
From: Pierre Yves MORDRET @ 2017-04-26 8:58 UTC (permalink / raw)
To: Rob Herring, M'boumba Cedric Madianga
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Alexandre TORGUE, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com,
dmaengine@vger.kernel.org, dan.j.williams@intel.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170320213413.4b6uopuilznyr2rl@rob-hp-laptop>
Hi Rob
On 03/20/2017 10:34 PM, Rob Herring wrote:
> On Mon, Mar 13, 2017 at 03:15:57PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds the documentation of device tree bindings for the STM32
>> DMAMUX.
>>
>> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>> ---
>> .../devicetree/bindings/dma/stm32-dmamux.txt | 57 ++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/stm32-dmamux.txt b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>> new file mode 100644
>> index 0000000..1039420
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>> @@ -0,0 +1,57 @@
>> +STM32 DMA MUX (DMA request router)
>> +
>> +Required properties:
>> +- compatible: "st,stm32-dmamux"
>> +- reg: Memory map for accessing module
>> +- #dma-cells: Should be set to <4>.
>> + For more details about the four cells, please see stm32-dma.txt
>> + documentation binding file
>> +- dma-masters: Phandle pointing to the DMA controller
>> +- clocks: Input clock of the DMAMUX instance.
>> +
>> +Optional properties:
>> +- dma-channels : Number of DMA channels supported.
>> +- dma-requests : Number of DMA requests supported.
>> +- resets: Reference to a reset controller asserting the DMA controller
>> +
>> +Example:
>> +
>> +/* DMA controller */
>> +dma2: dma-controller@40026400 {
>> + compatible = "st,stm32-dma";
>> + reg = <0x40026400 0x400>;
>> + interrupts = <56>,
>> + <57>,
>> + <58>,
>> + <59>,
>> + <60>,
>> + <68>,
>> + <69>,
>> + <70>;
>> + clocks = <&clk_hclk>;
>> + #dma-cells = <4>;
>> + st,mem2mem;
>> + resets = <&rcc 150>;
>> + st,dmamux;
>> + dma-channels = <8>;
>> +};
>> +
>> +/* DMA mux */
>> +dmamux2: dma-router@40020820 {
>> + compatible = "st,stm32-dmamux";
>> + reg = <0x40020800 0x1c>;
>> + #dma-cells = <4>;
>> + dma-requests = <128>;
>> + dma-masters = <&dma2>;
>
> I think this should be modeled after the interrupt-map property (or
> Stephen Boyd's gpio-map support which additionally allows pass thru of
> cell values). Something like this:
>
> dma-map = <0 41 0 0 &dma2 0 <req> 0 0>,
> <1 42 0 0 &dma2 1 <req> 0 0>;
> dma-map-mask = <0xffffffff 0xffffffff 0 0>;
>
> <req> is the request number on dma2 controller.
>
> This is more generic and would work if you have a single mux with
> multiple DMA controllers.
>
Would you mind to detail a little bit more your thoughts please ?
Are dma-map & dma-map-mask part of an existing bindings ? or need to be
developed ?
I'm a little bit confused where come from values you used.
>> +};
>> +
>> +/* DMA client */
>> +usart1: serial@40011000 {
>> + compatible = "st,stm32-usart", "st,stm32-uart";
>> + reg = <0x40011000 0x400>;
>> + interrupts = <37>;
>> + clocks = <&clk_pclk2>;
>> + dmas = <&dmamux2 0 41 0x400 0x00>,
>> + <&dmamux2 1 42 0x400 0x00>;
>> + dma-names = "rx", "tx";
>> +};
>> --
>> 1.9.1
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-04-26 8:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Vladimir Barinov
In-Reply-To: <CAMuHMdXbe=rkeS+-teg7nqbjULWY0_5pBO1XEzCGdYA4gB57oA@mail.gmail.com>
On Wed, Apr 26, 2017 at 10:11:55AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> CC Vladimir (which I forgot to CC initially, sorry for that)
>
> On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
> >> The Renesas Salvator-X and ULCB development board can be equipped with
> >> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> >> use separate DTBs, but currently there's no sharing of board-specific
> >> devices in DTS.
> >>
> >> This series reduces duplication by extracting common board support into
> >> their own .dtsi files. As the level of support varies across boards and
> >> SoCs, this requires the addition of a few external clocks and
> >> placeholder devices on R-Car M3-W, so the common board support DTS can
> >> refer to them.
> >>
> >> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> >> M3-W, which are present in r8a7795.dtsi, and used in
> >> r8a7795-salvator-x.dts,
> >> - RFC patch 3 adds placeholders for devices that are not yet supported
> >> and/or tested on R-Car M3-W, but used on R-Car H3,
> >> - RFC patch 4 extracts common Salvator-X board support,
> >> - RFC patch 5 extracts common ULCB board support.
> >>
> >> For R-Car H3 based boards, there are no functional changes.
> >> For R-Car M3-W based boards, some new devices are now described in DT.
> >>
> >> Dependencies:
> >> - renesas-devel-20170420-v4.11-rc7,
> >> - Patches 1 and 2 can be applied as-is,
> >> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
> >> out R-Car H3 and M3-W SiP"
> >> (http://www.spinics.net/lists/devicetree/msg173820.html).
> >>
> >> DTB changes have been inspected using scripts/dtc/dtx_diff.
> >> This has been tested on Salvator-X (both H3 and M3-W).
> >> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
> >>
> >> Thanks for your comments!
> >
> > Thanks for tackling this important problem. I have looked over the changes
> > and they seem nice to me. I would, however, be more comfortable applying
> > them if they were rested on the ULCB boards.
>
> tested?
Yes, tested :)
> I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
^ permalink raw reply
* Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback
From: Jose Abreu @ 2017-04-26 8:55 UTC (permalink / raw)
To: Vineet Gupta,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Carlos Palminha, Alexey Brodkin, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <77599cf5-33e5-2ecd-2b2a-43630195a3b8-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hi Vineet,
On 24-04-2017 18:36, Vineet Gupta wrote:
> On 04/21/2017 03:15 AM, Jose Abreu wrote:
>> This patch adds the necessary DT bindings to get HDMI audio
>> output in ARC AXS10x SDP. The bindings for I2S controller were
>> added as well as the bindings for simple audio card.
> Are these waiting on Rob or is it OK for me to pick these up for 4.12 ?
Yes, I was waiting for Rob ack but he has been silent. It would
be nice if these went for 4.12.
Best regards,
Jose Miguel Abreu
>
> -Vineet
>
>> Signed-off-by: Jose Abreu <joabreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Acked-by: Alexey Brodkin <abrodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: Carlos Palminha <palminha-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: Alexey Brodkin <abrodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Vineet Gupta <vgupta-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>> arch/arc/boot/dts/axs10x_mb.dtsi | 22 ++++++++++++++++++----
>> 1 file changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
>> index d6c1bbc..9d882b1 100644
>> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
>> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
>> @@ -149,12 +149,13 @@
>> interrupts = <14>;
>> };
>>
>> - i2c@0x1e000 {
>> - compatible = "snps,designware-i2c";
>> + i2s: i2s@1e000 {
>> + compatible = "snps,designware-i2s";
>> reg = <0x1e000 0x100>;
>> - clock-frequency = <400000>;
>> - clocks = <&i2cclk>;
>> + clocks = <&i2sclk 0>;
>> + clock-names = "i2sclk";
>> interrupts = <15>;
>> + #sound-dai-cells = <0>;
>> };
>>
>> i2c@0x1f000 {
>> @@ -174,6 +175,7 @@
>> adi,input-colorspace = "rgb";
>> adi,input-clock = "1x";
>> adi,clock-delay = <0x03>;
>> + #sound-dai-cells = <0>;
>>
>> ports {
>> #address-cells = <1>;
>> @@ -295,5 +297,17 @@
>> };
>> };
>> };
>> +
>> + sound_playback {
>> + compatible = "simple-audio-card";
>> + simple-audio-card,name = "AXS10x HDMI Audio";
>> + simple-audio-card,format = "i2s";
>> + simple-audio-card,cpu {
>> + sound-dai = <&i2s>;
>> + };
>> + simple-audio-card,codec {
>> + sound-dai = <&adv7511>;
>> + };
>> + };
>> };
>> };
--
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/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Geert Uytterhoeven @ 2017-04-26 8:11 UTC (permalink / raw)
To: Simon Horman
Cc: Mark Rutland, devicetree@vger.kernel.org, Geert Uytterhoeven,
Kuninori Morimoto, Yoshihiro Shimoda, Magnus Damm,
Vladimir Barinov, Linux-Renesas, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170426080642.GK25517@verge.net.au>
Hi Simon,
CC Vladimir (which I forgot to CC initially, sorry for that)
On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
>> The Renesas Salvator-X and ULCB development board can be equipped with
>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
>> use separate DTBs, but currently there's no sharing of board-specific
>> devices in DTS.
>>
>> This series reduces duplication by extracting common board support into
>> their own .dtsi files. As the level of support varies across boards and
>> SoCs, this requires the addition of a few external clocks and
>> placeholder devices on R-Car M3-W, so the common board support DTS can
>> refer to them.
>>
>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
>> M3-W, which are present in r8a7795.dtsi, and used in
>> r8a7795-salvator-x.dts,
>> - RFC patch 3 adds placeholders for devices that are not yet supported
>> and/or tested on R-Car M3-W, but used on R-Car H3,
>> - RFC patch 4 extracts common Salvator-X board support,
>> - RFC patch 5 extracts common ULCB board support.
>>
>> For R-Car H3 based boards, there are no functional changes.
>> For R-Car M3-W based boards, some new devices are now described in DT.
>>
>> Dependencies:
>> - renesas-devel-20170420-v4.11-rc7,
>> - Patches 1 and 2 can be applied as-is,
>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
>> out R-Car H3 and M3-W SiP"
>> (http://www.spinics.net/lists/devicetree/msg173820.html).
>>
>> DTB changes have been inspected using scripts/dtc/dtx_diff.
>> This has been tested on Salvator-X (both H3 and M3-W).
>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
>>
>> Thanks for your comments!
>
> Thanks for tackling this important problem. I have looked over the changes
> and they seem nice to me. I would, however, be more comfortable applying
> them if they were rested on the ULCB boards.
tested?
I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [SPAM]Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Ryder Lee @ 2017-04-26 8:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <CAK8P3a1vgi9VBZfRNq0dDKzmfe8FkHQtgz6fEXW9fyUnBHtaQQ@mail.gmail.com>
Hi
On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote:
> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> > Add documentation for PCIe host driver available in MT7623
> > series SoCs.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > .../bindings/pci/mediatek,mt7623-pcie.txt | 153 +++++++++++++++++++++
> > 1 file changed, 153 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> > new file mode 100644
> > index 0000000..ee93ba2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> > @@ -0,0 +1,153 @@
> > +Mediatek MT7623 PCIe controller
> > +
> > +Required properties:
> > +- compatible: Should contain "mediatek,mt7623-pcie".
>
> Did mediatek license the IP block from someone else or was it
> developed in-house? Is there a name and/or version identifier
> for the block itself other than identifying it as the one in mt7623?
Originally, it license from synopsys. Our designer add a wrapper to hide
the DBI detail so that we cannot use them directly. Perhaps I can call
it "mediatek,gen2v1-pcie", because we have a plan to upstream a in-house
Gen2 IP in the future.
> > +- device_type: Must be "pci"
> > +- reg: Base addresses and lengths of the pcie controller.
> > +- interrupts: A list of interrupt outputs of the controller.
>
> Please be more specific about what each interrupt is for, and how
> many there are.
OK.
> > +Required properties:
> > +- device_type: Must be "pci"
> > +- assigned-addresses: Address and size of the port configuration registers
> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > + and device number.
> > +- #address-cells: Must be 3
> > +- #size-cells: Must be 2
> > +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
> > + property is sufficient.
> > +- clocks: Must contain an entry for each entry in clock-names.
> > + See ../clocks/clock-bindings.txt for details.
> > +- clock-names: Must include the following entries:
> > + - sys_ck
> > +- resets: Must contain an entry for each entry in reset-names.
> > + See ../reset/reset.txt for details.
>
> This seems odd: you have a device that is simply identified as "pci"
> without any more specific ID, but you require additional properties
> (clocks, reset, ...) that are not part of the standard PCI binding.
>
> Can you clarify how the port devices related to the root device in
> this hardware design?
I will write clarify like this:
PCIe subsys includes one Host/PCI bridge and 3 PCIe MAC port. There
are 3 bus master for data access and 1 slave for configuration and
status register access. Each port has PIPE interface to PHY and
> Have you considered moving the nonstandard properties into the host
> bridge node and having that device deal with setting up the links
> to the other drivers? That way we could use the regular pcie
> port driver for the children.
>
OK, but I still want to use port->reset to catch reset properties in
driver.
> > +- reset-names: Must include the following entries:
> > + - pcie-reset
> > +- num-lanes: Number of lanes to use for this port.
> > +- phys: Must contain an entry for each entry in phy-names.
> > +- phy-names: Must include an entry for each sub node. Entries are of the form
> > + "pcie-phyN": where N ranges from 0 to the value specified for port number.
> > + See ../phy/phy-mt7623-pcie.txt for details.
>
> I think the name should not include the number of the port but rather
> be always the same here.
>
Hmm, I think it's better to keep the name here. It's more readable for
user to understand the relationship between port0 and phy0.
> Arnd
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
From: Ryder Lee @ 2017-04-26 8:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <CAK8P3a39TFkJ5=jp8me+Dyg-Qi-N_1ZKxpJGvnhmPEo4csnFCw@mail.gmail.com>
Hi,
On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote:
> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>
> > +static inline bool mtk_pcie_link_is_up(struct mtk_pcie_port *port)
> > +{
> > + return !!(readl_relaxed(port->base + PCIE_LINK_STATUS) &
> > + PCIE_PORT_LINKUP);
> > +}
>
> If this is not performance critical, please use the regular readl() instead
> of readl_relaxed().
I will correct it.
> > +static bool mtk_pcie_valid_device(struct mtk_pcie *pcie,
> > + struct pci_bus *bus, int devfn)
> > +{
> > + struct mtk_pcie_port *port;
> > + struct pci_dev *dev;
> > + struct pci_bus *pbus;
> > +
> > + /* if there is no link, then there is no device */
> > + list_for_each_entry(port, &pcie->ports, list) {
> > + if (bus->number == 0 && port->index == PCI_SLOT(devfn) &&
> > + mtk_pcie_link_is_up(port)) {
> > + return true;
> > + } else if (bus->number != 0) {
> > + pbus = bus;
> > + do {
> > + dev = pbus->self;
> > + if (port->index == PCI_SLOT(dev->devfn) &&
> > + mtk_pcie_link_is_up(port)) {
> > + return true;
> > + }
> > + pbus = dev->bus;
> > + } while (dev->bus->number != 0);
> > + }
> > + }
> > +
> > + return false;
> > +}
>
>
>
>
> > +static int mtk_pcie_hw_rd_cfg(struct mtk_pcie *pcie, u32 bus, u32 devfn,
> > + int where, int size, u32 *val)
> > +{
> > + writel(PCIE_CONF_ADDR(where, PCI_FUNC(devfn), PCI_SLOT(devfn), bus),
> > + pcie->base + PCIE_CFG_ADDR);
> > +
> > + *val = 0;
> > +
> > + switch (size) {
> > + case 1:
> > + *val = readb(pcie->base + PCIE_CFG_DATA + (where & 3));
> > + break;
> > + case 2:
> > + *val = readw(pcie->base + PCIE_CFG_DATA + (where & 2));
> > + break;
> > + case 4:
> > + *val = readl(pcie->base + PCIE_CFG_DATA);
> > + break;
> > + }
> > +
> > + return PCIBIOS_SUCCESSFUL;
> > +}
>
> This is a fairly standard set of read/write operations. Can you change
> the pci_ops
> to use pci_generic_config_read/pci_generic_config_write and an appropriate
> map function instead?
OK I will add a .map_bus() like this:
{ .
writel(PCIE_CONF_ADDR(where, fun, slot, bus), base + PCIE_CFG_ADDR);
return base + PCIE_CFG_DATA + (where & 3);
}
> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
> > +{
> > + struct device *dev = pcie->dev;
> > + struct mtk_pcie_port *port, *tmp;
> > + int err, linkup = 0;
> > +
> > + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
> > + err = clk_prepare_enable(port->sys_ck);
> > + if (err) {
> > + dev_err(dev, "failed to enable port%d clock\n",
> > + port->index);
> > + continue;
> > + }
> > +
> > + /* assert RC */
> > + reset_control_assert(port->reset);
> > + /* de-assert RC */
> > + reset_control_deassert(port->reset);
> > +
> > + /* power on PHY */
> > + err = phy_power_on(port->phy);
> > + if (err) {
> > + dev_err(dev, "failed to power on port%d phy\n",
> > + port->index);
> > + goto err_phy_on;
> > + }
> > +
> > + mtk_pcie_assert_ports(port);
> > +
>
> Similar to the comment I had for the binding, I wonder if it would be
> better to keep all the information about the ports in one place and
> then just deal with it at the root level.
>
> Alternatively, we could decide to standardize on the properties
> you have added to the pcie port node, but then I would handle
> them in the pcieport driver rather than in the host bridge driver.
Sorry, I'm not sure what you want me to do here.
I could move all clock operation in root level. But we need to keep the
reset and PHY operation sequence in the loop, In addition, we could
easily free resources if ports link fail.
How about moving this function to mtk_pcie_parse_and_add_res()?
> > +/*
> > + * This IP lacks interrupt status register to check or map INTx from
> > + * different devices at the same time.
> > + */
> > +static int __init mtk_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> > +{
> > + struct mtk_pcie *pcie = dev->bus->sysdata;
> > + struct mtk_pcie_port *port;
> > +
> > + list_for_each_entry(port, &pcie->ports, list)
> > + if (port->index == slot)
> > + return port->irq;
> > +
> > + return -1;
> > +}
>
> This looks odd, what is it needed for specifically? It looks like
> it's broken for devices behind bridges, and the interrupt mapping
> should normally come from the interrupt-map property, without
> the need for a driver specific map_irq override.
Our hardware just has a GIC for each port and lacks interrupt status for
host driver to distinguish INTx. So I return port IRQ here.
> > +static int mtk_pcie_register_ports(struct mtk_pcie *pcie)
> > +{
> > + struct pci_bus *bus, *child;
> > +
> > + bus = pci_scan_root_bus(pcie->dev, 0, &mtk_pcie_ops, pcie,
> > + &pcie->resources);
>
> Can you use the new pci_register_host_bridge() method instead of
> pci_scan_root_bus() here?
May I know what's difference between pci_scan_root_bus() and using
pci_register_host_bridge() directly? What situation should we use it?
It seems that just tegra use this new method currently.
I'm not sure whether I can still use pci_scan_root_bus() here?
> ARnd
Thanks for the review!
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-04-26 8:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland, devicetree, Kuninori Morimoto, Yoshihiro Shimoda,
Magnus Damm, linux-renesas-soc, Rob Herring, linux-arm-kernel
In-Reply-To: <1492779321-23939-1-git-send-email-geert+renesas@glider.be>
Hi Geert,
On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> The Renesas Salvator-X and ULCB development board can be equipped with
> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> use separate DTBs, but currently there's no sharing of board-specific
> devices in DTS.
>
> This series reduces duplication by extracting common board support into
> their own .dtsi files. As the level of support varies across boards and
> SoCs, this requires the addition of a few external clocks and
> placeholder devices on R-Car M3-W, so the common board support DTS can
> refer to them.
>
> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> M3-W, which are present in r8a7795.dtsi, and used in
> r8a7795-salvator-x.dts,
> - RFC patch 3 adds placeholders for devices that are not yet supported
> and/or tested on R-Car M3-W, but used on R-Car H3,
> - RFC patch 4 extracts common Salvator-X board support,
> - RFC patch 5 extracts common ULCB board support.
>
> For R-Car H3 based boards, there are no functional changes.
> For R-Car M3-W based boards, some new devices are now described in DT.
>
> Dependencies:
> - renesas-devel-20170420-v4.11-rc7,
> - Patches 1 and 2 can be applied as-is,
> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
> out R-Car H3 and M3-W SiP"
> (http://www.spinics.net/lists/devicetree/msg173820.html).
>
> DTB changes have been inspected using scripts/dtc/dtx_diff.
> This has been tested on Salvator-X (both H3 and M3-W).
> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
>
> Thanks for your comments!
Thanks for tackling this important problem. I have looked over the changes
and they seem nice to me. I would, however, be more comfortable applying
them if they were rested on the ULCB boards.
^ permalink raw reply
* Re: [PATCH 13/15] drm/sun4i: Add HDMI support
From: Chen-Yu Tsai @ 2017-04-26 7:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Mike Turquette, Stephen Boyd, dri-devel,
Daniel Vetter, David Airlie, Mark Rutland, Rob Herring,
devicetree, linux-clk, linux-arm-kernel, linux-kernel,
linux-sunxi
In-Reply-To: <20170426065005.zoewz53q7l7r5e7p@lukather>
On Wed, Apr 26, 2017 at 2:50 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Chen-Yu,
>
> On Fri, Apr 21, 2017 at 11:17:17PM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
>> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
>> > controller.
>> >
>> > That HDMI controller is able to do audio and CEC, but those have been left
>> > out for now.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> > ---
>> > drivers/gpu/drm/sun4i/Makefile | 5 +-
>> > drivers/gpu/drm/sun4i/sun4i_hdmi.h | 124 ++++++-
>> > drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 128 ++++++-
>> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 449 +++++++++++++++++++++-
>> > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 236 +++++++++++-
>> > 5 files changed, 942 insertions(+), 0 deletions(-)
>> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h
>> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
>> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
>> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>>
>> Applying patch #9608371 using 'git am'
>> Description: [13/15] drm/sun4i: Add HDMI support
>> Applying: drm/sun4i: Add HDMI support
>> .git/rebase-apply/patch:116: trailing whitespace.
>>
>> .git/rebase-apply/patch:531: trailing whitespace.
>>
>> .git/rebase-apply/patch:701: trailing whitespace.
>>
>> warning: 3 lines add whitespace errors.
>
> Fixed.
>
>> > +int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *parent)
>> > +{
>> > + struct clk_init_data init;
>> > + struct sun4i_ddc *ddc;
>> > + const char *parent_name;
>> > +
>> > + parent_name = __clk_get_name(parent);
>> > + if (!parent_name)
>> > + return -ENODEV;
>> > +
>> > + ddc = devm_kzalloc(hdmi->dev, sizeof(*ddc), GFP_KERNEL);
>> > + if (!ddc)
>> > + return -ENOMEM;
>> > +
>> > + init.name = "hdmi-ddc";
>> > + init.ops = &sun4i_ddc_ops;
>> > + init.parent_names = &parent_name;
>> > + init.num_parents = 1;
>> > + init.flags = CLK_SET_RATE_PARENT;
>>
>> I don't think this is really needed. It probably doesn't hurt though,
>> since DDC is used when HDMI is not used for displaying, but it might
>> affect any upstream PLLs, which theoretically may affect other users
>> of said PLLs. The DDC clock is slow enough that we should be able to
>> generate a usable clock rate anyway.
>
> Good point, I removed it.
>
>> > + writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
>> > + SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
>> > + hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
>> > +
>> > + x = mode->htotal - mode->hsync_start;
>> > + y = mode->vtotal - mode->vsync_start;
>>
>> I'm a bit skeptical about this one. All the other parameters are not
>> inclusive of other, why would this one be different? Shouldn't it
>> be "Xtotal - Xsync_end" instead?
>
> By the usual meaning of backporch, you're right. However, Allwinner's
> seems to have it's own, which is actually the backporch + sync length.
>
> We also have that on all the other connectors (and TCON), and this was
> confirmed at the time using a scope on an RGB signal.
Yes. On the later SoCs such as the A31, the user manual actually has
timing diagrams showing this.
Unlike the TCON, the HDMI controller's timings lists the front porch
separately, instead of an all inclusive Xtotal. This is what made me
look twice. This should be easy to confirm though. Since the HDMI modes
are well known and can be exactly reproduced on our hardware, we can
just check for any distortions or refresh rate errors.
>
>>
>> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
>> > + hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
>> > +
>> > + x = mode->hsync_start - mode->hdisplay;
>> > + y = mode->vsync_start - mode->vdisplay;
>> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
>> > + hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
>> > +
>> > + x = mode->hsync_end - mode->hsync_start;
>> > + y = mode->vsync_end - mode->vsync_start;
>> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
>> > + hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
>> > +
>> > + val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
>> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
>> > + val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
>> > +
>> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
>> > + val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
>> > +
>> > + writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
>>
>> You don't handle the interlaced video here, even though you set
>>
>> hdmi->connector.interlace_allowed = true
>>
>> later.
>
> I'll fix that.
>
>> The double clock and double scan flags aren't handled either, though
>> I don't understand which one is supposed to represent the need for the
>> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
>> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
>
> I'm not sure about this one though. I'd like to keep things quite
> simple for now and build up on that once the basis is working. Is it
> common in the wild?
If you drive the display at SDTV resolutions, then yes. Mode lines from
my HDMI monitor:
720x576i 50 720 732 795 864 576 580 586 625 flags: nhsync, nvsync,
interlace, dblclk; type: driver
720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
interlace, dblclk; type: driver
720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
interlace, dblclk; type: driver
AFAIK these are standard modes that all devices should support. Whether
they are used daily is another thing. Maybe block modes with dblclk
in .mode_fixup for now?
>> > + hdmi->base + SUN4I_HDMI_DDC_FIFO_CTRL_REG);
>> > + writel(SUN4I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) |
>> > + SUN4I_HDMI_DDC_ADDR_EDDC(0x60) |
>> > + SUN4I_HDMI_DDC_ADDR_OFFSET(offset) |
>> > + SUN4I_HDMI_DDC_ADDR_SLAVE(0x50),
>>
>> You can use DDC_ADDR from drm_edid.h.
>
> Done.
There's also DDC_SEGMENT_ADDR (which is 0x30) you can use to replace 0x60.
The 1 bit shift is probably something related to I2C.
>> > +static enum drm_connector_status
>> > +sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
>> > +{
>> > + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
>> > + unsigned long reg;
>> > +
>> > + if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
>> > + reg & SUN4I_HDMI_HPD_HIGH,
>> > + 0, 500000))
>>
>> We shouldn't need to do polling here. It should just return the status
>> at the instance it's called. Instead we should have a worker that does
>> polling to check if something is plugged or unplugged. I don't see any
>> interrupt bits for this though. :(
>
> As far as I know, polling in detect is okay. Why would you want to
> remove it?
Hmm, I guess it only serves to debounce the detection, i.e. extend the
time period of validity from the instance the function is run to the
instance plus 500 ms.
To be clear I'm not against it. However this only really works when
the DRM subsystem is brought up. We still need something else for
hotplugging, which is what I was arguing for.
Regards
ChenYu
>> > + ret = drm_encoder_init(drm,
>> > + &hdmi->encoder,
>> > + &sun4i_hdmi_funcs,
>> > + DRM_MODE_ENCODER_TMDS,
>> > + NULL);
>> > + if (ret) {
>> > + dev_err(dev, "Couldn't initialise the HDMI encoder\n");
>> > + return ret;
>> > + }
>> > +
>> > + hdmi->encoder.possible_crtcs = BIT(0);
>>
>> You can use drm_of_find_possible_crtcs() now. See the TV encoder driver.
>
> Ack.
>
>> > +
>> > + drm_connector_helper_add(&hdmi->connector,
>> > + &sun4i_hdmi_connector_helper_funcs);
>> > + ret = drm_connector_init(drm, &hdmi->connector,
>> > + &sun4i_hdmi_connector_funcs,
>> > + DRM_MODE_CONNECTOR_HDMIA);
>> > + if (ret) {
>> > + dev_err(dev,
>> > + "Couldn't initialise the Composite connector\n");
>>
>> Wrong connector.
>
> Fixed.
>
>> > + ret = sun4i_ddc_create(hdmi, hdmi->tmds_clk);
>> > + if (ret) {
>> > + dev_err(&pdev->dev, "Couldn't create the DDC clock\n");
>> > + return ret;
>> > + }
>>
>> We do all this in the bind function for all the other components.
>> Any particular reason to do it differently here?
>
> Not really, I'll change it.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/2] gpio: DT bindings, move tca9554 from pcf857x to pca953x
From: Geert Uytterhoeven @ 2017-04-26 7:56 UTC (permalink / raw)
To: Anders Darander
Cc: Linus Walleij, Alexandre Courbot, Rob Herring,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Rutland
In-Reply-To: <20170421124631.19269-2-anders@chargestorm.se>
On Fri, Apr 21, 2017 at 2:46 PM, Anders Darander <anders@chargestorm.se> wrote:
> The TCA9554 is similar to the PCA9554. Update the DT binding docs.
>
> Signed-off-by: Anders Darander <anders@chargestorm.se>
> ---
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 +
> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt | 1 -
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index e63935710011..7f57271df2bc 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -26,6 +26,7 @@ Required properties:
> ti,tca6416
> ti,tca6424
> ti,tca9539
> + ti,tca9554
> onsemi,pca9654
> exar,xra1202
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> index ada4e2973323..7d3bd631d011 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> @@ -25,7 +25,6 @@ Required Properties:
> - "nxp,pcf8574": For the NXP PCF8574
> - "nxp,pcf8574a": For the NXP PCF8574A
> - "nxp,pcf8575": For the NXP PCF8575
> - - "ti,tca9554": For the TI TCA9554
>
> - reg: I2C slave address.
BTW, gpio-pca953x.txt seems to lack lots of gpio-controller-related properties.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: r8a7795: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 7:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas, linux-arm-kernel@lists.infradead.org, Magnus Damm,
Sergei Shtylyov, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdVw9OJZarw3SRa7NuuaMtmDKPVN3Om0GFVFm5k_YAqn6g@mail.gmail.com>
On Mon, Apr 24, 2017 at 11:03:54AM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 24, 2017 at 10:51 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > The device trees for Renesas SoCs use either pfc or pin-controller
> > as the node name for the PFC device. This patch is intended to take a step
> > towards unifying the node name used as pin-controller which appears to
> > be more the more generic of the two and thus more in keeping with the DT
>
> s/be more/be/
>
> > specs.
> >
> > My analysis is that this is a user-visible change to the extent that kernel
> > logs, and sysfs entries change from e6060000.pfc and pfc@e6060000 to
> > e6060000.pin-controller and pin-controller@e6060000.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, I fixed the typo when queuing this up.
^ permalink raw reply
* Re: [PATCH v2 09/23] MAINTAINERS: Add file patterns for infiniband device tree bindings
From: Geert Uytterhoeven @ 2017-04-26 7:36 UTC (permalink / raw)
To: Doug Ledford
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sean Hefty,
Hal Rosenstock, linux-rdma
In-Reply-To: <1493148079.3041.90.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Doug,
On Tue, Apr 25, 2017 at 9:21 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Sun, 2017-03-26 at 10:45 +0200, Geert Uytterhoeven wrote:
>> On Sat, Mar 25, 2017 at 3:40 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> wrote:
>> >
>> > 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
>>
>> That wasn't my intention, though, cfr. the quoted paragraph above
>> ("you" and "your subsystem").
>
> Sorry, I didn't catch that in the original message. I've applied it to
> my tree.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards
From: Krzysztof Kozlowski @ 2017-04-26 7:22 UTC (permalink / raw)
To: Hoegeun Kwon
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
kgene-DgEjT+Ai2ygdnm+yROfE0A, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
a.hajda-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <1493085261-3488-1-git-send-email-hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Tue, Apr 25, 2017 at 3:54 AM, Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
> 1 file changed, 1 deletion(-)
>
Looks correct. It is too late for me for v4.12 so I will pick it up
for v4.13. For my reference:
Reviewed-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Best regards,
Krzysztof
--
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: [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support
From: Maxime Ripard @ 2017-04-26 6:50 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Mike Turquette, Stephen Boyd,
linux-kernel, dri-devel, linux-sunxi, Rob Herring, Daniel Vetter,
linux-clk, linux-arm-kernel
In-Reply-To: <CAGb2v66n6AXbOAh05V_Gv2UgRp=xEMG9qhJU8JSuy4-F-UOQQQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7563 bytes --]
Hi Chen-Yu,
On Fri, Apr 21, 2017 at 11:17:17PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
> > controller.
> >
> > That HDMI controller is able to do audio and CEC, but those have been left
> > out for now.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/gpu/drm/sun4i/Makefile | 5 +-
> > drivers/gpu/drm/sun4i/sun4i_hdmi.h | 124 ++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 128 ++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 449 +++++++++++++++++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 236 +++++++++++-
> > 5 files changed, 942 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>
> Applying patch #9608371 using 'git am'
> Description: [13/15] drm/sun4i: Add HDMI support
> Applying: drm/sun4i: Add HDMI support
> .git/rebase-apply/patch:116: trailing whitespace.
>
> .git/rebase-apply/patch:531: trailing whitespace.
>
> .git/rebase-apply/patch:701: trailing whitespace.
>
> warning: 3 lines add whitespace errors.
Fixed.
> > +int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *parent)
> > +{
> > + struct clk_init_data init;
> > + struct sun4i_ddc *ddc;
> > + const char *parent_name;
> > +
> > + parent_name = __clk_get_name(parent);
> > + if (!parent_name)
> > + return -ENODEV;
> > +
> > + ddc = devm_kzalloc(hdmi->dev, sizeof(*ddc), GFP_KERNEL);
> > + if (!ddc)
> > + return -ENOMEM;
> > +
> > + init.name = "hdmi-ddc";
> > + init.ops = &sun4i_ddc_ops;
> > + init.parent_names = &parent_name;
> > + init.num_parents = 1;
> > + init.flags = CLK_SET_RATE_PARENT;
>
> I don't think this is really needed. It probably doesn't hurt though,
> since DDC is used when HDMI is not used for displaying, but it might
> affect any upstream PLLs, which theoretically may affect other users
> of said PLLs. The DDC clock is slow enough that we should be able to
> generate a usable clock rate anyway.
Good point, I removed it.
> > + writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
> > + SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
> > +
> > + x = mode->htotal - mode->hsync_start;
> > + y = mode->vtotal - mode->vsync_start;
>
> I'm a bit skeptical about this one. All the other parameters are not
> inclusive of other, why would this one be different? Shouldn't it
> be "Xtotal - Xsync_end" instead?
By the usual meaning of backporch, you're right. However, Allwinner's
seems to have it's own, which is actually the backporch + sync length.
We also have that on all the other connectors (and TCON), and this was
confirmed at the time using a scope on an RGB signal.
>
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
> > +
> > + x = mode->hsync_start - mode->hdisplay;
> > + y = mode->vsync_start - mode->vdisplay;
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
> > +
> > + x = mode->hsync_end - mode->hsync_start;
> > + y = mode->vsync_end - mode->vsync_start;
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
> > +
> > + val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > + val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > + val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
> > +
> > + writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
>
> You don't handle the interlaced video here, even though you set
>
> hdmi->connector.interlace_allowed = true
>
> later.
I'll fix that.
> The double clock and double scan flags aren't handled either, though
> I don't understand which one is supposed to represent the need for the
> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
I'm not sure about this one though. I'd like to keep things quite
simple for now and build up on that once the basis is working. Is it
common in the wild?
> > + hdmi->base + SUN4I_HDMI_DDC_FIFO_CTRL_REG);
> > + writel(SUN4I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) |
> > + SUN4I_HDMI_DDC_ADDR_EDDC(0x60) |
> > + SUN4I_HDMI_DDC_ADDR_OFFSET(offset) |
> > + SUN4I_HDMI_DDC_ADDR_SLAVE(0x50),
>
> You can use DDC_ADDR from drm_edid.h.
Done.
> > +static enum drm_connector_status
> > +sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
> > +{
> > + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
> > + unsigned long reg;
> > +
> > + if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
> > + reg & SUN4I_HDMI_HPD_HIGH,
> > + 0, 500000))
>
> We shouldn't need to do polling here. It should just return the status
> at the instance it's called. Instead we should have a worker that does
> polling to check if something is plugged or unplugged. I don't see any
> interrupt bits for this though. :(
As far as I know, polling in detect is okay. Why would you want to
remove it?
> > + ret = drm_encoder_init(drm,
> > + &hdmi->encoder,
> > + &sun4i_hdmi_funcs,
> > + DRM_MODE_ENCODER_TMDS,
> > + NULL);
> > + if (ret) {
> > + dev_err(dev, "Couldn't initialise the HDMI encoder\n");
> > + return ret;
> > + }
> > +
> > + hdmi->encoder.possible_crtcs = BIT(0);
>
> You can use drm_of_find_possible_crtcs() now. See the TV encoder driver.
Ack.
> > +
> > + drm_connector_helper_add(&hdmi->connector,
> > + &sun4i_hdmi_connector_helper_funcs);
> > + ret = drm_connector_init(drm, &hdmi->connector,
> > + &sun4i_hdmi_connector_funcs,
> > + DRM_MODE_CONNECTOR_HDMIA);
> > + if (ret) {
> > + dev_err(dev,
> > + "Couldn't initialise the Composite connector\n");
>
> Wrong connector.
Fixed.
> > + ret = sun4i_ddc_create(hdmi, hdmi->tmds_clk);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't create the DDC clock\n");
> > + return ret;
> > + }
>
> We do all this in the bind function for all the other components.
> Any particular reason to do it differently here?
Not really, I'll change it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/3] iio: adc: meson-saradc: mark all meson_sar_adc_data static and const
From: Jonathan Cameron @ 2017-04-26 6:31 UTC (permalink / raw)
To: Martin Blumenstingl, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: carlo-KA+7E9HrN00dnm+yROfE0A, khilman-rdvid1DuHRBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170417182820.26670-4-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On 17/04/17 19:28, Martin Blumenstingl wrote:
> These are only passed as of_device_id.data and never modified. Thus we
> can mark them as static const, just like the of_device_id instances
> where they are used.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Reordering the patches would make this simpler as you'd only have
to do the existing ones.
Not a bit issue though so you could just not bother...
Jonathan
> ---
> drivers/iio/adc/meson_saradc.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index cf13691009ee..8f742b71b165 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -843,31 +843,31 @@ static const struct iio_info meson_sar_adc_iio_info = {
> .driver_module = THIS_MODULE,
> };
>
> -struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> .has_bl30_integration = false,
> .resolution = 10,
> .name = "meson-meson8b-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> .has_bl30_integration = false,
> .resolution = 10,
> .name = "meson-meson8b-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> .has_bl30_integration = true,
> .resolution = 10,
> .name = "meson-gxbb-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxl-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxm-saradc",
>
^ permalink raw reply
* Re: [PATCH 2/3] iio: adc: meson-saradc: add Meson8b SoC compatibility
From: Jonathan Cameron @ 2017-04-26 6:29 UTC (permalink / raw)
To: Martin Blumenstingl, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: carlo-KA+7E9HrN00dnm+yROfE0A, khilman-rdvid1DuHRBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170417182820.26670-3-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On 17/04/17 19:28, Martin Blumenstingl wrote:
> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
>
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
>
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Fine apart from what superficially looks like a cut and paste error inline...
Jonathan
> ---
> drivers/iio/adc/meson_saradc.c | 80 +++++++++++++++++++++++++++++-------------
> 1 file changed, 56 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..cf13691009ee 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
> };
>
> struct meson_sar_adc_data {
> + bool has_bl30_integration;
> unsigned int resolution;
> const char *name;
> };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>
> mutex_lock(&indio_dev->mlock);
>
> - /* prevent BL30 from using the SAR ADC while we are using it */
> - regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> - /* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> - do {
> - udelay(1);
> - regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> - } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> - if (timeout < 0)
> - return -ETIMEDOUT;
> + if (priv->data->has_bl30_integration) {
> + /* prevent BL30 from using the SAR ADC while we are using it */
> + regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> + /*
> + * wait until BL30 releases it's lock (so we can use the SAR
> + * ADC)
> + */
> + do {
> + udelay(1);
> + regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> + } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> + if (timeout < 0)
> + return -ETIMEDOUT;
> + }
>
> return 0;
> }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
> {
> struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>
> - /* allow BL30 to use the SAR ADC again */
> - regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> + if (priv->data->has_bl30_integration)
> + /* allow BL30 to use the SAR ADC again */
> + regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>
> mutex_unlock(&indio_dev->mlock);
> }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> */
> meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>
> - /*
> - * leave sampling delay and the input clocks as configured by BL30 to
> - * make sure BL30 gets the values it expects when reading the
> - * temperature sensor.
> - */
> - regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
> - if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> - return 0;
> + if (priv->data->has_bl30_integration) {
> + /*
> + * leave sampling delay and the input clocks as configured by
> + * BL30 to make sure BL30 gets the values it expects when
> + * reading the temperature sensor.
> + */
> + regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
> + if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> + return 0;
> + }
>
> meson_sar_adc_stop_sample_engine(indio_dev);
>
> @@ -834,23 +843,46 @@ static const struct iio_info meson_sar_adc_iio_info = {
> .driver_module = THIS_MODULE,
> };
>
> +struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> + .has_bl30_integration = false,
> + .resolution = 10,
> + .name = "meson-meson8b-saradc",
Not meson-meson8-saradc?
> +};
> +
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> + .has_bl30_integration = false,
> + .resolution = 10,
> + .name = "meson-meson8b-saradc",
> +};
> +
> struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> + .has_bl30_integration = true,
> .resolution = 10,
> .name = "meson-gxbb-saradc",
> };
>
> struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> + .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxl-saradc",
> };
>
> struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> + .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxm-saradc",
> };
>
> static const struct of_device_id meson_sar_adc_of_match[] = {
> {
> + .compatible = "amlogic,meson8-saradc",
> + .data = &meson_sar_adc_meson8_data,
> + },
> + {
> + .compatible = "amlogic,meson8b-saradc",
> + .data = &meson_sar_adc_meson8b_data,
> + },
> + {
> .compatible = "amlogic,meson-gxbb-saradc",
> .data = &meson_sar_adc_gxbb_data,
> }, {
>
--
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/3] drm/sun4i: More cleanups and fixes
From: Maxime Ripard @ 2017-04-26 6:21 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: David Airlie, Rob Herring, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170425152505.6796-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
On Tue, Apr 25, 2017 at 11:25:02PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> The subject is probably getting old. Here are a few more cleanups.
>
> Patch 1 should have been part of the patch
>
> drm/sun4i: Use lists to track registered display backends and TCONs
>
> from my multiple pipeline support series. Please squash it in if you can.
>
> Patch 2 just moves setting the TCON clocks back inside the TCON driver.
>
> Patch 3 cleans up a DRM driver debug message.
Applied all, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [GIT PULL] Immutable branch between MFD and IIO due for the v4.12 merge window
From: Jonathan Cameron @ 2017-04-26 5:51 UTC (permalink / raw)
To: Lee Jones
Cc: mark.rutland, thomas.petazzoni, lars, linux-pm, liam,
linux-kernel, linux-sunxi, sre, linux-iio, linux, Quentin Schulz,
wens, robh+dt, icenowy, pmeerw, knaack.h, maxime.ripard,
devicetree, linux-arm-kernel
In-Reply-To: <20170424110239.cv5nylgvymhwvg4w@dell>
On 24/04/17 12:02, Lee Jones wrote:
> On Fri, 14 Apr 2017, Jonathan Cameron wrote:
>
>> On 11/04/17 11:05, Lee Jones wrote:
>>> Enjoy!
>>>
>>> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>>>
>>> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>>>
>>> are available in the git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-iio-v4.12
>>>
>>> for you to fetch changes up to f2499ab450d3052097ba53a7d763f767935c0c59:
>>>
>>> iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs (2017-04-11 11:02:33 +0100)
>>>
>>> ----------------------------------------------------------------
>>> Immutable branch between MFD and IIO due for the v4.12 merge window
>>>
>>> ----------------------------------------------------------------
>>> Quentin Schulz (1):
>>> iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
>>>
>>> drivers/iio/adc/Kconfig | 10 +
>>> drivers/iio/adc/Makefile | 1 +
>>> drivers/iio/adc/axp20x_adc.c | 617 +++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 628 insertions(+)
>>> create mode 100644 drivers/iio/adc/axp20x_adc.c
>>>
>> Hi Lee,
>>
>> Thanks for doing this, but the reason it was going to go through your
>> tree in the first place was a dependency on
>> commit 4707274714ef ("mfd: axp20x: Correct name of temperature data ADC registers")
>>
>> Not present in the immutable branch.
>>
>> There isn't much time for anything else going on around this driver though
>> so other than a possible merge conflict on the Kconfig and Makefile shouldn't
>> matter if this just goes through mfd. (famous last words ;)
>
> It's not as though you committed it to text and sent it out to a
> public mailing list for us all to reference though is it? Doh!
>
It came up in the original discussions (which was the only reason I knew).
Chen-Yu Tsai in email:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/495789.html
Quentin did put a link in his request that you take it, but removing the
need to click would have been better!
Jonathan
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Rajendra Nayak @ 2017-04-26 4:32 UTC (permalink / raw)
To: Sudeep Holla, Viresh Kumar, Mark Brown
Cc: Rafael Wysocki, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lina.iyer-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <95aa4b97-4e1a-13bb-f4d8-982b778012ba-5wv7dgnIgG8@public.gmane.org>
> On 17/04/17 06:27, Viresh Kumar wrote:
>> On 13-04-17, 14:42, Sudeep Holla wrote:
>>> What I was referring is about power domain provider with multiple power
>>> domains(simply #power-domain-cells=<1> case as explained in the
>>> power-domain specification.
>>
>> I am not sure if we should be looking to target such a situation for now, as
>> that would be like this:
>>
>> Device controlled by Domain A. Domain A itself is controlled by Domain B and
>> Domain C.
>>
>
> No, may be I was not so clear. I am just referring a power controller
> that provides say 3 different power domains and are indexed 0 - 2.
> The consumer just passes the index along with the phandle for the power
> domain info.
>
>> Though we will end up converting the domain-performance-state property to an
>> array if that is required in near future.
>>
>
> OK, better to document that so that we know how to extend it. We have
> #power-domain-cells=<1> on Juno with SCPI.
>
>>> Yes. To simplify what not we just have power-domain for a device and
>>> change state of that domain to change the performance of that device.
>>
>> Consider this case to understand what I have in Mind.
>>
>> The power domain have its states as A, B, C, D. There can be multiple devices
>> regulated by that domain and one of the devices have its power states as: A1,
>> A2, A3, B1, B2, B3, C1, C2, C3, D1, D2, D3 and all these states have different
>> frequency/voltages.
>>
>> IOW, the devices can have regulators as well and may want to fine tune within
>> the domain performance-state.
>>
>
> Understood. I would incline towards reusing regulators we that's what is
> changed behind the scene. Calling this operating performance point
> is misleading and doesn't align well with existing specs/features.
[]...
>>> If we are looking this power-domains with performance as just some
>>> *advanced regulators*, I don't like the complexity added.
+ Mark
I don;t see any public discussions on why we ruled out using regulators to
support this but maybe there were some offline discussions on this.
Mark, this is a long thread, so just summarizing here to give you the context.
At qualcomm, we have an external M3 core (running its own firmware) which controls
a few voltage rails (including AVS on those). The devices vote for the voltage levels
(or performance levels) they need by passing an integer value to the M3 (not actual
voltage values). Since that didn't fit well with the existing regulator apis it was
proposed we look at modeling these as powerdomain performance levels (and reuse genpd
framework) which is what this series from Viresh is about.
Since the discussion now is moving towards 'why not use regulator framework for this
instead of adding all the complexity with powerdomain performance levels since
these are regulators underneath', I looped you in so you can provide some feedback
on can these really be modeled as some *advanced regulators* with some apis to set some
regulator performance levels (instead of voltage levels).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree
From: Ryan Lee @ 2017-04-26 2:51 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
Kuninori Morimoto, Arnd Bergmann,
ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
lars-Qo5EllUWu/uELgA04lAiVw, bardliao-Rasf1IRRPZFBDgjK7y7TUQ,
nh6z-fFIq/eER6g8, KCHSU0-KrzQf0k3Iz9BDgjK7y7TUQ, Axel Lin,
romain.perier-ZGY8ohtN/8qB+jHODAdFcQ, Srinivas Kandagatla,
oder_chiou-Rasf1IRRPZFBDgjK7y7TUQ,
Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dylan Reid, Ryan Lee
In-Reply-To: <CAN4-oj=+WuNShte3e27XCWNHVTw6dBTUiQ=dmCLcX6nA9zx1eg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 25, 2017 at 9:51 AM, Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org> wrote:
> '
>
> On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> The patch
>>
>> ASoC: Add support for Maxim Integrated MAX98927 Amplifier
>>
>> has been applied to the asoc tree at
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>>
>> All being well this means that it will be integrated into the linux-next
>> tree (usually sometime in the next 24 hours) and sent to Linus during
>> the next merge window (or sooner if it is a bug fix), however if
>> problems are discovered then the patch may be dropped or reverted.
>>
>> You may get further e-mails resulting from automated or manual testing
>> and review of the tree, please engage with people reporting problems and
>> send followup patches addressing any issues that are reported if needed.
>>
>> If any updates are required or you are submitting further changes they
>> should be sent as incremental updates against current git, existing
>> patches will not be replaced.
>>
>> Please add any relevant lists and maintainers to the CCs when replying
>> to this mail.
>>
>> Thanks,
>> Mark
>
> I have tried to check MAX98927 driver on linux-next tree and
> 'git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git' but
> have failed.
> So I wanted to check the current status of MAX98927 driver.
> I'm sorry for top-posting.
Please ignore this mail.
I just checked it is on linux-next tree.
I'm sorry again to make people confused.
>
>>
>> From 7c0c2000716e64151b3c0c62026c18f31537ebe9 Mon Sep 17 00:00:00 2001
>> From: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
>> Date: Tue, 4 Apr 2017 02:23:08 +0900
>> Subject: [PATCH] ASoC: Add support for Maxim Integrated MAX98927 Amplifier
>>
>> Signed-off-by: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
>> Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> .../devicetree/bindings/sound/max98925.txt | 22 -
>> .../devicetree/bindings/sound/max98926.txt | 32 -
>> .../devicetree/bindings/sound/max9892x.txt | 41 +
>> sound/soc/codecs/Kconfig | 5 +
>> sound/soc/codecs/Makefile | 2 +
>> sound/soc/codecs/max98927.c | 841 +++++++++++++++++++++
>> sound/soc/codecs/max98927.h | 272 +++++++
>> 7 files changed, 1161 insertions(+), 54 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/sound/max98925.txt
>> delete mode 100644 Documentation/devicetree/bindings/sound/max98926.txt
>> create mode 100644 Documentation/devicetree/bindings/sound/max9892x.txt
>> create mode 100644 sound/soc/codecs/max98927.c
>> create mode 100644 sound/soc/codecs/max98927.h
>>
>> diff --git a/Documentation/devicetree/bindings/sound/max98925.txt b/Documentation/devicetree/bindings/sound/max98925.txt
>> deleted file mode 100644
>> index 27be63e2aa0d..000000000000
>> --- a/Documentation/devicetree/bindings/sound/max98925.txt
>> +++ /dev/null
>> @@ -1,22 +0,0 @@
>> -max98925 audio CODEC
>> -
>> -This device supports I2C.
>> -
>> -Required properties:
>> -
>> - - compatible : "maxim,max98925"
>> -
>> - - vmon-slot-no : slot number used to send voltage information
>> -
>> - - imon-slot-no : slot number used to send current information
>> -
>> - - reg : the I2C address of the device for I2C
>> -
>> -Example:
>> -
>> -codec: max98925@1a {
>> - compatible = "maxim,max98925";
>> - vmon-slot-no = <0>;
>> - imon-slot-no = <2>;
>> - reg = <0x1a>;
>> -};
>> diff --git a/Documentation/devicetree/bindings/sound/max98926.txt b/Documentation/devicetree/bindings/sound/max98926.txt
>> deleted file mode 100644
>> index 0b7f4e4d5f9a..000000000000
>> --- a/Documentation/devicetree/bindings/sound/max98926.txt
>> +++ /dev/null
>> @@ -1,32 +0,0 @@
>> -max98926 audio CODEC
>> -
>> -This device supports I2C.
>> -
>> -Required properties:
>> -
>> - - compatible : "maxim,max98926"
>> -
>> - - vmon-slot-no : slot number used to send voltage information
>> - or in inteleave mode this will be used as
>> - interleave slot.
>> -
>> - - imon-slot-no : slot number used to send current information
>> -
>> - - interleave-mode : When using two MAX98926 in a system it is
>> - possible to create ADC data that that will
>> - overflow the frame size. Digital Audio Interleave
>> - mode provides a means to output VMON and IMON data
>> - from two devices on a single DOUT line when running
>> - smaller frames sizes such as 32 BCLKS per LRCLK or
>> - 48 BCLKS per LRCLK.
>> -
>> - - reg : the I2C address of the device for I2C
>> -
>> -Example:
>> -
>> -codec: max98926@1a {
>> - compatible = "maxim,max98926";
>> - vmon-slot-no = <0>;
>> - imon-slot-no = <2>;
>> - reg = <0x1a>;
>> -};
>> diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt b/Documentation/devicetree/bindings/sound/max9892x.txt
>> new file mode 100644
>> index 000000000000..f6171591ddc6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/max9892x.txt
>> @@ -0,0 +1,41 @@
>> +Maxim Integrated MAX98925/MAX98926/MAX98927 Speaker Amplifier
>> +
>> +This device supports I2C.
>> +
>> +Required properties:
>> +
>> + - compatible : should be one of the following
>> + - "maxim,max98925"
>> + - "maxim,max98926"
>> + - "maxim,max98927"
>> +
>> + - vmon-slot-no : slot number used to send voltage information
>> + or in inteleave mode this will be used as
>> + interleave slot.
>> + MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
>> + MAX98927 slot range : 0 ~ 15, Default : 0
>> +
>> + - imon-slot-no : slot number used to send current information
>> + MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
>> + MAX98927 slot range : 0 ~ 15, Default : 0
>> +
>> + - interleave-mode : When using two MAX9892X in a system it is
>> + possible to create ADC data that that will
>> + overflow the frame size. Digital Audio Interleave
>> + mode provides a means to output VMON and IMON data
>> + from two devices on a single DOUT line when running
>> + smaller frames sizes such as 32 BCLKS per LRCLK or
>> + 48 BCLKS per LRCLK.
>> + Range : 0 (off), 1 (on), Default : 0
>> +
>> + - reg : the I2C address of the device for I2C
>> +
>> +Example:
>> +
>> +codec: max98927@3a {
>> + compatible = "maxim,max98927";
>> + vmon-slot-no = <0>;
>> + imon-slot-no = <1>;
>> + interleave-mode = <0>;
>> + reg = <0x3a>;
>> +};
>> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
>> index 9e1718a8cb1c..65e31ab88280 100644
>> --- a/sound/soc/codecs/Kconfig
>> +++ b/sound/soc/codecs/Kconfig
>> @@ -89,6 +89,7 @@ config SND_SOC_ALL_CODECS
>> select SND_SOC_MAX9867 if I2C
>> select SND_SOC_MAX98925 if I2C
>> select SND_SOC_MAX98926 if I2C
>> + select SND_SOC_MAX98927 if I2C
>> select SND_SOC_MAX9850 if I2C
>> select SND_SOC_MAX9860 if I2C
>> select SND_SOC_MAX9768 if I2C
>> @@ -585,6 +586,10 @@ config SND_SOC_MAX98925
>> config SND_SOC_MAX98926
>> tristate
>>
>> +config SND_SOC_MAX98927
>> + tristate "Maxim Integrated MAX98927 Speaker Amplifier"
>> + depends on I2C
>> +
>> config SND_SOC_MAX9850
>> tristate
>>
>> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
>> index 7e1dad79610b..64656c43200c 100644
>> --- a/sound/soc/codecs/Makefile
>> +++ b/sound/soc/codecs/Makefile
>> @@ -84,6 +84,7 @@ snd-soc-max98371-objs := max98371.o
>> snd-soc-max9867-objs := max9867.o
>> snd-soc-max98925-objs := max98925.o
>> snd-soc-max98926-objs := max98926.o
>> +snd-soc-max98927-objs := max98927.o
>> snd-soc-max9850-objs := max9850.o
>> snd-soc-max9860-objs := max9860.o
>> snd-soc-mc13783-objs := mc13783.o
>> @@ -312,6 +313,7 @@ obj-$(CONFIG_SND_SOC_MAX98357A) += snd-soc-max98357a.o
>> obj-$(CONFIG_SND_SOC_MAX9867) += snd-soc-max9867.o
>> obj-$(CONFIG_SND_SOC_MAX98925) += snd-soc-max98925.o
>> obj-$(CONFIG_SND_SOC_MAX98926) += snd-soc-max98926.o
>> +obj-$(CONFIG_SND_SOC_MAX98927) += snd-soc-max98927.o
>> obj-$(CONFIG_SND_SOC_MAX9850) += snd-soc-max9850.o
>> obj-$(CONFIG_SND_SOC_MAX9860) += snd-soc-max9860.o
>> obj-$(CONFIG_SND_SOC_MC13783) += snd-soc-mc13783.o
>> diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
>> new file mode 100644
>> index 000000000000..b5ee29499e16
>> --- /dev/null
>> +++ b/sound/soc/codecs/max98927.c
>> @@ -0,0 +1,841 @@
>> +/*
>> + * max98927.c -- MAX98927 ALSA Soc Audio driver
>> + *
>> + * Copyright (C) 2016 Maxim Integrated Products
>> + * Author: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + */
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +#include <linux/cdev.h>
>> +#include <sound/pcm.h>
>> +#include <sound/pcm_params.h>
>> +#include <sound/soc.h>
>> +#include <linux/gpio.h>
>> +#include <linux/of_gpio.h>
>> +#include <sound/tlv.h>
>> +#include "max98927.h"
>> +
>> +static struct reg_default max98927_reg[] = {
>> + {MAX98927_R0001_INT_RAW1, 0x00},
>> + {MAX98927_R0002_INT_RAW2, 0x00},
>> + {MAX98927_R0003_INT_RAW3, 0x00},
>> + {MAX98927_R0004_INT_STATE1, 0x00},
>> + {MAX98927_R0005_INT_STATE2, 0x00},
>> + {MAX98927_R0006_INT_STATE3, 0x00},
>> + {MAX98927_R0007_INT_FLAG1, 0x00},
>> + {MAX98927_R0008_INT_FLAG2, 0x00},
>> + {MAX98927_R0009_INT_FLAG3, 0x00},
>> + {MAX98927_R000A_INT_EN1, 0x00},
>> + {MAX98927_R000B_INT_EN2, 0x00},
>> + {MAX98927_R000C_INT_EN3, 0x00},
>> + {MAX98927_R000D_INT_FLAG_CLR1, 0x00},
>> + {MAX98927_R000E_INT_FLAG_CLR2, 0x00},
>> + {MAX98927_R000F_INT_FLAG_CLR3, 0x00},
>> + {MAX98927_R0010_IRQ_CTRL, 0x00},
>> + {MAX98927_R0011_CLK_MON, 0x00},
>> + {MAX98927_R0012_WDOG_CTRL, 0x00},
>> + {MAX98927_R0013_WDOG_RST, 0x00},
>> + {MAX98927_R0014_MEAS_ADC_THERM_WARN_THRESH, 0x00},
>> + {MAX98927_R0015_MEAS_ADC_THERM_SHDN_THRESH, 0x00},
>> + {MAX98927_R0016_MEAS_ADC_THERM_HYSTERESIS, 0x00},
>> + {MAX98927_R0017_PIN_CFG, 0x55},
>> + {MAX98927_R0018_PCM_RX_EN_A, 0x00},
>> + {MAX98927_R0019_PCM_RX_EN_B, 0x00},
>> + {MAX98927_R001A_PCM_TX_EN_A, 0x00},
>> + {MAX98927_R001B_PCM_TX_EN_B, 0x00},
>> + {MAX98927_R001C_PCM_TX_HIZ_CTRL_A, 0x00},
>> + {MAX98927_R001D_PCM_TX_HIZ_CTRL_B, 0x00},
>> + {MAX98927_R001E_PCM_TX_CH_SRC_A, 0x00},
>> + {MAX98927_R001F_PCM_TX_CH_SRC_B, 0x00},
>> + {MAX98927_R0020_PCM_MODE_CFG, 0x40},
>> + {MAX98927_R0021_PCM_MASTER_MODE, 0x00},
>> + {MAX98927_R0022_PCM_CLK_SETUP, 0x22},
>> + {MAX98927_R0023_PCM_SR_SETUP1, 0x00},
>> + {MAX98927_R0024_PCM_SR_SETUP2, 0x00},
>> + {MAX98927_R0025_PCM_TO_SPK_MONOMIX_A, 0x00},
>> + {MAX98927_R0026_PCM_TO_SPK_MONOMIX_B, 0x00},
>> + {MAX98927_R0027_ICC_RX_EN_A, 0x00},
>> + {MAX98927_R0028_ICC_RX_EN_B, 0x00},
>> + {MAX98927_R002B_ICC_TX_EN_A, 0x00},
>> + {MAX98927_R002C_ICC_TX_EN_B, 0x00},
>> + {MAX98927_R002E_ICC_HIZ_MANUAL_MODE, 0x00},
>> + {MAX98927_R002F_ICC_TX_HIZ_EN_A, 0x00},
>> + {MAX98927_R0030_ICC_TX_HIZ_EN_B, 0x00},
>> + {MAX98927_R0031_ICC_LNK_EN, 0x00},
>> + {MAX98927_R0032_PDM_TX_EN, 0x00},
>> + {MAX98927_R0033_PDM_TX_HIZ_CTRL, 0x00},
>> + {MAX98927_R0034_PDM_TX_CTRL, 0x00},
>> + {MAX98927_R0035_PDM_RX_CTRL, 0x00},
>> + {MAX98927_R0036_AMP_VOL_CTRL, 0x00},
>> + {MAX98927_R0037_AMP_DSP_CFG, 0x02},
>> + {MAX98927_R0038_TONE_GEN_DC_CFG, 0x00},
>> + {MAX98927_R0039_DRE_CTRL, 0x01},
>> + {MAX98927_R003A_AMP_EN, 0x00},
>> + {MAX98927_R003B_SPK_SRC_SEL, 0x00},
>> + {MAX98927_R003C_SPK_GAIN, 0x00},
>> + {MAX98927_R003D_SSM_CFG, 0x01},
>> + {MAX98927_R003E_MEAS_EN, 0x00},
>> + {MAX98927_R003F_MEAS_DSP_CFG, 0x04},
>> + {MAX98927_R0040_BOOST_CTRL0, 0x00},
>> + {MAX98927_R0041_BOOST_CTRL3, 0x00},
>> + {MAX98927_R0042_BOOST_CTRL1, 0x00},
>> + {MAX98927_R0043_MEAS_ADC_CFG, 0x00},
>> + {MAX98927_R0044_MEAS_ADC_BASE_MSB, 0x00},
>> + {MAX98927_R0045_MEAS_ADC_BASE_LSB, 0x00},
>> + {MAX98927_R0046_ADC_CH0_DIVIDE, 0x00},
>> + {MAX98927_R0047_ADC_CH1_DIVIDE, 0x00},
>> + {MAX98927_R0048_ADC_CH2_DIVIDE, 0x00},
>> + {MAX98927_R0049_ADC_CH0_FILT_CFG, 0x00},
>> + {MAX98927_R004A_ADC_CH1_FILT_CFG, 0x00},
>> + {MAX98927_R004B_ADC_CH2_FILT_CFG, 0x00},
>> + {MAX98927_R004C_MEAS_ADC_CH0_READ, 0x00},
>> + {MAX98927_R004D_MEAS_ADC_CH1_READ, 0x00},
>> + {MAX98927_R004E_MEAS_ADC_CH2_READ, 0x00},
>> + {MAX98927_R0051_BROWNOUT_STATUS, 0x00},
>> + {MAX98927_R0052_BROWNOUT_EN, 0x00},
>> + {MAX98927_R0053_BROWNOUT_INFINITE_HOLD, 0x00},
>> + {MAX98927_R0054_BROWNOUT_INFINITE_HOLD_CLR, 0x00},
>> + {MAX98927_R0055_BROWNOUT_LVL_HOLD, 0x00},
>> + {MAX98927_R005A_BROWNOUT_LVL1_THRESH, 0x00},
>> + {MAX98927_R005B_BROWNOUT_LVL2_THRESH, 0x00},
>> + {MAX98927_R005C_BROWNOUT_LVL3_THRESH, 0x00},
>> + {MAX98927_R005D_BROWNOUT_LVL4_THRESH, 0x00},
>> + {MAX98927_R005E_BROWNOUT_THRESH_HYSTERYSIS, 0x00},
>> + {MAX98927_R005F_BROWNOUT_AMP_LIMITER_ATK_REL, 0x00},
>> + {MAX98927_R0060_BROWNOUT_AMP_GAIN_ATK_REL, 0x00},
>> + {MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE, 0x00},
>> + {MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT, 0x00},
>> + {MAX98927_R0073_BROWNOUT_LVL1_AMP1_CTRL1, 0x00},
>> + {MAX98927_R0074_BROWNOUT_LVL1_AMP1_CTRL2, 0x00},
>> + {MAX98927_R0075_BROWNOUT_LVL1_AMP1_CTRL3, 0x00},
>> + {MAX98927_R0076_BROWNOUT_LVL2_CUR_LIMIT, 0x00},
>> + {MAX98927_R0077_BROWNOUT_LVL2_AMP1_CTRL1, 0x00},
>> + {MAX98927_R0078_BROWNOUT_LVL2_AMP1_CTRL2, 0x00},
>> + {MAX98927_R0079_BROWNOUT_LVL2_AMP1_CTRL3, 0x00},
>> + {MAX98927_R007A_BROWNOUT_LVL3_CUR_LIMIT, 0x00},
>> + {MAX98927_R007B_BROWNOUT_LVL3_AMP1_CTRL1, 0x00},
>> + {MAX98927_R007C_BROWNOUT_LVL3_AMP1_CTRL2, 0x00},
>> + {MAX98927_R007D_BROWNOUT_LVL3_AMP1_CTRL3, 0x00},
>> + {MAX98927_R007E_BROWNOUT_LVL4_CUR_LIMIT, 0x00},
>> + {MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1, 0x00},
>> + {MAX98927_R0080_BROWNOUT_LVL4_AMP1_CTRL2, 0x00},
>> + {MAX98927_R0081_BROWNOUT_LVL4_AMP1_CTRL3, 0x00},
>> + {MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM, 0x00},
>> + {MAX98927_R0083_ENV_TRACK_BOOST_VOUT_DELAY, 0x00},
>> + {MAX98927_R0084_ENV_TRACK_REL_RATE, 0x00},
>> + {MAX98927_R0085_ENV_TRACK_HOLD_RATE, 0x00},
>> + {MAX98927_R0086_ENV_TRACK_CTRL, 0x00},
>> + {MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ, 0x00},
>> + {MAX98927_R00FF_GLOBAL_SHDN, 0x00},
>> + {MAX98927_R0100_SOFT_RESET, 0x00},
>> + {MAX98927_R01FF_REV_ID, 0x40},
>> +};
>> +
>> +static int max98927_dai_set_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt)
>> +{
>> + struct snd_soc_codec *codec = codec_dai->codec;
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> + unsigned int mode = 0;
>> + unsigned int format = 0;
>> + unsigned int invert = 0;
>> +
>> + dev_dbg(codec->dev, "%s: fmt 0x%08X\n", __func__, fmt);
>> +
>> + switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
>> + case SND_SOC_DAIFMT_CBS_CFS:
>> + mode = MAX98927_PCM_MASTER_MODE_SLAVE;
>> + break;
>> + case SND_SOC_DAIFMT_CBM_CFM:
>> + max98927->master = true;
>> + mode = MAX98927_PCM_MASTER_MODE_MASTER;
>> + break;
>> + default:
>> + dev_err(codec->dev, "DAI clock mode unsupported");
>> + return -EINVAL;
>> + }
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0021_PCM_MASTER_MODE,
>> + MAX98927_PCM_MASTER_MODE_MASK,
>> + mode);
>> +
>> + switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
>> + case SND_SOC_DAIFMT_NB_NF:
>> + break;
>> + case SND_SOC_DAIFMT_IB_NF:
>> + invert = MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE;
>> + break;
>> + default:
>> + dev_err(codec->dev, "DAI invert mode unsupported");
>> + return -EINVAL;
>> + }
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0020_PCM_MODE_CFG,
>> + MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE,
>> + invert);
>> +
>> + /* interface format */
>> + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
>> + case SND_SOC_DAIFMT_I2S:
>> + max98927->iface |= SND_SOC_DAIFMT_I2S;
>> + format = MAX98927_PCM_FORMAT_I2S;
>> + break;
>> + case SND_SOC_DAIFMT_LEFT_J:
>> + max98927->iface |= SND_SOC_DAIFMT_LEFT_J;
>> + format = MAX98927_PCM_FORMAT_LJ;
>> + break;
>> + case SND_SOC_DAIFMT_PDM:
>> + max98927->iface |= SND_SOC_DAIFMT_PDM;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + /* pcm channel configuration */
>> + if (max98927->iface & (SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_LEFT_J)) {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0018_PCM_RX_EN_A,
>> + MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN,
>> + MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN);
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0020_PCM_MODE_CFG,
>> + MAX98927_PCM_MODE_CFG_FORMAT_MASK,
>> + format << MAX98927_PCM_MODE_CFG_FORMAT_SHIFT);
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003B_SPK_SRC_SEL,
>> + MAX98927_SPK_SRC_MASK, 0);
>> +
>> + } else
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0018_PCM_RX_EN_A,
>> + MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN, 0);
>> +
>> + /* pdm channel configuration */
>> + if (max98927->iface & SND_SOC_DAIFMT_PDM) {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0035_PDM_RX_CTRL,
>> + MAX98927_PDM_RX_EN_MASK, 1);
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003B_SPK_SRC_SEL,
>> + MAX98927_SPK_SRC_MASK, 3);
>> + } else
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0035_PDM_RX_CTRL,
>> + MAX98927_PDM_RX_EN_MASK, 0);
>> + return 0;
>> +}
>> +
>> +/* codec MCLK rate in master mode */
>> +static const int rate_table[] = {
>> + 5644800, 6000000, 6144000, 6500000,
>> + 9600000, 11289600, 12000000, 12288000,
>> + 13000000, 19200000,
>> +};
>> +
>> +static int max98927_set_clock(struct max98927_priv *max98927,
>> + struct snd_pcm_hw_params *params)
>> +{
>> + struct snd_soc_codec *codec = max98927->codec;
>> + /* BCLK/LRCLK ratio calculation */
>> + int blr_clk_ratio = params_channels(params) * max98927->ch_size;
>> + int value;
>> +
>> + if (max98927->master) {
>> + int i;
>> + /* match rate to closest value */
>> + for (i = 0; i < ARRAY_SIZE(rate_table); i++) {
>> + if (rate_table[i] >= max98927->sysclk)
>> + break;
>> + }
>> + if (i == ARRAY_SIZE(rate_table)) {
>> + dev_err(codec->dev, "failed to find proper clock rate.\n");
>> + return -EINVAL;
>> + }
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0021_PCM_MASTER_MODE,
>> + MAX98927_PCM_MASTER_MODE_MCLK_MASK,
>> + i << MAX98927_PCM_MASTER_MODE_MCLK_RATE_SHIFT);
>> + }
>> +
>> + switch (blr_clk_ratio) {
>> + case 32:
>> + value = 2;
>> + break;
>> + case 48:
>> + value = 3;
>> + break;
>> + case 64:
>> + value = 4;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0022_PCM_CLK_SETUP,
>> + MAX98927_PCM_CLK_SETUP_BSEL_MASK,
>> + value);
>> + return 0;
>> +}
>> +
>> +static int max98927_dai_hw_params(struct snd_pcm_substream *substream,
>> + struct snd_pcm_hw_params *params,
>> + struct snd_soc_dai *dai)
>> +{
>> + struct snd_soc_codec *codec = dai->codec;
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> + unsigned int sampling_rate = 0;
>> + unsigned int chan_sz = 0;
>> +
>> + /* pcm mode configuration */
>> + switch (snd_pcm_format_width(params_format(params))) {
>> + case 16:
>> + chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_16;
>> + break;
>> + case 24:
>> + chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_24;
>> + break;
>> + case 32:
>> + chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_32;
>> + break;
>> + default:
>> + dev_err(codec->dev, "format unsupported %d",
>> + params_format(params));
>> + goto err;
>> + }
>> +
>> + max98927->ch_size = snd_pcm_format_width(params_format(params));
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0020_PCM_MODE_CFG,
>> + MAX98927_PCM_MODE_CFG_CHANSZ_MASK, chan_sz);
>> +
>> + dev_dbg(codec->dev, "format supported %d",
>> + params_format(params));
>> +
>> + /* sampling rate configuration */
>> + switch (params_rate(params)) {
>> + case 8000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_8000;
>> + break;
>> + case 11025:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_11025;
>> + break;
>> + case 12000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_12000;
>> + break;
>> + case 16000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_16000;
>> + break;
>> + case 22050:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_22050;
>> + break;
>> + case 24000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_24000;
>> + break;
>> + case 32000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_32000;
>> + break;
>> + case 44100:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_44100;
>> + break;
>> + case 48000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_48000;
>> + break;
>> + default:
>> + dev_err(codec->dev, "rate %d not supported\n",
>> + params_rate(params));
>> + goto err;
>> + }
>> + /* set DAI_SR to correct LRCLK frequency */
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0023_PCM_SR_SETUP1,
>> + MAX98927_PCM_SR_SET1_SR_MASK,
>> + sampling_rate);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0024_PCM_SR_SETUP2,
>> + MAX98927_PCM_SR_SET2_SR_MASK,
>> + sampling_rate << MAX98927_PCM_SR_SET2_SR_SHIFT);
>> +
>> + /* set sampling rate of IV */
>> + if (max98927->interleave_mode &&
>> + sampling_rate > MAX98927_PCM_SR_SET1_SR_16000)
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0024_PCM_SR_SETUP2,
>> + MAX98927_PCM_SR_SET2_IVADC_SR_MASK,
>> + sampling_rate - 3);
>> + else
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0024_PCM_SR_SETUP2,
>> + MAX98927_PCM_SR_SET2_IVADC_SR_MASK,
>> + sampling_rate);
>> + return max98927_set_clock(max98927, params);
>> +err:
>> + return -EINVAL;
>> +}
>> +
>> +#define MAX98927_RATES SNDRV_PCM_RATE_8000_48000
>> +
>> +#define MAX98927_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
>> + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE)
>> +
>> +static int max98927_dai_set_sysclk(struct snd_soc_dai *dai,
>> + int clk_id, unsigned int freq, int dir)
>> +{
>> + struct snd_soc_codec *codec = dai->codec;
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> +
>> + max98927->sysclk = freq;
>> + return 0;
>> +}
>> +
>> +static const struct snd_soc_dai_ops max98927_dai_ops = {
>> + .set_sysclk = max98927_dai_set_sysclk,
>> + .set_fmt = max98927_dai_set_fmt,
>> + .hw_params = max98927_dai_hw_params,
>> +};
>> +
>> +static int max98927_dac_event(struct snd_soc_dapm_widget *w,
>> + struct snd_kcontrol *kcontrol, int event)
>> +{
>> + struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> +
>> + switch (event) {
>> + case SND_SOC_DAPM_POST_PMU:
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003A_AMP_EN,
>> + MAX98927_AMP_EN_MASK, 1);
>> + /* enable VMON and IMON */
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003E_MEAS_EN,
>> + MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN,
>> + MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R00FF_GLOBAL_SHDN,
>> + MAX98927_GLOBAL_EN_MASK, 1);
>> + break;
>> + case SND_SOC_DAPM_POST_PMD:
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R00FF_GLOBAL_SHDN,
>> + MAX98927_GLOBAL_EN_MASK, 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003A_AMP_EN,
>> + MAX98927_AMP_EN_MASK, 0);
>> + /* disable VMON and IMON */
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003E_MEAS_EN,
>> + MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN, 0);
>> + break;
>> + default:
>> + return 0;
>> + }
>> + return 0;
>> +}
>> +
>> +static const char * const max98927_switch_text[] = {
>> + "Left", "Right", "LeftRight"};
>> +
>> +static const struct soc_enum dai_sel_enum =
>> + SOC_ENUM_SINGLE(MAX98927_R0025_PCM_TO_SPK_MONOMIX_A,
>> + MAX98927_PCM_TO_SPK_MONOMIX_CFG_SHIFT,
>> + 3, max98927_switch_text);
>> +
>> +static const struct snd_kcontrol_new max98927_dai_controls =
>> + SOC_DAPM_ENUM("DAI Sel", dai_sel_enum);
>> +
>> +static const struct snd_soc_dapm_widget max98927_dapm_widgets[] = {
>> + SND_SOC_DAPM_AIF_IN("DAI_OUT", "HiFi Playback", 0, SND_SOC_NOPM, 0, 0),
>> + SND_SOC_DAPM_DAC_E("Amp Enable", "HiFi Playback", MAX98927_R003A_AMP_EN,
>> + 0, 0, max98927_dac_event,
>> + SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
>> + SND_SOC_DAPM_MUX("DAI Sel Mux", SND_SOC_NOPM, 0, 0,
>> + &max98927_dai_controls),
>> + SND_SOC_DAPM_OUTPUT("BE_OUT"),
>> +};
>> +
>> +static DECLARE_TLV_DB_SCALE(max98927_spk_tlv, 300, 300, 0);
>> +static DECLARE_TLV_DB_SCALE(max98927_digital_tlv, -1600, 25, 0);
>> +
>> +static bool max98927_readable_register(struct device *dev, unsigned int reg)
>> +{
>> + switch (reg) {
>> + case MAX98927_R0001_INT_RAW1 ... MAX98927_R0028_ICC_RX_EN_B:
>> + case MAX98927_R002B_ICC_TX_EN_A ... MAX98927_R002C_ICC_TX_EN_B:
>> + case MAX98927_R002E_ICC_HIZ_MANUAL_MODE
>> + ... MAX98927_R004E_MEAS_ADC_CH2_READ:
>> + case MAX98927_R0051_BROWNOUT_STATUS
>> + ... MAX98927_R0055_BROWNOUT_LVL_HOLD:
>> + case MAX98927_R005A_BROWNOUT_LVL1_THRESH
>> + ... MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE:
>> + case MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT
>> + ... MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ:
>> + case MAX98927_R00FF_GLOBAL_SHDN:
>> + case MAX98927_R0100_SOFT_RESET:
>> + case MAX98927_R01FF_REV_ID:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +};
>> +
>> +static bool max98927_volatile_reg(struct device *dev, unsigned int reg)
>> +{
>> + switch (reg) {
>> + case MAX98927_R0001_INT_RAW1 ... MAX98927_R0009_INT_FLAG3:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +}
>> +
>> +static const char * const max98927_boost_voltage_text[] = {
>> + "6.5V", "6.625V", "6.75V", "6.875V", "7V", "7.125V", "7.25V", "7.375V",
>> + "7.5V", "7.625V", "7.75V", "7.875V", "8V", "8.125V", "8.25V", "8.375V",
>> + "8.5V", "8.625V", "8.75V", "8.875V", "9V", "9.125V", "9.25V", "9.375V",
>> + "9.5V", "9.625V", "9.75V", "9.875V", "10V"
>> +};
>> +
>> +static SOC_ENUM_SINGLE_DECL(max98927_boost_voltage,
>> + MAX98927_R0040_BOOST_CTRL0, 0,
>> + max98927_boost_voltage_text);
>> +
>> +static const char * const max98927_current_limit_text[] = {
>> + "1.00A", "1.10A", "1.20A", "1.30A", "1.40A", "1.50A", "1.60A", "1.70A",
>> + "1.80A", "1.90A", "2.00A", "2.10A", "2.20A", "2.30A", "2.40A", "2.50A",
>> + "2.60A", "2.70A", "2.80A", "2.90A", "3.00A", "3.10A", "3.20A", "3.30A",
>> + "3.40A", "3.50A", "3.60A", "3.70A", "3.80A", "3.90A", "4.00A", "4.10A"
>> +};
>> +
>> +static SOC_ENUM_SINGLE_DECL(max98927_current_limit,
>> + MAX98927_R0042_BOOST_CTRL1, 1,
>> + max98927_current_limit_text);
>> +
>> +static const struct snd_kcontrol_new max98927_snd_controls[] = {
>> + SOC_SINGLE_TLV("Speaker Volume", MAX98927_R003C_SPK_GAIN,
>> + 0, 6, 0,
>> + max98927_spk_tlv),
>> + SOC_SINGLE_TLV("Digital Volume", MAX98927_R0036_AMP_VOL_CTRL,
>> + 0, (1<<MAX98927_AMP_VOL_WIDTH)-1, 0,
>> + max98927_digital_tlv),
>> + SOC_SINGLE("Amp DSP Switch", MAX98927_R0052_BROWNOUT_EN,
>> + MAX98927_BROWNOUT_DSP_SHIFT, 1, 0),
>> + SOC_SINGLE("Ramp Switch", MAX98927_R0037_AMP_DSP_CFG,
>> + MAX98927_AMP_DSP_CFG_RMP_SHIFT, 1, 0),
>> + SOC_SINGLE("DRE Switch", MAX98927_R0039_DRE_CTRL,
>> + MAX98927_DRE_EN_SHIFT, 1, 0),
>> + SOC_SINGLE("Volume Location Switch", MAX98927_R0036_AMP_VOL_CTRL,
>> + MAX98927_AMP_VOL_SEL_SHIFT, 1, 0),
>> + SOC_ENUM("Boost Output Voltage", max98927_boost_voltage),
>> + SOC_ENUM("Current Limit", max98927_current_limit),
>> +};
>> +
>> +static const struct snd_soc_dapm_route max98927_audio_map[] = {
>> + {"Amp Enable", NULL, "DAI_OUT"},
>> + {"DAI Sel Mux", "Left", "Amp Enable"},
>> + {"DAI Sel Mux", "Right", "Amp Enable"},
>> + {"DAI Sel Mux", "LeftRight", "Amp Enable"},
>> + {"BE_OUT", NULL, "DAI Sel Mux"},
>> +};
>> +
>> +static struct snd_soc_dai_driver max98927_dai[] = {
>> + {
>> + .name = "max98927-aif1",
>> + .playback = {
>> + .stream_name = "HiFi Playback",
>> + .channels_min = 1,
>> + .channels_max = 2,
>> + .rates = MAX98927_RATES,
>> + .formats = MAX98927_FORMATS,
>> + },
>> + .capture = {
>> + .stream_name = "HiFi Capture",
>> + .channels_min = 1,
>> + .channels_max = 2,
>> + .rates = MAX98927_RATES,
>> + .formats = MAX98927_FORMATS,
>> + },
>> + .ops = &max98927_dai_ops,
>> + }
>> +};
>> +
>> +static int max98927_probe(struct snd_soc_codec *codec)
>> +{
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> +
>> + max98927->codec = codec;
>> + codec->control_data = max98927->regmap;
>> + codec->cache_bypass = 1;
>> +
>> + /* Software Reset */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0100_SOFT_RESET, MAX98927_SOFT_RESET);
>> +
>> + /* IV default slot configuration */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
>> + 0xFF);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
>> + 0xFF);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0025_PCM_TO_SPK_MONOMIX_A,
>> + 0x80);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0026_PCM_TO_SPK_MONOMIX_B,
>> + 0x1);
>> + /* Set inital volume (+13dB) */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0036_AMP_VOL_CTRL,
>> + 0x38);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R003C_SPK_GAIN,
>> + 0x05);
>> + /* Enable DC blocker */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0037_AMP_DSP_CFG,
>> + 0x03);
>> + /* Enable IMON VMON DC blocker */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R003F_MEAS_DSP_CFG,
>> + 0xF7);
>> + /* Boost Output Voltage & Current limit */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0040_BOOST_CTRL0,
>> + 0x1C);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0042_BOOST_CTRL1,
>> + 0x3E);
>> + /* Measurement ADC config */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0043_MEAS_ADC_CFG,
>> + 0x04);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0044_MEAS_ADC_BASE_MSB,
>> + 0x00);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0045_MEAS_ADC_BASE_LSB,
>> + 0x24);
>> + /* Brownout Level */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1,
>> + 0x06);
>> + /* Envelope Tracking configuration */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM,
>> + 0x08);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0086_ENV_TRACK_CTRL,
>> + 0x01);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ,
>> + 0x10);
>> +
>> + /* voltage, current slot configuration */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R001E_PCM_TX_CH_SRC_A,
>> + (max98927->i_l_slot<<MAX98927_PCM_TX_CH_SRC_A_I_SHIFT|
>> + max98927->v_l_slot)&0xFF);
>> +
>> + if (max98927->v_l_slot < 8) {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
>> + 1 << max98927->v_l_slot, 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001A_PCM_TX_EN_A,
>> + 1 << max98927->v_l_slot,
>> + 1 << max98927->v_l_slot);
>> + } else {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
>> + 1 << (max98927->v_l_slot - 8), 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001B_PCM_TX_EN_B,
>> + 1 << (max98927->v_l_slot - 8),
>> + 1 << (max98927->v_l_slot - 8));
>> + }
>> +
>> + if (max98927->i_l_slot < 8) {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
>> + 1 << max98927->i_l_slot, 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001A_PCM_TX_EN_A,
>> + 1 << max98927->i_l_slot,
>> + 1 << max98927->i_l_slot);
>> + } else {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
>> + 1 << (max98927->i_l_slot - 8), 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001B_PCM_TX_EN_B,
>> + 1 << (max98927->i_l_slot - 8),
>> + 1 << (max98927->i_l_slot - 8));
>> + }
>> +
>> + /* Set interleave mode */
>> + if (max98927->interleave_mode)
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001F_PCM_TX_CH_SRC_B,
>> + MAX98927_PCM_TX_CH_INTERLEAVE_MASK,
>> + MAX98927_PCM_TX_CH_INTERLEAVE_MASK);
>> + return 0;
>> +}
>> +
>> +static const struct snd_soc_codec_driver soc_codec_dev_max98927 = {
>> + .probe = max98927_probe,
>> + .component_driver = {
>> + .controls = max98927_snd_controls,
>> + .num_controls = ARRAY_SIZE(max98927_snd_controls),
>> + .dapm_widgets = max98927_dapm_widgets,
>> + .num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
>> + .dapm_routes = max98927_audio_map,
>> + .num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
>> + },
>> +};
>> +
>> +static const struct regmap_config max98927_regmap = {
>> + .reg_bits = 16,
>> + .val_bits = 8,
>> + .max_register = MAX98927_R01FF_REV_ID,
>> + .reg_defaults = max98927_reg,
>> + .num_reg_defaults = ARRAY_SIZE(max98927_reg),
>> + .readable_reg = max98927_readable_register,
>> + .volatile_reg = max98927_volatile_reg,
>> + .cache_type = REGCACHE_RBTREE,
>> +};
>> +
>> +static void max98927_slot_config(struct i2c_client *i2c,
>> + struct max98927_priv *max98927)
>> +{
>> + int value;
>> +
>> + if (!of_property_read_u32(i2c->dev.of_node,
>> + "vmon-slot-no", &value))
>> + max98927->v_l_slot = value & 0xF;
>> + else
>> + max98927->v_l_slot = 0;
>> + if (!of_property_read_u32(i2c->dev.of_node,
>> + "imon-slot-no", &value))
>> + max98927->i_l_slot = value & 0xF;
>> + else
>> + max98927->i_l_slot = 1;
>> +}
>> +
>> +static int max98927_i2c_probe(struct i2c_client *i2c,
>> + const struct i2c_device_id *id)
>> +{
>> +
>> + int ret = 0, value;
>> + int reg = 0;
>> + struct max98927_priv *max98927 = NULL;
>> +
>> + max98927 = devm_kzalloc(&i2c->dev,
>> + sizeof(*max98927), GFP_KERNEL);
>> +
>> + if (!max98927) {
>> + ret = -ENOMEM;
>> + return ret;
>> + }
>> + i2c_set_clientdata(i2c, max98927);
>> +
>> + /* update interleave mode info */
>> + if (!of_property_read_u32(i2c->dev.of_node,
>> + "interleave_mode", &value)) {
>> + if (value > 0)
>> + max98927->interleave_mode = 1;
>> + else
>> + max98927->interleave_mode = 0;
>> + } else
>> + max98927->interleave_mode = 0;
>> +
>> + /* regmap initialization */
>> + max98927->regmap
>> + = devm_regmap_init_i2c(i2c, &max98927_regmap);
>> + if (IS_ERR(max98927->regmap)) {
>> + ret = PTR_ERR(max98927->regmap);
>> + dev_err(&i2c->dev,
>> + "Failed to allocate regmap: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + /* Check Revision ID */
>> + ret = regmap_read(max98927->regmap,
>> + MAX98927_R01FF_REV_ID, ®);
>> + if (ret < 0) {
>> + dev_err(&i2c->dev,
>> + "Failed to read: 0x%02X\n", MAX98927_R01FF_REV_ID);
>> + return ret;
>> + }
>> + dev_info(&i2c->dev, "MAX98927 revisionID: 0x%02X\n", reg);
>> +
>> + /* voltage/current slot configuration */
>> + max98927_slot_config(i2c, max98927);
>> +
>> + /* codec registeration */
>> + ret = snd_soc_register_codec(&i2c->dev, &soc_codec_dev_max98927,
>> + max98927_dai, ARRAY_SIZE(max98927_dai));
>> + if (ret < 0)
>> + dev_err(&i2c->dev, "Failed to register codec: %d\n", ret);
>> +
>> + return ret;
>> +}
>> +
>> +static int max98927_i2c_remove(struct i2c_client *client)
>> +{
>> + snd_soc_unregister_codec(&client->dev);
>> + return 0;
>> +}
>> +
>> +static const struct i2c_device_id max98927_i2c_id[] = {
>> + { "max98927", 0},
>> + { },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(i2c, max98927_i2c_id);
>> +
>> +#if defined(CONFIG_OF)
>> +static const struct of_device_id max98927_of_match[] = {
>> + { .compatible = "maxim,max98927", },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, max98927_of_match);
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id max98927_acpi_match[] = {
>> + { "MX98927", 0 },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(acpi, max98927_acpi_match);
>> +#endif
>> +
>> +static struct i2c_driver max98927_i2c_driver = {
>> + .driver = {
>> + .name = "max98927",
>> + .of_match_table = of_match_ptr(max98927_of_match),
>> + .acpi_match_table = ACPI_PTR(max98927_acpi_match),
>> + .pm = NULL,
>> + },
>> + .probe = max98927_i2c_probe,
>> + .remove = max98927_i2c_remove,
>> + .id_table = max98927_i2c_id,
>> +};
>> +
>> +module_i2c_driver(max98927_i2c_driver)
>> +
>> +MODULE_DESCRIPTION("ALSA SoC MAX98927 driver");
>> +MODULE_AUTHOR("Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>");
>> +MODULE_LICENSE("GPL");
>> diff --git a/sound/soc/codecs/max98927.h b/sound/soc/codecs/max98927.h
>> new file mode 100644
>> index 000000000000..ece6a608cbe1
>> --- /dev/null
>> +++ b/sound/soc/codecs/max98927.h
>> @@ -0,0 +1,272 @@
>> +/*
>> + * max98927.h -- MAX98927 ALSA Soc Audio driver
>> + *
>> + * Copyright 2013-15 Maxim Integrated Products
>> + * Author: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + *
>> + */
>> +#ifndef _MAX98927_H
>> +#define _MAX98927_H
>> +
>> +/* Register Values */
>> +#define MAX98927_R0001_INT_RAW1 0x0001
>> +#define MAX98927_R0002_INT_RAW2 0x0002
>> +#define MAX98927_R0003_INT_RAW3 0x0003
>> +#define MAX98927_R0004_INT_STATE1 0x0004
>> +#define MAX98927_R0005_INT_STATE2 0x0005
>> +#define MAX98927_R0006_INT_STATE3 0x0006
>> +#define MAX98927_R0007_INT_FLAG1 0x0007
>> +#define MAX98927_R0008_INT_FLAG2 0x0008
>> +#define MAX98927_R0009_INT_FLAG3 0x0009
>> +#define MAX98927_R000A_INT_EN1 0x000A
>> +#define MAX98927_R000B_INT_EN2 0x000B
>> +#define MAX98927_R000C_INT_EN3 0x000C
>> +#define MAX98927_R000D_INT_FLAG_CLR1 0x000D
>> +#define MAX98927_R000E_INT_FLAG_CLR2 0x000E
>> +#define MAX98927_R000F_INT_FLAG_CLR3 0x000F
>> +#define MAX98927_R0010_IRQ_CTRL 0x0010
>> +#define MAX98927_R0011_CLK_MON 0x0011
>> +#define MAX98927_R0012_WDOG_CTRL 0x0012
>> +#define MAX98927_R0013_WDOG_RST 0x0013
>> +#define MAX98927_R0014_MEAS_ADC_THERM_WARN_THRESH 0x0014
>> +#define MAX98927_R0015_MEAS_ADC_THERM_SHDN_THRESH 0x0015
>> +#define MAX98927_R0016_MEAS_ADC_THERM_HYSTERESIS 0x0016
>> +#define MAX98927_R0017_PIN_CFG 0x0017
>> +#define MAX98927_R0018_PCM_RX_EN_A 0x0018
>> +#define MAX98927_R0019_PCM_RX_EN_B 0x0019
>> +#define MAX98927_R001A_PCM_TX_EN_A 0x001A
>> +#define MAX98927_R001B_PCM_TX_EN_B 0x001B
>> +#define MAX98927_R001C_PCM_TX_HIZ_CTRL_A 0x001C
>> +#define MAX98927_R001D_PCM_TX_HIZ_CTRL_B 0x001D
>> +#define MAX98927_R001E_PCM_TX_CH_SRC_A 0x001E
>> +#define MAX98927_R001F_PCM_TX_CH_SRC_B 0x001F
>> +#define MAX98927_R0020_PCM_MODE_CFG 0x0020
>> +#define MAX98927_R0021_PCM_MASTER_MODE 0x0021
>> +#define MAX98927_R0022_PCM_CLK_SETUP 0x0022
>> +#define MAX98927_R0023_PCM_SR_SETUP1 0x0023
>> +#define MAX98927_R0024_PCM_SR_SETUP2 0x0024
>> +#define MAX98927_R0025_PCM_TO_SPK_MONOMIX_A 0x0025
>> +#define MAX98927_R0026_PCM_TO_SPK_MONOMIX_B 0x0026
>> +#define MAX98927_R0027_ICC_RX_EN_A 0x0027
>> +#define MAX98927_R0028_ICC_RX_EN_B 0x0028
>> +#define MAX98927_R002B_ICC_TX_EN_A 0x002B
>> +#define MAX98927_R002C_ICC_TX_EN_B 0x002C
>> +#define MAX98927_R002E_ICC_HIZ_MANUAL_MODE 0x002E
>> +#define MAX98927_R002F_ICC_TX_HIZ_EN_A 0x002F
>> +#define MAX98927_R0030_ICC_TX_HIZ_EN_B 0x0030
>> +#define MAX98927_R0031_ICC_LNK_EN 0x0031
>> +#define MAX98927_R0032_PDM_TX_EN 0x0032
>> +#define MAX98927_R0033_PDM_TX_HIZ_CTRL 0x0033
>> +#define MAX98927_R0034_PDM_TX_CTRL 0x0034
>> +#define MAX98927_R0035_PDM_RX_CTRL 0x0035
>> +#define MAX98927_R0036_AMP_VOL_CTRL 0x0036
>> +#define MAX98927_R0037_AMP_DSP_CFG 0x0037
>> +#define MAX98927_R0038_TONE_GEN_DC_CFG 0x0038
>> +#define MAX98927_R0039_DRE_CTRL 0x0039
>> +#define MAX98927_R003A_AMP_EN 0x003A
>> +#define MAX98927_R003B_SPK_SRC_SEL 0x003B
>> +#define MAX98927_R003C_SPK_GAIN 0x003C
>> +#define MAX98927_R003D_SSM_CFG 0x003D
>> +#define MAX98927_R003E_MEAS_EN 0x003E
>> +#define MAX98927_R003F_MEAS_DSP_CFG 0x003F
>> +#define MAX98927_R0040_BOOST_CTRL0 0x0040
>> +#define MAX98927_R0041_BOOST_CTRL3 0x0041
>> +#define MAX98927_R0042_BOOST_CTRL1 0x0042
>> +#define MAX98927_R0043_MEAS_ADC_CFG 0x0043
>> +#define MAX98927_R0044_MEAS_ADC_BASE_MSB 0x0044
>> +#define MAX98927_R0045_MEAS_ADC_BASE_LSB 0x0045
>> +#define MAX98927_R0046_ADC_CH0_DIVIDE 0x0046
>> +#define MAX98927_R0047_ADC_CH1_DIVIDE 0x0047
>> +#define MAX98927_R0048_ADC_CH2_DIVIDE 0x0048
>> +#define MAX98927_R0049_ADC_CH0_FILT_CFG 0x0049
>> +#define MAX98927_R004A_ADC_CH1_FILT_CFG 0x004A
>> +#define MAX98927_R004B_ADC_CH2_FILT_CFG 0x004B
>> +#define MAX98927_R004C_MEAS_ADC_CH0_READ 0x004C
>> +#define MAX98927_R004D_MEAS_ADC_CH1_READ 0x004D
>> +#define MAX98927_R004E_MEAS_ADC_CH2_READ 0x004E
>> +#define MAX98927_R0051_BROWNOUT_STATUS 0x0051
>> +#define MAX98927_R0052_BROWNOUT_EN 0x0052
>> +#define MAX98927_R0053_BROWNOUT_INFINITE_HOLD 0x0053
>> +#define MAX98927_R0054_BROWNOUT_INFINITE_HOLD_CLR 0x0054
>> +#define MAX98927_R0055_BROWNOUT_LVL_HOLD 0x0055
>> +#define MAX98927_R005A_BROWNOUT_LVL1_THRESH 0x005A
>> +#define MAX98927_R005B_BROWNOUT_LVL2_THRESH 0x005B
>> +#define MAX98927_R005C_BROWNOUT_LVL3_THRESH 0x005C
>> +#define MAX98927_R005D_BROWNOUT_LVL4_THRESH 0x005D
>> +#define MAX98927_R005E_BROWNOUT_THRESH_HYSTERYSIS 0x005E
>> +#define MAX98927_R005F_BROWNOUT_AMP_LIMITER_ATK_REL 0x005F
>> +#define MAX98927_R0060_BROWNOUT_AMP_GAIN_ATK_REL 0x0060
>> +#define MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE 0x0061
>> +#define MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT 0x0072
>> +#define MAX98927_R0073_BROWNOUT_LVL1_AMP1_CTRL1 0x0073
>> +#define MAX98927_R0074_BROWNOUT_LVL1_AMP1_CTRL2 0x0074
>> +#define MAX98927_R0075_BROWNOUT_LVL1_AMP1_CTRL3 0x0075
>> +#define MAX98927_R0076_BROWNOUT_LVL2_CUR_LIMIT 0x0076
>> +#define MAX98927_R0077_BROWNOUT_LVL2_AMP1_CTRL1 0x0077
>> +#define MAX98927_R0078_BROWNOUT_LVL2_AMP1_CTRL2 0x0078
>> +#define MAX98927_R0079_BROWNOUT_LVL2_AMP1_CTRL3 0x0079
>> +#define MAX98927_R007A_BROWNOUT_LVL3_CUR_LIMIT 0x007A
>> +#define MAX98927_R007B_BROWNOUT_LVL3_AMP1_CTRL1 0x007B
>> +#define MAX98927_R007C_BROWNOUT_LVL3_AMP1_CTRL2 0x007C
>> +#define MAX98927_R007D_BROWNOUT_LVL3_AMP1_CTRL3 0x007D
>> +#define MAX98927_R007E_BROWNOUT_LVL4_CUR_LIMIT 0x007E
>> +#define MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1 0x007F
>> +#define MAX98927_R0080_BROWNOUT_LVL4_AMP1_CTRL2 0x0080
>> +#define MAX98927_R0081_BROWNOUT_LVL4_AMP1_CTRL3 0x0081
>> +#define MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM 0x0082
>> +#define MAX98927_R0083_ENV_TRACK_BOOST_VOUT_DELAY 0x0083
>> +#define MAX98927_R0084_ENV_TRACK_REL_RATE 0x0084
>> +#define MAX98927_R0085_ENV_TRACK_HOLD_RATE 0x0085
>> +#define MAX98927_R0086_ENV_TRACK_CTRL 0x0086
>> +#define MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ 0x0087
>> +#define MAX98927_R00FF_GLOBAL_SHDN 0x00FF
>> +#define MAX98927_R0100_SOFT_RESET 0x0100
>> +#define MAX98927_R01FF_REV_ID 0x01FF
>> +
>> +/* MAX98927_R0018_PCM_RX_EN_A */
>> +#define MAX98927_PCM_RX_CH0_EN (0x1 << 0)
>> +#define MAX98927_PCM_RX_CH1_EN (0x1 << 1)
>> +#define MAX98927_PCM_RX_CH2_EN (0x1 << 2)
>> +#define MAX98927_PCM_RX_CH3_EN (0x1 << 3)
>> +#define MAX98927_PCM_RX_CH4_EN (0x1 << 4)
>> +#define MAX98927_PCM_RX_CH5_EN (0x1 << 5)
>> +#define MAX98927_PCM_RX_CH6_EN (0x1 << 6)
>> +#define MAX98927_PCM_RX_CH7_EN (0x1 << 7)
>> +
>> +/* MAX98927_R001A_PCM_TX_EN_A */
>> +#define MAX98927_PCM_TX_CH0_EN (0x1 << 0)
>> +#define MAX98927_PCM_TX_CH1_EN (0x1 << 1)
>> +#define MAX98927_PCM_TX_CH2_EN (0x1 << 2)
>> +#define MAX98927_PCM_TX_CH3_EN (0x1 << 3)
>> +#define MAX98927_PCM_TX_CH4_EN (0x1 << 4)
>> +#define MAX98927_PCM_TX_CH5_EN (0x1 << 5)
>> +#define MAX98927_PCM_TX_CH6_EN (0x1 << 6)
>> +#define MAX98927_PCM_TX_CH7_EN (0x1 << 7)
>> +
>> +/* MAX98927_R001E_PCM_TX_CH_SRC_A */
>> +#define MAX98927_PCM_TX_CH_SRC_A_V_SHIFT (0)
>> +#define MAX98927_PCM_TX_CH_SRC_A_I_SHIFT (4)
>> +
>> +/* MAX98927_R001F_PCM_TX_CH_SRC_B */
>> +#define MAX98927_PCM_TX_CH_INTERLEAVE_MASK (0x1 << 5)
>> +
>> +/* MAX98927_R0020_PCM_MODE_CFG */
>> +#define MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE (0x1 << 2)
>> +#define MAX98927_PCM_MODE_CFG_FORMAT_MASK (0x7 << 3)
>> +#define MAX98927_PCM_MODE_CFG_FORMAT_SHIFT (3)
>> +#define MAX98927_PCM_FORMAT_I2S (0x0 << 0)
>> +#define MAX98927_PCM_FORMAT_LJ (0x1 << 0)
>> +
>> +#define MAX98927_PCM_MODE_CFG_CHANSZ_MASK (0x3 << 6)
>> +#define MAX98927_PCM_MODE_CFG_CHANSZ_16 (0x1 << 6)
>> +#define MAX98927_PCM_MODE_CFG_CHANSZ_24 (0x2 << 6)
>> +#define MAX98927_PCM_MODE_CFG_CHANSZ_32 (0x3 << 6)
>> +
>> +/* MAX98927_R0021_PCM_MASTER_MODE */
>> +#define MAX98927_PCM_MASTER_MODE_MASK (0x3 << 0)
>> +#define MAX98927_PCM_MASTER_MODE_SLAVE (0x0 << 0)
>> +#define MAX98927_PCM_MASTER_MODE_MASTER (0x3 << 0)
>> +
>> +#define MAX98927_PCM_MASTER_MODE_MCLK_MASK (0xF << 2)
>> +#define MAX98927_PCM_MASTER_MODE_MCLK_RATE_SHIFT (2)
>> +
>> +/* MAX98927_R0022_PCM_CLK_SETUP */
>> +#define MAX98927_PCM_CLK_SETUP_BSEL_MASK (0xF << 0)
>> +
>> +/* MAX98927_R0023_PCM_SR_SETUP1 */
>> +#define MAX98927_PCM_SR_SET1_SR_MASK (0xF << 0)
>> +
>> +#define MAX98927_PCM_SR_SET1_SR_8000 (0x0 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_11025 (0x1 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_12000 (0x2 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_16000 (0x3 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_22050 (0x4 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_24000 (0x5 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_32000 (0x6 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_44100 (0x7 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_48000 (0x8 << 0)
>> +
>> +/* MAX98927_R0024_PCM_SR_SETUP2 */
>> +#define MAX98927_PCM_SR_SET2_SR_MASK (0xF << 4)
>> +#define MAX98927_PCM_SR_SET2_SR_SHIFT (4)
>> +#define MAX98927_PCM_SR_SET2_IVADC_SR_MASK (0xf << 0)
>> +
>> +/* MAX98927_R0025_PCM_TO_SPK_MONOMIX_A */
>> +#define MAX98927_PCM_TO_SPK_MONOMIX_CFG_MASK (0x3 << 6)
>> +#define MAX98927_PCM_TO_SPK_MONOMIX_CFG_SHIFT (6)
>> +
>> +/* MAX98927_R0035_PDM_RX_CTRL */
>> +#define MAX98927_PDM_RX_EN_MASK (0x1 << 0)
>> +
>> +/* MAX98927_R0036_AMP_VOL_CTRL */
>> +#define MAX98927_AMP_VOL_SEL (0x1 << 7)
>> +#define MAX98927_AMP_VOL_SEL_WIDTH (1)
>> +#define MAX98927_AMP_VOL_SEL_SHIFT (7)
>> +#define MAX98927_AMP_VOL_MASK (0x7f << 0)
>> +#define MAX98927_AMP_VOL_WIDTH (7)
>> +#define MAX98927_AMP_VOL_SHIFT (0)
>> +
>> +/* MAX98927_R0037_AMP_DSP_CFG */
>> +#define MAX98927_AMP_DSP_CFG_DCBLK_EN (0x1 << 0)
>> +#define MAX98927_AMP_DSP_CFG_DITH_EN (0x1 << 1)
>> +#define MAX98927_AMP_DSP_CFG_RMP_BYPASS (0x1 << 4)
>> +#define MAX98927_AMP_DSP_CFG_DAC_INV (0x1 << 5)
>> +#define MAX98927_AMP_DSP_CFG_RMP_SHIFT (4)
>> +
>> +/* MAX98927_R0039_DRE_CTRL */
>> +#define MAX98927_DRE_CTRL_DRE_EN (0x1 << 0)
>> +#define MAX98927_DRE_EN_SHIFT 0x1
>> +
>> +/* MAX98927_R003A_AMP_EN */
>> +#define MAX98927_AMP_EN_MASK (0x1 << 0)
>> +
>> +/* MAX98927_R003B_SPK_SRC_SEL */
>> +#define MAX98927_SPK_SRC_MASK (0x3 << 0)
>> +
>> +/* MAX98927_R003C_SPK_GAIN */
>> +#define MAX98927_SPK_PCM_GAIN_MASK (0x7 << 0)
>> +#define MAX98927_SPK_PDM_GAIN_MASK (0x7 << 4)
>> +#define MAX98927_SPK_GAIN_WIDTH (3)
>> +
>> +/* MAX98927_R003E_MEAS_EN */
>> +#define MAX98927_MEAS_V_EN (0x1 << 0)
>> +#define MAX98927_MEAS_I_EN (0x1 << 1)
>> +
>> +/* MAX98927_R0040_BOOST_CTRL0 */
>> +#define MAX98927_BOOST_CTRL0_VOUT_MASK (0x1f << 0)
>> +#define MAX98927_BOOST_CTRL0_PVDD_MASK (0x1 << 7)
>> +#define MAX98927_BOOST_CTRL0_PVDD_EN_SHIFT (7)
>> +
>> +/* MAX98927_R0052_BROWNOUT_EN */
>> +#define MAX98927_BROWNOUT_BDE_EN (0x1 << 0)
>> +#define MAX98927_BROWNOUT_AMP_EN (0x1 << 1)
>> +#define MAX98927_BROWNOUT_DSP_EN (0x1 << 2)
>> +#define MAX98927_BROWNOUT_DSP_SHIFT (2)
>> +
>> +/* MAX98927_R0100_SOFT_RESET */
>> +#define MAX98927_SOFT_RESET (0x1 << 0)
>> +
>> +/* MAX98927_R00FF_GLOBAL_SHDN */
>> +#define MAX98927_GLOBAL_EN_MASK (0x1 << 0)
>> +
>> +struct max98927_priv {
>> + struct regmap *regmap;
>> + struct snd_soc_codec *codec;
>> + struct max98927_pdata *pdata;
>> + unsigned int spk_gain;
>> + unsigned int sysclk;
>> + unsigned int v_l_slot;
>> + unsigned int i_l_slot;
>> + bool interleave_mode;
>> + unsigned int ch_size;
>> + unsigned int rate;
>> + unsigned int iface;
>> + unsigned int master;
>> + unsigned int digital_gain;
>> +};
>> +#endif
>> --
>> 2.11.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 v6 4/5] i2c: aspeed: added driver for Aspeed I2C
From: Ryan Chen @ 2017-04-26 0:52 UTC (permalink / raw)
To: Brendan Higgins
Cc: Benjamin Herrenschmidt, Wolfram Sang, Rob Herring, Mark Rutland,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Joel Stanley,
Vladimir Zapolskiy, Kachalov Anton, Cédric Le Goater,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, OpenBMC Maillist
In-Reply-To: <CAFd5g45htFgr5oHbB9W_nyyMfm5J7BCKUuP73RxKhNW3LkWtyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Thanks Ryan. Can you shed some light on the meaning of the high-speed bit as well please ?
>
> About ASPEED_I2CD_M_HIGH_SPEED_EN, it is support for I2C specification "High speed transfer". And also device need support it.
> If you just speed up the I2C bus clock, you don’t have to enable ASPEED_I2CD_M_HIGH_SPEED_EN, just change the clock is ok.
>
>Interesting, I thought that ASPEED_I2CD_M_SDA_DRIVE_1T_EN and its counterpart would be used for fast mode or fast mode plus and ASPEED_I2CD_M_HIGH_SPEED_EN would be used for fast mode plus or high speed mode and that they work by driving the SDA and SCL signals to >improve rise times. It made sense to me because the lowest SCL you can get with base clock set to zero is about ~1.5MHz which is in between fast mode plus (1MHz) and high speed mode (3.4MHz).
>But from what you are saying, ASPEED_I2CD_M_SDA_DRIVE_1T_EN and its counterpart are totally orthogonal to the selected speed and ASPEED_I2CD_M_HIGH_SPEED_EN exists as a matter of convenience to set all of the divider registers to their smallest possible values. Is my >
>understanding correct?
In I2c specification[http://www.csd.uoc.gr/~hy428/reading/i2c_spec.pdf] there have a chapter about high speed transfer. It will start from specific command (00001XXX) and after that can transfer to high speed mode.
The following is our high speed mode programming guide. That also have description at AST2400 datasheet. 40.7.12
>
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Tuesday, April 25, 2017 5:35 PM
> To: Ryan Chen <ryan_chen@aspeedtech.com>; Brendan Higgins
> <brendanhiggins@google.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Thomas
> Gleixner <tglx@linutronix.de>; Jason Cooper <jason@lakedaemon.net>;
> Marc Zyngier <marc.zyngier@arm.com>; Joel Stanley <joel@jms.id.au>;
> Vladimir Zapolskiy <vz@mleia.com>; Kachalov Anton <mouse@mayc.ru>;
> Cédric Le Goater <clg@kaod.org>; linux-i2c@vger.kernel.org;
> devicetree@vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; OpenBMC Maillist
> <openbmc@lists.ozlabs.org>
> Subject: Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C
>
> On Tue, 2017-04-25 at 08:50 +0000, Ryan Chen wrote:
>> Hello All,
>> ASPEED_I2CD_M_SDA_DRIVE_1T_EN,
>> ASPEED_I2CD_SDA_DRIVE_1T_EN is specific for some case usage.
>> For example, if i2c bus is use on "high speed" and
>> "single slave and master" and i2c bus is too long. It need drive SDA or SCL less lunacy.
>> It would enable it.
>> Otherwise, don’t enable it. especially in multi-master.
>> It can’t be enable.
>
> That smells like a specific enough use case that we should probably cover with a device-tree property, something like an empty "sda-extra-drive" property (empty properties are typically used for booleans, their presence means "true").
>
> Thanks Ryan. Can you shed some light on the meaning of the high-speed
> bit as well please ? Does it force to a specific speed (ignoring the
> divisor) or we can still play with the clock high/low counts ?
>
...
>> > Your latest patch still does that. It will do things like start a
>> > STOP command *then* ack the status bits. I'm pretty sure that's
>> > bogus.
>> >
>> > That way it's a lot simpler to simply move the
>> >
>> > writel(irq_status, bus->base + ASPEED_I2C_INTR_STS_REG);
>> >
>> > To either right after the readl of the status reg at the beginning
>> > of aspeed_i2c_master_irq().
>> >
>> > I would be very surprised if that didn't work properly and wasn't
>> > much safer than what you are currently doing.
>>
>> I think I tried your way and it worked. In anycase, Ryan will be able
>> to clarify for us.
After thinking about this more, I think Ben is right. It would be unusual for such a common convention to be broken and even if it is, I do not see how a command could take effect until it is actually issued. Nevertheless, it would make me feel better if you, Ryan, could comment on this.
>>
>> >
>> > > Let me know if you still think we need a "RECOVERY" state.
>> >
...
I feel pretty good about this; it does not look like there will be a lot of changes going into v8; hopefully, that version will be good enough to get merged.
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Andrew Lunn @ 2017-04-26 0:49 UTC (permalink / raw)
To: Eric Anholt
Cc: Florian Fainelli, Vivien Didelot, netdev, Rob Herring,
Mark Rutland, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui, Scott Branden, Jon Mason
In-Reply-To: <20170425235357.7690-2-eric@anholt.net>
> + eth0: ethernet@18042000 {
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1000>;
Hi Eric
Sorry i missed this the first time. Does this Ethernet controller do >
1Gbps? Does this max-speed do anything useful?
Andrew
^ permalink raw reply
* Re: [PATCH v2 1/2] of: support dtc compiler flags for overlays
From: Frank Rowand @ 2017-04-26 0:10 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Rob Herring, Stephen Boyd, Michal Marek, devicetree,
Linux Kernel Mailing List, Linux Kbuild mailing list
In-Reply-To: <CAK7LNARd-XsCfSJhDj3JisH=u4XZm8DaPEa5Pg2ciWrq8Ueing@mail.gmail.com>
On 04/25/17 15:04, Masahiro Yamada wrote:
> 2017-04-25 8:05 GMT+09:00 <frowand.list@gmail.com>:
>> From: Frank Rowand <frank.rowand@sony.com>
>>
>> The dtc compiler version that adds initial support was available
>> in 4.11-rc1. Add the ability to set the dtc compiler flags needed
>> by overlays.
>>
>> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
>> ---
>
>
> I know your motivation for 1/2 is overlay,
> but this patch itself is more generic.
> (support for per-file dtc compiler flag)
>
> Could you reword the commit subject a little bit?
>
> Otherwise,
>
> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Fixed in version 4.
-Frank
>
>
>
>> scripts/Makefile.lib | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>> index 0a07f9014944..0bbec480d323 100644
>> --- a/scripts/Makefile.lib
>> +++ b/scripts/Makefile.lib
>> @@ -283,6 +283,8 @@ ifeq ($(KBUILD_ENABLE_EXTRA_GCC_CHECKS),)
>> DTC_FLAGS += -Wno-unit_address_vs_reg
>> endif
>>
>> +DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
>> +
>> # Generate an assembly file to wrap the output of the device tree compiler
>> quiet_cmd_dt_S_dtb= DTB $@
>> cmd_dt_S_dtb= \
>> --
>
>
^ permalink raw reply
* [PATCH v4 2/2] of: Add unit tests for applying overlays
From: frowand.list @ 2017-04-26 0:09 UTC (permalink / raw)
To: Rob Herring, stephen.boyd, mmarek; +Cc: devicetree, linux-kernel, linux-kbuild
In-Reply-To: <1493165394-29367-1-git-send-email-frowand.list@gmail.com>
From: Frank Rowand <frank.rowand@sony.com>
Existing overlay unit tests examine individual pieces of the overlay
code. The new tests target the entire process of applying an overlay.
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
---
There are checkpatch warnings. I have reviewed them and feel they
can be ignored.
drivers/of/fdt.c | 14 +-
drivers/of/of_private.h | 12 +
drivers/of/unittest-data/Makefile | 17 +-
drivers/of/unittest-data/overlay.dts | 53 ++++
drivers/of/unittest-data/overlay_bad_phandle.dts | 20 ++
drivers/of/unittest-data/overlay_base.dts | 80 ++++++
drivers/of/unittest.c | 317 +++++++++++++++++++++++
7 files changed, 505 insertions(+), 8 deletions(-)
create mode 100644 drivers/of/unittest-data/overlay.dts
create mode 100644 drivers/of/unittest-data/overlay_bad_phandle.dts
create mode 100644 drivers/of/unittest-data/overlay_base.dts
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e5ce4b59e162..e33f7818bc6c 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -31,6 +31,8 @@
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#include <asm/page.h>
+#include "of_private.h"
+
/*
* of_fdt_limit_memory - limit the number of regions in the /memory node
* @limit: maximum entries
@@ -469,11 +471,11 @@ static int unflatten_dt_nodes(const void *blob,
* Returns NULL on failure or the memory chunk containing the unflattened
* device tree on success.
*/
-static void *__unflatten_device_tree(const void *blob,
- struct device_node *dad,
- struct device_node **mynodes,
- void *(*dt_alloc)(u64 size, u64 align),
- bool detached)
+void *__unflatten_device_tree(const void *blob,
+ struct device_node *dad,
+ struct device_node **mynodes,
+ void *(*dt_alloc)(u64 size, u64 align),
+ bool detached)
{
int size;
void *mem;
@@ -1261,6 +1263,8 @@ void __init unflatten_device_tree(void)
/* Get pointer to "/chosen" and "/aliases" nodes for use everywhere */
of_alias_scan(early_init_dt_alloc_memory_arch);
+
+ unittest_unflatten_overlay_base();
}
/**
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 18bbb4517e25..de5c604f5cc4 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -55,6 +55,18 @@ static inline int of_property_notify(int action, struct device_node *np,
}
#endif /* CONFIG_OF_DYNAMIC */
+#ifdef CONFIG_OF_UNITTEST
+extern void __init unittest_unflatten_overlay_base(void);
+#else
+static inline void unittest_unflatten_overlay_base(void) {};
+#endif
+
+extern void *__unflatten_device_tree(const void *blob,
+ struct device_node *dad,
+ struct device_node **mynodes,
+ void *(*dt_alloc)(u64 size, u64 align),
+ bool detached);
+
/**
* General utilities for working with live trees.
*
diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
index 1ac5cc01d627..6e00a9c69e58 100644
--- a/drivers/of/unittest-data/Makefile
+++ b/drivers/of/unittest-data/Makefile
@@ -1,7 +1,18 @@
obj-y += testcases.dtb.o
+obj-y += overlay.dtb.o
+obj-y += overlay_bad_phandle.dtb.o
+obj-y += overlay_base.dtb.o
targets += testcases.dtb testcases.dtb.S
+targets += overlay.dtb overlay.dtb.S
+targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S
+targets += overlay_base.dtb overlay_base.dtb.S
-.SECONDARY: \
- $(obj)/testcases.dtb.S \
- $(obj)/testcases.dtb
+.PRECIOUS: \
+ $(obj)/%.dtb.S \
+ $(obj)/%.dtb
+
+# enable creation of __symbols__ node
+DTC_FLAGS_overlay := -@
+DTC_FLAGS_overlay_bad_phandle := -@
+DTC_FLAGS_overlay_base := -@
diff --git a/drivers/of/unittest-data/overlay.dts b/drivers/of/unittest-data/overlay.dts
new file mode 100644
index 000000000000..6cd7e6a0c13e
--- /dev/null
+++ b/drivers/of/unittest-data/overlay.dts
@@ -0,0 +1,53 @@
+/dts-v1/;
+/plugin/;
+
+/ {
+
+ fragment@0 {
+ target = <&electric_1>;
+
+ __overlay__ {
+ status = "ok";
+
+ hvac_2: hvac-large-1 {
+ compatible = "ot,hvac-large";
+ heat-range = < 40 75 >;
+ cool-range = < 65 80 >;
+ };
+ };
+ };
+
+ fragment@1 {
+ target = <&rides_1>;
+
+ __overlay__ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "ok";
+
+ ride@200 {
+ compatible = "ot,ferris-wheel";
+ reg = < 0x00000200 0x100 >;
+ hvac-provider = < &hvac_2 >;
+ hvac-thermostat = < 27 32 > ;
+ hvac-zones = < 12 5 >;
+ hvac-zone-names = "operator", "snack-bar";
+ spin-controller = < &spin_ctrl_1 3 >;
+ spin-rph = < 30 >;
+ gondolas = < 16 >;
+ gondola-capacity = < 6 >;
+ };
+ };
+ };
+
+ fragment@2 {
+ target = <&lights_2>;
+
+ __overlay__ {
+ status = "ok";
+ color = "purple", "white", "red", "green";
+ rate = < 3 256 >;
+ };
+ };
+
+};
diff --git a/drivers/of/unittest-data/overlay_bad_phandle.dts b/drivers/of/unittest-data/overlay_bad_phandle.dts
new file mode 100644
index 000000000000..270ee885a623
--- /dev/null
+++ b/drivers/of/unittest-data/overlay_bad_phandle.dts
@@ -0,0 +1,20 @@
+/dts-v1/;
+/plugin/;
+
+/ {
+
+ fragment@0 {
+ target = <&electric_1>;
+
+ __overlay__ {
+
+ // This label should cause an error when the overlay
+ // is applied. There is already a phandle value
+ // in the base tree for motor-1.
+ spin_ctrl_1_conflict: motor-1 {
+ accelerate = < 3 >;
+ decelerate = < 5 >;
+ };
+ };
+ };
+};
diff --git a/drivers/of/unittest-data/overlay_base.dts b/drivers/of/unittest-data/overlay_base.dts
new file mode 100644
index 000000000000..5566b27fb61a
--- /dev/null
+++ b/drivers/of/unittest-data/overlay_base.dts
@@ -0,0 +1,80 @@
+/dts-v1/;
+/plugin/;
+
+/*
+ * Base device tree that overlays will be applied against.
+ *
+ * Do not add any properties in node "/".
+ * Do not add any nodes other than "/testcase-data-2" in node "/".
+ * Do not add anything that would result in dtc creating node "/__fixups__".
+ * dtc will create nodes "/__symbols__" and "/__local_fixups__".
+ */
+
+/ {
+ testcase-data-2 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ electric_1: substation@100 {
+ compatible = "ot,big-volts-control";
+ reg = < 0x00000100 0x100 >;
+ status = "disabled";
+
+ hvac_1: hvac-medium-1 {
+ compatible = "ot,hvac-medium";
+ heat-range = < 50 75 >;
+ cool-range = < 60 80 >;
+ };
+
+ spin_ctrl_1: motor-1 {
+ compatible = "ot,ferris-wheel-motor";
+ spin = "clockwise";
+ };
+
+ spin_ctrl_2: motor-8 {
+ compatible = "ot,roller-coaster-motor";
+ };
+ };
+
+ rides_1: fairway-1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "ot,rides";
+ status = "disabled";
+ orientation = < 127 >;
+
+ ride@100 {
+ compatible = "ot,roller-coaster";
+ reg = < 0x00000100 0x100 >;
+ hvac-provider = < &hvac_1 >;
+ hvac-thermostat = < 29 > ;
+ hvac-zones = < 14 >;
+ hvac-zone-names = "operator";
+ spin-controller = < &spin_ctrl_2 5 &spin_ctrl_2 7 >;
+ spin-controller-names = "track_1", "track_2";
+ queues = < 2 >;
+ };
+ };
+
+ lights_1: lights@30000 {
+ compatible = "ot,work-lights";
+ reg = < 0x00030000 0x1000 >;
+ status = "disabled";
+ };
+
+ lights_2: lights@40000 {
+ compatible = "ot,show-lights";
+ reg = < 0x00040000 0x1000 >;
+ status = "disabled";
+ rate = < 13 138 >;
+ };
+
+ retail_1: vending@50000 {
+ reg = < 0x00050000 0x1000 >;
+ compatible = "ot,tickets";
+ status = "disabled";
+ };
+
+ };
+};
+
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 62db55b97c10..12597ff8cfb0 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -8,6 +8,7 @@
#include <linux/err.h>
#include <linux/errno.h>
#include <linux/hashtable.h>
+#include <linux/libfdt.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/of_irq.h>
@@ -1925,6 +1926,320 @@ static void __init of_unittest_overlay(void)
static inline void __init of_unittest_overlay(void) { }
#endif
+/*
+ * __dtb_ot_begin[] and __dtb_ot_end[] are created by cmd_dt_S_dtb
+ * in scripts/Makefile.lib
+ */
+
+#define OVERLAY_INFO_EXTERN(name) \
+ extern uint8_t __dtb_##name##_begin[]; \
+ extern uint8_t __dtb_##name##_end[]
+
+#define OVERLAY_INFO(name, expected) \
+{ .dtb_begin = __dtb_##name##_begin, \
+ .dtb_end = __dtb_##name##_end, \
+ .expected_result = expected, \
+}
+
+struct overlay_info {
+ uint8_t *dtb_begin;
+ uint8_t *dtb_end;
+ void *data;
+ struct device_node *np_overlay;
+ int expected_result;
+ int overlay_id;
+};
+
+OVERLAY_INFO_EXTERN(overlay_base);
+OVERLAY_INFO_EXTERN(overlay);
+OVERLAY_INFO_EXTERN(overlay_bad_phandle);
+
+#ifdef CONFIG_OF_OVERLAY
+
+/* order of entries is hard-coded into users of overlays[] */
+static struct overlay_info overlays[] = {
+ OVERLAY_INFO(overlay_base, -9999),
+ OVERLAY_INFO(overlay, 0),
+ OVERLAY_INFO(overlay_bad_phandle, -EINVAL),
+ {}
+};
+
+static struct device_node *overlay_base_root;
+
+/*
+ * Create base device tree for the overlay unittest.
+ *
+ * This is called from very early boot code.
+ *
+ * Do as much as possible the same way as done in __unflatten_device_tree
+ * and other early boot steps for the normal FDT so that the overlay base
+ * unflattened tree will have the same characteristics as the real tree
+ * (such as having memory allocated by the early allocator). The goal
+ * is to test "the real thing" as much as possible, and test "test setup
+ * code" as little as possible.
+ *
+ * Have to stop before resolving phandles, because that uses kmalloc.
+ */
+void __init unittest_unflatten_overlay_base(void)
+{
+ struct overlay_info *info;
+ u32 data_size;
+ u32 size;
+
+ info = &overlays[0];
+
+ if (info->expected_result != -9999) {
+ pr_err("No dtb 'overlay_base' to attach\n");
+ return;
+ }
+
+ data_size = info->dtb_end - info->dtb_begin;
+ if (!data_size) {
+ pr_err("No dtb 'overlay_base' to attach\n");
+ return;
+ }
+
+ size = fdt_totalsize(info->dtb_begin);
+ if (size != data_size) {
+ pr_err("dtb 'overlay_base' header totalsize != actual size");
+ return;
+ }
+
+ info->data = early_init_dt_alloc_memory_arch(size,
+ roundup_pow_of_two(FDT_V17_SIZE));
+ if (!info->data) {
+ pr_err("alloc for dtb 'overlay_base' failed");
+ return;
+ }
+
+ memcpy(info->data, info->dtb_begin, size);
+
+ __unflatten_device_tree(info->data, NULL, &info->np_overlay,
+ early_init_dt_alloc_memory_arch, true);
+ overlay_base_root = info->np_overlay;
+}
+
+/*
+ * The purpose of of_unittest_overlay_data_add is to add an
+ * overlay in the normal fashion. This is a test of the whole
+ * picture, instead of testing individual elements.
+ *
+ * A secondary purpose is to be able to verify that the contents of
+ * /proc/device-tree/ contains the updated structure and values from
+ * the overlay. That must be verified separately in user space.
+ *
+ * Return 0 on unexpected error.
+ */
+static int __init overlay_data_add(int onum)
+{
+ struct overlay_info *info;
+ int k;
+ int ret;
+ u32 size;
+ u32 size_from_header;
+
+ for (k = 0, info = overlays; info; info++, k++) {
+ if (k == onum)
+ break;
+ }
+ if (onum > k)
+ return 0;
+
+ size = info->dtb_end - info->dtb_begin;
+ if (!size) {
+ pr_err("no overlay to attach, %d\n", onum);
+ ret = 0;
+ }
+
+ size_from_header = fdt_totalsize(info->dtb_begin);
+ if (size_from_header != size) {
+ pr_err("overlay header totalsize != actual size, %d", onum);
+ return 0;
+ }
+
+ /*
+ * Must create permanent copy of FDT because of_fdt_unflatten_tree()
+ * will create pointers to the passed in FDT in the EDT.
+ */
+ info->data = kmemdup(info->dtb_begin, size, GFP_KERNEL);
+ if (!info->data) {
+ pr_err("unable to allocate memory for data, %d\n", onum);
+ return 0;
+ }
+
+ of_fdt_unflatten_tree(info->data, NULL, &info->np_overlay);
+ if (!info->np_overlay) {
+ pr_err("unable to unflatten overlay, %d\n", onum);
+ ret = 0;
+ goto out_free_data;
+ }
+ of_node_set_flag(info->np_overlay, OF_DETACHED);
+
+ ret = of_resolve_phandles(info->np_overlay);
+ if (ret) {
+ pr_err("resolve ot phandles (ret=%d), %d\n", ret, onum);
+ goto out_free_np_overlay;
+ }
+
+ ret = of_overlay_create(info->np_overlay);
+ if (ret < 0) {
+ pr_err("of_overlay_create() (ret=%d), %d\n", ret, onum);
+ goto out_free_np_overlay;
+ } else {
+ info->overlay_id = ret;
+ ret = 0;
+ }
+
+ pr_debug("__dtb_overlay_begin applied, overlay id %d\n", ret);
+
+ goto out;
+
+out_free_np_overlay:
+ /*
+ * info->np_overlay is the unflattened device tree
+ * It has not been spliced into the live tree.
+ */
+
+ /* todo: function to free unflattened device tree */
+
+out_free_data:
+ kfree(info->data);
+
+out:
+ return (ret == info->expected_result);
+}
+
+/*
+ * The purpose of of_unittest_overlay_high_level is to add an overlay
+ * in the normal fashion. This is a test of the whole picture,
+ * instead of individual elements.
+ *
+ * The first part of the function is _not_ normal overlay usage; it is
+ * finishing splicing the base overlay device tree into the live tree.
+ */
+static __init void of_unittest_overlay_high_level(void)
+{
+ struct device_node *last_sibling;
+ struct device_node *np;
+ struct device_node *of_symbols;
+ struct device_node *overlay_base_symbols;
+ struct device_node **pprev;
+ struct property *prop;
+ int ret;
+
+ if (!overlay_base_root) {
+ unittest(0, "overlay_base_root not initialized\n");
+ return;
+ }
+
+ /*
+ * Could not fixup phandles in unittest_unflatten_overlay_base()
+ * because kmalloc() was not yet available.
+ */
+ of_resolve_phandles(overlay_base_root);
+
+ /*
+ * do not allow overlay_base to duplicate any node already in
+ * tree, this greatly simplifies the code
+ */
+
+ /*
+ * remove overlay_base_root node "__local_fixups", after
+ * being used by of_resolve_phandles()
+ */
+ pprev = &overlay_base_root->child;
+ for (np = overlay_base_root->child; np; np = np->sibling) {
+ if (!of_node_cmp(np->name, "__local_fixups__")) {
+ *pprev = np->sibling;
+ break;
+ }
+ pprev = &np->sibling;
+ }
+
+ /* remove overlay_base_root node "__symbols__" if in live tree */
+ of_symbols = of_get_child_by_name(of_root, "__symbols__");
+ if (of_symbols) {
+ /* will have to graft properties from node into live tree */
+ pprev = &overlay_base_root->child;
+ for (np = overlay_base_root->child; np; np = np->sibling) {
+ if (!of_node_cmp(np->name, "__symbols__")) {
+ overlay_base_symbols = np;
+ *pprev = np->sibling;
+ break;
+ }
+ pprev = &np->sibling;
+ }
+ }
+
+ for (np = overlay_base_root->child; np; np = np->sibling) {
+ if (of_get_child_by_name(of_root, np->name)) {
+ unittest(0, "illegal node name in overlay_base %s",
+ np->name);
+ return;
+ }
+ }
+
+ /*
+ * overlay 'overlay_base' is not allowed to have root
+ * properties, so only need to splice nodes into main device tree.
+ *
+ * root node of *overlay_base_root will not be freed, it is lost
+ * memory.
+ */
+
+ for (np = overlay_base_root->child; np; np = np->sibling)
+ np->parent = of_root;
+
+ mutex_lock(&of_mutex);
+
+ for (np = of_root->child; np; np = np->sibling)
+ last_sibling = np;
+
+ if (last_sibling)
+ last_sibling->sibling = overlay_base_root->child;
+ else
+ of_root->child = overlay_base_root->child;
+
+ for_each_of_allnodes_from(overlay_base_root, np)
+ __of_attach_node_sysfs(np);
+
+ if (of_symbols) {
+ for_each_property_of_node(overlay_base_symbols, prop) {
+ ret = __of_add_property(of_symbols, prop);
+ if (ret) {
+ unittest(0,
+ "duplicate property '%s' in overlay_base node __symbols__",
+ prop->name);
+ return;
+ }
+ ret = __of_add_property_sysfs(of_symbols, prop);
+ if (ret) {
+ unittest(0,
+ "unable to add property '%s' in overlay_base node __symbols__ to sysfs",
+ prop->name);
+ return;
+ }
+ }
+ }
+
+ mutex_unlock(&of_mutex);
+
+
+ /* now do the normal overlay usage test */
+
+ unittest(overlay_data_add(1),
+ "Adding overlay 'overlay' failed\n");
+
+ unittest(overlay_data_add(2),
+ "Adding overlay 'overlay_bad_phandle' failed\n");
+}
+
+#else
+
+static inline __init void of_unittest_overlay_high_level(void) {}
+
+#endif
+
static int __init of_unittest(void)
{
struct device_node *np;
@@ -1962,6 +2277,8 @@ static int __init of_unittest(void)
/* Double check linkage after removing testcase data */
of_unittest_check_tree_linkage();
+ of_unittest_overlay_high_level();
+
pr_info("end of unittest - %i passed, %i failed\n",
unittest_results.passed, unittest_results.failed);
--
Frank Rowand <frank.rowand@sony.com>
^ permalink raw reply related
* [PATCH v4 1/2] of: per-file dtc compiler flags
From: frowand.list-Re5JQEeQqe8AvxtiuMwx3w @ 2017-04-26 0:09 UTC (permalink / raw)
To: Rob Herring, stephen.boyd-QSEj5FYQhm4dnm+yROfE0A,
mmarek-IBi9RG/b67k
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493165394-29367-1-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
The dtc compiler version that adds initial support was available
in 4.11-rc1. Add the ability to set an additional dtc compiler
flag is needed by overlays.
Signed-off-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
---
scripts/Makefile.lib | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 0a07f9014944..0bbec480d323 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -283,6 +283,8 @@ ifeq ($(KBUILD_ENABLE_EXTRA_GCC_CHECKS),)
DTC_FLAGS += -Wno-unit_address_vs_reg
endif
+DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
+
# Generate an assembly file to wrap the output of the device tree compiler
quiet_cmd_dt_S_dtb= DTB $@
cmd_dt_S_dtb= \
--
Frank Rowand <frank.rowand-7U/KSKJipcs@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 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