* Re: [PATCH v3 4/4] regulator: core: Balance coupled regulators voltages
From: Mark Brown @ 2017-12-15 15:19 UTC (permalink / raw)
To: Maciej Purski
Cc: linux-kernel, devicetree, Liam Girdwood, Rob Herring,
Mark Rutland, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <0bca0d20-1ca8-be4c-a60e-bbc0c640ae41@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Wed, Dec 13, 2017 at 10:25:00AM +0100, Maciej Purski wrote:
> > shared. To that end I'd adjust the code so that we always have a
> > coupling descriptor and then handle the case where there's only one
> > regulator described in there.
> Do you have any suggestion, how should I implement that path? The thing which
> makes it more complicated is locking, because set_voltage_unlocked is done
> under one regulator's mutex and its suppliers, while balance procedure locks
> every coupled regulator without its suppliers. The suppliers for a single
> regulator are locked when setting a single regulator's voltage takes place.
We only really need to lock the supplies when doing the actual mechanics
of voltage changes so I'm not sure I see a big issue here - if we always
go through balancing first then voltage setting it should be fine. If
everything is always balancing (even uncoupled regulators) then part of
the transition should be moving some if not all of the data updates to
balancing.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] arm: sunxi: Add alternative pins for spi0
From: Maxime Ripard @ 2017-12-15 15:08 UTC (permalink / raw)
To: Stefan Mavrodiev
Cc: Stefan Mavrodiev, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring,
Mark Rutland, Russell King, Chen-Yu Tsai,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list
In-Reply-To: <5f518e4b-e624-17c2-7e72-24ba930a1c15-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
Hi,
On Thu, Dec 14, 2017 at 08:24:54AM +0200, Stefan Mavrodiev wrote:
> On 12/13/2017 05:40 PM, Maxime Ripard wrote:
> > Hi,
> >
> > On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote:
> > > Allwinner A10/A13/A20 SoCs have pinmux for spi0
> > > on port C. The patch adds these pins in the respective
> > > dts includes.
> > >
> > > Signed-off-by: Stefan Mavrodiev <stefan-kyXcfZUBQGPQT0dZR+AlfA@public.gmane.org>
> > Do you have any boards that are using these?
> >
> > We won't merge that patch if there's no users for it.
>
> A20-OLinuXino-Lime/Lime2 and A10-OLinuXino-Lime with spi flash.
> For A13 we still doesn't have that option.
If this bus is exposed on the headers, you can add those to the DT but
leave them disabled if you want. Buf if there's no users of those
nodes, our policy is not to merge them.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [v7, 3/3] ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl, imx6q-snvs-lpgpr" node
From: Stefan Wahren @ 2017-12-15 15:07 UTC (permalink / raw)
To: Maciej S. Szmigiero, Oleksij Rempel
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Guy Shapiro,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Srinivas Kandagatla, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Maxime Ripard,
Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <cfd53377-437a-98d3-1a0e-1123495a35ee-APzI5cXaD1zVlRWJc41N0YvC60bnQu0Y@public.gmane.org>
Hi Maciej,
Am 11.12.2017 um 23:31 schrieb Maciej S. Szmigiero:
> On 20.06.2017 09:09, Oleksij Rempel wrote:
>> This node is for Low Power General Purpose Register which can
>> be used as Non-Volatile Storage.
>>
>> Signed-off-by: Oleksij Rempel <o.rempel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> ---
>> arch/arm/boot/dts/imx6qdl.dtsi | 4 ++++
>> arch/arm/boot/dts/imx6ul.dtsi | 4 ++++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
>> index e426faa9c243..94e992558238 100644
> (..)
>
> FYI: It looks to me that while the driver itself from this series was
> picked up and eventually reached Linus' tree this DT change was
> forgotten, since I can't find in any tree (or am I not looking at the
> right place?).
thanks for the reminder. It's possible that this patch won't apply
anymore and needs a resend.
>
> Maciej
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] ARM64: dts: meson-axg: enable IR controller
From: Yixun Lan @ 2017-12-15 15:06 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ, Rob Herring, Neil Armstrong,
Mark Rutland, Carlo Caione,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513350088.2261.62.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Jerome
On 12/15/2017 11:01 PM, Jerome Brunet wrote:
> On Fri, 2017-12-15 at 22:59 +0800, Yixun Lan wrote:
>> Enable IR remote controller which found in Amlogic's Meson-AXG SoCs.
>>
>> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>>
>> ---
>>
>> Changes since v2 at [2]
>> - rebase to Kevin's v4.16/dt64 branch
>> - this patch depend on pinctrl DT driver
>>
>> Changes since v1 at [1]:
>> - drop the compatbile 'amlogic,meson-gx-ir'
>>
>> [2]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005574.html
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005527.html
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 14 ++++++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
>> index 70eca1f8736a..e85fb665f12e 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
>> @@ -20,3 +20,9 @@
>> &uart_AO {
>> status = "okay";
>> };
>> +
>> +&ir {
>> + status = "okay";
>> + pinctrl-0 = <&remote_input_ao_pins>;
>> + pinctrl-names = "default";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index a0d7b10da512..1cd34141a5c1 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -223,6 +223,13 @@
>> #gpio-cells = <2>;
>> gpio-ranges = <&pinctrl_aobus 0 0 15>;
>> };
>> +
>> + remote_input_ao_pins: remote_input_ao {
>> + mux {
>> + groups = "remote_input_ao";
>> + function = "remote_input_ao";
>> + };
>> + };
>> };
>>
>> uart_AO: serial@3000 {
>> @@ -242,6 +249,13 @@
>> clock-names = "xtal", "pclk", "baud";
>> status = "disabled";
>> };
>> +
>> + ir: ir@8000 {
>> + compatible = "amlogic,meson-gxbb-ir";
>
> compatible = "amlogic,meson-axg-ir", "amlogic,meson-gxbb-ir";
>
> please (and the binding doc patch)
what's the policy for adding new compatible string?
is this a must even we don't use it for now?
or what's the problem if adding it when we really need it
>
>> + reg = <0x0 0x8000 0x0 0x20>;
>> + interrupts = <GIC_SPI 196 IRQ_TYPE_EDGE_RISING>;
>> + status = "disabled";
>> + };
>> };
>> };
>> };
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] ARM64: dts: meson-axg: enable IR controller
From: Jerome Brunet @ 2017-12-15 15:01 UTC (permalink / raw)
To: Yixun Lan, Kevin Hilman, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Neil Armstrong, Mark Rutland, Carlo Caione,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215145906.1494-1-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
On Fri, 2017-12-15 at 22:59 +0800, Yixun Lan wrote:
> Enable IR remote controller which found in Amlogic's Meson-AXG SoCs.
>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> ---
>
> Changes since v2 at [2]
> - rebase to Kevin's v4.16/dt64 branch
> - this patch depend on pinctrl DT driver
>
> Changes since v1 at [1]:
> - drop the compatbile 'amlogic,meson-gx-ir'
>
> [2]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005574.html
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005527.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 14 ++++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 70eca1f8736a..e85fb665f12e 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -20,3 +20,9 @@
> &uart_AO {
> status = "okay";
> };
> +
> +&ir {
> + status = "okay";
> + pinctrl-0 = <&remote_input_ao_pins>;
> + pinctrl-names = "default";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index a0d7b10da512..1cd34141a5c1 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -223,6 +223,13 @@
> #gpio-cells = <2>;
> gpio-ranges = <&pinctrl_aobus 0 0 15>;
> };
> +
> + remote_input_ao_pins: remote_input_ao {
> + mux {
> + groups = "remote_input_ao";
> + function = "remote_input_ao";
> + };
> + };
> };
>
> uart_AO: serial@3000 {
> @@ -242,6 +249,13 @@
> clock-names = "xtal", "pclk", "baud";
> status = "disabled";
> };
> +
> + ir: ir@8000 {
> + compatible = "amlogic,meson-gxbb-ir";
compatible = "amlogic,meson-axg-ir", "amlogic,meson-gxbb-ir";
please (and the binding doc patch)
> + reg = <0x0 0x8000 0x0 0x20>;
> + interrupts = <GIC_SPI 196 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
> + };
> };
> };
> };
--
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 v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)
From: Shameerali Kolothum Thodi @ 2017-12-15 15:01 UTC (permalink / raw)
To: lorenzo.pieralisi@arm.com, robin.murphy@arm.com,
marc.zyngier@arm.com, will.deacon@arm.com
Cc: joro@8bytes.org, John Garry, xuwei (O), Guohanjun (Hanjun Guo),
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
devicetree@vger.kernel.org, Linuxarm
In-Reply-To: <20171214160957.13716-1-shameerali.kolothum.thodi@huawei.com>
Hi Lorenzo/Robin/Will,
Since this has all the necessary reviewed-by from all concerned now(Thanks to all),
just wondering how this will be picked up? through iort or iommu?
Please let me know.
Thanks,
Shameer
> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Thursday, December 14, 2017 4:10 PM
> To: lorenzo.pieralisi@arm.com; robin.murphy@arm.com;
> marc.zyngier@arm.com; will.deacon@arm.com
> Cc: joro@8bytes.org; John Garry <john.garry@huawei.com>; xuwei (O)
> <xuwei5@hisilicon.com>; Guohanjun (Hanjun Guo) <guohanjun@huawei.com>;
> iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; devicetree@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>
> Subject: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
>
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
>
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
>
> This patch implements an ACPI based quirk to reserve the hw msi regions
> in the smmu-v3 driver which means these address regions will not be
> translated and will be excluded from iova allocations.
>
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve and reserve
> the associated ITS base address from a device IORT node. The function
> has a check for smmu model to determine whether the platform requires
> the HW MSI reservation or not.
> 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> dts files so that users are warned about the non-DT support for this
> erratum.
>
> Changelog:
>
> v11--> v12
> -Thanks to Lorenzo, Fixed !CONFIG_IOMMU_API compile error(patch #1).
>
> v10 --> v11
> -Addressed comments from Lorenzo(patch#1)
> -Added Robin's Reviewed-by to patch #2
>
> v9 --> v10
> Addressed comments:
> -Moved smmu model check to iort helper function to selectively apply
> the msi reservation which will make the fn call generic from iommu-dma.
> -Removed PCI blacklisting patch, instead added smmu nodes(disabled)
> with comments to hip06/hip07 dts file.
>
> v8 --> v9
> -Thanks to Marc, fixed IORT helper function to reserve the ITS
> translater region only.
> -Removed the DT support for MSI reservation and blacklisted
> HiSilicon PCIe controllers on DT based systems when SMMUv3 is
> enabled.
>
> v7 --> v8
> Addressed comments from Rob and Lorenzo:
> -Modified to use DT compatible string for errata.
> -Changed logic to retrieve the msi-parent for DT case.
>
> v6 --> v7
> Addressed request from Will to add DT support for the erratum:
> - added bt binding
> - add of_iommu_msi_get_resv_regions()
> New arm64 silicon errata entry
> Rename iort_iommu_{its->msi}_get_resv_regions
>
> v5 --> v6
> Addressed comments from Robin and Lorenzo:
> -No change to patch#1 .
> -Reverted v5 patch#2 as this might break the platforms where this quirk
> is not applicable. Provided a generic function in iommu code and added
> back the quirk implementation in SMMU v3 driver(patch#3)
>
> v4 --> v5
> Addressed comments from Robin and Lorenzo:
> -Added a comment to make it clear that, for now, only straightforward
> HW topologies are handled while reserving ITS regions(patch #1).
>
> v3 --> v4
> Rebased on 4.13-rc1.
> Addressed comments from Robin, Will and Lorenzo:
> -As suggested by Robin, moved the ITS msi reservation into
> iommu_dma_get_resv_regions().
> -Added its_count != resv region failure case(patch #1).
>
> v2 --> v3
> Addressed comments from Lorenzo and Robin:
> -Removed dev_is_pci() check in smmuV3 driver.
> -Don't treat device not having an ITS mapping as an error in
> iort helper function.
>
> v1 --> v2
> -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
>
> RFCv2 -->PATCH
> -Incorporated Lorenzo's review comments.
>
> RFC v1 --> RFC v2
> Based on Robin's review comments,
> -Removed the generic erratum framework.
> -Using IORT/MADT tables to retrieve the ITS base addr instead
> of vendor specific CSRT table.
>
> Shameer Kolothum (3):
> ACPI/IORT: Add msi address regions reservation helper
> iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
> arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
>
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 56 ++++++++++++++++
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 25 +++++++
> drivers/acpi/arm64/iort.c | 111 ++++++++++++++++++++++++++++++-
> drivers/iommu/dma-iommu.c | 8 ++-
> drivers/irqchip/irq-gic-v3-its.c | 3 +-
> include/linux/acpi_iort.h | 7 +-
> 6 files changed, 204 insertions(+), 6 deletions(-)
>
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: dts: marvell: armada-37xx: add nodes allowing cpufreq support
From: Gregory CLEMENT @ 2017-12-15 15:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, linux-pm, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Rob Herring, devicetree, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits, Evan Wang, Andre Heider
In-Reply-To: <20171214150006.25438-5-gregory.clement@free-electrons.com>
Hi,
On jeu., déc. 14 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> In order to be able to use cpu freq, we need to associate a clock to each
> CPU and to expose the power management registers.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied on mvebu/dt64
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-372x.dtsi | 1 +
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> index 59d7557d3b1b..2554e0baea6b 100644
> --- a/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> @@ -56,6 +56,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x1>;
> + clocks = <&nb_periph_clk 16>;
> enable-method = "psci";
> };
> };
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index 90c26d616a54..3056d7168e0b 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -65,6 +65,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a53", "arm,armv8";
> reg = <0>;
> + clocks = <&nb_periph_clk 16>;
> enable-method = "psci";
> };
> };
> @@ -234,6 +235,12 @@
> };
> };
>
> + nb_pm: syscon@14000 {
> + compatible = "marvell,armada-3700-nb-pm",
> + "syscon";
> + reg = <0x14000 0x60>;
> + };
> +
> pinctrl_sb: pinctrl@18800 {
> compatible = "marvell,armada3710-sb-pinctrl",
> "syscon", "simple-mfd";
> --
> 2.15.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3] ARM64: dts: meson-axg: enable IR controller
From: Yixun Lan @ 2017-12-15 14:59 UTC (permalink / raw)
To: Kevin Hilman, devicetree
Cc: Rob Herring, Neil Armstrong, Jerome Brunet, Mark Rutland,
Carlo Caione, Yixun Lan, linux-amlogic, linux-arm-kernel,
linux-kernel
Enable IR remote controller which found in Amlogic's Meson-AXG SoCs.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
Changes since v2 at [2]
- rebase to Kevin's v4.16/dt64 branch
- this patch depend on pinctrl DT driver
Changes since v1 at [1]:
- drop the compatbile 'amlogic,meson-gx-ir'
[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005574.html
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005527.html
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 14 ++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..e85fb665f12e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -20,3 +20,9 @@
&uart_AO {
status = "okay";
};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index a0d7b10da512..1cd34141a5c1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -223,6 +223,13 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_aobus 0 0 15>;
};
+
+ remote_input_ao_pins: remote_input_ao {
+ mux {
+ groups = "remote_input_ao";
+ function = "remote_input_ao";
+ };
+ };
};
uart_AO: serial@3000 {
@@ -242,6 +249,13 @@
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
+
+ ir: ir@8000 {
+ compatible = "amlogic,meson-gxbb-ir";
+ reg = <0x0 0x8000 0x0 0x20>;
+ interrupts = <GIC_SPI 196 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
};
};
};
--
2.15.1
^ permalink raw reply related
* Re: [PATCH 2/2] media: coda: Add i.MX51 (CodaHx4) support
From: Philipp Zabel @ 2017-12-15 14:59 UTC (permalink / raw)
To: Hans Verkuil, linux-media
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Fabio Estevam,
Chris Healy, devicetree, kernel
In-Reply-To: <e26f7f6a-afa6-c55c-d94e-095df27c19ae@xs4all.nl>
Hi Hans,
On Fri, 2017-12-15 at 15:22 +0100, Hans Verkuil wrote:
> Hi Philipp,
>
> On 13/12/17 15:09, Philipp Zabel wrote:
> > Add support for the CodaHx4 VPU used on i.MX51.
> >
> > Decoding h.264, MPEG-4, and MPEG-2 video works, as well as encoding
> > h.264. MPEG-4 encoding is not enabled, it currently produces visual
> > artifacts.
> >
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
> > drivers/media/platform/coda/coda-bit.c | 45 ++++++++++++++++++++++---------
> > drivers/media/platform/coda/coda-common.c | 44 +++++++++++++++++++++++++++---
> > drivers/media/platform/coda/coda.h | 1 +
> > 3 files changed, 74 insertions(+), 16 deletions(-)
> >
>
> <snip>
>
> > + [CODA_IMX51] = {
> > + .firmware = {
> > + "vpu_fw_imx51.bin",
> > + "vpu/vpu_fw_imx51.bin",
> > + "v4l-codahx4-imx51.bin"
> > + },
> > + .product = CODA_HX4,
> > + .codecs = codahx4_codecs,
> > + .num_codecs = ARRAY_SIZE(codahx4_codecs),
> > + .vdevs = codahx4_video_devices,
> > + .num_vdevs = ARRAY_SIZE(codahx4_video_devices),
> > + .workbuf_size = 128 * 1024,
> > + .tempbuf_size = 304 * 1024,
> > + .iram_size = 0x14000,
> > + },
>
> What's the status of the firmware? Is it going to be available in some firmware
> repository? I remember when testing other imx devices that it was a bit tricky
> to get hold of the firmware. And googling v4l-codahx4-imx51.bin doesn't find
> anything other than this patch.
As far as I am aware, so far all efforts to get these firmware binaries
relicensed in a way that makes them redistributable in linux-firmware
have not succeeded.
They are distributed by NXP directly in the firmware-imx package.
The http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/ repository
contains links to the latest version:
wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-5.4.bin
dd if=firmware-imx-5.4.bin bs=34087 skip=1 | tar xj
cat firmware-imx-5.4/COPYING
regards
Philipp
^ permalink raw reply
* Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Daniel Thompson @ 2017-12-15 14:51 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Jingoo Han, Richard Purdie, Jacek Anaszewski, Pavel Machek,
Rob Herring, Doug Anderson, Brian Norris, Guenter Roeck,
Lee Jones, Alexandru Stan, linux-leds, devicetree, linux-kernel
In-Reply-To: <20171116141151.21171-3-enric.balletbo@collabora.com>
On Thu, Nov 16, 2017 at 03:11:51PM +0100, Enric Balletbo i Serra wrote:
> When you want to change the brightness using a PWM signal, one thing you
> need to consider is how human perceive the brightness. Human perceive the
> brightness change non-linearly, we have better sensitivity at low
> luminance than high luminance, so to achieve perceived linear dimming, the
> brightness must be matches to the way our eyes behave. The CIE 1931
> lightness formula is what actually describes how we perceive light.
>
> This patch adds support to compute the brightness levels based on a static
> table filled with the numbers provided by the CIE 1931 algorithm, for now
> it only supports PWM resolutions up to 65535 (16 bits) with 1024 steps.
> Lower PWM resolutions are implemented using the same curve but with less
> steps, e.g. For a PWM resolution of 256 (8 bits) we have 37 steps.
>
> The calculation of the duty cycle using the CIE 1931 algorithm is enabled by
> default when you do not define the 'brightness-levels' propriety in your
> device tree.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> drivers/video/backlight/pwm_bl.c | 160 +++++++++++++++++++++++++++++++++++----
> include/linux/pwm_backlight.h | 1 +
> 2 files changed, 147 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 59b1bfb..ea96358 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -26,6 +26,112 @@
>
> #define NSTEPS 256
>
> +/*
> + * CIE lightness to PWM conversion table. The CIE 1931 lightness formula is what
> + * actually describes how we perceive light:
> + *
> + * Y = (L* / 902.3) if L* ≤ 0.08856
> + * Y = ((L* + 16) / 116)^3 if L* > 0.08856
> + *
> + * Where Y is the luminance (output) between 0.0 and 1.0, and L* is the
> + * lightness (input) between 0 and 100.
> + */
> +const unsigned int cie1931_table[1024] = {
I'm a little surprised to see such a large table. I thought we'd be able
to use the linear interpolation logic to smooth a smaller table.
> + 0, 7, 14, 21, 28, 35, 43, 50, 57, 64, 71, 78, 85, 92, 99, 106, 114, 121,
> + 128, 135, 142, 149, 156, 163, 170, 177, 185, 192, 199, 206, 213, 220,
> + 227, 234, 241, 248, 256, 263, 270, 277, 284, 291, 298, 305, 312, 319,
> + 327, 334, 341, 348, 355, 362, 369, 376, 383, 390, 398, 405, 412, 419,
> + 426, 433, 440, 447, 454, 461, 469, 476, 483, 490, 497, 504, 511, 518,
> + 525, 532, 540, 547, 554, 561, 568, 575, 582, 589, 596, 603, 610, 618,
> + 625, 633, 640, 648, 655, 663, 671, 679, 687, 695, 703, 711, 719, 727,
> + 735, 744, 752, 761, 769, 778, 786, 795, 804, 813, 822, 831, 840, 849,
> + 858, 867, 876, 886, 895, 905, 914, 924, 934, 943, 953, 963, 973, 983,
> + 993, 1004, 1014, 1024, 1034, 1045, 1055, 1066, 1077, 1087, 1098, 1109,
> + 1120, 1131, 1142, 1153, 1165, 1176, 1187, 1199, 1210, 1222, 1234, 1245,
> + 1257, 1269, 1281, 1293, 1305, 1318, 1330, 1342, 1355, 1367, 1380, 1392,
> + 1405, 1418, 1431, 1444, 1457, 1470, 1483, 1497, 1510, 1523, 1537, 1551,
> + 1564, 1578, 1592, 1606, 1620, 1634, 1648, 1662, 1677, 1691, 1706, 1720,
> + 1735, 1750, 1765, 1780, 1795, 1810, 1825, 1840, 1855, 1871, 1886, 1902,
> + 1918, 1933, 1949, 1965, 1981, 1997, 2014, 2030, 2046, 2063, 2079, 2096,
> + 2113, 2130, 2146, 2163, 2181, 2198, 2215, 2232, 2250, 2267, 2285, 2303,
> + 2321, 2338, 2356, 2375, 2393, 2411, 2429, 2448, 2466, 2485, 2504, 2523,
> + 2542, 2561, 2580, 2599, 2618, 2638, 2657, 2677, 2697, 2716, 2736, 2756,
> + 2776, 2796, 2817, 2837, 2858, 2878, 2899, 2920, 2941, 2961, 2983, 3004,
> + 3025, 3046, 3068, 3089, 3111, 3133, 3155, 3177, 3199, 3221, 3243, 3266,
> + 3288, 3311, 3333, 3356, 3379, 3402, 3425, 3448, 3472, 3495, 3519, 3542,
> + 3566, 3590, 3614, 3638, 3662, 3686, 3711, 3735, 3760, 3784, 3809, 3834,
> + 3859, 3884, 3910, 3935, 3960, 3986, 4012, 4037, 4063, 4089, 4115, 4142,
> + 4168, 4194, 4221, 4248, 4274, 4301, 4328, 4356, 4383, 4410, 4438, 4465,
> + 4493, 4521, 4549, 4577, 4605, 4633, 4661, 4690, 4719, 4747, 4776, 4805,
> + 4834, 4863, 4893, 4922, 4952, 4981, 5011, 5041, 5071, 5101, 5131, 5162,
> + 5192, 5223, 5254, 5285, 5316, 5347, 5378, 5409, 5441, 5472, 5504, 5536,
> + 5568, 5600, 5632, 5664, 5697, 5729, 5762, 5795, 5828, 5861, 5894, 5928,
> + 5961, 5995, 6028, 6062, 6096, 6130, 6164, 6199, 6233, 6268, 6302, 6337,
> + 6372, 6407, 6442, 6478, 6513, 6549, 6585, 6621, 6657, 6693, 6729, 6765,
> + 6802, 6839, 6875, 6912, 6949, 6986, 7024, 7061, 7099, 7137, 7174, 7212,
> + 7250, 7289, 7327, 7366, 7404, 7443, 7482, 7521, 7560, 7600, 7639, 7679,
> + 7718, 7758, 7798, 7838, 7879, 7919, 7960, 8000, 8041, 8082, 8123, 8165,
> + 8206, 8248, 8289, 8331, 8373, 8415, 8457, 8500, 8542, 8585, 8628, 8671,
> + 8714, 8757, 8800, 8844, 8887, 8931, 8975, 9019, 9064, 9108, 9152, 9197,
> + 9242, 9287, 9332, 9377, 9423, 9468, 9514, 9560, 9606, 9652, 9698, 9745,
> + 9791, 9838, 9885, 9932, 9979, 10026, 10074, 10121, 10169, 10217, 10265,
> + 10313, 10362, 10410, 10459, 10508, 10557, 10606, 10655, 10704, 10754,
> + 10804, 10854, 10904, 10954, 11004, 11055, 11105, 11156, 11207, 11258,
> + 11310, 11361, 11413, 11464, 11516, 11568, 11620, 11673, 11725, 11778,
> + 11831, 11884, 11937, 11990, 12044, 12097, 12151, 12205, 12259, 12314,
> + 12368, 12423, 12477, 12532, 12587, 12643, 12698, 12754, 12809, 12865,
> + 12921, 12977, 13034, 13090, 13147, 13204, 13261, 13318, 13375, 13433,
> + 13491, 13548, 13606, 13665, 13723, 13781, 13840, 13899, 13958, 14017,
> + 14077, 14136, 14196, 14256, 14316, 14376, 14436, 14497, 14557, 14618,
> + 14679, 14740, 14802, 14863, 14925, 14987, 15049, 15111, 15173, 15236,
> + 15299, 15362, 15425, 15488, 15551, 15615, 15679, 15743, 15807, 15871,
> + 15935, 16000, 16065, 16130, 16195, 16260, 16326, 16392, 16457, 16523,
> + 16590, 16656, 16723, 16789, 16856, 16923, 16991, 17058, 17126, 17194,
> + 17261, 17330, 17398, 17467, 17535, 17604, 17673, 17742, 17812, 17881,
> + 17951, 18021, 18091, 18162, 18232, 18303, 18374, 18445, 18516, 18588,
> + 18659, 18731, 18803, 18875, 18947, 19020, 19093, 19166, 19239, 19312,
> + 19385, 19459, 19533, 19607, 19681, 19755, 19830, 19905, 19980, 20055,
> + 20130, 20206, 20281, 20357, 20433, 20510, 20586, 20663, 20740, 20817,
> + 20894, 20971, 21049, 21127, 21205, 21283, 21361, 21440, 21519, 21598,
> + 21677, 21756, 21836, 21915, 21995, 22075, 22156, 22236, 22317, 22398,
> + 22479, 22560, 22642, 22723, 22805, 22887, 22969, 23052, 23135, 23217,
> + 23300, 23384, 23467, 23551, 23635, 23719, 23803, 23887, 23972, 24057,
> + 24142, 24227, 24313, 24398, 24484, 24570, 24656, 24743, 24829, 24916,
> + 25003, 25091, 25178, 25266, 25354, 25442, 25530, 25618, 25707, 25796,
> + 25885, 25974, 26064, 26153, 26243, 26334, 26424, 26514, 26605, 26696,
> + 26787, 26879, 26970, 27062, 27154, 27246, 27338, 27431, 27524, 27617,
> + 27710, 27804, 27897, 27991, 28085, 28179, 28274, 28369, 28463, 28559,
> + 28654, 28749, 28845, 28941, 29037, 29134, 29230, 29327, 29424, 29521,
> + 29619, 29717, 29815, 29913, 30011, 30110, 30208, 30307, 30406, 30506,
> + 30605, 30705, 30805, 30906, 31006, 31107, 31208, 31309, 31410, 31512,
> + 31614, 31716, 31818, 31920, 32023, 32126, 32229, 32332, 32436, 32540,
> + 32644, 32748, 32852, 32957, 33062, 33167, 33272, 33378, 33484, 33590,
> + 33696, 33802, 33909, 34016, 34123, 34230, 34338, 34446, 34554, 34662,
> + 34770, 34879, 34988, 35097, 35206, 35316, 35426, 35536, 35646, 35757,
> + 35867, 35978, 36090, 36201, 36313, 36425, 36537, 36649, 36762, 36874,
> + 36987, 37101, 37214, 37328, 37442, 37556, 37671, 37785, 37900, 38015,
> + 38131, 38246, 38362, 38478, 38594, 38711, 38828, 38945, 39062, 39179,
> + 39297, 39415, 39533, 39651, 39770, 39889, 40008, 40127, 40247, 40367,
> + 40487, 40607, 40728, 40848, 40969, 41091, 41212, 41334, 41456, 41578,
> + 41700, 41823, 41946, 42069, 42193, 42316, 42440, 42564, 42689, 42813,
> + 42938, 43063, 43189, 43314, 43440, 43566, 43692, 43819, 43946, 44073,
> + 44200, 44328, 44456, 44584, 44712, 44840, 44969, 45098, 45227, 45357,
> + 45487, 45617, 45747, 45877, 46008, 46139, 46270, 46402, 46534, 46666,
> + 46798, 46930, 47063, 47196, 47329, 47463, 47596, 47730, 47865, 47999,
> + 48134, 48269, 48404, 48540, 48675, 48811, 48948, 49084, 49221, 49358,
> + 49495, 49633, 49771, 49909, 50047, 50185, 50324, 50463, 50603, 50742,
> + 50882, 51022, 51162, 51303, 51444, 51585, 51726, 51868, 52010, 52152,
> + 52294, 52437, 52580, 52723, 52867, 53010, 53154, 53299, 53443, 53588,
> + 53733, 53878, 54024, 54169, 54315, 54462, 54608, 54755, 54902, 55050,
> + 55197, 55345, 55493, 55642, 55790, 55939, 56089, 56238, 56388, 56538,
> + 56688, 56839, 56989, 57140, 57292, 57443, 57595, 57747, 57900, 58053,
> + 58205, 58359, 58512, 58666, 58820, 58974, 59129, 59284, 59439, 59594,
> + 59750, 59906, 60062, 60218, 60375, 60532, 60689, 60847, 61005, 61163,
> + 61321, 61480, 61639, 61798, 61957, 62117, 62277, 62437, 62598, 62759,
> + 62920, 63081, 63243, 63405, 63567, 63729, 63892, 64055, 64219, 64382,
> + 64546, 64710, 64875, 65039, 65204, 65369, 65535,
> +};
> +
> struct pwm_bl_data {
> struct pwm_device *pwm;
> struct device *dev;
> @@ -38,6 +144,7 @@ struct pwm_bl_data {
> unsigned int scale;
> bool legacy;
> bool piecewise;
> + bool use_lth_table;
Again, I didn't think we'd need to special case the lookup table except
in the probe method. It's "just" a built-in levels table (ideally
reinforced with with code to figure out how many steps to interpolate).
> int (*notify)(struct device *,
> int brightness);
> void (*notify_after)(struct device *,
> @@ -104,6 +211,8 @@ static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
> } else {
> duty_cycle = scale(pb, pb->levels[brightness]);
> }
> + } else if (pb->use_lth_table) {
> + duty_cycle = cie1931_table[brightness];
> } else {
> duty_cycle = scale(pb, brightness);
> }
> @@ -169,9 +278,9 @@ static int pwm_backlight_parse_dt(struct device *dev,
> /* determine the number of brightness levels */
> prop = of_find_property(node, "brightness-levels", &length);
> if (!prop)
> - return -EINVAL;
> -
> - data->levels_count = length / sizeof(u32);
> + data->use_lth_table = true;
> + else
> + data->levels_count = length / sizeof(u32);
>
> /* read brightness levels from DT property */
> if (data->levels_count > 0) {
> @@ -181,24 +290,28 @@ static int pwm_backlight_parse_dt(struct device *dev,
> if (!data->levels)
> return -ENOMEM;
>
> - ret = of_property_read_u32_array(node, "brightness-levels",
> - data->levels,
> - data->levels_count);
> - if (ret < 0)
> - return ret;
> -
> - ret = of_property_read_u32(node, "default-brightness-level",
> - &value);
> - if (ret < 0)
> - return ret;
> + if (prop) {
> + ret = of_property_read_u32_array(node,
> + "brightness-levels",
> + data->levels,
> + data->levels_count);
> + if (ret < 0)
> + return ret;
> + }
>
> data->piecewise = of_property_read_bool(node,
> "use-linear-interpolation");
>
> - data->dft_brightness = value;
> data->levels_count--;
> }
>
> + ret = of_property_read_u32(node, "default-brightness-level",
> + &value);
> + if (ret < 0)
> + return ret;
> +
> + data->dft_brightness = value;
> +
> if (data->piecewise)
> data->max_brightness = data->levels_count * NSTEPS;
> else
> @@ -260,8 +373,10 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct device_node *node = pdev->dev.of_node;
> struct pwm_bl_data *pb;
> + struct pwm_state state;
> struct pwm_args pargs;
> int ret;
> + int i;
>
> if (!data) {
> ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
> @@ -303,6 +418,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->dev = &pdev->dev;
> pb->enabled = false;
> pb->piecewise = data->piecewise;
> + pb->use_lth_table = data->use_lth_table;
>
> pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
> GPIOD_ASIS);
> @@ -361,6 +477,22 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>
> dev_dbg(&pdev->dev, "got pwm for backlight\n");
>
> + if (pb->use_lth_table) {
> + /* Get PWM resolution */
> + pwm_get_state(pb->pwm, &state);
> + if (state.period > 65535) {
> + dev_err(&pdev->dev, "PWM resolution not supported\n");
> + goto err_alloc;
> + }
> + /* Find the number of steps based on the PWM resolution */
> + for (i = 0; i < ARRAY_SIZE(cie1931_table); i++)
> + if (cie1931_table[i] >= state.period) {
> + data->max_brightness = i;
> + break;
> + }
> + pb->scale = data->max_brightness;
> + }
> +
> /*
> * FIXME: pwm_apply_args() should be removed when switching to
> * the atomic PWM API.
> diff --git a/include/linux/pwm_backlight.h b/include/linux/pwm_backlight.h
> index 444a91b..4ec3b0d 100644
> --- a/include/linux/pwm_backlight.h
> +++ b/include/linux/pwm_backlight.h
> @@ -15,6 +15,7 @@ struct platform_pwm_backlight_data {
> unsigned int pwm_period_ns;
> unsigned int *levels;
> unsigned int levels_count;
> + bool use_lth_table;
Why not just "if (!levels)"?
> bool piecewise;
> /* TODO remove once all users are switched to gpiod_* API */
> int enable_gpio;
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 5/5] ARM: dts: iwg20d-q7-common: Sound DMA support via DVC on DTS
From: Biju Das @ 2017-12-15 14:50 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Kuninori Morimoto, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree, linux-renesas-soc, Biju Das
In-Reply-To: <1513349453-54689-1-git-send-email-biju.das@bp.renesas.com>
DMA transfer uses DVC
DMA DMApp
[MEM] -> [SRC] -> [DVC] -> [SSIU] -> [SSI]
DMA DMApp
[MEM] <- [DVC] <- [SRC] <- [SSIU] <- [SSI]
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 9f6ec25..ccbdf5a 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -8,6 +8,29 @@
* kind, whether express or implied.
*/
+/*
+ * SSI-SGTL5000
+ *
+ * This command is required when Playback/Capture
+ *
+ * amixer set "DVC Out" 100%
+ * amixer set "DVC In" 100%
+ *
+ * You can use Mute
+ *
+ * amixer set "DVC Out Mute" on
+ * amixer set "DVC In Mute" on
+ *
+ * You can use Volume Ramp
+ *
+ * amixer set "DVC Out Ramp Up Rate" "0.125 dB/64 steps"
+ * amixer set "DVC Out Ramp Down Rate" "0.125 dB/512 steps"
+ * amixer set "DVC Out Ramp" on
+ * aplay xxx.wav &
+ * amixer set "DVC Out" 80% // Volume Down
+ * amixer set "DVC Out" 100% // Volume Up
+ */
+
/ {
aliases {
serial0 = &scif0;
@@ -240,8 +263,8 @@
rcar_sound,dai {
dai0 {
- playback = <&ssi1 &src3>;
- capture = <&ssi0 &src2>;
+ playback = <&ssi1 &src3 &dvc1>;
+ capture = <&ssi0 &src2 &dvc0>;
};
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: iwg20d-q7-common: Sound DMA support via SRC on DTS
From: Biju Das @ 2017-12-15 14:50 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Kuninori Morimoto, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree, linux-renesas-soc, Biju Das
In-Reply-To: <1513349453-54689-1-git-send-email-biju.das@bp.renesas.com>
DMA transfer to/from SRC
DMA DMApp
[MEM] -> [SRC] -> [SSIU] -> [SSI]
DMA DMApp
[MEM] <- [SRC] <- [SSIU] <- [SSI]
Current sound driver is supporting SSI/SRC random connection.
So, this patch is trying
SSI1 -> SRC3
SSI0 <- SRC2
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 38f1e2b..9f6ec25 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -240,8 +240,8 @@
rcar_sound,dai {
dai0 {
- playback = <&ssi1>;
- capture = <&ssi0>;
+ playback = <&ssi1 &src3>;
+ capture = <&ssi0 &src2>;
};
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: iwg20d-q7-common: Sound DMA support via BUSIF on DTS
From: Biju Das @ 2017-12-15 14:50 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Kuninori Morimoto, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree, linux-renesas-soc, Biju Das
In-Reply-To: <1513349453-54689-1-git-send-email-biju.das@bp.renesas.com>
DMA transfer to/from SSIU
DMA
[MEM] -> [SSIU] -> [SSI]
DMA
[MEM] <- [SSIU] <- [SSI]
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index fd50065..38f1e2b 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -246,11 +246,6 @@
};
};
-&ssi0 {
- no-busif;
-};
-
&ssi1 {
- no-busif;
shared-pin;
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: iwg20d-q7-common: Sound DMA support on DTS
From: Biju Das @ 2017-12-15 14:50 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Kuninori Morimoto, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Biju Das
In-Reply-To: <1513349453-54689-1-git-send-email-biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
DMA transfer to/from SSI
DMA
[MEM] -> [SSI]
DMA
[MEM] <- [SSI]
Signed-off-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Reviewed-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 41bc4ed..fd50065 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -247,10 +247,10 @@
};
&ssi0 {
- pio-transfer;
+ no-busif;
};
&ssi1 {
- pio-transfer;
+ no-busif;
shared-pin;
};
--
1.9.1
--
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
* [PATCH 1/5] ARM: dts: iwg20d-q7-common: Sound PIO support
From: Biju Das @ 2017-12-15 14:50 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Kuninori Morimoto, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Biju Das
In-Reply-To: <1513349453-54689-1-git-send-email-biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Enable sound PIO support on carrier board.
Signed-off-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Reviewed-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 46 +++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 2070b14..41bc4ed 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -34,6 +34,22 @@
regulator-always-on;
};
+ rsnd_sgtl5000: sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&sndcodec>;
+ simple-audio-card,frame-master = <&sndcodec>;
+
+ sndcpu: simple-audio-card,cpu {
+ sound-dai = <&rcar_sound>;
+ };
+
+ sndcodec: simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ };
+ };
+
vcc_sdhi1: regulator-vcc-sdhi1 {
compatible = "regulator-fixed";
@@ -166,6 +182,11 @@
power-source = <1800>;
};
+ sound_pins: sound {
+ groups = "ssi0129_ctrl", "ssi0_data", "ssi1_data";
+ function = "ssi";
+ };
+
usb0_pins: usb0 {
groups = "usb0";
function = "usb0";
@@ -208,3 +229,28 @@
&usbphy {
status = "okay";
};
+
+&rcar_sound {
+ pinctrl-0 = <&sound_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /* Single DAI */
+ #sound-dai-cells = <0>;
+
+ rcar_sound,dai {
+ dai0 {
+ playback = <&ssi1>;
+ capture = <&ssi0>;
+ };
+ };
+};
+
+&ssi0 {
+ pio-transfer;
+};
+
+&ssi1 {
+ pio-transfer;
+ shared-pin;
+};
--
1.9.1
--
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
* [PATCH 0/5] Add sound support
From: Biju Das @ 2017-12-15 14:50 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Simon Horman, Kuninori Morimoto, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Biju Das
This series aims to add sound support for iWave RZ/G1M board.
This patch series has below dependencies
1) https://www.spinics.net/lists/arm-kernel/msg622754.html
2) https://patchwork.kernel.org/patch/10108041/
Biju Das (5):
ARM: dts: iwg20d-q7-common: Sound PIO support
ARM: dts: iwg20d-q7-common: Sound DMA support on DTS
ARM: dts: iwg20d-q7-common: Sound DMA support via BUSIF on DTS
ARM: dts: iwg20d-q7-common: Sound DMA support via SRC on DTS
ARM: dts: iwg20d-q7-common: Sound DMA support via DVC on DTS
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 64 +++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
--
1.9.1
--
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 v12 1/3] ACPI/IORT: Add msi address regions reservation helper
From: Marc Zyngier @ 2017-12-15 14:49 UTC (permalink / raw)
To: Shameer Kolothum
Cc: lorenzo.pieralisi, robin.murphy, will.deacon, joro, john.garry,
xuwei5, guohanjun, iommu, linux-arm-kernel, linux-acpi,
devicetree, linuxarm
In-Reply-To: <20171214160957.13716-2-shameerali.kolothum.thodi@huawei.com>
On Thu, 14 Dec 2017 16:09:55 +0000,
Shameer Kolothum wrote:
>
> On some platforms msi parent address regions have to be excluded from
> normal IOVA allocation in that they are detected and decoded in a HW
> specific way by system components and so they cannot be considered normal
> IOVA address space.
>
> Add a helper function that retrieves ITS address regions - the msi
> parent - through IORT device <-> ITS mappings and reserves it so that
> these regions will not be translated by IOMMU and will be excluded from
> IOVA allocations. The function checks for the smmu model number and
> only applies the msi reservation if the platform requires it.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> drivers/acpi/arm64/iort.c | 111 +++++++++++++++++++++++++++++++++++++--
> drivers/irqchip/irq-gic-v3-its.c | 3 +-
> include/linux/acpi_iort.h | 7 ++-
> 3 files changed, 116 insertions(+), 5 deletions(-)
For the ITS part:
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ permalink raw reply
* Re: [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller
From: Neil Armstrong @ 2017-12-15 14:48 UTC (permalink / raw)
To: Yixun Lan, Kevin Hilman, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Jerome Brunet, Rob Herring, Mark Rutland, Carlo Caione, Sunny Luo,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215144217.223593-1-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
On 15/12/2017 15:42, Yixun Lan wrote:
> From: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> Add DT info for the SPICC controller which found in
> the Amlogic's Meson-AXG SoC.
>
> Signed-off-by: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> ---
> Changes int v2 since [1]
> - rebase to Kevin's tree, branch v4.16/dt64
> - this patch depend on clock & pinctrl DT patch
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005495.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 93 ++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index d356ce74ad89..d33721005748 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
>
> / {
> compatible = "amlogic,meson-axg";
> @@ -120,6 +121,28 @@
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
>
> + spicc0: spi@13000 {
> + compatible = "amlogic,meson-axg-spicc";
> + reg = <0x0 0x13000 0x0 0x3c>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc CLKID_SPICC0>;
> + clock-names = "core";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
[...]
> +
> + spi1_ss0_x_pins: spi1_ss0_x {
> + mux {
> + groups = "spi1_ss0_x";
> + function = "spi1";
> + };
> + };
> };
> };
>
>
Reviewed-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@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
* Re: [PATCH v2 0/3] ARM: sun8i: a83t: Add support for I2S and I2C
From: Maxime Ripard @ 2017-12-15 14:43 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171214042350.29469-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Thu, Dec 14, 2017 at 12:23:47PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v2 of my A83T I2S and I2C support series.
>
> Changes since v1:
>
> - Dropped ASoC patch that was merged
> - Added SoC-specific compatible strings for I2C controllers
> - Added Maxime's Acked-by
>
> This series adds support for I2S and I2C on the Allwinner A83T SoC.
> The I2S controllers are similar to the ones found on the A31. However
> the TX FIFO and interrupt status registers were swapped around. This
> seems to be a recurring theme for the audio related hardware blocks.
>
> Patch 1 adds device nodes and default pinmux settings for the I2S
> controllers.
>
> Patch 2 adds device nodes and default pinmux settings for the I2C
> controllers.
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Philippe Ombredanne @ 2017-12-15 14:42 UTC (permalink / raw)
To: Heiko Stübner
Cc: Mark Rutland, Emil Renner Berthing, Huibin Hong, Catalin Marinas,
Linus Walleij, Will Deacon, Kever Yang, LKML, Klaus Goger,
Joseph Chen, Romain Perier, Matthias Kaehlcke, Sugar Zhang,
Simon Xue, Heinrich Schuchardt, Brian Norris, Russell King,
Jaehoon Chung, linux-rockchip, Chen-Yu Tsai, Jacob Chen,
Jianqun Xu, Shawn Lin
In-Reply-To: <21020918.S4038j3A1a@diego>
On Fri, Dec 15, 2017 at 3:28 PM, Heiko Stübner <heiko@sntech.de> wrote:
> Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
>> Klaus,
>>
>> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
>>
>> <klaus.goger@theobroma-systems.com> wrote:
>> > This patch series replaces all the license text in rockchip devicetree
>> > files text with a proper SPDX-License-Identifier.
>> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
>> > yet merged.
>> >
>> > These series also fixes the issue with contradicting statements in most
>> > licenses. The introduction text claims to be GPL or X11[2] but the
>> > following verbatim copy of the license is actually a MIT[3] license.
>> > The X11 license includes a advertise clause and trademark information
>> > related to the X Consortium. As these X Consortium specfic points are
>> > irrelevant for us we stick with the actuall license text.
>> >
>> > [1] https://patchwork.kernel.org/patch/10091607/
>> > [2] https://spdx.org/licenses/X11.html
>> > [3] https://spdx.org/licenses/MIT.html
>>
>> FWIW, the X11 license name was not always something clearly defined.
>> SPDX calls it clearly MIT which is the most widely accepted name for
>> the corresponding text. And this is also what we have in Thomas doc
>> patches that should be the kernel reference.
>>
>> Also, as a general note, you want to make sure that such as patch set
>> is not merged by mistake until you have collected an explicit review
>> or ack from all the copyright holders involved.
>
> Just for my understanding, is it really necessary to get Acks from _all_
> previous contributors?
>
> I see that Thomas patches moving license texts into the kernel itself do not
> seem to have landed yet, but when the actual license text does _not_ change
> and only its location to a common place inside the kernel sources, it feels
> a bit overkill trying to get Acks from _everybody_ that contributed to
> Rockchip devicetrees for the last 4 years.
>
> If we would actually want to change the license I would definitly feel
> differently, but the license text does not change.
Well you are technically right. But there is a social and politeness
angle to this too. So may be getting the ack of all contributors is
not always needed, but getting it is best and the right to do and at
least getting for the named copyright holders should be there.
That's only only my take: leaving aside any technical legal issue, say
I would be on the receiving end as one of the holder or contributors:
I would find it really great and nice to have my ack requested. And I
would be a dork not to give it. So I like to do to others the same I
would appreciate done to me (within reason, as I sometimes shoot
myself in the foot ;) )
--
Cordially
Philippe Ombredanne
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller
From: Yixun Lan @ 2017-12-15 14:42 UTC (permalink / raw)
To: Kevin Hilman, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Neil Armstrong, Jerome Brunet, Rob Herring, Mark Rutland,
Carlo Caione, Yixun Lan, Sunny Luo,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
Add DT info for the SPICC controller which found in
the Amlogic's Meson-AXG SoC.
Signed-off-by: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
---
Changes int v2 since [1]
- rebase to Kevin's tree, branch v4.16/dt64
- this patch depend on clock & pinctrl DT patch
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005495.html
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 93 ++++++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d356ce74ad89..d33721005748 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -120,6 +121,28 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
+ spicc0: spi@13000 {
+ compatible = "amlogic,meson-axg-spicc";
+ reg = <0x0 0x13000 0x0 0x3c>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc CLKID_SPICC0>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spicc1: spi@15000 {
+ compatible = "amlogic,meson-axg-spicc";
+ reg = <0x0 0x15000 0x0 0x3c>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc CLKID_SPICC1>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
uart_A: serial@24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -194,6 +217,76 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+
+ spi0_pins: spi0 {
+ mux {
+ groups = "spi0_miso",
+ "spi0_mosi",
+ "spi0_clk";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss0_pins: spi0_ss0 {
+ mux {
+ groups = "spi0_ss0";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss1_pins: spi0_ss1 {
+ mux {
+ groups = "spi0_ss1";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss2_pins: spi0_ss2 {
+ mux {
+ groups = "spi0_ss2";
+ function = "spi0";
+ };
+ };
+
+
+ spi1_a_pins: spi1_a {
+ mux {
+ groups = "spi1_miso_a",
+ "spi1_mosi_a",
+ "spi1_clk_a";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss0_a_pins: spi1_ss0_a {
+ mux {
+ groups = "spi1_ss0_a";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss1_pins: spi1_ss1 {
+ mux {
+ groups = "spi1_ss1";
+ function = "spi1";
+ };
+ };
+
+ spi1_x_pins: spi1_x {
+ mux {
+ groups = "spi1_miso_x",
+ "spi1_mosi_x",
+ "spi1_clk_x";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss0_x_pins: spi1_ss0_x {
+ mux {
+ groups = "spi1_ss0_x";
+ function = "spi1";
+ };
+ };
};
};
--
2.15.1
--
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
* Re: [RFC v2 1/2] backlight: pwm_bl: linear interpolation between values of brightness-levels
From: Daniel Thompson @ 2017-12-15 14:40 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Jingoo Han, Richard Purdie, Jacek Anaszewski, Pavel Machek,
Rob Herring, Doug Anderson, Brian Norris, Guenter Roeck,
Lee Jones, Alexandru Stan, linux-leds, devicetree, linux-kernel
In-Reply-To: <20171116141151.21171-2-enric.balletbo@collabora.com>
On Thu, Nov 16, 2017 at 03:11:50PM +0100, Enric Balletbo i Serra wrote:
>
> Setting use-linear-interpolation in the dts will allow you to have linear
> interpolation between values of brightness-levels.
>
> There are now 256 between each of the values of brightness-levels. If
> something is requested halfway between 2 values, we'll use linear
> interpolation.
Why 256?
>
> This way a high resolution pwm duty cycle can be used without having to
> list out every possible value in the dts. This system also allows for
> gamma corrected values (eg: "brightness-levels = <0 2 4 8 16 32>;").
>
> Patch based on the Alexandru M Stan work done for ChromeOS kernels.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> .../bindings/leds/backlight/pwm-backlight.txt | 2 +
> drivers/video/backlight/pwm_bl.c | 55 +++++++++++++++++-----
> include/linux/pwm_backlight.h | 2 +
> 3 files changed, 47 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> index 764db86..7c48f20 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> @@ -17,6 +17,8 @@ Optional properties:
> "pwms" property (see PWM binding[0])
> - enable-gpios: contains a single GPIO specifier for the GPIO which enables
> and disables the backlight (see GPIO binding[1])
> + - use-linear-interpolation: set this propriety to enable linear interpolation
> + between each of the values of brightness-levels.
Deciding whether or not this deployment of interpolation is a property
of the hardware is a finely balanced judgement. On the whole I conclude
that since the lookup table is a property of the hardware so too is the
deployment of interpolation.
Following up on the "why 256?" comment. IMHO either the number of
interpolated steps should be calculated from the underlying PWM
resolution or it could simply be specified in the DT (e.g. replace
use-linear-interpolation with num-interpolated-steps).
> [0]: Documentation/devicetree/bindings/pwm/pwm.txt
> [1]: Documentation/devicetree/bindings/gpio/gpio.txt
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 9bd1768..59b1bfb 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -24,6 +24,8 @@
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
>
> +#define NSTEPS 256
> +
> struct pwm_bl_data {
> struct pwm_device *pwm;
> struct device *dev;
> @@ -35,6 +37,7 @@ struct pwm_bl_data {
> struct gpio_desc *enable_gpio;
> unsigned int scale;
> bool legacy;
> + bool piecewise;
> int (*notify)(struct device *,
> int brightness);
> void (*notify_after)(struct device *,
> @@ -76,17 +79,36 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> pb->enabled = false;
> }
>
> -static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
> +static int scale(struct pwm_bl_data *pb, int x)
> {
> unsigned int lth = pb->lth_brightness;
> +
> + return (x * (pb->period - lth) / pb->scale) + lth;
> +}
> +
> +static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
> +{
> + int coarse = brightness / NSTEPS;
> + int fine = brightness % NSTEPS;
> int duty_cycle;
>
> - if (pb->levels)
> - duty_cycle = pb->levels[brightness];
> - else
> - duty_cycle = brightness;
> + if (pb->levels) {
> + if (pb->piecewise) {
> + duty_cycle = scale(pb, pb->levels[coarse]);
> + if (fine > 0)
> + duty_cycle += (scale(pb, pb->levels[coarse + 1])
> + - scale(pb, pb->levels[coarse]))
> + * fine / NSTEPS;
> + dev_dbg(pb->dev, "brightness=%d coarse=%d fine=%d\n",
> + brightness, coarse, fine);
> + } else {
> + duty_cycle = scale(pb, pb->levels[brightness]);
> + }
> + } else {
> + duty_cycle = scale(pb, brightness);
> + }
>
> - return (duty_cycle * (pb->period - lth) / pb->scale) + lth;
> + return duty_cycle;
> }
>
> static int pwm_backlight_update_status(struct backlight_device *bl)
> @@ -149,11 +171,11 @@ static int pwm_backlight_parse_dt(struct device *dev,
> if (!prop)
> return -EINVAL;
>
> - data->max_brightness = length / sizeof(u32);
> + data->levels_count = length / sizeof(u32);
>
> /* read brightness levels from DT property */
> - if (data->max_brightness > 0) {
> - size_t size = sizeof(*data->levels) * data->max_brightness;
> + if (data->levels_count > 0) {
> + size_t size = sizeof(*data->levels) * data->levels_count;
>
> data->levels = devm_kzalloc(dev, size, GFP_KERNEL);
> if (!data->levels)
> @@ -161,7 +183,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
>
> ret = of_property_read_u32_array(node, "brightness-levels",
> data->levels,
> - data->max_brightness);
> + data->levels_count);
> if (ret < 0)
> return ret;
>
> @@ -170,10 +192,18 @@ static int pwm_backlight_parse_dt(struct device *dev,
> if (ret < 0)
> return ret;
>
> + data->piecewise = of_property_read_bool(node,
> + "use-linear-interpolation");
> +
> data->dft_brightness = value;
> - data->max_brightness--;
> + data->levels_count--;
> }
>
> + if (data->piecewise)
> + data->max_brightness = data->levels_count * NSTEPS;
> + else
> + data->max_brightness = data->levels_count;
I think we lost a -1 here?
Daniel.
^ permalink raw reply
* Re: [PATCH v2 2/5] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Heiko Stübner @ 2017-12-15 14:35 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: MyungJoo Ham, Chanwoo Choi, Lee Jones, Rob Herring,
dianders-hpIqsD4AKlfQT0dZR+AlfA, groeck-F7+t8E8rja9g9hUCZPvPmw,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171213103219.1464-2-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Am Mittwoch, 13. Dezember 2017, 11:32:16 CET schrieb Enric Balletbo i Serra:
> Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Just for people reading along, with the extcon driver-patch applied,
Enric sent a slightly fixed devicetree series, so we're moving to the v3
patches and ignoring the v2 dts from this series.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Rafael J. Wysocki @ 2017-12-15 14:29 UTC (permalink / raw)
To: Dave Gerlach
Cc: Viresh Kumar, Rob Herring, Rafael J . Wysocki, linux-arm-kernel,
Linux OMAP Mailing List, Linux PM, devicetree@vger.kernel.org,
Tony Lindgren, Nishanth Menon
In-Reply-To: <20171215042528.28715-4-d-gerlach@ti.com>
On Fri, Dec 15, 2017 at 5:25 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Document the devicetree bindings that describe Texas Instruments
> opp-supply which allow a platform to describe multiple regulators and
> additional information, such as registers containing data needed to
> program aforementioned regulators.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
I need an ACK from Rob on this one.
> ---
> .../bindings/opp/ti-omap5-opp-supply.txt | 63 ++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
>
> diff --git a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
> new file mode 100644
> index 000000000000..832346e489a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
> @@ -0,0 +1,63 @@
> +Texas Instruments OMAP compatible OPP supply description
> +
> +OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which
> +contain data that can be used to adjust voltages programmed for some of their
> +supplies for more efficient operation. This binding provides the information
> +needed to read these values and use them to program the main regulator during
> +an OPP transitions.
> +
> +Also, some supplies may have an associated vbb-supply which is an Adaptive Body
> +Bias regulator which much be transitioned in a specific sequence with regards
> +to the vdd-supply and clk when making an OPP transition. By supplying two
> +regulators to the device that will undergo OPP transitions we can make use
> +of the multi regulator binding that is part of the OPP core described here [1]
> +to describe both regulators needed by the platform.
> +
> +[1] Documentation/devicetree/bindings/opp/opp.txt
> +
> +Required Properties for Device Node:
> +- vdd-supply: phandle to regulator controlling VDD supply
> +- vbb-supply: phandle to regulator controlling Body Bias supply
> + (Usually Adaptive Body Bias regulator)
> +
> +Required Properties for opp-supply node:
> +- compatible: Should be one of:
> + "ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB
> + "ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD
> + along with VBB
> + "ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD
> + but no VBB.
> +- reg: Address and length of the efuse register set for the device (mandatory
> + only for "ti,omap5-opp-supply")
> +- ti,efuse-settings: An array of u32 tuple items providing information about
> + optimized efuse configuration. Each item consists of the following:
> + volt: voltage in uV - reference voltage (OPP voltage)
> + efuse_offseet: efuse offset from reg where the optimized voltage is stored.
> +- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.
> +
> +Example:
> +
> +/* Device Node (CPU) */
> +cpus {
> + cpu0: cpu@0 {
> + device_type = "cpu";
> +
> + ...
> +
> + vdd-supply = <&vcc>;
> + vbb-supply = <&abb_mpu>;
> + };
> +};
> +
> +/* OMAP OPP Supply with Class0 registers */
> +opp_supply_mpu: opp_supply@4a003b20 {
> + compatible = "ti,omap5-opp-supply";
> + reg = <0x4a003b20 0x8>;
> + ti,efuse-settings = <
> + /* uV offset */
> + 1060000 0x0
> + 1160000 0x4
> + 1210000 0x8
> + >;
> + ti,absolute-max-voltage-uv = <1500000>;
> +};
> --
> 2.15.1
>
^ permalink raw reply
* Re: [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stübner @ 2017-12-15 14:28 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Mark Rutland, Emil Renner Berthing, Huibin Hong, Catalin Marinas,
Linus Walleij, Will Deacon, Kever Yang, LKML, Klaus Goger,
Joseph Chen, Romain Perier, Matthias Kaehlcke, Sugar Zhang,
Simon Xue, Heinrich Schuchardt, Brian Norris, Russell King,
Jaehoon Chung, linux-rockchip, Chen-Yu Tsai, Jacob Chen,
Jianqun Xu, Shawn Lin
In-Reply-To: <CAOFm3uHba4kBD81thpxSpDBsDS4Y5m7cN2jfYt_uT5atdSDmqg@mail.gmail.com>
Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
> Klaus,
>
> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
>
> <klaus.goger@theobroma-systems.com> wrote:
> > This patch series replaces all the license text in rockchip devicetree
> > files text with a proper SPDX-License-Identifier.
> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
> > yet merged.
> >
> > These series also fixes the issue with contradicting statements in most
> > licenses. The introduction text claims to be GPL or X11[2] but the
> > following verbatim copy of the license is actually a MIT[3] license.
> > The X11 license includes a advertise clause and trademark information
> > related to the X Consortium. As these X Consortium specfic points are
> > irrelevant for us we stick with the actuall license text.
> >
> > [1] https://patchwork.kernel.org/patch/10091607/
> > [2] https://spdx.org/licenses/X11.html
> > [3] https://spdx.org/licenses/MIT.html
>
> FWIW, the X11 license name was not always something clearly defined.
> SPDX calls it clearly MIT which is the most widely accepted name for
> the corresponding text. And this is also what we have in Thomas doc
> patches that should be the kernel reference.
>
> Also, as a general note, you want to make sure that such as patch set
> is not merged by mistake until you have collected an explicit review
> or ack from all the copyright holders involved.
Just for my understanding, is it really necessary to get Acks from _all_
previous contributors?
I see that Thomas patches moving license texts into the kernel itself do not
seem to have landed yet, but when the actual license text does _not_ change
and only its location to a common place inside the kernel sources, it feels
a bit overkill trying to get Acks from _everybody_ that contributed to
Rockchip devicetrees for the last 4 years.
If we would actually want to change the license I would definitly feel
differently, but the license text does not change.
Thanks
Heiko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox