* [PATCH -next] hwrng: st - Fix missing clk_disable_unprepare() on error in st_rng_probe()
From: Patrice Chotard @ 2016-09-12 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473509022-3478-1-git-send-email-weiyj.lk@gmail.com>
Hi Wey
On 09/10/2016 02:03 PM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix the missing clk_disable_unprepare() before return
> from st_rng_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/char/hw_random/st-rng.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
> index 7e8aa6b..938ec10 100644
> --- a/drivers/char/hw_random/st-rng.c
> +++ b/drivers/char/hw_random/st-rng.c
> @@ -108,6 +108,7 @@ static int st_rng_probe(struct platform_device *pdev)
> ret = hwrng_register(&ddata->ops);
> if (ret) {
> dev_err(&pdev->dev, "Failed to register HW RNG\n");
> + clk_disable_unprepare(clk);
> return ret;
> }
>
>
>
>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply
* [PATCH 08/10] PM / Domains: Add support for removing PM domains
From: Jon Hunter @ 2016-09-12 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFp+eDBLge40uv6aDuYOkaKAksgqZekqomLZijPrhDzj6A@mail.gmail.com>
On 12/09/16 08:21, Ulf Hansson wrote:
> On 9 September 2016 at 17:17, Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>> On 09/09/16 14:54, Jon Hunter wrote:
>>> On 08/09/16 12:49, Ulf Hansson wrote:
>>>> On 16 August 2016 at 11:49, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>> The genpd framework allows users to add PM domains via the pm_genpd_init()
>>>>> function, however, there is no corresponding function to remove a PM
>>>>> domain. For most devices this may be fine as the PM domains are never
>>>>> removed, however, for devices that wish to populate the PM domains from
>>>>> within a driver, having the ability to remove a PM domain if the probing
>>>>> of the device fails or the driver is unloaded is necessary.
>>>>>
>>>>> Add the function pm_genpd_remove() to remove a PM domain by referencing
>>>>> it's generic_pm_domain structure.
>>>>>
>>>>> PM domains can only be removed if they are not a parent domain to
>>>>> another PM domain and have no devices associated with them.
>>>>
>>>> I think we should also check if the there's is a provider registered
>>>> for the genpd, as it should also prevent the genpd from being removed.
>>>> Right?
>>>
>>> Yes I would agree. I had thought that after patch #4 of this series that
>>> only the provider itself would be able to call this. However, we should
>>> probably still verify that the provider has correctly remove itself.
>>
>> So now I have the following. I am still not 100% happy. I cannot clear
>> the ->provider when calling of_genpd_del_provider() and so I cannot use
>> this to verify if the provider is present and so I need to check the
>> list of providers and it gets a bit messy. I have been wracking my
>> brains to find a better alternative (including a single function to
>> remove the provider and domains at once but there are issues with that
>> as well).
>
> Instead of using the ->provider pointer to know whether the genpd has
> a valid provider, why not just add an additional ->has_provider bool
> flag in the genpd struct?
>
> Simply set the flag when adding the provider and reset it when
> removing it. Wouldn't that work?
Yes. I was trying not to add to much clutter to the struct. However, may
be this is the best option.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v7 0/8] CPUs capacity information for heterogeneous systems
From: Juri Lelli @ 2016-09-12 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473085372-2840-1-git-send-email-juri.lelli@arm.com>
Hi,
this is a ping for people interested in this series. Patches 2,4,7-8
still needs ACKs.
I know it's only been a week since I posted v7, but this series would
pair nicely with asym cpu capacity support bits already sitting in
tip/sched/core. I also know that it might be already late for 4.9 merge
window; nevertheless, still hoping we can make it.
Thanks!
Best,
- Juri
On 05/09/16 15:22, Juri Lelli wrote:
> Hi all,
>
> version 7 of "CPUs capacity information for heterogeneous systems" patchset [1]
> (please refer to previous postings to get some context).
>
> A few changes from v6:
>
> - rebase on top of mainline (4.8-rc5)
> - some ACKs collected
> - changelogs fixes
> - use cpuinfo.max_freq
> - add delayed work to unregister notifier
>
> Patches high level description:
>
> o 01/08 introduces documentation for the new optional DT binding
> o [02-06]/08 add cpu-capacity attribute to TC2, Juno and Juno r2 DTs and
> provide parsing of such information at boot time
> o [07-08]/08 introduce sysfs attribute
>
> In case you would like to test this out, I pushed a branch here:
>
> git://linux-arm.org/linux-jl.git upstream/default_caps_v7
>
> This branch contains additional patches, useful to better understand how CPU
> capacity information is actually used by the scheduler.
>
> These patches also form the basis for Morten/Dietmar's "Clean-ups and
> asymmetric cpu capacity support" series [2] (and the EAS stack in general).
>
> Best,
>
> - Juri
>
> [1] v1 - https://lkml.org/lkml/2015/11/23/391
> v2 - https://lkml.org/lkml/2016/1/8/417
> v3 - https://lkml.org/lkml/2016/2/3/405
> v4 - https://lkml.org/lkml/2016/3/18/350
> v5 - https://lkml.org/lkml/2016/6/15/291
> v6 - https://lkml.org/lkml/2016/7/19/419
> [2] https://lkml.org/lkml/2016/8/31/292
>
>
> Juri Lelli (8):
> Documentation: arm: define DT cpu capacity-dmips-mhz bindings
> arm: parse cpu capacity-dmips-mhz from DT
> arm, dts: add TC2 cpu capacity-dmips-mhz information
> arm64: parse cpu capacity-dmips-mhz from DT
> arm64, dts: add Juno cpu capacity-dmips-mhz information
> arm64, dts: add Juno r2 cpu capacity-dmips-mhz information
> arm: add sysfs cpu_capacity attribute
> arm64: add sysfs cpu_capacity attribute
>
> .../devicetree/bindings/arm/cpu-capacity.txt | 236 +++++++++++++++++++++
> Documentation/devicetree/bindings/arm/cpus.txt | 10 +
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 5 +
> arch/arm/kernel/topology.c | 228 +++++++++++++++++++-
> arch/arm64/boot/dts/arm/juno-r2.dts | 6 +
> arch/arm64/boot/dts/arm/juno.dts | 6 +
> arch/arm64/kernel/topology.c | 232 +++++++++++++++++++-
> 7 files changed, 721 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/cpu-capacity.txt
>
> --
> 2.7.0
>
^ permalink raw reply
* [PATCH 08/10] PM / Domains: Add support for removing PM domains
From: Ulf Hansson @ 2016-09-12 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63871fe6-cda6-2a95-9c09-e4b3ebfa3419@nvidia.com>
On 9 September 2016 at 17:17, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 09/09/16 14:54, Jon Hunter wrote:
>> On 08/09/16 12:49, Ulf Hansson wrote:
>>> On 16 August 2016 at 11:49, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>> The genpd framework allows users to add PM domains via the pm_genpd_init()
>>>> function, however, there is no corresponding function to remove a PM
>>>> domain. For most devices this may be fine as the PM domains are never
>>>> removed, however, for devices that wish to populate the PM domains from
>>>> within a driver, having the ability to remove a PM domain if the probing
>>>> of the device fails or the driver is unloaded is necessary.
>>>>
>>>> Add the function pm_genpd_remove() to remove a PM domain by referencing
>>>> it's generic_pm_domain structure.
>>>>
>>>> PM domains can only be removed if they are not a parent domain to
>>>> another PM domain and have no devices associated with them.
>>>
>>> I think we should also check if the there's is a provider registered
>>> for the genpd, as it should also prevent the genpd from being removed.
>>> Right?
>>
>> Yes I would agree. I had thought that after patch #4 of this series that
>> only the provider itself would be able to call this. However, we should
>> probably still verify that the provider has correctly remove itself.
>
> So now I have the following. I am still not 100% happy. I cannot clear
> the ->provider when calling of_genpd_del_provider() and so I cannot use
> this to verify if the provider is present and so I need to check the
> list of providers and it gets a bit messy. I have been wracking my
> brains to find a better alternative (including a single function to
> remove the provider and domains at once but there are issues with that
> as well).
Instead of using the ->provider pointer to know whether the genpd has
a valid provider, why not just add an additional ->has_provider bool
flag in the genpd struct?
Simply set the flag when adding the provider and reset it when
removing it. Wouldn't that work?
>
> I think that long term it may make sense to reference the providers
> exclusively by the fwnode_handle and make the list of provider non-DT
> specific. I could do it now, but it would increase the series.
Perhaps a good idea. Although I agree, let's not make that change as a
part of this series.
[...]
Kind regards
Uffe
^ permalink raw reply
* [PATCH v4 2/3] arm64: dts: Add ZTE ZX296718 SoC dts and Makefile
From: Jun Nie @ 2016-09-12 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908091103.GA16924@tiger>
2016-09-08 17:11 GMT+08:00 Shawn Guo <shawnguo@kernel.org>:
> This version looks pretty good to me. Some nit-picks below though ...
>
> On Tue, Sep 06, 2016 at 02:04:20PM +0800, Jun Nie wrote:
>> Add device tree support for ZX296718 SoC and evaluation board based on it.
>
> Please wrap the commit log around column 70.
>
>> Also document new values.
>>
>> Signed-off-by: Jun Nie <jun.nie@linaro.org>
>> ---
>> Documentation/devicetree/bindings/arm/zte.txt | 24 +++
>> arch/arm64/boot/dts/Makefile | 1 +
>> arch/arm64/boot/dts/zte/Makefile | 5 +
>> arch/arm64/boot/dts/zte/zx296718-evb.dts | 25 +++
>> arch/arm64/boot/dts/zte/zx296718.dtsi | 254 ++++++++++++++++++++++++++
>> 5 files changed, 309 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/zte/Makefile
>> create mode 100644 arch/arm64/boot/dts/zte/zx296718-evb.dts
>> create mode 100644 arch/arm64/boot/dts/zte/zx296718.dtsi
>
> <snip>
>
>> diff --git a/arch/arm64/boot/dts/zte/Makefile b/arch/arm64/boot/dts/zte/Makefile
>> new file mode 100644
>> index 0000000..6678066
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/zte/Makefile
>> @@ -0,0 +1,5 @@
>> +dtb-$(CONFIG_ARCH_ZX) += zx296718-evb.dtb
>> +
>> +always := $(dtb-y)
>> +subdir-y := $(dts-dirs)
>> +clean-files := *.dtb
>> diff --git a/arch/arm64/boot/dts/zte/zx296718-evb.dts b/arch/arm64/boot/dts/zte/zx296718-evb.dts
>> new file mode 100644
>> index 0000000..d7cefb4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/zte/zx296718-evb.dts
>> @@ -0,0 +1,25 @@
>> +/*
>> + * ZTE Ltd. zx296718 Plaform
>> + *
>> + */
>
> We should probably consider to add a proper licence. GPL/X11 dual is
> mostly used and recommended, and there are quite a lot examples in the
> DTS folder.
>
Will do.
>> +/dts-v1/;
>> +#include "zx296718.dtsi"
>> +
>> +/ {
>> + model = "ZTE zx296718 evaluation board";
>> + compatible = "zte,zx296718-evb", "zte,zx296718";
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + memory at 40000000 {
>> + device_type = "memory";
>> + reg = <0x40000000 0x40000000>;
>> + };
>> +
>> +};
>> +
>> +&uart0 {
>> + status = "okay";
>> +};
>> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
>> new file mode 100644
>> index 0000000..c75a819
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
>> @@ -0,0 +1,254 @@
>> +/*
>> + * DTS File for ZTE ZX296718 Plaform
>> + *
>> + * Copyright (c) 2016 ZTE Semiconductor Co., Ltd.
>> + */
>
> Ditto
Will do.
>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +
>> +/ {
>> + compatible = "zte,zx296718";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu-map {
>> + cluster0 {
>> + core0 {
>> + cpu = <&cpu0>;
>> + };
>> + core1 {
>> + cpu = <&cpu1>;
>> + };
>> + core2 {
>> + cpu = <&cpu2>;
>> + };
>> + core3 {
>> + cpu = <&cpu3>;
>> + };
>> + };
>> + };
>> +
>> + cpu0: cpu at 0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53","arm,armv8";
>> + reg = <0x0 0x0>;
>> + enable-method = "psci";
>> + };
>> +
>> + cpu1: cpu at 1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53","arm,armv8";
>> + reg = <0x0 0x1>;
>> + enable-method = "psci";
>> + };
>> +
>> + cpu2: cpu at 2 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53","arm,armv8";
>> + reg = <0x0 0x2>;
>> + enable-method = "psci";
>> + };
>> +
>> + cpu3: cpu at 3 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a53","arm,armv8";
>> + reg = <0x0 0x3>;
>> + enable-method = "psci";
>> + };
>> + };
>> +
>> + osc12m: osc12m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <12000000>;
>> + clock-output-names = "osc12m";
>> + };
>> +
>> + osc24m: osc24m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <24000000>;
>> + clock-output-names = "osc24m";
>> + };
>> +
>> + osc25m: osc25m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <25000000>;
>> + clock-output-names = "osc25m";
>> + };
>> +
>> + clk24k: clk-24k {
>
> I would suggest we name node of fixed rate clock in an unified way like
> clock-xxx.
>
Will do.
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <24000>;
>> + clock-output-names = "rtcclk";
>> + };
>> +
>> + osc32k: osc32k-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <32000>;
>> + clock-output-names = "osc32k";
>> + };
>> +
>> + osc60m: osc60m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <60000000>;
>> + clock-output-names = "osc60m";
>> + };
>> +
>> + osc99m: osc99m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <99000000>;
>> + clock-output-names = "osc99m";
>> + };
>> +
>> + osc125m: osc125m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <125000000>;
>> + clock-output-names = "osc125m";
>> + };
>> +
>> + osc198m: osc198m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <198000000>;
>> + clock-output-names = "osc198m";
>> + };
>> +
>> + pll_vga: pll-1073m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <1073000000>;
>> + clock-output-names = "pll_vga";
>> + };
>> +
>> + pll_ddr: pll-932m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <932000000>;
>> + clock-output-names = "pll_ddr";
>> + };
>> +
>> + pll_mac: pll-1000m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <1000000000>;
>> + clock-output-names = "pll_mac";
>> + };
>> +
>> + pll_mm0: pll-1188m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <1188000000>;
>> + clock-output-names = "pll_mm0";
>> + };
>> +
>> + pll_mm1: pll-1296m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <1296000000>;
>> + clock-output-names = "pll_mm1";
>> + };
>> +
>> + pll_audio: pll-884m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <884000000>;
>> + clock-output-names = "pll_audio";
>> + };
>> +
>> + pll_hsic: pll-960m-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <960000000>;
>> + clock-output-names = "pll_hsic";
>> + };
>
> Do we really have so many uncontrolled clocks with fixed rate in the
> SoC?
PLL clocks can be configured actually according to register. But I
prefer to keep them as fixed clocks due to two reasons:
1. ZTE do not want to expose too much information of PLL.
2. All clients blocks, such as MMC and video codec, assume the
related input clock's frequency as a derivation from PLL default
frequency value in block clock control register description.
>
> Shawn
^ permalink raw reply
* [PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
From: Srinivas Ramana @ 2016-09-12 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D3C06D.4030908@codeaurora.org>
If the bootloader uses the long descriptor format and jumps to
kernel decompressor code, TTBCR may not be in a right state.
Before enabling the MMU, it is required to clear the TTBCR.PD0
field to use TTBR0 for translation table walks.
The 'commit dbece45894d3a ("ARM: 7501/1: decompressor:
reset ttbcr for VMSA ARMv7 cores")' does the reset of TTBCR.N, but
doesn't consider all the bits for the size of TTBCR.N.
Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
indicate the use of TTBR0 and the correct base address width.
Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
---
arch/arm/boot/compressed/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index af11c2f8f3b7..fc6d541549a2 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -779,7 +779,7 @@ __armv7_mmu_cache_on:
orrne r0, r0, #1 @ MMU enabled
movne r1, #0xfffffffd @ domain 0 = client
bic r6, r6, #1 << 31 @ 32-bit translation system
- bic r6, r6, #3 << 0 @ use only ttbr0
+ bic r6, r6, #(7 << 0) | (1 << 4) @ use only ttbr0
mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer
mcrne p15, 0, r1, c3, c0, 0 @ load domain access control
mcrne p15, 0, r6, c2, c0, 2 @ load ttb control
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH] clk: stm32f4: don't assume 48MHz clock is derived from primary PLL
From: Andrea Merello @ 2016-09-12 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b39d3544-9512-9e0b-2f5b-4135835009f9@st.com>
On Fri, Sep 9, 2016 at 11:57 AM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> Hi Andrea,
>
> On 09/08/2016 09:01 AM, Andrea Merello wrote:
>>
>> This driver just look at the PLLs configurations set by the
>> bootloader, but it assumes the 48MHz clock is derived from the primary
>> PLL; however using PLLSAI is another option for generating the 48MHz
>> clock.
>>
>> This patch make the driver to check for this, and eventually adjust the
>> clock tree accordingly
>
>
> Another patch-set is ongoing concerning RTC clock for stm32f4. It is
> developed by Gabriel Fernandez (I add him directly in this reply).
> Can you check with him how he plans to manage this RTC clock in order to
> have something similar / coherent for SAI clocks, 48MHz ....
>
> Concerning this patch,
> When I look at the clock tree I see that 48 MHz is only provided by pll
> named "PLL". So If you use PLL SAI to provide a clock at 48 MHz, you
> actually use SAI_A or SAI_B clock. I'm right ?
No, SAI_A and SAI_B are two other clocks output, that comes from
PLLSAI through other divisors and muxes; here I simply look at if the
bootloader selected the "PLL48CLK" output of the SAI PLL instead of
the "PLL48CLK" of the primary PLL.
> I think we need to have something more configurable. Each special clock (SAI
> / RTC /LCd ...) have to be configurable and each "parents" (PLL / PLLI2S /
> PLLSAI) should be described at least in the driver.
Yes, there are probably other possible clock configurations that the
driver does not recognize yet; I just added this one because I found
it useful in real-world scenario (USB/SDcard working and core running
at the max speed at the same time).
>
> Gabriel,
>
> Can you send a draft of your patch-set for RTC clock to Andrea, in order to
> discuss about this topic.
>
> Thanks
>
> Alex
>
>
>
>>
>> Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
>> Cc: Michael Turquette <mturquette@baylibre.com>
>> Cc: Stephen Boyd <sboyd@codeaurora.org>
>> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> Cc: Alexandre Torgue <alexandre.torgue@st.com>
>> Cc: Bruno Herrera <bruherrera@gmail.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 26 ++++++++++++++++++++++++--
>> 1 file changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index 02d6810..7f1ba8f 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -24,6 +24,7 @@
>> #include <linux/of.h>
>> #include <linux/of_address.h>
>>
>> +#define STM32F4_RCC_CR 0x00
>> #define STM32F4_RCC_PLLCFGR 0x04
>> #define STM32F4_RCC_CFGR 0x08
>> #define STM32F4_RCC_AHB1ENR 0x30
>> @@ -31,6 +32,8 @@
>> #define STM32F4_RCC_AHB3ENR 0x38
>> #define STM32F4_RCC_APB1ENR 0x40
>> #define STM32F4_RCC_APB2ENR 0x44
>> +#define STM32F4_RCC_PLLSAICFGR 0x88
>> +#define STM32F4_RCC_DCKCFGR 0x8C
>>
>> struct stm32f4_gate_data {
>> u8 offset;
>> @@ -238,16 +241,35 @@ static struct clk *clk_register_apb_mul(struct
>> device *dev, const char *name,
>> static void stm32f4_rcc_register_pll(const char *hse_clk, const char
>> *hsi_clk)
>> {
>> unsigned long pllcfgr = readl(base + STM32F4_RCC_PLLCFGR);
>> -
>> + unsigned long pllsaicfgr = readl(base + STM32F4_RCC_PLLSAICFGR);
>> + unsigned long dckcfgr = readl(base + STM32F4_RCC_DCKCFGR);
>> + unsigned long rcccr = readl(base + STM32F4_RCC_CR);
>> + bool saien = rcccr & BIT(28);
>> unsigned long pllm = pllcfgr & 0x3f;
>> unsigned long plln = (pllcfgr >> 6) & 0x1ff;
>> unsigned long pllp = BIT(((pllcfgr >> 16) & 3) + 1);
>> const char *pllsrc = pllcfgr & BIT(22) ? hse_clk : hsi_clk;
>> unsigned long pllq = (pllcfgr >> 24) & 0xf;
>> + bool src48_sai = dckcfgr & BIT(27);
>> + unsigned long pllsain = (pllsaicfgr >> 6) & 0x1ff;
>> + unsigned long pllsaip = BIT(((pllsaicfgr >> 16) & 3) + 1);
>>
>> clk_register_fixed_factor(NULL, "vco", pllsrc, 0, plln, pllm);
>> clk_register_fixed_factor(NULL, "pll", "vco", 0, 1, pllp);
>> - clk_register_fixed_factor(NULL, "pll48", "vco", 0, 1, pllq);
>> +
>> + if (src48_sai && !saien) {
>> + pr_err("48MHz derived from SAI PLL, but SAI PLL disabled
>> (blame the bootloader)\n");
>> + return;
>> + }
>> +
>> + if (saien)
>> + clk_register_fixed_factor(NULL, "sai",
>> + pllsrc, 0, pllsain, pllm);
>> +
>> + if (src48_sai)
>> + clk_register_fixed_factor(NULL, "pll48", "sai", 0, 1,
>> pllsaip);
>> + else
>> + clk_register_fixed_factor(NULL, "pll48", "vco", 0, 1,
>> pllq);
>> }
>>
>> /*
>>
>
^ permalink raw reply
* [PATCH v3 1/4] drm/bridge: Add RGB to VGA bridge support
From: Chen-Yu Tsai @ 2016-09-12 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908121751.16911-2-maxime.ripard@free-electrons.com>
Hi,
On Thu, Sep 8, 2016 at 8:17 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen EDIDs.
>
> Add a bridge that doesn't do anything but expose the modes available on the
> screen, either based on the EDIDs if available, or based on the XGA
> standards.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../bindings/display/bridge/rgb-to-vga-bridge.txt | 52 +++++
> drivers/gpu/drm/bridge/Kconfig | 6 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/rgb-to-vga.c | 232 +++++++++++++++++++++
> 4 files changed, 291 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> new file mode 100644
> index 000000000000..83a053fb51a0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> @@ -0,0 +1,52 @@
> +Passive RGB to VGA bridge
> +-------------------------
> +
> +This binding is aimed for entirely passive RGB to VGA bridges that do not
> +require any configuration.
> +
> +Required properties:
> +
> +- compatible: Must be "rgb-to-vga-bridge"
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modeled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for RGB input
> +- Video port 1 for VGA output
> +
> +
> +Example
> +-------
> +
> +bridge {
> + compatible = "rgb-to-vga-bridge";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint {
> + remote-endpoint = <&tcon0_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint {
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> +};
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index b590e678052d..42b95adf5091 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -17,6 +17,12 @@ config DRM_ANALOGIX_ANX78XX
> the HDMI output of an application processor to MyDP
> or DisplayPort.
>
> +config DRM_RGB_TO_VGA
> + tristate "Dumb RGB to VGA Bridge support"
> + select DRM_KMS_HELPER
> + help
> + Support for passive RGB to VGA bridges
> +
> config DRM_DW_HDMI
> tristate
> select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index efdb07e878f5..3bb8cbe09fe9 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,6 +1,7 @@
> ccflags-y := -Iinclude/drm
>
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> +obj-$(CONFIG_DRM_RGB_TO_VGA) += rgb-to-vga.o
> obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
> obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/rgb-to-vga.c b/drivers/gpu/drm/bridge/rgb-to-vga.c
> new file mode 100644
> index 000000000000..84b1b10198a4
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/rgb-to-vga.c
> @@ -0,0 +1,232 @@
No beginning file header / copyright statement?
> +
> +#include <linux/module.h>
> +#include <linux/of_graph.h>
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/drm_crtc_helper.h>
> +
> +struct dumb_vga {
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> +
> + struct i2c_adapter *ddc;
> +};
> +
> +static inline struct dumb_vga *
> +drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct dumb_vga, bridge);
> +}
> +
> +static inline struct dumb_vga *
> +drm_connector_to_dumb_vga(struct drm_connector *connector)
> +{
> + return container_of(connector, struct dumb_vga, connector);
> +}
> +
> +static int dumb_vga_get_modes(struct drm_connector *connector)
> +{
> + struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct edid *edid;
> + int ret;
> +
> + if (IS_ERR(vga->ddc))
> + goto fallback;
> +
> + edid = drm_get_edid(connector, vga->ddc);
> + if (!edid) {
> + DRM_INFO("EDID readout failed, falling back to standard modes\n");
> + goto fallback;
> + }
> +
> + drm_mode_connector_update_edid_property(connector, edid);
> + return drm_add_edid_modes(connector, edid);
> +
> +fallback:
> + /*
> + * In case we cannot retrieve the EDIDs (broken or missing i2c
> + * bus), fallback on the XGA standards
> + */
> + ret = drm_add_modes_noedid(connector, 1920, 1200);
> +
> + /* And prefer a mode pretty much anyone can handle */
> + drm_set_preferred_mode(connector, 1024, 768);
> +
> + return ret;
> +}
> +
> +static struct drm_encoder *
> +dumb_vga_best_encoder(struct drm_connector *connector)
> +{
> + struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> +
> + return vga->bridge.encoder;
> +}
> +
> +static struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
> + .get_modes = dumb_vga_get_modes,
> + .best_encoder = dumb_vga_best_encoder,
drm_modeset_helper_vtables.h says the following about .best_encoder:
You can leave this function to NULL if the connector is only
attached to a single encoder and you are using the atomic helpers.
In this case, the core will call drm_atomic_helper_best_encoder()
for you.
IMHO you can drop the callback here.
> +};
> +
> +static enum drm_connector_status
> +dumb_vga_connector_detect(struct drm_connector *connector, bool force)
> +{
> + struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> +
> + /*
> + * Even if we have an I2C bus, we can't assume that the cable
> + * is disconnected if drm_probe_ddc. Some cables don't wire
> + * the DDC pins, or the I2C bus might be disfunctional.
> + */
> + if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
> + return connector_status_connected;
> +
> + return connector_status_unknown;
> +}
> +
> +static void
> +dumb_vga_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_cleanup(connector);
> +}
> +
> +static struct drm_connector_funcs dumb_vga_con_funcs = {
> + .dpms = drm_atomic_helper_connector_dpms,
> + .detect = dumb_vga_connector_detect,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = dumb_vga_connector_destroy,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static int dumb_vga_attach(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + int ret;
> +
> + if (!bridge->encoder) {
> + DRM_ERROR("Missing encoder\n");
> + return -ENODEV;
> + }
> +
> + drm_connector_helper_add(&vga->connector,
> + &dumb_vga_con_helper_funcs);
> + ret = drm_connector_init(bridge->dev, &vga->connector,
> + &dumb_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
> + if (ret) {
> + DRM_ERROR("Failed to initialize connector\n");
> + return ret;
> + }
> +
> + drm_mode_connector_attach_encoder(&vga->connector,
> + bridge->encoder);
> +
> + return 0;
> +}
> +
> +static void dumb_vga_nop(struct drm_bridge *bridge) {};
> +
> +static struct drm_bridge_funcs dumb_vga_bridge_funcs = {
const?
> + .attach = dumb_vga_attach,
> + .enable = dumb_vga_nop,
> + .disable = dumb_vga_nop,
> + .pre_enable = dumb_vga_nop,
> + .post_disable = dumb_vga_nop,
Nit: The 4 nops can be dropped. The header file states these
callbacks are optional.
> +};
> +
> +static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
> +{
> + struct device_node *end_node, *phandle, *remote;
> + struct i2c_adapter *ddc;
> +
> + end_node = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!end_node) {
> + dev_err(dev, "Missing connector endpoint\n");
> + return ERR_PTR(-ENODEV);
> + }
> +
> + remote = of_graph_get_remote_port_parent(end_node);
> + of_node_put(end_node);
> + if (!remote) {
> + dev_err(dev, "Enable to parse remote node\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
> + of_node_put(remote);
> + if (!phandle)
> + return ERR_PTR(-ENODEV);
> +
> + ddc = of_get_i2c_adapter_by_node(phandle);
> + of_node_put(phandle);
> + if (!ddc)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return ddc;
> +}
> +
> +static int dumb_vga_probe(struct platform_device *pdev)
> +{
> + struct dumb_vga *vga;
> + int ret;
> +
> + vga = devm_kzalloc(&pdev->dev, sizeof(*vga), GFP_KERNEL);
> + if (!vga)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, vga);
> +
> + vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
> + if (IS_ERR(vga->ddc)) {
> + if (PTR_ERR(vga->ddc) == -ENODEV) {
> + dev_info(&pdev->dev,
> + "No i2c bus specified... Disabling EDID readout\n");
> + } else {
> + dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
> + return PTR_ERR(vga->ddc);
> + }
> + }
> +
> + vga->bridge.funcs = &dumb_vga_bridge_funcs;
> + vga->bridge.of_node = pdev->dev.of_node;
> +
> + ret = drm_bridge_add(&vga->bridge);
> + if (ret && !IS_ERR(vga->ddc))
> + i2c_put_adapter(vga->ddc);
> +
> + return ret;
> +}
> +
> +static int dumb_vga_remove(struct platform_device *pdev)
> +{
> + struct dumb_vga *vga = platform_get_drvdata(pdev);
> +
> + drm_bridge_remove(&vga->bridge);
> +
> + if (!IS_ERR(vga->ddc))
> + i2c_put_adapter(vga->ddc);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id dumb_vga_match[] = {
> + { .compatible = "rgb-to-vga-bridge" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, dumb_vga_match);
> +
> +struct platform_driver dumb_vga_driver = {
> + .probe = dumb_vga_probe,
> + .remove = dumb_vga_remove,
> + .driver = {
> + .name = "rgb-to-vga-bridge",
> + .of_match_table = dumb_vga_match,
> + },
> +};
> +module_platform_driver(dumb_vga_driver);
> +
> +MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
> +MODULE_DESCRIPTION("Dumb RGB to VGA bridge driver");
> +MODULE_LICENSE("GPL");
FWIW the rest looks fine.
Regards
ChenYu
^ permalink raw reply
* [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
From: Y.B. Lu @ 2016-09-12 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473392840.30217.170.camel@buserror.net>
Hi Scott,
Thanks for your review :)
See my comment inline.
> -----Original Message-----
> From: Scott Wood [mailto:oss at buserror.net]
> Sent: Friday, September 09, 2016 11:47 AM
> To: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Arnd
> Bergmann
> Cc: linuxppc-dev at lists.ozlabs.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> clk at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> foundation.org; netdev at vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie
> Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> > The global utilities block controls power management, I/O device
> > enabling, power-onreset(POR) configuration monitoring, alternate
> > function selection for multiplexed signals,and clock control.
> >
> > This patch adds a driver to manage and access global utilities block.
> > Initially only reading SVR and registering soc device are supported.
> > Other guts accesses, such as reading RCW, should eventually be moved
> > into this driver as well.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > Signed-off-by: Scott Wood <oss@buserror.net>
>
> Don't put my signoff on patches that I didn't put it on
> myself. ?Definitely don't put mine *after* yours on patches that were
> last modified by you.
>
> If you want to mention that the soc_id encoding was my suggestion, then
> do so explicitly.
>
[Lu Yangbo-B47093] I found your 'signoff' on this patch at below link.
http://patchwork.ozlabs.org/patch/649211/
So, let me just change the order in next version ?
Signed-off-by: Scott Wood <oss@buserror.net>
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > +/* SoC attribute definition for QorIQ platform */ static const struct
> > +soc_device_attribute qoriq_soc[] = { #ifdef CONFIG_PPC
> > + /*
> > + ?* Power Architecture-based SoCs T Series
> > + ?*/
> > +
> > + /* SoC: T1024/T1014/T1023/T1013 Rev: 1.0 */
> > + { .soc_id = "svr:0x85400010,name:T1024,die:T1024",
> > + ??.revision = "1.0",
> > + },
> > + { .soc_id = "svr:0x85480010,name:T1024E,die:T1024",
> > + ??.revision = "1.0",
> > + },
>
> Revision could be computed from the low 8 bits of SVR (just as you do for
> unknown SVRs).
>
[Lu Yangbo-B47093] Yes, you're right. Will remove it here.
> We could move the die name into .family:
>
> {
> .soc_id = "svr:0x85490010,name:T1023E,",
> .family = "QorIQ T1024",
> }
>
> I see you dropped svre (and the trailing comma), though I guess the vast
> majority of potential users will be looking at .family. ?In which case do
> we even need name? ?If we just make the soc_id be "svr:0xnnnnnnnn" then
> we could shrink the table to an svr+mask that identifies each die. ?I'd
> still want to keep the "svr:" even if we're giving up on the general
> tagging system, to make it clear what the number refers to, and to
> provide some defense against users who match only against soc_id rather
> than soc_id+family. ?Or we could go further and format soc_id as "QorIQ
> SVR 0xnnnnnnnn" so that soc_id-only matches are fully acceptable rather
> than just less dangerous.
[Lu Yangbo-B47093] It's a good idea to move die into .family I think.
In my opinion, it's better to keep svr and name in soc_id just like your suggestion above.
> {
> .soc_id = "svr:0x85490010,name:T1023E,",
> .family = "QorIQ T1024",
> }
The user probably don?t like to learn the svr value. What they want is just to match the soc they use.
It's convenient to use name+rev for them to match a soc.
Regarding shrinking the table, I think it's hard to use svr+mask. Because I find many platforms use different masks.
We couldn?t know the mask according svr value.
>
> > +static const struct soc_device_attribute *fsl_soc_device_match(
> > + unsigned int svr, const struct soc_device_attribute *matches) {
> > + char svr_match[50];
> > + int n;
> > +
> > + n = sprintf(svr_match, "*%08x*", svr);
>
> n = sprintf(svr_match, "svr:0x%08x,*", svr);
>
> (according to the current encoding)
>
[Lu Yangbo-B47093] Ok. Will do that.
> > +
> > + do {
> > + if (!matches->soc_id)
> > + return NULL;
> > + if (glob_match(svr_match, matches->soc_id))
> > + break;
> > + } while (matches++);
>
> Are you expecting "matches++" to ever evaluate as false?
[Lu Yangbo-B47093] Yes, this is used to match the soc we use in qoriq_soc array until getting true.
We need to get the name and die information defined in array.
>
> > + /* Register soc device */
> > + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> > + if (!soc_dev_attr) {
> > + ret = -ENOMEM;
> > + goto out_unmap;
> > + }
>
> Couldn't this be statically allocated?
[Lu Yangbo-B47093] Do you mean we define this struct statically ?
static struct soc_device_attribute soc_dev_attr;
>
> > +
> > + machine = of_flat_dt_get_machine_name();
> > + if (machine)
> > + soc_dev_attr->machine = kasprintf(GFP_KERNEL, "%s",
> > machine);
> > +
> > + soc_dev_attr->family = kasprintf(GFP_KERNEL, "QorIQ");
> > +
> > + svr = fsl_guts_get_svr();
> > + fsl_soc = fsl_soc_device_match(svr, qoriq_soc);
> > + if (fsl_soc) {
> > + soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%s",
> > + ?fsl_soc->soc_id);
>
> You can use kstrdup() if you're just copying the string as is.
[Lu Yangbo-B47093] Ok. Will do that.
>
> > + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%s",
> > + ???fsl_soc->revision);
> > + } else {
> > + soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%08x",
> > svr);
>
> kasprintf(GFP_KERNEL, "svr:0x%08x,", svr);
[Lu Yangbo-B47093] Sorry, will add that.
>
>
> > +
> > + soc_dev = soc_device_register(soc_dev_attr);
> > + if (IS_ERR(soc_dev)) {
> > + ret = -ENODEV;
>
> Why are you changing the error code?
[Lu Yangbo-B47093] What error code should we use ? :)
>
> > + goto out;
> > + } else {
>
> Unnecessary "else".
[Lu Yangbo-B47093] Oh.. Correct!
>
> > + pr_info("Detected: %s\n", soc_dev_attr->machine);
>
> Machine: %s
[Lu Yangbo-B47093] Ok. Will do that.
>
> > + pr_info("Detected SoC family: %s\n", soc_dev_attr->family);
> > + pr_info("Detected SoC ID: %s, revision: %s\n",
> > + soc_dev_attr->soc_id, soc_dev_attr->revision);
>
> s/Detected //g
[Lu Yangbo-B47093] Ok, will do that.
>
>
> > + }
> > + return 0;
> > +out:
> > + kfree(soc_dev_attr->machine);
> > + kfree(soc_dev_attr->family);
> > + kfree(soc_dev_attr->soc_id);
> > + kfree(soc_dev_attr->revision);
> > + kfree(soc_dev_attr);
> > +out_unmap:
> > + iounmap(guts->regs);
> > +out_free:
> > + kfree(guts);
>
> devm
[Lu Yangbo-B47093] What's the devm meaning here :)
>
> > +static int fsl_guts_remove(struct platform_device *dev) {
> > + kfree(soc_dev_attr->machine);
> > + kfree(soc_dev_attr->family);
> > + kfree(soc_dev_attr->soc_id);
> > + kfree(soc_dev_attr->revision);
> > + kfree(soc_dev_attr);
> > + soc_device_unregister(soc_dev);
> > + iounmap(guts->regs);
> > + kfree(guts);
> > + return 0;
> > +}
>
> Don't free the memory before you unregister the device that uses it (moot
> if you use devm).
[Lu Yangbo-B47093] The soc.c driver mentions that.
Ensure soc_dev->attr is freed prior to calling soc_device_unregister.
>
> >
> > +#ifdef CONFIG_FSL_GUTS
> > +unsigned int fsl_guts_get_svr(void);
> > +#endif
>
> Don't ifdef prototypes (unless you're going to provide a stub
> alternative).
[Lu Yangbo-B47093] Ok, will remove ifdef.
>
> -Scott
^ permalink raw reply
* [PATCH V2] cpufreq: create link to policy only for registered CPUs
From: Viresh Kumar @ 2016-09-12 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160819110032.GM1041@n2100.armlinux.org.uk>
If a cpufreq driver is registered very early in the boot stage (e.g.
registered from postcore_initcall()), then cpufreq core may generate
kernel warnings for it.
In this case, the CPUs are brought online, then the cpufreq driver is
registered, and then the CPU topology devices are registered. However,
by the time cpufreq_add_dev() gets called, the cpu device isn't stored
in the per-cpu variable (cpu_sys_devices,) which is read by
get_cpu_device().
So the cpufreq core fails to get device for the CPU, for which
cpufreq_add_dev() was called in the first place and we will hit a
WARN_ON(!cpu_dev).
Even if we reuse the 'dev' parameter passed to cpufreq_add_dev() to
avoid that warning, there might be other CPUs online that share the
policy with the cpu for which cpufreq_add_dev() is called. Eventually
get_cpu_device() will return NULL for them as well, and we will hit the
same WARN_ON() again.
In order to fix these issues, change cpufreq core to create links to the
policy for a cpu only when cpufreq_add_dev() is called for that CPU.
Reuse the 'real_cpus' mask to track that as well.
Note that cpufreq_remove_dev() already handles removal of the links for
individual CPUs and cpufreq_add_dev() has aligned with that now.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V1->V2:
- Updated changelog based on suggestions from Russell
- Tested by from Russell
drivers/cpufreq/cpufreq.c | 89 +++++++++++++++--------------------------------
1 file changed, 28 insertions(+), 61 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 13fb589b6d2c..3a64136bf21b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -916,58 +916,18 @@ static struct kobj_type ktype_cpufreq = {
.release = cpufreq_sysfs_release,
};
-static int add_cpu_dev_symlink(struct cpufreq_policy *policy, int cpu)
+static int add_cpu_dev_symlink(struct cpufreq_policy *policy,
+ struct device *dev)
{
- struct device *cpu_dev;
-
- pr_debug("%s: Adding symlink for CPU: %u\n", __func__, cpu);
-
- if (!policy)
- return 0;
-
- cpu_dev = get_cpu_device(cpu);
- if (WARN_ON(!cpu_dev))
- return 0;
-
- return sysfs_create_link(&cpu_dev->kobj, &policy->kobj, "cpufreq");
+ dev_dbg(dev, "%s: Adding symlink\n", __func__);
+ return sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
}
-static void remove_cpu_dev_symlink(struct cpufreq_policy *policy, int cpu)
+static void remove_cpu_dev_symlink(struct cpufreq_policy *policy,
+ struct device *dev)
{
- struct device *cpu_dev;
-
- pr_debug("%s: Removing symlink for CPU: %u\n", __func__, cpu);
-
- cpu_dev = get_cpu_device(cpu);
- if (WARN_ON(!cpu_dev))
- return;
-
- sysfs_remove_link(&cpu_dev->kobj, "cpufreq");
-}
-
-/* Add/remove symlinks for all related CPUs */
-static int cpufreq_add_dev_symlink(struct cpufreq_policy *policy)
-{
- unsigned int j;
- int ret = 0;
-
- /* Some related CPUs might not be present (physically hotplugged) */
- for_each_cpu(j, policy->real_cpus) {
- ret = add_cpu_dev_symlink(policy, j);
- if (ret)
- break;
- }
-
- return ret;
-}
-
-static void cpufreq_remove_dev_symlink(struct cpufreq_policy *policy)
-{
- unsigned int j;
-
- /* Some related CPUs might not be present (physically hotplugged) */
- for_each_cpu(j, policy->real_cpus)
- remove_cpu_dev_symlink(policy, j);
+ dev_dbg(dev, "%s: Removing symlink\n", __func__);
+ sysfs_remove_link(&dev->kobj, "cpufreq");
}
static int cpufreq_add_dev_interface(struct cpufreq_policy *policy)
@@ -999,7 +959,7 @@ static int cpufreq_add_dev_interface(struct cpufreq_policy *policy)
return ret;
}
- return cpufreq_add_dev_symlink(policy);
+ return 0;
}
__weak struct cpufreq_governor *cpufreq_default_governor(void)
@@ -1129,7 +1089,6 @@ static void cpufreq_policy_put_kobj(struct cpufreq_policy *policy, bool notify)
down_write(&policy->rwsem);
cpufreq_stats_free_table(policy);
- cpufreq_remove_dev_symlink(policy);
kobj = &policy->kobj;
cmp = &policy->kobj_unregister;
up_write(&policy->rwsem);
@@ -1211,8 +1170,8 @@ static int cpufreq_online(unsigned int cpu)
if (new_policy) {
/* related_cpus should at least include policy->cpus. */
cpumask_copy(policy->related_cpus, policy->cpus);
- /* Remember CPUs present at the policy creation time. */
- cpumask_and(policy->real_cpus, policy->cpus, cpu_present_mask);
+ /* Clear mask of registered CPUs */
+ cpumask_clear(policy->real_cpus);
}
/*
@@ -1327,6 +1286,8 @@ static int cpufreq_online(unsigned int cpu)
return ret;
}
+static void cpufreq_offline(unsigned int cpu);
+
/**
* cpufreq_add_dev - the cpufreq interface for a CPU device.
* @dev: CPU device.
@@ -1336,22 +1297,28 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
{
struct cpufreq_policy *policy;
unsigned cpu = dev->id;
+ int ret;
dev_dbg(dev, "%s: adding CPU%u\n", __func__, cpu);
- if (cpu_online(cpu))
- return cpufreq_online(cpu);
+ if (cpu_online(cpu)) {
+ ret = cpufreq_online(cpu);
+ if (ret)
+ return ret;
+ }
- /*
- * A hotplug notifier will follow and we will handle it as CPU online
- * then. For now, just create the sysfs link, unless there is no policy
- * or the link is already present.
- */
+ /* Create sysfs link on CPU registration */
policy = per_cpu(cpufreq_cpu_data, cpu);
if (!policy || cpumask_test_and_set_cpu(cpu, policy->real_cpus))
return 0;
- return add_cpu_dev_symlink(policy, cpu);
+ ret = add_cpu_dev_symlink(policy, dev);
+ if (ret) {
+ cpumask_clear_cpu(cpu, policy->real_cpus);
+ cpufreq_offline(cpu);
+ }
+
+ return ret;
}
static void cpufreq_offline(unsigned int cpu)
@@ -1432,7 +1399,7 @@ static void cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif)
cpufreq_offline(cpu);
cpumask_clear_cpu(cpu, policy->real_cpus);
- remove_cpu_dev_symlink(policy, cpu);
+ remove_cpu_dev_symlink(policy, dev);
if (cpumask_empty(policy->real_cpus))
cpufreq_policy_free(policy, true);
--
2.7.1.410.g6faf27b
^ permalink raw reply related
* [PATCH 4/9] mtd: nand: Add function to convert ONFI mode to data_interface
From: Sascha Hauer @ 2016-09-12 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909143522.6a3b6975@bbrezillon>
On Fri, Sep 09, 2016 at 02:35:22PM +0200, Boris Brezillon wrote:
> On Fri, 9 Sep 2016 14:05:07 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> > onfi_init_data_interface() initializes a data interface with
> > values from a given ONFI mode.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > drivers/mtd/nand/nand_timings.c | 16 ++++++++++++++++
> > include/linux/mtd/nand.h | 2 ++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c
> > index 9af2ebc..ece4ff2 100644
> > --- a/drivers/mtd/nand/nand_timings.c
> > +++ b/drivers/mtd/nand/nand_timings.c
> > @@ -269,3 +269,19 @@ const struct nand_sdr_timings *onfi_async_timing_mode_to_sdr_timings(int mode)
> > return &onfi_sdr_timings[mode].timings.sdr;
> > }
> > EXPORT_SYMBOL(onfi_async_timing_mode_to_sdr_timings);
> > +
> > +/**
> > + * onfi_init_data_interface - [NAND Interface] Initialize a data interface from
> > + * given ONFI mode
> > + * @iface: The data interface to be initialized
> > + * @mode: The ONFI timing mode
> > + */
> > +int onfi_init_data_interface(struct nand_data_interface *iface, int mode)
>
> Can we choose a more future proof prototype (like the one I suggested)
> for this function. Passing the nand_chip will later allow to extract
> extended timings (tR, tPROG, tCCS, ...) from the param page, and
> passing the interface type makes it compatible with DDR mode.
Ok, will change as you suggested to:
int onfi_init_data_interface(struct nand_chip *chip,
struct nand_data_interface *iface,
enum nand_data_interface_type type,
int timing_mode)
Before I send another round: Are the other patches ok?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 0/5] ARM: dts: sun8i: Add touchscreen node to various tablets
From: Chen-Yu Tsai @ 2016-09-12 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911182327.824-1-hdegoede@redhat.com>
On Mon, Sep 12, 2016 at 2:23 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi Maxime,
>
> Now that Dmitry has queued up the firmware-name property changes
> in his for-linus branch, these dt patches are ready for merging.
>
> Regards,
>
> Hans
Series looks good,
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCHv2] ARM: dts: ARM: dts: Fix omap5 SDIO dat1 interrupt
From: Tony Lindgren @ 2016-09-12 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909210243.19296-1-tony@atomide.com>
* Tony Lindgren <tony@atomide.com> [160909 14:02]:
> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> @@ -332,7 +332,7 @@
>
> wlcore_irq_pin: pinmux_wlcore_irq_pin {
> pinctrl-single,pins = <
> - OMAP5_IOPAD(0x40, PIN_INPUT_PULLUP | MUX_MODE6) /* llia_wakereqin.gpio1_wk14 */
> + OMAP5_IOPAD(0x40, PIN_INPUT | MUX_MODE6) /* llia_wakereqin.gpio1_wk14 */
> >;
> };
> };
> @@ -355,15 +355,17 @@
> non-removable;
> cap-power-off-card;
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc3_pins &wlcore_irq_pin>;
> + pinctrl-0 = <&mmc3_pins>;
> interrupts-extended = <&gic GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH
> - &omap5_pmx_core 0x168>;
> + &omap5_pmx_core 0x16a>;
>
And the &gic is wrong here, it should be &wakeupgen. That seems to
make things a bit better on omap5-uevm. Updated patch below.
Regards,
Tony
8< -----------------
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 8 Sep 2016 09:04:50 -0700
Subject: [PATCH] ARM: dts: ARM: dts: Fix omap5 SDIO dat1 interrupt
Few changes to fix issues I've noticed while debugging omap5-uevm
wl18xx issues:
1. Move wlcore irq pin muxing under wlcore. This irq could be
different from gpio_wk14 on some board variants
2. Don't configure pull on wlcore irq pin. There is a 10k
pull up resistor R105 on the device to VDDS_1v8_MAIN
3. The padconf register for wlsdio_data1 is wrong, it's really
at 0x1a8 + 2 - 0x40 = 0x16a offset, not at 0x168 as that's
for wlsdio_data0
4. Mark the omap5-uevm wlan as compatible with ti,wl1837 as
that's what the TDK R078 part seems to be
5. The MMC interrupt for WLAN musb be wakeupgen, not gic
Looks like omap5-uevm WLAN behaves better now, but I still seem
to have issues with some access points.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap5-board-common.dtsi | 10 ++++++----
arch/arm/boot/dts/omap5-uevm.dts | 4 ++++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -332,7 +332,7 @@
wlcore_irq_pin: pinmux_wlcore_irq_pin {
pinctrl-single,pins = <
- OMAP5_IOPAD(0x40, PIN_INPUT_PULLUP | MUX_MODE6) /* llia_wakereqin.gpio1_wk14 */
+ OMAP5_IOPAD(0x40, PIN_INPUT | MUX_MODE6) /* llia_wakereqin.gpio1_wk14 */
>;
};
};
@@ -355,15 +355,17 @@
non-removable;
cap-power-off-card;
pinctrl-names = "default";
- pinctrl-0 = <&mmc3_pins &wlcore_irq_pin>;
- interrupts-extended = <&gic GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH
- &omap5_pmx_core 0x168>;
+ pinctrl-0 = <&mmc3_pins>;
+ interrupts-extended = <&wakeupgen GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH
+ &omap5_pmx_core 0x16a>;
#address-cells = <1>;
#size-cells = <0>;
wlcore: wlcore at 2 {
compatible = "ti,wl1271";
reg = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlcore_irq_pin>;
interrupt-parent = <&gpio1>;
interrupts = <14 IRQ_TYPE_LEVEL_HIGH>; /* gpio 14 */
ref-clock-frequency = <26000000>;
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -61,3 +61,7 @@
OMAP5_IOPAD(0x1be, PIN_OUTPUT | MUX_MODE6) /* mcspi1_somi.gpio5_141 */
>;
};
+
+&wlcore {
+ compatible = "ti,wl1837";
+};
--
2.9.3
^ permalink raw reply
* [PATCH v4 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K
From: CK Hu @ 2016-09-12 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1471417088-2993-4-git-send-email-bibby.hsieh@mediatek.com>
Hi, Bibby:
Sorry for the late reply.
On Wed, 2016-08-17 at 14:58 +0800, Bibby Hsieh wrote:
> From: Junzhi Zhao <junzhi.zhao@mediatek.com>
>
> Pixel clock should be 297MHz when resolution is 4K.
>
>From the code you modified, I think title should be: "Enlarge pll_rate
range from (<original lower bound>, <original upper bound>) to (<new
lower bound>, <new upper bound>)"
In description, you can explain the pll_rate for 4K and this enlargement
could support more resolution include 4K (Not only 4K).
> Signed-off-by: Junzhi Zhao <junzhi.zhao@mediatek.com>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 0186e50..90fb831 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -432,11 +432,16 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> unsigned long pll_rate;
> unsigned int factor;
>
> + /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
> pix_rate = 1000UL * mode->clock;
> - if (mode->clock <= 74000)
> + if (mode->clock <= 27000)
> + factor = 16 * 3;
> + else if (mode->clock <= 84000)
> factor = 8 * 3;
> - else
> + else if (mode->clock <= 167000)
> factor = 4 * 3;
> + else
> + factor = 2 * 3;
> pll_rate = pix_rate * factor;
>
> dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
Regards,
CK
^ permalink raw reply
* [RFD] hix5hd2 datasheet?
From: Jiancheng Xue @ 2016-09-12 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37ac958a-2196-349d-6af9-995067f1bdb8@gmail.com>
Hi,
On 2016/9/11 8:47, Marty Plummer wrote:
> On 09/09/2016 03:34 AM, Wei Xu wrote:
>> Hi Marty,
>>
>> On 08/09/2016 23:58, Marty Plummer wrote:
>>> Hello,
>>>
>>> I'm currently working to get the ethernet interface for the
>>> hi3520 SoC to work, and I think (emphasis on think) the hix5hd2-gmac
>>> driver is compatible, or nearly so, as checking the sdk source code
>>> for the interface has a fairly large amount of similar code (well, as
>>> similar as 2.6.24 vs 4.8-rc4 code can be) and identical register
>>> definitions to the very bit, so I was hoping to compare the datasheets
>>> and see how far the commonality goes. Plus, having the datasheets
>>> readily available will be of assistance to anyone else looking to
>>> contribute.
>>
>> +Jiancheng into this mail group.
>> Maybe you could get the hix5hd2 datasheets from him.
>> Thanks!
>>
Currently, the complete datasheet can only be released to customers and
partners who have signed NDA with hisilicon. We have no public version
to supply in this case. I'll point out this issue internally. I hope we can
get the solution.
>> Best Regards,
>> Wei
>>
>>>
>>> Thanks,
>>> Marty
>>>
>>>
>>
> In additon, I'm wondering how the second reg property for the
> hix5hd2-gmac devicetree is determined (in fact, that is my main concern),
> as I'm pretty sure it will work with the gmac on hi3520, but I can't
> find a register in the hi3520 datasheet that I could 100% say is the
> right one, and adding the driver to the initrd causes a kernel panic
> (I'm assuming this is because of wrong reg values unless otherwise
> proven) on an otherwise mostly working kernel.
>
As being described in the ./Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt,
the second reg property means MAC_IF control register. The bits layout in this register of
hix5hd2 is like this:
Bits Access Name Description
[31:20] RO reserved reserved
[19] RO phy_link_status 0:Link Down 1:Link Up
[18:17] RO phy_link_speed 00:2.5MHz 01:25MHz 10:125MHz 11:reserved
[16] RO phy_link_mode 0:full duplex 1:half duplex
[15:9] RO reserved reserved
[8] RW loopback_mode 0:disable 1:enable
[7:5] RW phy_select 000:GMII/MII Mode 001:RGMII mode 002:RMII mode
[4] RW duplex_mode 0:full 1:half
[3] RW tx_config 0:disable 1:enable
[2] RW link_status 0:Link Down 1:Link Up
[1] RW mac_speed 0:10Mbps 1:100Mbps
[0] RW port_select 0:1000Mbps 1:10/1000Mbps
I have no hi3520 datasheet,either.I'm not sure about that they use the same gmac IP block.
I hope this information can help you.
Regards,
Jiancheng
^ permalink raw reply
* [PATCH v2] extcon: Add support for qcom SPMI PMIC USB id detection hardware
From: Chanwoo Choi @ 2016-09-12 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909214847.20103-1-stephen.boyd@linaro.org>
Hi Stephen,
Looks good to me.
But, there are something that need to be modified.
- add the author information
- add the description of driver
- use the extcon_set_state() instead of extcon_set_cable_state_()
I modified this patch and applied it because I should send
the pull request within this week after releasing the rc6.
I added the comment about the modification.
On 2016? 09? 10? 06:48, Stephen Boyd wrote:
> Some Qualcomm PMICs have a misc device that performs USB id pin
> detection via an interrupt. When the interrupt triggers, we
> should read the interrupt line to see if it has gone high or low.
> If the interrupt is low then the ID pin is grounded, and if the
> interrupt is high then the ID pin is being held high.
>
> Cc: Roger Quadros <rogerq@ti.com>
> Cc: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>
> Changes from v1:
> * Fixed Makefile ordering
> * Fixed up copyright markings
>
> .../bindings/extcon/qcom,pm8941-misc.txt | 41 +++++
> drivers/extcon/Kconfig | 6 +
> drivers/extcon/Makefile | 1 +
> drivers/extcon/extcon-qcom-spmi-misc.c | 167 +++++++++++++++++++++
> 4 files changed, 215 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
> create mode 100644 drivers/extcon/extcon-qcom-spmi-misc.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
> new file mode 100644
> index 000000000000..35383adb10f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
> @@ -0,0 +1,41 @@
> +Qualcomm's PM8941 USB ID Extcon device
> +
> +Some Qualcomm PMICs have a "misc" module that can be used to detect when
> +the USB ID pin has been pulled low or high.
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: Should contain "qcom,pm8941-misc";
> +
> +- reg:
> + Usage: required
> + Value type: <u32>
> + Definition: Should contain the offset to the misc address space
> +
> +- interrupts:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Should contain the usb id interrupt
> +
> +- interrupt-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain the string "usb_id" for the usb id interrupt
> +
> +Example:
> +
> + pmic {
> + usb_id: misc at 900 {
> + compatible = "qcom,pm8941-misc";
> + reg = <0x900>;
> + interrupts = <0x0 0x9 0 IRQ_TYPE_EDGE_BOTH>;
> + interrupt-names = "usb_id";
> + };
> + }
> +
> + usb-controller {
> + extcon = <&usb_id>;
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 3d89e60a3e71..04788d92ea52 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -96,6 +96,12 @@ config EXTCON_PALMAS
> Say Y here to enable support for USB peripheral and USB host
> detection by palmas usb.
>
> +config EXTCON_QCOM_SPMI_MISC
> + tristate "Qualcomm USB extcon support"
> + help
> + Say Y here to enable SPMI PMIC based USB cable detection
> + support on Qualcomm PMICs such as PM8941.
> +
> config EXTCON_RT8973A
> tristate "Richtek RT8973A EXTCON support"
> depends on I2C
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 972c813c375b..31a0a999c4fb 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> +obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += extcon-qcom-spmi-misc.o
> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
> obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
> diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c b/drivers/extcon/extcon-qcom-spmi-misc.c
> new file mode 100644
> index 000000000000..1b8e24494c60
> --- /dev/null
> +++ b/drivers/extcon/extcon-qcom-spmi-misc.c
> @@ -0,0 +1,167 @@
> +/**
> + * Based on extcon-usb-gpio.c
I think that following description is better than before.
I'll modify it.
* extcon-qcom-spmi-misc.c - Qualcomm USB extcon driver to support USB ID
* detection based on extcon-usb-gpio.c.
> + *
> + * Copyright (C) 2016 Linaro Ltd
s/Ltd/Ltd.
You are missing the author information. I'll add following information:
* Stephen Boyd <stephen.boyd@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/extcon.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/workqueue.h>
> +
> +#define USB_ID_DEBOUNCE_MS 5 /* ms */
> +
> +struct qcom_usb_extcon_info {
> + struct extcon_dev *edev;
> + int irq;
> + struct delayed_work wq_detcable;
> + unsigned long debounce_jiffies;
> +};
> +
> +static const unsigned int qcom_usb_extcon_cable[] = {
> + EXTCON_USB_HOST,
> + EXTCON_NONE,
> +};
> +
> +static void qcom_usb_extcon_detect_cable(struct work_struct *work)
> +{
> + bool id;
> + int ret;
> + struct qcom_usb_extcon_info *info = container_of(to_delayed_work(work),
> + struct qcom_usb_extcon_info,
> + wq_detcable);
> +
> + /* check ID and update cable state */
> + ret = irq_get_irqchip_state(info->irq, IRQCHIP_STATE_LINE_LEVEL, &id);
> + if (ret)
> + return;
> +
> + extcon_set_cable_state_(info->edev, EXTCON_USB_HOST, !id);
The extcon_set_cable_state_() is deprecated.
Instead, I'll modify it using extcon_set_state() as following:
extcon_set_state(info->edev, EXTCON_USB_HOST, !id);
> +}
> +
> +static irqreturn_t qcom_usb_irq_handler(int irq, void *dev_id)
> +{
> + struct qcom_usb_extcon_info *info = dev_id;
> +
> + queue_delayed_work(system_power_efficient_wq, &info->wq_detcable,
> + info->debounce_jiffies);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int qcom_usb_extcon_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct qcom_usb_extcon_info *info;
> + int ret;
> +
> + info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + info->edev = devm_extcon_dev_allocate(dev, qcom_usb_extcon_cable);
> + if (IS_ERR(info->edev)) {
> + dev_err(dev, "failed to allocate extcon device\n");
> + return -ENOMEM;
> + }
> +
> + ret = devm_extcon_dev_register(dev, info->edev);
> + if (ret < 0) {
> + dev_err(dev, "failed to register extcon device\n");
> + return ret;
> + }
> +
> + info->debounce_jiffies = msecs_to_jiffies(USB_ID_DEBOUNCE_MS);
> + INIT_DELAYED_WORK(&info->wq_detcable, qcom_usb_extcon_detect_cable);
> +
> + info->irq = platform_get_irq_byname(pdev, "usb_id");
> + if (info->irq < 0)
> + return info->irq;
> +
> + ret = devm_request_threaded_irq(dev, info->irq, NULL,
> + qcom_usb_irq_handler,
> + IRQF_TRIGGER_RISING |
> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> + pdev->name, info);
> + if (ret < 0) {
> + dev_err(dev, "failed to request handler for ID IRQ\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, info);
> + device_init_wakeup(dev, 1);
> +
> + /* Perform initial detection */
> + qcom_usb_extcon_detect_cable(&info->wq_detcable.work);
> +
> + return 0;
> +}
> +
> +static int qcom_usb_extcon_remove(struct platform_device *pdev)
> +{
> + struct qcom_usb_extcon_info *info = platform_get_drvdata(pdev);
> +
> + cancel_delayed_work_sync(&info->wq_detcable);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int qcom_usb_extcon_suspend(struct device *dev)
> +{
> + struct qcom_usb_extcon_info *info = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + if (device_may_wakeup(dev))
> + ret = enable_irq_wake(info->irq);
> +
> + return ret;
> +}
> +
> +static int qcom_usb_extcon_resume(struct device *dev)
> +{
> + struct qcom_usb_extcon_info *info = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + if (device_may_wakeup(dev))
> + ret = disable_irq_wake(info->irq);
> +
> + return ret;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(qcom_usb_extcon_pm_ops,
> + qcom_usb_extcon_suspend, qcom_usb_extcon_resume);
> +
> +static const struct of_device_id qcom_usb_extcon_dt_match[] = {
> + { .compatible = "qcom,pm8941-misc", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, qcom_usb_extcon_dt_match);
> +
> +static struct platform_driver qcom_usb_extcon_driver = {
> + .probe = qcom_usb_extcon_probe,
> + .remove = qcom_usb_extcon_remove,
> + .driver = {
> + .name = "extcon-pm8941-misc",
> + .pm = &qcom_usb_extcon_pm_ops,
> + .of_match_table = qcom_usb_extcon_dt_match,
> + },
> +};
> +module_platform_driver(qcom_usb_extcon_driver);
> +
> +MODULE_DESCRIPTION("QCOM USB ID extcon driver");
You are missing the author information. I'll add it as following:
MODULE_AUTHOR("Stephen Boyd <stephen.boyd@linaro.org>");
> +MODULE_LICENSE("GPL v2");
>
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v3] arm64: Improve kprobes test for atomic sequence
From: David Long @ 2016-09-12 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160910144841.1bbbffd8548128146df11a41@kernel.org>
On 09/10/2016 01:48 AM, Masami Hiramatsu wrote:
> On Fri, 9 Sep 2016 15:26:09 -0400
> David Long <dave.long@linaro.org> wrote:
>
>> From: "David A. Long" <dave.long@linaro.org>
>>
>> Kprobes searches backwards a finite number of instructions to determine if
>> there is an attempt to probe a load/store exclusive sequence. It stops when
>> it hits the maximum number of instructions or a load or store exclusive.
>> However this means it can run up past the beginning of the function and
>> start looking at literal constants. This has been shown to cause a false
>> positive and blocks insertion of the probe. To fix this, further limit the
>> backwards search to stop if it hits a symbol address from kallsyms. The
>> presumption is that this is the entry point to this code (particularly for
>> the common case of placing probes at the beginning of functions).
>>
>> This also improves efficiency by not searching code that is not part of the
>> function. There may be some possibility that the label might not denote the
>> entry path to the probed instruction but the likelihood seems low and this
>> is just another example of how the kprobes user really needs to be
>> careful about what they are doing.
>
> Of course user should be careful, but also, in such case, kernel can reject
> to probe it.
>
I'm not exactly sure what you mean. I'm just saying when everything
goes right we still cannot promise perfection in detecting a probe
within an atomic sequence. This patch will reject a probe that is after
a ldx and has no intervening kallsyms label (and assuming it's within
the defined maximum count of subsequent instructions).
>
>>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> ---
>> arch/arm64/kernel/probes/decode-insn.c | 48 ++++++++++++++++------------------
>> 1 file changed, 23 insertions(+), 25 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c
>> index 37e47a9..a691112 100644
>> --- a/arch/arm64/kernel/probes/decode-insn.c
>> +++ b/arch/arm64/kernel/probes/decode-insn.c
>> @@ -16,6 +16,7 @@
>> #include <linux/kernel.h>
>> #include <linux/kprobes.h>
>> #include <linux/module.h>
>> +#include <linux/kallsyms.h>
>> #include <asm/kprobes.h>
>> #include <asm/insn.h>
>> #include <asm/sections.h>
>> @@ -122,7 +123,7 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
>> static bool __kprobes
>> is_probed_address_atomic(kprobe_opcode_t *scan_start, kprobe_opcode_t *scan_end)
>> {
>> - while (scan_start > scan_end) {
>> + while (scan_start >= scan_end) {
>> /*
>> * atomic region starts from exclusive load and ends with
>> * exclusive store.
>> @@ -142,33 +143,30 @@ arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
>> {
>> enum kprobe_insn decoded;
>> kprobe_opcode_t insn = le32_to_cpu(*addr);
>> - kprobe_opcode_t *scan_start = addr - 1;
>> - kprobe_opcode_t *scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
>> -#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
>> - struct module *mod;
>> -#endif
>> -
>> - if (addr >= (kprobe_opcode_t *)_text &&
>> - scan_end < (kprobe_opcode_t *)_text)
>> - scan_end = (kprobe_opcode_t *)_text;
>> -#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
>> - else {
>> - preempt_disable();
>> - mod = __module_address((unsigned long)addr);
>> - if (mod && within_module_init((unsigned long)addr, mod) &&
>> - !within_module_init((unsigned long)scan_end, mod))
>> - scan_end = (kprobe_opcode_t *)mod->init_layout.base;
>> - else if (mod && within_module_core((unsigned long)addr, mod) &&
>> - !within_module_core((unsigned long)scan_end, mod))
>> - scan_end = (kprobe_opcode_t *)mod->core_layout.base;
>> - preempt_enable();
>> + kprobe_opcode_t *scan_end = 0;
>
> Please use NULL for pointer.
>
A change has been made for v4.
>> + unsigned long size = 0, offset = 0;
>> +
>> + /*
>> + * If there's a symbol defined in front of and near enough to
>> + * the probe address assume it is the entry point to this
>> + * code and use it to further limit how far back we search
>> + * when determining if we're in an atomic sequence. If we could
>> + * not find any symbol skip the atomic test altogether as we
>> + * could otherwise end up searching irrelevant text/literals.
>> + * KPROBES depends on KALLSYMS so this last case should never
>> + * happen.
>> + */
>> + if (kallsyms_lookup_size_offset((unsigned long) addr, &size, &offset)) {
>> + if (offset < (MAX_ATOMIC_CONTEXT_SIZE*sizeof(kprobe_opcode_t)))
>> + scan_end = addr - (offset / sizeof(kprobe_opcode_t));
>> + else
>> + scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
>
> } else
> return INSN_REJECTED;
>
> that is what I expected...
>
> Thank you,
>
>> }
>> -#endif
>> decoded = arm_probe_decode_insn(insn, asi);
>>
>> - if (decoded == INSN_REJECTED ||
>> - is_probed_address_atomic(scan_start, scan_end))
>> - return INSN_REJECTED;
>> + if (decoded != INSN_REJECTED && scan_end)
>> + if (is_probed_address_atomic(addr - 1, scan_end))
>> + return INSN_REJECTED;
>>
>> return decoded;
>> }
>> --
>> 2.5.0
>>
>
>
Thanks,
-dl
^ permalink raw reply
* [PATCH 7/8] clocksource: Kconfig: Modify CMT config support 64bit
From: Bui Duc Phuc @ 2016-09-12 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4193048.IXigyaYqrQ@avalon>
Hi Laurent
Thank you for your comments.
> I think you should instead add
>
> select SH_TIMER_CMT
>
> to the config ARCH_RENESAS section in arch/arm64/Kconfig.platforms
I will update in V2.
--
Regards,
Bui Duc Phuc
^ permalink raw reply
* [PATCH 1/8] ARM: dts: bcm283x: Define standard pinctrl groups in the gpio node.
From: Dave Stevenson @ 2016-09-11 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737l893d2.fsf@eliezer.anholt.net>
On 09/09/16 22:20, Eric Anholt wrote:
> e<#secure method=pgpmime mode=sign>
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
>> Hi,
>>
>>> According to this page [1] the pinctrl group for parallel display interface is
>>> missing. Is it intended?
>>>
>>> [1] - http://elinux.org/RPi_BCM2835_GPIOs
>> Just an oversight I guess. Eric?
>>
>> Does this look correct?
>>
>> + dpi_gpio4: dpi_gpio4 {
>> + brcm,pins = <4 5 6 7 8 9 10 11 12 13
>> + 14 15 16 17 18 19 20 21
>> + 22 23 24 25 26 27>;
>> + brcm,function = <BCM2835_FSEL_ALT2>;
>> + };
> For DPI, you also need pins 0-3 in there for clock and syncs.
>
> That set of data pins would be for a 24-bit mode, which is what we
> should be using for the Adafruit kippah + 7" panel combo.
The Kippah is only 18bit, RGB666.
https://www.adafruit.com/products/2454
"The pins used are GPIO 2 through 21 inclusive. That means you don't get
the UART RX/TX pins (no console cable) and you don't get the standard
user I2C pins, the EEPROM I2C pins, or hardware SPI pins. You do get to
use pins #22, #23, #24, #25, #26 and #27, and the USB ports are fine to
use too."
On the forum there are some that report they have used DPI in RGB888,
but they're not using the Kippah. I had mentioned this to Phil E that
there should be a dpi18 overlay, but not got around to sorting that.
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
>
^ permalink raw reply
* [GIT PULL] Allwinner arm64 config changes for 4.9
From: Maxime Ripard @ 2016-09-11 21:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof,
Please pull the following patch for the next merge window.
Thanks!
Maxime
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-config64-for-4.9
for you to fetch changes up to d229d205132bfd75fa0cf36fce24264ed01de28a:
arm64: sunxi: Kconfig: add essential pinctrl driver (2016-08-23 21:37:17 +0200)
----------------------------------------------------------------
Allwinner ARM64 Kconfig changes
Select the pinctrl driver in kconfig
----------------------------------------------------------------
Andre Przywara (1):
arm64: sunxi: Kconfig: add essential pinctrl driver
arch/arm64/Kconfig.platforms | 2 ++
1 file changed, 2 insertions(+)
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160911/ae4db3b7/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL] Allwinner core changes for 4.9
From: Maxime Ripard @ 2016-09-11 21:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof,
Please pull the following changes for the next merge window.
Thanks!
Maxime
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-core-for-4.9
for you to fetch changes up to c1efda1238be1efa8612e26ee98795298ffd6f95:
ARM: sunxi: Support the Nextthing GR8 (2016-09-08 14:32:23 +0200)
----------------------------------------------------------------
Allwinner core changes for 4.9
Add support for big endian on the Allwinner A20, and the Nextthing GR8 SoC
----------------------------------------------------------------
Maxime Ripard (1):
ARM: sunxi: Support the Nextthing GR8
Michael Weiser (1):
ARM: sunxi: enable big-endian
Documentation/arm/sunxi/README | 2 ++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
MAINTAINERS | 1 +
arch/arm/mach-sunxi/Kconfig | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
5 files changed, 6 insertions(+)
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160911/ed8910f1/attachment.sig>
^ permalink raw reply
* [GIT PULL] Allwinner DRM changes for 4.9
From: Maxime Ripard @ 2016-09-11 21:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi David,
Please pull the following patches for the next merge window.
Thanks!
Maxime
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-drm-for-4.9
for you to fetch changes up to 0c3ff44cc23cbede56aa1ca5916b126e681ca69b:
drm/sun4i: add missing header dependencies (2016-09-08 14:55:48 +0200)
----------------------------------------------------------------
Allwinner DRM changes for 4.9
This tag adds the support of a new SoC to sun4i-drm (the Allwinner A33),
and the usual few fixes and enhancements
----------------------------------------------------------------
Baoyou Xie (1):
drm/sun4i: add missing header dependencies
Chen-Yu Tsai (1):
drm/sun4i: Clear encoder->bridge if a bridge is not found
Jonathan Liu (1):
drm/sun4i: rgb: add missing calls to drm_panel_{prepare,unprepare}
Maxime Ripard (7):
drm/sun4i: Store TCON's device structure pointer
drm/sun4i: Move panel retrieval in RGB connector
drm/sun4i: Add bridge support
drm/sun4i: support TCONs without channel 1
drm/sun4i: support A33 tcon
drm/sun4i: backend: Handle the SAT
drm/sun4i: Add a DRC driver
Wei Yongjun (1):
drm/sun4i: Remove redundant dev_err call in sun4i_tcon_init_regmap()
.../bindings/display/sunxi/sun4i-drm.txt | 43 +++++++-
drivers/gpu/drm/sun4i/Makefile | 2 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 61 +++++++++++
drivers/gpu/drm/sun4i/sun4i_backend.h | 3 +
drivers/gpu/drm/sun4i/sun4i_dotclock.c | 1 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 12 ++-
drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 1 +
drivers/gpu/drm/sun4i/sun4i_rgb.c | 71 ++++++++++---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 98 ++++++++++++-----
drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 ++
drivers/gpu/drm/sun4i/sun6i_drc.c | 118 +++++++++++++++++++++
11 files changed, 365 insertions(+), 51 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun6i_drc.c
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160911/3ab18d55/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: Fix LEDs for igepv5
From: Tony Lindgren @ 2016-09-11 20:50 UTC (permalink / raw)
To: linux-arm-kernel
The LEDs on igepv5 are on the GPIO expander unlike on omap5-uevm.
Configuration copied from git.isee.biz git tree except fixed for
red and blue mapping.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap5-board-common.dtsi | 10 ----------
arch/arm/boot/dts/omap5-igep0050.dts | 19 +++++++++++++++++++
arch/arm/boot/dts/omap5-uevm.dts | 10 ++++++++++
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -77,16 +77,6 @@
reset-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>; /* gpio3_79 ETH_NRESET */
};
- leds {
- compatible = "gpio-leds";
- led1 {
- label = "omap5:blue:usr1";
- gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>; /* gpio5_153 D1 LED */
- linux,default-trigger = "heartbeat";
- default-state = "off";
- };
- };
-
tpd12s015: encoder {
compatible = "ti,tpd12s015";
diff --git a/arch/arm/boot/dts/omap5-igep0050.dts b/arch/arm/boot/dts/omap5-igep0050.dts
--- a/arch/arm/boot/dts/omap5-igep0050.dts
+++ b/arch/arm/boot/dts/omap5-igep0050.dts
@@ -30,6 +30,25 @@
gpios = <&gpio4 22 GPIO_ACTIVE_HIGH>;
};
};
+
+ leds {
+ compatible = "gpio-leds";
+ led at 1 {
+ label = "board:green:usr0";
+ gpios = <&tca6416 1 0>;
+ default-state = "off";
+ };
+ led at 2 {
+ label = "board:red:usr1";
+ gpios = <&tca6416 2 0>;
+ default-state = "off";
+ };
+ led at 3 {
+ label = "board:blue:usr1";
+ gpios = <&tca6416 3 0>;
+ default-state = "off";
+ };
+ };
};
&hdmi {
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -17,6 +17,16 @@
device_type = "memory";
reg = <0 0x80000000 0 0x7f000000>; /* 2032 MB */
};
+
+ leds {
+ compatible = "gpio-leds";
+ led1 {
+ label = "omap5:blue:usr1";
+ gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>; /* gpio5_153 D1 LED */
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+ };
};
&hdmi {
--
2.9.3
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.9, take 2
From: Maxime Ripard @ 2016-09-11 20:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Please pull the following branch for 4.9, based on top of the previous
one.
To maintain bisectability, while avoiding some un-trivial merge
conflicts, I had to merge the clk branch that I've sent a PR to Mike
and Stephen. This branch will of course be stable.
Thanks!
Maxime
The following changes since commit bdc2601b02d31974b5765b93ac263b2eeab2e07c:
Merge branch 'sunxi/clk-for-4.9' into sunxi/dt-for-4.9 (2016-09-10 11:45:28 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-for-4.9-2
for you to fetch changes up to 7a988a4dd29a8cfcf405a12441533d765d25a6b8:
ARM: dts: gr8: Add support for the GR8 evaluation board (2016-09-11 22:23:17 +0200)
----------------------------------------------------------------
Allwinner DT changes for 4.9, take 2
A second set of device tree changes, this time switching a few SoCs to the
new sunxi-ng clock framework. We also added the support for a new SoC
(NextThing GR8 and its evaluation board), and the support for the DRM
driver in the A33.
----------------------------------------------------------------
Chen-Yu Tsai (2):
ARM: dts: sun6i: switch A31/A31s to new CCU clock bindings
ARM: dts: sun8i: Move A23/A33 usbphy and usb_otg nodes to common dtsi
Maxime Ripard (3):
ARM: sun8i: Convert the A23 and A33 to the CCU
ARM: sun8i: a33: Add display pipeline
ARM: sun8i: a23/a33: Add RGB666 pins
Myl?ne Josserand (2):
ARM: dts: Add NextThing GR8 dtsi
ARM: dts: gr8: Add support for the GR8 evaluation board
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/ntc-gr8-evb.dts | 342 +++++++++++
arch/arm/boot/dts/ntc-gr8.dtsi | 1087 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/sun6i-a31.dtsi | 424 +++----------
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 295 +++------
arch/arm/boot/dts/sun8i-a23.dtsi | 80 +--
arch/arm/boot/dts/sun8i-a33.dtsi | 236 +++++---
7 files changed, 1791 insertions(+), 674 deletions(-)
create mode 100644 arch/arm/boot/dts/ntc-gr8-evb.dts
create mode 100644 arch/arm/boot/dts/ntc-gr8.dtsi
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160911/08fd7c31/attachment.sig>
^ permalink raw reply
* [GIT PULL] Allwinner clocks changes for 4.9
From: Maxime Ripard @ 2016-09-11 20:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the usual bunch of clock patches for the Allwinner SoCs, this
time converting more SoCs to the new framework.
Thanks!
Maxime
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-clk-for-4.9
for you to fetch changes up to d63a5e7c713a68bd368016f2022326a1a91310d8:
clk: sunxi-ng: Add hardware dependency (2016-09-10 11:41:21 +0200)
----------------------------------------------------------------
Allwinner Clock changes for 4.9
Four more SoCs converted to the new clock framework (A31, A31s, A23 and
A33).
----------------------------------------------------------------
Chen-Yu Tsai (6):
clk: sunxi-ng: mux: Increase fixed pre-divider div size
clk: sunxi-ng: nkm: Add mux to support multiple parents
clk: sunxi-ng: mux: Add support for mux tables
clk: sunxi-ng: mux: support fixed pre-dividers on multiple parents
clk: sunxi-ng: mux: Add clk notifier functions
clk: sunxi-ng: Add A31/A31s clocks
Jean Delvare (1):
clk: sunxi-ng: Add hardware dependency
Maxime Ripard (8):
clk: sunxi-ng: mux: Rename mux macro to be consistent
clk: sunxi-ng: div: Add mux table macros
clk: sunxi-ng: div: Add kerneldoc for the _ccu_div structure
clk: sunxi-ng: div: Allow to set a maximum
clk: sunxi-ng: mux: Add mux table macro
clk: sunxi-ng: Add N-class clocks support
clk: sunxi-ng: Add A33 CCU support
clk: sunxi-ng: Add A23 CCU
.../devicetree/bindings/clock/sunxi-ccu.txt | 5 +-
drivers/clk/sunxi-ng/Kconfig | 39 +
drivers/clk/sunxi-ng/Makefile | 4 +
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 1235 ++++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun6i-a31.h | 72 ++
drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h | 63 +
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 737 ++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 780 +++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 +-
drivers/clk/sunxi-ng/ccu_div.h | 66 +-
drivers/clk/sunxi-ng/ccu_mp.c | 23 +-
drivers/clk/sunxi-ng/ccu_mp.h | 2 +-
drivers/clk/sunxi-ng/ccu_mult.c | 133 +++
drivers/clk/sunxi-ng/ccu_mult.h | 35 +
drivers/clk/sunxi-ng/ccu_mux.c | 56 +-
drivers/clk/sunxi-ng/ccu_mux.h | 68 +-
drivers/clk/sunxi-ng/ccu_nkm.c | 44 +-
drivers/clk/sunxi-ng/ccu_nkm.h | 23 +
drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +-
drivers/clk/sunxi-ng/ccu_nm.c | 16 +-
include/dt-bindings/clock/sun6i-a31-ccu.h | 187 +++
include/dt-bindings/clock/sun8i-a23-a33-ccu.h | 127 ++
include/dt-bindings/reset/sun6i-a31-ccu.h | 106 ++
include/dt-bindings/reset/sun8i-a23-a33-ccu.h | 87 ++
24 files changed, 3860 insertions(+), 79 deletions(-)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun6i-a31.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun6i-a31.h
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a23.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a33.c
create mode 100644 drivers/clk/sunxi-ng/ccu_mult.c
create mode 100644 include/dt-bindings/clock/sun6i-a31-ccu.h
create mode 100644 include/dt-bindings/clock/sun8i-a23-a33-ccu.h
create mode 100644 include/dt-bindings/reset/sun6i-a31-ccu.h
create mode 100644 include/dt-bindings/reset/sun8i-a23-a33-ccu.h
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160911/71472c94/attachment.sig>
^ 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