* Re: [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Fabio Estevam @ 2017-01-04 15:26 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Mark Rutland, devel, Steve Longerbeam, Philipp Zabel,
devicetree@vger.kernel.org, Greg Kroah-Hartman,
Russell King - ARM Linux, linux-kernel, robh+dt@kernel.org,
Sascha Hauer, Fabio Estevam, mchehab, Shawn Guo,
linux-arm-kernel@lists.infradead.org, linux-media
In-Reply-To: <1483477049-19056-6-git-send-email-steve_longerbeam@mentor.com>
On Tue, Jan 3, 2017 at 6:57 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> + camera: ov5642@3c {
> + compatible = "ovti,ov5642";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5642>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + clock-names = "xclk";
> + reg = <0x3c>;
> + xclk = <24000000>;
> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
> + rev B board is VGEN5 */
Please use vgen3 so that by default we have the valid AVDD-supply for
revC boards which is more recent and more the users have access to.
> + mipi_camera: ov5640@3c {
> + compatible = "ovti,ov5640_mipi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5640>;
> + reg = <0x3c>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + clock-names = "xclk";
> + xclk = <24000000>;
> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
> + rev B board is VGEN5 */
Same here.
> + pinctrl_ov5640: ov5640grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x80000000
> + MX6QDL_PAD_SD1_CLK__GPIO1_IO20 0x80000000
Please avoid all the 0x80000000 IOMUX settings and replace them by
their real values.
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Nishanth Menon @ 2017-01-04 15:38 UTC (permalink / raw)
To: Tony Lindgren, Linus Walleij
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Rob Herring,
devicetree, linux-gpio, linux-omap, Lokesh Vutla
In-Reply-To: <20170102221228.GH9325@atomide.com>
On 01/02/2017 04:12 PM, Tony Lindgren wrote:
[...]
Minor one:
> + * Copyright (C) 2015 Texas Instruments, Inc.
Could you make this:
Copyright (C) 2015-2017 Texas Instruments Incorporated -
http://www.ti.com/
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH 0/9] ARM: dts: armada388: Introduce Clearfog Base DT
From: Gregory CLEMENT @ 2017-01-04 15:48 UTC (permalink / raw)
To: Russell King
Cc: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring, Sebastian Hesselbarth
In-Reply-To: <E1cO43Q-0007yJ-ON-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Hi Russell,
On lun., janv. 02 2017, Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> This patch series, based upon the previously submitted fix for the SPI
> flash, reworks the Clearfog DT files to add support for the SolidRun
> Clearfog Base platform.
>
> The conventional model is now known as the "Clearfog Pro" module, which
> has the DSA switch and two PCIe sockets. The base model is a smaller
> board without the DSA switch, replacing it with a second copper gigabit
> port, and only one PCIe socket.
>
> We retain the original DT file (named armada-388-clearfog.dtb) for
> compatibility with existing installations - not only the filename,
> but also the board name exposed in userspace.
All the series applied on mvebu/dt.
I amended the last two patches because the license text was mangled as
spotted by Alexandre Belloni, so I fixed it while applying the patches.
Thanks,
Gregory
>
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/armada-388-clearfog-base.dts | 94 ++++++
> arch/arm/boot/dts/armada-388-clearfog-pro.dts | 55 ++++
> arch/arm/boot/dts/armada-388-clearfog.dts | 364 ++++-----------------
> arch/arm/boot/dts/armada-388-clearfog.dtsi | 310 ++++++++++++++++++
> .../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 21 ++
> 6 files changed, 548 insertions(+), 298 deletions(-)
> create mode 100644 arch/arm/boot/dts/armada-388-clearfog-base.dts
> create mode 100644 arch/arm/boot/dts/armada-388-clearfog-pro.dts
> create mode 100644 arch/arm/boot/dts/armada-388-clearfog.dtsi
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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] mailbox: sti: Fix mbox-names copy and paste error
From: Lee Jones @ 2017-01-04 16:01 UTC (permalink / raw)
To: Rob Herring
Cc: patrice.chotard-qxv4g6HH51o,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170104145732.7yiqbi7rf7m6lem4@rob-hp-laptop>
On Wed, 04 Jan 2017, Rob Herring wrote:
> On Wed, Jan 04, 2017 at 12:05:27PM +0000, Lee Jones wrote:
> > Due to an over-sight, mbox-names has become mbox-name in some instances.
> >
> > Let's put it right.
> >
> > Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/mailbox/sti-mailbox.txt | 4 ++--
> > arch/arm/boot/dts/stih407-family.dtsi | 8 ++++----
> > drivers/mailbox/mailbox-sti.c | 2 +-
> > 3 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > index 351f612..648d176 100644
> > --- a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > @@ -9,7 +9,7 @@ Controller
> > Required properties:
> > - compatible : Should be "st,stih407-mailbox"
> > - reg : Offset and length of the device's register set
> > -- mbox-name : Name of the mailbox
> > +- mbox-names : Name of the mailbox
>
> It's worse than this. mbox-names is for the mailbox client side.
Ah yes, of course. False alarm.
Let's just leave it as it is. ;)
I'll reply to the reporter directly.
> This should just be dropped. Plus, *-names is pointless when there
> is only 1 element.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: mbox-name vs. mbox-names (was: Re: [PATCH v4 1/5] mailbox: dt: Supply bindings for ST's Mailbox IP)
From: Lee Jones @ 2017-01-04 16:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel, Maxime Coquelin, Jassi Brar,
devicetree@vger.kernel.org
In-Reply-To: <20161024084107.GD14477@dell>
On Mon, 24 Oct 2016, Lee Jones wrote:
> On Fri, 21 Oct 2016, Geert Uytterhoeven wrote:
>
> > On Fri, Oct 16, 2015 at 9:21 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > .../devicetree/bindings/mailbox/sti-mailbox.txt | 51 ++++++++++++++++++++++
> > > 1 file changed, 51 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > > new file mode 100644
> > > index 0000000..b61eec9
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > > @@ -0,0 +1,51 @@
> > > +ST Microelectronics Mailbox Driver
> > > +
> > > +Each ST Mailbox IP currently consists of 4 instances of 32 channels. Messages
> > > +are passed between Application and Remote processors using shared memory.
> > > +
> > > +Controller
> > > +----------
> > > +
> > > +Required properties:
> > > +- compatible : Should be "st,stih407-mailbox"
> > > +- reg : Offset and length of the device's register set
> > > +- mbox-name : Name of the mailbox
> >
> > All other mailbox drivers use "mbox-names". Oops, it's in v4.9-rc1...
> >
> > Can we still fix that?
>
> So long as all the fixes; changes to the driver and DT are merged in a
> single kernel release, we can change it.
Scrap that, change of plan. Actually current code is correct.
mbox-name does not have the same functionality as mbox-names.
mbox-names is a client-side property used to request channels, where
as mbox-name is used to provide a better user-readable name other than
mailbox{0..x}.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Tony Lindgren @ 2017-01-04 16:05 UTC (permalink / raw)
To: Nishanth Menon
Cc: Linus Walleij, Gary Bisson, Grygorii Strashko, Mark Rutland,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Lokesh Vutla
In-Reply-To: <63a8a1ec-343a-8c96-a0d2-21d81f7ad10e-l0cyMroinI0@public.gmane.org>
* Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> [170104 07:39]:
> On 01/02/2017 04:12 PM, Tony Lindgren wrote:
> [...]
> Minor one:
> > + * Copyright (C) 2015 Texas Instruments, Inc.
> Could you make this:
> Copyright (C) 2015-2017 Texas Instruments Incorporated - http://www.ti.com/
Sure, it's your patch :) Will repost.
Regards,
Tony
--
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 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-04 16:13 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <1483536406.7312.3.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On 4 January 2017 at 14:26, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
>> V4: Move code to of.c
>> Use one helper called at init time (no runtime hooks)
>> Modify orig_flags
>
>
>> +/**
>> + * wiphy_read_of_freq_limits - read frequency limits from device
>> tree
>> + *
>> + * @wiphy: the wireless device to get extra limits for
>> + *
>> + * Some devices may have extra limitations specified in DT. This may
>> be useful
>> + * for chipsets that normally support more bands but are limited due
>> to board
>> + * design (e.g. by antennas or extermal power amplifier).
>> + *
>> + * This function reads info from DT and uses it to *modify* channels
>> (disable
>> + * unavailable ones). It's usually a *bad* idea to use it in drivers
>> with
>> + * shared channel data as DT limitations are device specific.
>> + *
>> + * As this function access device node it has to be called after
>> set_wiphy_dev.
>> + * It also modifies channels so they have to be set first.
>> + */
>
> It should also be called before wiphy_register(), I think? And I
> suppose you should add a comment about not being able to use shared
> channels.
>
>> + pr_debug("Disabling freq %d MHz as
>> it's out of OF limits\n",
>> + chan->center_freq);
>> + chan->orig_flags |=
>> IEEE80211_CHAN_DISABLED;
>>
> But just setting orig_flags also won't work, since it'd be overwritten
> again by wiphy_register(), no?
I told you I successfully tested it, didn't I? Well, I quickly checked
wiphy_register and couldn't understand how it was possible it worked
for me...
OK, so after some debugging I understood why I got this working. It's
the way brcmfmac handles channels.
At the beginning all channels are disabled: see __wl_2ghz_channels &
__wl_5ghz_channels. They have IEEE80211_CHAN_DISABLED set in "flags"
for every channel.
In early phase brcmfmac calls wiphy_read_of_freq_limits which sets
IEEE80211_CHAN_DISABLED in "orig_flags" for unavailable channels.
Then brcmf_construct_chaninfo kicks in. Normally it removes
IEEE80211_CHAN_DISABLED from "flags" for most of channels, but it
doesn't happen anymore due to my change:
if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
continue;
Then brcmfmac calls wiphy_apply_custom_regulatory which sets some bits
like IEEE80211_CHAN_NO_80MHZ and IEEE80211_CHAN_NO_160MHZ in "flags".
Finally wiphy_register is called which copies "flags" to
"original_flags". As brcmfmac /respected/ IEEE80211_CHAN_DISABLED set
in orig_flags, it also left IEEE80211_CHAN_DISABLED in flags. This way
I got IEEE80211_CHAN_DISABLED in orig_flags after overwriting that
field inside wiphy_register.
That's quite crazy, right?
I guess you're right after all, I should set IEEE80211_CHAN_DISABLED
in "flags" field, let wiphy_register copy that to "orig_flags" and
sanitize brcmfmac.
--
Rafał
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: armada388-clearfog: add phy reset gpio-hog
From: Gregory CLEMENT @ 2017-01-04 16:26 UTC (permalink / raw)
To: Russell King
Cc: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO4Vz-00005t-8n-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Hi Russell,
On lun., janv. 02 2017, Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
It would be nice to have some word here about this patch. Especially why
we need it now. I guess it is for being less dependent on the
initialization done by the bootloader but maybe you have other reasons.
Thanks,
Gregory
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> ---
> arch/arm/boot/dts/armada-388-clearfog-base.dts | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-388-clearfog-base.dts b/arch/arm/boot/dts/armada-388-clearfog-base.dts
> index f86e1876fb38..da788ea40717 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog-base.dts
> +++ b/arch/arm/boot/dts/armada-388-clearfog-base.dts
> @@ -74,7 +74,17 @@
> phy = <&phy1>;
> };
>
> +&gpio0 {
> + phy1_reset {
> + gpio-hog;
> + gpios = <19 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "phy1-reset";
> + };
> +};
> +
> &mdio {
> + pinctrl-0 = <&mdio_pins µsom_phy_clk_pins &clearfog_phy_pins>;
> phy1: ethernet-phy@1 {
> /*
> * Annoyingly, the marvell phy driver configures the LED
> @@ -87,6 +97,11 @@
> };
>
> &pinctrl {
> + /* phy1 reset */
> + clearfog_phy_pins: clearfog-phy-pins {
> + marvell,pins = "mpp19";
> + marvell,function = "gpio";
> + };
> rear_button_pins: rear-button-pins {
> marvell,pins = "mpp44";
> marvell,function = "gpio";
> --
> 2.7.4
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/5] ARM: dts: armada388: rework clearfog's .dtsi references
From: Gregory CLEMENT @ 2017-01-04 16:31 UTC (permalink / raw)
To: Russell King
Cc: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring, Sebastian Hesselbarth
In-Reply-To: <E1cO4UH-0008SR-GW-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Hi Russell,
On lun., janv. 02 2017, Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> This patch series, based upon the previous series adding Clearfog Base
> support, reworks the clearfog .dtsi file to reference nodes by label
> rather than by path.
>
> Not everything is moved - just those which had labels at the time the
> patches were created.
All the series is applied on mvebu/dt, however I would like to have a
commit log for the first patch before pushing it to arm-soc.
Thanks,
Gregory
>
> arch/arm/boot/dts/armada-388-clearfog-base.dts | 15 +
> arch/arm/boot/dts/armada-388-clearfog.dtsi | 353 ++++++++++-----------
> .../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 113 ++++---
> 3 files changed, 245 insertions(+), 236 deletions(-)
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Nishanth Menon @ 2017-01-04 16:51 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linus Walleij, Gary Bisson, Grygorii Strashko, Mark Rutland,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Lokesh Vutla
In-Reply-To: <20170104160511.GF25222-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On 01/04/2017 10:05 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> [170104 07:39]:
>> On 01/02/2017 04:12 PM, Tony Lindgren wrote:
>> [...]
>> Minor one:
>>> + * Copyright (C) 2015 Texas Instruments, Inc.
>> Could you make this:
>> Copyright (C) 2015-2017 Texas Instruments Incorporated - http://www.ti.com/
>
> Sure, it's your patch :) Will repost.
Thanks.
I just finished testing it as well and well it still does the job it
used to do. thanks for taking this forward.
I did get a few kernel-doc warnings, which i need to look closer at.
will comment back today if I see something of use for us to fix up.
--
Regards,
Nishanth Menon
--
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] scripts/dtc: Update to upstream version 0931cea3ba20
From: Rob Herring @ 2017-01-04 16:57 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA; +Cc: Frank Rowand, Mark Rutland
Sync to upstream dtc commit 0931cea3ba20 ("dtc: fdtdump: check fdt if
not in scanning mode"). In particular, this pulls in dtc overlay
support.
This adds the following commits from upstream:
f88865469b65 dtc: Fix memory leak in character literal parsing
00fbb8696b66 Rename boot_info
1ef86ad2c24f dtc: Clean up /dts-v1/ and /plugin/ handling in grammar
e3c769aa9c16 dtc: Don't always generate __symbols__ for plugins
c96cb3c0169e tests: Don't use -@ on plugin de/recompile tests
66381538ce24 tests: Remove "suppression of fixups" tests
ba765b273f0f tests: Clarify dtc overlay tests
6ea8cd944fcd tests: More thorough tests of libfdt overlay application without dtc
7d8ef6e1db97 tests: Correct fdt handling of overlays without fixups and base trees without symbols
b4dc0ed8b127 tests: Fix double expansion bugs in test code
3ea879dc0c8f tests: Split overlay tests into those with do/don't exercise dtc plugin generation
47b4d66a2f11 tests: Test auto-alias generation on base tree, not overlay
72e1ad811523 tests: Make overlay/plugin tests unconditional
e7b3c3b5951b tests: Add overlay tests
9637e3f772a9 tests: Add check_path test
20f29d8d41f6 dtc: Plugin and fixup support
a2c92cac53f8 dtc: Document the dynamic plugin internals
8f70ac39801d checks: Pass boot_info instead of root node
ea10f953878f libfdt: add missing errors to fdt_strerror()
daa75e8fa594 libfdt: fix fdt_stringlist_search()
e28eff5b787a libfdt: fix fdt_stringlist_count()
ae97c7722840 tests: overlay: Rename the device tree blobs to be more explicit
96162d2bd9cb tests: overlay: Add test suffix to the compiled blobs
5ce8634733b7 libfdt: Add fdt_overlay_apply to the exported symbols
804a9db90ad2 fdt: strerr: Remove spurious BADOVERLAY
e8c3a1a493fa tests: overlay: Move back the bad fixup tests
7a72d89d3f81 libfdt: overlay: Fix symbols and fixups nodes condition
cabbaa972cdd libfdt: overlay: Report a bad overlay for mismatching local fixups
deb0a5c1aeaa libfdt: Add BADPHANDLE error string
7b7a6be9ba15 libfdt: Don't use 'index' as a local variable name
aea8860d831e tests: Add tests cases for the overlay code
0cdd06c5135b libfdt: Add overlay application function
39240cc865cf libfdt: Extend the reach of FDT_ERR_BADPHANDLE
4aa3a6f5e6d9 libfdt: Add new errors for the overlay code
6d1832c9e64b dtc: Remove "home page" link
45fd440a9561 Fix some typing errors in libfdt.h and livetree.c
a59be4939c13 Merge tag 'v1.4.2'
a34bb721caca dtc: Fix assorted problems in the testcases for the -a option
874f40588d3e Implement the -a option to pad dtb aligned
ec02b34c05be dtc: Makefile improvements for release uploading
1ed45d40a137 dtc: Bump version to 1.4.2
36fd7331fb11 libfdt: simplify fdt_del_mem_rsv()
d877364e4a0f libfdt: Add fdt_setprop_inplace_namelen_partial
3e9037aaad44 libfdt: Add fdt_getprop_namelen_w
84e0e1346c68 libfdt: Add max phandle retrieval function
d29126c90acb libfdt: Add iterator over properties
902d0f0953d0 libfdt: Add a subnodes iterator macro
c539075ba8ba fdtput.c: Fix memory leak.
f79ddb83e185 fdtget.c: Fix memory leak
1074ee54b63f convert-dtsv0-lexer.l: fix memory leak
e24d39a024e6 fdtdump.c: make sure size_t argument to memchr is always unsigned.
44a59713cf05 Remove unused srcpos_dump() function
cb9241ae3453 DTC: Fix memory leak on flatname.
1ee0ae24ea09 Simplify check field and macro names
9d97527a8621 Remove property check functions
2e709d158e11 Remove tree check functions
c4cb12e193e3 Alter grammar to allow multiple /dts-v1/ tags
d71d25d76012 Use xasprintf() in srcpos
9dc404958e9c util: Add xasprintf portable asprintf variant
beef80b8b55f Correct a missing space in a fdt_header cast
68d43cec1253 Correct line lengths in libfdt.h
b0dbceafd49a Correct space-after-tab in libfdt.h
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
scripts/dtc/checks.c | 349 ++++++++--------
scripts/dtc/dtc-lexer.l | 21 +-
scripts/dtc/dtc-lexer.lex.c_shipped | 650 +++++++++++++++---------------
scripts/dtc/dtc-parser.tab.c_shipped | 752 ++++++++++++++++++-----------------
scripts/dtc/dtc-parser.tab.h_shipped | 54 +--
scripts/dtc/dtc-parser.y | 34 +-
scripts/dtc/dtc.c | 69 +++-
scripts/dtc/dtc.h | 39 +-
scripts/dtc/flattree.c | 41 +-
scripts/dtc/fstree.c | 5 +-
scripts/dtc/libfdt/Makefile.libfdt | 2 +-
scripts/dtc/libfdt/fdt_ro.c | 30 +-
scripts/dtc/libfdt/fdt_rw.c | 6 +-
scripts/dtc/libfdt/fdt_strerror.c | 6 +
scripts/dtc/libfdt/fdt_wip.c | 29 +-
scripts/dtc/libfdt/libfdt.h | 210 ++++++++--
scripts/dtc/libfdt/libfdt_env.h | 1 +
scripts/dtc/livetree.c | 299 +++++++++++++-
scripts/dtc/srcpos.c | 35 +-
scripts/dtc/srcpos.h | 1 -
scripts/dtc/treesource.c | 14 +-
scripts/dtc/util.c | 30 ++
scripts/dtc/util.h | 1 +
scripts/dtc/version_gen.h | 2 +-
24 files changed, 1661 insertions(+), 1019 deletions(-)
Just sending diffstat to the list. Full patch is here[1].
Rob
[1] https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/commit/?h=dt/next&id=6f05afcbb031722ec1eff77dde188ff2edf8940e
--
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 v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2017-01-04 17:00 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, dan.j.williams@intel.com,
vinod.koul@intel.com, michal.simek@xilinx.com, Soren Brinkmann,
moritz.fischer@ettus.com, laurent.pinchart@ideasonboard.com,
luis@debethencourt.com, Jose.Abreu@synopsys.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20170104152613.hhdptwsyg73ev3dz@rob-hp-laptop>
Hi Rob,
Thanks for the review....
> On Wed, Jan 04, 2017 at 07:05:53PM +0530, Kedareswara rao Appana wrote:
> > When VDMA is configured for more than one frame in the h/w for example
> > h/w is configured for n number of frames and user Submits n number of
> > frames and triggered the DMA using issue_pending API.
> > In the current driver flow we are submitting one frame at a time but
> > we should submit all the n number of frames at one time as the h/w Is
> > configured for n number of frames.
>
> Please fix run-on sentences, capitalization, and word wrapping.
Sure will fix in the next version....
[Snip]
-- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> > @@ -66,6 +66,8 @@ Optional child node properties:
> > Optional child node properties for VDMA:
> > - xlnx,genlock-mode: Tells Genlock synchronization is
> > enabled/disabled in hardware.
> > +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
> > + enabled/disabled in hardware.
>
> What's the default (when not present)? That should be the most common case.
> Looks like the code treats this as bool, but that's not clear here. The name is not
> clear what it is doing. Enabling or disabling the feature?
Default value is zero...
When this property is present it tells hardware is configured for frame store configuration.
Will fix the explanation part in the next version like below.
xlnx,fstore-config: Tells hardware is configured for frame store configuration.
Is the above explanation clear???
Regards,
Kedar.
^ permalink raw reply
* staging/fbtft: Backward Device Tree compatibility in a drm version
From: Noralf Trønnes @ 2017-01-04 17:14 UTC (permalink / raw)
To: devicetree@vger.kernel.org
Cc: OSUOSL Drivers, DRI Development, Greg Kroah-Hartman
Hi,
I'm working on a drivers/gpu/drm version of drivers/staging/fbtft which
are drivers for tiny, usually SPI connected, displays. Now I'm wondering
if I can be backwards compatible and support Device Trees written for the
fbtft drivers. The main obstacle as I understand it, is the init property
which are values to be written to the controller registers to support a
different panel with the same controller. It even has encoded values for
delays... My understanding is that this is not accepted.
It's in fact a display panel description in the form of register values
and delays.
Here is what a binding doc would look like for one of the fbtft drivers:
* Samsung S6D02A1 Framebuffer Driver
Required properties:
- compatible: Should be "samsung,s6d02a1".
The node for this driver must be a child node of a SPI controller, hence
all mandatory properties described in ../spi/spi-bus.txt must be specified.
Optional properties:
- dc-gpios: D/C pin used with the 4-wire 8-bit data serial interface mode
- reset-gpios: Reset pin
- led-gpios: Backlight control
- width: Panel width in pixels
- height: Panel height in pixels
- rotate: Panel rotation in degrees counter clockwise (0,90,180,270)
- bgr: Panel is wired as BGR565 instead of RGB565
- buswidth: Bit width of the bus, in the case of SPI: 8 (4-wire) or 9
(3-wire) bits.
- txbuflen: Size of transfer buffer. Used for little-big endian
conversion.
- debug: Control debug output to the kernel log
- init: Panel initialization sequence overriding the driver default.
Values OR'ed with:
0x1000000 - Write the following values to this register.
0x2000000 - Delay in milliseconds
Example:
mz61581: mz61581@0{
compatible = "samsung,s6d02a1";
reg = <0>;
spi-max-frequency = <128000000>;
spi-cpol;
spi-cpha;
width = <320>;
height = <480>;
rotate = <270>;
bgr;
buswidth = <8>;
txbuflen = <32768>;
reset-gpios = <&gpio 15 0>;
dc-gpios = <&gpio 25 0>;
led-gpios = <&gpio 18 0>;
init = <0x10000b0 00
0x1000011
0x20000ff
0x10000b3 0x02 0x00 0x00 0x00
0x10000c0 0x13 0x3b 0x00 0x02 0x00 0x01 0x00 0x43
0x10000c1 0x08 0x16 0x08 0x08
0x10000c4 0x11 0x07 0x03 0x03
0x10000c6 0x00
0x10000c8 0x03 0x03 0x13 0x5c 0x03 0x07 0x14 0x08 0x00 0x21
0x08 0x14 0x07 0x53 0x0c 0x13 0x03 0x03 0x21 0x00
0x1000035 0x00
0x1000036 0xa0
0x100003a 0x55
0x1000044 0x00 0x01
0x10000d0 0x07 0x07 0x1d 0x03
0x10000d1 0x03 0x30 0x10
0x10000d2 0x03 0x14 0x04
0x1000029
0x100002c>;
/* This is a workaround to make sure the init sequence slows down
and doesn't fail */
debug = <3>;
};
Noralf.
^ permalink raw reply
* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Gregory CLEMENT @ 2017-01-04 17:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20170102022249.10657-4-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Florian,
On lun., janv. 02 2017, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
> dsa: Document new binding"). The legacy binding node is kept included, but is
> marked disabled.
>
I tested this patch on mvebu/dt (I needed to reduce the context to apply
the patch due to the changes made by Russell King on this file). I also
set the status of the old binding to "disable" (instead of "okay").
It seems to work with the limited test did:
ifconfig eth1 up
udhcpc -i lan1
iperf -c mylaptop
(same for lan4)
However is there a way to be sure that the new binding is used?
Gregory
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/armada-388-clearfog.dts | 65 +++++++++++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
> index 71ce201c903e..35207aa1f4ec 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog.dts
> +++ b/arch/arm/boot/dts/armada-388-clearfog.dts
> @@ -351,6 +351,8 @@
> };
>
> dsa@0 {
> + status = "okay";
> +
> compatible = "marvell,dsa";
> dsa,ethernet = <ð1>;
> dsa,mii-bus = <&mdio>;
> @@ -444,3 +446,66 @@
> status = "disabled";
> };
> };
> +
> +&mdio {
> + status = "okay";
> +
> + switch@4 {
> + compatible = "marvell,mv88e6085";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <4>;
> + pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
> + pinctrl-names = "default";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + label = "lan5";
> + };
> +
> + port@1 {
> + reg = <1>;
> + label = "lan4";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan3";
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan2";
> + };
> +
> + port@4 {
> + reg = <4>;
> + label = "lan1";
> + };
> +
> + port@5 {
> + reg = <5>;
> + label = "cpu";
> + ethernet = <ð1>;
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> +
> + port@6 {
> + /* 88E1512 external phy */
> + reg = <6>;
> + label = "lan6";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> +};
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-04 17:27 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <87shoyeo2j.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On 01/04/2017 09:23 AM, Gregory CLEMENT wrote:
> Hi Florian,
>
> On lun., janv. 02 2017, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
>> dsa: Document new binding"). The legacy binding node is kept included, but is
>> marked disabled.
>>
>
> I tested this patch on mvebu/dt (I needed to reduce the context to apply
> the patch due to the changes made by Russell King on this file). I also
> set the status of the old binding to "disable" (instead of "okay").
Yes, that needs fixing, thanks for mentioning that.
>
> It seems to work with the limited test did:
> ifconfig eth1 up
> udhcpc -i lan1
> iperf -c mylaptop
>
> (same for lan4)
>
> However is there a way to be sure that the new binding is used?
The best way is probably to make sure that your switch device appears
parented to the MDIO bus driver under /sys/class/mdio_bus/*mvmdio*.
Alternatively, if you see a message like:
DSA: switch 0 0 parsed
in your dmesg, that would also be indicative of using the new binding
and corresponding code.
Thanks a lot for trying that out!
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/8] ARM: dts: armada-370-rd: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-04 17:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20170103163609.GE32450-g2DYL2Zd6BY@public.gmane.org>
On 01/03/2017 08:36 AM, Andrew Lunn wrote:
>> +
>> + switch: switch@10 {
>> + compatible = "marvell,mv88e6085";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <16>;
>
> Hummm, a device tree question. switch@10, reg = <16>. Is there an
> implicit understanding that the 10 is hex?
Most (if not all?) unit addresses are hexadecimal, which is why this was
chosen here, but I really don't mind changing that.
--
Florian
--
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 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Vivien Didelot @ 2017-01-04 17:38 UTC (permalink / raw)
To: Florian Fainelli, Gregory CLEMENT
Cc: linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <5a40436a-ebad-8a94-c5c5-546ba33ba545@gmail.com>
Hi Florian, All,
Florian Fainelli <f.fainelli@gmail.com> writes:
>> However is there a way to be sure that the new binding is used?
>
> The best way is probably to make sure that your switch device appears
> parented to the MDIO bus driver under /sys/class/mdio_bus/*mvmdio*.
> Alternatively, if you see a message like:
>
> DSA: switch 0 0 parsed
>
> in your dmesg, that would also be indicative of using the new binding
> and corresponding code.
That makes me think that we should either remove, or use different
values for the version described in net/dsa/dsa.c:
char dsa_driver_version[] = "0.1";
Today this is absolutely useless and erroneous.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-04 17:42 UTC (permalink / raw)
To: Vivien Didelot
Cc: Florian Fainelli, Gregory CLEMENT, linux-arm-kernel, Jason Cooper,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <87fuky7mjt.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
> That makes me think that we should either remove, or use different
> values for the version described in net/dsa/dsa.c:
>
> char dsa_driver_version[] = "0.1";
>
> Today this is absolutely useless and erroneous.
I think it has been useless for over 9 years.
Feel free to remove it.
Andrew
^ permalink raw reply
* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Vivien Didelot @ 2017-01-04 17:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Gregory CLEMENT, linux-arm-kernel, Jason Cooper,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20170104174248.GG5517@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
>> That makes me think that we should either remove, or use different
>> values for the version described in net/dsa/dsa.c:
>>
>> char dsa_driver_version[] = "0.1";
>>
>> Today this is absolutely useless and erroneous.
>
> I think it has been useless for over 9 years.
Do we want to get rid of it, or do we want to have a string version per
DSA implementation? (old vs. new bindings).
I don't like the actual way to distinguish between the two (grep'ing
dmesg as Florian shown). Maybe a pr_info in dsa2.c would be enough to
inform about DSA "v2". What do you guys prefer?
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH V2 4/5] PCI: exynos: support the using PHY generic framework
From: Krzysztof Kozlowski @ 2017-01-04 17:50 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, krzk, kishon, jingoohan1,
vivek.gautam, pankaj.dubey, alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-5-jh80.chung@samsung.com>
On Wed, Jan 04, 2017 at 09:34:34PM +0900, Jaehoon Chung wrote:
> This patch is for using PHY generic framework.
> To maintain backward compatibility, check whether phy is supported or
> not with 'using_phy'.
>
> And if someone use the old dt-file, display the "deprecated" message.
> But it's still working fine with it.
This needs improvements. How about:
"Switch the pci-exynos driver to generic PHY framework. At the same time
backward compatibility is preserved: warning will be printed for old
DTB.
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> Changelog on V2:
> - This patch is split from previous PATCH[1/4]
> - Maintain the backward compatibility
> - Adds 'using_phy' for cheching whether phy framework is used or not
> - Adds 'DEPRECATED' message for old dt-binding way
>
> drivers/pci/host/pci-exynos.c | 61 +++++++++++++++++++++++++++++++++++--------
> 1 file changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index feed0fd..34f2eed 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -21,6 +21,7 @@
> #include <linux/of_gpio.h>
> #include <linux/pci.h>
> #include <linux/platform_device.h>
> +#include <linux/phy/phy.h>
> #include <linux/resource.h>
> #include <linux/signal.h>
> #include <linux/types.h>
> @@ -110,6 +111,10 @@ struct exynos_pcie {
> struct exynos_pcie_clk_res *clk_res;
> const struct exynos_pcie_ops *ops;
> int reset_gpio;
> +
> + /* For Generic PHY Framework */
> + bool using_phy;
> + struct phy *phy;
> };
>
> struct exynos_pcie_ops {
> @@ -135,6 +140,10 @@ static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
> if (IS_ERR(ep->mem_res->elbi_base))
> return PTR_ERR(ep->mem_res->elbi_base);
>
> + /* If using the PHY framework, doesn't need to get other resource */
> + if (ep->using_phy)
> + return 0;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
> if (IS_ERR(ep->mem_res->phy_base))
> @@ -396,17 +405,28 @@ static int exynos_pcie_establish_link(struct exynos_pcie *exynos_pcie)
> }
>
> exynos_pcie_assert_core_reset(exynos_pcie);
> - exynos_pcie_assert_phy_reset(exynos_pcie);
> - exynos_pcie_deassert_phy_reset(exynos_pcie);
> - exynos_pcie_power_on_phy(exynos_pcie);
> - exynos_pcie_init_phy(exynos_pcie);
> -
> - /* pulse for common reset */
> - exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> - PCIE_PHY_COMMON_RESET);
> - udelay(500);
> - exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> - PCIE_PHY_COMMON_RESET);
> +
> + if (exynos_pcie->using_phy) {
> + phy_reset(exynos_pcie->phy);
> +
> + exynos_pcie_writel(exynos_pcie->mem_res->elbi_base, 1,
> + PCIE_PWR_RESET);
> +
> + phy_power_on(exynos_pcie->phy);
> + phy_init(exynos_pcie->phy);
> + } else {
> + exynos_pcie_assert_phy_reset(exynos_pcie);
> + exynos_pcie_deassert_phy_reset(exynos_pcie);
> + exynos_pcie_power_on_phy(exynos_pcie);
> + exynos_pcie_init_phy(exynos_pcie);
> +
> + /* pulse for common reset */
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> + PCIE_PHY_COMMON_RESET);
> + udelay(500);
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> + PCIE_PHY_COMMON_RESET);
> + }
>
> exynos_pcie_deassert_core_reset(exynos_pcie);
> dw_pcie_setup_rc(pp);
> @@ -420,6 +440,11 @@ static int exynos_pcie_establish_link(struct exynos_pcie *exynos_pcie)
> if (!dw_pcie_wait_for_link(pp))
> return 0;
>
> + if (exynos_pcie->using_phy) {
> + phy_power_off(exynos_pcie->phy);
> + return -ETIMEDOUT;
> + }
> +
> while (exynos_pcie_readl(exynos_pcie->mem_res->phy_base,
> PCIE_PHY_PLL_LOCKED) == 0) {
> val = exynos_pcie_readl(exynos_pcie->mem_res->block_base,
> @@ -633,6 +658,17 @@ static int __init exynos_pcie_probe(struct platform_device *pdev)
>
> exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
>
> + /* Assume that controller doesn't use the PHY framework */
> + exynos_pcie->using_phy = false;
> +
> + exynos_pcie->phy = devm_of_phy_get(dev, np, NULL);
> + if (IS_ERR(exynos_pcie->phy)) {
> + if (PTR_ERR(exynos_pcie->phy) == -EPROBE_DEFER)
> + return PTR_ERR(exynos_pcie->phy);
> + dev_warn(dev, "Use the 'phy' property. Current DT of pci-exynos was deprecated!!\n");
> + } else
> + exynos_pcie->using_phy = true;
> +
> if (exynos_pcie->ops && exynos_pcie->ops->get_mem_resources) {
> ret = exynos_pcie->ops->get_mem_resources(pdev, exynos_pcie);
> if (ret)
> @@ -657,6 +693,9 @@ static int __init exynos_pcie_probe(struct platform_device *pdev)
> return 0;
>
> fail_probe:
> + if (exynos_pcie->using_phy)
> + phy_exit(exynos_pcie->phy);
> +
> if (exynos_pcie->ops && exynos_pcie->ops->deinit_clk_resources)
> exynos_pcie->ops->deinit_clk_resources(exynos_pcie);
> return ret;
> --
> 2.10.2
>
^ permalink raw reply
* Re: [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Boris Brezillon @ 2017-01-04 17:50 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: Cédric Le Goater, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
Marek Vasut, Rob Herring, Joel Stanley, Brian Norris,
David Woodhouse
In-Reply-To: <4c5cf674-06f9-ad6b-05bf-a1d39aaa7ed5-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Cyrille, Cédric,
On Wed, 4 Jan 2017 15:52:07 +0100
Cyrille Pitchen <cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> Anyway, since the review is done now, on my side I won't ask you to remove
> >> or split the support of the 'Command' mode in a separated patch.
> >> I let you do as you want, if it help you to introduce some part of the
> >> support of this 'Command' mode now even if not completed yet, no problem on
> >> my side :)
> >>
> >> I was just giving you some pieces of advice for the next time if you want
> >> to speed up the review of another patch introducing new features.
> >>
> >> However, I will just ask you one more version handling the dummy cycles
> >> properly as it would help us for the global maintenance of the spi-nor
> >> subsystem. This is the only mandatory modification I ask you, after that I
> >> think it would be ok for me and since Marek has already reviewed your
> >> driver, it would be ready to be merged into the spi-nor tree.
> >
> > Sending a v5 which should address your comments.
> >
> > I have removed the label property and will start a new thread in the
> > topic. Any hints on which binding we could add this label prop ?
> >
>
> Here I will provide just few thoughts about this new DT property. I don't
> pretend this is what should be done. I still think other mtd maintainers
> should be involved to discuss this topic.
>
> First the DT property name "label" sounds good to me: it is consistent with
> "label" DT property used to name mtd partitions. However, I don't think it
> should be documented in jedec,spi-nor.txt but *maybe* in partition.txt as
> the purpose of this new DT property seems very close to the "label"
> property of partition nodes: let's think about some hard-disk device
> (/dev/sda) and its partition devices (/dev/sdaX).
Hm, partition.txt may not be appropriate here. We're not documenting
the MTD partition binding, but the MTD device one. Maybe we should
create mtd.txt and put all generic MTD dev properties here.
>
> Besides, the concept of this memory label is not limited to SPI NOR but
> could also apply to NAND memories or any other MTD handled memories.
Definitely. Actually I think I'll need that for the Atmel NAND
controller driver rework I'm currently working on, to keep mtdparts
parser happy even after changing the NAND device naming scheme.
> Hence the DT property might be handled by drivers/mtd/ofpart.c instead of
> being handled by spi-nor.c or by each SPI NOR memory controller driver.
Actually, that could be done at the mtdcore level in
mtd_set_dev_defaults() [1].
>
> Finally, I guess we should take time to discuss and all agree what should
> be done precisely before introducing a new DT property because one general
> rule with DTB files is that users should be able to update their kernel
> image (zImage, uImage, ...) without changing their DTB: device trees should
> be backward compatible. Hence if we make a wrong choice today, we are
> likely to have to live with it and keep supporting that bad choice.
Rob already acked the patch, so, if all MTD maintainers agree that this
new property is acceptable, we should be fine ;-).
>
> Anyway, maybe you could describe a little bit your use case; what you
> intend to do with this label from you userspace application.
Here is mine: I want the mtdparts parser to work correctly with
existing bootloaders even after changing the NAND device naming scheme
to allow one NAND controller to expose multiple devices.
Current naming scheme: NAND device name is always atmel_nand
New naming sheme: atmel-nand.%d where %d is replaced by the CS line
number the NAND device is connected too.
Also note that it's easier to refer to a flash device by it's purpose
(like System-firmware in Cedric's example) rather than the controller
CS line this device is connected to.
Regards,
Boris
[1]http://code.bulix.org/p019ah-107877
--
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 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy
From: Krzysztof Kozlowski @ 2017-01-04 17:52 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, krzk, kishon, jingoohan1,
vivek.gautam, pankaj.dubey, alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-3-jh80.chung@samsung.com>
On Wed, Jan 04, 2017 at 09:34:32PM +0900, Jaehoon Chung wrote:
> This patch supports to use Generic Phy framework for Exynos PCIe phy.
> When Exynos that supported the pcie want to use the PCIe,
> it needs to control the phy resgister.
> But it should be more complex to control in their own PCIe device drivers.
>
> Currently, there is an exynos5440 case to support the pcie.
> So this driver is based on Exynos5440 PCIe.
> In future, will support the Other exynos SoCs likes exynos5433, exynos7.
I have troubles understanding this. Please, work on the commit message.
For the code itself:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
... but commit message is really important to understand why/what was
done.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Nishanth Menon @ 2017-01-04 17:57 UTC (permalink / raw)
To: Tony Lindgren, Linus Walleij
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Lokesh Vutla
In-Reply-To: <20170102221228.GH9325-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On 01/02/2017 04:12 PM, Tony Lindgren wrote:
[...]
I got the following warnings with kernel-doc:
> $ ./scripts/kernel-doc drivers/pinctrl/ti/pinctrl-ti-iodelay.c>/dev/null
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:132: warning: Excess struct/union/enum/typedef member 'name' description in 'ti_iodelay_pingroup'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:132: warning: Excess struct/union/enum/typedef member 'map' description in 'ti_iodelay_pingroup'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:159: warning: Excess struct/union/enum/typedef member 'names' description in 'ti_iodelay_device'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:211: warning: No description found for parameter 'cfg'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:211: warning: Excess function parameter 'val' description in 'ti_iodelay_pinconf_set'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:418: warning: Cannot understand *
> on line 418 - I thought it was a doc line
Marking them below
> diff --git a/drivers/pinctrl/ti/pinctrl-ti-iodelay.c b/drivers/pinctrl/ti/pinctrl-ti-iodelay.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/pinctrl/ti/pinctrl-ti-iodelay.c
[...]
> +/**
> + * struct ti_iodelay_pingroup - Structure that describes one group
> + * @name: Name of the group
^^--> we should drop this
> + * @map: pinctrl map allocated for the group
^^--> we should drop this
> + * @cfg: configuration array for the pin (from dt)
> + * @ncfg: number of configuration values allocated
> + * @config: pinconf "Config" - currently a dummy value
> + */
> +struct ti_iodelay_pingroup {
> + struct ti_iodelay_cfg *cfg;
> + int ncfg;
> + unsigned long config;
> +};
> +
> +/**
> + * struct ti_iodelay_device - Represents information for a iodelay instance
> + * @dev: Device pointer
> + * @phys_base: Physical address base of the iodelay device
> + * @reg_base: Virtual address base of the iodelay device
> + * @regmap: Regmap for this iodelay instance
> + * @pctl: Pinctrl device
> + * @desc: pinctrl descriptor for pctl
> + * @pa: pinctrl pin wise description
> + * @names: names of the pins
^^--> we should drop this
> + * @reg_data: Register definition data for the IODelay instance
> + * @reg_init_conf_values: Initial configuration values.
> + */
> +struct ti_iodelay_device {
> + struct device *dev;
> + unsigned long phys_base;
> + void __iomem *reg_base;
> + struct regmap *regmap;
> +
> + struct pinctrl_dev *pctl;
> + struct pinctrl_desc desc;
> + struct pinctrl_pin_desc *pa;
> +
> + const struct ti_iodelay_reg_data *reg_data;
> + struct ti_iodelay_reg_values reg_init_conf_values;
> +};
> +
[...]
> +/**
> + * ti_iodelay_pinconf_set() - Configure the pin configuration
> + * @iod: iodelay device
> + * @val: Configuration value
^^ --> should be cfg ?
> + *
> + * Update the configuration register as per TRM and lockup once done.
> + * *IMPORTANT NOTE* SoC TRM does recommend doing iodelay programmation only
> + * while in Isolation. But, then, isolation also implies that every pin
> + * on the SoC (including DDR) will be isolated out. The only benefit being
> + * a glitchless configuration, However, the intent of this driver is purely
> + * to support a "glitchy" configuration where applicable.
> + *
> + * Return: 0 in case of success, else appropriate error value
> + */
> +static int ti_iodelay_pinconf_set(struct ti_iodelay_device *iod,
> + struct ti_iodelay_cfg *cfg)
[...]
> +
> +/**
> + *
Could you make this:
* ti_iodelay_node_iterator() - Iterate iodelay node
> + * @pctldev: Pin controller driver
> + * @np: Device node
> + * @pinctrl_spec: Parsed arguments from device tree
> + * @pins: Array of pins in the pin group
> + * @pin_index: Pin index in the pin array
> + * @data: Pin controller driver specific data
> + *
> + */
> +static int ti_iodelay_node_iterator(struct pinctrl_dev *pctldev,
> + struct device_node *np,
> + const struct of_phandle_args *pinctrl_spec,
> + int *pins, int pin_index, void *data)
[...]
Otherwise, the patch looks fine. Thanks for doing this.
--
Regards,
Nishanth Menon
--
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 5/5] ARM: dts: exynos5440: support the phy-pcie node for pcie
From: Krzysztof Kozlowski @ 2017-01-04 17:58 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, krzk, kishon, jingoohan1,
vivek.gautam, pankaj.dubey, alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-6-jh80.chung@samsung.com>
On Wed, Jan 04, 2017 at 09:34:35PM +0900, Jaehoon Chung wrote:
> Add phy-pcie node for using Exynos5440 pcie.
> And use the reg-names as "elbi" and "config".
'and' is only for joining in compound sentences, don't start with it.
> Because the getting configuratioin space address from ranges is old way.
Spell-check please.
> It also is helpful to distinguish more clearly.
Distinguish what? Please work on the commit msg, I am not picking
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> Changelog on V2:
> - Removes the child-node
> - Fixes the typo
> - Removes the unnecessary comments
>
> arch/arm/boot/dts/exynos5440.dtsi | 34 ++++++++++++++++++++++------------
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
> index 2a2e570..feb074d 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -290,11 +290,22 @@
> clock-names = "usbhost";
> };
>
> + pcie_phy0: pcie-phy@270000 {
> + #phy-cells = <0>;
> + compatible = "samsung,exynos5440-pcie-phy";
> + reg = <0x270000 0x1000>, <0x271000 0x40>;
> + };
> +
> + pcie_phy1: pcie-phy@272000 {
> + #phy-cells = <0>;
> + compatible = "samsung,exynos5440-pcie-phy";
> + reg = <0x272000 0x1000>, <0x271040 0x40>;
> + };
> +
> pcie_0: pcie@290000 {
> compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x290000 0x1000
> - 0x270000 0x1000
> - 0x271000 0x40>;
> + reg = <0x290000 0x1000>, <0x40000000 0x1000>;
> + reg-names = "elbi", "config";
> interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> @@ -303,9 +314,9 @@
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> - ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
> - 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
> - 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
> + phys = <&pcie_phy0>;
> + ranges = <0x81000000 0 0 0x40001000 0 0x00010000
> + 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>;
I think the comments were useful. You can leave them.
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 0>;
> interrupt-map = <0x0 0 &gic 53>;
> @@ -315,9 +326,8 @@
>
> pcie_1: pcie@2a0000 {
> compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a0000 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> + reg = <0x2a0000 0x1000>, <0x60000000 0x1000>;
> + reg-names = "elbi", "config";
> interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> @@ -326,9 +336,9 @@
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> - ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
> - 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
> - 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
> + phys = <&pcie_phy1>;
> + ranges = <0x81000000 0 0 0x60001000 0 0x00010000
> + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>;
I think the comments were useful. You can leave them.
This looks like depending on the changes in the driver, so I will need a
tag or stable branch from PCIe maintainers.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This new file should be used for properties that apply to all wireless
devices.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Switch to a single ieee80211-freq-limit property that allows specifying
*multiple* ranges. This resolves problem with more complex rules as pointed
by Felx.
Make description implementation agnostic as pointed by Arend.
Rename node to wifi as suggested by Martin.
V3: Use more real-life frequencies in the example.
V5: Describe hardware design as possible use for this property
V6: Even better property description, thanks Rob for your help!
---
.../devicetree/bindings/net/wireless/ieee80211.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
new file mode 100644
index 0000000..f6442b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
@@ -0,0 +1,24 @@
+Common IEEE 802.11 properties
+
+This provides documentation of common properties that are valid for all wireless
+devices.
+
+Optional properties:
+ - ieee80211-freq-limit : list of supported frequency ranges in KHz. This can be
+ used for devices that in a given config support less channels than
+ normally. It may happen chipset supports a wide wireless band but it is
+ limited to some part of it due to used antennas or power amplifier.
+ An example case for this can be tri-band wireless router with two
+ identical chipsets used for two different 5 GHz subbands. Using them
+ incorrectly could not work or decrease performance noticeably.
+
+Example:
+
+pcie@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ wifi@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ ieee80211-freq-limit = <2402000 2482000>,
+ <5170000 5250000>;
+ };
+};
--
2.10.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
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