* Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Heiko Stuebner @ 2017-01-12 1:28 UTC (permalink / raw)
To: Doug Anderson
Cc: Xing Zheng, open list:ARM/Rockchip SoC..., Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Caesar Wang,
Shawn Lin, Brian Norris, Jianqun Xu, Elaine Zhang, David Wu,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAD=FV=WMQ22G67YoQx2t7J6_ZuB3sUjVjXh-0KhPEO_6zbiyUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Am Mittwoch, 11. Januar 2017, 16:50:10 CET schrieb Doug Anderson:
> Hi,
>
> On Tue, Jan 10, 2017 at 11:58 AM, Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> > Hi Doug,
> >
> > Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko Stübner:
> >> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> >> > Hi,
> >> >
> >> > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >>
> >> wrote:
> >> > > The structure rockchip_clk_provider needs to refer the GRF regmap
> >> > > in somewhere, if the CRU node has not "rockchip,grf" property,
> >> > > calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> >> > > regmap, and the MUXGRF type clock will be not supported.
> >> > >
> >> > > Therefore, we need to add them.
> >> > >
> >> > > Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >> > > ---
> >> > >
> >> > > Changes in v4:
> >> > > - separte the binding patch
> >> > >
> >> > > Changes in v3:
> >> > > - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
> >> > >
> >> > > Changes in v2:
> >> > > - referring pmugrf for PMUGRU
> >> > > - fix the typo "invaild" in COMMIT message
> >> > >
> >> > > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >> > > 1 file changed, 2 insertions(+)
> >> >
> >> > This seems fine to me, so:
> >> >
> >> > Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> >
> >> > ...but I will say that before you actually add any real "MUXGRF"
> >> > clocks on rk3399 you _might_ need to rework the code to make things
> >> > truly "optional". If it turns out that any existing clocks that
> >> > already exist today already go through one of these muxes in the GRF
> >> > and we've always been assuming one setting of the mux, we'll need to
> >> > make sure we keep assuming that setting of the mux even if the "grf"
> >> > isn't specified.
> >>
> >> I guess I see that a bit more relaxed :-) .
> >>
> >> I.e. the GRF being optional is a remnant of syscons not being available
> >> when the clocks get set up- so were coming in later or not at all. For
> >> the rk3288 I converted, there we never really had the case of the GRF
> >> missing.
> >>
> >> And the GRF mux for the vcodec now present is not being used by anything
> >> yet (neither driver nor binding), so no old devicetree can break.
> >>
> >> > As I understand it, your motivation for this patch is to eventually be
> >> > able to model the EDP reference clock which can either be xin24 or
> >> > "edp osc". Presumably the eDP "reference clock" isn't related to any
> >> > of the pre-existing eDP clocks so that one should be safe.
> >>
> >> Same here, so far we don't even have edp or even any other graphical
> >> output
> >> on the rk3399, so again there is no old devicetree that could break when
> >> the grf is not specified.
> >
> > reading all of the above again, it feels like you essentially also said
> > similar things already in your original reply and I misread some of it.
> >
> > But again, I don't see the need for any more code right now, as hopefully
> > the simple stuff we currently only support does not have any grf-based
> > muxes in it. Xing + Rockchip people, please correct me if I'm wrong here
> > :-)
> Right. I have no objection to Xing's patch. I just want to make sure
> that if it's listed as "Optional" that it's really optional.
>
> I was worried that we would introduce some GRF-based mux in the
> _middle_ of some existing clock tree because we simply didn't model
> the mux before and assumed one particular setting. If nothing like
> that ever happens then we're fine.
Thankfully the clock diagrams on the old socs were pretty verbose, listing all
grf-based clocks as well. For example the rk3288 seems to have two and it
seems I've been carrying dummy definitions for those from the time I did the
initial clock tree [0].
And thankfully grf-based clocks somehow always only get used for more
"esotheric" components like vcodec and iep on the rk3288 :-) .
Heiko
[0] https://github.com/mmind/linux-rockchip/blob/devel/workbench/drivers/clk/rockchip/clk-rk3288.c
lines 371 and 799 .. looks like I'll need to add the iep clock as well
at some point.
--
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 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933
From: Laurent Pinchart @ 2017-01-12 1:31 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-clk, Michael Turquette, Stephen Boyd, Rob Herring,
devicetree, linux-renesas-soc
In-Reply-To: <20170112010324.28068-1-marek.vasut@gmail.com>
Hi Marek,
Thank you for the patch.
On Thursday 12 Jan 2017 02:03:23 Marek Vasut wrote:
> Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips.
> These are I2C clock generators with optional clock source from
> either XTal or dedicated clock generator and, depending on the
> model, two or more clock outputs.
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Please add this tag if you submit a v3.
> ---
> V2: Add mapping between the clock specifier and physical pins of the chip
> ---
> .../devicetree/bindings/clock/idt,versaclock5.txt | 65 +++++++++++++++++++
> 1 file changed, 65 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/idt,versaclock5.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt new file mode
> 100644
> index 000000000000..87e9c47a89a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> @@ -0,0 +1,65 @@
> +Binding for IDT VersaClock5 programmable i2c clock generator.
> +
> +The IDT VersaClock5 are programmable i2c clock generators providing
> +from 3 to 12 output clocks.
> +
> +==I2C device node==
> +
> +Required properties:
> +- compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933".
> +- reg: i2c device address, shall be 0x68 or 0x6a.
> +- #clock-cells: from common clock binding; shall be set to 1.
> +- clocks: from common clock binding; list of parent clock handles,
> + - 5p49v5923: (required) either or both of XTAL or CLKIN
> + reference clock.
> + - 5p49v5933: (optional) property not present (internal
> + Xtal used) or CLKIN reference
> + clock.
> +- clock-names: from common clock binding; clock input names, can be
> + - 5p49v5923: (required) either or both of "xin", "clkin".
> + - 5p49v5933: (optional) property not present or "clkin".
> +
> +==Mapping between clock specifier and physical pins==
> +
> +When referencing the provided clock in the DT using phandle and
> +clock specifier, the following mapping applies:
> +
> +5P49V5923:
> + 0 -- OUT0_SEL_I2CB
> + 1 -- OUT1
> + 2 -- OUT2
> +
> +5P49V5933:
> + 0 -- OUT0_SEL_I2CB
> + 1 -- OUT1
> + 2 -- OUT4
> +
> +==Example==
> +
> +/* 25MHz reference crystal */
> +ref25: ref25m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <25000000>;
> +};
> +
> +i2c-master-node {
> +
> + /* IDT 5P49V5923 i2c clock generator */
> + vc5: clock-generator@6a {
> + compatible = "idt,5p49v5923";
> + reg = <0x6a>;
> + #clock-cells = <1>;
> +
> + /* Connect XIN input to 25MHz reference */
> + clocks = <&ref25m>;
> + clock-names = "xin";
> + };
> +};
> +
> +/* Consumer referencing the 5P49V5923 pin OUT1 */
> +consumer {
> + ...
> + clocks = <&vc5 1>;
> + ...
> +}
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] PCI: rockchip: Add quirk to disable RC's ASPM L0s
From: Shawn Lin @ 2017-01-12 1:44 UTC (permalink / raw)
To: Bjorn Helgaas, Shawn Lin
Cc: Bjorn Helgaas, Rob Herring, linux-pci, linux-rockchip, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree
In-Reply-To: <20170111182822.GC14532@bhelgaas-glaptop.roam.corp.google.com>
On 2017/1/12 2:28, Bjorn Helgaas wrote:
> On Mon, Dec 12, 2016 at 07:51:27PM +0800, Shawn Lin wrote:
>> Rockchip's RC outputs 100MHz reference clock but there are
>> two methods for PHY to generate it.
>>
>> (1)One of them is to use system PLL to generate 100MHz clock and
>> the PHY will relock it and filter signal noise then outputs the
>> reference clock.
>>
>> (2)Another way is to share Soc's 24MHZ crystal oscillator with
>> PHY and force PHY's DLL to generate 100MHz internally.
>>
>> When using case(2), the exit from L0s doesn't work fine occasionally
>> due to the broken design of RC receiver's logical circuit. So even if
>> we use extended-synch, it still fails for PHY to relock the bits from
>> FTS sometimes. This will hang the system.
>>
>> Maybe we could argue that why not use case(1) to avoid it? The reason
>> is that as we could see the reference clock is derived from system PLL
>> and the path from it to PHY isn't so clean which means there are some
>> noise introduced by power-domain and other buses can't be filterd out
>> by PHY and we could see noise from the frequency spectrum by
>> oscilloscope. This makes the TX compatibility test a little difficult
>> to pass the spec. So case(1) and case(2) are both used indeed now. If
>> using case(2), we should disable RC's L0s support, and that is why we
>> need this property to indicate this quirk.
>>
>> Also after checking quirk.c, I noticed there is already a quirk for
>> disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
>> shouldn't do that as mentioned above that case(1) could still works fine
>> with L0s.
>>
>> Reported-by: Jeffy Chen <jeffy.chen@rock-chips.com>
>> Cc: Brian Norris <briannorris@chromium.org>
>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>>
>> ---
>>
>> Changes in v2:
>> - drop the quirk prefix
>>
>> Documentation/devicetree/bindings/pci/rockchip-pcie.txt | 2 ++
>> drivers/pci/host/pcie-rockchip.c | 9 +++++++++
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> index 71aeda1..1453a73 100644
>> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> @@ -43,6 +43,8 @@ Required properties:
>> - interrupt-map-mask and interrupt-map: standard PCI properties
>>
>> Optional Property:
>> +- aspm-no-l0s: RC won't support ASPM L0s. This property is needed if
>> + using 24MHz OSC for RC's PHY.
>> - ep-gpios: contain the entry for pre-reset gpio
>> - num-lanes: number of lanes to use
>> - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
>> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
>> index f2dca7b..35988fc 100644
>> --- a/drivers/pci/host/pcie-rockchip.c
>> +++ b/drivers/pci/host/pcie-rockchip.c
>> @@ -140,6 +140,8 @@
>> #define PCIE_RC_CONFIG_DCR_CSPL_SHIFT 18
>> #define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
>> #define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
>> +#define PCIE_RC_CONFIG_LINK_CAP (PCIE_RC_CONFIG_BASE + 0xcc)
>> +#define PCIE_RC_CONFIG_LINK_CAP_L0S BIT(10)
>> #define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
>> #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
>> #define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
>> @@ -653,6 +655,13 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>> status &= ~PCIE_RC_CONFIG_THP_CAP_NEXT_MASK;
>> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_THP_CAP);
>>
>> + /* Clear L0s from RC's link cap */
>> + if (of_property_read_bool(dev->of_node, "apsm-no-l0s")) {
>
> Did you test this? This string ("apsm-no-l0s") doesn't match the
> "aspm-no-l0s" documented above. The current tree doesn't contain either
> string in any DTS.
>
oops, mea culpa. I think I wrote this and tested it on the kernel4.4
chromeOS tree. There were some non-upstream patches there so I slightly
amend it when rebasing on your next branch, I guess I made the mistake
then.
I will fix this.
>> + status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LINK_CAP);
>> + status &= ~PCIE_RC_CONFIG_LINK_CAP_L0S;
>> + rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LINK_CAP);
>> + }
>> +
>> rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
>>
>> rockchip_pcie_write(rockchip,
>> --
>> 1.9.1
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH v2 0/5] Reset Controller Nodes for TI Keystone platforms
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Philipp Zabel, Rob Herring, Russell King, linux-arm-kernel,
devicetree, linux-kernel, Andrew Davis, Suman Anna
Hi Santosh,
This is a slightly updated patch series for the reset controller nodes for
TI Keystone2 SoCs. The only change is to rename the reset controller nodes
from "psc-reset-controller" to just "reset-controller" following Rob Herring's
comment on the Documentation update patch [1]. There are no changes to the first
2 patches. I have already posted a v2 for the Documentation update as well.
Please pick this up instead of the v1 series [2].
regards
Suman
[1] https://www.spinics.net/lists/arm-kernel/msg553646.html
[2] https://www.spinics.net/lists/arm-kernel/msg552911.html
Suman Anna (5):
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
ARM: dts: keystone: Add PSC node
ARM: dts: keystone-k2hk: Add PSC reset controller node
ARM: dts: keystone-k2l: Add PSC reset controller node
ARM: dts: keystone-k2e: Add PSC reset controller node
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/keystone.dtsi | 5 +++++
arch/arm/mach-keystone/Kconfig | 1 +
5 files changed, 55 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/5] ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Nishanth Menon, devicetree, Russell King, linux-kernel,
Rob Herring, Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Keystone 2 family of SoCs will use various Reset Controller
drivers for managing the resets of remote processor devices like
DSPs on the SoC, so select the ARCH_HAS_RESET_CONTROLLER option
by default to enable the Reset framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
v2: No changes
arch/arm/mach-keystone/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 24bd64dabdfc..554357035f30 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -4,6 +4,7 @@ config ARCH_KEYSTONE
select ARM_GIC
select HAVE_ARM_ARCH_TIMER
select KEYSTONE_TIMER
+ select ARCH_HAS_RESET_CONTROLLER
select ARM_ERRATA_798181 if SMP
select COMMON_CLK_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/5] ARM: dts: keystone: Add PSC node
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Philipp Zabel, Rob Herring, Russell King, linux-arm-kernel,
devicetree, linux-kernel, Andrew Davis, Suman Anna, Dave Gerlach
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module is responsible
for the power and clock management for each of the peripherals
present on the SoC. Represent this as a syscon node so that
multiple users can leverage it for various functionalities.
Signed-off-by: Suman Anna <s-anna@ti.com>
[afd@ti.com: add simple-mfd compatible]
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v2: No changes
arch/arm/boot/dts/keystone.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba2d4f4..ec203d0a673d 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -83,6 +83,11 @@
reg = <0x02310000 0x200>;
};
+ psc: power-sleep-controller@02350000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x02350000 0x1000>;
+ };
+
devctrl: device-state-control@02620000 {
compatible = "ti,keystone-devctrl", "syscon";
reg = <0x02620000 0x1000>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/5] ARM: dts: keystone-k2hk: Add PSC reset controller node
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: devicetree, Russell King, linux-kernel, Rob Herring,
Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2H SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: change reset node name from psc-reset-controller to reset-controller
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2hk.dtsi b/arch/arm/boot/dts/keystone-k2hk.dtsi
index e0780f111537..69d449430511 100644
--- a/arch/arm/boot/dts/keystone-k2hk.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2hk", "ti,keystone";
model = "Texas Instruments Keystone 2 Kepler/Hawking SoC";
@@ -58,6 +60,24 @@
};
};
+ psc: power-sleep-controller@02350000 {
+ pscrst: reset-controller {
+ compatible = "ti,k2hk-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ 0xa4c 8 0xa4c 8 0x84c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 4: dsp4 */
+ 0xa50 8 0xa50 8 0x850 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 5: dsp5 */
+ 0xa54 8 0xa54 8 0x854 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 6: dsp6 */
+ 0xa58 8 0xa58 8 0x858 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 7: dsp7 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio@02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: keystone-k2l: Add PSC reset controller node
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: devicetree, Russell King, linux-kernel, Rob Herring,
Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2L SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: change reset node name from psc-reset-controller to reset-controller
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index b58015737a35..15392d32c572 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2l", "ti,keystone";
model = "Texas Instruments Keystone 2 Lamarr SoC";
@@ -216,6 +218,20 @@
};
};
+ psc: power-sleep-controller@02350000 {
+ pscrst: reset-controller {
+ compatible = "ti,k2l-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio@02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: keystone-k2e: Add PSC reset controller node
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Philipp Zabel, Rob Herring, Russell King, linux-arm-kernel,
devicetree, linux-kernel, Andrew Davis, Suman Anna
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2E SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: change reset node name from psc-reset-controller to reset-controller
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi b/arch/arm/boot/dts/keystone-k2e.dtsi
index 9d1d8a64d10e..0dd4cdd6d40c 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2e", "ti,keystone";
model = "Texas Instruments Keystone 2 Edison SoC";
@@ -94,6 +96,17 @@
};
};
+ psc: power-sleep-controller@02350000 {
+ pscrst: reset-controller {
+ compatible = "ti,k2e-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio@02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v3] PCI: rockchip: Add quirk to disable RC's ASPM L0s
From: Shawn Lin @ 2017-01-12 1:53 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Rob Herring, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree-u79uwXL29TY76Z2rM5mHXA,
Shawn Lin
Rockchip's RC outputs 100MHz reference clock but there are
two methods for PHY to generate it.
(1)One of them is to use system PLL to generate 100MHz clock and
the PHY will relock it and filter signal noise then outputs the
reference clock.
(2)Another way is to share Soc's 24MHZ crystal oscillator with
PHY and force PHY's DLL to generate 100MHz internally.
When using case(2), the exit from L0s doesn't work fine occasionally
due to the broken design of RC receiver's logical circuit. So even if
we use extended-synch, it still fails for PHY to relock the bits from
FTS sometimes. This will hang the system.
Maybe we could argue that why not use case(1) to avoid it? The reason
is that as we could see the reference clock is derived from system PLL
and the path from it to PHY isn't so clean which means there are some
noise introduced by power-domain and other buses can't be filterd out
by PHY and we could see noise from the frequency spectrum by
oscilloscope. This makes the TX compatibility test a little difficult
to pass the spec. So case(1) and case(2) are both used indeed now. If
using case(2), we should disable RC's L0s support, and that is why we
need this property to indicate this quirk.
Also after checking quirk.c, I noticed there is already a quirk for
disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
shouldn't do that as mentioned above that case(1) could still works fine
with L0s.
Reported-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Cc: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v3:
- fix misspelled aspm for the property name
Changes in v2:
- drop the quirk prefix
Documentation/devicetree/bindings/pci/rockchip-pcie.txt | 2 ++
drivers/pci/host/pcie-rockchip.c | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index 71aeda1..1453a73 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -43,6 +43,8 @@ Required properties:
- interrupt-map-mask and interrupt-map: standard PCI properties
Optional Property:
+- aspm-no-l0s: RC won't support ASPM L0s. This property is needed if
+ using 24MHz OSC for RC's PHY.
- ep-gpios: contain the entry for pre-reset gpio
- num-lanes: number of lanes to use
- vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index f2dca7b..140cdc7 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -140,6 +140,8 @@
#define PCIE_RC_CONFIG_DCR_CSPL_SHIFT 18
#define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
#define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
+#define PCIE_RC_CONFIG_LINK_CAP (PCIE_RC_CONFIG_BASE + 0xcc)
+#define PCIE_RC_CONFIG_LINK_CAP_L0S BIT(10)
#define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
#define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
#define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
@@ -653,6 +655,13 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
status &= ~PCIE_RC_CONFIG_THP_CAP_NEXT_MASK;
rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_THP_CAP);
+ /* Clear L0s from RC's link cap */
+ if (of_property_read_bool(dev->of_node, "aspm-no-l0s")) {
+ status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LINK_CAP);
+ status &= ~PCIE_RC_CONFIG_LINK_CAP_L0S;
+ rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LINK_CAP);
+ }
+
rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
rockchip_pcie_write(rockchip,
--
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
* Re: [PATCH v2 0/5] Reset Controller Nodes for TI Keystone platforms
From: santosh.shilimkar @ 2017-01-12 2:28 UTC (permalink / raw)
To: Suman Anna, Santosh Shilimkar
Cc: devicetree, Russell King, linux-kernel, Rob Herring,
Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
On 1/11/17 5:48 PM, Suman Anna wrote:
> Hi Santosh,
>
> This is a slightly updated patch series for the reset controller nodes for
> TI Keystone2 SoCs. The only change is to rename the reset controller nodes
> from "psc-reset-controller" to just "reset-controller" following Rob Herring's
> comment on the Documentation update patch [1]. There are no changes to the first
> 2 patches. I have already posted a v2 for the Documentation update as well.
> Please pick this up instead of the v1 series [2].
>
I haven't picked up V1 so no worries. Even V2 I won't apply for another
week to give some more time if there are any more comments on the
bindings.
Thanks for following up.
Regards,
Santosh
^ permalink raw reply
* RE: [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Jacky Bai @ 2017-01-12 2:57 UTC (permalink / raw)
To: Linus Walleij
Cc: Shawn Guo, Michael Turquette, Stephen Boyd, Rob Herring,
Mark Rutland, Sascha Hauer, Fabio Estevam, Daniel Lezcano,
Thomas Gleixner, Philipp Zabel, linux-clk,
devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, jacky.baip@gmail.com
In-Reply-To: <CACRpkdYTpEHyzBY-mA4YUsj=xt46Pibka3-4VHwUXosfgbgp1Q@mail.gmail.com>
> Subject: Re: [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc
> for imx6sll
>
> On Mon, Jan 9, 2017 at 3:32 AM, Jacky Bai <ping.bai@nxp.com> wrote:
>
> > I have look into the above commit on using generic binding. But I
> > think the generic pinconf is not very easy to add in imx pinctrl Driver. imx
> pinctrl use a different way to parse the pin configure.
>
> OK atleast I need an indication from one of the i.MX maintainers how they
> want to proceed.
>
> > Each fsl,pin entry looks like <PIN_FUNC_ID CONFIG> in dts, the
> > CONFIG is the pad setting value like pull-up, open-drain, drive strength etc.
> The above config bit definition is specific to each SOC in the PAD CTL register.
> >
> > If we want set the pin config to enable hysteresis, 47KOhm Pull Up,
> > 50Mhz speed, 80Ohm driver strength and Fast Slew Rate, then the CONFIG
> value should be 0x17059( ORs corresponding bit definition).
>
> Hysteresis is an input property and does not make sense on something that
> need drive strength and slew rate configuration which are output properties.
> (I guess you mean 80mA drive strength.)
>
For some bi-direction pins, like SD DATA pin, we may need to enable the hysteresis configuration.
> Actually such oxymoronic settings is a good reason to migrate to generic
> bindings because when you describe stuff with generic strings you see better
> what is going on, and we can add sanity checks to cases like this in the generic
> code where it would indeed be valid to ask why this combination of settings is
> being made.
>
Another thing is that we can use a pins-tool program developed by NXP to generate the pinctrl configuration code that can
be used directly in dts. This tiny program can avoid pin function conflict. As on i.MX, there are so may pins, each pin can be used
for up 8 function. Configuring the pins is a time-consuming work. This tools is very useful for customer to generate the dts code.
Using generic pinconf is another option, but it may need more time to add it and more work to do. For now, I think we can still keep the legacy method?
> > This value will be set in
> > PAD CTL register to config the corresponding pin.
>
> Yes? That is common. It looks like that in DT:
>
> {
> input-schmitt-enable;
> bias-pull-up = <47000>;
> slew-rate = <50000000>;
> drive-strength = <80000>;
> };
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 00/24] i.MX Media Driver
From: Steve Longerbeam @ 2017-01-12 3:22 UTC (permalink / raw)
To: Tim Harvey, Steve Longerbeam
Cc: Mark Rutland, andrew-ct.chen, minghsiu.tsai, nick, songjun.wu,
Hans Verkuil, robert.jarzmik, devel, markus.heiser,
laurent.pinchart+renesas, Russell King - ARM Linux, geert,
linux-media, devicetree@vger.kernel.org, Sascha Hauer,
Arnd Bergmann, mchehab, bparrot, Rob Herring, Simon Horman,
tiffany.lin, linux-arm-kernel@lists.infradead.org,
Niklas Söderlund, Greg Kroah-Hartman
In-Reply-To: <CAJ+vNU2zU++Xam_UpDPfmSQhauhhS3_z8L-+ww6o-D9brWhiwA@mail.gmail.com>
Hi Tim,
On 01/11/2017 03:14 PM, Tim Harvey wrote:
>
> <snip>
>
> Hi Steve,
>
> I took a stab at testing this today on a gw51xx which has an adv7180
> hooked up as follows:
> - i2c3@0x20
> - 8bit data bus from DAT12 to DAT19, HSYNC, VSYNC, PIXCLK on CSI0 pads
> (CSI0_IPU1)
> - PWRDWN# on MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20
> - IRQ# on MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23
> - all three analog inputs available to off-board connector
>
> My patch to the imx6qdl-gw51xx dtsi is:
As long as you used the patch to imx6qdl-sabreauto.dtsti that adds
the adv7180 support as a guide, you should be ok here.
> <snip>
>
>
>
> On an IMX6Q I'm getting the following when the adv7180 module loads:
> [ 12.862477] adv7180 2-0020: chip found @ 0x20 (21a8000.i2c)
> [ 12.907767] imx-media: Registered subdev adv7180 2-0020
> [ 12.907793] imx-media soc:media@0: Entity type for entity adv7180
> 2-0020 was not initialized!
> [ 12.907867] imx-media: imx_media_create_link: adv7180 2-0020:0 ->
> ipu1_csi0_mux:1
>
> Is the warning that adv7180 was not initialized expected and or an issue?
Yeah it's still a bug in the adv7180 driver, needs fixing.
>
> Now that your driver is hooking into the current media framework, I'm
> not at all clear on how to link and configure the media entities.
It's all documented at Documentation/media/v4l-drivers/imx.rst.
Follow the SabreAuto pipeline setup example.
> <snip>
>
>
> Additionally I've found that on an IMX6S/IMX6DL we crash while
> registering the media-ic subdev's:
> [ 3.975473] imx-media: Registered subdev ipu1_csi1_mux
> [ 3.980921] imx-media: Registered subdev ipu1_csi0_mux
> [ 4.003205] imx-media: Registered subdev ipu1_ic_prpenc
> [ 4.025373] imx-media: Registered subdev ipu1_ic_prpvf
> [ 4.037944] ------------[ cut here ]------------
> [ 4.042571] Kernel BUG at c06717dc [verbose debug info unavailable]
> [ 4.048845] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [ 4.053990] Modules linked in:
> [ 4.057076] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 4.9.0-rc6-00524-g84dad6e-dirty #446
> [ 4.065260] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> ...
> [ 4.296250] [<c0671780>] (v4l2_subdev_init) from [<c06fb02c>]
> (imx_ic_probe+0x94/0x1ac)
> [ 4.304271] [<c06faf98>] (imx_ic_probe) from [<c05173d8>]
> (platform_drv_probe+0x54/0xb8)
> [ 4.312373] r9:c0d5e858 r8:00000000 r7:fffffdfb r6:c0e5dbf8
> r5:da603810 r4:c16738d8
> [ 4.320129] [<c0517384>] (platform_drv_probe) from [<c0515978>]
> (driver_probe_device+0x20c/0x2c0)
> [ 4.329010] r7:c0e5dbf8 r6:00000000 r5:da603810 r4:c16738d8
> [ 4.334681] [<c051576c>] (driver_probe_device) from [<c0515af4>]
> (__driver_attach+0xc8/0xcc)
> [ 4.343129] r9:c0d5e858 r8:00000000 r7:00000000 r6:da603844
> r5:c0e5dbf8 r4:da603810
> [ 4.350889] [<c0515a2c>] (__driver_attach) from [<c0513adc>]
> (bus_for_each_dev+0x74/0xa8)
> [ 4.359078] r7:00000000 r6:c0515a2c r5:c0e5dbf8 r4:00000000
> [ 4.364753] [<c0513a68>] (bus_for_each_dev) from [<c05151d4>]
> (driver_attach+0x20/0x28)
>
> I assume there is an iteration that needs a test on a missing pointer
> only available on chips with both IPU's or PRP
Yep, I only have quad boards here so I haven't gotten around to
testing on S/DL.
But it looks like I forgot to clear out the csi subdev pointer array before
passing it to imx_media_of_parse(). I think that might explain the OOPS
above. Try this patch:
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index 357654d..0cf2d61 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -379,7 +379,7 @@ static int imx_media_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *node = dev->of_node;
- struct imx_media_subdev *csi[4];
+ struct imx_media_subdev *csi[4] = {0};
struct imx_media_dev *imxmd;
int ret;
Steve
^ permalink raw reply related
* Re: [PATCH 3/4] dt-bindings: power/supply: Update TPS65217 properties
From: Sebastian Reichel @ 2017-01-12 3:47 UTC (permalink / raw)
To: Milo Kim
Cc: bcousson, Tony Lindgren, Arnd Bergmann, Lee Jones,
Dmitry Torokhov, linux-omap, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161209062833.5768-4-woogyom.kim@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
Hi Milo,
On Fri, Dec 09, 2016 at 03:28:32PM +0900, Milo Kim wrote:
> Add interrupt specifiers for USB and AC charger input. Interrupt numbers
> are from the datasheet.
> Fix wrong property for compatible string.
>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> ---
> .../devicetree/bindings/power/supply/tps65217_charger.txt | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
> index 98d131a..a11072c 100644
> --- a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
> +++ b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
> @@ -2,11 +2,16 @@ TPS65217 Charger
>
> Required Properties:
> -compatible: "ti,tps65217-charger"
> +-interrupts: TPS65217 interrupt numbers for the AC and USB charger input change.
> + Should be <0> for the USB charger and <1> for the AC adapter.
> +-interrupt-names: Should be "USB" and "AC"
>
> This node is a subnode of the tps65217 PMIC.
>
> Example:
>
> tps65217-charger {
> - compatible = "ti,tps65090-charger";
> + compatible = "ti,tps65217-charger";
> + interrupts = <0>, <1>;
> + interrupt-names = "USB", "AC";
> };
Thanks, I queued this into power-supply's for-next branch.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/1] iio: adc: tlc4541: add support for TI tlc4541 adc
From: Phil Reid @ 2017-01-12 3:51 UTC (permalink / raw)
To: Peter Meerwald-Stadler
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.02.1701111007240.12204-jW+XmwGofnusTnJN9+BGXg@public.gmane.org>
On 11/01/2017 17:17, Peter Meerwald-Stadler wrote:
> On Wed, 11 Jan 2017, Phil Reid wrote:
>
>> Oops, title should be PATCH V2.
>>
>> On 11/01/2017 14:51, Phil Reid wrote:
>>> This adds TI's tlc4541 16-bit ADC driver. Which is a single channel
>>> ADC. Supports raw and trigger buffer access.
>>> Also supports the tlc3541 14-bit device, which has not been tested.
>>> Implementation of the tlc3541 is fairly straight forward thou.
>
> comments below
>
>>
>>> Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
>>> ---
>>>
>>> Notes:
>>> Changes from v1:
>>> - Add tlc3541 support and chan spec.
>>> - remove fields that where already 0 from TLC4541_V_CHAN macro
>>> - Increase rx_buf size in tlc4541_state to avoid copy in
>>> tlc4541_trigger_handle
>>> - Remove erroneous be16_to_cpu in tlc4541_trigger_handle
>>> - Docs/binding: spi -> SPI & add ti,tlc3541
>>>
>>> I haven't add Rob's Ack due to adding a new compatible string.
>>>
>>> I tried to ".index = 1" from the spec as suggested by Peter, but that
>>> didn't
>>> seem to work. Perhaps remove of .channel was the intended target.
>
> the only between index = 0/1 should be that the channel is called
> in_voltage0_raw vs in_voltage_raw in sysfs -- maybe there is an issue in
> iio_readdev?
>
Did a little more testing and the problem looks to be in libiio.
Here's the output from iio and list of sysfs files when "indexed = 1"
iio:device8: tlc4541 (buffer capable)
2 channels found:
voltage0: (input, index: 0, format: be:U16/16>>0)
2 channel-specific attributes found:
attr 0: raw value: 174
attr 1: scale value: 0.076293945
timestamp: (input, index: 1, format: le:S64/64>>0)
1 device-specific attributes found:
attr 0: current_timestamp_clock value: realtime
root@cyclone5:~# ls /sys/bus/iio/devices/iio\:device8/*
/sys/bus/iio/devices/iio:device8/current_timestamp_clock /sys/bus/iio/devices/iio:device8/in_voltage_scale
/sys/bus/iio/devices/iio:device8/dev /sys/bus/iio/devices/iio:device8/name
/sys/bus/iio/devices/iio:device8/in_voltage0_raw /sys/bus/iio/devices/iio:device8/uevent
/sys/bus/iio/devices/iio:device8/buffer:
enable length watermark
/sys/bus/iio/devices/iio:device8/of_node:
#io-channel-cells enable-dma name reg spi-max-frequency
compatible linux,phandle phandle spi-cpha vref-supply
/sys/bus/iio/devices/iio:device8/power:
autosuspend_delay_ms control runtime_active_time runtime_status runtime_suspended_time
/sys/bus/iio/devices/iio:device8/scan_elements:
in_timestamp_en in_timestamp_index in_timestamp_type in_voltage0_en in_voltage0_index in_voltage0_type
/sys/bus/iio/devices/iio:device8/subsystem:
devices drivers drivers_autoprobe drivers_probe uevent
/sys/bus/iio/devices/iio:device8/trigger:
current_trigger
And the same when "indexed = 0"
iio:device8: tlc4541 (buffer capable)
2 channels found:
voltage: (input)
2 channel-specific attributes found:
attr 0: raw value: 173
attr 1: scale value: 0.076293945
timestamp: (input, index: 1, format: le:S64/64>>0)
1 device-specific attributes found:
attr 0: current_timestamp_clock value: realtime
root@cyclone5:~# ls /sys/bus/iio/devices/iio\:device8/*
/sys/bus/iio/devices/iio:device8/current_timestamp_clock /sys/bus/iio/devices/iio:device8/in_voltage_scale
/sys/bus/iio/devices/iio:device8/dev /sys/bus/iio/devices/iio:device8/name
/sys/bus/iio/devices/iio:device8/in_voltage_raw /sys/bus/iio/devices/iio:device8/uevent
/sys/bus/iio/devices/iio:device8/buffer:
enable length watermark
/sys/bus/iio/devices/iio:device8/of_node:
#io-channel-cells enable-dma name reg spi-max-frequency
compatible linux,phandle phandle spi-cpha vref-supply
/sys/bus/iio/devices/iio:device8/power:
autosuspend_delay_ms control runtime_active_time runtime_status runtime_suspended_time
/sys/bus/iio/devices/iio:device8/scan_elements:
in_timestamp_en in_timestamp_index in_timestamp_type in_voltage_en in_voltage_index in_voltage_type
/sys/bus/iio/devices/iio:device8/subsystem:
devices drivers drivers_autoprobe drivers_probe uevent
/sys/bus/iio/devices/iio:device8/trigger:
current_trigger
The iio scope application also does not allow the tlc4541 channel to be selected when "indexed = 0".
I've had a bit of play with some test apps but it looks like to me libiio is not parsing the
scan_elements folder correctly when the channels are not indexed.
Haven't located exactly where as yet.
So is the correct path here to fix libiio?
I'm using libiio from git build a few weeks ago, I'll try updating to see if it fixes anything.
Last commit was:
9838779 - Paul Cercueil , 3 weeks ago : Local backend: Return scan result even if 0 devices
--
Regards
Phil Reid
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings
From: Chris Brandt @ 2017-01-12 4:14 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Mark Rutland, Geert Uytterhoeven,
Simon Horman
Cc: devicetree, linux-renesas-soc, Chris Brandt
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
v3:
* added list of how many interrupts each SOC has
v2:
* added interrupt description
---
Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
index e4ba92aa..c32dc5a 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
+++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
@@ -8,6 +8,7 @@ Required properties:
- compatible: should be "renesas,mmcif-<soctype>", "renesas,sh-mmcif" as a
fallback. Examples with <soctype> are:
+ - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs
- "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs
- "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
- "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs
@@ -17,6 +18,13 @@ Required properties:
- "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs
- "renesas,mmcif-sh73a0" for the MMCIF found in sh73a0 SoCs
+- interrupts: Some SoCs have only 1 shared interrupt, while others have either
+ 2 or 3 individual interrupts (error, int, card detect). Below is the number
+ of interrupts for each SoC:
+ 1: r8a73a4, r8a7778, r8a7790, r8a7791, r8a7793, r8a7794
+ 2: r8a7740, sh73a0
+ 3: r7s72100
+
- clocks: reference to the functional clock
- dmas: reference to the DMA channels, one per channel name listed in the
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-12 4:23 UTC (permalink / raw)
To: catalin.marinas, will.deacon, marc.zyngier, mark.rutland, oss,
devicetree, shawnguo, stuart.yoder, linux-arm-kernel, linuxarm
In-Reply-To: <1483772858-10380-1-git-send-email-dingtianhong@huawei.com>
Hi Marc:
How about this v7, if any suggestions very grateful.
Thanks.
Ding
On 2017/1/7 15:07, Ding Tianhong wrote:
> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
> potential to contain an erroneous value when the timer value changes".
> Accesses to TVAL (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread the system count registers until the value of the second
> read is larger than the first one by less than 32, the system counter can be guaranteed
> not to return wrong value twice by back-to-back read and the error value is always larger
> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>
> v2: Introducing a new generic erratum handling mechanism for fsl,a008585 and hisilicon,161601.
> Significant rework based on feedback, including seperate the fsl erratum a008585
> to another patch, update the erratum name and remove unwanted code.
>
> v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> being globally visible. After discussion with Marc and Will, a consensus decision was
> made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> and make some generic name more specific, export timer_unstable_counter_workaround
> for module access.
>
> Significant rework based on feedback, including fix some alignment problem, make the
> #define __hisi_161601_read_reg to be private to the .c file instead of being globally
> visible, add more accurate annotation and modify a bit of logical format to enable
> arch_timer_read_ool_enabled, remove the kernel commandline parameter
> clocksource.arm_arch_timer.hisilicon-161601.
>
> Introduce a generic aquick framework for erratum in ACPI mode.
>
> v4: rename the quirk handler parameter to make it more generic, and
> avoid break loop when handling the quirk becasue it need to
> support multi quirks handler.
>
> update some data structures for acpi mode.
>
> v5: Adapt the new kernel-parameters.txt for latest kernel version.
> Set the retries of reread system counter to 50, because it is possible
> that some interrupts may lead to more than twice read errors and break the loop,
> it will trigger the warning, so we set the number of retries far beyond the number of
> iterations the loop has been observed to take.
>
> v6: The last 2 patches in the previous version about the ACPI mode will conflict witch Fuwei's
> GTDT patches, so remove the ACPI part and only support the DT base code for this patch set.
>
> We have trigger a bug when select the CONFIG_FUNCTION_GRAPH_TRACER and enable function_graph
> to /sys/kernel/debug/tracing/current_tracer, the system will stall into an endless loop, it looks
> like that the ftrace_graph_caller will be related to xxx.read_cntvct_el0 and read the system counter
> again, so mark the xxx.read_cntvct_el0 with notrace to fix the problem.
>
> v7: Introduce a new general config symbol named CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND to enable the workaround
> for any chips which has similar arch timer erratum just like "fsl,erratum_a008585" and "hisilicon,erratum_161601",
> modify the struct arch_timer_erratum_workaround to be compatible different chip erratum more easily, and
> reconstruction some code base on the new config symbol and struct, thanks to Marc's suggestion.
>
> Ding Tianhong (4):
> arm64: arch_timer: Add device tree binding for hisilicon-161601
> erratum
> arm64: arch_timer: Introduce a generic erratum handing mechanism for
> fsl-a008585
> arm64: arch_timer: Work around Erratum Hisilicon-161601
> arm64: arch timer: Add timer erratum property for Hip05-d02 and
> Hip06-d03
>
> Documentation/admin-guide/kernel-parameters.txt | 9 --
> Documentation/arm64/silicon-errata.txt | 1 +
> .../devicetree/bindings/arm/arch_timer.txt | 8 ++
> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
> arch/arm64/include/asm/arch_timer.h | 38 ++----
> drivers/clocksource/Kconfig | 18 +++
> drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------
> 8 files changed, 152 insertions(+), 74 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v5] arm64: dts: mt8173: add mmsel clocks for 4K support
From: Daniel Kurtz @ 2017-01-12 4:42 UTC (permalink / raw)
To: Bibby Hsieh, Matthias Brugger
Cc: Mark Rutland, open list:OPEN FIRMWARE AND...,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
moderated list:ARM/Mediatek SoC support, Rob Herring, Pawel Moll,
Ian Campbell, Kumar Gala, Catalin Marinas, Will Deacon,
Yingjoe Chen, Sascha Hauer, James Liao, Lorenzo Pieralisi,
YH Huang, CK Hu, Yong Wu, Eddie Huang, dawei.chien@mediatek.com,
Chunfeng Yun, Junzhi Zhao, Philipp Zabel
In-Reply-To: <1470279438-60372-1-git-send-email-bibby.hsieh@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]
Hi Matthias,
On Thu, Aug 4, 2016 at 10:57 AM, Bibby Hsieh <bibby.hsieh@mediatek.com>
wrote:
> To support HDMI 4K resolution, mmsys need clcok
> mm_sel to be 400MHz.
>
> The board .dts file should override the clock rate
> property with the higher VENCPLL frequency the board
> supports HDMI 4K resolution.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
It looks like this patch was lost. It is actually a prerequisite for MTK
4k HDMI support, which already landed in v4.9.
See the email thread entitled:
[PATCH v5 0/3] MT8173 HDMI 4K support <https://lkml.org/lkml/2016/9/28/893>
Or these three:
0d2200794f0a drm/mediatek: modify the factor to make the pll_rate set in
the 1G-2G range
968253bd7caa drm/mediatek: enhance the HDMI driving current
d542b7c473f0 drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock
enable
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 78529e4..c3f32f3 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -690,6 +690,8 @@
> compatible = "mediatek,mt8173-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> + assigned-clocks = <&topckgen CLK_TOP_MM_SEL>;
> + assigned-clock-rates = <400000000>;
> #clock-cells = <1>;
> };
>
> --
> 1.7.9.5
>
[-- Attachment #2: Type: text/html, Size: 2386 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] mmc: pwrseq-simple: add disable-post-power-on option
From: Matt Ranostay @ 2017-01-12 4:43 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus Walleij, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren,
Liam Breck
In-Reply-To: <CAPDyKFp5j5ZqJkavCSYwWQ7nKtjOqCTv=ubhjYRsSEJUw07e3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jan 11, 2017 at 2:55 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 9 January 2017 at 05:53, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
>> On Fri, Dec 30, 2016 at 12:05 AM, Linus Walleij
>> <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> On Mon, Dec 19, 2016 at 1:01 AM, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
>>>
>>>> * SD8787 has a "powerdown" line, and CW1200 has a "powerup" line.. I
>>>> know this is a simple logic inversion.
>>>
>>> If this is a GPIO line, the GPIO subsystem can flag a line for
>>> inverted logic. GPIO_ACTIVE_LOW from device tree for example.
>>
>> Slight ping on Ulf on this thread :).
>
> Thanks, sorry for the delay!
>
>>
>> I do understand the inverted logic flag but that doesn't help if there
>> are different logic states between various chipsets.
>
> For cw1200 (I looked at code from an old ST-Ericsson vendor tree), the
> sequence is as follows:
>
> 1) Enable clock/power to the card/chip.
> 2) Assert GPIO pin. I assume this also can be done before the
> clock/power is enabled.
> 3) Wait some time (~50ms).
> 4) De-assert GPIO pin.
> 5) Wait some time (~20ms)
> 6) Assert GPIO pin.
> 7) Wait some time (~32ms).
>
> At power off, the GPIO pin is de-asserted and of course also the
> clock/power is disabled. Just to make sure we have all the relevant
> logic.
>
> Looking at mmc pwrseq simple, perhaps we can extend this to deal with
> GPIOs that needs to be *toggled*, as this is not just reset GPIOs.
> Then we also need to deal with the delays in-between the toggling.
Wouldn't we need to have a per chip function for each device
supported? As well document gpios? I suspect we'd need an array of
gpios defined in device tree since different devices will likely have
various numbers of pins to toggle
- Matt
>
> Thoughts?
>
> Kind regards
> Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5] arm64: dts: mt8173: add mmsel clocks for 4K support
From: Daniel Kurtz @ 2017-01-12 4:50 UTC (permalink / raw)
To: Bibby Hsieh
Cc: Mark Rutland, open list:OPEN FIRMWARE AND...,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
moderated list:ARM/Mediatek SoC support, Rob Herring, Pawel Moll,
Ian Campbell, Kumar Gala, Catalin Marinas, Will Deacon,
Matthias Brugger, Yingjoe Chen, Sascha Hauer, James Liao,
Lorenzo Pieralisi
In-Reply-To: <1470279438-60372-1-git-send-email-bibby.hsieh@mediatek.com>
Hi Matthias,
(Trying again to send plain text email)...
On Thu, Aug 4, 2016 at 10:57 AM, Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
> To support HDMI 4K resolution, mmsys need clcok
> mm_sel to be 400MHz.
>
> The board .dts file should override the clock rate
> property with the higher VENCPLL frequency the board
> supports HDMI 4K resolution.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
It looks like this patch was lost. It is actually a prerequisite for
MTK 4k HDMI support, which already landed in v4.9.
See the email thread entitled:
[PATCH v5 0/3] MT8173 HDMI 4K support <https://lkml.org/lkml/2016/9/28/893>
Or these three:
0d2200794f0a drm/mediatek: modify the factor to make the pll_rate set
in the 1G-2G range
968253bd7caa drm/mediatek: enhance the HDMI driving current
d542b7c473f0 drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
-Dan
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 78529e4..c3f32f3 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -690,6 +690,8 @@
> compatible = "mediatek,mt8173-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> + assigned-clocks = <&topckgen CLK_TOP_MM_SEL>;
> + assigned-clock-rates = <400000000>;
> #clock-cells = <1>;
> };
>
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v3 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Anurup M @ 2017-01-12 5:57 UTC (permalink / raw)
To: Mark Rutland
Cc: Rob Herring, will.deacon-5wv7dgnIgG8,
dikshit.n-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
anurup.m-hv44wF8Li93QT0dZR+AlfA,
zhangshaokun-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaojun-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
sanil.kumar-C8/M+/jPZTeaMJb+Lgu22Q,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
shiju.jose-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, shyju.pv-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <20170110174515.GC24036@leverpostej>
On Tuesday 10 January 2017 11:15 PM, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 10:28:54AM +0530, Anurup M wrote:
>>
>> On Wednesday 04 January 2017 04:26 AM, Rob Herring wrote:
>>> On Mon, Jan 02, 2017 at 01:49:03AM -0500, Anurup M wrote:
>>>> From: Tan Xiaojun <tanxiaojun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>>>
>>>> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
>>>>
>>>> Signed-off-by: Tan Xiaojun <tanxiaojun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>>> Signed-off-by: Anurup M <anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
>>>> 1 file changed, 41 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>> new file mode 100644
>>>> index 0000000..bbe8b45
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>> @@ -0,0 +1,41 @@
>>>> +The Hisilicon Djtag is an independent component which connects with some other
>>>> +components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
>>>> +in the chip. The djtag controls access to connecting modules of CPU and IO
>>>> +dies.
>>>> +The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
>>>> +are accessed by djtag during real time debugging. In IO die there are connecting
>>>> +components like RSA. These components appear as devices attached to djtag bus.
>>>> +
>>>> +Hisilicon HiP05/06/07 djtag for CPU and IO die
>>>> +Required properties:
>>>> + - compatible : The value should be as follows
>>>> + (a) "hisilicon,hip05-djtag-v1" for CPU and IO die which use v1 hw in
>>>> + HiP05 chipset.
>>> You don't need to distinguish the CPU and IO blocks?
>> The CPU and IO djtag nodes will have different base address(in reg
>> property).
>> There is no difference in handling of CPU and IO dies in the djtag driver.
>> So there is currently no need to distinguish them.
> It may still make sense to distinuguish them, even if the current djtag
> driver can handle them the same. Presumably clients of the djtag driver
> will poke CPU and IO djtag units differently.
Ok. I shall add "-cpu-/-io-" in the compatible field to distinguish.
e.g. "hisilicon,hip05-cpu-djtag-v1".
Thanks,
Anurup
> Thanks,
> Mark.
--
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 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters
From: Anurup M @ 2017-01-12 6:27 UTC (permalink / raw)
To: Mark Rutland
Cc: robh+dt, gregkh, catalin.marinas, arnd, geert+renesas, davem,
akpm, corbet, will.deacon, linux-kernel, devicetree,
linux-arm-kernel, anurup.m, zhangshaokun, tanxiaojun, xuwei5,
sanil.kumar, john.garry, gabriele.paoloni, shiju.jose,
wangkefeng.wang, linuxarm, shyju.pv, dikshit.n
In-Reply-To: <20170110174311.GB24036@leverpostej>
On Tuesday 10 January 2017 11:13 PM, Mark Rutland wrote:
> Hi,
>
> On Mon, Jan 02, 2017 at 01:47:52AM -0500, Anurup M wrote:
>> ToDo:
>> 1) The counter overflow handling is currently unsupported in this
>> patch series.
> From a quick scan of the patches, I see mention of an interrupt in a
> comment the driver, but there's noething in the DT binding.
>
> Is there an overflow interrupt at all?
>
> Or do you need to implement polling to avoid overflow?
>
> This is a prerequisite for merging the driver.
The HiP0x chips support counter overflow interrupt for L3C and MN.
The HiP05/06 interrupts in CPU die use Hisilicon mbigen-v1, but the
mbigen-v1
driver is not available in mainline. So the L3C and MN PMU in HiP05/06
cannot
support counter overflow in driver.
As the support for HiP05/06 are not the prime focus now. I shall remove
them
from the patch series and shall plan to include them later.
For HiP07, as it use mbigen-v2, which is in mainline, I shall include
the overflow
handling support in the next revision (V4 series).
Thanks,
Anurup
> Thanks,
> Mark.
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Krzysztof Kozlowski @ 2017-01-12 6:34 UTC (permalink / raw)
To: cwchoi00-Re5JQEeQqe8AvxtiuMwx3w, Chanwoo Choi
Cc: Kukjin Kim, Javier Martinez Canillas, Rob Herring, Mark Rutland,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org, Sylwester Nawrocki,
Marek Szyprowski, a.hajda-Sze3O3UU22JBDgjK7y7TUQ, linux-kernel,
linux-samsung-soc, devicetree, linux-arm-kernel
In-Reply-To: <CAGTfZH0H_kA9cRPG4Vqh3iLZncfXqfKDFiSYEXV1zp+9yFP25Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jan 11, 2017 at 11:22 PM, Chanwoo Choi <cwchoi00-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 2017-01-12 1:26 GMT+09:00 Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>>> This patch replaces the small letter of base address, offset and hex value
>>> with the capital letter to keep the consistency on Exynos5433.
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> index abaf6b4d599d..d7ed1a68b6fd 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> @@ -231,7 +231,7 @@
>>> compatible = "arm,psci";
>>> method = "smc";
>>> cpu_off = <0x84000002>;
>>> - cpu_on = <0xC4000003>;
>>> + cpu_on = <0xc4000003>;
>>
>> There is no point of such "improvements". This is just unnecessary
>> churn.
>>
>> Sometimes such things are accepted as part of some bigger work (vide
>> recent Andrzej's sysmmu for HDMI/TV). But on its own? No sense at all.
>
> Do you mean that this patch is not reasonable? or
> The modification of cpu_on property is only not reasonable?
>
> It is simple for the consistency to use the hex value in dts file.
The patch is not reasonable (as sent alone).
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings
From: Geert Uytterhoeven @ 2017-01-12 7:36 UTC (permalink / raw)
To: Chris Brandt
Cc: Ulf Hansson, Rob Herring, Mark Rutland, Simon Horman,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170112041452.14136-1-chris.brandt@renesas.com>
Hi Chris,
On Thu, Jan 12, 2017 at 5:14 AM, Chris Brandt <chris.brandt@renesas.com> wrote:
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
>
> ---
> v3:
> * added list of how many interrupts each SOC has
> v2:
> * added interrupt description
Thanks or the update!
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: Sekhar Nori @ 2017-01-12 7:39 UTC (permalink / raw)
To: David Lechner
Cc: Kevin Hilman, Rob Herring, Mark Rutland, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1dd57ac3-554f-7d66-97b0-b76c3ddc7854@lechnology.com>
On Wednesday 11 January 2017 09:55 PM, David Lechner wrote:
>>> +&spi0 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>>> +
>>> + flash@0 {
>>> + compatible = "n25q128a13", "jedec,spi-nor";
>>> + reg = <0>;
>>> + spi-max-frequency = <50000000>;
>>> + ti,spi-wdelay = <8>;
>>> +
>>> + /* Partitions are based on the official firmware from LEGO */
>>> + partitions {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + partition@0 {
>>> + label = "U-Boot";
>>> + reg = <0 0x40000>;
>>> + };
>>> +
>>> + partition@40000 {
>>> + label = "U-Boot Env";
>>> + reg = <0x40000 0x10000>;
>>> + };
>>> +
>>> + partition@50000 {
>>> + label = "Kernel";
>>> + reg = <0x50000 0x200000>;
>>> + };
>>> +
>>> + partition@250000 {
>>> + label = "Filesystem";
>>> + reg = <0x250000 0xa50000>;
>>> + };
>>> +
>>> + partition@cb0000 {
>>> + label = "Storage";
>>> + reg = <0xcb0000 0x2f0000>;
>>> + };
>>> + };
>>> + };
>>> +
>>> + adc@3 {
>>> + compatible = "ti-ads7957";
>>
>> So looks like this works because of_register_spi_device() sets up
>> modalias of spi device from compatible string. I am fine with it, just
>> highlighting it here to make sure this is acceptable practice. I did not
>> really find any precedence for using SPI device name as compatible
>> property in existing DTS files.
>
> Indeed. It looks like this sort of "trivial" device binding is just used
> for i2c devices. I will submit some patches to add proper device tree
> bindings and change this to "ti,ads7957".
Alright, if you are going to do that, then I suggest you respin this
patch with the adc node dropped for now. That way we can ensure basic
board support in v4.11. If dependencies pan out, the adc can go in too
as a separate patch.
Thanks,
Sekhar
^ 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